demux/demux_lavf: pass dummy filename when an HLS mimetype is detected #11683
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
From my testing, with both patches, HLS live stream works again. |
Traneptora
force-pushed
the
m3u8-filename-mime-check
branch
2 times, most recently
from
24931fa
to
4f9ade3
Compare
Traneptora
changed the title
|
Changes since last force-push:
|
Traneptora
force-pushed
the
m3u8-filename-mime-check
branch
from
4f9ade3
to
ff1f927
Compare
My test confirmed that this is working without upstream patch. |
sfan5
reviewed
May 14, 2023
Pass "dummy.m3u8" filename to work around FFmpeg commit 6b1f68ccb04d791f0250e05687c346a99ff47ea1 which broke their HLS demuxer and its ability to probe. Since the above commit, libavformat will check the filename of the file to be probed and reject it if it doesn't end with a valid HLS extension i.e. m3u8,hls,m3u (never mind that .hls is not a valid HLS extension). In addition to a bug with query strings, this also breaks mpv functionality as mpv explicitly doesn't tell libavformat the filename when probing, in order to properly detect the file based only on their contents. The [HLS specification](https://www.rfc-editor.org/rfc/rfc8216.txt) aka RFC 8216, specifies in section 4 that "Each Playlist file MUST be identifiable either by the path component of its URI or by HTTP Content-Type." Notably, it does not require both, so this FFmpeg commit is noncompliant. We work around this noncompliance by checking the MIME type ourselves. If the mimetype matches one of the valid HLS mimetypes (and also application/x-mpegurl, a legacy pre-standardization type), then we pass "dummy.m3u8" to libavformat in order to work around its overly strict checking of filenames. Without this patch, we are unable to play many HLS streams, including a few from the ytdl hook. This patch restores those ability to play those streams when built against FFmpeg master. Do note that if the server sends an invalid content-type header then we cannot implement this workaround so those streams will still fail to play.
Traneptora
force-pushed
the
m3u8-filename-mime-check
branch
from
ff1f927
to
592dffc
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Note that this won't fix all HLS issues because a commit still needs to be merged upstream. Ideally test it with: https://patchwork.ffmpeg.org/project/ffmpeg/patch/20230512202622.29531-1-leo.izen@gmail.com/