[Haskell-cafe] Re: [Haskell] Google Summer of Code 2009

[Achim Schneider]

Jamie <haskell at datakids.org> wrote:

> 
> On Thu, 12 Feb 2009, Conrad Parker wrote:
> 
> > 2009/2/12 Don Stewart <dons at galois.com>:
> >> Thanks for the analysis, this clarifies things greatly.
> >> Feasibility and scope is a big part of how we determine what
> >> projects to work on.
> >
> > I agree that it's beyond the scope of a SoC project.
> >
> > Rather than H.263 or H.264 I was going to suggest implementation of
> > Theora or OMS, both of which avoid the patent issues and have
> > publicly available specs:
> >
> > http://theora.org/doc/Theora.pdf
> > http://www.openmediacommons.org/collateral/OMS-video-v0.9.pdf
> >
> > Scanning those documents should give anyone a fair idea of the
> > amount of work involved. My understanding is that OMS is of a
> > similar complexity to H.263, and H.264 is more complex than any of
> > these.
> >
> > 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.

-- 
(c) this sig last receiving data processing entity. Inspect headers
for copyright history. All rights reserved. Copying, hiring, renting,
performance and/or quoting of this signature prohibited.