| Message ID | 20220817214932.42351-2-george@nsup.org |
|---|---|
| State | New |
| Headers | show |
| Series | [FFmpeg-devel,1/2] doc/plans: add a file to list approved projects | expand |
| Context | Check | Description |
|---|---|---|
| yinshiyou/make_loongarch64 | success | Make finished |
| yinshiyou/make_fate_loongarch64 | success | Make fate finished |
| andriy/make_x86 | success | Make finished |
| andriy/make_fate_x86 | success | Make fate finished |
Why reinventing yet another ad-hoc thing.
On Wed, 17 Aug 2022, at 23:49, Nicolas George wrote: > +An API that can be used everywhere a function needs to return a > string, or > +really an arbitrary buffer of bytes, and everywhere code needs to > build a > +string from parts. It needs to be fast and lightweight enough to be > used in > +tight loops, like once per frame, without limiting the size of the How is that different from open_memstream?
On 8/18/22 13:23, Jean-Baptiste Kempf wrote: > On Wed, 17 Aug 2022, at 23:49, Nicolas George wrote: >> +An API that can be used everywhere a function needs to return a >> string, or >> +really an arbitrary buffer of bytes, and everywhere code needs to >> build a >> +string from parts. It needs to be fast and lightweight enough to be >> used in >> +tight loops, like once per frame, without limiting the size of the > > How is that different from open_memstream? I'm not sure open_memstream is available on all platforms, in particular I think it's missing on MinGW. But otherwise, it looks like it, so maybe it makes more sense to just use a compatibility shimmy on windows? - Leo Izen (thebombzen)
Leo Izen (12022-08-22): > > > +An API that can be used everywhere a function needs to return a > > > string, or > > > +really an arbitrary buffer of bytes, and everywhere code needs to > > > build a > > > +string from parts. It needs to be fast and lightweight enough to be > > > used in > > > +tight loops, like once per frame, without limiting the size of the > > > > How is that different from open_memstream? > > I'm not sure open_memstream is available on all platforms, in particular I > think it's missing on MinGW. > > But otherwise, it looks like it, so maybe it makes more sense to just use a > compatibility shimmy on windows? open_memstream() does not even qualify for “fast and lightweight enough to be used in tight loops”, let alone all the features AVWriter has. Regards,
diff --git a/doc/plans.md b/doc/plans.md index 0d7336e8b4..d96328aabc 100644 --- a/doc/plans.md +++ b/doc/plans.md @@ -4,3 +4,41 @@ Projects listed below have been approved by the FFmpeg developers community, and their author(s) can invest time and effort implementing them. The resulting patches will be subject to technical review like any other patches, but they can no longer be rejected on principle. + +## AVWriter: a unified API for building and returning strings + +**Author:** Nicolas George + +An API that can be used everywhere a function needs to return a string, or +really an arbitrary buffer of bytes, and everywhere code needs to build a +string from parts. It needs to be fast and lightweight enough to be used in +tight loops, like once per frame, without limiting the size of the returned +string when needed. It should make checking for overflows and possible +memory allocation errors simple. It should easily be compatible with other +uses of strings, especially standard C buffers. + +AVWriter is an enhancement on the AVBPrint API; AVBPrint already achieves +some of these objectives but not all. + +Like other FFmpeg components, AVWriter is designed as a limited +object-oriented virtual class / interface with multiple implementations. To +let applications define their own writers and allocate structures on the +stack or as part of their data, structures contain their own size and the +code only accesses fields that exist. + +Some functions are specific to a particular implementation of AVWriter; for +example getting a mallocated buffer from a dynamic AVWriter. It is the +responsibility of the caller to use the right type, which will usually be +enforced by an assert. + +**Future plans where AVWriter will help:** + +A universal API to return the string associated with an elementary type +(pixel format, channel layout, etc.) and to serialize complex types, +especially side data. + +A system to store error messages in contexts instead of logging them, to +make it easier for applications, especially GUI, to display them cleanly. + +An extension to `avwriter_printf()` to use any serializable object directly +from the format string.
Signed-off-by: Nicolas George <george@nsup.org> --- doc/plans.md | 38 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 38 insertions(+)