Youtube-dl can"t merge VP9+Opus youtube videos #28042
Comments
dkoao
changed the title
|
Hi, I can confirm that there is no problem with this specific video, as I ran the command with no issues using Python 2.7.12, ffmpeg 2.8.17, and ffprobe 2.8.17. I"ll try to reproduce the issue on a system with closer specifications to yours. Quick update: I was able to reproduce the error on a different system with both Python 2.7.16 and 3.8.7, and ffmpeg, ffprobe 4.1.6-1. I"m going to try again with the same version of ffmpeg as I used before to see whether the ffmpeg version is the cause of this. |
|
I was unable to reproduce the issue on a different system with ffmpeg 2.8.17, leading me to believe the issue lies somewhere with the version differences. |
|
So this is is probably an issue in ffmpeg >= 3? |
|
Potentially. I sort of put this off hoping others with different versions of ffmpeg could test this so we could track down which version was the earliest where this doesn"t work. |
|
Experienced this conversion failure error on youtube-dl 2021.03.03 (latest) with ffmpeg 2020-08-31 (last build from Zeranoe) and Python 3.4.4 on W10. After downloading a VP9 video stream ( |
|
I am experiencing this on and off. It"s at random with itags for video 302 and 303 plus audio 251. This is the latest version: |
|
From some testing, I can confirm this is a ffmpeg issue. |
|
What would be the best way to contact the ffmpeg team about it/describe the issue? |
|
ffmpeg provided by Ubuntu"s default repository have same problem. btw this should be reported to ffmpeg devs tho Edit: transcoding have worked, while copy doesn"t |
|
I joined ffmpeg"s mailing list, but they don"t want to investigate unless the ffmpeg command used is provided. This is frustrating. If any of the youtube-dl devs reads this, please contact ffmpeg since it looks like they"re not going to fix this on their end. Does anyone have the ffmpeg command that youtube-dl would use to merge 302 or 303 + 251? |
|
@mechalincoln |
|
Thank you for the prompt response @nao20010128nao . I will relay this to them. This was the output: |
|
One of the developers replied with this: |
|
@mechalincoln Can you give a link to the ffmpeg issue you opened? |
@pukkandan I started a thread in their mailing list, since their bug report requirements are stringent and a bit beyond my skill level: https://ffmpeg.org/bugreports.html I figured it was more expedient to report the issue and get that done than set up youtube-dl on a linux box, since I usually use it on Windows. Here is an archive of their mailing list for April of this year: http://ffmpeg.org/pipermail/ffmpeg-user/2021-April/date.html The subject line I used is "[FFmpeg-user] Issue affecting ffmpeg and youtube-dl". This was the message where the developer replied with the above: http://ffmpeg.org/pipermail/ffmpeg-user/2021-April/052736.html I wish they used something other than an antiquated mailing list, but this is OG open source so whatever works for them. |
|
Another developer added this: |
|
I have opened an issue: https://trac.ffmpeg.org/ticket/9187#ticket
Doesn"t work atleast without any parameters and I have no idea what params to use |
|
Thank you. I appreciate it, since I"m not getting far with their mailing list. |
|
I have unearthed my archive of (many) ffmpeg-win32 builds and conducted some tests: 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): (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 (in red letters), having only produced a partial mux, sized ca. 471 KiB (length ca. 5s). 😞 |
|
The FFmpeg devs closed the issue [ticket 9187] reported by @pukkandan, labeling it as a duplicate of Cannot copy vp9 stream from webm to mp4 [ticket 9086] OTOH, in original ticket 9086 they"re hinting it"s actually A case of the "Which came first: the chicken or the egg?" riddle, if you ask me... 😄 |
@Vangelis66 I recommend posting your findings on either of the issues |
|
OK, I think I may have made some progress, the findings of which, sadly, won"t apply to the vast majority of Now, to the point: @mechalincoln wrote:
@pukkandan wrote:
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:
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
... and after some brief experimentation, I achieved successful muxing to a WEBM container, with FFmpeg-n4.4, by issuing:
MediaInfo Log of produced file: However, the only software player on my system that produces a trouble-free playback of the resultant webm file is the mpv-based SMPlayer:
YMMV, of course, especially on systems (Win10) with VP9 hardware decoding... @pukkandan : I don"t think the FFmpeg people would engage further in this... Of course, migrating every 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... 😉 |
|
@Vangelis66 I have relayed that to them, in addition to the results of your testing to track down the error in past builds. I don"t know that it"ll matter due to the stipulation of using the current git head (which I surmise is the most recent version) but I figured it wouldn"t hurt to try. Thanks again. |
|
Update from one of the devs:
|
|
I"m not seeing much movement from the ffmpeg side. Is there anything anyone else wants to relay to them? |
|
Any news on this? I just want my merge to webms to work |
|
On Wed, Apr 28, 2021 at 4:43 PM draggingsnow ***@***.***> wrote:
Any news on this? I just want my merge to webms to work
I wish there was. I don"t believe there are any changes here, nor have I
seen any changes on the youtube-dl side.
I"m using H264 more as a workaround, to get the videos I"d want in good
quality, but I"d prefer being able to use VP9 with HFR if I could.
|
Just use |
|
On Thu, Apr 29, 2021 at 5:21 AM pukkandan ***@***.***> wrote:
I just want my merge to webms to work
but I"d prefer being able to use VP9 with HFR if I could.
Just use ffmpeg 3.0.1. This version does not have the issue. Unless you
are downloading AV1 videos, it shouldn"t cause any other issues either
Good to know. That said, I hope eventually this issue is fixed in the
ffmpeg code.
Thank you for the tip.
|
|
@danny-wu wrote:
That is actually
Many thanks, indeed! 👍 This is the actual mailing list thread: http://ffmpeg.org/pipermail/ffmpeg-devel/2021-May/280189.html The one dev that replied as of now appears to be yet unconvinced... 😞 Knowing how evil Google are 😠 👎 , I wouldn"t rule out them "fixing" their HFR encodes on purpose, just to spoil it for "downloaders"... Knowing the ffmpeg devs, it"ll probably take eons to review/approve/merge submitted patch; @danny-wu, are you willing to post your patch here, too, and, optimally, compile win32 FFmpeg builds for us Windows people (preferably ones that would launch on Vista, too, as that is the minimum ffmpeg supports currently) ? I haven"t been idle myself on this, despite not posting here... 😜
supposedly will make FFmpeg disregard the However, that switch has to be specified before the "invalid" VP9 file, e.g. works but fails 😭 (ffmpeg44 a renamed ffmpeg.exe v4.4) ... Where I am currently stuck is that when I supply the switch to |
|
Hi @Vangelis66, I will continue working on the patch with the goals of incorporating it into ffmpeg.
Unfortunately I do not develop on Windows, and have no clue how to compile for Windows. Sorry! But someone else is of course welcome to compile (although I cannot endorse the security of any binaries, and do not encourage running untrusted binaries).
I think this is a valid case that calls for introducing a |
If #27723 is approved, it can be easily expanded to allow this without the need for another switch. See yt-dlp/yt-dlp@5b1ecbb for one possible implementation |
|
@pukkandan: Many thanks 👍
Using ffmpeg n4.4 release, the resultant webm file plays with no issues at all on MPC-BE, MPC-HC, PotPlayer and (mpv-based) SMPlayer, but reproduction has serious video issues (audio is fine) in both VLC 2/VLC 3 (can"t test VLC 4 here...). So, if your default video player is NOT VLC, give the above "workaround" a try (unfortunate as it might be, currently it requires using a Addendum: Using |
@Vangelis66 May I suggest you have a look at https://forum.doom9.org/showthread.php?t=181802 ? |
|
A Googler has filed an issue about their malformed VP9 encoding in their internal bug tracker. |
Looking at ffmpeg.c, it seems to me that int64_t max = ost->last_mux_dts + !(s->oformat->flags & AVFMT_TS_NONSTRICT);
...
if (pkt->dts < max) {
if (pkt->pts >= pkt->dts)
pkt->pts = FFMAX(pkt->pts, max);
pkt->dts = max;
}should be equivalent to ( -bsf:v "setts=pts=if((DTS < PREV_OUTDTS) * (PTS >= DTS)\, max(PTS\, PREV_OUTDTS)\, PTS):dts=max(DTS\, PREV_OUTDTS)"at least the docs promise that “The expressions are evaluated through the eval API”. Unfortunately I wasn"t able to run even a simpler version of it: However, nonsensical stuff like Does anybody know how to properly escape commas in bitstream filters? Did anyone have any success running |
|
If someone is tired waiting for FFmpeg devs to fix this issue, FFmpeg builds with a patch by @danny-wu can be found here: https://github.com/nihil-admirari/FFmpeg-With-VP9-Timestamp-Fix/releases. Builds are based on https://github.com/BtbN/FFmpeg-Builds. When it comes to |
|
Your information about setts filter is incorrect and misleading. Also you provided no proofs for your claims. -bsf:v setts=ts="N*(1001/60000)/TB" I"m sure if you know how to properly overwrite non-monotonic PTS/DTS in stream that if you provide working formula I can write expression for you to be used in setts filter. |
If you were to read what is written above carefully, you would"ve found the following:
I wasn"t claiming that any TS filter expression results in an error, I was claiming that expressions containing commas do not parse. The error message was also presented, I don"t quite understand how that isn"t a proof: That said, I"ve retested everything again with latest FFmpeg from BtbN. Looks like a problem with commas has been fixed since June (now it"s a problem with parentheses, see below). Video downloaded with yt-dlp --keep-video --ffmpeg-location /opt/ffmpeg-N-103585-gbb9141cc13-linux64-gpl/bin/ -f bv*[ext=webm]+ba[ext=webm]" -S +size W9mNLFseTT4does merge with an additional Full FFmpeg command line: /opt/ffmpeg-N-103585-gbb9141cc13-linux64-gpl/bin/ffmpeg -y -i "file:Blender Help - Dust Impact - Animated puff or cloud of dust from an object impact. [W9mNLFseTT4].f303.webm" -i "file:Blender Help - Dust Impact - Animated puff or cloud of dust from an object impact. [W9mNLFseTT4].f251.webm" -c copy -map 0:v:0 -map 1:a:0 -bsf:v "setts=dts=max(DTS\, PREV_OUTDTS)" "file:Blender Help - Dust Impact - Animated puff or cloud of dust from an object impact. [W9mNLFseTT4].temp.webm"However, an attempt to set PTS in addition to DTS with
Quoting myself:
int64_t max = ost->last_mux_dts + !(s->oformat->flags & AVFMT_TS_NONSTRICT);
...
if (pkt->dts < max) {
if (pkt->pts >= pkt->dts)
pkt->pts = FFMAX(pkt->pts, max);
pkt->dts = max;
}
Looks like WebM & Matroska are both non-strict: https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/webm_chunk.c#L298, https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/matroskaenc.c#L2842 (correct me if I"m wrong, or if VP9 could be merged into a container that is strict).
The task is to convert the C code above into FFmpeg eval expression. My attempt: partially worked. I"d be happy to hear how to write a conditional that doesn"t result in |
|
Handling of commas was fixed in FFmpeg/FFmpeg@301d275, almost a month after my comment. |
|
FFmpeg/FFmpeg@301d275 has not been backported to 4.4 release branch. Problem with commas is still reproducible there. Turns out that With PTS part present, |
|
Continuing the investigation. One merge was done with vanilla FFmpeg using /opt/ffmpeg-N-103588-g0b4d009587-linux64-gpl/bin/ffmpeg -i "file:Blender Help - Dust Impact - Animated puff or cloud of dust from an object impact. [W9mNLFseTT4].f303.webm" -i "file:Blender Help - Dust Impact - Animated puff or cloud of dust from an object impact. [W9mNLFseTT4].f251.webm" -c copy -map 0:v:0 -map 1:a:0 -bsf:v "setts=pts=if(lt(DTS\, PREV_OUTDTS) * gte(PTS\, DTS)\, max(PTS\, PREV_OUTDTS)\, PTS):dts=max(DTS\, PREV_OUTDTS)" "file:setts.webm"A second merge was done with patched FFmpeg without using any filters: /opt/ffmpeg-N-103588-g0b4d009587-linux64-nonfree/bin/ffmpeg -i "file:Blender Help - Dust Impact - Animated puff or cloud of dust from an object impact. [W9mNLFseTT4].f303.webm" -i "file:Blender Help - Dust Impact - Animated puff or cloud of dust from an object impact. [W9mNLFseTT4].f251.webm" -c copy -map 0:v:0 -map 1:a:0 "file:patched.webm"FFprobe was used to show the packet structure: /opt/ffmpeg-N-103588-g0b4d009587-linux64-gpl/bin/ffprobe -show_packets setts.webm > setts.pkts
/opt/ffmpeg-N-103588-g0b4d009587-linux64-gpl/bin/ffprobe -show_packets patched.webm > patched.pktsDiff is empty. (If you know a better way to diff videos, please let me know.) diff setts.pkts patched.pktsLooks like Once |
|
I want to congratulate you, Nil, 👍 for the thorough investigation of this
The non-coder, layman, user of Most fortunately, the "patched" ffmpeg builds you provide act as a stopgap/workaround 👍 ; may I be cheeky and kindly ask you to submit a PR with that same fix (I believe that"s the one) to this repo: https://github.com/rdp/ffmpeg-windows-build-helpers I"m in need of ffmpeg-win32-static builds that will run at least on Windows Vista SP2 32-bit (and higher), currently that script/toolchain/compiler is compatible with above requirements... Many thanks indeed for your investigative work, much appreciated here! 👍 😄 Best regards |
If you have yt-dlp -f "bv*[ext=webm]+ba[ext=webm]" W9mNLFseTT4 --ppa "Merger:-bsf:v "setts=pts=if(lt(DTS\, PREV_OUTDTS) * gte(PTS\, DTS)\, max(PTS\, PREV_OUTDTS)\, PTS):dts=max(DTS\, PREV_OUTDTS)""
I think the patch can simply be applied along with other patches in the build script you"ve referenced: # In function build_ffmpeg
...
cd $output_dir
apply_patch file://$patch_dir/frei0r_load-shared-libraries-dynamically.diff
+ apply_patch "file://$patch_dir/0001-Fixes-ticket-9086.patch"I won"t be submitting a proper pull request: sorry, it"s just too much work. |
|
Just saw this thread.. It"s worth noting ffmpeg has several dts/time related "problems" that they refuse to address and they are not limited to YT. A datastream does not need to be contiguous, Forcing either PTS or DTS to anything without knowing their true state is asking for trouble. Unless YT fixed the videos linked above, I can"t duplicate this or I"d test it myself with the sortdts fflag rather then try resetting it.. |
|
@h1z1 wrote:
The YT video ( FWIW, as a Windows Vista SP2 32-bit user, I have no access to the patched ffmpeg builds mentioned earlier in this thread (those, as well as the ones recently offered by TL;DR: Youtube (read: Google) haven"t fixed their HFR VP9 raw streams... 😞 |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
Still failing with ffmpeg 4.1, 4.3. |
|
Talked to FFmpeg developers on
https://trac.ffmpeg.org/ticket/9086 is now closed. |
Checklist
Verbose log
FFmpeg gives me the following error when I run the command mentioned in the above output manually:
[webm @ 0x7fe94ccf40c0] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 5620 >= 5600 av_interleaved_write_frame(): Invalid argumentI"ve tried to re-download it multiple times and the issue persists. Other videos can be merged fine, so it seems like this is a problem with this particular video.
The text was updated successfully, but these errors were encountered: