Rtsp server negative rates implementation

[Muzzu Daniela]

I would like to try to implement a kind of reverse playback from gst-rtsp server, starting first with matroska files with mpeg4 video (for which reverse playback from file source already works fine).

 

I’m using a slightly modified version of test-mkv.exe as rtsp server to stream that kind of files (the pipeline is:

filesrc ! matroskademux ! queue ! mpeg4vparse (needed?) ! rtpmp4vpay).

 

Rtsp-server has already been modified to handle negative rates and perform a seek in reverse direction, so that server-side filesrc element starts reading file chunks in reverse order. The client receives some packets but it seems to me they are discarded since buffering level stays to 0.

 

Now some questions on which is the best way to proceed (not necessarily a “standard” way, but possibly the less complicated one):

 

1.      What shall be the play response from server to a negative scale request (e.g. -1.0 with range 10-0)? Shall the server notify the actual negative rate and range in use, so that the client pipeline is aware of that, or shall reply with e.g. 1.0 speed and 0-10 range as if the playback was in forward order?

In the first case, it should mean the client pipeline has to finish some frame / timestamp reordering , while in the second case i guess the server has completed all the job and the client pipeline processes frames just as they were in normal play order.

 

2.      In both cases, which are the pipeline elements that shall be modified in order to implement this feature? I guess that, since the client is able to reverse play from file, most elements are OK (filesrc, matroskademux, decodebin, videosink). Maybe there is something to do in rtp pay/depay elements, can you give me an idea?

 

Thanks in advance,

Daniela

 

 

 

_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Muzzu Daniela]

Hi everybody,

 

I’m still going on in implementing reverse playback from gst-rtsp server. After further investigation, one of the main issues I see is that DISCONT buffer flag set by matroska demuxer in the server (when demuxing chunks in reverse order) is lost in basertppayload before sending rtp content. What it happens in the client is that ffmpeg decoder queues all decoded chunks together since it cannot separate them by means of the discont flag, and flushes the queue only after receiving an end of stream event.

 

So the question is: how can I keep the discont flag information set by the server so that the client too can get it? I’ve seen that the flag is cleared when rtpmp4vpay calls gst_buffer_create_sub, but, even if I patch this, it’s lost after pushing buffer into rtp adapter. When rtpmp4vpay retrieves pushed data from the adapter, flags are lost. How can I avoid this? Is there a more appropriate method to signal a discontinuity to the client?

 

Thanks,

Daniela

_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel