Caps renegotiation with codec_data results in "not-negotiated"
Locked
Caps renegotiation with codec_data results in "not-negotiated"
 
|
Hi all,
I have a transcoding pipeline that looks like this: http://www.sharp.fm/0.00.02.176790240-gst-launch.PAUSED_PLAYING.dot.svg I have my MPEG2 TS being transcoded on the fly, however about 55 minutes into the stream we attempt to renegotiate the caps for a reason I don’t understand and then fail as per the log below. The caps differ by the addition of the “codec_data” to the caps, which for some reason isn’t liked. Is there a missing element that should be added to handle “codec_data"? minfrin@towerofpi9:/var/www/html/stream $ cat /mnt/stream/stream10.out | grep ALLOCATION 0:00:02.092736080 9358 0x74b01b80 DEBUG videoencoder gstvideoencoder.c:1651:gst_video_encoder_negotiate_default:<omxh264enc-omxh264enc0> didn't get downstream ALLOCATION hints 0:00:02.092804985 9358 0x74b01b80 DEBUG videoencoder gstvideoencoder.c:1658:gst_video_encoder_negotiate_default:<omxh264enc-omxh264enc0> ALLOCATION (1) params: allocation query: 0x75529000, GstQueryAllocation, caps=(GstCaps)"video/x-h264\,\ stream-format\=\(string\)byte-stream\,\ alignment\=\(string\)au\,\ profile\=\(string\)high\,\ level\=\(string\)4\,\ width\=\(int\)544\,\ height\=\(int\)576\,\ pixel-aspect-ratio\=\(fraction\)64/33\,\ framerate\=\(fraction\)25/1", need-pool=(boolean)true, allocator=(GArray)NULL; 0:55:35.347010877 9358 0x74b01b80 DEBUG videoencoder gstvideoencoder.c:1651:gst_video_encoder_negotiate_default:<omxh264enc-omxh264enc0> didn't get downstream ALLOCATION hints 0:55:35.347103585 9358 0x74b01b80 DEBUG videoencoder gstvideoencoder.c:1658:gst_video_encoder_negotiate_default:<omxh264enc-omxh264enc0> ALLOCATION (1) params: allocation query: 0x68a3e8f0, GstQueryAllocation, caps=(GstCaps)"video/x-h264\,\ stream-format\=\(string\)byte-stream\,\ alignment\=\(string\)au\,\ profile\=\(string\)high\,\ level\=\(string\)4\,\ width\=\(int\)544\,\ height\=\(int\)576\,\ pixel-aspect-ratio\=\(fraction\)64/33\,\ framerate\=\(fraction\)25/1\,\ codec_data\=\(buffer\)404409361803c489a8", need-pool=(boolean)true, allocator=(GArray)NULL; The full log is as follows: 0:55:35.294566109 9358 0x75528030 DEBUG omxvideoenc gstomxvideoenc.c:1612:gst_omx_video_enc_handle_frame:<omxh264enc-omxh264enc0> Passed frame to component 0:55:35.297810135 9358 0x74b01b80 DEBUG omxvideoenc gstomxvideoenc.c:753:gst_omx_video_enc_loop:<omxh264enc-omxh264enc0> Handling buffer: 0x00000480 0 0:55:35.297892998 9358 0x74b01b80 DEBUG omxh264enc gstomxh264enc.c:618:gst_omx_h264_enc_handle_output_frame:<omxh264enc-omxh264enc0> got codecconfig in byte-stream format 0:55:35.297927894 9358 0x74b01b80 DEBUG omxvideoenc gstomxvideoenc.c:762:gst_omx_video_enc_loop:<omxh264enc-omxh264enc0> Finished frame: ok 0:55:35.298151954 9358 0x74b01b80 DEBUG omxvideoenc gstomxvideoenc.c:770:gst_omx_video_enc_loop:<omxh264enc-omxh264enc0> Read frame from component 0:55:35.298184974 9358 0x74b01b80 DEBUG omxvideoenc gstomxvideoenc.c:753:gst_omx_video_enc_loop:<omxh264enc-omxh264enc0> Handling buffer: 0x00000480 0 0:55:35.298624604 9358 0x74b01b80 DEBUG omxvideoenc gstomxvideoenc.c:562:gst_omx_video_enc_handle_output_frame:<omxh264enc-omxh264enc0> Handling codec data 0:55:35.347010877 9358 0x74b01b80 DEBUG videoencoder gstvideoencoder.c:1651:gst_video_encoder_negotiate_default:<omxh264enc-omxh264enc0> didn't get downstream ALLOCATION hints /GstPipeline:pipeline0/GstTranscoder:transcoder/GstEncodeBin:encodebin0/GstOMXH264Enc-omxh264enc:omxh264enc-omxh264enc0.GstPad:src: caps = video/x-h264, stream-format=(string)byte-stream, alignment=(string)au, profile=(string)high, level=(string)4, width=(int)544, height=(int)576, pixel-aspect-ratio=(fraction)64/33, framerate=(fraction)25/1, codec_data=(buffer)404409361803c489a8 /GstPipeline:pipeline0/GstTranscoder:transcoder/GstEncodeBin:encodebin0/GstStreamCombiner:streamcombiner0.GstPad:src: caps = video/x-h264, stream-format=(string)byte-stream, alignment=(string)au, profile=(string)high, level=(string)4, width=(int)544, height=(int)576, pixel-aspect-ratio=(fraction)64/33, framerate=(fraction)25/1, codec_data=(buffer)404409361803c489a8 /GstPipeline:pipeline0/GstTranscoder:transcoder/GstEncodeBin:encodebin0/GstStreamCombiner:streamcombiner0.GstStreamCombinerPad:encodingsink: caps = video/x-h264, stream-format=(string)byte-stream, alignment=(string)au, profile=(string)high, level=(string)4, width=(int)544, height=(int)576, pixel-aspect-ratio=(fraction)64/33, framerate=(fraction)25/1, codec_data=(buffer)404409361803c489a8 0:55:35.347103585 9358 0x74b01b80 DEBUG videoencoder gstvideoencoder.c:1658:gst_video_encoder_negotiate_default:<omxh264enc-omxh264enc0> ALLOCATION (1) params: allocation query: 0x68a3e8f0, GstQueryAllocation, caps=(GstCaps)"video/x-h264\,\ stream-format\=\(string\)byte-stream\,\ alignment\=\(string\)au\,\ profile\=\(string\)high\,\ level\=\(string\)4\,\ width\=\(int\)544\,\ height\=\(int\)576\,\ pixel-aspect-ratio\=\(fraction\)64/33\,\ framerate\=\(fraction\)25/1\,\ codec_data\=\(buffer\)404409361803c489a8", need-pool=(boolean)true, allocator=(GArray)NULL; 0:55:35.354795216 9358 0x74b01b80 DEBUG omxvideoenc gstomxvideoenc.c:762:gst_omx_video_enc_loop:<omxh264enc-omxh264enc0> Finished frame: ok 0:55:35.355044328 9358 0x74b01b80 DEBUG omxvideoenc gstomxvideoenc.c:770:gst_omx_video_enc_loop:<omxh264enc-omxh264enc0> Read frame from component 0:55:35.355084796 9358 0x74b01b80 DEBUG omxvideoenc gstomxvideoenc.c:753:gst_omx_video_enc_loop:<omxh264enc-omxh264enc0> Handling buffer: 0x00000490 0 0:55:35.355134327 9358 0x74b01b80 DEBUG omxh264enc gstomxh264enc.c:618:gst_omx_h264_enc_handle_output_frame:<omxh264enc-omxh264enc0> got codecconfig in byte-stream format 0:55:35.355169639 9358 0x74b01b80 DEBUG omxvideoenc gstomxvideoenc.c:762:gst_omx_video_enc_loop:<omxh264enc-omxh264enc0> Finished frame: ok 0:55:35.355347970 9358 0x74b01b80 DEBUG omxvideoenc gstomxvideoenc.c:770:gst_omx_video_enc_loop:<omxh264enc-omxh264enc0> Read frame from component 0:55:35.355378907 9358 0x74b01b80 DEBUG omxvideoenc gstomxvideoenc.c:753:gst_omx_video_enc_loop:<omxh264enc-omxh264enc0> Handling buffer: 0x00000430 3336240000 0:55:35.355423594 9358 0x74b01b80 DEBUG videoencoder gstvideoencoder.c:500:gst_video_encoder_set_headers:<omxh264enc-omxh264enc0> new headers 0x731f4e20 0:55:35.355464687 9358 0x74b01b80 DEBUG omxvideoenc gstomxvideoenc.c:586:gst_omx_video_enc_handle_output_frame:<omxh264enc-omxh264enc0> Handling output data 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 ... 0:55:35.609748254 9358 0x2114e00 DEBUG omxvideoenc gstomxvideoenc.c:916:gst_omx_video_enc_stop:<omxh264enc-omxh264enc0> Stopping encoder 0:55:35.612063957 9358 0x2114e00 DEBUG omxvideoenc gstomxvideoenc.c:364:gst_omx_video_enc_shutdown:<omxh264enc-omxh264enc0> Shutting down encoder 0:55:35.740784212 9358 0x2114e00 DEBUG omxvideoenc gstomxvideoenc.c:387:gst_omx_video_enc_close:<omxh264enc-omxh264enc0> Closing encoder 0:55:35.740867128 9358 0x2114e00 DEBUG omxvideoenc gstomxvideoenc.c:364:gst_omx_video_enc_shutdown:<omxh264enc-omxh264enc0> Shutting down encoder Setting pipeline to NULL ... 0:55:35.757703708 9358 0x2114e00 DEBUG videoencoder gstvideoencoder.c:852:gst_video_encoder_finalize:<omxh264enc-omxh264enc0> finalize Freeing pipeline … Regards, Graham — _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
smime.p7s (4K)
Re: Caps renegotiation with codec_data results in "not-negotiated"
|
|
On Mon, 2016-11-21 at 02:50 +0200, Graham Leggett wrote:
> Hi all, > > I have a transcoding pipeline that looks like this: > > http://www.sharp.fm/0.00.02.176790240-gst-launch.PAUSED_PLAYING.dot.s > vg > > I have my MPEG2 TS being transcoded on the fly, however about 55 > minutes into the stream we attempt to renegotiate the caps for a > reason I don’t understand and then fail as per the log below. > > The caps differ by the addition of the “codec_data” to the caps, > which for some reason isn’t liked. > > Is there a missing element that should be added to handle > “codec_data"? does not like the codec_data or buffers, and returns not-negotiated instead. If you get a full log, you should find the reason for that shortly above the very first mention of "not-negotiated" in the log. -- Sebastian Dröge, Centricular Ltd · http://www.centricular.com _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: Caps renegotiation with codec_data results in "not-negotiated"
|
|
On 21 Nov 2016, at 10:29 AM, Sebastian Dröge <[hidden email]> wrote:
> The problem here seems to be that some element downstream of omxh264enc > does not like the codec_data or buffers, and returns not-negotiated > instead. If you get a full log, you should find the reason for that > shortly above the very first mention of "not-negotiated" in the log. Downstream is mpegtsmux, and looking at the caps codec_data is not mentioned, though not sure that that’s fatal: video/x-h264 stream-format: byte-stream alignment: { au, nal } omxh264enc and mpegtsmux are in turn linked together by encodebin, are there any known issues with respect to getting these to renegotiate when needed? Will try get a new log once gcc 6.2.0 is built with a working AddressSanitizer. Regards, Graham — _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: Caps renegotiation with codec_data results in "not-negotiated"
|
|
On Tue, 2016-11-22 at 00:46 +0200, Graham Leggett wrote:
> On 21 Nov 2016, at 10:29 AM, Sebastian Dröge <[hidden email] > om> wrote: > > > The problem here seems to be that some element downstream of > > omxh264enc > > does not like the codec_data or buffers, and returns not-negotiated > > instead. If you get a full log, you should find the reason for that > > shortly above the very first mention of "not-negotiated" in the > > log. > > Downstream is mpegtsmux, and looking at the caps codec_data is not > mentioned, though not sure that that’s fatal: > > video/x-h264 > stream-format: byte-stream > alignment: { au, nal } > > omxh264enc and mpegtsmux are in turn linked together by encodebin, > are there any known issues with respect to getting these to > renegotiate when needed? information is in-band in this case. We'll need a full debug log here -- Sebastian Dröge, Centricular Ltd · http://www.centricular.com _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: Caps renegotiation with codec_data results in "not-negotiated"
|
|
On 23 Nov 2016, at 10:06 AM, Sebastian Dröge <[hidden email]> wrote:
> byte-stream h264 has no "codec_data" in the headers, only avc has. The > information is in-band in this case. Looking at http://www.sharp.fm/0.07.26.578741662-gst-launch.error.dot.svg we definitely have some oddness with codec_data being added to byte-stream. It looks like h264parse is the one that is refusing to negotiate, it is receiving a codec_data with a stream-format: byte-stream and then refusing to accept it. The source of the codec_data is omxh264enc. Looking in gst_omx_video_enc_handle_output_frame() in gstomxvideoenc.c I’m not seeing anything that checks first whether we are byte-stream or avc before adding the codec_data to the caps. Busy testing this hack workaround to see if it makes a difference: diff --git a/omx/gstomxvideoenc.c b/omx/gstomxvideoenc.c index bfad2f3..a16e714 100644 --- a/omx/gstomxvideoenc.c +++ b/omx/gstomxvideoenc.c @@ -554,29 +554,32 @@ gst_omx_video_enc_handle_output_frame (GstOMXVideoEnc * self, GstOMXPort * port, if ((buf->omx_buf->nFlags & OMX_BUFFERFLAG_CODECCONFIG) && buf->omx_buf->nFilledLen > 0) { - GstVideoCodecState *state; - GstBuffer *codec_data; - GstMapInfo map = GST_MAP_INFO_INIT; - GstCaps *caps; + if (0) { + GstVideoCodecState *state; + GstBuffer *codec_data; + GstMapInfo map = GST_MAP_INFO_INIT; + GstCaps *caps; - GST_DEBUG_OBJECT (self, "Handling codec data"); + GST_DEBUG_OBJECT (self, "Handling codec data"); - caps = klass->get_caps (self, self->enc_out_port, self->input_state); - codec_data = gst_buffer_new_and_alloc (buf->omx_buf->nFilledLen); + caps = klass->get_caps (self, self->enc_out_port, self->input_state); + codec_data = gst_buffer_new_and_alloc (buf->omx_buf->nFilledLen); - gst_buffer_map (codec_data, &map, GST_MAP_WRITE); - memcpy (map.data, - buf->omx_buf->pBuffer + buf->omx_buf->nOffset, - buf->omx_buf->nFilledLen); - gst_buffer_unmap (codec_data, &map); - state = - gst_video_encoder_set_output_state (GST_VIDEO_ENCODER (self), caps, - self->input_state); - state->codec_data = codec_data; - gst_video_codec_state_unref (state); - if (!gst_video_encoder_negotiate (GST_VIDEO_ENCODER (self))) { - gst_video_codec_frame_unref (frame); - return GST_FLOW_NOT_NEGOTIATED; + gst_buffer_map (codec_data, &map, GST_MAP_WRITE); + memcpy (map.data, + buf->omx_buf->pBuffer + buf->omx_buf->nOffset, + buf->omx_buf->nFilledLen); + gst_buffer_unmap (codec_data, &map); + state = + gst_video_encoder_set_output_state (GST_VIDEO_ENCODER (self), caps, + self->input_state); + state->codec_data = codec_data; + gst_video_codec_state_unref (state); + if (!gst_video_encoder_negotiate (GST_VIDEO_ENCODER (self))) { + gst_video_codec_frame_unref (frame); + GST_ERROR_OBJECT (self, "Downstream refused to negotiate our codec_data in the caps"); + return GST_FLOW_NOT_NEGOTIATED; + } } flow_ret = GST_FLOW_OK; } else if (buf->omx_buf->nFilledLen > 0) { Regards, Graham — _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: Caps renegotiation with codec_data results in "not-negotiated"
|
|
On Sun, 2016-12-11 at 17:09 +0200, Graham Leggett wrote:
> On 23 Nov 2016, at 10:06 AM, Sebastian Dröge <[hidden email] > om> wrote: > > > byte-stream h264 has no "codec_data" in the headers, only avc has. > > The > > information is in-band in this case. > > Looking at http://www.sharp.fm/0.07.26.578741662-gst-launch.error.dot > .svg we definitely have some oddness with codec_data being added to > byte-stream. > > It looks like h264parse is the one that is refusing to negotiate, it > is receiving a codec_data with a stream-format: byte-stream and then > refusing to accept it. > The source of the codec_data is omxh264enc. Looking in > gst_omx_video_enc_handle_output_frame() in gstomxvideoenc.c I’m not > seeing anything that checks first whether we are byte-stream or avc > before adding the codec_data to the caps. That would be a bug, yes. The codec_data should be in-band for byte- stream. -- Sebastian Dröge, Centricular Ltd · http://www.centricular.com _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: Caps renegotiation with codec_data results in "not-negotiated"
|
|
| Free forum by Nabble | Edit this page |