[FFmpeg-trac] #10149(avformat:new): Unable to read most of HLS M3U8 from Arte TV
FFmpeg
trac at avcodec.org
Thu Feb 23 06:23:24 EET 2023
#10149: Unable to read most of HLS M3U8 from Arte TV
-------------------------------------+-------------------------------------
Reporter: Thomas | Owner: (none)
ERNEST |
Type: defect | Status: new
Priority: normal | Component: avformat
Version: 4.4.3 | Resolution:
Keywords: hls m3u8 | Blocked By:
webvtt fmp4 subtitles |
Blocking: | Reproduced by developer: 0
Analyzed by developer: 0 |
-------------------------------------+-------------------------------------
Comment (by quinkblack):
sidx is the direct reason leading to the failure, but it's not the root
cause.
1. Media initialization section byterange includes sidx. There is no
benefical in HLS's case, although DASH can use sidx explicitly. How to
interpret the sidx is a question, HLS spec doesn't help. If the byterange
excluding sidx, the issue should be gone.
{{{
#EXT-X-MAP:URI="089171-000-A_v360.mp4",BYTERANGE="33087 at 0"
}}}
2. FFmpeg mp4 demux has no issue to handle the sidx. You can test it with
{{{
ffplay 'https://arte-
cmafhls.akamaized.net/am/cmaf/089000/089100/089171-000-A/230120220655/medias/089171-000-A_v360.mp4'
}}}
The issue happens when playback fmp4 inside HLS. The log message "sidx
reference_type 1 is not implemented" is misleading. It's some IO error
leads to this error, the fmp4 doesn't use sidx reference_type 1.
I don't have much time to dig further now.
--
Ticket URL: <https://trac.ffmpeg.org/ticket/10149#comment:4>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker
More information about the FFmpeg-trac
mailing list