User avatar
peepo
Posts: 306
Joined: Sun Oct 21, 2012 9:36 am

camera input port 73: 0x80001005 bad parameter

Mon May 12, 2014 10:39 am

OMX error: Failed to free buffer for camera input port 73: 0x80001005 bad parameter
any clues please?
did anything change recently?

$ raspivid -t 5000 displays as expected

completely new clean build on new SD card using
https://github.com/peepo/openGL-RPi-tutorial
encode_OGL example

this had been working, on various boxes
until a very recent rpi-update**.

**this is slightly tenuous as:
a userland patch incorporated mmal
and we changed the tutorial build process

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 9909
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: camera input port 73: 0x80001005 bad parameter

Mon May 12, 2014 11:17 am

AFAIK nothing significant has changed there.

But why are you playing with the clock port of the camera component?
None of the components you appear to be playing with (camera, egl_render, and null_sink) really have any use for timestamping of the buffers, and clock components are always a pain in the neck. (It's one of the reasons that MMAL didn't reuse the OMX clock architecture - it was just too unwieldy). You'd be as well off just leaving camera port 73 disabled and not having a clock component at all.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

User avatar
gagle
Posts: 82
Joined: Fri Feb 14, 2014 6:54 pm
Contact: Website

Re: camera input port 73: 0x80001005 bad parameter

Mon May 12, 2014 11:39 am

6by9 wrote:AFAIK nothing significant has changed there.

But why are you playing with the clock port of the camera component?
None of the components you appear to be playing with (camera, egl_render, and null_sink) really have any use for timestamping of the buffers, and clock components are always a pain in the neck. (It's one of the reasons that MMAL didn't reuse the OMX clock architecture - it was just too unwieldy). You'd be as well off just leaving camera port 73 disabled and not having a clock component at all.
Haha, that's completely true!. The clock component it's incredible hard to use up to the point that I'm not able to simply set the timestamp of the capture in the jpeg metadata, it's muich easier if you simply call to gettimeofday() and set the metadata labels manually.

I also recommend to not use the port 73. The h264 encoder works well without it.

User avatar
peepo
Posts: 306
Joined: Sun Oct 21, 2012 9:36 am

Re: camera input port 73: 0x80001005 bad parameter

Mon May 12, 2014 12:04 pm

oops: thank you for the prompt responses,

not to labour the point:

I know nothing of OMX,
I took drhastings openGL-openMAX code,
the only one I could find using camera,
and am busy making reduced test case
mostly openGL removed

these are intended to be reduced test cases.
time stamp not required
so if you can tell me what to delete...

// commenting out references for 73 just now...

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 9909
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: camera input port 73: 0x80001005 bad parameter

Mon May 12, 2014 12:17 pm

Haha, that's completely true!. The clock component it's incredible hard to use up to the point that I'm not able to simply set the timestamp of the capture in the jpeg metadata, it's muich easier if you simply call to gettimeofday() and set the metadata labels manually.
Clock timestamps are NOT the time of day - it's a signed 64bit value representing the time in us and is controlled by the client. It's used for timestamping frames within a video clip (whether on encode or for scheduling on decode), and is normally set to 0 at the start of encoding. The JPEG encoder doesn't even look at it when forming the EXIF data.
I also recommend to not use the port 73. The h264 encoder works well without it.
That's where I would disagree if using IL rather than MMAL to do video encode.
The clock component should allow for accurate A/V sync if both audio and video sides hook into it (normally audio as master and video slaved to it - it compensates for clock drift too). You can also have the clock running at other than realtime to record slow-mo or fast-mo without any external processing of timestamps (one of our old tests was doing synchronised A/V slow-mo all totally with IL with no client intervention once the pipes were configured). Lots of flexibility, but also a right pain in the proverbial to get right.

The cheat that MMAL pulls with camera is to use the custom parameter OMX_IndexParamCommonUseStcTimestamps to allow timestamping buffers in the absence of a clock component, but it's not as flexible (no way to do things like pausing the recording to resume again without a change in timestamp, add offsets, scaled time, or a raft of other things).
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

User avatar
gagle
Posts: 82
Joined: Fri Feb 14, 2014 6:54 pm
Contact: Website

Re: camera input port 73: 0x80001005 bad parameter

Mon May 12, 2014 12:25 pm

Try to comment the lines 913-915 of video.c. If you tunnel the clock-camera components, you don't need to free the buffer, it it's released automatically by the source component (the clock in this case).

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 9909
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: camera input port 73: 0x80001005 bad parameter

Mon May 12, 2014 12:32 pm

peepo wrote:oops: thank you for the prompt responses,

not to labour the point:

I know nothing of OMX,
I took drhastings openGL-openMAX code,
the only one I could find using camera,
and am busy making reduced test case
mostly openGL removed
The OMX IL spec is published by Khronos and free for anyone to read - http://www.khronos.org/registry/omxil/s ... cation.pdf
I'd recommend a read of at least the basics to get an idea of how it is meant to work. I believe it's only officially supported on RaspberryPi for video decode as that is the interface XBMC and the like already had, although it may be using image_encode and image_decode for thumbnails too.
All "official" camera support is based on MMAL (gagle has chosen to use OpenMaxIL for his API, but has been made fully aware that support will be minimal from us).
these are intended to be reduced test cases.
time stamp not required
so if you can tell me what to delete...

// commenting out references for 73 just now...
Remove any calls referring to the clock component port 80 and camera port 73. You could probably remove the clock component completely if you're wanting reduced test cases - it isn't adding anything for you.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

User avatar
peepo
Posts: 306
Joined: Sun Oct 21, 2012 9:36 am

Re: camera input port 73: 0x80001005 bad parameter

Mon May 12, 2014 12:36 pm

removed 913-915 as part of 73 purge

have not yet removed clock references...

get:
OMX error: Failed to switch state of the camera component to executing: 0x80001000 insufficient resource

i do recognise that without better understanding this may go nowhere,

would be very nice to have a simple openGL+camera+openMAX
and we had one...

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 9909
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: camera input port 73: 0x80001005 bad parameter

Mon May 12, 2014 12:42 pm

gagle wrote:Try to comment the lines 913-915 of video.c. If you tunnel the clock-camera components, you don't need to free the buffer, it it's released automatically by the source component (the clock in this case).
I actually can't see anything initialising ctx.camera_ppBuffer_in, and it is never passed to OMX_UseBuffer or from OMX_AllocateBuffer, so calling OMX_FreeBuffer on it would appear to be an error anyway.

Going the whole hog, you're wanting to remove lines 761 to 770, 870 to 873, 892 to 895, and 913 to 915.

(Minor correction: the buffer isn't always allocated by the source component in a tunnel - OMX_IndexParamCompBufferSupplier allows configuration of who allocates the buffer within a tunnel.)
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

User avatar
peepo
Posts: 306
Joined: Sun Oct 21, 2012 9:36 am

Re: camera input port 73: 0x80001005 bad parameter

Mon May 12, 2014 12:57 pm

6by9 this is very kind, enacting ~:"

unfortunately still encoding to black...
no error messages, but,
could this be the culprit:

Port 240 is input, disabled, buffers wants:3 needs:1, size:0, pop:0, aligned:16
Video type:
Width: 0
Height: 0
Stride: 0
SliceHeight: 0
Bitrate: 0
Framerate: 0.00

Return to “Camera board”