#11611: VVC in MKV container: IDRs with leading pictures not decoded correctly
--------------------------------------+------------------------------------
Reporter: Gabriel Hege | Owner: (none)
Type: defect | Status: new
Priority: normal | Component: avformat
Version: git-master | Resolution:
Keywords: mkv vvc | Blocked By:
Blocking: | Reproduced by developer: 0
Analyzed by developer: 0 |
--------------------------------------+------------------------------------
Description changed by Gabriel Hege:
Old description:
> 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.mp4
> }}}
> -> encodes 300 frames.
>
> Decode to YUV (or play back using ffplay):
> {{{
> ./ffmpeg -i test.mp4 test.yuv
> }}}
> -> outputs 271 frames.
New description:
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.
--
--
Ticket URL: <https://trac.ffmpeg.org/ticket/11611#comment:1>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker
_______________________________________________
FFmpeg-trac mailing list
FFmpeg-trac@avcodec.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-trac
To unsubscribe, visit link above, or email
ffmpeg-trac-requ...@ffmpeg.org with subject "unsubscribe".
