mirror of
https://gitlab.freedesktop.org/gstreamer/gstreamer.git
synced 2024-12-19 06:46:38 +00:00
openh264dec: Fix up EOS handling
If the last frame(s) produce errors, then we need to drop them or else we spin forever failing to decode a frame and thinking it'll get better if we wait for more data that's never coming.
This commit is contained in:
parent
f9c04f3987
commit
984b150e65
1 changed files with 17 additions and 4 deletions
|
@ -202,6 +202,7 @@ gst_openh264dec_handle_frame (GstVideoDecoder * decoder,
|
|||
guint i;
|
||||
guint8 *p;
|
||||
guint row_stride, component_width, component_height, src_width, row;
|
||||
gboolean at_eos = (frame == NULL);
|
||||
|
||||
if (frame) {
|
||||
if (!gst_buffer_map (frame->input_buffer, &map_info, GST_MAP_READ)) {
|
||||
|
@ -247,6 +248,15 @@ gst_openh264dec_handle_frame (GstVideoDecoder * decoder,
|
|||
}
|
||||
}
|
||||
|
||||
/* No output available yet */
|
||||
if (dst_buf_info.iBufferStatus != 1) {
|
||||
if (at_eos)
|
||||
return GST_FLOW_EOS;
|
||||
|
||||
gst_video_codec_frame_unref (frame);
|
||||
return GST_FLOW_OK;
|
||||
}
|
||||
|
||||
/* FIXME: openh264 has no way for us to get a connection
|
||||
* between the input and output frames, we just have to
|
||||
* guess based on the input. Fortunately openh264 can
|
||||
|
@ -257,10 +267,13 @@ gst_openh264dec_handle_frame (GstVideoDecoder * decoder,
|
|||
return GST_FLOW_EOS;
|
||||
}
|
||||
|
||||
/* No output available yet */
|
||||
if (dst_buf_info.iBufferStatus != 1) {
|
||||
gst_video_codec_frame_unref (frame);
|
||||
return GST_FLOW_OK;
|
||||
{
|
||||
GstClockTime pts = dst_buf_info.uiOutYuvTimeStamp;
|
||||
if (pts != frame->pts) {
|
||||
GST_DEBUG_OBJECT (decoder, "Got output PTS %" GST_TIME_FORMAT
|
||||
" but expected %" GST_TIME_FORMAT, GST_TIME_ARGS (pts),
|
||||
GST_TIME_ARGS (frame->pts));
|
||||
}
|
||||
}
|
||||
|
||||
actual_width = dst_buf_info.UsrData.sSystemBuffer.iWidth;
|
||||
|
|
Loading…
Reference in a new issue