Re: [FFmpeg-devel] [PATCH] Fix iterating of input and output devices

[Timo Rothenpieler]

Am 16.03.2018 um 10:52 schrieb Timo Rothenpieler:

Will push tomorrow unless someone sees a problem with this.



applied



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

[FFmpeg-devel] [PATCH] avformat/hlsenc: initialize saveptrs

[Timo Rothenpieler]

av_strtok calls strspn on a non-NULL *saveptr, so not NULL initializing it is 
an issue.

Fixes CID #1428568
---
 libavformat/hlsenc.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index b7c6fbde6a..fa17776efe 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -1873,7 +1873,8 @@ static int parse_cc_stream_mapstring(AVFormatContext *s)
 {
 HLSContext *hls = s->priv_data;
 int nb_ccstreams;
-char *p, *q, *saveptr1, *saveptr2, *ccstr, *keyval;
+char *p, *q, *ccstr, *keyval;
+char *saveptr1 = NULL, *saveptr2 = NULL;
 const char *val;
 ClosedCaptionsStream *ccs;
 
-- 
2.16.2

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

Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: initialize saveptrs

[Timo Rothenpieler]

Am 21.03.2018 um 20:33 schrieb Timo Rothenpieler:

av_strtok calls strspn on a non-NULL *saveptr, so not NULL initializing it is 
an issue.

Fixes CID #1428568
---
  libavformat/hlsenc.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index b7c6fbde6a..fa17776efe 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -1873,7 +1873,8 @@ static int parse_cc_stream_mapstring(AVFormatContext *s)
  {
  HLSContext *hls = s->priv_data;
  int nb_ccstreams;
-char *p, *q, *saveptr1, *saveptr2, *ccstr, *keyval;
+char *p, *q, *ccstr, *keyval;
+char *saveptr1 = NULL, *saveptr2 = NULL;
  const char *val;
  ClosedCaptionsStream *ccs;


Just realized, the more correct approach is probably to check the 
av_strdup below this for ENOMEM. Not sure about the exact semantics 
there, initializing these still seems like a good safety measure.




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

[FFmpeg-devel] [PATCH] configure: rename cuda to ffnvcodec

[Timo Rothenpieler]

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 it's not what they need.

This will make it complain about ffnvcodec instead.

Signed-off-by: Timo Rothenpieler <t...@rothenpieler.org>
---
 configure | 28 
 1 file changed, 16 insertions(+), 12 deletions(-)

diff --git a/configure b/configure
index fe81ba31b5..5fbab4501d 100755
--- a/configure
+++ b/configure
@@ -307,11 +307,11 @@ External library support:
   The following libraries provide various hardware acceleration features:
   --disable-amfdisable AMF video encoding code [autodetect]
   --disable-audiotoolbox   disable Apple AudioToolbox code [autodetect]
-  --disable-cuda   disable dynamically linked Nvidia CUDA code 
[autodetect]
   --enable-cuda-sdkenable CUDA features that require the CUDA SDK [no]
   --disable-cuvid  disable Nvidia CUVID support [autodetect]
   --disable-d3d11vadisable Microsoft Direct3D 11 video acceleration 
code [autodetect]
   --disable-dxva2  disable Microsoft DirectX 9 video acceleration code 
[autodetect]
+  --disable-ffnvcodec  disable dynamically linked Nvidia code [autodetect]
   --enable-libdrm  enable DRM code (Linux) [no]
   --enable-libmfx  enable Intel MediaSDK (AKA Quick Sync Video) code 
via libmfx [no]
   --enable-libnpp  enable Nvidia Performance Primitives-based code [no]
@@ -1660,6 +1660,7 @@ HWACCEL_AUTODETECT_LIBRARY_LIST="
 cuvid
 d3d11va
 dxva2
+ffnvcodec
 nvdec
 nvenc
 vaapi
@@ -2675,11 +2676,12 @@ zmbv_encoder_deps="zlib"
 
 # hardware accelerators
 crystalhd_deps="libcrystalhd_libcrystalhd_if_h"
-cuda_deps_any="libdl LoadLibrary"
-cuvid_deps="cuda"
+cuda_deps="ffnvcodec"
+cuvid_deps="ffnvcodec"
 d3d11va_deps="dxva_h ID3D11VideoDecoder ID3D11VideoContext"
 dxva2_deps="dxva2api_h DXVA2_ConfigPictureDecode ole32 user32"
-nvdec_deps="cuda"
+ffnvcodec_deps_any="libdl LoadLibrary"
+nvdec_deps="ffnvcodec"
 videotoolbox_hwaccel_deps="videotoolbox pthreads"
 videotoolbox_hwaccel_extralibs="-framework QuartzCore"
 xvmc_deps="X11_extensions_XvMClib_h"
@@ -2797,13 +2799,13 @@ qsvvpp_select="qsv"
 vaapi_encode_deps="vaapi"
 v4l2_m2m_deps_any="linux_videodev2_h"
 
-hwupload_cuda_filter_deps="cuda"
-scale_npp_filter_deps="cuda libnpp"
+hwupload_cuda_filter_deps="ffnvcodec"
+scale_npp_filter_deps="ffnvcodec libnpp"
 scale_cuda_filter_deps="cuda_sdk"
 thumbnail_cuda_filter_deps="cuda_sdk"
 
 amf_deps_any="libdl LoadLibrary"
-nvenc_deps="cuda"
+nvenc_deps="ffnvcodec"
 nvenc_deps_any="libdl LoadLibrary"
 nvenc_encoder_deps="nvenc"
 
@@ -3357,7 +3359,7 @@ avformat_deps="avcodec avutil"
 avformat_suggest="libm network zlib"
 avresample_deps="avutil"
 avresample_suggest="libm"
-avutil_suggest="clock_gettime cuda libm libdrm libmfx opencl user32 vaapi 
videotoolbox corefoundation corevideo coremedia wincrypt"
+avutil_suggest="clock_gettime ffnvcodec libm libdrm libmfx opencl user32 vaapi 
videotoolbox corefoundation corevideo coremedia wincrypt"
 postproc_deps="avutil gpl"
 postproc_suggest="libm"
 swresample_deps="avutil"
@@ -5811,8 +5813,10 @@ check_type "va/va.h va/va_enc_vp9.h"  
"VAEncPictureParameterBufferVP9"
 
 check_type "vdpau/vdpau.h" "VdpPictureInfoHEVC"
 
-check_pkg_config cuda "ffnvcodec >= 8.0.14.1" \
-"ffnvcodec/nvEncodeAPI.h ffnvcodec/dynlink_cuda.h 
ffnvcodec/dynlink_cuviddec.h ffnvcodec/dynlink_nvcuvid.h" ""
+if ! disabled ffnvcodec; then
+check_pkg_config ffnvcodec "ffnvcodec >= 8.0.14.1" \
+"ffnvcodec/nvEncodeAPI.h ffnvcodec/dynlink_cuda.h 
ffnvcodec/dynlink_cuviddec.h ffnvcodec/dynlink_nvcuvid.h" ""
+fi
 
 check_cpp_condition windows.h 
"!WINAPI_FAMILY_PARTITION(WINAPI_PARTITION_DESKTOP)" && enable winrt || disable 
winrt
 
@@ -6257,11 +6261,11 @@ if enabled x86; then
 mingw32*|mingw64*|win32|win64|linux|cygwin*)
 ;;
 *)
-disable cuda cuvid nvdec nvenc
+disable ffnvcodec cuvid nvdec nvenc
 ;;
 esac
 else
-disable cuda cuvid nvdec nvenc
+disable ffnvcodec cuvid nvdec nvenc
 fi
 
 enabled nvenc &&
-- 
2.15.1

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

Re: [FFmpeg-devel] [PATCH] compat: remove in-tree NVidia headers

[Timo Rothenpieler]

Am 05.03.2018 um 20:46 schrieb Lou Logan:

On Tue, Feb 27, 2018, at 6:24 AM, Timo Rothenpieler wrote:


Patch applied.


Could you mention the new repo, and perhaps some simple instructions, on 
HWAccelIntro? I've seen a few confused users. I would but I'm not a HW user and 
I don't want to add anything incorrect.


I tried to do that multiple times already, but trac won't let me login, 
it just eventually runs into a Gateway Timeout if I try.




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] configure: rename cuda to ffnvcodec

[Timo Rothenpieler]

Am 04.03.2018 um 20:15 schrieb Compn:

On Sat,  3 Mar 2018 22:39:45 +0100, Timo Rothenpieler
<t...@rothenpieler.org> 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 it's not what they need.

This will make it complain about ffnvcodec instead.


i'm not objecting.

but if you put a error message that explains what a person needs when
it errors , that might also be a good idea (and it would also only be
a one or two line change).

-compn


I looked into doing that, but the code handling those errors in a 
generic way would need quite some ugly special cases to do that.


Still, I might look into giving a better error that at some point.

It being called cuda is inaccurate anyway, so renaming it to ffnvcodec 
is not too terrible.


So for now, I just pushed this, and will look into a more verbose error 
later.




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] compat: remove in-tree NVidia headers

[Timo Rothenpieler]

Am 05.03.2018 um 21:17 schrieb Lou Logan:

On Mon, Mar 5, 2018, at 11:07 AM, Timo Rothenpieler wrote:


I tried to do that multiple times already, but trac won't let me login,
it just eventually runs into a Gateway Timeout if I try.


Weird. I can't duplicate that issue. Is anyone else experiencing this?

If you give me the info I can add it until we figure out the trac issue.


It worked now, added the necessary info.



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 3/3] avcodec/nvenc: Declare support for P016

[Timo Rothenpieler]

On 02.03.2018 05:26, Philip Langdale wrote:
> nvenc doesn't support P016, but we have two problems today:
> 
> 1) We declare support for YUV444P16 which nvenc also doesn't support.
>We do this because it's the only pix_fmt we have that can
>approximate nvenc's internal format that is YUV444P10 with data in
>MSBs instead of LSBs. Because the declared format is a 16bit one,
>it will be preferrentially chosen when encoding >10bit content,
>but that content will normally be YUV420P12 or P016 which should
>get mapped to P010 and not YUV444P10.
> 
> 2) Transcoding P016 content with nvenc should be possible in a pure
>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 do this 'properly'.
> 
> Signed-off-by: Philip Langdale 
> ---
>  libavcodec/nvenc.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c
> index 161c56adc2..e00c1fb245 100644
> --- a/libavcodec/nvenc.c
> +++ b/libavcodec/nvenc.c
> @@ -41,7 +41,8 @@ const enum AVPixelFormat ff_nvenc_pix_fmts[] = {
>  AV_PIX_FMT_NV12,
>  AV_PIX_FMT_P010,
>  AV_PIX_FMT_YUV444P,
> -AV_PIX_FMT_YUV444P16,
> +AV_PIX_FMT_P016,  // Truncated to 10bits
> +AV_PIX_FMT_YUV444P16, // Truncated to 10bits
>  AV_PIX_FMT_0RGB32,
>  AV_PIX_FMT_0BGR32,
>  AV_PIX_FMT_CUDA,
> @@ -52,6 +53,7 @@ const enum AVPixelFormat ff_nvenc_pix_fmts[] = {
>  };
>  
>  #define IS_10BIT(pix_fmt)  (pix_fmt == AV_PIX_FMT_P010|| \
> +pix_fmt == AV_PIX_FMT_P016|| \
>  pix_fmt == AV_PIX_FMT_YUV444P16)
>  
>  #define IS_YUV444(pix_fmt) (pix_fmt == AV_PIX_FMT_YUV444P || \
> @@ -1222,6 +1224,7 @@ static NV_ENC_BUFFER_FORMAT 
> nvenc_map_buffer_format(enum AVPixelFormat pix_fmt)
>  case AV_PIX_FMT_NV12:
>  return NV_ENC_BUFFER_FORMAT_NV12_PL;
>  case AV_PIX_FMT_P010:
> +case AV_PIX_FMT_P016:
>  return NV_ENC_BUFFER_FORMAT_YUV420_10BIT;
>  case AV_PIX_FMT_YUV444P:
>  return NV_ENC_BUFFER_FORMAT_YUV444_PL;
> 

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 them.



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] Access to cuda functions

[Timo Rothenpieler]

I can't think of a situation where there'd possibly be more than one
nvidia driver installed on a system.
And even if, the same application loading a lib of the same name will
internally hit its reference counter and just use the exact same one again.



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

Re: [FFmpeg-devel] [PATCH 1/1] make headers compile in c++ mode

[Timo Rothenpieler]

On 26.04.2018 14:47, Daniel Oberhoff wrote:
> ---
>  include/ffnvcodec/dynlink_loader.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/ffnvcodec/dynlink_loader.h 
> b/include/ffnvcodec/dynlink_loader.h
> index 352a0c8..3b0a284 100644
> --- a/include/ffnvcodec/dynlink_loader.h
> +++ b/include/ffnvcodec/dynlink_loader.h
> @@ -114,7 +114,7 @@
>   \
>  n##_free_functions(functions);   \
>   \
> -f = *functions = calloc(1, sizeof(*f));  \
> +f = *functions = (T*)calloc(1, sizeof(*f));  \
>  if (!f)  \
>  return -1;   \
>   \

