Hello,
On Tue, Jan 30, 2007 at 12:13:11AM +0100, Michael Niedermayer wrote:
> On Mon, Jan 29, 2007 at 11:03:26PM +0100, Reimar D?ffinger wrote:
> > @@ -498,6 +497,13 @@
> > /* make a note of where the stream is sitting */
> > s->next_chunk_offset = url_ftell(pb);
> >
> > + if (palette_changed) {
> > + if (av_new_packet(pkt, AVPALETTE_SIZE))
> > + chunk_type = CHUNK_NOMEM;
> > + memcpy(pkt->data, s->palette, AVPALETTE_SIZE);
>
> are you aware that you put endian specific data into the AVPacket? this is
> not good at all
> i would rather pass the palette as it is stored to the decoder (unless of
> course the specific codec can be stored in several containers and expects
> some specific format)
The way it is stored is a partial and in additon 6 bit per component
palette. Though honestly I don't get why the palette is in host
endianness in the first place. I may simplify the conversion to RGB32
but (probably) complicates all other cases.
I can use the palette as MPlayer expects it (always LE), which has the
advantage that the swscale functions actually work with it (though it
does help much as long as the format in AVFrame stays endian-dependant).
> also i would pass the palette like a normal video frame into the decoder
> instead of using AVCodecContext
Sure, that would be preferable, but how to tell the decoder this is a
palette? Adding a flag parameter to the decode function? That would make
for quite a huge patch a (and a lot of work to make it)...
Advantage: that way could also be used for some other kinds of "extradata".
Greetings,
Reimar D?ffinger
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4