On Wed, 20 Mar 2024 20:55:26 +0100 Michael Niedermayer
wrote:
> On Wed, Mar 20, 2024 at 03:23:53PM +0100, Niklas Haas wrote:
> > On Tue, 19 Mar 2024 22:55:56 +0100 Michael Niedermayer
> > wrote:
> > > is it neccessary to drop compatibility to the old syntax ?
> >
> > Only if we want to use
On Wed, Mar 20, 2024 at 03:23:53PM +0100, Niklas Haas wrote:
> On Tue, 19 Mar 2024 22:55:56 +0100 Michael Niedermayer
> wrote:
> > is it neccessary to drop compatibility to the old syntax ?
>
> Only if we want to use framesync. If we don't care about synchronizing
> the streams, then we could
On Tue, 19 Mar 2024 22:55:56 +0100 Michael Niedermayer
wrote:
> is it neccessary to drop compatibility to the old syntax ?
Only if we want to use framesync. If we don't care about synchronizing
the streams, then we could drop FS and just use a custom activate
function which forwards output
On Wed, Mar 13, 2024 at 01:24:25PM +0100, Niklas Haas wrote:
> From: Niklas Haas
>
> This filter's existing design has a number of issues:
>
> - There is no guarantee whatsoever about the order in which frames are
> pushed onto the main and ref link, due to this being entirely
> dependent
> This should be It is probably the reason for Michael's segfault.
> Apart from that: It is easier if you simply used 0..2 for *iter (1==
> returned sws_get_class, 2 returned ff_framesync_child_class_iterate).
Changed this function to:
static const AVClass *child_class_iterate(void **iter)
{
On Wed, Mar 13, 2024 at 08:43:58PM -0300, James Almer wrote:
> On 3/13/2024 8:41 PM, Michael Niedermayer wrote:
> > On Wed, Mar 13, 2024 at 01:24:25PM +0100, Niklas Haas wrote:
> > > From: Niklas Haas
> > >
> > > This filter's existing design has a number of issues:
> > >
> > > - There is no
Niklas Haas:
> From: Niklas Haas
>
> This filter's existing design has a number of issues:
>
> - There is no guarantee whatsoever about the order in which frames are
> pushed onto the main and ref link, due to this being entirely
> dependent on the order in which downstream filters decide
On 3/13/2024 8:41 PM, Michael Niedermayer wrote:
On Wed, Mar 13, 2024 at 01:24:25PM +0100, Niklas Haas wrote:
From: Niklas Haas
This filter's existing design has a number of issues:
- There is no guarantee whatsoever about the order in which frames are
pushed onto the main and ref link,
On Wed, Mar 13, 2024 at 01:24:25PM +0100, Niklas Haas wrote:
> From: Niklas Haas
>
> This filter's existing design has a number of issues:
>
> - There is no guarantee whatsoever about the order in which frames are
> pushed onto the main and ref link, due to this being entirely
> dependent
On 2024-03-13 05:54 pm, Niklas Haas wrote:
From: Niklas Haas
This filter's existing design has a number of issues:
- There is no guarantee whatsoever about the order in which frames are
pushed onto the main and ref link, due to this being entirely
dependent on the order in which
On Wed, 13 Mar 2024 13:24:25 +0100 Niklas Haas wrote:
> -frame_changed = in->width != link->w ||
> -in->height != link->h ||
> -in->format != link->format ||
> -in->sample_aspect_ratio.den !=
> link->sample_aspect_ratio.den ||
> -
From: Niklas Haas
This filter's existing design has a number of issues:
- There is no guarantee whatsoever about the order in which frames are
pushed onto the main and ref link, due to this being entirely
dependent on the order in which downstream filters decide to request
frames from
12 matches
Mail list logo
