[Bug 762910] rtspsrc: Add special support for ONVIF servers (custom headers, timestamp extraction, ...)

[GStreamer (GNOME Bugzilla)]

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

Sebastian Dröge (slomo) <slomo at coaxion.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|gst-plugins-bad             |gst-plugins-good
            Summary|onvifparse: extract and     |rtspsrc: Add special
                   |apply onvif timestamp       |support for ONVIF servers
                   |                            |(custom headers, timestamp
                   |                            |extraction, ...)

--- Comment #7 from Sebastian Dröge (slomo) <slomo at coaxion.net> ---
(In reply to Nicola from comment #6)
> (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

Can we detect if there is a onvif server? Does it tell us anything in the
DESCRIBE or SETUP replies that can be used?


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

We don't require RTCP so that should be fine then :) But it also hints that we
should use the onvif time information instead of the RTCP SRs.


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

2) means the server sends data as fast as possible and not in real-time? That
might break some assumptions in various places, where we assume RTP data is
sent in real-time. But let's see that once the other parts are fixed.


In any case, I think we should detect onvif servers in rtspsrc and then do
special things for that.

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