Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
 help / color / mirror / Atom feed
* [FFmpeg-devel] Embedded documentation?
@ 2023-05-01 10:13 Nicolas George
  2023-05-01 11:28 ` Diederick C. Niehorster
                   ` (3 more replies)
  0 siblings, 4 replies; 12+ messages in thread
From: Nicolas George @ 2023-05-01 10:13 UTC (permalink / raw)
  To: ffmpeg-devel


[-- Attachment #1.1.1: Type: text/plain, Size: 621 bytes --]

Hi.

Three years ago, I shared some brief thoughts about embedding the
documentation in the libraries. For example, that would allow GUI
applications to open help dialogs about specific options.

To see what it would need, I wrote the following header. I did not work
any further, because groundwork need to be laid first. But now that it
was mentioned in another thread, I think it is a good idea to show it,
to see how people like it.

Please share your remarks. Even “+1” to say you like it, because people
who will not like it will not hesitate to post “-1”.

Regards,

-- 
  Nicolas George

[-- Attachment #1.1.2: documentation.c --]
[-- Type: text/x-csrc, Size: 6849 bytes --]

typedef struct AVDocNode AVDocNode;
typedef struct AVDocLink AVDocLink;
typedef enum AVDocNodeType AVDocNodeType;
typedef enum AVDocLinkType AVDocLinkType;

/**
 * Link to another documentation node.
 */
struct AVDocLink {
    AVDocNode *target;
    AVDocLinkType type;
};

/**
 * Node in the documentation system.
 *
 * A node can be the description of a codec, format, filter, option, type,
 * etc.
 */
struct AVDocNode {

    /**
     * Names of the component.
     *
     * It is a concatenation of 0-terminated strings, terminated by an empty
     * string (i.e. a double 0).
     * For example "frame_rate, rate, r" would be "frame_rate\0rate\0r\0\0".
     * The first name is the main name of the component, the other are
     * aliases.
     * If this field is used as a plain C string, it contains only the main
     * name.
     */
    const char *names;

    /**
     * Unique identifier of the compnent.
     *
     * It is composed of alphanumeric characters plus underscore and slash
     * and written hierarchically.
     *
     * For example, the width option of the scale filter would be
     * "lavfi/vf_scale/opt_width".
     *
     * This identifier can be used for links in the text.
     *
     * It matches the symbol that makes the documentation available, in the
     * avdoc_ namespace with double underscore standing for slashes:
     * extern const AVDocNode avdoc_lavfi__vf_scale__opt_width;
     */
    const char *id;

    /**
     * Title / short description, possibly NULL.
     *
     * Can be used in a table of contents for example.
     */
    const char *title;

    /**
     * Text of the documentation in XXX Markdown / FFHTML.
     *
     * Apparently we want to write the documentation in Markdown or similar,
     * but the build system can convert when creating the data structure to
     * embed in the library.
     *
     * On one hand, Markdown can be dumped as is to the user, in a terminal
     * or a basic dialog box.
     *
     * On the other hand, strict minimalist HTML is more program-friendly,
     * which makes it more convenient for programs that want to display it
     * with actual italics 
     *
     * I think FFHTML (i.e. a small, strict and clearly documented subset of
     * HTML) would be better.
     */
    const char *text;

    /**
     * Object about which the documentation is.
     *
     * If not NULL, points to an object starting with an AVClass pointer.
     */
    void *object;

    /**
     * Links towards other nodes.
     *
     * All nodes linked in the text must have an entry here, but implicit
     * links are possible too, for example the type of an option.
     *
     * The types are ordered by type.
     */
    const AVDocLink *links;

    /**
     * Type of the node, and of the object documented.
     */
    AVDocNodeType type;

};

/**
 * Type of a documentation node.
 */
enum AVDocNodeType {
    AVDOC_TYPE_GENERIC = 0,
    AVDOC_TYPE_MUXER,
    AVDOC_TYPE_DEMUXER,
    AVDOC_TYPE_ENCODER,
    AVDOC_TYPE_DECODER,
    AVDOC_TYPE_FILTER,
    AVDOC_TYPE_BITSTREAM_FILTER,
    AVDOC_TYPE_SWSCALER,
    AVDOC_TYPE_SWRESAMPLER,
    AVDOC_TYPE_DEVICE_VIDEO_OUTPUT,
    AVDOC_TYPE_DEVICE_VIDEO_INPUT,
    AVDOC_TYPE_DEVICE_AUDIO_OUTPUT,
    AVDOC_TYPE_DEVICE_AUDIO_INPUT,
    AVDOC_TYPE_DEVICE_OUTPUT,
    AVDOC_TYPE_DEVICE_INPUT,
    AVDOC_TYPE_OPTION,
    AVDOC_TYPE_TYPE,
    AVDOC_TYPE_SYNTAX,
    AVDOC_TYPE_EXAMPLES,
    AVDOC_TYPE_EXPLANATIONS,
};

/**
 * Type of a link, i.e. relation between the source and the target of the
 * link.
 *
 * More important links have a lower value.
 */
enum AVDocLinkType {

    /**
     * The linked node is the parent.
     *
     * For example, the parent the node for a private option is the node for
     * the corresponding codec/format/filter.
     */
    AVDOC_LINK_PARENT = 0x100,

    /**
     * The linked node is a subpart, section, chapter, etc.
     */
    AVDOC_LINK_SUBPART = 0x200,

    /**
     * The linked node describes an option or an option constant.
     */
    AVDOC_LINK_OPTION = 0x300,

    /**
     * Threshold value for the self-contained minimal documentation of an
     * object.
     */
    AVDOC_LINK_SELF_CONTAINED = 0x400,

    /**
     * The linked node is the reference for a type, syntax, etc.
     */
    AVDOC_LINK_REFERENCE = 0x500,

    /**
     * Threshold value for the self-contained complete documentation of an
     * object, including refernce for types and syntaxes.
     */
    AVDOC_LINK_SELF_CONTAINED_FULL = 0x600,

    /**
     * The linked node contains details and explanations.
     */
    AVDOC_LINK_DETAILS = 0x700,

};

typedef struct AVDocExcerpt AVDocExcerpt;
typedef struct AVDocTocNode AVDocTocNode;

/**
 * Excerpt of the documentation, structured and with links.
 *
 * Always returned by the library.
 *
 * This structure is the root of a tree of AVDocTocNode;
 * siblings in the tree are structured as a linked list.
 */
struct AVDocExcerpt {

    /**
     * First node of the excerpt
     */
    AVDocTocNode *begin;

};

/**
 * Node in an excerpt of the documentation.
 *
 * This contains the node and its relation with other nodes.
 */
struct AVDocTocNode {

    AVDocNode *node;

    AVDocTocNode *next;

    AVDocTocNode *first_child;

};

/**
 * Get the documentation node associated with an object, if any.
 *
 * obj must point to an object starting with an AVClass pointer.
 */
const AVDocNode *av_documentation_get_node(void *obj);

/**
 * Get an excerpt of the documentation around a node.
 *
 * @param excerpt    used to return the excerpt
 * @param nodes      nodes to document;
 *                   if one is NULL, it is skipped;
 *                   if all are NULL, a dummy documentation is returned
 * @param nb_nodes   number of nodes
 * @param threshold  limit of the excerpt, it will contain all nodes pointed
 *                   by links that are below the threshold, recursively;
 *                   AVDOC_LINK_SELF_CONTAINED and
 *                   AVDOC_LINK_SELF_CONTAINED_FULL are useful values.
 * @return  >= 0 for success or an AVERROR code, possibly AVERROR(ENOMEM)
 */
int av_documentation_get_excerpt(AVDocExcerpt **excerpt,
                                 const AVDocNode **node, unsigned nb_nodes,
                                 AVDocLinkType threshold);

typedef enum AVDocFormat {
    AV_DOC_FORMAT_HTML,
    AV_DOC_FORMAT_MARKDOWN,
};

#define AV_DOC_FORMAT_FLAG_TOC 0x0001

/**
 * Serialize a documentation excerpt.
 */
void av_documentation_write(AVWriter wr, AVDocExcerpt **excerpt,
                            AVDocFormat format, unsigned flags);

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [FFmpeg-devel] Embedded documentation?
  2023-05-01 10:13 [FFmpeg-devel] Embedded documentation? Nicolas George
@ 2023-05-01 11:28 ` Diederick C. Niehorster
  2023-05-03 17:52   ` Nicolas George
  2023-05-01 13:15 ` Timo Rothenpieler
                   ` (2 subsequent siblings)
  3 siblings, 1 reply; 12+ messages in thread
From: Diederick C. Niehorster @ 2023-05-01 11:28 UTC (permalink / raw)
  To: FFmpeg development discussions and patches

On Mon, May 1, 2023 at 12:13 PM Nicolas George <george@nsup.org> wrote:

> Hi.
>
> Three years ago, I shared some brief thoughts about embedding the
> documentation in the libraries. For example, that would allow GUI
> applications to open help dialogs about specific options.
>
> To see what it would need, I wrote the following header. I did not work
> any further, because groundwork need to be laid first. But now that it
> was mentioned in another thread, I think it is a good idea to show it,
> to see how people like it.
>

+1. I assume a lot of the AVDocNode can be automatically populated from its
corresponding option? We'd not want to maintain, e.g. option names and
aliases in more than one place.

Cheers,
Dee
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [FFmpeg-devel] Embedded documentation?
  2023-05-01 10:13 [FFmpeg-devel] Embedded documentation? Nicolas George
  2023-05-01 11:28 ` Diederick C. Niehorster
@ 2023-05-01 13:15 ` Timo Rothenpieler
  2023-05-03 18:01   ` Nicolas George
  2023-05-03 19:31 ` Thilo Borgmann
  2023-05-07 22:10 ` Stefano Sabatini
  3 siblings, 1 reply; 12+ messages in thread
From: Timo Rothenpieler @ 2023-05-01 13:15 UTC (permalink / raw)
  To: ffmpeg-devel

On 01.05.2023 12:13, Nicolas George wrote:
> Hi.
> 
> Three years ago, I shared some brief thoughts about embedding the
> documentation in the libraries. For example, that would allow GUI
> applications to open help dialogs about specific options.
> 
> To see what it would need, I wrote the following header. I did not work
> any further, because groundwork need to be laid first. But now that it
> was mentioned in another thread, I think it is a good idea to show it,
> to see how people like it.
> 
> Please share your remarks. Even “+1” to say you like it, because people
> who will not like it will not hesitate to post “-1”.
> 
> Regards,

Somewhat loosely related to this:

A frequent issue is that it's entirely non-obvious which global 
libavcodec options a codec might make use of.
Having a way to self-document that would be amazing, so those options 
show up in the --help output, ideally with their codec-specific default.

The obvious idea I had for this was to utilize the FFCodecDefault struct 
which already exists, maybe expanding it a tiny bit to allow the second 
value to be NULL, indicating "This codec uses that option, but does not 
change the default".

Main issue with this is that FFCodecDefault is a private struct.
It could just be made public and user-queryable, while making every 
current user of it aware of possible NULL-values, which they can then 
just ignore.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [FFmpeg-devel] Embedded documentation?
  2023-05-01 11:28 ` Diederick C. Niehorster
@ 2023-05-03 17:52   ` Nicolas George
  0 siblings, 0 replies; 12+ messages in thread
From: Nicolas George @ 2023-05-03 17:52 UTC (permalink / raw)
  To: FFmpeg development discussions and patches


[-- Attachment #1.1: Type: text/plain, Size: 894 bytes --]

Diederick C. Niehorster (12023-05-01):
> +1.

Thanks.

>     I assume a lot of the AVDocNode can be automatically populated from its
> corresponding option? We'd not want to maintain, e.g. option names and
> aliases in more than one place.

I cannot promise there will be no duplication at all, and AVOption is
very limited and needs to be replaced anyway.

But I can promise it will not have to be written as a C structure with
all its fields initialized.

I have not discussed it nor finalized any of the details, but I am
thinking the build system will parse either doxy-style comments in the C
source code or in a separate .md file with the same name to generate the
structures for the built-in documentation. If the system parses comments
in the C source, it can also parse the AVOption initializers, at least
in the simple cases.

Regards,

-- 
  Nicolas George

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [FFmpeg-devel] Embedded documentation?
  2023-05-01 13:15 ` Timo Rothenpieler
@ 2023-05-03 18:01   ` Nicolas George
  0 siblings, 0 replies; 12+ messages in thread
From: Nicolas George @ 2023-05-03 18:01 UTC (permalink / raw)
  To: FFmpeg development discussions and patches


[-- Attachment #1.1: Type: text/plain, Size: 1469 bytes --]

Timo Rothenpieler (12023-05-01):
> Somewhat loosely related to this:
> 
> A frequent issue is that it's entirely non-obvious which global libavcodec
> options a codec might make use of.
> Having a way to self-document that would be amazing, so those options show
> up in the --help output, ideally with their codec-specific default.

Interesting remark. I also thought in the past that knowing if a certain
component uses or ignore a particular common option would be useful, but
I had not pushed the reflexion to that point.

> The obvious idea I had for this was to utilize the FFCodecDefault struct
> which already exists, maybe expanding it a tiny bit to allow the second
> value to be NULL, indicating "This codec uses that option, but does not
> change the default".
> 
> Main issue with this is that FFCodecDefault is a private struct.
> It could just be made public and user-queryable, while making every current
> user of it aware of possible NULL-values, which they can then just ignore.

I can imagine a few other solutions.

Note that the way we store the information in the library does not have
to be the same as the way we give that information to the user. For
example, internally we could store an array of used or unused options
and to the user we can include only the used options in AVDocExcerpt.

The most annoying task for this will be to look at the code component by
component.

Regards,

-- 
  Nicolas George

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [FFmpeg-devel] Embedded documentation?
  2023-05-01 10:13 [FFmpeg-devel] Embedded documentation? Nicolas George
  2023-05-01 11:28 ` Diederick C. Niehorster
  2023-05-01 13:15 ` Timo Rothenpieler
@ 2023-05-03 19:31 ` Thilo Borgmann
  2023-05-07 22:10 ` Stefano Sabatini
  3 siblings, 0 replies; 12+ messages in thread
From: Thilo Borgmann @ 2023-05-03 19:31 UTC (permalink / raw)
  To: ffmpeg-devel

Hi,

> Three years ago, I shared some brief thoughts about embedding the
> documentation in the libraries. For example, that would allow GUI
> applications to open help dialogs about specific options.
> 
> To see what it would need, I wrote the following header. I did not work
> any further, because groundwork need to be laid first. But now that it
> was mentioned in another thread, I think it is a good idea to show it,
> to see how people like it.
> 
> Please share your remarks. Even “+1” to say you like it, because people
> who will not like it will not hesitate to post “-1”.

+1.

I certainly like the idea. Not thinking ahead about any details except that for custom very small builds, one should be able to disable this feature.

-Thilo
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [FFmpeg-devel] Embedded documentation?
  2023-05-01 10:13 [FFmpeg-devel] Embedded documentation? Nicolas George
                   ` (2 preceding siblings ...)
  2023-05-03 19:31 ` Thilo Borgmann
@ 2023-05-07 22:10 ` Stefano Sabatini
  2023-05-08 15:03   ` Nicolas George
                     ` (2 more replies)
  3 siblings, 3 replies; 12+ messages in thread
From: Stefano Sabatini @ 2023-05-07 22:10 UTC (permalink / raw)
  To: FFmpeg development discussions and patches

On date Monday 2023-05-01 12:13:09 +0200, Nicolas George wrote:
> Hi.
> 
> Three years ago, I shared some brief thoughts about embedding the
> documentation in the libraries. For example, that would allow GUI
> applications to open help dialogs about specific options.
> 
> To see what it would need, I wrote the following header. I did not work
> any further, because groundwork need to be laid first. But now that it
> was mentioned in another thread, I think it is a good idea to show it,
> to see how people like it.
> 
> Please share your remarks. Even “+1” to say you like it, because people
> who will not like it will not hesitate to post “-1”.
> 
> Regards,
> 
> -- 
>   Nicolas George

> typedef struct AVDocNode AVDocNode;
> typedef struct AVDocLink AVDocLink;
> typedef enum AVDocNodeType AVDocNodeType;
> typedef enum AVDocLinkType AVDocLinkType;
> 
> /**
>  * Link to another documentation node.
>  */
> struct AVDocLink {
>     AVDocNode *target;
>     AVDocLinkType type;
> };
> 
> /**
>  * Node in the documentation system.
>  *
>  * A node can be the description of a codec, format, filter, option, type,
>  * etc.
>  */
> struct AVDocNode {
> 
>     /**
>      * Names of the component.
>      *
>      * It is a concatenation of 0-terminated strings, terminated by an empty
>      * string (i.e. a double 0).

>      * For example "frame_rate, rate, r" would be "frame_rate\0rate\0r\0\0".
>      * The first name is the main name of the component, the other are
>      * aliases.

I'd prefer to use something easily parsable and still more
human-readable, such as "frame_rate,rate,r"

>      * If this field is used as a plain C string, it contains only the main
>      * name.
>      */
>     const char *names;
> 
>     /**
>      * Unique identifier of the compnent.
>      *
>      * It is composed of alphanumeric characters plus underscore and slash
>      * and written hierarchically.
>      *

>      * For example, the width option of the scale filter would be
>      * "lavfi/vf_scale/opt_width".

maybe something as:
lavfi/scale/option:width

the name of a filter is unique, and we don't want to expose the
internals of the library (vf_, af_ etc. - also they don't make much
sense for multi/trans-media filters)

>      *
>      * This identifier can be used for links in the text.
>      *
>      * It matches the symbol that makes the documentation available, in the
>      * avdoc_ namespace with double underscore standing for slashes:
>      * extern const AVDocNode avdoc_lavfi__vf_scale__opt_width;
>      */
>     const char *id;
> 
>     /**
>      * Title / short description, possibly NULL.
>      *
>      * Can be used in a table of contents for example.
>      */
>     const char *title;
> 

>     /**
>      * Text of the documentation in XXX Markdown / FFHTML.
>      *
>      * Apparently we want to write the documentation in Markdown or similar,
>      * but the build system can convert when creating the data structure to
>      * embed in the library.
>      *
>      * On one hand, Markdown can be dumped as is to the user, in a terminal
>      * or a basic dialog box.
>      *
>      * On the other hand, strict minimalist HTML is more program-friendly,
>      * which makes it more convenient for programs that want to display it
>      * with actual italics 
>      *
>      * I think FFHTML (i.e. a small, strict and clearly documented subset of
>      * HTML) would be better.
>      */
>     const char *text;

I think the problem with HTML is that then you need to parse it if you
want to display it, so I'd tend to rather go with markdown:
1. it provides readable raw output
2. there are plenty of libraries which can render it to various
formats (including HTML)

> 
>     /**
>      * Object about which the documentation is.
>      *
>      * If not NULL, points to an object starting with an AVClass pointer.
>      */
>     void *object;
> 
>     /**
>      * Links towards other nodes.
>      *
>      * All nodes linked in the text must have an entry here, but implicit
>      * links are possible too, for example the type of an option.
>      *
>      * The types are ordered by type.
>      */
>     const AVDocLink *links;
> 

>     /**
>      * Type of the node, and of the object documented.
>      */
>     AVDocNodeType type;

We already define AV_CLASS_CATEGORY (libavutil/log.h), could it be
adjusted for this scope?

> };
> 
> /**
>  * Type of a documentation node.
>  */
> enum AVDocNodeType {
>     AVDOC_TYPE_GENERIC = 0,
>     AVDOC_TYPE_MUXER,
>     AVDOC_TYPE_DEMUXER,
>     AVDOC_TYPE_ENCODER,
>     AVDOC_TYPE_DECODER,
>     AVDOC_TYPE_FILTER,
>     AVDOC_TYPE_BITSTREAM_FILTER,
>     AVDOC_TYPE_SWSCALER,
>     AVDOC_TYPE_SWRESAMPLER,
>     AVDOC_TYPE_DEVICE_VIDEO_OUTPUT,
>     AVDOC_TYPE_DEVICE_VIDEO_INPUT,
>     AVDOC_TYPE_DEVICE_AUDIO_OUTPUT,
>     AVDOC_TYPE_DEVICE_AUDIO_INPUT,
>     AVDOC_TYPE_DEVICE_OUTPUT,
>     AVDOC_TYPE_DEVICE_INPUT,
>     AVDOC_TYPE_OPTION,
>     AVDOC_TYPE_TYPE,
>     AVDOC_TYPE_SYNTAX,
>     AVDOC_TYPE_EXAMPLES,
>     AVDOC_TYPE_EXPLANATIONS,
> };
> 
> /**
>  * Type of a link, i.e. relation between the source and the target of the
>  * link.
>  *
>  * More important links have a lower value.
>  */
> enum AVDocLinkType {
> 
>     /**
>      * The linked node is the parent.
>      *
>      * For example, the parent the node for a private option is the node for
>      * the corresponding codec/format/filter.
>      */
>     AVDOC_LINK_PARENT = 0x100,
> 
>     /**
>      * The linked node is a subpart, section, chapter, etc.
>      */
>     AVDOC_LINK_SUBPART = 0x200,
> 

>     /**
>      * The linked node describes an option or an option constant.
>      */
>     AVDOC_LINK_OPTION = 0x300,

>     /**
>      * Threshold value for the self-contained minimal documentation of an
>      * object.
>      */

I cannot parse this, where is the threshold value defined?

>     AVDOC_LINK_SELF_CONTAINED = 0x400,
> 
>     /**
>      * The linked node is the reference for a type, syntax, etc.
>      */
>     AVDOC_LINK_REFERENCE = 0x500,
> 
>     /**
>      * Threshold value for the self-contained complete documentation of an
>      * object, including refernce for types and syntaxes.
>      */
>     AVDOC_LINK_SELF_CONTAINED_FULL = 0x600,
> 

>     /**
>      * The linked node contains details and explanations.
>      */
>     AVDOC_LINK_DETAILS = 0x700,

Maybe an example would clarify this, since there is ambiguity about
what default and explanations are.

> };
> 
> typedef struct AVDocExcerpt AVDocExcerpt;
> typedef struct AVDocTocNode AVDocTocNode;
> 

> /**
>  * Excerpt of the documentation, structured and with links.
>  *
>  * Always returned by the library.
>  *
>  * This structure is the root of a tree of AVDocTocNode;
>  * siblings in the tree are structured as a linked list.
>  */
> struct AVDocExcerpt {
> 
>     /**
>      * First node of the excerpt
>      */
>     AVDocTocNode *begin;
> 
> };

isn't this redundant? can't you just use AVDocTocNode?

> /**
>  * Node in an excerpt of the documentation.
>  *
>  * This contains the node and its relation with other nodes.
>  */
> struct AVDocTocNode {

I dislike this name, as it is not descriptive at all (I assume Toc
stands for Table Of Contents). Maybe AVDocNodeContext?

> 
>     AVDocNode *node;
> 
>     AVDocTocNode *next;
> 
>     AVDocTocNode *first_child;
> 
> };

> /**
>  * Get the documentation node associated with an object, if any.
>  *
>  * obj must point to an object starting with an AVClass pointer.
>  */
> const AVDocNode *av_documentation_get_node(void *obj);
> 
> /**
>  * Get an excerpt of the documentation around a node.
>  *
>  * @param excerpt    used to return the excerpt
>  * @param nodes      nodes to document;
>  *                   if one is NULL, it is skipped;
>  *                   if all are NULL, a dummy documentation is returned
>  * @param nb_nodes   number of nodes
>  * @param threshold  limit of the excerpt, it will contain all nodes pointed
>  *                   by links that are below the threshold, recursively;
>  *                   AVDOC_LINK_SELF_CONTAINED and
>  *                   AVDOC_LINK_SELF_CONTAINED_FULL are useful values.
>  * @return  >= 0 for success or an AVERROR code, possibly AVERROR(ENOMEM)
>  */
> int av_documentation_get_excerpt(AVDocExcerpt **excerpt,
>                                  const AVDocNode **node, unsigned nb_nodes,
>                                  AVDocLinkType threshold);
> 
> typedef enum AVDocFormat {
>     AV_DOC_FORMAT_HTML,
>     AV_DOC_FORMAT_MARKDOWN,
> };
> 
> #define AV_DOC_FORMAT_FLAG_TOC 0x0001
> 
> /**
>  * Serialize a documentation excerpt.
>  */
> void av_documentation_write(AVWriter wr, AVDocExcerpt **excerpt,
>                             AVDocFormat format, unsigned flags);

Can you share more details about the plan? In particular, is the doc
going to be embedded in the code itself (e.g. in the C
implementation)? Or should we have some dedicated headers containing
the docs?

We should also avoid to duplicate the same information between docs
and code, so there should be some way to autogenerate the docs from
the corresponding entries in the code.


> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [FFmpeg-devel] Embedded documentation?
  2023-05-07 22:10 ` Stefano Sabatini
@ 2023-05-08 15:03   ` Nicolas George
  2023-05-08 15:42   ` Nicolas George
  2023-05-08 19:05   ` Nicolas George
  2 siblings, 0 replies; 12+ messages in thread
From: Nicolas George @ 2023-05-08 15:03 UTC (permalink / raw)
  To: FFmpeg development discussions and patches


[-- Attachment #1.1: Type: text/plain, Size: 1873 bytes --]

Stefano Sabatini (12023-05-08):
> I think the problem with HTML is that then you need to parse it if you
> want to display it, so I'd tend to rather go with markdown:
> 1. it provides readable raw output
> 2. there are plenty of libraries which can render it to various
> formats (including HTML)

I will reply to this separately.

A lot of your comments are a little premature: I am not ready to start
working on this just now. For starters, it is out of question without
AVWriter being committed, and I am still waiting for somebody who is not
a-priori hostile and who understand strings to look at the code.

But this issue can be discussed now.

I think using Markdown internally would be a huge mistake.

You say “it provides readable raw format”: you seem to be assuming
ffmpeg/ffplay/ffprobe will dump the documentation to the terminal as is
and be done with it, and all other kinds of applications will have to
manage the rest themselves.

Well, this is not the kind of API I want to design. I want an API where
we provide to the applications all its needs to prepare the
documentation for the user, with the data in the most convenient format.

And for that, the internal format needs to be convenient to manage with
a program. A C program specifically.

Markdown is designed to be easy to type and easy to look at by humans.
But that makes it terrible to manage with a program. For starters, its
syntax is highly ambiguous, already with “*” and “**”.

HTML is a much better choice. Note: I am not suggesting the full complex
beast of HTML found on the world-wide-web, with CSS and javascript and
bad syntax and all the crap. I am suggesting a very well-defined subset
of clean HTML. That is much easier to parse than Markdown, with only <
and & acting as special characters.

Regards,

-- 
  Nicolas George

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [FFmpeg-devel] Embedded documentation?
  2023-05-07 22:10 ` Stefano Sabatini
  2023-05-08 15:03   ` Nicolas George
@ 2023-05-08 15:42   ` Nicolas George
  2023-05-08 15:48     ` Zhanbang He
  2023-05-08 19:05   ` Nicolas George
  2 siblings, 1 reply; 12+ messages in thread
From: Nicolas George @ 2023-05-08 15:42 UTC (permalink / raw)
  To: FFmpeg development discussions and patches


[-- Attachment #1.1: Type: text/plain, Size: 2273 bytes --]

Stefano Sabatini (12023-05-08):
> I cannot parse this, where is the threshold value defined?

The threshold is the enum constant that was being described.

> Maybe an example would clarify this, since there is ambiguity about
> what default and explanations are.

Let us think how this is meant to be used. For example, the user of a
GUI clicks on a filter, the application asks the library “give me the
documentation for this” and displays it somewhere.

Imagine the whole FFmpeg documentation as a gigantic hypertext document,
like <https://ffmpeg.org/ffmpeg-all.html>. Imagine we want the
documentation for the scale filter. So we start at
<https://ffmpeg.org/ffmpeg-all.html#scale-1>, and we take:

- the introduction of the scale filter,
- the width option,
- the height option,
- the flags option,
- the size option,
- etc.,
- the examples,
- the commands,

But the width and height options are expressions, therefore we will need
also <https://ffmpeg.org/ffmpeg-all.html#Expression-Evaluation>.
And the size option is a video size, so we take
<https://ffmpeg.org/ffmpeg-all.html#Video-size> too.
And the flags option requires
<https://ffmpeg.org/ffmpeg-all.html#Scaler-Options>.
And maybe the various scaler flags link to explanations about their pros
and cons, and we want these explanations too.

In general, to get the documentation for a component, avdoc starts at
the doc node of this component, and it follows all the links from there,
and then all the links from the nodes reached, etc., recursively, until
avdoc has all the documentation that might be useful to understand that
component. Then it returns to the application.

But that means we will get 50 pages of documentation for most
components. It is fine to display in a full-fledged help browser, but a
50 pages tooltip is not very convenient.

This is where the thresholds come into play:

- if you want a tooltip, av_documentation_get_excerpt(obj, 0);

- if you want a help dialog where scrolling is possible,
  av_documentation_get_excerpt(obj, AVDOC_LINK_SELF_CONTAINED);

- if you want a help browser where hyperlinks are possible,
  av_documentation_get_excerpt(obj, AVDOC_LINK_SELF_CONTAINED_FULL).

Regards,

-- 
  Nicolas George

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [FFmpeg-devel] Embedded documentation?
  2023-05-08 15:42   ` Nicolas George
@ 2023-05-08 15:48     ` Zhanbang He
  2023-05-08 16:42       ` Nicolas George
  0 siblings, 1 reply; 12+ messages in thread
From: Zhanbang He @ 2023-05-08 15:48 UTC (permalink / raw)
  To: FFmpeg development discussions and patches

Can it supports chatGPT?

On Monday, May 8, 2023, Nicolas George <george@nsup.org> wrote:

> Stefano Sabatini (12023-05-08):
> > I cannot parse this, where is the threshold value defined?
>
> The threshold is the enum constant that was being described.
>
> > Maybe an example would clarify this, since there is ambiguity about
> > what default and explanations are.
>
> Let us think how this is meant to be used. For example, the user of a
> GUI clicks on a filter, the application asks the library “give me the
> documentation for this” and displays it somewhere.
>
> Imagine the whole FFmpeg documentation as a gigantic hypertext document,
> like <https://ffmpeg.org/ffmpeg-all.html>. Imagine we want the
> documentation for the scale filter. So we start at
> <https://ffmpeg.org/ffmpeg-all.html#scale-1>, and we take:
>
> - the introduction of the scale filter,
> - the width option,
> - the height option,
> - the flags option,
> - the size option,
> - etc.,
> - the examples,
> - the commands,
>
> But the width and height options are expressions, therefore we will need
> also <https://ffmpeg.org/ffmpeg-all.html#Expression-Evaluation>.
> And the size option is a video size, so we take
> <https://ffmpeg.org/ffmpeg-all.html#Video-size> too.
> And the flags option requires
> <https://ffmpeg.org/ffmpeg-all.html#Scaler-Options>.
> And maybe the various scaler flags link to explanations about their pros
> and cons, and we want these explanations too.
>
> In general, to get the documentation for a component, avdoc starts at
> the doc node of this component, and it follows all the links from there,
> and then all the links from the nodes reached, etc., recursively, until
> avdoc has all the documentation that might be useful to understand that
> component. Then it returns to the application.
>
> But that means we will get 50 pages of documentation for most
> components. It is fine to display in a full-fledged help browser, but a
> 50 pages tooltip is not very convenient.
>
> This is where the thresholds come into play:
>
> - if you want a tooltip, av_documentation_get_excerpt(obj, 0);
>
> - if you want a help dialog where scrolling is possible,
>   av_documentation_get_excerpt(obj, AVDOC_LINK_SELF_CONTAINED);
>
> - if you want a help browser where hyperlinks are possible,
>   av_documentation_get_excerpt(obj, AVDOC_LINK_SELF_CONTAINED_FULL).
>
> Regards,
>
> --
>   Nicolas George
>
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [FFmpeg-devel] Embedded documentation?
  2023-05-08 15:48     ` Zhanbang He
@ 2023-05-08 16:42       ` Nicolas George
  0 siblings, 0 replies; 12+ messages in thread
From: Nicolas George @ 2023-05-08 16:42 UTC (permalink / raw)
  To: FFmpeg development discussions and patches


[-- Attachment #1.1: Type: text/plain, Size: 159 bytes --]

Zhanbang He (12023-05-08):
> Can it supports chatGPT?

Of course not. Only ChatGnuTP, for obvious reasons of freedom.

Regards,

-- 
  Nicolas George

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [FFmpeg-devel] Embedded documentation?
  2023-05-07 22:10 ` Stefano Sabatini
  2023-05-08 15:03   ` Nicolas George
  2023-05-08 15:42   ` Nicolas George
@ 2023-05-08 19:05   ` Nicolas George
  2 siblings, 0 replies; 12+ messages in thread
From: Nicolas George @ 2023-05-08 19:05 UTC (permalink / raw)
  To: FFmpeg development discussions and patches


[-- Attachment #1.1: Type: text/plain, Size: 1183 bytes --]

Stefano Sabatini (12023-05-08):
> Can you share more details about the plan? In particular, is the doc
> going to be embedded in the code itself (e.g. in the C
> implementation)? Or should we have some dedicated headers containing
> the docs?
> 
> We should also avoid to duplicate the same information between docs
> and code, so there should be some way to autogenerate the docs from
> the corresponding entries in the code.

This is far from settled, but I imagine something like that:

- Short doc paragraphs go directly in the C source code as comments with
  a specific markup, like doxygen but distinct from it.

- Longer doc texts go in a file with the same name as the C source code
  but a different extension, probably .md.

- The build system parses all this to generate source files with the
  structured documentation to be compiled into the library.

- The build system can also parse parts of the C source code to extract
  the structure information, for example AVOption initializers.

- The build system also parses the current texinfo documentation so that
  we do not have to rewrite it all at once.

Regards,

-- 
  Nicolas George

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2023-05-08 19:05 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-05-01 10:13 [FFmpeg-devel] Embedded documentation? Nicolas George
2023-05-01 11:28 ` Diederick C. Niehorster
2023-05-03 17:52   ` Nicolas George
2023-05-01 13:15 ` Timo Rothenpieler
2023-05-03 18:01   ` Nicolas George
2023-05-03 19:31 ` Thilo Borgmann
2023-05-07 22:10 ` Stefano Sabatini
2023-05-08 15:03   ` Nicolas George
2023-05-08 15:42   ` Nicolas George
2023-05-08 15:48     ` Zhanbang He
2023-05-08 16:42       ` Nicolas George
2023-05-08 19:05   ` Nicolas George

Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \
		ffmpegdev@gitmailbox.com
	public-inbox-index ffmpegdev

Example config snippet for mirrors.


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git