[Bug 701385] Videomixer does incorrect timestamp calculations in certain cases, which leads to dropping buffers that should be kept.
GStreamer (bugzilla.gnome.org)
bugzilla at gnome.org
Fri Jun 7 04:50:50 PDT 2013
https://bugzilla.gnome.org/show_bug.cgi?id=701385
GStreamer | gst-plugins-good | git
Sebastian Dröge <slomo> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #245838|none |needs-work
status| |
--- Comment #4 from Sebastian Dröge <slomo at circular-chaos.org> 2013-06-07 11:50:44 UTC ---
Review of attachment 245838:
--> (https://bugzilla.gnome.org/review?bug=701385&attachment=245838)
I don't think this is correct. ts_offset is used in
gst_videomixer2_src_setcaps() to rebase timestamps if the output framerate
changes during playback.
As such ts_offset has to be taken into account in the segment.position as well
as in the output timestamps.
There might be bugs related to that though that might need to be fixed.
ts_offset is supposed to be the output running time when the last time the
output framerate was set (i.e. ts_offset + nframes is always the current output
timestamp)
::: gst/videomixer/videomixer2.c
@@ +929,3 @@
}
+ timestamp += mix->ts_offset;
Why?
@@ +1001,3 @@
+ if (mix->segment.position == -1) {
+ output_start_time = 0 * GST_SECOND;
Why? The first timestamp after a seek should be segment.start
@@ +1406,3 @@
stop_type, stop, NULL);
mix->segment.position = -1;
+ mix->ts_offset = mix->segment.start;
This could indeed make sense but is conflicting with the setting of ts_offset
to position - start in update_src_caps(). That would need to be changed there
to just setting it to position. These two changes I think make the usage of
ts_offset sane again.
@@ +1744,2 @@
mix->segment.position = -1;
+ mix->ts_offset = mix->segment.start;
Here I think all the output status resetting should be removed, i.e.
segment.position, nframes and ts_offset
--
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.
More information about the gstreamer-bugs
mailing list