Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
 help / color / mirror / Atom feed
From: Nicolas George <george@nsup.org>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Subject: Re: [FFmpeg-devel] [PATCH] lavu: header and documentation for AVWriter
Date: Wed, 31 Aug 2022 21:28:17 +0200
Message-ID: <Yw+2UR7RYQQBAVG0@phare.normalesup.org> (raw)
In-Reply-To: <GV1P250MB073756F6453A730ABE7940A48F789@GV1P250MB0737.EURP250.PROD.OUTLOOK.COM>


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

Andreas Rheinhardt (12022-08-31):
> He is not only stack-allocating AVWriter, he also intends to
> stack-allocate the actual writers like AVDynbufWriter, AVBufWriter
> (AVWriter is just a wrapper around the underlying writers). This means
> that no allocations need to be performed for AVBufWriter at all (and due
> to the inherent small-string optimization of an AVBPrint, it can also be
> avoided for AVDynbufWriter in lots of cases).
> If you return pointers to an AVWriter struct, you need to allocate this
> struct somewhere, which means that your init/av_dynbuf_writer_wrap has
> an allocation that can fail and therefore needs to be checked; and the
> struct needs to be freed lateron.

Thanks. I could have been more precise.

AVWriter itself uses a new kind of mini decentralized object system,
where all objects are a pair of pointers, first a const pointer to the
structure of primitive methods and second the structure itself, and are
passed by value. It does not require any future extension, it just works
that way.

This scheme allows to add methods on an existing structure without
altering it. So, any kind of side data, for example, can become an
object with serialize methods, or an object with ref/unref methods, etc.

The various implementations of AVWriter are also designed to be
allocated on the stack by the caller. This time, to avoid being
encumbered by sizeof(struct) for compatibility, I use a different trick:
one of the first field of the structure is its own size, set by whoever
allocated it.

Currently, the code only checks that the size is at least the original
size. If we later extend the structure, the code will have to check if
the fields it tries to access are below the reported size, and if they
are not it will have to manage without them, use a fallback value.

For writers, need for extending the structure is very unlikely. But for
the methods structures, it can happen. Methods structures defined by
earlier applications will just behave as if these methods are
unimplemented.

The ability to allocate on the stack is essential to AVWriter, since it
needs to be lightweight enough that we never have to hesitate to use it.
Of course, it can always be allocated dynamically. I wonder if I should
include functions to allocate dynamically and init av_dynbuf_writer() at
least.

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".

  reply	other threads:[~2022-08-31 19:28 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-24 15:18 Nicolas George
2022-08-24 15:45 ` Soft Works
2022-08-24 15:59 ` Andreas Rheinhardt
2022-08-24 16:01   ` Nicolas George
2022-08-30 17:08 ` Nicolas George
2022-08-30 19:33 ` Leo Izen
2022-08-30 19:37   ` Nicolas George
2022-08-31  3:13     ` Leo Izen
2022-08-31  3:23       ` Andreas Rheinhardt
2022-08-31 19:28         ` Nicolas George [this message]
2022-08-31 23:03 ` Stefano Sabatini
2022-09-01 13:01   ` Nicolas George
2022-09-01 21:33     ` Stefano Sabatini
2022-09-02  6:41 ` Anton Khirnov
2022-09-07 13:30   ` Nicolas George
2022-09-07 20:05     ` Jean-Baptiste Kempf
2022-09-07 21:13       ` Nicolas George
2022-09-08 16:18     ` Anton Khirnov
2022-09-14 21:29     ` Michael Niedermayer
2023-04-25 17:11 ` Nicolas George
2023-04-25 17:20   ` James Almer
2023-04-28 10:00     ` Nicolas George
2023-04-26  9:05   ` Anton Khirnov
2023-04-28  9:58     ` Nicolas George

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Yw+2UR7RYQQBAVG0@phare.normalesup.org \
    --to=george@nsup.org \
    --cc=ffmpeg-devel@ffmpeg.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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