GNOME Bugzilla – Bug 743175
Add support for RECORD
Last modified: 2015-02-10 09:03:01 UTC
Attached patches add support for the RECORD method to gst-rtsp-server, including an example. Please review :) Especially I'm not sure about the properties for RECORD on the media-factory/media/stream. Should there be also one for PLAY (PLAY and RECORD is apparently allowed, but we don't implement that yet)? Or a flags property?
Created attachment 294866 [details] [review] Add initial support for RECORD We currently only support media that is RECORD or PLAY only, not both at once.
Created attachment 294867 [details] [review] rtsp-stream: Put the timestamp of receival of the initial packet over TCP on the first buffer
Created attachment 294869 [details] [review] test-record: Use GOptionContext to parse the server port and take the pipeline from the commandline
Created attachment 294870 [details] [review] rtsp-media: Expose latency setting for setting the rtpbin latency
Created attachment 295119 [details] [review] rtsp-client: fix a couple of leaks in handle_announce
Created attachment 295120 [details] [review] tests: add some simple unit tests for ANNOUNCE and RECORD
Works very nicely for me: ./test-record "( decodebin name=depay0 ! autovideosink decodebin name=depay1 ! autoaudiosink )" Then with ffmpeg: ffmpeg -re -i /home/wim/data/serenity_1080p.mov -strict -2 -f rtsp -muxdelay 0.1 rtsp://127.0.0.1:8554/test I think a flag property would be ok to say that play/record is allowed. If you use the launch syntax you can set the flags based on the pay/depay element names you can find. Otherwise the app has to set the flags to let the server block announce/play requests for you.
Seems like a good plan to me, I'll update the patch accordingly later. So a flags-typed property (and getter/setter functions) for the media factory, media and stream. And additionally some defaulting for the flags in collect_media based on what element names are found. Thanks for testing and looking at the patches :)
Created attachment 295690 [details] [review] rtsp-media: Use flags to distinguish between PLAY and RECORD media
The problem with autodetecting the flags is that we must default to PLAY. Otherwise we loose backwards compatibility with old media that does not use a pipeline string but also does not set the flags by itself.
For rtsp-stream we might later need a new_full() that takes a srcpad and a sinkpad. Not completely sure. But that's for someone to figure out when it's actually needed ;)
This is now all merged.
This stuff is really promising, thanks for telling me about it this morning, slomo! I'm looking into the possibility of using this to proxy an rtsp stream through an intermediary server, so I don't want to use decodebin elements but instead, take each received/"recorded" encoded streams and provide it as a PLAY media for another rtsp client. so I put gst_rtsp_media_factory_set_transport_mode (factory, GST_RTSP_TRANSPORT_MODE_RECORD | GST_RTSP_TRANSPORT_MODE_PLAY); into the test-record example and supply a pipeline of ./test-record "( rtpmp4vdepay name=depay0 ! mpeg4videoparse ! rtpmp4vpay name=pay0 pt=96 rtpmp4gdepay name=depay1 ! aacparse ! rtpmp4gpay name=pay1 pt=97 )" which results in: (lt-test-record:10642): GLib-GObject-WARNING **: g_object_get_valist: object class 'GstRtpMP4VDepay' has no property named 'pt' 0:00:02.692684917 10642 0x6b4450 ERROR rtspmedia rtsp-media.c:3461:default_handle_sdp: 0x7f5d6402e370: Media has more or less streams than SDP (4 /= 2) 0:00:02.692717707 10642 0x6b4450 ERROR rtspclient rtsp-client.c:2265:handle_sdp: client 0x81c8b0: could not handle SDP 0:00:02.692730227 10642 0x6b4450 ERROR rtspclient rtsp-client.c:2409:handle_announce_request: client 0x81c8b0: can't handle SDP once the RECORD commences. it's probably simply a strcmp matching name "pay" to where it says "depay" or something like that. I'm too exhausted to look at the code right now but I will certainly help fixing this :) and hey, we also need a gstreamer rtspclient, don't we? using avconv is totally NOT an option ^^
Created attachment 296442 [details] [review] method to distinguish between in and out streams I noticed the sdp stream miscount error comes from a loop counting ALL streams, also the RECORD streams, so GstRTSPStream now has a gst_rtsp_stream_get_transport_mode method that returns GST_RTSP_TRANSPORT_MODE_PLAY or RECORD. In three different functions auf rtsp-media, iterations of ALL streams was modified to only consider PLAY streams like the traditional behaviour. This fixes a few ERRORs and glib-CRITICALs but doesn't allow PLAY|RECORD streaming from depay to pay quite yet.
Comment on attachment 296442 [details] [review] method to distinguish between in and out streams Andreas said that this patch was still a bit buggy. Also let's put this into a new bug report :)