vegac wrote:
The problem with the idea of the initial buffering is that no matter how big of a buffer you make, it will eventually run out because the slower O2's can't keep up with the codec...
Meaning: Even if you buffer 10 frames, by the time you hit frame 15 your buffer is depleted and you're lagging again - the only way to really do this would be to buffer enough to compensate for the remaining of the decode time - roughly 2/3 of the video would have to be pre-buffered, and if it runs slower than realtime (which it obviously does since you're having slowdown in the first place) that means to watch a movie you're taking a 90 minute pre-buffering before you even get the chance to enjoy your movie...
90 minutes of decompressed video would take more ram than these machines can hold!
On top of this there's the large number of audio sync issues it would introduce, as audio and video are decoded on their own and we'd have to also make a large buffer for audio...
Realistically, there's a limit to how much these machines can do, and these O2s especially are limited compared to say, Octanes.
Yes; I'm aplying the idea here on VideoTrackerRT with real success; but again, I'm working with shortest video-chunks, and in many cases the total-video-lenght fits perfectly on RAM; so, no problemas here!
But you're right, even if you could store 512 MBytes of uncompressed video in RAM, does not cover then the total lenght of the movie, and when the buffer be empty, the new process could not be attached on the processor schedule successfully with the movie even playing from RAM...
At this step, 60 seconds of uncompressed video without audio, on a typical DVD-rip resolution could be 900MBytes (60seconds x 15MBytes_per_second)
So, if you set a buffer-warning-level of about 20%, then the video could suffer an slowdown every 48 seconds; wich does not seems very comfortable.
On the case of VideoTrackerRT, it's using buffer-to-disk behind the second level of buffering, so, every video-preview with lenghts greater than 15 seconds is automatically writing to disk on uncompressed format. Then, you can play a preview at full rate motion quality.
Anyway, this method is suppossed to work with at least a 2x7200RPM striped array, to sustain easily more than 24 MBytes second.
I'm not running in troubles with the audio synch, since I have not audio processing even!
I think the only ways to do the job on this *crazy* (yeah!, I know, I Know!) way that I'm propossing could be:
1) Wait 100 minutes or more, browsing Neko-Forum with Mozilla, while your O2 fill a huge buffer on disk with uncompressed audio/video (81 GBytes for 90 minutes of very good quality video)
2) Take an hybrid aproach (like me), playing from disk while you render in RAM in background the next chunk before the new write down to disk. There is a complicated balance needed between the different processes: decoding, mem_buff, playing, decoding, write_mem_buff, write_mem_to_disk, etc...) But really works if the sum of bandwidths is less than max allowed, and specially if the playing action leaves some deegree of free resources on the processor and a lot of free resources in RAM.
3) Cray-Link two O2(s), and use one to decode to memory, and the second to play directly the result from RAM!
Beautiful if possibly!
Well; I guess that now, the math reveals that my aproachs are mainly intended for dual processor systems, or really big proc/mem/HD setups...
Or in my case, for movies of less than 10 minutes of duration!
Catch-up!
Login
Register
FAQ
Search
