James Almer (12023-04-25):
> I support the addition of a new better API as a replacement for AVBprint, as
> long as you take into account the suggestions made by people and their
> requests for exemplifications of its usage and usefulness. This also means
> potential changes to the header.
Of cour
Anton Khirnov (12023-04-26):
> This project is developed in the open, private emails, rumors, and
> hearsay do not count as arguments.
>
> This code is unnecessary bloat that adds nothing of value to the
> project.
Your negative opinion has already been taken into consideration, it is
the main re
Quoting Nicolas George (2023-04-25 19:11:44)
> Hi.
>
> I finally have some tome to go at this again.
>
> Totalizing this thread, the previous discussions and the few private
> mails I received, I conclude there is significant more support than
> opposition to AVWriter, so I am moving forward with
On 4/25/2023 2:11 PM, Nicolas George wrote:
Hi.
I finally have some tome to go at this again.
Totalizing this thread, the previous discussions and the few private
mails I received, I conclude there is significant more support than
opposition to AVWriter, so I am moving forward with polishing an
Hi.
I finally have some tome to go at this again.
Totalizing this thread, the previous discussions and the few private
mails I received, I conclude there is significant more support than
opposition to AVWriter, so I am moving forward with polishing and
pushing the implementation.
(To avoid antag
On Wed, Sep 07, 2022 at 03:30:09PM +0200, Nicolas George wrote:
> Anton Khirnov (12022-09-02):
> > As I already said to you in private, I do not think the motivation and
> > use cases for this have been sufficiently established.
> >
> > You claim this will bring massive advantages all over the pla
Quoting Nicolas George (2022-09-07 15:30:09)
> Anton Khirnov (12022-09-02):
> > As I already said to you in private, I do not think the motivation and
> > use cases for this have been sufficiently established.
> >
> > You claim this will bring massive advantages all over the place. You
> > should
Jean-Baptiste Kempf (12022-09-07):
> Open source communities are based on consensus. You cannot just discard an
> opinion
> as less important than other just because YOU consider it's not important.
>
> Especially about someone who is in the top 5 contributor of the project, in
> the
> last few
On Wed, 7 Sep 2022, at 15:30, Nicolas George wrote:
> With that correction stated, I have already answered you that your
> inability to see the benefits is only proof that your work on FFmpeg is
[...]
> last time it happened you used the worst possible implementation and we
Please stop attacking p
Anton Khirnov (12022-09-02):
> As I already said to you in private, I do not think the motivation and
> use cases for this have been sufficiently established.
>
> You claim this will bring massive advantages all over the place. You
> should support these claims with some actual patches that demons
As I already said to you in private, I do not think the motivation and
use cases for this have been sufficiently established.
You claim this will bring massive advantages all over the place. You
should support these claims with some actual patches that demonstrate
these advantages on some real cod
On date Thursday 2022-09-01 15:01:27 +0200, Nicolas George wrote:
[...]
> Thanks for the review. I do not think it is necessary to send an updated
> patch for these changes, is it?
Not needed, thanks.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.or
Stefano Sabatini (12022-09-01):
> serializeS
Locally fixed.
> This "something" is vague and can be confused with the "something" in
> "av_something_write", maybe something as:
> when presented with invalid arguments, if the flag is not set the
> called method should leave...
No, the first interp
On date Wednesday 2022-08-24 17:18:28 +0200, Nicolas George wrote:
> The actual implementation, tests and uses in the rest of
> FFmpeg code will be committed separately once the API is
> settled.
>
> Signed-off-by: Nicolas George
> ---
> doc/avwriter_intro.md | 109 ++
> libavutil/writer
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 a
Leo Izen:
>
> On 8/30/22 15:37, Nicolas George wrote:
>> Leo Izen (12022-08-30):
>>> Is there a reason this is AVWriter wr = foo() and not AVWriter *wr =
>>> foo()?
>>> Most other APIs return pointers to structs, rather than structs
>>> themselves
>>> (see: av_packet_alloc). Using a pointer would
On 8/30/22 15:37, Nicolas George wrote:
Leo Izen (12022-08-30):
Is there a reason this is AVWriter wr = foo() and not AVWriter *wr = foo()?
Most other APIs return pointers to structs, rather than structs themselves
(see: av_packet_alloc). Using a pointer would prevent us from having
sizeof(AVW
Leo Izen (12022-08-30):
> Is there a reason this is AVWriter wr = foo() and not AVWriter *wr = foo()?
> Most other APIs return pointers to structs, rather than structs themselves
> (see: av_packet_alloc). Using a pointer would prevent us from having
> sizeof(AVWriter) as part of the ABI, as was don
On 8/24/22 11:18, Nicolas George wrote:
+```
+AVWriter wr = av_dynbuf_writer();
+av_something_write(wr, something, 0);
+if (av_writer_get_error(wr, 0) < 0)
+die("Failed");
+use_string(av_dynbuf_writer_get_data(wr, NULL));
+av_dynbuf_writer_fin
Nicolas George (12022-08-24):
> The actual implementation, tests and uses in the rest of
> FFmpeg code will be committed separately once the API is
> settled.
>
> Signed-off-by: Nicolas George
> ---
> doc/avwriter_intro.md | 109 ++
> libavutil/writer.h| 484 +
Andreas Rheinhardt (12022-08-24):
> Where is this header?
# Note: FF_NEW_SZ is a macro defined elsewhere; it is really part of the
# implementation more than the API.
This is all there is to it for this case. I can move it here for now.
Regards,
--
Nicolas George
signature.asc
Description:
Nicolas George:
> The actual implementation, tests and uses in the rest of
> FFmpeg code will be committed separately once the API is
> settled.
>
I think you misunderstood JB: He did not say that the headers are pushed
without the implementation, he just said that the headers should be
discussed
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Nicolas George
> Sent: Wednesday, August 24, 2022 5:18 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: [FFmpeg-devel] [PATCH] lavu: header and documentation for
> AVWriter
>
> The actual implementation, tests and uses in the rest of
>
23 matches
Mail list logo