Added Download Audio Only

[gamersindo1223]

I haven't tested it yet, using http.DetectContentType it always says video/mp4 which is, weird

[gamersindo1223]

@wader hey, just askin. can you check if the http.DetectContentType is still video/mp4 even though it's an m4a file?

[gamersindo1223]

Could use --audio-format mp3 but that will result on some loss on quality

[wader]

Hey, hmm i wonder if this should be a DownloadOption?

I would guess that http.DetectContentType only does some basic probing, to know what kind of media a mp4 file has you probably need to digg a bit deeper.

What https://github.com/wader/ydls does is it to use New to get a Result and then walk thru Entries to find a good format fit to download, then i think you can also know what type of container and media it has (at least what yt-dlp claims). But i'm not sure what your use case is? avoid re-transcoding?

[gamersindo1223]

1. This would make more sense other than putting it inside DownloadOption And Not ``Options```
2. Im not avoiding it, but looks like http.DetectContentType always detect the m4a as mp4, I'm forced to input the mimetype myself

[wader]

1. This would make more sense other than putting it inside DownloadOption And Not ``Options```

Yes, the New function is mostly to download format metadata and not the meda itself, at least that was the idea from the start.

2. Im not avoiding it, but looks like http.DetectContentType always detect the m4a as mp4, I'm forced to input the mimetype myself

Looking at the code https://github.com/golang/go/blob/b31e9a63a4d7ed98b89719ee54b752920782ae15/src/net/http/sniff.go#L265 it seem to only be able to return video/mp4, to see if a mp4 container only has audio i think you would have to traverse the box tree and look at the trak/mdia boxes etc. My idea was to trust yt-dlp:s extractor data about what media a certain format has, but it might be wrong i guess. If you really want to know and performance is not huge issue you might be able to use ffprobe etc.

[gamersindo1223]

Hmm, performance is a huge issue but some delay would not matter so much.

[gamersindo1223]

Oh and, is it a good idea to implement --audio-formats? https://github.com/yt-dlp/yt-dlp#post-processing-options

[wader]

Hmm, performance is a huge issue but some delay would not matter so much.

If you use something like ffprobe it will add a bit of delay but once that is done it will be same speed. ydls uses ffprobe to verify that the select format actually is what yt-dlp claims it is, it does this to know if it needs to transcode or if it can just transmux (much faster). To speed things up it also uses https://github.com/wader/ydls/tree/master/internal/rereader so that it does not need to redownload things.

[wader]

Oh and, is it a good idea to implement --audio-formats? https://github.com/yt-dlp/yt-dlp#post-processing-options

You mean as a DownloadOption? yeah maybe. Most of goutubedl's API is designed to just provide metadata and "raw" format download and it's up to someone else to convert etc (like what ydls does), so that is the reason why things might feel a bit weird. But maybe it would make sense to support some of yt-dlp:s convert abilities somehow, i haven't played around with that much.

[gamersindo1223]

updating pr

[wader]

Tests fail because of the new youtube bot restrictions hmm, have to figure out some better way to test i guess. One idea is to run our own local http server in the tests and relay on the generic extractor somehow, might be ok?

How do you feel about adding test for this change? is a good way to make sure things don't break in the future.

[gamersindo1223]

Tests fail because of the new youtube bot restrictions hmm, have to figure out some better way to test i guess. One idea is to run our own local http server in the tests and relay on the generic extractor somehow, might be ok?

How do you feel about adding test for this change? is a good way to make sure things don't break in the future.

and/or use your own coookie

[wader]

Tests fail because of the new youtube bot restrictions hmm, have to figure out some better way to test i guess. One idea is to run our own local http server in the tests and relay on the generic extractor somehow, might be ok? How do you feel about adding test for this change? is a good way to make sure things don't break in the future.

and/or use your own coookie

Mm could work, but i guess the cookie will expire and i guess i don't want it connected to my personal google account? :) but it would be great if the tests were decoupled from anything external but maybe it's not worth it.

[gamersindo1223]

Tests fail because of the new youtube bot restrictions hmm, have to figure out some better way to test i guess. One idea is to run our own local http server in the tests and relay on the generic extractor somehow, might be ok? How do you feel about adding test for this change? is a good way to make sure things don't break in the future.

and/or use your own coookie

Mm could work, but i guess the cookie will expire and i guess i don't want it connected to my personal google account? :) but it would be great if the tests were decoupled from anything external but maybe it's not worth it.

Hmm, other than using cookie file (or using yt-dlp-oauth2 plugin) bypassing your not a robot page isn't possible

[gamersindo1223]

Or using a proxy

[wader]

Hmm, other than using cookie file (or using yt-dlp-oauth2 plugin) bypassing your not a robot page isn't possible

Yeah is a bit bad and also a sign that the tests should ideally not relay on external things that can change, or at least very few known stable things. But it would probably take some effort to redo all the tests in a nice way.

[wader]

Hey again, the current PR works for your use case? merge?

[gamersindo1223]

Yes it is working on my machine