[FFmpeg-devel] [RFC] Better modularization and extension of docs - 2

[Stefano Sabatini]

On date Sunday 2012-09-09 11:51:39 +0200, Clément Bœsch encoded:
> On Fri, Sep 07, 2012 at 01:55:24PM +0200, Stefano Sabatini wrote:
> > Hi,
> > 
> > relevant thread:
> > http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/108669
> > 
> > I find the monolithic FFmpeg pages more and more clumsy, e.g. when I
> > want to look for information related to a filter. In that case a:
> > man ffmpeg-filters
> > 
> > would be much better, and would avoid redundancy in the ff* tool
> > pages.
> > 
> 
> Yes, I agree with that.
> 
> > Possible sections would be:
> > 
> > tools: ffmpeg/ffplay/ffprobe/ffserver
> > protocols
> > muxers
> > demuxers
> > indevs
> > outdevs
> > decoders
> > encoders
> > bitstream-filters/bsfs
> > filters
> > 
> > It may made sense to merge muxers/demuxers => formats,
> > indevs/outdevs => devices, decoders/encoders => codecs.
> > 
> 
> No need to oversplit everything; so yes I think it makes more sense to
> merge muxers and demuxers (and protocols?) into formats, decoders and
> encoders into codecs, and indevs and outdevs into devices.

Hi,

I just sent libavcodec.texi, the big plan:

- add more pages: libavformat, libavdevice, libavfilter, libswscale,
  libswresample.
  The library pages should contain a possibly extensive description of the
  various options (which so far is only covered by ffmpeg -h full or
  the source code).

- remove library specific bits from the tool man pages, in order to
  have more wieldly pages

For example decoders.texi and encoders.texi should be merged into
libavcodec.texi.

The whole point of the reformatting is to get more modular
documentation (e.g. no need to grep all the ffmpeg huge man page to
find a filter), to provide a *place* where to document library
specific topics (e.g. encoding quality), and where to extend the
really sparse documentation for the various options.
-- 
FFmpeg = Fabulous Foolish Murdering Patchable Extensive Geisha