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 , 10 months ago
comment:2 by , 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?
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.