[FFmpeg-devel] [PATCH 05/24] ffmpeg: move some muxing-related code into a separate file

[Anton Khirnov]

Quoting Andreas Rheinhardt (2021-12-17 02:55:43)
> Anton Khirnov:
> > This is a first step towards making muxers more independent from the
> > rest of the code.
> > ---
> >  fftools/Makefile     |  11 +-
> >  fftools/ffmpeg.c     | 273 ++--------------------------------------
> >  fftools/ffmpeg.h     |  10 ++
> >  fftools/ffmpeg_mux.c | 293 +++++++++++++++++++++++++++++++++++++++++++
> >  4 files changed, 320 insertions(+), 267 deletions(-)
> >  create mode 100644 fftools/ffmpeg_mux.c
> > 
> > diff --git a/fftools/ffmpeg_mux.c b/fftools/ffmpeg_mux.c
> > new file mode 100644
> > index 0000000000..e7c6ddd8f8
> > --- /dev/null
> > +++ b/fftools/ffmpeg_mux.c
> > @@ -0,0 +1,293 @@
> > +/*
> > + * This file is part of FFmpeg.
> > + *
> > + * FFmpeg is free software; you can redistribute it and/or
> > + * modify it under the terms of the GNU Lesser General Public
> > + * License as published by the Free Software Foundation; either
> > + * version 2.1 of the License, or (at your option) any later version.
> > + *
> > + * FFmpeg is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> > + * Lesser General Public License for more details.
> > + *
> > + * You should have received a copy of the GNU Lesser General Public
> > + * License along with FFmpeg; if not, write to the Free Software
> > + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
> > + */
> > +
> > +#include <stdio.h>
> > +#include <string.h>
> > +
> > +#include "libavformat/avformat.h"
> > +#include "libavformat/avio.h"
> > +
> > +#include "libavcodec/packet.h"
> > +
> > +#include "libavutil/fifo.h"
> > +#include "libavutil/intreadwrite.h"
> > +#include "libavutil/log.h"
> > +#include "libavutil/mem.h"
> > +#include "libavutil/timestamp.h"
> > +
> > +#include "ffmpeg.h"
> > +
> 
> These library headers are ordered reversely to our usual order. Is
> this intended?

I am not aware of there being a usual order. So no, it's not.

> (It has the advantage that e.g. missing lavu headers
> in the lavf headers could be uncovered.)

Won't make checkheaders also find that?

-- 
Anton Khirnov