Re: [FFmpeg-devel] [PATCH 1/6] lavfi/buffersink: add accessors for the stream properties.

On Fri, 23 Dec 2016 21:02:09 +0100 Michael Niedermayer wrote: > On Fri, Dec 23, 2016 at 06:51:38PM +0100, Nicolas George wrote: > > Le tridi 3 nivôse, an CCXXV, Michael Niedermayer a écrit : > > > libavfilter had a public API that allowed filters to be implemented > > >

Re: [FFmpeg-devel] [PATCH 1/6] lavfi/buffersink: add accessors for the stream properties.

Le quartidi 4 nivôse, an CCXXV, Michael Niedermayer a écrit : > My oppinion is that If we intend to have AVFilterLink public in the > future then making it private now is a bad idea and wasted time. Something I just remembered: With the prospect of inter-filters threading, it is better if even

Re: [FFmpeg-devel] [PATCH 1/6] lavfi/buffersink: add accessors for the stream properties.

Le quartidi 4 nivôse, an CCXXV, Michael Niedermayer a écrit : > you snipped the context and reply to the quote as if it was meant > in a different context. > Not everyone intends to attack you :) Sorry; I might have still been a little on edge. > The quoted text are the steps which IMHO make

Re: [FFmpeg-devel] [PATCH 1/6] lavfi/buffersink: add accessors for the stream properties.

On Fri, Dec 23, 2016 at 11:46:07PM +0100, Nicolas George wrote: > Le tridi 3 nivôse, an CCXXV, Michael Niedermayer a écrit : > > shouldnt there be a public annoncement about the intend to make the API > > public > > shouldnt there be a public call for API design suggestions and discussion > >

Re: [FFmpeg-devel] [PATCH 1/6] lavfi/buffersink: add accessors for the stream properties.

Le tridi 3 nivôse, an CCXXV, Michael Niedermayer a écrit : > shouldnt there be a public annoncement about the intend to make the API public > shouldnt there be a public call for API design suggestions and discussion > shouldnt there be a public call for API related patches with deadline > shouldnt

Re: [FFmpeg-devel] [PATCH 1/6] lavfi/buffersink: add accessors for the stream properties.

On Fri, Dec 23, 2016 at 09:23:50PM +0100, Nicolas George wrote: > Le tridi 3 nivôse, an CCXXV, Michael Niedermayer a écrit : > > APIs in FFmpeg will change as long as the project is alive. > > > > new developers join, older ones leave, peoples goals and oppinions > > change. The libavfilter API

Re: [FFmpeg-devel] [PATCH 1/6] lavfi/buffersink: add accessors for the stream properties.

Le tridi 3 nivôse, an CCXXV, Michael Niedermayer a écrit : > APIs in FFmpeg will change as long as the project is alive. > > new developers join, older ones leave, peoples goals and oppinions > change. The libavfilter API is based on the lessons learned from > previous projects and frameworks, in

Re: [FFmpeg-devel] [PATCH 1/6] lavfi/buffersink: add accessors for the stream properties.

On Fri, Dec 23, 2016 at 06:51:38PM +0100, Nicolas George wrote: > Le tridi 3 nivôse, an CCXXV, Michael Niedermayer a écrit : > > libavfilter had a public API that allowed filters to be implemented > > these changes move it farther away from it > > I do care about having some public API that allows

Re: [FFmpeg-devel] [PATCH 1/6] lavfi/buffersink: add accessors for the stream properties.

Le tridi 3 nivôse, an CCXXV, Michael Niedermayer a écrit : > libavfilter had a public API that allowed filters to be implemented > these changes move it farther away from it > I do care about having some public API that allows filters > to be implemented. > You pointed out that you work alone and

Re: [FFmpeg-devel] [PATCH 1/6] lavfi/buffersink: add accessors for the stream properties.

On Fri, Dec 23, 2016 at 05:08:49PM +0100, Nicolas George wrote: > Le tridi 3 nivôse, an CCXXV, Michael Niedermayer a écrit : > > From these 2 the first > > Ok, that makes one. > > > but i think the user app needs more access > > to be able to implement filters and this could

