On Apr 6, 2011, at 6:33 PM, 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? > - 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?
I would like to export SEIs from H.264 pictures for the noble purpose of implementing film grain synthesis - that could use multiple side data streams. I'm not sure how the memory management would work, though. AVPacket would be easier to use if it had retain counting > - 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? MPEG-2 can change pix_fmt midstream, and we support width/height changing for several codecs. …although that's poorly specified/tested/not working with frame threads and I'd prefer to remove it. _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
