[Bug 659723] New: Rendering hangs at playing variant m3u8 playlist

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=659723
  GStreamer | gst-plugins-bad | git

           Summary: Rendering hangs at playing variant m3u8 playlist
    Classification: Platform
           Product: GStreamer
           Version: git
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: gst-plugins-bad
        AssignedTo: gstreamer-bugs at lists.freedesktop.org
        ReportedBy: reynaldo at opendot.cl
         QAContact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---


You get a hang at ~9s with this pipeline:

[1] gst-launch souphttpsrc
location=http://devimages.apple.com/iphone/samples/bipbop/bipbopall.m3u8  ! 
hlsdemux ! mpegtsdemux ! h264parse ! ffdec_h264 ! xvimagesink

(using tsdemux here doesn't help. Same results)

What's odd is that you can manually play from the first playlist file
in that top level bipbopall.m3u8 variant playlist without it hanging:

[2] gst-launch souphttpsrc
location=http://devimages.apple.com/iphone/samples/bipbop/gear1/prog_index.m3u8
 !  hlsdemux ! mpegtsdemux ! h264parse ! ffdec_h264 ! xvimagesink

You can also play from the other three playlist files pointed to from
bipbopall.m3u8 with no hangs at all:

gear2/prog_index.m3u8
gear3/prog_index.m3u8
gear4/prog_index.m3u8

Here are the relevant sections of the above mentioned playlist files:

This is bipbopall.m3u8, the top level playlist:

#EXTM3U
#EXT-X-STREAM-INF:PROGRAM-ID=1, BANDWIDTH=200000
gear1/prog_index.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1, BANDWIDTH=311111
gear2/prog_index.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1, BANDWIDTH=484444
gear3/prog_index.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1, BANDWIDTH=737777
gear4/prog_index.m3u8

This is prog_index.m3u8 for gear1

#EXTM3U
#EXT-X-TARGETDURATION:10
#EXT-X-MEDIA-SEQUENCE:0
#EXTINF:10, no desc
fileSequence0.ts
#EXTINF:10, no desc
fileSequence1.ts
...

This is prog_index.m3u8 for gear2

#EXTM3U
#EXT-X-TARGETDURATION:10
#EXT-X-MEDIA-SEQUENCE:0
#EXTINF:10, no desc
fileSequence0.ts
#EXTINF:10, no desc
fileSequence1.ts
...

This is prog_index.m3u8 for gear3

#EXTM3U
#EXT-X-TARGETDURATION:10
#EXT-X-MEDIA-SEQUENCE:0
#EXTINF:10, no desc
fileSequence0.ts
#EXTINF:10, no desc
fileSequence1.ts
....

This is prog_index.m3u8 for gear4

#EXTM3U
#EXT-X-TARGETDURATION:10
#EXT-X-MEDIA-SEQUENCE:0
#EXTINF:10, no desc
fileSequence0.ts
#EXTINF:10, no desc
fileSequence1.ts
....

My gut feeling says this is a problem in the hls demuxer
but I have yet to confirm whether this is the case. Maybe
its worth mentioning that this bug was originally observed
on a pandaboard with a diferent, omx/v4l2, decoding/rendering
stage.

I'm attaching *:4 logs for [1] (m3u8_full.log) and (m3u8_prog1.log).
These logs were obtained with an uninstalled setup based on a gst-
checkout from yesterday.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.