[FFmpeg-devel] grabbing from dv1394

[Michael Niedermayer]

Hi
On Wed, Jun 06, 2007 at 01:58:54AM +0300, Tommi Sakari Uimonen wrote:
> >> I got the dv1394 grabbing working with a patch from
> >> http://svn.pardus.org.tr/pardus/devel/applications/multimedia/ffmpeg/files/ffmpeg-dv1394.patch
> >>
> >> I grab with:
> >>
> >> ./ffmpeg -f dv1394 -i /dev/dv1394/0 -f avi -acodec copy -vcodec copy -y
> >> outfile.avi
> 
> > You should always post the *complete* output messages. In this case, it
> > would have told us the actual containers, codecs, sizes, ...
> 
> For first grabbing test, I mount my disk with -o remount,sync. The result 
> being that only 7 frames get written of about 30 seconds of running.
> 
[...]
> > You are writing raw video to file. That eats a lot of I/O resources, and
> > a large fraction of that use will be concentrated in bursts - which will
> > interfere with the interrupts from the TV card.
> 
> Raw dv in PAL format and 48kHz stereo wav is roughly 4MB/s (estimated up). 
> Even old IDE harddisks can cope with this. My old AthlonXP was able to 
> grab 90min dv (using dvgrab) without one single frame lost.
> 
> AFAIK, Firewire was designed not to be 'bursty' (like USB is), but to 
> guarantee steady data stream. Of course I'm just waving hands and I 
> really don't know the internals of the implementation. And even if 
> firewire gives steady flow, the other resources might be on the bursty 
> side of the road.
> 
> > There are various ways: patch ffmpeg so that there is an fsync after
> > every write; or a sync(2) after every frame write; or a separate process
> > that does a sync(2) every second; or write to a partition that is
> > mounted with -o sync.
> 
> The sync may not be the answer here, as it proved to be extremely slow.
> And dvgrab performs fine on async filesystem, that rules out the I/O 
> resource issues.
> 
> I haven't yet browsed the code enough to see if the grabbing and writing 
> to disk are done in separate threads. At least in audio grabbing 
> (Ardour,ecasound and other decent hd recorders) it is a must that the disk 
> thread and audio thread are separated. Otherwise it will result to audio 
> dropouts.
> 
> Maybe I should also dig into the dvgrab code to see what it does 
> differently.

maybe, also trying with just video or just audio
looking at syslog, trying with /dev/null or a ramdisk as destination
could be helpfull in debuging this for whoever does (not me)

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Good people do not need laws to tell them to act responsibly, while bad
people will find a way around the laws. -- Plato
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070606/b50ac24e/attachment.pgp>