Re: [gst-devel] Start recording from a webcam already playing

[Arnout V. <ar...@mi...>]

On Friday 30 January 2009 20:37:49 Marc wrote:
> I am trying to build an application more or less like Cheese
> (http://projects.gnome.org/cheese/). However I would like to switch from
> just showing the webcam to a recording state "smoothly" when the user press
> the record button.
>
> So far I have tried the following approaches without succes:
> Changing location property of filesink while playing (from /dev/null to a
> real path). This is not possible (filesink tells me so). Open 2 different
> pipelines both of them pointing to the same v4l2src (no success since only
> one pipeline can access the webcam at once). Since these approaches were
> not working I tried to set the pipeline to STATE_NULL, change the location
> of the filesink, and then set the pipeline to STATE_PLAYING again. However,
> when setting the pipeline to STATE_NULL, no STATE_CHANGE event is thrown.
> Is this the expected behavior ?
>
> Any ideas ? Can the smooth "play-to-record" be accomplished with GStreamer
> ?
>
> Thank you
> PD. For the record: I am programming in Python and the pipeline I am trying
> to manage is the following:
>
>  gst-launch-0.10 v4l2src ! tee name=videoout ! queue ! videorate !
> video/x-raw-yuv,fps=15 ! queue ! theoraenc quality=60 ! queue ! muxout.
> pulsesrc ! audio/x-raw-int,rate=22000,channels=1,width=16 ! queue !
> audioconvert ! vorbisenc ! queue ! muxout. oggmux name=muxout ! filesink
> location=test.ogg videoout. ! queue ! ffmpegcolorspace ! ximagesink

 You can add the videoout tail of the pipeline dynamically.  Start without it, 
and when the user presses the record button, add it to the pipeline and link 
it (and set each element to PLAYING individually).  It's not even necessary 
to pause the pipeline.

 It's more difficult to smoothly stop the recording, though.  You'll have to 
block the queue element behind the tee (see docs/design/part-block.txt in the 
source tree).  In addition, you have to push an EOS into it to make sure the 
muxer writes duration and index to the file.

 A last caveat is the timestamps.  The buffer timestamps start running as soon 
as the v4l2src starts playing, which makes it appear in the output file as if 
it starts with a big hole.  The only way I found to fix that is to add an 
adapter element that shifts the buffer timestamps (see 
http://bugzilla.gnome.org/show_bug.cgi?id=561224 ).

 Regard,
 Arnout
-- 
Arnout Vandecappelle                               arnout at mind be
Senior Embedded Software Architect                 +32-16-286540
Essensium/Mind                                     http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium                BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  D206 D44B 5155 DF98 550D  3F2A 2213 88AA A1C7 C933