[gst-devel] Why does this file encoding pipeline not work?

[wally_bkg]

I've been playing around with the various encoders in gstreamer to get an
idea of quality/size/cpu tradeoffs, and so far x264enc is looking like the
best overall compromise, at least based on what is shipped with Ubuntu
10.04.  

I need a readily available target with a reasonable lifespan and update
policy, Ubuntu LTS versions seem to me the best compromise at present, so
for the time being I need to live with whatever limitations exist in the
gstreamer-0.10.28 its ships with.

I can create a test file with:
gst-launch -e v4l2src ! video/x-raw-yuv, framerate=\(fraction\)30000/1001,
width=640, height=480 ! x264enc ! avimux ! filesink location=test.avi

This file plays back fine in Totem, although Totem will not play it if I
change the name to test.mp4, although changing it to test.mpr or test.264
will work.   What's up with this?  

Also, while the files I record with these various gstreamer pipelines all
play back fine in Totem (using gstreamer, Doh!),  most all of them will not
play back on a Windows system that  is my "gold standard" for playing
obscure media formats people give me to convert for their Powerpoint
presentations.


However trying to get an idea of CPU usage in a more realistic analog of my
application the following pipeline locks up displaying only a single frame
and produces an output file of 0 bytes:

gst-launch -e v4l2src ! video/x-raw-yuv, framerate=\(fraction\)30000/1001,
width=640, height=480 ! tee name=t ! queue ! xvimagesink t. ! queue !
x264enc ! avimux ! filesink location=test.avi

I get:
Setting pipeline to PAUSED ...
Pipeline is live and does not need PREROLL ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
And the display window is locked on a single frame ....

When I press control-C in the terminal window I get:
Caught interrupt -- handling interrupt.
Interrupt: Stopping pipeline ...
EOS on shutdown enabled -- Forcing EOS on the pipeline
Waiting for EOS...
which hangs until I press control-C again.

If I close the output window when its locked up instead of pressing
control-C in the terminal window
I get this when the window is closed:
ERROR: from element /GstPipeline:pipeline0/GstXvImageSink:xvimagesink0:
Output window was closed
Additional debug info:
xvimagesink.c(1299): gst_xvimagesink_handle_xevents ():
/GstPipeline:pipeline0/GstXvImageSink:xvimagesink0
Execution ended after 7073325548 ns.
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
Setting pipeline to NULL ...
Freeing pipeline ...


I'd like to point out, that "man gst-launch" appears to have no mention of
the -e option, which I learned about on this list a while back.


My C code that effectively does:

vrl2src->videoscale->queue->appsink -\
                                      \appsrc->queue->xvimagesink
                                      \appsrc->queue->x264enc->filesink
(with the above caps set on the appsink, & appsrc elements)
Seems to work ok, although I haven't got to the point of independently
starting/stopping the recoding pipeline, initially all three start at once. 
I'm pretty happy with the ~72% CPU usages shown by top (quad core) and can
run two instances of the program writing to different out directories,
although there may be recording glitches introduced when doing this, I need
further testing.

The videoscale element does nothing for most of my capture cards as they can
output 640x480 frames, but I have a USB Haupapauge HRV-950Q that can only do
720x480 on its analog inputs.  Video scale is very expensive in this case,
increasing CPU usage by ~25%





-- 
View this message in context: http://gstreamer-devel.966125.n4.nabble.com/Why-does-this-file-encoding-pipeline-not-work-tp3090988p3090988.html
Sent from the GStreamer-devel mailing list archive at Nabble.com.