On 23/10/14 17:06, Dave Rice wrote:
> On Oct 23, 2014, at 4:05 AM, Clément Bœsch <u...@pkh.me> wrote:
>> On Tue, Oct 21, 2014 at 09:32:39AM +0200, Carl Eugen Hoyos wrote:
>>> Hi!
>>>
>>> It appears to me that we all know that fieldmatch needs cfr input,
>>> but it isn't mentioned in the documentation.
>>> Related to ticket #3968.
>>>
>>> Please comment, Carl Eugen
>>
>>> diff --git a/doc/filters.texi b/doc/filters.texi
>>> index c70ddf3..bc77623 100644
>>> --- a/doc/filters.texi
>>> +++ b/doc/filters.texi
>>> @@ -4447,6 +4447,9 @@ and VIVTC/VFM (VapourSynth project). The later is a
>>> light clone of TFM from
>>> which @code{fieldmatch} is based on. While the semantic and usage are very
>>> close, some behaviour and options names can differ.
>>>
>>> +The filter only works for strictly constant frame rate input. If your input
>>> +has variable frame rate, try the @ref{pullup} filter.
>>> +
>>
>> Well... isn't telecined content supposed to be CFR anyway? I would say
>> it's supposed to be undefined behaviour in any ivtc filter but well. No
>> opinion really.
>
> This would be ideal, but some common production applications use VFR. For
> instance when digitizing with the Log and Capture interface of Final Cut Pro
> the first and last frame usually have custom durations although most of the
> rest of the file is 2997/100. There’s another setting in the Final Cut to
> compensate for dropped frames by extending the duration of the last good
> captured frame.
Not only FCP. Pipelines do it too.
> Dave Rice
> _[..]
--
Tim.
Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
