[Bug 753037] rtpopusdepay: timestamp handling regression

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=753037

--- Comment #9 from Nicolas Dufresne (stormer) <nicolas.dufresne at collabora.co.uk> ---
So I've been looking deeper, and in fact there is a series of issues. The one I
expose in comment 8 is a bug introduce with buffer list. We use the last TS
from the list rather then the first to create the segment.

Though, a bigger issue I found, and it has been this way for a long time, is
that rtph264depay sets timestamp base on the input, while the rtpbasedepayload
set timestamp to running-time. This bug has been around for a long time, and
never been an issues until now. Show story, from base class stand point
"depayloader: Use input segment start" is wrong, but from h264depay standpoint
it's right. Another subtle bugs is the duration is copied as is, while it fact
it should have been scaled with the rate to be coherant with the running time.
Normally, we'd calculate a end position, convert it to running time and compute
back the duration.

In fact, there is no clear reason why we waste CPU cycle converting these
timestamp to running time except that stats property sends running time (which
we could convert on demand). This property is also not thread safe, it should
obviously take the the lock before reading all those values from the private
class structure. A lot of issues in one that this bug raise up.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.