Opened 10 months ago

Last modified 10 months ago

#10437 new defect

webp codec does not report progress

Reported by: Jozef Chutka Owned by:
Priority: normal Component: undetermined
Version: git-master Keywords: webp
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

Using ffmpeg 6.0 (same results on nightly build), when encodinginto animated webp, the reported progress does not provide accurate information:

ffmpeg -i input.mp4 -f webp -vcodec webp output.webp -y

I am using some 30 seconds 720p video input.mp4

...
frame=    0 fps=0.0 q=0.0 size=       0kB time=-577014:32:22.77 bitrate=  -0.0kbits/s speed=N/A    
frame=    0 fps=0.0 q=0.0 size=       0kB time=-577014:32:22.77 bitrate=  -0.0kbits/s speed=N/A    
frame=    0 fps=0.0 q=0.0 size=       0kB time=-577014:32:22.77 bitrate=  -0.0kbits/s speed=N/A    
frame=    0 fps=0.0 q=0.0 size=       0kB time=-577014:32:22.77 bitrate=  -0.0kbits/s speed=N/A    
frame=    0 fps=0.0 q=0.0 size=       0kB time=-577014:32:22.77 bitrate=  -0.0kbits/s speed=N/A    
frame=    0 fps=0.0 q=0.0 size=       0kB time=-577014:32:22.77 bitrate=  -0.0kbits/s speed=N/A    
[out#0/webp @ 0x1af0ec0] video:783kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.000000%
frame=    1 fps=0.3 q=-0.0 Lsize=     783kB time=00:00:00.00 bitrate=N/A speed=   0x    

The log ends with frame=1, however there is ~740 in the output.webp

Change History (2)

comment:1 by Marton Balint, 10 months ago

This is because the WebP anim encoder outputs a single packet after processing all the input frames.

This is a very unusual way for an encoder to operate, and the only reason it can get away with it (and with storing the whole encoded bitstream in-memory) is that WebP animations are usually very short. There is not much we can do about this, because the WebPAnimEncoder API does not provide way to get the partial bitstream.

The frame=xxx in the status line actually means the number of written packets, therefore it will be 1.

comment:2 by Jozef Chutka, 10 months ago

Hi Marton,

thanks for the insights.

In my project I am streaming raw data into ffmpeg via stdin and so have a good control over how many frames has beed provided. I am able report progress based on that. It might not be perfectly accurate but still better then no information.

I wonder, if this is something you might want to do on ffmpeg side, I mean ffmpeg is aware of how many frames were sent into WebPAnimEncoder, and could use the information for frame=xxx log ... Or is this too hacky to implement?

Note: See TracTickets for help on using tickets.