After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 659723 - Rendering hangs at playing variant m3u8 playlist
Rendering hangs at playing variant m3u8 playlist
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
git master
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2011-09-21 14:30 UTC by Reynaldo H. Verdejo Pinochet
Modified: 2013-06-12 06:22 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Logs for [1] (821.18 KB, application/x-gzip)
2011-09-21 14:49 UTC, Reynaldo H. Verdejo Pinochet
Details
Logs for [2] (771.25 KB, application/x-gzip)
2011-09-21 14:49 UTC, Reynaldo H. Verdejo Pinochet
Details

Description Reynaldo H. Verdejo Pinochet 2011-09-21 14:30:05 UTC
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.
Comment 1 Reynaldo H. Verdejo Pinochet 2011-09-21 14:49:01 UTC
Created attachment 197162 [details]
Logs for [1]
Comment 2 Reynaldo H. Verdejo Pinochet 2011-09-21 14:49:31 UTC
Created attachment 197163 [details]
Logs for [2]
Comment 3 Julien Isorce 2012-02-24 12:49:08 UTC
Hi with playbin2 uri="http://devimages.apple.com/iphone/samples/bipbop/bipbopall.m3u8", at around 9 sec I got:

** (gst-launch-0.10:26490): CRITICAL **: gst_adapter_take_buffer: assertion `nbytes > 0' failed

Program received signal SIGSEGV, Segmentation fault.

Thread 3024092016 (LWP 26501)

  • #0 gst_buffer_is_metadata_writable
    at gstbuffer.c line 684
  • #1 gst_buffer_make_metadata_writable
    at gstbuffer.c line 707
  • #2 gst_base_parse_chain
    at gstbaseparse.c line 2478
  • #3 gst_pad_push
    at gstpad.c line 4710
  • #4 gst_single_queue_push_one
    at gstmultiqueue.c line 1087
  • #5 gst_multi_queue_loop
    at gstmultiqueue.c line 1318
  • #6 gst_task_func
    at gsttask.c line 327
  • #7 default_func
    at gsttaskpool.c line 70
  • #8 ??
    from /lib/i386-linux-gnu/libglib-2.0.so.0
  • #9 ??
    from /lib/i386-linux-gnu/libglib-2.0.so.0
  • #10 start_thread
    at pthread_create.c line 304
  • #11 clone
    at ../sysdeps/unix/sysv/linux/i386/clone.S line 130

Comment 4 Thibault Saunier 2012-03-13 16:39:40 UTC
It works properly with tsdemux.

tsdmux is now autopluged instead of mpegtsdemux in master, and as mpegtsdemux will not be maintained anymore, I think we should close as obsolete unless anyone have any reason not to.
Comment 5 Edward Hervey 2013-06-12 06:22:02 UTC
Works fine with current master. Closing as obsolete (as per confirmation in above comment).