On Wed, Apr 06, 2011 at 06:33:46PM -0400, Ronald S. Bultje wrote: > Hi, > > On Wed, Apr 6, 2011 at 4:26 PM, Kostya Shishkov > <[email protected]> wrote: > > This adds side information to AVPacket > > > > --- > > libavcodec/avcodec.h | 21 +++++++++++++++++++++ > > libavcodec/avpacket.c | 39 +++++++++++++++++++++++++++++++++++++++ > > libavcodec/version.h | 2 +- > > 3 files changed, 61 insertions(+), 1 deletions(-) > > There's some issues here: > - what if we consider the "palette" as side-data in a stream with pal1 > pkt1 pkt2 pkt3 pal2 pkt4 pkt5 pkt6 pal3 pkt7 pkt8 pk9, and we seek to > (the start of) pkt6? Is anyone (demuxer, probably) in charge of > "forcing" the updated side-data after a seek?
unfortunately, no unless demuxer knows new palette chunk positions and reads them along (can be done for some AVIs though, patchiswelcome) > - what if we want multiple types of "side data"? E.g. RTSP with a > palette _and_ a sequence nr.? I'd prefer separate variables for each > of them in AVPacket, if we go this way. Any reason you want this > generic side-data thing and have only one of them in AVPacket, instead > of at least an array? Feel free to extend as you see fit. For now I don't see any real-world collisions in side data but it should be easy to extend. > - I don't quite understand why we do special handling of palette > changing in midstream, but no such thing for the (hypothetical) case > of pix_fmt changing mid-stream, or codec changing midstream. Is that > just because it doesn't happen in practice? It happens but for most things it's not a normal practice (except for codec change in some broadcast streams) while palette change is quite common with palettised codecs and many containers (mostly for game codecs) have special palette change chunk. _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
