New hang on startup for omxh264enc

[Graham Leggett]

On 09 Dec 2016, at 7:54 AM, Sebastian Dröge <sebastian at centricular.com> wrote:

>> It seems there are two problems, the first being that
>> gst_video_decoder_negotiate() fails twice in a row. I suspect the
>> error checking is naive here, the real error is discarded and we’re
>> assuming we always fail for the same reason.
>> 
>> The second problem is that after failing, we plow on regardless with
>> the card in a disabled state, which then causes our hang further down
>> the line.
>> 
>> Does this make sense?

Looking further.

The first gst_video_decoder_negotiate() fails because the downstream omxh264enc element does not support GLMemory for some reason. It appears support for this was added to the decoder, but not the encoder. This is unfortunate but not a bug.

The second gst_video_decoder_negotiate() fails because the downstream omxh264enc element does not support RGBA. It is not clear why RGBA was chosen, given that it is not a supported input format for much of OMX. Again, in theory this is unfortunate but not a bug - or is it? Is it normal for the decoder to arbitrarily choose a single format and not leave it up to negotiation?

Given that we failed to negotiate twice, we now follow the no_egl path, however this path doesn't appear to place OMX in a state where it can renegotiate in future.

It is not yet clear to me what the no_egl path does that is different to the path that would have been taken if this RPI specific code wasn't there at all.

Despite not having successfully negotiated we plow on regardless, and the renegotiation happens because a downstream element requests I420. This renegotiation fails and thus we hang.

> Yes, thanks for the analysis. Can you add this information also to the
> bug report, and try writing a patch for that?

Happy to submit patches, but can’t until I fully understand what the correct behaviour should be first. Would it be possible to clarify what the card should be doing in this case?

To be specific, when gst_omx_video_dec_reconfigure_output_port() fails to reconfigure the output port for whatever reason, what state should the card be left in afterwards, the disabled state or the enabled state?

Regards,
Graham
—

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3240 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20161210/87547229/attachment.bin>