[Bug 778426] qtdemux: Properly handle edit list in push mode
GStreamer (GNOME Bugzilla)
bugzilla at gnome.org
Sat Mar 31 12:08:12 UTC 2018
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.
More information about the gstreamer-bugs
mailing list