dirkf

Solution 1: apply normalisation once the file has been downloaded; to minimise re-encoding, download the audio in native format and use a suitable _ffmpeg_ (or other) command to get the...

Closing pending a PR for (2) above.

`-v` shows _ffmpeg_ output, but not for postprocessing. Otherwise wait for https://github.com/yt-dlp/yt-dlp/pull/2475 and back-port. A nice work-around for the case where your audio extraction appears to be taking too long...

You could just leave the _cmd_, or shell, window open but minimised. Then for the next download just restore the window, use up-arrow to recall the last (or a similar)...

When considering possible tactics to overcome filename limits, it may be helpful to review the [T-shirt](https://github.com/ytdl-org/youtube-dl/issues/29912) and related links.

I had a different approach to decoding the messy player config which might be of use (see https://github.com/ytdl-org/youtube-dl/issues/29458#issuecomment-874354702). This follows on from your l.59; earlier on I had ` _URICHARS...

The PR author didn't implement any review comments. Looks like it needs a QA review before merging.

This is what's in the webpage: ```html ``` This apparently [1] invalid URL should be corrected to https://reoa92d.com/uploaded/1649416469.mp4#t=0.1, which Mozilla does. But `compat_urllib_request.Request()` doesn't. The URL specification says that a...

Eg this, which applies to both yt-dlp and yt-dl (same function code): ```py def sanitize_url(url): - # Prepend protocol-less URLs with `http:` scheme in order to mitigate - # the...

> ... it's better to handle this directly in the url_opener That would be appropriate since urllib/urllib2 is the source of the problem. Whenever I trace the code around opener...