GNOME Bugzilla – Bug 707414
x264enc: crash and warning
Last modified: 2013-09-18 16:51:03 UTC
Created attachment 254008 [details] [review] Patch for crash encoder calls gst_x264_enc_init_encoder from reset even if it has no input_state yet (can happen when flush comes before format).
Created attachment 254010 [details] [review] Patch for warning Second problem is unsigned comparison always false warning from clang. For the record, I still think that what x264 enc does to DTS here is pretty horrible, at least until we have a way to propagate the delay downstream (in which case I'd probably be fine with it) :)
Comment on attachment 254008 [details] [review] Patch for crash This does not apply to git master any longer, the reset vfunc was deprecated in favor of flush. As I understand it the version in git master should be fine but can you confirm? Additionally pushing this change to the 1.0 branch can be done once we know it's fixed in master.
I'm currently about a month behind and I can't upgrade to master yet, but looking at the code static gboolean gst_x264_enc_flush (GstVideoEncoder * encoder) { GstX264Enc *x264enc = GST_X264_ENC (encoder); gst_x264_enc_flush_frames (x264enc, FALSE); gst_x264_enc_close_encoder (x264enc); gst_x264_enc_dequeue_all_frames (x264enc); gst_x264_enc_init_encoder (x264enc); return TRUE; } Are you sure that gst_x264_enc_init_encoder will never be called without input state? Does the base class not call flush unless there was input state set?
Thanks, it actually can happen still: commit 55037ab411218786a7625e2d8827ae253f4b4909 Author: Sebastian Dröge <slomo@circular-chaos.org> Date: Wed Sep 4 16:32:43 2013 +0200 x264enc: Check if we have an input state before using it Flushing might happen before caps were set on the encoder, which would lead to crashes here. Thanks to Matej Knopp for analyzing this. https://bugzilla.gnome.org/show_bug.cgi?id=707414 In 1.0 this bug did not exist yet, it was introduced in some 1.1 version.