applied



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

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

[Timo Rothenpieler]

On 07.10.2018 04:19, 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.
---
  libavcodec/hevcdec.c |  2 ++
  libavcodec/nvdec.c   | 43 +++
  2 files changed, 37 insertions(+), 8 deletions(-)

diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
index a3b5c8cb71..508e093ea3 100644
--- a/libavcodec/hevcdec.c
+++ b/libavcodec/hevcdec.c
@@ -409,6 +409,8 @@ static enum AVPixelFormat get_format(HEVCContext *s, const 
HEVCSPS *sps)
  #endif
  break;
  case AV_PIX_FMT_YUV420P12:
+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..7e5c1791ea 100644
--- a/libavcodec/nvdec.c
+++ b/libavcodec/nvdec.c
@@ -34,6 +34,9 @@
  #include "nvdec.h"
  #include "internal.h"
  
+#define cudaVideoSurfaceFormat_YUV444P 2

+#define cudaVideoSurfaceFormat_YUV444P16 3


This will probably collide once the headers add those values, not sure 
how to properly handle that, but they at least should have a different 
naming scheme.



  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 ? cudaVideoSurfaceFormat_YUV444P :
+ cudaVideoSurfaceFormat_NV12;
+break;
+case 10:
+case 12:
+output_format = chroma_444 ? cudaVideoSurfaceFormat_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, _h, _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 

Re: [FFmpeg-devel] [PATCH 1/5] avutil: Add YUV444P10_LSB and YUV444P12_LSB pixel formats

[Timo Rothenpieler]

On 08/10/2018 09:24, Marton Balint wrote:



On Sun, 7 Oct 2018, Philip Langdale wrote:


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 MSBs 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 LSBs, 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.


MSB and LSB is mixed up as far as I understand.

In classic formats ffmpeg stores data in low bits, the least significant 
bits of 16 bit values.


In P010 and so on the docs says "zeros are in the low bits", therefore 
data is in the high bits, which are the most significant ones.


Am I missing something?

Otherwise, I dont't disagree that this is the 
fastest/easiest/least-error-prone way to add support for this, but it 
sure feels like JUVJ formats all over again.




Yes, the padding is in the LSB, data in MSB. _MSB is probably the better 
name then.


I don't think it's YUVJ all over again, as it was the exact same bit 
layout than normal YUV, while this one is actually different.





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] #7496: Access to the reference track (dolby vision) of a stream

[Timo Rothenpieler]

On 16.10.2018 19:25, dmitrij.gresser...@loewe.de wrote:

Hello,

i need access to the reference track of a stream in a mp4 file.
ISO/IEC 14496-12:2005 describes this as the track_ID of the Track Reference Box.
Here is my approach attached as a patch.


Adding a field just for this seems a bit weird.
It probably should add this as side data via av_stream_add_side_data 
instead.




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] avcodec/imm4: improve decoding of some files

[Timo Rothenpieler]

> @@ -205,9 +206,26 @@ static int decode_blocks(AVCodecContext *avctx, 
GetBitContext *gb,
>  static int decode_intra(AVCodecContext *avctx, GetBitContext *gb, 
AVFrame *frame)

>  {
>  IMM4Context *s = avctx->priv_data;
> -int ret, x, y;
> +int ret, x, y, offset = 0;
>
> -s->factor = intra_cb[s->sindex];
> +if (s->hi == 0) {
> +if (s->lo > 2)
> +return AVERROR_INVALIDDATA;
> +s->factor = intra_cb[s->lo];
> +} else {
> +if (s->hi == 1) {
> +s->factor = s->lo * 2;
> +} else {
> +s->factor = s->lo * 2;
> +}
> +}

This if-branch does not look like it does what it's intended to do.

> @@ -244,9 +262,26 @@ static int decode_inter(AVCodecContext *avctx, 
GetBitContext *gb,

>  AVFrame *frame, AVFrame *prev)
>  {
>  IMM4Context *s = avctx->priv_data;
> -int ret, x, y;
> +int ret, x, y, offset = 0;
>
> -s->factor = inter_cb[s->sindex];
> +if (s->hi == 0) {
> +if (s->lo > 2)
> +return AVERROR_INVALIDDATA;
> +s->factor = inter_cb[s->lo];
> +} else {
> +if (s->hi == 1) {
> +s->factor = s->lo * 2;
> +} else {
> +s->factor = s->lo * 2;
> +}
> +}

Same here



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

[Timo Rothenpieler]

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] libavfilter/vaapi: enable vaapi rotation feature via call Intel iHD driver

[Timo Rothenpieler]

On 23.10.2018 10:55, Moritz Barsnick wrote:

On Tue, Oct 23, 2018 at 15:52:40 +0800, Zachary Zhou wrote:

It supports clockwise rotation by 0/90/180/270 degrees defined in
va/va_vpp.h, tested following command line on SKL platform


Since these angles of rotation are called "transpose" in ffmpeg's other
filters (transpose, transpose_npp), shouldn't that be the name chosen
for this functionality?

It could then also use similar options.

Just wondering.


The transpose filters do not do plain rotation, they also flip the image 
at the same time. For reasons I'm not sure about that's more useful than 
plain rotation by multiples of 90°.

From the looks of it, this filter does not do any flipping.



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/3] avfilter/vf_yadif_cuda: CUDA accelerated deinterlacer

[Timo Rothenpieler]

Not an export on CUDA code but it looks sensible to me, C part looks 
good as well.


GTM once the yadiff changes have been acked.



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/3] avfilter/vf_yadif_cuda: CUDA accelerated deinterlacer

[Timo Rothenpieler]

On 01.11.2018 21:54, Carl Eugen Hoyos wrote:

2018-10-26 17:56 GMT+02:00, Philip Langdale :

Could you add some sample numbers about how fast the cuda
variant is compared to cpu?


I don't think such numbers are overly useful by themselves.
The primary benefit here is that it's now possible to decode, 
deinterlace and encode all without pulling the frames out of VRAM.


Though it would definitely be interesting. I guess hwupload + yadif_cuda 
+ hwdownload vs. normal yadif is a fair comparison?




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 3/3] avcodec/nvdec: Increase frame pool size to help deinterlacing

[Timo Rothenpieler]

On 26.10.2018 17:56, Philip Langdale wrote:

With the cuda yadif filter in use, the number of mapped decoder
frames could increase by two, as the filter holds on to additional
frames.

Signed-off-by: Philip Langdale 
---
  libavcodec/nvdec.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/nvdec.c b/libavcodec/nvdec.c
index 4dd6b1acf3..8e91c36084 100644
--- a/libavcodec/nvdec.c
+++ b/libavcodec/nvdec.c
@@ -601,7 +601,7 @@ int ff_nvdec_frame_params(AVCodecContext *avctx,
  frames_ctx->format= AV_PIX_FMT_CUDA;
  frames_ctx->width = (avctx->coded_width + 1) & ~1;
  frames_ctx->height= (avctx->coded_height + 1) & ~1;
-frames_ctx->initial_pool_size = dpb_size;
+frames_ctx->initial_pool_size = dpb_size + 2;


A small comment here as to where that magic +2 is coming from and it's GTM.



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] Add CUDA function cuDeviceGetAttribute

[Timo Rothenpieler]

On 02.11.2018 00:09, Soft Works wrote:

That enum is _way_ too massive. Most of that seems entirely useless in
the context of ffmpeg anyway, like all the 1D and 3D stuff, and probably
most of the 2D stuff as well.


I copied the full enum to have an exact match to cuda.h, but no problem, I can 
trim it down.


Can you trim it down to only those exact ones you need? Also, just get
rid of the comments, we're not doing that anywhere else anyway.


I kept them because dynlink_cuviddec.h has all comments included as well.
Should I still remove them in this case?


Those headers come straight from nvidia under a free license(MIT) and 
are just slightly modified for better compatibility.


There is no such thing for CUDA sadly.



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] Add CUDA function cuDeviceGetAttribute

[Timo Rothenpieler]

That enum is _way_ too massive. Most of that seems entirely useless in 
the context of ffmpeg anyway, like all the 1D and 3D stuff, and probably 
most of the 2D stuff as well.


Can you trim it down to only those exact ones you need? Also, just get 
rid of the comments, we're not doing that anywhere else anyway.




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] Maintainer of nv-codec-headers

[Timo Rothenpieler]

Send a patch to this list and I'll see if I can add it.



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] Add CUDA function cuDeviceGetAttribute V2

[Timo Rothenpieler]

LGTM, will apply next time I get a chance.



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] avfilter/vf_transpose_npp: adding NV12 support to transpose_npp filter

[Timo Rothenpieler]

On 02/11/2018 13:35, Roman Arzumanyan wrote:

Hello,

This patch adds NV12 support to vf_transpose_npp filter.
Now filter can be used in nvdec -> nvenc transcoding scenarios like this:
ffmpeg -hwaccel cuvid -c:v h264_cuvid  -i input.h264 -c:v h264_nvenc -vf 
transpose_npp="dir=clock" -y output.h264

--
BR, Roman Arzumanyan


This was intentionally omitted to avoid code duplication with scale_npp.

What you can do right now is
-vf scale_npp=format=yuv420p,transpose_npp=dir=clock

Optionally another ,scale_npp=format=nv12 at the end, to go back to 
nv12. But as nvenc can take yuv420p input, this is not necessary in most 
cases.


This should perform the exact same operations as adding the 
de/interleaving functionality to the transpose_npp filter itself, and 
thus not perform worse in any way.




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 3/5] avcodec/nvdec: Explicitly mark codecs that support 444 output formats

[Timo Rothenpieler]

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

[Timo Rothenpieler]

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 = >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 = >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 = >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(, device_hwctx->stream));

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

+offset += height;
  }
  
  ret = CHECK_CU(ctx->cudl->cuStreamSynchronize(device_hwctx->stream));

 

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

[Timo Rothenpieler]

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

[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?



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 5/5] avcodec/nvenc: Accept YUV444P10_MSB and YUV444P12_MSB content

[Timo Rothenpieler]

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

[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?

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 1/5] avutil: Add YUV444P10_LSB and YUV444P12_LSB pixel formats

[Timo Rothenpieler]

On 09/10/2018 02:32, Carl Eugen Hoyos wrote:

2018-10-08 21:59 GMT+02:00, Timo Rothenpieler :

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.


Sorry if this was already done and I forgot but please explain why
you cannot use YUV444P16 for this use-case.

If the only thing missing is libavfilter understanding
bits_per_raw_sample
we should add it there: It is needed in any case and would save us a few
pix_fmts and could speed up many use cases compared to your solution.


It's pretty much all of ffmpeg and all client applications understanding
it.
First of all, bits_per_raw_sample, or an equivalent bit depth field, is
missing from AVFrame.
"In" avfilter it's primarily swscale I guess, but it also affects each
and every filter supporting YUV444P16.
Also, for encoders, it would mean they need a way to indicate what bit
depths they can take, and that also has to be per pix_fmt they support.
Then all of avcodec, ffmpeg.c, ... needs support for that.
It's quite a deep rabit hole of changes with quite a good chance of
something going horribly wrong in the process. Probably even in more
places than just the ones mentioned here.


This may or may not be true, unfortunately my question was not
how difficult it would be to fix this mess (I don't think it is), but
why you want to add more to the mess.

What would happen if you just use YUV444P16?


For example nvenc only supports 10 bit encoding, but takes it in the 
YUV444P16 format. The rest of ffmpeg has no idea it only supports 10 
bit, and at times even up-converts 10 bit content to 16 bit via swscale 
due to that.
Also, it loses quality without the user noticing, as there is no outside 
indication it does in fact not support 16 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] avcodec/libopenh264enc.c

[Timo Rothenpieler]

This patch is corrupted, also needs a more meaningful commit message.



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 1/5] avutil: Add YUV444P10_LSB and YUV444P12_LSB pixel formats

[Timo Rothenpieler]

On 07.10.2018 19:50, Philip Langdale wrote:

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 MSBs 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 LSBs, 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.


I'm very much in favor of adding those, and potentially similar other 
ones in the future.
The other option is to add a bit depth field to AVFrame, and changes in 
various places to support it, including logic for encoder to signal 
support for pix_fmt/bit_depth support.
The later approach, while it does seem cleaner, also seems very error 
prone and invasive, so I'd prefer adding the few cases we have as pixel 
formats.




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 1/5] avutil: Add YUV444P10_LSB and YUV444P12_LSB pixel formats

[Timo Rothenpieler]

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.


Sorry if this was already done and I forgot but please explain why
you cannot use YUV444P16 for this use-case.

