[gstreamer-bugs] [Bug 366155] New: [matroskademux] Several problems in encoding handling code
GStreamer (bugzilla.gnome.org)
bugzilla-daemon at bugzilla.gnome.org
Sat Oct 28 01:16:48 PDT 2006
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
More information about the Gstreamer-bugs
mailing list