Support new DMS video format

[fireattack]

Nico started rolling out new "DMS" video/stream format.

Currently some video's certain quality (e.g. 1080p of this video) can only be obtained via DMS, which means NNdownload can only download up to 720p now.

See also:

https://github.com/yt-dlp/yt-dlp/pull/8685 https://github.com/yt-dlp/yt-dlp/issues/8758

[AlexAplin]

That video has been deleted, unfortunately. DMS is still going through a gradual rollout and videos/users are being selected randomly. I've been trying a few videos uploaded after 2023-11-01 and haven't found any examples of 1080p failing, so DMC seems predominant even still, and I haven't found any word on when older videos might be transitioned off DMC.

The other benefit of this change is that videos 30-60 minutes long can use 720p now (and also 1080p as of 12/15). sm43110779 can still be downloaded, but only in the expected 360p with DMC.

This seems likely to not be abandoned like a lot of the Nicocas functionality (#48) so we sould work on this. It seems like a fairly straightforward m3u8 manifest is retrieved and there might be some light encryption (probably doesn't matter, seems like the access key might be given directly in the page params).

Current concerns:

• How can we determine if a video should be upgraded to download from DMS instead of DMC?
  • EDIT: If params["media"]["domand"] is specified
• Will older videos be reencoded in any way when they are migrated? When might that happen?
• Can all existing qualities be retrieved on DMS, or will we have to determine the appropriate route?
  • EDIT: All qualities appear to be enumerated under params["media"]["domand"]

[AlexAplin]

Getting to the media URLs is pretty trivial and enumerating qualities doesn't take much tweaking. We'll need to settle on a way to mux these to a file, like m3u8-to-MP4, but might just have to do it from scratch to maintain our session. Additionally, that allows us to probably introduce a new flag to specify video or audio only for download.

[fireattack]

Ah, didn't realize we don't have an HLS/m3u8 downloader already. Once we have that in place, it should be very helpful for implementing #11 too (I already wrote a quick one for my own usage (https://github.com/fireattack/python-scripts/blob/master/nico.py) but I use external tools to handle the actual HLS downloading.)

[AlexAplin]

In my testing it doesn't really seem like the segments will need a session maintained to retrieve everything, however the key will 403 otherwise. So my thinking is we can probably retrieve the key, rewrite the manifest to use a local key file, and just let ffmpeg run with it. Might also just be safer to retrieve every segment and rewrite those too, though can get noisy having hundreds of segments sitting around. Something like this should suffice:

ffmpeg -protocol_whitelist https,http,tcp,tls,file,crypto -allowed_extensions ALL -i video-h264-720p.m3u8 -c copy out.mp4

Think we'll also need -bsf:a aac_adtstoasc when muxing the audio.

[AlexAplin]

All indications at this point seem to be that DMS is available for all videos now. To clarify where things stand with #146 (which I'm going to merge shortly):

• Multithreading (-r/--threads) and resuming partial downloads are not supported for DMS delivery. #148 will investigate reintroducing these as we look to making our own implementation rather than using ffmpeg for the heavy lifting.
• Video downloads in progress are now written to .part.mp4 files. When the download is complete, the extension updates to .mp4.
• As a result of the above change, any incomplete/partial videos that were downloaded with DMC prior to this change may incorrectly be reported as complete since we don't perform any byte window or length checks with DMS.
• Immediate focus after merging is going to be #36. As a part of that work, I'll likely remove/deprecate DMC functions.