Re: [FFmpeg-devel] [PATCH 4/5] lavfi: drop the requirement that request_frame returns a frame.

On Mon, Sep 21, 2015 at 12:32:22AM +0200, Michael Niedermayer wrote: > On Sun, Sep 20, 2015 at 07:39:11PM +0200, Nicolas George wrote: > > Le jour de la Raison, an CCXXIII, Paul B Mahol a écrit : > > > For complex cases one needs to set for which set of input pixel > > > formats output pixel

Re: [FFmpeg-devel] [PATCH 4/5] lavfi: drop the requirement that request_frame returns a frame.

Dana 21. 9. 2015. 00:32 osoba "Michael Niedermayer" napisala je: > > On Sun, Sep 20, 2015 at 07:39:11PM +0200, Nicolas George wrote: > > Le jour de la Raison, an CCXXIII, Paul B Mahol a écrit : > > > For complex cases one needs to set for which set of input pixel > > > formats

Re: [FFmpeg-devel] [PATCH 4/5] lavfi: drop the requirement that request_frame returns a frame.

On 9/20/15, Nicolas George wrote: > Le primidi 11 fructidor, an CCXXIII, Paul B Mahol a écrit : >> One more thing, the query_formats is very limited for filters that pick >> one >> pixel format for input and another one for output depending on picked >> format >> for input.

Re: [FFmpeg-devel] [PATCH 4/5] lavfi: drop the requirement that request_frame returns a frame.

On 9/20/15, Nicolas George wrote: > Le jour de la Raison, an CCXXIII, Paul B Mahol a écrit : >> For complex cases one needs to set for which set of input pixel >> formats output pixel format will be picked from another set, so its >> M->N mapping, without overlaping. > > Yes, but

Re: [FFmpeg-devel] [PATCH 4/5] lavfi: drop the requirement that request_frame returns a frame.

Le jour de la Raison, an CCXXIII, Paul B Mahol a écrit : > For complex cases one needs to set for which set of input pixel > formats output pixel format will be picked from another set, so its > M->N mapping, without overlaping. Yes, but what algorithm do you apply to the mapping afterwards to

Re: [FFmpeg-devel] [PATCH 4/5] lavfi: drop the requirement that request_frame returns a frame.

On Sun, Sep 20, 2015 at 07:39:11PM +0200, Nicolas George wrote: > Le jour de la Raison, an CCXXIII, Paul B Mahol a écrit : > > For complex cases one needs to set for which set of input pixel > > formats output pixel format will be picked from another set, so its > > M->N mapping, without

Re: [FFmpeg-devel] [PATCH 4/5] lavfi: drop the requirement that request_frame returns a frame.

Le primidi 11 fructidor, an CCXXIII, Paul B Mahol a écrit : > One more thing, the query_formats is very limited for filters that pick one > pixel format for input and another one for output depending on picked format > for input. Returning EAGAIN almost always works but there are special >

Re: [FFmpeg-devel] [PATCH 4/5] lavfi: drop the requirement that request_frame returns a frame.

Le decadi 10 fructidor, an CCXXIII, Michael Niedermayer a écrit : > there may be one problem though > if the parameters of Frames change and a link "contains" 5 frames > it is possible that not all these frames have the same size or > aspect ratio. Currently a link contains dimensions and aspect

Re: [FFmpeg-devel] [PATCH 4/5] lavfi: drop the requirement that request_frame returns a frame.

On 8/26/15, Nicolas George geo...@nsup.org wrote: It requires a loop in filters or the framework, that makes the scheduling less efficient and more complex. This is purely an internal change since the loop is now present in buffersink. Note that no filter except buffersink did rely on the

Re: [FFmpeg-devel] [PATCH 4/5] lavfi: drop the requirement that request_frame returns a frame.

On 8/26/15, Paul B Mahol one...@gmail.com wrote: On 8/26/15, Nicolas George geo...@nsup.org wrote: Le nonidi 9 fructidor, an CCXXIII, Paul B Mahol a ecrit : I'm interested. Glad to read it. So here it is: Foremost, I want to remove the recursiveness. Currently, when a frame is requested on

Re: [FFmpeg-devel] [PATCH 4/5] lavfi: drop the requirement that request_frame returns a frame.

On 8/26/15, Nicolas George geo...@nsup.org wrote: Le nonidi 9 fructidor, an CCXXIII, Paul B Mahol a ecrit : I'm interested. Glad to read it. So here it is: Foremost, I want to remove the recursiveness. Currently, when a frame is requested on buffersink, it recursively calls request_frame()

[FFmpeg-devel] [PATCH 4/5] lavfi: drop the requirement that request_frame returns a frame.

It requires a loop in filters or the framework, that makes the scheduling less efficient and more complex. This is purely an internal change since the loop is now present in buffersink. Note that no filter except buffersink did rely on the requirement. Signed-off-by: Nicolas George

Re: [FFmpeg-devel] [PATCH 4/5] lavfi: drop the requirement that request_frame returns a frame.

On 8/26/15, Nicolas George geo...@nsup.org wrote: It requires a loop in filters or the framework, that makes the scheduling less efficient and more complex. This is purely an internal change since the loop is now present in buffersink. Note that no filter except buffersink did rely on the

Re: [FFmpeg-devel] [PATCH 4/5] lavfi: drop the requirement that request_frame returns a frame.

On Wed, Aug 26, 2015 at 04:46:21PM +0200, Nicolas George wrote: Le nonidi 9 fructidor, an CCXXIII, Paul B Mahol a écrit : I'm interested. Glad to read it. So here it is: Foremost, I want to remove the recursiveness. Currently, when a frame is requested on buffersink, it recursively calls