GNOME Bugzilla – Bug 637403
qtmux do not store 1st TS when detect 1st buffer
Last modified: 2011-01-03 16:43:46 UTC
Created attachment 176539 [details] [review] Patch for updating the pad 1st TS on 1st buffer arrival. When the function gst_qt_mux_add_buffer receives the first buffer it just keep a reference and return GST_FLOW_OK without updating the 'pad->first_ts'. When the second buffer is received it will try to determine if it is an 'out-of-order' buffer, one of the steps on this process is to ask if the 'pad->first_ts' is valid, but since it haven't been updated yet it will give a false positive. This can be corrected updating the 'pad->first_ts' at the moment the we detect the first buffer.
The observation is correct, but recent commit [*] have changed matters, rendering this particular problem obsolete as side-effect. [*] commit 38c93429784d10ddd4da0dbe390616b7e9196729 Author: Mark Nauwelaerts <mark.nauwelaerts@collabora.co.uk> Date: Mon Jan 3 17:24:23 2011 +0100 qtmux: adjust nasty case timestamp tracking That is, all sorts of problems arise with re-ordered input timestamps that tend to defy automagic handling for every case, so allow for a few variations that can be tried depending on circumstances. Also try to document accordingly. Also fixes #638288. commit 460785352c0739529b17aa4ebc6558c8eb086ca1 Author: Felipe Contreras <felipe.contreras@nokia.com> Date: Thu Dec 30 21:48:41 2010 +0200 qtmux: get rid of timestamp overprotectiveness Signed-off-by: Felipe Contreras <felipe.contreras@nokia.com>