GNOME Bugzilla – Bug 561406
[qtmux] Dirac stream has wrong duration and initial timestamps
Last modified: 2009-08-10 23:49:55 UTC
Assumption: schroenc's initial buffer can have dts (= OFFSET_END) < 0 [seems to be possible given the present code path that exists for this contingency, and so confirmed by test] In the above case, when processing first buffers, scaled_dts is calculated < 0, and then also scaled_duration < 0 (or "equivalently" >> 0). This is passed to lower layers, leading to a first "delta" >> 0, and therefore wrong duration overall (and timestamp).
Created attachment 122971 [details] [review] Possible patch * Initialize last_dts with initial upstream provided dts.
I modified the behavior slightly in schroedinger, however, I'm not completely happy with the added complexity: video/x-qt-part - BUFFER_OFFSET() is the "composition time" (or whatever quicktime calls it), and should start at 0 and increment at the frame rate. This means it is never negative. video/x-mp4-part - BUFFSET_OFFSET() is the DTS, which might be negative for the first few buffers. It is unclear to me why we should care about the distinction. qtdemux can easily take DTS and convert to composition time.
What's the status of this bug? This seems to be fixed in schro now and the attached patch is obsolete. Correct?
Yes.