StatCounter

Saturday, April 20, 2013

Enabling hardware h264 encoding with gstreamer on the Raspberry Pi


This should be helpful for those trying to use the hardware h264 encoder inside the BCM2835.

The repo already contains precompiled binaries for the raspberry pi, so this will be much faster than building gst-omx from source. We should thank [Defiant] for this.




Result:


You can now enjoy your well deserved omxh264enc video sink.


19 comments:

Anonymous said...

If you do a gst-inspect-1.0 and don't find the "omx" plugins, you may need to delete ~/.cache/gstreamer-1.0, where a cache of the gstreamer 1.0 plugins reside. My "omx" plugins were blacklisted, so removing that path regenerated the plugins cache inclusive of the "omx" plugins.

madduck said...

Thank you for doing all this work. Would you be interested in integrating this with Raspbian properly?

Anonymous said...

Th Raspbian people have no plans to integrate jessie-packages:
http://www.raspberrypi.org/phpBB3/viewtopic.php?p=291702#p291702

"Manis B" said...

@Anon @madduck:

I think they will eventually HAVE to integrate it with raspian jessie at some point or the other. gst-omx is already part of gstreamer-1.x. The logic of staying with gstreamer-0.10.x series is absurd for the raspi, because of the lack of OpenMAX IL support and hence the hardware encoder goodies.

z said...

Everything works great, but there is a nasty bug when using omxh264enc with target-bitrate and control-rate (i.e. if you want to control the quality of the encoding)

e.g.

when you run :
gst-launch-1.0 filesrc location=test.mjpeg ! jpegparse ! jpegdec ! omxh264enc target-bitrate=500000 control-rate=2 ! avimux ! filesink location=/tmp/test.avi

You get the following error :


ERROR: Pipeline doesn't want to pause.
ERROR: from element /GstPipeline:pipeline0/GstOMXH264Enc-omxh264enc:omxh264enc-omxh264enc0: Could not initialize supporting library.

"Manis B" said...

@z:

I had a feeling that the openmax api for the raspi has the bitrates hard coded in specific 'steps'.

Either that or there is indeed a bug with omxh264enc, which I think is unlikely.

z said...

Hmm, good point. Thanks! Where can I find the default settings? Has anyone actually encoded high quality h264 streams using this library? The default settings yield horrible quality because the bitrate is set WAY too low.

z said...

Oops, I meant to say where can I find the hard coded step sizes and working setting that enable encoding at higher bitrates?

Great work by the way!

"Manis B" said...

I am just guessing that there are hard steps involved, but I am not sure. I guess some trial and error will be necessary to verify that..

And thanks, but this one trick is not exactly mine. I merely compiled the data from different online sources because I felt it could be useful. :)

z said...

Ok, I think I got one step closer. With the option --gst-debug 3 I get additional debugging info. Whenever I try to set control-rate or target-bitrate parameters on omxh264enc I get the following error :

omxvideoenc gstomxvideoenc.c:307:gst_omx_video_enc_open: Failed to set bitrate parameters: Version mismatch (0x8000100f)

There could indeed be a real problem here. The next step is to look at the actual source code and see what the heck is going on.

z said...

Alright, more debug info using --gst-debug omx*:5.

The complete command line is :

gst-launch-1.0 --gst-debug omx*:5 filesrc location=test.mjpeg ! jpegparse ! jpegdec ! omxh264enc target-bitrate=500000 ! avimux ! filesink location=/tmp/test2.avi


...And you get the following debug info :


