On Wed, 8 Oct 2003, Maarten De Boer wrote:
> > no flow control - what happens if the encoding can't, even momentarily,
> > keep up (disc accesses, other programs running, whatever)
>
> This is something I would like to comment on. Being an audio software
> developer, these are issues that I am rather familiar with. I guess that
> with audio, for example hard-disk recording, this is more of an issue:
> you might, perception-wise, get away with a dropped video frame, but not
With video you get the possibility of dropping both video and
audio - in a DV stream both are present. I don't believe
there's the option of telling the capture to "only drop frames
of video if we fall behind" ;)
> ears). These problems can be solved by using high scheduling priorities
> for time-critical applications, patching your kernel with the low latency
> and pre-emptible patches (the later is included with the 2.6.0-testX
> kernels), and doing disk access in a seperate thread with lower priority,
Those help a _lot_ but they are not a 100% guarantee. What
will happen if 'dvgrab' can't keep up? Gaps in the audio and
video is my guess.
ffmpeg isn't threaded and is unlikely to become threaded is the
feeling I have from mentions of that topic in the mailing list.
Oh - I have done high quality (but small - 320x240) MPEG-4
encoding on a Athlon 2800, around 2/3 real time. Without the
high quality options, etc it could do real time I am fairly sure.
Cheers,
Steven Schultz
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php
_______________________________________________
Mjpeg-users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/mjpeg-users
