[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

--- Comment #8 from Nicola <lists at svrinformatica.it> ---
(In reply to Sebastian Dröge (slomo) from comment #7)
> (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?

maybe we can look for a=x-onvif-track in describe response, an onvif camera
should set this line only when we request a recording

however there are several use case:

1) replay a recording from the start, in this case, if no special headers are
sent, the server (camera) send the stream in real time and all is fine (but
onvif timestamps are not used) until a big gap
2) replay a recording from a start date to an end date, special headers are
required for rtsp setup and play requests
3) download a recording (what I need), special headers are needed for rtsp
setup and play requests to download to max speed (eventually also the range
headers from 2) )

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

yes, the speed is limited by the network/client so if we request to the server
to send to max speed we can sync on the clock client side, we should use tcp as
onvif specs recommends

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

there are several use cases, if we want to handle them automatically we need to
at least give to the users the ability so specify start and end date and based
on this send an appropriate range header.

My approach to allow to send custom headers (see other patch) and to extract
onvif timestamp, if someone manually plug onvifparse, seems less invasive and
more flexible, however I could be too focalized on my specific use case

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