[Bug 737412] h264: playing a certain broken stream causes a crash (stack corruption caused by codec parser)

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=737412
  GStreamer | gst-plugins-bad | 1.4.3

Vincent Penquerc'h <vincent.penquerch> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |vincent.penquerch at collabora
                   |                            |.co.uk
         Resolution|                            |FIXED
   Target Milestone|HEAD                        |1.5.1

--- Comment #10 from Vincent Penquerc'h <vincent.penquerch at collabora.co.uk> 2015-01-14 11:45:26 UTC ---
Doh. I'll have to think hard to top that one :D

commit c73a5e0c545babe50130e7042be8cf92828afa18
Author: Vincent Penquerc'h <vincent.penquerch at collabora.co.uk>
Date:   Mon Jan 12 17:24:52 2015 +0000

    h264parser: fix stack smashing

    Ensure that we do not trust the bitstream when filling a table
    with a fixed max size.
    Additionally, the code was not quite matching what the spec says:
    - a value of 3 broke from the loop before adding an entry
    - an unhandled value did not add an entry
    The reference algorithm does these things differently (7.3.3.1
    in ITU-T Rec. H.264 (05/2003)).

    This plays (apparently correctly) the original repro file, with
    no stack smashing.

    Based on a patch and bug report by André Draszik <git at andred.net>

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