After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 724611 - RTSP server omits frames when client supplies a range in the PLAY request
RTSP server omits frames when client supplies a range in the PLAY request
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-rtsp-server
git master
Other Linux
: Normal normal
: 1.2.3
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2014-02-18 08:47 UTC by Branko Subasic
Modified: 2014-02-25 22:29 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Make sure streaming starts at with at requested position with decodeable frames (2.56 KB, patch)
2014-02-18 08:50 UTC, Branko Subasic
none Details | Review

Description Branko Subasic 2014-02-18 08:47:56 UTC
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.
Comment 1 Branko Subasic 2014-02-18 08:50:19 UTC
Created attachment 269512 [details] [review]
Make sure streaming starts at with at requested position with decodeable frames
Comment 2 Wim Taymans 2014-02-18 15:30:35 UTC
Would it also be ok to not flush when the start is not updated?
Comment 3 Wim Taymans 2014-02-18 15:41:19 UTC
commit f67fc23aab59f28796bebf130504ff46ccb97b0a
Author: Wim Taymans <wtaymans@redhat.com>
Date:   Tue Feb 18 16:38:39 2014 +0100

    media: only flush when setting a new start position
    
    Only flush the pipeline when we change the start position with
    a seek.
    
    See https://bugzilla.gnome.org/show_bug.cgi?id=724611
Comment 4 Wim Taymans 2014-02-18 16:00:38 UTC
commit 7ed2a6ef98d75085c47053c5d4bd7ae99c44d84d
Author: Branko Subasic <branko@axis.com>
Date:   Tue Feb 18 09:44:34 2014 +0100

    rtsp-media: don't loose frames handling new PLAY request
    
    If client supplied a range check if the range specifies the start point.
    If not, then do an accurate seek to the current position. If a start
    point was specified do do a key unit seek to make sure the streaming
    starts with decodeable frames.
    
    Fixes https://bugzilla.gnome.org/show_bug.cgi?id=724611