OMX h264 encoder

[00jmsmachado]

Hi all,

I am using Rpi and Gstreamer to stream my HD web cam with low latency. Currently I am using two different encoders for that purpose. With the omx I am getting some video quality issues and with x264 i am getting high CPU usage and low frequency.

The following is the pipe with x264 encoder

Code: Select all

gst-launch-1.0 -vv v4l2src ! videoscale !  videorate  ! videoconvert ! \
  video/x-raw,width=1280,height=720,framerate=30/1  ! x264enc bitrate=8000 ! \
h264parse !  rtph264pay pt=96 config-interval=1 ! udpsink host=$1 port=$2

The following are pipelines with low latency but with quality issues, despite the value that is use in the bitrate property.

Code: Select all

gst-launch-1.0 -vv v4l2src ! videoscale !  videorate  ! videoconvert ! \
  video/x-raw,width=720,height=480,framerate=30/1  ! omxh264enc inline-header=true periodicty-idr=1 ! \
video/x-h264,width=720,height=480,framerate=30/1,profile=high,target-bitrate=8000000,control-rate=variable,quant-i-frames=250 ! \
rtph264pay pt=96 ! udpsink host=$1 port=$2

gst-launch-1.0 -vv v4l2src  \
image/jpeg,width=1280,height=720,framerate=30/1  ! jpegdec ! videoconvert  ! \
video/x-raw,width=1280,height=720  ! videorate !  omxh264enc inline-header=true periodicty-idr=1 ! \
video/x-h264,width=1280,height=720,framerate=30/1,profile=high,target-bitrate=5000000 ! \
rtph264pay pt=96 ! udpsink host=$1 port=$2

Would be really cool to have this working with OMX and understand what is needed to have better quality.

Looking forward to have some clues from this community.

Thanks in advance,
Joao M.

[jamesh]

Hmm, not sure what is going on there. Bitrate is certainly high enough. I wonder if one of the other parameters you are setting is dropping the quality.

Try removing al the setting s except bitrate.

Another option is to use raspivid as the source, feeding the output to gstreamer pipeline. There is another recent post with some examples of this.

[00jmsmachado]

Hi james.

I did what u suggested but did not work. I removed the extra parameters and tried to increase the value a lot but nothing really changed.

Regarding the second option. I tried a few days ago but the raspvid is configured to use raspi camera and I am using USB cam.
Can you provide me the post that u mentioned?

thank u the reply

[jamesh]

Ahh, sorry, missed the bit about using a webcam.

Webcams are going to be a lot slower than the raspi cam, but not sure why the quality is bad when using the OMX encoder, but almost certainly down to the source material being provided already bad. If you dump the output of the camera direct to the display, what is the quality like?

[00jmsmachado]

The output with 'image/jpeg' is awesome and fast but networking demanding. Didn't figure it out how much yet

And Yes, it strange because with x264 plugin the quality is farly better, therefore there is something wrong and tricky with omx codec

Gonna use the GST_DEBUG to figure it out something in the negotiation phase.

Thank you for the feedback

[jwatte]

FWIW, I'm also not seeing great quality from raspivid using the built-in H.264 encoder. (This is using the Raspberry Pi camera)
I'm using all default settings, 512x288 resolution, and 30 fps, on a RPi 2. Default settings. I'm wondering what I can do to improve quality? Set I-frame interval to 1 or 2 perhaps? (Minimum size is not as important to me.)

[jamesh]

FWIW, I'm also not seeing great quality from raspivid using the built-in H.264 encoder. (This is using the Raspberry Pi camera)
I'm using all default settings, 512x288 resolution, and 30 fps, on a RPi 2. Default settings. I'm wondering what I can do to improve quality? Set I-frame interval to 1 or 2 perhaps? (Minimum size is not as important to me.)

Bitrate has the biggest effect. I-frame frequency not so much. Try setting the quantisation parameter (cannot remember if up or down), that could help.

The HW encoder is pretty good, quality issues will be down to settings or source image, not the HW.

[jwatte]

The bitrate it chooses to output is much less than the maximum bitrate. I leave it at the default, but then only give it the small images, so I assume it should do great. I'll play with the quantization.

[Phill76]

Hello
i have exactly the same issue : low quality even though bitrate is high. have you found a solution ?
thanks a lot

[DivideZAR]

I'm getting the same result.
High FPS but terrible video quality.

Software encoding still giving better video results.

Anyone know if there is any settings I'm missing ?

Or is the hardware assisted encoding just bad ?

[jamesh]

I'm getting the same result.
High FPS but terrible video quality.

Software encoding still giving better video results.

Anyone know if there is any settings I'm missing ?

Or is the hardware assisted encoding just bad ?

HW encoding is fine. Check out from footage taken with the Pi camera to see what it is capable of.

Software encoding can often produce better results because it is not trying to encode in real time - it can add P frames for example, which cannot be done well in real time encoding, or it can spend a lot more time on various stages of the encode process to give better results.

However, with a high enough bit rate the quality should be very good with the HW encoder , so I'd suggest some sort of setup issue.

[6by9]

Software encoding can often produce better results because it is not trying to encode in real time - it can add P frames for example, which cannot be done well in real time encoding, or it can spend a lot more time on various stages of the encode process to give better results.

Cough - B frames. P frames are supported by the hardware.

Looking at the original post, "periodicity-idr=1" sounds like you're asking for just I frames - that'll seriously limit the compression that can be applied to not much better than Mjpeg!

[DivideZAR]

@ Jamesh

Thanks , I´ll try that out

[jamesh]

Software encoding can often produce better results because it is not trying to encode in real time - it can add P frames for example, which cannot be done well in real time encoding, or it can spend a lot more time on various stages of the encode process to give better results.

Cough - B frames. P frames are supported by the hardware.

Looking at the original post, "periodicity-idr=1" sounds like you're asking for just I frames - that'll seriously limit the compression that can be applied to not much better than Mjpeg!

Damn, always get those the wrong way round. I keep thinking of P as previous, whereas I should think of B as before.

[jwatte]

P means Previous -- the next frame is predicted based on the previous frame.
B means Bidirectional -- it needs both the previous and next frame. You can do this in hardware only if you're OK with several frames of latency, and the memory to store all those frames.

[jwatte]

For what it's worth (old thread, but still shows up on Google,) I find that for smaller images, playing with the quantization parameter is better for getting high quality. The h264 "best practices" generally recommend quantization in the 20-40 range for "other" codec implementations, but I've found that I have to push it down to 15 or even 10 to get great-quality images. On the flip side, this doesn't consume as much data as I would have feared, so perhaps this is just a different tuning scale.

[drgeoff]

P means Previous -- the next frame is predicted based on the previous frame.
B means Bidirectional -- it needs both the previous and next frame. You can do this in hardware only if you're OK with several frames of latency, and the memory to store all those frames.

What you have written is not strictly accurate.

P means predicted from a past frame, not necessarily the previous frame. Indeed if you have B frames, the P frames cannot be predicted from the previous frames.

Bidirectional is predicted from a mix of a past frame and a future one. Not necessarily previous and next.

And why the mention of 'hardware'? Hardware or software, employing B frames will introduce additional end to end delay and a requirement to store more frames.

[jwatte]

You are technically correct, which is the best kind of correct!