GNOME Bugzilla – Bug 724611
RTSP server omits frames when client supplies a range in the PLAY request
Last modified: 2014-02-25 22:29:09 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.
Created attachment 269512 [details] [review] Make sure streaming starts at with at requested position with decodeable frames
Would it also be ok to not flush when the start is not updated?
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
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