[Haskell-cafe] Re: [Haskell] Google Summer of Code 2009
conrad at metadecks.org
Wed Feb 11 21:06:16 EST 2009
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
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.
>> 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
>> >>> licensing
>> >>> at all (it is created by ITU-T Video Coding Experts Group (VCEG)) so one
>> >>> can
>> >>> write H.263 in Haskell and release freely without patent licensing
>> >>> issues.
>> >>> 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
>> >>> improve
>> >>> 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
>> > decoding.
>> 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
More information about the Haskell-Cafe