[gstreamer-bugs] [Bug 625557] x264enc doesn't flush delayed frames properly

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=625557
  GStreamer | gst-plugins-ugly | 0.10.15

Robert Swain <robert.swain> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #166758|0                           |1
        is obsolete|                            |

--- Comment #2 from Robert Swain <robert.swain at gmail.com> 2010-07-30 08:04:15 UTC ---
Created an attachment (id=166810)
 View: https://bugzilla.gnome.org/attachment.cgi?id=166810
 Review: https://bugzilla.gnome.org/review?bug=625557&attachment=166810

Fix frame flushing bug

It seems that the i_nal > 0 check didn't work possibly because we can have > 1
frame of delay in the x264 encoder. This meant that one real frame would be
pushed in and no NALs would come out, one NULL frame would be pushed in and no
NALs would come out and we'd consider it flushed but with no output buffers.
Using x264_encoder_delayed_frames() would then cause a third call to
x264_encoder_encode() with a NULL input frame which would finally return the
encoded frame (i.e. > 0 NALs). That's my theory anyway.

As such, we don't need the i_nal check but it's only supported in libx264 APIs
versions 71 and higher (around 2009-08) so I've added in a bit of ifdeffery to
at least be able to flush one frame though that method is broken. Perhaps we
can figure out some more reliable way of flushing when the API is not
available. I think the delay can be calculated from x264 parameters.

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