[gstreamer-bugs] [Bug 366155] New: [matroskademux] Several problems in encoding handling code

[GStreamer (bugzilla.gnome.org)]

Do not reply to this via email (we are currently unable to handle email
responses and they get discarded).  You can add comments to this bug at
http://bugzilla.gnome.org/show_bug.cgi?id=366155

  GStreamer | gst-plugins-good | Ver: HEAD CVS

           Summary: [matroskademux] Several problems in encoding handling
                    code
           Product: GStreamer
           Version: HEAD CVS
          Platform: Other
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: gst-plugins-good
        AssignedTo: gstreamer-bugs at lists.sourceforge.net
        ReportedBy: michal.benes at itonis.tv
         QAContact: gstreamer-bugs at lists.sourceforge.net
     GNOME version: Unspecified
   GNOME milestone: Unspecified


There are some problems with the recent patch that adds support for track
encoding

In gst_matroska_decode_buffer it is assumed that encoding type is compression.
And therefore possibly uninitialized value enc.comp_algo is used. Matroska
demuxer therefore tries to unzip encrypted tracks.

Not all possible values of comp_algo are checked (comp_algo == 3 is missing),
therefore new_data may stay NULL and buffer referencing NULL data may be pushed
to sink pad.

There is a for-cycle over all encodings, but new_data is generated allways from
the original buffer (and old new_data leaked).

Data should be decoded according to encoding order (I have sorted encodings
decreasingly in enc.order in my patch)

I have also removed \n from GST_WARNINGS

(patch follows)


-- 
Configure bugmail: http://bugzilla.gnome.org/userprefs.cgi?tab=email