Closed. This question is not about programming or software development. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 12 days ago.
Improve this question
I need to create pipelines to stream and play an GStreamer, mpgets over UDP/RTP video stream... after some trials, I found a reliable and quite low-latency result:
Player script:
gst-launch-1.0 udpsrc port=4001 caps="application/x-rtp" ! \
rtpmp2tdepay ! \
tsdemux ! \
h264parse ! avdec_h264 ! \
videoconvert ! \
queue max-size-buffers=150 ! autovideosink sync=false;
Streamer:
gst-launch-1.0 filesrc location=video.mp4 ! qtdemux ! \
h264parse ! avdec_h264 ! \
x264enc tune=zerolatency ! \
mpegtsmux alignment=7 ! \
rtpmp2tpay ! \
udpsink host=127.0.0.1 port=4001;
This works fine if the player is started before the streamer, but if I invert the startup order, I get this:
Streamer output:
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Redistribute latency...
Redistribute latency...
Redistribute latency...
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
Got EOS from element "pipeline0".
Execution ended after 0:00:09.969634553
Setting pipeline to NULL ...
Freeing pipeline ...
Player output:
Setting pipeline to PAUSED ...
Pipeline is live and does not need PREROLL ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
The player freezes in this state without showing a single frame (no windows open, etc.).
After Ctrl + C, it exits gracefully, signaling abort:
^Chandling interrupt.
Interrupt: Stopping pipeline ...
Execution ended after 0:06:33.125092033
Setting pipeline to NULL ...
Freeing pipeline ...
Is possible to make it startup-order-agnostic?
P.S.:
I'm using GStreamer 1.16.3 on Ubuntu 20.04 Desktop (Focal Fossa).
video.mp4 is one of the H.264 test videos available here; since it's a QuickTime video, it needs qtdemux in the streamer pipeline.
I got the same issue also using the same pipelines through the API (without using gst-launch-1.0).
Using the h264parse config-interval=-1 option, as suggested below, is not working.
You will have to send the codec parameters periodically for random access:
..
x264enc tune=zerolatency ! \
h264parse config-interval=-1 ! \
mpegtsmux alignment=7 ! \
..
Related
Dear gstreamer community,
I am running gstreamer (1.20.3) on ubuntu 22.04 LTS with decklinkdrivers (12.4)
After building (and playing around with gstreamer, wathing tutorials etc) the following pipeline I am able to decode a high quality HD SRT Stream (udp streaming) and am outputting it to SDI (in 1080i50), works very well.
gst-launch-1.0 -v srtsrc uri=srt://x.x.x.x:xxxx latency=200 ! tsdemux name=demux demux. ! h264parse ! video/x-h264 ! avdec_h264 ! queue ! videoconvert ! video/x-raw,format=UYVY ! decklinkvideosink mode=1080i50 sync=false demux. ! avdec_aac ! queue ! audioconvert ! audio/x-raw, format=S32LE, channels=2 ! decklinkaudiosink
Audio to Videosync is stable to each other for hours (didn't test for days), but after testing the encoder to decoder end to end on my gstreamer pipeline audio comes a little too early (about 60ms early).
I tried to only change buffersize in audiopart of the pipeline to correct the timing on the audiosite e.g.
queue max-size-buffers=0 max-size-time=0 max-size-bytes=0 min-threshold-time=60000000
but audio to video offset didn't change here trying several different min-threshold-times.
for the decklinkaudiosink there is no ts-offset cap to change the timing here and also changing the buffer-time property here didn't change anything.
Can anybody please help me here how to correct the audio timing or audio latency to accurate videodecoding on my pipeline!?
Thanks!
So, I'm starting to play around with gstreamer and I'm able to do very simple pipes such as
gst-launch-1.0 -v v4l2src device=/dev/video1 ! video/x-raw,format=YUY2,width=640,height=480,framerate=10/1 ! videoconvert ! autovideosink
Now, as my USB webcam (which is video1, video0 being the computer's built in camera) supports h264 (I have checked using lsusb), I would like to try to get the h264 feed directly. I understand that this feed is muxed in the mjpeg one, but looking around on the web it seems that gstreamer is able to get it nonetheless.
Since my end goal is to stream it from a Beaglebone, I made an attempt using the solution given to this post (adding a listener from a different terminal):
#sender
gst-launch-1.0 v4l2src device=/dev/video1 ! video/x-264,width=320,height=90,framerate=10/1 ! tcpserversink host=192.168.148.112 port=9999
But this yields the following error :
WARNING: erroneous pipeline: could not link v4l2src0 to tcpserversink0
I also tried something similar to my first command, changing the source from raw to h264 (based on that post , trying the full command given there gives the same error message)
gst-launch-1.0 -v v4l2src device=/dev/video1 ! video/x-h264,width=640,height=480,framerate=10/1 ! h264parse ! avdec_h264 ! autovideosink
But again, this did not work either:
Setting pipeline to PAUSED ...
Pipeline is live and does not need PREROLL ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
ERROR: from element /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Internal data flow error.
Additional debug info:
gstbasesrc.c(2948): gst_base_src_loop (): /GstPipeline:pipeline0/GstV4l2Src:v4l2src0:
streaming task paused, reason not-negotiated (-4)
Execution ended after 0:00:00.036309961
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
Setting pipeline to NULL ...
Freeing pipeline ...
I admit this is driving me pretty crazy: looking on SO or elsewhere on the web, there seems to be a lot of people who made it work with exactly the same webcam as the one I have (Logitech C920), but I keep running into issues one after the other.
What would be an example of correct pipe to extract the h264 from that webcam?
You definitely need to use a payloader before it hits the wire. For example rtph264pay. Here is an example that cannot test as I don't have your hardware available. I have working udp examples from alternates sources if this doesn't steer you in the right direction.
server
gst-launch v4l2src device=/dev/video1 \
! video/x-264,width=320,height=90,framerate=10/1 \
! x264enc \
! queue \
! rtph264pay, config-interval=3, pt=96, mtu=1500 \
! queue \
! tcpserversink host=127.0.0.1 port=9002
client
gst-launch tcpserversrc host=127.0.0.1 port=9002 \
! application/x-rtp, media=video, clock-rate=90000, encoding-name=H264, payload=96 \
! rtph264depay \
! video/x-h264 \
! queue \
! ffdec_h264 \
! queue \
! xvimagesink
I have a pcm audio file that I want to stream via rtp. When I do
gst-launch-1.0 filesrc location=AudioRaw515151.pcm ! audio/x-raw, format=S16LE, channels=1, layout=interleaved, rate=8000 ! alawenc ! rtppcmapay ! udpsink host=192.168.2.5 port=5010
I have that kind of message
Pipeline is PREROLLING ...
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
Got EOS from element "pipeline0".
Execution ended after 0:00:00.019270487
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
Setting pipeline to NULL ...
Freeing pipeline ...
But I can play this audio, That means that audio is ok.
gst-launch-1.0 filesrc location=AudioRaw515151.pcm ! audio/x-raw, format=S16LE, channels=1, layout=interleaved, rate=8000 ! alawenc ! rtppcmapay ! rtppcmdepay ! alawdec ! audiosink
I tried to take another file-avi file, take audio from it and maked the same thing
gst-launch-1.0 filesrc location=file.avi ^
! qtdemux name=mux^
! queue ^
! faad ^
! audioconvert ^
! audioresample ^
! "audio/x-raw, layout=(string)interleaved, rate=(int)8000" ^
! alawenc ^
! rtppcmapay ^
! queue ^
! udpsink host=192.168.2.5 port=5010
As you see, this the same thing but with audio from avi. Everything works.
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
When I open Wireshark I see that when I run my pipeline with PCM, it fires all data without any delay and in every packet that I send is:
Header checksum: 0x0000 [incorrect, should be 0x40b5 (may be caused by "IP checksum offload"?)]
Message: Bad checksum
So here is a question. I think that I have a problem with timestamps or something like that, when I do !alawenc (encoding to G711), I am right?
And what solution can fix that problem?
First Question. Does the 2nd example play?
A few more comments:
file.avi and qtdemux sounds wrong, just use decodebin (or uridecodebin) to leave the pligging to gstreamer.
for raw audio I recommend to use the audioparse element
And finally there are a bunch of rtp examples in the git repo:
https://cgit.freedesktop.org/gstreamer/gst-plugins-good/tree/tests/examples/rtp/client-PCMA.sh
I am trying to use latest gstreamer and x265enc together. I saw that someone have already posted some commits in http://cgit.freedesktop.org/gstreamer/gst-plugins-bad/log/ext/x265/gstx265enc.c
Can anyone please give an example pipeline where it is known to working (gst-launch-1.0 pipeline example will be very helpful)
1)
What is the current status of x265enc plugin for gstreamer ? does it work really ?
Which branch of gstreamer I need to use to build x265enc? I want to build whole gsteamer source code which will be compatible with x265enc plugin.
What are the system requirement for x265enc and how to build it ? Any wiki/basic instructions will be very helpful.
My goal is to broadcast my ip cameras (h264 streams) as h265 stream on vaughnlive.tv
Currently, I am using following pipeline to broadcast in h264 format:
GST_DEBUG=2 gst-launch-1.0 flvmux name=mux streamable=true ! rtmpsink
sync=true location="rtmp://xxxxxxxxxxxx" rtspsrc
location="rtsp://xxxxxxx" caps="application/x-rtp,
media=(string)audio, clock-rate=(int)90000, encoding-name=(string)MPA,
payload=(int)96" ! rtpmpadepay ! mpegaudioparse ! queue ! mad !
audioconvert ! queue ! voaacenc bitrate=128000 ! aacparse !
audio/mpeg,mpegversion=4,stream-format=raw ! mux. rtspsrc
location="rtsp://xxxxxxx"
caps="application/x-rtp,media=(string)video,clock-rate=(int)90000,
encoding-name=(string)H264" ! rtph264depay !
video/x-h264,stream-format=avc,alignment=au,byte-stream=false ! queue
! decodebin ! queue ! videorate ! "video/x-raw,framerate=30/1" ! queue
! x264enc threads=4 speed-preset=ultrafast bitrate=3072 ! mux.
2)
Can anyone please suggest on how should I change this pipeline to broadcast in h265 format using x265enc element?
A little late but, maybe some people will find this question when seeking info about H.265 support in gstreamer nowadays. This is with gstreamer 1.6.1 compiled from source on Ubuntu 15.10 which has packages ready for libx265..
1,
Encoder
There is x265enc which will be enabled when we have library libx265-dev.
The encoder is inside gst-plugins-bad so after doing autogen.sh you should see x265enc enabled.
You may also need h265parse, rtph265pay/depay
Decoder
I see two decoders, dont know which one is working, I guess libde265dec there is also avdec_h265.
mux
For mux for x264 I was using mpegtsmux, but this does not support video/x265, some work has to be done. The matroskamux should be working when using filesink etc..
[16:39] hi, which container is suitable for x265enc, for x264enc I was using mpegtsmux?
[16:54] otopolsky: mpegts would work if you add support for h265 there, not very difficult[16:55] slomo_: so we need to just add the caps compatibility?
[16:55] otopolsky: otherwise, matroskamux supports it. mp4mux/qtmux could get support for it relatively easily too
[16:55] otopolsky: a bit more than that. look at what tsdemux does for h265
[16:56] otopolsky: and check the gst_mpegts_descriptor_from_registration related code in tsmux
[17:00] slomo_: thanks
2,
Questioned flvmux also does not support h265 only h264..
matroskamux cannot be used for streaming, so only way is to patch mpegtsmux or flvmux etc.
I am trying to user gst-launch to stream mp3 audio over tcp, this is what I am trying :
$ gst-launch-0.10 filesrc location="/path/to/file.mp3" ! tcpserversink host=0.0.0.0 port=3000
but it doesn't work the output is as follow :
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
ERROR: from element /GstPipeline:pipeline0/GstTCPServerSink:tcpserversink0: Internal GStreamer error: negotiation problem. Please file a bug at http://bugzilla.gnome.org/enter_bug.cgi?product=GStreamer.
Additional debug info:
gstmultifdsink.c(2700): gst_multi_fd_sink_render (): /GstPipeline:pipeline0/GstTCPServerSink:tcpserversink0:
Received first buffer without caps set
Execution ended after 94657 ns.
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
Setting pipeline to NULL ...
Freeing pipeline ..
Whats the problem where I am going wrong?
I did lots of search on internet but didn't found the right document how to use gst-launch properly. if anyone can please point me to right doc or tell me how to use it it will great.
tcpserversink complains about missing caps on its sink pad:
Received first buffer without caps set
This is because tcpserversink wants to know what it sends.
One way to tell it would be to manually decode and re-encode the stream:
gst-launch-0.10 filesrc location="/path/to/file.mp3" ! mad ! audioconvert ! lame ! tcpserversink host=0.0.0.0 port=3000
But that's just waste of CPU power.
There's an element called mpegaudioparse that (apart from some other stuff) figures out the details of the mpeg stream and sets its output caps accordingly. By simply putting it between your filesrc and the tcpserversink you'll end up with a working pipeline:
$ gst-launch-0.10 filesrc location="/path/to/file.mp3" ! mpegaudioparse ! tcpserversink host=0.0.0.0 port=3000