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
Related
I'm using mediasoup create plaintransport then I forward from udpsrc to tcpserversink like this:
gst-launch-1.0 udpsrc port=57616 caps="application/x-rtp,media=(string)audio,clock-rate=(int)48000,payload=(int)100,encoding-name=(string)OPUS,ssrc=(uint)613744965" ! rtpopusdepay ! opusdec ! tcpserversink port=23333 host=0.0.0.0
on Client:
gst-launch-1.0 tcpclientsrc port=23333 host=11.22.33.44 ! rawaudioparse ! decodebin ! audioconvert ! audioresample ! autoaudiosink
the problems is audio stream always delay 2,3 and increase time by time. and I have warning like this
gstrtpbasedepayload.c(505): gst_rtp_base_depayload_handle_buffer (): /GstPipeline:pipeline0/GstRTPOpusDepay:rtpopusdepay0:
Received invalid RTP payload, dropping
WARNING: from element /GstPipeline:pipeline0/GstRTPOpusDepay:rtpopusdepay0: Could not decode stream.
please help me solve this and improve stream delay problems
I have a working gstreamer pipeline, using videobalance to adjust the contrast and brightness of a camera stream, the output of which is displayed on screen:
gst-launch-1.0 nvarguscamerasrc sensor-id=0 saturation=0 !
"video/x-raw(memory:NVMM),width=1920,height=1080,framerate=30/1" !
nvvidconv ! videobalance contrast=1.5 brightness=-0.3 ! nvoverlaysink
I want to do the same again, but this time record the camera stream to a file. I tried adding the videobalance element to the pipeline suggested by the authors of the drivers I'm using (which works fine otherwise):
gst-launch-1.0 nvarguscamerasrc sensor-id=0 saturation=0 !
"video/x-raw(memory:NVMM),width=1920,height=1080,framerate=30/1" !
nvv4l2h264enc ! videobalance contrast=1.5 brightness=-0.3 ! h264parse !
mp4mux ! filesink location=test.mp4 -e
But, I get the error:
WARNING: erroneous pipeline: could not link nvv4l2h264enc0 to videobalance0
Any suggestions for where I'm going wrong and/or possible solutions would be greatly appreciated.
NVidea encoders use NVMM memory, so it can't directly connect encoder to videobalance. Just adding simple video convert will solve the problem:
gst-launch-1.0 nvarguscamerasrc sensor-id=0 saturation=0 !
"video/x-raw(memory:NVMM),width=1920,height=1080,framerate=30/1" !
nvv4l2h264enc ! videoconvert ! videobalance contrast=1.5 brightness=-0.3 ! h264parse !
mp4mux ! filesink location=test.mp4 -e
I have streamed video via vlc player over rtsp and then I have displayed this video via gstreamer-0.10. However, While vlc was streaming video over rtsp, I suddenly lost stream in the first minute of stream before end of stream.
I have used following pipeline:
GST_DEBUG=2 gst-launch-0.10 rtspsrc location=rtsp://127.0.0.1:8554/test !
gstrtpjitterbuffer ! rtph264depay ! ffdec_h264 ! videorate ! xvimagesink
sync=false
I have got following output:
rtpjitterbuffer.c:428:calculate_skew: delta - skew: 0:00:01.103711536 too big, reset skew
rtpjitterbuffer.c:387:calculate_skew: backward timestamps at server, taking new base time
Got EOS from element "pipeline0".
Execution ended after 59982680309 ns.
Setting pipeline to PAUSED ...
gst_rtspsrc_send: got NOT IMPLEMENTED, disable method PAUSE
How to fix this problem ?
I have found solution. I have used rtspt://... instead of rtsp://... to enforce TCP instead of UDP.
gst-launch-0.10 rtspsrc location= rtspt://127.0.0.1:8554/test ! gstrtpjitterbuffer ! rtph264depay ! ffdec_h264 ! xvimagesink sync=false
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)
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.