[Bug 754222] qtdemux: Only use the tfdt instead of the fragment timestamp if they don't differ too much

GStreamer (GNOME Bugzilla) bugzilla at gnome.org
Fri Aug 28 03:25:39 PDT 2015


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

Enrique Ocaña González <eocanha at igalia.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |eocanha at igalia.com

--- Comment #3 from Enrique Ocaña González <eocanha at igalia.com> ---
Sorry if this comment is a bit out of context for this particular bug and
doesn't belong here, but I think that it can open an interesting debate:

We're using qtdemux in WebKit to process data coming from Media Source
Extensions[1] appends.  At appsrc push time, we don't have any info about what
time the data we're appending belongs to. We rely on what qtdemux detects.

When our tests and use cases append data linearly from the begining, qtdemux
keeps timing info internally and generates the proper timestamps without
problems.

However, there are problems for sparse ranges. If the user seeks forward and
the upper layer (out of our control) decides to append [2:00, 2:30] right after
a former append of [0:00, 1:00], then the internal demuxer status keeps
generating PTSs in the range [1:00, 1:30]. Note that in our layer we don't
really know the time range being appended, so we can't hint appsrc in any way.

We have a patch[2] for qtdemux_parse_trun() to use decode_ts (which comes from
the TFDT atom) if it's significantly higher than the time in the last sample
(just the contrary of what you propose in your patch). This rule allows us to
blindly feed sparse ranges and have qtdemux generating the right times.

Is it wrong to rely on TFDT as much as possible? What alternatives do we have
to support sparse ranges in the appended data?


[1] https://w3c.github.io/media-source/
[2] http://pastebin.com/612D3kyU

-- 
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