On 04/02/2011 05:06 PM, Kostya wrote: > On Sat, Apr 02, 2011 at 04:06:44AM -0700, Ronald S. Bultje wrote: >> Hi, >> >> On Sat, Apr 2, 2011 at 2:52 AM, Kostya <[email protected]> wrote: >>> I think this can be resolved by passing new palette in AVPacket in some way: >>> 0) do nothing and pretent that problem doesn't exist >>> 1a) just add AV_PKG_FLAG_PAL and make codec treat last 1024 bytes of data as >>> palette (should be done for muxers too). Alternatively packet size may be >>> hacked so palette will be after declared packet end (but that's too hacky to >>> my taste). >>> 1å) add AV_PKT_FLAG_PAL and pass only palette change in packet (it may break >>> timestamp handling, I fear) >>> 2) introduce some specific fields in AVPacket for passing such information >>> (too hacky IMO) >> >> Since you're implementing it, I think you should choose. >> AV_PKT_FLAG_PAL sounds fine, but it does feel a little clunky. I also >> feel having a new "uint8_t *palette_data;" pointer is fine also, then >> you don't have to change all data to data[0]. > > Since Luca wants to smuggle something too, I've chosen more generic name. > Proof-of-concept patches attached. >
Nice, that reminds me that today I noticed that av_dup_packet should be documented a bit more since might behave in surprising ways... lu -- Luca Barbato Gentoo/linux http://dev.gentoo.org/~lu_zero _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