Re: [FFmpeg-devel] [PATCH 1/6] lavfi/buffersink: add accessors for the stream properties.

On 12/23/2016 11:31 AM, Nicolas George wrote: > L'octidi 28 frimaire, an CCXXV, Nicolas George a écrit : >> +AVRational av_buffersink_get_frame_rate (const >> AVFilterContext *ctx); >> +int av_buffersink_get_w (const >> AVFilterContext *ctx); >> +int

Re: [FFmpeg-devel] [PATCH 1/6] lavfi/buffersink: add accessors for the stream properties.

On Fri, 23 Dec 2016 15:49:16 +0100 Nicolas George wrote: > Le primidi 1er nivôse, an CCXXV, wm4 a écrit : > > [about windows COM system] > > > To make it short, everything in COM consists of structs with function > > pointers. Structs are never extended, if you need new

Re: [FFmpeg-devel] [PATCH 1/6] lavfi/buffersink: add accessors for the stream properties.

Le tridi 3 nivôse, an CCXXV, Michael Niedermayer a écrit : > also AVCodecParameters would be an option to use as a struct if a > struct is used Unfortunately not, since it lacks at least time_base and frame_rate. We could add them, but think it would be a bad idea. It also has a lot of other

Re: [FFmpeg-devel] [PATCH 1/6] lavfi/buffersink: add accessors for the stream properties.

Le tridi 3 nivôse, an CCXXV, Michael Niedermayer a écrit : > From these 2 the first Ok, that makes one. >but i think the user app needs more access > to be able to implement filters and this could make either API > obsoleete User app implementing filters is not for today

Re: [FFmpeg-devel] [PATCH 1/6] lavfi/buffersink: add accessors for the stream properties.

On Fri, Dec 23, 2016 at 04:59:45PM +0100, Michael Niedermayer wrote: > On Fri, Dec 23, 2016 at 03:31:45PM +0100, Nicolas George wrote: > > L'octidi 28 frimaire, an CCXXV, Nicolas George a écrit : > > > +AVRational av_buffersink_get_frame_rate (const > > > AVFilterContext *ctx); > >

Re: [FFmpeg-devel] [PATCH 1/6] lavfi/buffersink: add accessors for the stream properties.

On Fri, Dec 23, 2016 at 03:31:45PM +0100, Nicolas George wrote: > L'octidi 28 frimaire, an CCXXV, Nicolas George a écrit : > > +AVRational av_buffersink_get_frame_rate (const > > AVFilterContext *ctx); > > +int av_buffersink_get_w (const > >

Re: [FFmpeg-devel] [PATCH 1/6] lavfi/buffersink: add accessors for the stream properties.

Le primidi 1er nivôse, an CCXXV, wm4 a écrit : [about windows COM system] > To make it short, everything in COM consists of structs with function > pointers. Structs are never extended, if you need new function > pointers, you just add new structs, which you can dynamically query > from the old

Re: [FFmpeg-devel] [PATCH 1/6] lavfi/buffersink: add accessors for the stream properties.

L'octidi 28 frimaire, an CCXXV, Nicolas George a écrit : > +AVRational av_buffersink_get_frame_rate (const > AVFilterContext *ctx); > +int av_buffersink_get_w (const > AVFilterContext *ctx); > +int av_buffersink_get_h

Re: [FFmpeg-devel] [PATCH 1/6] lavfi/buffersink: add accessors for the stream properties.