0:00:00.440415303 2917 0x19d9240 DEBUG omx gstomx.c:129:gst_omx_core_acquire: Successfully loaded core '/opt/vc/lib/libopenmaxil.so'
0:00:00.443486186 2917 0x19d9240 DEBUG omx gstomx.c:144:gst_omx_core_acquire: Successfully initialized core '/opt/vc/lib/libopenmaxil.so'
0:00:00.447060051 2917 0x19d9240 DEBUG omx gstomx.c:653:gst_omx_component_new: Successfully got component handle 0x1a072a0 (OMX.broadcom.video_encode) from core '/opt/vc/lib/libopenmaxil.so'
0:00:00.449518958 2917 0x19d9240 DEBUG omx gstomx.c:807:gst_omx_component_get_state: Getting state of video_encode
0:00:00.451061899 2917 0x19d9240 DEBUG omx gstomx.c:884:gst_omx_component_get_state: video_encode returning state Loaded
0:00:00.453213818 2917 0x19d9240 DEBUG omx gstomx.c:906:gst_omx_component_add_port: video_encode adding port 200
0:00:00.454697761 2917 0x19d9240 DEBUG omx gstomx.c:997:gst_omx_component_get_parameter: Getting video_encode parameter at index 0x02000001
0:00:00.456785682 2917 0x19d9240 DEBUG omx gstomx.c:1000:gst_omx_component_get_parameter: Got video_encode parameter at index 0x02000001: None (0x00000000)
0:00:00.457898640 2917 0x19d9240 DEBUG omx gstomx.c:906:gst_omx_component_add_port: video_encode adding port 201
0:00:00.459316586 2917 0x19d9240 DEBUG omx gstomx.c:997:gst_omx_component_get_parameter: Getting video_encode parameter at index 0x02000001
0:00:00.460966523 2917 0x19d9240 DEBUG omx gstomx.c:1000:gst_omx_component_get_parameter: Got video_encode parameter at index 0x02000001: None (0x00000000)
0:00:00.461596499 2917 0x19d9240 DEBUG omx gstomx.c:997:gst_omx_component_get_parameter: Getting video_encode parameter at index 0x06000004
0:00:00.463281435 2917 0x19d9240 DEBUG omx gstomx.c:1000:gst_omx_component_get_parameter: Got video_encode parameter at index 0x06000004: None (0x00000000)
0:00:00.464341395 2917 0x19d9240 DEBUG omx gstomx.c:1016:gst_omx_component_set_parameter: Setting video_encode parameter at index 0x06000004
0:00:00.465720342 2917 0x19d9240 DEBUG omx gstomx.c:1019:gst_omx_component_set_parameter: Set video_encode parameter at index 0x06000004: Version mismatch (0x8000100f)
0:00:00.466747303 2917 0x19d9240 ERROR omxvideoenc gstomxvideoenc.c:307:gst_omx_video_enc_open: Failed to set bitrate parameters: Version mismatch (0x8000100f)


Can it be header file mismatch or the wrong version of .so file gets loaded???

z said...

By the way, I am using the latest Raspbian :

2013-02-09-wheezy-raspbian.zip

z said...

OK, bug confirmed :

http://www.raspberrypi.org/phpBB3/viewtopic.php?f=38&t=6852&p=352692&hilit=omxh264enc#p352692


On the same thread, may 14th, someone posted that he found a solution to a related problem and that he will post a patch to gst-omx

"gst-omx encoder don't set up encoder bittrate correctly( you will get some default output bitrate ).
I found solution and I will post patch to gst-omx"

Anonymous said...
This comment has been removed by a blog administrator.
Anonymous said...

No fbdevsink for me on last Rasbian image : not find by gst-inspect and no libgstfbdevsink.so in /usr/lib/arm-linux-gnueabihf/gstreamer-1.0/

Anonymous said...

Use eglglessink instead of fbdevsink

Joe Wareham said...
This comment has been removed by a blog administrator.
Markus Fritsche said...

I had problems transcoding VDR recorded transport streams (Audio delay to video is high on my DVB-Streams) - the resulting mkv (matroska) files were not in sync. I figured there is a problem with the MKV container implementation in this distribution. I went and compiled gstreamer-1.2 myself, and got rid of that problem.

Laese said...

Sketch Arduino for Wifly RN-XV modem configuration without Wifly library and
with front-end: https://dl.dropboxusercontent.com/u/101922388/WiflySanUSB.