rtsp: test-launch vs c

[Nicolas Dufresne]

Le vendredi 19 juin 2020 à 13:23 +0200, Goran Broeckaert a écrit :
> Hello,
> 
> Right now I have a simple pipeline: "videotestsrc ! x264enc ! h264parse !
> rtph264 name=pay0". I use the test-launch application, which is an example
> from the rtps-server plugin. I did some modifications to the application to
> have both options: transmitting using unicast and multicast.
> 
> I'm using version 1.16.2 of gstreamer, gst-rtps-server and gst-plugins-bad on
> Ubuntu20.04.
> 
> The simple pipeline works perfectly: I can use ffplay to retrieve the stream
> (both unicast and multicast). If I modify the pipeline to the following: 
> "videotestsrc ! x264enc ! h264parse ! rtph264 ! rtponviftimestamp ntp-offset=0 
> ! name=pay0", I can retrieve the stream using unicast, but when I do it with
> multicast it does not work. I've used debugging level 4, but I couldn't find
> anything that said where it went wrong.
> 
> How should I proceed with debugging this?

It is most likely the x264enc configuration that isn't adequate. In general, you
might want to consider lower profiles then what would be picked by default
(notably avoiding YCbCr 4:4:4 as this is rarely supported by HW decoders). You
can control the sub-sampling by controlling the input color format:

   videotestsrc ! video/x-raw,format=I420 ! x264enc ...

Then best result for streaming are done with CBR (constant bitrate), this is the
default for this encoder. But you may wan to adapt the "bitrate" property
(careful this one is in Kbit/s) if you see degraded quality. Another thing you
wan to control is the speed and the latency of the compression algorithm. To
simplify this, there is a "tune" property. "zerolatency" or "fastdecode" tuning
should work fairly well for your use case. Finally, you want to control the
H.264 profiles. A very conservative choice would be to select "constrained-
baseline", this a format that is pretty much guarantied to be supported. But to
gain a bit more features, you may want to select "main" profile. That is done
with:

   ... ! x264enc tune=zerolatency ! video/x-h264,profile=constrained-baseline ! ...

Because that's not enough, in multicast clients will connect at random point in
time. The delay to be able to display is variable and depend on the distance
between two keyframes. You can control that distance on the encoder using "key-
int-max" property. A value of 60 will insert a key frame every 60 frames. With
30fps, this means that you worst case scenario it will take 2s to display the
video.

  ... ! x264enc tune=zerolatency key-int-max=60 ! ...

Hope this is useful and works for you,
Nicolas

p.s. recent x264 library enabled slices in zerolatency, which is not always well
supported, I believe that setting threads=1 will disable this, as the number of
sliced is selected base on the number of allowed encoding threads.

> 
> Thanks for your help! Kind regards,
> Goran Broeckaert
> 
> PS: I've uploaded the patch to modify the test-launch.c to have the option to
> use multicast to pastebin: https://pastebin.com/qjpaYwCL .
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel