GNOME Bugzilla – Bug 703111
New plugin with convenience RTP source/sink elements
Last modified: 2018-11-03 13:16:30 UTC
These are two modules - rtpsink - rtpsrc They register the rtp uri handler and and allow receiving and sending data over the network with RTP and RTCP on the standard sockets. Furthermore, the URI handling is such that all the GStreamer properties can be encoded in the URI in a standards fashion: e.g. rtp://239.1.2.3:1234?encoding-name=H264 use: gst-launch-1.0 rtpsrc uri=rtp://239.1.2.3:1234?encoding-name=H264 ! decodebin ! autovideosink I will provide a version that is a bit more cleaned up: - recently work on encryption has been done; we need to figure out if it fits in these modules or not This will be added as the code is moved out our our code base gradually and as it is tested on amd64 and armhf in the seperate form.
Created attachment 247809 [details] source package for rtp modules
I like the idea and it should be useful for many users. The only problem I see here is that rtp:// is not a standard URI scheme, but then appsrc: is neither
Can you create a patch against gst-plugins-bad that adds these elements?
I also like the general idea, here are some (non-exhaustive) first-glance comments: Tries to use the not-included rtpencrypt/rtpdecrypt? rtpptchange? ? What's GstTouringNewSource ? The RtpParameters already exists more or less as-is in gst-plugins-base/gst-libs/gst/rtp/gstrtppayloads.c with APIs to access it. Why hardcode use-pipeline-clock ?
The en/decrypt were added in the last week, they should be moved out; the ptchange is a remnant from the past with Bosch encoders using undefined pt values, it could be removed. The parameters are indeed an extended version of the base plugins; so that will have to go to. the use-pipeline-clock has to do with synchronisation. I'll create a patch for bad one of the following days.
Yeah, needs to be cleaned up a bit as Marc already said in the initial comment :) What is this encryption stuff doing there? Is it just srtp, or something else?
It got in about 2 weeks ago. Basically it is there to compensate for a bad SRTP implementation (which we have to decode to an external system). It will be moved out to an higher bin.
Created attachment 267831 [details] [review] Patch against the bad plugins for the rtp bins FOSDEM 2014 What does one do; next to chatting with some very familiar faces? Catching up on some work that was long overdue. This patch provides the rtp modules against the bad plugins. The typical way would be receiving gst-launch rtpsrc uri=rtp://239.1.2.3:1234?encoding-name=H264 ! rtph264depay ! rtph264parse ! ... The encoding-name is added there as a workaround for a long outstanding bug on the typefinder that does not correctly make the difference between MPEG4 pt2 and pt10 (H.264). It does show the general mode of operation of our modules: we allow encoding the properties of a module in the URI, so for all the properties you get with gst-inspect, you can add them in the uri: e.g. rtp://239.1.2.3:1234?encoding-name=H264&latency=200... sending (v4l2 device sending out h264, but any h264 source will do) gst-launch v4l2src uri=v4l2:///dev/video0 ! h264parse ! rtph264pay ! rtpsink uri=rtp://239.1.2.3:1234
Created attachment 267840 [details] [review] Use the base-plugins
Created attachment 267844 [details] [review] remove parallel implementation of RTP parameter lookup
Created attachment 267845 [details] [review] Remove encryption AES hooks The original submission contained encryption hooks for AES/SRTP. This patch removes them and these will be added later in an SRTP submission.
The TouringNewSource is a message that is coming from upstream. The name reflects functionality where it was developed for; but in essence; it sends another NOTE in the RTCP messages. I think it can be kept in there, maybe the name should be something else.
Created attachment 267849 [details] [review] remove obsolete pt squashing the bins contained references to a now (1.x) obsolete module that squashed the pt information in the data stream. 0.10 rtp(de)pay caps relied heavily on the pt value and in case of e.g. Bosch encoders, who raped the pt values, this broke compatibility. This was one way of squashing the pt, by overriding it (36 for Bosch H.264) with a proper dynamic one. Since the pt information has now been removed from the rtp(de)payloaders, this is no longer used.
Created attachment 267851 [details] [review] rtpsrc and rtpsink merged patches A merged patch for rtpsrc and rtpsink I wanted to keep the entire patch set traceable in the bugzilla...
Created attachment 268240 [details] [review] Patch
Hi Marc, I think barcortp plugins should be in ext directory as it depends on Soup. Plugins in gst directory seem to have no dependency and are added to GST_PLUGINS_SELECTED (used in gst/Makefile.am) with AG_GST_CHECK_PLUGIN macro. Because of this, barcortp was not being build in my case, even with soup-dev installed. I updated your patch to fix this. This patch is based on 1.2.2. Cheers
What did ever happen to this? Very interesting but it looks it never made it to merge.
I am poking Sebastian, Edward and Tim on a semi-regular basis whenever I see them :-) I am currently waiting for a new release of GStreamer to get rid of the the SOUP dependency. I know the new URI class is in git, but as long as I cannot release the internal code on an official release, I am stuck.
I'd like to get this in too, it's something that would many people's life easier ;) Someone would need to update the patch to latest GIT and get rid of the soup dependency by using GstUri instead.
*** Bug 741543 has been marked as a duplicate of this bug. ***
Review of attachment 267851 [details] [review]: Might make sense to rename the gstbarco* files to something without barco :) ::: gst/barcortp/gstrtpsrc.c @@ +479,3 @@ + "sampling", G_TYPE_STRING, "RGB", + "depth", G_TYPE_INT, 24, + "width", G_TYPE_INT, 800, "height", G_TYPE_INT, 600, NULL); This function does not make any sense at all :) The parameters for the application/x-rtp caps should be retrieved from the URI, not magic values hardcoded (why should RAW-RGB24 always be 800x600?)
> Might make sense to rename the gstbarco* files to something without barco :) That is not a problem, it is just a string replacement. > ::: gst/barcortp/gstrtpsrc.c > @@ +479,3 @@ > + "sampling", G_TYPE_STRING, "RGB", > + "depth", G_TYPE_INT, 24, > + "width", G_TYPE_INT, 800, "height", G_TYPE_INT, 600, NULL); > > This function does not make any sense at all :) The parameters for the > application/x-rtp caps should be retrieved from the URI, not magic values > hardcoded (why should RAW-RGB24 always be 800x600?) When the code was written, I was not using RGB, so I hardcoded it to something ppl could use for testing (RAW at 600x800 does not require that much bandwidht). I think I removed this a couple weeks ago. I would need to check.
It's the same problem for other formats, like L16 is hardcoded to two channels and a specific sample rate. It should be possible to just give the values via the URI instead of hardcoding magic values :)
I think there is also a way to just use 'caps' as a property in some cases, but since that is pretty complex for non-Gstreamer users, it is rarely used. I would need to see if it is used/suppored broadly, or just for v2dsink. In essence, if a sink/source element has a caps property, it can be encoded in the uri.
> I would need to see if it is used/suppored broadly, or just for v2dsink. Euhm, that would be v4l2sink of course. I don't know where I got that other name.
How is that related to v4l2sink or any other elements? The problem here is that for various RTP codec mappings to work, you have to provide a set of properties. Currently you hardcode them, but in a way that is not going to work well in general. Why assume that all L16 streams are 2 channels and 48kHz if they could as well have completely different settings? IMHO the uri property should allow setting all these things directly, and all properties set in the URI should be converted to caps fields directly (and not to anything else, like other properties). E.g. rtp://127.0.0.1:5000?encoding-name=L16,channels=2,clock-rate=96000 would be converted to application/x-rtp,encoding-name=L16,channels=2,clock-rate=96000.
I am finding a way to use rtp source with uridecodebin, and I get to know here. @Marc Leeman I suppose your rtpsrc considers only one session by given uri, right? if it's right, do you have a plan for enhancement of your patch to support multiple sessions?
(In reply to Justin J. Kim from comment #27) > I am finding a way to use rtp source with uridecodebin, and I get to know > here. > > @Marc Leeman > I suppose your rtpsrc considers only one session by given uri, right? > if it's right, do you have a plan for enhancement of your patch to support > multiple sessions? rtpsrc spawns src pads for different sessions, so if the src resets, you will get a new src pad. I do not think it cleans up the pads at this time, I would need to link to the demuxer to see if it itself has cleaned up the session (and that is configurable).
Very useful, it make our life easier. Someone can make it as soon as possible to merge into the master?
Created attachment 341529 [details] [review] Improve rtpsrc plugin > It should be possible to just give the values via the URI instead of >hardcoding magic values :) I did this job,no need for third party libraries. I think RTPSRC's most valuable place, can let playbin work to obtain the additional configuration data through URI‘s query string.That is, like the following URI it's work properly: gst-launch-1.0 playbin uri="rtp://10.9.44.117:5000?media=video&clock-rate=90000&encoding-name=H264&payload=96&do-retransmission=true&latency-ms=50&rtp-profile=1&rtx-host=10.9.44.118&rtx-port=5006" or gst-launch-1.0 rtpsrc uri=rtp://10.9.44.117:5000 caps=application/x-rtp,media=video,clock-rate=90000,encoding-name=H264,payload=96 ! rtph264depay ! h264parse ! decodebin ! autovideosink sync=false I am not sure what rtpsink exactly does, so, according to the razor, I didn't merge rtpsink.
rtpsink allows to send RTP data on the network by using the correct socket combination and by linking up RTCP.
(In reply to Marc Leeman from comment #31) > rtpsink allows to send RTP data on the network by using the correct socket > combination and by linking up RTCP. Hi Marc,thanks for your infos.
Is the patch from luckychou already merged to mainline somewhere? Or verified?
I will post an update for the elements one of these; most importantly rtpsink has now changed to use request pads so that the multiple streams exit the element over the same session. For rtpsrc, I've removed all the encryption cruft (I don't remember if it was still there when I originally submitted the elements).
Hi guys, does this receiver: gst-launch-1.0 playbin uri="rtp://10.9.44.117:5000?media=video&clock-rate=90000&encoding-name=H264&payload=96&do-retransmission=true&latency-ms=50&rtp-profile=1&rtx-host=10.9.44.118&rtx-port=5006" work in case the sender is like: $ ./gst-launch-1.0 -v videotestsrc ! video/x-raw,width=800,height=600 ! videoscale ! videoconvert ! x264enc tune=zerolatency ! rtph264pay ! udpsink host=127.0.0.1 port=5000 e.g. used the udpsink element instead of rtpsink? And second question: is it possible to use in receiver 'udp' scheme instead of 'rtp', like: gst-launch-1.0 playbin uri="udp://10.9.44.117:5000?media=video&clock-rate=90000&encoding-name=H264&payload=96&do-retransmission=true&latency-ms=50&rtp-profile=1&rtx-host=10.9.44.118&rtx-port=5006" ?
Yes it works, but doing it like that is not optimal (sending without a rtpbin will not create RTCP). RTP is not UDP with a simple header. rtpsrc uri=rtp://239.1.2.3:1234?encoding-name=H264 rtpsink uri=rtp://239.1.2.3:1234 On the sender side, you do not need to pass the encoding name, the encoding name is used as a hint at the receiver side.
Created attachment 365573 [details] src archive I added an archive of the latest code (otherwise I'll forget). The most important changes would be: 1/ removal of cruft 2/ rtpsink has request pads -> you can send multiple streams in one session
Can you add a single, big patch for this against gst-plugins-bad to the bug? That would allow reviewing it in Bugzilla :)
Of course, I just added this quickly because I see some ppl having a look at it and I don't want them to mess around with the really old stuff.
See also: https://github.com/mleeman/gst-plugins-rtp
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/99.