Although cuvid can only output 8bit, it can consume HEVC Main10 if
the bit depth is set properly. In cases where >8bit is not supported,
this change is still beneficial as the decoder will fail to be
created instead of plowing throw and decoding as 8bit.
We need to remove the dynlink fanciness and replace it with normal
function prototypes and update the include paths and configure logic.
We don't need to explicitly check for PICPARMS now - they're going
to be there.
Currently does not work with the ffmpeg cli tool, due do it using the
old one in one out API.
Anything using the new API, like mpv, can make use of it, provided it is
prepared for a decoder modifying the framerate and outputing multiple
frames per input. FFmpeg itself is not.
Despite the video parser seeming to correctly handle 422 and 444
chroma formats, the video decoder fails miserably to actually
decode frames - even though no errors are ever returned; you just
get frames showing unintialized garbage.
Signed-off-by: Philip Langdale <philipl@overt.org>
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
I'm not really sure how this worked at all before, but we do need to
reinitalize the parser with the stream extradata.
Signed-off-by: Philip Langdale <philipl@overt.org>
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
The cuvid parser is basically undocumented, and although you'd
think that a failed callback would result in the overall parse
call returning an error, that is not true.
So, we end up silently trying to keep going as if nothing is wrong,
which doesn't achieve anything.
Solution: check the internal error flag every time.
Signed-off-by: Philip Langdale <philipl@overt.org>
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
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>
