- 17 Jan, 2013 1 commit
-
-
Luca Barbato authored
-
- 26 Feb, 2012 1 commit
-
-
Anton Khirnov authored
r_frame_rate should in theory have something to do with input framerate, but in practice it is often made up from thin air by lavf. So unless we are targeting a constant output framerate, it's better to just use input stream timebase. Brings back dropped frames in nuv and cscd tests introduced in cd1ad18a
-
- 03 Feb, 2012 1 commit
-
-
Anton Khirnov authored
Right now those muxers use the default timebase in all cases(1/90000). This patch avoid unnecessary rescaling and makes the printed timestamps more readable. Also, extend the printed information to include the timebases and packet pts/duration and align the columns. Obviously changes the results of all fate tests which use those two muxers.
-
- 17 Aug, 2011 3 commits
-
-
Kostya Shishkov authored
Signed-off-by:
Anton Khirnov <anton@khirnov.net>
-
Kostya Shishkov authored
Signed-off-by:
Anton Khirnov <anton@khirnov.net>
-
Kostya Shishkov authored
First, container stores only DTS and not PTS as it was believed. Second, multiple frames in a packet store timestamp instead of position after the frame length. Signed-off-by:
Anton Khirnov <anton@khirnov.net>
-
- 02 Aug, 2011 1 commit
-
-
Kostya Shishkov authored
Old version divided it wrong, which resulted in chroma drift (visible on FATE sample too as dirty trails left by clouds). Signed-off-by:
Ronald S. Bultje <rsbultje@gmail.com>
-
- 10 Oct, 2010 1 commit
-
-
Alexander Strange authored
The rm demuxer has timestamp bugs, so this test is sensitive to changes in timestamp correction. The previous commit did not make output any better or worse on this test, just different. See https://roundup.ffmpeg.org/issue2288 for details. Originally committed as revision 25432 to svn://svn.ffmpeg.org/ffmpeg/trunk
-
- 31 Aug, 2010 1 commit
-
-
Vitor Sessak authored
Originally committed as revision 25008 to svn://svn.ffmpeg.org/ffmpeg/trunk
-