[Bug 762910] rtspsrc: Add special support for ONVIF servers (custom headers, timestamp extraction, ...)
GStreamer (GNOME Bugzilla)
bugzilla at gnome.org
Mon Mar 7 10:15:17 UTC 2016
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.
More information about the gstreamer-bugs
mailing list