omxh264enc: Occassional addition of codec_data to caps when stream-format: byte-stream

Submitted by min..@..arp.fm

Link to original bug (#775962)

Description

When attempting to transcode a highly lossy MPEG transport stream using omxh264dec followed by omxh264enc, from time to time codec_data will be added to the caps when stream-format is byte-stream.

This triggers a downstream negotiation failure, which terminates the transcode.

0:55:35.355504114 9358 0x74b01b80 DEBUG videoencoder gstvideoencoder.c:2117:gst_video_encoder_finish_frame:<omxh264enc-omxh264enc0> Sending headers
0:55:35.355882808 9358 0x74b01b80 DEBUG omxvideoenc gstomxvideoenc.c:762:gst_omx_video_enc_loop:<omxh264enc-omxh264enc0> Finished frame: not-negotiated
0:55:35.356075305 9358 0x74b01b80 DEBUG omxvideoenc gstomxvideoenc.c:770:gst_omx_video_enc_loop:<omxh264enc-omxh264enc0> Read frame from component
0:55:35.356120045 9358 0x74b01b80 WARN omxvideoenc gstomxvideoenc.c:843:gst_omx_video_enc_loop:<omxh264enc-omxh264enc0> error: Internal data stream error.
0:55:35.356148690 9358 0x74b01b80 WARN omxvideoenc gstomxvideoenc.c:843:gst_omx_video_enc_loop:<omxh264enc-omxh264enc0> error: stream stopped, reason not-negotiated
0:55:35.402848003 9358 0x75528030 DEBUG omxvideoenc gstomxvideoenc.c:1460:gst_omx_video_enc_handle_frame:<omxh264enc-omxh264enc0> Handling frame
ERROR: from element /GstPipeline:pipeline0/GstTranscoder:transcoder/GstEncodeBin:encodebin0/GstOMXH264Enc-omxh264enc:omxh264enc-omxh264enc0: Internal data stream error.
Additional debug info:
gstomxvideoenc.c(843): gst_omx_video_enc_loop (): /GstPipeline:pipeline0/GstTranscoder:transcoder/GstEncodeBin:encodebin0/GstOMXH264Enc-omxh264enc:omxh264enc-omxh264enc0:
stream stopped, reason not-negotiated
Execution ended after 0:55:35.377031725
Setting pipeline to PAUSED ...
Setting pipeline to READY ...

The decision on whether to inline the codec_data or add it to the caps is made here in gst_omx_h264_enc_handle_output_frame():

if (buf->omx_buf->nFlags & OMX_BUFFERFLAG_CODECCONFIG) {
/* The codec data is SPS/PPS with a startcode => bytestream stream format
* For bytestream stream format the SPS/PPS is only in-stream and not
* in the caps!
*/
if (buf->omx_buf->nFilledLen >= 4 &&
GST_READ_UINT32_BE (buf->omx_buf->pBuffer +
buf->omx_buf->nOffset) == 0x00000001) {
// inline, else caps

From time to time this if statement is false when it should be true.

This check seems bogus - if the buffer is too short, or if a particular value is exactly 0x00000001, we inline, otherwise we falls back to the buggy behaviour. The lossy stream might account for broken data.

Ideally this check should be based on the caps, not the content of the stream (which could be corrupt / missing) - does this make sense?