SideDownload error: Only VP8 or VP9 or AV1 video and Vorbis or Opus audio and WebVTT subtitles are supported for WebM

[Ede Wolf]

I get the following error message when trying to download a 4k video from Youtube:

SideDownload error:
[webm @ 0000028d6b87d740] Only VP8 or VP9 or AV1 video and Vorbis or Opus audio and WebVTT subtitles are supported for WebM.
[out#0/webm @ 0000028d6a704d40] Could not write header (incorrect codec parameters ?): Invalid argument
[aost#0:1/copy @ 0000028d6b84b7c0] Error initializing output stream:     

I updated to the most recent beta version, including the helper app, but no luck.

Somebody posted a possible solution to this problem on Stackexchange:

FFmpeg Error: Only VP8 or VP9 or AV1 video and Vorbis or Opus audio and WebVTT subtitles are supported for WebM and incorrect codec parameters - Stack Overflow

However I don't know how to apply the suggested solution to DownloadHelper.

Is there something I can do?

[Wild Willy]

One thing you could do is make a conforming problem report. State your operating system.
State the release number of your browser. "Latest" doesn't cut it. State your release
number of VDH. "Latest" doesn't cut it. State your release number of CoApp. "Latest"
doesn't cut it. Quote the URL of the YouTube video that caused this problem. The URL on
YouTube of the page containing the video. You need to provide enough information for
other people to see if they get the same results you do. Also, were you doing a simple
Side Download? Or were you doing a Side Download & Convert? If the latter, don't. Just
do a Side Download. Once you get the video successfully, then launch a Convert as a
separate step later. If a Side Download & Convert fails, you are left with no results.
If the Side Download succeeds but the Convert fails, you still have the downloaded file.
You can try a different Convert without having to download the file again. My advice is
to NEVER use Side Download & Convert. Always use Side Download, then Convert later.

There is a possible solution that comes to mind. Search this forum for a thread whose
title is, "How to download from YouTube." That describes how to use techniques other
than VDH to download from YouTube. I wrote that to carry us through the month or so
earlier this year when YouTube decided to frivolously change their format. Again. It
took a while for the VDH guys to come up with a new way of doing things. In the interim,
that thread described what was the way to get YouTube content. Those techniques still
work, although VDH does it all much more conveniently. But I don't send you there to see
if any of those techniques get your as yet unidentified YouTube video. I am directing
you to a post in that thread dated July 17. Have you done what it describes there? If
not, do it. If you don't remember, do it. It is a harmless step that you can perform at
any time, & for as many times as you wish. It hurts nothing to repeat it. But you need
to have done it at least once on any of the VDH 8.x releases. It might clear this up for
you. Might. Maybe. You won't know until you try.

Still, you should get in the habit of posting proper problem reports. It saves so much
time. So let's have that from you now.

As for the stackoverflow discussion, that doesn't sound applicable to VDH. We don't have
the kind of control over VDH's use of ffmpeg that would allow any of what they describe
there to be applied in our context. That discussion also seems very particularly related
to video livestreaming. Not just capturing a livestream, but creating one & capturing it
on the fly. Even if any of that is applicable to VDH, only Michel & Paul could make any
use of it to adjust the code inside VDH & the CoApp. But I can't say whether anything
there would be applicable to VDH. I'm just another user. I don't have access to the
code, & it's unlikely I'd understand it anyway. Like I say, the user interface to VDH
doesn't allow us to provide any of the ffmpeg parameters they discuss over there. Or any
ffmpeg parameters, for that matter. It's all encapsulated within VDH & we have no access
to that level of tweaking. If you want to experiment with ffmpeg, you can do that
without reference to VDH.

[Ede Wolf]

VDH version is 8.1.0.0a9. CoApp version is 2.0.10.

Operating system is Windows 10. Browser was Firefox 120.0.1.

I used the "Side Download" option. I performed the reset of settings as suggested in the thread you mentioned.

The Youtube URL I can not provide, since it is an unlisted video I have purchased. It might not work for you anyhow for this reason. I'm posting the "debug information" from the context menu of that video below. Codecs are as follows:

Codecs

vp09.00.51.08.01.01.01.01.00 (313) / opus (251)

Another hint: I installed VDH beta for the Microsoft Edge browser and set my licence information. The download started there in 4k, but proceeded very slowly and aborted at some point later.
The partially downloaded video is playable. I tried to download again, after which I was prompted that there was a timeout for 4K download because of a missing "conversion function licence".
I purchased this licence and retried the download, after which the SAME error message appeared as in Firefox (SideDownloadError).

It looks like licensing the conversion functions is responsible for this problem. You might look in that direction...

{
  "ns": "yt",
  "el": "detailpage",
  "cpn": "OKaYjQ7MkPl1weq0",
  "ver": 2,
  "cmt": "6.564",
  "fmt": "313",
  "fs": "0",
  "rt": "10.527",
  "euri": "",
  "lact": 0,
  "cl": "590345707",
  "mos": 0,
  "state": "4",
  "volume": 53,
  "cbr": "Firefox",
  "cbrver": "120.0",
  "c": "WEB",
  "cver": "2.20231214.06.00",
  "cplayer": "UNIPLAYER",
  "cos": "Windows",
  "cosver": "10.0",
  "cplatform": "DESKTOP",
  "hl": "de_DE",
  "cr": "DE",
  "len": "979.781",
  "fexp": "v1,23983296,2730,18618,2602,73492,54572,73455,176963,53633,84737,25688,672,8870,1088,5877,394,133212,26306282,4054,1930,5181,9369,1556,1141,5876,2252,859,406,395,293,9513,2337,2346,1359,2486,3359,2750,1191,817,3942,610,1994,551,1991,2411,2086,946,3673,428",
  "afmt": "251",
  "muted": "0",
  "docid": "qiiWMskSyvI",
  "ei": "7719ZeHQI-bBi9oPoM-q-AE",
  "plid": "AAYMoetx04lPCac7",
  "of": "L_224b5BokWsQ5UWgAws_w",
  "vm": "CAEQABgEOjJBSHFpSlRLdVZoVlFDTVRUeUh1SWRNYnU4anIxXzZINmtpcFJtc1lkeXI1bnB2dEtyZ2JuQVBta0tESWUtS1hqTkpuRUlZRUthR3R4SXFvMjZIVlhtVFBTaGFRa3d2Y1NvcWZhUE1FLVI3cGtBS3hWcThJSkVDSGpZYjJSU2RabldIb0dMRk42R2ViMFVrVUhhQmpRcjdIVVdONDlubG1kNEFoAg",
  "vct": "6.564",
  "vd": "979.781",
  "vpl": "1.000-6.564",
  "vbu": "0.000-26.926",
  "vpa": "1",
  "vsk": "0",
  "ven": "0",
  "vpr": "1",
  "vrs": "4",
  "vns": "2",
  "vec": "null",
  "vemsg": "",
  "vvol": "0.53",
  "vdom": "1",
  "vsrc": "1",
  "vw": "1174",
  "vh": "660",
  "lct": "6.564",
  "lsk": false,
  "lmf": false,
  "lbw": "11885652.644",
  "lhd": "0.018",
  "lst": "0.000",
  "laa": "itag_251_type_3_src_reslicegetRequestInfoForRange_segsrc_reslicegetRequestInfoForRange_seg_2_range_316044-474907_time_20.0-30.0_off_0_len_158864_end_1",
  "lva": "itag_313_type_3_src_reslicegetRequestInfoForRange_segsrc_reslicegetRequestInfoForRange_seg_5_range_37623185-41817488_time_24.7-27.3_off_0_len_4194304",
  "lar": "itag_251_type_3_src_getRequestInfoForRange_segsrc_getRequestInfoForRange_seg_2_range_316044-474907_time_20.0-30.0_off_0_len_158864_end_1",
  "lvr": "itag_313_type_3_src_getRequestInfoForRange_segsrc_getRequestInfoForRange_seg_5_range_37623185-41817488_time_24.7-27.3_off_0_len_4194304",
  "laq": "0",
  "lvq": "0",
  "lab": "0.000-30.001",
  "lvb": "0.000-26.926",
  "ismb": 16630000,
  "leader": 1,
  "relative_loudness": "-16.361",
  "optimal_format": "2160p",
  "user_qual": 2160,
  "release_version": "youtube.player.web_20231212_01_RC00",
  "debug_videoId": "qiiWMskSyvI",
  "0sz": "false",
  "op": "",
  "yof": "false",
  "dis": "",
  "gpu": "ANGLE_(NVIDIA,_NVIDIA_GeForce_GTX_980_Direct3D11_vs_5_0_ps_5_0)",
  "debug_playbackQuality": "hd2160",
  "debug_date": "Sat Dec 16 2023 16:10:49 GMT+0100 (Mitteleuropäische Normalzeit)",
  "timestamp": 1702739449982  

[Ede Wolf]

This video is public from the same channel and gives me the same problem:

ASMR - 🎮 perfektes background ASMR für GAMING! 🖱️ 🖥️ German / Deutsch - YouTube

[Wild Willy]

Well, this is very puzzling. I'm running Windows 11 but otherwise, I am also running
Firefox 120.0.1, VDH 8.1.0.0a9 beta, & CoApp 2.0.10. The 4K variant downloaded for me
without incident . . . other than the rather surprising 22 MILLION bytes per second I was
getting with this download. That has to be the fastest I've ever seen from YouTube. But
the download completed in about 1 minute without error & the resulting file played fine.
I didn't sit & watch it all the way through, just sampled it at intervals. And you need
to be in a quiet room or wear headphones. It's ASMR. The audio on this one is nearly
inaudible, which is as intended. But I was hearing it.

I am baffled. The only thing I can think might make any difference, & I'm not sure it
should but it's all I can think of, is that I changed the target file name before I
launched the download. The default that VDH picked up off the web page included some
emojis or whatever those were. Graphics of some kind. I removed those & renamed the
file simply "German 4K.mp4." But like I say, that shouldn't make any difference.

Oh. One other thing. I was not logged in when I did my download. There have been
numerous reports that being logged in on YouTube was a problem. I have only the generic
free Google ID & it has been my experience that VDH has usually worked on YouTube when I
am logged on with that. That has been on just run-of-the-mill content. Age restricted
content that you can look at with the free Google ID has not worked in VDH. When it
comes to a paid Google ID of some sort, that has also caused problems. When you start
talking about purchased content, you do need to log in to look at that, although you can
purchase content using a free ID. I did that once & discovered that VDH refused to
download the item correctly. It downloaded the item but the results looked like the
content was protected by DRM. I ended up resorting to a screen recorder to make a copy
of it. I didn't think of checking whether DRM was actually in effect on the item. I
would not be surprised if any paid content were protected by DRM, not only on YouTube but
on any site. Paid content is not necessarily always protected by DRM. But it's a common
thing sites do. Of course, downloading DRM-protected content is not possible. It's
actually illegal. So VDH is never going to download it, at least, not properly. Nor is
ffmpeg nor any other legal tool. However, I was not logged in for this ASMR video & it
downloaded fine for me. That's enough to eliminate DRM from this issue.

I don't think the VDH license is a factor here. Maybe it is but I'd be surprised if it
were. I have a license & it didn't interfere. When it comes to Edge, I suppose I do
have it here. It comes with W11. But I do everything possible to avoid using it. I
certainly don't have a VDH license for Edge & I'm not about to get one. Chrome is not an
issue because Chrome is not permitted to download from YouTube. I don't have Chrome
anyway.

I think we're going to need either Michel or Paul to peek in here. But what if they have
no trouble downloading this one, either? I don't know where that leaves us.

[jcv...@gmail.com]

Hi Ede,

Sorry for this.

With your details I can reproduce the issue so I will forward to the dev team.

Thanks for the feedback.

jerome

[Paul]

Hi.

Can you confirm that the first choice in the hit list are MP4 files? And that these MP4 work as expected?

We have identified a few issues with the way youtube encode webm/vpx videos (incompatibility with ffmpeg).

It's not just that specific issue you're mentioning here, there are some other videos with webm-only problems.

So for now we decided to promote MP4 first.

WebM usually comes with higher video qualities, so it's important that we fix those issues.

We are aware of these problems. And that's something we are prioritizing.

I hope to solve that soon!

[Ede Wolf]

I was able to download the video in question in other resolutions as MP4 successfully.

[Wild Willy]

Attached is the complete VDH menu I get on that page. It's a bit long so it takes 3
screenshots to show the full scroll of the menu.

Just now I Side Downloaded the 3840x2160 webm shown in the middle of that first image. I
got the same failure Ede did. The other day when I did this, there was a 3840x2160 mp4
on the menu in that position & that downloaded fine. That mp4 variant is not showing up
today. So weird.

I also did the player json trick. I found 18 objects: 14 video objects & 4 audio
objects. At resolution 3840x2160, there was only a webm. There was also a 2560x1440
webm. There were no mp4s at those 2 resolutions. For the rest of the resolutions,
beginning with 1920x1080 & getting progressively lower, there were 6 pairs of mp4/webm at
the same resolution. There was 1 audio/mp4 of medium quality, 2 audio/webms of low
quality, 1 audio/webm of medium quality. Since you don't offer a choice, I am assuming
that you always pick the medium quality audio of either mp4 or webm to pair with
whichever resolution of object the user selects. I have not seen an audio object of
better than medium quality. I would expect higher quality audio objects occur somewhere
on YouTube. I just haven't happened to find any. This pattern of 4 audio objects is
what I have always encountered.

Using the information in the Network Monitor, I isolated the 3840x2160 webm video track
in its own browser tab. That took several minutes, during which time Resource Monitor
showed Firefox downloading a steady 46,000 bytes per second. Putrid. Eventually, the
Firefox media player appeared with the first frame of the video. I used Save Video As to
download the video track. Even after I closed the browser tab for the video, the
download still was progressing at only 46,000 bytes per second. Firefox was telling me
it was going to take 10 hours to complete. For an 18-minute video? That's disgusting.

Then I isolated the medium quality audio webm track to its own browser tab. This loaded
in just a couple of seconds. I downloaded that via Save Audio As, then closed the
browser tab. The Firefox download manager showed the audio track downloading at a good
speed. But launching the download of the audio track goosed the download of the video
track. I swapped over to Resource Monitor & saw the download of the video track was
speeding up gradually from 1 million byes per second to 10 million to 20 million to 30
million . . . It was approaching 40 million when it completed. I can only imagine how
fast it would have gotten if it had been any longer & the download would have continued
longer.

In any case, I merged the 2 tracks together, See the attached text file. I did that
because my experience has been that VLC does not like to play webm tracks synchronously.
VLC won't let you skip around in webm video when the tracks are separate. After merging,
the webm played fine & I was able to skip through it, sampling it here & there. It was
all there, video & audio, right to the end.

I say that my success at downloading the 3840x2160 video this way is an encouraging sign
that you will eventually succeed in making this work in VDH.

[Wild Willy]

Paul, your comment above about YouTube mkv incompatibility with ffmpeg intrigued me. I
went back to the German ASMR video mentioned upthread & downloaded the 4K video track &
the "medium quality" (YouTube's terminology) audio track using ffmpeg. I've attached my
ffmpeg logs for those operations to this post. For the audio, I got this odd error that
you can see in the log. Since the download was fairly short, I tried a second time.
That second try is what is in the attached log, but the first try gave identical results.
I don't know if this is what you meant when you said there are incompatibilities with
ffmpeg. It would take testing with plenty of other examples to reach a conclusion. But
the error I got was about 3 seconds from the end. I did successfully download almost the
whole audio track with ffmpeg. It seems almost compatible. Maybe there is just an error
in this content. Firefox Save Audio As had no trouble with it when I did that earlier in
this discussion. So I don't know exactly what to make of this error.

The video track downloaded completely, no errors, & it played fine. You will note,
however, the utterly putrid download speeds I was getting for these downloads. It is my
understanding that there is this magic formula you apply to the URLs for the tracks. I
am under the impression that this involves applying certain javascripts to parts of the
URL, then adding certain & qualifiers to the URL. When you do that, you get
multi-million bytes per second download speeds from YouTube. Since I don't know the
magic formula, my download of the video track lasted 6 hours. The audio track seemed to
get the speed we used to get with VDH in previous releases, that is, half the duration of
the clip. But my video download was in the 0.04-0.05 speed range. I thought the download
was going to last 10 hours, so 6 hours was better than expected. But still putrid. It's
a good thing computers (not to mention humans) can multitask. I was determined to see
this through so I just let it run while I went about doing other things.

Since I only just a couple of weeks ago got on Windows 11, I thought I would try playing
these 2 mkv tracks synchronously in VLC. I wanted to verify that the problems I had seen
on Windows 7 playing synchronous mkv content in VLC were still in W11. They are. When
you try to play separate mkv tracks synchronously in VLC, you can't skip. Skipping works
for a couple of skips, then the video resets to time index 0. This is the problem I saw
on W7 & it is still the problem I see on W11. This is obviously a bug in VLC. But it's
easily circumvented. I simply merged the 2 tracks into a single file. That lets you
skip around in the file just fine. That is the file I played to test my download
results. It worked fine, except for the last 3 seconds being silent.

There are a couple of advantages to downloading mkv content, no matter whether you do it
with ffmpeg or VDH. During download of mp4 content, you usually (not always, but almost
always) cannot play the content while the download is still in progress. This is not
true of mkv downloads. You can chase-play an mkv while it is still being downloaded.
VLC can read from the front of the file while your download is writing to the back of the
file. Of course, you can play only the portion of the clip that has been downloaded, but
still, this is an improvement over mp4. Another improvement over mp4 is what happens
when a download fails. With mp4, usually an interrupted download leaves you with a file
that cannot be played & cannot be repaired. The all-powerful moov atom is missing. I'm
talking about a download that ends with an error, not a download that you terminate early
yourself. Such mp4 content can be stopped via the VDH stop or abort button in the blue
dot status menu & you'll have a playable file. This was something you corrected in one
of the recent 8.x betas. Ditto for entering q in an ffmpeg command window. But if there
is for example a line error with an mp4, you usually end up with garbage no matter what
tool you're using. This is not true with mkv. There is no such thing as a moov atom in
mkv. I think the ability to chase play mkv content & the ability to play unexpectedly
interrupted mkv content are probably both the result of this same absence of a moov atom.
The file structure is just different. I imagine it was a design criterion for whoever
came up with the mkv file architecture. The goal was to eliminate the restrictions
imposed by the moov atom in mp4. Now, I might sound like some kind of expert. I'm not.
I don't know what the actual file structures are. I could not construct either mkv or
mp4 content from scratch. I need recording apps to do that, same as any other ordinary
user. I'm just describing what I have observed as a regular old user. Given these
advantages of mkv over mp4, I would probably always prefer to download mkv content,
except for the VLC thing. Maybe I should pursue that as a bug with the Videolan folks.
Maybe. If I get up the energy to sign up to their support forum & file a bug report. I
wouldn't hold my breath waiting for that.

So the point of my exercise was to question exactly what you mean by ffmpeg
incompatibility. It looks compatible to me, even if the downloads run at a snail's pace.
Can you give me some examples of YouTube content that refuses to download with ffmpeg?

And while I have your attention, please look in on this one:

https://groups.google.com/g/video-downloadhelper-q-and-a/c/AmqrGD84Lsc

It seems that the ffmpeg you have bundled with the CoApp has support for AES-128
encryption but not SAMPLE-AES encryption. My suspicion is that you need to build ffmpeg
differently. Unfortunately, I can't test out my theory on the content mentioned in that
thread because it is behind a user ID & password. But my web searches lead me to believe
that the real ffmpeg I have would support SAMPLE-AES encryption, whereas the user in that
other thread is reporting that the captive ffmpeg that you distribute with the CoApp is
missing this support due to the ffmpeg build parameters you use. Do please look at that
other thread.

[Wild Willy]

There has been some progress on this one.  You need to be preparing yourself to switch
away from this Google Group & start monitoring this page:

https://github.com/aclap-dev/video-downloadhelper/discussions?discussions_q=

If you want VDH support, it will be provided in a new location.  This Google Group will
not be erased but GitHub will be the focus of VDH support from now on.  The German ASMR
video above is mentioned over there on GitHub.  You'll have to go look for that mention.