diff options
author | wm4 <wm4@nowhere> | 2019-05-25 14:59:48 +0200 |
---|---|---|
committer | wm4 <wm4@nowhere> | 2019-09-19 20:37:04 +0200 |
commit | a84c4de31f32dd46aa5b57b072ee32b913f5d80a (patch) | |
tree | 2c3d9dbb3ded84b294a07ab4060af228d607534e /demux/stheader.h | |
parent | b04a761ce41fd2e2e24f5cf60cf60f30db148fcc (diff) | |
download | mpv-a84c4de31f32dd46aa5b57b072ee32b913f5d80a.tar.bz2 mpv-a84c4de31f32dd46aa5b57b072ee32b913f5d80a.tar.xz |
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.
Diffstat (limited to 'demux/stheader.h')
0 files changed, 0 insertions, 0 deletions