Re: [FFmpeg-devel] [PATCH]Mention in the documentation that fieldmatch needs cfr input
> On Wednesday, October 29, 2014 1:33 PM, Carl Eugen Hoyos > wrote: > > Nicholas Robbins ffmpeg.org> writes: > >> Not now, but later, I would be interested in helping to >> adapt decimate to do what we want. A detectfps filter >> might be useful too, and would be a subset of the work. > > I believe if decimate just detects 23.9 -> 29.97 and > 29.97 -> 23.9 it will fix nearly all use cases. > > Carl Eugen If it is running after fieldmatch, then it needs to detect 23.9 29.9 (w 1/5 duplicates duplicates, ouput of fieldmatch on TC material) 29.9 (w/o duplicates, interlaced or progressive, but not TC) A bonus would be to differentiate 29.9 that was originally 23.9 (Film, TC with 3:2) or originally 24.9 (PAL, TC with 3:3:2:2:2) If the input to -vf "fieldmatch,decimate" is mixed 30fps progressive and the result of TC then it decimate will always see 30fps frame rate, but some frames will be duplicated, or am I missing something? -Nick ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Mention in the documentation that fieldmatch needs cfr input
Nicholas Robbins ffmpeg.org> writes: > Not now, but later, I would be interested in helping to > adapt decimate to do what we want. A detectfps filter > might be useful too, and would be a subset of the work. I believe if decimate just detects 23.9 -> 29.97 and 29.97 -> 23.9 it will fix nearly all use cases. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Mention in the documentation that fieldmatch needs cfr input
> On Wednesday, October 29, 2014 12:25 PM, Carl Eugen Hoyos > wrote: > > Calvin Walton kepstin.ca> writes: > >> For content that was in mpeg2 with field flags set >> appropriate for display on an interlaced TV > > This is unrelated to this issue: > FFmpeg simply ignores the flag and interprets the > input as progressive. > >> which basically accounts for all DVD content > > I live in PAL-country but from user reports and > samples (like the one in question) I know that > this unfortunately isn't true;-( > > This whole issue is about vob files that contain > both progressive 24000/1001 and (hard-) telecined > 3/1001 video in the same stream (with actual > switching frame rates). > It appears to me that decimate should detect the > frame rate changes and not drop anything for the > progressive content. > > Carl Eugen I've also seen mixed hard telecined (24->29.97) and interlaced (29.97) in the same stream, or hard telecined and 29.97 progressive. This whole thing makes me wish we used PAL here. Also metric paper, but that is a different gripe. Not now, but later, I would be interested in helping to adapt decimate to do what we want. A detectfps filter might be useful too, and would be a subset of the work. Nick ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Mention in the documentation that fieldmatch needs cfr input
Calvin Walton kepstin.ca> writes: > For content that was in mpeg2 with field flags set > appropriate for display on an interlaced TV This is unrelated to this issue: FFmpeg simply ignores the flag and interprets the input as progressive. > which basically accounts for all DVD content I live in PAL-country but from user reports and samples (like the one in question) I know that this unfortunately isn't true;-( This whole issue is about vob files that contain both progressive 24000/1001 and (hard-) telecined 3/1001 video in the same stream (with actual switching frame rates). It appears to me that decimate should detect the frame rate changes and not drop anything for the progressive content. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Mention in the documentation that fieldmatch needs cfr input
On Sat, 2014-10-25 at 12:22 +, Carl Eugen Hoyos wrote:
> Clément Bœsch pkh.me> writes:
>
> > > +The filter only works for constant frame rate input. If your
> > > input
> > > +has mixed telecined and progressive content with changing
> > > framerate,
> > > +try the ref{pullup} filter.
> >
> > Well I don't mind much but then... how is pullup making
> > any difference here actually
>
> Just to sum it up:
> pullup works fine and is fast for all samples I have seen,
> it definitely misses many merging opportunities if the
> horizontal motion is very low (meaning some frames with
> artefacts remain for every real-world input).
> fieldmatch is very slow, it is apparently able to
> produce perfect output for badly cut input with constant
> (telecined) framerate but it fails completely for mixed
> content (as found on many DVD's).
>
> Imo, fps=3/1001,fieldmatch,decimate should fix this
> but decimate unfortunately does not drop the frame that
> fps inserted but a random (?) frame.
> (Or fieldmatch finds matches in progressive input?)
For content that was in mpeg2 with field flags set appropriate for
display on an interlaced TV - which basically accounts for all DVD
content - mplayer had a 'softpulldown' filter that used these flags to
turn the video stream from mixed progressive+telecined+interlaced
content with variable framerate (in NTSC, mixed 24/1001 frames/s and
60/1001 fields/s) into a telecined+interlaced video with constant
framerate (60/1001 fields/s).
I wonder if something similar would be useful in ffmpeg, to provide a
constant fps stream that a detelecine filter could use as input.
--
Calvin Walton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Mention in the documentation that fieldmatch needs cfr input
Clément Bœsch pkh.me> writes:
> > +The filter only works for constant frame rate input. If your input
> > +has mixed telecined and progressive content with changing framerate,
> > +try the ref{pullup} filter.
>
> Well I don't mind much but then... how is pullup making
> any difference here actually?
I removed the pullup suggestion and the patch was merged
by Michael.
As discussed on irc, I believe that this should be fixed
in decimate: It can detect the framerate change and not
drop any frames for the progressive parts.
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Mention in the documentation that fieldmatch needs cfr input
Clément Bœsch pkh.me> writes:
> > +The filter only works for constant frame rate input. If your input
> > +has mixed telecined and progressive content with changing framerate,
> > +try the ref{pullup} filter.
>
> Well I don't mind much but then... how is pullup making
> any difference here actually?
You mean why does it work with pullup but not fieldmatch?
I honestly cannot answer, sorry...
> fieldmatch isn't actually touching the pts nor using them.
I wonder if that (together with using decimate) isn't the
problem.
But this is of course completely unrelated.
Just to sum it up:
pullup works fine and is fast for all samples I have seen,
it definitely misses many merging opportunities if the
horizontal motion is very low (meaning some frames with
artefacts remain for every real-world input).
fieldmatch is very slow, it is apparently able to
produce perfect output for badly cut input with constant
(telecined) framerate but it fails completely for mixed
content (as found on many DVD's).
Imo, fps=3/1001,fieldmatch,decimate should fix this
but decimate unfortunately does not drop the frame that
fps inserted but a random (?) frame.
(Or fieldmatch finds matches in progressive input?)
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Mention in the documentation that fieldmatch needs cfr input
On Thu, Oct 23, 2014 at 05:58:48PM +0200, Carl Eugen Hoyos wrote:
> On Thursday 23 October 2014 10:05:07 am Clément Bœsch wrote:
> > > +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?
>
> Patch updated.
>
> Thank you, Carl Eugen
> diff --git a/doc/filters.texi b/doc/filters.texi
> index c70ddf3..24e3e50 100644
> --- a/doc/filters.texi
> +++ b/doc/filters.texi
> @@ -4447,6 +4447,10 @@ 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 constant frame rate input. If your input
> +has mixed telecined and progressive content with changing framerate,
> +try the @ref{pullup} filter.
> +
Well I don't mind much but then... how is pullup making any difference
here actually? fieldmatch isn't actually touching the pts nor using them.
[...]
--
Clément B.
pgp9t6007Hw8N.pgp
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Mention in the documentation that fieldmatch needs cfr input
On 23/10/14 17:06, Dave Rice wrote:
> On Oct 23, 2014, at 4:05 AM, Clément Bœsch 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
Re: [FFmpeg-devel] [PATCH]Mention in the documentation that fieldmatch needs cfr input
On Oct 23, 2014, at 4:05 AM, Clément Bœsch 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.
Dave Rice
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Mention in the documentation that fieldmatch needs cfr input
On Thursday 23 October 2014 10:05:07 am Clément Bœsch wrote:
> > +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?
Patch updated.
Thank you, Carl Eugen
diff --git a/doc/filters.texi b/doc/filters.texi
index c70ddf3..24e3e50 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -4447,6 +4447,10 @@ 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 constant frame rate input. If your input
+has mixed telecined and progressive content with changing framerate,
+try the @ref{pullup} filter.
+
The filter accepts the following options:
@table @option
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Mention in the documentation that fieldmatch needs cfr input
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.
[...]
--
Clément B.
pgpbUXeagfMr5.pgp
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Mention in the documentation that fieldmatch needs cfr input
Derek Buitenhuis gmail.com> writes:
> On 10/21/2014 8:32 AM, Carl Eugen Hoyos wrote:
> > +The filter only works for strictly constant frame rate input.
I removed "strictly" locally.
> > If your input
> > +has variable frame rate, try the ref{pullup} filter.
>
> Perhaps the filter should output a warning as well?
I have no opinion, but this sounds unrelated to me.
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Mention in the documentation that fieldmatch needs cfr input
On 10/21/2014 8:32 AM, Carl Eugen Hoyos wrote:
> +The filter only works for strictly constant frame rate input. If your input
> +has variable frame rate, try the @ref{pullup} filter.
Perhaps the filter should output a warning as well?
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH]Mention in the documentation that fieldmatch needs cfr input
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.
+
The filter accepts the following options:
@table @option
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
