Marghanita da Cruz <[email protected]> writes:
> Sridhar Dhanapalan wrote:
>
>> Yes, it's a slight derivation of the script we used at LCA2007, which uses
>> ffmpeg2theora. It's worked well for us so far. If there's a problem, I
>> suspect it's with the installed copy of ffmpeg2theora.
>
> There are a couple of other possible causes:
>
> * as Martin suggested disk isn't keeping up (in the capture - assuming
> DVGRAB). Though my experience of capture (Kino/DVGRAB) is the computer
> display has/should have lower priority - so, I have to track the capture
> on the camcorder display
Ah. When I was doing DV capture, some time ago, I found that frame dropping
was pretty hard to avoid. Even running to a five disk RAID-0 with a gig of
memory for caching I found that none of the common file systems at the time[1]
would robustly keep up.
In the end I found the most reliable "solution" was:
while sleep 1; do sync; done
That works independently of the filesystem; testing showed that XFS hurt less
for other things at the same time, but there was little other difference.
Ugly, but it kept data flowing out smoothly rather than in bursts that tended
to cause frame dropping. Sadly, given the figures that have shown up in the
current per-BDI flushing work on the kernel it *still* looks like 2.6.30 has
problems keeping a smooth dataflow on create — though that might finally
change in the .31 or .32 timeframe.
Regards,
Daniel
Footnotes:
[1] XFS, ext2, ext3 in all three data modes.
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
