Hardware encoding; hello_encode YUV420P issue

Hello,

Trying to track down an issue I'm having when modifying the hello_encode example file. When compiled as-is, it works and the test image is visible. I'm attempting to modify the code to use real video data, but am running int an odd issue.

In the code, I've changed this line:

Code: Select all

def.format.video.eColorFormat = OMX_COLOR_FormatYUV420PackedPlanar;

to this:

Code: Select all

def.format.video.eColorFormat = OMX_COLOR_FormatYUV420Planar;

When the resulting binary is executed, it stops after the second print_def statement, with the following output:

Code: Select all

Port 200: in 1/1 15360 16 disabled,not pop.,not cont. 160x64 160x64 @1966080 20
Port 200: in 1/1 15360 16 disabled,not pop.,not cont. 640x480 640x480 @1966080 19

Any ideas on this one?

[dom]

OMX_COLOR_FormatYUV420Planar is not supported. What's the problem with OMX_COLOR_FormatYUV420PackedPlanar?

Interesting! How did you see that it is not supported? Does it have to do with the encoder chip itself, or the firmware loaded onto it?

Given the limited processing power on the Pi, I need a matching format supported both by the Pi's encoder and the v4l2 API / device. I'm going from this list:

http://linuxtv.org/downloads/v4l-dvb-apis/

I don't see YUV420 Packed Planar as an option.

What could be used instead? Or, is there a way to add support for YUV420P on the Pi's encoder?

[dom]

V4L2_PIX_FMT_YUV420 looks right to me for V4L side. And on openMAX side:
YUV420PackedPlanar : packed per payload in planar slices

Make sure your image size has a width with a multiple of 32 and height a multiple of 16.
Suppose you chose 320x240. Then the buffer should contain:
76800 bytes of Y data at offset 0
19200 bytes of U data at offset 76800
19200 bytes of V data at offset 96000.

At worst you will have to memcpy the Y, U and V buffers to be a contiguous block (but it may be possible to persuade V4L to do that for you).

When I capture an image from the V4L2 device in YUV420P, the buffer is filled to L x W x 2 bytes. Similarly, the Pi buffer is only L x W x 1.5 bytes.

I had hoped to find a solution that allowed direct encoding without additional manipulation by the Pi's CPU.

None of the Packed Planar formats supported by the V4L2 API seem to appear in the list for the Pi.

Also, are you aware of a document that shows the supported formats for the Pi?

[dom]

OMX_IndexParamPortDefinition: 200
Query / set the format of the raw video frames. eColorFormat must be

Code: Select all

OMX_COLOR_FormatYUV420PackedPlanar
OMX_COLOR_FormatYUV420PackedSemiPlanar
OMX_COLOR_Format16bitRGB565
OMX_COLOR_Format24bitBGR888
OMX_COLOR_Format32bitABGR8888

nSliceHeight must be the same as nFrameHeight rounded up to the nearest multiple of 16. nStride must be a multiple of 32. Additional proprietary formats are allowed.
This port also accepts being tunnelled with an image domain output port, and will convert fields as necessary.

YUV420 should have U and V subsampled by a factor of two in width and height, so a YUV420 array should be LxWx1.5 bytes.
http://en.wikipedia.org/wiki/YUV

What's the problem with OMX_COLOR_FormatYUV420PackedPlanar?

The problem is that almost all cheap USB cameras support only V4L2_PIX_FMT_YUYV which is YUV 4:2:2 (not planar). So there is no straight forward solution to put the data into RasPi HW OpenMax interface. Either data must be processed by SW in libv4l2 (still SW) or in user application. v4l does not support format conversion in kernel.

I'm getting the same problem and after some tries I see that there is no possibility to get the HW encoding from cheap USB camera in realtime.

Is there possibility to transcode the format using current OpenMax or include YUV 4:2:2 Packet support into RaspPi firmware ?