[racket] H264 Codec in Racket
Tony Garnock Jones has some bit comprehension libraries on planet I believe.
On Jun 14, 2012, at 8:12 PM, Anurag Mendhekar wrote:
>
> Thanks for all the helpful suggestions.
>
> 1. Full agreement on using macros to make things efficient. Ramakrishnan Muthukrishnan pointed me to an excellent paper on Bit-Comprehensions (think set/list comprehensions for bits) in Erlang and we are trying to use similar metaphors for h264 (the bit comprehensions don't directly translate due to context sensitivity of the h264 bit stream), but we will definitely be exploiting the power of macros for efficiency.
>
> 2. Typed racket is also something we will explore. Are there any benchmarks out there for typed v. untyped racket? Also, I'm assuming we can restrict ourselves to typed racket only where it really matters so that we can move back-and-forth between typed and untyped racket.
>
> Best,
>
> A.
> From: Eli Barzilay <eli at barzilay.org>
> To: Anurag Mendhekar <mendhekar at yahoo.com>
> Cc: "users at racket-lang.org" <users at racket-lang.org>
> Sent: Thursday, June 14, 2012 7:26 AM
> Subject: Re: [racket] H264 Codec in Racket
>
> More than a week ago, Anurag Mendhekar wrote:
> > I'm considering writing an H.264 encoder/decoder in Racket. Has
> > anyone tried such a thing before?
> >
> > Codecs require a lot of bit-whacking and the h264 standard is
> > particularly convoluted. Efficiencies are obtained in C in many
> > different and usually complex ways. Codec experts usually recommend
> > starting at C/++ and go to assembly to extract further performance.
> >
> > Does any one have thoughts on this? Would someone be interested in
> > working with me on an open-source project for this? I expect an
> > exercise like this will also push the Racket implementation to
> > deliver higher performance, or will establish a proof point about
> > how good the implementations is.
>
> You've got a bunch of suggestions -- and many of them focus on
> traditional aspects of these problems (like using TR to make the code
> run faster, the problem of dealing with 32-bit numbers etc). But one
> thing that wasn't mentioned is that Racket has the advantage of
> macros, which can often be used in such bit-whacking (nice term)
> situations. It can be used to easily pre-generate some code that
> would otherwise be too complicated to write. When you say
>
> Efficiencies are obtained in C in many different and usually
> complex ways.
>
> then my guess is that that's a perfect case for doing these kind of
> things.
>
> --
> ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
> http://barzilay.org/ Maze is Life!
>
>
> ____________________
> Racket Users list:
> http://lists.racket-lang.org/users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20120614/eebcf4a5/attachment.html>