[Bug 778426] qtdemux: Properly handle edit list in push mode

[GStreamer (GNOME Bugzilla)]

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

--- Comment #20 from Seungha Yang <pudding8757 at gmail.com> ---
Sorry for late response Thiago :(

I fixed zero-duration edit list issue. Previously, the reported file
http://yt-dash-mse-test.commondatastorage.googleapis.com/unit-tests/media/car-20120827-86.mp4
was not playable in pull mode regardless of my patch, since we've not handled
zero-duration edit list as Thiago said in bug #793058.

(In reply to Alicia Boya García from comment #15)
> Review of attachment 345400 [details] [review]:
> 
> r+
> 
> ::: gst/isomp4/qtdemux.c
> @@ +6431,3 @@
>              demux->got_moov = TRUE;
> +            if (demux->fragmented) {
> +              /* fragmented streams headers shouldn't contain edts atoms */
> 
> Fragmented streams can (and often should) contain edts atoms. Nevertheless,
> that is better changed in a different patch, after edts.duration=0 support
> is added, which is often used in fragmented files.

Agree :) Fragmented mp4 can have it.

> @@ +6434,3 @@
> +              gst_qtdemux_check_send_pending_segment (demux);
> +            } else {
> +              gst_event_replace (&demux->pending_newsegment, NULL);
> 
> This line makes me wonder... Why are we setting demux->pending_newsegment in
> the first place?
> 
> demux->pending_newsegment is loaded with the movie (unedited) playback
> range, which should never be emitted by the srcpads. Instead, the requested
> movie position should be mapped to an edit, like the following line does.
> 
> (This is a reflection about qtdemux, not a problem with this particular
> patch.)

I guess it could be related dashdemux use case. Is there any reference for
relation between edit list and mpd timeline? I don't mean that code is optimal
though :)

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