If the only thing missing is libavfilter understanding bits_per_raw_sample
we should add it there: It is needed in any case and would save us a few
pix_fmts and could speed up many use cases compared to your solution.


It's pretty much all of ffmpeg and all client applications understanding it.
First of all, bits_per_raw_sample, or an equivalent bit depth field, is 
missing from AVFrame.
"In" avfilter it's primarily swscale I guess, but it also affects each 
and every filter supporting YUV444P16.
Also, for encoders, it would mean they need a way to indicate what bit 
depths they can take, and that also has to be per pix_fmt they support.

Then all of avcodec, ffmpeg.c, ... needs support for that.
It's quite a deep rabit hole of changes with quite a good chance of 
something going horribly wrong in the process. Probably even in more 
places than just the ones mentioned here.




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] avfilter/vf_transpose adding NPP transpose filter

[Timo Rothenpieler]

I did some re-formating and added the missing configure bit.
Updated patch for that can be found on Github:

https://github.com/BtbN/FFmpeg/commit/3e9ad52cfbebfade0d26758dad862e0c0a002c91

https://github.com/BtbN/FFmpeg/commit/3e9ad52cfbebfade0d26758dad862e0c0a002c91.patch



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] avfilter/vf_transpose adding NPP transpose filter

[Timo Rothenpieler]

Minus the missing configure dependency, documentation entry and minor 
bump, the filter looks fine to me code wise.


Two issues though:

From my understanding, it's not a transpose filter, but a rotation one, 
fixed to 90 degree angles. Unless I'm missing something in the code, 
it's not doing any actual flipping, like vf_transpose does.
It should also be calling nppiTranspose_8u_C1R somewhere after/before 
the call to nppiRotate_8u_C1R. Or use a transformation matrix to do the 
transposition in one step, assuming libnpp has a function for that.


It's possible that I missed it doing the transpose somewhere, so please 
correct me if I'm wrong.


I'd also strongly prefer this filter to be compatible with the arguments 
of normal vf_transpose, and behave the same for the same arguments. 
Additional parameters with more functions are fine.




Timo



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] FFmpeg 4.1

[Timo Rothenpieler]

On 20/09/2018 00:32, Michael Niedermayer wrote:

On Wed, Sep 19, 2018 at 10:31:19PM +0200, Marton Balint wrote:



On Fri, 14 Sep 2018, Michael Niedermayer wrote:


Hi all

its almost 5 months since 4.0 so its time to make a new release.

Are there any suggestions for a name ?
If not ill pick something from unused past suggestions.

If there are no objections i will likely make that release in the next
weeks


Whatever happened to Coverity, it would be nice make it work again and fix
some issues reported there before the release...


well, i wonder too what happened. I thought the coverity stuff was
automated now.
Did something get stuck ?
coverity displays "Last Build Status: Running. Your build is currently being 
analyzed"
should i try to terminate it ? or was there an issue with the submitting and
someone just fixed that ?



The automated builds are still running fine, but something on their end 
got horribly stuck, and so far every attempt of mine to contact them was 
ignored.
If we have an official contact that could ask them what's going on, that 
would be very nice.




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]lavd: Remove libndi newtek

[Timo Rothenpieler]

I contacted NewTek about this, here's the pretty much immediate response 
I got:


On 03.12.2018 18:55, Andrew Cross  wrote:

Yikes, I am pretty surprised by this to be honest I think that our intent might 
have been entirely misconstrued.

We are in no way trying to abuse anything anyone did and if they want us to not 
distribute FFMPEG then we'd be very happy to stop doing that ... we did this 
purely as a public service because loads of people complained (hundreds) to use 
about NDI not being part of the FFMPEG nightly builds. We had initially tried 
to help make it part of the nightly builds but got a lot of push-back and it 
did not seem worth the fight (our headers are MIT licensed and you can download 
our run-times for free, so it is no different than say nvEnc, etc... that are 
all parts of the builds). At the end of the day, we make no money of NDI and 
just give it away and support it for free so it is hardly part of an evil ploy 
to corrupt anyone ;)

I'd prefer not to jump in the middle of the thread, but we are happy to work 
with anyone on this, our only goal is to serve people using NDI and if FFMPEG 
do not want us to distribute it then we're happy to do that, likewise if they 
want us to change the options we're also happy to do that. We'd be happy to do 
what we reasonably can for it to be part of the nightly builds as well ...

Feel free to pass this along and anyone can email me directly who wants too.

Andrew



I think the easiest way out here would be to make an LGPL build instead?
libndi can still be enabled then, but the build isn't nonfree.
libx264 would have to go, but that's probably still better for them than 
removing ffmpeg entirely.




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

[FFmpeg-devel] [PATCH] lavc/decode: allow users to shrink the hw frames pool size, if they so desire.

[Timo Rothenpieler]

---
 libavcodec/decode.c| 9 +
 libavcodec/options_table.h | 2 +-
 2 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index c89c77c43a..08ae8788a2 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -1256,10 +1256,11 @@ int avcodec_get_hw_frames_parameters(AVCodecContext 
*avctx,
 AVHWFramesContext *frames_ctx = (AVHWFramesContext*)frames_ref->data;
 
 if (frames_ctx->initial_pool_size) {
-// If the user has requested that extra output surfaces be
-// available then add them here.
-if (avctx->extra_hw_frames > 0)
-frames_ctx->initial_pool_size += avctx->extra_hw_frames;
+// If the user has requested extra/fewer output surfaces be
+// available then add/substract them here.
+frames_ctx->initial_pool_size += avctx->extra_hw_frames;
+if (avctx->extra_hw_frames < 0)
+av_log(avctx, AV_LOG_WARNING, "Decreasing hwaccel frame pool 
size!\n");
 
 // If frame threading is enabled then an extra surface per thread
 // is also required.
diff --git a/libavcodec/options_table.h b/libavcodec/options_table.h
index 099261e168..af0ab1cfe0 100644
--- a/libavcodec/options_table.h
+++ b/libavcodec/options_table.h
@@ -478,7 +478,7 @@ static const AVOption avcodec_options[] = {
 {"ignore_level", "ignore level even if the codec level used is unknown or 
higher than the maximum supported level reported by the hardware driver", 0, 
AV_OPT_TYPE_CONST, { .i64 = AV_HWACCEL_FLAG_IGNORE_LEVEL }, INT_MIN, INT_MAX, V 
| D, "hwaccel_flags" },
 {"allow_high_depth", "allow to output YUV pixel formats with a different 
chroma sampling than 4:2:0 and/or other than 8 bits per component", 0, 
AV_OPT_TYPE_CONST, {.i64 = AV_HWACCEL_FLAG_ALLOW_HIGH_DEPTH }, INT_MIN, 
INT_MAX, V | D, "hwaccel_flags"},
 {"allow_profile_mismatch", "attempt to decode anyway if HW accelerated 
decoder's supported profiles do not exactly match the stream", 0, 
AV_OPT_TYPE_CONST, {.i64 = AV_HWACCEL_FLAG_ALLOW_PROFILE_MISMATCH }, INT_MIN, 
INT_MAX, V | D, "hwaccel_flags"},
-{"extra_hw_frames", "Number of extra hardware frames to allocate for the 
user", OFFSET(extra_hw_frames), AV_OPT_TYPE_INT, { .i64 = -1 }, -1, INT_MAX, 
V|D },
+{"extra_hw_frames", "Number of extra hardware frames to allocate for the user, 
negative values are supported at own risk", OFFSET(extra_hw_frames), 
AV_OPT_TYPE_INT, { .i64 = 0 }, INT_MIN, INT_MAX, V|D },
 {NULL},
 };
 
-- 
2.17.0

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

Re: [FFmpeg-devel] [PATCH] lavc/decode: allow users to shrink the hw frames pool size, if they so desire.

[Timo Rothenpieler]

On 25/11/2018 15:05, Mark Thompson wrote:

I see what you're trying to do here, but I'm not sure that overloading this option is the 
best way to achieve it.  This option has a specific meaning in terms of the consumer of 
the frames, and is intended to be negotiated (any consumers of hardware frames should 
declare how many they will hold onto at most in a given configuration), but since that is 
very much configuration-dependent it hasn't yet been done.  Setting it to, for example, 
-3 ends up saying "I want the frame pool to be large enough for the consumer to be 
able to hold onto at most -2 frames at any given time", which is nonsensical in the 
meaning of the particular option.

Presumably the case you're actually imagining wanting this option is to reduce 
memory use when a stream doesn't actually use the maximum number of reference 
frames - given that this is generally signalled in the stream, can you instead 
propagate the real number of reference frames into the allocation so that it 
uses the correct number rather than the maximum?  Alternatively, if you have 
some particular program in mind then it could just use hw_frames_ctx rather 
than hw_device_ctx and do this allocation itself.


The case I'm targeting is that for example the CUDA yadif filter needs 
to hold onto a buffer of up to 2 frames, which it in turn steals from 
the nvdec decoders buffer. But if you don't use yadif, that's 2 unused 
frames, which is potentially quite a bit of VRAM.


nvdec already uses some logic based on the stream, but that logic is 
sometimes wrong in both directions. So the idea here is to give the user 
an option to optimize a given commandline for memory use.




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] libavfilter: scale_cuda filter adds dynamic command values

[Timo Rothenpieler]

On 26.11.2018 19:09, msanders wrote:

Hi,

This patch adds command support for dynamic change the size in the “scale_cuda” 
resize filter. In fact, it’s the first GPU filter accepting realtime commands. 
Using similar changes it’s possible to port it to other hwaccelerators. The 
only limitation is that the values cannot exceed the initial values. It is 
therefore necessary to set up the graph with the higher values you may need.

One example: { -filter_complex "scale_cuda=720:576,hwdownload,format=nv12,zmq" }
And then you can use the  or ZMQ messages to change the width and/or height.

Warning: This patch requires, to have sense, to apply too this other patch that 
fixes the hwdownload filter.
https://patchwork.ffmpeg.org/patch/11165/



I'm not sure if this is such a good idea. There's a lot of places all 
over the codebase that have a hardcoded assumption about how hardware 
frames in general, and CUDA frames in particular work.


A lot of code checks the width/height from the hwframes ctx instead of 
the frame itself, because it needs the real size(1088 for 1080p for 
example) of the underlying buffer at all times.
So those consumers would straight up ignore any scaling done to the 
frames, reading messed up data instead.


On top of that, in the specific case of CUDA, the CUDA pix_fmt is 
defined with the assumption that the entire frame is in a single 
continuous buffer with all planes right after one another. This would 
most prominently affect nvenc, as its API only takes one lone CUdevptr 
as input, and then has a fixed idea about how the data behind it looks.


So it would produce output with random data to the right and bottom of 
the scaled frame, still with the outer dimensions before the 
re-configuration.


The only way this could possibly work is if a new hw_frames_ctx is 
created on reconfiguration.
With nvenc this would actually work without any changes, as it re-reads 
the width/height out of it on every frame already, and initially only 
gets the CUDA-Context and sw_pix_fmt out of it, so those would need to 
stay the same, which isn't an issue.
But for a bunch of other hardware filters more work is needed. Specially 
as some parts overlap with other APIs.




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] Add CUDA function cuMemAllocPitch

[Timo Rothenpieler]

applied



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] Revert "avcodec/decode: copy the output parameters from the last bsf in the chain back to the AVCodecContext"

[Timo Rothenpieler]

So, what do we do now? Honor the doxy and stop trying to manipulate
what's meant to be an user owned pointer/buffer, officially break the
API and declare it's meant to be allocated by the user but then
ownership is passed to the library during or after the avcodec_open2()
call, or just revert this commit and pretend nothing happened?


Documenting the API break that already happened seems like the least bad 
option right now. Firefox already merged code to work around the crash.


It already is freed in multiple places, so existing code probably 
already is compatible.


No solution to this is overly pretty unfortunately.
Specially as this goes along with likely leaking the extradata pointer, 
as unconditionally freeing it will most definitely cause crashes left 
and right.




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] 971108 - ffmpeg doesn't use GPU

[Timo Rothenpieler]

This list is about development of ffmpeg itself.
You are probably looking for libav-users.



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] scaling option

[Timo Rothenpieler]

On 26/03/2019 13:47, Yufei He wrote:

Hi

Is there option for scaling on transcoding ?

e.g. transcoding from a quadhd file to 640 * 480.

Thanks.

Yufei.



Yes there is, but this is ffmpeg-devel, so not the place to ask user 
questions.





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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] configure: include pkgconfig path as vaapi header search

[Timo Rothenpieler]

On 20/03/2019 08:57, Zhong Li wrote:

Currectly just standard header path and be found,
check_type/struct will fail if vaapi is installed somewhere else.
---
  configure | 18 ++
  1 file changed, 10 insertions(+), 8 deletions(-)

