Quoting James Almer (2024-01-26 17:22:06) > On 1/26/2024 1:17 PM, Anton Khirnov wrote: > > Quoting James Almer (2024-01-26 17:09:32) > >> On 1/26/2024 9:17 AM, Anton Khirnov wrote: > >>> Quoting Lynne (2024-01-26 13:11:33) > >>>> Jan 26, 2024, 11:40 by an...@khirnov.net: > >>>> > >>>>> --- > >>>>> libavcodec/Makefile | 49 +--------------- > >>>>> libavcodec/bsf/Makefile | 56 > >>>>> +++++++++++++++++++ > >>>>> > >>>> > >>>> Is that the general direction we want to take? > >>>> I don't mind it, but I'm wondering if I should do this for what I care > >>>> about? > >>> > >>> I'd say yes for things with >~ 10 files. libavcodec/ got way too large. > >> > >> Is your idea something like.. > >> > >> libavcodec/bsf > >> libavcodec/common > >> libavcodec/decoder > >> libavcodec/encoder > >> libavcodec/parser > >> > >> And then subfolders within those for big modules like h264, hevc, vvc, > >> mpeg2, vp9, etc? > > > > No, that strikes me as overkill. A subdir for bsfs, a subdir for every > > codec/group of codecs/subsystem. > > I don't think it's overkill. It separates modules per type, so it's easy > to find a parser that right now is mixed between all the decoder related > files.
My plan is for parsers to turn into bitstream filters, so... > >> And like Andreas mentioned, the arch subfolders need to be considered > >> for this. > > > > Why? > > I mean, where do you want them? inside the decoder/encoder subfolders > (thus splitting them), or outside as they are right now? I am perfectly fine with leaving them as they are now. Too many directory levels make things hard to find as well. -- Anton Khirnov _______________________________________________ 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".