Hi Traneptora On Tue, Feb 04, 2025 at 06:35:07PM -0500, Leo Izen wrote: > > > 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 > > > 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? yes, i was thinking the same, we should do this for git master thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB "Nothing to hide" only works if the folks in power share the values of you and everyone you know entirely and always will -- Tom Scott