GNOME Bugzilla – Bug 692789
H264parse overwrites codec_data field before comparing old one and new one
Last modified: 2013-02-04 08:09:19 UTC
When parsing different H264 streams successively, h264parse overwrites codec_data field in gst_h264_parse_set_caps() with the new codec_data from the caps before the comparison done in gst_h264_parse_set_caps(). In my mind, the line h264parse->codec_data = gst_buffer_ref (codec_data); in gst_h264_parse_set_caps() is to be removed as first the old buffer is not unref (potential memory leak), and codec_data field is correctly replace with the new one from the caps in gst_h264_parse_set_caps(), after the comparison. Because of this, codec_data from GstH264Parse structure and from the caps are always the same. See the provided patch in attachment. Cheers, Paul HENRYS
Created attachment 234719 [details] [review] Patch
Good point. There is something not entirely right with how the codec_data field is being used. Currently it tries to track the codec_data in the output caps as well in the input caps which is not quite right, and leads to problems (a.o.) such as noted above. Following commit, somewhat more extended than the proposed path, tries to remedy this: commit 7df753165f809280e7992bac382afddeff416871 Author: Mark Nauwelaerts <mnauw@users.sourceforge.net> Date: Sat Feb 2 18:44:11 2013 +0100 h264parse: separate fields for distinct functional uses of codec_data field Fixes https://bugzilla.gnome.org/show_bug.cgi?id=692789
Ok Mark. Thx for the fix.