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

[GStreamer (GNOME Bugzilla)]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #338324|none                        |needs-work
             status|                            |

--- Comment #25 from Sebastian Dröge (slomo) <slomo at coaxion.net> ---
Review of attachment 338324:
 --> (https://bugzilla.gnome.org/review?bug=754575&attachment=338324)

Scale should probably be applied_rate. That is: it needs special support by the
media, and generally in our seek events we don't distinguish between the two.

Which in conclusion means: if the client asks for scale=2 and rate=12, we might
as well provide applied_rate=1/24 and rate=1.0. Which should be considered in
the response (i.e. we should give what is actually happening!), and can be
parsed from the segment event. For example, scaletempo converts rate=X to
applied_rate=1/X.

It is the decision of the elements inside the pipeline, how to get the
effective rate from the seek event.

::: gst/rtsp-server/rtsp-client.c
@@ +1197,3 @@
+  }
+
+  /* parse the scale and speed headers, if present, and remember wheteher they

Typo: whether

@@ +1199,3 @@
+  /* parse the scale and speed headers, if present, and remember wheteher they
+   * were present in the request. by only adding scale and/or speed headers to
+   * our respons if the request contained scale and/or speed headers we lower

respons*e*

@@ +1226,3 @@
+     */
+    GST_FIXME ("how to handle the Scale-header? For now just use 1.0");
+    scale = 1.0;

Shouldn't we cause rate=scale, scale=1.0 here then? That's giving the same
media timeline to the client at least

@@ +1255,3 @@
+    *resp_scale_hdr = g_strdup_printf ("%1.1f", scale);
+  if (add_speed_hdr)
+    *resp_speed_hdr = g_strdup_printf ("%1.1f", speed);

Some more digits would be nice, maybe 1.3f?

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