[Ffmpeg-devel] [PATCH] C93 demuxer and decoder (GSoC qualification task)

Michael Niedermayer michaelni
Thu Apr 5 22:08:30 CEST 2007


Hi

On Thu, Apr 05, 2007 at 10:36:15PM +0300, Anssi Hannula wrote:
[...]
> > [...]
> >> +    if (*buf++ & C93_HAS_PALETTE) {
> >> +        uint32_t *palette = (uint32_t *) newpic->data[1];
> >> +        c93->palette_changed = 1;
> >> +        for (i = 0; i < 256; i++) {
> >> +            palette[i] = bytestream_get_be24(&buf);
> >> +        }
> >> +    } else {
> >> +        buf += 256 * 3;
> >> +        if (c93->palette_changed) {
> >> +            memcpy(newpic->data[1], oldpic->data[1], 256 * 4);
> >> +            c93->palette_changed = 0;
> >> +        }
> > 
> > what is the palette_changed code good for?
> 
> So that the palette is only copied when it has really changed.
> Is the overhead of copying so negligible that there is no need for that?

yes 786 bytes copy per frame compared to 320x192=61440 bytes copy per frame
is negligible also considering that for many blocks its more than just
copy


[...]
> > 
> > [...]
> >> +    ret = av_new_packet(pkt, datasize + 768 + 1);
> >> +    if (ret < 0)
> >> +        return ret;
> >> +    pkt->data[0] = 0;
> >> +
> >> +    ret = get_buffer(pb, pkt->data + 768 + 1, datasize);
> >> +    if (ret < datasize) {
> >> +        av_free_packet(pkt);
> >> +        return AVERROR_IO;
> >> +    }
> >> +
> >> +    datasize = get_le16(pb); /* palette size */
> >> +    if (datasize) {
> >> +        if (datasize != 768) {
> >> +            av_log(s, AV_LOG_ERROR, "invalid palette size %u\n", datasize);
> >> +            av_free_packet(pkt);
> >> +            return AVERROR_INVALIDDATA;
> >> +        }
> >> +        pkt->data[0] |= C93_HAS_PALETTE;
> >> +        ret = get_buffer(pb, pkt->data + 1, datasize);
> >> +        if (ret < datasize) {
> >> +            av_free_packet(pkt);
> >> +            return AVERROR_IO;
> >> +        }
> >> +    }
> > 
> > if there is no palette pkt->size should be decreased by 768
> 
> Even when the 768 unused bytes are in the beginning of the pkt instead
> of the end?

hmm, i missed that, i just thought if the packets get stored in some other
container (like avi) it would be better to avoid the extra useless 768 bytes

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I know you won't believe me, but the highest form of Human Excellence is
to question oneself and others. -- Socrates
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070405/7c5bdd38/attachment.pgp>



More information about the ffmpeg-devel mailing list