[gst-devel] Dropped frames at gstbaseaudiosrc

[Mark Nauwelaerts]

Sebastian Vöcking wrote:
> Hello!
> 
> I have a small problem. I am trying to record from my tv card with
> v4l2src. It works well unless I don't add sound to the pipeline. As soon
> as I record sound as well I get warnings about dropped frames and my
> videos end up shorter than they should be. If I construct my pipeline
> with gst-launch I can reproduce the problem:
> 
> gst-launch-0.10 v4l2src ! theoraenc ! oggmux name="ogg" alsasrc !
> audio/x-raw-int,rate=32000 ! audioconvert ! vorbisenc ! ogg. ogg. !
> filesink location=test.ogg
> 
> <snip>
> WARNING: from element /pipeline0/alsasrc0: Internal GStreamer error:
> clock problem.  Please file a bug at
> http://bugzilla.gnome.org/enter_bug.cgi?product=GStreamer.
> Additional debug info:
> gstbaseaudiosrc.c(583): gst_base_audio_src_create
> (): /pipeline0/alsasrc0:
> dropped 14322 samples
>
> Using osssrc or using a different audio device leads to the same
> problem. But I exchange v4l2src with videotestsrc or alsasrc with
> audiotestsrc everything is fine.

I have had this happening too.  The message about clock problem is a bit
misleading or at least not so explanatory (and has changed a bit in latest release).

What happens is;
data is copied from device (buffers) into an intermediate ringbuffer, and then
taken from this ringbuffer and pushed out.  The messages indicate that the
ringbuffer is not being emptied fast enough, causing samples (as indicated) to
be dropped.  audiotestsrc does not use such a ringbuffer (IIRC), so there isn't
one that can be complained about.  Using videotestsrc may lead to a simpler
video pattern that compresses easier/faster.

What to do about it (possibly);
allow for "looser/more" threading and/or buffering, e.g.
- use queue in one or both of the streams going into the muxer
(e.g. before the encoder element)
- in gst-plugins-good cvs (soon to be released), the property queue-size (of
v4l2src) controls the number of (device/hardware) buffers into which frames are
captured (within limits of course that the devicedriver can/will handle)
- simlarly, alsasrc (and osssrc) properties buffer-time and latency-time
determine the total buffer size and individual buffer size
However, note that "determine" is relative; this is again a request to the
device/driver, only to be satisfied within limits (-v switch might show the
actual real values that are eventually applied)
Also, these parameters affect both the device buffer settings as well as the
intermediate ringbuffer size (the latter seems a bit strange ?, as data is
actually copied from the former into the latter).

[see also
http://gentrans.sourceforge.net/docs/head/manual/html/howto.html#sect-recording
for some talk about recording]

Regards,
Mark.