[FFmpeg-devel] [PATCH] exr: piz decompression
Reimar.Doeffinger at gmx.de
Wed Mar 6 19:32:59 CET 2013
On Wed, Mar 06, 2013 at 12:54:13PM +0000, Paul B Mahol wrote:
> On 3/5/13, Reimar Doeffinger <Reimar.Doeffinger at gmx.de> wrote:
> > On Tue, Mar 05, 2013 at 08:06:37PM +0000, Paul B Mahol wrote:
> >> On 3/5/13, Reimar Doeffinger <Reimar.Doeffinger at gmx.de> wrote:
> >> > On Tue, Mar 05, 2013 at 01:47:43PM +0000, Paul B Mahol wrote:
> >> >> On 2/27/13, Paul B Mahol <onemda at gmail.com> wrote:
> >> >> > Signed-off-by: Paul B Mahol <onemda at gmail.com>
> >> >> > ---
> >> >> > libavcodec/exr.c | 477
> >> >> > +++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >> >> > 1 file changed, 477 insertions(+)
> >> >> >
> >> >>
> >> >> ping
> >> >
> >> > Well, it's a good bit of code so I don't have time to properly
> >> > review, but maybe you explain why it's not possible to reuse
> >> > the existing huffman and/or VLC code?
> >> This one is 16 bit, and other huffman code looks different.
> > Well, it looks that this one specifies the coding by the lengths,
> > I can't find a table for that.
> Table for what?
I meant function. A function that can build the necessary VLC
tables based on a table of coded lengths.
> > But the original symbols are 16 bit for the existing huffman code,
> > so I don't know what you mean by that?
> > Also I was also wondering about why it isn't reusing the get_vlc code,
> > because that one looks flexible enough to me to reuse it.
> I can't see how get_vlc is gonna be useful.
Well, to me it looks like the get_code macro and most of the huf_decode
function reimplements things that get_vlc already does.
Though to be honest I find it quite hard to wrap my head around what the code
actually does since so many variable names are only two letters of which I can at
best guess what they stand for.
More information about the ffmpeg-devel