On Thu, 12 Feb 2009, Achim Schneider wrote:
Jamie <hask...@datakids.org> wrote:
For Theora playback we've found that the largest CPU load comes from
colorspace conversion, where the YUV output of the codec needs to be
converted to RGB for some targets (like Firefox). That is some
fairly straightforward array processing, and would be a good place
to start for anyone trying to implement video codecs in Haskell.
That is great idea and a great seed to plant. Wonder if Theora is as
good as H.264 in terms of video quality and bandwidth usage?
Theora isn't meant to be a H.264 competitor, but a replacement for
flash, wmv and the ilk. I dare to guess that it works decent for low
bitrates, especially if you're more interested in detecting shapes than
skin pores. I guess you just have to do field tests: encoding video on
the fly just isn't what general-purpose CPUs are made for, it's the
playing field of processors that take SIMD seriously, i.e. GPUs.
Signers (deaf people or "hearing" people who know sign language) naturally
put strong emphasize on smooth video quality (i.e. at least 25 fps with no
blurries/fuzzy). I use Mirial Softphone (to me, a best H.323/SIP video
softphone so far, run on Windows) and it runs very nicely and perfectly on
my Dell 1 GHz Centrind Duo laptop in both H.263 and H.264 (I even tried
H.264 at 704x576 at 30 FPS and it works real nice).
However Mirial sure did display "CPU overload" message time to time on my
Samsung NC10 netbook especially using H.264 and result in pixelization of
video frames.
So no problem at all with my Dell laptop but kind of borderline on Atom
1.6Ghz netbook. I agree it would surely help offload the CPU work when
there is hardware encoder/decoder present in GPU. I see more and more GPU
now support H.264 decoder which is nice.
Jamie
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
