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

["GStreamer" (GNOME Bugzilla)]

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

Bug ID: 754575
Summary: trick modes in gst-rtsp-server
Classification: Platform
Product: GStreamer
Version: git master
OS: Linux
Status: NEW
Severity: enhancement
Priority: Normal
Component: gst-rtsp-server
Assignee: gstreamer-***@lists.freedesktop.org
Reporter: ***@axis.com
QA Contact: gstreamer-***@lists.freedesktop.org
GNOME version: ---

I am creating this ticket to initiate a discussion about supporting trick modes
in the server.

The use case I am trying to address is an Onvif client specifying the Frames
header field in PLAY:

Frames: [intra|all]

which is used for limiting transfer bandwidth when playing .mkv recorded files.

Don't know if any of you has already thought about it, but what do you think
about exposing methods for setting/getting trick modes in GstRTSPMedia like:

void gst_rtsp_media_set_trick_modes (GstRTSPMedia * media,
GstRTSPTrickModeFlags flags);
GstRTSPMediaTrickModeFlags gst_rtsp_media_get_trick_modes (GstRTSPMEdia *
media);

And then setting GstSeekFlags appropriately when doing the seek from
gst_rtsp_media_seek ()?

["GStreamer" (GNOME Bugzilla)]

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

Branko Subasic <***@axis.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@axis.com

--- Comment #1 from Branko Subasic <***@axis.com> ---
A slightly different approach would be to modify gst_rtsp_media_seek() to take
two more arguments, the seek flags and the rate, which allows for play modes
other than the currently available. I addition, if we change GstRTSPClient to
include one more virtual function, setup_play_mode(), we allow the
implementations to setup the seek in a non-default way as it sees fit.

["GStreamer" (GNOME Bugzilla)]

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

--- Comment #2 from Branko Subasic <***@axis.com> ---
Created attachment 320604
--> https://bugzilla.gnome.org/attachment.cgi?id=320604&action=edit
Makes it possible to tell the rtsp-media how to do the seek

["GStreamer" (GNOME Bugzilla)]

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

--- Comment #3 from Branko Subasic <***@axis.com> ---
Created attachment 320605
--> https://bugzilla.gnome.org/attachment.cgi?id=320605&action=edit
Let implementations decide how to do the seek

["GStreamer" (GNOME Bugzilla)]

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

Nicolas Dufresne (stormer) <***@collabora.co.uk> changed:

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

--- Comment #4 from Nicolas Dufresne (stormer) <***@collabora.co.uk> ---
Review of attachment 320604:
--> (https://bugzilla.gnome.org/review?bug=754575&attachment=320604)

::: gst/rtsp-server/rtsp-media.h
@@ +257,3 @@
+ GstRTSPTimeRange
*range,
+ GstSeekFlags flags,
+ gdouble rate);

API Break. Don't do that. Create a new one instead.

["GStreamer" (GNOME Bugzilla)]

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

--- Comment #5 from Branko Subasic <***@axis.com> ---
You are right, I didn't think about that. Uploading a new version of the
patches. Added a new function gst_rtsp_media_seek_full() which does all the
work, and is wrapped by gst_rtsp_media_seek().

["GStreamer" (GNOME Bugzilla)]

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

Branko Subasic <***@axis.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
Attachment #320604|needs-work |none
status| |
Attachment #320604|0 |1
is obsolete| |

--- Comment #6 from Branko Subasic <***@axis.com> ---
Created attachment 320670
--> https://bugzilla.gnome.org/attachment.cgi?id=320670&action=edit
Makes it possible to tell the rtsp-media how to do the seek

["GStreamer" (GNOME Bugzilla)]

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

Branko Subasic <***@axis.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
Attachment #320605|0 |1
is obsolete| |

--- Comment #7 from Branko Subasic <***@axis.com> ---
Created attachment 320671
--> https://bugzilla.gnome.org/attachment.cgi?id=320671&action=edit
Let implementations decide how to do the seek

["GStreamer" (GNOME Bugzilla)]

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

--- Comment #8 from Branko Subasic <***@axis.com> ---
Found a bug in the media patch. Will upload a new patch in a short while.

["GStreamer" (GNOME Bugzilla)]

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

Branko Subasic <***@axis.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
Attachment #320670|0 |1
is obsolete| |

--- Comment #9 from Branko Subasic <***@axis.com> ---
Created attachment 320889
--> https://bugzilla.gnome.org/attachment.cgi?id=320889&action=edit
Makes it possible to tell the rtsp-media how to do the seek

["GStreamer" (GNOME Bugzilla)]

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

Branko Subasic <***@axis.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
Attachment #320671|0 |1
is obsolete| |

--- Comment #10 from Branko Subasic <***@axis.com> ---
Created attachment 320890
--> https://bugzilla.gnome.org/attachment.cgi?id=320890&action=edit
Let implementations decide how to do the seek

