[FFmpeg-devel] Confusion over temporal filters.

[Richard Ling]

Thanks Marton & Paul.
Flushing filter state after a seek makes good sense.  For my proposed
filter (video normalization, with auto gain control) flushing will give a
much more acceptable result than using unrelated frames.  For my use case
I'm only interested in transcoding complete files, so I always get the
exact expected result.  But maybe some time, the filter API could be
updated so that after a seek, a filter can request frames that are before
the seek position.
Thanks again for your answers.
R.

On 10 September 2017 at 17:17, Marton Balint <cus at passwd.hu> wrote:

>
>
> On Sun, 10 Sep 2017, Paul B Mahol wrote:
>
> On 9/10/17, Richard Ling <divetec at rling.com> wrote:
>>
>>> I'm thinking of adding a temporal filter (one that relies on context from
>>> previous frames), and I've realised I'm a bit confused about how they
>>> should work.
>>>
>>> Say I open a file with ffplay and let it play up to frame 100.  Then I
>>> open
>>> the same file with another instance of ffplay and seek directly to frame
>>> 100.  It seems to me that frame 100 should look the same in both cases.
>>> Put another way, a specific set of filters, applied to a specific file,
>>> should completely define what every frame of that file looks like.
>>> Seeking
>>> around in the file should not change that.  Is that right (in principle)?
>>>
>>> So, looking at some of the existing temporal filters (eg. deflicker), I
>>> don't think that is what happens.  They filter based on the frames
>>> previously passed to the filter, and if the user seeks over a bunch of
>>> frames, the filter will see frames as consecutive that are not actually
>>> consecutive in the file, so it will give a different result.  Also,
>>> looking
>>> at the API, I can't see a way to get the behaviour I expect.  I can't
>>> see a
>>> way for a filter to ask its inputs for a frame from a different
>>> (specific)
>>> time.  Is that right?
>>>
>>> If my understanding is wrong, please let me know!
>>>
>>> If my undersanding is correct, then I guess my questions are:
>>> (1) is this behaviour a known issue (or a deliberate design choice)?
>>>
>>
>> Both. There is no seeking in lavfi (yet).
>>
>
> Actually ffplay re-creates the filter chain after every seek flushing any
> state of the filters, therefore non-consecuitve frames are not passed to
> the filters.
>
> Regards,
> Marton
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>