[Bug 788777] rtpjitterbuffer/h264parse timestamp issue (regression)

[GStreamer (GNOME Bugzilla)]

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

--- Comment #9 from Nicola <lists at svrinformatica.it> ---
(In reply to Håvard Graff (hgr) from comment #8)
> Maybe we even could use the arrival time in the jitterbuffer as "dts" when
> dts is -1?
> 
> @Nicola: you feel like getting down and dirty with the jitterbuffer-tests? A
> quick scan reveals that we indeed have no tests that pass in -1
> (GST_CLOCK_TIME_NONE) as dts, so you could write a simple test that:
> 
> 1. Pushes some buffers with dts set to GST_CLOCK_TIME_NONE
> (generate_test_buffer_full)
> 2. Increments the time on the clock (with, say, 20ms), for each buffer
> pushed, simulating that the buffers are arriving at appropriate times.
> 3. Verifies that the output pts on the buffers are indeed incrementing
> (which they might not be now)

Sorry for the delay, I'll try to write a test case, probably I can find some
spare time the next week, but I don't think will be easy, the problem does not
happen for each buffer but happens randomically (probably when the camera burst
data), 10-15 buffers are sended with the same timestamp and after that the
stream works normally for 10-15 minutes and so on

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