gst-launch camera get wrong color space - colors

I am using the following command to review the Raspberry Pi camera with Tinker board(Tinker OS V2.0.8).
gst-launch-1.0 v4l2src device=/dev/video0 !
video/x-raw,format=NV12,width=640,height=480 ! videoconvert !
autovideosink
But the colour of the images show green as below(suppose be white):
So what suppose be the problem?
Is there any way to adjust the colour-balance?
I'm guessing the problem is about the format of the output images, which gives NV12 that makes image look greenly.

Problem solved:
Base on the tutorial https://tinkerboarding.co.uk/wiki/index.php?title=CSI-camera
After Tinker OS V2.0.8 using following command to stream video:
gst-launch-1.0 rkcamsrc device=/dev/video0 io-mode=4 isp-mode=2A
tuning-xml-path=/etc/cam_iq/IMX219.xml ! videoconvert !
video/x-raw,format=NV12,width=1800,height=960 ! rkximagesink

Related

Get image from csi camera on google dev board

I am trying to get an image with coral camera on dev board mini, but have a problem to construct right gstreamer pipeline. I am trying this one
gst-launch-1.0 v4l2src device='/dev/video1' num_buffers=1 ! video/x-raw,format=YUY2,width=640,height=480,framerate=30/1 ! jpegenc ! filesink location=image.jpg
gst-launch-1.0 v4l2src device='/dev/video1' num_buffers=1 ! video/x-raw,format=YUY2,width=640,height=480,framerate=30/1 ! videoconvert !jpegenc ! filesink location=image.jpg
but I am getting only green image. How to construct the proper pipeline?

Using videobalance to adjust contrast and brightness in gstreamer pipeline saving camera stream to file

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

How to solve a RAW stream playback problem with GStreamer and VAAPi

I am currently experiencing a small problem with GStreamer, here are more details:
Configuration:
Intel i7-6700
Intel HD Graphics 530
Ubuntu 18.04 LTS
GStreamer1.0
VAAPI plugin
I receive a UDP stream from a video source, this stream is sent in RAW UYVY format. Here is my command line to decode it:
gst-launch-1.0 -v udpsrc port="1234" caps = "application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)RAW, sampling=(string)YCbCr-4:2:2, depth=(string)8, width=(string)1920, height=(string)1080, colorimetry=(string)BT709-2, payload=(int)96, ssrc=(uint)1188110121, timestamp-offset=(uint)4137478200, seqnum-offset=(uint)7257, a-framerate=(string)25" ! rtpvrawdepay ! decodebin ! queue ! videoconvert ! xvimagesink
Problem as we can see on the screenshot below, the CPU load (right) is far too high for this kind of task and we can see the GPU load (left) which is almost zero.
To overcome this problem, I want to use the VAAPI graphics acceleration as I did in a previous project with H264 of which here is the command line below:
gst-launch-1.0 -v udpsrc port=1234 caps= "application/x-rtp, media\=(string)video, clock-rate=(int)90000, encoding-name=(string)H264, packetization-mode=(string)1, profile-level-id=(string)640028, payload=(int)96, ssrc=(uint)2665415388, timestamp-offset=(uint)3571350145, seqnum-offset=(uint)18095, a-framerate=(string)25" ! rtph264depay ! queue ! vaapih264dec low-latency=1 ! autovideosink
The line above works perfectly and the CPU has almost no more loads. So I adapt this command line to use it with a RAW stream, here is the command:
gst-launch-1.0 -v udpsrc port="1234" caps = "application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)RAW, sampling=(string)YCbCr-4:2:2, depth=(string)8, width=(string)1920, height=(string)1080, colorimetry=(string)BT709-2, payload=(int)96, ssrc=(uint)1188110121, timestamp-offset=(uint)4137478200, seqnum-offset=(uint)7257, a-framerate=(string)25" ! rtpvrawdepay ! vaapidecodebin ! videoconvert ! xvimagesink
It is the same line as the one at the beginning but I changed the element decodebin by vaapidecodebin as I had replaced avdec_h264 by vaapih264dec for my H264 stream. Unfortunately it doesn't work and I end up with this error:
WARNING: wrong pipeline: unable to connect rtpvrawdepay0 to vaapidecodebin0
How I can solve this problem? Do you have any leads to solve this problem?
What exactly are you trying to accelerate here? The CPU load is probably either due to the videoconvert as this is run in software to convert UYVY into a format your renderer supports (Hopefully that's another YUV format and not RGB) or it is the data transfer of the uncompressed data from CPU memory to GPU memory.
Note that transferring uncompressed image data is a much higher data rate than compressed H.264 video.
If you think the videoconvert is the expensive part you may want to try to use OpenGL for convert and displaying: .. ! glupload ! glcolorconvert ! glimagesink.
Maybe vaapipostproc can help you with color conversion if you don't want to go the OpenGL route.

udpsink doesnt seem to stream anything but filesink works

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.

Gstreamer audio problem on embedded linux

I work on embedded linux. I want play video with minimum CPU. So after I completed compile, I tried play video with mplayer and gstreamer. Mplayer use CPU avarage %10-20. I want to obtain this perform on gstreamer. So I tried these command:
1- gst-launch filesrc location=video_path.mpeg ! mpegdemux ! mpeg2dec ! autovideosink
2-gst-launch-0.10 filesrc location=video_path.mpeg ! dvddemux ! mpegvideoparse ! mpeg2dec ! xvimagesink
These commands use avarage %10-20 CPU. This number that I want number. But audio did not work with these command. I tried added audio element but I could not achieve.
I also tried gst-launch-1.0 playbin uri=file:///video_path.mpeg. Audio work with this command but CPU usage is so high and I don2t prefer this.
How can I work audio with 1 or 2 commands?
1- gst-launch filesrc location=video_path.mpeg ! mpegdemux ! mpeg2dec
! autovideosink
2-gst-launch-0.10 filesrc location=video_path.mpeg ! dvddemux !
mpegvideoparse ! mpeg2dec ! xvimagesink
With the above two pipelines you are asking gtreamer to just play video, as a result you aren’t getting any audio.
gst-launch filesrc location=video_path.mpeg ! mpegdemux name=demuxer
demuxer. ! queue ! mpeg2dec ! autovideosink demuxer. ! queue ! mad !
audioconvert ! audioresample ! autoaudiosink
The above pipeline should play both audio and video.
Note: If you have support for hardware decoding that would reduce further CPU usage.

Resources