From: GStreamer (bugzilla.gnome.org) <bug...@bu...> - 2009-07-18 08:37:05
|
If you have any questions why you received this email, please see the text at the end of this email. Replies to this email are NOT read, please see the text at the end of this email. You can add comments to this bug at: http://bugzilla.gnome.org/show_bug.cgi?id=588915 GStreamer | gst-plugins-base | Ver: git Kipp changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #138644|0 |1 is obsolete| | ------- Comment #3 from Kipp 2009-07-18 08:36 UTC ------- Created an attachment (id=138655) --> (http://bugzilla.gnome.org/attachment.cgi?id=138655&action=view) fall back to using timestamp if input offset is invalid This version tries to initialize the output offset counter first by scaling the input buffer's offset, falling back to scaling the input buffer's timestamp if the offset is invalid, falling back to initializing the offset counter to 0 if the timestamp is invalid. Since the audiorate element is available to correct streams with poor timestamp <--> offset relationships, I don't think this element needs to be too fancy with respect to attempting to correct the timestamps and offsets of an input stream. However, one thing I have just noticed is that the output timestamps are computed as a cumulative sum of the output durations. That algorithm is prone to acumulating round-off errors, it would be better to compute the timestamps by scaling the output offset counter. But I think that is probably a separate bug-report. -- See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received this email, why you can't respond via email, how to stop receiving emails (or reduce the number you receive), and how to contact someone if you are having problems with the system. You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=588915. |