On Wed, 22 Nov 2017 23:36:23 +0100
Timo Rothenpieler wrote:
> >> I'd like to look through it again and test a bit more (will try to
> >> do so tomorrow, certainly by the end of the week), but I think it
> >> should be ready to commit with the external header removed.
> >
> > Are you planning t
On Fri, 24 Nov 2017 00:51:29 +
Mark Thompson wrote:
> Enables VP8 decoding - the decoder places the the bitstream version
> in the profile field, which we want to ignore.
> ---
> libavcodec/vaapi_decode.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/
On Fri, 24 Nov 2017 00:51:30 +
Mark Thompson wrote:
> This is needed by later hwaccel code to tell which encoding process
> was used for a particular frame, because hardware decoders may only
> support a subset of possible methods.
> ---
> libavcodec/avcodec.h | 6 ++
> libavcodec/mjpeg
On Fri, 24 Nov 2017 00:51:24 +
Mark Thompson wrote:
> ---
> libavcodec/avcodec.h| 2 +-
> libavcodec/decode.c | 2 +-
> libavcodec/dxva2_h264.c | 6 +--
> libavcodec/dxva2_hevc.c | 6 +--
> libavcodec/dxva2_mpeg2.c| 6 +--
> libavcodec/dxva2_vc1.c | 12 +
On Fri, 24 Nov 2017 00:51:19 +
Mark Thompson wrote:
> This includes a pointer to the associated hwaccel for decoders using
> hwaccels - these will be used later to implement the hwaccel setup
> without needing a global list.
>
> Also added is a new file listing all hwaccels as external
> dec
On Fri, 24 Nov 2017 00:51:31 +
Mark Thompson wrote:
> Also adds some extra fields to the main context structure that may
> be needed by a hwaccel decoder.
> ---
> The YUVJ formats really mess with this. This patch hacks them out so
> that the hwaccel works, suggestions welcome on what to act
ize, and data can be copied out safely.
In this particular jpeg case, you end up with a blank (green) line
at the bottom due to nvdec refusing to decode the last line, but
the behaviour matches cuviddec, so it's as good as you're going to
get.
Signed-off-by: Philip Langdale
---
libav
On Fri, 24 Nov 2017 22:49:18 -0300
James Almer wrote:
> Both are autodetected, and their dependency on cuda is checked
> elsewhere.
>
> Fixes ticket #6849.
> ---
> configure | 4
> 1 file changed, 4 deletions(-)
>
> diff --git a/configure b/configure
> index 3ec6407fb2..7769427ffb 100755
Signed-off-by: Philip Langdale
---
Changelog | 2 +-
configure | 2 ++
libavcodec/Makefile| 1 +
libavcodec/hwaccels.h | 1 +
libavcodec/nvdec.c | 1 +
libavcodec/nvdec_vp8.c | 97 ++
libavcodec/version.h
On Sun, 26 Nov 2017 22:35:58 +
Mark Thompson wrote:
> On 26/11/17 22:04, Philip Langdale wrote:
> > Signed-off-by: Philip Langdale
> > ---
> > Changelog | 2 +-
> > configure | 2 ++
> > libavcodec/Makefile| 1 +
Now that we have a way to identify hardware backed decoders, let
us do so. I may have missed some.
Signed-off-by: Philip Langdale
---
libavcodec/crystalhd.c | 4 +++-
libavcodec/cuviddec.c | 4 +++-
libavcodec/mediacodecdec.c | 24 ++--
libavcodec/mmaldec.c
.
Philip Langdale (2):
avcodec: Add metadata to identify hardware backed codecs
avcodec: Add hardware metadata to hardware backed decoders
Changelog | 1 +
doc/APIchanges | 5 +
libavcodec/avcodec.h | 19 +++
libavcodec/crystalhd.c
provider).
Signed-off-by: Philip Langdale
---
Changelog| 1 +
doc/APIchanges | 5 +
libavcodec/avcodec.h | 19 +++
3 files changed, 25 insertions(+)
diff --git a/Changelog b/Changelog
index 76d6fad56b..a99edbf4b7 100644
--- a/Changelog
+++ b/Changelog
On Sun, 10 Dec 2017 14:14:30 +0100
Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol
> ---
> libavcodec/nvenc.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c
> index 4a91d99720..6ef51adaf0 100644
> --- a/libavcodec/nvenc.
On 2017-12-11 07:34, wm4 wrote:
On Mon, 27 Nov 2017 20:45:59 -0800
Philip Langdale wrote:
We have a number of hardware backed implementations in the codebase
that are done as full decoders instead of HWAccels for various
reasons. These decoders cannot be discovered today, and clients
which
fully, because it's
concerned with decoder configuration, not information about the fact
whether the hardware is used or not.
AV_CODEC_CAP_HYBRID exists specifically for QSV, which can have
software
implementations in case the hardware is not capable.
Based on a patch by Philip Langdale
On Wed, 30 Aug 2017 14:09:01 +0200
Clément Bœsch wrote:
> From: Clément Bœsch
>
> ---
> configure | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/configure b/configure
> index 44e45791c2..a9932aeba6 100755
> --- a/configure
> +++ b/configure
> @@ -1532,7 +1532,
On Wed, 30 Aug 2017 20:09:34 +0100
Mark Thompson wrote:
> ---
> """
> Cannot load libcuda.so.1
>
> Thread 1 "ffmpeg_g" received signal SIGSEGV, Segmentation fault.
> 0x5657cd59 in ff_nvenc_encode_close (avctx=0x578ed920) at
> src/libavcodec/nvenc.c:1337 1337cu_res =
> dl_fn->
On Sat, 2 Sep 2017 21:27:03 +0200
Timo Rothenpieler wrote:
> Signed-off-by: Timo Rothenpieler
> ---
> libavcodec/nvenc.c | 65
> -
> libavcodec/nvenc.h | 6 + libavcodec/nvenc_h264.c | 6 +
> libavcodec/nvenc_hevc.c | 4 +++
>
On Wed, 6 Sep 2017 18:14:17 +0200
Timo Rothenpieler wrote:
> >> +int ff_nvenc_receive_packet(AVCodecContext *avctx, AVPacket *pkt)
> >> +{
> >> +CUresult cu_res;
> >> +CUcontext dummy;
> >> +NvencSurface *tmpoutsurf;
> >
> > You can remove tmpoutsurf in ff_nvenc_send_frame
>
> B
On Tue, 3 Oct 2017 16:08:32 +0200
Timo Rothenpieler wrote:
> Am 03.10.2017 um 15:15 schrieb wm4:
> > From: Anton Khirnov
> >
> > Some parts of the code are based on a patch by
> > Timo Rothenpieler
> >
> > Merges Libav commit b9129ec4668c511e0a79e25c6f25d748cee172c9.
> >
> > As a complicatio
On Tue, 3 Oct 2017 15:15:17 +0200
wm4 wrote:
> Currently, AVHWAccels are looked up using a (codec_id, pixfmt) tuple.
> This means it's impossible to have 2 decoders for the same codec and
> using the same opaque hardware pixel format.
>
> This breaks merging Libav's CUVID hwaccel. FFmpeg has it
On Tue, 3 Oct 2017 15:15:16 +0200
wm4 wrote:
> cuvid.c is used by Libav's CUVID hwaccel. Resolve the conflict and
> avoid future merge problems by renaming our decoder.
> ---
> libavcodec/Makefile| 10 +-
> libavcodec/{cuvid.c => cuviddec.c} | 0
> 2 files changed, 5 in
On Tue, 3 Oct 2017 15:15:18 +0200
wm4 wrote:
> From: Anton Khirnov
>
> Some parts of the code are based on a patch by
> Timo Rothenpieler
>
> Merges Libav commit b9129ec4668c511e0a79e25c6f25d748cee172c9.
>
> As a complication, all the names conflict. Add a _hwaccel suffix to
> the merged co
On 2017-09-29 09:56, wm4 wrote:
On Fri, 29 Sep 2017 15:04:00 +
"Mironov, Mikhail" wrote:
I would like to understand better the nature of the concern. The
license is MIT. The paragraph in question is a notice, not limiting
the usage of the SDK.
I can definitely reduce number of headers. I
With all the various refactorings that have happened over the years,
the current pts logic is very broken for non-trivial cases (ie: ones
where not every frame/field has a meaningful pts assocated with it).
Generally, we do not want to write AV_NOPTS_VALUE as the output
timestamp, regardless of an
These changes should bring CrystalHD functionality back to where it was when
the decoder was originally completed. There are various interlaced edge cases
that remain problematic, and can probably only be addressed by switching to
the new m:n decode API - which I might do someday.
Philip Langdale
The hardware handling of packed bframes was always questionable but
it used to ok with my workaround. Today, not so much. But today we
have a bsf to unpack the bframes, so let's just use that and be
done with it.
---
libavcodec/crystalhd.c | 127 -
1
On Sun, 9 Oct 2016 10:50:11 -0700
Philip Langdale wrote:
> These changes should bring CrystalHD functionality back to where it
> was when the decoder was originally completed. There are various
> interlaced edge cases that remain problematic, and can probably only
> be addressed by
On Wed, 19 Oct 2016 14:00:29 +0200
Timo Rothenpieler wrote:
> ---
> compat/cuda/dynlink_cuda.h | 88 +
> compat/cuda/dynlink_cuviddec.h | 808
> +
> compat/cuda/dynlink_loader.h | 254 +
> compat/cuda/dynlink_nvcuvid.h | 316 +
Now that we don't need to do ridiculous things to work out if a
frame is interlaced or not, we don't need an extra h.264 parser.
Signed-off-by: Philip Langdale
---
libavcodec/crystalhd.c | 55 --
1 file changed, 4 insertions(+), 51
This was needed to detect an interlaced failure case that doesn't
happen with the new decode api.
Signed-off-by: Philip Langdale
---
libavcodec/crystalhd.c | 40
1 file changed, 40 deletions(-)
diff --git a/libavcodec/crystalhd.c b/libav
It's not possible to return EAGAIN when we've passed input EOF and are
in draining mode. If do return EAGAIN, we're saying there's no way to
get any more output - which isn't true in many cases.
So let's handled these cases in an internal loop as best we can.
do a tight loop in the decoder to get the second field
requires restoring some heuristics to avoid dead-locking when
additional input is required to get additional output.
Signed-off-by: Philip Langdale
---
libavcodec/crystalhd.c | 480 +
libavcodec
4:2:2) even if the luma is isn't.
Signed-off-by: Philip Langdale
---
libavcodec/crystalhd.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/libavcodec/crystalhd.c b/libavcodec/crystalhd.c
index 9120940..137ed20 100644
--- a/libavcodec/crystalhd.c
+++ b/libavcodec/crystalhd.c
The old code had to retain a partial frame across two calls in
the case of separate interlaced fields. Now, we know that we'll
get both fields within the same receive_frame call, and so we
don't need to manage the frame as private state any more.
Signed-off-by: Philip Langdale
---
It seems that without all the other 1:1 heuristics, we don't have
a fundamental problem trusting the interlaced flag on output
pictures. That's a relief.
Signed-off-by: Philip Langdale
---
libavcodec/crystalhd.c | 37 -
1 file changed, 4 inserti
We don't need to document the horrible hacks that we removed.
Signed-off-by: Philip Langdale
---
libavcodec/crystalhd.c | 38 +-
1 file changed, 5 insertions(+), 33 deletions(-)
diff --git a/libavcodec/crystalhd.c b/libavcodec/crystalhd.c
index 7c
up on that and went back to making the old hardware
based path work. Turns out that it wasn't broken except that some
samples have a 6 byte drop packet which I wasn't accounting for.
Now it works again and seeks are good.
Signed-off-by: Philip Langdale
---
libavcodec/c
x27;d gain nothing.
Philip Langdale (10):
crystalhd: Fix up the missing first sample
crystalhd: Switch to new decode API and remove the insanity
crystalhd: Revert back to letting hardware handle packed b-frames
crystalhd: Remove trust_interlaced heuristic
crystalhd: We don't need the
Signed-off-by: Philip Langdale
---
libavcodec/crystalhd.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/libavcodec/crystalhd.c b/libavcodec/crystalhd.c
index b68701a..4ac138c 100644
--- a/libavcodec/crystalhd.c
+++ b/libavcodec/crystalhd.c
@@ -848,8 +848,7 @@ static int
On Thu, 27 Oct 2016 16:01:42 +0200
Timo Rothenpieler wrote:
> >
> > breaks fate:
> >
> > ./configure && make -j12 fate-vsynth1-msmpeg4
> > ...
> > TESTvsynth1-msmpeg4
> > --- ./tests/ref/vsynth/vsynth1-msmpeg4 2016-10-27
> > 03:11:18.675647981 +0200 +++ tests/data/fate/vsynth1-msmpeg4
> >
On 2016-10-27 09:48, Nicolas George wrote:
Le sextidi 6 brumaire, an CCXXV, Philip Langdale a écrit :
the library spams stdout (which sucks, but what can you do)
First step, look if there is a clean way of fixing it from the outside.
Maybe by setting a logging callback? You probably already
On 2016-10-27 13:47, Hendrik Leppkes wrote:
On Thu, Oct 27, 2016 at 5:09 PM, Philip Langdale
wrote:
On Thu, 27 Oct 2016 16:01:42 +0200
Timo Rothenpieler wrote:
>
> breaks fate:
>
> ./configure && make -j12 fate-vsynth1-msmpeg4
> ...
> TESTvsynth1-msmpeg4
> -
This avoids it getting picked by default, which is generally
undesirable and can break test runs.
Signed-off-by: Philip Langdale
---
libavcodec/allcodecs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index b592aa3..594d104
On Sat, 29 Oct 2016 00:59:23 +0200
Andreas Cadhalpun wrote:
> On 28.10.2016 03:40, Philip Langdale wrote:
> > This avoids it getting picked by default, which is generally
> > undesirable and can break test runs.
> >
> > Signed-off-by: Philip Langdale
> > --
decode
such videos.
After this change, both cuvid and nvenc support P010, but the
ffmpeg_cuvid transcoding logic will need more work to connect the
two together. Similarly, the scale_npp filter still only works with
8bit surfaces.
Signed-off-by: Philip Langdale
---
compat/cuda/dynlink_cuviddec.h |
decode
such videos.
After this change, both cuvid and nvenc support P010, but the
ffmpeg_cuvid transcoding logic will need more work to connect the
two together. Similarly, the scale_npp filter still only works with
8bit surfaces.
Signed-off-by: Philip Langdale
---
compat/cuda/dynlink_cuviddec.h |
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sun, 20 Nov 2016 14:20:21 +0100
Michael Niedermayer wrote:
> On Sat, Nov 19, 2016 at 05:18:08PM -0800, Philip Langdale wrote:
> > The nvidia 375.xx driver introduces support for P016 output
> > surfaces, for 10bit and 12bit HEV
decode
such videos.
After this change, both cuvid and nvenc support P010, but the
ffmpeg_cuvid transcoding logic will need more work to connect the
two together. Similarly, the scale_npp filter still only works with
8bit surfaces.
Signed-off-by: Philip Langdale
---
compat/cuda/cuviddec.h |
P016 is the 16-bit variant of NV12 (planar luma, packed chroma), using
two bytes per component.
It may, and in fact is most likely to, be used in situations where
there are less than 16 bits of data. It is the responsibility of
the writer to zero out any unused LSBs.
Signed-off-by: Philip
On Sun, 20 Nov 2016 17:13:01 -0500
"Ronald S. Bultje" wrote:
> Hi,
>
> On Sun, Nov 20, 2016 at 4:59 PM, Philip Langdale
> wrote:
>
> > diff --git a/libavutil/pixfmt.h b/libavutil/pixfmt.h
> > index 96860ce..4cd3a77 100644
> > --- a/libavutil/pixfmt.h
It's pretty much P010 with the low 6 bits explicitly allowed to contain
data. I did not attempt to implement any fast path conversion for P010.
Someone could obviously add that if desired.
Philip Langdale (2):
avutil: add P016 pixel format
swscale: add P016 input support
libavutil/pixd
P016 is the 16-bit variant of NV12 (planar luma, packed chroma), using
two bytes per component.
It may, and in fact is most likely to, be used in situations where
there are less than 16 bits of data. It is the responsibility of
the writer to zero out any unused LSBs.
Signed-off-by: Philip
Signed-off-by: Philip Langdale
---
libswscale/input.c | 32
libswscale/utils.c | 2 ++
2 files changed, 34 insertions(+)
diff --git a/libswscale/input.c b/libswscale/input.c
index 1f4ea18..8b5f348 100644
--- a/libswscale/input.c
+++ b/libswscale/input.c
. For simplicity, it
does not maintain the previous ability to output NV12 for > 8 bit
input video - the user will need to update their driver to decode
such videos.
Signed-off-by: Philip Langdale
---
compat/cuda/dynlink_cuviddec.h | 3 ++-
libavcodec/cuvid.c
These changes allow cuvid to output P016 for 10/12bit content
and nvenc to accept it (treating it as P010). Additional work
will be required for transcoding, however.
Philip Langdale (2):
avcodec/cuvid: Add support for P016 as an output surface format
avcodec/nvenc: Accept P016 content
.
After this change, both cuvid and nvenc support P016, but the
ffmpeg_cuvid transcoding logic will need more work to connect the
two together. Similarly, the scale_npp filter still only works with
8bit surfaces.
Signed-off-by: Philip Langdale
---
libavcodec/nvenc.c | 3 +++
1 file changed, 3
P016 is the 16-bit variant of NV12 (planar luma, packed chroma), using
two bytes per component.
It may, and in fact is most likely to, be used in situations where
there are less than 16 bits of data. It is the responsibility of
the writer to zero out any unused LSBs.
Signed-off-by: Philip
It's pretty much P010 with the low 6 bits explicitly allowed to contain
data. I did not attempt to implement any fast path conversion for P010.
Someone could obviously add that if desired.
Updated to bump minor version
Philip Langdale (2):
avutil: add P016 pixel format
swscale: add
Signed-off-by: Philip Langdale
---
libswscale/input.c | 32
libswscale/utils.c | 2 ++
2 files changed, 34 insertions(+)
diff --git a/libswscale/input.c b/libswscale/input.c
index 1f4ea18..8b5f348 100644
--- a/libswscale/input.c
+++ b/libswscale/input.c
The latest nvidia drivers support P010/P016 output formats for 10/12bit
content.
Philip Langdale (2):
libavutil/hwcontext_cuda: Support P010 and P016 formats
avcodec/cuvid: Add support for P010/P016 as an output surface format
compat/cuda/dynlink_cuviddec.h | 3 +-
libavcodec/cuvid.c
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.
Signed-off-by: Philip Langdale
---
compat/cuda/dynlink_cuviddec.h | 3 +-
libavcodec/cuvid.c
CUVID is now capable of returning 10bit and 12bit decoded content
in P010/P016. Let's support transfering those formats.
Signed-off-by: Philip Langdale
---
libavutil/hwcontext_cuda.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/libavutil/hwcontext_cud
On Tue, 22 Nov 2016 08:27:46 -0800
Philip Langdale wrote:
> The latest nvidia drivers support P010/P016 output formats for
> 10/12bit content.
>
> Philip Langdale (2):
> libavutil/hwcontext_cuda: Support P010 and P016 formats
> avcodec/cuvid: Add support for P010/P016 as
This dubious behaviour in nvenc was finally removed by nvidia, and
as we refuse to run on anything older than 7.0, we don't need to
keep it around for old versions.
Signed-off-by: Philip Langdale
---
libavcodec/nvenc.c | 12
1 file changed, 12 deletions(-)
diff --git a/libav
until registration time, which is
actually how we handle other frame properties, such as dimensions.
By itself, this change doesn't allow for transcoding of 10bit
content from cuvid, but it reduces the problem to the hardcoding of
the sw format in ffmpeg_cuvid.c
Signed-off-by: Philip Langdale
---
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sat, 26 Nov 2016 23:55:17 +0100
Michael Niedermayer wrote:
> Hi all
>
> The machine on which the coverity stuff is is old, both hw and OS.
> the OS will no longer get security updates in a few months and the hw
> does not always boot and its swit
This should deal with some false positives, but might lead to
more of them depending on whether it realises that av_freep()
wraps av_free() or not.
Signed-off-by: Philip Langdale
---
tools/coverity.c | 28 +---
1 file changed, 25 insertions(+), 3 deletions(-)
diff --git
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sun, 27 Nov 2016 21:26:13 +0100
Michael Niedermayer wrote:
> On Sun, Nov 27, 2016 at 11:00:21AM -0800, Philip Langdale wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > On Sat, 26 Nov 2016
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
-BEGIN PGP SIGNATURE-
iEYEARECAAYFAlg7ZnwACgkQ+NaxlGp1aC7rHQCfeMtiAL4kPwIFd37da56aFtVY
eiEAn3Vh0A63CcNSu6MuGVuo8p5U/CJw
=eJcJ
-END PGP SIGNATURE-
___
ffmpeg-devel mailing list
ffmpeg-devel@f
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: P
I've been investigating using cuvid for interactive playback, and even without
using CUDA->OpenGL interop, it's quite usable. This series includes two major
items:
* Declare decoders for the other formats that cuvid supports
* Implement flushing so that seeks in a player will
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: P
ready
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
---
libavcodec/cuvid.c | 130 +
1 file changed, 91 insertions(+), 39 deletions(-)
di
check the internal error flag every time.
Signed-off-by: Philip Langdale
---
libavcodec/cuvid.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/libavcodec/cuvid.c b/libavcodec/cuvid.c
index de75960..19a7772 100644
--- a/libavcodec/cuvid.c
+++ b/libavcodec/cuvid.c
@@ -272
A couple of cuvid improvements
Philip Langdale (2):
cuvid: Fully re-initialize the parser after a flush.
cuvid: Check for non 420 chroma formats - they aren't supported
libavcodec/cuvid.c | 16
1 file changed, 16 insertions(+)
--
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
---
libavcodec/cuvid.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/libavcodec/cuvid.c b/libavcodec/cuvid.c
index 19
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
---
libavcodec/cuvid.c | 6
Although the old API is supposed to functional, the crystalhd
decoder is currently not working for non-annex.b h.264 content.
So, let's update to the modern API and make it work again.
Signed-off-by: Philip Langdale
---
libavcodec/crystalhd.c
Signed-off-by: Philip Langdale
---
compat/cuda/cuviddec.h | 844 +
compat/cuda/nvcuvid.h | 333 +++
2 files changed, 1177 insertions(+)
create mode 100644 compat/cuda/cuviddec.h
create mode 100644 compat/cuda/nvcuvid.h
diff --gi
We remove the dynlink fanciness with normal function prototypes and
update the include paths.
Signed-off-by: Philip Langdale
---
compat/cuda/cuviddec.h | 53 +-
compat/cuda/nvcuvid.h | 34 +++-
2 files changed, 29
Signed-off-by: Philip Langdale
---
libavcodec/cuvid.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/cuvid.c b/libavcodec/cuvid.c
index f2e92cf..7fd0b0d 100644
--- a/libavcodec/cuvid.c
+++ b/libavcodec/cuvid.c
@@ -30,7 +30,7 @@
#include "avcodec.h"
dynlink
system that's specific to the Video SDK samples, which we don't need and
don't really want.
Philip Langdale (3):
cuvid: Add MIT licenced nvcuid headers from Video SDK 7.0
cuvid: Modify cuvid headers to be usable
cuvid: Use the compat headers for nvcuvid
compat/cuda/c
On Wed, 21 Sep 2016 15:09:36 +1000
Matt Oliver wrote:
> On 21 September 2016 at 14:38, Philip Langdale
> wrote:
>
> > The cuvid header situation is a mess - the only feature-complete
> > headers are
> > in the Video SDK and not in the cuda header collection. The h
We don't need to explicitly check for PICPARMS now - they're going
to be there.
Signed-off-by: Philip Langdale
---
configure | 51 ++-
1 file changed, 22 insertions(+), 29 deletions(-)
diff --git a/configure b/configure
index af3fbf
On Sun, 18 Sep 2016 12:43:25 -0700
Philip Langdale wrote:
> Although the old API is supposed to functional, the crystalhd
> decoder is currently not working for non-annex.b h.264 content.
>
> So, let's update to the modern API and make it work again.
>
> Signed-
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.
Signed-off-by: Philip Langd
On Tue, 27 Sep 2016 19:23:20 -0700
Sasi Inguva wrote:
> Signed-off-by: Sasi Inguva
> ---
> libavcodec/movtextdec.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/libavcodec/movtextdec.c b/libavcodec/movtextdec.c
> index abf8711..a33fff7 100644
> --- a/libavcodec/movtextdec.c
> ++
On Sun, 2 Oct 2016 18:58:13 +0200
Timo Rothenpieler wrote:
> ---
> MAINTAINERS | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index d1e487a..3570253 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -78,6 +78,7 @@ Other:
>eval.c, eval.h
On Sun, 2 Oct 2016 18:58:12 +0200
Timo Rothenpieler wrote:
> ---
> libavutil/hwcontext_cuda.c | 43
> --- 1 file changed, 28
> insertions(+), 15 deletions(-)
>
> diff --git a/libavutil/hwcontext_cuda.c b/libavutil/hwcontext_cuda.c
> index 40d2971..706d195
From: Philip Langdale
Signed-off-by: Philip Langdale
---
Changelog | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Changelog b/Changelog
index c528804..93fa6b3 100644
--- a/Changelog
+++ b/Changelog
@@ -21,6 +21,8 @@ version :
- hysteresis filter
- lut2 filter
- yuvtestsrc filter
On Wed, 5 Oct 2016 13:09:06 +0200
Carl Eugen Hoyos wrote:
> 2016-10-05 5:56 GMT+02:00 Philip Langdale :
> > From: Philip Langdale
> >
> > Signed-off-by: Philip Langdale
> > ---
> > Changelog | 3 +++
> > 1 file changed, 3 insertions(+)
>
> Plea
On 2016-06-08 21:54, Mark Thompson wrote:
On 08/06/16 13:59, Carl Eugen Hoyos wrote:
Mark Thompson jkqxz.net> writes:
Uses the global -hwaccel_lax_profile_check option (may be
misnamed for this purpose, but it has the right spirit).
Iirc, all old x264 files have a very high profile set (5.0
On Mon, 2 Jan 2017 00:56:18 -0700
Pavel Koshevoy wrote:
> On Sun, Jan 1, 2017 at 6:00 PM, wrote:
> > From: Pavel Koshevoy
> >
> > NVDEC (CUVID) does not support unlimited video resolutions, so if
> > the resolution of the source is known it can be used during
> > avcodec_open2 call to fail ear
On Mon, 16 Jan 2017 16:44:16 +0100
wm4 wrote:
> Copied and modified from hwcontext_qsv.c.
> ---
> libavutil/hwcontext_cuda.c | 26 ++
> 1 file changed, 26 insertions(+)
>
> diff --git a/libavutil/hwcontext_cuda.c b/libavutil/hwcontext_cuda.c
> index 5dd0d99272..ed595c3e0
On Mon, 16 Jan 2017 18:56:09 +0100
wm4 wrote:
> On Mon, 16 Jan 2017 09:31:42 -0800
> Philip Langdale wrote:
>
> > On Mon, 16 Jan 2017 16:44:16 +0100
> > wm4 wrote:
> >
> > > Copied and modified from hwcontext_qsv.c.
> > &g
On Sat, 21 Jan 2017 10:27:30 -0700
pkoshe...@gmail.com wrote:
> From: Pavel Koshevoy
>
> Evidently CUVID doesn't support decoding 422 or 444 chroma formats,
> and only a limited set of resolutions per codec are supported.
>
> Unfortunately CUVID silently drops packets for video of unsupported
>
On Sun, 22 Jan 2017 12:12:26 -0700
Pavel Koshevoy wrote:
> Yeah, but I don't even get a 1st frame failure with YUV420P 8K from
> h264_cuvid -- all I ever get is a 0 from avcodec_send_packet and
> AVERROR(EAGAIN) from avcodec_receive_frame. This is what I've
> observed with GeForce GT 730 and G
Signed-off-by: Philip Langdale
---
libswscale/input.c| 32
libswscale/swscale_unscaled.c | 4 +++-
libswscale/utils.c| 2 ++
3 files changed, 37 insertions(+), 1 deletion(-)
diff --git a/libswscale/input.c b/libswscale/input.c
index
201 - 300 of 620 matches
Mail list logo
