[FFmpeg-devel] [PATCH] lavfi/fps: rescale input PTS immediately.

[Michael Niedermayer]

On Sat, Jan 25, 2014 at 07:37:58PM +0100, Nicolas George wrote:
> Keeping it in its original time base leads to more complex code
> and systematic rounding errors.
> 
> Also change default rounding direction: rounding down is more
> logical, rounding up was a workaround for the systematic errors.
> 
> Fix trac ticket #3329 and part of #2674.
> 
> Signed-off-by: Nicolas George <george at nsup.org>
> ---
>  libavfilter/vf_fps.c | 24 ++++++++++++------------
>  1 file changed, 12 insertions(+), 12 deletions(-)
> 
> 
> The 24->48 part of #2674 is due to the lack of frame duration or EOF PTS.
> I intend to propose an API that will allow, amongst other things, EOF PTS.
> 
> This code also has a lot of room for improvement. Amongst other things:
> 
> * Use AV_OPT_TYPE_DURATION for start_time and get rid of floating-point
>   arithmetic.
> 
> * Keep the first frame separately from the FIFO.
> 
> 

using the output timebase for input timestamps is flawed, and cannot
work optimally because it discards information that is required

consider input at 1/100 timebase and output at 1/1 timebase
for each output frame one input frame has to be selected.
There may be between 0 and 100 frames during the display interval of
a specific output frame.
Along one direction of argumentation, the best choice to represent
the interval from second 7 to second 8
would be a frame, which has its middle of its display interval closest
to the time 7.5sec
but if you have 5 frames with timestamp 7 and 5 with timestamp 8
which frame that is has been lost

another way to argue about which frame is best would bias toward
even spacing, so if the input frames are very asymetrically placed
like 0, 0.9, 1.9, 2.1, 2.9, 3.9
that output should on fps 1/1 be using 0, 0.9, 1.9, 2.9, 3.9 it should
not pick the frames at 0, 1.9, 2.1, 3.9 because they are poorly
distributed. Again this isnt possibly when the input timestamps have
been rounded into the output timebase

There are other lines of argumentation what is best but discarding
the exact input timestamps probably causes problems to them as well

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No great genius has ever existed without some touch of madness. -- Aristotle
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20140125/4dc368a9/attachment.asc>