1 Dec
2009
1 Dec
'09
10:27 p.m.
On 12/02/2009 12:33 PM, Paul Davis wrote:
On Tue, Dec 1, 2009 at 8:02 PM, Danni
Coy<danni.coy(a)gmail.com> wrote:
Anyone who has those extreme requirements can probably afford to buy the
hardware required to run the system.
2 playstation3 boxes would probably provide enough grunt to manage the
load for converting on the fly between the formats.
Patrick Shirkey
Boost Hardware Ltd
You would be suprised. RGBA32 is used quite
commonly in the compositor
world, usually stored as a sequence of images, with even higher precisions
available. Raw RGB24 is reasonably common with the video professionals I
know, when I questioned them about it they said that they could acheive more
film like colour grading than they could in any of the YUV colour spaces.
It's probably not the best format for realtime work given the amount of data
that needs to be transmitted (or maybe it is), I have previously worked with
piping raw YUV (yuv4linux) between applications and having something like
jack to manage the connections would be a godsend.
my understanding is that one of the many problems that video faces is
that there truly is no equivalent to "32 bit floating point for
audio". whereas this format for audio samples is pretty much
acceptable for just about all purposes, and the ones not satisfied by
it are corner cases, in video there are many common cases that prefer
quite different data representations. for an audio analogy, imagine a
JACK world where some clients wanted FFT-bin data while others wanted
floating point encoding of PCM.
until or unless someone can step up and authoritatively say "the
interchange format for video is XXXXXX", its hard to imagine a "jack
for video" system really working very usefully for a significant
number of people. those who work entirely in the RGBA32 or YUV spaces
would be happy with just that format; anyone mixing processing that is
better suited to different formats is going to take a hell of a
performance hit.