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 791207 - dashdemux: doesn't play facebook live streams
dashdemux: doesn't play facebook live streams
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
1.12.3
Other Linux
: Normal major
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2017-12-04 13:41 UTC by Andreas Frisch
Modified: 2018-11-03 14:16 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Andreas Frisch 2017-12-04 13:41:09 UTC
I'm trying to play MPEG-DASH streams from facebook live
1. go to https://www.facebook.com/live/ and select a random stream
2. view the stream, right-click, display stream uri
3. copy that stream uri and run it though youtube-dl -g $uri
4. you get the actual MPEG DASH manifest uri which can be fed into gst-play
e.g. gst-play-1.0 "https://video.ftxl1-1.fna.fbcdn.net/hvideo-ash5/v/rMTvKZnCY3MLMygC0gCTG/live-dash/dash-abr1/761610404036944.mpd?_nc_rl=AfAdnDdKb8wmBUW6&oh=5199f0f8ddb5624c41c42a93727af578&oe=5A27CF0B" -v

result is just a tiny thumbnail which doesn't move

with gst-launch-1.0 uridecodebin uri="..." ! autovideosink sync=false at least there is a little bit of motion but the stream is also full of defects

... ! autoaudiosink sync=false will usually sound fine though

when looking at the timestamps falling out of the dashdemux with
gst-launch-1.0 souphttpsrc location="https://video.ftxl1-1.fna.fbcdn.net/hvideo-atn2/v/r9sFsHpnUNM2jJZUix-M2/live-dash/dash-abr4/2081836301833050.mpd?_nc_rl=AfDWx0uVBpW-bxwm&oh=77a92c9031f065a1e801f47bfdcadaa6&oe=5A278CA6" ! dashdemux ! fakesink silent=false -v
...
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = chain   ******* (fakesink0:sink) (664 bytes, dts: none, pts: 1:00:50.381000000, duration: none, offset: 0, offset_end: 664, flags: 00000040 discont , meta: none) 0x7f0cf801c620

it seems that the timestamps start way in the future which prevents the playback
Comment 1 Edward Hervey 2017-12-04 13:50:28 UTC
(One of) the issue is that the initial "live" seek in gst_dash_demux_setup_streams() silently fails. We try to seek to "now", but the various available fragments start at a much lower value (ex 1hour and not something like 8:46:06.501858000).

I think this points to the core issue related to there not being a presentation time offset.
Comment 2 Jun Xie 2017-12-05 09:47:51 UTC
seems segment start time is not set correctly,  IMHO, start time need to be set as the live edge join point, rather than 0
Comment 3 GStreamer system administrator 2018-11-03 14:16:02 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/636.