On Sun, Aug 23, 2020 at 05:15:18PM +0200, Nicolas George wrote:
> Michael Niedermayer (12020-08-22):
> > iam not sure what extension you (plural) envission here but AVOption.help
> > can be extended without breaking API/ABI.
> > Consider if for example one wanted to add a filename, markdown or othe
Alexander Strasser (12020-08-22):
> Wow the discussion gets up to speed quickly :)
Yes, it's nice for once.
> I think we should eradicate the copy in the source files and
> keep the description in the corresponding .md file. We shall
> build a tool that creates supplementary C files from the .md
Michael Niedermayer (12020-08-22):
> iam not sure what extension you (plural) envission here but AVOption.help
> can be extended without breaking API/ABI.
> Consider if for example one wanted to add a filename, markdown or other
> text string. AVOption.help is a zero terminated string. you can add
Hi Jim!
On 2020-08-22 14:09 -0700, Jim DeLaHunt wrote:
> On Fri Aug 21 15:35:38 EEST 2020, Nicolas George wrote:
> > 1. What would you think about putting the documentation for
> > libavfilter/vf_foobar.c into libavfilter/doc/vf_foobar.texi …
> > 2. What would you think about switching from
On Fri Aug 21 15:35:38 EEST 2020, Nicolas George wrote:
> 1. What would you think about putting the documentation for
> libavfilter/vf_foobar.c into libavfilter/doc/vf_foobar.texi …
> 2. What would you think about switching from texinfo to a small basic
> subset of HTML for new documenta
On Sat, Aug 22, 2020 at 02:12:13PM +0200, Nicolas George wrote:
> Clement Boesch (12020-08-22):
> > AVOption.help and AVFilter.description (as well as AVCodec.description
> > etc) do contain redundant information with the documentation.
>
> There is truth in what you say, but I disagree this is re
Hi Nicolas,
hi Clement!
Wow the discussion gets up to speed quickly :)
Thanks for bringing up all those good points!
I'm intentionally top-posting, because I want to say something
concerning the points you discuss below. Though I couldn't find
a good way to do it in a comment style, so instead I'
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Nicolas George
> Sent: Saturday, August 22, 2020 2:12 PM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] Documentation: proposed changes in the
> struc
Clement Boesch (12020-08-22):
> AVOption.help and AVFilter.description (as well as AVCodec.description
> etc) do contain redundant information with the documentation.
There is truth in what you say, but I disagree this is really redundant:
AVOption.help and AV*.description are supposed to be very
On Sat, Aug 22, 2020 at 01:15:14AM +0200, Clément Bœsch wrote:
[...]
> But I think we have it wrong with the documentation approach. What is
> currently described within the code corresponds to the "technical
> documentation". While all the extra information on the filters may enter
> within the "e
On Fri, Aug 21, 2020 at 11:40:20PM +0200, Nicolas George wrote:
> Clement Boesch (12020-08-21):
> > The split is probably not a bad idea, but can we discuss having the
> > documentation within the C code to prevent duplication/redundancy?
> >
> > We could write a tool to generate the documentation
Clement Boesch (12020-08-21):
> The split is probably not a bad idea, but can we discuss having the
> documentation within the C code to prevent duplication/redundancy?
>
> We could write a tool to generate the documentation file, or maybe part of
> it for a start (the options). Having to document
On Fri, Aug 21, 2020 at 02:35:38PM +0200, Nicolas George wrote:
> 1. What would you think about putting the documentation for
>libavfilter/vf_foobar.c into libavfilter/doc/vf_foobar.texi instead
>of into huge doc/filters.texi (25k lines!)? And same for codecs,
>formats, etc.
>
>We
On Fri, Aug 21, 2020 at 09:42:57PM +0200, Oneric wrote:
> On Fri, Aug 21, 2020 at 14:46:53 +0200, Timo Rothenpieler wrote:
> > Something like Markdown would come to mind. It should have all formatting
> > tools one needs for documentation.
>
> Imho ReStructuredText would be better suited for docum
On Fri, Aug 21, 2020 at 14:46:53 +0200, Timo Rothenpieler wrote:
> Something like Markdown would come to mind. It should have all formatting
> tools one needs for documentation.
Imho ReStructuredText would be better suited for documentation than Markdown,
while being similarly "text-like".
Unlike
Timo Rothenpieler (12020-08-21):
> That seems long overdue to me.
> The current approach to documentation has become very hard to properly
> maintain.
This seems to get some approval.
I think it would probably not be very hard to convert existing
components in bulk.
I'll see if I can wrangle som
On 2020-08-21 14:35 +0200, Nicolas George wrote:
> 1. What would you think about putting the documentation for
>libavfilter/vf_foobar.c into libavfilter/doc/vf_foobar.texi instead
>of into huge doc/filters.texi (25k lines!)? And same for codecs,
>formats, etc.
>
>We can adopt this f
On 2020-08-21 15:02 +0200, Jean-Baptiste Kempf wrote:
>
>
> On Fri, 21 Aug 2020, at 14:35, Nicolas George wrote:
> > 2. What would you think about switching from texinfo to a small basic
> >subset of HTML for new documentation?
> >
> >I think most of us are much more familiar with HTML synt
On 21-08-2020 06:05 pm, Nicolas George wrote:
1. What would you think about putting the documentation for
libavfilter/vf_foobar.c into libavfilter/doc/vf_foobar.texi instead
of into huge doc/filters.texi (25k lines!)? And same for codecs,
formats, etc.
We can adopt this for new
On Fri, 21 Aug 2020, at 14:35, Nicolas George wrote:
> 2. What would you think about switching from texinfo to a small basic
>subset of HTML for new documentation?
>
>I think most of us are much more familiar with HTML syntax than with
>texinfo.
Use Markdown.
It's defined, spec'd an
On 21.08.2020 14:35, Nicolas George wrote:
1. What would you think about putting the documentation for
libavfilter/vf_foobar.c into libavfilter/doc/vf_foobar.texi instead
of into huge doc/filters.texi (25k lines!)? And same for codecs,
formats, etc.
We can adopt this for new docu
1. What would you think about putting the documentation for
libavfilter/vf_foobar.c into libavfilter/doc/vf_foobar.texi instead
of into huge doc/filters.texi (25k lines!)? And same for codecs,
formats, etc.
We can adopt this for new documentation and move progressively
existing comp
22 matches
Mail list logo
