[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