On 1/28/25 4:44 PM, Michael Niedermayer wrote:
Hi
On Tue, Jan 28, 2025 at 10:12:30PM +0200, Jan Ekström wrote:
On Tue, Jan 28, 2025 at 4:24 PM Michael Niedermayer
<mich...@niedermayer.cc> wrote:
Maybe fixes: 11435
Do I understand correctly that the root issue that's being attempted
to be fixed by the initial patch set is that unusual demuxers were
possible to have been probed and opened through the HLS meta demuxer?
In that case I would say that instead of trying to make very nebulous
and easily breakable extension based checking, maybe this demuxer
should just limit its default usable input formats?
To my knowledge the officially utilized container formats for HLS are
MPEG-TS, MP4-likes (fragmented mp4) and raw audio formats such as AAC,
MP3 or AC-3. One could check what hls.js or ExoPlayer support, and
that should be a generally mostly encompassing thing that does not
depend on what extensions are in use. Adding an AVOption to add
additional formats without code changes would then allow for some
outliers to be added by users.
there is extended M3U
https://en.wikipedia.org/wiki/M3U
that allows a wide range of things in it
our hls demuxer can read these, if we limit to mpeg-ts/mp4 we would remove
support for these.
From reading this, it seems like we're using the same demuxer for both
HLS streams (specified informationally in RFC 8216) as well as for
generic m3u playlists, and changes to the HLS implementation for
security reasons also change the M3U demuxer.
Why don't we just separate this into two different demuxers/protocols?
- Leo Izen (Traneptora)
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
