dirkf

Exactly, the weirdness is that the extensive attempts in the function to select a valid encoding are failing; also that the Python IO library doesn't reveal this until `.flush()`. Last...

The default compression is `-6` which gives a 12% smaller than `-1` for 30% more `time` (against the current codebase). The trade-off for `-9` is x2 CPU vs 7% better...

>... something like %(id)s into filename That would have helped, and since you can adjust the destination (and other) directory/ies using _yt-dlp_ options, there's now generally little need to override...

Doesn't the description of `--no-overwrites` need to be improved? >`Do not overwrite any files` Regarding overwrites, the manual mentions variously "video" files, "video and metadata" files, "related" files, and "post-processed"...

While this is pending, may I suggest an additional helper, say `value()` (naming up for grabs) like this: ```py def value(result): return lambda obj: None if obj is None else...

Sure, but I was looking for some sugar-coating to make the intent more obvious, as `filter` does for `{lambda x: x or None}`.

This problem still exists, because the potential filesize is only checked (only known?) for HTTP downloads and not for fragment (DASH, HLS) downloads. TODO: check how this works in _yt-dlp_.

>... check how this works in _yt-dlp_. The same: https://github.com/yt-dlp/yt-dlp/issues/10663#issuecomment-2393100696

It's a bit vexing that the yt-dlp PR has done the same job, but by all means plunder any useful stuff from there. I would generally merge/back-port an updated _yt-dlp_...

Great. Also, if there are standard patterns for the discarded sites where NPO videos are embedded, we can add a class variable `_EMBED_REGEX` that is a list of those patterns...