[Bug 775962] New: Occassional addition of codec_data to caps when stream-format: byte-stream

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=775962

            Bug ID: 775962
           Summary: Occassional addition of codec_data to caps when
                    stream-format: byte-stream
    Classification: Platform
           Product: GStreamer
           Version: git master
                OS: Mac OS
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gst-omx
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: minfrin at sharp.fm
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

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?

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.