not to mention race conditions and that its used for stream copy, used to determine IPB type by
applications and other things.
Fixes various frame drop/timestamp issues with frame multithreading.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The codec uses all previous frames as reference frames, so they
certainly must be preserved and readable.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Changing the lowres value is risky because the user application may have a
local copy and not read back into it, or not undo some lowres dependant things.
A patch implementing this in ffplay is already on ffmpeg-dev, so this feature
should be back soon.
This reverts commit 125ea3ee06.
Actually check the return value of DecodeBegin, to make
sure that it has encountered no errors.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Remove the CODEC_CAP_LOSSLESS flag, as it doesn't make
any sense for a decoder to use it.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Since buf_size is only used in this one function, there
is no reason for it to be part of UtVideoContext.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
run: The number of zero coefficients preceding a non-zero coefficient,
in the scan order. The absolute value of the non-zero coefficient is
called "level".
The run-level code makes illegal reads when trying to set up tables for
nonsense level 0.
run: The number of zero coefficients preceding a non-zero coefficient,
in the scan order. The absolute value of the non-zero coefficient is
called "level".
The run-level code makes illegal reads when trying to set up tables for
nonsense level 0.
Width and height, as used in utvideo_decode_frame, do not
need to be unsigned, and it could cause sign-compare
warnings later on.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The frameinfo size member of the Ut Video extradata
was erroneously thought to be the number of stripes.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The original format field in Ut Video's extradata
should not be used to determine the output format.
Cases can occur where the original format differs
from the actual current format, and thus should
not be used as the output format. Instead, rely
solely on the FOURCC.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
p cannot be calculated before av_dup_packet since that one
might change avpkt->data, causing invalid reads and a
non-working range check.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
avctx->width/height remain right/bottom cropped as previous behaviour.
Hardware decoders need to know the uncropped data to allocate surfaces
of correct height. Some hardware is picky and fails to decoder properly
if a surface larger than needed is used during decode, so just aligning
up is not enough.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
There were multiple issues, for example might we have to re-run
the decompression when the size of the buffer increased,
we should always use a decompression buffer large enough for
the header (so we do not get stuck when the size is too small).
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
I am not sure these new values are correct, not am I sure
the semantics are a good idea since we do not seem to make any
use of them but they caused a lot of confusion, but this
seems to make things closer to matching the documentation.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Michael Niedermayer
Carl Eugen Hoyos
Reimar Döffinger
Alex Converse
Justin Ruggles
Diego Biurrun
Kostya Shishkov
Vitor Sessak
Derek Buitenhuis
Joakim Plate