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

GStreamer (GNOME Bugzilla) bugzilla at gnome.org
Wed Oct 31 14:46:46 UTC 2018


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

--- Comment #36 from Branko Subasic <branko.subasic at axis.com> ---
(In reply to Mathieu Duponchelle from comment #35)
> Review of attachment 373995 [details] [review]:
> 
> 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.

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

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

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