I have been using yt-dlp for twitter for animations, but I have no clear idea on which format to use for youtube videos.

I have used the -F command to merge the highest resolution webm option (with webm_dash) with the highest quality webm audio (with webm_dash) to export and upload the video, however it still seems like it is not the highest quality output.

Here is an example as post 4715229

Which format should be used to export Youtube videos correctly using yt-dlp? Or would there a more optiomal software to use for such cases?

short answer: it's pay-to-win

long answer: youtube locks higher bitrate videos behind their $15 USD monthy subscription plan: youtube premium. and since this site demand the highest quality available; what that means is you'll need access to that higher quality bitrate version of the video if you want it on here without bearphones immediately replacing it (i think even the advice they gave me when i was uploading chikn nuggit was "get premium")

if for whatever reason you already have premium: just add the parameter --cookies-from-browser <name of browser you use here> and that should grab the cookies that let things know if you got premium and then yt-dlp will download the higher bitrate version of the vid (which is 356 for the webmdash, but yt-dlp should automatically pick this and the highest quality audio format available when just punching in the url plain)

dripen_arn said:
short answer: it's pay-to-win

long answer: youtube locks higher bitrate videos behind their $15 USD monthy subscription plan: youtube premium. and since this site demand the highest quality available; what that means is you'll need access to that higher quality bitrate version of the video if you want it on here without bearphones immediately replacing it (i think even the advice they gave me when i was uploading chikn nuggit was "get premium")

if for whatever reason you already have premium: just add the parameter --cookies-from-browser <name of browser you use here> and that should grab the cookies that let things know if you got premium and then yt-dlp will download the higher bitrate version of the vid (which is 356 for the webmdash, but yt-dlp should automatically pick this and the highest quality audio format available when just punching in the url plain)

The 356 format does not seem to be available when using cookies on yt-dlp. the highest available version is 616, which is mp4 premium.

Using the URL plain with the cookies, also only seems to combine 616+251 as an output.

coopercaller said:
The 356 format does not seem to be available when using cookies on yt-dlp. the highest available version is 616, which is mp4 premium.

Using the URL plain with the cookies, also only seems to combine 616+251 as an output.

hmmm, i think that number i came up with was from a specific video. i should've corrected that

can you link to the video(s) you're trying to download? i want to check what's going on

dripen_arn said:
hmmm, i think that number i came up with was from a specific video. i should've corrected that

can you link to the video(s) you're trying to download? i want to check what's going on

Here

Maybe the yt-dlp I am using is different (even if it is updated to the latest version).

At worst case, I'll have to download the mp4 format and convert it to webm via ffmpeg

odd, i'm getting a result for 356 on this video too

do you have premium? i think i remember not getting 356 as an option until i did (tho that wouldn't explain the mp4 premium varient popping up if you don't)

dripen_arn said:
odd, i'm getting a result for 356 on this video too

356 webm 1920x1080 30 │ 10.82MiB 1008k https │ vp9 1008k video only 1080p Premium, webm_dash

do you have premium? i think i remember not getting 356 as an option until i did (tho that wouldn't explain the mp4 premium varient popping up if you don't)

I do have premium, but as mentioned, I only get the premium version for the mp4.

Maybe the yt-dlp I am using is different? Could be due to me using the .exe variable rather than the python version.

If it is possible, could you link the version of yt-dlp that you are using?

coopercaller said:
I do have premium, but as mentioned, I only get the premium version for the mp4.

Maybe the yt-dlp I am using is different? Could be due to me using the .exe variable rather than the python version.

If it is possible, could you link the version of yt-dlp that you are using?

i think i just installed it using winget, which is microsoft's built-in package manager that just lets you install stuff by typing it out in-console

if you have a mac then install brew and run brew install yt-dlp in terminal. there are plenty of similar options for linux but idk shit about linux

sorry for needling some more, but do you use the --cookies-from-browser parameter? i tried it again without it and it gave me the exact same search that you ended up with

dripen_arn said:
i think i just installed it using winget, which is microsoft's built-in package manager that just lets you install stuff by typing it out in-console

winget install yt-dlp

if you have a mac then install brew and run brew install yt-dlp in terminal. there are plenty of similar options for linux but idk shit about linux

sorry for needling some more, but do you use the --cookies-from-browser parameter? i tried it again without it and it gave me the exact same search that you ended up with

I actually used both --cookies-from-browser and --cookies commands but both of the options gave me the same results.

Closed chrome while using--cookies-from-browser.

Also extracted cookies using Get cookies.txt

coopercaller said:
I actually used both --cookes-from-browser and --cookies commands but both of the options gave me the same results.

