[FFmpeg-user] Issue affecting ffmpeg and youtube-dl

JD mechalincoln at gmail.com
Wed Apr 14 12:29:40 EEST 2021 

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.

More information about the ffmpeg-user mailing list