Re: [FFmpeg-devel] [PATCH 07/10] lavf: document that AVStream::codecpar may be modified by lavf after avformat_write_header(). This is assumed not to break API because it's already true (see e.g. matr

Could we just declare that lavf can update extradata (and nothing else) if it gets packets with new-extradata side-data? If not, I suppose we could either add something to AVStreamInternal, or do something internal in check_bitstream (and update movenc and matroskaenc, as both exhibit this behav

Re: [FFmpeg-devel] [PATCH 07/10] lavf: document that AVStream::codecpar may be modified by lavf after avformat_write_header(). This is assumed not to break API because it's already true (see e.g. matr

On Fri, Mar 16, 2018 at 12:29 AM, Michael Niedermayer wrote: > On Wed, Mar 14, 2018 at 01:24:42AM -0500, Rodger Combs wrote: >> --- >> libavformat/avformat.h | 3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) >> >> diff --git a/libavformat/avformat.h b/libavformat/avformat.h >> index 9e87

Re: [FFmpeg-devel] [PATCH 07/10] lavf: document that AVStream::codecpar may be modified by lavf after avformat_write_header(). This is assumed not to break API because it's already true (see e.g. matr

On Wed, Mar 14, 2018 at 01:24:42AM -0500, Rodger Combs wrote: > --- > libavformat/avformat.h | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/libavformat/avformat.h b/libavformat/avformat.h > index 9e87d6cdac..5f0ebfc114 100644 > --- a/libavformat/avformat.h > +++ b/liba

Re: [FFmpeg-devel] [PATCH 07/10] lavf: document that AVStream::codecpar may be modified by lavf after avformat_write_header(). This is assumed not to break API because it's already true (see e.g. matr

On 3/14/2018 3:24 AM, Rodger Combs wrote: > This is assumed not to break API because it's already true (see e.g. > matroskaenc handling of new AAC extradata) That's an API violation from the muxer's part instead. The correct approach is to fix the violation, not adapt the API around it. > --- >