On Wed, 21 Dec 2016 01:56:59 +0100 Andreas Cadhalpun wrote: > On 20.12.2016 15:46, wm4 wrote: > > In general, replacing public fields with macro-generated accessors is > > really just a rename. Admittedly, it removes a confusing indirection > > (though

Re: [FFmpeg-devel] [PATCH 1/6] lavfi/buffersink: add accessors for the stream properties.

On Tue, 20 Dec 2016 22:58:28 +0100 Nicolas George wrote: > Le decadi 30 frimaire, an CCXXV, wm4 a écrit : > > > You mean a single structure returned by a single accessor with all the > > > stream's properties instead of individual accessors for individual > > > properties? Well,

Re: [FFmpeg-devel] [PATCH 1/6] lavfi/buffersink: add accessors for the stream properties.

Le decadi 30 frimaire, an CCXXV, Andreas Cadhalpun a écrit : > I'm not aware of a user outside of ffmpeg and const changes shouldn't cause > big > problems, as only the API changes, not the ABI. So it is probably OK. Thanks. > I'm not convinced that this is more convenient. APIchanges can still

Re: [FFmpeg-devel] [PATCH 1/6] lavfi/buffersink: add accessors for the stream properties.

On 20.12.2016 15:46, wm4 wrote: > In general, replacing public fields with macro-generated accessors is > really just a rename. Admittedly, it removes a confusing indirection > (though ->inputs[0]) in this case, but in general the improvements are > very minor. What does it matter if whether there

Re: [FFmpeg-devel] [PATCH 1/6] lavfi/buffersink: add accessors for the stream properties.

Le decadi 30 frimaire, an CCXXV, wm4 a écrit : > > You mean a single structure returned by a single accessor with all the > > stream's properties instead of individual accessors for individual > > properties? Well, the naive methods of returning a structure to the > > caller would make the size of

Re: [FFmpeg-devel] [PATCH 1/6] lavfi/buffersink: add accessors for the stream properties.

On Mon, 19 Dec 2016 09:40:41 +0100 Nicolas George wrote: > L'octidi 28 frimaire, an CCXXV, wm4 a écrit : > > For buffersink, you could simply return a struct with the parameters. > > As a value type, it'd be a copy and wouldn't need accessors. > > You mean a single structure

Re: [FFmpeg-devel] [PATCH 1/6] lavfi/buffersink: add accessors for the stream properties.

On 18.12.2016 13:22, Nicolas George wrote: > av_buffersink_get_frame_rate() did already exist; its argument becomes const. > > TODO minor version bump > > API-Change: libavfilter > Signed-off-by: Nicolas George > --- > libavfilter/buffersink.c | 25 +++-- >

Re: [FFmpeg-devel] [PATCH 1/6] lavfi/buffersink: add accessors for the stream properties.

L'octidi 28 frimaire, an CCXXV, wm4 a écrit : > For buffersink, you could simply return a struct with the parameters. > As a value type, it'd be a copy and wouldn't need accessors. You mean a single structure returned by a single accessor with all the stream's properties instead of individual

Re: [FFmpeg-devel] [PATCH 1/6] lavfi/buffersink: add accessors for the stream properties.

On Sun, 18 Dec 2016 19:32:16 +0100 Nicolas George wrote: > By "actual internal structs", I suspect you mean something similar to > this: > > typedef struct AVFormatContext { > ... > AVFormatInternal *internal; > ... > }; > > Introducing these structures was a big

Re: [FFmpeg-devel] [PATCH 1/6] lavfi/buffersink: add accessors for the stream properties.

L'octidi 28 frimaire, an CCXXV, James Almer a écrit : > You didn't answer what's the gain here. Yes I did: discuss that with Hendrik, Andreas and Clément, not me. >How is this better than keeping the > struct public and letting library users keep accessing

Re: [FFmpeg-devel] [PATCH 1/6] lavfi/buffersink: add accessors for the stream properties.

On 12/18/2016 3:32 PM, Nicolas George wrote: > L'octidi 28 frimaire, an CCXXV, James Almer a écrit : >> Is this to make AVFilterLink a fully internal struct? > > As you can see in patch 6/6 in this series. > >> What's the reason >> to do that

Re: [FFmpeg-devel] [PATCH 1/6] lavfi/buffersink: add accessors for the stream properties.

L'octidi 28 frimaire, an CCXXV, James Almer a écrit : > Is this to make AVFilterLink a fully internal struct? As you can see in patch 6/6 in this series. > What's the reason > to do that in that case, instead of simply making its private

Re: [FFmpeg-devel] [PATCH 1/6] lavfi/buffersink: add accessors for the stream properties.

On 12/18/2016 9:22 AM, Nicolas George wrote: > av_buffersink_get_frame_rate() did already exist; its argument becomes const. > > TODO minor version bump What's the purpose of adding these accessors? The only reason we have done this before was because of the now dropped libav ABI compatibility,