diff --git a/configure b/configure
index eaf543df96..0e3c2d24bf 100755
--- a/configure
+++ b/configure
@@ -6024,14 +6024,6 @@ check_type "windows.h d3d11.h" "ID3D11VideoDecoder"
  check_type "windows.h d3d11.h" "ID3D11VideoContext"
  check_type "d3d9.h dxva2api.h" DXVA2_ConfigPictureDecode -D_WIN32_WINNT=0x0602
  
-check_type "va/va.h va/va_dec_hevc.h" "VAPictureParameterBufferHEVC"

-check_struct "va/va.h" "VADecPictureParameterBufferVP9" bit_depth
-check_struct "va/va.h va/va_vpp.h" "VAProcPipelineCaps" rotation_flags
-check_type "va/va.h va/va_enc_hevc.h" "VAEncPictureParameterBufferHEVC"
-check_type "va/va.h va/va_enc_jpeg.h" "VAEncPictureParameterBufferJPEG"
-check_type "va/va.h va/va_enc_vp8.h"  "VAEncPictureParameterBufferVP8"
-check_type "va/va.h va/va_enc_vp9.h"  "VAEncPictureParameterBufferVP9"
-
  check_type "vdpau/vdpau.h" "VdpPictureInfoHEVC"
  
  if enabled cuda_sdk; then

@@ -6469,6 +6461,16 @@ if enabled vaapi; then
  check_cpp_condition vaapi_1 "va/va.h" "VA_CHECK_VERSION(1, 0, 0)"
  fi
  
+if enabled vaapi; then

+check_type "va/va.h va/va_dec_hevc.h" "VAPictureParameterBufferHEVC"
+check_struct "va/va.h" "VADecPictureParameterBufferVP9" bit_depth
+check_struct "va/va.h va/va_vpp.h" "VAProcPipelineCaps" rotation_flags
+check_type "va/va.h va/va_enc_hevc.h" "VAEncPictureParameterBufferHEVC"
+check_type "va/va.h va/va_enc_jpeg.h" "VAEncPictureParameterBufferJPEG"
+check_type "va/va.h va/va_enc_vp8.h"  "VAEncPictureParameterBufferVP8"
+check_type "va/va.h va/va_enc_vp9.h"  "VAEncPictureParameterBufferVP9"
+fi
+
  if enabled_all opencl libdrm ; then
  check_type "CL/cl_intel.h" "clCreateImageFromFdINTEL_fn" &&
  enable opencl_drm_beignet



Do I understand this right, that the desired effect is achieved by 
putting those check_* behind the pkgconfig check, which is in between 
the old and the new location?


If so, this looks OK to me.



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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH][FFmpeg-devel v2] Add GPU accelerated video crop filter

[Timo Rothenpieler]

On 25/03/2019 09:27, Tao Zhang wrote:

Hi,

Timo and Mark and I have been discussing this, and we think the right
thing to do is add support to vf_scale_cuda to respect the crop
properties on an input AVFrame. Mark posted a patch to vf_crop to
ensure that the properties are set, and then the scale filter should
respect those properties if they are set. You can look at
vf_scale_vaapi for how the properties are read, but they will require
explicit handling to adjust the src dimensions passed to the scale
filter.

Maybe a little not intuitive to users.


This will be a more efficient way of handling crops, in terms of total
lines of code and also allowing crop/scale with one less copy.

I know this is quite different from the approach you've taken here, and
we appreciate the work you've done, but it should be better overall to
implement this integrated method.

Hi Philip,

Glad to hear you guys had discussion on this. As I am also considering the 
problem, I have some questions about your idea.
So, what if user did not insert a scale_cuda after crop filter? Do you plan to 
automatically insert scale_cuda or just ignore the crop?
What if user want to do crop,transpose_cuda,scale_cuda? So we also need to 
handle crop inside transpose_cuda filter?

>

I have the same question.
Ideally, scale_cuda should be auto-inserted at the required places once 
it works that way.
Otherwise it seems pointless to me if the user still has to manually 
insert it after the generic filters setting metadata.


For that reason it should also still support getting its parameters 
passed directly as a fallback, and potentially even expose multiple 
filter names, so crop_cuda and transpose_cuda are still visible, but 
ultimately point to the same filter code.


We have a transpose_npp, right now, but with libnpp slowly being on its 
way out, transpose_cuda is needed, and ultimately even a format_cuda 
filter, since right now scale_npp is the only filter that can convert 
pixel formats on the hardware.
I'd also like to see scale_cuda to support a few more interpolation 
algorithms, but that's not very important for now.


All this functionality can be in the same filter, which is scale_cuda. 
The point of that is that it avoids needless expensive frame copies as 
much as possible.




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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] Add GPU accelerated video crop filter

[Timo Rothenpieler]

On 23.03.2019 12:31, UsingtcNower wrote:
> diff --git a/configure b/configure
> index 331393f..88f1e91 100755
> --- a/configure
> +++ b/configure
> @@ -2978,6 +2978,7 @@ scale_npp_filter_deps="ffnvcodec libnpp"
>   scale_cuda_filter_deps="ffnvcodec cuda_nvcc"
>   thumbnail_cuda_filter_deps="ffnvcodec cuda_nvcc"
>   transpose_npp_filter_deps="ffnvcodec libnpp"
> +crop_cuda_filter_deps="ffnvcodec cuda_nvcc"

These are generally kept in alphabetical order.


+static av_cold int init_processing_chain(AVFilterContext *ctx, int in_width, 
int in_height,
+ int out_width, int out_height,
+ int left, int top)
+{
+CUDACropContext *s = ctx->priv;
+
+AVHWFramesContext *in_frames_ctx;
+
+enum AVPixelFormat in_format;
+enum AVPixelFormat out_format;
+int ret;
+
+/* check that we have a hw context */
+if (!ctx->inputs[0]->hw_frames_ctx) {
+av_log(ctx, AV_LOG_ERROR, "No hw context provided on input\n");
+return AVERROR(EINVAL);
+}
+in_frames_ctx = (AVHWFramesContext*)ctx->inputs[0]->hw_frames_ctx->data;
+in_format = in_frames_ctx->sw_format;
+out_format= (s->format == AV_PIX_FMT_NONE) ? in_format : s->format;
+
+if (!format_is_supported(in_format)) {
+av_log(ctx, AV_LOG_ERROR, "Unsupported input format: %s\n",
+   av_get_pix_fmt_name(in_format));
+return AVERROR(ENOSYS);
+}
+if (!format_is_supported(out_format)) {
+av_log(ctx, AV_LOG_ERROR, "Unsupported output format: %s\n",
+   av_get_pix_fmt_name(out_format));
+return AVERROR(ENOSYS);
+}
+
+if (in_width == out_width && in_height == out_height)
+s->passthrough = 1;
+
+s->in_fmt = in_format;
+s->out_fmt = out_format;
+
+s->planes_in[0].width   = in_width;
+s->planes_in[0].height  = in_height;
+s->planes_out[0].width  = out_width;
+s->planes_out[0].height = out_height;
+s->planes_in[0].left = left;
+s->planes_in[0].top = top;
+s->planes_out[0].left = 0;
+s->planes_out[0].top = 0;


This is a nit, but why not align all of them?

Also missing a version bump. I'd say bumping lavf micro version is enough.


Otherwise this looks good to me. Will give it a test later, and I don't 
really see any reason not to merge this.




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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] Add GPU accelerated video crop filter

[Timo Rothenpieler]

On 23.03.2019 14:46, Steven Liu wrote:

Documentation of the crop_cuda should be submitted together.


Thanks
Steven



True, forgot about that. Should be almost identical to that of the 
regular crop filter.




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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 1/5] configure: Add an explicit check and option for nvcc

[Timo Rothenpieler]

On 21.02.2019 04:57, Philip Langdale wrote:

The use of nvcc to compile cuda kernels is distinct from the use of
cuda sdk libraries and linking against those libraries. We have
previously not bothered to distinguish these two cases because all
the filters that used cuda kernels also used the sdk. In the following
changes, I'm going to remove the sdk dependency from those filters,
but we need a way to ensure that nvcc is present and functioning, and
also a way to explicitly disable its use so that the filters are not
built.

Note that, unlike the cuda_sdk dependency, using nvcc to compile
a kernel does not cause a build to become non-free. Although nvcc
is distributed with the cuda sdk, and is EULA encumbered, the
compilation process we use does not introduce any EULA covered
code or libraries into the build. In this sense, using nvcc is just
like using any other proprietary compiler like msvc - compiling free
code doesn't suddently make it non-free.

There was previously some confusion on this topic, but the important
distinction is that we use nvcc to generate ptx files - these are
not compiled GPU binaries, but rather an intermediate assembly
representation that is JIT compiled (and I think linked with certain
nvidia library code) when you actually try and run the kernel. nvidia
use this technique to relax machine code compatibility between
hardware generations.

 From here, we can make two observations:
* The ptx files that we include in libavfilter are aggregated rather
   than linked, from the perspective of the (L)GPL
* No proprietary code is included with the ptx files. That code is
   only linked in at the final compilation step at runtime.



From a technical standpoint, this whole series looks fine to me.

However, it really does not fell non-nonfree to me that the only way to 
build these filters remains to register with nvidia, accept their 
various EULAs and download their SDK for nvcc and the libs around it.


Even moving them out of ffmpeg and loading them at runtime (which would 
be a major ABI, API and usability break) does not solve that.
You still need to either get said SDK and build them yourself, or get 
someone else to do it an run into the same issue with redistributability 
there.


If the general majority agrees that this series way of doing things is 
conforming, it is is good to go.

But I myself won't make that call.

I'd still like to get this merged asap, so if in doubt, keep nvcc in the 
nonfree list for now, and discuss its removal from there in a separate 
patch.




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

Re: [FFmpeg-devel] [PATCH] avfilter/vf_yadif_cuda: Relicence cuda kernel to MIT

[Timo Rothenpieler]

The patch seems to be corrupted by something. At least git am is 
refusing to apply it, and it looks very jumbled on patchwork.


But it LGTM. Feel free to push.



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

Re: [FFmpeg-devel] [PATCH 0/5] Clean up CUDA SDK usage and remove non-free requirement

[Timo Rothenpieler]

On 21.02.2019 04:57, Philip Langdale wrote:

I've been thinking about this for a while, but I only recently made the
realisation that compiling cuda kernels to the ptx format does not
introduce any non-free dependencies - the ptx files are an intermediate
assembly code format that is actually compiled to binary form at
runtime. With that understood, we just need to switch the remaining
users of the CUDA SDK to ffnvcodec and we will remove the non-free
entanglements from cuda.

Philip Langdale (5):
   configure: Add an explicit check and option for nvcc
   avfilter/vf_yadif_cuda: Switch to using ffnvcodec
   avfilter/vf_scale_cuda: Switch to using ffnvcodec
   avfilter/vf_thumbnail_cuda: Switch to using ffnvcodec
   configure: Remove cuda_sdk dependency option


Series applied, but kept cuda_nvcc non-free.



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

Re: [FFmpeg-devel] [PATCH] use the correct option of pkg-config to check version

[Timo Rothenpieler]

This seems weird to me, why would there only be an issue on Ubuntu 16.04?
I'd assume that the code in question has been tested quite a bit.

Do you have an example of where and how it fails?



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

Re: [FFmpeg-devel] [PATCH] ffnvcodec/compat: Fix CUdeviceptr definition for 64bit CPU

[Timo Rothenpieler]

On 11/03/2019 06:37, Ruta Gadkari wrote:

Hi

Please find the attached patch, it rectifies the definition of cuda device 
pointer for PPC64 architecture.
PPC64 support is present from Video Codec SDK 9.

Thanks
Ruta


Applied and released a new version of ffnvcodec 9.




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

Re: [FFmpeg-devel] [PATCH] configure: enable ffnvcodec, nvenc, nvdec for ppc64

[Timo Rothenpieler]

On 11/03/2019 09:40, Carl Eugen Hoyos wrote:

2019-03-11 6:36 GMT+01:00, Ruta Gadkari :


Please find attached the patch, it enables ffnvcodec and
nvenc, nvdec, cuvid for PPC64 architecture.


Is it supported on both little and big endian?


Good question.


This email message is for the sole use of the intended
recipient(s) and may contain confidential information.


Please remove this nonsense from future emails.


While I agree that it's pointless on mails to public lists, I don't 
think there is anything they can do against their mail server adding it.
And I prefer having that at the end of every mail over not being able to 
identify patches from @nvidia.com as such as easily.




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

Re: [FFmpeg-devel] [PATCH] avcodec/nvenc: Reconfigure resolution on-the-fly

[Timo Rothenpieler]

looks good at first glance, will give it a test this weekend.



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

Re: [FFmpeg-devel] [PATCH] configure: enable ffnvcodec, nvenc, nvdec for ppc64

[Timo Rothenpieler]

On 12/03/2019 09:52, Ruta Gadkari wrote:


On 11/03/2019 15:51, Carl Eugen Hoyos wrote:

2019-03-11 11:16 GMT+01:00, Timo Rothenpieler :

On 11/03/2019 09:40, Carl Eugen Hoyos wrote:

2019-03-11 6:36 GMT+01:00, Ruta Gadkari :


Please find attached the patch, it enables ffnvcodec and nvenc,
nvdec, cuvid for PPC64 architecture.


Is it supported on both little and big endian?


Good question.



Assuming it is only supported on little-endian ppc64, the check should be fixed 
accordingly.


The support is present only on little endian.
Fixed the check, please find attached the updated patch.


Looks good to me now.



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

Re: [FFmpeg-devel] [PATCHv3] avcodec/nvenc: Reconfigure resolution on-the-fly

[Timo Rothenpieler]

So what's the final verdict here, can this be pushed or not?

Timo - did you manage to test it over last weekend?


I haven't found the time, sorry.
I'm generally not opposed to this. It does not disrupt normal use, and 
spinning up nvenc does have a surprisingly hefty overhead, so it makes 
sense to have features like that.


One request I'd have for the patch though, if one of the new max_ 
parameters is set, and dyn res changing is not supported, there should 
be an error.


Likewise if the res does change and max_width/height were not set.
Silently not doing anything seems bad.

Also, someone needs to ack the non-nvenc changes. Not sure if that 
explanation is really needed, since this is an nvenc specific edge case.




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

Re: [FFmpeg-devel] [PATCH] avcodec/nvenc: Reconfigure resolution on-the-fly

[Timo Rothenpieler]

On 08/03/2019 00:57, Carl Eugen Hoyos wrote:

2019-03-06 15:57 GMT+01:00, Oliver Collyer :

Hi

I needed the dynamic resolution changing feature of NVENC to be accessible
through the ffmpeg libraries for a hobby project, so I added support and
here is a patch.

I will format this as a proper patch after any changes necessary following
feedback.

To use this feature you would need to:

1. Specify max_width and max_height before opening the encoder


Can't they be set to a maximum number to be as flexible as possible?


That'd be a bad idea, as it will allocate that amount of memory for 
every frame, no matter how large it actually ends up being.




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

Re: [FFmpeg-devel] Server upgrades

[Timo Rothenpieler]

On 06/02/2019 14:50, Reimar Döffinger wrote:

As I remember, apache actually wants certificate and chain separately, so we 
might need to create and use 2 different ones (even if the difference is just a 
cat command or so).

https://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslcertificatechainfile

It wants it as a single file, just like nginx. The old way is deprecated.



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] Server upgrades

[Timo Rothenpieler]

On 06/02/2019 11:46, Michael Niedermayer wrote:

There is also a new lets encrypt certificate, these expire frequently
The problem probably is that the server didnt sent the full chain of
certificates
ive manually made a certificate that works now but reimars script needs
an update so it cats all the certs of the chain together. (ccing reimar
for this) or maybe someone knows a cleaner way to make nginx use more than
1 as apache supports.


I'm using https://github.com/lukas2511/dehydrated on my servers.
It generates a fullchain.pem, which contains the full chain and the 
cert, by default, which can be used for that exact purpose.

Manually specifying the chain is actually deprecated even on Apache.



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 1/2] libavcodec/nvenc_hevc: adding B frame support

[Timo Rothenpieler]

On 13.02.2019 09:52, Roman Arzumanyan wrote:

Hello,

Please find attached patch, it adds HEVC B-frames support to nvenc_hevc.

This feature requires Video Codec SDK 9 + Turing card.



Will it cause issues if set on an older card, or just plain get ignored?

If it's ignored, this 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] nv-codec-headers: Video Codec SDK 9 support

[Timo Rothenpieler]

On 13.02.2019 09:47, Roman Arzumanyan wrote:

Hello,

Please find attached patch for nv-codec-headers.

It adds Video Codec SDK 9 support.



Applied and followed up with a patch adding some more new fields from 
SDK 9.0.18.




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/2] libavcodec/cuviddec: adding HEVC YUV444P decoding support

[Timo Rothenpieler]

On 13.02.2019 09:56, Roman Arzumanyan wrote:

Hello,

Please find attached patch, it adds HEVC YUV444P decoding support.

Supported formats are AV_PIX_FMT_YUV444P, AV_PIX_FMT_YUV444P10LE, 
AV_PIX_FMT_YUV444P12LE.


This feature requires Video Codec SDK 9.


There is one big issue with this.
And that is, that ffmpeg expects the data for YUV444P10 and YUV444P12 to 
be in the least significant bits.
Nvenc (and I hope/assume as does nvdec/cuvid) on the other hand put the 
data into the most significant bits.


As a workaround we have so far resorted to using the 16 bit pix_fmt 
everywhere, as it happens to match up.

That has the issue of losing the information about the bit depth.
So far every attempt at solving it (like, adding new pix_fmts that match 
what nvenc/dec uses) have not found consent.




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 1/2] libavcodec/nvenc_hevc: adding B frame support

[Timo Rothenpieler]

On 13.02.2019 20:18, Timo Rothenpieler wrote:

On 13.02.2019 09:52, Roman Arzumanyan wrote:

Hello,

Please find attached patch, it adds HEVC B-frames support to nvenc_hevc.

This feature requires Video Codec SDK 9 + Turing card.



Will it cause issues if set on an older card, or just plain get ignored?

If it's ignored, this LGTM.



Missed that the existing cap check will catch this.

Applied



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 4/4] avcodec/cuviddec: Add support for decoding HEVC 4:4:4 content

[Timo Rothenpieler]

On 14.02.2019 05:03, 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 | 66 ++-
  1 file changed, 46 insertions(+), 20 deletions(-)

diff --git a/libavcodec/cuviddec.c b/libavcodec/cuviddec.c
index 03589367ce..d6f9c620f4 100644
--- a/libavcodec/cuviddec.c
+++ b/libavcodec/cuviddec.c
@@ -34,8 +34,14 @@
  #include "avcodec.h"
  #include "decode.h"
  #include "hwaccel.h"
+#include "nvdec.h"
  #include "internal.h"
  
+#if !NVDECAPI_CHECK_VERSION(9, 0)

+#define cudaVideoSurfaceFormat_YUV444 2
+#define cudaVideoSurfaceFormat_YUV444_16Bit 3
+#endif
+
  typedef struct CuvidContext
  {
  AVClass *avclass;
@@ -106,6 +112,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;
@@ -148,17 +155,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 = >caps8;
  break;
  case 2: // 10-bit
-pix_fmts[1] = AV_PIX_FMT_P010;
+pix_fmts[1] = chroma_444 ? AV_PIX_FMT_YUV444P16 : AV_PIX_FMT_P010;
  caps = >caps10;
  break;
  case 4: // 12-bit
-pix_fmts[1] = AV_PIX_FMT_P016;
+pix_fmts[1] = chroma_444 ? AV_PIX_FMT_YUV444P16 : AV_PIX_FMT_P016;
  caps = >caps12;
  break;
  default:
@@ -261,12 +270,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;

@@ -280,8 +283,15 @@ 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 = cudaVideoSurfaceFormat_YUV444;
+break;
+case AV_PIX_FMT_YUV444P16:
+cuinfo.OutputFormat = cudaVideoSurfaceFormat_YUV444_16Bit;
+break;
  default:
-av_log(avctx, AV_LOG_ERROR, "Output formats other than NV12, P010 or P016 
are not supported\n");
+av_log(avctx, AV_LOG_ERROR, "Unsupported output format: %s\n",
+   av_get_pix_fmt_name(avctx->sw_pix_fmt));
  ctx->internal_error = AVERROR(EINVAL);
  return 0;
  }
@@ -490,6 +500,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;
@@ -520,7 +531,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++) {
+int height = avctx->height >> (i ? pixdesc->log2_chroma_h : 0);
  CUDA_MEMCPY2D cpy = {
  .srcMemoryType = CU_MEMORYTYPE_DEVICE,
  .dstMemoryType = CU_MEMORYTYPE_DEVICE,
@@ -530,22 +544,25 @@ 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(, device_hwctx->stream));

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

+   

Re: [FFmpeg-devel] [FFmpeg-cvslog] avutil/cuda_check: avoid pointlessly exporting same symbol from two libraries

[Timo Rothenpieler]

On 14.02.2019 19:59, Carl Eugen Hoyos wrote:

2019-02-14 18:21 GMT+01:00, Hendrik Leppkes :

On Thu, Feb 14, 2019 at 4:51 PM Carl Eugen Hoyos  wrote:





Am 14.02.2019 um 13:39 schrieb Timo Rothenpieler :

ffmpeg | branch: master | Timo Rothenpieler  |
Fri Feb  8 22:47:01 2019 +0100|
[15c6390139096b7e7634bf0f6aaab1cd8b3aa509] | committer: Timo
Rothenpieler

avutil/cuda_check: avoid pointlessly exporting same symbol from two
libraries


http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=15c6390139096b7e7634bf0f6aaab1cd8b3aa509

---

libavcodec/Makefile |  6 +++---
libavcodec/cuda_check.c |  1 -
libavutil/Makefile  |  2 +-



libavutil/cuda_check.c  | 45
-


Apart from breaking compilation doesn’t this also break ABI?


I got reports about this breaking compilation in its old state, which 
caused me to to turn it into a static inline header-only function.


For my this compiles and works fine, is there any constellation/compiler 
where it doesn't?




No, this entire mess with duplicated ff_ symbols is specifically to
avoid having to include it in the ABI.


But old libavcodec does not work with new libavutil now or am I wrong?


Is that really a thing we expect or advertise to work? It does not seem 
sane and I'd expect a lot of other things to explode.



In any case, shouldn't the function have another name if it is static now?


No idea if there is any naming convention for static inline header-only 
functions. I kept it as is to avoid having to touch even more files, but 
renaming it is of course no big deal.




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] [FFmpeg-cvslog] avutil/cuda_check: avoid pointlessly exporting same symbol from two libraries

[Timo Rothenpieler]

You changed libavfilter but didn't commit (I guess), please mention
ticket #7735.
(I didn't test myself, sorry if there is no issue!)


I just completely missed the parts in libavfilter.
I am thoroughly confused why this did not break compilation for me.
Will push the missing part asap.



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] [FFmpeg-cvslog] avutil/cuda_check: avoid pointlessly exporting same symbol from two libraries

[Timo Rothenpieler]

On 15.02.2019 01:01, Carl Eugen Hoyos wrote:

2019-02-14 23:36 GMT+01:00, Carl Eugen Hoyos :


please mention ticket #7735.


Ping!


I remembered the moment i pushed the patch, sorry.



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] Patchwork attribution

[Timo Rothenpieler]

On 18/04/2019 09:49, Gyan wrote:


Patchwork can incorrectly assign ownership. See 
https://patchwork.ffmpeg.org/patch/12680/


The author is Sam John as identified by Message ID as well as the From 
field in the headers, yet Patchwork attributes this patch to "Oliver 
Collyer via ffmpeg-devel", a name which appears nowhere in the headers 
or in the submitted patch. The downloaded mbox patch shows the same 
wrong attribution. Does anyone know what's going on?


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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


This happens due to Mailman having to rewrite peoples E-Mail addresses 
if they have strong DKIM/DMARC configured on their sending Domain.
If that is the case, only the server of the actual Domain who owns the 
right private key can send E-Mails under the name of that Domain.


So for mailing lists to be able to send on the messages, they are forced 
to change the sender address.

In the case of this list:
Sam John 
gets translated to.
Sam John via ffmpeg-devel 

Nothing can be sensibly done about this, cause the alternative would be 
the message getting rejected by the majority of Mailservers.
It's unfortunate that this also messes with the patches. People who are 
affected should probably attach patches instead of using send-email.




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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Patchwork attribution

[Timo Rothenpieler]

Ok.  Then shouldn't it assign 'Sam John via ffmpeg-devel' as the author? 
It did do that for 'Oliver Collyer via ffmpeg-devel', the string wrongly 
substituted here.

This looks like a parser failure in Patchwork.

Gyan


If the patch is sent with git send-email, the From: header of the E-Mail 
is where git puts the Author. So patchwork has no chance to correct this.




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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 0/3] avfilter/vf_scale_cuda: Various improvements

[Timo Rothenpieler]

On 14.05.2019 05:12, Philip Langdale wrote:

After Sergey's bug report, I went and fixed a couple of other things
I noticed while I was looking at the filter.

Philip Langdale (3):
   avfilter/vf_scale_cuda: Fix incorrect scaling of > 8bit content
   avfilter/vf_scale_cuda: Add support for YUV444P16
   avfilter/vf_scale_cuda: Simplify output plane addressing

  libavfilter/vf_scale_cuda.c | 41 +
  1 file changed, 28 insertions(+), 13 deletions(-)



Series LGTM



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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] lavfi/vf_scale_cuda: Reset frame size after acquiring from hwframe.

[Timo Rothenpieler]

On 24.05.2019 21:32, Сергей Свечников wrote:

Actually, I've submitted the fix a while ago and got ignored. I then wrote
to Timo directly to his email and got ignored again.
https://github.com/Svechnikov/ffmpeg-scale-cuda-problem


I simply missed the original mail to the list, sorry about that.

The mail you sent to me directly got caught by Spamassassin due to 
"Excess base64 in From: field", which it also tagged this mail with, but 
it coming via this list saved it.




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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 2/3] avcodec/nvenc: add master display and light level sei for HDR10

[Timo Rothenpieler]

On 27.05.2019 23:49, Lance Wang wrote:

On Saturday, May 25, 2019, James Almer  wrote:


On 5/22/2019 3:59 AM, lance.lmw...@gmail.com wrote:

From: Limin Wang 

The testing command for the HDR10 output with nvenc:
$ ./ffmpeg_g -y -i 4K.mp4 -c:v hevc_nvenc -g 7 -color_primaries bt2020

-colorspace bt2020_ncl -color_trc smpte2084 -sei hdr10 \

 -master_display "G(13250,34500)B(7500,3000)R(

34000,16000)WP(15635,16450)L(1000,50)" -max_cll "0, 0" test.ts


Please notice it is preferable to use the frame sei side data than

master_display and max_cll paramters config

---
  libavcodec/nvenc.c  | 129 
  libavcodec/nvenc.h  |  18 ++
  libavcodec/nvenc_hevc.c |  11 
  3 files changed, 158 insertions(+)

diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c
index 75dda6d689..3fd0eca4a5 100644
--- a/libavcodec/nvenc.c
+++ b/libavcodec/nvenc.c
@@ -22,6 +22,9 @@
  #include "config.h"

  #include "nvenc.h"
+#include "cbs_h265.h"


This doesn't seem right. The encoder isn't using this framework at all.

You're apparently including this only to get the
H265RawSEIMasteringDisplayColourVolume and
H265RawSEIContentLightLevelInfo structs, which you don't really need to
fill sei_data[i].payload

OK,  I'll remove the dependent for the two structure and update the patch.





I'm still not convinced that all this belong in an encoder.
Can it really not be made into a filter that adds it as extra data to 
frames? There got to be other frame consumers that use this kind of data.




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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

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

[Timo Rothenpieler]

On 04.05.2019 16:13, Paul B Mahol wrote:

Signed-off-by: Paul B Mahol 
---
  doc/filters.texi  |  18 +++
  libavfilter/Makefile  |   1 +
  libavfilter/allfilters.c  |   1 +
  libavfilter/vf_colorkey.c | 102 +-
  4 files changed, 121 insertions(+), 1 deletion(-)

diff --git a/doc/filters.texi b/doc/filters.texi
index cd82869849..1ac37a32b8 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -6723,6 +6723,24 @@ ffmpeg -i background.png -i video.mp4 -filter_complex 
"[1:v]colorkey=0x3BBD1E:0.
  @end example
  @end itemize
  
+@section colorhold

+Remove all color information for all RGB colors except for certain one.
+
+The filter accepts the following options:
+
+@table @option
+@item color
+The color which will not be replaced with neutral gray.
+
+@item similarity
+Similarity percentage with the above color.
+0.01 matches only the exact key color, while 1.0 matches everything.
+
+@item blend
+Blend percentage. 0.0 makes pixels fully gray.
+Higher values result in more preserved color.
+@end table
+
  @section colorlevels
  
  Adjust video input frames using levels.

diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 59d12ce069..b41304d480 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -179,6 +179,7 @@ OBJS-$(CONFIG_COLORCHANNELMIXER_FILTER)  += 
vf_colorchannelmixer.o
  OBJS-$(CONFIG_COLORKEY_FILTER)   += vf_colorkey.o
  OBJS-$(CONFIG_COLORKEY_OPENCL_FILTER)+= vf_colorkey_opencl.o opencl.o 
\
  opencl/colorkey.o
+OBJS-$(CONFIG_COLORHOLD_FILTER)  += vf_colorkey.o
  OBJS-$(CONFIG_COLORLEVELS_FILTER)+= vf_colorlevels.o
  OBJS-$(CONFIG_COLORMATRIX_FILTER)+= vf_colormatrix.o
  OBJS-$(CONFIG_COLORSPACE_FILTER) += vf_colorspace.o colorspace.o 
colorspacedsp.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index ae725cb0e0..9bdfa7d1bc 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -167,6 +167,7 @@ extern AVFilter ff_vf_colorbalance;
  extern AVFilter ff_vf_colorchannelmixer;
  extern AVFilter ff_vf_colorkey;
  extern AVFilter ff_vf_colorkey_opencl;
+extern AVFilter ff_vf_colorhold;
  extern AVFilter ff_vf_colorlevels;
  extern AVFilter ff_vf_colormatrix;
  extern AVFilter ff_vf_colorspace;
diff --git a/libavfilter/vf_colorkey.c b/libavfilter/vf_colorkey.c
index 3d65e59d42..b546cd4122 100644
--- a/libavfilter/vf_colorkey.c
+++ b/libavfilter/vf_colorkey.c
@@ -34,6 +34,9 @@ typedef struct ColorkeyContext {
  uint8_t colorkey_rgba[4];
  float similarity;
  float blend;
+
+int (*do_slice)(AVFilterContext *ctx, void *arg,
+int jobnr, int nb_jobs);
  } ColorkeyContext;
  
  static uint8_t do_colorkey_pixel(ColorkeyContext *ctx, uint8_t r, uint8_t g, uint8_t b)

@@ -77,15 +80,65 @@ static int do_colorkey_slice(AVFilterContext *avctx, void 
*arg, int jobnr, int n
  return 0;
  }
  
+static int do_colorhold_slice(AVFilterContext *avctx, void *arg, int jobnr, int nb_jobs)

+{
+AVFrame *frame = arg;
+
+const int slice_start = (frame->height * jobnr) / nb_jobs;
+const int slice_end = (frame->height * (jobnr + 1)) / nb_jobs;
+
+ColorkeyContext *ctx = avctx->priv;
+
+int o, x, y;
+
+for (y = slice_start; y < slice_end; ++y) {
+for (x = 0; x < frame->width; ++x) {
+int t, r, g, b;


Nit, but I'd prefer to not mix "declaration at top" with intermittent 
declaration of vars.

In this case, I'd just put o down here as well.


+o = frame->linesize[0] * y + x * 4;
+r = frame->data[0][o + ctx->co[0]];
+g = frame->data[0][o + ctx->co[1]];
+b = frame->data[0][o + ctx->co[2]];
+
+t = do_colorkey_pixel(ctx, r, g, b);
+
+if (t > 0) {
+int a = (r + g + b) / 3;
+int rt = 255 - t;
+
+frame->data[0][o + ctx->co[0]] = (a * t + r * rt + 127) >> 8;
+frame->data[0][o + ctx->co[1]] = (a * t + g * rt + 127) >> 8;
+frame->data[0][o + ctx->co[2]] = (a * t + b * rt + 127) >> 8;
+}
+}
+}
+
+return 0;
+}
+
+static av_cold int init_filter(AVFilterContext *avctx)
+{
+ColorkeyContext *ctx = avctx->priv;
+
+if (!strcmp(avctx->filter->name, "colorkey")) {
+ctx->do_slice = do_colorkey_slice;
+} else {
+ctx->do_slice = do_colorhold_slice;
+}
+
+return 0;
+}
+
  static int filter_frame(AVFilterLink *link, AVFrame *frame)
  {
  AVFilterContext *avctx = link->dst;
+ColorkeyContext *ctx = avctx->priv;
  int res;
  
  if (res = av_frame_make_writable(frame))

  return res;
  
-if (res = avctx->internal->execute(avctx, do_colorkey_slice, frame, NULL, FFMIN(frame->height, ff_filter_get_nb_threads(avctx

+if (res = avctx->internal->execute(avctx, ctx->do_slice, frame, NULL, 
FFMIN(frame->height, 

Re: [FFmpeg-devel] [PATCH] avfilter/drawtext: make command processing error-resilient

[Timo Rothenpieler]

On 10/05/2019 15:55, Gyan wrote:
At present, if the command args passed to drawtext contain any invalid 
values, ffmpeg may crash or, at best, stop drawing any text.
Attached patch gets the filter to continue with existing parameters, if 
not all of the changes can be parsed or applied. This allows users in 
live processing to correct and resubmit.


Gyan


This patch has at least two mis-uses of av_freep(), which potentially 
lead to a crash.



+av_freep(old);
+
+ctx->priv = new;


Should probably be av_freep();


+fail:
+av_log(ctx, AV_LOG_ERROR, "Failed to process command. Continuing with existing 
parameters.\n");
+av_freep(new);
+return ret;


Should probably be av_freep();

I did not do a full review of the patch, just pointing out those issues 
Coverity found. See coverity CID 1445099.



Timo



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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 2/3] avcodec/nvenc: add master display and light level sei for HDR10

[Timo Rothenpieler]

On 22.05.2019 08:59, lance.lmw...@gmail.com wrote:

From: Limin Wang 

The testing command for the HDR10 output with nvenc:
$ ./ffmpeg_g -y -i 4K.mp4 -c:v hevc_nvenc -g 7 -color_primaries bt2020 
-colorspace bt2020_ncl -color_trc smpte2084 -sei hdr10 \
 -master_display 
"G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(1000,50)" -max_cll "0, 
0" test.ts

Please notice it is preferable to use the frame sei side data than 
master_display and max_cll paramters config
---
  libavcodec/nvenc.c  | 129 
  libavcodec/nvenc.h  |  18 ++
  libavcodec/nvenc_hevc.c |  11 
  3 files changed, 158 insertions(+)

diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c
index 75dda6d689..3fd0eca4a5 100644
--- a/libavcodec/nvenc.c
+++ b/libavcodec/nvenc.c
@@ -22,6 +22,9 @@
  #include "config.h"
  
  #include "nvenc.h"

+#include "cbs_h265.h"
+#include "hevc_sei.h"
+#include "put_bits.h"
  
  #include "libavutil/hwcontext_cuda.h"

  #include "libavutil/hwcontext.h"
@@ -30,6 +33,7 @@
  #include "libavutil/avassert.h"
  #include "libavutil/mem.h"
  #include "libavutil/pixdesc.h"
+#include "libavutil/mastering_display_metadata.h"
  #include "internal.h"
  
  #define CHECK_CU(x) FF_CUDA_CHECK_DL(avctx, dl_fn->cuda_dl, x)

@@ -1491,6 +1495,46 @@ av_cold int ff_nvenc_encode_init(AVCodecContext *avctx)
  ctx->data_pix_fmt = avctx->pix_fmt;
  }
  
+ctx->display_primaries_x[0] = 13250;

+ctx->display_primaries_y[0] = 34500;
+ctx->display_primaries_x[1] = 7500;
+ctx->display_primaries_y[1] = 3000;
+ctx->display_primaries_x[2] = 34000;
+ctx->display_primaries_y[2] = 16000;
+ctx->white_point_x  = 15635;
+ctx->white_point_y  = 16450;
+ctx->max_display_mastering_luminance = 1000;
+ctx->min_display_mastering_luminance = 500;
+ctx->max_content_light_level = 0;
+ctx->max_pic_average_light_level = 0;


Does all this really belong into an encoder? The command line parameter 
also looks very arcane.
To me, this looks more like a filter or something should add this as 
extra data, and then multiple encoders can pick it up from there.


Same goes for patch 3/3. Patch 1/3 is looks OK to me.


Timo



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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] lavfi/vf_scale_cuda: Add format option

[Timo Rothenpieler]

On 24/05/2019 01:49, Josh Allmann wrote:

Makes certain usages of the lavfi API easier.
---
  libavfilter/vf_scale_cuda.c | 12 +++-
  1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/libavfilter/vf_scale_cuda.c b/libavfilter/vf_scale_cuda.c
index b7cdb81081..6b1ef2bb6f 100644
--- a/libavfilter/vf_scale_cuda.c
+++ b/libavfilter/vf_scale_cuda.c
@@ -81,6 +81,7 @@ typedef struct CUDAScaleContext {
  
  char *w_expr;   ///< width  expression string

  char *h_expr;   ///< height expression string
+char *format_str;
  
  CUcontext   cu_ctx;

  CUmodulecu_module;
@@ -101,7 +102,15 @@ static av_cold int cudascale_init(AVFilterContext *ctx)
  {
  CUDAScaleContext *s = ctx->priv;
  
-s->format = AV_PIX_FMT_NONE;

+if (!strcmp(s->format_str, "same")) {
+s->format = AV_PIX_FMT_NONE;
+} else {
+s->format = av_get_pix_fmt(s->format_str);
+if (s->format == AV_PIX_FMT_NONE) {
+av_log(ctx, AV_LOG_ERROR, "Unrecognized pixel format: %s\n", 
s->format_str);
+return AVERROR(EINVAL);
+}
+}
  s->frame = av_frame_alloc();
  if (!s->frame)
  return AVERROR(ENOMEM);
@@ -533,6 +542,7 @@ fail:
  static const AVOption options[] = {
  { "w",  "Output video width",  OFFSET(w_expr), AV_OPT_TYPE_STRING, { .str = 
"iw"   }, .flags = FLAGS },
  { "h",  "Output video height", OFFSET(h_expr), AV_OPT_TYPE_STRING, { .str = 
"ih"   }, .flags = FLAGS },
+{ "format", "Output pixel format", OFFSET(format_str), AV_OPT_TYPE_STRING, { .str = 
"same" }, .flags = FLAGS },
  { NULL },
  };


I'm not sure what to think about a dummy option like this. It might be 
very confusing for users to see a format option, which only accepts a 
single value, "same", and effectively does nothing.


Not strictly against it, since I can see the convenience it adds when 
building command lines, but I'd like some second opinions on this.




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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] lavfi/vf_scale_cuda: Reset frame size after acquiring from hwframe.

[Timo Rothenpieler]

On 24.05.2019 18:39, Josh Allmann wrote:

The first frame is scaled correctly, and subsequent frames are
over-scaled / cropped since the frame data is reset with the
hwframe after each invocation of the scaler.

The hwframe-allocated frame has a width/height that is 32-bit
aligned. The scaler uses this aligned width / height as its target,
leading to "over-scaling" and then cropping of the result.

To generate a broken test sample:

   ffmpeg -hwaccel cuvid -c:v h264_cuvid -i  -an \
 -lavfi scale_cuda=w=426:h=240 -c:v h264_nvenc 
---

Tested with NV12 and 420P inputs.

Noting that YUV444P seems generally broken - both before/after this patch.


  libavfilter/vf_scale_cuda.c | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/libavfilter/vf_scale_cuda.c b/libavfilter/vf_scale_cuda.c
index 6b1ef2bb6f..13eb3ad24c 100644
--- a/libavfilter/vf_scale_cuda.c
+++ b/libavfilter/vf_scale_cuda.c
@@ -489,6 +489,8 @@ static int cudascale_scale(AVFilterContext *ctx, AVFrame 
*out, AVFrame *in)
  
  av_frame_move_ref(out, s->frame);

  av_frame_move_ref(s->frame, s->tmp_frame);
+s->frame->width = s->planes_out[0].width;
+s->frame->height= s->planes_out[0].height;
  
  ret = av_frame_copy_props(out, in);

  if (ret < 0)


This is certainly correct. The original author of this must have wrongly 
assumed that av_frame_copy_props takes care of it.

Wonder how this was never noticed before.

Applied, thanks.



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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Hardware acceleration decoding question

[Timo Rothenpieler]

On 23.05.2019 10:06, Asaf Kave wrote:

Hello all,
I am using FFmpeg libarary in my software to do HW decoding for video
(H.264\H.265) on windows machine.
My decoding is based on 'hw_decode.c' example, and after i call decode a
frame i am using  AVFrame::data[3] to get the pointer to
the IDirect3DSurface9 and use it in my video player.

i didn't find any direction\example how to handle this pointer after i done
with it, do i need to release it? or the library is responsible for that ?

Thanks,
Asaf


This list is about development of FFmpeg itself, not for developing 
against its libraries. You are probably looking for libav-users.


Regarding your question, the Hardware Buffers are wrapped in the 
internal buffers of the frame. So whenever you unref the frame, you 
should consider them as freed.

In reality they just going to be re-used though.



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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] lavfi/vf_scale_cuda: Add format option

[Timo Rothenpieler]

On 24.05.2019 18:27, Josh Allmann wrote:

On Fri, 24 May 2019 at 06:00, Timo Rothenpieler  wrote:


On 24/05/2019 01:49, Josh Allmann wrote:

Makes certain usages of the lavfi API easier.
---
   libavfilter/vf_scale_cuda.c | 12 +++-
   1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/libavfilter/vf_scale_cuda.c b/libavfilter/vf_scale_cuda.c
index b7cdb81081..6b1ef2bb6f 100644
--- a/libavfilter/vf_scale_cuda.c
+++ b/libavfilter/vf_scale_cuda.c
@@ -81,6 +81,7 @@ typedef struct CUDAScaleContext {

   char *w_expr;   ///< width  expression string
   char *h_expr;   ///< height expression string
+char *format_str;

   CUcontext   cu_ctx;
   CUmodulecu_module;
@@ -101,7 +102,15 @@ static av_cold int cudascale_init(AVFilterContext *ctx)
   {
   CUDAScaleContext *s = ctx->priv;

-s->format = AV_PIX_FMT_NONE;
+if (!strcmp(s->format_str, "same")) {
+s->format = AV_PIX_FMT_NONE;
+} else {
+s->format = av_get_pix_fmt(s->format_str);
+if (s->format == AV_PIX_FMT_NONE) {
+av_log(ctx, AV_LOG_ERROR, "Unrecognized pixel format: %s\n", 
s->format_str);
+return AVERROR(EINVAL);
+}
+}
   s->frame = av_frame_alloc();
   if (!s->frame)
   return AVERROR(ENOMEM);
@@ -533,6 +542,7 @@ fail:
   static const AVOption options[] = {
   { "w",  "Output video width",  OFFSET(w_expr), AV_OPT_TYPE_STRING, { .str 
= "iw"   }, .flags = FLAGS },
   { "h",  "Output video height", OFFSET(h_expr), AV_OPT_TYPE_STRING, { .str 
= "ih"   }, .flags = FLAGS },
+{ "format", "Output pixel format", OFFSET(format_str), AV_OPT_TYPE_STRING, { .str = 
"same" }, .flags = FLAGS },
   { NULL },
   };


I'm not sure what to think about a dummy option like this. It might be
very confusing for users to see a format option, which only accepts a
single value, "same", and effectively does nothing.



Not sure I understand the issue.  "same" is the default (terminology
borrowed from the scale_npp filter), and it'll assign the format to
whatever is passed in (eg, format=yuv420p assigns that).


Oh, I misread that code as just always throwing an error if it's != "same".

Unfortunately, that option is omitted for a reason.
If you look at scalecuda_resize:
https://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavfilter/vf_scale_cuda.c;h=b7cdb81081ff4a34e7b641c533fc23a5714fed61;hb=HEAD#l380

It has the assumption built into it that the output frame has the same 
format as the input frame. So if you were to set format=nv12 and then 
input a yuv420p frame, this will most likely crash or at least severely 
misbehave.


I would not be opposed to scale_cuda gaining the ability to also change 
frame pix_fmts, we are lacking such a filter at the moment if one 
ignores scale_npp.

But in its current state, it can't do that.



Not strictly against it, since I can see the convenience it adds when
building command lines, but I'd like some second opinions on this.



Actually I'm using the API, albeit with some of lavfi conveniences to
parse filter strings. This avoids "wiring in" the output format
manually when crossing the lavfi boundary.

Here's a example that demonstrates the issue via CLI (this may
actually be a bug elsewhere?):

Broken:
ffmpeg -loglevel verbose -hwaccel cuvid -c:v h264_cuvid -i input.ts
-an -lavfi scale_cuda=w=426:h=240,hwdownload,format=yuv420p -c:v
libx264 out.ts

Working:
ffmpeg -loglevel verbose -hwaccel cuvid -c:v h264_cuvid -i input.ts
-an -lavfi scale_cuda=w=426:h=240:format=yuv420p,hwdownload,format=yuv420p
-c:v libx264 out.ts


Is this actually working in a sense where the result looks sensible?
Cause with how the code currently is, scale_cuda with format set to 
yuv420p and getting nv12 as input from h264_cuvid will produce a frame 
labeled as yuv420p but containing nv12 data.




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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [DECISION] Project policy on closed source components

[Timo Rothenpieler]

On 28/04/2019 22:02, Marton Balint wrote:

Hi All,

There has been discussion on the mailing list several times about the 
inclusion of support for closed source components (codecs, formats, 
filters, etc) in the main ffmpeg codebase.


Also the removal of libNDI happened without general consensus, so a vote 
is necessary to justify the removal.


So here is a call to the voting committee [1] to decide on the following 
two questions:


1) Should libNDI support be removed from the ffmpeg codebase?


No

2) Should patches using closed source libraries which are not considered 
"System Libraries" according to the GPL be rejected?


They should have a very good reason to be included, but not generally be 
rejected just on that basis.


On the example of NDI, its widespread use in video equipment and lack of 
alternatives gives it plenty of reason to be part of FFmpeg.
So if this was still for vote in the current form, I'd say "No" here as 
well.




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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 1/1] cuviddec: Add capability check for maximum macroblock count

[Timo Rothenpieler]

applied



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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] configure: enable ffnvcodec, nvenc, nvdec for ppc64

[Timo Rothenpieler]

applied



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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] cuviddec: improved way of finding out if a frame is interlaced or progressive

[Timo Rothenpieler]

applied, thanks.



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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v2] lavfi: add colorkey_opencl filter

[Timo Rothenpieler]

More a general question regarding OpenCL filters than related to this 
specific one.
We are not integrating OpenCL acceleration into the relevant native 
filter anymore, like the very old original OpenCL infra worked, are we?
So that vf_colorkey would just use OpenCL acceleration on its own 
whenever available and fallback to the software path otherwise.




Timo



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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [MSVC toolchain] Patch to allow building FFmpeg with Linux bash on Windows (WSL)

[Timo Rothenpieler]

On 24/04/2019 01:38, Carl Eugen Hoyos wrote:

2017-12-29 13:16 GMT+01:00, Cyber Sinh :

Sorry for the diff instead of regular git patch. Here is the patch.


Only saw this today after wondering
why nobody tried using wsl before...


I'm using WSL since a while, but never bothered trying to setup MSVC 
with it.




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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v2] libavcodec/amfenc: Vulkan initialization support for encoder.

[Timo Rothenpieler]

On 12/08/2019 12:35, Дмитрий Овчинников wrote:

Yes, it is possible, but it is required to implement separate patch with
selector dx9, dx11, vulkan. We could do it when this one is committed.
I will double check with opencl interop and will comeback.


There is no standardized OpenCL/Vulkan Interop as of now, but there are 
working group for it and it's probably gonna happen sooner or later, so 
it'd be nice to be prepared.




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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] Fixing HW accelerated decoders hanging or throwing error in h263dec

[Timo Rothenpieler]

On 02.08.2019 11:18, Stefan Schoenefeld wrote:

Hi all,

Recently we encountered an issue when decoding a h.263 file:

FFmpeg will freeze when decoding h.263 video with NVDEC. Turns out this is not 
directly related to NVDEC but is a problem that shows with several other HW 
decoders like VDPAU, though the exact kind of error is different (either error 
messages or freezing[1]). The root cause is that ff_thread_finish_setup() is 
called twice per frame from ff_h263_decode_frame(). This is not supported by 
ff_thread_finish_setup() and specifically checked for and warned against in the 
functions code. The issue is also specific to hw accelerated decoding only as 
the second call to ff_thread_finish_setup() is only issued when hw acceleration 
is on. The fix is simple: add a check that the first call is only send when hw 
acceleration is off, and the second call only when hw acceleration is on (see 
attached patch). This works fine as far as I was able to test with vdpau and 
nvdec/nvcuvid hw decoding. The patch also adds NVDEC to the hw config list if 
available.

I also noticed a secondary issue when browsing through the code which is that, 
according to documentation, ff_thread_finish_setup() should only be called if 
the codec implements update_thread_context(), which h263dec does not. The patch 
does not address this and I'm not sure any action needs to be taken here at all.

Thanks,
Stefan

[1] This is depending on whether or not the hw decoder sets the  
HWACCEL_CAPS_ASYNC_SAFE flag

 From 0620ee777a8ba98145bb4781e30a77687c97dbf8 Mon Sep 17 00:00:00 2001
From: Stefan Schoenefeld 
Date: Fri, 2 Aug 2019 10:52:22 +0200
Subject: [PATCH] Fixing HW accelerated decoders hanging or throwing error
messages in h263dec

---
libavcodec/h263dec.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/libavcodec/h263dec.c b/libavcodec/h263dec.c
index 6f001f6..8ee844e 100644
--- a/libavcodec/h263dec.c
+++ b/libavcodec/h263dec.c
@@ -614,7 +614,7 @@ retry:
  if ((ret = ff_mpv_frame_start(s, avctx)) < 0)
  return ret;
-if (!s->divx_packed)
+if (!s->divx_packed && !avctx->hwaccel)
  ff_thread_finish_setup(avctx);


