[FFmpeg-devel] [PATCH 01/17] avformat/mxfenc: Auto-insert h264_mp4toannexb BSF if needed

[Tomas Härdin]

ons 2021-11-10 klockan 14:21 +0100 skrev Andreas Rheinhardt:
> Tomas Härdin:
> > tis 2021-11-09 klockan 22:07 +0100 skrev Andreas Rheinhardt:
> > > Tomas Härdin:
> > > > tis 2021-11-09 klockan 18:34 +0100 skrev Andreas Rheinhardt:
> > > > > The mxf and mxf_opatom muxer expect H.264 in Annex B format.
> > > > > 
> > > > > Signed-off-by: Andreas Rheinhardt
> > > > > <andreas.rheinhardt at outlook.com>
> > > > > ---
> > > > > The check here is taken from mpegtsenc.
> > > > 
> > > > You didn't think to make both muxers share code instead of
> > > > copy-
> > > > pasting?
> > > > 
> > > 
> > > Well, I can share it. The problem is just that I didn't really
> > > know
> > > where it belongs: mux.c? utils.c? A new file?
> > 
> > A new file probably, say libavformat/annexb.c
> > 
> > Do we ever need to be able to do this kind of stuff in lavc? In
> > that
> > case it could maybe live there. But that again increases coupling
> > between the two libs..
> > 
> 
> lavc does not have AVStreams or AVFormatContexts, so sharing code
> would
> be absolutely impossible anyway. But one can share ideas: Using a bsf
> to
> prepare data for a decoder is also done for certain decoders; see
> AVCodec.bsfs. These bitstream filters are applied unconditionally and
> are therefore supposed to detect themselves whether they should do
> something or whether the data already has the desired form. I am
> unsure
> whether this is a better approach; doing the same in lavf would add a
> problem that lavc does not have: There would be a copy of every
> non-refcounted packet when using av_write_frame().

Just noting here that it might be that we shouldn't even insert a BSF.
See my comment on patch 03.

/Tomas