[PATCH] exr: piz decompression
Signed-off-by: Paul B Mahol <onemda@gmail.com> --- libavcodec/exr.c | 477 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 477 insertions(+) diff --git a/libavcodec/exr.c b/libavcodec/exr.c index 7e9e68c..a65e6ba 100644 --- a/libavcodec/exr.c +++ b/libavcodec/exr.c @@ -32,6 +32,7 @@ #include <zlib.h> +#include "get_bits.h" #include "avcodec.h" #include "bytestream.h" #include "mathops.h" @@ -54,6 +55,9 @@ typedef struct EXRThreadData { uint8_t *tmp; int tmp_size; + + uint8_t *bitmap; + uint16_t *lut; } EXRThreadData; typedef struct EXRContext { @@ -259,6 +263,471 @@ static int rle_uncompress(const uint8_t *src, int compressed_size, return 0; } +#define USHORT_RANGE (1 << 16) +#define BITMAP_SIZE (1 << 13) + +static uint16_t reverse_lut(const uint8_t *bitmap, uint16_t *lut) +{ + int i, k = 0; + + for (i = 0; i < USHORT_RANGE; ++i) { + if ((i == 0) || (bitmap[i >> 3] & (1 << (i & 7)))) + lut[k++] = i; + } + + i = k - 1; + + memset(lut + k, 0, (USHORT_RANGE - k) * 2); + + return i; +} + +static void apply_lut(const uint16_t *lut, uint16_t *dst, int dsize) +{ + int i; + + for (i = 0; i < dsize; ++i) + dst[i] = lut[dst[i]]; +} + +#define HUF_ENCBITS 16 // literal (value) bit length +#define HUF_DECBITS 14 // decoding bit size (>= 8) + +#define HUF_ENCSIZE ((1 << HUF_ENCBITS) + 1) // encoding table size +#define HUF_DECSIZE (1 << HUF_DECBITS) // decoding table size +#define HUF_DECMASK (HUF_DECSIZE - 1) + +typedef struct HufDec { + int len:8; + int lit:24; + int *p; +} HufDec; + +static void huf_canonical_code_table(uint64_t *hcode) +{ + uint64_t c, n[59] = { 0 }; + int i; + + /* + * For each i from 0 through 58, count the + * number of different codes of length i, and + * store the count in n[i]. + */ + for (i = 0; i < HUF_ENCSIZE; ++i) + n[hcode[i]] += 1; + + /* + * For each i from 58 through 1, compute the + * numerically lowest code with length i, and + * store that code in n[i]. + */ + c = 0; + for (i = 58; i > 0; --i) { + uint64_t nc = ((c + n[i]) >> 1); + n[i] = c; + c = nc; + } + + /* + * hcode[i] contains the length, l, of the + * code for symbol i. Assign the next available + * code of length l to the symbol and store both + * l and the code in hcode[i]. + */ + for (i = 0; i < HUF_ENCSIZE; ++i) { + int l = hcode[i]; + + if (l > 0) + hcode[i] = l | (n[l]++ << 6); + } +} + +#define SHORT_ZEROCODE_RUN 59 +#define LONG_ZEROCODE_RUN 63 +#define SHORTEST_LONG_RUN (2 + LONG_ZEROCODE_RUN - SHORT_ZEROCODE_RUN) +#define LONGEST_LONG_RUN (255 + SHORTEST_LONG_RUN) + +static int huf_unpack_enc_table(GetByteContext *gb, + int32_t im, int32_t iM, uint64_t *hcode) +{ + GetBitContext gbit; + + init_get_bits8(&gbit, gb->buffer, bytestream2_get_bytes_left(gb)); + + for (; im <= iM; im++) { + uint64_t l = hcode[im] = get_bits(&gbit, 6); + + if (l == LONG_ZEROCODE_RUN) { + int zerun = get_bits(&gbit, 8) + SHORTEST_LONG_RUN; + + if (im + zerun > iM + 1) + return AVERROR_INVALIDDATA; + + while (zerun--) + hcode[im++] = 0; + + im--; + } else if (l >= (uint64_t) SHORT_ZEROCODE_RUN) { + int zerun = l - SHORT_ZEROCODE_RUN + 2; + + if (im + zerun > iM + 1) + return AVERROR_INVALIDDATA; + + while (zerun--) + hcode[im++] = 0; + + im--; + } + } + + bytestream2_skip(gb, (get_bits_count(&gbit) + 7) / 8); + huf_canonical_code_table(hcode); + + return 0; +} + +static int huf_build_dec_table(const uint64_t *hcode, int im, + int iM, HufDec *hdecod) +{ + for (; im <= iM; im++) { + uint64_t c = hcode[im] >> 6; + int i, l = hcode[im] & 63; + + if (c >> l) + return AVERROR_INVALIDDATA; + + if (l > HUF_DECBITS) { + HufDec *pl = hdecod + (c >> (l - HUF_DECBITS)); + if (pl->len) + return AVERROR_INVALIDDATA; + + pl->lit++; + + if (pl->p) + pl->p = av_realloc_f(pl->p, pl->lit, sizeof(int)); + else + pl->p = av_malloc(sizeof(int)); + if (!pl->p) + return AVERROR(ENOMEM); + + pl->p[pl->lit - 1] = im; + } else if (l) { + HufDec *pl = hdecod + (c << (HUF_DECBITS - l)); + + for (i = 1 << (HUF_DECBITS - l); i > 0; i--, pl++) { + if (pl->len || pl->p) + return AVERROR_INVALIDDATA; + pl->len = l; + pl->lit = im; + } + } + } + + return 0; +} + +#define get_char(c, lc, gb) { \ + c = (c << 8) | bytestream2_get_byte(gb); \ + lc += 8; \ +} + +#define get_code(po, rlc, c, lc, gb, out, oe) { \ + if (po == rlc) { \ + if (lc < 8) \ + get_char(c, lc, gb); \ + lc -= 8; \ + \ + uint8_t cs = (c >> lc); \ + \ + if (out + cs > oe) \ + return AVERROR_INVALIDDATA; \ + \ + uint16_t s = out[-1]; \ + \ + while (cs-- > 0) \ + *out++ = s; \ + } else if (out < oe) { \ + *out++ = po; \ + } else { \ + return AVERROR_INVALIDDATA; \ + } \ +} + +static int huf_decode(const uint64_t *hcode, const HufDec *hdecod, + GetByteContext *gb, int nbits, + int rlc, int no, uint16_t *out) +{ + uint64_t c = 0; + int lc = 0; + uint16_t *outb = out; + uint16_t *oe = out + no; + const uint8_t *ie = gb->buffer + (nbits + 7) / 8; // input byte size + + while (gb->buffer < ie) { + get_char(c, lc, gb); + + while (lc >= HUF_DECBITS) { + const HufDec pl = hdecod[(c >> (lc-HUF_DECBITS)) & HUF_DECMASK]; + + if (pl.len) { + lc -= pl.len; + get_code(pl.lit, rlc, c, lc, gb, out, oe); + } else { + int j; + + if (!pl.p) + return AVERROR_INVALIDDATA; + + for (j = 0; j < pl.lit; j++) { + int l = hcode[pl.p[j]] & 63; + + while (lc < l && bytestream2_get_bytes_left(gb) > 0) + get_char(c, lc, gb); + + if (lc >= l) { + if ((hcode[pl.p[j]] >> 6) == + ((c >> (lc - l)) & ((1LL << l) - 1))) { + lc -= l; + get_code(pl.p[j], rlc, c, lc, gb, out, oe); + break; + } + } + } + + if (j == pl.lit) + return AVERROR_INVALIDDATA; + } + } + } + + int i = (8 - nbits) & 7; + c >>= i; + lc -= i; + + while (lc > 0) { + const HufDec pl = hdecod[(c << (HUF_DECBITS - lc)) & HUF_DECMASK]; + + if (pl.len) { + lc -= pl.len; + get_code(pl.lit, rlc, c, lc, gb, out, oe); + } else { + return AVERROR_INVALIDDATA; + } + } + + if (out - outb != no) + return AVERROR_INVALIDDATA; + return 0; +} + +static int huf_uncompress(GetByteContext *gb, + uint16_t *dst, int dst_size) +{ + int32_t src_size, im, iM; + uint32_t tableLength, nBits; + uint64_t *freq; + HufDec *hdec; + int ret, i; + + src_size = bytestream2_get_le32(gb); + im = bytestream2_get_le32(gb); + iM = bytestream2_get_le32(gb); + tableLength = bytestream2_get_le32(gb); + nBits = bytestream2_get_le32(gb); + if (im < 0 || im >= HUF_ENCSIZE || + iM < 0 || iM >= HUF_ENCSIZE || + src_size < 0) + return AVERROR_INVALIDDATA; + + bytestream2_skip(gb, 4); + + freq = av_malloc(HUF_ENCSIZE * sizeof(uint64_t)); + hdec = av_mallocz(HUF_DECSIZE * sizeof(HufDec)); + if (!freq || !hdec) + return AVERROR(ENOMEM); + + if ((ret = huf_unpack_enc_table(gb, im, iM, freq)) < 0) + return ret; + + if (nBits > 8 * bytestream2_get_bytes_left(gb)) + return AVERROR_INVALIDDATA; + + if ((ret = huf_build_dec_table(freq, im, iM, hdec)) < 0) + return ret; + if ((ret = huf_decode(freq, hdec, gb, nBits, iM, dst_size, dst)) < 0) + return ret; + + for (i = 0; i < HUF_DECSIZE; i++) { + if (hdec[i].p) + av_free(hdec[i].p); + } + + av_free(freq); + av_free(hdec); + + return 0; +} + +static inline void wdec14(uint16_t l, uint16_t h, uint16_t *a, uint16_t *b) +{ + int16_t ls = l; + int16_t hs = h; + int hi = hs; + int ai = ls + (hi & 1) + (hi >> 1); + int16_t as = ai; + int16_t bs = ai - hi; + + *a = as; + *b = bs; +} + +#define NBITS 16 +#define A_OFFSET (1 << (NBITS - 1)) +#define MOD_MASK ((1 << NBITS) - 1) + +static inline void wdec16(uint16_t l, uint16_t h, uint16_t *a, uint16_t *b) +{ + int m = l; + int d = h; + int bb = (m - (d >> 1)) & MOD_MASK; + int aa = (d + bb - A_OFFSET) & MOD_MASK; + *b = bb; + *a = aa; +} + +static void wav_decode(uint16_t *in, int nx, int ox, + int ny, int oy, uint16_t mx) +{ + int w14 = (mx < (1 << 14)); + int n = (nx > ny) ? ny: nx; + int p = 1; + int p2; + + while (p <= n) + p <<= 1; + + p >>= 1; + p2 = p; + p >>= 1; + + while (p >= 1) { + uint16_t *py = in; + uint16_t *ey = in + oy * (ny - p2); + uint16_t i00, i01, i10, i11; + int oy1 = oy * p; + int oy2 = oy * p2; + int ox1 = ox * p; + int ox2 = ox * p2; + + for (; py <= ey; py += oy2) { + uint16_t *px = py; + uint16_t *ex = py + ox * (nx - p2); + + + for (; px <= ex; px += ox2) { + uint16_t *p01 = px + ox1; + uint16_t *p10 = px + oy1; + uint16_t *p11 = p10 + ox1; + + if (w14) { + wdec14(*px, *p10, &i00, &i10); + wdec14(*p01, *p11, &i01, &i11); + wdec14(i00, i01, px, p01); + wdec14(i10, i11, p10, p11); + } else { + wdec16(*px, *p10, &i00, &i10); + wdec16(*p01, *p11, &i01, &i11); + wdec16(i00, i01, px, p01); + wdec16(i10, i11, p10, p11); + } + } + + if (nx & p) { + uint16_t *p10 = px + oy1; + + if (w14) + wdec14(*px, *p10, &i00, p10); + else + wdec16(*px, *p10, &i00, p10); + + *px= i00; + } + } + + if (ny & p) { + uint16_t *px = py; + uint16_t *ex = py + ox * (nx - p2); + + for (; px <= ex; px += ox2) { + uint16_t *p01 = px + ox1; + + if (w14) + wdec14(*px, *p01, &i00, p01); + else + wdec16(*px, *p01, &i00, p01); + + *px = i00; + } + } + + p2 = p; + p >>= 1; + } +} + +static int piz_uncompress(EXRContext *s, const uint8_t *src, int ssize, int dsize, EXRThreadData *td) +{ + GetByteContext gb; + uint16_t maxval, min_non_zero, max_non_zero; + uint16_t *ptr, *tmp = (uint16_t *)td->tmp; + int8_t *out; + int ret, i, ysize; + + if (!td->bitmap) + td->bitmap = av_malloc(BITMAP_SIZE); + if (!td->lut) + td->lut = av_malloc(1 << 17); + if (!td->bitmap || !td->lut) + return AVERROR(ENOMEM); + + bytestream2_init(&gb, src, ssize); + min_non_zero = bytestream2_get_le16(&gb); + max_non_zero = bytestream2_get_le16(&gb); + + if (max_non_zero >= BITMAP_SIZE) + return AVERROR_INVALIDDATA; + + memset(td->bitmap, 0, FFMIN(min_non_zero, BITMAP_SIZE)); + if (min_non_zero <= max_non_zero) + bytestream2_get_buffer(&gb, td->bitmap + min_non_zero, max_non_zero - min_non_zero + 1); + + maxval = reverse_lut(td->bitmap, td->lut); + + ret = huf_uncompress(&gb, tmp, dsize / sizeof(int16_t)); + if (ret) + return ret; + + ysize = dsize / (s->xdelta * 2 * s->desc->nb_components); + + ptr = tmp; + for (i = 0; i < s->desc->nb_components; i++, ptr += s->xdelta * ysize) + wav_decode(ptr, s->xdelta, 1, ysize, s->xdelta, maxval); + + apply_lut(td->lut, tmp, dsize / sizeof(int16_t)); + + out = td->uncompressed_data; + for (i = 0; i < ysize; i++) { + int j; + for (j = 0; j < s->desc->nb_components; j++) { + uint16_t *in = tmp + j * s->xdelta * ysize + i * s->xdelta; + memcpy(out, in, s->xdelta * 2); + out += s->xdelta * 2; + } + } + + return 0; +} + static int decode_block(AVCodecContext *avctx, void *tdata, int jobnr, int threadnr) { @@ -310,6 +779,9 @@ static int decode_block(AVCodecContext *avctx, void *tdata, case EXR_ZIP16: ret = zip_uncompress(src, data_size, uncompressed_size, td); break; + case EXR_PIZ: + ret = piz_uncompress(s, src, data_size, uncompressed_size, td); + break; case EXR_RLE: ret = rle_uncompress(src, data_size, uncompressed_size, td); } @@ -626,6 +1098,9 @@ static int decode_frame(AVCodecContext *avctx, case EXR_ZIP16: s->scan_lines_per_block = 16; break; + case EXR_PIZ: + s->scan_lines_per_block = 32; + break; default: av_log(avctx, AV_LOG_ERROR, "Compression type %d is not supported\n", s->compr); return AVERROR_PATCHWELCOME; @@ -721,6 +1196,8 @@ static av_cold int decode_end(AVCodecContext *avctx) EXRThreadData *td = &s->thread_data[i]; av_free(td->uncompressed_data); av_free(td->tmp); + av_free(td->bitmap); + av_free(td->lut); } av_freep(&s->thread_data); -- 1.7.11.4
On 2/27/13, Paul B Mahol <onemda@gmail.com> wrote:
Signed-off-by: Paul B Mahol <onemda@gmail.com> --- libavcodec/exr.c | 477 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 477 insertions(+)
ping
On Tue, Mar 05, 2013 at 01:47:43PM +0000, Paul B Mahol wrote:
On 2/27/13, Paul B Mahol <onemda@gmail.com> wrote:
Signed-off-by: Paul B Mahol <onemda@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?
On 3/5/13, Reimar Doeffinger <Reimar.Doeffinger@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@gmail.com> wrote:
Signed-off-by: Paul B Mahol <onemda@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.
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On Tue, Mar 05, 2013 at 08:06:37PM +0000, Paul B Mahol wrote:
On 3/5/13, Reimar Doeffinger <Reimar.Doeffinger@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@gmail.com> wrote:
Signed-off-by: Paul B Mahol <onemda@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. 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. Though I admit I don't know how code it would save in the end.
On 3/5/13, Reimar Doeffinger <Reimar.Doeffinger@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@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@gmail.com> wrote:
Signed-off-by: Paul B Mahol <onemda@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?
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.
Though I admit I don't know how code it would save in the end. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On Wed, Mar 06, 2013 at 12:54:13PM +0000, Paul B Mahol wrote:
On 3/5/13, Reimar Doeffinger <Reimar.Doeffinger@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@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@gmail.com> wrote:
Signed-off-by: Paul B Mahol <onemda@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.
On 2013-03-06 1:32 PM, Reimar Döffinger wrote:
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.
Hint hint. Nudge nudge. - Derek
Hi,
Signed-off-by: Paul B Mahol <onemda@gmail.com>
libavcodec/exr.c | 477 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 477 insertions(+)
diff --git a/libavcodec/exr.c b/libavcodec/exr.c index 7e9e68c..a65e6ba 100644 --- a/libavcodec/exr.c +++ b/libavcodec/exr.c
What is the status of this patch? Regards
On Sun, Aug 11, 2013 at 04:23:54PM +0200, Piotr Bandurski wrote:
Hi,
Signed-off-by: Paul B Mahol <onemda@gmail.com>
libavcodec/exr.c | 477 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 477 insertions(+)
diff --git a/libavcodec/exr.c b/libavcodec/exr.c index 7e9e68c..a65e6ba 100644 --- a/libavcodec/exr.c +++ b/libavcodec/exr.c
What is the status of this patch?
I suspect it is kind of waiting for someone to figure out if this is rather ordinary huffman/VLC coding as I guessed and thus should be using the functions we have for that instead of reimplementing it or if I'm completely off...
On 8/11/13, Reimar Doeffinger <Reimar.Doeffinger@gmx.de> wrote:
On Sun, Aug 11, 2013 at 04:23:54PM +0200, Piotr Bandurski wrote:
Hi,
Signed-off-by: Paul B Mahol <onemda@gmail.com>
libavcodec/exr.c | 477 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 477 insertions(+)
diff --git a/libavcodec/exr.c b/libavcodec/exr.c index 7e9e68c..a65e6ba 100644 --- a/libavcodec/exr.c +++ b/libavcodec/exr.c
What is the status of this patch?
I suspect it is kind of waiting for someone to figure out if this is rather ordinary huffman/VLC coding as I guessed and thus should be using the functions we have for that instead of reimplementing it or if I'm completely off...
I will apply this unless someone shows this really can be used by existing code.
On 09.10.2013, at 15:22, Paul B Mahol <onemda@gmail.com> wrote:
On 8/11/13, Reimar Doeffinger <Reimar.Doeffinger@gmx.de> wrote:
On Sun, Aug 11, 2013 at 04:23:54PM +0200, Piotr Bandurski wrote:
Hi,
Signed-off-by: Paul B Mahol <onemda@gmail.com>
libavcodec/exr.c | 477 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 477 insertions(+)
diff --git a/libavcodec/exr.c b/libavcodec/exr.c index 7e9e68c..a65e6ba 100644 --- a/libavcodec/exr.c +++ b/libavcodec/exr.c
What is the status of this patch?
I suspect it is kind of waiting for someone to figure out if this is rather ordinary huffman/VLC coding as I guessed and thus should be using the functions we have for that instead of reimplementing it or if I'm completely off...
I will apply this unless someone shows this really can be used by existing code.
What needs to be shown? The generic vlc code should handle basically any kind of variable length code to symbol conversion. I think that is what the code does, though I don't fully understand it - assuming you understand the code that should answer whether it can be used? Whether the huffman code could be reused is more tricky, and I don't really care about it, it just might have been one way to make more clear what kind of concepts this codec uses and how it differs from how it is done commonly.
On 10/10/13, Reimar Doeffinger <Reimar.Doeffinger@gmx.de> wrote:
On 09.10.2013, at 15:22, Paul B Mahol <onemda@gmail.com> wrote:
On 8/11/13, Reimar Doeffinger <Reimar.Doeffinger@gmx.de> wrote:
On Sun, Aug 11, 2013 at 04:23:54PM +0200, Piotr Bandurski wrote:
Hi,
Signed-off-by: Paul B Mahol <onemda@gmail.com>
libavcodec/exr.c | 477 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 477 insertions(+)
diff --git a/libavcodec/exr.c b/libavcodec/exr.c index 7e9e68c..a65e6ba 100644 --- a/libavcodec/exr.c +++ b/libavcodec/exr.c
What is the status of this patch?
I suspect it is kind of waiting for someone to figure out if this is rather ordinary huffman/VLC coding as I guessed and thus should be using the functions we have for that instead of reimplementing it or if I'm completely off...
I will apply this unless someone shows this really can be used by existing code.
What needs to be shown? The generic vlc code should handle basically any kind of variable length code to symbol conversion. I think that is what the code does, though I don't fully understand it - assuming you understand the code that should answer whether it can be used? Whether the huffman code could be reused is more tricky, and I don't really care about it, it just might have been one way to make more clear what kind of concepts this codec uses and how it differs from how it is done commonly.
Looks like neither you nor me can do it so I will apply this as is (with additional issues fixed).
On 10.10.2013, at 12:48, Paul B Mahol <onemda@gmail.com> wrote:
On 10/10/13, Reimar Doeffinger <Reimar.Doeffinger@gmx.de> wrote:
On 09.10.2013, at 15:22, Paul B Mahol <onemda@gmail.com> wrote:
On 8/11/13, Reimar Doeffinger <Reimar.Doeffinger@gmx.de> wrote:
On Sun, Aug 11, 2013 at 04:23:54PM +0200, Piotr Bandurski wrote:
Hi,
> Signed-off-by: Paul B Mahol <onemda@gmail.com> --- libavcodec/exr.c | 477 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 477 insertions(+)
diff --git a/libavcodec/exr.c b/libavcodec/exr.c index 7e9e68c..a65e6ba 100644 --- a/libavcodec/exr.c +++ b/libavcodec/exr.c
What is the status of this patch?
I suspect it is kind of waiting for someone to figure out if this is rather ordinary huffman/VLC coding as I guessed and thus should be using the functions we have for that instead of reimplementing it or if I'm completely off...
I will apply this unless someone shows this really can be used by existing code.
What needs to be shown? The generic vlc code should handle basically any kind of variable length code to symbol conversion. I think that is what the code does, though I don't fully understand it - assuming you understand the code that should answer whether it can be used? Whether the huffman code could be reused is more tricky, and I don't really care about it, it just might have been one way to make more clear what kind of concepts this codec uses and how it differs from how it is done commonly.
Looks like neither you nor me can do it so I will apply this as is (with additional issues fixed).
I very much expect I could, though I don't care one bit about this feature, so avoiding messy code duplication is the only reason for me to do it. Is there a good specification of the format? I definitely don't want to do it if I have to reverse-engineer your code into a specification first...
On 10/11/13, Reimar Doeffinger <Reimar.Doeffinger@gmx.de> wrote:
On 10.10.2013, at 12:48, Paul B Mahol <onemda@gmail.com> wrote:
On 10/10/13, Reimar Doeffinger <Reimar.Doeffinger@gmx.de> wrote:
On 09.10.2013, at 15:22, Paul B Mahol <onemda@gmail.com> wrote:
On 8/11/13, Reimar Doeffinger <Reimar.Doeffinger@gmx.de> wrote:
On Sun, Aug 11, 2013 at 04:23:54PM +0200, Piotr Bandurski wrote:
Hi,
>> Signed-off-by: Paul B Mahol <onemda@gmail.com> > --- > libavcodec/exr.c | 477 > +++++++++++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 477 insertions(+) > > diff --git a/libavcodec/exr.c b/libavcodec/exr.c > index 7e9e68c..a65e6ba 100644 > --- a/libavcodec/exr.c > +++ b/libavcodec/exr.c
What is the status of this patch?
I suspect it is kind of waiting for someone to figure out if this is rather ordinary huffman/VLC coding as I guessed and thus should be using the functions we have for that instead of reimplementing it or if I'm completely off...
I will apply this unless someone shows this really can be used by existing code.
What needs to be shown? The generic vlc code should handle basically any kind of variable length code to symbol conversion. I think that is what the code does, though I don't fully understand it - assuming you understand the code that should answer whether it can be used? Whether the huffman code could be reused is more tricky, and I don't really care about it, it just might have been one way to make more clear what kind of concepts this codec uses and how it differs from how it is done commonly.
Looks like neither you nor me can do it so I will apply this as is (with additional issues fixed).
I very much expect I could, though I don't care one bit about this feature, so avoiding messy code duplication is the only reason for me to do it. Is there a good specification of the format? I definitely don't want to do it if I have to reverse-engineer your code into a specification first...
There is no specification for this codec(its is based on PIZ image though), all documents points to take look at OpenEXR source code.
On 11.10.2013, at 18:58, Paul B Mahol <onemda@gmail.com> wrote:
On 10/11/13, Reimar Doeffinger <Reimar.Doeffinger@gmx.de> wrote:
On 10.10.2013, at 12:48, Paul B Mahol <onemda@gmail.com> wrote:
On 10/10/13, Reimar Doeffinger <Reimar.Doeffinger@gmx.de> wrote:
On 09.10.2013, at 15:22, Paul B Mahol <onemda@gmail.com> wrote:
On 8/11/13, Reimar Doeffinger <Reimar.Doeffinger@gmx.de> wrote:
On Sun, Aug 11, 2013 at 04:23:54PM +0200, Piotr Bandurski wrote: > Hi, > >>> Signed-off-by: Paul B Mahol <onemda@gmail.com> >> --- >> libavcodec/exr.c | 477 >> +++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> 1 file changed, 477 insertions(+) >> >> diff --git a/libavcodec/exr.c b/libavcodec/exr.c >> index 7e9e68c..a65e6ba 100644 >> --- a/libavcodec/exr.c >> +++ b/libavcodec/exr.c > > What is the status of this patch?
I suspect it is kind of waiting for someone to figure out if this is rather ordinary huffman/VLC coding as I guessed and thus should be using the functions we have for that instead of reimplementing it or if I'm completely off...
I will apply this unless someone shows this really can be used by existing code.
What needs to be shown? The generic vlc code should handle basically any kind of variable length code to symbol conversion. I think that is what the code does, though I don't fully understand it - assuming you understand the code that should answer whether it can be used? Whether the huffman code could be reused is more tricky, and I don't really care about it, it just might have been one way to make more clear what kind of concepts this codec uses and how it differs from how it is done commonly.
Looks like neither you nor me can do it so I will apply this as is (with additional issues fixed).
I very much expect I could, though I don't care one bit about this feature, so avoiding messy code duplication is the only reason for me to do it. Is there a good specification of the format? I definitely don't want to do it if I have to reverse-engineer your code into a specification first...
There is no specification for this codec(its is based on PIZ image though), all documents points to take look at OpenEXR source code.
Oh well. I guess go ahead then. Maybe I'll find time to try to make it reuse the VLC code, but it will be some time. Litlle value in letting the patch rot. Of course I'd welcome anyone looking into it.
participants (4)
-
Derek Buitenhuis -
Paul B Mahol -
Piotr Bandurski -
Reimar Döffinger