[Bug 724611] New: RTSP server omits frames when client supplies a range in the PLAY request
GStreamer (bugzilla.gnome.org)
bugzilla at gnome.org
Tue Feb 18 00:27:40 PST 2014
https://bugzilla.gnome.org/show_bug.cgi?id=724611
GStreamer | gst-rtsp-server | git
Summary: RTSP server omits frames when client supplies a range
in the PLAY request
Classification: Platform
Product: GStreamer
Version: git
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: Normal
Component: gst-rtsp-server
AssignedTo: gstreamer-bugs at lists.freedesktop.org
ReportedBy: branko.subasic at axis.com
QAContact: gstreamer-bugs at lists.freedesktop.org
GNOME version: ---
When a client issues a PLAY request with a Range-header that doesn't specify a
start (e.g. npt=-1234) buffers will be dropped when the seek is done, because a
flushing seek is issued.
I also think that the server should always do a "complete seek" i.e. a seek to
a key unit if the client has requested an actual start point in the
Range-header. Else the server may end up sending a sequence of delta units in
the beginning. These will not be decodeable by the client.
For example, a client starts has playing a recording. After a while it sends a
PAUSE. Then he sends a new PLAY request with a range. The range start happens
to match the current position, but the client does not know that, so it expects
the streaming
So I think that the server should check if the received range omits the start,
and, if so, it should do an accurate seek to the current position. And if a
start point was specified it should do a key unit seek.
I have attached a patch with a possible solution.
--
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- 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