James Almer (12023-04-29):
> History has shown that these notifications have had no effect on users, and
> even on this same project's developers. A good example was ffserver.c, which
> accessed an unholy amount of lavf private fields (both exposed in public
> headers and even internal ones), and
On 4/29/2023 6:13 AM, Nicolas George wrote:
Anton Khirnov (12023-04-29):
That does not follow at all - just because something was moved once does
not mean it cannot be moved again if a better place is found later.
Good, then you should have no objection to replacing your private
structure
Anton Khirnov (12023-04-29):
> That does not follow at all - just because something was moved once does
> not mean it cannot be moved again if a better place is found later.
Good, then you should have no objection to replacing your private
structure with a “/* these fields are private to… */”
Quoting Nicolas George (2023-04-29 10:46:31)
> Nicolas George (12023-04-28):
> > And during the work of turning all into threads, opportunities to split
> > the structure in more logical ways with less code noise will almost
> > certainly present themselves.
>
> I had intended to not reply
Nicolas George (12023-04-28):
> And during the work of turning all into threads, opportunities to split
> the structure in more logical ways with less code noise will almost
> certainly present themselves.
I had intended to not reply further on this, but I just had a severe
case of esprit de
James Almer (12023-04-28):
> The longtime goal of this work is to have completely standalone modules
> within the CLI and each of them threaded. So while ffmpeg may not be a
> library, clearly defining what fields should be accessed from "the outside"
> and which shouldn't would have the same
On 4/28/2023 5:45 AM, Nicolas George wrote:
Anton Khirnov (12023-04-27):
Start by moving OutputStream.filtered_frame to it, which really belongs
to the filtergraph rather than the output stream.
Then just move them to OutputStream. This is just code noise for no
practical benefit, since
Anton Khirnov (12023-04-27):
> Start by moving OutputStream.filtered_frame to it, which really belongs
> to the filtergraph rather than the output stream.
Then just move them to OutputStream. This is just code noise for no
practical benefit, since ffmpeg is not a library and does not have to
deal
Start by moving OutputStream.filtered_frame to it, which really belongs
to the filtergraph rather than the output stream.
---
fftools/ffmpeg.h | 1 -
fftools/ffmpeg_filter.c | 31 ++-
fftools/ffmpeg_mux.c | 1 -
fftools/ffmpeg_mux_init.c | 4
4
