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

[GStreamer (GNOME Bugzilla)]

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

--- Comment #18 from Branko Subasic <branko.subasic at axis.com> ---
(In reply to Nikita Bobkov from comment #17)
> Review of attachment 339331 [details] [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.

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.

> @@ +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?

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