[Haskell-cafe] Re: [Haskell] Google Summer of Code 2009
haskell at datakids.org
Thu Feb 12 07:45:59 EST 2009
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:
> 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 codec is being used in Ekiga (popular SIP/H.323 video softphone but
that thing keeps crashing on me :( )
>>> On Wed, Feb 11, 2009 at 21:00, Jamie <haskell at datakids.org> wrote:
>>>> Hi Gwern,
>>>> On Wed, 11 Feb 2009, Gwern Branwen wrote:
>>>>>> I just checked H.263 and it looks like it does not require patent
>>>>>> at all (it is created by ITU-T Video Coding Experts Group (VCEG)) so one
>>>>>> write H.263 in Haskell and release freely without patent licensing
>>>>>> So writing H.263 in Haskell could be a good GSoC project. One mentioned
>>>>>> that GHC produce slow code, well H.263 could be a good test case to
>>>>>> GHC optimization over time. In The Computer Language Benchmarks Game,
>>>>>> Haskell has some catching up to do. :)
>>>>> It does sound like a reasonably discrete task, and it sounds like you have
>>>>> a use for it; but I wonder if it's doable in a single summer?
>>>> I have no idea, I have not dig deeper into H.263 C source code but I guess
>>>> it should be quite trivial as it is a black box with video frame input and
>>>> output with several parameters for encoding and just frame in/out for
>>> I didn't dig into the source code either, but I've just skimmed
>>> through Wikipedia page on that codec:
>>> and in seems far from trivial. Anything that has 23 annexes is likely
>>> to be quite complex :-)
>>> Therefore I seriously doubt chances for success of such project. I did
>>> some checks: in libavcodec at least following files consist of
>>> implementation of H.263:
>>> h263.c h263data.h h263dec.c h263.h
>>> h263_parser.c h263_parser.h
>>> How many lines are there?
>>> [Tener at laptener libavcodec]$ wc h263*
>>> 6295 19280 218932 h263.c
>>> 314 2117 10423 h263data.h
>>> 816 2171 26675 h263dec.c
>>> 46 217 2032 h263.h
>>> 91 282 2361 h263_parser.c
>>> 29 165 1047 h263_parser.h
>>> 7591 24232 261470 razem
>>> In Haskell project one would also need to provide some additional
>>> utility code which is part of libavcodec.
>>> Fast grep shows the tip of an iceberg:
>>> [Tener at laptener libavcodec]$ grep include h263* | grep -v "<"
>>> h263.c:#include "dsputil.h"
>>> h263.c:#include "avcodec.h"
>>> h263.c:#include "mpegvideo.h"
>>> h263.c:#include "h263data.h"
>>> h263.c:#include "mpeg4data.h"
>>> h263.c:#include "mathops.h"
>>> h263data.h:#include "mpegvideo.h"
>>> h263dec.c:#include "avcodec.h"
>>> h263dec.c:#include "dsputil.h"
>>> h263dec.c:#include "mpegvideo.h"
>>> h263dec.c:#include "h263_parser.h"
>>> h263dec.c:#include "mpeg4video_parser.h"
>>> h263dec.c:#include "msmpeg4.h"
>>> h263.h:#include "config.h"
>>> h263.h:#include "msmpeg4.h"
>>> h263_parser.c:#include "parser.h"
>>> h263_parser.h:#include "parser.h"
>>> Bottom line: I don't think it is reasonable to assume anyone without
>>> previous knowledge of H.263 is able to fit that project into one
>>> summer. But! It's Haskell community, and people here see the
>>> impossible happen from time to time ;-)
>>> All best
>>> Christopher Skrzętnicki
>>> Haskell-Cafe mailing list
>>> Haskell-Cafe at haskell.org
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
More information about the Haskell-Cafe