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

[Andreas Rheinhardt]

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.
> 

The usual order is the inverse of linking order (i.e. lavu-lavc-lavf).

>> (It has the advantage that e.g. missing lavu headers
>> in the lavf headers could be uncovered.)
> 
> Won't make checkheaders also find that?
> 

Some of our headers behave differently when included internally (when
DHAVE_AV_CONFIG_H is defined) than when included externally; the fftools
belong to the latter category, I believe checkheaders belongs to the former.

- Andreas