CODEWITHSUNDEEP
linuxcolorsrgbgstreamer
pfulop
pfulop

Reputation: 1009

gstreamer wrong colors when converting h264 to raw RGB

I have stream on one computer using this command:

gst-launch-1.0 -e v4l2src do-timestamp=true ! video264,width=1296,height=730,framerate=30/1 ! h264parse !  rtph264pay config-interval=1 ! gdppay ! udpsink host=192.168.1.116 port=5000

So the output is h264 in YU12 format. I need this format in raw RGB, so on receiver site I use:

gst-launch-1.0 -v udpsrc port=5000 ! gdpdepay ! rtph264depay ! avdec_h264 ! decodebin ! videoconvert ! video/x-raw,format=\(string\)RGB ! videoconvert !  fpsdisplaysink sync=false text-overlay=true

Which results in image with right colors, as you can see bellow: fpsdisplaysink is ok

However when I pipe this output to other program, and I tried custom one which converts rgb frames to textures and also ffplay with parameter pix_fmt rgb24, the colors are wrong and the picture is shifted in some weird way. wrong colors with piped output

What is weird is when I try bgr the red color was correct in second output the fdisplaysink one didn't change.

I am using gst-launch-1.0 --version gst-launch-1.0 version 1.4.5 GStreamer 1.4.5

Any help is appreciated.

Upvotes: 1

Views: 6613

Answers (2)

mpr
mpr

Reputation: 3378

As noted in the comments below: the "-q" option is needed to prevent gst-launch from spitting out debug info to the stdout pipe.

Ok, funny story, looks like when you specify video size in ffplay you use HEIGHTxWIDTH, and in GStreamer you use WIDTHxHEIGHT. This command works fine:

gst-launch-1.0 -q videotestsrc pattern=ball ! video/x-raw,height=320,width=240,framerate=30/1,format=RGB ! fdsink | ffplay -f rawvideo -pixel_format rgb24 -video_size 240x320 -i -

If the colors are shifted you probably have an RGB mixed up with a BGR somewhere.

You can get a list of all the ffplay pixel formats like this:

ffplay -pix_fmts

And the GStreamer pixel formats that videoconvert supports are here:

gst-inspect-1.0 videoconvert

Upvotes: 2

pfulop
pfulop

Reputation: 1009

So it turned out, it's some kind of pipeing problem. I am not sure why but pipeing via stdout to another program just shifts everything. It looks like the frames are starting on wrong byte or something. I even got to the point where the video was doing some moving picture effect where with each frame the picture was more shifted. It is not really a matter of used colorspace, it just happens to every single one.

I am not sure how to remove this problem, and this solution I am posting is not how to remove it rather than how to avoid it.

Stdout doesn't work correctly, but saving to file for instance does. So I tried using named pipe. Classic mkfifo. Doing something like this

gst-launch-1.0 -v udpsrc port=5000 ! gdpdepay ! rtph264depay ! avdec_h264 ! decodebin ! videoconvert ! video/x-raw,height=730,width=1296,framerate=25/1,format=RGB ! videoconvert ! filesink sync=false location=pipe

and than either opening the pipe, or simply redirecting it like 

cat pipe | program -

makes it working like a charm. No colors wrong, no shifted picture.

I am not sure what is the difference between named pipes and stdout pipeing in linux (I simply never had enough time to study them), I just once read there is less overhead in named ones.

Upvotes: 0

Related Questions