[FFmpeg-user] Issue affecting ffmpeg and youtube-dl
Paul B Mahol
onemda at gmail.com
Wed Apr 14 20:08:32 EEST 2021
You can not reset all dts to 0, that does not make any sense.
On Wed, Apr 14, 2021 at 11:30 AM JD <mechalincoln at gmail.com> wrote:
> On Tue, Apr 13, 2021 at 11:47 AM Paul B Mahol <onemda at gmail.com> wrote:
>
> > Please try setts bitstream filter.
> >
> > It is specifically designed for such videos.
> >
> > Actually I tested setts bitstream filter with broken youtube files.
> >
>
> I received some followup from the youtube-dl github:
>
> @mechalincoln: Could you revisit the ffmpeg-user mailing list and kindly
> ask for more clarification towards "fine-tuning" the bsf:v setts
> syntax/arguments?
>
>
> For context, this was the user's reasoning:
>
> The first thing is, that the "setts bitstream filter" is a very recent
> addition to FFmpeg code; I first conducted my experiments with a ffmpeg
> build version n4.3.2, and that filter was missing there! But, it is present
> in latest stable n4.4 release:
>
> ffmpeg -hide_banner -bsfs =>
>
> Bitstream filters:
> aac_adtstoasc
> av1_frame_merge
> av1_frame_split
> av1_metadata
> chomp
> dump_extra
> dca_core
> eac3_core
> extract_extradata
> filter_units
> h264_metadata
> h264_mp4toannexb
> h264_redundant_pps
> hapqa_extract
> hevc_metadata
> hevc_mp4toannexb
> imxdump
> mjpeg2jpeg
> mjpegadump
> mp3decomp
> mpeg2_metadata
> mpeg4_unpack_bframes
> mov2textsub
> noise
> null
> opus_metadata
> pcm_rechunk
> prores_metadata
> remove_extra
> setts
> text2movsub
> trace_headers
> truehd_core
> vp9_metadata
> vp9_raw_reorder
> vp9_superframe
> vp9_superframe_split
> Documentation for that new bsf is provided in
>
> https://ffmpeg.org/ffmpeg-bitstream-filters.html#setts
>
> The syntax for bsfs is documented in
>
> https://ffmpeg.org/ffmpeg-bitstream-filters.html#Description
>
> In previous logs of this thread, muxing fails because of discrepancies in
> the DTS of the input video file (formats -f=302|303) ; I first fetched the
> two elementary streams by issuing:
>
> youtube-dl --console-title -c --no-part --fixup never -f 302 "W9mNLFseTT4"
> -o VP9_674p60.webm
>
> youtube-dl --console-title -c --no-part --fixup never -f 251 "W9mNLFseTT4"
> -o opus96k.webm
>
> ... and after some brief experimentation, I achieved successful muxing to a
> WEBM container, with FFmpeg-n4.4, by issuing:
>
> ffmpeg -i "VP9_674p60.webm" -i "opus96k.webm" -c copy -bsf:v setts=dts=0
> "VP9+opus.webm" =>
>
> ffmpeg version n4.4-ffmpeg-windows-build-helpers Copyright (c) 2000-2021
> the FFm
> peg developers
> built with gcc 10.2.0 (GCC)
> (configuration redacted, for brevity)
> libavutil 56. 70.100 / 56. 70.100
> libavcodec 58.134.100 / 58.134.100
> libavformat 58. 76.100 / 58. 76.100
> libavdevice 58. 13.100 / 58. 13.100
> libavfilter 7.110.100 / 7.110.100
> libavresample 4. 0. 0 / 4. 0. 0
> libswscale 5. 9.100 / 5. 9.100
> libswresample 3. 9.100 / 3. 9.100
> libpostproc 55. 9.100 / 55. 9.100
> Input #0, matroska,webm, from 'VP9_674p60.webm':
> Metadata:
> encoder : google/video-file
> http://youtube.com/streaming/otf/durations/112015: Segment-Count: 54
> : Segment-Durations-Ms:
> 5339,5338,5339(r=1),5338,5339(r=1),5
>
> 338,5339(r=1),5338,5339(r=1),5338,5339(r=1),5338,5339(r=1),5338,5339(r=1),5338,5
>
> 339(r=1),5338,5339(r=1),5338,5339(r=1),5338,5339(r=1),5338,5339(r=1),5338,5339(r
> =1),5338,5339(r=1),5338,5339(r=1),533
> :
> :
> Duration: N/A, start: 0.000000, bitrate: N/A
> Stream #0:0(eng): Video: vp9 (Profile 0), yuv420p(tv,
> bt709/unknown/unknown),
> 1280x674, SAR 1:1 DAR 640:337, 59.94 fps, 59.94 tbr, 1k tbn, 1k tbc
> (default)
> Input #1, matroska,webm, from 'opus96k.webm':
> Metadata:
> encoder : google/video-file
> Duration: 00:04:46.56, start: -0.007000, bitrate: 92 kb/s
> Stream #1:0(eng): Audio: opus, 48000 Hz, stereo, fltp (default)
> Output #0, webm, to 'VP9+opus.webm':
> Metadata:
> http://youtube.com/streaming/otf/durations/112015: Segment-Count: 54
> : Segment-Durations-Ms:
> 5339,5338,5339(r=1),5338,5339(r=1),5
>
> 338,5339(r=1),5338,5339(r=1),5338,5339(r=1),5338,5339(r=1),5338,5339(r=1),5338,5
>
> 339(r=1),5338,5339(r=1),5338,5339(r=1),5338,5339(r=1),5338,5339(r=1),5338,5339(r
> =1),5338,5339(r=1),5338,5339(r=1),533
> :
> :
> encoder : Lavf58.76.100
> Stream #0:0(eng): Video: vp9 (Profile 0), yuv420p(tv,
> bt709/unknown/unknown),
> 1280x674 [SAR 1:1 DAR 640:337], q=2-31, 59.94 fps, 59.94 tbr, 1k tbn, 1k
> tbc (de
> fault)
> Stream #0:1(eng): Audio: opus, 48000 Hz, stereo, fltp (default)
> Stream mapping:
> Stream #0:0 -> #0:0 (copy)
> Stream #1:0 -> #0:1 (copy)
> Press [q] to stop, [?] for help
> frame= 1 fps=0.0 q=-1.0 size= 1kB time=00:00:00.00
> bitrate=8032.0kbits/
> frame=17177 fps=0.0 q=-1.0 size= 6400kB time=00:03:01.30 bitrate=
> 289.2kbits/
> [webm @ 08905680] Starting new cluster due to timestamp
> frame=17177 fps=0.0 q=-1.0 Lsize= 9734kB time=00:04:46.54 bitrate=
> 278.3kbits
> /s speed= 472x
> video:6403kB audio:3122kB subtitle:0kB other streams:0kB global headers:0kB
> muxi
> ng overhead: 2.192095%
> MediaInfo Log of produced file:
> VP9+opus.webm.txt
>
> However, the only software player on my system that produces a trouble-free
> playback of the resultant webm file is the mpv-based SMPlayer
>
> ...
>
> @mechalincoln: Could you revisit the ffmpeg-user mailing list and kindly
> ask for more clarification towards "fine-tuning" the bsf:v setts
> syntax/arguments?
> I have little experience in filter syntax, less so with this very new one,
> for which no working examples can be currently found on-line... 😢
>
> Of course, migrating every yt-dl user to FFmpeg 4.4+ isn't very practical
> currently, plus the fact the issue at hand manifests itself at random
> youtube video IDs discourages, probably, the devs from writing code
> exclusive to ffmpeg 4.4+... Additionally, a lot more testing is needed on
> how the muxed file (with using the setts bsf) behaves on popular media
> players... ❓
>
> Addition: The webm file produced by OLD ffmpeg (N-78989-gcaeed04 in my
> tests) plays absolutely fine in ALL players available in my machine
> (MPC-HC, MPC-BE, PotPlayer, VLC 3 and SMPlayer), thus I still consider
> using an ol'n'good ffmpeg build to be the definitive cure for this... 😉
>
>
> The github issue is here:
> https://github.com/ytdl-org/youtube-dl/issues/28042
>
> Another user had an archive of ffmpeg-win32 builds and did tests:
>
> I have unearthed my archive of (many) ffmpeg-win32 builds and conducted
> some tests:
> the last build (in my archive) with which muxing succeeds is
> ffmpeg-n3.1-dev-526-N-78989-git-20160310-gcaeed04
> while the first with which it fails is
> ffmpeg-n3.1-dev-1443-N-79906-git-20160510-gc8c14d0
>
> This is not much, but it narrows down the culprit change to within 917
> commits, during a time-frame of two months (Mar 10th to May 10th 2016).
>
> In the working builds, as is also obvious in the log inside your ffmpeg
> ticket, the matroska muxer identifies the discrepancy in DTS (decoding time
> stamp), but proceeds to perform an auto-correction (while issuing a warning
> doing so):
>
> 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.
> (in yellow letters), which lets the muxing complete successfully. 👍
>
> In the non-working builds, the matroska muxer identifies the DTS
> discrepancy, does not auto-correct DTS and, ultimately, fails
>
> Application provided invalid, non monotonically increasing dts to muxer in
> stream 0: 5355 >= 5339
> av_interleaved_write_frame(): Invalid argument
> (in red letters), having only produced a partial mux, sized ca. 471 KiB
> (length ca. 5s). 😞
>
>
> I hope this information is helpful.
>
> I appreciate the help on this issue.
>
> Thank you.
> _______________________________________________
> ffmpeg-user mailing list
> ffmpeg-user at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> ffmpeg-user-request at ffmpeg.org with subject "unsubscribe".
More information about the ffmpeg-user
mailing list