[Bug 750847] dashdemux: variables containing time information should be guint64 not gint64

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=750847

Vincent Penquerc'h <vincent.penquerch at collabora.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |vincent.penquerch at collabora
                   |                            |.co.uk

--- Comment #3 from Vincent Penquerc'h <vincent.penquerch at collabora.co.uk> ---
After looking at the spec and code for the signed values in the header:

GstPeriodNode::start, duration:
No particular indication of signedness in the spec.

GstMetricsRangeNode::starttime, duration:
No particular indication of signedness in the spec.
starttime is said to be relative to the period stat time. I think everything is
supposed to be clipped to that, so negative would not make sense here, but it's
unclear again.

GstMPDNode::mediaPresentationDuration, minimumUpdatePeriod, minBufferTime,
timeShiftBufferDepth, maxSegmentDuration, maxSubsegmentDuration
No particular indication of signedness in the spec.

GstMPDNode: suggestedPresentationDelay
The only thing that could related to signedness is a mention this can be used
to sync playback to wall clock, this this hints that it could be negative.

GstMediaSegment::repeat
Can be negative (see https://bugzilla.gnome.org/show_bug.cgi?id=752480)

GstMediaSegment::range_start, range_end, index_range_start, index_range_end:
Seems not to come directly from attributes, end is used in the STL sense, so -1
is valid there. Thus a -1 start makes sense too (even though it may be
impossible in practice)

GstActiveStream::representation_idx
Internal, negative doesn't make sense in theory, but I guess it might be
possible to be in a state where there is no current representation. This is not
the case with current code I thinkl.

GstActiveStream::segment_index
Internal, -1 is used

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.