Am 01.11.2016 17:17 schrieb "Andreas Cadhalpun" < andreas.cadhal...@googlemail.com>: > > On 01.11.2016 17:06, James Almer wrote: > > On 11/1/2016 12:54 PM, Andreas Cadhalpun wrote: > >> What I like about the approach of using the private extra_data context buffer is > >> that is is quite obvious where it is set. On the other hand the codecpar > >> extradata can be set anywhere, which makes it difficult to understand/debug. > >> The very bug this patch would fix is an excellent example of that. > >> > >> So I'd rather convert the apngdec demuxer to pass the extradata as side data. > >> I'll send a patch doing that. > > > > Is it worth doing that? This patch is pretty simple and solves the issue for > > both encoder and demuxer. > > With it the muxer will use either the original extradata or any new one sent > > within a packet. In both cases, the muxer uses its own buffer to keep it. > > > > I don't think changing the demuxer to append the same extradata it already > > sent during init() again with a packet makes sense. It's extra complexity > > for no gain. > > Not again, but instead, as the extradata is then only transferred as side data. > That way it is again consistent between demuxer/decoder and encoder/muxer. >
I don't think thats a good idea. Demuxers should fill the extradata field if any is present and required for decoding - some other decoder might want extradata for init or something, and that way you can accommodate it without having to wait for the first packet. That's basically how all demuxers work, will extradata and if it can and does change just send an update notice. - Hendrik _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
