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 621696 - Can only encode with x264enc from a live source using a constant quantizer
Can only encode with x264enc from a live source using a constant quantizer
Status: RESOLVED NOTABUG
Product: GStreamer
Classification: Platform
Component: gst-plugins-ugly
0.10.15
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2010-06-15 20:57 UTC by Kristofor
Modified: 2010-06-18 12:48 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Kristofor 2010-06-15 20:57:46 UTC
I am using v4lsrc to capture from a live source and trying to use the x264enc element. I use the -e argument to allow for a proper EOS to be sent to the pipeline, but the pipeline will always hang while it waits to receive the EOS, unless I use pass=4 (for x264enc). It is not ideal for me to use a constant quantizer when encoding x264 video.
Comment 1 Mark Nauwelaerts 2010-06-17 12:59:39 UTC
Following pipeline run and terminate just fine for me (using -e and Ctrl-C):

videotestsrc is-live=true ! x264enc ! fakesink
v4l2src ! ffmpegcolorspace ! x264enc ! fakesink
Comment 2 Kristofor 2010-06-17 15:45:48 UTC
You're right about that. I forget to give certain details in my bug description, my apologies. The pipeline's that I am creating require the use of the tee element, and when that is used I am unable to propagate an EOS properly.

ideotestsrc is-live=true ! queue ! tee name=t ! x264enc ! fakesink t. ! queue ! fakesink
Comment 3 Mark Nauwelaerts 2010-06-18 12:48:24 UTC
Indeed, that one seems to hang, but (adding some -v) afaics it already hangs before any EOS handling comes into play, as it fails to preroll.

It seems that x264enc performs some large lookahead, so it takes in a lot of buffers (40) and produces no output for some time.  The "some time" here seems more than other queue can handle, so a deadlock occurs trying to preroll.

The above can be made to preroll (and then also handling EOS fine) by:
* using async=false on fakesink
* larger queue limits
* tweaking x264enc behaviour (e.g. bitrate vs constant quality, or by other properties, note e.g. also bug #607798).