[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