Recording Video

Ian Davidson id012c3076 at
Fri Dec 14 10:13:11 PST 2012

Please can you advise me.

I am attempting to record audio/video which I expect to last up to 1½ 
hours.  If I try to do that as one single file, storing as AVI, I get a 
file which is over 2GB and that causes problems.  Therefore, I like to 
record 3 shorter videos - and in the past I have manually stopped the 
recording at a 'convenient point' and started a new recording - keeping 
each recording to a maximum of 40 minutes.

An alternative approach would be to record for a certain time and then 
automatically stop and start a new recording.  This would mean that the 
recording break would probably come when someone was speaking, so there 
would be a little 'hiccup'.  I wrote the script below to see how much of 
a gap there was between successive recordings (the camera was pointing 
at a digital clock showing seconds).  The videos did not turn out quite 
as I expected.

v4l2-ctl -i 1
while [ $counter -lt 3 ]; do
     let counter=counter+1
     gst-launch-1.0 -e v4l2src norm=PAL num-buffers=100 ! 
! queue ! mux. alsasrc num-buffers=440 ! audioconvert ! 
'audio/x-raw,rate=44100,channels=2' ! queue ! mux. avimux name=mux ! 
filesink location="$fullFileName"

It would appear that video-1 was fine.  Video-2 then started and there 
was a slight break in the audio from the end of video-1. However, the 
video content of video-2 has a 4 second gap in the middle of the clip.

I assume that the 2 sources v4l2src and alsasrc are each set to produce 
the nominated number of buffers - and that's what they are going to do.  
The fact that one source has produced an EOS (I assume) does not stop 
the other.

Would I be correct in assuming that, if I wrote a C program, rather than 
using gst-launch, I would be able close both sources down at a time that 
suited me?  And also that I cannot do it using gst-launch?



By the way, thanks to those who have already got me this far.
Ian Davidson
Facts used in this message may or may not reflect an underlying 
objective reality. Facts are supplied for personal use only.
Recipients quoting supplied information do so at their own risk. Facts 
supplied may vary in whole or part from widely accepted standards.
While painstakingly researched, facts may or may not be indicative of 
actually occurring events or natural phenomena.
The author accepts no responsibility for personal loss or injury 
resulting from memorisation and subsequent use.

More information about the gstreamer-devel mailing list