stream-detector
stream-detector copied to clipboard
54ac
yt-dlp command line unsuitable for live-stream .m3u8
It might be not a bug of this plugin but I still wanted to post in case you wish to make a workaround.
I used the "command for youtube-dl" option to capture live streams from bongacams. A .m3u8 playlist there only gives a 3-second .ts file, youtube-dl keeps requesting .m3u8 to get the next .ts, and it goes until being cancelled.
When I use "command for yt-dlp" it only saves one .ts from the .m3u8 and doesn't fetch for the next ones. So it's always just a 3-sec video.
I guess some of the default behaviour of yt-dlp is different so some other option has to be passed to command line. Not sure which one. So if you know which argument to pass to yt-dlp in order to make it work the same as youtube-dl you might modify the command line.
This is a yt-dlp thing I'd imagine. I would generally advise to use ffmpeg for downloading m3u8 streams, but if anyone knows the appropriate command line option to add/change, let me know.
and why no Multi-threaded fragment downloads: Download multiple fragments of m3u8/mpd videos in parallel. Use --concurrent-fragments (-N) option to set the number of threads used in yt-dlp
Sure. Although I think it'd be good enough to implement a sane default (e.g. 4) rather than have an entire new option considering yt-dlp is the only software including multithreading I believe, unless I'm mistaken.
With this commit you accidently (I guess) also added the "-N 4" option to the youtube-dl commandline
https://github.com/rowrawer/stream-detector/commit/1fc33e7fedc4551fcda333095ef6f308a166bd27
Only there is no such option in youtube-dl and therefore the copied command doesn't work
youtube-dl: error: no such option: -N
My bad, I thought youtube-dl supported this option. Might just remove youtube-dl support, since yt-dlp is a better fork and is being kept up to date, unless youtube-dl has unique use cases.
No, 4 is hardcoded. Would that make a significant difference? I might implement an option for the number of yt-dlp threads.
No, 4 is hardcoded. Would that make a significant difference?
because it can change according to internet conditions
Would that make a significant difference?
reducing the chance of file corruption if download is interrupted.
Would that make a significant difference?
reducing the chance of file corruption if download is interrupted.
I suppose so. I'll consider adding an option related to the multithreading.
There will be an option to specify the amount of threads in yt-dlp in v2.10.19.