dirkf

Also, the error is in code that was already known to be obsolete (https://github.com/yt-dlp/yt-dlp/issues/6398, #28381).

https://github.com/yt-dlp/yt-dlp/issues/7473 says you now have to authenticate, which I guess means passing cookies from your logged-in browser session.

As bashonly suggests in the yt-dlp PR, we should wait to see how the Muskified Twitter turns out before committing a new extractor.

Is that a random value, or is there an algorithm for generating it? BTW, the current _yt-dlp_ code adds a `User-Agent` header with value `Googlebot`. I presume that's supposed to...

I'm back-porting the current _yt-dlp_ Twitter/X extractor ATM. I suggest anyone who wants to contribute should hold back until this becomes a PR and then propose any improvements.

What "source" are you not getting that you think you should be getting? The third example (406 error) should be fixed by #9125.

It fixed the 406 error that was being shown in a prior yt-dlp version. As for `source`, the routine `_extract_original_format()` that would find it for a `www.video.com` URL isn't being...

The POC code included back-porting #9125, which fixes the 406. At l.843 of #9125, something like this: ```diff if '://player.vimeo.com/video/' in url: config = self._search_json( r'\b(?:playerC|c)onfig\s*=', webpage, 'info section', video_id)...

In order for this to make sense (as in this case) there would have to be additional rules about using `-o -` since the command might specify multiple subtitles, thumbnails,...

Currently, the API through which yt-dl[p] functionality is invoked doesn't have any concept of the parameter ordering. So "first" would have to mean "first download performed". Since the user can't...