On Sat, Jul 21, 2018 at 05:36:02PM -0300, James Almer wrote: > On 7/21/2018 4:54 PM, Michael Niedermayer wrote: > > On Sat, Jul 21, 2018 at 02:28:21PM -0300, James Almer wrote: > >> And add it to the list of configurable components in Makefile, so changes > >> to > >> the file will be tracked and the usual warning to suggest re-running > >> configure > >> will be shown. > >> > >> Signed-off-by: James Almer <jamr...@gmail.com> > >> --- > >> Makefile | 1 + > >> configure | 2 +- > >> libavcodec/Makefile | 1 + > >> libavcodec/parser.c | 85 ---------------------------------- > >> libavcodec/parsers.c | 106 +++++++++++++++++++++++++++++++++++++++++++ > >> 5 files changed, 109 insertions(+), 86 deletions(-) > >> create mode 100644 libavcodec/parsers.c > > > > parser.c, parsers.c parser_list.c > > > > decode.c (no decoder.c, no decoders, no decoder_list.c, no parse.c) > > encode.c (matching decode but differing from parser) > > > > seems a bit inconsistent, naming wise. > > decode.c and encode.c are not component related files. They are the same > as parser.c is now, containing API independent of available components. > > It still could use some cleaning, in any case. We have the following > right now: > > allcodecs.c (list of decoders and encoders, plus related > iteration/register API) > codec_list.c (generated file for enabled decoders and encoders) > decode.c (non iteration/register related decoder API functions) > encode.c (non iteration/register related encoder API functions) > > allfilters.c (list of filters, plus related iteration/register API) > filter_list.c (generated file for enabled filters) > > allformats.c (list of demuxers and muxers, plus related > iteration/register API) > demuxer_list.c (generated file for enabled demuxers) > muxer_list.c (generated file for enabled muxers) > > alldevices.c (list of indevs and outdevs, plus related > iteration/register API) > indev_list.c (generated file for enabled indevs) > outdev_list.c (generated file for enabled outdevs) > > protocols.c (list of protocols, plus related iteration/register API) > protocol_list.c (generated file for enabled protocols) > > bitstream_filters.c (list of bsfs, plus related iteration/register API) > bsf_list.c (generated file for enabled bsfs) > bsf.c (non iteration/register related bsf API functions) > bitstream_filter.c (deprecated bsf API, to be removed in a major bump) > > parsers.c (list of parsers, plus related iteration/register API) > parser_list.c (generated file for enabled parsers) > parser.c (non iteration/register related parser API functions) > >
> We could add the "all" prefix to the last three component list files. We > could rename parser.c into parse.c to be in line with decode/encode.c. > We could split the generated list of decoders and encoders into their > own files. We could look into moving the deprecated bsf functions into > the main bsf file and choose a consistent naming for them all (bsf is > shorter and probably best), etc. > > I can look into doing some cleaning in this regard if we come to a > consensus as to what should be done. This patch was mainly to get the > file listing available parsers to trigger the Makefile message in case > of changes, while making sure it only happens when new parsers are added > instead of every time a bug is fixed in av_parser_parse2() or any other > such function. Iam in favor of any cleanup in respect to file naming that makes things more logically, easy to understand and consistently structured. Then again i also dont intend here to push anyone toward anything. If you have any doubt about some change on the naming then its better to leave it, we can always rename something later but renaming and then undoing would be alot more annoying. I just wanted to bring attention to the naming as it seemed to me that it was inconsistent for no obvious reason PS: the file list you wrote in that mail, this should be in some more vissible place i think than a mail on the ML thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Awnsering whenever a program halts or runs forever is On a turing machine, in general impossible (turings halting problem). On any real computer, always possible as a real computer has a finite number of states N, and will either halt in less than N cycles or never halt.
signature.asc
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
