video_encode/h264: Setting a profile causes component never to reach Executing state #161

Closed
sdroege opened this Issue Mar 11, 2013 · 9 comments

Projects

None yet

4 participants

@sdroege
sdroege commented Mar 11, 2013

Hi,

when setting the profile/level of the h264 encoder to some (probably unsupported?) value via OMX_IndexParamVideoProfileLevelCurrent, no error is reported when setting this value but the component simple refuses to go to Executing state. For example happens with OMX_VIDEO_AVCProfileBaseline and OMX_VIDEO_AVCLevel11. Setting to OMX_VIDEO_AVCProfileHigh and OMX_VIDEO_AVCLevel4 (which seems to be the default) works fine.

If a profile/level combination is not supported by the component it should instead of failing this weird way just return an error when setting it :)

In the logs this is the what happens (important difference between a working run is that the codec is unloaded in the beginning, working runs have reload=0 instead of reload=1 there):
[...]
478601.668: video_encode:1:RIL: set_port_state port 200 state 2
478601.691: video_encode:1:RIL: reload codec: vll=0, reload=1
478601.702: video_encode:1:RIL: unloading codec VLL
478601.715: video_encode:1:RIL: unloaded codec
478602.460: video_encode:1:RIL: opening encoder with w:640, h:480, br:0, fr:0x1e0000, intra:0, data: 0, data_size: 2097152
[...]
478701.931: video_encode:1:SendCommand(0,3,f457c94) State to executing
478701.967: ve_process_thread(job=0,valid_lines=0,encoder=ee91558,worker_out.r/w=0/0)
478701.991: video_encode:1:starting command 0
478702.015: video_encode:1:RIL: set_port_state port 200 state 4
478702.029: video_encode:1:RIL: take input port executing
478702.051: video_encode:1:RIL: set_port_state port 201 state 4
478702.087: ve_process_thread(job=0,valid_lines=0,encoder=ee91558,worker_out.r/w=0/0)
478702.110: video_encode:1:RIL: set_port_state port 200 state 4
478702.125: video_encode:1:RIL: open encoder
478702.958: video_encode:1:RIL: failed to open encoder: -1073807358
478702.973: video_encode:1:RIL: could not go to EXECUTING
478702.997: video_encode:1:RIL: set_port_state port 200 state 4
478703.016: video_encode:1:RIL: ve_set_port_state: clearing state change error
478721.825: ve_process_thread(job=0,valid_lines=0,encoder=ee91558,worker_out.r/w=0/0)
478721.848: video_encode:1:RIL: set_port_state port 200 state 4
478721.863: video_encode:1:RIL: take input port executing
478721.899: ve_process_thread(job=0,valid_lines=0,encoder=ee91558,worker_out.r/w=0/0)
478721.921: video_encode:1:RIL: set_port_state port 200 state 4
478721.937: video_encode:1:RIL: open encoder
478722.664: video_encode:1:RIL: failed to open encoder: -1073807358
478722.679: video_encode:1:RIL: could not go to EXECUTING
478722.701: video_encode:1:RIL: set_port_state port 200 state 4
478722.720: video_encode:1:RIL: ve_set_port_state: clearing state change error
478741.822: ve_process_thread(job=0,valid_lines=0,encoder=ee91558,worker_out.r/w=0/0)
478741.846: video_encode:1:RIL: set_port_state port 200 state 4
478741.862: video_encode:1:RIL: take input port executing
478741.897: ve_process_thread(job=0,valid_lines=0,encoder=ee91558,worker_out.r/w=0/0)
478741.920: video_encode:1:RIL: set_port_state port 200 state 4
478741.934: video_encode:1:RIL: open encoder
478742.638: video_encode:1:RIL: failed to open encoder: -1073807358
478742.653: video_encode:1:RIL: could not go to EXECUTING
478742.675: video_encode:1:RIL: set_port_state port 200 state 4
478742.694: video_encode:1:RIL: ve_set_port_state: clearing state change error
478761.820: ve_process_thread(job=0,valid_lines=0,encoder=ee91558,worker_out.r/w=0/0)
478761.842: video_encode:1:RIL: set_port_state port 200 state 4
478761.856: video_encode:1:RIL: take input port executing
478761.891: ve_process_thread(job=0,valid_lines=0,encoder=ee91558,worker_out.r/w=0/0)
478761.914: video_encode:1:RIL: set_port_state port 200 state 4
478761.929: video_encode:1:RIL: open encoder
478762.614: video_encode:1:RIL: failed to open encoder: -1073807358
478762.628: video_encode:1:RIL: could not go to EXECUTING
478762.650: video_encode:1:RIL: set_port_state port 200 state 4
478762.668: video_encode:1:RIL: ve_set_port_state: clearing state change error
478781.820: ve_process_thread(job=0,valid_lines=0,encoder=ee91558,worker_out.r/w=0/0)
478781.842: video_encode:1:RIL: set_port_state port 200 state 4
478781.857: video_encode:1:RIL: take input port executing
[and so on, never stops even after exiting the process]

@sdroege
sdroege commented Mar 11, 2013

Example based on hello_encode: http://pastebin.com/0rrGwbFd

Changing that to High/4 for example makes it work.

@popcornmix
Contributor

It looks like video_encode does a sanity check on profile which can return an error, but basically just stores the profile for when (later) the codec is opened which may fail more precisely.

I'm guessing this is an architecture decision. video_encode can support many encoders, and typically they are loaded though a dll interface (which is a slow procedure), and video_encode doesn't know if a profile is supported until it tries to open the encoder.

I guess for the Pi, with a limited number of encoder/profiles supported, we could hard code exactly what is supported into video_encode. How important is this?

@sdroege
sdroege commented Mar 15, 2013

The problem is that it does fail to open the encoder but never reports this back to userland. The transition to Executing never fails (and never happens), so userland code is just waiting forever (or until timeout).

Having that fixed would be enough IMHO, an error when setting the profile/level would be convenient but not really required.

@popcornmix
Contributor

From OpenMAX guy 2:

That should set the internal state_change_error on the port, which should trigger an error return.

In the code posted the error would be returned in the call to

printf("encode to executing...\n");
ilclient_change_component_state(video_encode, OMX_StateExecuting);

which doesn't check it's return code. Are we sure that we aren't actually returning the error?

@sdroege
sdroege commented Mar 15, 2013

Yes, the printf("looping for buffers...\n") a few lines below never happens.

@Ruffio
Ruffio commented Jun 24, 2015

@sdroege can this issue be closed?

@popcornmix
Contributor

Pretty sure this has been fixed. @sdroege can you reproduce?

@6by9
6by9 commented Jun 24, 2015

(Probably fixed by firmware commit "9970951 venc:...". It's also the change that should have addressed #254 locking things up)

@Ruffio
Ruffio commented Jun 30, 2016

@popcornmix, as there have been no response (from @sdroege) to the reproduction question from 24 June 2015, this issue should be closed

@popcornmix popcornmix closed this Jun 30, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment