[racket] H264 Codec in Racket

Very cool. I'll check them out in detail. In the meantime, I'm still trying to figure out how we can either apply the comprehensions directly, or extend them to handle h264 streams. 

Some of the challenges in this context:  Think of almost any variable length binary protocol you know. It usually has some indication of how long the variable portion of the packet is going to be, or a very predictable 'end-of-section' marker. So it is usually straight-forward to express this as a comprehension, and provides for elegant and efficient packet processing architectures. 

H.264, on the other hand, uses 3-4 different forms of binary encoding (including arithmetic coding) which only makes sense if you continuously decode every bit that comes in. It is my sense that this is impossible to express as a comprehension without using set!'s. Not the whole stream is like this so there are places where comprehensions make sense but the boundaries are unavailable once you encounter an entropy-coded portion of the stream. 

This, along with other complexities in the standard,  cause h264 code to be mostly hideous, although video coding is based on very elegant mathematics. One of my goals of doing this in Scheme is to bring that elegance into real implementations. 

(OK, probably not the best discussion for this forum, but I thought I'd share my thinking :-) 


Best,


A. 

________________________________
 From: Matthias Felleisen <matthias at ccs.neu.edu>
To: Anurag Mendhekar <mendhekar at yahoo.com> 
Cc: "users at racket-lang.org" <users at racket-lang.org>; Eli Barzilay <eli at barzilay.org> 
Sent: Thursday, June 14, 2012 5:18 PM
Subject: Re: [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/0564ea25/attachment-0001.html>