After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 656007 - x264enc: stops temporarily on flushing seek to a time before current time
x264enc: stops temporarily on flushing seek to a time before current time
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-ugly
0.10.18
Other Linux
: Normal normal
: 1.1.3
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2011-08-05 04:42 UTC by blake tregre
Modified: 2013-07-25 11:32 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
example program with simple pipeline (1.37 KB, text/x-csrc)
2011-08-05 04:42 UTC, blake tregre
  Details
patch closing and reopening underlying encoder (4.11 KB, patch)
2012-01-09 23:02 UTC, blake tregre
none Details | Review
second proposed patch - closes and reopens the underlying encoder (4.11 KB, patch)
2012-01-10 00:56 UTC, blake tregre
none Details | Review
cleaned up and pared down patch (1.14 KB, patch)
2012-01-10 19:36 UTC, blake tregre
rejected Details | Review

Description blake tregre 2011-08-05 04:42:23 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)
Comment 1 blake tregre 2011-08-05 04:42:59 UTC
Created attachment 193293 [details]
example program with simple pipeline
Comment 2 blake tregre 2012-01-09 23:02:25 UTC
Created attachment 204911 [details] [review]
patch closing and reopening underlying encoder
Comment 3 blake tregre 2012-01-09 23:03:20 UTC
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.
Comment 4 Tim-Philipp Müller 2012-01-09 23:14:28 UTC
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.
Comment 5 blake tregre 2012-01-10 00:52:29 UTC
(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?
Comment 6 blake tregre 2012-01-10 00:56:02 UTC
Created attachment 204919 [details] [review]
second proposed patch - closes and reopens the underlying encoder
Comment 7 Tim-Philipp Müller 2012-01-10 00:59:25 UTC
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.
Comment 8 blake tregre 2012-01-10 19:36:48 UTC
Created attachment 204977 [details] [review]
cleaned up and pared down patch

You're right.  I have removed the locking and extraneous clean up.
Comment 9 Sebastian Dröge (slomo) 2013-07-25 11:32:04 UTC
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