#9884 closed defect (fixed)
CRF affects the number of produced frames in VP9
Reported by: | Athari | Owned by: | |
---|---|---|---|
Priority: | normal | Component: | avcodec |
Version: | git-master | Keywords: | libvpx |
Cc: | Athari | Blocked By: | |
Blocking: | Reproduced by developer: | yes | |
Analyzed by developer: | yes |
Description
I have 12 input frames in PNG format. When I encode WebM+VP9 with -crf 0
, I get a video with 3 frames. When I encode with -crf 20
, I get 6 frames. When I encode with -crf 40
, I get 12 frames. MKVToolNix info tool confirms that there're only 3/6 block groups in the clusters of the incomplete videos.
FFMPEG reads all 12 frames, encodes all 12 frames, but then muxes only 3 packets with no explanation.
Changing the container (MKV, MP4, IVF) doesn't affect the result. Encoding with VP8 always produces a video with the correct duration (ranging from -c:v libvpx -crf 63 -qmin 63 -qmax 63 -b:v 500 -auto-alt-ref 0
to -c:v libvpx -crf 0 -qmin 0 -qmax 0 -b:v 100M -auto-alt-ref 0
). I tried changing various parameters of VP9 too, but none of them affected the result. Other sequences of frames seem to be encoded correctly with the same arguments.
Output from -crf 0
:
> ffmpeg -y -loglevel debug -r 10 -i "%04d.png" -framerate 10 -crf 0 "_.webm" ffmpeg version 2022-05-08-git-f77ac5131c-full_build-www.gyan.dev Copyright (c) 2000-2022 the FFmpeg developers built with gcc 11.3.0 (Rev1, Built by MSYS2 project) configuration: --enable-gpl --enable-version3 --enable-static --disable-w32threads --disable-autodetect --enable-fontconfig --enable-iconv --enable-gnutls --enable-libxml2 --enable-gmp --enable-bzlib --enable-lzma --enable-libsnappy --enable-zlib --enable-librist --enable-libsrt --enable-libssh --enable-libzmq --enable-avisynth --enable-libbluray --enable-libcaca --enable-sdl2 --enable-libdav1d --enable-libdavs2 --enable-libuavs3d --enable-libzvbi --enable-librav1e --enable-libsvtav1 --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxavs2 --enable-libxvid --enable-libaom --enable-libjxl --enable-libopenjpeg --enable-libvpx --enable-mediafoundation --enable-libass --enable-frei0r --enable-libfreetype --enable-libfribidi --enable-liblensfun --enable-libvidstab --enable-libvmaf --enable-libzimg --enable-amf --enable-cuda-llvm --enable-cuvid --enable-ffnvcodec --enable-nvdec --enable-nvenc --enable-d3d11va --enable-dxva2 --enable-libmfx --enable-libshaderc --enable-vulkan --enable-libplacebo --enable-opencl --enable-libcdio --enable-libgme --enable-libmodplug --enable-libopenmpt --enable-libopencore-amrwb --enable-libmp3lame --enable-libshine --enable-libtheora --enable-libtwolame --enable-libvo-amrwbenc --enable-libilbc --enable-libgsm --enable-libopencore-amrnb --enable-libopus --enable-libspeex --enable-libvorbis --enable-ladspa --enable-libbs2b --enable-libflite --enable-libmysofa --enable-librubberband --enable-libsoxr --enable-chromaprint libavutil 57. 24.101 / 57. 24.101 libavcodec 59. 27.100 / 59. 27.100 libavformat 59. 23.100 / 59. 23.100 libavdevice 59. 6.100 / 59. 6.100 libavfilter 8. 38.100 / 8. 38.100 libswscale 6. 6.100 / 6. 6.100 libswresample 4. 6.100 / 4. 6.100 libpostproc 56. 5.100 / 56. 5.100 ... Output #0, webm, to '_.webm': Metadata: encoder : Lavf59.23.100 Stream #0:0, 0, 1/1000: Video: vp9, 1 reference frame, yuva420p(tv, progressive), 100x100 (0x0) [SAR 1:1 DAR 1:1], 0/1, q=2-31, 10 fps, 1k tbn Metadata: encoder : Lavc59.27.100 libvpx-vp9 Side data: cpb: bitrate max/min/avg: 0/0/0 buffer size: 0 vbv_delay: N/A Clipping frame in rate conversion by 0.000008 cur_dts is invalid st:0 (0) [init:1 i_done:0 finish:0] (this is harmless if it occurs once at the start per stream) Last message repeated 12 times [out_0_0 @ 000001a5138c5ec0] EOF on sink link out_0_0:default. ... [webm @ 000001a5137ef8c0] Writing block of size 7331 with pts 200, dts 200, duration 100 at relative offset 17446 in cluster at offset 494. TrackNumber 1, keyframe 0 [webm @ 000001a5137ef8c0] end duration = 300 [webm @ 000001a5137ef8c0] stream 0 end duration = 300 frame= 12 fps=0.0 q=0.0 Lsize= 26kB time=00:00:00.20 bitrate=1048.1kbits/s speed=0.487x video:22kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 17.963535% Input file #0 (%04d.png): Input stream #0:0 (video): 12 packets read (202119 bytes); 12 frames decoded; Total: 12 packets (202119 bytes) demuxed Output file #0 (_.webm): Output stream #0:0 (video): 12 frames encoded; 3 packets muxed (22323 bytes); Total: 3 packets (22323 bytes) muxed [AVIOContext @ 000001a51385f5c0] Statistics: 26333 bytes written, 0 seeks, 1 writeouts 12 frames successfully decoded, 0 decoding errors
The attached archive includes input frames, output videos, full logs in debug mode produced with 3 different CRF values.
Attachments (1)
Change History (12)
by , 2 years ago
Attachment: | frames-videos-logs.zip added |
---|
follow-up: 2 comment:1 by , 2 years ago
Crf 0 is not lossless for vp9. This is:
ffmpeg -i input.mp4 -c:v libvpx-vp9 -lossless 1 output.webm
follow-up: 3 comment:2 by , 2 years ago
Replying to Balling:
Crf 0 is not lossless for vp9. This is:
ffmpeg -i input.mp4 -c:v libvpx-vp9 -lossless 1 output.webm
Both -lossless 1
and -crf 0
produce the same number of frames, 3 out of 12.
comment:3 by , 2 years ago
Status: | new → open |
---|
Replying to Athari:
Both
-lossless 1
and-crf 0
produce the same number of frames, 3 out of 12.
Yes, I was just saying. -c:v av1 -crf 0 is lossless though. But that does not preserve alpha yet.
I will open since it does look like a bug.
follow-up: 5 comment:4 by , 2 years ago
Analyzed by developer: | set |
---|---|
Component: | undetermined → avcodec |
Reproduced by developer: | set |
Version: | unspecified → git-master |
This happens only when you try to encode a stream with an alpha channel. The alpha channel is encoded as a separate stream, and our wrapper is not handling it right.
If you don't care about retaining that from your input images, a workaround is to force a pixel format without alpha, using -pix_fmt yuv420p or similar.
follow-up: 6 comment:5 by , 2 years ago
Replying to James:
This happens only when you try to encode a stream with an alpha channel. The alpha channel is encoded as a separate stream, and our wrapper is not handling it right.
If you don't care about retaining that from your input images, a workaround is to force a pixel format without alpha, using -pix_fmt yuv420p or similar.
I need this for Telegram, so VP9+YUVA420p+WebM is the only option for me.
follow-up: 7 comment:6 by , 2 years ago
Replying to Athari:
I need this for Telegram, so VP9+YUVA420p+WebM is the only option for me.
I submitted a fix for this a few hours ago. See https://patchwork.ffmpeg.org/project/ffmpeg/patch/20220821172047.1709-1-jamrial@gmail.com/
Can you confirm it works for you?
follow-up: 8 comment:7 by , 2 years ago
Replying to James:
I submitted a fix for this a few hours ago. See https://patchwork.ffmpeg.org/project/ffmpeg/patch/20220821172047.1709-1-jamrial@gmail.com/
Can you confirm it works for you?
Yes, it works correctly for me now, thank you!
P.S. Is it normally assumed here that a random bug reporter will be able to build FFMPEG with a patch applied? :)
comment:8 by , 2 years ago
Replying to Athari:
Replying to James:
I submitted a fix for this a few hours ago. See https://patchwork.ffmpeg.org/project/ffmpeg/patch/20220821172047.1709-1-jamrial@gmail.com/
Can you confirm it works for you?
Yes, it works correctly for me now, thank you!
Thanks for confirming.
P.S. Is it normally assumed here that a random bug reporter will be able to build FFMPEG with a patch applied? :)
No, but when they can it helps testing patches.
comment:9 by , 2 years ago
Resolution: | → fixed |
---|---|
Status: | open → closed |
Should be fixed in 9c7a8a8546e0bea9a32174cb40cefda5ddc45001
comment:10 by , 2 years ago
Keywords: | libvpx added |
---|
Frames, Videos, Logs