This seems to be due to the massive amounts of IO needed for realtime video <br><br>When I was working with YUV4Linux (basically a DVD stream without encryption or compression) for a 2 GB file I was getting 2 minutes and 18 seconds at PAL DV resolution. Raw rgb should be almost double that and rgba more than double. HD resolutions will double and quadruple the amount of memory/storage needed.<br>
<br>To get data between applications I was using Fifos. Which work, but are difficult to set up and tempremental at the best of times.<br><br>I don&#39;t think it would be that realistic to work with compression between applications in jack type situation. though colour space compression should be possible<br>
<br>to give some idea of the memory/disk IO requirements needed.<br>I did some quick calculations <br><br>comparing a pal dv sized stream 720 x 576 @ 25 frames a second<br>vs 48 000 samples per second floating point audio stream.<br>
<br>rgba 32bit float = 864 48k audio streams.<br>rgba 8bit int = 216 48k audio streams.<br>rgb 8 bit int =  162  48k audio streams<br>YCrCb 422 = 108 48k audio streams<br>YCrCb 420 = 81 48k audio streams<br><br>for 720p <br>
rgb 8bit = 360 48k audio streams<br>YCrCb 420 = 180  &quot; &quot; &quot;<br><br>for 1080p<br>rgb 8bit = 810 48k audio streams<br><br>Are there any other color spaces I should be worried about?<br><br>Most compositors use RGBA internally either as 8bit int or floats.<br>
FreiOr is a set of video plugins used by a lot of different video editing programs it prefers rgba 8888, (bgra8888 is the other option) so that format must at least be acceptable to a lot of video editors. Effectv is the other shared video plugin set I am aware of and it uses rgb888. <br>
Cinelerra supports RGBA float, RGBA 8888 &amp; YUVA 8888 and non Alpha varients of the above.<br><br>Perhaps the most sensible Idea would be to concider purhaps RGB(A) 888(8) and YUV(A) 888(8) as different types of port. <br>
<br><br><div class="gmail_quote">On Wed, Dec 2, 2009 at 11:33 AM, Paul Davis <span dir="ltr">&lt;<a href="mailto:paul@linuxaudiosystems.com">paul@linuxaudiosystems.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">On Tue, Dec 1, 2009 at 8:02 PM, Danni Coy &lt;<a href="mailto:danni.coy@gmail.com">danni.coy@gmail.com</a>&gt; wrote:<br>
&gt; You would be suprised. RGBA32 is used quite commonly in the compositor<br>
&gt; world, usually stored as a sequence of images, with even higher precisions<br>
&gt; available. Raw RGB24 is reasonably common with the video professionals I<br>
&gt; know, when I questioned them about it they said that they could acheive more<br>
&gt; film like colour grading than they could in any of the YUV colour spaces.<br>
&gt;<br>
&gt; It&#39;s probably not the best format for realtime work given the amount of data<br>
&gt; that needs to be transmitted (or maybe it is), I have previously worked with<br>
&gt; piping raw YUV (yuv4linux) between applications and having something like<br>
&gt; jack to manage the connections would be a godsend.<br>
<br>
</div>my understanding is that one of the many problems that video faces is<br>
that there truly is no equivalent to &quot;32 bit floating point for<br>
audio&quot;. whereas this format for audio samples is pretty much<br>
acceptable for just about all purposes, and the ones not satisfied by<br>
it are corner cases, in video there are many common cases that prefer<br>
quite different data representations. for an audio analogy, imagine a<br>
JACK world where some clients wanted FFT-bin data while others wanted<br>
floating point encoding of PCM.<br>
<br>
until or unless someone can step up and authoritatively say &quot;the<br>
interchange format for video is XXXXXX&quot;, its hard to imagine a &quot;jack<br>
for video&quot; system really working very usefully for a significant<br>
number of people. those who work entirely in the RGBA32 or YUV spaces<br>
would be happy with just that format; anyone mixing processing that is<br>
better suited to different formats is going to take a hell of a<br>
performance hit.<br>
<font color="#888888"><br>
--p<br>
</font></blockquote></div><br>