[Bug 754230] qtdemux: support sparse time ranges in qtdemux without needing a seek for MSE

[GStreamer (GNOME Bugzilla)]

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

--- Comment #45 from Enrique Ocaña González <eocanha at igalia.com> ---
(In reply to Jan Schmidt from comment #42)
> Created attachment 343081 [details] [review]
> qtdemux: Don't reset output timestamps when no tfdt
> 
> If a fragmented stream doesn't have a tfdt, don't
> reset the output timestamps at each fragment boundary
> by erroneously using the default value of 0. Introduced
> by commit 69fc48

This patch caused a regression on our use case (YouTube TV MSE Conformance
Tests 2016, test 40. AppendOutOfOrder).

It's an audio stream whose data is appended out of order (as per the test) in
these batches (ranges are in seconds): [10, 20] [0, 10] [30, 40] [20, 30]. All
the fragments have TFDT atoms, but the new condition added in your patch is
misinterpreting a legitimate "0" value from a TFDT atom with "no TFDT atom at
all".

I've thought about two possible solutions:

A) Have an extra boolean parameter to qtdemux_parse_trun() hinting if the
tfdt_node has been found in qtdemux_parse_moof(). Use that info in the
condition you added, instead of checking decode_ts != 0. I've coded this one
locally and it works fine.

B) Initialize decode_time to GST_CLOCK_TIME_NONE in qtdemux_parse_moof() and
add a couple of extra cases in qtdemux_parse_trun() to use 0 when
GST_CLOCK_TIME_NONE is passed. Except in the decode_ts != 0 condition, of
course, which now would be decode_ts != GST_CLOCK_TIME_NONE.

Which one do you prefer me to submit as a patch?

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