Closed chrome while using--cookies-from-browser.

Also extracted cookies using Get cookies.txt

the only thing i can assume is wrong is that you're not using --cookies-from-browser right, where you're supposed to end it with the name of the browser you're logged into (e.g. --cookies-from-browser chrome --cookies-from-browser firefox --cookies-from-browser netscape --cookies-from-browser ect)

if you have been doing it the right way; then i am at a complete loss

I was going to suggest spoofing iOS (--extractor-args "youtube:player_client=default,ios"), which was recommended when I looked up how to get Premium videos last year, but it seems yt-dlp does that by default now?

coopercaller said:
At worst case, I'll have to download the mp4 format and convert it to webm via ffmpeg

Did you download the MP4 and convert that yourself?

When I run a basic download command with yt-dlp on the video you linked, yt-dlp gets 616+251 and muxes them to WebM. The 616 may say it's an MP4, but it's a VP9 MP4. Seems there's no need to re-encode (usually MP4 video is H264, needing re-encoding to VP9). The video I get is not quite identical to Mairo's (ffprobe says mine is 5kb/s smaller), but my result (6.38MB) must be much closer to Mairo's (6.42MB) than your 3.5MB upload.

yt-dlp https://www.youtube.com/watch?v=kqj-fo7i4Yg
[youtube] Extracting URL: https://www.youtube.com/watch?v=kqj-fo7i4Yg
[youtube] kqj-fo7i4Yg: Downloading webpage
[youtube] kqj-fo7i4Yg: Downloading ios player API JSON
[youtube] kqj-fo7i4Yg: Downloading android player API JSON
[youtube] kqj-fo7i4Yg: Downloading m3u8 information
[info] kqj-fo7i4Yg: Downloading 1 format(s): 616+251
[hlsnative] Downloading m3u8 manifest
[hlsnative] Total fragments: 12
[download] Destination: 나 좀 풀어줄래？ [kqj-fo7i4Yg].f616.mp4
[download] 100% of    5.76MiB in 00:00:01 at 4.86MiB/s
[download] Destination: 나 좀 풀어줄래？ [kqj-fo7i4Yg].f251.webm
[download] 100% of  650.19KiB in 00:00:00 at 13.26MiB/s
[Merger] Merging formats into "나 좀 풀어줄래？ [kqj-fo7i4Yg].webm"
Deleting original file 나 좀 풀어줄래？ [kqj-fo7i4Yg].f251.webm (pass -k to keep)
Deleting original file 나 좀 풀어줄래？ [kqj-fo7i4Yg].f616.mp4 (pass -k to keep)

[youtube] kqj-fo7i4Yg: Downloading ios player API JSON

That should be the "spoof iOS" part. Default behavior.

[Merger] Merging formats into "나 좀 풀어줄래？ [kqj-fo7i4Yg].webm"
Deleting original file 나 좀 풀어줄래？ [kqj-fo7i4Yg].f251.webm (pass -k to keep)
Deleting original file 나 좀 풀어줄래？ [kqj-fo7i4Yg].f616.mp4 (pass -k to keep)

And that's muxing the MP4 to WebM, automatically. Default behavior.

Edit: Okay, reading...

I have used the -F command to merge the highest resolution webm option (with webm_dash) with the highest quality webm audio (with webm_dash) to export and upload the video, however it still seems like it is not the highest quality output.

You don't need to select webm_dash. See above. Get the best VP9 version, not the best WebM version.

Edit more! The AVC1 videos are the ones that need re-encoding.

abadbird said:
I was going to suggest spoofing iOS (--extractor-args "youtube:player_client=default,ios"), which was recommended when I looked up how to get Premium videos last year, but it seems yt-dlp does that by default now?

Did you download the MP4 and convert that yourself?

When I run a basic download command with yt-dlp on the video you linked, yt-dlp gets 616+251 and muxes them to WebM. The 616 may say it's an MP4, but it's a VP9 MP4. Seems there's no need to re-encode (usually MP4 video is H264, needing re-encoding to VP9). The video I get is not quite identical to Mairo's (ffprobe says mine is 5kb/s smaller), but my result (6.38MB) must be much closer to Mairo's (6.42MB) than your 3.5MB upload.

