| Message ID | CAL7-sS0UiHK2zEpaK143JEtZ3w17wy0jPO09WbWyz1r=fKxUsg@mail.gmail.com |
|---|---|
| State | New |
| Headers | show |
| Series | [FFmpeg-devel] fftools/ffmpeg: Restore DTS correction for VP9 copies | expand |
| Context | Check | Description |
|---|---|---|
| andriy/configure | warning | Failed to apply patch |
On 5/12/2021 10:02 AM, Danny Wu wrote: > Fixes ticket 9086. > > Since early 2021, some of YouTube's VP9 encodes have non-monotonous DTS. > This makes ffmpeg fatally fail when trying to copy or encode the V9 video. > > ffmpeg already includes functionality to correct this, however it was > disabled without explanation for VP9 stream copies in > 2e6636aa87303d37b112e79f093ca39500f92364 The reason is that a bitstream filter that merges frames into superframes (1 visible + up to 7 invisible) was implemented. > > This patch restores the DTS correction logic, and allows ffmpeg to correctly > encode (invalid) videos produced by youtube.com. I have verified that frames > are NOT being cut (so it does not re-introduce 4313). Shouldn't google not produce invalid files? Also, can you link one of these videos to test this issue? > --- > fftools/ffmpeg.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c > index 3ad11452da..67deb7762f 100644 > --- a/fftools/ffmpeg.c > +++ b/fftools/ffmpeg.c > @@ -823,7 +823,6 @@ static void write_packet(OutputFile *of, AVPacket > *pkt, OutputStream *ost, int u > } > if ((st->codecpar->codec_type == AVMEDIA_TYPE_AUDIO || > st->codecpar->codec_type == AVMEDIA_TYPE_VIDEO || > st->codecpar->codec_type == AVMEDIA_TYPE_SUBTITLE) && > pkt->dts != AV_NOPTS_VALUE && > - !(st->codecpar->codec_id == AV_CODEC_ID_VP9 && ost->stream_copy) && > ost->last_mux_dts != AV_NOPTS_VALUE) { > int64_t max = ost->last_mux_dts + !(s->oformat->flags & > AVFMT_TS_NONSTRICT); > if (pkt->dts < max) { Your mail client mangled the patch.
> Shouldn't google not produce invalid files? Also, can you link one of > these videos to test this issue? While I agree that Google should fix the issue, I think it would be beneficial for ffmpeg to correct these classes of errors, in-line with what ffmpeg already does for every other format other than VP9. The correction code currently emits a warning to notify the user of the invalid file. Here are the steps to reproduction: ffmpeg -y -loglevel 'repeat+info' -i 'file:LIGHTSKINJOHN - only-MakTbhIZ5zo.f302.webm' -i 'file:LIGHTSKINJOHN - only-MakTbhIZ5zo.f251.webm' -c copy -map '0:v:0' -map '1:a:0' 'file:LIGHTSKINJOHN - only-MakTbhIZ5zo.temp.webm' To get the source video files, the easiest way is to run the following ffmpeg step: youtube-dl -v -f '(bestvideo[vcodec=vp9])+(bestaudio[acodec=opus])' https://youtu.be/MakTbhIZ5zo The error is: [webm @ 0x55978716c740] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 5355 >= 5339 WIth the proposed patch, this gets corrected and a warning is emitted: [webm @ 0x563ed2eb5540] Non-monotonous DTS in output stream 0:0; previous: 5355, current: 5339; changing to 5355. This may result in incorrect timestamps in the output file. > Your mail client mangled the patch. My apologies. Hope the below works. I am successfully able to git apply this, but in case it's still corrupt, please try https://pastebin.com/raw/GWkrCu5w From 0eb57f3746008dc04d86690d97caa1b579d3e215 Mon Sep 17 00:00:00 2001 From: Danny Wu <admin@glados.cc> Date: Wed, 12 May 2021 08:51:13 -0400 Subject: [PATCH] fftools/ffmpeg: Restore DTS correction for VP9 copies Fixes ticket 9086. Since early 2021, some of YouTube's VP9 encodes have non-monotonous DTS. This makes ffmpeg fatally fail when trying to copy or encode the V9 video. ffmpeg already includes functionality to correct this, however it was disabled without explanation for VP9 stream copies in 2e6636aa87303d37b112e79f093ca39500f92364 This patch restores the DTS correction logic, and allows ffmpeg to correctly encode (invalid) videos produced by youtube.com. I have verified that frames are NOT being cut (so it does not re-introduce 4313). --- fftools/ffmpeg.c | 1 - 1 file changed, 1 deletion(-) diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c index 3ad11452da..67deb7762f 100644 --- a/fftools/ffmpeg.c +++ b/fftools/ffmpeg.c @@ -823,7 +823,6 @@ static void write_packet(OutputFile *of, AVPacket *pkt, OutputStream *ost, int u } if ((st->codecpar->codec_type == AVMEDIA_TYPE_AUDIO || st->codecpar->codec_type == AVMEDIA_TYPE_VIDEO || st->codecpar->codec_type == AVMEDIA_TYPE_SUBTITLE) && pkt->dts != AV_NOPTS_VALUE && - !(st->codecpar->codec_id == AV_CODEC_ID_VP9 && ost->stream_copy) && ost->last_mux_dts != AV_NOPTS_VALUE) { int64_t max = ost->last_mux_dts + !(s->oformat->flags & AVFMT_TS_NONSTRICT); if (pkt->dts < max) {
Hi, On Wed, May 12, 2021 at 8:33 PM Danny Wu <admin@glados.cc> wrote: > > > Shouldn't google not produce invalid files? Also, can you link one of > > these videos to test this issue? > I filed a bug for this (b/188197059).
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c index 3ad11452da..67deb7762f 100644 --- a/fftools/ffmpeg.c +++ b/fftools/ffmpeg.c @@ -823,7 +823,6 @@ static void write_packet(OutputFile *of, AVPacket *pkt, OutputStream *ost, int u } if ((st->codecpar->codec_type == AVMEDIA_TYPE_AUDIO || st->codecpar->codec_type == AVMEDIA_TYPE_VIDEO || st->codecpar->codec_type == AVMEDIA_TYPE_SUBTITLE) && pkt->dts != AV_NOPTS_VALUE && - !(st->codecpar->codec_id == AV_CODEC_ID_VP9 && ost->stream_copy) &&
Fixes ticket 9086. Since early 2021, some of YouTube's VP9 encodes have non-monotonous DTS. This makes ffmpeg fatally fail when trying to copy or encode the V9 video. ffmpeg already includes functionality to correct this, however it was disabled without explanation for VP9 stream copies in 2e6636aa87303d37b112e79f093ca39500f92364 This patch restores the DTS correction logic, and allows ffmpeg to correctly encode (invalid) videos produced by youtube.com. I have verified that frames are NOT being cut (so it does not re-introduce 4313). --- fftools/ffmpeg.c | 1 - 1 file changed, 1 deletion(-) ost->last_mux_dts != AV_NOPTS_VALUE) { int64_t max = ost->last_mux_dts + !(s->oformat->flags & AVFMT_TS_NONSTRICT); if (pkt->dts < max) {