On Tue, Apr 13, 2021 at 11:47 AM Paul B Mahol <one...@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@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
