[FFmpeg-devel] grabbing from dv1394

[Roman Shaposhnick]

On Tue, 2007-07-10 at 23:39 +0300, Tommi Sakari Uimonen wrote:
> >> The single thread approach works for
> >> encoding disk streams but not for realtime usage.
> >
> >  Could you, please, elaborate on this one?
> 
> Yes, it was a bit uninformative and merely waving hands.
> 
> I mean that if the DV capturing and disk writing are done in the same 
> thread so that the capture must wait until the write() finishes, it is 
> possible that some frames get dropped because of write being momentarily 
> slow due to other disk activity.

  True, but that's what you have a ring buffer for. You tell the
hardware where to store the data and all you have to care about is
that you have enough of slack to compensate for jitter and stuff.
As a matter of fact, with the new Linux system calls splice()/vmsplice()
and tee() you might even do very cool things like "syncless" IO. The
bottom line, however, is that as long as hardware knows what to do
and have enough storage space to perform its job -- it doesn't really
matter whether you're reading/writing that data from the same thread 
or not.

> I might be wrong of course that write() does not wait at all even if there 
> is disk activity (the O_NONBLOCK option at open()) but to my understanding 
> all these so called realtime critical processes like capturing audio from 
> soundcard or capturing DV from camera should be done in two separate 
> threads; 

  Well, first of all -- quite a few things become kernel threads
(tasks?) without you even realizing it. So the fact that you still have
just one user thread is not really that important. It seems to me
that what you say applies only to the case where you have 2 or more
blocking IO operations going on at the same time. If you have only
one the threading argument doesn't hold. In the case of DV capturing
you really have just one blocking point -- a write to disk. Reading
from the FireWire is not even handled by your CPU (well, almost).

> The comment about single threads and encoding disk streams meant that even 
> slow computers finish their tasks without losing frames - they just take 
> longer time to get there, hence the "time" is no realtime and there is no 
> need for special manouvers.

  I guess I don't quite follow the above argument.

> But I admit that using two threads is not the answer, since dvgrab is not 
> using any realtime privileges for the threads, so it must be something 
> extra that ffmpeg does, or maybe ffmpeg uses too small ringbuffer, or 
> maybe ffmpeg is too fast and processes some frames twice - that would 
> explain some of the jerkiness and incomplete frames on the output.

  What kernel are you running this on?

Thanks,
Roman.