[FFmpeg-devel] [PATCH 2/2] avformat/hls: .ts is always ok even if its a mov/mp4

[Leo Izen]

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
>> <michael at 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)