You can not reset all dts to 0, that does not make any sense. On Wed, Apr 14, 2021 at 11:30 AM JD <mechalinc...@gmail.com> wrote:
> 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". _______________________________________________ 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".
