id012c3076 at blueyonder.co.uk
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
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 !
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
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.
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