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 751529 - dashdemux: stream->presentationTimeOffset is not always set
dashdemux: stream->presentationTimeOffset is not always set
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
git master
Other All
: Normal normal
: 1.7.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2015-06-26 09:15 UTC by Florin Apostol
Modified: 2016-02-25 13:27 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Florin Apostol 2015-06-26 09:15:56 UTC
The standard does not impose any restrictions on when presentationTimeOffset can be set, so in theory it  could be set for any segment, regardless of how the segment is defined (segment base, segment list or segment template).
However, it seems that stream->presentationTimeOffset is only computed if the segment list is obtained from a  template.

Shouldn't stream->presentationTimeOffset be set for any kind of segment?

stream->presentationTimeOffset is set by gst_mpd_client_setup_representation and it's value is obtained using gst_mpd_parser_get_stream_presentation_offset function.
Comment 1 Sebastian Dröge (slomo) 2015-06-26 09:30:08 UTC
I guess we should set it to GST_CLOCK_TIME none if it's unset... and check for GstClockTime none in all places where we get the presentation offset.

gst_adaptive_demux_get_presentation_offset() must return 0 for the cases when the offset is not set.


Want to provide a patch? Also note last night's changes in that area.
Comment 2 Sebastian Dröge (slomo) 2015-06-26 10:54:28 UTC
I think it would be initialized to 0 currently and then we would return 0 as offset everywhere. So maybe everything's good already
Comment 3 Florin Apostol 2015-06-26 11:18:41 UTC
yes, it is initialized to 0 because the stream is allocated by g_slice_new0.

But my question is about computing it: it seems that gst_mpd_client_setup_representation will compute and set it only for template segments. Shouldn't it be computed for any kind of segment? For example, for list or base segment, it will be ignored.

I don't know if that is a valid case, but the standard does not mention that it must be provided only for template segments. I expected that if a segment provides a presentationTimeOffset, it will be picked up and reflected in the return value of gst_mpd_parser_get_stream_presentation_offset
Comment 4 Thiago Sousa Santos 2015-06-26 14:41:04 UTC
It would be good to look at the spec and parse in the nodes that could have it. It seems that it is defined in the SegmentBaseType and could be used in different nodes if I understand the xml-syntax stuff correctly.
Comment 5 Florin Apostol 2015-06-26 14:55:26 UTC
From what I saw, the parsing is done correctly. The problem is that the parsed information is not always used. More precisely, it is used only for template segments. For other segment types the stream->presentationTimeOffset (which should be set by gst_mpd_client_setup_representation) is never set and remains 0.

What I'm saying is that gst_mpd_client_setup_representation should set stream->presentationTimeOffset for all kind of segments, not only template segments.
Comment 6 Sebastian Dröge (slomo) 2015-06-26 15:04:24 UTC
I think you're right and it should be used everywhere. Wouldn't make sense otherwise to allow it to be used in non-template cases ;)
Comment 7 Thiago Sousa Santos 2015-11-17 21:39:41 UTC
Ping? Anyone working on a patch here?
Comment 8 Thiago Sousa Santos 2015-11-21 00:04:03 UTC
commit 5be46607bb5020259cf733505fb77be38a3a5b60
Author: Thiago Santos <thiagoss@osg.samsung.com>
Date:   Fri Nov 20 20:59:16 2015 -0300

    dashdemux: always set presentationTimeOffset
    
    Set it for all types of segment lists (templates / lists / base)
    and not only for templates.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=751529