-
Notifications
You must be signed in to change notification settings - Fork 10k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
"--hls-use-mpegts --no-part" should create files with ".ts" extension #11105
Comments
@jaimeMF @Vangelis66 I am new to youtube-dl, but I think most or all modules default to But I fully agree that this should be done by default... if possible. Because So for now I have to be sure to only send the .ts/use-mpegts flags when I know the site uses mpegts. @jaimeMF I think it makes a lot of sense to automatically replace the meaning of "ext" with ".ts" when --hls-use-mpegts is enabled and youtube-dl detects a m3u8 playlist. That way we can use a single command to download any file, and always be sure to get live-playable .ts files when they are livestreams. I hate using .mp4 since its metadata isn't written until the end so if my computer or the app crashes then I can never recover the file since it has no metadata. And only mpegts files can be live-previewed before the download is complete. So I choose to get all livestreams as .ts and then manually convert to a different container later for archival. |
@SteveJobzniak Or maybe it is easier to replace ext with .ts if ffmpeg is executed with the |
@diamond12 Not sure if that would work. The "external downloader" script that launches ffmpeg says And https://github.com/rg3/youtube-dl/blob/master/youtube_dl/downloader/hls.py is another HLS downloader which would need fixing too. I propose a possible solution: If the youtube-dl extractor detects a .m3u8 file AND Either way, this is a pretty silly problem in youtube-dl. Its "automatic filename" feature definitely shouldn't be applying a totally incorrect file extension! :-O It's not a "feature request". It's a necessary bugfix. |
@SteveJobzniak I agree it's a bug and I don't know why it is marked as a feature request. The source that you pointed me to is right after |
@diamond12 Oh yeah you are right! So they do check that it's a HLS stream before applying All that's missing now is applying the correct output extension (.ts) whenever it detects a HLS stream. I think correcting the meaning of |
@jaimeMF I am extremely overworked, but took a minute to look at the source to get things rolling. It seems the function https://github.com/rg3/youtube-dl/blob/master/youtube_dl/YoutubeDL.py#L1363 It loops through all possible video sources and fills in their 'ext' value if missing. And then it also runs The https://github.com/rg3/youtube-dl/blob/master/youtube_dl/utils.py#L2323 It seems like all of this extension/protocol/URL-determining code is done without connecting to the server to check any mimetype. It looks like any advanced detection (such as a ".m3u8" hiding behind a ".php" URL), is up to that website's extractor plugin to put in the returned Since it seems like YouTube-DL hasn't got any responsibility to further verify the protocol, it seems like modifying the extension selector in YoutubeDL.py's
That would fix the bug. Please comment to let us know your thoughts. Is there a better location to fix the bug? Did I find the right location? Could you please fix this bug without a pull request? I need to go now. |
OS: Windows Vista SP2 x86, latest OS updates from Microsoft.
Using the latest standalone "youtube-dl.exe" downloaded from Github.
youtube-dl --version => 2016.11.02
Also using FFmpeg.exe 3.0 (x86) downloaded from the Zeranoe repo.
The first channel of the Greek National TV broadcaster uses Youtube to host its live stream;
ERT1 LIVE => https://www.youtube.com/watch?v=gnnO4TeJG-4
The actual youtube URL changes frequently...
--hls-prefer-native
doesn't seem to be able to handle this stream,so ffmpeg MUST be used. When issuing:
youtube-dl -f 94 --no-part "https://www.youtube.com/watch?v=gnnO4TeJG-4"
the stream download is delegated to FFmpeg and (correctly) youtube-dl creates
a file with the ".mp4" extension. When I
CTRL+C
, the end file is correctlyidentified by MediaInfo to be an MP4 file.
On the contrary, when I issue:
youtube-dl -f 94 --hls-use-mpegts --no-part "https://www.youtube.com/watch?v=gnnO4TeJG-4"
youtube-dl (again) generates a file with file extension ".mp4", but
the
--hls-use-mpegts
switch creates an MPEG-TS container which has(by default) a ".ts" file extension (... at least on Windows)!
CTRL+C
ing results in an end file which is, in essence, a ".ts" file,as reported by MediaInfo, but with an erroneous ".mp4" extension.
I have to manually rename the file back to the correct ".ts" extension.
I am of the opinion this is a bugged behaviour on the part of the
application and that youtube-dl should be smart enough to attribute
the correct file extention (.ts) when
--hls-use-mpegts
is employed...Many thanks to all the devs' team for their on-going efforts!
The text was updated successfully, but these errors were encountered: