date:20181020

Libx264 uses strtok which is not thread safe. Strtok is used in
x264_param_default_preset in param_apply_tune in x264/common/base.c.
Therefore the flag must be removed.

Fixes ticket #7446.

Signed-off-by: Marton Balint 
---
 libavcodec/libx264.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
index 54e6703d73..d6367bf557 100644
--- a/libavcodec/libx264.c
+++ b/libavcodec/libx264.c
@@ -1063,8 +1063,7 @@ AVCodec ff_libx264_encoder = {
 .priv_class   = &x264_class,
 .defaults = x264_defaults,
 .init_static_data = X264_init_static,
-.caps_internal= FF_CODEC_CAP_INIT_THREADSAFE |
-FF_CODEC_CAP_INIT_CLEANUP,
+.caps_internal= FF_CODEC_CAP_INIT_CLEANUP,
 .wrapper_name = "libx264",
 };
 #endif
@@ -1115,8 +1114,7 @@ AVCodec ff_libx262_encoder = {
 .priv_class   = &X262_class,
 .defaults = x264_defaults,
 .pix_fmts = pix_fmts_8bit,
-.caps_internal= FF_CODEC_CAP_INIT_THREADSAFE |
-FF_CODEC_CAP_INIT_CLEANUP,
+.caps_internal= FF_CODEC_CAP_INIT_CLEANUP,
 .wrapper_name = "libx264",
 };
 #endif
-- 
2.16.4

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] 2 alternative ways to check in vp9 decode_tiles() if there is data remaining

Hi

2 alternative patchsets are attached to fix $SUBJ

The 2 alternatives should behave similar.

The first adds a function to check if the next range coder symbol read would
trigger the end of input case.
We then error out before reading in case the read would trigger this case

The second sets a flag if the end of input case triggered and subsequently
errors out

The second case should be slower as it requires additional checks in inner
loops, but i was asked to implement this with a flag, so i implemented both
ways.

Which version, if any, should i apply ?

Thanks

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I do not agree with what you have to say, but I'll defend to the death your
right to say it. -- Voltaire
From 9ce6dc735dd44c31d9210b1ff5f595a9cb46638c Mon Sep 17 00:00:00 2001
From: Michael Niedermayer 
Date: Sat, 11 Aug 2018 22:28:31 +0200
Subject: [PATCH 1/2] avcodec/vp56: Add vpX_rac_is_end() to check for the end
 of input

Signed-off-by: Michael Niedermayer 
---
 libavcodec/vp56.h | 8 
 1 file changed, 8 insertions(+)

diff --git a/libavcodec/vp56.h b/libavcodec/vp56.h
index b8dda9e73a..70e1d38a83 100644
--- a/libavcodec/vp56.h
+++ b/libavcodec/vp56.h
@@ -227,6 +227,14 @@ int ff_vp56_decode_frame(AVCodecContext *avctx, void *data, int *got_frame,
 extern const uint8_t ff_vp56_norm_shift[256];
 int ff_vp56_init_range_decoder(VP56RangeCoder *c, const uint8_t *buf, int buf_size);
 
+/**
+ * vp5689 returns 1 if the end of the stream has been reached, 0 otherwise.
+ */
+static av_always_inline int vpX_rac_is_end(VP56RangeCoder *c)
+{
+return c->end <= c->buffer && c->bits >= 0;
+}
+
 static av_always_inline unsigned int vp56_rac_renorm(VP56RangeCoder *c)
 {
 int shift = ff_vp56_norm_shift[c->high];
-- 
2.19.1

From 868608bd9d0b72944bd3448adb03366949541b5b Mon Sep 17 00:00:00 2001
From: Michael Niedermayer 
Date: Sat, 4 Aug 2018 22:21:02 +0200
Subject: [PATCH 2/2] avcodec/vp9: Check in decode_tiles() if there is data
 remaining

Fixes: Timeout
Fixes: 9330/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VP9_fuzzer-5707345857347584

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavcodec/vp9.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
index b1178c9c0c..acf3ffc9e7 100644
--- a/libavcodec/vp9.c
+++ b/libavcodec/vp9.c
@@ -1306,6 +1306,9 @@ static int decode_tiles(AVCodecContext *avctx,
 decode_sb_mem(td, row, col, lflvl_ptr,
   yoff2, uvoff2, BL_64X64);
 } else {
+if (vpX_rac_is_end(td->c)) {
+return AVERROR_INVALIDDATA;
+}
 decode_sb(td, row, col, lflvl_ptr,
   yoff2, uvoff2, BL_64X64);
 }
-- 
2.19.1

From 39f3aa2218b7019ef13d990ee70a61dffa71fd13 Mon Sep 17 00:00:00 2001
From: Michael Niedermayer 
Date: Sat, 11 Aug 2018 22:32:06 +0200
Subject: [PATCH 1/2] avcodec/vp56: Add is_end flag

Signed-off-by: Michael Niedermayer 
---
 libavcodec/vp56.h | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/libavcodec/vp56.h b/libavcodec/vp56.h
index b8dda9e73a..25da1c75cb 100644
--- a/libavcodec/vp56.h
+++ b/libavcodec/vp56.h
@@ -89,6 +89,7 @@ typedef struct VP56RangeCoder {
 const uint8_t *buffer;
 const uint8_t *end;
 unsigned int code_word;
+int is_end;
 } VP56RangeCoder;
 
 typedef struct VP56RefDc {
@@ -236,9 +237,12 @@ static av_always_inline unsigned int vp56_rac_renorm(VP56RangeCoder *c)
 c->high   <<= shift;
 code_word <<= shift;
 bits   += shift;
-if(bits >= 0 && c->buffer < c->end) {
-code_word |= bytestream_get_be16(&c->buffer) << bits;
-bits -= 16;
+if(bits >= 0) {
+if (c->buffer < c->end) {
+code_word |= bytestream_get_be16(&c->buffer) << bits;
+bits -= 16;
+} else
+c->is_end = 1;
 }
 c->bits = bits;
 return code_word;
-- 
2.19.1

From 72aa2377c7b401f1a0c2866bc1471f4c98310415 Mon Sep 17 00:00:00 2001
From: Michael Niedermayer 
Date: Sat, 4 Aug 2018 22:21:02 +0200
Subject: [PATCH 2/2] avcodec/vp9: Check in decode_tiles() if there is data
 remaining

Fixes: Timeout
Fixes: 9330/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VP9_fuzzer-5707345857347584

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavcodec/vp9.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
index b1178c9c0c..dd5c8098c8 100644
--- a/libavcodec/vp9.c
+++ b/libavcodec/vp9.c
@@ -1308,6 +1308,9 @@ static int decode_tiles(AVCodecContext *avctx,
 } else {
 decode_sb(td, row, col, lflvl_ptr,

Re: [FFmpeg-devel] avcodec/proresenc_aw improvements

>
> See coverity bug report, avctx->profile is not checked for valid values i
> think.
>
> Hello,

Doesn't find where avctx->profile can have an invalid value

seems to be checked in prores_encode_init

if FF_PROFILE_UNKNOWN
use pix fmt YUV422P10 or YUV444P10 to select the profile
(can pix_fmt be another value here ?), if yes, will add an else part here

if avtc->profile < 0 or > 4, return an error.

Martin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/libx264: remove FF_CODEC_CAP_INIT_THREADSAFE flag

2018-10-20 Thread Hendrik Leppkes

On Sat, Oct 20, 2018 at 12:35 PM Marton Balint  wrote:
>
> Libx264 uses strtok which is not thread safe. Strtok is used in
> x264_param_default_preset in param_apply_tune in x264/common/base.c.
> Therefore the flag must be removed.
>
> Fixes ticket #7446.
>
> Signed-off-by: Marton Balint 
> ---
>  libavcodec/libx264.c | 6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
> index 54e6703d73..d6367bf557 100644
> --- a/libavcodec/libx264.c
> +++ b/libavcodec/libx264.c
> @@ -1063,8 +1063,7 @@ AVCodec ff_libx264_encoder = {
>  .priv_class   = &x264_class,
>  .defaults = x264_defaults,
>  .init_static_data = X264_init_static,
> -.caps_internal= FF_CODEC_CAP_INIT_THREADSAFE |
> -FF_CODEC_CAP_INIT_CLEANUP,
> +.caps_internal= FF_CODEC_CAP_INIT_CLEANUP,
>  .wrapper_name = "libx264",
>  };
>  #endif
> @@ -1115,8 +1114,7 @@ AVCodec ff_libx262_encoder = {
>  .priv_class   = &X262_class,
>  .defaults = x264_defaults,
>  .pix_fmts = pix_fmts_8bit,
> -.caps_internal= FF_CODEC_CAP_INIT_THREADSAFE |
> -FF_CODEC_CAP_INIT_CLEANUP,
> +.caps_internal= FF_CODEC_CAP_INIT_CLEANUP,
>  .wrapper_name = "libx264",
>  };
>  #endif
> --
> 2.16.4
>

Was this ever reported to x264? Theoretically some other library or
another part of a calling application could still use strtok and break
it.

- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/libx264: remove FF_CODEC_CAP_INIT_THREADSAFE flag




On Sat, 20 Oct 2018, Hendrik Leppkes wrote:


On Sat, Oct 20, 2018 at 12:35 PM Marton Balint  wrote:


Libx264 uses strtok which is not thread safe. Strtok is used in
x264_param_default_preset in param_apply_tune in x264/common/base.c.
Therefore the flag must be removed.

Fixes ticket #7446.

Signed-off-by: Marton Balint 
---
 libavcodec/libx264.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
index 54e6703d73..d6367bf557 100644
--- a/libavcodec/libx264.c
+++ b/libavcodec/libx264.c
@@ -1063,8 +1063,7 @@ AVCodec ff_libx264_encoder = {
 .priv_class   = &x264_class,
 .defaults = x264_defaults,
 .init_static_data = X264_init_static,
-.caps_internal= FF_CODEC_CAP_INIT_THREADSAFE |
-FF_CODEC_CAP_INIT_CLEANUP,
+.caps_internal= FF_CODEC_CAP_INIT_CLEANUP,
 .wrapper_name = "libx264",
 };
 #endif
@@ -1115,8 +1114,7 @@ AVCodec ff_libx262_encoder = {
 .priv_class   = &X262_class,
 .defaults = x264_defaults,
 .pix_fmts = pix_fmts_8bit,
-.caps_internal= FF_CODEC_CAP_INIT_THREADSAFE |
-FF_CODEC_CAP_INIT_CLEANUP,
+.caps_internal= FF_CODEC_CAP_INIT_CLEANUP,
 .wrapper_name = "libx264",
 };
 #endif
--
2.16.4



Was this ever reported to x264?


Not by me.

Theoretically some other library or another part of a calling 
application could still use strtok and break it.


I agree, this should be fixed in x264 as well, but until then it 
seems harmless to remove the flag.


Regards,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] avcodec : add prores_metadata bsf and fate test

Hello,

Patch in attach add a bsf filter to set color property of a prores frame

Can be used, to set all frames of prores file to the same value
(avoid color shift on some frame depending of the software used to decode
the file)
or fix the value, for file created with incorrect metadata.

Martin


0002-fate-prores_metadata_bsf-add-test-for-setting-color-.patch
Description: Binary data


0001-avcodec-add-prores_metadata-bsf-for-set-the-color-pr.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/libx264: remove FF_CODEC_CAP_INIT_THREADSAFE flag

2018-10-20 Thread Vittorio Giovara

On Sat, Oct 20, 2018 at 12:30 PM Marton Balint  wrote:

>
>
> On Sat, 20 Oct 2018, Hendrik Leppkes wrote:
>
> > On Sat, Oct 20, 2018 at 12:35 PM Marton Balint  wrote:
> >>
> >> Libx264 uses strtok which is not thread safe. Strtok is used in
> >> x264_param_default_preset in param_apply_tune in x264/common/base.c.
> >> Therefore the flag must be removed.
> >>
> >> Fixes ticket #7446.
> >>
> >> Signed-off-by: Marton Balint 
> >> ---
> >>  libavcodec/libx264.c | 6 ++
> >>  1 file changed, 2 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
> >> index 54e6703d73..d6367bf557 100644
> >> --- a/libavcodec/libx264.c
> >> +++ b/libavcodec/libx264.c
> >> @@ -1063,8 +1063,7 @@ AVCodec ff_libx264_encoder = {
> >>  .priv_class   = &x264_class,
> >>  .defaults = x264_defaults,
> >>  .init_static_data = X264_init_static,
> >> -.caps_internal= FF_CODEC_CAP_INIT_THREADSAFE |
> >> -FF_CODEC_CAP_INIT_CLEANUP,
> >> +.caps_internal= FF_CODEC_CAP_INIT_CLEANUP,
> >>  .wrapper_name = "libx264",
> >>  };
> >>  #endif
> >> @@ -1115,8 +1114,7 @@ AVCodec ff_libx262_encoder = {
> >>  .priv_class   = &X262_class,
> >>  .defaults = x264_defaults,
> >>  .pix_fmts = pix_fmts_8bit,
> >> -.caps_internal= FF_CODEC_CAP_INIT_THREADSAFE |
> >> -FF_CODEC_CAP_INIT_CLEANUP,
> >> +.caps_internal= FF_CODEC_CAP_INIT_CLEANUP,
> >>  .wrapper_name = "libx264",
> >>  };
> >>  #endif
> >> --
> >> 2.16.4
> >>
> >
> > Was this ever reported to x264?
>
> Not by me.
>
> > Theoretically some other library or another part of a calling
> > application could still use strtok and break it.
>
> I agree, this should be fixed in x264 as well, but until then it
> seems harmless to remove the flag.
>

this could potentially break a couple of use cases where it "happens to
work" (especially those that rely on the aforementioned abaa1226)
rather that dropping the flag entirely, why not fixing x264 first, bump its
version, and apply the flag conditionally on that?
-- 
Vittorio
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] avfilter/show_info : print color information

Hello,

Patch in attach add to show_info filter
print of the color property (range, primaries, trc, space)

Martin


0003-avfilter-show_info-add-print-of-color-information.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avfilter: add vibrance filter

Signed-off-by: Paul B Mahol 
---
 doc/filters.texi  |  29 +
 libavfilter/Makefile  |   1 +
 libavfilter/allfilters.c  |   1 +
 libavfilter/vf_vibrance.c | 240 ++
 4 files changed, 271 insertions(+)
 create mode 100644 libavfilter/vf_vibrance.c

diff --git a/doc/filters.texi b/doc/filters.texi
index f314718a56..d49e30b168 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -17274,6 +17274,35 @@ and ones with constant delta pts.
 If there was frames with variable delta, than it will also show min and max 
delta
 encountered.
 
+@section vibrance
+
+Boost or cut saturation.
+
+The filter accepts the following options:
+@table @option
+@item intensity
+Set strength of boost if positive value or cut if negative value. Default is 0.
+Allowed range is from -2 to 2.
+
+@item rbal
+Set the red balance. Default is 1. Allowed range is from -10 to 10.
+
+@item gbal
+Set the green balance. Default is 1. Allowed range is from -10 to 10.
+
+@item bbal
+Set the blue balance. Default is 1. Allowed range is from -10 to 10.
+
+@item rlum
+Set the red luma coefficient.
+
+@item glum
+Set the green luma coefficient.
+
+@item blum
+Set the blue luma coefficient.
+@end table
+
 @anchor{vignette}
 @section vignette
 
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 46c6023bcc..38fe649078 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -393,6 +393,7 @@ OBJS-$(CONFIG_VAGUEDENOISER_FILTER)  += 
vf_vaguedenoiser.o
 OBJS-$(CONFIG_VECTORSCOPE_FILTER)+= vf_vectorscope.o
 OBJS-$(CONFIG_VFLIP_FILTER)  += vf_vflip.o
 OBJS-$(CONFIG_VFRDET_FILTER) += vf_vfrdet.o
+OBJS-$(CONFIG_VIBRANCE_FILTER)   += vf_vibrance.o
 OBJS-$(CONFIG_VIDSTABDETECT_FILTER)  += vidstabutils.o 
vf_vidstabdetect.o
 OBJS-$(CONFIG_VIDSTABTRANSFORM_FILTER)   += vidstabutils.o 
vf_vidstabtransform.o
 OBJS-$(CONFIG_VIGNETTE_FILTER)   += vf_vignette.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 536765581b..2289efbb5b 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -374,6 +374,7 @@ extern AVFilter ff_vf_vaguedenoiser;
 extern AVFilter ff_vf_vectorscope;
 extern AVFilter ff_vf_vflip;
 extern AVFilter ff_vf_vfrdet;
+extern AVFilter ff_vf_vibrance;
 extern AVFilter ff_vf_vidstabdetect;
 extern AVFilter ff_vf_vidstabtransform;
 extern AVFilter ff_vf_vignette;
diff --git a/libavfilter/vf_vibrance.c b/libavfilter/vf_vibrance.c
new file mode 100644
index 00..d167ab8e2f
--- /dev/null
+++ b/libavfilter/vf_vibrance.c
@@ -0,0 +1,240 @@
+/*
+ * Copyright (c) 2018 Paul B Mahol
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/opt.h"
+#include "libavutil/imgutils.h"
+#include "avfilter.h"
+#include "formats.h"
+#include "internal.h"
+#include "video.h"
+
+typedef struct VibranceContext {
+const AVClass *class;
+
+float intensity;
+float balance[3];
+float lcoeffs[3];
+
+int depth;
+
+int (*do_slice)(AVFilterContext *s, void *arg,
+int jobnr, int nb_jobs);
+} VibranceContext;
+
+static inline float lerpf(float v0, float v1, float f)
+{
+return v0 + (v1 - v0) * f;
+}
+
+static int vibrance_slice8(AVFilterContext *avctx, void *arg, int jobnr, int 
nb_jobs)
+{
+VibranceContext *s = avctx->priv;
+AVFrame *frame = arg;
+const int width = frame->width;
+const int height = frame->height;
+const float gc = s->lcoeffs[0];
+const float bc = s->lcoeffs[1];
+const float rc = s->lcoeffs[2];
+const float intensity = s->intensity;
+const float gintensity = intensity * s->balance[0];
+const float bintensity = intensity * s->balance[1];
+const float rintensity = intensity * s->balance[2];
+const int slice_start = (height * jobnr) / nb_jobs;
+const int slice_end = (height * (jobnr + 1)) / nb_jobs;
+const int glinesize = frame->linesize[0];
+const int blinesize = frame->linesize[1];
+const int rlinesize = frame->linesize[2];
+uint8_t *gptr = frame->data[0] + slice_start * glinesize;
+uint8_t *bptr = frame->data[1] + slice_start * blinesize;
+uint8_t *rptr = frame->data[2] + slice_start * rlinesize;
+
+for (int y = sl

Re: [FFmpeg-devel] [PATCH] avfilter: add chromahold filter

On 10/18/18, Paul B Mahol  wrote:
> Signed-off-by: Paul B Mahol 
> ---
>  doc/filters.texi   | 20 
>  libavfilter/Makefile   |  1 +
>  libavfilter/allfilters.c   |  1 +
>  libavfilter/vf_chromakey.c | 96 +-
>  4 files changed, 116 insertions(+), 2 deletions(-)
>

will apply soon.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] avfilter : merge setfield and setrange and add set color property option

Hello,

Missing doc update, and changelog entry.

001 : Merge setfield and setrange to a new setparams filter
like both filter have near identical code, and merging it, can let a user
to set all property at the same time.

in setparams, the field mode option have been rename to field_mode
Current behaviour is not modify for setrange, setfield

002 : Add in setparams the possibility to set color primaries, trc,
colorspace
of the frame
use for the option the same name define in by avutil/pix_desc.c


Don't know if i need to set previous filter (setfield setrange) as
deprecated
(and log the new syntax using setparams filter)
And if yes, is it a good idea to put in the log message a removal date
(like in 1 or 2 year ?) ?

Like : "setfield is deprecated, use setparams=field_mode... instead.
setfield filter will be remove in October 2020".

Martin


0004-avfilter-setparams-merge-setfield-and-setrange-filte.patch
Description: Binary data


0005-avfilter-setparam-add-options-to-set-color-primaries.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [LDP] FFmpeg at LinuxDays 2018 in Prague

2018-10-20 Thread Thilo Borgmann

Hi again,

> FFmpeg been accepted for a booth at the LinuxDays 2018 in Prague, Czech 
> Republic during October 6th to 7th!
> 
> [...] Find detailed information here:
> 
> https://www.linuxdays.cz/2018/en/


about two weeks ago the Linux Days Prague took place. For limited space and 
luggage, I could only show one version of our usual demos. However, even in a 
low resolution and low framerate, the motion vector overlay attracted a lot of 
people.

The conference is quite similar to the Chemnitzer LinuxTage, however I met some 
more professional users there like we are used to in Chemnitz. There were also 
a lot of users quite familiar with FFmpeg already so both groups gave me a lot 
of quite interesting conversations.

Being the only booth staff this time, I could not attend any talks, though. 
Therefore I cannot comment on their quality but many of them were given in 
English. They are, however, live streamed in 4K and later stored on a YouTube 
channel. I visited the streaming team and they got their FFmpeg CLI usage well 
done (works & no problems).

We are more than welcome to give talks / workshops there next year. In contrast 
to Chemnitz, even the accomodation for me was free in a nearby hotel! Which 
will significantly reduce my reimbursement request later to something like 30€ 
in total.

Also, I've met a very friendly guy who has sponsored a Raspberry Pi 3 (Model 
B+).
If anyone wants to have it for some specific purpose related to FFmpeg 
development, I'm happy to ship it to any other FFmpeg developer! Who want to do 
something useful with it?
Otherwise I'll set it up as a new demo machine for conferences to come - It was 
actually sponsored because my Intel-based IoT board performed so badly, which 
was however based on my lazyness to setup HW capabilities accordingly - so 
anyway we'll make the kind sponsor more happy with a better hardware setup next 
time.

Finally, I would very much like to have more company at the booth next year! :)

-Thilo
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] GSoC 2018 mentor summit review

2018-10-20 Thread Thilo Borgmann

Hi folks,

last weekend we attended the annual GSoC mentor summit. This time, it was Pedro
Arthur and myself going there. As usual, there have been a huge amount of
interesting fellow open-source projects around and we've met a lot of
interesting people.

There have been a lot of interesting sessions like last year. Of course, many
topics have been quite similar and development/progress in some areas are not
too fast. The usual suspects have been in the general audio/video/multimedia
session (VideoLAN, Kodi, Mixxx, MuseScore, Apertus, and others). Apart from the
usual chat, we ha a general discussion about multimedia apps in the future - in
general about moving away from a bare desktop application to a more web and/or
service based application. More of interest for the front-end applications than
for us being a library, of course.

There has been a session about OSS licences again, I can't remember a severe
change of information given compared to last year, so [1] should still be an
excellent resource of more information.

The team from ScummVM is interested in improving one of the gaming codecs and
maybe someone will be into this fun :) They should provide us some samples
containing yet ignored side-data, used for sprite-like animation of decoded
sprite content onto the output image/canvas (if I understood correctly, what
they were explaining).

We also have an open offer for cooperation/support by Red Hen Lab [2]. They are
recording and transcoding a massiva amount of TV broadcastsa around the world
including more rare formats like DTMB (chineese TV) and ISDB (JP and southern
american TV). They would be able to provide us with any samples we might find
interesting. If anyone is interested, send me a mail.

There has been an announcement about an upcoming new Google program from
Google's OSPO. There will be a "Season of Docs", aiming to reach out for
technical writers to enhance documentation of open source programs. In contrast
to GSoC, this shall not be a sponsored work but pro bono. More details yet to
be disclosed!

Finally, a community driven overview of the sessions given and notes taken per
session can be found here [3], for anyone interested in specifics of that or
the corresponding notes.

It was my pleasure to come to know Pedro in person - maybe he has some more
comments about the summit and hin impressions.

Cheers,
Thilo

[1] https://opensource.org/licenses/

[2] http://www.redhenlab.org/

[3]
https://docs.google.com/document/d/1nNSud67RB_39HERpPdn-r6U3ANiC31VWHiFkKAoENBI/edit?ts=5bc91932#heading=h.lbox8n3en4ka
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] avfilter : merge setfield and setrange and add set color property option

On 10/20/18, Paul B Mahol  wrote:
> On 10/20/18, Martin Vignali  wrote:
>> Hello,
>>
>> Missing doc update, and changelog entry.
>>
>> 001 : Merge setfield and setrange to a new setparams filter
>> like both filter have near identical code, and merging it, can let a user
>> to set all property at the same time.
>>
>> in setparams, the field mode option have been rename to field_mode
>> Current behaviour is not modify for setrange, setfield
>>
>> 002 : Add in setparams the possibility to set color primaries, trc,
>> colorspace
>> of the frame
>> use for the option the same name define in by avutil/pix_desc.c
>>
>>
>> Don't know if i need to set previous filter (setfield setrange) as
>> deprecated
>> (and log the new syntax using setparams filter)
>> And if yes, is it a good idea to put in the log message a removal date
>> (like in 1 or 2 year ?) ?
>>
>> Like : "setfield is deprecated, use setparams=field_mode... instead.
>> setfield filter will be remove in October 2020".
>>
>> Martin
>>
>
> Blocking this patch, no code should remove old filters.
>
> If you want more parameters to be changed write new filters instead.
>

Feel free to merge code into single file and add another filter which
would change more stuff at once instead of one filter which will
change all values. Removing filters is bad.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] avfilter : merge setfield and setrange and add set color property option

On 10/20/18, Martin Vignali  wrote:
> Hello,
>
> Missing doc update, and changelog entry.
>
> 001 : Merge setfield and setrange to a new setparams filter
> like both filter have near identical code, and merging it, can let a user
> to set all property at the same time.
>
> in setparams, the field mode option have been rename to field_mode
> Current behaviour is not modify for setrange, setfield
>
> 002 : Add in setparams the possibility to set color primaries, trc,
> colorspace
> of the frame
> use for the option the same name define in by avutil/pix_desc.c
>
>
> Don't know if i need to set previous filter (setfield setrange) as
> deprecated
> (and log the new syntax using setparams filter)
> And if yes, is it a good idea to put in the log message a removal date
> (like in 1 or 2 year ?) ?
>
> Like : "setfield is deprecated, use setparams=field_mode... instead.
> setfield filter will be remove in October 2020".
>
> Martin
>

Blocking this patch, no code should remove old filters.

If you want more parameters to be changed write new filters instead.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] avfilter : merge setfield and setrange and add set color property option

Hello,

>
> > Blocking this patch, no code should remove old filters.
> >
>
I suppose you talk about the proposal of removing setfield, setrange later ?


> > If you want more parameters to be changed write new filters instead.
> >
>
This is what the current patch do.



>
> Feel free to merge code into single file and add another filter which
> would change more stuff at once instead of one filter which will
> change all values. Removing filters is bad.
>

If i not miss something, this is what i do.

I only keep setparams, because seems the right name for the filter i would
like to write
But setrange and setfield are keep, with the same behaviour

Just call the same code in filter frame, (which change the param only if
the property is not set to auto (-1) (which is a default value for field,
range...)

Martin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [LDP] FFmpeg at LinuxDays 2018 in Prague

2018-10-20 Thread Thomas Volkert


On 20.10.2018 17:15, Thilo Borgmann wrote:
> Hi again,
>
>> FFmpeg been accepted for a booth at the LinuxDays 2018 in Prague, Czech 
>> Republic during October 6th to 7th!
>>
>> [...] Find detailed information here:
>>
>> https://www.linuxdays.cz/2018/en/
> [..]
>
> Being the only booth staff this time, I could not attend any talks, though. 
> Therefore I cannot comment on their quality but many of them were given in 
> English. They are, however, live streamed in 4K and later stored on a YouTube 
> channel. I visited the streaming team and they got their FFmpeg CLI usage 
> well done (works & no problems). [..]

It seems that all videos got already removed from Youtube so far.

Best regards,
Thomas.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] avfilter : merge setfield and setrange and add set color property option

On 10/20/18, Martin Vignali  wrote:
> Hello,
>
>>
>> > Blocking this patch, no code should remove old filters.
>> >
>>
> I suppose you talk about the proposal of removing setfield, setrange later ?

It was not clear from commit log. So patches are fine for merge.
Just missing documentation for new filter.

>
>
>> > If you want more parameters to be changed write new filters instead.
>> >
>>
> This is what the current patch do.
>

Yes.

>
>
>>
>> Feel free to merge code into single file and add another filter which
>> would change more stuff at once instead of one filter which will
>> change all values. Removing filters is bad.
>>
>
> If i not miss something, this is what i do.
>
> I only keep setparams, because seems the right name for the filter i would
> like to write
> But setrange and setfield are keep, with the same behaviour
>
> Just call the same code in filter frame, (which change the param only if
> the property is not set to auto (-1) (which is a default value for field,
> range...)

Yes, setparam is ok filter name.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/libx264: remove FF_CODEC_CAP_INIT_THREADSAFE flag




On Sat, 20 Oct 2018, Vittorio Giovara wrote:


On Sat, Oct 20, 2018 at 12:30 PM Marton Balint  wrote:




On Sat, 20 Oct 2018, Hendrik Leppkes wrote:

> On Sat, Oct 20, 2018 at 12:35 PM Marton Balint  wrote:
>>
>> Libx264 uses strtok which is not thread safe. Strtok is used in
>> x264_param_default_preset in param_apply_tune in x264/common/base.c.
>> Therefore the flag must be removed.
>>
>> Fixes ticket #7446.
>>
>> Signed-off-by: Marton Balint 
>> ---
>>  libavcodec/libx264.c | 6 ++
>>  1 file changed, 2 insertions(+), 4 deletions(-)
>>
>> diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
>> index 54e6703d73..d6367bf557 100644
>> --- a/libavcodec/libx264.c
>> +++ b/libavcodec/libx264.c
>> @@ -1063,8 +1063,7 @@ AVCodec ff_libx264_encoder = {
>>  .priv_class   = &x264_class,
>>  .defaults = x264_defaults,
>>  .init_static_data = X264_init_static,
>> -.caps_internal= FF_CODEC_CAP_INIT_THREADSAFE |
>> -FF_CODEC_CAP_INIT_CLEANUP,
>> +.caps_internal= FF_CODEC_CAP_INIT_CLEANUP,
>>  .wrapper_name = "libx264",
>>  };
>>  #endif
>> @@ -1115,8 +1114,7 @@ AVCodec ff_libx262_encoder = {
>>  .priv_class   = &X262_class,
>>  .defaults = x264_defaults,
>>  .pix_fmts = pix_fmts_8bit,
>> -.caps_internal= FF_CODEC_CAP_INIT_THREADSAFE |
>> -FF_CODEC_CAP_INIT_CLEANUP,
>> +.caps_internal= FF_CODEC_CAP_INIT_CLEANUP,
>>  .wrapper_name = "libx264",
>>  };
>>  #endif
>> --
>> 2.16.4
>>
>
> Was this ever reported to x264?

Not by me.

> Theoretically some other library or another part of a calling
> application could still use strtok and break it.

I agree, this should be fixed in x264 as well, but until then it
seems harmless to remove the flag.



this could potentially break a couple of use cases where it "happens to
work" (especially those that rely on the aforementioned abaa1226)
rather that dropping the flag entirely, why not fixing x264 first, bump its
version, and apply the flag conditionally on that?


Fine by me, if someone could pick this up on the x264 side that would be 
great.


Thanks,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/libx264: remove FF_CODEC_CAP_INIT_THREADSAFE flag

2018-10-20 Thread Hendrik Leppkes

On Sat, Oct 20, 2018 at 4:50 PM Vittorio Giovara
 wrote:
>
> On Sat, Oct 20, 2018 at 12:30 PM Marton Balint  wrote:
>
> >
> >
> > On Sat, 20 Oct 2018, Hendrik Leppkes wrote:
> >
> > > On Sat, Oct 20, 2018 at 12:35 PM Marton Balint  wrote:
> > >>
> > >> Libx264 uses strtok which is not thread safe. Strtok is used in
> > >> x264_param_default_preset in param_apply_tune in x264/common/base.c.
> > >> Therefore the flag must be removed.
> > >>
> > >> Fixes ticket #7446.
> > >>
> > >> Signed-off-by: Marton Balint 
> > >> ---
> > >>  libavcodec/libx264.c | 6 ++
> > >>  1 file changed, 2 insertions(+), 4 deletions(-)
> > >>
> > >> diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
> > >> index 54e6703d73..d6367bf557 100644
> > >> --- a/libavcodec/libx264.c
> > >> +++ b/libavcodec/libx264.c
> > >> @@ -1063,8 +1063,7 @@ AVCodec ff_libx264_encoder = {
> > >>  .priv_class   = &x264_class,
> > >>  .defaults = x264_defaults,
> > >>  .init_static_data = X264_init_static,
> > >> -.caps_internal= FF_CODEC_CAP_INIT_THREADSAFE |
> > >> -FF_CODEC_CAP_INIT_CLEANUP,
> > >> +.caps_internal= FF_CODEC_CAP_INIT_CLEANUP,
> > >>  .wrapper_name = "libx264",
> > >>  };
> > >>  #endif
> > >> @@ -1115,8 +1114,7 @@ AVCodec ff_libx262_encoder = {
> > >>  .priv_class   = &X262_class,
> > >>  .defaults = x264_defaults,
> > >>  .pix_fmts = pix_fmts_8bit,
> > >> -.caps_internal= FF_CODEC_CAP_INIT_THREADSAFE |
> > >> -FF_CODEC_CAP_INIT_CLEANUP,
> > >> +.caps_internal= FF_CODEC_CAP_INIT_CLEANUP,
> > >>  .wrapper_name = "libx264",
> > >>  };
> > >>  #endif
> > >> --
> > >> 2.16.4
> > >>
> > >
> > > Was this ever reported to x264?
> >
> > Not by me.
> >
> > > Theoretically some other library or another part of a calling
> > > application could still use strtok and break it.
> >
> > I agree, this should be fixed in x264 as well, but until then it
> > seems harmless to remove the flag.
> >
>
> this could potentially break a couple of use cases where it "happens to
> work" (especially those that rely on the aforementioned abaa1226)
> rather that dropping the flag entirely, why not fixing x264 first, bump its
> version, and apply the flag conditionally on that?

What exactly would this break? avcodec should just do the right thing.
It would just be slower.
The flag can be re-introduced if a fixed version is released.

- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] avfilter : merge setfield and setrange and add set color property option

Le sam. 20 oct. 2018 à 18:18, Paul B Mahol  a écrit :

> On 10/20/18, Martin Vignali  wrote:
> > Hello,
> >
> >>
> >> > Blocking this patch, no code should remove old filters.
> >> >
> >>
> > I suppose you talk about the proposal of removing setfield, setrange
> later ?
>
> It was not clear from commit log. So patches are fine for merge.
> Just missing documentation for new filter.
>
> >
> >
> >> > If you want more parameters to be changed write new filters instead.
> >> >
> >>
> > This is what the current patch do.
> >
>
> Yes.
>
> >
> >
> >>
> >> Feel free to merge code into single file and add another filter which
> >> would change more stuff at once instead of one filter which will
> >> change all values. Removing filters is bad.
> >>
> >
> > If i not miss something, this is what i do.
> >
> > I only keep setparams, because seems the right name for the filter i
> would
> > like to write
> > But setrange and setfield are keep, with the same behaviour
> >
> > Just call the same code in filter frame, (which change the param only if
> > the property is not set to auto (-1) (which is a default value for field,
> > range...)
>
> Yes, setparam is ok filter name.
>
>
New patch in attach
(add doc for setparams)

Martin


0001-avfilter-setparams-merge-setfield-and-setrange-filte.patch
Description: Binary data


0002-avfilter-setparam-add-options-to-set-color-primaries.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] swscale/unscaled : add grayf32 bswap and rename packed_16bpc_bswap

Hello,

001 : add unscaled grayf32 bswap func
similar to packed_16bpc_bswap processing

002 : rename packed_16bpc_bswap func to bswap_16bpc
this func is used for planar and packed bswap16

Martin


0002-swscale-swscale_unscaled-rename-packed_16bpc_bswap.patch
Description: Binary data


0001-swscale-swscale_unscaled-add-grayf32-le-to-be.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 2/5] avcodec/nvdec: Add support for decoding HEVC 4:4:4 content

The latest generation video decoder on the Turing chips supports
decoding HEVC 4:4:4. Supporting this is relatively straight-forward;
we need to account for the different chroma format and pick the
right output and sw formats at the right times.

There was one bug which was the hard-coded assumption that the
first chroma plane would be half-height; I fixed this to use the
actual shift value on the plane.

The output formats ('2', and '3') are currently undocumented but
appear to be YUV444P and YUV444P16 based on how they behave.

Signed-off-by: Philip Langdale 
---
 libavcodec/hevcdec.c   |  3 +++
 libavcodec/nvdec.c | 43 +++---
 libavutil/hwcontext_cuda.c |  2 ++
 3 files changed, 40 insertions(+), 8 deletions(-)

diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
index a3b5c8cb71..972f2b56b6 100644
--- a/libavcodec/hevcdec.c
+++ b/libavcodec/hevcdec.c
@@ -409,6 +409,9 @@ static enum AVPixelFormat get_format(HEVCContext *s, const 
HEVCSPS *sps)
 #endif
 break;
 case AV_PIX_FMT_YUV420P12:
+case AV_PIX_FMT_YUV444P:
+case AV_PIX_FMT_YUV444P10:
+case AV_PIX_FMT_YUV444P12:
 #if CONFIG_HEVC_NVDEC_HWACCEL
 *fmt++ = AV_PIX_FMT_CUDA;
 #endif
diff --git a/libavcodec/nvdec.c b/libavcodec/nvdec.c
index e779be3a45..43cc38485a 100644
--- a/libavcodec/nvdec.c
+++ b/libavcodec/nvdec.c
@@ -34,6 +34,9 @@
 #include "nvdec.h"
 #include "internal.h"
 
+#define NVDEC_FORMAT_YUV444P 2
+#define NVDEC_FORMAT_YUV444P16 3
+
 typedef struct NVDECDecoder {
 CUvideodecoder decoder;
 
@@ -273,7 +276,8 @@ int ff_nvdec_decode_init(AVCodecContext *avctx)
 
 CUVIDDECODECREATEINFO params = { 0 };
 
-int cuvid_codec_type, cuvid_chroma_format;
+cudaVideoSurfaceFormat output_format;
+int cuvid_codec_type, cuvid_chroma_format, chroma_444;
 int ret = 0;
 
 sw_desc = av_pix_fmt_desc_get(avctx->sw_pix_fmt);
@@ -291,6 +295,7 @@ int ff_nvdec_decode_init(AVCodecContext *avctx)
 av_log(avctx, AV_LOG_ERROR, "Unsupported chroma format\n");
 return AVERROR(ENOSYS);
 }
+chroma_444 = cuvid_chroma_format == cudaVideoChromaFormat_444;
 
 if (!avctx->hw_frames_ctx) {
 ret = ff_decode_get_hw_frames_ctx(avctx, AV_HWDEVICE_TYPE_CUDA);
@@ -298,6 +303,21 @@ int ff_nvdec_decode_init(AVCodecContext *avctx)
 return ret;
 }
 
+switch (sw_desc->comp[0].depth) {
+case 8:
+output_format = chroma_444 ? NVDEC_FORMAT_YUV444P :
+ cudaVideoSurfaceFormat_NV12;
+break;
+case 10:
+case 12:
+output_format = chroma_444 ? NVDEC_FORMAT_YUV444P16 :
+ cudaVideoSurfaceFormat_P016;
+break;
+default:
+av_log(avctx, AV_LOG_ERROR, "Unsupported bit depth\n");
+return AVERROR(ENOSYS);
+}
+
 frames_ctx = (AVHWFramesContext*)avctx->hw_frames_ctx->data;
 
 params.ulWidth = avctx->coded_width;
@@ -305,8 +325,7 @@ int ff_nvdec_decode_init(AVCodecContext *avctx)
 params.ulTargetWidth   = avctx->coded_width;
 params.ulTargetHeight  = avctx->coded_height;
 params.bitDepthMinus8  = sw_desc->comp[0].depth - 8;
-params.OutputFormat= params.bitDepthMinus8 ?
- cudaVideoSurfaceFormat_P016 : 
cudaVideoSurfaceFormat_NV12;
+params.OutputFormat= output_format;
 params.CodecType   = cuvid_codec_type;
 params.ChromaFormat= cuvid_chroma_format;
 params.ulNumDecodeSurfaces = frames_ctx->initial_pool_size;
@@ -388,6 +407,8 @@ static int nvdec_retrieve_data(void *logctx, AVFrame *frame)
 NVDECFrame*cf = (NVDECFrame*)fdd->hwaccel_priv;
 NVDECDecoder *decoder = (NVDECDecoder*)cf->decoder_ref->data;
 
+AVHWFramesContext *hwctx = (AVHWFramesContext *)frame->hw_frames_ctx->data;
+
 CUVIDPROCPARAMS vpp = { 0 };
 NVDECFrame *unmap_data = NULL;
 
@@ -397,6 +418,7 @@ static int nvdec_retrieve_data(void *logctx, AVFrame *frame)
 
 unsigned int pitch, i;
 unsigned int offset = 0;
+int shift_h = 0, shift_v = 0;
 int ret = 0;
 
 vpp.progressive_frame = 1;
@@ -433,10 +455,11 @@ static int nvdec_retrieve_data(void *logctx, AVFrame 
*frame)
 unmap_data->idx_ref = av_buffer_ref(cf->idx_ref);
 unmap_data->decoder_ref = av_buffer_ref(cf->decoder_ref);
 
+av_pix_fmt_get_chroma_sub_sample(hwctx->sw_format, &shift_h, &shift_v);
 for (i = 0; frame->linesize[i]; i++) {
 frame->data[i] = (uint8_t*)(devptr + offset);
 frame->linesize[i] = pitch;
-offset += pitch * (frame->height >> (i ? 1 : 0));
+offset += pitch * (frame->height >> (i ? shift_v : 0));
 }
 
 goto finish;
@@ -576,7 +599,7 @@ int ff_nvdec_frame_params(AVCodecContext *avctx,
 {
 AVHWFramesContext *frames_ctx = (AVHWFramesContext*)hw_frames_ctx->data;
 const AVPixFmtDescriptor *sw_desc;
-int cuvid_codec_type, cuvid_chroma_format;
+int

[FFmpeg-devel] [PATCH 4/5] avcodec/cuviddec: Add support for decoding HEVC 4:4:4 content

This is the equivalent change for cuviddec after the previous change
for nvdec. I made similar changes to the copying routines to handle
pixel formats in a more generic way.

Note that unlike with nvdec, there is no confusion about the ability
of a codec to output 444 formats. This is because the cuvid parser is
used, meaning that 444 JPEG content is still indicated as using a 420
output format.

Signed-off-by: Philip Langdale 
---
 libavcodec/cuviddec.c | 59 +--
 1 file changed, 40 insertions(+), 19 deletions(-)

diff --git a/libavcodec/cuviddec.c b/libavcodec/cuviddec.c
index f21273c07e..ca9044353d 100644
--- a/libavcodec/cuviddec.c
+++ b/libavcodec/cuviddec.c
@@ -35,6 +35,9 @@
 #include "hwaccel.h"
 #include "internal.h"
 
+#define CUVID_FORMAT_YUV444P 2
+#define CUVID_FORMAT_YUV444P16 3
+
 typedef struct CuvidContext
 {
 AVClass *avclass;
@@ -127,6 +130,7 @@ static int CUDAAPI cuvid_handle_video_sequence(void 
*opaque, CUVIDEOFORMAT* form
 CUVIDDECODECAPS *caps = NULL;
 CUVIDDECODECREATEINFO cuinfo;
 int surface_fmt;
+int chroma_444;
 
 int old_width = avctx->width;
 int old_height = avctx->height;
@@ -169,17 +173,19 @@ static int CUDAAPI cuvid_handle_video_sequence(void 
*opaque, CUVIDEOFORMAT* form
 cuinfo.target_rect.right = cuinfo.ulTargetWidth;
 cuinfo.target_rect.bottom = cuinfo.ulTargetHeight;
 
+chroma_444 = format->chroma_format == cudaVideoChromaFormat_444;
+
 switch (format->bit_depth_luma_minus8) {
 case 0: // 8-bit
-pix_fmts[1] = AV_PIX_FMT_NV12;
+pix_fmts[1] = chroma_444 ? AV_PIX_FMT_YUV444P : AV_PIX_FMT_NV12;
 caps = &ctx->caps8;
 break;
 case 2: // 10-bit
-pix_fmts[1] = AV_PIX_FMT_P010;
+pix_fmts[1] = chroma_444 ? AV_PIX_FMT_YUV444P10_MSB : AV_PIX_FMT_P010;
 caps = &ctx->caps10;
 break;
 case 4: // 12-bit
-pix_fmts[1] = AV_PIX_FMT_P016;
+pix_fmts[1] = chroma_444 ? AV_PIX_FMT_YUV444P12_MSB : AV_PIX_FMT_P016;
 caps = &ctx->caps12;
 break;
 default:
@@ -282,12 +288,6 @@ static int CUDAAPI cuvid_handle_video_sequence(void 
*opaque, CUVIDEOFORMAT* form
 return 0;
 }
 
-if (format->chroma_format != cudaVideoChromaFormat_420) {
-av_log(avctx, AV_LOG_ERROR, "Chroma formats other than 420 are not 
supported\n");
-ctx->internal_error = AVERROR(EINVAL);
-return 0;
-}
-
 ctx->chroma_format = format->chroma_format;
 
 cuinfo.CodecType = ctx->codec_type = format->codec;
@@ -301,6 +301,14 @@ static int CUDAAPI cuvid_handle_video_sequence(void 
*opaque, CUVIDEOFORMAT* form
 case AV_PIX_FMT_P016:
 cuinfo.OutputFormat = cudaVideoSurfaceFormat_P016;
 break;
+case AV_PIX_FMT_YUV444P:
+cuinfo.OutputFormat = CUVID_FORMAT_YUV444P;
+break;
+case AV_PIX_FMT_YUV444P10_MSB:
+case AV_PIX_FMT_YUV444P12_MSB:
+case AV_PIX_FMT_YUV444P16:
+cuinfo.OutputFormat = CUVID_FORMAT_YUV444P16;
+break;
 default:
 av_log(avctx, AV_LOG_ERROR, "Output formats other than NV12, P010 or 
P016 are not supported\n");
 ctx->internal_error = AVERROR(EINVAL);
@@ -511,6 +519,7 @@ static int cuvid_output_frame(AVCodecContext *avctx, 
AVFrame *frame)
 return ret;
 
 if (av_fifo_size(ctx->frame_queue)) {
+const AVPixFmtDescriptor *pixdesc;
 CuvidParsedFrame parsed_frame;
 CUVIDPROCPARAMS params;
 unsigned int pitch = 0;
@@ -541,7 +550,10 @@ static int cuvid_output_frame(AVCodecContext *avctx, 
AVFrame *frame)
 goto error;
 }
 
-for (i = 0; i < 2; i++) {
+pixdesc = av_pix_fmt_desc_get(avctx->sw_pix_fmt);
+
+for (i = 0; i < pixdesc->nb_components; i++) {
+size_t height = avctx->height >> (i ? pixdesc->log2_chroma_h : 
0);
 CUDA_MEMCPY2D cpy = {
 .srcMemoryType = CU_MEMORYTYPE_DEVICE,
 .dstMemoryType = CU_MEMORYTYPE_DEVICE,
@@ -551,22 +563,27 @@ static int cuvid_output_frame(AVCodecContext *avctx, 
AVFrame *frame)
 .dstPitch  = frame->linesize[i],
 .srcY  = offset,
 .WidthInBytes  = FFMIN(pitch, frame->linesize[i]),
-.Height= avctx->height >> (i ? 1 : 0),
+.Height= height,
 };
 
 ret = CHECK_CU(ctx->cudl->cuMemcpy2DAsync(&cpy, 
device_hwctx->stream));
 if (ret < 0)
 goto error;
 
-offset += avctx->height;
+offset += height;
 }
 
 ret = 
CHECK_CU(ctx->cudl->cuStreamSynchronize(device_hwctx->stream));
 if (ret < 0)
 goto error;
-} else if (avctx->pix_fmt == AV_PIX_FMT_NV12 ||
-   avctx->pix_fmt == AV_PIX_FMT_P010 ||
-   avctx->p

[FFmpeg-devel] [PATCH 5/5] avcodec/nvenc: Accept YUV444P10_MSB and YUV444P12_MSB content

12bit is implicitly truncated to 10bit as part of doing this, but we
already do that for P016 and YUV444P16.

I've bundled a single version bump and changelog entry in this change
to reflect the updates to all three of nvdec/nvenc/cuviddec.

Signed-off-by: Philip Langdale 
---
 Changelog  |  1 +
 libavcodec/nvenc.c | 18 +-
 2 files changed, 14 insertions(+), 5 deletions(-)

diff --git a/Changelog b/Changelog
index 1b0bc95b7a..1334eec474 100644
--- a/Changelog
+++ b/Changelog
@@ -35,6 +35,7 @@ version :
 - AV1 parser
 - SER demuxer
 - sinc audio filter source
+- Support for HEVC 4:4:4 content in nvdec/nvenc/cuviddec
 
 
 version 4.0:
diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c
index e180d7b993..5be98a5182 100644
--- a/libavcodec/nvenc.c
+++ b/libavcodec/nvenc.c
@@ -41,8 +41,10 @@ const enum AVPixelFormat ff_nvenc_pix_fmts[] = {
 AV_PIX_FMT_NV12,
 AV_PIX_FMT_P010,
 AV_PIX_FMT_YUV444P,
-AV_PIX_FMT_P016,  // Truncated to 10bits
-AV_PIX_FMT_YUV444P16, // Truncated to 10bits
+AV_PIX_FMT_P016,  // Truncated to 10bits
+AV_PIX_FMT_YUV444P10_MSB,
+AV_PIX_FMT_YUV444P12_MSB, // Truncated to 10bits
+AV_PIX_FMT_YUV444P16, // Truncated to 10bits
 AV_PIX_FMT_0RGB32,
 AV_PIX_FMT_0BGR32,
 AV_PIX_FMT_CUDA,
@@ -52,11 +54,15 @@ const enum AVPixelFormat ff_nvenc_pix_fmts[] = {
 AV_PIX_FMT_NONE
 };
 
-#define IS_10BIT(pix_fmt)  (pix_fmt == AV_PIX_FMT_P010|| \
-pix_fmt == AV_PIX_FMT_P016|| \
+#define IS_10BIT(pix_fmt)  (pix_fmt == AV_PIX_FMT_P010  || \
+pix_fmt == AV_PIX_FMT_P016  || \
+pix_fmt == AV_PIX_FMT_YUV444P10_MSB || \
+pix_fmt == AV_PIX_FMT_YUV444P12_MSB || \
 pix_fmt == AV_PIX_FMT_YUV444P16)
 
-#define IS_YUV444(pix_fmt) (pix_fmt == AV_PIX_FMT_YUV444P || \
+#define IS_YUV444(pix_fmt) (pix_fmt == AV_PIX_FMT_YUV444P   || \
+pix_fmt == AV_PIX_FMT_YUV444P10_MSB || \
+pix_fmt == AV_PIX_FMT_YUV444P12_MSB || \
 pix_fmt == AV_PIX_FMT_YUV444P16)
 
 static const struct {
@@ -1263,6 +1269,8 @@ static NV_ENC_BUFFER_FORMAT nvenc_map_buffer_format(enum 
AVPixelFormat pix_fmt)
 return NV_ENC_BUFFER_FORMAT_YUV420_10BIT;
 case AV_PIX_FMT_YUV444P:
 return NV_ENC_BUFFER_FORMAT_YUV444_PL;
+case AV_PIX_FMT_YUV444P10_MSB:
+case AV_PIX_FMT_YUV444P12_MSB:
 case AV_PIX_FMT_YUV444P16:
 return NV_ENC_BUFFER_FORMAT_YUV444_10BIT;
 case AV_PIX_FMT_0RGB32:
-- 
2.19.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 0/5] Add nvidia hw decode support for HEVC 4:4:4 content

The new video decoder hardware on Turing GPUs supports HEVC 4:4:4 content.
This patch series adds the necessary new pixel formats and implements
support in nvdec/nvenc/cuviddec.

(Since the previous post of this series, I fixed the reversed terminology
on the pixel formats)

The big discussion was about the new pixel formats. I would like to get
to a clear conclusion on this otherwise, this patch series goes nowhere
forever, which I obviously don't want to happen, and I don't think is
a legitmate outcome for reasonable functionality.

So, discussion points:

1) What are the new data layouts that lack representation in the existing
   pixel formats?

With the introduction of HEVC 444 support in the decoding hardware, we
now have 3 plane YUV444 containing 10 or 12 bit data in an MSB packed
format. MSB packing means the layout can be interpreted as 16 bit data
transparently - equivalent to how P010 and P016 work. However, all the
pre-existing formats are LSB packed so these layouts cannot be mapped
to any of them except for YUV444P16, which is transparently compatible
in the same way that P016 is.

2) Why would we just not use YUV444P16 for everything?

The main reason is loss of metadata - after declaring that the data is
stored as YUV444P16, we no longer know what the actual bith depth is.
Using a format that explicitly declares the number of relevant bits
preserves that, which may be beneficial for filtering or other
transformations.

3) Why would we just not add these new formats and move on?

There is a general reluctance to add new pixel formats without good
reason, which is fair enough, but some people have also expressed a
wish to decouple bit depth from pixel formats. This would mean
carrying that information elsewhere and having the pixel format
purely reflect the physical layout (ie: You'd only have P016 and
YUV444P16).

4) Why not just implement this new mechanism for bit depth?

Because it's a massive amount of work. Adding new metadata like this
is a huge task that has impact throughout the codebase and also
requires all clients to be rewritten at some point. A very close
analog has been the attempt to remove YUVJ formats - these formats
indicate the choice of a particular colourspace, with the same physical
layout.

Despite a lot of time and a lot of work, the YUVJ removal is still not
done and it's been six months since the last patchset was proposed.
There is no reason to believe that decoupling bit depth would not be
a project of equal size and timescale - to say that this patchset is
blocked on bit depth decoupling is to say that it's blocked indefinitely;
no one even seriously articulated a desire to decouple bit depth until
this patchset raised the issue, and no one has committed to doing the
work.

It's also unclear whether anyone would seriously suggest removing P010,
which is an industry standard format - it would pointlessly harm
interoperability with other tools and clients for ffmpeg to unilaterally
declare that P010 was pointless and another mechanism should be used.

Put another way, If YUV444P10_MSB was described in an MSDN document
like P010, we'd probably not be having this conversation. (For the
curious, MSDN only describes packed 444 formats.)

5) What about splitting the difference?

One option that would reflect the relationship between P010 and P016
would be to only add YUV444P10_MSB and use YUV444P16 for 12 bit data.
This means we add one format rather than two, and the usage of them
is equivalent. Is that an interesting compromise? Doesn't bother me.

6) What does bother me?

All I ultimately care about is getting this in. It's legimate hardware
capability and I really want to make sure it's available. From that
perspective I don't care if we add 0/1/2 formats - I will do whatever
is agreed in the end. The option I am not happy with is saying that
we can only expose the hardware capabilities if we implement bit depth
decoupling - that's really saying you don't ever expect this
functionality to go in.

So, please, let's just make a decision.

Philip Langdale (5):
  avutil: Add YUV444P10_MSB and YUV444P12_MSB pixel formats
  avcodec/nvdec: Add support for decoding HEVC 4:4:4 content
  avcodec/nvdec: Explicitly mark codecs that support 444 output formats
  avcodec/cuviddec: Add support for decoding HEVC 4:4:4 content
  avcodec/nvenc: Accept YUV444P10_MSB and YUV444P12_MSB content

 Changelog  |  1 +
 libavcodec/cuviddec.c  | 59 ++
 libavcodec/hevcdec.c   |  3 ++
 libavcodec/nvdec.c | 46 +++--
 libavcodec/nvdec.h |  5 +++-
 libavcodec/nvdec_h264.c|  2 +-
 libavcodec/nvdec_hevc.c| 10 +--
 libavcodec/nvdec_mjpeg.c   |  2 +-
 libavcodec/nvdec_mpeg12.c  |  2 +-
 libavcodec/nvdec_mpeg4.c   |  2 +-
 libavcodec/nvdec_vc1.c |  2 +-
 libavcodec/nvdec_vp8.c |  2 +-
 libavcodec/nvdec_vp9.c |  2 +-
 libavcodec/nvenc.c | 18 
 libavutil/hwcontext_

[FFmpeg-devel] [PATCH 3/5] avcodec/nvdec: Explicitly mark codecs that support 444 output formats

With the introduction of HEVC 444 support, we technically have two
codecs that can handle 444 - HEVC and MJPEG. In the case of MJPEG,
it can decode, but can only output one of the semi-planar formats.

That means we need additional logic to decide whether to use a
444 output format or not.

Signed-off-by: Philip Langdale 
---
 libavcodec/nvdec.c|  7 ---
 libavcodec/nvdec.h|  5 -
 libavcodec/nvdec_h264.c   |  2 +-
 libavcodec/nvdec_hevc.c   | 10 --
 libavcodec/nvdec_mjpeg.c  |  2 +-
 libavcodec/nvdec_mpeg12.c |  2 +-
 libavcodec/nvdec_mpeg4.c  |  2 +-
 libavcodec/nvdec_vc1.c|  2 +-
 libavcodec/nvdec_vp8.c|  2 +-
 libavcodec/nvdec_vp9.c|  2 +-
 10 files changed, 23 insertions(+), 13 deletions(-)

diff --git a/libavcodec/nvdec.c b/libavcodec/nvdec.c
index 43cc38485a..76e8b7c7bc 100644
--- a/libavcodec/nvdec.c
+++ b/libavcodec/nvdec.c
@@ -295,7 +295,7 @@ int ff_nvdec_decode_init(AVCodecContext *avctx)
 av_log(avctx, AV_LOG_ERROR, "Unsupported chroma format\n");
 return AVERROR(ENOSYS);
 }
-chroma_444 = cuvid_chroma_format == cudaVideoChromaFormat_444;
+chroma_444 = ctx->supports_444 && cuvid_chroma_format == 
cudaVideoChromaFormat_444;
 
 if (!avctx->hw_frames_ctx) {
 ret = ff_decode_get_hw_frames_ctx(avctx, AV_HWDEVICE_TYPE_CUDA);
@@ -595,7 +595,8 @@ static AVBufferRef *nvdec_alloc_dummy(int size)
 
 int ff_nvdec_frame_params(AVCodecContext *avctx,
   AVBufferRef *hw_frames_ctx,
-  int dpb_size)
+  int dpb_size,
+  int supports_444)
 {
 AVHWFramesContext *frames_ctx = (AVHWFramesContext*)hw_frames_ctx->data;
 const AVPixFmtDescriptor *sw_desc;
@@ -616,7 +617,7 @@ int ff_nvdec_frame_params(AVCodecContext *avctx,
 av_log(avctx, AV_LOG_VERBOSE, "Unsupported chroma format\n");
 return AVERROR(EINVAL);
 }
-chroma_444 = cuvid_chroma_format == cudaVideoChromaFormat_444;
+chroma_444 = supports_444 && cuvid_chroma_format == 
cudaVideoChromaFormat_444;
 
 frames_ctx->format= AV_PIX_FMT_CUDA;
 frames_ctx->width = (avctx->coded_width + 1) & ~1;
diff --git a/libavcodec/nvdec.h b/libavcodec/nvdec.h
index 85a0fcf725..09ae8c37e6 100644
--- a/libavcodec/nvdec.h
+++ b/libavcodec/nvdec.h
@@ -61,6 +61,8 @@ typedef struct NVDECContext {
 unsigned *slice_offsets;
 int   nb_slices;
 unsigned int  slice_offsets_allocated;
+
+int   supports_444;
 } NVDECContext;
 
 int ff_nvdec_decode_init(AVCodecContext *avctx);
@@ -72,7 +74,8 @@ int ff_nvdec_simple_decode_slice(AVCodecContext *avctx, const 
uint8_t *buffer,
  uint32_t size);
 int ff_nvdec_frame_params(AVCodecContext *avctx,
   AVBufferRef *hw_frames_ctx,
-  int dpb_size);
+  int dpb_size,
+  int supports_444);
 int ff_nvdec_get_ref_idx(AVFrame *frame);
 
 #endif /* AVCODEC_NVDEC_H */
diff --git a/libavcodec/nvdec_h264.c b/libavcodec/nvdec_h264.c
index 25b30329d0..116bd4fb5d 100644
--- a/libavcodec/nvdec_h264.c
+++ b/libavcodec/nvdec_h264.c
@@ -166,7 +166,7 @@ static int nvdec_h264_frame_params(AVCodecContext *avctx,
 {
 const H264Context *h = avctx->priv_data;
 const SPS   *sps = h->ps.sps;
-return ff_nvdec_frame_params(avctx, hw_frames_ctx, sps->ref_frame_count + 
sps->num_reorder_frames);
+return ff_nvdec_frame_params(avctx, hw_frames_ctx, sps->ref_frame_count + 
sps->num_reorder_frames, 0);
 }
 
 const AVHWAccel ff_h264_nvdec_hwaccel = {
diff --git a/libavcodec/nvdec_hevc.c b/libavcodec/nvdec_hevc.c
index e04a701f3a..9e726f708e 100644
--- a/libavcodec/nvdec_hevc.c
+++ b/libavcodec/nvdec_hevc.c
@@ -269,7 +269,13 @@ static int nvdec_hevc_frame_params(AVCodecContext *avctx,
 {
 const HEVCContext *s = avctx->priv_data;
 const HEVCSPS *sps = s->ps.sps;
-return ff_nvdec_frame_params(avctx, hw_frames_ctx, 
sps->temporal_layer[sps->max_sub_layers - 1].max_dec_pic_buffering + 1);
+return ff_nvdec_frame_params(avctx, hw_frames_ctx, 
sps->temporal_layer[sps->max_sub_layers - 1].max_dec_pic_buffering + 1, 1);
+}
+
+static int nvdec_hevc_decode_init(AVCodecContext *avctx) {
+NVDECContext *ctx = avctx->internal->hwaccel_priv_data;
+ctx->supports_444 = 1;
+return ff_nvdec_decode_init(avctx);
 }
 
 const AVHWAccel ff_hevc_nvdec_hwaccel = {
@@ -281,7 +287,7 @@ const AVHWAccel ff_hevc_nvdec_hwaccel = {
 .end_frame= ff_nvdec_end_frame,
 .decode_slice = nvdec_hevc_decode_slice,
 .frame_params = nvdec_hevc_frame_params,
-.init = ff_nvdec_decode_init,
+.init = nvdec_hevc_decode_init,
 .uninit   = ff_nvdec_decode_uninit,
 .priv_data_size   = sizeof(NVDECContext),
 };
diff --git a/libavcodec/nvdec_mjpeg.c b/libavcodec/nvdec_mjpeg.c
index 7e404246ce.

[FFmpeg-devel] [PATCH 1/5] avutil: Add YUV444P10_MSB and YUV444P12_MSB pixel formats

Currently, ffmpeg defines a set of YUV444P formats for use where
the bits-per-pixel are between 8 and 16 bits. In these formats,
the bits are packed in the LSBs of the 16 bits of available storage.

On the other hand, all the hardware vendors have defined their
equivalent formats with the bits packed in the MSBs, which has the
virtue of making the memory layouts compatible with being treated
as full 16 bit values (which is also why P010 is defined this way).

So, to be able to use these hardware compatible formats, we need
definitions for them in ffmpeg. Right now, I need this for nvdec,
but Vulkan also uses the same format definitions.

Signed-off-by: Philip Langdale 
---
 libavutil/pixdesc.c | 48 +
 libavutil/pixfmt.h  |  8 
 libavutil/version.h |  4 ++--
 3 files changed, 58 insertions(+), 2 deletions(-)

diff --git a/libavutil/pixdesc.c b/libavutil/pixdesc.c
index 970a83214c..8b2f521c88 100644
--- a/libavutil/pixdesc.c
+++ b/libavutil/pixdesc.c
@@ -1629,6 +1629,54 @@ static const AVPixFmtDescriptor 
av_pix_fmt_descriptors[AV_PIX_FMT_NB] = {
 },
 .flags = AV_PIX_FMT_FLAG_BE | AV_PIX_FMT_FLAG_PLANAR,
 },
+[AV_PIX_FMT_YUV444P10LE_MSB] = {
+.name = "yuv444p10lemsb",
+.nb_components = 3,
+.log2_chroma_w = 0,
+.log2_chroma_h = 0,
+.comp = {
+{ 0, 2, 0, 6, 10, 1, 9, 1 },/* Y */
+{ 1, 2, 0, 6, 10, 1, 9, 1 },/* U */
+{ 2, 2, 0, 6, 10, 1, 9, 1 },/* V */
+},
+.flags = AV_PIX_FMT_FLAG_PLANAR,
+},
+[AV_PIX_FMT_YUV444P10BE_MSB] = {
+.name = "yuv444p10bemsb",
+.nb_components = 3,
+.log2_chroma_w = 0,
+.log2_chroma_h = 0,
+.comp = {
+{ 0, 2, 0, 6, 10, 1, 9, 1 },/* Y */
+{ 1, 2, 0, 6, 10, 1, 9, 1 },/* U */
+{ 2, 2, 0, 6, 10, 1, 9, 1 },/* V */
+},
+.flags = AV_PIX_FMT_FLAG_BE | AV_PIX_FMT_FLAG_PLANAR,
+},
+[AV_PIX_FMT_YUV444P12LE_MSB] = {
+.name = "yuv444p12lemsb",
+.nb_components = 3,
+.log2_chroma_w = 0,
+.log2_chroma_h = 0,
+.comp = {
+{ 0, 2, 0, 4, 12, 1, 11, 1 },/* Y */
+{ 1, 2, 0, 4, 12, 1, 11, 1 },/* U */
+{ 2, 2, 0, 4, 12, 1, 11, 1 },/* V */
+},
+.flags = AV_PIX_FMT_FLAG_PLANAR,
+},
+[AV_PIX_FMT_YUV444P12BE_MSB] = {
+.name = "yuv444p12bemsb",
+.nb_components = 3,
+.log2_chroma_w = 0,
+.log2_chroma_h = 0,
+.comp = {
+{ 0, 2, 0, 4, 12, 1, 11, 1 },/* Y */
+{ 1, 2, 0, 4, 12, 1, 11, 1 },/* U */
+{ 2, 2, 0, 4, 12, 1, 11, 1 },/* V */
+},
+.flags = AV_PIX_FMT_FLAG_BE | AV_PIX_FMT_FLAG_PLANAR,
+},
 [AV_PIX_FMT_D3D11VA_VLD] = {
 .name = "d3d11va_vld",
 .log2_chroma_w = 1,
diff --git a/libavutil/pixfmt.h b/libavutil/pixfmt.h
index 6815f8dc7b..aaa7dcdb50 100644
--- a/libavutil/pixfmt.h
+++ b/libavutil/pixfmt.h
@@ -340,6 +340,11 @@ enum AVPixelFormat {
 AV_PIX_FMT_GRAYF32BE,  ///< IEEE-754 single precision Y, 32bpp, big-endian
 AV_PIX_FMT_GRAYF32LE,  ///< IEEE-754 single precision Y, 32bpp, 
little-endian
 
+AV_PIX_FMT_YUV444P10LE_MSB,  ///< planar YUV 4:4:4, 30bpp, (1 Cr & Cb 
sample per 1x1 Y samples), MSB packed, little-endian
+AV_PIX_FMT_YUV444P10BE_MSB,  ///< planar YUV 4:4:4, 30bpp, (1 Cr & Cb 
sample per 1x1 Y samples), MSB packed, big-endian
+AV_PIX_FMT_YUV444P12LE_MSB,  ///< planar YUV 4:4:4, 36bpp, (1 Cr & Cb 
sample per 1x1 Y samples), MSB packed, little-endian
+AV_PIX_FMT_YUV444P12BE_MSB,  ///< planar YUV 4:4:4, 36bpp, (1 Cr & Cb 
sample per 1x1 Y samples), MSB packed, big-endian
+
 AV_PIX_FMT_NB ///< number of pixel formats, DO NOT USE THIS if you 
want to link with shared libav* because the number of formats might differ 
between versions
 };
 
@@ -391,6 +396,9 @@ enum AVPixelFormat {
 #define AV_PIX_FMT_YUV422P16 AV_PIX_FMT_NE(YUV422P16BE, YUV422P16LE)
 #define AV_PIX_FMT_YUV444P16 AV_PIX_FMT_NE(YUV444P16BE, YUV444P16LE)
 
+#define AV_PIX_FMT_YUV444P10_MSB AV_PIX_FMT_NE(YUV444P10BE_MSB, 
YUV444P10LE_MSB)
+#define AV_PIX_FMT_YUV444P12_MSB AV_PIX_FMT_NE(YUV444P12BE_MSB, 
YUV444P12LE_MSB)
+
 #define AV_PIX_FMT_GBRP9 AV_PIX_FMT_NE(GBRP9BE ,GBRP9LE)
 #define AV_PIX_FMT_GBRP10AV_PIX_FMT_NE(GBRP10BE,GBRP10LE)
 #define AV_PIX_FMT_GBRP12AV_PIX_FMT_NE(GBRP12BE,GBRP12LE)
diff --git a/libavutil/version.h b/libavutil/version.h
index f84ec89154..377714a91e 100644
--- a/libavutil/version.h
+++ b/libavutil/version.h
@@ -79,8 +79,8 @@
  */
 
 #define LIBAVUTIL_VERSION_MAJOR  56
-#define LIBAVUTIL_VERSION_MINOR  19
-#define LIBAVUTIL_VERSION_MICRO 101
+#define LIBAVUTIL_VERSION_MINOR  20
+#define LIBAVUTIL_VERSION_MICRO 100
 
 #define LIBAVUTIL_VERSION_INT   AV_VERSION_INT(LIBAVUTIL_VERSION_M

Re: [FFmpeg-devel] [PATCH 2/5] avcodec/nvdec: Add support for decoding HEVC 4:4:4 content


On 20.10.2018 22:46, Philip Langdale wrote:

The latest generation video decoder on the Turing chips supports
decoding HEVC 4:4:4. Supporting this is relatively straight-forward;
we need to account for the different chroma format and pick the
right output and sw formats at the right times.

There was one bug which was the hard-coded assumption that the
first chroma plane would be half-height; I fixed this to use the
actual shift value on the plane.

The output formats ('2', and '3') are currently undocumented but
appear to be YUV444P and YUV444P16 based on how they behave.

Signed-off-by: Philip Langdale 
---
  libavcodec/hevcdec.c   |  3 +++
  libavcodec/nvdec.c | 43 +++---
  libavutil/hwcontext_cuda.c |  2 ++
  3 files changed, 40 insertions(+), 8 deletions(-)

diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
index a3b5c8cb71..972f2b56b6 100644
--- a/libavcodec/hevcdec.c
+++ b/libavcodec/hevcdec.c
@@ -409,6 +409,9 @@ static enum AVPixelFormat get_format(HEVCContext *s, const 
HEVCSPS *sps)
  #endif
  break;
  case AV_PIX_FMT_YUV420P12:
+case AV_PIX_FMT_YUV444P:
+case AV_PIX_FMT_YUV444P10:
+case AV_PIX_FMT_YUV444P12:
  #if CONFIG_HEVC_NVDEC_HWACCEL
  *fmt++ = AV_PIX_FMT_CUDA;
  #endif
diff --git a/libavcodec/nvdec.c b/libavcodec/nvdec.c
index e779be3a45..43cc38485a 100644
--- a/libavcodec/nvdec.c
+++ b/libavcodec/nvdec.c
@@ -34,6 +34,9 @@
  #include "nvdec.h"
  #include "internal.h"
  
+#define NVDEC_FORMAT_YUV444P 2

+#define NVDEC_FORMAT_YUV444P16 3
+
  typedef struct NVDECDecoder {
  CUvideodecoder decoder;
  
@@ -273,7 +276,8 @@ int ff_nvdec_decode_init(AVCodecContext *avctx)
  
  CUVIDDECODECREATEINFO params = { 0 };
  
-int cuvid_codec_type, cuvid_chroma_format;

+cudaVideoSurfaceFormat output_format;
+int cuvid_codec_type, cuvid_chroma_format, chroma_444;
  int ret = 0;
  
  sw_desc = av_pix_fmt_desc_get(avctx->sw_pix_fmt);

@@ -291,6 +295,7 @@ int ff_nvdec_decode_init(AVCodecContext *avctx)
  av_log(avctx, AV_LOG_ERROR, "Unsupported chroma format\n");
  return AVERROR(ENOSYS);
  }
+chroma_444 = cuvid_chroma_format == cudaVideoChromaFormat_444;
  
  if (!avctx->hw_frames_ctx) {

  ret = ff_decode_get_hw_frames_ctx(avctx, AV_HWDEVICE_TYPE_CUDA);
@@ -298,6 +303,21 @@ int ff_nvdec_decode_init(AVCodecContext *avctx)
  return ret;
  }
  
+switch (sw_desc->comp[0].depth) {

+case 8:
+output_format = chroma_444 ? NVDEC_FORMAT_YUV444P :
+ cudaVideoSurfaceFormat_NV12;
+break;
+case 10:
+case 12:
+output_format = chroma_444 ? NVDEC_FORMAT_YUV444P16 :
+ cudaVideoSurfaceFormat_P016;
+break;
+default:
+av_log(avctx, AV_LOG_ERROR, "Unsupported bit depth\n");
+return AVERROR(ENOSYS);
+}
+
  frames_ctx = (AVHWFramesContext*)avctx->hw_frames_ctx->data;
  
  params.ulWidth = avctx->coded_width;

@@ -305,8 +325,7 @@ int ff_nvdec_decode_init(AVCodecContext *avctx)
  params.ulTargetWidth   = avctx->coded_width;
  params.ulTargetHeight  = avctx->coded_height;
  params.bitDepthMinus8  = sw_desc->comp[0].depth - 8;
-params.OutputFormat= params.bitDepthMinus8 ?
- cudaVideoSurfaceFormat_P016 : 
cudaVideoSurfaceFormat_NV12;
+params.OutputFormat= output_format;
  params.CodecType   = cuvid_codec_type;
  params.ChromaFormat= cuvid_chroma_format;
  params.ulNumDecodeSurfaces = frames_ctx->initial_pool_size;
@@ -388,6 +407,8 @@ static int nvdec_retrieve_data(void *logctx, AVFrame *frame)
  NVDECFrame*cf = (NVDECFrame*)fdd->hwaccel_priv;
  NVDECDecoder *decoder = (NVDECDecoder*)cf->decoder_ref->data;
  
+AVHWFramesContext *hwctx = (AVHWFramesContext *)frame->hw_frames_ctx->data;

+
  CUVIDPROCPARAMS vpp = { 0 };
  NVDECFrame *unmap_data = NULL;
  
@@ -397,6 +418,7 @@ static int nvdec_retrieve_data(void *logctx, AVFrame *frame)
  
  unsigned int pitch, i;

  unsigned int offset = 0;
+int shift_h = 0, shift_v = 0;
  int ret = 0;
  
  vpp.progressive_frame = 1;

@@ -433,10 +455,11 @@ static int nvdec_retrieve_data(void *logctx, AVFrame 
*frame)
  unmap_data->idx_ref = av_buffer_ref(cf->idx_ref);
  unmap_data->decoder_ref = av_buffer_ref(cf->decoder_ref);
  
+av_pix_fmt_get_chroma_sub_sample(hwctx->sw_format, &shift_h, &shift_v);

  for (i = 0; frame->linesize[i]; i++) {
  frame->data[i] = (uint8_t*)(devptr + offset);
  frame->linesize[i] = pitch;
-offset += pitch * (frame->height >> (i ? 1 : 0));
+offset += pitch * (frame->height >> (i ? shift_v : 0));
  }
  
  goto finish;

@@ -576,7 +599,7 @@ int ff_nvdec_frame_params(AVCodecContext *avctx,
  {
  AVHWFramesContext *frames_ctx = (AVHWFramesContext

Re: [FFmpeg-devel] [PATCH 0/5] Add nvidia hw decode support for HEVC 4:4:4 content

2018-10-20 Thread Carl Eugen Hoyos

2018-10-20 22:46 GMT+02:00, Philip Langdale :

> The big discussion was about the new pixel formats. I would
> like to get to a clear conclusion on this otherwise, this patch
> series goes nowhere forever

Wouldn't it be an alternative to first commit the patch with P16
and then discuss what the disadvantage is?

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/5] avcodec/nvdec: Explicitly mark codecs that support 444 output formats


On 20.10.2018 22:46, Philip Langdale wrote:

With the introduction of HEVC 444 support, we technically have two
codecs that can handle 444 - HEVC and MJPEG. In the case of MJPEG,
it can decode, but can only output one of the semi-planar formats.

That means we need additional logic to decide whether to use a
444 output format or not.

Signed-off-by: Philip Langdale 
---
  libavcodec/nvdec.c|  7 ---
  libavcodec/nvdec.h|  5 -
  libavcodec/nvdec_h264.c   |  2 +-
  libavcodec/nvdec_hevc.c   | 10 --
  libavcodec/nvdec_mjpeg.c  |  2 +-
  libavcodec/nvdec_mpeg12.c |  2 +-
  libavcodec/nvdec_mpeg4.c  |  2 +-
  libavcodec/nvdec_vc1.c|  2 +-
  libavcodec/nvdec_vp8.c|  2 +-
  libavcodec/nvdec_vp9.c|  2 +-
  10 files changed, 23 insertions(+), 13 deletions(-)

diff --git a/libavcodec/nvdec.c b/libavcodec/nvdec.c
index 43cc38485a..76e8b7c7bc 100644
--- a/libavcodec/nvdec.c
+++ b/libavcodec/nvdec.c
@@ -295,7 +295,7 @@ int ff_nvdec_decode_init(AVCodecContext *avctx)
  av_log(avctx, AV_LOG_ERROR, "Unsupported chroma format\n");
  return AVERROR(ENOSYS);
  }
-chroma_444 = cuvid_chroma_format == cudaVideoChromaFormat_444;
+chroma_444 = ctx->supports_444 && cuvid_chroma_format == 
cudaVideoChromaFormat_444;
  
  if (!avctx->hw_frames_ctx) {

  ret = ff_decode_get_hw_frames_ctx(avctx, AV_HWDEVICE_TYPE_CUDA);
@@ -595,7 +595,8 @@ static AVBufferRef *nvdec_alloc_dummy(int size)
  
  int ff_nvdec_frame_params(AVCodecContext *avctx,

AVBufferRef *hw_frames_ctx,
-  int dpb_size)
+  int dpb_size,
+  int supports_444)
  {
  AVHWFramesContext *frames_ctx = (AVHWFramesContext*)hw_frames_ctx->data;
  const AVPixFmtDescriptor *sw_desc;
@@ -616,7 +617,7 @@ int ff_nvdec_frame_params(AVCodecContext *avctx,
  av_log(avctx, AV_LOG_VERBOSE, "Unsupported chroma format\n");
  return AVERROR(EINVAL);
  }
-chroma_444 = cuvid_chroma_format == cudaVideoChromaFormat_444;
+chroma_444 = supports_444 && cuvid_chroma_format == 
cudaVideoChromaFormat_444;
  
  frames_ctx->format= AV_PIX_FMT_CUDA;

  frames_ctx->width = (avctx->coded_width + 1) & ~1;
diff --git a/libavcodec/nvdec.h b/libavcodec/nvdec.h
index 85a0fcf725..09ae8c37e6 100644
--- a/libavcodec/nvdec.h
+++ b/libavcodec/nvdec.h
@@ -61,6 +61,8 @@ typedef struct NVDECContext {
  unsigned *slice_offsets;
  int   nb_slices;
  unsigned int  slice_offsets_allocated;
+
+int   supports_444;
  } NVDECContext;
  
  int ff_nvdec_decode_init(AVCodecContext *avctx);

@@ -72,7 +74,8 @@ int ff_nvdec_simple_decode_slice(AVCodecContext *avctx, const 
uint8_t *buffer,
   uint32_t size);
  int ff_nvdec_frame_params(AVCodecContext *avctx,
AVBufferRef *hw_frames_ctx,
-  int dpb_size);
+  int dpb_size,
+  int supports_444);
  int ff_nvdec_get_ref_idx(AVFrame *frame);
  
  #endif /* AVCODEC_NVDEC_H */

diff --git a/libavcodec/nvdec_h264.c b/libavcodec/nvdec_h264.c
index 25b30329d0..116bd4fb5d 100644
--- a/libavcodec/nvdec_h264.c
+++ b/libavcodec/nvdec_h264.c
@@ -166,7 +166,7 @@ static int nvdec_h264_frame_params(AVCodecContext *avctx,
  {
  const H264Context *h = avctx->priv_data;
  const SPS   *sps = h->ps.sps;
-return ff_nvdec_frame_params(avctx, hw_frames_ctx, sps->ref_frame_count + 
sps->num_reorder_frames);
+return ff_nvdec_frame_params(avctx, hw_frames_ctx, sps->ref_frame_count + 
sps->num_reorder_frames, 0);
  }
  
  const AVHWAccel ff_h264_nvdec_hwaccel = {

diff --git a/libavcodec/nvdec_hevc.c b/libavcodec/nvdec_hevc.c
index e04a701f3a..9e726f708e 100644
--- a/libavcodec/nvdec_hevc.c
+++ b/libavcodec/nvdec_hevc.c
@@ -269,7 +269,13 @@ static int nvdec_hevc_frame_params(AVCodecContext *avctx,
  {
  const HEVCContext *s = avctx->priv_data;
  const HEVCSPS *sps = s->ps.sps;
-return ff_nvdec_frame_params(avctx, hw_frames_ctx, 
sps->temporal_layer[sps->max_sub_layers - 1].max_dec_pic_buffering + 1);
+return ff_nvdec_frame_params(avctx, hw_frames_ctx, 
sps->temporal_layer[sps->max_sub_layers - 1].max_dec_pic_buffering + 1, 1);
+}
+
+static int nvdec_hevc_decode_init(AVCodecContext *avctx) {
+NVDECContext *ctx = avctx->internal->hwaccel_priv_data;
+ctx->supports_444 = 1;
+return ff_nvdec_decode_init(avctx);
  }
  
  const AVHWAccel ff_hevc_nvdec_hwaccel = {

@@ -281,7 +287,7 @@ const AVHWAccel ff_hevc_nvdec_hwaccel = {
  .end_frame= ff_nvdec_end_frame,
  .decode_slice = nvdec_hevc_decode_slice,
  .frame_params = nvdec_hevc_frame_params,
-.init = ff_nvdec_decode_init,
+.init = nvdec_hevc_decode_init,
  .uninit   = ff_nvdec_decode_uninit,
  .priv_data_size

Re: [FFmpeg-devel] [PATCH 4/5] avcodec/cuviddec: Add support for decoding HEVC 4:4:4 content


On 20.10.2018 22:47, Philip Langdale wrote:

This is the equivalent change for cuviddec after the previous change
for nvdec. I made similar changes to the copying routines to handle
pixel formats in a more generic way.

Note that unlike with nvdec, there is no confusion about the ability
of a codec to output 444 formats. This is because the cuvid parser is
used, meaning that 444 JPEG content is still indicated as using a 420
output format.

Signed-off-by: Philip Langdale 
---
  libavcodec/cuviddec.c | 59 +--
  1 file changed, 40 insertions(+), 19 deletions(-)

diff --git a/libavcodec/cuviddec.c b/libavcodec/cuviddec.c
index f21273c07e..ca9044353d 100644
--- a/libavcodec/cuviddec.c
+++ b/libavcodec/cuviddec.c
@@ -35,6 +35,9 @@
  #include "hwaccel.h"
  #include "internal.h"
  
+#define CUVID_FORMAT_YUV444P 2

+#define CUVID_FORMAT_YUV444P16 3
+
  typedef struct CuvidContext
  {
  AVClass *avclass;
@@ -127,6 +130,7 @@ static int CUDAAPI cuvid_handle_video_sequence(void 
*opaque, CUVIDEOFORMAT* form
  CUVIDDECODECAPS *caps = NULL;
  CUVIDDECODECREATEINFO cuinfo;
  int surface_fmt;
+int chroma_444;
  
  int old_width = avctx->width;

  int old_height = avctx->height;
@@ -169,17 +173,19 @@ static int CUDAAPI cuvid_handle_video_sequence(void 
*opaque, CUVIDEOFORMAT* form
  cuinfo.target_rect.right = cuinfo.ulTargetWidth;
  cuinfo.target_rect.bottom = cuinfo.ulTargetHeight;
  
+chroma_444 = format->chroma_format == cudaVideoChromaFormat_444;

+
  switch (format->bit_depth_luma_minus8) {
  case 0: // 8-bit
-pix_fmts[1] = AV_PIX_FMT_NV12;
+pix_fmts[1] = chroma_444 ? AV_PIX_FMT_YUV444P : AV_PIX_FMT_NV12;
  caps = &ctx->caps8;
  break;
  case 2: // 10-bit
-pix_fmts[1] = AV_PIX_FMT_P010;
+pix_fmts[1] = chroma_444 ? AV_PIX_FMT_YUV444P10_MSB : AV_PIX_FMT_P010;
  caps = &ctx->caps10;
  break;
  case 4: // 12-bit
-pix_fmts[1] = AV_PIX_FMT_P016;
+pix_fmts[1] = chroma_444 ? AV_PIX_FMT_YUV444P12_MSB : AV_PIX_FMT_P016;
  caps = &ctx->caps12;
  break;
  default:
@@ -282,12 +288,6 @@ static int CUDAAPI cuvid_handle_video_sequence(void 
*opaque, CUVIDEOFORMAT* form
  return 0;
  }
  
-if (format->chroma_format != cudaVideoChromaFormat_420) {

-av_log(avctx, AV_LOG_ERROR, "Chroma formats other than 420 are not 
supported\n");
-ctx->internal_error = AVERROR(EINVAL);
-return 0;
-}
-
  ctx->chroma_format = format->chroma_format;
  
  cuinfo.CodecType = ctx->codec_type = format->codec;

@@ -301,6 +301,14 @@ static int CUDAAPI cuvid_handle_video_sequence(void 
*opaque, CUVIDEOFORMAT* form
  case AV_PIX_FMT_P016:
  cuinfo.OutputFormat = cudaVideoSurfaceFormat_P016;
  break;
+case AV_PIX_FMT_YUV444P:
+cuinfo.OutputFormat = CUVID_FORMAT_YUV444P;
+break;
+case AV_PIX_FMT_YUV444P10_MSB:
+case AV_PIX_FMT_YUV444P12_MSB:
+case AV_PIX_FMT_YUV444P16:
+cuinfo.OutputFormat = CUVID_FORMAT_YUV444P16;
+break;
  default:
  av_log(avctx, AV_LOG_ERROR, "Output formats other than NV12, P010 or P016 
are not supported\n");
  ctx->internal_error = AVERROR(EINVAL);
@@ -511,6 +519,7 @@ static int cuvid_output_frame(AVCodecContext *avctx, 
AVFrame *frame)
  return ret;
  
  if (av_fifo_size(ctx->frame_queue)) {

+const AVPixFmtDescriptor *pixdesc;
  CuvidParsedFrame parsed_frame;
  CUVIDPROCPARAMS params;
  unsigned int pitch = 0;
@@ -541,7 +550,10 @@ static int cuvid_output_frame(AVCodecContext *avctx, 
AVFrame *frame)
  goto error;
  }
  
-for (i = 0; i < 2; i++) {

+pixdesc = av_pix_fmt_desc_get(avctx->sw_pix_fmt);
+
+for (i = 0; i < pixdesc->nb_components; i++) {
+size_t height = avctx->height >> (i ? pixdesc->log2_chroma_h : 
0);


Is there a specific reason size_t is used here? It's the first use in 
the entire file.



  CUDA_MEMCPY2D cpy = {
  .srcMemoryType = CU_MEMORYTYPE_DEVICE,
  .dstMemoryType = CU_MEMORYTYPE_DEVICE,
@@ -551,22 +563,27 @@ static int cuvid_output_frame(AVCodecContext *avctx, 
AVFrame *frame)
  .dstPitch  = frame->linesize[i],
  .srcY  = offset,
  .WidthInBytes  = FFMIN(pitch, frame->linesize[i]),
-.Height= avctx->height >> (i ? 1 : 0),
+.Height= height,
  };
  
  ret = CHECK_CU(ctx->cudl->cuMemcpy2DAsync(&cpy, device_hwctx->stream));

  if (ret < 0)
  goto error;
  
-offset += avctx->height;

+offset += height;
  }
  
  ret = CHECK_CU(ctx->cudl->cuStreamSynchronize(device_hwct

Re: [FFmpeg-devel] [PATCH 5/5] avcodec/nvenc: Accept YUV444P10_MSB and YUV444P12_MSB content


On 20.10.2018 22:47, Philip Langdale wrote:

12bit is implicitly truncated to 10bit as part of doing this, but we
already do that for P016 and YUV444P16.

I've bundled a single version bump and changelog entry in this change
to reflect the updates to all three of nvdec/nvenc/cuviddec.

Signed-off-by: Philip Langdale 
---
  Changelog  |  1 +
  libavcodec/nvenc.c | 18 +-
  2 files changed, 14 insertions(+), 5 deletions(-)

diff --git a/Changelog b/Changelog
index 1b0bc95b7a..1334eec474 100644
--- a/Changelog
+++ b/Changelog
@@ -35,6 +35,7 @@ version :
  - AV1 parser
  - SER demuxer
  - sinc audio filter source
+- Support for HEVC 4:4:4 content in nvdec/nvenc/cuviddec
  
  
  version 4.0:

diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c
index e180d7b993..5be98a5182 100644
--- a/libavcodec/nvenc.c
+++ b/libavcodec/nvenc.c
@@ -41,8 +41,10 @@ const enum AVPixelFormat ff_nvenc_pix_fmts[] = {
  AV_PIX_FMT_NV12,
  AV_PIX_FMT_P010,
  AV_PIX_FMT_YUV444P,
-AV_PIX_FMT_P016,  // Truncated to 10bits
-AV_PIX_FMT_YUV444P16, // Truncated to 10bits
+AV_PIX_FMT_P016,  // Truncated to 10bits
+AV_PIX_FMT_YUV444P10_MSB,
+AV_PIX_FMT_YUV444P12_MSB, // Truncated to 10bits
+AV_PIX_FMT_YUV444P16, // Truncated to 10bits
  AV_PIX_FMT_0RGB32,
  AV_PIX_FMT_0BGR32,
  AV_PIX_FMT_CUDA,
@@ -52,11 +54,15 @@ const enum AVPixelFormat ff_nvenc_pix_fmts[] = {
  AV_PIX_FMT_NONE
  };
  
-#define IS_10BIT(pix_fmt)  (pix_fmt == AV_PIX_FMT_P010|| \

-pix_fmt == AV_PIX_FMT_P016|| \
+#define IS_10BIT(pix_fmt)  (pix_fmt == AV_PIX_FMT_P010  || \
+pix_fmt == AV_PIX_FMT_P016  || \
+pix_fmt == AV_PIX_FMT_YUV444P10_MSB || \
+pix_fmt == AV_PIX_FMT_YUV444P12_MSB || \
  pix_fmt == AV_PIX_FMT_YUV444P16)
  
-#define IS_YUV444(pix_fmt) (pix_fmt == AV_PIX_FMT_YUV444P || \

+#define IS_YUV444(pix_fmt) (pix_fmt == AV_PIX_FMT_YUV444P   || \
+pix_fmt == AV_PIX_FMT_YUV444P10_MSB || \
+pix_fmt == AV_PIX_FMT_YUV444P12_MSB || \
  pix_fmt == AV_PIX_FMT_YUV444P16)
  
  static const struct {

@@ -1263,6 +1269,8 @@ static NV_ENC_BUFFER_FORMAT nvenc_map_buffer_format(enum 
AVPixelFormat pix_fmt)
  return NV_ENC_BUFFER_FORMAT_YUV420_10BIT;
  case AV_PIX_FMT_YUV444P:
  return NV_ENC_BUFFER_FORMAT_YUV444_PL;
+case AV_PIX_FMT_YUV444P10_MSB:
+case AV_PIX_FMT_YUV444P12_MSB:
  case AV_PIX_FMT_YUV444P16:
  return NV_ENC_BUFFER_FORMAT_YUV444_10BIT;
  case AV_PIX_FMT_0RGB32:



LGTM



smime.p7s
Description: S/MIME Cryptographic Signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 0/5] Add nvidia hw decode support for HEVC 4:4:4 content


On 20.10.2018 23:00, Carl Eugen Hoyos wrote:

2018-10-20 22:46 GMT+02:00, Philip Langdale :


The big discussion was about the new pixel formats. I would
like to get to a clear conclusion on this otherwise, this patch
series goes nowhere forever


Wouldn't it be an alternative to first commit the patch with P16
and then discuss what the disadvantage is?


How would you tell apart 10 and 12 bit content?



smime.p7s
Description: S/MIME Cryptographic Signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 0/5] Add nvidia hw decode support for HEVC 4:4:4 content

2018-10-20 Thread Carl Eugen Hoyos

2018-10-20 23:16 GMT+02:00, Timo Rothenpieler :
> On 20.10.2018 23:00, Carl Eugen Hoyos wrote:
>> 2018-10-20 22:46 GMT+02:00, Philip Langdale :
>>
>>> The big discussion was about the new pixel formats. I would
>>> like to get to a clear conclusion on this otherwise, this patch
>>> series goes nowhere forever
>>
>> Wouldn't it be an alternative to first commit the patch with P16
>> and then discuss what the disadvantage is?
>
> How would you tell apart 10 and 12 bit content?

You write it into raw_bits_per_pixel.

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 5/5] avcodec/nvenc: Accept YUV444P10_MSB and YUV444P12_MSB content




On Sat, 20 Oct 2018, Timo Rothenpieler wrote:


On 20.10.2018 22:47, Philip Langdale wrote:

12bit is implicitly truncated to 10bit as part of doing this, but we
already do that for P016 and YUV444P16.



Huh? I thought one of the reasons of adding a separate pixel format is to 
be able to differentiate between the actually supported depths. If 
you do implicit depth truncation, then what is the point?


Thanks,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 5/5] avcodec/nvenc: Accept YUV444P10_MSB and YUV444P12_MSB content


On 20.10.2018 23:34, Marton Balint wrote:



On Sat, 20 Oct 2018, Timo Rothenpieler wrote:


On 20.10.2018 22:47, Philip Langdale wrote:

12bit is implicitly truncated to 10bit as part of doing this, but we
already do that for P016 and YUV444P16.



Huh? I thought one of the reasons of adding a separate pixel format is 
to be able to differentiate between the actually supported depths. If 
you do implicit depth truncation, then what is the point?


That's only nvenc, it can only encode 8 or 10 bit.
But for decoding it can actually do 12 bit.



smime.p7s
Description: S/MIME Cryptographic Signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 0/5] Add nvidia hw decode support for HEVC 4:4:4 content


On 20.10.2018 23:31, Carl Eugen Hoyos wrote:

2018-10-20 23:16 GMT+02:00, Timo Rothenpieler :

On 20.10.2018 23:00, Carl Eugen Hoyos wrote:

2018-10-20 22:46 GMT+02:00, Philip Langdale :


The big discussion was about the new pixel formats. I would
like to get to a clear conclusion on this otherwise, this patch
series goes nowhere forever


Wouldn't it be an alternative to first commit the patch with P16
and then discuss what the disadvantage is?


How would you tell apart 10 and 12 bit content?


You write it into raw_bits_per_pixel.


You mean bits_per_raw_sample?

To do that in a way that's actually usable we start going back the whole 
rabbit hole though. It starts with the field missing on frames, and goes 
on with nothing using it for video at all so far, only for audio, where 
that kinda setup is actually well supported.




smime.p7s
Description: S/MIME Cryptographic Signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/5] avcodec/nvdec: Add support for decoding HEVC 4:4:4 content

On Sat, 20 Oct 2018 22:58:34 +0200
Timo Rothenpieler  wrote:

> >   
> > +// It it semantically incorrect to use AX_PIX_FMT_YUV444P16
> > for either the 10
> > +// or 12 bit case, but ffmpeg and nvidia disagree on which end
> > the padding
> > +// bits go at. P16 is unambiguous and matches.  
> 
> This comment seems redundant, since AX_PIX_FMT_YUV444P16 isn't even
> used.

Yeah, that's outdated from the original version with no pix fmts. I'll
remove it.

> > diff --git a/libavutil/hwcontext_cuda.c b/libavutil/hwcontext_cuda.c
> > index 3b1d53e799..43337f14f0 100644
> > --- a/libavutil/hwcontext_cuda.c
> > +++ b/libavutil/hwcontext_cuda.c
> > @@ -38,6 +38,8 @@ static const enum AVPixelFormat
> > supported_formats[] = { AV_PIX_FMT_YUV444P,
> >   AV_PIX_FMT_P010,
> >   AV_PIX_FMT_P016,
> > +AV_PIX_FMT_YUV444P10_MSB,
> > +AV_PIX_FMT_YUV444P12_MSB,  
> 
> You are adding these to supported formats, but are not actually
> adding support, so cuda_frames_init and cuda_get_buffer will both run
> into the BUG case. Should be super easy, as they're identical to
> 444P16.

This actually works fine. cuda_frames_init and cuda_get_buffer both use
generic mechanisms that introspect the pix desc information.
 
> >   AV_PIX_FMT_YUV444P16,  
> Technically, this can go now. But I guess removing it is an API
> break, so it gotta stay I guess.

Right. And at the end of the day it works correctly in the context of
the hwcontext. You might feed into some theoretical filter that would
handle it appropriately. Just because nvenc can't actually consume it
fully doesn't make it wrong.

--phil
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 4/5] avcodec/cuviddec: Add support for decoding HEVC 4:4:4 content

On Sat, 20 Oct 2018 23:10:57 +0200
Timo Rothenpieler  wrote:

> >   
> > -for (i = 0; i < 2; i++) {
> > +pixdesc = av_pix_fmt_desc_get(avctx->sw_pix_fmt);
> > +
> > +for (i = 0; i < pixdesc->nb_components; i++) {
> > +size_t height = avctx->height >> (i ?
> > pixdesc->log2_chroma_h : 0);  
> 
> Is there a specific reason size_t is used here? It's the first use in 
> the entire file.

Default habit from other projects. Fixed.
 
> > +size_t offset = 0;  
> 
> Same here about size_t

Also fixed.
 
> > +for (i = 0; i < pixdesc->nb_components; i++) {
> > +tmp_frame->data[i] = (uint8_t*)mapped_frame +
> > offset;
> > +tmp_frame->linesize[i] = pitch;  
> 
> I'd kinda like to have a comment here explaining that if YUV420P
> would be used, pitch would need special handling, because it also
> gets shifted there for the U/V planes.

Added.
 
Thanks,

--phil
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/5] avcodec/nvdec: Add support for decoding HEVC 4:4:4 content




On 20.10.2018 23:52, Philip Langdale wrote:

On Sat, 20 Oct 2018 22:58:34 +0200
Timo Rothenpieler  wrote:

   
+// It it semantically incorrect to use AX_PIX_FMT_YUV444P16

for either the 10
+// or 12 bit case, but ffmpeg and nvidia disagree on which end
the padding
+// bits go at. P16 is unambiguous and matches.


This comment seems redundant, since AX_PIX_FMT_YUV444P16 isn't even
used.


Yeah, that's outdated from the original version with no pix fmts. I'll
remove it.


diff --git a/libavutil/hwcontext_cuda.c b/libavutil/hwcontext_cuda.c
index 3b1d53e799..43337f14f0 100644
--- a/libavutil/hwcontext_cuda.c
+++ b/libavutil/hwcontext_cuda.c
@@ -38,6 +38,8 @@ static const enum AVPixelFormat
supported_formats[] = { AV_PIX_FMT_YUV444P,
   AV_PIX_FMT_P010,
   AV_PIX_FMT_P016,
+AV_PIX_FMT_YUV444P10_MSB,
+AV_PIX_FMT_YUV444P12_MSB,


You are adding these to supported formats, but are not actually
adding support, so cuda_frames_init and cuda_get_buffer will both run
into the BUG case. Should be super easy, as they're identical to
444P16.


This actually works fine. cuda_frames_init and cuda_get_buffer both use
generic mechanisms that introspect the pix desc information.


Right, I had the 3.4 branch checked out when checking that...


   AV_PIX_FMT_YUV444P16,

Technically, this can go now. But I guess removing it is an API
break, so it gotta stay I guess.


Right. And at the end of the day it works correctly in the context of
the hwcontext. You might feed into some theoretical filter that would
handle it appropriately. Just because nvenc can't actually consume it
fully doesn't make it wrong.

--phil
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel





smime.p7s
Description: S/MIME Cryptographic Signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 0/5] Add nvidia hw decode support for HEVC 4:4:4 content

2018-10-20 Thread Carl Eugen Hoyos

2018-10-20 23:43 GMT+02:00, Timo Rothenpieler :
> On 20.10.2018 23:31, Carl Eugen Hoyos wrote:
>> 2018-10-20 23:16 GMT+02:00, Timo Rothenpieler :
>>> On 20.10.2018 23:00, Carl Eugen Hoyos wrote:
 2018-10-20 22:46 GMT+02:00, Philip Langdale :

> The big discussion was about the new pixel formats. I would
> like to get to a clear conclusion on this otherwise, this patch
> series goes nowhere forever

 Wouldn't it be an alternative to first commit the patch with P16
 and then discuss what the disadvantage is?
>>>
>>> How would you tell apart 10 and 12 bit content?
>>
>> You write it into raw_bits_per_pixel.
>
> You mean bits_per_raw_sample?

Yes.

> To do that in a way that's actually usable

In which way is it not usable now?

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 2/2] avcodec/ilbcdec: Check startindex

Fixes: Out of array read
Fixes: 
10789/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ILBC_fuzzer-5153255445757952

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavcodec/ilbcdec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/ilbcdec.c b/libavcodec/ilbcdec.c
index 8f234b98e1..8a6dbe0b75 100644
--- a/libavcodec/ilbcdec.c
+++ b/libavcodec/ilbcdec.c
@@ -1372,7 +1372,7 @@ static int ilbc_decode_frame(AVCodecContext *avctx, void 
*data,
 
 if (unpack_frame(s))
 mode = 0;
-if (s->frame.start < 1)
+if (s->frame.start < 1 || s->frame.start > 5)
 mode = 0;
 
 if (mode) {
-- 
2.19.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 1/2] avcodec/jpeg2000dec: Fix off by 1 error in JPEG2000_PGOD_CPRL handling

Fixes: assertion failure
Fixes: 
10785/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_JPEG2000_fuzzer-5672160496975872

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavcodec/jpeg2000dec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/jpeg2000dec.c b/libavcodec/jpeg2000dec.c
index 96dab8e176..5b07f07aa9 100644
--- a/libavcodec/jpeg2000dec.c
+++ b/libavcodec/jpeg2000dec.c
@@ -1162,7 +1162,7 @@ static int 
jpeg2000_decode_packets_po_iteration(Jpeg2000DecoderContext *s, Jpeg2
 step_x = 32;
 step_y = 32;
 
-if (RSpoc > FFMIN(codsty->nreslevels, REpoc))
+if (RSpoc >= FFMIN(codsty->nreslevels, REpoc))
 continue;
 
 for (reslevelno = RSpoc; reslevelno < FFMIN(codsty->nreslevels, 
REpoc); reslevelno++) {
-- 
2.19.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/mpeg4videodec: Fix typo in sprite delta check

On Thu, Oct 18, 2018 at 01:54:02AM +0200, Michael Niedermayer wrote:
> Fixes: Integer overflow
> Fixes: 
> 10890/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MPEG4_fuzzer-5636062181851136
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/mpeg4videodec.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

will apply

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The misfortune of the wise is better than the prosperity of the fool.
-- Epicurus


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] fftools/ffmpeg.c: allow forcing input framerate on streamcopy