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.rheinha...@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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".