This seems correct to me, but I'd like another pair of eyes to look over it.


  if (avctx->hwaccel) {
@@ -747,6 +747,9 @@ const AVCodecHWConfigInternal *ff_h263_hw_config_list[] = {
#if CONFIG_H263_VAAPI_HWACCEL
  HWACCEL_VAAPI(h263),
#endif
+#if CONFIG_MPEG4_NVDEC_HWACCEL
+HWACCEL_NVDEC(mpeg4),
+#endif


Probably cleaner to split this into its own patch, but otherwise OK.


#if CONFIG_MPEG4_VDPAU_HWACCEL
  HWACCEL_VDPAU(mpeg4),
#endif
--
2.7.4





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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] FFmpeg 4.2

[Timo Rothenpieler]

On 04.08.2019 07:56, Michael Niedermayer wrote:

On Sun, Jul 21, 2019 at 07:11:40PM +0200, Michael Niedermayer wrote:

On Mon, May 20, 2019 at 08:39:45PM +0200, Michael Niedermayer wrote:

Hi

Its quite some time since 4.1 so its probably getting time to branch
4.2.

If there are any bugs you want fixed in 4.2 its probably a good idea to
fix them soon.

Are there any suggestions for a name ?
If not ill pick something from unused past suggestions.

If there are no objections i will likely make that release in the next weeks


4.2 branch made
i intend to make the 4.2 release from HEAD of release/4.2 in the next 1-2 weeks
please backport any relevant bugfixes to it.


Status update: There are a few remaining crashes / security issues which i think
we should fix and include before the release. Iam working on that currently.

When thats done depends on
1. any delays (bikesheds, distractions, headaches, good weather that makes me 
ignore
this and go for a walk or maybe going for a walk occasionally actually helps
my efficiency who knows, ...)
2. influx of more security reports (fuzzer and any human reports), there where
several new reports in the last 2 weeks which fall in the "I think that 
should
be fixed before the release" category
3. murphies law and anything else unexpected

Thanks


I would kinda like to have the h263 hwaccel fix in for 4.2.
It's a one line patch that unbreaks it for all hwaccel backends.



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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] Fixing HW accelerated decoders hanging or throwing error in h263dec

[Timo Rothenpieler]

On 02.08.2019 11:18, Stefan Schoenefeld wrote:

Hi all,

Recently we encountered an issue when decoding a h.263 file:

FFmpeg will freeze when decoding h.263 video with NVDEC. Turns out this is not 
directly related to NVDEC but is a problem that shows with several other HW 
decoders like VDPAU, though the exact kind of error is different (either error 
messages or freezing[1]). The root cause is that ff_thread_finish_setup() is 
called twice per frame from ff_h263_decode_frame(). This is not supported by 
ff_thread_finish_setup() and specifically checked for and warned against in the 
functions code. The issue is also specific to hw accelerated decoding only as 
the second call to ff_thread_finish_setup() is only issued when hw acceleration 
is on. The fix is simple: add a check that the first call is only send when hw 
acceleration is off, and the second call only when hw acceleration is on (see 
attached patch). This works fine as far as I was able to test with vdpau and 
nvdec/nvcuvid hw decoding. The patch also adds NVDEC to the hw config list if 
available.

I also noticed a secondary issue when browsing through the code which is that, 
according to documentation, ff_thread_finish_setup() should only be called if 
the codec implements update_thread_context(), which h263dec does not. The patch 
does not address this and I'm not sure any action needs to be taken here at all.

Thanks,
Stefan

[1] This is depending on whether or not the hw decoder sets the  
HWACCEL_CAPS_ASYNC_SAFE flag


Split in two, applied and backported to relevant branches.



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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [REFUND-REQUEST] Packaging and Shipping cost AMD GPU

[Timo Rothenpieler]

I have sent one of my spare AMD GPUs to Rodger Combs for work on AMF and 
AMF/Vulkan integration.


Since there is personal information on the receipts, I won't post them 
here, but can send them to the responsible person on request easily.


Packaging:
PackSet M: 1.99€
Bubble-Wrap "Protection Kit": 4.99€

Shipping:
Insured shipping via DHL (DE->US): 37.99€

Total cost: 44.97€
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH NV HEADERS] Add cuCtxGetDevice

[Timo Rothenpieler]

On 12/09/2019 15:19, Steve Lhomme wrote:

It can be useful to determine if the decoder context is the same as the display
context.

It's used in some samples at https://github.com/NVIDIA/video-sdk-samples
---
  include/ffnvcodec/dynlink_cuda.h   | 1 +
  include/ffnvcodec/dynlink_loader.h | 2 ++
  2 files changed, 3 insertions(+)



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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH NV HEADERS] allow overriding the PREFIX from the environment

[Timo Rothenpieler]

On 12/09/2019 15:17, Steve Lhomme wrote:

---
  Makefile | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index a51c2c9..c3a9209 100644
--- a/Makefile
+++ b/Makefile
@@ -1,4 +1,4 @@
-PREFIX = /usr/local
+PREFIX ?= /usr/local


Overriding the prefix worked just fine last time I tested it.

You do make install PREFIX=...


  LIBDIR = lib
  INSTALL = install
  SED = sed


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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [REFUND-REQUEST] Packaging and Shipping cost AMD GPU

[Timo Rothenpieler]

On 02.09.2019 18:24, Timo Rothenpieler wrote:
I have sent one of my spare AMD GPUs to Rodger Combs for work on AMF and 
AMF/Vulkan integration.


Since there is personal information on the receipts, I won't post them 
here, but can send them to the responsible person on request easily.


Packaging:
PackSet M: 1.99€
Bubble-Wrap "Protection Kit": 4.99€

Shipping:
Insured shipping via DHL (DE->US): 37.99€

Total cost: 44.97€



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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 1/2] build: add support for building CUDA files with clang

[Timo Rothenpieler]

On 30.07.2019 09:51, Rodger Combs wrote:

This avoids using the CUDA SDK at all; instead, we provide a minimal
reimplementation of the basic functionality that lavfi actually uses.
It generates very similar code to what NVCC produces.

The header contains no implementation code derived from the SDK.
The function and type declarations are derived from the SDK only to the
extent required to build a compatible implementation. This is generally
accepted to qualify as fair use.

Because this option does not require the proprietary SDK, it does not require
the "--enable-nonfree" flag in configure.
---
  compat/cuda/cuda_runtime.h | 131 +
  configure  |  49 +-
  ffbuild/common.mak |   3 +-
  3 files changed, 166 insertions(+), 17 deletions(-)
  create mode 100644 compat/cuda/cuda_runtime.h

diff --git a/compat/cuda/cuda_runtime.h b/compat/cuda/cuda_runtime.h
new file mode 100644
index 00..dbe50f8711
--- /dev/null
+++ b/compat/cuda/cuda_runtime.h
@@ -0,0 +1,131 @@
+/*
+ * Minimum CUDA compatibility definitions header
+ *
+ * Copyright (c) 2019 Rodger Combs
+ *
+ * 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
+ */
+
+#ifndef AV_COMPAT_CUDA_CUDA_RUNTIME_H
+#define AV_COMPAT_CUDA_CUDA_RUNTIME_H
+
+// Common macros
+#define __global__ __attribute__((global))
+#define __device__ __attribute__((device))
+#define __device_builtin__ __attribute__((device_builtin))
+#define __align__(N) __attribute__((aligned(N)))
+#define __inline__ __inline__ __attribute__((always_inline))
+
+#define max(a, b) ((a) > (b) ? (a) : (b))
+#define min(a, b) ((a) < (b) ? (a) : (b))
+#define abs(x) ((x) < 0 ? -(x) : (x))
+
+#define atomicAdd(a, b) (__atomic_fetch_add(a, b, __ATOMIC_SEQ_CST))
+
+// Basic typedefs
+typedef __device_builtin__ unsigned long long cudaTextureObject_t;
+
+typedef struct __device_builtin__ __align__(2) uchar2
+{
+unsigned char x, y;
+} uchar2;
+
+typedef struct __device_builtin__ __align__(4) ushort2
+{
+unsigned short x, y;
+} ushort2;
+
+typedef struct __device_builtin__ uint3
+{
+unsigned int x, y, z;
+} uint3;
+
+typedef struct uint3 dim3;
+
+typedef struct __device_builtin__ __align__(8) int2
+{
+int x, y;
+} int2;
+
+typedef struct __device_builtin__ __align__(4) uchar4
+{
+unsigned char x, y, z, w;
+} uchar4;
+
+typedef struct __device_builtin__ __align__(8) ushort4
+{
+unsigned char x, y, z, w;
+} ushort4;
+
+typedef struct __device_builtin__ __align__(16) int4
+{
+int x, y, z, w;
+} int4;
+
+// Accessors for special registers
+#define GETCOMP(reg, comp) \
+asm("mov.u32 %0, %%" #reg "." #comp ";" : "=r"(tmp)); \
+ret.comp = tmp;
+
+#define GET(name, reg) static inline __device__ uint3 name() {\
+uint3 ret; \
+unsigned tmp; \
+GETCOMP(reg, x) \
+GETCOMP(reg, y) \
+GETCOMP(reg, z) \
+return ret; \
+}
+
+GET(getBlockIdx, ctaid)
+GET(getBlockDim, ntid)
+GET(getThreadIdx, tid)
+
+// Instead of externs for these registers, we turn access to them into calls 
into trivial ASM
+#define blockIdx (getBlockIdx())
+#define blockDim (getBlockDim())
+#define threadIdx (getThreadIdx())
+
+// Basic initializers (simple macros rather than inline functions)
+#define make_uchar2(a, b) ((uchar2){.x = a, .y = b})
+#define make_ushort2(a, b) ((ushort2){.x = a, .y = b})
+#define make_uchar4(a, b, c, d) ((uchar4){.x = a, .y = b, .z = c, .w = d})
+#define make_ushort4(a, b, c, d) ((ushort4){.x = a, .y = b, .z = c, .w = d})
+
+// Conversions from the tex instruction's 4-register output to various types
+#define TEX2D(type, ret) static inline __device__ void conv(type* out, 
unsigned a, unsigned b, unsigned c, unsigned d) {*out = (ret);}
+
+TEX2D(unsigned char, a & 0xFF)
+TEX2D(unsigned short, a & 0x)
+TEX2D(uchar2, make_uchar2(a & 0xFF, b & 0xFF))
+TEX2D(ushort2, make_ushort2(a & 0x, b & 0x))
+TEX2D(uchar4, make_uchar4(a & 0xFF, b & 0xFF, c & 0xFF, d & 0xFF))
+TEX2D(ushort4, make_ushort4(a & 0x, b & 0x, c & 0x, d & 0x))
+
+// Template calling tex instruction and converting the output to the selected 
type
+template 
+static inline __device__ T tex2D(cudaTextureObject_t texObject, float x, float 
y)
+{
+  T ret;
+  unsigned ret1, ret2, ret3, ret4;
+  

Re: [FFmpeg-devel] [PATCH 2/2] lavfi/vf_thumbnail_cuda: fix operator precedence bug

[Timo Rothenpieler]

applied



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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] compat/cuda: Change inclusion guards

[Timo Rothenpieler]

On 05/08/2019 03:09, Andreas Rheinhardt wrote:

cuda_runtime.h as well as dynlink_loader.h used nonstandard inclusion
guards with an AV_ prefix, although these files are not in an libav*/
path. So change the inclusion guards and adapt the ref file of the
source fate test accordingly.

Signed-off-by: Andreas Rheinhardt 


applied.

Thanks!



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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] configure: cuda_llvm: fix include path for MSYS2

[Timo Rothenpieler]

On 05.08.2019 21:47, Ricardo Constantino wrote:

MSYS2 converts paths to MinGW-based applications from unix to
pseudo-windows paths on execution time.
Since there was no space between '-include' and the path, MSYS2 doesn't
detect the path properly.
---
  configure | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure b/configure
index bddc05b850..34c2adb4a4 100755
--- a/configure
+++ b/configure
@@ -6094,7 +6094,7 @@ fi
  if enabled cuda_nvcc; then
  nvccflags="$nvccflags -ptx"
  else
-nvccflags="$nvccflags -S -nocudalib -nocudainc --cuda-device-only 
-include${source_link}/compat/cuda/cuda_runtime.h"
+nvccflags="$nvccflags -S -nocudalib -nocudainc --cuda-device-only -include 
${source_link}/compat/cuda/cuda_runtime.h"
  check_nvcc cuda_llvm
  fi
  



Are you sure this is necessary? source_link only ever points to either . 
or src, and I don't see why msys2 would need to fix that, since it's a 
relative path.




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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v2] libavcodec/amfenc: Vulkan initialization support for encoder.

[Timo Rothenpieler]

On 08/08/2019 20:33, OvchinnikovDmitrii wrote:

Added linux support for amf encoder through vulkan.

To use h.264(AMD VCE) encoder on linux amdgru-pro version 19.20+ and 
amf-amdgpu-pro package(amdgru-pro contains, but does not install automatically) 
are required.
This driver can be installed using amdgpu-pro-install script in official amd 
driver archive.

Initialization of amf encoder occurs in this order:
1) trying to initialize through dx11(only windows)
2) trying to initialize through dx9(only windows)
3) trying to initialize through vulkan

Only Vulkan initialization available on linux.



Is it possible to use Vulkan on Windows? For Interop with OpenCL and the 
like that could come very handy.




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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".