- 12 Dec, 2016 1 commit
-
-
Timo Rothenpieler authored
-
- 23 Nov, 2016 1 commit
-
-
Philip Langdale authored
I moved this into the handle_video_sequence callback because that's the earliest time you can make an accurate decision as to what the format should be. However, transcoding requires that the decision between using the accelerated PIX_FMT_CUDA vs a normal pix format happen at init() time. There is enough information available to make that decision and things work out with the underlying format only being discovered in the sequence callback.
-
- 22 Nov, 2016 3 commits
-
-
Philip Langdale authored
The nvidia 375.xx driver introduces support for P016 output surfaces, for 10bit and 12bit HEVC content (it's also the first driver to support hardware decoding of 12bit content). The cuvid api, as far as I can tell, only declares one output format that they appear to refer to as P016 in the driver strings. Of course, 10bit content in P016 is identical to P010, and it is useful for compatibility purposes to declare the format to be P010 to work with other components that only know how to consume P010 (and to avoid triggering swscale conversions that are lossy when they shouldn't be). For simplicity, this change does not maintain the previous ability to output dithered NV12 for 10/12 bit input video - the user will need to update their driver to decode such videos.
-
Miroslav Slugen authored
Signed-off-by:
Timo Rothenpieler <timo@rothenpieler.org>
-
Timo Rothenpieler authored
And remove the now obsolete compat headers.
-
- 30 Oct, 2016 1 commit
-
-
Philip Langdale authored
Turns out cuvid doesn't support h.263.
-
- 22 Oct, 2016 1 commit
-
-
Philip Langdale authored
In practice, this works fine.
-
- 04 Oct, 2016 1 commit
-
-
Timo Rothenpieler authored
hwcontext_cuda was changed to take care of proper alignment internally
-
- 29 Sep, 2016 3 commits
-
-
Timo Rothenpieler authored
-
Timo Rothenpieler authored
-
Timo Rothenpieler authored
-
- 23 Sep, 2016 3 commits
-
-
Timo Rothenpieler authored
-
Philip Langdale authored
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.
-
Philip Langdale authored
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.
-
- 21 Sep, 2016 2 commits
-
-
Timo Rothenpieler authored
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.
-
Timo Rothenpieler authored
-
- 17 Sep, 2016 2 commits
-
-
Philip Langdale authored
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>
-
Philip Langdale authored
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>
-
- 10 Sep, 2016 1 commit
-
-
Philip Langdale authored
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>
-
- 09 Sep, 2016 2 commits
-
-
Timo Rothenpieler authored
-
Timo Rothenpieler authored
-
- 06 Sep, 2016 2 commits
-
-
Philip Langdale authored
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>
-
Philip Langdale authored
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>
-
- 10 Jun, 2016 1 commit
-
-
Timo Rothenpieler authored
-