["GStreamer" (GNOME Bugzilla)]

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

Branko Subasic <***@axis.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
Attachment #320889|0 |1
is obsolete| |

--- Comment #11 from Branko Subasic <***@axis.com> ---
Created attachment 322752
--> https://bugzilla.gnome.org/attachment.cgi?id=322752&action=edit
Makes it possible to tell the rtsp-media how to do the seek

["GStreamer" (GNOME Bugzilla)]

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

--- Comment #12 from Branko Subasic <***@axis.com> ---
Sorry for spamming like this, but I realized that I somehow managed to screw up
the previous version of this patch. But now it should be OK.

["GStreamer" (GNOME Bugzilla)]

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

Branko Subasic <***@axis.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
Attachment #322752|0 |1
is obsolete| |

--- Comment #13 from Branko Subasic <***@axis.com> ---
Created attachment 338323
--> https://bugzilla.gnome.org/attachment.cgi?id=338323&action=edit
Allow trick mode playback by

["GStreamer" (GNOME Bugzilla)]

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

--- Comment #14 from Branko Subasic <***@axis.com> ---
Created attachment 338324
--> https://bugzilla.gnome.org/attachment.cgi?id=338324&action=edit
Add support for Scale and Speed headers

["GStreamer" (GNOME Bugzilla)]

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

Branko Subasic <***@axis.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
Attachment #320890|0 |1
is obsolete| |

--- Comment #15 from Branko Subasic <***@axis.com> ---
Created attachment 338325
--> https://bugzilla.gnome.org/attachment.cgi?id=338325&action=edit
Allow sub classes to adjust the playback mode

["GStreamer" (GNOME Bugzilla)]

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

Branko Subasic <***@axis.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
Attachment #338325|0 |1
is obsolete| |

--- Comment #16 from Branko Subasic <***@axis.com> ---
Created attachment 339331
--> https://bugzilla.gnome.org/attachment.cgi?id=339331&action=edit
Allow sub classes to adjust the playback mode

["GStreamer" (GNOME Bugzilla)]

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

