[Bug 793058] qtdemux: add support for edit lists for fragmented files in push mode

[GStreamer (GNOME Bugzilla)]

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

--- Comment #15 from Alicia Boya García <aboya at igalia.com> ---
(In reply to Alicia Boya García from comment #2)
> When doing so in the current version it seems to work OK in my brief tests.
> 
> On the other hand, commenting the if over this pending patch
> https://bugzilla.gnome.org/show_bug.cgi?id=778426 causes a regression in
> files without an edit list because the segment is cleared without being set
> then again. It should not delete the default segment if the file does not
> contain edit lists. 

I have checked again and it's quite the opposite, the segment is not emitted in
the file WITH edit list (car-20120827-86.mp4)

There actually two bugs here playing together:

a) Lack of support for duration = 0 in edit lists.

b) Lack of support for edit lists in fragmented files.

Removing the conditional fixes b), but a) remains.

(In reply to Alicia Boya García from comment #5)
> Notice how the movie presentation starts close to zero whereas without the
> edit list there is the equivalent time interval of a frame without image.
> 
> Unfortunately, it does not start exactly at zero because of rounding errors
> inherent to GStreamer design*.
> 
> * This is a consequence of applying edits by performing addition of fixed
> point nanoseconds (first frame unedited track time PTS lossly converted to
> fixed point in order to set GstBuffer.pts + edit start lossly converted to
> fixed point in order to set GstSegment.start). Unfortunately, since
> GstBuffer.dts is unsigned, qtdemux cannot handle edits by itself, they have
> to be applied by GstSegment transformation from (unsigned) buffer time to
> stream time.

In this case this is not a rounding error, it's a side effect of a) that causes
addition to occur with GST_CLOCK_TIME_NONE, effectively subtracting 1
nanosecond, and through several hops it ends up in the emitted GstSegment.

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