[Bug 730995] Memory leak with interlaced h264 stream

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=730995
  GStreamer | gst-omx | 1.3.1

--- Comment #6 from Aurélien Zanelli <aurelien.zanelli at parrot.com> 2014-06-02 07:57:17 UTC ---
(In reply to comment #5)
> (In reply to comment #4)
> I see, so the list order is the order in which frames came in. Re-ordering
> happens in the decoder. But libav will allocate output buffers for them, even
> though they have been re-ordered. In fact, it only marks one of the field. This
> is pretty clever, so we can drop unneeded frames much sooner. I don't think we
> can do the same here, as the API is different.

You're right, we can do this here because frames could be re-ordered by decoder
and could be output by OMX component in display order without allocating output
frame before. So in case the stream is out of order, with this method, we will
drop frames which could be output later. e.g:

frame 1 (display order 3)  -->  +--------+  --> frame 3
frame 2 (display order 2)  -->  | OMXDec |  --> frame 2
frame 3 (display order 1)  -->  +--------+  --> frame 1

                List : frame 1 -> frame 2 -> frame 3

In this exemple, with the above method frame 1 and 2 will be released but they
shouldn't.

> My only concern is that we rely on correct PTS, hopefully it's always right,
> though even if it was wrong, I think the result will be ok, and better than
> leaking.
Yes, it could be better than leaking. Also I think we should check for valid
PTS or not and if not just remove invalid timestamped frames.

I will update the patch to add some comments and make minor modifications.

-- 
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.