Does it work if you additionally set control-rate=variable? By default it uses the component's default, which might be "disabled".

I check it with my debugs logs and gst-omx call openmax api that set up bitrate and control-rate
I changed it to constant and variable
nothing happen

I found solution
it looks like rpi openmax api need to specify targetbitrate on output port 

static gboolean
gst_omx_video_enc_set_format (GstVideoEncoder * encoder,
    GstVideoCodecState * state)
{

...........

  if (klass->set_format) {
    if (!klass->set_format (self, self->enc_in_port, state)) {
      GST_ERROR_OBJECT (self, "Subclass failed to set the new format");
      return FALSE;
    }
  }

  GST_DEBUG_OBJECT (self, "Updating outport port definition");
  if (gst_omx_port_update_port_definition (self->enc_out_port,
          NULL) != OMX_ErrorNone)
    return FALSE;


  if(self->target_bitrate != 0xffffffff){
	  GST_DEBUG_OBJECT (self, "Set up output bitrate");
	  self->enc_out_port->port_def.format.video.nBitrate = self->target_bitrate;
	  if (gst_omx_port_update_port_definition (self->enc_out_port,
			  &self->enc_out_port->port_def) != OMX_ErrorNone)
	    return FALSE;
  }

Now I think that we will need add same fix in function
static void
gst_omx_video_enc_set_property (GObject * object, guint prop_id,
    const GValue * value, GParamSpec * pspec)

Thanks, can you provide a real patch for this? It should only be done when initially updating the port definition, i.e. in gst_omx_video_enc_open() additional to the use of OMX_IndexParamVideoBitrate

Here's the patch that works for me
http://pastebin.com/8wvTaakv

Remember you should always specify both target-bitrate and control-rate.

omxh264enc target-bitrate=1000000 control-rate=variable

Is the first part of the patch really required? What happens if that code in set_property is called?

Arguably it's also a bug in the RPi gst-omx that it requires nBitrate to be set. To me it looks like this is supposed to be read-only.

https://github.com/raspberrypi/firmware/issues/193

(In reply to comment #7)
> Is the first part of the patch really required? What happens if that code in
> set_property is called?

There was an error like Bad Parameter, I'll try again later and post the exact error.

I've checked that again. It looks like I was wrong, it works without the first part of patch. In fact self->enc is NULL (component is not created yet) so that code is never executed.

So m][sko's code is enough for setting bitrate:
http://pastebin.com/2TUNyPef

Moreover I've found another way to set bitrate through OMX_IndexParamVideoBitrate parameter. This patch works good as well:
http://pastebin.com/jwAbMfv7

In original gst_omx code this parameter is set in gst_omx_video_enc_open but it has no effect since it seems to be lost if set before set_format call.

Do you have any plan sebastian how to add more parameters to omx?
every encoder have some specific parameters
I would like to add VDR frame interval that exist only in H264

I don't like current "caps solution" for encoder properties and I don't want to extend this list.

That new change definitely makes sense, is everything working as expected with this now?

commit 5ba55b6c9aad49858304a38e0ab475c1ecafd646
Author: Roman Arutyunyan <arutyunyan.roman@gmail.com>
Date:   Mon Jul 1 15:48:47 2013 +0200

    gstomxvideoenc: Set bitrate in setcaps
    
    Otherwise it gets lost whenever we configure new caps
    
    https://bugzilla.gnome.org/show_bug.cgi?id=698049

(In reply to comment #12)
> Do you have any plan sebastian how to add more parameters to omx?
> every encoder have some specific parameters
> I would like to add VDR frame interval that exist only in H264
> 
> I don't like current "caps solution" for encoder properties and I don't want to
> extend this list.

Which caps solution do you mean? Only profile and level are negotiated via the caps, other things will be handled by properties. Adding new properties for specific video codecs can easily be done in the classes for them, I don't plan on adding any right now but would accept patches to do so.

Here's the real reason of the problem.

After setting compression format eCompressionFormat = OMX_VIDEO_CodingAVC with port definition update in gst_omx_h264_enc_set_format all bitrate settings are lost. That's the way Raspberry Pi Openmax implementation works. It seems other implementations work differently.

(In reply to comment #13)
> That new change definitely makes sense, is everything working as expected with
> this now?

Yes