On Mon, Jan 14, 2019 at 01:43:45PM -0500, Devin Heitmueller wrote:
> On Mon, Jan 14, 2019 at 12:45 PM Michael Niedermayer
> wrote:
> > well, there are other types of side data too. for example motion
> > vectors would need to be updated on crop depending on which rectangle
> > is croped out
>
> A
On Mon, Jan 14, 2019 at 12:45 PM Michael Niedermayer
wrote:
> well, there are other types of side data too. for example motion
> vectors would need to be updated on crop depending on which rectangle
> is croped out
Ah, yes, of course. I thought we were just discussing captions.
So are you propo
On Mon, Jan 14, 2019 at 11:11:59AM -0500, Devin Heitmueller wrote:
> > > In short, a centralized function would be good, but we probably need
> > > to think through what the API looks like so we don't have to introduce
> > > a new API in libavutil and then deprecate it once we want to make the
> >
> > In short, a centralized function would be good, but we probably need
> > to think through what the API looks like so we don't have to introduce
> > a new API in libavutil and then deprecate it once we want to make the
> > splitting/combining logic work according to the spec.
>
> I fear that no
On Mon, Jan 14, 2019 at 09:21:10AM -0500, Devin Heitmueller wrote:
> On Mon, Jan 14, 2019 at 3:31 AM Michael Niedermayer
> wrote:
> > Thus a new function should be added which does all this, and that then
> > be used
>
> For what it's worth, the fix is actually incorrect both here and in
> vf_vps
On Mon, Jan 14, 2019 at 3:31 AM Michael Niedermayer
wrote:
> Thus a new function should be added which does all this, and that then
> be used
For what it's worth, the fix is actually incorrect both here and in
vf_vps. When doubling the framerate, the correct behavior is to split
the content acro
Carl Eugen Hoyos (12019-01-14):
> Then we would have the same function as now, no?
No, the function we have now removes side data based on its type, the
new function would remove it based on circumstances, whatever that means
to be determined at a later point.
Regards,
--
Nicolas George
sig
2019-01-14 13:12 GMT+01:00, Nicolas George :
> Carl Eugen Hoyos (12019-01-14):
>> Do you mean a new function that exactly removes the kind of side
>> data that we decide in advance should always be removed from
>> duplicated frames?
>
> That seems like a good idea. Applications may want to duplicat
Carl Eugen Hoyos (12019-01-14):
> Do you mean a new function that exactly removes the kind of side
> data that we decide in advance should always be removed from
> duplicated frames?
That seems like a good idea. Applications may want to duplicate frames
too, and they will not be updated when we ad
2019-01-14 9:31 GMT+01:00, Michael Niedermayer :
> On Sun, Jan 13, 2019 at 05:26:49PM -0500, Gabriel Blanchard wrote:
>> When frame doubling using yadif/bwdif closed captioning gets copied to
>> the
>> second frame - as a result the closed captioning text is garbage.
>>
>> I've attached a very simp
On Sun, Jan 13, 2019 at 05:26:49PM -0500, Gabriel Blanchard wrote:
> When frame doubling using yadif/bwdif closed captioning gets copied to the
> second frame - as a result the closed captioning text is garbage.
>
> I've attached a very simple patch that fixes this issue. Very similar to
> what vf
When frame doubling using yadif/bwdif closed captioning gets copied to the
second frame - as a result the closed captioning text is garbage.
I've attached a very simple patch that fixes this issue. Very similar to
what vf_fps.c already does around line 253.
-Gabe
From 0f6d3c31842ae33eaa3d5d91600b
12 matches
Mail list logo
