[Bug 731974] videodecoder: parse source data until a frame is obtained

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=731974
  GStreamer | gst-plugins-base | 1.2.4

Gwenole Beauchesne <gb.devel> changed:

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

--- Comment #10 from Gwenole Beauchesne <gb.devel at gmail.com> 2014-07-02 11:34:06 UTC ---
Created an attachment (id=279744)
 View: https://bugzilla.gnome.org/attachment.cgi?id=279744
 Review: https://bugzilla.gnome.org/review?bug=731974&attachment=279744

videodecoder: parse any source data that is still available

Fix gst_video_decoder_parse_available() to really parse any pending source data
that is still available in the adapter. This is a memory optimization to avoid
expansion of video packed added to the adapter, but also a fix to EOS condition
when the subclass parse() function ultimately only needed to call into
gvd_have_frame() and no additional source bytes were consumed, i.e.
gvd_add_to_frame() is not called.

This situation can occur when decoding H.264 streams in byte-stream/nal mode
for instance. A decoder always requires the next NAL unit to be parsed so that
to determine picture boundaries. When a new picture is found, no byte is
consumed (i.e. gvd_add_to_frame() is not called) but gvd_have_frame() is called
(i.e. priv->current_frame is gone).

Also make sure to avoid infinite loops caused by incorrect subclass parse()
implementations. This can occur when no byte gets consumed and no appropriate
indication (GST_VIDEO_DECODER_FLOW_NEED_DATA) is returned.

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