yt-dlp https://www.youtube.com/watch?v=kqj-fo7i4Yg
[youtube] Extracting URL: https://www.youtube.com/watch?v=kqj-fo7i4Yg
[youtube] kqj-fo7i4Yg: Downloading webpage
[youtube] kqj-fo7i4Yg: Downloading ios player API JSON
[youtube] kqj-fo7i4Yg: Downloading android player API JSON
[youtube] kqj-fo7i4Yg: Downloading m3u8 information
[info] kqj-fo7i4Yg: Downloading 1 format(s): 616+251
[hlsnative] Downloading m3u8 manifest
[hlsnative] Total fragments: 12
[download] Destination: 나 좀 풀어줄래？ [kqj-fo7i4Yg].f616.mp4
[download] 100% of    5.76MiB in 00:00:01 at 4.86MiB/s
[download] Destination: 나 좀 풀어줄래？ [kqj-fo7i4Yg].f251.webm
[download] 100% of  650.19KiB in 00:00:00 at 13.26MiB/s
[Merger] Merging formats into "나 좀 풀어줄래？ [kqj-fo7i4Yg].webm"
Deleting original file 나 좀 풀어줄래？ [kqj-fo7i4Yg].f251.webm (pass -k to keep)
Deleting original file 나 좀 풀어줄래？ [kqj-fo7i4Yg].f616.mp4 (pass -k to keep)

[youtube] kqj-fo7i4Yg: Downloading ios player API JSON

That should be the "spoof iOS" part. Default behavior.

[Merger] Merging formats into "나 좀 풀어줄래？ [kqj-fo7i4Yg].webm"
Deleting original file 나 좀 풀어줄래？ [kqj-fo7i4Yg].f251.webm (pass -k to keep)
Deleting original file 나 좀 풀어줄래？ [kqj-fo7i4Yg].f616.mp4 (pass -k to keep)

And that's muxing the MP4 to WebM, automatically. Default behavior.

Edit: Okay, reading...

You don't need to select webm_dash. See above. Get the best VP9 version, not the best WebM version.

Edit more! The AVC1 videos are the ones that need re-encoding.

Oh, so basically I can just type yt-dlp https://www.youtube.com/watch?v=kqj-fo7i4Yg, (add --cookies or --cookies-from-browser chrome, if there is an enchanced bitrate version) and it'll pick the best VP9 version as a webm.

I hope I got that right.

coopercaller said:
Oh, so basically I can just type yt-dlp https://www.youtube.com/watch?v=kqj-fo7i4Yg, (add --cookies or --cookies-from-browser chrome, if there is an enchanced bitrate version) and it'll pick the best VP9 version as a webm.

I hope I got that right.

yeah you got it right!

coopercaller said:
Oh, so basically I can just type yt-dlp https://www.youtube.com/watch?v=kqj-fo7i4Yg, (add --cookies or --cookies-from-browser chrome, if there is an enchanced bitrate version) and it'll pick the best VP9 version as a webm.

I hope I got that right.

dripen_arn said:
yeah you got it right!

yt-dlp is more clever in sense that it takes actual highest quality usually, where youtube-dl takes highest quality that's available as singular file, which in context of youtube is fucking ridiculous as all you will get at that point is 720p h264 MP4.

For Premium streams, you do need Youtube Premium subscription as well as passing your cookies to yt-dlp for it to get it.

coopercaller said:
Oh, so basically I can just type yt-dlp https://www.youtube.com/watch?v=kqj-fo7i4Yg, (add --cookies or --cookies-from-browser chrome, if there is an enchanced bitrate version) and it'll pick the best VP9 version as a webm.

I hope I got that right.

I haven't messed with yt-dlp much, so I can't speak too authoritatively about what it will do.

it'll pick the best VP9 version as a webm

I think it'll take the best video and audio separately and try to mux them together, like Mairo has said. I don't know if the best video will always be encoded with VP9, but it has been in my limited use.

VP9 is important because that's what e621 accepts. VP9 video can be uploaded to e621 without re-encoding and avoid the additional quality loss from re-encoding. WebM and MP4 are "containers." They hold the video, audio, and some other information in a single file and tell video players (including web browsers) how to play the videos. WebM is important because that's the only video container e621 accepts, because it's free to use. MP4 is patented and requires a paid license for e621 to use (or risk legal action).

The YouTube Premium video that I get for https://www.youtube.com/watch?v=kqj-fo7i4Yg is in VP9 (this under "VCODEC" -> vp09.00.40.08 -> vp09 = VP9) but within an MP4 container. MP4 and WebM can both play VP9, and for this video yt-dlp automatically removes the MP4 container and switches to WebM. This creates a file that e621 should accept without any special modification or instruction from the uploader, which is cool and easy. yt-dlp needs ffmpeg and ffprobe to do this!

coopercaller said:
(add --cookies or --cookies-from-browser chrome, if there is an enchanced bitrate version)

mairo said:
For Premium streams, you do need Youtube Premium subscription as well as passing your cookies to yt-dlp for it to get it.

