New hang on startup for omxh264enc

[Sebastian Dröge]

On Sat, 2016-12-10 at 15:04 +0200, Graham Leggett wrote:
> 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.

Yes, adding support for EGLImage to the encoder is IIRC not possible on
the RPi though.

> 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?

That sounds like a bug, like a left-over from the trying of the
egl_render path. We try to set a format that downstream supports in
gst_omx_video_dec_negotiate():
  param.eColorFormat = m->type;

> 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.

It should be exactly the same, not sure why anything was duplicated
there.

> > 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?

If reconfiguration fails, that should probably be an error. Or is there
a way to recover from there at this point.

I thought the problem here was that the output port gets a new video
format, and we fail to reconfigure correctly here? That is, we fail to
do the correct steps required to make the reconfiguration work?

-- 
Sebastian Dröge, Centricular Ltd · http://www.centricular.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: This is a digitally signed message part
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20161212/cd3bf514/attachment.sig>