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.
Thank you for doing all this work. Would you be interested in integrating this with Raspbian properly?
Th Raspbian people have no plans to integrate jessie-packages:http://www.raspberrypi.org/phpBB3/viewtopic.php?p=291702#p291702
@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.
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.aviYou 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.
@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.
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.
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!
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. :)
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.
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_encode0:00:00.451061899 2917 0x19d9240 DEBUG omx gstomx.c:884:gst_omx_component_get_state: video_encode returning state Loaded0:00:00.453213818 2917 0x19d9240 DEBUG omx gstomx.c:906:gst_omx_component_add_port: video_encode adding port 2000:00:00.454697761 2917 0x19d9240 DEBUG omx gstomx.c:997:gst_omx_component_get_parameter: Getting video_encode parameter at index 0x020000010: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 2010:00:00.459316586 2917 0x19d9240 DEBUG omx gstomx.c:997:gst_omx_component_get_parameter: Getting video_encode parameter at index 0x020000010: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 0x060000040: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 0x060000040: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???
By the way, I am using the latest Raspbian :2013-02-09-wheezy-raspbian.zip
OK, bug confirmed :http://www.raspberrypi.org/phpBB3/viewtopic.php?f=38&t=6852&p=352692&hilit=omxh264enc#p352692On 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"
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/
Use eglglessink instead of fbdevsink
Hi,Sorry I couldn't find your name anywhere on the website - my apologies!I came by i/o blog and the quality of content really grabbed my attention, so I thought I’d drop you a message. It’s great seeing so much Raspberry Pi stuff, and that’s what we’re into!I’m currently collaborating with Premier Farnell, a top electronics tech company, and we’d love to know if you’d be interested in mentioning PF and/or some of its products on your website.At the moment, we are able to provide bespoke content written by Premier Farnell’s very own tech copywriters at your request. Also, in the coming weeks we will also be expanding the scope of our collaborations to include things such as product testing, reviews, organising tech/electronics networking and events, and providing you with access to experts for Q&A. We could also potentially send products for giveaways on your site or offer exclusive discounts for your readership, which could stir up some interest.As I say, good content is available right now, but we can do the other stuff in the near future.Let me know what you think, and if you have any questions, fire away!Best,Joe
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.
Sketch Arduino for Wifly RN-XV modem configuration without Wifly library and with front-end: https://dl.dropboxusercontent.com/u/101922388/WiflySanUSB.
Post a Comment