GNOME Bugzilla – Bug 754546
tsdemux: Problem with playing some HLS links
Last modified: 2018-11-03 13:40:03 UTC
Below HLS links are unable to play: http://stmw.rthk.hk/aod/_definst_/radio/archive/radio1/Free_as_the_wind/mp3/mp3:20140221.mp3/playlist.m3u8 http://stmw2.rthk.hk/aod/_definst_/radio/archive/radio1/hkfootpath/mp3/mp3:20140330.mp3/playlist.m3u8 http://test.live.net.il/glz-a-zixief.m3u8
I tried the first one but it's not playing for me in vlc either. Does it work for you in any application?
(In reply to Sebastian Dröge (slomo) from comment #1) > I tried the first one but it's not playing for me in vlc either. Does it > work for you in any application? Yes, I tested these links on Android (Samsung Note 3) and its playing fine there. We are currently working on the patch for Tizen and will upload the fix/patch shortly for review.
Ok, great. Thanks! :) Please make sure the patch applies to latest GIT master, and not only to 1.4.
Created attachment 311044 [details] Patch for the bug 754546 Below is the issue analysis for the issue, HLS Links(mentioned in the bug) not playing. [problem] For HLS servers/links sending Random Access flag, mpegts packetizer was returning Invalid timestamp [cause] Mpegts packetizer was not handling Random Access Indicator flag [solution] Added Logic to Handle Random Access Indicator flag. Handled Random Access Indicator flag of Adaptation field in MPEGTS Kindly guide me on how to push the code changes to git for merging and review. Thanks!
Comment on attachment 311044 [details] Patch for the bug 754546 Please attach a proper patch in git format-patch format, thanks.
Hi, While cloning the git repo , I m getting the below error: git clone -v git://anongit.freedesktop.org/git/gstreamer/gst-plugins-bad Cloning into 'gst-plugins-bad'... fatal: protocol error: bad line length character: <Scr Does anyone have any idea, how to resolve this error?
Looks like a network problem on your side? Please try with the http URL :)
Created attachment 311432 [details] [review] Problem with playing some HLS links [problem] For HLS servers/links sending Random Access flag, mpegts packetizer was returning Invalidtimestamp [cause] Mpegts packetizer was not handling Random Access Indicator flag [solution] Added Logic to Handle Random Access Indicator flag. Handled Random Access Indicator flag of Adaptation field in MPEGTS
What exactly is the problem here? That hlsdemux outputs a [0,-1] segment but timestamps are actually starting at a big number, and your patch now offsets them to start at 0? If so, the real fix would most likely be in hlsdemux or adaptivedemux to make sure an appropriate segment is generated.
Hi, Could you please let me know that, how the new segment generation in HLSDemux will fix this scenario, As even if we generate appropriate new segment, mpegts_packetizer_pts_to_ts function which calaulates the Stream time in mpegtspacketizer will still retun GST_CLOCK_TIME_NONE as , here ts calculation is done only for PCR case, but in case of Random Access, it will still return GST_CLOCK_TIME_NONE as ts. Thanks !
I didn't say that it will fix this scenario. Only that the correct fix is most likely inside hlsdemux or adaptivedemux. Also you didn't answer my questions from the previous comment so I can't really tell you anything new :)
Hi, let me answer your below questions from your previous reply. What exactly is the problem here? So, here the exact problem is not with new segment generation. Rather the problem is with calculation of TS from PTS in mpegts_packetizer_pts_to_ts function. That hlsdemux outputs a [0,-1] segment but timestamps are actually starting at a big number, and your patch now offsets them to start at 0? Here PTS timestamps from the segments are fine, its not starting at a big number. And my patch is handling the TS calculation in case of Random Access indicator flag, as in mpegts_packetizer_pts_to_ts , which calculates TS from the received PTS is only for PCR flags. So, even if the PTS from segment is coming correct, mpegts_packetizer_pts_to_ts is returning TS as GST_CLOCK_TIME_NONE for Non-PCR cases. Thanks !
Hi, Can I get a feedback on the above changes and comment. Please check it once . Thanks !
I don't understand what you mean, sorry :) I would have to look at the streams myself, but no time for that currently... maybe someone else does.
Hi, Can someone please help me checking this code.
Review of attachment 311432 [details] [review]: I know nothing about the RANDOM_ACCESS flag, if you could point us to the specification that could help. Though, I can explain in what Sebastien means. Right now, you calculate a base time for your timestamp and do some math to offset that to 0. This is redundant, as we already offset that using the GstSegment. We offset the first PTS (lowest) to running time 0 in tsdemux.c calculate_and_push_newsegment(). It does that, unless upstream already provided a segment in time format. In anycase, please share the specification around RANDOM_ACCESS, and we will be able to provide with better review.
Its a one bit flag of Mpegts Adaptation Filed Format. It is set to 1 if the PES packet in this TS packet starts a video/audio sequence. For more details please visit below links: https://en.wikipedia.org/wiki/MPEG_transport_stream Thanks !
-- 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/296.