I do not need nor have YouTube Premium, but I can still download the YouTube Premium video with yt-dlp. Don't need cookies, nothing. yt-dlp just does it anyway. That's why I was talking about iOS, which I also don't have. If what I read last year is still true, YouTube serves the Premium video to iOS for free, without a Premium account. Thus, yt-dlp tells YouTube it is iOS (and Android and a normal browser and a radio (?)) to give users the most download options possible for the highest quality possible. Does this sound like an exploit? It does to me, and it has existed and been used for at least a year. YouTube might properly lock this eventually as they mature their Premium service.

If you add -vU for verbose output to a -F query, yt-dlp will show the origin of each stream too. My one "Premium" stream displays as Premium, IOS with verbose output.

yt-dlp -F -vU https://www.youtube.com/watch?v=kqj-fo7i4Yg
...
ID      EXT   RESOLUTION FPS CH │    FILESIZE   TBR PROTO │ VCODEC          VBR ACODEC      ABR ASR MORE INFO
...
616     mp4   1920x1080   30    │ ~  13.89MiB 1793k m3u8  │ vp09.00.40.08 1793k video only          Premium, IOS

Perhaps, if you have Premium and pass those cookies to yt-dlp, yt-dlp may show a second, non-iOS Premium video stream too?

I mean, we probably shouldn't be uploading versions of stuff that's only on YouTube Premium anyway... that would be considered payed content, no?

dba_afish said:
I mean, we probably shouldn't be uploading versions of stuff that's only on YouTube Premium anyway... that would be considered payed content, no?

Apparently not, the reasoning given is that the artist wasn't the one to put that paywall there

dba_afish said:
I mean, we probably shouldn't be uploading versions of stuff that's only on YouTube Premium anyway... that would be considered payed content, no?

if a trusted janitor's gonna regularly replace standard bitrate posts with premium's enhanced bitrate versions; then no this site does not consider this content out of bounds

dba_afish said:
I mean, we probably shouldn't be uploading versions of stuff that's only on YouTube Premium anyway... that would be considered payed content, no?

As far as I understand how it works, content creators don't deal with YouTube Premium themselves. Creators can (if they're verified and set their videos to being monetized) get paid based on ad views, which applies to all versions of such videos regardless of resolution and quality. Premium is provided by YouTube as a way for viewers to skip ads but still pay the creator as if they had seen them, basically, along with access to extra content like YouTube TV and Movies and stuff. The content that is actually Premium-exclusive tends not to work with yt-dlp as it has DRM on it, requiring proprietary licensed browser plugins to play.

For normal YouTube content that could be considered paid, that the creator has set to monetize, it would be through ad revenue that's independent of the quality of the video. Premium is a viewer-side incentive rather than a creator-side one. The creator doesn't get anything more or less for a user viewing the Premium-quality version.

And AFAIK, there have been videos deleted from here that were sourced from monetized YouTube videos. But if they're unmonetized (even if they have ads; the creator doesn't get anything from them in that case, just as most people posting on FA don't get anything from FA's ads), they're good.

abadbird said:
I do not need nor have YouTube Premium, but I can still download the YouTube Premium video with yt-dlp.

You do. The Premium stream you get without it is Apple iOS specific version that's h264, not VP9.

dba_afish said:
I mean, we probably shouldn't be uploading versions of stuff that's only on YouTube Premium anyway... that would be considered payed content, no?

An unpopular take there, but it makes a weird sort of sense. Are they getting paid extra for being behind that paywall?

I wonder if we'd not be better off trying to get the producer of the original video to upload a native video already encoded to best quality e621 allows (100MB VP9 WEBMs with specific settings for audio and video). Surely, they kept their source files. Heck, YT is known to keep non-transcoded files even if it only serves a limited resolution, that you can download if you're the channel owner. Although of course it would be a horrible idea to depend on that as an artist with a dead drive! XD

snpthecat said:
Apparently not, the reasoning given is that the artist wasn't the one to put that paywall there

Ah, that answers that question. They don't get a single penny over normal monetization, either.

watsit said:
...requiring proprietary licensed browser plugins to play.

*cough*Widevine*cough*

A dirty little secret with video sites, BTW:
So long as you have the right URL (including possibly expiring keys), you can download any file they provide. It's just how CDNs work. The reason they all have expiring keys in the first place is that it was easier than access permissions granular to a specific group for a file being checked every time a file is requested. The CDN just refuses to provide the file just like normal 403 error if the far-faster-to-check access key is bad. One check is linear time, the other has to scale to billions of files. Fun computer science facts! :)
I have seen YT fail on specific videos (and resolutions!) because of a hiccup with the content servers. If you try again later, or from an IP in a different region, it suddenly gets a different server so it just works in those cases.