Start recording from a webcam already playing

[SnOp-2]

Hi,

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:

1. Changing location property of filesink while playing (from /dev/null to a real path). This is not possible (filesink tells me so).
   
2. 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

--
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Arnout Vandecappelle]

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                 [phone]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Andoni Morales]

 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 ).

The 'reset' property must be setted to true just before dinamically linking the encoder tail or after linking it?
Is it possible to record various segments in the same file using this method?
I mean, for the first segment you set the base_time to 0, but if I want to encode another segment in the same file, by unliking the encoding tail and relinking it later, if I set the 'reset' property to TRUE this will reset the base_time to 0 again, when it should be setted to the elapsed time of the previous segment.
One last thing, if I pause the recording, by unlinking the encoding tail and setting its state to PAUSED, how do I send an EOS event to the muxer (which is not linked anymore) if I defenitively want to stop the recording?

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[SnOp-2]

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 ?

Thanks

2009/1/31 Arnout Vandecappelle <[hidden email]>

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                 [phone]
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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Arnout Vandecappelle]

On Saturday 31 January 2009 18:41:31 Andoni Morales wrote:
> The 'reset' property must be setted to true just before dinamically linking
> the encoder tail or after linking it?

 It must be set before the first buffer arrives that must be re-timestamped.  
In practice, that means before it is set to PAUSED.

> Is it possible to record various
> segments in the same file using this method? I mean, for the first segment
> you set the base_time to 0, but if I want to encode another segment in the
> same file, by unliking the encoding tail and relinking it later, if I set
> the 'reset' property to TRUE this will reset the base_time to 0 again, when
> it should be setted to the elapsed time of the previous segment.

 If you want to concatenate several pieces of stream with continuous
timestamps, it indeed won't work.  There is anyway no way you can do the
right thing there, since the first timestamp of the second piece has to be 'a
bit' later than the last one of the first piece, but there's no way of
knowing how much later (unless you have a known and fixed buffer rate).

 You best bet is to use the shift element from gentrans and calculate the
offsets manually.


> One last
> thing, if I pause the recording, by unlinking the encoding tail and setting
> its state to PAUSED, how do I send an EOS event to the muxer (which is not
> linked anymore) if I defenitively want to stop the recording?

 You have to push an EOS event either on an element or a pad, upstream from
the muxer, in the tail you're unlinking.  Since you're blocking on a pad you
have to take care it's downstream from the block, of course.  Also you have
to make sure there are no more queues behind it, otherwise the EOS will be
handled asynchronously which means you have to wait for an EOS message on the
bus before you actually unlink and destroy the elements.

 I have a block callback that looks like this:

static void pipe_tail_replace_block_cb (GstPad *pad, gboolean blocked,
gpointer user_data)
{
    if (!blocked)
    {
        error("pipe_tail_replace_cb called while not blocked!\n");
        free(user_data);
        return;
    }
    log_message("Pipe tail queue is blocked.\n");

    /* Close the output file by sending it an EOS.  That's the peer pad of
       the pad we're blocking on. Not the pad itself, that one is blocked! */
    gst_pad_send_event(GST_PAD_PEER(pad), gst_event_new_eos());

    /* Do the actual replacement in the main thread
       (it accesses global variables). */
    g_idle_add(pipe_tail_replace_cb, user_data);
}


 Regards,
 Arnout
--
Arnout Vandecappelle                               arnout at mind be
Senior Embedded Software Architect                 [phone]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Stefan Sauer]

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 <[hidden email] <mailto:[hidden email]>>
>
>     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                 [phone]
>     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
>     [hidden email]
>     <mailto:[hidden email]>
>     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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

------------------------------------------------------------------------------
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[René Stadler]

Marc wrote:

> Hi,
>
> 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:
>
>    1. Changing location property of filesink while playing (from
>       /dev/null to a real path). This is not possible (filesink tells me
>       so).
>    2. 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
>
> --
> Marc S.
>

I added an element called "camerabin" to gst-plugins-bad today, I think it is
exactly what you are looking for.

--
Regards,
   René Stadler

------------------------------------------------------------------------------
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Farkas Levente]

On Mon, Feb 9, 2009 at 11:05 PM, René Stadler <[hidden email]> wrote:

Marc wrote:
> Hi,
>
> 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:
>
>    1. Changing location property of filesink while playing (from
>       /dev/null to a real path). This is not possible (filesink tells me
>       so).
>    2. 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
>
> --
> Marc S.
>

I added an element called "camerabin" to gst-plugins-bad today, I think it is
exactly what you are looking for.

can you tell me a little bit more about this bin? any docs or usage?
thanks.


--
 Levente                               "Si vis pacem para bellum!"

------------------------------------------------------------------------------
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Lutz Müller-2]

On Tue, 2009-02-10 at 14:25 +0100, Farkas Levente wrote:

> can you tell me a little bit more about this bin? any docs or usage?
> thanks.

The documentation is available inline:
http://cgit.freedesktop.org/gstreamer/gst-plugins-bad/tree/gst/camerabin/gstcamerabin.c

It will be available online at
http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-bad-plugins/html/ (currently, it is not as the element is brand new...).

Regards

Lutz


------------------------------------------------------------------------------
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Farkas Levente]

Stefan Kost wrote:

> 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.

what's the right solution? ie. none hackish? or there is currently no
solution? it seems to be a very basic thing to me.

--
  Levente                               "Si vis pacem para bellum!"

------------------------------------------------------------------------------
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[SnOp-2]

Hello,

Thanks to your advice I managed to adapt the webcam viewer in the pygst tutorial (http://pygstdocs.berlios.de/pygst-tutorial/webcam-viewer.html) to perfom on demand recording without needing to stop the webcam live preview. You'll find the file attached to this mail. To overcome the timestamp issue the application modifies the buffer timestamp (using the buffer-probe approach).

I must say that this technique works way more fluently in an application made in Clutter than the example presented here. I guess it may be because the clutter version does not rescale the video output like the attached example.

Thank for your wise advice, folks.

2009/2/12 Farkas Levente <[hidden email]>

Stefan Kost wrote:
> 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.

what's the right solution? ie. none hackish? or there is currently no
solution? it seems to be a very basic thing to me.

--
 Levente                               "Si vis pacem para bellum!"

------------------------------------------------------------------------------
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

--
Marc S.

------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Frans van Berckel]

Hi Marc,

There is no software license documented in
webcam_noninterrupted_recorder.py yet.


Frans van Berckel

On Fri, 2009-02-13 at 18:27 +0100, Marc wrote:

> Hello,
>
> Thanks to your advice I managed to adapt the webcam viewer in the
> pygst tutorial
> (http://pygstdocs.berlios.de/pygst-tutorial/webcam-viewer.html) to
> perfom on demand recording without needing to stop the webcam live
> preview. You'll find the file attached to this mail. To overcome the
> timestamp issue the application modifies the buffer timestamp (using
> the buffer-probe approach).
>
> I must say that this technique works way more fluently in an
> application made in Clutter than the example presented here. I guess
> it may be because the clutter version does not rescale the video
> output like the attached example.
>
> Thank for your wise advice, folks.
>
> --
> Marc S.
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a $600 discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H

> gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel


------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Filippo Argiolas-2]

2009/1/30 Marc <[hidden email]>:
> Hi,
>
> I am trying to build an application more or less like Cheese
> (http://projects.gnome.org/cheese/).

May I ask why? why not to start contributing directly to Cheese to
make it better?
There is great room for improvements and we really had little time to
hack on it recently.
So, new contributors are always welcome ;-)

Cheers,
Filippo

------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel