They are not just inverses of each other.
This should restore behavior to before the introduction of framerate
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
When decoding, this field holds the inverse of the framerate that can be
written in the headers for some codecs. Using a field called 'time_base'
for this is very misleading, as there are no timestamps associated with
it. Furthermore, this field is used for a very different purpose during
encoding.
Add a new field, called 'framerate', to replace the use of time_base for
decoding.
Initialise VC1DSPContext for parser as well as for decoder.
Note, the VC-1 code doesn't actually use the function pointer yet.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Initialise VC1DSPContext for parser as well as for decoder.
Note, the VC-1 code doesn't actually use the function pointer yet.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The most interesting parts are initialization in ff_MPV_common_init() and
uninitialization in ff_MPV_common_end().
ff_mpeg_unref_picture and ff_thread_release_buffer have additional NULL
checks for Picture.f, because these functions can be called on
uninitialized or partially initialized Pictures.
NULL pointer checks are added to ff_thread_release_buffer() stub function.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
Fixes an issue where the B-frame coding mode switches from interlaced
fields to interlaced frames, causing incorrect decisions in the motion
compensation code and resulting in visual artifacts.
CC: libav-stable@libav.org
Signed-off-by: Tim Walker <tdskywalker@gmail.com>
1 is the only valid value for VC-1/WMV3, and setting it here makes sure
no invalid value is send to a hw accelerator, for example.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Introduced by 28243b0d35
Intensity compensation is always used once it was encountered, because
v->next_use_ic is never set back to zero.
Reset v->next_use_ic, when resetting v->next_luty/uv.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Fix https://trac.ffmpeg.org/ticket/3204
The problem was that intensity compensation was always used once it was
encountered. This is because v->next_use_ic was never set back to zero.
To fix this, when resetting v->next_luty/uv, also reset v->next_use_ic.
This improved (restored) performance by 85% when decoding
http://bit.ly/bbbwmv
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Tables are always allocated now with sufficient space for either progressive
or interlaced content. The alternative would be to detect a change
and reallocate.
This fixes decoding of a sample.
Signed-off-by: Martin Storsjö <martin@martin.st>
Fixes ticket2531
Tables are always allocated now with sufficient space for either progressive
or interlaced content. The alternative would be to detect a change
and reallocate.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
There are samples in the wild with B-frames and P-frames with different
interlace mode.
CC: libav-stable@libav.org
Reported-by: Jean-Baptiste Kempf <jb@videolan.org>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Use the intensity-compensated reference frame for subsequent
fields/B-frames.
Since we currently don't change the reference frame we have to
maintain lookup tables for intensity compensation in the following
dependent frames.
Signed-off-by: Martin Storsjö <martin@martin.st>
The existing implementation had little to do with VC1.
This could be implemented by adjusting the reference frames
ithemselfs but that would make frame multi-threading difficult.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Alexandra Hájková
Vittorio Giovara
Diego Biurrun
Michael Niedermayer
zhaoxiu.zeng
Paul B Mahol
Anton Khirnov
Ben Avison
Justin Ruggles
wm4
Tim Walker
Hendrik Leppkes
Mason Carter
Kostya Shishkov
Martin Storsjö