Opened 16 months ago
Last modified 16 months ago
#11611 new defect
VVC in MKV container: IDRs with leading pictures not decoded correctly
| Reported by: | Gabriel Hege | Owned by: | |
|---|---|---|---|
| Priority: | normal | Component: | avformat |
| Version: | git-master | Keywords: | mkv vvc |
| Cc: | Blocked By: | ||
| Blocking: | Reproduced by developer: | no | |
| Analyzed by developer: | no |
Description (last modified by )
Summary of the bug:
The default behavior for VVenC (since v1.10.0) is to create an IDR with
leading pictures for the first picture in decoding order (POC 32). When this VVC bitstream is muxed to an MKV container and the resulting file is decoded, the leading pictures are missing.
The problem is that negative PTS are calculated for the leading pictures, so they are discarded.
I fixed the same issue for MP4 in libavformat/movenc.c (https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=14519), but I am not really familiar with the MKV format and the code looks quite different so I wasn't able apply the same solution for libavformat/matroskaenc.c.
How to reproduce:
FFmpeg needs to be built with --enable-libvvenc and a recent libvvenc, e.g. v1.14:
ffmpeg version N-119722-gbf6d3dc339 Copyright (c) 2000-2025 the FFmpeg developers built with gcc 13 (Ubuntu 13.3.0-6ubuntu2~24.04) configuration: --enable-libvvenc --disable-shared --enable-static --enable-gpl --enable-nonfree --enable-version3 --disable-doc --env='PKG_CONFIG_PATH=/home/hege/.local/lib/pkgconfig/'
Encode VVC directly into MKV container:
./ffmpeg -i /data/YUV/foreman_352x288_30Hz_i420_8.y4m -an -preset faster -vcodec vvc test.mkv
-> encodes 300 frames.
Decode to YUV (or play back using ffplay):
./ffmpeg -i test.mkv test.yuv
-> outputs 271 frames.
