On Fri, Dec 04, 2015 at 03:33:39PM +0100, Nicolas George wrote:
[...]
> Extra features
>
> This system allows a few new interesting features. Some of them just
> thanks to no longer worrying about sizeof(AVOption).
>
> Special syntaxes
>
> Any component can define its own syntax. It should not be abused,
> since consistency is also good, but it will be useful sometimes.
>
> Polymorphism
>
> A field can accept different types, both at API level and for the
> user. For example, a video size can be both a whole to accept size
> names ("hd720") or individual numbers w and h.
>
> Namespaced sub-structures
>
> If the field "f" is itself a structure made of fields, including "a"
> and "b", then several syntaxes can be allowed to set it:
> "f.a=5:f.b=3", "f={a=5:b=3}", and optionally just "a=5:b=3" if there
> are no field "a" and "b" in the parent structure.
>
> Hooks
>
> Fields can have a type that wraps their real type to perform extra
> actions. For example set another field to indicate whether the option
> was set by the user or left to default.
>
> Varying options
>
> New options can appear or disappear according to previously set
> options, like the number of inputs for a filter. For example, a codec
> context could accept "codec=libx264:crf=20" (but not
> "crf=20:codec=libx264").
>
> Embedded documentation
>
> Types and fields can contain documentation, more than the simple
> string currently in AVOption. An API should be available to build a
> single documentation page for a given set of elements, pulling the
> necessary dependencies (description for the syntax of fields) only
> once, and at various detail levels: short summary for a tooltip or
> full text with examples for the web page.
>
> Syntax validation and autocompletion
>
> Parsers should have a dry-mode run where they read the string but do
> not set values, to allow applications to check fields early. They
> could even return suggested completions or corrections. (This is
> somewhat incompatible with varying options, we can live with that.)
>
>
> Conclusion
>
> This has been a very lengthy exposition. Actually, I believe
> implementation would not be that long. Well, longer than text, of course,
> but not as gigantic as the explanation suggests. And a lot of steps can be
> made incrementally.
>
> IMHO, the result would be both a better design and an enhanced user
> experience.
>
>
> Personal note: if you skimmed through the whole thing and did not find it
> completely uninteresting, I would appreciate even short quick feedback,
> even "looks interesting, will read more carefully later".the new features this would introduce sound interresting and also reducing the escaping madness would be nice. I wont comment on the implementation details as i have not thought about them really but i definitly agree that there are limitations in the current API and that improving it would be desirable. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I know you won't believe me, but the highest form of Human Excellence is to question oneself and others. -- Socrates
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
