[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

--- Comment #7 from Mark Nauwelaerts <mnauw at users.sourceforge.net> 2012-07-23 14:17:32 UTC ---
(In reply to comment #6)
> (In reply to comment #5)
> > 
> > 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).
> 
> The current trend (see HLSdemux) for dealing with fragmented (adaptive) content
> is to create a new decoding chain every time a new bitrate is selected. For
> DASH, this means that every time a new representation is selected, a new isomp4
> demux is instantiated, with a stream composed of a moov box provided by the
> DASH initialization segment, and followed by several consecutive moof boxes
> starting at a specific offset (typically _not_ zero).
> 
> Without parsing the tfdt box, the qtdemux will indeed start ts and segment as
> zero, and the playback will not be blocked. However, and it is maybe a bug, the
> downstream chain will lose the knowledge of the current playback position.     

Note that position tracking is done by the 'time/position' member in a segment
(event), so rather than a segment (S, NONE, S) and buffer times starting at S,
it is also possible (and maybe easier/cleaner) to use (0, NONE, S) and buffer
times starting at 0.

> 
> > 
> > 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.
> 
> Would you mean fixing the segment right after the transition to
> QTDEMUX_STATE_MOVIE and before actually sending it ?

(indeed) Somewhere around when _chain has the buffer timestamp at hand (and if
it is the one of the first buffer needing a newsegment before sending the
buffer).

However, in combination with above remark it should suffice to have atom
parsing dump the tfdt decode/position in some state variable, which is then
used as the position parameter for the (initial) newsegment event (created in
the _STATE_HEADER handling).

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