This is in the same the same vein as c981b1145a.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The new decode API allows for m:n decode patterns, which is what
you need to use this hardware in a sane way. There are so many
situations where 1:1 doesn't happen naturally that it's a miracle
I got it working as well as I did.
With this change, we can throw all of the crazy heuristics and
sleeps(!) out, and things work correctly.
The slice index expected by D3D11VA is the one from the texture not from the
array or texture/slices.
In VLC the slices we provide the decoder don't start from 0 and thus pictures
appear in bogus order. With possible crashes and corruptions when using an
invalid index.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Right now, if we attempt to use cuvid in a media player and then
try to seek, the decoder will happily pass out whatever frames were
already in flight before the seek.
There is both the output queue in our code and some number of frames
within the cuvid decoder that need to be accounted for.
cuvid doesn't support flush, so our only choice is to do a brute-force
re-creation of the decoder, which also implies re-creating the parser,
but this is fine.
The only subtlty is that there is sanity check code in decoder
initialisation that wants to make sure the HWContextFrame hasn't already
been initialised. This is a fair check to do at the beginning but not
after a flush, so it has to be made conditional.
Signed-off-by: Philip Langdale <philipl@overt.org>
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
cuvid/nvdecode also supports mpeg1, mpeg2, h.263/mpeg4-asp and mjpeg.
It should, in theory, also support wmv3 via the vc1 support, given
that vdpau supports this. However, it failed to play wmv3 samples
which vdpau played correctly, so I'm not sure what to make of it.
Signed-off-by: Philip Langdale <philipl@overt.org>
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
Currently it's exported as AVFrame.pkt_pts, which is also the only use
for that field. The reason it is done like this is that lavc used to
export various codec-specific "timing" information in AVFrame.pts, which
is not done anymore.
Since it is confusing to the callers to have a separate field which is
used only for decoder timestamps and nothing else, deprecate pkt_pts and
use just AVFrame.pts everywhere.
This avoids enabling and building the x264rgb encoder when its actually not supported and
thus would not work
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This function is supposed to "reset" a codec context to a clean state so
that it can be opened again. The only reason it exists is to allow using
AVStream.codec as a decoding context (after it was already
opened/used/closed by avformat_find_stream_info()). Since that behaviour
is now deprecated, there is no reason for this function to exist
anymore.
Since AVCodecContext contains a lot of complex state, copying a codec
context is not a well-defined operation. The purpose for which it is
typically used (which is well-defined) is copying the stream parameters
from one codec context to another. That is now possible with through the
AVCodecParameters API. Therefore, there is no reason for
avcodec_copy_context() to exist.
Derek Buitenhuis
Philip Langdale
Michael Niedermayer
Matthieu Bouron
Timo Rothenpieler
Steve Lhomme
Sasi Inguva
Carl Eugen Hoyos
Yogender Gupta
Rostislav Pehlivanov
Oliver Collyer
Paul B Mahol
Jon Toohill
Jan Sebechlebsky
Martin Storsjö
Vittorio Giovara
Anton Khirnov
Neil Birkbeck
Diego Biurrun