[gstreamer-bugs] [Bug 640023] Jitterbuffer: does not put the same gst timestamp on packets with the same RTP timestamp

GStreamer (bugzilla.gnome.org) bugzilla at gnome.org
Thu Jan 20 04:19:03 PST 2011


https://bugzilla.gnome.org/show_bug.cgi?id=640023
  GStreamer | gst-plugins-good | git

Wim Taymans <wim.taymans> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |wim.taymans at gmail.com

--- Comment #3 from Wim Taymans <wim.taymans at gmail.com> 2011-01-20 12:19:01 UTC ---
Unfortunately, this makes it calculate the clock skew only on the first packet
of a fragmented frame.

Maybe it's better to feed all timestamps in the skew correction but only use a
more recent skew for the timestamps when the rtp time changes. you have to be
careful about reordered packets too, so it should probably be done on the
output side of things.

Maybe the easiest is to store the current skew in the buffer offset or
something and then on the output size apply it to the buffer timestamp.

The real problem is again in ffmpeg, it uses the timestamp difference between
consecutive packets to estimate the duration. It's difficult to do this right.. 

Also setting access-unit to TRUE on the depayloader (or using caps) should fix
this because then each buffer is a complete frame and ffmpeg will do the right
thing.

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