[Bug 696770] Memory leak when processing h.264 field pictures

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=696770
  GStreamer | gst-libav | 1.0.5

--- Comment #12 from sreerenj <bsreerenj at gmail.com> 2013-06-04 19:13:53 UTC ---
(In reply to comment #8)
> Review of attachment 245998 [details]:
> 
> ::: ext/libav/gstavviddec.c
> @@ +1400,3 @@
> +     ffmpeg is allocating the output buffer only for complete frames and not
> +     for the individual fields. */
> +  if (frame && !frame->output_buffer) {
> 
> I don't think this is correct. libav is not necessarily allocating an output
> buffer for the current input frame immediately

Does the following code path in get_buffer() making sure the latest frame
buffer allocation?

picture->reordered_opaque = context->reordered_opaque;
  frame =
      gst_video_decoder_get_frame (GST_VIDEO_DECODER (ffmpegdec),
      picture->reordered_opaque);

> 
> Also does this mean that every GstVideoCodecFrame was a field here, not a
> frame? In that case it would be something that the parser should've fixed,
> GstVideoCodecFrame is supposed to be one complete frame with everything related
> to it.

Yes, for field-encoded stream, every GstVideoCodecFrame is a field. The issue
is exactly what I mentioned before.  I don't think it is the duty of parser.
Because if I understood correctly some decoders can send fields as frames to
renderer directly.  For eg, vaapi has a feature for this. vaPutsurface() api
has flags to specify whether the surface has top fields or bottom fields. But
AFAIK this is not yet supported in driver. So in current gstreamer-vaapi we are
using the same surface to render both top and bottom fields.

I have a fix for this to gstreamer-vaapi also:
https://bugzilla.gnome.org/show_bug.cgi?id=701257

We need similar fixes to mpeg2dec also.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.