Muxing h264 video with sparse klv with Mpegtsmux

[cbourget]

Hi all,

I'm currently working on a pipeline which could record a video stream
through a udpsink and mux it with a klv stream received through a udpsink
also. As long as both streams are received the recording works perfectly but
as soon as the klv stream stop (which could happen in the context of my
application) the recording stops.

I did some research and found that technically as long as my stream are
live-stream it could handle the interruption but it doesn't seems to be
working. Here is the pipeline I am using :

gst-launch-1.0 -vm udpsrc uri=udp://224.0.0.1:5001 ! application/x-rtp,
encoding-name=H264, payload=96 ! rtph264depay ! video/x-h264,
stream-format=byte-stream, alignement=nal ! muxer. udpsrc
uri=udp://224.0.0.1:5000 ! meta/x-klv, parsed=true ! muxer. mpegtsmux
name=muxer ! filesink location=/home/charles/test.mpg

To stream the video I use the following pipeline :
gst-launch-1.0 -vm videotestsrc pattern=ball is-live=true ! video/x-raw,
width=300, height=300 ! x264enc tune=4 ! rtph264pay ! udpsink host=224.0.0.1
port=5001

The KLV data comes from an application which sends it through udp.

I am wondering if there is an option or an element which could solve my
problem or if there is a mistake in my pipeline.

Thank you in advance for your suggestion!

Charles Bourget



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[mz]

I can't confirm this solution is entirely successful (still having troubles
with utilizing the KLV in playback), but I found the best way to do this is
to utilize an appsink/src, with the appsink accumulating the KLV as it comes
in from your source, and the appsrc pushing it out towards the muxer. The
trick is that whenever you do NOT have any KLV buffers stored in the
appsink, you will need to push a gap buffer (with the GAP flag) to the
muxer. This will ensure the video frames are continuously processed, as
every video frame will either be muxed with a real KLV buffer from your
source or a "fake" gap buffer.



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[livinginlosangeles]

I am playing with the webRTC demos found at https://gitlab.freedesktop.org/gstreamer/gst-examples/. When I run the janusvideoroom.py demo, I get an ssl.SSLError: [SSL: WRONG_VERSION_NUMBER] wrong version number (_ssl.c:1122). This is obviously an issue with my NGINX reverse proxy. Has anyone had any experience with this? My python client ssl version is OpenSSL 1.1.1h  22 Sep 2020 and appears to support TLSv1.3. I forced my NGINX to use TLS v1.3. However when I look at the connection in Wireshark, I see my client handshaking at 1.0 (or 1.2) but never 1.3.

Tyler

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