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

[Stefan Kost]

Marc schrieb:
> Thank you very much Arnout.
> 
> Using the method you described I am able to record from the webcam every
> time the user presses a button. As you pointed, also, I am having
> trouble with timestamps. In my case, since I just need to record one
> file at time, I would be ok to reset the base time for the v4l2src
> element. However ,when I try to set the base_time to 0 for this element
> it stops streaming new images.
> 
> Since I'd like to stick to the "default" gstreamer packages, is there a
> way to set the base_time for v4l2src without it being stopped ?

Another (kind of hackish) approach is to have a buffer-probe handler on the
sink-pad of the first element on the record pipeline. This could rewrite the
timestamps of the incoming buffers.

Stefan

> 
> Thanks
> 
> 2009/1/31 Arnout Vandecappelle <arnout at mind.be <mailto:arnout at mind.be>>
> 
>     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
> 
>     ------------------------------------------------------------------------------
>     This SF.net email is sponsored by:
>     SourcForge Community
>     SourceForge wants to tell your story.
>     http://p.sf.net/sfu/sf-spreadtheword
>     _______________________________________________
>     gstreamer-devel mailing list
>     gstreamer-devel at lists.sourceforge.net
>     <mailto:gstreamer-devel at lists.sourceforge.net>
>     https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
> 
> 
> 
> 
> -- 
> Marc S.
> 
> 
> ------------------------------------------------------------------------
> 
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel