Limits of the Gst-omx OpenMAX IL H.264 encoder on the Raspberry Pi 3?

[James Cameron]

On Mon, Jul 02, 2018 at 08:37:56AM +0000, Matthew Thyer wrote:
> [...]
> I'm now wanting to understand the following issues:
> 
>   ● The available resolutions for my video source

G'day Matthew,

For the ov5647, a good information source is the sensor datasheet,
which shows the registers can be programmed for almost any image
dimensions up to the resolution of the sensor array, 2592x1944.

https://cdn.sparkfun.com/datasheets/Dev/RaspberryPi/ov5647_full.pdf

This may be bandwidth constrained by the cable, the bus, the bus
controller or the host processor.

Another source of information is the kernel driver, both in source
code and exposed interfaces.  It is common for a kernel driver to only
implement popular resolutions, despite what the sensor can do.

>   ● The available frame rates for my video source

For the ov5647 sensor itself, there's a list of maximum frame rates by
resolution; 2592x1944 at 15, 1080p at 30, 960p at 45, 720p at 60, 640x480 at 90, and
320x240 at 120.

However, for a dark scene the automatic exposure control (when
configured) may force an integration time that is beyond the time
between frames at your preferred rate, causing the frame to be
delayed.

If later parts of your pipeline cannot cope with variable frame rate,
add the videorate element.

>   ● How to intelligently choose the target-bitrate parameter of the OpenMax
>     H.264 encoder

I've no comment on the encoder; I just wanted to dump my brain for you
on the OmniVision sensor IP.  ;-)

>   ● The meaning of the control-rate parameter of the OpenMax H.264 encoder
>   ● The H.264 encoding profiles that are supported by the OpenMax H.264 encoder
>     and in what scenarios I would want to use each of them
> 
> Additionally, I need to understand whether there are particular hardware
> platform configurations required to support different configurations (e.g.
> gpu_mem in /boot/config.txt).
> 
> Ideally, I'd like to be able to programmatically assess whether a given
> configuration is viable.
> 
> It would also be great if I could query the camera for its capabilities if this
> is possible.

You could read the camera registers, I guess.  I've not tried it on
this sensor.  But reading the v4l2 layer interfaces would be handy to
assess the driver implementation.

> Does anyone have any pointers to assist with my problem?
> 
> ---
> 
> Matthew Thyer
> 
> (08) 8313 9283
> 
> 4.38 Ingkarni Wardli
> 
> Adelaide University
> 

-- 
James Cameron
http://quozl.netrek.org/