[FFmpeg-devel] [PATCH] fix VVC encoding with leading pictures
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). This
leads to FFmpeg generating an edit list with an empty entry, skipping
the leading pictures.
This patch fixes the calculation for the start_pts, while the DTS is
negative (as produced by libvvenc).
How to reproduce the issue (needs --enable-libvvenc and a recent
libvvenc, e.g. v1.13):
Encode VVC directly into MP4 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
When dumping the mp4-structure using 'MP4Box -diso test.mp4', I see the
following EditListBox, which skips the first couple of
frames:Specification="p12" Container="edts" EntryCount="2">
With the fix applied 300 frames are decoded as expected and the
EditListBox looks like this:
Specification="p12" Container="edts" EntryCount="1">
From acbafeaeb7926af495a9c375903b0c190af6af88 Mon Sep 17 00:00:00 2001
From: Gabriel Hege
Date: Wed, 16 Apr 2025 13:51:06 +0200
Subject: [PATCH] fix VVC encoding with leading pictures
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). This
leads to FFmpeg generating an edit list with an empty entry, skipping
the leading pictures.
This patch fixes the calculation for the start_pts, while the DTS is
negative (as produced by vvenc).
Signed-off-by: Gabriel Hege
---
libavformat/movenc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 4bc8bd1b2a..305f920022 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -3966,7 +3966,7 @@ static int mov_write_edts_tag(AVIOContext *pb, MOVMuxContext *mov,
int flags = 0;
if (track->entry) {
-if (start_dts != track->cluster[0].dts || start_ct != track->cluster[0].cts) {
+if (start_dts != track->cluster[0].dts || (start_ct != track->cluster[0].cts && track->cluster[0].dts >= 0)) {
av_log(mov->fc, AV_LOG_DEBUG,
"EDTS using dts:%"PRId64" cts:%d instead of dts:%"PRId64" cts:%"PRId64" tid:%d\n",
@@ -6928,7 +6928,7 @@ int ff_mov_write_packet(AVFormatContext *s, AVPacket *pkt)
trk->flags |= MOV_TRACK_CTTS;
trk->cluster[trk->entry].cts = pkt->pts - pkt->dts;
trk->cluster[trk->entry].flags = 0;
-if (trk->start_cts == AV_NOPTS_VALUE)
+if (trk->start_cts == AV_NOPTS_VALUE || (pkt->dts <= 0 && trk->start_cts > pkt->pts - pkt->dts))
trk->start_cts = pkt->pts - pkt->dts;
if (trk->end_pts == AV_NOPTS_VALUE)
trk->end_pts = trk->cluster[trk->entry].dts +
--
2.43.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avformat/movenc: fix VVC encoding with leading pictures
This is a resubmission with a corrected commit message.
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). This
leads to FFmpeg generating an edit list with an empty entry, skipping
the leading pictures.
This patch fixes the calculation for the start_pts, while the DTS is
negative (as produced by libvvenc).
How to reproduce the issue (needs --enable-libvvenc and a recent
libvvenc, e.g. v1.13):
Encode VVC directly into MP4 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
When dumping the mp4-structure using 'MP4Box -diso test.mp4', I see the
following EditListBox, which skips the first couple of
frames:Specification="p12" Container="edts" EntryCount="2">
With the fix applied 300 frames are decoded as expected and the
EditListBox looks like this:
Specification="p12" Container="edts" EntryCount="1">
From d241417038ef78c1d2eb6c38e515a5153082a65f Mon Sep 17 00:00:00 2001
From: Gabriel Hege
Date: Wed, 16 Apr 2025 13:51:06 +0200
Subject: [PATCH] avformat/movenc: fix VVC encoding with leading pictures
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). This
leads to FFmpeg generating an edit list with an empty entry, skipping
the leading pictures.
This patch fixes the calculation for the start_pts, while the DTS is
negative (as produced by vvenc).
Signed-off-by: Gabriel Hege
---
libavformat/movenc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 4bc8bd1b2a..305f920022 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -3966,7 +3966,7 @@ static int mov_write_edts_tag(AVIOContext *pb, MOVMuxContext *mov,
int flags = 0;
if (track->entry) {
-if (start_dts != track->cluster[0].dts || start_ct != track->cluster[0].cts) {
+if (start_dts != track->cluster[0].dts || (start_ct != track->cluster[0].cts && track->cluster[0].dts >= 0)) {
av_log(mov->fc, AV_LOG_DEBUG,
"EDTS using dts:%"PRId64" cts:%d instead of dts:%"PRId64" cts:%"PRId64" tid:%d\n",
@@ -6928,7 +6928,7 @@ int ff_mov_write_packet(AVFormatContext *s, AVPacket *pkt)
trk->flags |= MOV_TRACK_CTTS;
trk->cluster[trk->entry].cts = pkt->pts - pkt->dts;
trk->cluster[trk->entry].flags = 0;
-if (trk->start_cts == AV_NOPTS_VALUE)
+if (trk->start_cts == AV_NOPTS_VALUE || (pkt->dts <= 0 && trk->start_cts > pkt->pts - pkt->dts))
trk->start_cts = pkt->pts - pkt->dts;
if (trk->end_pts == AV_NOPTS_VALUE)
trk->end_pts = trk->cluster[trk->entry].dts +
--
2.43.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/movenc: fix VVC encoding with leading pictures
On 25.05.25 04:08, Nuo Mi wrote: On Thu, May 22, 2025 at 4:35 PM Gabriel Hege wrote: On 17.05.25 04:26, Nuo Mi wrote: On Fri, May 16, 2025 at 7:05 PM Gabriel Hege wrote: This is a resubmission with a corrected commit message. 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). This leads to FFmpeg generating an edit list with an empty entry, skipping the leading pictures. This patch fixes the calculation for the start_pts, while the DTS is negative (as produced by libvvenc). How to reproduce the issue (needs --enable-libvvenc and a recent libvvenc, e.g. v1.13): Hi Gabriel, Thank you for your patch. It addresses the MP4 issue, but it looks like MKV has the same problem as well. Hi Nuo Mi, I'm sorry I don't really have an understanding of the MKV format. I had a quick look at the code, but the processing seems quite different and I didn't really find the corresponding code locations to fix the problem there. Hi Gabriel, Thank you for checking. Could you help create a similar issue for MKV? Someone familiar with MKV might pick it up. I filed a bug report: https://trac.ffmpeg.org/ticket/11611 Hi James and all, If no one objects, I’ll push this. Thank you. Hi @James Almer , Could you please take a look at the patch when you have a moment? You've been the most active contributor to this file recently. Encode VVC directly into MP4 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 When dumping the mp4-structure using 'MP4Box -diso test.mp4', I see the following EditListBox, which skips the first couple of frames: With the fix applied 300 frames are decoded as expected and the EditListBox looks like this: ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/movenc: fix VVC encoding with leading pictures
On 17.05.25 04:26, Nuo Mi wrote: On Fri, May 16, 2025 at 7:05 PM Gabriel Hege wrote: This is a resubmission with a corrected commit message. 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). This leads to FFmpeg generating an edit list with an empty entry, skipping the leading pictures. This patch fixes the calculation for the start_pts, while the DTS is negative (as produced by libvvenc). How to reproduce the issue (needs --enable-libvvenc and a recent libvvenc, e.g. v1.13): Hi Gabriel, Thank you for your patch. It addresses the MP4 issue, but it looks like MKV has the same problem as well. Hi Nuo Mi, I'm sorry I don't really have an understanding of the MKV format. I had a quick look at the code, but the processing seems quite different and I didn't really find the corresponding code locations to fix the problem there. Hi @James Almer , Could you please take a look at the patch when you have a moment? You've been the most active contributor to this file recently. Encode VVC directly into MP4 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 When dumping the mp4-structure using 'MP4Box -diso test.mp4', I see the following EditListBox, which skips the first couple of frames: With the fix applied 300 frames are decoded as expected and the EditListBox looks like this: ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
