[Bug 677535] isomp4/qtdemux: Add support for MPEG DASH tfdt box

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=677535
  GStreamer | gst-plugins-good | 0.10.31

Mark Nauwelaerts <mnauw> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mnauw at users.sourceforge.net

--- Comment #5 from Mark Nauwelaerts <mnauw at users.sourceforge.net> 2012-07-04 12:50:39 UTC ---
(In reply to comment #4)
> Created an attachment (id=217170)
 View: https://bugzilla.gnome.org/attachment.cgi?id=217170
 Review: https://bugzilla.gnome.org/review?bug=677535&attachment=217170

> Updated-patch-without-irrelevant-modifications
> 
> Here is the updated patch (without the two irrelevant changes)

Looks like the decode time is only used at the very start of the stream (which
could make sense since it should be sum of the previous durations according to
spec otherwise), though one would expect the initial one to be 0 anyway unless
the file in question is a partial one of some sort.

However, there is also a // style comment, and more importantly, the lower
level parsing code should not be fiddling with segments, which are quite
intricate in qtdemux (in view of possible edit lists etc).  And this segment is
one only used in push mode, and is a global one that is being adjusted on
stream specific values.  Also, adjusting the segment that way basically mutes
the 'decode time' effect altogether; generally it makes no real difference to
send buffers with ts starting at 0 (and a segment as well) or sending buffers
with ts starting at decode_time (and a segment as well).

All in all, makes it feel this patch has some very specific (push-based)
setting/context/use-case in mind above and beyond merely support for tfdt in
qtdemux.  If so, then e.g. adjusting the push-based segment elsewhere (e.g. in
chain) based on the first buffer's timestamp or so might be a better approach.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.