[Bug 762910] onvifparse: extract and apply onvif timestamp

[GStreamer (GNOME Bugzilla)]

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

--- Comment #6 from Nicola <lists at svrinformatica.it> ---
(In reply to Sebastian Dröge (slomo) from comment #5)
> Well, we should find a solution for autoplugging onvifparse and making these
> streams work out of the box :)

seems not easy, probably non standard headers for rtspsrc requests are needed,
see below

> 
> So basically this here provides the same guarantees as the NTP time in RTCP
> packets. Maybe it can be used in similar ways inside rtpbin then?
> 

yes, other relevant notes from onvif replay specs:

- Clients should use a TCP-based transport for replay, in order to achieve
reliable delivery of media packets
- The server MAY elect not to send RTCP packets during replay. In typical usage
RTCP packets are not required, because usually a reliable transport will be
used, and because absolute time information is sent within the stream, making
the timing information in RTCP sender reports redundant.


> 
> How is it solving playback of these streams? You say they have a huge
> timestamp gap, what exactly does that mean? A timestamp gap in the RTP
> timestamps (and not a wraparound)? There's code for handling that in
> rtpbin/rtpsource somewhere
> 
> The on_timeout lines you pasted there sound more like a problem with the
> server not responding to RTCP anymore. But would have to be tracked down
> properly by reading the logs


there are 2 issue here:

1) you have to set "Rate-Control: no" header when rtspsrc send play request. If
this header is omitted the camera send the recording syncronized on timestamp
and so when the first recording end it will not send anything until the gap to
the next start is filled and so rtspsrc will exit for timeout if this gap is
big enough
2) if you set "Rate-Control: no" the camera send the recording to the max speed
and gstreamer can sync on the clock, however this seems problematic too (at
least over tcp), after the huge gap this is what happen:

Pushing buffer 6005, dts 99:99:99.999999999, pts 0:04:08.745810372
Pushing buffer 6006, dts 99:99:99.999999999, pts 0:00:00.087810372
....
Pushing buffer 6213, dts 99:99:99.999999999, pts 0:00:00.087810372

full logs here:

http://195.250.34.59/temp/log.txt.bz2 

> 
> 
> In any case, I think there's another bug here independent of your patch and
> we should generally handle these streams somehow automatically

let me know what you think is needed for upstream inclusion, however I'm on
deadline and my approach seems fine so I don't think I'll have enough time to
dig into rtpbin, at least now

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