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 <c...@passwd.hu> wrote: > > > On Sun, 10 Sep 2017, Paul B Mahol wrote: > > On 9/10/17, Richard Ling <dive...@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@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
