> Date: Sat, 20 Mar 2010 19:23:40 -0700
> From: giles at thaumas.net
>
> We've talked about it, but one of the problems is that the current API
> is one-frame-in-one-frame-out, so it's not clear how to pass multiple
> input frames at once without breaking API. How would you implement
> that?
If I understand you correctly, you could do the Microsoft method of making a
new function called th_encode_ycbr_in_ex() that takes multiple frames if
that's what you need (although I don't understand how this is
necessary). Abstractly, you can avoid "breaking API" by adding
functionality rather than changing it...
> There is some scope for multithreading the per-frame pipeline, but
> that only scales to three or four threads.
Does it scale any worse than Vorbis? There are many applications that don't
scale well past two or four threads so you'll be in good company. It will
certainly help in the short term and, in the long term, we may never need to
scale it higher than that, much like how multi-threading is rarely used for
audio encoding anymore... It certainly won't be any worse than it is now
where you can't thread it at all!
_________________________________________________________________
IM on the go with Messenger on your phone
http://go.microsoft.com/?linkid=9712960
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.xiph.org/pipermail/theora-dev/attachments/20100321/92941ce7/attachment.htm