> 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
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) {
--
2.17.1
___
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".
