GNOME Bugzilla – Bug 656007
x264enc: stops temporarily on flushing seek to a time before current time
Last modified: 2013-07-25 11:32:07 UTC
I have a pipeline containing x264enc, such as "videotestsrc ! video/x-raw-yuv,width=1024,height=1024,framerate=10/1 ! x264enc ! fakesink sync=true", when I seek from 90 seconds to 50 seconds the pipeline pauses for 40 seconds (this is true for any timestamps Y > X, seeking from Y to X pauses for Y-X). I originally stumbled across this when serving up transcoded video via RTSP. It seems to only happen when using x264enc, but perhaps I'm mistaken. Also, is this too much to expect of a video encoder? I have attached an example. Entering a number, n, from 0 to 9 and pressing enter seeks to n * 10 seconds, 'x' exits. Sorry, it's not terribly sophisticated. Thanks. versions: gstreamer 0.10.35 gst-plugins-base 0.10.35 gst-plugins-good 0.10.30 gst-plugins-ugly 0.10.18 x264 85 (1a6d32)
Created attachment 193293 [details] example program with simple pipeline
Created attachment 204911 [details] [review] patch closing and reopening underlying encoder
At Wim's suggestion, I tried closing and reopening the underlying x264 encoder on a flushing seek. It seems to work, but some locked was necessary.
That should probably be done on FLUSH_STOP (where the pad stream lock is held), not on FLUSH_START (which is some random other thread, usually the one the seek is initiated from). Also, the flush events should be sent on downwards.
(In reply to comment #4) > That should probably be done on FLUSH_STOP (where the pad stream lock is held), > not on FLUSH_START (which is some random other thread, usually the one the seek > is initiated from). Ok, I will post a patch with this change. > Also, the flush events should be sent on downwards. I push the event on the encoder's srcpad, but perhaps I'm misunderstanding your comment. Could you expand a bit please?
Created attachment 204919 [details] [review] second proposed patch - closes and reopens the underlying encoder
You're right, I was confused by your re-shuffling of the gst_pad_push_event(). Ideally the patch should be minimally invasive and avoids cleanups or style changes that aren't needed (or does them in a separate commit). The additional locking is probably also not needed any more when you move to use FLUSH_STOP.
Created attachment 204977 [details] [review] cleaned up and pared down patch You're right. I have removed the locking and extraneous clean up.
commit 291b05b40aadd3ba1646184d024a3cdf8f9f6c1f Author: Sebastian Dröge <slomo@circular-chaos.org> Date: Thu Jul 25 10:46:04 2013 +0200 videoencoder: Reset internal state and segments on FLUSH_STOP https://bugzilla.gnome.org/show_bug.cgi?id=656007 commit a4a89275f834554d8fd890ff723231a7f474ff17 Author: Sebastian Dröge <slomo@circular-chaos.org> Date: Thu Jul 25 11:01:20 2013 +0200 x264enc: React properly to flushing/resetting the encoder https://bugzilla.gnome.org/show_bug.cgi?id=656007