From a84c4de31f32dd46aa5b57b072ee32b913f5d80a Mon Sep 17 00:00:00 2001 From: wm4 Date: Sat, 25 May 2019 14:59:48 +0200 Subject: manpage: deinterlacing with backwards playback probably works As well as other filtering. I was writing this with the assumption that timestamps go backwards (which I first planned to do). But in fact, timestamps go forward, frame durations are positive, and adding a frame duration to a timestamp yields the correct result. The only strange thing is that timestamps are negative. Also, media of course goes backwards. In other possible implementation, filters would see normal forward playback, interrupted by seeks or discontinuities. It turns out the current implementation of providing a continuous backward media stream is probably better for filters. Even deinterlacing seems to work. libavcodec always outputs fields in as interleaved frames (i.e. fields are not reversed), and making up timestamps for the new frames (when doubling the framerate) works exactly like like in the forward case. Actually the previous paragraph was a lie, and libavcodec does not output fields as interleaved frames in rare cases. Sometimes AVFrame contains single fields. In this case you'd need to inverse the field dominance for deinterlacing filters to work correctly. --- DOCS/man/options.rst | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/DOCS/man/options.rst b/DOCS/man/options.rst index 460e07b1c7..74ea73be98 100644 --- a/DOCS/man/options.rst +++ b/DOCS/man/options.rst @@ -420,9 +420,7 @@ Playback Control - Backward output. This is relatively simple, because the decoder returns the frames in the needed order. However, this may cause various problems - because very basic assumptions are broken (such as time going forward). - Also, some filtering becomes impossible. Deinterlacing filters will not - work. + because filters see audio and video going backward. Known problems: -- cgit v1.2.3