Back in August 2010 I ran a brief experiment using GstInputSelector to switch between various video sources. You may have noticed that it was using Theora encoder while most of my other DVB experiments used H.264 encoder in MPEG-TS container. The reason for this was that I could not make x264enc work in the pipeline used for the video switcher.
To summarize the problem, this pipeline works:
gst-launch -e videotestsrc ! tee name="splitter" !
queue ! xvimagesink sync=false
splitter. ! queue ! theoraenc ! oggmux ! filesink location=test.ogg
while this one will freeze right after start:
gst-launch -e videotestsrc ! tee name="splitter" !
queue ! xvimagesink sync=false
splitter. ! queue ! x264enc ! mpegtsmux ! filesink location=test.ts
I was quite sure it was due to x264enc because I could use any compatible muxer including no muxer at all, even try to save raw H.264 directly to file. It would freeze in all cases when running on Ubuntu 10.04 or 10.10, but not on Ubuntu 9.10. Since I am using GStreamer from PPA, the only difference between the 9.10 and the 10.x machines are libx264 version.
Today I learned how to fix it and make x264enc work in this pipeline, thanks to an email on the GStreamer-devel mailing list. In his email Senthil writes that “The queue will block the supplier when there is no more space in it. … Since x264enc may take more time to consume, setting leaky property (as suggested in the doc) on the queue before xvimagesink might help” – and indeed it does!
gst-launch -e videotestsrc ! tee name="splitter" !
queue leaky=1 ! xvimagesink sync=false
splitter. ! queue ! x264enc ! mpegtsmux ! filesink location=test.ts
works like a charm. I tried both the leaky=1 (upstream) and leaky=2 (downstream) options and both work. The default is leaky=0 (not leaky).
You can now expect an update of the multicam.py script as well as better integration with the rest of the gnuradio-dvb package.