[Bug 754575] trick modes in gst-rtsp-server

[GStreamer (GNOME Bugzilla)]

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

--- Comment #19 from Nikita Bobkov <NikitaDBobkov at gmail.com> ---
(In reply to Branko Subasic from comment #18)
> (In reply to Nikita Bobkov from comment #17)
> > Review of attachment 339331 [details] [review] [review]:
> > 
> > ::: gst/rtsp-server/rtsp-client.c
> > @@ +1181,3 @@
> >  static GstRTSPStatusCode
> > +default_adjust_play_mode (GstRTSPClient * client, GstRTSPContext * ctx,
> > +    GstRTSPTimeRange * range, gdouble * scale, gdouble * speed, gdouble *
> > rate,
> > 
> > How about passing range by pointer to pointer? This would allow us to "fix"
> > range if it is missing. VLC likes to send PLAY request with Scale header but
> > without Range header.
> 
> That's a good idea I guess.
> 
> > @@ +1184,3 @@
> > +    GstSeekFlags * flags)
> > +{
> > +  /* FIXME: How to handle the Scale header?
> > 
> > According to standard we have to transcode but this usually is not an option
> > at least for me due to performance issues. For now I send all frames as they
> > are and switch to key frames only mode when the scale is high enough. VLC
> > seems to be satisfied with this approach.
> 
> Well, the Scale header is supposed to increase the viewing rate (assuming
> it's > 1) but maintain the data rate. By just sending the all data we're not
> really Scaling anything.

Well... we are scaling timestamps :-) But yes, you are right. 

> Moreover, how to decide what's a high enough Scale value to trigger the
> key-frames-only approach? By making the function virtual an implementation
> can decide what's appropriate in it's context.
> 

Yes. I like your virtual function approach. I used your code and I am doing the
work I need by overriding it. I've just shared what I had to do to make VLC
work. I understand that it is not what RFC say I should do. Sadly.

> > @@ +1202,3 @@
> > +
> > +  /* as for the speed header, just map it to rate */
> > +   *        For formats with delta units, like h264, we could perhaps drop
> > 
> > But RTP timestamps are calculated directly from running time (if this hasn't
> > changed since 1.4.5). This means RTP stream will look like it has scale
> > applied to it instead of speed except its bitrate will be multiplied by rate.
> 
> I don't quite follow here. As far as I understand the whole purpose of the
> Speed header is so the client can decide the viewing rate.
> 
> The following is from RFC2326:
> 
> "Use of this field changes the bandwidth used for data delivery. It is
>  meant for use in specific circumstances where preview of the
>  presentation at a higher or lower rate is necessary."
> 
> Isn't that what the patch does? Affects the viewing rate?

It also affects RTP timestamps which are supposed to mean presentation time.
But AFAIK speed should not affect presentation at all. Server just sends same
data but possibly in advance. In case of speed timestamps should be incremented
by speed * clock_rate per second of wall clock. In our case they are
incremented by clock_rate. This is due to running time of pipeline is not
affected by rate of segment. So we actually "scale" timestamps.
Here is an interesting link: 
http://ietf.10.n7.nabble.com/RTSP-Speed-and-Scale-overview-text-td191370.html
I guess they might be talking about RTSP 2.0. Even if so i don't think that
effect of Speed header has changed.

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