CRF affects the number of produced frames in VP9

[Athari]

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.

[Athari]

Frames, Videos, Logs

[Balling]

Crf 0 is not lossless for vp9. This is:
ffmpeg -i input.mp4 -c:v libvpx-vp9 -lossless 1 output.webm

[Athari]

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.

[Balling]

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.

[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.

[Athari]

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.

[James]

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?

[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!

P.S. Is it normally assumed here that a random bug reporter will be able to build FFMPEG with a patch applied? :)

[James]

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.

[James]

Should be fixed in 9c7a8a8546e0bea9a32174cb40cefda5ddc45001

[Carl Eugen Hoyos]

Duplicate of ticket #7759