I am developing an IP Streaming based media player. I am using the following pipelines:
Src:
gst-launch-1.0 -vvv udpsrc port=5004 ! application/x-rtp, payload=96 ! rtph2 64depay ! h264parse ! imxvpudec ! imxipuvideosink sync=false
Sink:
C:\gstreamer\1.0\x86_64\bin\gst-launch-1.0.exe -v filesrc location=C:\\gstreamer\\1.0\\x86_64\\bin\\hash.h264 ! h264parse ! rtph264pay ! udpsink host=153.77.205.139 port=5004 sync=true
This was the proof of concept. Now, We wanted to have an application which can perform the same operation but with a little tweak when there is no streaming or when no data from the sink, we need to switch to offline base media player, means play a set of videos offline and when there is data on udp port, switch to streaming.
Following are my queries:
Is there any way to find out streaming has been completed after video play over IP
Is there any way to find out there is no streaming happening.
Please help. I am ready to help you if you need more details
For udpsrc there is timeout property, which sends a message on bus if there is no data available (you can try setting it to 1 second), for streaming is complted you should get EOS on the bus again. (try this pipeline gst-launch-1.0 -vvvm udpsrc port=5004 timeout=100000000 ! application/x-rtp, payload=96 ! rtph2 64depay ! h264parse ! imxvpudec ! imxipuvideosink sync=false)
Related
Is it possible to write rtpopus to a file, then read it back with gstreamer? It seems simple but I'm getting nowhere with it and can't seem to find any information online. Here is my attempt:
gst-launch-1.0.exe audiotestsrc ! opusenc ! rtpopuspay ! filesink location=test.opus
Then, close and run:
gst-launch-1.0.exe filesrc location="test.opus" ! rtpopusdepay ! fakesink dump=true
gstreamer fails with:
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
ERROR: from element /GstPipeline:pipeline0/GstFileSrc:filesrc0: Internal data stream error.
Additional debug info:
../libs/gst/base/gstbasesrc.c(3127): gst_base_src_loop (): /GstPipeline:pipeline0/GstFileSrc:filesrc0:
streaming stopped, reason error (-5)
ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...
Freeing pipeline ...
I don't think it could work. RTP is related to UDP packetization so it would work when streaming over UDP.
You'd better use a file container supporting opus audio such as matroskamux:
gst-launch-1.0 -e audiotestsrc ! audioconvert ! opusenc ! matroskamux ! filesink location=test.mkv
# Let play for 5s and stop with Ctrl-C
# Replay:
gst-launch-1.0 filesrc location=test.mkv ! matroskademux ! opusdec ! audioconvert ! autoaudiosink
I have trouble streaming pulse audio monitor via rtp to an audio player like vlc or gst-launch with udpsrc
this command works and the file has audio that is currently being played
gst-launch-1.0 -v pulsesrc device = "alsa_output.pci-0000_00_1b.0.analog-stereo.monitor" ! opusenc ! oggmux ! filesink location=test.ogg
but when i use this,
gst-launch-1.0 -v pulsesrc device="alsa_output.pci-0000_00_1b.0.analog-stereo.monitor" ! opusenc ! rtpopuspay ! udpsink host=0.0.0.0 port=4000
vlc (from an android phone) tells me that it cannot play the stream with uri rtp://ip-addr:4000
and gst-launch from same machine starts but the resulting file is empty.
gst-launch-1.0 -v udpsrc uri=rtp://0.0.0.0:4000 ! rtpopusdepay ! oggmux ! filesink location=test.ogg
gstreamer version is
$ gst-launch-1.0 --version
gst-launch-1.0 version 1.16.0
GStreamer 1.16.0
Just started this account, I wanted to add this as a comment, but couldn't because of rep limitations.
I'm not experienced in using vlc, but at least I get your GStreamer pipelines working if I add the caps, definitions of the rtp stream parameters, to the rtpopusdepay.
So instead of:
gst-launch-1.0 -v udpsrc uri=rtp://0.0.0.0:4000 ! rtpopusdepay ! oggmux ! filesink location=test.ogg
you'll need to use:
gst-launch-1.0 udpsrc uri=udp://0.0.0.0:4000 ! application/x-rtp,payload=96,encoding-name=OPUS ! rtpopusdepay ! opusdec ! autoaudiosink
for GStreamer. The mandatory parts are the payload and encoding-name, others you can find from gst-inspect-1.0 rtpopuspay/rtpopusdepay. You might need to change the numbers depending on what you define on the server side/what's the default on your machine.
So in conclusion, I got that GStreamer pipeline working by moving the rtp definitions to the caps for rtpopusdepay. As I said, I'm not familiar with vlc, so I don't know how to define those GStreamer caps there, if it even depends on those, but I hope this gives some insight on your work.
I'm trying to send audio through an RTP Stream using gstreamer with the lowest latency possible and I want to do it from a Pepper(gstreamer 0.10) to my computer(gstreamer 0.10 or 1.0).
I can send audio with little latency (20 ms) from the computer to Pepper however I doesn't work as well from the Pepper to the computer. When I try to adjust the buffer-time under 200 ms, I get this type of error :
WARNING: Can't record audio fast enough
Dropped 318 samples. This is most likely beacause downstream can't keep up and is consuming samples too slowly.
I used the answers here and so far and worked with the following pipelines:
Sender
gst-launch-0.10 -v alsasrc name=mic provide-clock=true do-timestamp=true buffer-time=20000 mic. ! \
audio/x-raw-int, format=S16LE, channels=1, width=16,depth=16,rate=16000 ! \
audioconvert ! rtpL16pay ! queue ! udpsink host=pepper.local port=4000 sync=false
Receiver
gst-launch-0.10 -v udpsrc port=4000 caps = 'application/x-rtp, media=audio, clock-rate=16000, encoding-name=L16, encoding-params=1, channels=1, payload=96' ! \
rtpL16depay ! autoaudiosink buffer-time=80000 sync=false
I don't really know how to tackle this issue as the CPU usage is not anormal.
And to be frank I am quite new in this, so I don't get what are the parameters to play with to get low latency. I hope someone can help me! (and that it is not a hardware problem too ^^)
Thanks a lot!
I don't think gst-launch-0.10 is made to work in real-time (RT).
Please consider writing your own program (even using GStreamer) to perform the streaming from an RT thread. NAOqi OS has the RT patches included and support this.
But with network involved in your pipeline, you may not be able to guarantee it is going to be processed in time.
So maybe the simplest solution could be to keep a queue before the audio processing of the sender:
gst-launch-0.10 -v alsasrc name=mic provide-clock=true do-timestamp=true buffer-time=20000 mic. ! \
audio/x-raw-int, format=S16LE, channels=1, width=16,depth=16,rate=16000 ! \
queue ! audioconvert ! rtpL16pay ! queue ! udpsink host=pepper.local port=4000 sync=false
Also consider that the receiver may cause a drop if it cannot process the audio in time, and that a queue might help too:
gst-launch-0.10 -v udpsrc port=4000 caps = 'application/x-rtp, media=audio, clock-rate=16000, encoding-name=L16, encoding-params=1, channels=1, payload=96' ! \
rtpL16depay ! queue ! autoaudiosink buffer-time=80000 sync=false
I want be able to stream couple chunks which have TS as a container. If I stream only audio or video, then it's fine. But when I do both simultaneously a pipeline doesn't start. It says prerolling for a long time.
I've tried hints from here. It makes my pipeline easier but still prerolling at start.
I believe there is a problem with tsdemux. Don't really know why it happens. Logs are not so informative, so I ended up writing this post.
Here is my pipeline. It's not perfect and I know it, but separatly it works. So let's stick with it.
gst-launch-1.0 multifilesrc location="chunck%d.ts" index = 0 ! tsdemux name=demux
demux. !queue ! h264parse ! mux.
demux. ! queue ! faad ! audoconvert ! voaacenc !
flvmux name=mux ! filesink location=stream.ts
It this one I've used filesink for testing purposes. I know about rtmpsink and have tried it before.
Thx a lot.
UPDATE
I've managed to combine video and audio. But there is a problem with skipping frames when using my pipeline.
gst-launch-1.0 --gst-debug-level=0 multifilesrc location="chunk%d.ts" index = 0 ! tsdemux name=demux !
queue ! h264parse ! flvmux name=mux ! queue ! filesink location=stream.flv
demux. ! queue ! aacparse ! mux.audio
Next task is to get rid of the problem. Maybe it's the parser issue. Will see.
i am using g streamer-0.10 on Ubuntu os for streaming an web cam video on to an rtmp server i am getting an video output but their is a problem in audio . Below command used for streaming
gst-launch-0.10 v4l2src ! videoscale method=0 ! video/x-raw-yuv,width=852,height=480,framerate=(fraction)24/1 ! ffmpegcolorspace ! x264enc pass=pass1 threads=0 bitrate=900 tune=zerolatency ! flvmux name=mux ! rtmpsink location='rtmp://..../live/testing' demux. alsasrc device="hw:0,0" ! audioresample ! audio/x-raw-int,rate=48000,channels=2,depth=16 ! pulseaudiosink
Blockquote
by running the above command i got an error
gstbaseaudiosrc.c(840): gst_base_audio_src_create (): /GstPipeline:pipeline0/GstAlsaSrc:alsasrc0:
Dropped 13920 samples. This is most likely because downstream can't keep up and is consuming samples too slowly.
Blockquote
so the audio is not audible.
Help me out to solve this problem.
Thanks in advance
Ameeth
I don't understand your pipeline. What is "demux." in the middle?
The problem you are facing is because you have not seperated your elements with queues. Keep a queue before your sinks and after your sources to give the rest all seperate threads to run. It should allow get rid of the issue.
Since I don't have pulse audio or rtmp reciever in my system i have tested out the following and it works.
gst-launch-0.10 v4l2src ! ffmpegcolorspace ! queue ! x264enc pass=pass1 threads=0 bitrate=900000 tune=zerolatency ! queue ! flvmux name=mux ! fakesink alsasrc ! queue ! audioresample ! audioconvert ! queue ! autoaudiosink
You can change it accordingly and use it. The only thing I had to do to make it work and remove the error your are facing is to add the queues.
For me (Logitech c920 on Raspberry Pi3 w/ GStreamer 1.4.4) I was able to get rid of the "Dropped samples" warning by using audioresample to set the sampling rate of the alsasrc to something that flvmux liked. From gst-inspect-1.0 flvmux, it looks like flvmux only supports 5512, 11025, 22050, 44100 sample rates for x-raw and 5512, 8000, 11025, 16000, 22050, 44100 for mp4. Here's my working pipeline
gst-launch-1.0 -v -e \
uvch264src initial-bitrate=800000 average-bitrate=800000 iframe-period=2000 device=/dev/video0 name=src auto-start=true \
src.vidsrc ! video/x-h264,width=864,height=480,framerate=30/1 ! h264parse ! mux. \
alsasrc device=hw:1 ! 'audio/x-raw, rate=32000, format=S16LE, channels=2' ! queue ! audioresample ! "audio/x-raw,rate=44100" ! queue ! voaacenc bitrate=96000 ! mux. \
flvmux name=mux ! rtmpsink location="rtmp://live-sea.twitch.tv/app/MYSTREAMKEY"
I was surprised that flvmux didn't complain about getting an audio source that was at an unsupported sampling rate. Not sure if that's expected behavior.