On Thu, 17 Feb 2005 07:49:27 +0800
"HiNet" <[EMAIL PROTECTED]> wrote:
> > No, not needed to. Just get the scheduler to do it's job right.
> > But you'd be i/o limited anyways. Getting out two video uncompressed
> > video streams over PCI is .. well.. quite at the limit.
>
> In one hand one process must do video compression as high frame
> rate as it can. And that causes lots of disk io.
Disk IO is negilgible. It's just a few 100kByte/s
Even DVDs with very high bitrates are seldom over 3MByte/s.
What matters is the RAM<->CPU and RAM<->GPU bandwith, there
you are in the 10MByte/s-100MByte/s
(640*480pixel * 30fps * 2bytes/pixel = 18MByte/s
1024*768pixel * 30fps * 2bytes/pixel = 45MByte/s)
_This_ is the problem!
Note that a 33MHz 32bit PCI bus gets saturated somewhere
between 80 and 100MByte/s (theoretical max was iirc 135MByte/s)
> On the other hand, another
> process must show original uncompressed video streams in real time.
> Take 16 BT878 chips as an example, writing 480 frames(cif size) through
> PCI bus is not a problem if you ignore serious FIFO overrun.
480fps with 320x240 ? That's already 70MByte/s which is quite
close to saturation. Unless you are using 64bit or 66MHz PCI.
> But coming
> to flawless real time, the user space process can show each video stream
> 30 frames/sec in average.
Just one ?
> flawless?? No. There are other busy processes
> and this ocasionally causes some delay. Some time intervals between
> some of the two continuous frames would be longer than 1/30 second
> or even longer than 1/15 second, but still each video stream 30 frames/sec
> in average.
Yes, known problem. The player software needs real time scheduling
for this. Which requires root rights -> problem on comon systems.
There are some ways to mitigate that problem, but they are not
reliable.
But this discussion is going OT, i suggest to continue it on
mplayer-dev-eng or any other video player development list.
Attila Kinali
--
éãåããéãåã
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
