> On Thursday, September 3, 2015 8:45 AM, Carl Eugen Hoyos
> wrote:
> > Nicholas Robbins ffmpeg.org> writes:
>
>> >> You are using dejudder & fps to produce a stream of
>> >> frames lies ABCDDEFGHH... then decimate drops the
>> >> dups. Seems brutal.
>> >
>> > Why / how?
>>
>> It
Nicholas Robbins ffmpeg.org> writes:
> >> You are using dejudder & fps to produce a stream of
> >> frames lies ABCDDEFGHH... then decimate drops the
> >> dups. Seems brutal.
> >
> > Why / how?
>
> It just seems strange to me to make those extra frames
> just to throw them away. Seems mea
> On Wednesday, September 2, 2015 5:43 PM, Carl Eugen Hoyos
> wrote:
> I didn't test because it works fine afaict.
Great
>> Or are you offering a suggestion for mixed 24fps
>> progressive and 24->30 telecined?
>
> Yes.
>
>> In that case it seems like this should work.
>
> This is w
Carl Eugen Hoyos ag.or.at> writes:
> +If your input has mixed telecined and progressive content which implies
> +changing framerates use the following filterchain to produce the
> +necessary cfr stream:
Changed locally to avoid the misinterpretation 30fps
telecined and 30fps progressive:
If you
Nicholas Robbins ffmpeg.org> writes:
> Do you have a sample where dejudder used like this helps?
http://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket3968/
> If so does it work better with larger n?
I didn't test because it works fine afaict.
> Your suggestion is for material that is a mix of 30
On Wednesday, September 2, 2015 7:50 AM, Carl Eugen Hoyos
wrote:
>Hi!
>
>As Clément always pointed out correctly, the issues users see with
>fieldmatch and mixed telecined and progressive content have nothing
>to do with decimate (and of course not fieldmatch) but with the
>specifics of our fp
Hi!
As Clément always pointed out correctly, the issues users see with
fieldmatch and mixed telecined and progressive content have nothing
to do with decimate (and of course not fieldmatch) but with the
specifics of our fps filter (see my ignored mail for details).
Attached patch should help,
