On 2017-01-31 07:45, wm4 wrote:
On Tue, 31 Jan 2017 15:38:33 +
Sumit Agarwal wrote:
From 0d6be9eebacc4403ecd7677e89c3205892b8809b Mon Sep 17 00:00:00 2001
From: sumit
Date: Tue, 31 Jan 2017 21:00:50 +0530
Subject: [PATCH] Add 420 10-bit transcode support for hwaccel cuvid
---
ffmpeg_cuv
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, 31 Jan 2017 14:43:24 +0100
Michael Niedermayer wrote:
> On Sun, Jan 29, 2017 at 01:11:51PM -0800, Philip Langdale wrote:
> > Signed-off-by: Philip Langdale
> > ---
> > libswscale/in
We have been pretending that the nvenc YUV444P10 format is our
YUV444P16 format, and this is not a good idea. It leads to us
failing to dither >10bit content when transcoding and also
results in encoded files with 4:4:4 sampling which are almost
certainly not what the user wants.
Philip Langd
Now that we have an accurate pixfmt available, let's use it for
the format mapping in nvenc and stop pretending we support > 10bit.
Signed-off-by: Philip Langdale
---
libavcodec/nvenc.c | 8
libavcodec/version.h | 2 +-
2 files changed, 5 insertions(+), 5 deletions(-)
diff
code.
In the mean time, common 12 bit content (YUV420P12 or P016) will be
correctly converted to P010 for nvenc.
Signed-off-by: Philip Langdale
---
libavutil/pixdesc.c | 24
libavutil/pixfmt.h | 5 +
libavutil/version.h | 2 +-
3 files changed, 30 insertions(+),
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 2 Feb 2017 12:08:59 +0100
Michael Niedermayer wrote:
> On Thu, Feb 02, 2017 at 11:48:49AM +0100, Michael Niedermayer wrote:
> > On Thu, Feb 02, 2017 at 11:26:26AM +0100, Timo Rothenpieler wrote:
> > > >> In the mean time, common 12 bit cont
On 2017-02-02 08:26, wm4 wrote:
Does supporting the nvenc 4:4:4 format even have any advantage? Does it
support encoding something non-4:2:0? If not, then the first option is
probably preferable for now.
With sufficiently new hardware it does. It will output h.264 or hevc
with 4:4:4 by default
On 2017-02-02 00:15, Carl Eugen Hoyos wrote:
2017-02-01 23:54 GMT+01:00 Philip Langdale :
We have been pretending that the nvenc YUV444P10 format is our
YUV444P16 format, and this is not a good idea. It leads to us
failing to dither >10bit content when transcoding
Could you provide samp
On Sun, 12 Feb 2017 22:43:41 +0100
Miroslav Slugeň wrote:
> Dne 12.2.2017 v 22:31 Timo Rothenpieler napsal(a):
> > On 2/12/2017 10:25 PM, Miroslav Slugeň wrote:
> >> This patch is for discussion only, not ready to commit yet and
> >> maybe newer will be.
> >>
> >> NVENC in current CUDA 8 SDK is
On Mon, 13 Feb 2017 08:52:34 +0100
Miroslav Slugeň wrote:
> Dne 12.2.2017 v 23:20 Philip Langdale napsal(a):
> > On Sun, 12 Feb 2017 22:43:41 +0100
> > Miroslav Slugeň wrote:
> >
> >> Dne 12.2.2017 v 22:31 Timo Rothenpieler napsal(a):
> >>> On
On Mon, 13 Feb 2017 07:21:51 -0800
Philip Langdale wrote:
> On Mon, 13 Feb 2017 08:52:34 +0100
> Miroslav Slugeň wrote:
>
> > >
> > I am using current STABLE drivers 375.26, because BETA drivers
> > 378.09 caused some crashes while encoding on NVENC.
> >
On 2017-02-13 08:33, Miroslav Slugeň wrote:
I am sure that i know what is going on, NVENC is inserting wrong SPS
VUI aspect_ratio_idc to h264 packets when you encode at resolution
720x576 and 720x480
AR 16:9 will insert aspect_ratio_idc=4 but it should be
aspect_ratio_idc=255, sar_width=64, sar_
On Tue, 14 Feb 2017 12:32:07 +
Yogender Gupta wrote:
> Hi Miroslav , Philip,
>
> We will look at this issue, and provide a fix for the same. Would be
> great to send me and Sumit (also copied here) the command lines that
> you tried and the observations to repro at our end.
Here's the sampl
On Tue, 28 Feb 2017 05:44:04 +
Konda Raju wrote:
> Hi,
>
> The attached patch adds initial qp value options for I, P and B
> frames.
>
> -Raju Konda
>
> ---
> This email message is for the sole use of the inten
On Tue, 28 Feb 2017 11:54:32 +0100
Miroslav Slugeň wrote:
> Dne 28.2.2017 v 10:44 Timo Rothenpieler napsal(a):
> > Am 28.02.2017 um 01:24 schrieb Ganapathy Raman Kasi:
> >> Can someone please help review patch. Thanks.
> > I have seen an marked it, but I don't have time to review and test
> >
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 1 Mar 2017 11:58:39 +0100
Timo Rothenpieler wrote:
> >> We recently just had all sorts of discussions what decoders should
> >> and should not do, I don't think scaling in a decoder is a good
> >> thing to start doing here.
> >
> > scaling
On 2017-03-13 07:28, wal...@free.fr wrote:
The crystalhd video decoder was not updated to the commit:
af9cac1be1750ecc0e12c6788a3aeed1f1a778be changes and so is broken.
Is there someone trying to upgrade the crystalhd code? This device is
old, but is still useful. I hope I'm not the only one usi
On Tue, 14 Mar 2017 02:49:27 +0100 (CET)
wal...@free.fr wrote:
> Indeed 7447ec91b5a692121b81a04c6501a5811d867775 is working; But I
> have the following errors with the last ffmpeg git state:
> [h264_crystalhd @ 0x7fda3c060500] This decoder requires using the
> avcodec_send_packet() API. Last messa
On Mon, 13 Mar 2017 19:39:35 -0700
Philip Langdale wrote:
> On Tue, 14 Mar 2017 02:49:27 +0100 (CET)
> wal...@free.fr wrote:
>
> > Indeed 7447ec91b5a692121b81a04c6501a5811d867775 is working; But I
> > have the following errors with the last ffmpeg git state:
> > [h264
#x27;s the whole point of the API. Your implementation still assumes
you have a 1:1 relationship - which is true for software decoders but
not for hardware and definitely not for crystalhd.
You could look at the mpv implementation of this for guidance.
>
> - Mail original -
> De:
On Wed, 15 Mar 2017 10:09:17 +0100 (CET)
wal...@free.fr wrote:
> In the meantime, I have updated the CrystalHD kernel driver to linux
> 4.9.y: https://github.com/wallak/crystalhd
>
> Wallak.
I've been sending updates to: https://github.com/dbason/crystalhd
--phil
___
On Sat, 18 Mar 2017 01:51:39 +0100 (CET)
Marton Balint wrote:
> On Sat, 18 Mar 2017, wal...@free.fr wrote:
>
> > The logs: http://pastebin.com/1duYR0Ui
> >
>
> Log with video only (run ffplay with -an -sn) might show it more
> clearly, but even from the logs above it looks like the CrystalHD
utput format.
Signed-off-by: Philip Langdale
---
ffmpeg.h | 1 +
ffmpeg_opt.c | 29 ++---
2 files changed, 23 insertions(+), 7 deletions(-)
diff --git a/ffmpeg.h b/ffmpeg.h
index fa81427471..1a0aec5862 100644
--- a/ffmpeg.h
+++ b/ffmpeg.h
@@ -76,6 +76,7 @@ typedef s
full transcoding with an additional command line argument, so force
them to specify that argument.
Philip Langdale (2):
ffmpeg: Switch cuvid to generic hwaccel
ffmpeg: Require output format when using cuvid hwaccel
Makefile | 1 -
ffmpeg.h | 2 +-
ffmpeg_cuvid.c | 73
-c:v h264_nvenc -f rawvideo /dev/null
Signed-off-by: Philip Langdale
---
Makefile | 1 -
ffmpeg.h | 1 -
ffmpeg_cuvid.c | 73 --
ffmpeg_opt.c | 4 ++--
4 files changed, 2 insertions(+), 77 deletions(-)
delete mode 1
On Sun, 25 Jun 2017 12:43:12 +0100
Mark Thompson wrote:
> Point (2) is somewhat more subtle. The default hwaccel behaviour is
> made for the real hwaccels attached to the normal decoder, and won't
> do the right thing for the dummy ones. The specific case that we
> strongly want to avoid is som
On Sat, 24 Jun 2017 21:42:23 -0400
"Ronald S. Bultje" wrote:
> Hi Philip,
>
> On Sat, Jun 24, 2017 at 7:40 PM, Philip Langdale
> wrote:
>
> > Feedback on first proposal was lack of interest in having default
> > behaviour vary between hwaccels, despite
re
dealing with.
Signed-off-by: Philip Langdale
---
ffmpeg.c | 2 +-
ffmpeg.h | 15 +++
ffmpeg_dxva2.c| 2 +-
ffmpeg_hw.c | 5 -
ffmpeg_opt.c | 21 ++---
ffmpeg_qsv.c | 2 +-
ffmpeg_videotoolbox.c | 2 +-
had before generic hwaccel.
Philip Langdale (2):
ffmpeg: Switch cuvid to generic hwaccel
ffmpeg: Set default output format for dummy hwaccels
Makefile | 1 -
ffmpeg.c | 2 +-
ffmpeg.h | 16 +++
ffmpeg_cuvid.c
-c:v h264_nvenc -f rawvideo /dev/null
Signed-off-by: Philip Langdale
---
Makefile | 1 -
ffmpeg.h | 1 -
ffmpeg_cuvid.c | 73 --
ffmpeg_opt.c | 4 ++--
4 files changed, 2 insertions(+), 77 deletions(-)
delete mode 1
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, 26 Jun 2017 21:19:28 +0200
Michael Niedermayer wrote:
> On Sun, Jun 25, 2017 at 02:27:06PM -0700, Philip Langdale wrote:
> > Dummy hwaccels, of which cuvid is the best example, behave
> > differently from real hwaccels. In t
On Sat, 1 Jul 2017 11:40:38 +0200
wm4 wrote:
> NVIDIA broke its own API when using VDPAU decoding. If you retrieve
> the decoded YUV data, or if you map the surfaces with GL interop, the
> result are interlacing artifacts. The only way to get non-broken data
> is by using the vdpau video mixer t
On 2017-07-14 08:19, Yogender Gupta wrote:
Please help to understand what is broken with a command line, so that
we can address this issue.
This is the issue that the hevc low level decoder outputs frames instead
of fields - which all the other decoders do.
Originally, the vdpau support didn't
On 2017-07-25 12:20, Yogender Gupta wrote:
Can someone else push these patches to GIT.
Regards,
Yogender
-Original Message-
From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
Of Timo Rothenpieler
Sent: Tuesday, July 18, 2017 5:16 PM
To: ffmpeg-devel@ffmpeg.org
Subject
On 2017-07-25 09:41, Yogender Gupta wrote:
Currently combining CPU and CUDA filters requires insertion of
hwupload and download filters. I am trying to simply this by auto
insertion of these filters. This patch is for hwupload_cuda, but I
want to do this for hwdownload as well.
The attached patc
On 2017-07-25 08:33, Yogender Gupta wrote:
I can push, but to answer Timo's question: I did not add P016 to
nvenc because it is technically not correct to pass 12bit content
through a 10bit surface - that will lead to truncation, rather than
dithering. If you are telling us that nvenc supports
On 2017-07-28 11:51, 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 a80f9cb2eb..a2ad72f7f4 100755
--- a/configure
+++ b/configure
@@ -1529,7 +1529,6 @@ EXTERNAL_LIBRARY_LIST="
$E
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 19 Jul 2017 17:46:30 +0200
Michael Niedermayer wrote:
> On Tue, Jul 18, 2017 at 10:34:20AM +, Yogender Gupta wrote:
> > Added 10/16bit formats to hwupload_cuda.
> >
> > Thanks,
> > Yogender
> >
> > --
On Wed, 26 Jul 2017 09:14:04 +
Philip Langdale wrote:
> On 2017-07-25 08:33, Yogender Gupta wrote:
> >>> I can push, but to answer Timo's question: I did not add P016 to
> >>> nvenc because it is technically not correct to pass 12bit content
> >>&
On Fri, 28 Jul 2017 11:59:13 +
Philip Langdale wrote:
> On 2017-07-28 11:51, Clément Bœsch wrote:
> > From: Clément Bœsch
> >
> > ---
> > configure | 7 ---
> > 1 file changed, 4 insertions(+), 3 deletions(-)
> >
> > diff --git a/configure
On Tue, 8 Aug 2017 05:15:52 +
Manoj Bonda wrote:
> Hi ,
>
> HEVC issue for read-back API has been fixed and will be part of the
> upcoming drivers. Please help us understand the issue with the open
> gl interop. As per our understanding we are mapping the video surface
> to gl using the gl-
On Sat, 24 Mar 2018 15:48:36 +0100
wm4 wrote:
> Subtitles which contained styled UTF-8 subtitles (i.e. not just 7 bit
> ASCII characters) were not handled correctly. The spec mandates that
> styling start/end ranges are in "characters". It's not quite clear
> what a "character" is supposed to be,
On Sat, 24 Mar 2018 13:43:21 +0100
wm4 wrote:
> This is for applications which want to explicitly check for invalid
> UTF-8 manually, and take actions that are better than dropping invalid
> subtitles silently. (It's pretty much silent because sporadic avcodec
> error messages are so common that
See the earlier fix for movtextdec for details. The equivalent bug is
present on the encoder side as well.
We need to track the text length in 'characters' (which seems to really
mean codepoints) to ensure that styles are applied across the correct
ranges.
Signed-off-by: Phili
See the earlier fix for movtextdec for details. The equivalent bug is
present on the encoder side as well.
We need to track the text length in 'characters' (which seems to really
mean codepoints) to ensure that styles are applied across the correct
ranges.
Signed-off-by: Phili
On Wed, 28 Mar 2018 12:01:47 +0200
wm4 wrote:
>
> LGTM.
>
> Maybe a later patch that adds the UTF-8 length as lavu function (or
> macro for SPEEED?) eould be nice, since we seem to need that often.
I can do that.
Although, I'm not sure the SPEEED version is readable enough to justify
using it
On Wed, 28 Mar 2018 13:14:57 +0200
wm4 wrote:
> On Wed, 28 Mar 2018 14:02:04 +0300
> Andrey Turkin wrote:
>
> > I think first check (ascii case) should be explicit bit-test, or
> > (if there is some reason to use sign-bit approach) at least "c"
> > should be signed char instead of simply char.
On Sun, 8 Apr 2018 03:29:44 +0200
Michael Niedermayer wrote:
> Limits based on 3GPP TS 26.245 V14.0.0
> Fixes: Timeout
> Fixes:
> 6377/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MOVTEXT_fuzzer-5175929115508736
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/
On Wed, 11 Apr 2018 13:48:59 +0200
t...@rothenpieler.org wrote:
> From: Timo Rothenpieler
>
> ---
> libavcodec/hevc_ps.c| 5 ++---
> libavcodec/hevc_ps.h| 1 +
> libavcodec/nvdec_hevc.c | 6 ++
> 3 files changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/libavcodec/hevc_ps.c
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 26 Apr 2018 17:09:14 +0200
Daniel Oberhoff wrote:
> > On 26. Apr 2018, at 16:20, Daniel Oberhoff
> > wrote:
> >
> > ---
> > include/ffnvcodec/dynlink_cuda.h | 8
> > 1 file changed, 8 insertions(+)
> >
> > diff --git a/include/ffnv
On 2018-04-30 08:20, Daniel Oberhoff wrote:
On 30. Apr 2018, at 15:52, Daniel Oberhoff
wrote:
Hello All,
I am fighting since a few days to get the frames from the cuvid
decoder using the cuda pixel format transfered to opengl.
What i have done is create textures on gl using glGenTextures a
On 2018-05-07 11:39, Timo Rothenpieler wrote:
---
doc/APIchanges| 3 +++
libavutil/hwcontext.h | 7 +++
libavutil/version.h | 2 +-
3 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index ede5b186ae..307c7a51ee 100644
--- a/doc/APIchange
On Fri, 26 Jan 2018 20:18:30 +0100
Timo Rothenpieler wrote:
> If some logic like vsync in ffmpeg.c duplicates frames, it might pass
> the same frame twice, which will result in a crash due it being
> effectively mapped and unmapped twice.
>
> Signed-off-by: Timo Rothenpieler
> ---
> libavcodec
/nvdec_mjpeg.c b/libavcodec/nvdec_mjpeg.c
new file mode 100644
index 00..7e404246ce
--- /dev/null
+++ b/libavcodec/nvdec_mjpeg.c
@@ -0,0 +1,86 @@
+/*
+ * MJPEG HW decode acceleration through NVDEC
+ *
+ * Copyright (c) 2017 Philip Langdale
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg
ocked merging.
However, nvdec support doesn't require any remapping of YUVJ, so there's no
need for the hack, and hopefully no blocker for merging.
I have not included the other patches from Mark's original set as they are
also not required for nvdec.
Mark Thompson (1):
mjpegdec: Add h
From: Mark Thompson
Also adds some extra fields to the main context structure that may
be needed by a hwaccel decoder.
(Modified by philipl to remove a YUVJ mapping hack that isn't required
by nvdec and would otherwise block merging the rest of the change.)
---
libavcodec/mjpegdec.c | 68 +
---
libavcodec/mjpegdec.c | 6 --
libavcodec/mjpegdec.h | 5 +++--
2 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
index 9a7a329b19..b41d2ce467 100644
--- a/libavcodec/mjpegdec.c
+++ b/libavcodec/mjpegdec.c
@@ -715,8 +715,8 @@ unk_pi
to be done from an AVFrame,
and it seems conceptually undesirable to set the link colour range on
that basis. The one possible reason to handle this is if if the input
is not a decoder and so the color range would come from codecpar. If
so, it could be handled as a separate change.
Signed-off-by: P
(or modify it, as
some filters will do).
Based on existing properties of this type, this change adds a
link property and ways to set it from a buffer source and get it
from a buffer sink.
Signed-off-by: Philip Langdale
---
libavfilter/avfilter.c | 2 ++
libavfilter/avfilter.h | 1
In preparation for introducing Colour Range as a buffersrc parameter,
we need an option type to pass it. This probably seems like overkill
for an enum with two valid values, but even then you need to do
string parsing so you might as well get it right.
Signed-off-by: Philip Langdale
late the colour range, and finally, we get 'ffmpeg'
to get and set the range appropriately.
After this change, it is now possible to, for example. transcode
full range mjpeg to h.264, correctly, either by retaining the range,
or by compressing the range using a filter.
Philip Langda
Certain filters set or modify the output colour range. Today, they
do that per-frame, but now that we have a link property, they need
to set that as well.
Signed-off-by: Philip Langdale
---
libavfilter/avf_showcqt.c | 1 +
libavfilter/avf_showspectrum.c | 1 +
libavfilter/vf_colorspace.c
On Mon, 19 Feb 2018 23:28:43 +
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 ++
> l
On Mon, 19 Feb 2018 23:28:44 +
Mark Thompson wrote:
> Also adds some extra fields to the main context structure that may
> be needed by a hwaccel decoder.
> ---
> YUVJ hacks are removed, they will be handled in API-specific code.
>
>
> libavcodec/mjpegdec.c | 74
> +
On Mon, 19 Feb 2018 23:28:49 +
Mark Thompson wrote:
> From: Philip Langdale
>
> ---
> Changelog| 2 +-
> configure| 2 ++
> libavcodec/Makefile | 1 +
> libavcodec/hwaccels.h| 1 +
> libavcodec/mjpegdec.c| 6 ++
On Mon, 19 Feb 2018 23:28:45 +
Mark Thompson wrote:
> Adds YUV 4:1:1, 4:4:0 and 4:4:4 - these will be needed for JPEG
> decoding. ---
> libavutil/hwcontext_vaapi.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
> index 2
On Mon, 19 Feb 2018 23:28:46 +
Mark Thompson wrote:
> ---
> libavutil/hwcontext_vaapi.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
> index 68f88ecd6b..af9a136ef0 100644
> --- a/libavutil/hwcontext_va
On Mon, 19 Feb 2018 23:28:47 +
Mark Thompson wrote:
> Examine the supported fourcc list manually and make the best choice,
> then use the external attribute on the frames context to force that
> fourcc. ---
> libavcodec/vaapi_decode.c | 152
> +++---
>
is now possible to correctly pass the colour
range through a pipeline so that it it influences encoder behaviour,
and is recorded in the container, where relevant.
Philip Langdale (3):
avfilter: Add support for colour range as a link parameter
avfilter: Set output link colour range where
(or modify it, as
some filters will do).
Based on existing properties of this type, this change adds a
link property and ways to set it from a buffer source and get it
from a buffer sink.
Signed-off-by: Philip Langdale
---
doc/APIchanges | 5 +
libavfilter/avfilter.c | 2
to be done from an AVFrame,
and it seems conceptually undesirable to set the link colour range on
that basis. The one possible reason to handle this is if if the input
is not a decoder and so the color range would come from codecpar. If
so, it could be handled as a separate change.
Signed-off-by: P
Certain filters set or modify the output colour range. Today, they
do that per-frame, but now that we have a link property, they need
to set that as well.
Signed-off-by: Philip Langdale
---
libavfilter/avf_showcqt.c | 1 +
libavfilter/avf_showspectrum.c | 1 +
libavfilter/version.h
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 21 Feb 2018 23:37:57 +0100
Nicolas George wrote:
> Philip Langdale (2018-02-21):
> > As part of achieving our YUVJ-free future, it needs to be possible
> > to pass the colour range property from a decoder context to an
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 22 Feb 2018 12:39:16 +0100
Nicolas George wrote:
> Philip Langdale (2018-02-21):
> > Negotiation is part of Paul's larger changeset, and will be a useful
> > feature. My change is still a strict improvement over the curr
On 2018-02-22 08:06, wm4 wrote:
To be honest, I think we _could_ initialize the encoder AVCodecContext
color_range field from the first AVFrame. AFAIK we wait with encoder
initialization anyway until the first frame is filtered.
True enough, but we do have all these src/link/sink properties fo
---
libavcodec/hevcdec.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
index fc4eb781dc..c8877626d2 100644
--- a/libavcodec/hevcdec.c
+++ b/libavcodec/hevcdec.c
@@ -404,6 +404,11 @@ static enum AVPixelFormat get_format(HEVCContext *s, const
H
re
hardware pipeline, and that can't be done if nvenc doesn't say it
accepts P016. By mapping it to P010, we can use it, albeit with
truncation. I have established that swscale doesn't know how to
dither to 10bits so we'd get truncation anyway, even if we tried
to
, and avoids the current problem where yuv420p12 input is
preferrentially converted to yuv444p16 before being passed to nvenc.
Philip Langdale (3):
avcodec/hevcdec: Declare that nvdec supports 12bit decoding
swscale: Add p016 output support and generalise yuv420p1x to p010
avcodec/nvenc: De
To make the best use of existing code, I generalised the wrapper
that currently does yuv420p10 to p010 to support any mixture of
input and output sizes between 10 and 16 bits. This had the side
effect of yielding a working code path for all yuv420p1x formats
to p01x.
Signed-off-by: Philip
Signed-off-by: Philip Langdale
---
libavcodec/hevcdec.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
index fc4eb781dc..c8877626d2 100644
--- a/libavcodec/hevcdec.c
+++ b/libavcodec/hevcdec.c
@@ -404,6 +404,11 @@ static enum AVPixelFormat
This cleans up the ever-more-unreadable list of semi-planar
exclusions for selecting the planar copy wrapper.
---
libswscale/swscale_internal.h | 7 +++
libswscale/swscale_unscaled.c | 7 +--
2 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/libswscale/swscale_internal.h b/lib
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sat, 3 Mar 2018 00:55:25 +0100
Michael Niedermayer wrote:
> On Thu, Mar 01, 2018 at 08:26:52PM -0800, Philip Langdale wrote:
> > To make the best use of existing code, I generalised the wrapper
> > that currently does yuv420p10 to
On Fri, 2 Mar 2018 11:14:21 +0100
Timo Rothenpieler wrote:
>
> It's definitely better than the current situation, and I can't think
> of a scenario where it breaks something that's not already broken.
> So LGTM from me.
>
> The other patches also look sensible to me, but I'm not the one to Ok
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sat, 3 Mar 2018 23:21:51 +0100
Michael Niedermayer wrote:
> On Fri, Mar 02, 2018 at 03:40:39PM -0800, Philip Langdale wrote:
> > This cleans up the ever-more-unreadable list of semi-planar
> > exclusions for selecting the plan
On Sat, 3 Mar 2018 22:39:45 +0100
Timo Rothenpieler wrote:
> Right now, if someone configures ffmpeg with for example
> --enable-nvenc they will get an error message complaining about
> missing cuda. This is very confusing and already has lead people into
> installing the CUDA SDK, even though i
On Thu, 8 Oct 2020 11:48:51 +0530
ManojGuptaBonda wrote:
> Added VDPAU to list of supported formats for VP9 420 10 and 12 bit
> formats. Add VP9 10/12 Bit support for VDPAU
> ---
> libavcodec/vp9.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/libavcodec/vp9.c b/libavcodec/vp9.
da.c
new file mode 100644
index 00..7651a869d5
--- /dev/null
+++ b/libavfilter/vf_bwdif_cuda.c
@@ -0,0 +1,394 @@
+/*
+ * Copyright (C) 2018 Philip Langdale
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the
On Sun, 11 Oct 2020 18:36:42 +0200
Thomas Mundt wrote:
> Hi Philip,
>
> Am Fr., 9. Okt. 2020 um 18:33 Uhr schrieb Philip Langdale
> >:
>
> > I've been sitting on this for a couple of years now, and I figured I
> > should just send it out. This is what I be
On Sat, 17 Oct 2020 20:22:38 +0200
Andreas Rheinhardt wrote:
> If allocating fonts fails when reading the header, all fonts are
> freed, yet the counter of fonts is not reset and no error is
> returned; when subtitles are decoded lateron, the inexistent list of
> fonts is searched for the matchin
On Sat, 17 Oct 2020 09:37:38 +0200
Andreas Rheinhardt wrote:
> Background colour was never initialized if no style was available.
> Use a sane default of zero (i.e. completely transparent).
>
> Fixes Coverity issue #1461471.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> No change for this patc
have a smaller penalty than having greater than
needed chroma resolution.
v5: Update fate reference.
Signed-off-by: Philip Langdale
---
libavutil/pixdesc.c | 31 +++-
libavutil/pixdesc.h | 15 ++--
libavutil/tests/pixfmt_best.c | 129 +++
On Sat, 17 Sep 2022 21:13:37 +0200
Michael Niedermayer wrote:
> > ---
> > libavutil/pixdesc.c | 31 +++-
> > libavutil/pixdesc.h | 15 ++--
> > libavutil/tests/pixfmt_best.c | 129
> > +- tests/ref/fate/pixfmt_best|
> > 2 +- 4 files c
On Tue, 18 Oct 2022 15:31:21 +0200
Andreas Rheinhardt wrote:
> This file is built iff said hwaccel is enabled.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/nvdec_mjpeg.c | 4
> 1 file changed, 4 deletions(-)
>
> diff --git a/libavcodec/nvdec_mjpeg.c b/libavcodec/nvdec_mjpeg.c
On Sat, 29 Oct 2022 19:12:44 +0200
Timo Rothenpieler wrote:
> ---
> configure | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/configure b/configure
> index 70c9e41dcc..30f0ce4e26 100755
> --- a/configure
> +++ b/configure
> @@ -6757,7 +6757,8 @@ enabled mmal
On Fri, 4 Nov 2022 12:40:16 +0100
Timo Rothenpieler wrote:
> The encoder seems to be trading blows with hevc_nvenc.
> In terms of quality at low bitrate cbr settings, it seems to
> outperform it even. It produces fewer artifacts and the ones it
> does produce are less jarring to my perception.
>
t, as the channels are all bit-aligned inside a 32bit word.
Signed-off-by: Philip Langdale
---
libavutil/pixdesc.c | 70 -
1 file changed, 50 insertions(+), 20 deletions(-)
diff --git a/libavutil/pixdesc.c b/libavutil/pixdesc.c
index ca3e204a0b..62a
On Mon, 5 Dec 2022 23:25:58 +0100
Timo Rothenpieler wrote:
> ---
> doc/APIchanges | 3 +++
> libavcodec/avcodec.h | 11 +++
> libavcodec/options_table.h | 1 +
> libavcodec/version.h | 2 +-
> 4 files changed, 16 insertions(+), 1 deletion(-)
>
> diff --git a/
On Mon, 5 Dec 2022 23:25:59 +0100
Timo Rothenpieler wrote:
> ---
> libavcodec/nvdec.c | 13 +++--
> 1 file changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/nvdec.c b/libavcodec/nvdec.c
> index fbaedf0b6b..76ee395734 100644
> --- a/libavcodec/nvdec.c
> +++ b/libavco
On Fri, 9 Dec 2022 15:16:16 +0100
Timo Rothenpieler wrote:
> ---
> doc/APIchanges | 3 +++
> libavcodec/avcodec.h | 16
> libavcodec/options_table.h | 1 +
> libavcodec/version.h | 4 ++--
> 4 files changed, 22 insertions(+), 2 deletions(-)
>
> diff
On Fri, 9 Dec 2022 15:16:17 +0100
Timo Rothenpieler wrote:
> ---
> libavcodec/nvdec.c | 13 +++--
> 1 file changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/nvdec.c b/libavcodec/nvdec.c
> index fbaedf0b6b..a477449d14 100644
> --- a/libavcodec/nvdec.c
> +++ b/libavco
301 - 400 of 620 matches
Mail list logo