--- Comment #17 from Nikita Bobkov <***@gmail.com> ---
Review of attachment 339331:
--> (https://bugzilla.gnome.org/review?bug=754575&attachment=339331)

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

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

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

["GStreamer" (GNOME Bugzilla)]

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

Nikita Bobkov <***@gmail.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@gmail.com

["GStreamer" (GNOME Bugzilla)]

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

--- Comment #18 from Branko Subasic <***@axis.com> ---
(In reply to Nikita Bobkov from comment #17)

Post by "GStreamer" (GNOME Bugzilla)
::: 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.

Post by "GStreamer" (GNOME Bugzilla)
@@ +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

Post by "GStreamer" (GNOME Bugzilla)
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.

Post by "GStreamer" (GNOME Bugzilla)
@@ +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?

["GStreamer" (GNOME Bugzilla)]

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

--- Comment #19 from Nikita Bobkov <***@gmail.com> ---
(In reply to Branko Subasic from comment #18)

Post by "GStreamer" (GNOME Bugzilla)
(In reply to Nikita Bobkov from comment #17)

Post by "GStreamer" (GNOME Bugzilla)
::: 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.

Post by "GStreamer" (GNOME Bugzilla)
@@ +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.

Post by "GStreamer" (GNOME Bugzilla)
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.

Post by "GStreamer" (GNOME Bugzilla)

Post by "GStreamer" (GNOME Bugzilla)
@@ +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.
"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.

["GStreamer" (GNOME Bugzilla)]

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

--- Comment #20 from Nikita Bobkov <***@gmail.com> ---
Created attachment 341487
--> https://bugzilla.gnome.org/attachment.cgi?id=341487&action=edit
Reverse playback support

With this patch VLC can even play formats without predicted frames (like MJPEG)
in reverse from our server. For other formats (like H264) it shows only key
frames. RTSP server sends frames of GOP in forward order which seems to be
conforming to ONVIF streaming specification. Does anyone know RTSP/ONVIF client
which can play such streams?

["GStreamer" (GNOME Bugzilla)]

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

Kseniya Vasilchuk <***@gmail.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@gmail.com

["GStreamer" (GNOME Bugzilla)]

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

--- Comment #21 from Nicolas Dufresne (stormer) <***@ndufresne.ca> ---
Review of attachment 341487:
--> (https://bugzilla.gnome.org/review?bug=754575&attachment=341487)

::: gst/rtsp-server/rtsp-stream.c
@@ +2758,3 @@
if (format != GST_FORMAT_TIME)
*stop = -1;
+ else

There is an indentation issue here.

["GStreamer" (GNOME Bugzilla)]

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

Nikita Bobkov <***@gmail.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
Attachment #341487|0 |1
is obsolete| |

--- Comment #22 from Nikita Bobkov <***@gmail.com> ---
Created attachment 341496
--> https://bugzilla.gnome.org/attachment.cgi?id=341496&action=edit
Reverse playback support

["GStreamer" (GNOME Bugzilla)]

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

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

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@coaxion.net

--- Comment #23 from Sebastian Dröge (slomo) <***@coaxion.net> ---
From my understanding the difference between Scale and Speed here is the same
as applied_rate and rate in GStreamer. In one case, you have some rate already
applied to the stream itself (that is, timestamps are going in real-time but
e.g. a difference in timestamps of 1s represents 2s difference in the media
timeline), in the other case you're just sending the data faster/slower.

["GStreamer" (GNOME Bugzilla)]

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

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

What |Removed |Added
----------------------------------------------------------------------------
Attachment #338323|none |reviewed
status| |

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

Generally looks good to me

::: gst/rtsp-server/rtsp-media.c
@@ +2191,1 @@
+ if (range != NULL) {

Maybe mention that we now allow range!=NULL for seeks to the same position that
just change e.g. the rate. In the commit message and a comment here

@@ +2214,3 @@
stop_type = GST_SEEK_TYPE_SET;

+ trick_mode = flags != 0 || rate != 1.0;

Why is it trick_mode if flags != 0? GST_SEEK_FLAG_ACCURATE or
GST_SEEK_FLAG_FLUSH don't seem like trick modes

You probably also want to ensure that unsupported flags return in an error
here.

["GStreamer" (GNOME Bugzilla)]

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

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

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

--- Comment #25 from Sebastian Dröge (slomo) <***@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?

["GStreamer" (GNOME Bugzilla)]

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

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

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

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

::: gst/rtsp-server/rtsp-client.c
@@ +1202,3 @@
+
+ /* as for the speed header, just map it to rate */
+ *rate = *speed;

RTP timestamps are running_time, yes. Meaning, e.g.: if rate=2, applied_rate=1,
then timestamps are as before but you get the data twice as fast as (original)
real-time. If rate=1, applied_rate=2, then timestamps are all divided by 2 but
you get them in real-time.

That's exactly how the distinction between Speed and Scale could be achieved
here. Just that it's not the decision of the client in the end, but of the
server. Unless we extend the seek events by an applied_rate field.

::: gst/rtsp-server/rtsp-client.h
@@ +89,3 @@
* be sent for a tunneled connection. The response can be modified. Since
1.4
+ * @adjust_play_mode: called when a PLAY request is received to allow
+ * implementations to modify scale, speed, or seek flags for the seek. Since
1.12

Document which of the arguments are in, which are out, and which are both
("ref" in C# speak)

["GStreamer" (GNOME Bugzilla)]

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

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

::: gst/rtsp-server/rtsp-client.c
@@ +1184,3 @@
+ GstSeekFlags * flags)
+{
+ /* FIXME: How to handle the Scale header?

That, and going with KEYUNIT trick mode depending on the situation definitely
makes sense.

["GStreamer" (GNOME Bugzilla)]

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

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

What |Removed |Added
----------------------------------------------------------------------------
Attachment #341496|none |reviewed
status| |

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

Looks good, but please provide a clearer commit message.

Also it doesn't confuse clients if we now send things gop-by-gop backwards, and
each gop forwards?

["GStreamer" (GNOME Bugzilla)]

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

Nikita Bobkov <***@gmail.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
Attachment #341496|reviewed |none
status| |
Attachment #341496|0 |1
is obsolete| |

--- Comment #29 from Nikita Bobkov <***@gmail.com> ---
Created attachment 341572
--> https://bugzilla.gnome.org/attachment.cgi?id=341572&action=edit
Reverse playback support

I hope it is more clear now...

["GStreamer" (GNOME Bugzilla)]

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

--- Comment #30 from Nikita Bobkov <***@gmail.com> ---
(In reply to Sebastian Dröge (slomo) from comment #28)

Post by "GStreamer" (GNOME Bugzilla)
Looks good, but please provide a clearer commit message.
Also it doesn't confuse clients if we now send things gop-by-gop backwards,
and each gop forwards?

The only RTSP client I found to be able to initiate reverse playback is VLC. As
I said it does not really like this kind of stream:

(In reply to Nikita Bobkov from comment #20)

Post by "GStreamer" (GNOME Bugzilla)
Created attachment 341487 [details] [review]
Reverse playback support
With this patch VLC can even play formats without predicted frames (like
MJPEG) in reverse from our server. For other formats (like H264) it shows
only key frames. RTSP server sends frames of GOP in forward order which
seems to be conforming to ONVIF streaming specification. Does anyone know
RTSP/ONVIF client which can play such streams?

But I am not sure that VLC is good reference here considering how it splits
PLAY request into two parts: one with Range header and other with Scale.

["GStreamer" (GNOME Bugzilla)]

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

Rickard Hammar <***@gmail.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@gmail.com

["GStreamer" (GNOME Bugzilla)]

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

Branko Subasic <***@axis.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
Attachment #338323|reviewed |none
status| |
Attachment #338323|0 |1
is obsolete| |

--- Comment #31 from Branko Subasic <***@axis.com> ---
Created attachment 373993
--> https://bugzilla.gnome.org/attachment.cgi?id=373993&action=edit
Allow specifying rate when seeking

["GStreamer" (GNOME Bugzilla)]

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

Branko Subasic <***@axis.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
Attachment #339331|needs-work |none
status| |
Attachment #339331|0 |1
is obsolete| |

--- Comment #32 from Branko Subasic <***@axis.com> ---
Created attachment 373994
--> https://bugzilla.gnome.org/attachment.cgi?id=373994&action=edit
Allow sub classes to adjust the seek

["GStreamer" (GNOME Bugzilla)]

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

Branko Subasic <***@axis.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
Attachment #338324|needs-work |none
status| |
Attachment #338324|0 |1
is obsolete| |

--- Comment #33 from Branko Subasic <***@axis.com> ---
Created attachment 373995
--> https://bugzilla.gnome.org/attachment.cgi?id=373995&action=edit
Add support for Scale and Speed headers

["GStreamer" (GNOME Bugzilla)]

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

--- Comment #34 from Branko Subasic <***@axis.com> ---
I have now redone the patches according to comments above.
I have also restructured the patches slightly. The first adds the possibility
to specify a rate when seeking the media, the second patch makes it possible
for sub-classes to tweak the seek, and the third adds support for the Scale and
Speed headers.

["GStreamer" (GNOME Bugzilla)]

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

Mathieu Duponchelle <***@gmail.com> changed:

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

--- Comment #35 from Mathieu Duponchelle <***@gmail.com> ---
Review of attachment 373995:
--> (https://bugzilla.gnome.org/review?bug=754575&attachment=373995)

As far as I understand, these patches will not lead to a compliant behaviour
with respect to the Scale header, and I don't think the seeking mechanism in
GStreamer will let us express a combination of ABS(Scale) != 1.0 and Speed !=
1.0 appropriately. ABS(Scale) != 1.0 is expected to lead to the same data rate
as ABS(scale) == 1.0 , which roughly translates to seeking with the TRICK_MODE
flag and rate == Scale .

This means we cannot simply use a rate == Scale * Speed , and have to either
extend the seeking mechanism, or more pragmatically enforce the constraint that
when Speed != 1.0 , the only valid values for Scale are -1.0 or 1.0 .

["GStreamer" (GNOME Bugzilla)]

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

--- Comment #36 from Branko Subasic <***@axis.com> ---
(In reply to Mathieu Duponchelle from comment #35)

Post by "GStreamer" (GNOME Bugzilla)
As far as I understand, these patches will not lead to a compliant behaviour
with respect to the Scale header,

Well, I'm not sure what a compliant behaviour actually is.
The RFC says that the implementation of Scale is implementation dependent, and
that the response must contain the actual scale chosen. Similarly
implementation of Speed is "contingent on the server's ability and desire to
serve the media stream at the given speed".

But I agree that it does not behave as the RFC intended.

Post by "GStreamer" (GNOME Bugzilla)
and I don't think the seeking mechanism in
GStreamer will let us express a combination of ABS(Scale) != 1.0 and Speed
!= 1.0 appropriately. ABS(Scale) != 1.0 is expected to lead to the same data
rate as ABS(scale) == 1.0 , which roughly translates to seeking with the
TRICK_MODE flag and rate == Scale .

You are absolutely right, GStreamer's seeking mechanism does not support the
intended behaviour of the Scale header.

Post by "GStreamer" (GNOME Bugzilla)
This means we cannot simply use a rate == Scale * Speed , and have to either
extend the seeking mechanism, or more pragmatically enforce the constraint
that when Speed != 1.0 , the only valid values for Scale are -1.0 or 1.0 .

A (long) while ago I discussed this on the irc with Sebastian Dröge. His point
of view was that we let the media decide. This is the approach that we agreed
on.

I am of course willing to change it, but I'd like to hear Sebastian's opinion
as well.

["GStreamer" (GNOME Bugzilla)]

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

GStreamer system administrator <***@gstreamer.net> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |OBSOLETE

--- Comment #37 from GStreamer system administrator <***@gstreamer.net> ---
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been
closed from further activity.

You can subscribe and participate further through the new bug through this link
to our GitLab instance:
https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/issues/14.