Re: [FFmpeg-devel] [PATCH 1/6] cbs_h264: Fix handling of unknown SEI

2018-05-07 Thread Xiang, Haihao
On Tue, 2018-05-08 at 00:11 +0100, Mark Thompson wrote:
> The user should only interact directly with the data length, not the
> payload size.
> ---
>  libavcodec/cbs_h264_syntax_template.c | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/libavcodec/cbs_h264_syntax_template.c
> b/libavcodec/cbs_h264_syntax_template.c
> index 3ec4299915..b789207e33 100644
> --- a/libavcodec/cbs_h264_syntax_template.c
> +++ b/libavcodec/cbs_h264_syntax_template.c
> @@ -761,8 +761,11 @@ static int FUNC(sei_payload)(CodedBitstreamContext *ctx,
> RWContext *rw,
>  break;
>  default:
>  {
> -allocate(current->payload.other.data, current->payload_size);
> -for (i = 0; i < current->payload_size; i++)
> +#ifdef READ
> +current->payload.other.data_length = current->payload_size;
> +#endif
> +allocate(current->payload.other.data, current-
> >payload.other.data_length);
> +for (i = 0; i < current->payload.other.data_length; i++)
>  xu(8, payload_byte[i], current->payload.other.data[i], 0,
> 255, 1, i);
>  }
>  }

LGTM, I will need to fix the H265 one as well. 
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH 2/4] vaapi_encode_h265: Insert mastering display colour colume if needed

2018-05-07 Thread Xiang, Haihao
On Mon, 2018-05-07 at 22:03 +0100, Mark Thompson wrote:
> On 04/05/18 09:54, Xiang, Haihao wrote:
> > On Thu, 2018-05-03 at 22:43 +0100, Mark Thompson wrote:
> > > On 03/05/18 04:07, Haihao Xiang wrote:
> > > > '-sei xxx' is added to control SEI insertion, so far only mastering
> > > > display colour colume is available for testing.
> > > 
> > > Typo: "colume" (also in the commit title).
> > > 
> > 
> > Thanks for catching the typo, I will correct it in the new version of patch.
> > 
> > > > v2: use the mastering display parameters from
> > > > AVMasteringDisplayMetadata, set SEI_MASTERING_DISPLAY to 8 to match
> > > > the H.264 part and take VAAPIEncodeH265Context::sei_needed as a ORed
> > > > value so that we needn't check the correspoding SEI message again when
> > > > writting the header.
> > > > 
> > > > Signed-off-by: Haihao Xiang 
> > > > ---
> > > >  libavcodec/vaapi_encode_h265.c | 128
> > > > -
> > > >  1 file changed, 127 insertions(+), 1 deletion(-)
> > > > 
> > > > diff --git a/libavcodec/vaapi_encode_h265.c
> > > > b/libavcodec/vaapi_encode_h265.c
> > > > index 5203c6871d..326fe4fe66 100644
> > > > --- a/libavcodec/vaapi_encode_h265.c
> > > > +++ b/libavcodec/vaapi_encode_h265.c
> > > > @@ -24,15 +24,20 @@
> > > >  #include "libavutil/avassert.h"
> > > >  #include "libavutil/common.h"
> > > >  #include "libavutil/opt.h"
> > > > +#include "libavutil/mastering_display_metadata.h"
> > > >  
> > > >  #include "avcodec.h"
> > > >  #include "cbs.h"
> > > >  #include "cbs_h265.h"
> > > >  #include "hevc.h"
> > > > +#include "hevc_sei.h"
> > > >  #include "internal.h"
> > > >  #include "put_bits.h"
> > > >  #include "vaapi_encode.h"
> > > >  
> > > > +enum {
> > > > +SEI_MASTERING_DISPLAY   = 0x08,
> > > > +};
> > > >  
> > > >  typedef struct VAAPIEncodeH265Context {
> > > >  unsigned int ctu_width;
> > > > @@ -47,6 +52,9 @@ typedef struct VAAPIEncodeH265Context {
> > > >  H265RawSPS sps;
> > > >  H265RawPPS pps;
> > > >  H265RawSlice slice;
> > > > +H265RawSEI sei;
> > > > +
> > > > +H265RawSEIMasteringDiplayColourVolume mastering_display;
> > > >  
> > > >  int64_t last_idr_frame;
> > > >  int pic_order_cnt;
> > > > @@ -58,6 +66,7 @@ typedef struct VAAPIEncodeH265Context {
> > > >  CodedBitstreamContext *cbc;
> > > >  CodedBitstreamFragment current_access_unit;
> > > >  int aud_needed;
> > > > +int sei_needed;
> > > >  } VAAPIEncodeH265Context;
> > > >  
> > > >  typedef struct VAAPIEncodeH265Options {
> > > > @@ -65,6 +74,7 @@ typedef struct VAAPIEncodeH265Options {
> > > >  int aud;
> > > >  int profile;
> > > >  int level;
> > > > +int sei;
> > > >  } VAAPIEncodeH265Options;
> > > >  
> > > >  
> > > > @@ -175,6 +185,64 @@ fail:
> > > >  return err;
> > > >  }
> > > >  
> > > > +static int vaapi_encode_h265_write_extra_header(AVCodecContext *avctx,
> > > > +VAAPIEncodePicture
> > > > *pic,
> > > > +int index, int *type,
> > > > +char *data, size_t
> > > > *data_len)
> > > > +{
> > > > +VAAPIEncodeContext  *ctx = avctx->priv_data;
> > > > +VAAPIEncodeH265Context *priv = ctx->priv_data;
> > > > +CodedBitstreamFragment   *au = >current_access_unit;
> > > > +int err, i;
> > > > +
> > > > +if (priv->sei_needed) {
> > > > +if (priv->aud_needed) {
> > > > +err = vaapi_encode_h265_add_nal(avctx, au, >aud);
> > > > +if (err < 0)
> > > > +goto fail;
> > > > +priv->aud_needed = 0;
> > > > +}
> > > > +
> > > > +memset(>sei, 0, sizeof(priv->sei));
> > > > +priv->sei.nal_unit_header  = (H265RawNALUnitHeader) {
> > > > +.nal_unit_type = HEVC_NAL_SEI_PREFIX,
> > > > +.nuh_layer_id  = 0,
> > > > +.nuh_temporal_id_plus1 = 1,
> > > > +};
> > > > +
> > > > +i = 0;
> > > > +
> > > > +if (priv->sei_needed & SEI_MASTERING_DISPLAY) {
> > > > +priv->sei.payload[i].payload_type =
> > > > HEVC_SEI_TYPE_MASTERING_DISPLAY_INFO;
> > > > +priv->sei.payload[i].payload.mastering_display = priv-
> > > > > mastering_display;
> > > > 
> > > > +++i;
> > > > +}
> > > > +
> > > > +priv->sei.payload_count = i;
> > > > +av_assert0(priv->sei.payload_count > 0);
> > > > +
> > > > +err = vaapi_encode_h265_add_nal(avctx, au, >sei);
> > > > +if (err < 0)
> > > > +goto fail;
> > > > +priv->sei_needed = 0;
> > > > +
> > > > +err = vaapi_encode_h265_write_access_unit(avctx, data,
> > > > data_len,
> > > > au);
> > > > +if (err < 0)
> > > > +goto fail;
> > > > +
> > > > +ff_cbs_fragment_uninit(priv->cbc, au);
> > > > +
> > > > +*type = 

Re: [FFmpeg-devel] [PATCH 3/3] vaapi_encode_vp8: memset the the structure to 0

2018-05-07 Thread Xiang, Haihao
On Mon, 2018-05-07 at 21:48 +0100, Mark Thompson wrote:
> On 04/05/18 15:41, Haihao Xiang wrote:
> > The structure has reserved bytes, it is required to set the reserved
> > bytes to 0 for future use.
> > 
> > Signed-off-by: Haihao Xiang 
> > ---
> >  libavcodec/vaapi_encode_vp8.c | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/libavcodec/vaapi_encode_vp8.c b/libavcodec/vaapi_encode_vp8.c
> > index b4c5521d1f..a2e861a8d1 100644
> > --- a/libavcodec/vaapi_encode_vp8.c
> > +++ b/libavcodec/vaapi_encode_vp8.c
> > @@ -143,6 +143,8 @@ static int
> > vaapi_encode_vp8_write_quant_table(AVCodecContext *avctx,
> >  *type = VAQMatrixBufferType;
> >  *data_len = sizeof(quant);
> >  
> > +memset(, 0, sizeof(quant));
> > +
> >  if (pic->type == PICTURE_TYPE_P)
> >  q = priv->q_index_p;
> >  else
> > 
> 
> Yep, applied.
> 
> (... is there any plan to add anything to that structure?)
> 

Thanks for applying the patch and so far there is no plan to change that
structure. 


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


Re: [FFmpeg-devel] [PATCH 2/3] hwcontext_vaapi: Return error if can not find a VA RT format

2018-05-07 Thread Xiang, Haihao
On Mon, 2018-05-07 at 21:48 +0100, Mark Thompson wrote:
> On 04/05/18 15:41, Haihao Xiang wrote:
> > Otherwise va_rt_format might be unitialized
> > 
> > Signed-off-by: Haihao Xiang 
> > ---
> >  libavutil/hwcontext_vaapi.c | 5 +
> >  1 file changed, 5 insertions(+)
> > 
> > diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
> > index 7daaa951cc..e59042487d 100644
> > --- a/libavutil/hwcontext_vaapi.c
> > +++ b/libavutil/hwcontext_vaapi.c
> > @@ -1028,6 +1028,11 @@ static int vaapi_map_from_drm(AVHWFramesContext
> > *src_fc, AVFrame *dst,
> >  va_rt_format = vaapi_format_map[i].rt_format;
> >  }
> >  
> > +if (i >= FF_ARRAY_ELEMS(vaapi_format_map)) {
> > +av_log(dst_fc, AV_LOG_ERROR, "No matching VA RT format \n");
> > +return AVERROR(EINVAL);
> > +}
> > +
> >  buffer_handle = desc->objects[0].fd;
> >  buffer_desc.pixel_format = va_fourcc;
> >  buffer_desc.width= src_fc->width;
> > 
> 
> How would you hit this case?  Every fourcc in vaapi_drm_format_map is also
> present in vaapi_format_map.

It is reported by static analysis tool as well. I think adding a check here make
s sure the relationship between vaapi_drm_format_map and vaapi_format_map. or
how about av_assert0(i < FF_ARRAY_ELEMS(vaapi_format_map)) if you don't want to
add the if()?

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


Re: [FFmpeg-devel] [PATCH] avutil/hwcontext_cuda: add AVCUDAFramesContext and AVCUDAFramesContext.flags

2018-05-07 Thread Wang Bin
2018-05-08 5:10 GMT+08:00 Timo Rothenpieler :

> Frames can be mapped from nvdec/cuvid, not needing any actual memory
> allocation, but all other features of the hw_frames_ctx.
> Hence the dummy-mode, which does not allocate any (notable amounts of)
> memory but otherwise behaves the exact same.
> ---
>  doc/APIchanges |  3 +++
>  libavutil/hwcontext_cuda.c | 10 ++
>  libavutil/hwcontext_cuda.h | 18 +-
>  libavutil/version.h|  2 +-
>  4 files changed, 31 insertions(+), 2 deletions(-)
>
> diff --git a/doc/APIchanges b/doc/APIchanges
> index ede5b186ae..82ec888fd8 100644
> --- a/doc/APIchanges
> +++ b/doc/APIchanges
> @@ -15,6 +15,9 @@ libavutil: 2017-10-21
>
>  API changes, most recent first:
>
> +2018-05-xx - xx - lavu 56.19.100 - hwcontext.h
> +  Add AVCUDAFramesContext and AVCUDAFramesContext.flags.
> +
>  2018-04-xx - xx - lavu 56.18.100 - pixdesc.h
>Add AV_PIX_FMT_FLAG_ALPHA to AV_PIX_FMT_PAL8.
>
> diff --git a/libavutil/hwcontext_cuda.c b/libavutil/hwcontext_cuda.c
> index 37827a770c..0d867ef0f5 100644
> --- a/libavutil/hwcontext_cuda.c
> +++ b/libavutil/hwcontext_cuda.c
> @@ -83,6 +83,7 @@ static void cuda_buffer_free(void *opaque, uint8_t *data)
>  static AVBufferRef *cuda_pool_alloc(void *opaque, int size)
>  {
>  AVHWFramesContext *ctx = opaque;
> +AVCUDAFramesContext *frctx = ctx->hwctx;
>  AVCUDADeviceContext *hwctx = ctx->device_ctx->hwctx;
>  CudaFunctions  *cu = hwctx->internal->cuda_dl;
>
> @@ -97,6 +98,10 @@ static AVBufferRef *cuda_pool_alloc(void *opaque, int
> size)
>  return NULL;
>  }
>
> +// A lot of places expect the pointer to be !=NULL, so make minimum
> allocation instead.
> +if (frctx->flags & AV_CUDA_HWFRAMES_DUMMY_MODE)
> +size = 1;
> +
>  err = cu->cuMemAlloc(, size);
>  if (err != CUDA_SUCCESS)
>  goto fail;
> @@ -161,6 +166,7 @@ static int cuda_frames_init(AVHWFramesContext *ctx)
>
>  static int cuda_get_buffer(AVHWFramesContext *ctx, AVFrame *frame)
>  {
> +AVCUDAFramesContext *frctx = ctx->hwctx;
>  int aligned_width;
>  int width_in_bytes = ctx->width;
>
> @@ -210,6 +216,9 @@ static int cuda_get_buffer(AVHWFramesContext *ctx,
> AVFrame *frame)
>  frame->width  = ctx->width;
>  frame->height = ctx->height;
>
> +if (frctx->flags & AV_CUDA_HWFRAMES_DUMMY_MODE)
> +frame->data[0] = frame->data[1] = frame->data[2] = NULL;
> +
>  return 0;
>  }
>
> @@ -402,6 +411,7 @@ const HWContextType ff_hwcontext_type_cuda = {
>  .name = "CUDA",
>
>  .device_hwctx_size= sizeof(AVCUDADeviceContext),
> +.frames_hwctx_size= sizeof(AVCUDAFramesContext),
>  .frames_priv_size = sizeof(CUDAFramesContext),
>
>  .device_create= cuda_device_create,
> diff --git a/libavutil/hwcontext_cuda.h b/libavutil/hwcontext_cuda.h
> index 12dae8449e..388d6f8f1c 100644
> --- a/libavutil/hwcontext_cuda.h
> +++ b/libavutil/hwcontext_cuda.h
> @@ -45,7 +45,23 @@ typedef struct AVCUDADeviceContext {
>  } AVCUDADeviceContext;
>
>  /**
> - * AVHWFramesContext.hwctx is currently not used
> + * This struct is allocated as AVHWFramesContext.hwctx
>   */
> +typedef struct AVCUDAFramesContext {
> +/**
> + * Special implementation-specific flags.
> + *
> + * Must be set by the user before calling av_hwframe_ctx_init().
> + */
> +int flags;
> +} AVCUDAFramesContext;
> +
> +/**
> + * No actual allocation will happen, but otherwise behaves like normal.
> + *
> + * This is to be used if a AVHWFramesContext is required, but the actual
> + * allocation has to happen outside of it.
> + */
> +#define AV_CUDA_HWFRAMES_DUMMY_MODE (1 << 0)
>
>  #endif /* AVUTIL_HWCONTEXT_CUDA_H */
> diff --git a/libavutil/version.h b/libavutil/version.h
> index 5185454d9b..84409b1d69 100644
> --- a/libavutil/version.h
> +++ b/libavutil/version.h
> @@ -79,7 +79,7 @@
>   */
>
>  #define LIBAVUTIL_VERSION_MAJOR  56
> -#define LIBAVUTIL_VERSION_MINOR  18
> +#define LIBAVUTIL_VERSION_MINOR  19
>  #define LIBAVUTIL_VERSION_MICRO 100
>
>  #define LIBAVUTIL_VERSION_INT   AV_VERSION_INT(LIBAVUTIL_VERSION_MAJOR, \
> --
>

I think the flag should be added in avcodec, maybe AVCodecContext.flags2,
becuase
1. This flag is used by cuda decoder only, but not works avfilter and other
cuda apis.
2. Other hw codecs may support referencing the decoded memory instead of
copying it, for example, mmal decoder. see
https://github.com/wang-bin/FFmpeg/commit/74390ec836743dd337c92dd5da5f4f9ff638316b#diff-26a23a40f16babe0068c7340c6160472
3. the flag can be turned on/off at any time
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH 1/3] vaapi_encode: Initialize the pointer

2018-05-07 Thread Xiang, Haihao
On Mon, 2018-05-07 at 21:46 +0100, Mark Thompson wrote:
> On 04/05/18 15:41, Haihao Xiang wrote:
> > Otherwise it might use unitialized last_pic in av_assert0(last_pic)
> > 
> > Signed-off-by: Haihao Xiang 
> > ---
> >  libavcodec/vaapi_encode.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
> > index 36c85a3815..141e50c8ad 100644
> > --- a/libavcodec/vaapi_encode.c
> > +++ b/libavcodec/vaapi_encode.c
> > @@ -760,7 +760,7 @@ fail:
> >  static int vaapi_encode_truncate_gop(AVCodecContext *avctx)
> >  {
> >  VAAPIEncodeContext *ctx = avctx->priv_data;
> > -VAAPIEncodePicture *pic, *last_pic, *next;
> > +VAAPIEncodePicture *pic, *last_pic = NULL, *next;
> >  
> >  // Find the last picture we actually have input for.
> >  for (pic = ctx->pic_start; pic; pic = pic->next) {
> > 
> 
> How do you hit this?  last_pic should always get set.
> 

It was reported by some static analysis tools, but I agree with you that
last_pic should get set in the code path, however if we consider
vaapi_encode_truncate_gop() only,  last_pic will be uninitialized if ctx-
>pic_start is non-NULL but ctx->pic_start->input_available is not set. How about
to add av_assert0(!ctx->pic_start || ctx->pic_start->input_available) before the
 for () statement and remove av_assert0(last_pic)?


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


Re: [FFmpeg-devel] [PATCH v2 04/10] lavfi/nlmeans: add AArch64 SIMD for compute_safe_ssd_integral_image

2018-05-07 Thread Michael Niedermayer
On Mon, May 07, 2018 at 07:24:16PM +0200, Clément Bœsch wrote:
> ssd_integral_image_c: 49204.6
> ssd_integral_image_neon: 28346.8
> ---
>  libavfilter/aarch64/Makefile  |  3 +
>  libavfilter/aarch64/vf_nlmeans_init.c | 33 +++
>  libavfilter/aarch64/vf_nlmeans_neon.S | 80 +++
>  libavfilter/vf_nlmeans.c  | 26 ++---
>  libavfilter/vf_nlmeans.h  | 35 
>  5 files changed, 170 insertions(+), 7 deletions(-)
>  create mode 100644 libavfilter/aarch64/Makefile
>  create mode 100644 libavfilter/aarch64/vf_nlmeans_init.c
>  create mode 100644 libavfilter/aarch64/vf_nlmeans_neon.S
>  create mode 100644 libavfilter/vf_nlmeans.h

seems to break make testprogs unless iam missing something

CC  libavfilter/tests/integral.o
libavfilter/tests/integral.c: In function ‘main’:
libavfilter/tests/integral.c:68:40: warning: passing argument 1 of 
‘compute_ssd_integral_image’ from incompatible pointer type [enabled by default]
src, lz, xoff, yoff, e, w, h);
^
In file included from libavfilter/tests/integral.c:19:0:
./libavfilter/vf_nlmeans.c:244:13: note: expected ‘const struct 
NLMeansDSPContext *’ but argument is of type ‘uint32_t *’
 static void compute_ssd_integral_image(const NLMeansDSPContext *dsp,
 ^
libavfilter/tests/integral.c:68:40: warning: passing argument 2 of 
‘compute_ssd_integral_image’ makes pointer from integer without a cast [enabled 
by default]
src, lz, xoff, yoff, e, w, h);
^
In file included from libavfilter/tests/integral.c:19:0:
./libavfilter/vf_nlmeans.c:244:13: note: expected ‘uint32_t *’ but argument is 
of type ‘int’
 static void compute_ssd_integral_image(const NLMeansDSPContext *dsp,
 ^
libavfilter/tests/integral.c:68:40: warning: passing argument 3 of 
‘compute_ssd_integral_image’ makes integer from pointer without a cast [enabled 
by default]
src, lz, xoff, yoff, e, w, h);
^
In file included from libavfilter/tests/integral.c:19:0:
./libavfilter/vf_nlmeans.c:244:13: note: expected ‘ptrdiff_t’ but argument is 
of type ‘const uint8_t *’
 static void compute_ssd_integral_image(const NLMeansDSPContext *dsp,
 ^
libavfilter/tests/integral.c:68:40: warning: passing argument 4 of 
‘compute_ssd_integral_image’ makes pointer from integer without a cast [enabled 
by default]
src, lz, xoff, yoff, e, w, h);
^
In file included from libavfilter/tests/integral.c:19:0:
./libavfilter/vf_nlmeans.c:244:13: note: expected ‘const uint8_t *’ but 
argument is of type ‘int’
 static void compute_ssd_integral_image(const NLMeansDSPContext *dsp,
 ^
libavfilter/tests/integral.c:68:40: error: too few arguments to function 
‘compute_ssd_integral_image’
src, lz, xoff, yoff, e, w, h);
^
In file included from libavfilter/tests/integral.c:19:0:
./libavfilter/vf_nlmeans.c:244:13: note: declared here
 static void compute_ssd_integral_image(const NLMeansDSPContext *dsp,
 ^
make: *** [libavfilter/tests/integral.o] Error 1
make: Target `testprogs' not remade because of errors.

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

If you drop bombs on a foreign country and kill a hundred thousand
innocent people, expect your government to call the consequence
"unprovoked inhuman terrorist attacks" and use it to justify dropping
more bombs and killing more people. The technology changed, the idea is old.


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


Re: [FFmpeg-devel] [PATCH 6/6] fate/cbs: Add an SEI test

2018-05-07 Thread Mark Thompson
On 08/05/18 01:06, James Almer wrote:
> On 5/7/2018 8:11 PM, Mark Thompson wrote:
>> The artificial sample file sei-1.h264 contains five frames (IDR P B I B)
>> and the following SEI message types:
>> * Buffering period
>> * Picture timing
>> * Pan-scan rectangle (display as 4:3)
>> * User data registered, containing A/53 closed captions (captions match
>>   frame content, including reordering)
>> * Recovery point (at the I frame)
>> * Display orientation (identity transformation)
>> * Mastering display (with arbitrary contents)
>> * Undefined SEI type 1234 (containing ascending bytes)
>> ---
>> Sample file at .  (Named -1 
>> anticipating the possibility of adding more in future.)
>>
>> 140ddba635960ac73935a0fb268748a43c647151  fate/h264/sei-1.h264
> 
> If you crafted this file using the mastering display implementation from
> patch 5/6 then you may need to create it again with the fixed element sizes.

It didn't change because the numbers I had there were < 2^16, but I've 
regenerated anyway with a larger number as max so that it does get tested.

b8f3b5443c8e437a83d36a72657478529c2afcfc  fate/h264/sei-1.h264

>>
>>
>>  tests/fate/cbs.mak | 8 ++--
>>  1 file changed, 6 insertions(+), 2 deletions(-)
>>
>> diff --git a/tests/fate/cbs.mak b/tests/fate/cbs.mak
>> index bee349ed45..911e7704aa 100644
>> --- a/tests/fate/cbs.mak
>> +++ b/tests/fate/cbs.mak
>> @@ -14,7 +14,7 @@ endef
>>  
>>  # H.264 read/write
>>  
>> -FATE_CBS_H264_SAMPLES =   \
>> +FATE_CBS_H264_CONFORMANCE_SAMPLES = \
>>  SVA_Base_B.264\
>>  BASQP1_Sony_C.jsv \
>>  FM1_BT_B.h264 \
>> @@ -30,7 +30,11 @@ FATE_CBS_H264_SAMPLES =   \
>>  CVSE2_Sony_B.jsv  \
>>  CABACI3_Sony_B.jsv
>>  
>> -$(foreach N,$(FATE_CBS_H264_SAMPLES),$(eval $(call 
>> FATE_CBS_TEST,h264,$(basename $(N)),h264-conformance/$(N),h264)))
>> +FATE_CBS_H264_SAMPLES = \
>> +sei-1.h264
>> +
>> +$(foreach N,$(FATE_CBS_H264_CONFORMANCE_SAMPLES),$(eval $(call 
>> FATE_CBS_TEST,h264,$(basename $(N)),h264-conformance/$(N),h264)))
>> +$(foreach N,$(FATE_CBS_H264_SAMPLES),$(eval $(call 
>> FATE_CBS_TEST,h264,$(basename $(N)),h264/$(N),h264)))
> 
> Missing ref files? Or it doesn't generate them?

Missed, sorry:

diff --git a/tests/ref/fate/cbs-h264-sei-1 b/tests/ref/fate/cbs-h264-sei-1
new file mode 100644
index 00..2d1cb1fe7f
--- /dev/null
+++ b/tests/ref/fate/cbs-h264-sei-1
@@ -0,0 +1 @@
+5f537551b7dfab76a172f1aebb028986

>>  
>>  FATE_CBS_H264-$(call FATE_CBS_DEPS, H264, H264, H264, H264, H264) = 
>> $(FATE_CBS_h264)
>>  FATE_SAMPLES_AVCONV += $(FATE_CBS_H264-yes)
>>

Thanks,

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


Re: [FFmpeg-devel] [PATCH 6/6] fate/cbs: Add an SEI test

2018-05-07 Thread James Almer
On 5/7/2018 8:11 PM, Mark Thompson wrote:
> The artificial sample file sei-1.h264 contains five frames (IDR P B I B)
> and the following SEI message types:
> * Buffering period
> * Picture timing
> * Pan-scan rectangle (display as 4:3)
> * User data registered, containing A/53 closed captions (captions match
>   frame content, including reordering)
> * Recovery point (at the I frame)
> * Display orientation (identity transformation)
> * Mastering display (with arbitrary contents)
> * Undefined SEI type 1234 (containing ascending bytes)
> ---
> Sample file at .  (Named -1 
> anticipating the possibility of adding more in future.)
> 
> 140ddba635960ac73935a0fb268748a43c647151  fate/h264/sei-1.h264

If you crafted this file using the mastering display implementation from
patch 5/6 then you may need to create it again with the fixed element sizes.

> 
> 
>  tests/fate/cbs.mak | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/tests/fate/cbs.mak b/tests/fate/cbs.mak
> index bee349ed45..911e7704aa 100644
> --- a/tests/fate/cbs.mak
> +++ b/tests/fate/cbs.mak
> @@ -14,7 +14,7 @@ endef
>  
>  # H.264 read/write
>  
> -FATE_CBS_H264_SAMPLES =   \
> +FATE_CBS_H264_CONFORMANCE_SAMPLES = \
>  SVA_Base_B.264\
>  BASQP1_Sony_C.jsv \
>  FM1_BT_B.h264 \
> @@ -30,7 +30,11 @@ FATE_CBS_H264_SAMPLES =   \
>  CVSE2_Sony_B.jsv  \
>  CABACI3_Sony_B.jsv
>  
> -$(foreach N,$(FATE_CBS_H264_SAMPLES),$(eval $(call 
> FATE_CBS_TEST,h264,$(basename $(N)),h264-conformance/$(N),h264)))
> +FATE_CBS_H264_SAMPLES = \
> +sei-1.h264
> +
> +$(foreach N,$(FATE_CBS_H264_CONFORMANCE_SAMPLES),$(eval $(call 
> FATE_CBS_TEST,h264,$(basename $(N)),h264-conformance/$(N),h264)))
> +$(foreach N,$(FATE_CBS_H264_SAMPLES),$(eval $(call 
> FATE_CBS_TEST,h264,$(basename $(N)),h264/$(N),h264)))

Missing ref files? Or it doesn't generate them?

>  
>  FATE_CBS_H264-$(call FATE_CBS_DEPS, H264, H264, H264, H264, H264) = 
> $(FATE_CBS_h264)
>  FATE_SAMPLES_AVCONV += $(FATE_CBS_H264-yes)
> 

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


Re: [FFmpeg-devel] [PATCH 5/6] cbs_h264: Add support for mastering display SEI messages

2018-05-07 Thread James Almer
On 5/7/2018 8:11 PM, Mark Thompson wrote:
> ---
>  libavcodec/cbs_h264.h | 10 ++
>  libavcodec/cbs_h2645.c|  1 +
>  libavcodec/cbs_h264_syntax_template.c | 23 +++
>  libavcodec/h264_sei.h |  1 +
>  4 files changed, 35 insertions(+)
> 
> diff --git a/libavcodec/cbs_h264.h b/libavcodec/cbs_h264.h
> index b9536611ef..c46dd5064c 100644
> --- a/libavcodec/cbs_h264.h
> +++ b/libavcodec/cbs_h264.h
> @@ -306,6 +306,15 @@ typedef struct H264RawSEIDisplayOrientation {
>  uint8_t display_orientation_extension_flag;
>  } H264RawSEIDisplayOrientation;
>  
> +typedef struct H264RawSEIMasteringDisplayColourVolume {
> +uint16_t display_primaries_x[3];
> +uint16_t display_primaries_y[3];
> +uint16_t white_point_x;
> +uint16_t white_point_y;
> +uint16_t max_display_mastering_luminance;
> +uint16_t min_display_mastering_luminance;

These two should be uint32_t.

> +} H264RawSEIMasteringDisplayColourVolume;
> +
>  typedef struct H264RawSEIPayload {
>  uint32_t payload_type;
>  uint32_t payload_size;
> @@ -318,6 +327,7 @@ typedef struct H264RawSEIPayload {
>  H264RawSEIUserDataUnregistered user_data_unregistered;
>  H264RawSEIRecoveryPoint recovery_point;
>  H264RawSEIDisplayOrientation display_orientation;
> +H264RawSEIMasteringDisplayColourVolume 
> mastering_display_colour_volume;
>  struct {
>  uint8_t *data;
>  size_t data_length;
> diff --git a/libavcodec/cbs_h2645.c b/libavcodec/cbs_h2645.c
> index b8194cb3b1..7354a949cf 100644
> --- a/libavcodec/cbs_h2645.c
> +++ b/libavcodec/cbs_h2645.c
> @@ -427,6 +427,7 @@ static void cbs_h264_free_sei_payload(H264RawSEIPayload 
> *payload)
>  case H264_SEI_TYPE_PAN_SCAN_RECT:
>  case H264_SEI_TYPE_RECOVERY_POINT:
>  case H264_SEI_TYPE_DISPLAY_ORIENTATION:
> +case H264_SEI_TYPE_MASTERING_DISPLAY_COLOUR_VOLUME:
>  break;
>  case H264_SEI_TYPE_USER_DATA_REGISTERED:
>  av_buffer_unref(>payload.user_data_registered.data_ref);
> diff --git a/libavcodec/cbs_h264_syntax_template.c 
> b/libavcodec/cbs_h264_syntax_template.c
> index fb1685e6e6..027b555db6 100644
> --- a/libavcodec/cbs_h264_syntax_template.c
> +++ b/libavcodec/cbs_h264_syntax_template.c
> @@ -740,6 +740,25 @@ static int 
> FUNC(sei_display_orientation)(CodedBitstreamContext *ctx, RWContext *
>  return 0;
>  }
>  
> +static int FUNC(sei_mastering_display_colour_volume)(CodedBitstreamContext 
> *ctx, RWContext *rw,
> + 
> H264RawSEIMasteringDisplayColourVolume *current)
> +{
> +int err, c;
> +
> +for (c = 0; c < 3; c++) {
> +us(16, display_primaries_x[c], 0, 5, 1, c);
> +us(16, display_primaries_y[c], 0, 5, 1, c);
> +}
> +
> +u(16, white_point_x, 0, 5);
> +u(16, white_point_y, 0, 5);
> +
> +u(32, max_display_mastering_luminance, 1, MAX_UINT_BITS(32));
> +u(32, min_display_mastering_luminance, 0, 
> current->max_display_mastering_luminance - 1);
> +
> +return 0;
> +}
> +
>  static int FUNC(sei_payload)(CodedBitstreamContext *ctx, RWContext *rw,
>   H264RawSEIPayload *current)
>  {
> @@ -787,6 +806,10 @@ static int FUNC(sei_payload)(CodedBitstreamContext *ctx, 
> RWContext *rw,
>  CHECK(FUNC(sei_display_orientation)
>(ctx, rw, >payload.display_orientation));
>  break;
> +case H264_SEI_TYPE_MASTERING_DISPLAY_COLOUR_VOLUME:
> +CHECK(FUNC(sei_mastering_display_colour_volume)
> +  (ctx, rw, >payload.mastering_display_colour_volume));
> +break;
>  default:
>  {
>  #ifdef READ
> diff --git a/libavcodec/h264_sei.h b/libavcodec/h264_sei.h
> index 6455f3cec5..a169a10e49 100644
> --- a/libavcodec/h264_sei.h
> +++ b/libavcodec/h264_sei.h
> @@ -35,6 +35,7 @@ typedef enum {
>  H264_SEI_TYPE_FRAME_PACKING  = 45,  ///< frame packing 
> arrangement
>  H264_SEI_TYPE_DISPLAY_ORIENTATION= 47,  ///< display orientation
>  H264_SEI_TYPE_GREEN_METADATA = 56,  ///< GreenMPEG information
> +H264_SEI_TYPE_MASTERING_DISPLAY_COLOUR_VOLUME = 137,  ///< mastering 
> display properties
>  H264_SEI_TYPE_ALTERNATIVE_TRANSFER   = 147, ///< alternative transfer
>  } H264_SEI_Type;
>  
> 

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


Re: [FFmpeg-devel] libavutil/encryption_info: Allow multiple init info.

2018-05-07 Thread Jacob Trimble
On Mon, May 7, 2018 at 3:18 PM, Michael Niedermayer
 wrote:
> On Mon, Apr 23, 2018 at 11:03:57AM -0700, Jacob Trimble wrote:
>> While integrating my encryption info changes, I noticed a problem with
>> the init info structs.  I implemented them as side-data on the Stream.
>> But this means there can only be one per stream.  However, there can
>> be multiple 'pssh' atoms in a single stream (e.g. for key rotation or
>> multiple key systems). (sorry for not noticing sooner)
>>
>> Attached is a patch to fix this by making the init info a
>> singly-linked-list.  It is ABI compatible and is still easy to use and
>> understand.  The alternative would be to break ABI and have the
>> side-data methods return an array of pointers.  I could do that
>> instead if that is preferable.
>
>>  encryption_info.c |  154 
>> +++---
>>  encryption_info.h |5 +
>>  2 files changed, 106 insertions(+), 53 deletions(-)
>> e5eecc73a6997bbd11541771372d38ea9c3972a7  
>> 0001-libavutil-encryption_info-Allow-multiple-init-info.patch
>> From bb941a77e882e93629d63d63059d0063b9519e29 Mon Sep 17 00:00:00 2001
>> From: Jacob Trimble 
>> Date: Mon, 23 Apr 2018 10:33:58 -0700
>> Subject: [PATCH] libavutil/encryption_info: Allow multiple init info.
>>
>> It is possible for there to be multiple encryption init info structure.
>> For example, to support multiple key systems or in key rotation.  This
>> changes the AVEncryptionInitInfo struct to be a linked list so there
>> can be multiple structs without breaking ABI.
>>
>> Signed-off-by: Jacob Trimble 
>> ---
>>  libavutil/encryption_info.c | 154 +++-
>>  libavutil/encryption_info.h |   5 ++
>>  2 files changed, 106 insertions(+), 53 deletions(-)
>>
>> diff --git a/libavutil/encryption_info.c b/libavutil/encryption_info.c
>> index 20a752d6b4..9935c10d74 100644
>> --- a/libavutil/encryption_info.c
>> +++ b/libavutil/encryption_info.c
>> @@ -160,13 +160,16 @@ uint8_t *av_encryption_info_add_side_data(const 
>> AVEncryptionInfo *info, size_t *
>>  }
>>
>>  // The format of the AVEncryptionInitInfo side data:
>> -// u32be system_id_size
>> -// u32be num_key_ids
>> -// u32be key_id_size
>> -// u32be data_size
>> -// u8[system_id_size] system_id
>> -// u8[key_id_size][num_key_id] key_ids
>> -// u8[data_size] data
>> +// u32be init_info_count
>> +// {
>> +//   u32be system_id_size
>> +//   u32be num_key_ids
>> +//   u32be key_id_size
>> +//   u32be data_size
>> +//   u8[system_id_size] system_id
>> +//   u8[key_id_size][num_key_id] key_ids
>> +//   u8[data_size] data
>> +// }[init_info_count]
>>
>>  #define FF_ENCRYPTION_INIT_INFO_EXTRA 16
>>
>> @@ -215,6 +218,7 @@ void av_encryption_init_info_free(AVEncryptionInitInfo 
>> *info)
>>  for (i = 0; i < info->num_key_ids; i++) {
>>  av_free(info->key_ids[i]);
>>  }
>> +av_encryption_init_info_free(info->next);
>>  av_free(info->system_id);
>>  av_free(info->key_ids);
>>  av_free(info->data);
>> @@ -225,71 +229,115 @@ void 
>> av_encryption_init_info_free(AVEncryptionInitInfo *info)
>>  AVEncryptionInitInfo *av_encryption_init_info_get_side_data(
>>  const uint8_t *side_data, size_t side_data_size)
>>  {
>> -AVEncryptionInitInfo *info;
>> +AVEncryptionInitInfo *ret = NULL, *info;
>>  uint64_t system_id_size, num_key_ids, key_id_size, data_size, i;
>> +uint64_t init_info_count;
>>
>> -if (!side_data || side_data_size < FF_ENCRYPTION_INIT_INFO_EXTRA)
>> -return NULL;
>> -
>> -system_id_size = AV_RB32(side_data);
> [...]
>> +init_info_count = AV_RB32(side_data);
>
> i may be missing something but this looks like the meaning of the first
> field changes, this thus doesnt look compatible to me

It changes the binary format of the side-data, but that was explicitly
not part of ABI.  The fields in the structs are unchanged.  This would
only cause a problem if the side data bytes were stored out-of-band
from a different version of FFmpeg.

>
> also indention is quite inconsistent in the new code

One of these days, I'll remember that this uses 4 spaces not 2.  Fixed.

>
> [...]
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Many that live deserve death. And some that die deserve life. Can you give
> it to them? Then do not be too eager to deal out death in judgement. For
> even the very wise cannot see all ends. -- Gandalf
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
From 039632f7b75da569f3e43780a9fa36454031f37e Mon Sep 17 00:00:00 2001
From: Jacob Trimble 
Date: Mon, 23 Apr 2018 10:33:58 -0700
Subject: [PATCH] libavutil/encryption_info: Allow multiple init info.

It is possible for there to be multiple encryption init info structure.
For example, to 

Re: [FFmpeg-devel] [GSOC] [PATCH] SRCNN filter

2018-05-07 Thread James Almer
On 5/7/2018 8:05 PM, Hendrik Leppkes wrote:
> On Sun, May 6, 2018 at 10:27 PM, James Almer  wrote:
>> On 5/5/2018 5:38 PM, James Almer wrote:
>>> On 4/10/2018 2:16 PM, Sergey Lavrushkin wrote:
 diff --git a/libavfilter/vf_srcnn.c b/libavfilter/vf_srcnn.c
 new file mode 100644
 index 00..d9b4891f7f
 --- /dev/null
 +++ b/libavfilter/vf_srcnn.c
 @@ -0,0 +1,420 @@
 +/*
 + * Copyright (c) 2018 Sergey Lavrushkin
 + *
 + * 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
 + */
 +
 +/**
 + * @file
 + * Filter implementing image super-resolution using deep convolutional 
 networks.
 + * https://arxiv.org/abs/1501.00092
 + */
 +
 +#include "avfilter.h"
 +#include "formats.h"
 +#include "internal.h"
 +#include "libavutil/opt.h"
 +#include "unistd.h"
>>>
>>> This broke msvc. It should be (if anything) , and wrapped
>>> inside a HAVE_UNISTD_H preprocessor check.
>>
>> I (accidentally) applied this change as part of an unrelated commit, so
>> that's dealt with at least.
>>
>>>
 +static av_cold int init(AVFilterContext* context)
 +{
 +SRCNNContext *srcnn_context = context->priv;
 +AVIOContext* config_file_context;
 +int64_t file_size, srcnn_size;
 +
 +/// Check specified confguration file name and read network weights 
 from it
 +if (!srcnn_context->config_file_path){
 +av_log(context, AV_LOG_INFO, "configuration file for network was 
 not specified, using default weights for x2 upsampling\n");
 +
 +/// Create convolution kernels and copy default weights
 +srcnn_context->conv1.input_channels = 1;
 +srcnn_context->conv1.output_channels = 64;
 +srcnn_context->conv1.size = 9;
 +CHECK_ALLOCATION(allocate_copy_conv_data(_context->conv1, 
 conv1_kernel, conv1_biases), )
 +
 +srcnn_context->conv2.input_channels = 64;
 +srcnn_context->conv2.output_channels = 32;
 +srcnn_context->conv2.size = 1;
 +CHECK_ALLOCATION(allocate_copy_conv_data(_context->conv2, 
 conv2_kernel, conv2_biases), )
 +
 +srcnn_context->conv3.input_channels = 32;
 +srcnn_context->conv3.output_channels = 1;
 +srcnn_context->conv3.size = 5;
 +CHECK_ALLOCATION(allocate_copy_conv_data(_context->conv3, 
 conv3_kernel, conv3_biases), )
 +}
 +else if (access(srcnn_context->config_file_path, R_OK) != -1){
>>>
>>> This seems to be the function needed from unistd.h
>>>
>>> Looking at configure and libavformat/file.c it's apparently not
>>> available everywhere (we have a HAVE_ACCESS define, and also check for
>>> mode constants like R_OK).
>>
>> MSVC does not have access(), so i have temporarily made this filter
>> depend on its presence until a proper fix is applied. That target has
>> been broken for a few days now and that shouldn't be the case.
>> It should be a matter or doing the same thing as in libavformat/file.c,
>> i guess, or perhaps use _access() instead, which is available in MSVC.
> 
> Your check doesn't work, MSVC building is still broken.
> Probably because MSVC does have access, in io.h, but it does not have
> the R_OK token.
> 
> - Hendrik

I sent a patch to make the access() check stricter.

access() in msvc is in any case kinda weird. The check as is succeeds
(so the function exists in some form in the c library) so HAVE_ACCESS is
set to true in both msvc and mingw, but msvc doesn't define R_OK or any
other such constant.
We have a wrapper using msvc's specific _access() in lavf that's
ultimately only used by mingw because the only file calling access() is
file.c and it first makes sure said constants are also set.

With my configure patch the check will only succeed on mingw, so
technically changing nothing as far as lavf is concerned, but
effectively disabling the filter on msvc so lavfi can compile.

Better solution of course welcome.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH 2/2] avcodec/libzvbi-teletextdec: formatted ass output

2018-05-07 Thread Aman Gupta
On Mon, May 7, 2018 at 4:07 PM, Marton Balint  wrote:

>
>
> On Mon, 7 May 2018, Aman Gupta wrote:
>
>
>>
>> On Mon, May 7, 2018 at 12:50 PM, Aman Gupta  wrote:
>>
>>
>>   On Sun, May 6, 2018 at 2:05 PM, Marton Balint 
>> wrote:
>> Inspired by the VideoLAN text decoder and its port to FFmpeg
>> made by Aman
>> Gupta.
>>
>>
>> Thanks for incorporating my changes.
>>
>> I ran some tests, and colors work as expected. Positioning also works
>> well, and is also pretty close to my version.
>>
>>
>> I found that some live streams are not chopping empty lines correctly. I
>> see extra newlines at the end:
>>
>>   Dialogue: 
>> 0,0:13:21.66,9:59:59.99,Default,,0,0,0,,{\an1}Simson,\hPeter\hHartcher,\hRobyn\hParker
>> \Nand\hBenjamin \N \N \N
>>
>> Here's a sample which shows extra newlines: https://s3.amazonaws
>> .com/tmm1/teletext/capture_live1.mpg
>>
>
> This is kind of intentional, in this case the new lines are kept to
> position the subtitles a bit higher, and not to the very bottom of the
> screen, to keep the rough position of the teletext subtitles. At first I
> used \pos as well, but it only worked once per line for me, so I had to use
> some kind of newline-positioning anyway, and using native vertical
> alignment instead of \pos seemed nicer. (E.g. it allows the user to change
> left/right alignment text margins more easily in the headers or by an
> override).


Okay I see. I'm rendering my subtitles with a background so the large
half-empty bounding box looked strange to me.


>
>
>
>> It also looks like the "erase page" command is not being processed, which
>> causes stale captions to stay on the screen in some cases.
>> This is especially confusing when part of an old caption remains on one
>> line, but then newer captions appear on another line.
>>
>> Here's a sample that shows lines not being cleared correctly:
>> https://s3.amazonaws.com/tmm1/teletext/simple.mpg
>>
>>
>> With this sample, for instance, my decoder produces:
>>
>> Dialogue: 
>> 0,0:00:01.90,9:59:59.99,Default,,0,0,0,,{\an8}{\pos(192,213)}{\c&}and
>> this, as you rightly say,\N
>> Dialogue: 
>> 0,0:00:01.94,9:59:59.99,Default,,0,0,0,,{\an8}{\pos(192,213)}{\c&}and
>> this, as you rightly say,\N{\an8}{\pos(192,231)}{\c&}is
>> American.\N
>> Dialogue: 0,0:00:04.86,9:59:59.99,Default,,0,0,0,,
>> Dialogue: 
>> 0,0:00:04.94,9:59:59.99,Default,,0,0,0,,{\an8}{\pos(192,231)}{\c&}It's
>> rather nicely made.\N
>> Dialogue: 0,0:00:06.62,9:59:59.99,Default,,0,0,0,,
>> Dialogue: 
>> 0,0:00:06.70,9:59:59.99,Default,,0,0,0,,{\an8}{\pos(192,213)}{\c&}It's
>> got this fabulous\N
>> Dialogue: 
>> 0,0:00:06.74,9:59:59.99,Default,,0,0,0,,{\an8}{\pos(192,213)}{\c&}It's
>> got this fabulous\N{\an8}{\pos(192,231)}   {\c&}cast finial
>> here\N
>> Dialogue: 0,0:00:10.34,9:59:59.99,Default,,0,0,0,,
>> Dialogue: 
>> 0,0:00:10.42,9:59:59.99,Default,,0,0,0,,{\an8}{\pos(192,213)}{\c&}of
>> a very muscular figure\N
>> Dialogue: 
>> 0,0:00:10.46,9:59:59.99,Default,,0,0,0,,{\an8}{\pos(192,213)}{\c&}of
>> a very muscular figure\N{\an8}{\pos(192,231)} {\c&}pulling this
>> medallion.\N
>> Dialogue: 0,0:00:15.50,9:59:59.99,Default,,0,0,0,,
>> Dialogue: 
>> 0,0:00:15.58,9:59:59.99,Default,,0,0,0,,{\an8}{\pos(192,213)}{\c&}So
>> it's got strength to it. It's a\N
>> Dialogue: 0,0:00:15.62,9:59:59.99,Default,,0,0,0,,{\an8}{\pos(192,213)}
>> {\c&}So it's got strength to it. It's 
>> a\N{\an8}{\pos(192,231)}{\c&}really
>> characterful piece of silver.\N
>> Dialogue: 0,0:00:19.14,9:59:59.99,Default,,0,0,0,,
>>
>> And the decoder in this patch produces:
>>
>> Dialogue: 
>> 0,0:00:02.02,9:59:59.99,Default,,0,0,0,,{\an2}and\hthis,\has\hyou\hrightly\hsay,
>> \Nis\hAmerican. \N
>> Dialogue: 
>> 0,0:00:05.02,9:59:59.99,Default,,0,0,0,,{\an2}and\hthis,\has\hyou\hrightly\hsay,
>> \NIt's\hrather\hnicely\hmade. \N
>> Dialogue: 
>> 0,0:00:06.82,9:59:59.99,Default,,0,0,0,,{\an2}It's\hgot\hthis\hfabulous
>> \Ncast\hfinial\hhere \N
>> Dialogue: 
>> 0,0:00:10.54,9:59:59.99,Default,,0,0,0,,{\an2}of\ha\hvery\hmuscular\hfigure
>> \Npulling\hthis\hmedallion. \N
>> Dialogue: 
>> 0,0:00:15.70,9:59:59.99,Default,,0,0,0,,{\an2}So\hit's\hgot\hstrength\hto\hit.\hIt's\ha
>> \Nreally\hcharacterful\hpiece\hof\hsilver. \N
>> Dialogue: 
>> 0,0:00:19.30,9:59:59.99,Default,,0,0,0,,{\an2}So\hit's\hgot\hstrength\hto\hit.\hIt's\ha
>> \NBut\hmost\himportant\hof\hall, \N
>>
>> At the ~5s mark, the text on the screen should say "It's rather nicely
>> made", but this decoder still displays the line "and this as you rightly
>> say" from the previous sentence.
>>
>
> The mix of different subtitles showing up seems like a libzvbi bug :( ...
> I will try to send a patch to sourceforge hoping it will get picked up and
> integrated to a future release...
>

I'm curious how much code there is in libzvbi that we're actually? i.e. How
practical would it be to import it into ffmpeg?


>
> Also there is a slight difference in how empty 

Re: [FFmpeg-devel] [PATCH] avutil/hwcontext_cuda: add AVCUDAFramesContext and AVCUDAFramesContext.flags

2018-05-07 Thread Mark Thompson
On 07/05/18 22:28, Timo Rothenpieler wrote:
> Am 07.05.2018 um 23:22 schrieb Mark Thompson:
>> On 07/05/18 22:10, Timo Rothenpieler wrote:
>>> Frames can be mapped from nvdec/cuvid, not needing any actual memory
>>> allocation, but all other features of the hw_frames_ctx.
>>> Hence the dummy-mode, which does not allocate any (notable amounts of)
>>> memory but otherwise behaves the exact same.
>>> ---
>>>   doc/APIchanges |  3 +++
>>>   libavutil/hwcontext_cuda.c | 10 ++
>>>   libavutil/hwcontext_cuda.h | 18 +-
>>>   libavutil/version.h    |  2 +-
>>>   4 files changed, 31 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/doc/APIchanges b/doc/APIchanges
>>> index ede5b186ae..82ec888fd8 100644
>>> --- a/doc/APIchanges
>>> +++ b/doc/APIchanges
>>> @@ -15,6 +15,9 @@ libavutil: 2017-10-21
>>>     API changes, most recent first:
>>>   +2018-05-xx - xx - lavu 56.19.100 - hwcontext.h
>>> +  Add AVCUDAFramesContext and AVCUDAFramesContext.flags.
>>> +
>>>   2018-04-xx - xx - lavu 56.18.100 - pixdesc.h
>>>     Add AV_PIX_FMT_FLAG_ALPHA to AV_PIX_FMT_PAL8.
>>>   diff --git a/libavutil/hwcontext_cuda.c b/libavutil/hwcontext_cuda.c
>>> index 37827a770c..0d867ef0f5 100644
>>> --- a/libavutil/hwcontext_cuda.c
>>> +++ b/libavutil/hwcontext_cuda.c
>>> @@ -83,6 +83,7 @@ static void cuda_buffer_free(void *opaque, uint8_t *data)
>>>   static AVBufferRef *cuda_pool_alloc(void *opaque, int size)
>>>   {
>>>   AVHWFramesContext *ctx = opaque;
>>> +    AVCUDAFramesContext *frctx = ctx->hwctx;
>>>   AVCUDADeviceContext *hwctx = ctx->device_ctx->hwctx;
>>>   CudaFunctions  *cu = hwctx->internal->cuda_dl;
>>>   @@ -97,6 +98,10 @@ static AVBufferRef *cuda_pool_alloc(void *opaque, int 
>>> size)
>>>   return NULL;
>>>   }
>>>   +    // A lot of places expect the pointer to be !=NULL, so make minimum 
>>> allocation instead.
>>> +    if (frctx->flags & AV_CUDA_HWFRAMES_DUMMY_MODE)
>>> +    size = 1;
>>
>> What are those places - can we get rid of them instead?  Allocating a single 
>> byte here is rather yucky.
> 
> That'd be AVBuffer/Ref itself interpreting its alloc function returning NULL 
> as ENOMEM. Doubt changing it is a good idea. And as any other return value 
> than NULL indicates a valid pointer, this approach is what I picked.

You could make a new function called, say, "cuda_pool_dummy_alloc" which always 
returns a non-null pointer (to some random static variable).  Then set that as 
the allocation function for the buffer pool in dummy mode and drop this 
changing of size.  (That seems cleaner?  Or maybe I'm overthinking this...)

>>> +
>>>   err = cu->cuMemAlloc(, size);
>>>   if (err != CUDA_SUCCESS)
>>>   goto fail;
>>> @@ -161,6 +166,7 @@ static int cuda_frames_init(AVHWFramesContext *ctx)
>>>     static int cuda_get_buffer(AVHWFramesContext *ctx, AVFrame *frame)
>>>   {
>>> +    AVCUDAFramesContext *frctx = ctx->hwctx;
>>>   int aligned_width;
>>>   int width_in_bytes = ctx->width;
>>>   @@ -210,6 +216,9 @@ static int cuda_get_buffer(AVHWFramesContext *ctx, 
>>> AVFrame *frame)
>>>   frame->width  = ctx->width;
>>>   frame->height = ctx->height;
>>>   +    if (frctx->flags & AV_CUDA_HWFRAMES_DUMMY_MODE)
>>> +    frame->data[0] = frame->data[1] = frame->data[2] = NULL;
>>
>> Are you intending linesize and buf[0] to have been filled with specific 
>> values here?
>>
>> A comment saying exactly what is set and what isn't might help.  (Maybe the 
>> comment goes with the flag itself.)
> 
> Yes, that's intended. I'm only explicitly cleaning out those as they're 
> dangerous to have pointing to buffers that are smaller than the rest of the 
> frame advertises.
> 
> Describing this fact on the flag is probably a good idea.

Ok, sounds good.

>>> +
>>>   return 0;
>>>   }
>>>   @@ -402,6 +411,7 @@ const HWContextType ff_hwcontext_type_cuda = {
>>>   .name = "CUDA",
>>>     .device_hwctx_size    = sizeof(AVCUDADeviceContext),
>>> +    .frames_hwctx_size    = sizeof(AVCUDAFramesContext),
>>>   .frames_priv_size = sizeof(CUDAFramesContext),
>>>     .device_create    = cuda_device_create,
>>> diff --git a/libavutil/hwcontext_cuda.h b/libavutil/hwcontext_cuda.h
>>> index 12dae8449e..388d6f8f1c 100644
>>> --- a/libavutil/hwcontext_cuda.h
>>> +++ b/libavutil/hwcontext_cuda.h
>>> @@ -45,7 +45,23 @@ typedef struct AVCUDADeviceContext {
>>>   } AVCUDADeviceContext;
>>>     /**
>>> - * AVHWFramesContext.hwctx is currently not used
>>> + * This struct is allocated as AVHWFramesContext.hwctx
>>>    */
>>> +typedef struct AVCUDAFramesContext {
>>> +    /**
>>> + * Special implementation-specific flags.
>>> + *
>>> + * Must be set by the user before calling av_hwframe_ctx_init().
>>> + */
>>
>> This makes it sound like you /must/ write to the field.  Leaving it as zero 
>> is also fine.
> 
> Simply replacing "Must" with "May"?

Sure.  Looking 

Re: [FFmpeg-devel] [GSOC] [PATCH] SRCNN filter

2018-05-07 Thread Hendrik Leppkes
On Sun, May 6, 2018 at 10:27 PM, James Almer  wrote:
> On 5/5/2018 5:38 PM, James Almer wrote:
>> On 4/10/2018 2:16 PM, Sergey Lavrushkin wrote:
>>> diff --git a/libavfilter/vf_srcnn.c b/libavfilter/vf_srcnn.c
>>> new file mode 100644
>>> index 00..d9b4891f7f
>>> --- /dev/null
>>> +++ b/libavfilter/vf_srcnn.c
>>> @@ -0,0 +1,420 @@
>>> +/*
>>> + * Copyright (c) 2018 Sergey Lavrushkin
>>> + *
>>> + * 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
>>> + */
>>> +
>>> +/**
>>> + * @file
>>> + * Filter implementing image super-resolution using deep convolutional 
>>> networks.
>>> + * https://arxiv.org/abs/1501.00092
>>> + */
>>> +
>>> +#include "avfilter.h"
>>> +#include "formats.h"
>>> +#include "internal.h"
>>> +#include "libavutil/opt.h"
>>> +#include "unistd.h"
>>
>> This broke msvc. It should be (if anything) , and wrapped
>> inside a HAVE_UNISTD_H preprocessor check.
>
> I (accidentally) applied this change as part of an unrelated commit, so
> that's dealt with at least.
>
>>
>>> +static av_cold int init(AVFilterContext* context)
>>> +{
>>> +SRCNNContext *srcnn_context = context->priv;
>>> +AVIOContext* config_file_context;
>>> +int64_t file_size, srcnn_size;
>>> +
>>> +/// Check specified confguration file name and read network weights 
>>> from it
>>> +if (!srcnn_context->config_file_path){
>>> +av_log(context, AV_LOG_INFO, "configuration file for network was 
>>> not specified, using default weights for x2 upsampling\n");
>>> +
>>> +/// Create convolution kernels and copy default weights
>>> +srcnn_context->conv1.input_channels = 1;
>>> +srcnn_context->conv1.output_channels = 64;
>>> +srcnn_context->conv1.size = 9;
>>> +CHECK_ALLOCATION(allocate_copy_conv_data(_context->conv1, 
>>> conv1_kernel, conv1_biases), )
>>> +
>>> +srcnn_context->conv2.input_channels = 64;
>>> +srcnn_context->conv2.output_channels = 32;
>>> +srcnn_context->conv2.size = 1;
>>> +CHECK_ALLOCATION(allocate_copy_conv_data(_context->conv2, 
>>> conv2_kernel, conv2_biases), )
>>> +
>>> +srcnn_context->conv3.input_channels = 32;
>>> +srcnn_context->conv3.output_channels = 1;
>>> +srcnn_context->conv3.size = 5;
>>> +CHECK_ALLOCATION(allocate_copy_conv_data(_context->conv3, 
>>> conv3_kernel, conv3_biases), )
>>> +}
>>> +else if (access(srcnn_context->config_file_path, R_OK) != -1){
>>
>> This seems to be the function needed from unistd.h
>>
>> Looking at configure and libavformat/file.c it's apparently not
>> available everywhere (we have a HAVE_ACCESS define, and also check for
>> mode constants like R_OK).
>
> MSVC does not have access(), so i have temporarily made this filter
> depend on its presence until a proper fix is applied. That target has
> been broken for a few days now and that shouldn't be the case.
> It should be a matter or doing the same thing as in libavformat/file.c,
> i guess, or perhaps use _access() instead, which is available in MSVC.

Your check doesn't work, MSVC building is still broken.
Probably because MSVC does have access, in io.h, but it does not have
the R_OK token.

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


[FFmpeg-devel] [PATCH 6/6] fate/cbs: Add an SEI test

2018-05-07 Thread Mark Thompson
The artificial sample file sei-1.h264 contains five frames (IDR P B I B)
and the following SEI message types:
* Buffering period
* Picture timing
* Pan-scan rectangle (display as 4:3)
* User data registered, containing A/53 closed captions (captions match
  frame content, including reordering)
* Recovery point (at the I frame)
* Display orientation (identity transformation)
* Mastering display (with arbitrary contents)
* Undefined SEI type 1234 (containing ascending bytes)
---
Sample file at .  (Named -1 
anticipating the possibility of adding more in future.)

140ddba635960ac73935a0fb268748a43c647151  fate/h264/sei-1.h264


 tests/fate/cbs.mak | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/tests/fate/cbs.mak b/tests/fate/cbs.mak
index bee349ed45..911e7704aa 100644
--- a/tests/fate/cbs.mak
+++ b/tests/fate/cbs.mak
@@ -14,7 +14,7 @@ endef
 
 # H.264 read/write
 
-FATE_CBS_H264_SAMPLES =   \
+FATE_CBS_H264_CONFORMANCE_SAMPLES = \
 SVA_Base_B.264\
 BASQP1_Sony_C.jsv \
 FM1_BT_B.h264 \
@@ -30,7 +30,11 @@ FATE_CBS_H264_SAMPLES =   \
 CVSE2_Sony_B.jsv  \
 CABACI3_Sony_B.jsv
 
-$(foreach N,$(FATE_CBS_H264_SAMPLES),$(eval $(call 
FATE_CBS_TEST,h264,$(basename $(N)),h264-conformance/$(N),h264)))
+FATE_CBS_H264_SAMPLES = \
+sei-1.h264
+
+$(foreach N,$(FATE_CBS_H264_CONFORMANCE_SAMPLES),$(eval $(call 
FATE_CBS_TEST,h264,$(basename $(N)),h264-conformance/$(N),h264)))
+$(foreach N,$(FATE_CBS_H264_SAMPLES),$(eval $(call 
FATE_CBS_TEST,h264,$(basename $(N)),h264/$(N),h264)))
 
 FATE_CBS_H264-$(call FATE_CBS_DEPS, H264, H264, H264, H264, H264) = 
$(FATE_CBS_h264)
 FATE_SAMPLES_AVCONV += $(FATE_CBS_H264-yes)
-- 
2.16.3

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


[FFmpeg-devel] [PATCH 5/6] cbs_h264: Add support for mastering display SEI messages

2018-05-07 Thread Mark Thompson
---
 libavcodec/cbs_h264.h | 10 ++
 libavcodec/cbs_h2645.c|  1 +
 libavcodec/cbs_h264_syntax_template.c | 23 +++
 libavcodec/h264_sei.h |  1 +
 4 files changed, 35 insertions(+)

diff --git a/libavcodec/cbs_h264.h b/libavcodec/cbs_h264.h
index b9536611ef..c46dd5064c 100644
--- a/libavcodec/cbs_h264.h
+++ b/libavcodec/cbs_h264.h
@@ -306,6 +306,15 @@ typedef struct H264RawSEIDisplayOrientation {
 uint8_t display_orientation_extension_flag;
 } H264RawSEIDisplayOrientation;
 
+typedef struct H264RawSEIMasteringDisplayColourVolume {
+uint16_t display_primaries_x[3];
+uint16_t display_primaries_y[3];
+uint16_t white_point_x;
+uint16_t white_point_y;
+uint16_t max_display_mastering_luminance;
+uint16_t min_display_mastering_luminance;
+} H264RawSEIMasteringDisplayColourVolume;
+
 typedef struct H264RawSEIPayload {
 uint32_t payload_type;
 uint32_t payload_size;
@@ -318,6 +327,7 @@ typedef struct H264RawSEIPayload {
 H264RawSEIUserDataUnregistered user_data_unregistered;
 H264RawSEIRecoveryPoint recovery_point;
 H264RawSEIDisplayOrientation display_orientation;
+H264RawSEIMasteringDisplayColourVolume mastering_display_colour_volume;
 struct {
 uint8_t *data;
 size_t data_length;
diff --git a/libavcodec/cbs_h2645.c b/libavcodec/cbs_h2645.c
index b8194cb3b1..7354a949cf 100644
--- a/libavcodec/cbs_h2645.c
+++ b/libavcodec/cbs_h2645.c
@@ -427,6 +427,7 @@ static void cbs_h264_free_sei_payload(H264RawSEIPayload 
*payload)
 case H264_SEI_TYPE_PAN_SCAN_RECT:
 case H264_SEI_TYPE_RECOVERY_POINT:
 case H264_SEI_TYPE_DISPLAY_ORIENTATION:
+case H264_SEI_TYPE_MASTERING_DISPLAY_COLOUR_VOLUME:
 break;
 case H264_SEI_TYPE_USER_DATA_REGISTERED:
 av_buffer_unref(>payload.user_data_registered.data_ref);
diff --git a/libavcodec/cbs_h264_syntax_template.c 
b/libavcodec/cbs_h264_syntax_template.c
index fb1685e6e6..027b555db6 100644
--- a/libavcodec/cbs_h264_syntax_template.c
+++ b/libavcodec/cbs_h264_syntax_template.c
@@ -740,6 +740,25 @@ static int 
FUNC(sei_display_orientation)(CodedBitstreamContext *ctx, RWContext *
 return 0;
 }
 
+static int FUNC(sei_mastering_display_colour_volume)(CodedBitstreamContext 
*ctx, RWContext *rw,
+ 
H264RawSEIMasteringDisplayColourVolume *current)
+{
+int err, c;
+
+for (c = 0; c < 3; c++) {
+us(16, display_primaries_x[c], 0, 5, 1, c);
+us(16, display_primaries_y[c], 0, 5, 1, c);
+}
+
+u(16, white_point_x, 0, 5);
+u(16, white_point_y, 0, 5);
+
+u(32, max_display_mastering_luminance, 1, MAX_UINT_BITS(32));
+u(32, min_display_mastering_luminance, 0, 
current->max_display_mastering_luminance - 1);
+
+return 0;
+}
+
 static int FUNC(sei_payload)(CodedBitstreamContext *ctx, RWContext *rw,
  H264RawSEIPayload *current)
 {
@@ -787,6 +806,10 @@ static int FUNC(sei_payload)(CodedBitstreamContext *ctx, 
RWContext *rw,
 CHECK(FUNC(sei_display_orientation)
   (ctx, rw, >payload.display_orientation));
 break;
+case H264_SEI_TYPE_MASTERING_DISPLAY_COLOUR_VOLUME:
+CHECK(FUNC(sei_mastering_display_colour_volume)
+  (ctx, rw, >payload.mastering_display_colour_volume));
+break;
 default:
 {
 #ifdef READ
diff --git a/libavcodec/h264_sei.h b/libavcodec/h264_sei.h
index 6455f3cec5..a169a10e49 100644
--- a/libavcodec/h264_sei.h
+++ b/libavcodec/h264_sei.h
@@ -35,6 +35,7 @@ typedef enum {
 H264_SEI_TYPE_FRAME_PACKING  = 45,  ///< frame packing arrangement
 H264_SEI_TYPE_DISPLAY_ORIENTATION= 47,  ///< display orientation
 H264_SEI_TYPE_GREEN_METADATA = 56,  ///< GreenMPEG information
+H264_SEI_TYPE_MASTERING_DISPLAY_COLOUR_VOLUME = 137,  ///< mastering 
display properties
 H264_SEI_TYPE_ALTERNATIVE_TRANSFER   = 147, ///< alternative transfer
 } H264_SEI_Type;
 
-- 
2.16.3

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


[FFmpeg-devel] [PATCH 4/6] cbs_h264: Add support for pan-scan rectangle SEI messages

2018-05-07 Thread Mark Thompson
---
No immediate use for this or the following patch, but they were helpful for SEI 
testing.


 libavcodec/cbs_h264.h | 12 
 libavcodec/cbs_h2645.c|  1 +
 libavcodec/cbs_h264_syntax_template.c | 28 
 libavcodec/h264_sei.h |  1 +
 4 files changed, 42 insertions(+)

diff --git a/libavcodec/cbs_h264.h b/libavcodec/cbs_h264.h
index 2219d9da8d..b9536611ef 100644
--- a/libavcodec/cbs_h264.h
+++ b/libavcodec/cbs_h264.h
@@ -264,6 +264,17 @@ typedef struct H264RawSEIPicTiming {
 H264RawSEIPicTimestamp timestamp[3];
 } H264RawSEIPicTiming;
 
+typedef struct H264RawSEIPanScanRect {
+uint32_t pan_scan_rect_id;
+uint8_t  pan_scan_rect_cancel_flag;
+uint8_t  pan_scan_cnt_minus1;
+int32_t  pan_scan_rect_left_offset[3];
+int32_t  pan_scan_rect_right_offset[3];
+int32_t  pan_scan_rect_top_offset[3];
+int32_t  pan_scan_rect_bottom_offset[3];
+uint16_t pan_scan_rect_repetition_period;
+} H264RawSEIPanScanRect;
+
 typedef struct H264RawSEIUserDataRegistered {
 uint8_t itu_t_t35_country_code;
 uint8_t itu_t_t35_country_code_extension_byte;
@@ -301,6 +312,7 @@ typedef struct H264RawSEIPayload {
 union {
 H264RawSEIBufferingPeriod buffering_period;
 H264RawSEIPicTiming pic_timing;
+H264RawSEIPanScanRect pan_scan_rect;
 // H264RawSEIFiller filler -> no fields.
 H264RawSEIUserDataRegistered user_data_registered;
 H264RawSEIUserDataUnregistered user_data_unregistered;
diff --git a/libavcodec/cbs_h2645.c b/libavcodec/cbs_h2645.c
index 64a1a2d1ee..b8194cb3b1 100644
--- a/libavcodec/cbs_h2645.c
+++ b/libavcodec/cbs_h2645.c
@@ -424,6 +424,7 @@ static void cbs_h264_free_sei_payload(H264RawSEIPayload 
*payload)
 switch (payload->payload_type) {
 case H264_SEI_TYPE_BUFFERING_PERIOD:
 case H264_SEI_TYPE_PIC_TIMING:
+case H264_SEI_TYPE_PAN_SCAN_RECT:
 case H264_SEI_TYPE_RECOVERY_POINT:
 case H264_SEI_TYPE_DISPLAY_ORIENTATION:
 break;
diff --git a/libavcodec/cbs_h264_syntax_template.c 
b/libavcodec/cbs_h264_syntax_template.c
index b789207e33..fb1685e6e6 100644
--- a/libavcodec/cbs_h264_syntax_template.c
+++ b/libavcodec/cbs_h264_syntax_template.c
@@ -626,6 +626,30 @@ static int FUNC(sei_pic_timing)(CodedBitstreamContext 
*ctx, RWContext *rw,
 return 0;
 }
 
+static int FUNC(sei_pan_scan_rect)(CodedBitstreamContext *ctx, RWContext *rw,
+   H264RawSEIPanScanRect *current)
+{
+int err, i;
+
+ue(pan_scan_rect_id, 0, UINT32_MAX - 1);
+flag(pan_scan_rect_cancel_flag);
+
+if (!current->pan_scan_rect_cancel_flag) {
+ue(pan_scan_cnt_minus1, 0, 2);
+
+for (i = 0; i <= current->pan_scan_cnt_minus1; i++) {
+ses(pan_scan_rect_left_offset[i],   INT32_MIN + 1, INT32_MAX, 1, 
i);
+ses(pan_scan_rect_right_offset[i],  INT32_MIN + 1, INT32_MAX, 1, 
i);
+ses(pan_scan_rect_top_offset[i],INT32_MIN + 1, INT32_MAX, 1, 
i);
+ses(pan_scan_rect_bottom_offset[i], INT32_MIN + 1, INT32_MAX, 1, 
i);
+}
+
+ue(pan_scan_rect_repetition_period, 0, 16384);
+}
+
+return 0;
+}
+
 static int FUNC(sei_user_data_registered)(CodedBitstreamContext *ctx, 
RWContext *rw,
   H264RawSEIUserDataRegistered 
*current,
   uint32_t *payload_size)
@@ -737,6 +761,10 @@ static int FUNC(sei_payload)(CodedBitstreamContext *ctx, 
RWContext *rw,
 CHECK(FUNC(sei_pic_timing)
   (ctx, rw, >payload.pic_timing));
 break;
+case H264_SEI_TYPE_PAN_SCAN_RECT:
+CHECK(FUNC(sei_pan_scan_rect)
+  (ctx, rw, >payload.pan_scan_rect));
+break;
 case H264_SEI_TYPE_FILLER_PAYLOAD:
 {
 for (i = 0; i  < current->payload_size; i++)
diff --git a/libavcodec/h264_sei.h b/libavcodec/h264_sei.h
index 9488382b9f..6455f3cec5 100644
--- a/libavcodec/h264_sei.h
+++ b/libavcodec/h264_sei.h
@@ -27,6 +27,7 @@
 typedef enum {
 H264_SEI_TYPE_BUFFERING_PERIOD   = 0,   ///< buffering period (H.264, 
D.1.1)
 H264_SEI_TYPE_PIC_TIMING = 1,   ///< picture timing
+H264_SEI_TYPE_PAN_SCAN_RECT  = 2,   ///< pan-scan rectangle
 H264_SEI_TYPE_FILLER_PAYLOAD = 3,   ///< filler data
 H264_SEI_TYPE_USER_DATA_REGISTERED   = 4,   ///< registered user data as 
specified by Rec. ITU-T T.35
 H264_SEI_TYPE_USER_DATA_UNREGISTERED = 5,   ///< unregistered user data
-- 
2.16.3

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


[FFmpeg-devel] [PATCH 3/6] h264_metadata: Fix AUD writing

2018-05-07 Thread Mark Thompson
The aud structure exists on the stack, so the variable was previously
out-of-scope when the unit is written.
---
Something of a "how did this ever work", though apparently no compiler barfs on 
it until I was add more stuff after.


 libavcodec/h264_metadata_bsf.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/libavcodec/h264_metadata_bsf.c b/libavcodec/h264_metadata_bsf.c
index 1fbc5e3282..90ad4aad98 100644
--- a/libavcodec/h264_metadata_bsf.c
+++ b/libavcodec/h264_metadata_bsf.c
@@ -220,6 +220,7 @@ static int h264_metadata_filter(AVBSFContext *bsf, AVPacket 
*out)
 AVPacket *in = NULL;
 CodedBitstreamFragment *au = >access_unit;
 int err, i, j, has_sps;
+H264RawAUD aud;
 uint8_t *displaymatrix_side_data = NULL;
 size_t displaymatrix_side_data_size = 0;
 
@@ -256,9 +257,6 @@ static int h264_metadata_filter(AVBSFContext *bsf, AVPacket 
*out)
 0x3ff, // 0, 1, 2, 3, 4, 5, 6, 7, 8, 9
 };
 int primary_pic_type_mask = 0xff;
-H264RawAUD aud = {
-.nal_unit_header.nal_unit_type = H264_NAL_AUD,
-};
 
 for (i = 0; i < au->nb_units; i++) {
 if (au->units[i].type == H264_NAL_SLICE ||
@@ -281,7 +279,10 @@ static int h264_metadata_filter(AVBSFContext *bsf, 
AVPacket *out)
 goto fail;
 }
 
-aud.primary_pic_type = j;
+aud = (H264RawAUD) {
+.nal_unit_header.nal_unit_type = H264_NAL_AUD,
+.primary_pic_type = j,
+};
 
 err = ff_cbs_insert_unit_content(ctx->cbc, au,
  0, H264_NAL_AUD, , NULL);
-- 
2.16.3

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


[FFmpeg-devel] [PATCH 2/6] h264_metadata: Remove redundant setting of SEI payload size

2018-05-07 Thread Mark Thompson
This should be derived from the data length rather than set explicitly.
---
 libavcodec/h264_metadata_bsf.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/libavcodec/h264_metadata_bsf.c b/libavcodec/h264_metadata_bsf.c
index 27053dbdcf..1fbc5e3282 100644
--- a/libavcodec/h264_metadata_bsf.c
+++ b/libavcodec/h264_metadata_bsf.c
@@ -341,8 +341,6 @@ static int h264_metadata_filter(AVBSFContext *bsf, AVPacket 
*out)
 udu->data_length = len + 1;
 memcpy(udu->data, ctx->sei_user_data + i + 1, len + 1);
 
-payload.payload_size = 16 + udu->data_length;
-
 err = ff_cbs_h264_add_sei_message(ctx->cbc, au, );
 if (err < 0) {
 av_log(bsf, AV_LOG_ERROR, "Failed to add user data SEI "
-- 
2.16.3

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


[FFmpeg-devel] [PATCH 1/6] cbs_h264: Fix handling of unknown SEI

2018-05-07 Thread Mark Thompson
The user should only interact directly with the data length, not the
payload size.
---
 libavcodec/cbs_h264_syntax_template.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/libavcodec/cbs_h264_syntax_template.c 
b/libavcodec/cbs_h264_syntax_template.c
index 3ec4299915..b789207e33 100644
--- a/libavcodec/cbs_h264_syntax_template.c
+++ b/libavcodec/cbs_h264_syntax_template.c
@@ -761,8 +761,11 @@ static int FUNC(sei_payload)(CodedBitstreamContext *ctx, 
RWContext *rw,
 break;
 default:
 {
-allocate(current->payload.other.data, current->payload_size);
-for (i = 0; i < current->payload_size; i++)
+#ifdef READ
+current->payload.other.data_length = current->payload_size;
+#endif
+allocate(current->payload.other.data, 
current->payload.other.data_length);
+for (i = 0; i < current->payload.other.data_length; i++)
 xu(8, payload_byte[i], current->payload.other.data[i], 0, 255, 
1, i);
 }
 }
-- 
2.16.3

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


Re: [FFmpeg-devel] [PATCH 2/2] avcodec/libzvbi-teletextdec: formatted ass output

2018-05-07 Thread Marton Balint



On Mon, 7 May 2018, Aman Gupta wrote:




On Mon, May 7, 2018 at 12:50 PM, Aman Gupta  wrote:


  On Sun, May 6, 2018 at 2:05 PM, Marton Balint  wrote:
Inspired by the VideoLAN text decoder and its port to FFmpeg made 
by Aman
Gupta.


Thanks for incorporating my changes.

I ran some tests, and colors work as expected. Positioning also works well, and 
is also pretty close to my version.


I found that some live streams are not chopping empty lines correctly. I see 
extra newlines at the end:

  Dialogue: 
0,0:13:21.66,9:59:59.99,Default,,0,0,0,,{\an1}Simson,\hPeter\hHartcher,\hRobyn\hParker
 \Nand\hBenjamin \N \N \N

Here's a sample which shows extra newlines: 
https://s3.amazonaws.com/tmm1/teletext/capture_live1.mpg


This is kind of intentional, in this case the new lines are kept to 
position the subtitles a bit higher, and not to the very bottom of the 
screen, to keep the rough position of the teletext subtitles. At first I 
used \pos as well, but it only worked once per line for me, so I had to 
use some kind of newline-positioning anyway, and using native vertical 
alignment instead of \pos seemed nicer. (E.g. it allows the user to change 
left/right alignment text margins more easily in the headers or by 
an override).




It also looks like the "erase page" command is not being processed, which 
causes stale captions to stay on the screen in some cases.
This is especially confusing when part of an old caption remains on one line, 
but then newer captions appear on another line.

Here's a sample that shows lines not being cleared correctly: 
https://s3.amazonaws.com/tmm1/teletext/simple.mpg


With this sample, for instance, my decoder produces:

Dialogue: 
0,0:00:01.90,9:59:59.99,Default,,0,0,0,,{\an8}{\pos(192,213)}{\c&}and 
this, as you rightly say,\N
Dialogue: 0,0:00:01.94,9:59:59.99,Default,,0,0,0,,{\an8}{\pos(192,213)}{\c&}and 
this, as you rightly say,\N{\an8}{\pos(192,231)}        {\c&}is American.\N
Dialogue: 0,0:00:04.86,9:59:59.99,Default,,0,0,0,,
Dialogue: 
0,0:00:04.94,9:59:59.99,Default,,0,0,0,,{\an8}{\pos(192,231)}{\c&}It's 
rather nicely made.\N
Dialogue: 0,0:00:06.62,9:59:59.99,Default,,0,0,0,,
Dialogue: 
0,0:00:06.70,9:59:59.99,Default,,0,0,0,,{\an8}{\pos(192,213)}{\c&}It's 
got this fabulous\N
Dialogue: 
0,0:00:06.74,9:59:59.99,Default,,0,0,0,,{\an8}{\pos(192,213)}{\c&}It's got this 
fabulous\N{\an8}{\pos(192,231)}   {\c&}cast finial here\N
Dialogue: 0,0:00:10.34,9:59:59.99,Default,,0,0,0,,
Dialogue: 
0,0:00:10.42,9:59:59.99,Default,,0,0,0,,{\an8}{\pos(192,213)}{\c&}of a 
very muscular figure\N
Dialogue: 0,0:00:10.46,9:59:59.99,Default,,0,0,0,,{\an8}{\pos(192,213)}{\c&}of 
a very muscular figure\N{\an8}{\pos(192,231)} {\c&}pulling this medallion.\N
Dialogue: 0,0:00:15.50,9:59:59.99,Default,,0,0,0,,
Dialogue: 
0,0:00:15.58,9:59:59.99,Default,,0,0,0,,{\an8}{\pos(192,213)}{\c&}So 
it's got strength to it. It's a\N
Dialogue: 0,0:00:15.62,9:59:59.99,Default,,0,0,0,,{\an8}{\pos(192,213)} {\c&}So 
it's got strength to it. It's a\N{\an8}{\pos(192,231)}{\c&}really characterful 
piece of silver.\N
Dialogue: 0,0:00:19.14,9:59:59.99,Default,,0,0,0,,

And the decoder in this patch produces:

Dialogue: 
0,0:00:02.02,9:59:59.99,Default,,0,0,0,,{\an2}and\hthis,\has\hyou\hrightly\hsay,
 \Nis\hAmerican. \N
Dialogue: 
0,0:00:05.02,9:59:59.99,Default,,0,0,0,,{\an2}and\hthis,\has\hyou\hrightly\hsay,
 \NIt's\hrather\hnicely\hmade. \N
Dialogue: 
0,0:00:06.82,9:59:59.99,Default,,0,0,0,,{\an2}It's\hgot\hthis\hfabulous 
\Ncast\hfinial\hhere \N
Dialogue: 
0,0:00:10.54,9:59:59.99,Default,,0,0,0,,{\an2}of\ha\hvery\hmuscular\hfigure 
\Npulling\hthis\hmedallion. \N
Dialogue: 
0,0:00:15.70,9:59:59.99,Default,,0,0,0,,{\an2}So\hit's\hgot\hstrength\hto\hit.\hIt's\ha
 \Nreally\hcharacterful\hpiece\hof\hsilver. \N
Dialogue: 
0,0:00:19.30,9:59:59.99,Default,,0,0,0,,{\an2}So\hit's\hgot\hstrength\hto\hit.\hIt's\ha
 \NBut\hmost\himportant\hof\hall, \N

At the ~5s mark, the text on the screen should say "It's rather nicely made", but this 
decoder still displays the line "and this as you rightly say" from the previous sentence.


The mix of different subtitles showing up seems like a libzvbi bug :( ... 
I will try to send a patch to sourceforge hoping it will get picked up and 
integrated to a future release...


Also there is a slight difference in how empty subtitles are forwarded. 
For empty subtitles I always used AVSubtitleRect type AVSUBTITLE_NONE, you 
used AVSUBTITLE_ASS. I prefer AVSUBTITLE_NONE, because with it
ffmpeg -fix_sub_duration creates a valid ass file without empty 
subtitles.



I also have several other samples which use various features, available at the 
same URL:

capture_formatting1.mpg
capture_formatting2.mpg
capture_formatting3.mpg
capture_live1.mpg
capture_live2.mpg
capture_notCaptionedMessage.mpg
capture_threeLines1.mpg
capture_threeLines2.mpg
capture_threeLines3.mpg
capture_threeLines4.mpg
capture_yOffset1.mpg
three.ts
four.ts


Re: [FFmpeg-devel] [PATCH] mdct15: simplify the fft15 x86 SIMD

2018-05-07 Thread Rostislav Pehlivanov
On 6 May 2018 at 23:19, Rostislav Pehlivanov  wrote:

> Saves 1 gpr and 2 instructions and simplifies the macros a bit.
>
> Signed-off-by: Rostislav Pehlivanov 
> ---
>  libavcodec/x86/mdct15.asm | 37 +
>  1 file changed, 17 insertions(+), 20 deletions(-)
>
> diff --git a/libavcodec/x86/mdct15.asm b/libavcodec/x86/mdct15.asm
> index 0309112538..2a2cdbd21b 100644
> --- a/libavcodec/x86/mdct15.asm
> +++ b/libavcodec/x86/mdct15.asm
> @@ -76,7 +76,7 @@ SECTION .text
>  addps   m%3,  m%3,  m0  ; Finally offset with DCs
>  %endmacro
>
> -%macro BUTTERFLIES_DC 2 ; %1 - exptab_offset, %2 - out
> +%macro BUTTERFLIES_DC 1 ; %1 - exptab_offset
>  mulps xm0,  xm9, [exptabq + %1 + 16*0]
>  mulps xm1, xm10, [exptabq + %1 + 16*1]
>
> @@ -86,10 +86,10 @@ SECTION .text
>  addps   xm0,  xm1
>  addps   xm0,  xm8
>
> -movsd [%2q], xm0
> +movsd [outq], xm0
>  %endmacro
>
> -%macro BUTTERFLIES_AC 2 ; exptab, exptab_offset, src1, src2, src3, out
> (uses m0-m3)
> +%macro BUTTERFLIES_AC 1 ; %1 - exptab_offset
>  mulps  m0, m12, [exptabq + 64*0 + 0*mmsize + %1]
>  mulps  m1, m12, [exptabq + 64*0 + 1*mmsize + %1]
>  mulps  m2, m13, [exptabq + 64*1 + 0*mmsize + %1]
> @@ -104,15 +104,14 @@ SECTION .text
>
>  vextractf128 xm1, m0, 1
>
> -movlps [%2q + strideq*1], xm0
> -movhps [%2q + strideq*2], xm0
> -movlps [%2q +  stride3q], xm1
> -movhps [%2q + strideq*4], xm1
> +movlps [outq + strideq*1], xm0
> +movhps [outq + strideq*2], xm0
> +movlps [outq +  stride3q], xm1
> +movhps [outq + strideq*4], xm1
>  %endmacro
>
>  INIT_YMM avx
> -cglobal fft15, 4, 6, 14, out, in, exptab, stride, stride3, stride5
> -%define out0q inq
> +cglobal fft15, 4, 5, 14, out, in, exptab, stride, stride5
>  shl strideq, 3
>
>  movaps xm5, [exptabq + 480 + 16*0]
> @@ -123,22 +122,20 @@ cglobal fft15, 4, 6, 14, out, in, exptab, stride,
> stride3, stride5
>  FFT5  8,  xm9, 12
>  FFT5 16, xm10, 13
>
> +%define stride3q inq
>  lea stride3q, [strideq + strideq*2]
>  lea stride5q, [strideq + strideq*4]
>
> -mov out0q, outq
> +BUTTERFLIES_DC (8*6 + 4*0)*2*4
> +BUTTERFLIES_AC (8*0 + 0*0)*2*4
>
> -BUTTERFLIES_DC (8*6 + 4*0)*2*4, out0
> -lea outq, [out0q + stride5q*1]
> -BUTTERFLIES_DC (8*6 + 4*1)*2*4, out
> -lea outq, [out0q + stride5q*2]
> -BUTTERFLIES_DC (8*6 + 4*2)*2*4, out
> +add outq, stride5q
> +BUTTERFLIES_DC (8*6 + 4*1)*2*4
> +BUTTERFLIES_AC (8*2 + 0*0)*2*4
>
> -BUTTERFLIES_AC (8*0)*2*4, out0
> -lea outq, [out0q + stride5q*1]
> -BUTTERFLIES_AC (8*2)*2*4, out
> -lea outq, [out0q + stride5q*2]
> -BUTTERFLIES_AC (8*4)*2*4, out
> +add outq, stride5q
> +BUTTERFLIES_DC (8*6 + 4*2)*2*4
> +BUTTERFLIES_AC (8*4 + 0*0)*2*4
>
>  RET
>
> --
> 2.17.0
>
>
Pushed alongside a patch to simplify the init function
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [PATCH] configure: include unistd.h in the access() check

2018-05-07 Thread James Almer
This should make sure detection only succeeds on systems where we expect
it will be used.

Signed-off-by: James Almer 
---
The current access() test succeeds on systems lacking unistd.h, like msvc.
This results in the scrnn_filter being enabled but ultimately failing to
compile, as POSIX constants like R_OK are expected to also be present.

libavformat/os_support.h has a wrapper for win32 targets using a msvc
specific implementation of the function, but it can't be used in
libavfilter.

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

diff --git a/configure b/configure
index 7c143238a8..3d051a5826 100755
--- a/configure
+++ b/configure
@@ -5761,7 +5761,7 @@ check_func_headers malloc.h _aligned_malloc && enable 
aligned_malloc
 check_func  ${malloc_prefix}memalign&& enable memalign
 check_func  ${malloc_prefix}posix_memalign  && enable posix_memalign
 
-check_func  access
+check_func_headers unistd.h access
 check_func_headers stdlib.h arc4random
 check_lib   clock_gettime time.h clock_gettime || check_lib clock_gettime 
time.h clock_gettime -lrt
 check_func  fcntl
-- 
2.17.0

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


Re: [FFmpeg-devel] libavutil/encryption_info: Allow multiple init info.

2018-05-07 Thread Michael Niedermayer
On Mon, Apr 23, 2018 at 11:03:57AM -0700, Jacob Trimble wrote:
> While integrating my encryption info changes, I noticed a problem with
> the init info structs.  I implemented them as side-data on the Stream.
> But this means there can only be one per stream.  However, there can
> be multiple 'pssh' atoms in a single stream (e.g. for key rotation or
> multiple key systems). (sorry for not noticing sooner)
> 
> Attached is a patch to fix this by making the init info a
> singly-linked-list.  It is ABI compatible and is still easy to use and
> understand.  The alternative would be to break ABI and have the
> side-data methods return an array of pointers.  I could do that
> instead if that is preferable.

>  encryption_info.c |  154 
> +++---
>  encryption_info.h |5 +
>  2 files changed, 106 insertions(+), 53 deletions(-)
> e5eecc73a6997bbd11541771372d38ea9c3972a7  
> 0001-libavutil-encryption_info-Allow-multiple-init-info.patch
> From bb941a77e882e93629d63d63059d0063b9519e29 Mon Sep 17 00:00:00 2001
> From: Jacob Trimble 
> Date: Mon, 23 Apr 2018 10:33:58 -0700
> Subject: [PATCH] libavutil/encryption_info: Allow multiple init info.
> 
> It is possible for there to be multiple encryption init info structure.
> For example, to support multiple key systems or in key rotation.  This
> changes the AVEncryptionInitInfo struct to be a linked list so there
> can be multiple structs without breaking ABI.
> 
> Signed-off-by: Jacob Trimble 
> ---
>  libavutil/encryption_info.c | 154 +++-
>  libavutil/encryption_info.h |   5 ++
>  2 files changed, 106 insertions(+), 53 deletions(-)
> 
> diff --git a/libavutil/encryption_info.c b/libavutil/encryption_info.c
> index 20a752d6b4..9935c10d74 100644
> --- a/libavutil/encryption_info.c
> +++ b/libavutil/encryption_info.c
> @@ -160,13 +160,16 @@ uint8_t *av_encryption_info_add_side_data(const 
> AVEncryptionInfo *info, size_t *
>  }
>  
>  // The format of the AVEncryptionInitInfo side data:
> -// u32be system_id_size
> -// u32be num_key_ids
> -// u32be key_id_size
> -// u32be data_size
> -// u8[system_id_size] system_id
> -// u8[key_id_size][num_key_id] key_ids
> -// u8[data_size] data
> +// u32be init_info_count
> +// {
> +//   u32be system_id_size
> +//   u32be num_key_ids
> +//   u32be key_id_size
> +//   u32be data_size
> +//   u8[system_id_size] system_id
> +//   u8[key_id_size][num_key_id] key_ids
> +//   u8[data_size] data
> +// }[init_info_count]
>  
>  #define FF_ENCRYPTION_INIT_INFO_EXTRA 16
>  
> @@ -215,6 +218,7 @@ void av_encryption_init_info_free(AVEncryptionInitInfo 
> *info)
>  for (i = 0; i < info->num_key_ids; i++) {
>  av_free(info->key_ids[i]);
>  }
> +av_encryption_init_info_free(info->next);
>  av_free(info->system_id);
>  av_free(info->key_ids);
>  av_free(info->data);
> @@ -225,71 +229,115 @@ void av_encryption_init_info_free(AVEncryptionInitInfo 
> *info)
>  AVEncryptionInitInfo *av_encryption_init_info_get_side_data(
>  const uint8_t *side_data, size_t side_data_size)
>  {
> -AVEncryptionInitInfo *info;
> +AVEncryptionInitInfo *ret = NULL, *info;
>  uint64_t system_id_size, num_key_ids, key_id_size, data_size, i;
> +uint64_t init_info_count;
>  
> -if (!side_data || side_data_size < FF_ENCRYPTION_INIT_INFO_EXTRA)
> -return NULL;
> -
> -system_id_size = AV_RB32(side_data);
[...]
> +init_info_count = AV_RB32(side_data);

i may be missing something but this looks like the meaning of the first
field changes, this thus doesnt look compatible to me

also indention is quite inconsistent in the new code

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Many that live deserve death. And some that die deserve life. Can you give
it to them? Then do not be too eager to deal out death in judgement. For
even the very wise cannot see all ends. -- Gandalf


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


Re: [FFmpeg-devel] [PATCH] Added the possibility to pass an externally created CUDA context to libavutil/hwcontext.c/av_hwdevice_ctx_create() for decoding with NVDEC

2018-05-07 Thread Timo Rothenpieler

Am 07.05.2018 um 19:37 schrieb Oscar Amoros Huguet:

I was looking at the NVIDIA Video codec sdk samples 
(https://developer.nvidia.com/nvidia-video-codec-sdk#Download), where you can 
find the header NvDecoder.h next to cuviddec.h where CUVIDPROCPARAMS is defined.

Anyway, I should have looked at ffmpeg code directly, to see what’s being used, 
sorry for that.

Great then! Having the same cuda stream (either default or custom) for 
everything is the safest and most efficient way to go (in this case).

Thanks, and let me know if I can help with anything.



You can find the mentioned changes on my personal github:
https://github.com/BtbN/FFmpeg

The cuMemcpy is entirely gone, not just Async. And the CUstream can be 
set and will be passed on to cuvid/nvdec.




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] avutil/hwcontext_cuda: add AVCUDAFramesContext and AVCUDAFramesContext.flags

2018-05-07 Thread Timo Rothenpieler
Frames can be mapped from nvdec/cuvid, not needing any actual memory
allocation, but all other features of the hw_frames_ctx.
Hence the dummy-mode, which does not allocate any (notable amounts of)
memory but otherwise behaves the exact same.
---
 doc/APIchanges |  3 +++
 libavutil/hwcontext_cuda.c | 12 +++-
 libavutil/hwcontext_cuda.h | 22 +-
 libavutil/version.h|  2 +-
 4 files changed, 36 insertions(+), 3 deletions(-)

diff --git a/doc/APIchanges b/doc/APIchanges
index ede5b186ae..82ec888fd8 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,9 @@ libavutil: 2017-10-21
 
 API changes, most recent first:
 
+2018-05-xx - xx - lavu 56.19.100 - hwcontext.h
+  Add AVCUDAFramesContext and AVCUDAFramesContext.flags.
+
 2018-04-xx - xx - lavu 56.18.100 - pixdesc.h
   Add AV_PIX_FMT_FLAG_ALPHA to AV_PIX_FMT_PAL8.
 
diff --git a/libavutil/hwcontext_cuda.c b/libavutil/hwcontext_cuda.c
index 37827a770c..b0b4bf24ae 100644
--- a/libavutil/hwcontext_cuda.c
+++ b/libavutil/hwcontext_cuda.c
@@ -161,6 +161,7 @@ static int cuda_frames_init(AVHWFramesContext *ctx)
 
 static int cuda_get_buffer(AVHWFramesContext *ctx, AVFrame *frame)
 {
+AVCUDAFramesContext *frctx = ctx->hwctx;
 int aligned_width;
 int width_in_bytes = ctx->width;
 
@@ -171,7 +172,11 @@ static int cuda_get_buffer(AVHWFramesContext *ctx, AVFrame 
*frame)
 }
 aligned_width = FFALIGN(width_in_bytes, CUDA_FRAME_ALIGNMENT);
 
-frame->buf[0] = av_buffer_pool_get(ctx->pool);
+if (frctx->flags & AV_CUDA_HWFRAMES_DUMMY_MODE)
+frame->buf[0] = av_buffer_create(NULL, 0, NULL, NULL, 0);
+else
+frame->buf[0] = av_buffer_pool_get(ctx->pool);
+
 if (!frame->buf[0])
 return AVERROR(ENOMEM);
 
@@ -210,6 +215,10 @@ static int cuda_get_buffer(AVHWFramesContext *ctx, AVFrame 
*frame)
 frame->width  = ctx->width;
 frame->height = ctx->height;
 
+// they're pointing to invalid memory, dangerous to leave set
+if (frctx->flags & AV_CUDA_HWFRAMES_DUMMY_MODE)
+frame->data[0] = frame->data[1] = frame->data[2] = NULL;
+
 return 0;
 }
 
@@ -402,6 +411,7 @@ const HWContextType ff_hwcontext_type_cuda = {
 .name = "CUDA",
 
 .device_hwctx_size= sizeof(AVCUDADeviceContext),
+.frames_hwctx_size= sizeof(AVCUDAFramesContext),
 .frames_priv_size = sizeof(CUDAFramesContext),
 
 .device_create= cuda_device_create,
diff --git a/libavutil/hwcontext_cuda.h b/libavutil/hwcontext_cuda.h
index 12dae8449e..19accbd9be 100644
--- a/libavutil/hwcontext_cuda.h
+++ b/libavutil/hwcontext_cuda.h
@@ -45,7 +45,27 @@ typedef struct AVCUDADeviceContext {
 } AVCUDADeviceContext;
 
 /**
- * AVHWFramesContext.hwctx is currently not used
+ * This struct is allocated as AVHWFramesContext.hwctx
  */
+typedef struct AVCUDAFramesContext {
+/**
+ * Special implementation-specific flags.
+ *
+ * May be set by the user before calling av_hwframe_ctx_init().
+ */
+int flags;
+} AVCUDAFramesContext;
+
+/**
+ * No actual allocation will happen, but otherwise behaves like normal.
+ *
+ * This is to be used if a AVHWFramesContext is required, but the actual
+ * allocation is happening outside of it.
+ *
+ * The resulting AVFrames will be identical to normal frames, except for
+ * their data[] pointers being NULL and the AVBufferRef in buf[0] being
+ * set but containing no notable allocation of memory.
+ */
+#define AV_CUDA_HWFRAMES_DUMMY_MODE (1 << 0)
 
 #endif /* AVUTIL_HWCONTEXT_CUDA_H */
diff --git a/libavutil/version.h b/libavutil/version.h
index 5185454d9b..84409b1d69 100644
--- a/libavutil/version.h
+++ b/libavutil/version.h
@@ -79,7 +79,7 @@
  */
 
 #define LIBAVUTIL_VERSION_MAJOR  56
-#define LIBAVUTIL_VERSION_MINOR  18
+#define LIBAVUTIL_VERSION_MINOR  19
 #define LIBAVUTIL_VERSION_MICRO 100
 
 #define LIBAVUTIL_VERSION_INT   AV_VERSION_INT(LIBAVUTIL_VERSION_MAJOR, \
-- 
2.17.0

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


Re: [FFmpeg-devel] [PATCH] avutil/hwcontext_cuda: add AVCUDAFramesContext and AVCUDAFramesContext.flags

2018-05-07 Thread Timo Rothenpieler

Am 07.05.2018 um 23:22 schrieb Mark Thompson:

On 07/05/18 22:10, Timo Rothenpieler wrote:

Frames can be mapped from nvdec/cuvid, not needing any actual memory
allocation, but all other features of the hw_frames_ctx.
Hence the dummy-mode, which does not allocate any (notable amounts of)
memory but otherwise behaves the exact same.
---
  doc/APIchanges |  3 +++
  libavutil/hwcontext_cuda.c | 10 ++
  libavutil/hwcontext_cuda.h | 18 +-
  libavutil/version.h|  2 +-
  4 files changed, 31 insertions(+), 2 deletions(-)

diff --git a/doc/APIchanges b/doc/APIchanges
index ede5b186ae..82ec888fd8 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,9 @@ libavutil: 2017-10-21
  
  API changes, most recent first:
  
+2018-05-xx - xx - lavu 56.19.100 - hwcontext.h

+  Add AVCUDAFramesContext and AVCUDAFramesContext.flags.
+
  2018-04-xx - xx - lavu 56.18.100 - pixdesc.h
Add AV_PIX_FMT_FLAG_ALPHA to AV_PIX_FMT_PAL8.
  
diff --git a/libavutil/hwcontext_cuda.c b/libavutil/hwcontext_cuda.c

index 37827a770c..0d867ef0f5 100644
--- a/libavutil/hwcontext_cuda.c
+++ b/libavutil/hwcontext_cuda.c
@@ -83,6 +83,7 @@ static void cuda_buffer_free(void *opaque, uint8_t *data)
  static AVBufferRef *cuda_pool_alloc(void *opaque, int size)
  {
  AVHWFramesContext *ctx = opaque;
+AVCUDAFramesContext *frctx = ctx->hwctx;
  AVCUDADeviceContext *hwctx = ctx->device_ctx->hwctx;
  CudaFunctions  *cu = hwctx->internal->cuda_dl;
  
@@ -97,6 +98,10 @@ static AVBufferRef *cuda_pool_alloc(void *opaque, int size)

  return NULL;
  }
  
+// A lot of places expect the pointer to be !=NULL, so make minimum allocation instead.

+if (frctx->flags & AV_CUDA_HWFRAMES_DUMMY_MODE)
+size = 1;


What are those places - can we get rid of them instead?  Allocating a single 
byte here is rather yucky.


That'd be AVBuffer/Ref itself interpreting its alloc function returning 
NULL as ENOMEM. Doubt changing it is a good idea. And as any other 
return value than NULL indicates a valid pointer, this approach is what 
I picked.



+
  err = cu->cuMemAlloc(, size);
  if (err != CUDA_SUCCESS)
  goto fail;
@@ -161,6 +166,7 @@ static int cuda_frames_init(AVHWFramesContext *ctx)
  
  static int cuda_get_buffer(AVHWFramesContext *ctx, AVFrame *frame)

  {
+AVCUDAFramesContext *frctx = ctx->hwctx;
  int aligned_width;
  int width_in_bytes = ctx->width;
  
@@ -210,6 +216,9 @@ static int cuda_get_buffer(AVHWFramesContext *ctx, AVFrame *frame)

  frame->width  = ctx->width;
  frame->height = ctx->height;
  
+if (frctx->flags & AV_CUDA_HWFRAMES_DUMMY_MODE)

+frame->data[0] = frame->data[1] = frame->data[2] = NULL;


Are you intending linesize and buf[0] to have been filled with specific values 
here?

A comment saying exactly what is set and what isn't might help.  (Maybe the 
comment goes with the flag itself.)


Yes, that's intended. I'm only explicitly cleaning out those as they're 
dangerous to have pointing to buffers that are smaller than the rest of 
the frame advertises.


Describing this fact on the flag is probably a good idea.


+
  return 0;
  }
  
@@ -402,6 +411,7 @@ const HWContextType ff_hwcontext_type_cuda = {

  .name = "CUDA",
  
  .device_hwctx_size= sizeof(AVCUDADeviceContext),

+.frames_hwctx_size= sizeof(AVCUDAFramesContext),
  .frames_priv_size = sizeof(CUDAFramesContext),
  
  .device_create= cuda_device_create,

diff --git a/libavutil/hwcontext_cuda.h b/libavutil/hwcontext_cuda.h
index 12dae8449e..388d6f8f1c 100644
--- a/libavutil/hwcontext_cuda.h
+++ b/libavutil/hwcontext_cuda.h
@@ -45,7 +45,23 @@ typedef struct AVCUDADeviceContext {
  } AVCUDADeviceContext;
  
  /**

- * AVHWFramesContext.hwctx is currently not used
+ * This struct is allocated as AVHWFramesContext.hwctx
   */
+typedef struct AVCUDAFramesContext {
+/**
+ * Special implementation-specific flags.
+ *
+ * Must be set by the user before calling av_hwframe_ctx_init().
+ */


This makes it sound like you /must/ write to the field.  Leaving it as zero is 
also fine.


Simply replacing "Must" with "May"?



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] avutil/hwcontext_cuda: add AVCUDAFramesContext and AVCUDAFramesContext.flags

2018-05-07 Thread Mark Thompson
On 07/05/18 22:10, Timo Rothenpieler wrote:
> Frames can be mapped from nvdec/cuvid, not needing any actual memory
> allocation, but all other features of the hw_frames_ctx.
> Hence the dummy-mode, which does not allocate any (notable amounts of)
> memory but otherwise behaves the exact same.
> ---
>  doc/APIchanges |  3 +++
>  libavutil/hwcontext_cuda.c | 10 ++
>  libavutil/hwcontext_cuda.h | 18 +-
>  libavutil/version.h|  2 +-
>  4 files changed, 31 insertions(+), 2 deletions(-)
> 
> diff --git a/doc/APIchanges b/doc/APIchanges
> index ede5b186ae..82ec888fd8 100644
> --- a/doc/APIchanges
> +++ b/doc/APIchanges
> @@ -15,6 +15,9 @@ libavutil: 2017-10-21
>  
>  API changes, most recent first:
>  
> +2018-05-xx - xx - lavu 56.19.100 - hwcontext.h
> +  Add AVCUDAFramesContext and AVCUDAFramesContext.flags.
> +
>  2018-04-xx - xx - lavu 56.18.100 - pixdesc.h
>Add AV_PIX_FMT_FLAG_ALPHA to AV_PIX_FMT_PAL8.
>  
> diff --git a/libavutil/hwcontext_cuda.c b/libavutil/hwcontext_cuda.c
> index 37827a770c..0d867ef0f5 100644
> --- a/libavutil/hwcontext_cuda.c
> +++ b/libavutil/hwcontext_cuda.c
> @@ -83,6 +83,7 @@ static void cuda_buffer_free(void *opaque, uint8_t *data)
>  static AVBufferRef *cuda_pool_alloc(void *opaque, int size)
>  {
>  AVHWFramesContext *ctx = opaque;
> +AVCUDAFramesContext *frctx = ctx->hwctx;
>  AVCUDADeviceContext *hwctx = ctx->device_ctx->hwctx;
>  CudaFunctions  *cu = hwctx->internal->cuda_dl;
>  
> @@ -97,6 +98,10 @@ static AVBufferRef *cuda_pool_alloc(void *opaque, int size)
>  return NULL;
>  }
>  
> +// A lot of places expect the pointer to be !=NULL, so make minimum 
> allocation instead.
> +if (frctx->flags & AV_CUDA_HWFRAMES_DUMMY_MODE)
> +size = 1;

What are those places - can we get rid of them instead?  Allocating a single 
byte here is rather yucky.

> +
>  err = cu->cuMemAlloc(, size);
>  if (err != CUDA_SUCCESS)
>  goto fail;
> @@ -161,6 +166,7 @@ static int cuda_frames_init(AVHWFramesContext *ctx)
>  
>  static int cuda_get_buffer(AVHWFramesContext *ctx, AVFrame *frame)
>  {
> +AVCUDAFramesContext *frctx = ctx->hwctx;
>  int aligned_width;
>  int width_in_bytes = ctx->width;
>  
> @@ -210,6 +216,9 @@ static int cuda_get_buffer(AVHWFramesContext *ctx, 
> AVFrame *frame)
>  frame->width  = ctx->width;
>  frame->height = ctx->height;
>  
> +if (frctx->flags & AV_CUDA_HWFRAMES_DUMMY_MODE)
> +frame->data[0] = frame->data[1] = frame->data[2] = NULL;

Are you intending linesize and buf[0] to have been filled with specific values 
here?

A comment saying exactly what is set and what isn't might help.  (Maybe the 
comment goes with the flag itself.)

> +
>  return 0;
>  }
>  
> @@ -402,6 +411,7 @@ const HWContextType ff_hwcontext_type_cuda = {
>  .name = "CUDA",
>  
>  .device_hwctx_size= sizeof(AVCUDADeviceContext),
> +.frames_hwctx_size= sizeof(AVCUDAFramesContext),
>  .frames_priv_size = sizeof(CUDAFramesContext),
>  
>  .device_create= cuda_device_create,
> diff --git a/libavutil/hwcontext_cuda.h b/libavutil/hwcontext_cuda.h
> index 12dae8449e..388d6f8f1c 100644
> --- a/libavutil/hwcontext_cuda.h
> +++ b/libavutil/hwcontext_cuda.h
> @@ -45,7 +45,23 @@ typedef struct AVCUDADeviceContext {
>  } AVCUDADeviceContext;
>  
>  /**
> - * AVHWFramesContext.hwctx is currently not used
> + * This struct is allocated as AVHWFramesContext.hwctx
>   */
> +typedef struct AVCUDAFramesContext {
> +/**
> + * Special implementation-specific flags.
> + *
> + * Must be set by the user before calling av_hwframe_ctx_init().
> + */

This makes it sound like you /must/ write to the field.  Leaving it as zero is 
also fine.

> +int flags;
> +} AVCUDAFramesContext;
> +
> +/**
> + * No actual allocation will happen, but otherwise behaves like normal.
> + *
> + * This is to be used if a AVHWFramesContext is required, but the actual
> + * allocation has to happen outside of it.
> + */
> +#define AV_CUDA_HWFRAMES_DUMMY_MODE (1 << 0)
>  
>  #endif /* AVUTIL_HWCONTEXT_CUDA_H */
> diff --git a/libavutil/version.h b/libavutil/version.h
> index 5185454d9b..84409b1d69 100644
> --- a/libavutil/version.h
> +++ b/libavutil/version.h
> @@ -79,7 +79,7 @@
>   */
>  
>  #define LIBAVUTIL_VERSION_MAJOR  56
> -#define LIBAVUTIL_VERSION_MINOR  18
> +#define LIBAVUTIL_VERSION_MINOR  19
>  #define LIBAVUTIL_VERSION_MICRO 100
>  
>  #define LIBAVUTIL_VERSION_INT   AV_VERSION_INT(LIBAVUTIL_VERSION_MAJOR, \
> 

This approach seems ok to me.

Thanks,

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


[FFmpeg-devel] [PATCH] avutil/hwcontext_cuda: add AVCUDAFramesContext and AVCUDAFramesContext.flags

2018-05-07 Thread Timo Rothenpieler
Frames can be mapped from nvdec/cuvid, not needing any actual memory
allocation, but all other features of the hw_frames_ctx.
Hence the dummy-mode, which does not allocate any (notable amounts of)
memory but otherwise behaves the exact same.
---
 doc/APIchanges |  3 +++
 libavutil/hwcontext_cuda.c | 10 ++
 libavutil/hwcontext_cuda.h | 18 +-
 libavutil/version.h|  2 +-
 4 files changed, 31 insertions(+), 2 deletions(-)

diff --git a/doc/APIchanges b/doc/APIchanges
index ede5b186ae..82ec888fd8 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,9 @@ libavutil: 2017-10-21
 
 API changes, most recent first:
 
+2018-05-xx - xx - lavu 56.19.100 - hwcontext.h
+  Add AVCUDAFramesContext and AVCUDAFramesContext.flags.
+
 2018-04-xx - xx - lavu 56.18.100 - pixdesc.h
   Add AV_PIX_FMT_FLAG_ALPHA to AV_PIX_FMT_PAL8.
 
diff --git a/libavutil/hwcontext_cuda.c b/libavutil/hwcontext_cuda.c
index 37827a770c..0d867ef0f5 100644
--- a/libavutil/hwcontext_cuda.c
+++ b/libavutil/hwcontext_cuda.c
@@ -83,6 +83,7 @@ static void cuda_buffer_free(void *opaque, uint8_t *data)
 static AVBufferRef *cuda_pool_alloc(void *opaque, int size)
 {
 AVHWFramesContext *ctx = opaque;
+AVCUDAFramesContext *frctx = ctx->hwctx;
 AVCUDADeviceContext *hwctx = ctx->device_ctx->hwctx;
 CudaFunctions  *cu = hwctx->internal->cuda_dl;
 
@@ -97,6 +98,10 @@ static AVBufferRef *cuda_pool_alloc(void *opaque, int size)
 return NULL;
 }
 
+// A lot of places expect the pointer to be !=NULL, so make minimum 
allocation instead.
+if (frctx->flags & AV_CUDA_HWFRAMES_DUMMY_MODE)
+size = 1;
+
 err = cu->cuMemAlloc(, size);
 if (err != CUDA_SUCCESS)
 goto fail;
@@ -161,6 +166,7 @@ static int cuda_frames_init(AVHWFramesContext *ctx)
 
 static int cuda_get_buffer(AVHWFramesContext *ctx, AVFrame *frame)
 {
+AVCUDAFramesContext *frctx = ctx->hwctx;
 int aligned_width;
 int width_in_bytes = ctx->width;
 
@@ -210,6 +216,9 @@ static int cuda_get_buffer(AVHWFramesContext *ctx, AVFrame 
*frame)
 frame->width  = ctx->width;
 frame->height = ctx->height;
 
+if (frctx->flags & AV_CUDA_HWFRAMES_DUMMY_MODE)
+frame->data[0] = frame->data[1] = frame->data[2] = NULL;
+
 return 0;
 }
 
@@ -402,6 +411,7 @@ const HWContextType ff_hwcontext_type_cuda = {
 .name = "CUDA",
 
 .device_hwctx_size= sizeof(AVCUDADeviceContext),
+.frames_hwctx_size= sizeof(AVCUDAFramesContext),
 .frames_priv_size = sizeof(CUDAFramesContext),
 
 .device_create= cuda_device_create,
diff --git a/libavutil/hwcontext_cuda.h b/libavutil/hwcontext_cuda.h
index 12dae8449e..388d6f8f1c 100644
--- a/libavutil/hwcontext_cuda.h
+++ b/libavutil/hwcontext_cuda.h
@@ -45,7 +45,23 @@ typedef struct AVCUDADeviceContext {
 } AVCUDADeviceContext;
 
 /**
- * AVHWFramesContext.hwctx is currently not used
+ * This struct is allocated as AVHWFramesContext.hwctx
  */
+typedef struct AVCUDAFramesContext {
+/**
+ * Special implementation-specific flags.
+ *
+ * Must be set by the user before calling av_hwframe_ctx_init().
+ */
+int flags;
+} AVCUDAFramesContext;
+
+/**
+ * No actual allocation will happen, but otherwise behaves like normal.
+ *
+ * This is to be used if a AVHWFramesContext is required, but the actual
+ * allocation has to happen outside of it.
+ */
+#define AV_CUDA_HWFRAMES_DUMMY_MODE (1 << 0)
 
 #endif /* AVUTIL_HWCONTEXT_CUDA_H */
diff --git a/libavutil/version.h b/libavutil/version.h
index 5185454d9b..84409b1d69 100644
--- a/libavutil/version.h
+++ b/libavutil/version.h
@@ -79,7 +79,7 @@
  */
 
 #define LIBAVUTIL_VERSION_MAJOR  56
-#define LIBAVUTIL_VERSION_MINOR  18
+#define LIBAVUTIL_VERSION_MINOR  19
 #define LIBAVUTIL_VERSION_MICRO 100
 
 #define LIBAVUTIL_VERSION_INT   AV_VERSION_INT(LIBAVUTIL_VERSION_MAJOR, \
-- 
2.17.0

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


Re: [FFmpeg-devel] [PATCH] avutil/hwcontext: add flags field to AVHWFramesContext

2018-05-07 Thread Mark Thompson
On 07/05/18 21:52, Timo Rothenpieler wrote:
>> Nack.  Implementation-specific details go in the implementation-specific 
>> structure (AVHWFramesContext.hwctx).
>>
>> What are you actually thining of using this for?  If you want to add flags 
>> which are in common between multiple different implementations then maybe it 
>> would be suitable to put it here, but something implementation-specific 
>> really shouldn't be.
> 
> I want to add a mapped-frame/dummy mode to the CUDA frame allocator, where it 
> does everything a normal hwframes ctx does, except allocating memory, because 
> the backing memory comes mapped from the cuvid frame.
> 
> Which is a simple flag to set, but there is no way to tell it right now.
> 
> The structures in the struct you mentioned are private to libavutil, so I 
> can't set them from a decoder.

They are public, it's just the frames one for CUDA doesn't currently exist.  
You want to make a new AVCUDAFramesContext structure in 
libavutil/hwcontext_cuda.h.

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


Re: [FFmpeg-devel] [PATCH 2/4] vaapi_encode_h265: Insert mastering display colour colume if needed

2018-05-07 Thread Mark Thompson
On 04/05/18 09:54, Xiang, Haihao wrote:
> On Thu, 2018-05-03 at 22:43 +0100, Mark Thompson wrote:
>> On 03/05/18 04:07, Haihao Xiang wrote:
>>> '-sei xxx' is added to control SEI insertion, so far only mastering
>>> display colour colume is available for testing.
>>
>> Typo: "colume" (also in the commit title).
>>
> 
> Thanks for catching the typo, I will correct it in the new version of patch.
> 
>>> v2: use the mastering display parameters from
>>> AVMasteringDisplayMetadata, set SEI_MASTERING_DISPLAY to 8 to match
>>> the H.264 part and take VAAPIEncodeH265Context::sei_needed as a ORed
>>> value so that we needn't check the correspoding SEI message again when
>>> writting the header.
>>>
>>> Signed-off-by: Haihao Xiang 
>>> ---
>>>  libavcodec/vaapi_encode_h265.c | 128
>>> -
>>>  1 file changed, 127 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/libavcodec/vaapi_encode_h265.c b/libavcodec/vaapi_encode_h265.c
>>> index 5203c6871d..326fe4fe66 100644
>>> --- a/libavcodec/vaapi_encode_h265.c
>>> +++ b/libavcodec/vaapi_encode_h265.c
>>> @@ -24,15 +24,20 @@
>>>  #include "libavutil/avassert.h"
>>>  #include "libavutil/common.h"
>>>  #include "libavutil/opt.h"
>>> +#include "libavutil/mastering_display_metadata.h"
>>>  
>>>  #include "avcodec.h"
>>>  #include "cbs.h"
>>>  #include "cbs_h265.h"
>>>  #include "hevc.h"
>>> +#include "hevc_sei.h"
>>>  #include "internal.h"
>>>  #include "put_bits.h"
>>>  #include "vaapi_encode.h"
>>>  
>>> +enum {
>>> +SEI_MASTERING_DISPLAY   = 0x08,
>>> +};
>>>  
>>>  typedef struct VAAPIEncodeH265Context {
>>>  unsigned int ctu_width;
>>> @@ -47,6 +52,9 @@ typedef struct VAAPIEncodeH265Context {
>>>  H265RawSPS sps;
>>>  H265RawPPS pps;
>>>  H265RawSlice slice;
>>> +H265RawSEI sei;
>>> +
>>> +H265RawSEIMasteringDiplayColourVolume mastering_display;
>>>  
>>>  int64_t last_idr_frame;
>>>  int pic_order_cnt;
>>> @@ -58,6 +66,7 @@ typedef struct VAAPIEncodeH265Context {
>>>  CodedBitstreamContext *cbc;
>>>  CodedBitstreamFragment current_access_unit;
>>>  int aud_needed;
>>> +int sei_needed;
>>>  } VAAPIEncodeH265Context;
>>>  
>>>  typedef struct VAAPIEncodeH265Options {
>>> @@ -65,6 +74,7 @@ typedef struct VAAPIEncodeH265Options {
>>>  int aud;
>>>  int profile;
>>>  int level;
>>> +int sei;
>>>  } VAAPIEncodeH265Options;
>>>  
>>>  
>>> @@ -175,6 +185,64 @@ fail:
>>>  return err;
>>>  }
>>>  
>>> +static int vaapi_encode_h265_write_extra_header(AVCodecContext *avctx,
>>> +VAAPIEncodePicture *pic,
>>> +int index, int *type,
>>> +char *data, size_t
>>> *data_len)
>>> +{
>>> +VAAPIEncodeContext  *ctx = avctx->priv_data;
>>> +VAAPIEncodeH265Context *priv = ctx->priv_data;
>>> +CodedBitstreamFragment   *au = >current_access_unit;
>>> +int err, i;
>>> +
>>> +if (priv->sei_needed) {
>>> +if (priv->aud_needed) {
>>> +err = vaapi_encode_h265_add_nal(avctx, au, >aud);
>>> +if (err < 0)
>>> +goto fail;
>>> +priv->aud_needed = 0;
>>> +}
>>> +
>>> +memset(>sei, 0, sizeof(priv->sei));
>>> +priv->sei.nal_unit_header  = (H265RawNALUnitHeader) {
>>> +.nal_unit_type = HEVC_NAL_SEI_PREFIX,
>>> +.nuh_layer_id  = 0,
>>> +.nuh_temporal_id_plus1 = 1,
>>> +};
>>> +
>>> +i = 0;
>>> +
>>> +if (priv->sei_needed & SEI_MASTERING_DISPLAY) {
>>> +priv->sei.payload[i].payload_type =
>>> HEVC_SEI_TYPE_MASTERING_DISPLAY_INFO;
>>> +priv->sei.payload[i].payload.mastering_display = priv-
 mastering_display;
>>> +++i;
>>> +}
>>> +
>>> +priv->sei.payload_count = i;
>>> +av_assert0(priv->sei.payload_count > 0);
>>> +
>>> +err = vaapi_encode_h265_add_nal(avctx, au, >sei);
>>> +if (err < 0)
>>> +goto fail;
>>> +priv->sei_needed = 0;
>>> +
>>> +err = vaapi_encode_h265_write_access_unit(avctx, data, data_len,
>>> au);
>>> +if (err < 0)
>>> +goto fail;
>>> +
>>> +ff_cbs_fragment_uninit(priv->cbc, au);
>>> +
>>> +*type = VAEncPackedHeaderRawData;
>>> +return 0;
>>> +} else {
>>> +return AVERROR_EOF;
>>> +}
>>> +
>>> +fail:
>>> +ff_cbs_fragment_uninit(priv->cbc, au);
>>> +return err;
>>> +}
>>> +
>>>  static int vaapi_encode_h265_init_sequence_params(AVCodecContext *avctx)
>>>  {
>>>  VAAPIEncodeContext*ctx = avctx->priv_data;
>>> @@ -587,6 +655,53 @@ static int
>>> vaapi_encode_h265_init_picture_params(AVCodecContext *avctx,
>>>  priv->aud_needed = 0;
>>>  }
>>>  
>>> +priv->sei_needed = 0;
>>> +
>>> +if ((opt->sei & SEI_MASTERING_DISPLAY) &&
>>> +  

Re: [FFmpeg-devel] [PATCH 1/3] vaapi_encode: Initialize the pointer

2018-05-07 Thread Mark Thompson
On 04/05/18 15:41, Haihao Xiang wrote:
> Otherwise it might use unitialized last_pic in av_assert0(last_pic)
> 
> Signed-off-by: Haihao Xiang 
> ---
>  libavcodec/vaapi_encode.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
> index 36c85a3815..141e50c8ad 100644
> --- a/libavcodec/vaapi_encode.c
> +++ b/libavcodec/vaapi_encode.c
> @@ -760,7 +760,7 @@ fail:
>  static int vaapi_encode_truncate_gop(AVCodecContext *avctx)
>  {
>  VAAPIEncodeContext *ctx = avctx->priv_data;
> -VAAPIEncodePicture *pic, *last_pic, *next;
> +VAAPIEncodePicture *pic, *last_pic = NULL, *next;
>  
>  // Find the last picture we actually have input for.
>  for (pic = ctx->pic_start; pic; pic = pic->next) {
> 

How do you hit this?  last_pic should always get set.

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


Re: [FFmpeg-devel] [PATCH] avutil/hwcontext: add flags field to AVHWFramesContext

2018-05-07 Thread Timo Rothenpieler

Nack.  Implementation-specific details go in the implementation-specific 
structure (AVHWFramesContext.hwctx).

What are you actually thining of using this for?  If you want to add flags 
which are in common between multiple different implementations then maybe it 
would be suitable to put it here, but something implementation-specific really 
shouldn't be.


I want to add a mapped-frame/dummy mode to the CUDA frame allocator, 
where it does everything a normal hwframes ctx does, except allocating 
memory, because the backing memory comes mapped from the cuvid frame.


Which is a simple flag to set, but there is no way to tell it right now.

The structures in the struct you mentioned are private to libavutil, so 
I can't set them from a decoder.




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] vaapi_encode_vp8: memset the the structure to 0

2018-05-07 Thread Mark Thompson
On 04/05/18 15:41, Haihao Xiang wrote:
> The structure has reserved bytes, it is required to set the reserved
> bytes to 0 for future use.
> 
> Signed-off-by: Haihao Xiang 
> ---
>  libavcodec/vaapi_encode_vp8.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/libavcodec/vaapi_encode_vp8.c b/libavcodec/vaapi_encode_vp8.c
> index b4c5521d1f..a2e861a8d1 100644
> --- a/libavcodec/vaapi_encode_vp8.c
> +++ b/libavcodec/vaapi_encode_vp8.c
> @@ -143,6 +143,8 @@ static int 
> vaapi_encode_vp8_write_quant_table(AVCodecContext *avctx,
>  *type = VAQMatrixBufferType;
>  *data_len = sizeof(quant);
>  
> +memset(, 0, sizeof(quant));
> +
>  if (pic->type == PICTURE_TYPE_P)
>  q = priv->q_index_p;
>  else
> 

Yep, applied.

(... is there any plan to add anything to that structure?)

Thanks,

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


Re: [FFmpeg-devel] [PATCH 1/4] cbs_h265: read/write HEVC PREFIX SEI

2018-05-07 Thread Mark Thompson
On 04/05/18 05:03, Xiang, Haihao wrote:
> On Thu, 2018-05-03 at 22:32 +0100, Mark Thompson wrote:
>> On 03/05/18 04:07, Haihao Xiang wrote:
>>> Similar to H264, cbs_h265_{read, write}_nal_unit() can handle HEVC
>>> prefix SEI NAL units. Currently mastering display colour volume SEI
>>> message is added only, we may add more SEI message if needed later
>>>
>>> v2: Fix coding style and rebase the code
>>>
>>> Signed-off-by: Haihao Xiang 
>>> ---
>>>  libavcodec/cbs_h2645.c|  45 ++
>>>  libavcodec/cbs_h265.h |  36 
>>>  libavcodec/cbs_h265_syntax_template.c | 157
>>> ++
>>>  3 files changed, 238 insertions(+)
>>
>> Please run this through trace_headers with a suitable input and make sure it
>> works and that the output is correct.  (It currently hits some asserts.)
>>
>> ./ffmpeg_g -i input-with-hdr-metadata.mkv -c:v copy -bsf:v trace_headers -f
>> null -
>>
> 
> Sorry, I didn't run the above command to make sure reading SEI message works. 
> I
> have root-caused it and will update the patch. 
> 
> BTW reading H.264 SEI message also hits this assert if the SEI message is
> handled in the default path in cbs_h264_read_sei_payload(). I will fix it too.

Yeah.  (And also shows that fate doesn't actually cover the SEI cases at all.  
The data_length element is broken too.  I've made an artificial stream with a 
lot of suitable SEI types in for this, I'll send it soon so this is actually 
tested.)

Thanks,

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


Re: [FFmpeg-devel] [PATCH 2/3] hwcontext_vaapi: Return error if can not find a VA RT format

2018-05-07 Thread Mark Thompson
On 04/05/18 15:41, Haihao Xiang wrote:
> Otherwise va_rt_format might be unitialized
> 
> Signed-off-by: Haihao Xiang 
> ---
>  libavutil/hwcontext_vaapi.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
> index 7daaa951cc..e59042487d 100644
> --- a/libavutil/hwcontext_vaapi.c
> +++ b/libavutil/hwcontext_vaapi.c
> @@ -1028,6 +1028,11 @@ static int vaapi_map_from_drm(AVHWFramesContext 
> *src_fc, AVFrame *dst,
>  va_rt_format = vaapi_format_map[i].rt_format;
>  }
>  
> +if (i >= FF_ARRAY_ELEMS(vaapi_format_map)) {
> +av_log(dst_fc, AV_LOG_ERROR, "No matching VA RT format \n");
> +return AVERROR(EINVAL);
> +}
> +
>  buffer_handle = desc->objects[0].fd;
>  buffer_desc.pixel_format = va_fourcc;
>  buffer_desc.width= src_fc->width;
> 

How would you hit this case?  Every fourcc in vaapi_drm_format_map is also 
present in vaapi_format_map.

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


Re: [FFmpeg-devel] [PATCH] avutil/hwcontext: add flags field to AVHWFramesContext

2018-05-07 Thread Mark Thompson
On 07/05/18 19:39, Timo Rothenpieler wrote:
> ---
>  doc/APIchanges| 3 +++
>  libavutil/hwcontext.h | 7 +++
>  libavutil/version.h   | 2 +-
>  3 files changed, 11 insertions(+), 1 deletion(-)
> 
> diff --git a/doc/APIchanges b/doc/APIchanges
> index ede5b186ae..307c7a51ee 100644
> --- a/doc/APIchanges
> +++ b/doc/APIchanges
> @@ -15,6 +15,9 @@ libavutil: 2017-10-21
>  
>  API changes, most recent first:
>  
> +2018-05-xx - xx - lavu 56.19.100 - hwcontext.h
> +  Add AVHWFramesContext.flags.
> +
>  2018-04-xx - xx - lavu 56.18.100 - pixdesc.h
>Add AV_PIX_FMT_FLAG_ALPHA to AV_PIX_FMT_PAL8.
>  
> diff --git a/libavutil/hwcontext.h b/libavutil/hwcontext.h
> index f5a4b62387..23e2d335a5 100644
> --- a/libavutil/hwcontext.h
> +++ b/libavutil/hwcontext.h
> @@ -226,6 +226,13 @@ typedef struct AVHWFramesContext {
>   * Must be set by the user before calling av_hwframe_ctx_init().
>   */
>  int width, height;
> +
> +/**
> + * Special implementation-specific flags.
> + *
> + * Must be set by the user before calling av_hwframe_ctx_init().
> + */
> +int flags;
>  } AVHWFramesContext;
>  
>  /**
> diff --git a/libavutil/version.h b/libavutil/version.h
> index 5185454d9b..84409b1d69 100644
> --- a/libavutil/version.h
> +++ b/libavutil/version.h
> @@ -79,7 +79,7 @@
>   */
>  
>  #define LIBAVUTIL_VERSION_MAJOR  56
> -#define LIBAVUTIL_VERSION_MINOR  18
> +#define LIBAVUTIL_VERSION_MINOR  19
>  #define LIBAVUTIL_VERSION_MICRO 100
>  
>  #define LIBAVUTIL_VERSION_INT   AV_VERSION_INT(LIBAVUTIL_VERSION_MAJOR, \
> 

Nack.  Implementation-specific details go in the implementation-specific 
structure (AVHWFramesContext.hwctx).

What are you actually thining of using this for?  If you want to add flags 
which are in common between multiple different implementations then maybe it 
would be suitable to put it here, but something implementation-specific really 
shouldn't be.

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


Re: [FFmpeg-devel] [PATCH 2/2] avcodec/libzvbi-teletextdec: formatted ass output

2018-05-07 Thread Aman Gupta
On Mon, May 7, 2018 at 12:50 PM, Aman Gupta  wrote:

>
>
> On Sun, May 6, 2018 at 2:05 PM, Marton Balint  wrote:
>
>> Inspired by the VideoLAN text decoder and its port to FFmpeg made by Aman
>> Gupta.
>>
>
> Thanks for incorporating my changes.
>
> I ran some tests, and colors work as expected. Positioning also works
> well, and is also pretty close to my version.
>
>
> I found that some live streams are not chopping empty lines correctly. I
> see extra newlines at the end:
>
>   Dialogue: 0,0:13:21.66,9:59:59.99,Default,,0,0,0,,{\an1}Simson,\
> hPeter\hHartcher,\hRobyn\hParker \Nand\hBenjamin \N \N \N
>
> Here's a sample which shows extra newlines: https://s3.
> amazonaws.com/tmm1/teletext/capture_live1.mpg
>
>
> It also looks like the "erase page" command is not being processed, which
> causes stale captions to stay on the screen in some cases.
> This is especially confusing when part of an old caption remains on one
> line, but then newer captions appear on another line.
>
> Here's a sample that shows lines not being cleared correctly: https://s3.
> amazonaws.com/tmm1/teletext/simple.mpg
>

With this sample, for instance, my decoder produces:

Dialogue:
0,0:00:01.90,9:59:59.99,Default,,0,0,0,,{\an8}{\pos(192,213)}{\c&}and
this, as you rightly say,\N
Dialogue:
0,0:00:01.94,9:59:59.99,Default,,0,0,0,,{\an8}{\pos(192,213)}{\c&}and
this, as you rightly say,\N{\an8}{\pos(192,231)}{\c&}is
American.\N
Dialogue: 0,0:00:04.86,9:59:59.99,Default,,0,0,0,,
Dialogue:
0,0:00:04.94,9:59:59.99,Default,,0,0,0,,{\an8}{\pos(192,231)}{\c&}It's
rather nicely made.\N
Dialogue: 0,0:00:06.62,9:59:59.99,Default,,0,0,0,,
Dialogue:
0,0:00:06.70,9:59:59.99,Default,,0,0,0,,{\an8}{\pos(192,213)}{\c&}It's
got this fabulous\N
Dialogue:
0,0:00:06.74,9:59:59.99,Default,,0,0,0,,{\an8}{\pos(192,213)}{\c&}It's
got this fabulous\N{\an8}{\pos(192,231)}   {\c&}cast finial here\N
Dialogue: 0,0:00:10.34,9:59:59.99,Default,,0,0,0,,
Dialogue:
0,0:00:10.42,9:59:59.99,Default,,0,0,0,,{\an8}{\pos(192,213)}{\c&}of
a very muscular figure\N
Dialogue:
0,0:00:10.46,9:59:59.99,Default,,0,0,0,,{\an8}{\pos(192,213)}{\c&}of
a very muscular figure\N{\an8}{\pos(192,231)} {\c&}pulling this
medallion.\N
Dialogue: 0,0:00:15.50,9:59:59.99,Default,,0,0,0,,
Dialogue:
0,0:00:15.58,9:59:59.99,Default,,0,0,0,,{\an8}{\pos(192,213)}{\c&}So
it's got strength to it. It's a\N
Dialogue: 0,0:00:15.62,9:59:59.99,Default,,0,0,0,,{\an8}{\pos(192,213)}
{\c&}So it's got strength to it. It's
a\N{\an8}{\pos(192,231)}{\c&}really characterful piece of silver.\N
Dialogue: 0,0:00:19.14,9:59:59.99,Default,,0,0,0,,

And the decoder in this patch produces:

Dialogue:
0,0:00:02.02,9:59:59.99,Default,,0,0,0,,{\an2}and\hthis,\has\hyou\hrightly\hsay,
\Nis\hAmerican. \N
Dialogue:
0,0:00:05.02,9:59:59.99,Default,,0,0,0,,{\an2}and\hthis,\has\hyou\hrightly\hsay,
\NIt's\hrather\hnicely\hmade. \N
Dialogue:
0,0:00:06.82,9:59:59.99,Default,,0,0,0,,{\an2}It's\hgot\hthis\hfabulous
\Ncast\hfinial\hhere \N
Dialogue:
0,0:00:10.54,9:59:59.99,Default,,0,0,0,,{\an2}of\ha\hvery\hmuscular\hfigure
\Npulling\hthis\hmedallion. \N
Dialogue:
0,0:00:15.70,9:59:59.99,Default,,0,0,0,,{\an2}So\hit's\hgot\hstrength\hto\hit.\hIt's\ha
\Nreally\hcharacterful\hpiece\hof\hsilver. \N
Dialogue:
0,0:00:19.30,9:59:59.99,Default,,0,0,0,,{\an2}So\hit's\hgot\hstrength\hto\hit.\hIt's\ha
\NBut\hmost\himportant\hof\hall, \N

At the ~5s mark, the text on the screen should say "It's rather nicely
made", but this decoder still displays the line "and this as you rightly
say" from the previous sentence.

Aman


>
>
> I also have several other samples which use various features, available at
> the same URL:
>
> capture_formatting1.mpg
> capture_formatting2.mpg
> capture_formatting3.mpg
> capture_live1.mpg
> capture_live2.mpg
> capture_notCaptionedMessage.mpg
> capture_threeLines1.mpg
> capture_threeLines2.mpg
> capture_threeLines3.mpg
> capture_threeLines4.mpg
> capture_yOffset1.mpg
> three.ts
> four.ts
>
> Thanks,
> Aman
>
>
>
>>
>> Signed-off-by: Marton Balint 
>> ---
>>  doc/decoders.texi|  18 ++-
>>  libavcodec/libzvbi-teletextdec.c | 265 ++
>> +++--
>>  2 files changed, 270 insertions(+), 13 deletions(-)
>>
>> diff --git a/doc/decoders.texi b/doc/decoders.texi
>> index 8f07bc1afb..cc9b2ef123 100644
>> --- a/doc/decoders.texi
>> +++ b/doc/decoders.texi
>> @@ -255,12 +255,18 @@ Default value is *.
>>  @item txt_chop_top
>>  Discards the top teletext line. Default value is 1.
>>  @item txt_format
>> -Specifies the format of the decoded subtitles. The teletext decoder is
>> capable
>> -of decoding the teletext pages to bitmaps or to simple text, you should
>> use
>> -"bitmap" for teletext pages, because certain graphics and colors cannot
>> be
>> -expressed in simple text. You might use "text" for teletext based
>> subtitles if
>> -your application can handle simple text based subtitles. Default value is
>> -bitmap.
>> +Specifies the 

Re: [FFmpeg-devel] [PATCH 2/2] avcodec/libzvbi-teletextdec: formatted ass output

2018-05-07 Thread Aman Gupta
On Sun, May 6, 2018 at 2:05 PM, Marton Balint  wrote:

> Inspired by the VideoLAN text decoder and its port to FFmpeg made by Aman
> Gupta.
>

Thanks for incorporating my changes.

I ran some tests, and colors work as expected. Positioning also works well,
and is also pretty close to my version.


I found that some live streams are not chopping empty lines correctly. I
see extra newlines at the end:

  Dialogue:
0,0:13:21.66,9:59:59.99,Default,,0,0,0,,{\an1}Simson,\hPeter\hHartcher,\hRobyn\hParker
\Nand\hBenjamin \N \N \N

Here's a sample which shows extra newlines:
https://s3.amazonaws.com/tmm1/teletext/capture_live1.mpg


It also looks like the "erase page" command is not being processed, which
causes stale captions to stay on the screen in some cases.
This is especially confusing when part of an old caption remains on one
line, but then newer captions appear on another line.

Here's a sample that shows lines not being cleared correctly:
https://s3.amazonaws.com/tmm1/teletext/simple.mpg


I also have several other samples which use various features, available at
the same URL:

capture_formatting1.mpg
capture_formatting2.mpg
capture_formatting3.mpg
capture_live1.mpg
capture_live2.mpg
capture_notCaptionedMessage.mpg
capture_threeLines1.mpg
capture_threeLines2.mpg
capture_threeLines3.mpg
capture_threeLines4.mpg
capture_yOffset1.mpg
three.ts
four.ts

Thanks,
Aman



>
> Signed-off-by: Marton Balint 
> ---
>  doc/decoders.texi|  18 ++-
>  libavcodec/libzvbi-teletextdec.c | 265 ++
> +++--
>  2 files changed, 270 insertions(+), 13 deletions(-)
>
> diff --git a/doc/decoders.texi b/doc/decoders.texi
> index 8f07bc1afb..cc9b2ef123 100644
> --- a/doc/decoders.texi
> +++ b/doc/decoders.texi
> @@ -255,12 +255,18 @@ Default value is *.
>  @item txt_chop_top
>  Discards the top teletext line. Default value is 1.
>  @item txt_format
> -Specifies the format of the decoded subtitles. The teletext decoder is
> capable
> -of decoding the teletext pages to bitmaps or to simple text, you should
> use
> -"bitmap" for teletext pages, because certain graphics and colors cannot be
> -expressed in simple text. You might use "text" for teletext based
> subtitles if
> -your application can handle simple text based subtitles. Default value is
> -bitmap.
> +Specifies the format of the decoded subtitles.
> +@table @option
> +@item bitmap
> +The default format, you should use this for teletext pages, because
> certain
> +graphics and colors cannot be expressed in simple text or even ASS.
> +@item text
> +Simple text based output without formatting.
> +@item ass
> +Formatted ASS output, subtitle pages and teletext pages are returned in
> +different styles, subtitle pages are stripped down to text, but an effort
> is
> +made to keep the text alignment and the formatting.
> +@end table
>  @item txt_left
>  X offset of generated bitmaps, default is 0.
>  @item txt_top
> diff --git a/libavcodec/libzvbi-teletextdec.c b/libavcodec/libzvbi-
> teletextdec.c
> index 56a7182882..7541de0d53 100644
> --- a/libavcodec/libzvbi-teletextdec.c
> +++ b/libavcodec/libzvbi-teletextdec.c
> @@ -26,6 +26,7 @@
>  #include "libavutil/internal.h"
>  #include "libavutil/intreadwrite.h"
>  #include "libavutil/log.h"
> +#include "libavutil/common.h"
>
>  #include 
>
> @@ -56,7 +57,7 @@ typedef struct TeletextContext
>  char   *pgno;
>  int x_offset;
>  int y_offset;
> -int format_id; /* 0 = bitmap, 1 = text/ass */
> +int format_id; /* 0 = bitmap, 1 = text/ass, 2 = ass */
>  int chop_top;
>  int sub_duration; /* in msec */
>  int transparent_bg;
> @@ -74,8 +75,55 @@ typedef struct TeletextContext
>
>  int readorder;
>  uint8_t subtitle_map[2048];
> +int last_ass_alignment;
>  } TeletextContext;
>
> +static int my_ass_subtitle_header(AVCodecContext *avctx)
> +{
> +int ret = ff_ass_subtitle_header_default(avctx);
> +char *new_header;
> +uint8_t *event_pos;
> +
> +if (ret < 0)
> +return ret;
> +
> +event_pos = strstr(avctx->subtitle_header, "\r\n[Events]\r\n");
> +if (!event_pos)
> +return AVERROR_BUG;
> +
> +new_header = av_asprintf("%.*s%s%s",
> +(int)(event_pos - avctx->subtitle_header), avctx->subtitle_header,
> +"Style: "
> +"Teletext,"/* Name */
> +"Monospace,11,"/* Font{name,size} */
> +"" /* 
> {Primary,Secondary,Outline,Back}Colour
> */
> +"0,0,0,0," /* Bold, Italic, Underline, StrikeOut */
> +"160,100," /* Scale{X,Y} */
> +"0,0," /* Spacing, Angle */
> +"3,0.1,0," /* BorderStyle, Outline, Shadow */
> +"5,1,1,1," /* Alignment, Margin[LRV] */
> +"0\r\n"/* Encoding */
> +"Style: 

Re: [FFmpeg-devel] HLS Questions

2018-05-07 Thread Aman Gupta
On Wed, May 2, 2018 at 7:59 AM, Ronak Patel <
ronak2121-at-yahoo@ffmpeg.org> wrote:

> Hi all,
>
> So I’ve noticed that ffmpeg does not always properly follow the number we
> specify for hls_time when generating hls content.
>
> For example, if we have an MP4/AAC file at 44.1kHz sampling rate, we would
> expect that specifying 9.75238095238095 (420 frames) would return a
> manifest with the same exact amount of frames throughout.
> Instead, we see the AAC encoder vary the amount of frames without any real
> explanation.
>

Did you try -hls_flags split_by_time ?

Aman


>
> When we run the following command:
>
> /home/ronakp/bin/ffmpeg -i "${FILE}.mp4" -codec copy -hls_time
> 9.75238095238095 -hls_segment_type fmp4 -hls_flags single_file+append_list
> -hls_playlist_type vod "${FILE}_10sec_v7.m3u8"
>
> We get a manifest that looks like so:
>
> #EXTM3U
> #EXT-X-VERSION:7
> #EXT-X-TARGETDURATION:10
> #EXT-X-MEDIA-SEQUENCE:0
> #EXT-X-PLAYLIST-TYPE:VOD
> #EXT-X-MAP:URI="bk_acx0_006556_22_32_10sec_v7.m4s",BYTERANGE="738@0"
> #EXT-X-DISCONTINUITY
> #EXTINF:9.798821,
> #EXT-X-BYTERANGE:38733@738
> bk_acx0_006556_22_32_10sec_v7.m4s
> #EXTINF:9.752381,
> #EXT-X-BYTERANGE:38531@39471
> bk_acx0_006556_22_32_10sec_v7.m4s
> #EXTINF:9.752381,
> #EXT-X-BYTERANGE:38616@78002
> bk_acx0_006556_22_32_10sec_v7.m4s
> #EXTINF:9.752381,
> #EXT-X-BYTERANGE:38545@116618
> bk_acx0_006556_22_32_10sec_v7.m4s
>
> Notice the first segment there contains 2 more AAC frames...
>
> Now, when we run the following command:
>
> /home/ronakp/bin/ffmpeg -i "${FILE}.mp4" -codec copy -hls_time
> 0.975238095238095 -hls_segment_type fmp4 -hls_flags single_file+append_list
> -hls_playlist_type vod "${FILE}_10sec_v7.m3u8"
>
> #EXTM3U
> #EXT-X-VERSION:7
> #EXT-X-TARGETDURATION:1
> #EXT-X-MEDIA-SEQUENCE:0
> #EXT-X-PLAYLIST-TYPE:VOD
> #EXT-X-MAP:URI="bk_reco_004353_22_32_1sec_v7.m4s",BYTERANGE="738@0"
> #EXT-X-DISCONTINUITY
> #EXTINF:0.975238,
> #EXT-X-BYTERANGE:4110@738
> bk_reco_004353_22_32_1sec_v7.m4s
> #EXTINF:0.975238,
> #EXT-X-BYTERANGE:3897@4848
> bk_reco_004353_22_32_1sec_v7.m4s
> #EXTINF:0.975238,
> #EXT-X-BYTERANGE:4236@8745
> bk_reco_004353_22_32_1sec_v7.m4s
> #EXTINF:0.975238,
>
> It seems to have the correct amount of frames everywhere.
>
> Even more bizarre is if we run this command:
>
> /home/ronakp/bin/ffmpeg -i "../${FILE}.mp4" -codec copy -hls_time
> 9.75238095238095 -hls_segment_filename 'file%03d.ts' -hls_segment_type
> mpegts -hls_playlist_type vod "${FILE}_10sec_v3.m3u8"
>
> The manifest looks like the following:
>
> #EXTM3U
> #EXT-X-VERSION:3
> #EXT-X-TARGETDURATION:10
> #EXT-X-MEDIA-SEQUENCE:0
> #EXT-X-PLAYLIST-TYPE:VOD
> #EXTINF:9.799778,
> file000.ts
> #EXTINF:9.706889,
> file001.ts
> #EXTINF:9.75,
> file002.ts
> #EXTINF:9.799778,
> file003.ts
> #EXTINF:9.75,
> file004.ts
> #EXTINF:9.706889,
> file005.ts
> #EXTINF:9.799778,
> file006.ts
>
> The ts segments do not all have the same size, and seems like ffmpeg is
> unable to properly honor the supplied time.
>
> And finally, when I run the following command:
>
> /home/ronakp/bin/ffmpeg -i "${FILE}.mp4" -codec copy -f dash
> -single_file_name "${FILE}_1sec.m4s" -min_seg_duration 975238.095238095
> -hls_playlist 1 "${FILE}_1sec.mpd"
>
> I get a manifest that looks like:
>
> #EXTM3U
> #EXT-X-VERSION:6
> #EXT-X-TARGETDURATION:10
> #EXT-X-MEDIA-SEQUENCE:1
> #EXT-X-MAP:URI="bk_reco_004353_22_32_10sec.m4s",BYTERANGE="738@0"
> #EXTINF:9.798821,
> #EXT-X-BYTERANGE:38996@738
> bk_reco_004353_22_32_10sec.m4s
> #EXTINF:9.798821,
> #EXT-X-BYTERANGE:38754@39734
> bk_reco_004353_22_32_10sec.m4s
> #EXTINF:9.798821,
> #EXT-X-BYTERANGE:38765@78488
> bk_reco_004353_22_32_10sec.m4s
> #EXTINF:9.798821,
> #EXT-X-BYTERANGE:38583@117253
> bk_reco_004353_22_32_10sec.m4s
> #EXTINF:9.798821,
> #EXT-X-BYTERANGE:38752@155836
> bk_reco_004353_22_32_10sec.m4s
>
> Where every fragment has 1 extra frame in it.
>
> Can someone please help get this fixed? The fragmentation should have been
> uniform throughout and exactly the same no matter which options I specify
> here.
>
> For reference, I'm using the following versions of ffmpeg:
>
> ffmpeg version N-90757-g2fc12f4 Copyright (c) 2000-2018 the FFmpeg
> developers
>   built with gcc 4.4.6 (GCC) 20110731 (Red Hat 4.4.6-3)
>   configuration: --prefix=/home/ronakp/ffmpeg_build
> --pkg-config-flags=--static --extra-cflags=-I/home/ronakp/ffmpeg_build/include
> --extra-ldflags=-L/home/ronakp/ffmpeg_build/lib --extra-libs=-lpthread
> --extra-libs=-lm --bindir=/home/ronakp/bin --enable-gpl --enable-avisynth
> --enable-libfdk_aac --enable-libmp3lame --enable-libopus --enable-libvorbis
> --enable-nonfree --enable-libvorbis --enable-version3 --disable-ffplay
>   libavutil  56. 15.100 / 56. 15.100
>   libavcodec 58. 19.100 / 58. 19.100
>   libavformat58. 13.100 / 58. 13.100
>   libavdevice58.  4.100 / 58.  4.100
>   libavfilter 7. 18.100 /  7. 18.100
>   libswscale  5.  2.100 /  5.  2.100
>   libswresample   3.  2.100 /  3.  2.100
>   

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/libzvbi-teletextdec: add support for selecting subtitle pages only

2018-05-07 Thread Aman Gupta
On Sun, May 6, 2018 at 2:05 PM, Marton Balint  wrote:

> Signed-off-by: Marton Balint 
> ---
>  doc/decoders.texi|  5 +++--
>  libavcodec/libzvbi-teletextdec.c | 31 ++-
>  2 files changed, 25 insertions(+), 11 deletions(-)
>
> diff --git a/doc/decoders.texi b/doc/decoders.texi
> index a551d5d0fd..8f07bc1afb 100644
> --- a/doc/decoders.texi
> +++ b/doc/decoders.texi
> @@ -248,8 +248,9 @@ configuration. You need to explicitly configure the
> build with
>
>  @table @option
>  @item txt_page
> -List of teletext page numbers to decode. You may use the special * string
> to
> -match all pages. Pages that do not match the specified list are dropped.
> +List of teletext page numbers to decode. Pages that do not match the
> specified
> +list are dropped. You may use the special @code{*} string to match all
> pages,
> +or @code{subtitle} to match all subtitle pages.
>

Thanks for adding this. It works as expected for me.

Might be worth documenting in the AVOption.help text as well.

Aman


>  Default value is *.
>  @item txt_chop_top
>  Discards the top teletext line. Default value is 1.
> diff --git a/libavcodec/libzvbi-teletextdec.c b/libavcodec/libzvbi-
> teletextdec.c
> index a800ad34ae..56a7182882 100644
> --- a/libavcodec/libzvbi-teletextdec.c
> +++ b/libavcodec/libzvbi-teletextdec.c
> @@ -73,6 +73,7 @@ typedef struct TeletextContext
>  vbi_sliced  sliced[MAX_SLICES];
>
>  int readorder;
> +uint8_t subtitle_map[2048];
>  } TeletextContext;
>
>  static int chop_spaces_utf8(const unsigned char* t, int len)
> @@ -281,16 +282,14 @@ static void handler(vbi_event *ev, void *user_data)
>  vbi_page page;
>  int res;
>  char pgno_str[12];
> -vbi_subno subno;
> -vbi_page_type vpt;
>  int chop_top;
> -char *lang;
> +int is_subtitle_page = ctx->subtitle_map[ev->ev.ttx_page.pgno &
> 0x7ff];
>
>  snprintf(pgno_str, sizeof pgno_str, "%03x", ev->ev.ttx_page.pgno);
>  av_log(ctx, AV_LOG_DEBUG, "decoded page %s.%02x\n",
> pgno_str, ev->ev.ttx_page.subno & 0xFF);
>
> -if (strcmp(ctx->pgno, "*") && !strstr(ctx->pgno, pgno_str))
> +if (strcmp(ctx->pgno, "*") && (strcmp(ctx->pgno, "subtitle") ||
> !is_subtitle_page) && !strstr(ctx->pgno, pgno_str))
>  return;
>  if (ctx->handler_ret < 0)
>  return;
> @@ -303,9 +302,7 @@ static void handler(vbi_event *ev, void *user_data)
>  if (!res)
>  return;
>
> -vpt = vbi_classify_page(ctx->vbi, ev->ev.ttx_page.pgno, ,
> );
> -chop_top = ctx->chop_top ||
> -((page.rows > 1) && (vpt == VBI_SUBTITLE_PAGE));
> +chop_top = ctx->chop_top || ((page.rows > 1) && is_subtitle_page);
>
>  av_log(ctx, AV_LOG_DEBUG, "%d x %d page chop:%d\n",
> page.columns, page.rows, chop_top);
> @@ -357,11 +354,26 @@ static int slice_to_vbi_lines(TeletextContext *ctx,
> uint8_t* buf, int size)
>  else {
>  int line_offset  = buf[2] & 0x1f;
>  int field_parity = buf[2] & 0x20;
> -int i;
> +uint8_t *p = ctx->sliced[lines].data;
> +int i, pmag;
>  ctx->sliced[lines].id = VBI_SLICED_TELETEXT_B;
>  ctx->sliced[lines].line = (line_offset > 0 ? (line_offset
> + (field_parity ? 0 : 313)) : 0);
>  for (i = 0; i < 42; i++)
> -ctx->sliced[lines].data[i] = vbi_rev8(buf[4 + i]);
> +p[i] = vbi_rev8(buf[4 + i]);
> +/* Unfortunately libzvbi does not expose page flags, and
> + * vbi_classify_page only checks MIP, so we have to
> manually
> + * decode the page flags and store the results. */
> +pmag = vbi_unham16p(p);
> +if (pmag >= 0 && pmag >> 3 == 0) {   // We found a row 0
> header
> +int page = vbi_unham16p(p + 2);
> +int flags1 = vbi_unham16p(p + 6);
> +int flags2 = vbi_unham16p(p + 8);
> +if (page >= 0 && flags1 >= 0 && flags2 >= 0) {
> +int pgno = ((pmag & 7) << 8) + page;
> +// Check for disabled NEWSFLASH flag and enabled
> SUBTITLE and SUPRESS_HEADER flags
> +ctx->subtitle_map[pgno] = (!(flags1 & 0x40) &&
> flags1 & 0x80 && flags2 & 0x01);
> +}
> +}
>  lines++;
>  }
>  }
> @@ -502,6 +514,7 @@ static int teletext_close_decoder(AVCodecContext
> *avctx)
>  vbi_decoder_delete(ctx->vbi);
>  ctx->vbi = NULL;
>  ctx->pts = AV_NOPTS_VALUE;
> +memset(ctx->subtitle_map, 0, sizeof(ctx->subtitle_map));
>  if (!(avctx->flags2 & AV_CODEC_FLAG2_RO_FLUSH_NOOP))
>  ctx->readorder = 0;
>  return 0;
> --
> 2.13.6
>
> ___
> ffmpeg-devel mailing list
> 

Re: [FFmpeg-devel] [PATCH] avutil/hwcontext: add flags field to AVHWFramesContext

2018-05-07 Thread Philip Langdale

On 2018-05-07 11:39, Timo Rothenpieler wrote:

---
 doc/APIchanges| 3 +++
 libavutil/hwcontext.h | 7 +++
 libavutil/version.h   | 2 +-
 3 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/doc/APIchanges b/doc/APIchanges
index ede5b186ae..307c7a51ee 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,9 @@ libavutil: 2017-10-21

 API changes, most recent first:

+2018-05-xx - xx - lavu 56.19.100 - hwcontext.h
+  Add AVHWFramesContext.flags.
+
 2018-04-xx - xx - lavu 56.18.100 - pixdesc.h
   Add AV_PIX_FMT_FLAG_ALPHA to AV_PIX_FMT_PAL8.

diff --git a/libavutil/hwcontext.h b/libavutil/hwcontext.h
index f5a4b62387..23e2d335a5 100644
--- a/libavutil/hwcontext.h
+++ b/libavutil/hwcontext.h
@@ -226,6 +226,13 @@ typedef struct AVHWFramesContext {
  * Must be set by the user before calling av_hwframe_ctx_init().
  */
 int width, height;
+
+/**
+ * Special implementation-specific flags.
+ *
+ * Must be set by the user before calling av_hwframe_ctx_init().
+ */
+int flags;
 } AVHWFramesContext;

 /**
diff --git a/libavutil/version.h b/libavutil/version.h
index 5185454d9b..84409b1d69 100644
--- a/libavutil/version.h
+++ b/libavutil/version.h
@@ -79,7 +79,7 @@
  */

 #define LIBAVUTIL_VERSION_MAJOR  56
-#define LIBAVUTIL_VERSION_MINOR  18
+#define LIBAVUTIL_VERSION_MINOR  19
 #define LIBAVUTIL_VERSION_MICRO 100

 #define LIBAVUTIL_VERSION_INT   
AV_VERSION_INT(LIBAVUTIL_VERSION_MAJOR, \


LGTM.

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


[FFmpeg-devel] [PATCH] avutil/hwcontext: add flags field to AVHWFramesContext

2018-05-07 Thread Timo Rothenpieler
---
 doc/APIchanges| 3 +++
 libavutil/hwcontext.h | 7 +++
 libavutil/version.h   | 2 +-
 3 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/doc/APIchanges b/doc/APIchanges
index ede5b186ae..307c7a51ee 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,9 @@ libavutil: 2017-10-21
 
 API changes, most recent first:
 
+2018-05-xx - xx - lavu 56.19.100 - hwcontext.h
+  Add AVHWFramesContext.flags.
+
 2018-04-xx - xx - lavu 56.18.100 - pixdesc.h
   Add AV_PIX_FMT_FLAG_ALPHA to AV_PIX_FMT_PAL8.
 
diff --git a/libavutil/hwcontext.h b/libavutil/hwcontext.h
index f5a4b62387..23e2d335a5 100644
--- a/libavutil/hwcontext.h
+++ b/libavutil/hwcontext.h
@@ -226,6 +226,13 @@ typedef struct AVHWFramesContext {
  * Must be set by the user before calling av_hwframe_ctx_init().
  */
 int width, height;
+
+/**
+ * Special implementation-specific flags.
+ *
+ * Must be set by the user before calling av_hwframe_ctx_init().
+ */
+int flags;
 } AVHWFramesContext;
 
 /**
diff --git a/libavutil/version.h b/libavutil/version.h
index 5185454d9b..84409b1d69 100644
--- a/libavutil/version.h
+++ b/libavutil/version.h
@@ -79,7 +79,7 @@
  */
 
 #define LIBAVUTIL_VERSION_MAJOR  56
-#define LIBAVUTIL_VERSION_MINOR  18
+#define LIBAVUTIL_VERSION_MINOR  19
 #define LIBAVUTIL_VERSION_MICRO 100
 
 #define LIBAVUTIL_VERSION_INT   AV_VERSION_INT(LIBAVUTIL_VERSION_MAJOR, \
-- 
2.17.0

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


Re: [FFmpeg-devel] [GSOC] [PATCH] SRCNN filter

2018-05-07 Thread Sergey Lavrushkin
2018-05-07 17:41 GMT+03:00 Pedro Arthur :

> 2018-05-07 0:30 GMT-03:00 Steven Liu :
> > Hi Sergey,
> >
> > How should i test this filter?
> > I tested it some days ago, the picture get worse from 2nd frame.
> > input resolution 640x480 to 1280x720;
> >
> > ffmpeg -i input -vf srcnn output
> Hi,
> The filter expects the input upscaled by 2x, therefore the proper
> command would be
>
> ffmpeg -i input -vf "scale=2*iw:2*ih, srcnn, scale=1280:720"
>
> The default filter is trained for 2x upscale, anything different from
> that may generate bad results.


Hi,
Moreover, the filter expects the input upscaled with bicubic upscaling, so
for other upscaling algorithms bad results are also possible.
Also other models for x2, x3, x4 upsampling can be specified using
following command:
ffmpeg -i input -vf scale=iw*factor:-1,srcnn=path_to_model
Configuration files with other models can be found here:
https://drive.google.com/drive/folders/1-M9azWTtZ4egf8ndRU7Y_tiGP6QtN-Fp?usp=sharing
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] Added the possibility to pass an externally created CUDA context to libavutil/hwcontext.c/av_hwdevice_ctx_create() for decoding with NVDEC

2018-05-07 Thread Oscar Amoros Huguet
Thanks for the tip on the push/pop solution (custom version of the ffnvcodec 
headers). It works for us, we may do as you say.

Thanks again.

Oscar

-Original Message-
From: ffmpeg-devel  On Behalf Of Timo 
Rothenpieler
Sent: Monday, May 7, 2018 1:25 PM
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH] Added the possibility to pass an externally 
created CUDA context to libavutil/hwcontext.c/av_hwdevice_ctx_create() for 
decoding with NVDEC

On 26.04.2018 18:03, Oscar Amoros Huguet wrote:
> Thanks Mark,
> 
> You are right, we can implement in our code a sort of "av_hwdevice_ctx_set" 
> (which does not exist), by using av_hwdevice_ctx_alloc() + 
> av_hwdevice_ctx_init(). We actually use av_hwdevice_ctx_alloc in our code to 
> use the feature we implemented already. We are not sure about license 
> implications though, we link dynamically to work with LGPL. I guess both 
> calls are public, since they are not in "internal" labelled files.
> 
> We are perfectly ok with using av_hwdevice_ctx_alloc() + 
> av_hwdevice_ctx_init() outside ffmpeg, to use our own CUDA context. By doing 
> so, in the current ffmpeg code, there is an internal flag " 
> AVCUDADeviceContextInternal.is_allocated" that is not set to 1, therefore, 
> the cuda context is not destroyed by ffmpeg in "cuda_device_uninit", which is 
> the desired behavior.
> 
> In fact, this flag implies that the context was not allocated by ffmpeg. 
> Maybe this is the right flag to be used to avoid push/pop pairs when the CUDA 
> context is not created by ffmpeg. What do you think?
> 
> We can adapt all of the push/pop pairs on the code, to follow this policy, 
> whichever flag is used.
> 
> About the performance effects of this push/pop calls, we have seen with 
> NVIDIA profiling tools (NSIGHT for Visual Studio plugin), that the CUDA 
> runtime detects that the context you wat to set is the same as the one 
> currently set, so the push call does nothing and lasts 0.0016 ms in average 
> (CPU time). But for some reason, the cuCtxPopCurrent call, does take some 
> more time, and uses 0.02 ms of CPU time per call. This is 0,16 ms total per 
> frame when decoding 8 feeds. This is small, but it's easy to remove. 

I'm not a fan of touching every single bit of CUDA-related code for this. 
Push/Pop, specially for the context that's already active, should be free. If 
it's not, that's something I'd complain to nvidia about.

For your specific usecase, you could build FFmpeg with a custom version of the 
ffnvcodec headers, that has a custom function for the push/pop ctx functions, 
practically noops.

> Additionally, could you give your opinion on the feature we also may want to 
> add in the future, that we mentioned in the previous email? Basically, we may 
> want to add one more CUDA function, specifically cuMemcpy2DAsync, and the 
> possibility to set a CUStream in AVCUDADeviceContext, so it is used with 
> cuMemcpy2DAsync instead of cuMemcpy2D in "nvdec_retrieve_data" in file 
> libavcodec/nvdec.c. In our use case this would save up to  0.72 ms (GPU time) 
> per frame, in case of decoding 8 fullhd frames, and up to 0.5 ms (GPU time) 
> per frame, in case of decoding two 4k frames. This may sound too little, but 
> for us is significant. Our software needs to do many things in a maximum of 
> 33ms with CUDA on the GPU per frame, and we have little GPU time left.

This is interesting and I'm considering making that the default, as it would 
fit well with the current infrastructure, delaying the sync call to the moment 
the frame leaves avcodec, which with the internal re-ordering and delay should 
give plenty of time for the copy to finish.

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


Re: [FFmpeg-devel] [PATCH] Added the possibility to pass an externally created CUDA context to libavutil/hwcontext.c/av_hwdevice_ctx_create() for decoding with NVDEC

2018-05-07 Thread Oscar Amoros Huguet
Hi!

Even if there is need to have a syncronization before leaving the ffmpeg call, 
callin cuMemcpyAsync will allow the copies to overlap with any other task on 
the gpu, that was enqueued using any other non-blocking cuda stream. That’s 
exactly what we want to achieve.

This would benefit automatically any other app that uses non-blocking cuda 
streams, as independent cuda workflows.

Oscar

Enviat des del meu iPhone

El 7 maig 2018, a les 13:54, Timo Rothenpieler  va 
escriure:

>>> Additionally, could you give your opinion on the feature we also may
> want to add in the future, that we mentioned in the previous email?
> Basically, we may want to add one more CUDA function, specifically
> cuMemcpy2DAsync, and the possibility to set a CUStream in
> AVCUDADeviceContext, so it is used with cuMemcpy2DAsync instead of
> cuMemcpy2D in "nvdec_retrieve_data" in file libavcodec/nvdec.c. In our
> use case this would save up to  0.72 ms (GPU time) per frame, in case of
> decoding 8 fullhd frames, and up to 0.5 ms (GPU time) per frame, in case
> of decoding two 4k frames. This may sound too little, but for us is
> significant. Our software needs to do many things in a maximum of 33ms
> with CUDA on the GPU per frame, and we have little GPU time left.
>> 
>> This is interesting and I'm considering making that the default, as it
>> would fit well with the current infrastructure, delaying the sync call
>> to the moment the frame leaves avcodec, which with the internal
>> re-ordering and delay should give plenty of time for the copy to finish.
> 
> I'm not sure if/how well this works with the mapped cuvid frames though.
> The frame would already be unmapped and potentially re-used again before
> the async copy completes. So it would need an immediately call to Sync
> right after the 3 async copy calls, making the entire effort pointless.
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] Added the possibility to pass an externally created CUDA context to libavutil/hwcontext.c/av_hwdevice_ctx_create() for decoding with NVDEC

2018-05-07 Thread Oscar Amoros Huguet
I was looking at the NVIDIA Video codec sdk samples 
(https://developer.nvidia.com/nvidia-video-codec-sdk#Download), where you can 
find the header NvDecoder.h next to cuviddec.h where CUVIDPROCPARAMS is defined.

Anyway, I should have looked at ffmpeg code directly, to see what’s being used, 
sorry for that.

Great then! Having the same cuda stream (either default or custom) for 
everything is the safest and most efficient way to go (in this case).

Thanks, and let me know if I can help with anything.

Oscar

> El 7 maig 2018, a les 18:43, Timo Rothenpieler  va 
> escriure:
> 
> Am 07.05.2018 um 18:25 schrieb Oscar Amoros Huguet:
>> Have a look at this, looks pretty interesting:
>> /**
>> *   @brief  This function decodes a frame and returns the locked frame 
>> buffers
>> *   This makes the buffers available for use by the application without 
>> the buffers
>> *   getting overwritten, even if subsequent decode calls are made. The 
>> frame buffers
>> *   remain locked, until ::UnlockFrame() is called
>> */
>> bool DecodeLockFrame(const uint8_t *pData, int nSize, uint8_t 
>> ***pppFrame, int *pnFrameReturned, uint32_t flags = 0, int64_t **ppTimestamp 
>> = NULL, int64_t timestamp = 0, CUstream stream = 0);
>> Oscar
> 
> I'm not sure what API docs you are referring to here.
> Google has never seen them either.
> 
> But CUVIDPROCPARAMS, which is passed to cuvidMapVideoFrame, does indeed have
> CUstream output_stream;/**< IN: stream object used by cuvidMapVideoFrame */
> So setting the stream there would be easily possible.
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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


Re: [FFmpeg-devel] Misc improvements in nlmeans filter [v2]

2018-05-07 Thread Paul B Mahol
On 5/7/18, Clement Boesch  wrote:
> Changes since v1:
>
> - fixed float operation in double as pointed out by Moritz
> - fix broken commit split as pointed out by Michael
> - added patch 10: "use unsigned for the integral patch"
> - misc instruction shuffling in AArch64 SIMD for better performances
>
> I plan to push this soon unless someone wants more time to review.
>
> BTW, x86 SIMD patch welcome, the filter badly needs some performance
> improvements. Also, any suggestion on how not to make it spend 80% of
> the time in nlmeans_slice() welcome.
>
> Regards,

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


[FFmpeg-devel] [PATCH v2 07/10] lavfi/nlmeans: switch from double to float

2018-05-07 Thread Clément Bœsch
Overall speed appears to be 1.1x faster with no noticeable quality
impact.
---
 libavfilter/vf_nlmeans.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/libavfilter/vf_nlmeans.c b/libavfilter/vf_nlmeans.c
index f37f1183f7..aba587f46b 100644
--- a/libavfilter/vf_nlmeans.c
+++ b/libavfilter/vf_nlmeans.c
@@ -40,8 +40,8 @@
 #include "video.h"
 
 struct weighted_avg {
-double total_weight;
-double sum;
+float total_weight;
+float sum;
 };
 
 #define WEIGHT_LUT_NBITS 9
@@ -63,8 +63,8 @@ typedef struct NLMeansContext {
 ptrdiff_t ii_lz_32; // linesize in 32-bit units of 
the integral image
 struct weighted_avg *wa;// weighted average of every 
pixel
 ptrdiff_t wa_linesize;  // linesize for wa in struct 
size unit
-double weight_lut[WEIGHT_LUT_SIZE]; // lookup table mapping 
(scaled) patch differences to their associated weights
-double pdiff_lut_scale; // scale factor for patch 
differences before looking into the LUT
+float weight_lut[WEIGHT_LUT_SIZE];  // lookup table mapping 
(scaled) patch differences to their associated weights
+float pdiff_lut_scale;  // scale factor for patch 
differences before looking into the LUT
 int max_meaningful_diff;// maximum difference 
considered (if the patch difference is too high we ignore the pixel)
 NLMeansDSPContext dsp;
 } NLMeansContext;
@@ -402,7 +402,7 @@ static int nlmeans_slice(AVFilterContext *ctx, void *arg, 
int jobnr, int nb_jobs
 const int patch_diff_sq = get_integral_patch_value(td->ii_start, 
s->ii_lz_32, x, y, td->p);
 if (patch_diff_sq < s->max_meaningful_diff) {
 const int weight_lut_idx = patch_diff_sq * s->pdiff_lut_scale;
-const double weight = s->weight_lut[weight_lut_idx]; // 
exp(-patch_diff_sq * s->pdiff_scale)
+const float weight = s->weight_lut[weight_lut_idx]; // 
exp(-patch_diff_sq * s->pdiff_scale)
 wa[x].total_weight += weight;
 wa[x].sum += weight * src[x];
 }
@@ -453,8 +453,8 @@ static int nlmeans_plane(AVFilterContext *ctx, int w, int 
h, int p, int r,
 struct weighted_avg *wa = >wa[y*s->wa_linesize + x];
 
 // Also weight the centered pixel
-wa->total_weight += 1.0;
-wa->sum += 1.0 * src[y*src_linesize + x];
+wa->total_weight += 1.f;
+wa->sum += 1.f * src[y*src_linesize + x];
 
 dst[y*dst_linesize + x] = av_clip_uint8(wa->sum / 
wa->total_weight);
 }
-- 
2.17.0

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


[FFmpeg-devel] [PATCH v2 10/10] lavfi/nlmeans: use unsigned for the integral patch value

2018-05-07 Thread Clément Bœsch
This value can not be negative.
---
 libavfilter/vf_nlmeans.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/libavfilter/vf_nlmeans.c b/libavfilter/vf_nlmeans.c
index 22d26a12e3..547cb80acd 100644
--- a/libavfilter/vf_nlmeans.c
+++ b/libavfilter/vf_nlmeans.c
@@ -64,7 +64,7 @@ typedef struct NLMeansContext {
 ptrdiff_t wa_linesize;  // linesize for wa in struct 
size unit
 float weight_lut[WEIGHT_LUT_SIZE];  // lookup table mapping 
(scaled) patch differences to their associated weights
 float pdiff_lut_scale;  // scale factor for patch 
differences before looking into the LUT
-int max_meaningful_diff;// maximum difference 
considered (if the patch difference is too high we ignore the pixel)
+uint32_t max_meaningful_diff;   // maximum difference 
considered (if the patch difference is too high we ignore the pixel)
 NLMeansDSPContext dsp;
 } NLMeansContext;
 
@@ -129,12 +129,12 @@ static int query_formats(AVFilterContext *ctx)
  * contains the sum of the squared difference of every corresponding pixels of
  * two input planes of the same size as M.
  */
-static inline int get_integral_patch_value(const uint32_t *ii, int ii_lz_32, 
int x, int y, int p)
+static inline uint32_t get_integral_patch_value(const uint32_t *ii, int 
ii_lz_32, int x, int y, int p)
 {
-const int a = ii[(y - p - 1) * ii_lz_32 + (x - p - 1)];
-const int b = ii[(y - p - 1) * ii_lz_32 + (x + p)];
-const int d = ii[(y + p) * ii_lz_32 + (x - p - 1)];
-const int e = ii[(y + p) * ii_lz_32 + (x + p)];
+const uint32_t a = ii[(y - p - 1) * ii_lz_32 + (x - p - 1)];
+const uint32_t b = ii[(y - p - 1) * ii_lz_32 + (x + p)];
+const uint32_t d = ii[(y + p) * ii_lz_32 + (x - p - 1)];
+const uint32_t e = ii[(y + p) * ii_lz_32 + (x + p)];
 return e - d - b + a;
 }
 
@@ -398,9 +398,9 @@ static int nlmeans_slice(AVFilterContext *ctx, void *arg, 
int jobnr, int nb_jobs
 const uint8_t *src = td->src + y*src_linesize;
 struct weighted_avg *wa = s->wa + y*s->wa_linesize;
 for (x = td->startx; x < td->endx; x++) {
-const int patch_diff_sq = get_integral_patch_value(td->ii_start, 
s->ii_lz_32, x, y, td->p);
+const uint32_t patch_diff_sq = 
get_integral_patch_value(td->ii_start, s->ii_lz_32, x, y, td->p);
 if (patch_diff_sq < s->max_meaningful_diff) {
-const int weight_lut_idx = patch_diff_sq * s->pdiff_lut_scale;
+const unsigned weight_lut_idx = patch_diff_sq * 
s->pdiff_lut_scale;
 const float weight = s->weight_lut[weight_lut_idx]; // 
exp(-patch_diff_sq * s->pdiff_scale)
 wa[x].total_weight += weight;
 wa[x].sum += weight * src[x];
-- 
2.17.0

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


[FFmpeg-devel] [PATCH v2 08/10] lavfi/nlmeans: move final weighted averaging out of nlmeans_plane

2018-05-07 Thread Clément Bœsch
This helps figuring out where the filter is slow:

  70.53%  ffmpeg_g  ffmpeg_g  [.] nlmeans_slice
  25.73%  ffmpeg_g  ffmpeg_g  [.] compute_safe_ssd_integral_image_c
   1.74%  ffmpeg_g  ffmpeg_g  [.] compute_unsafe_ssd_integral_image
   0.82%  ffmpeg_g  ffmpeg_g  [.] ff_mjpeg_decode_sos
   0.51%  ffmpeg_g  [unknown] [k] 0x91800a80
   0.24%  ffmpeg_g  ffmpeg_g  [.] weight_averages

(Tested with a large image that takes several seconds to process)

Since this function is irrelevant speed wise, the file's TODO is
updated.
---
 libavfilter/vf_nlmeans.c | 33 ++---
 1 file changed, 22 insertions(+), 11 deletions(-)

diff --git a/libavfilter/vf_nlmeans.c b/libavfilter/vf_nlmeans.c
index aba587f46b..72a75a6e7a 100644
--- a/libavfilter/vf_nlmeans.c
+++ b/libavfilter/vf_nlmeans.c
@@ -20,7 +20,6 @@
 
 /**
  * @todo
- * - SIMD for final weighted averaging
  * - better automatic defaults? see "Parameters" @ 
http://www.ipol.im/pub/art/2011/bcm_nlm/
  * - temporal support (probably doesn't need any displacement according to
  *   "Denoising image sequences does not require motion estimation")
@@ -411,11 +410,30 @@ static int nlmeans_slice(AVFilterContext *ctx, void *arg, 
int jobnr, int nb_jobs
 return 0;
 }
 
+static void weight_averages(uint8_t *dst, ptrdiff_t dst_linesize,
+const uint8_t *src, ptrdiff_t src_linesize,
+struct weighted_avg *wa, ptrdiff_t wa_linesize,
+int w, int h)
+{
+int x, y;
+
+for (y = 0; y < h; y++) {
+for (x = 0; x < w; x++) {
+// Also weight the centered pixel
+wa[x].total_weight += 1.f;
+wa[x].sum += 1.f * src[x];
+dst[x] = av_clip_uint8(wa[x].sum / wa[x].total_weight);
+}
+dst += dst_linesize;
+src += src_linesize;
+wa += wa_linesize;
+}
+}
+
 static int nlmeans_plane(AVFilterContext *ctx, int w, int h, int p, int r,
  uint8_t *dst, ptrdiff_t dst_linesize,
  const uint8_t *src, ptrdiff_t src_linesize)
 {
-int x, y;
 int offx, offy;
 NLMeansContext *s = ctx->priv;
 /* patches center points cover the whole research window so the patches
@@ -448,17 +466,10 @@ static int nlmeans_plane(AVFilterContext *ctx, int w, int 
h, int p, int r,
 }
 }
 }
-for (y = 0; y < h; y++) {
-for (x = 0; x < w; x++) {
-struct weighted_avg *wa = >wa[y*s->wa_linesize + x];
 
-// Also weight the centered pixel
-wa->total_weight += 1.f;
-wa->sum += 1.f * src[y*src_linesize + x];
+weight_averages(dst, dst_linesize, src, src_linesize,
+s->wa, s->wa_linesize, w, h);
 
-dst[y*dst_linesize + x] = av_clip_uint8(wa->sum / 
wa->total_weight);
-}
-}
 return 0;
 }
 
-- 
2.17.0

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


[FFmpeg-devel] [PATCH v2 09/10] lavfi/nlmeans: reorder memory accesses in get_integral_patch_value

2018-05-07 Thread Clément Bœsch
This doesn't seem to make much of a difference but it can't hurt.
---
 libavfilter/vf_nlmeans.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/libavfilter/vf_nlmeans.c b/libavfilter/vf_nlmeans.c
index 72a75a6e7a..22d26a12e3 100644
--- a/libavfilter/vf_nlmeans.c
+++ b/libavfilter/vf_nlmeans.c
@@ -131,10 +131,10 @@ static int query_formats(AVFilterContext *ctx)
  */
 static inline int get_integral_patch_value(const uint32_t *ii, int ii_lz_32, 
int x, int y, int p)
 {
-const int e = ii[(y + p) * ii_lz_32 + (x + p)];
-const int d = ii[(y + p) * ii_lz_32 + (x - p - 1)];
-const int b = ii[(y - p - 1) * ii_lz_32 + (x + p)];
 const int a = ii[(y - p - 1) * ii_lz_32 + (x - p - 1)];
+const int b = ii[(y - p - 1) * ii_lz_32 + (x + p)];
+const int d = ii[(y + p) * ii_lz_32 + (x - p - 1)];
+const int e = ii[(y + p) * ii_lz_32 + (x + p)];
 return e - d - b + a;
 }
 
-- 
2.17.0

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


[FFmpeg-devel] [PATCH v2 06/10] lavfi/nlmeans: make compute_safe_ssd_integral_image_c faster

2018-05-07 Thread Clément Bœsch
before:  ssd_integral_image_c: 49204.6
after:   ssd_integral_image_c: 44272.8

Unrolling by 4 for made the biggest different on odroid-c2 (aarch64);
unrolling by 2 or 8 both raised 46k cycles vs 44k for 4.

Additionally, this is a much better reference when writing SIMD (SIMD
vectorization will just target 16 instead of 4).
---
 libavfilter/vf_nlmeans.c | 27 +--
 1 file changed, 17 insertions(+), 10 deletions(-)

diff --git a/libavfilter/vf_nlmeans.c b/libavfilter/vf_nlmeans.c
index c30e44498f..f37f1183f7 100644
--- a/libavfilter/vf_nlmeans.c
+++ b/libavfilter/vf_nlmeans.c
@@ -146,10 +146,6 @@ static inline int get_integral_patch_value(const uint32_t 
*ii, int ii_lz_32, int
  * function, we do not need any clipping here.
  *
  * The line above dst and the column to its left are always readable.
- *
- * This C version computes the SSD integral image using a scalar accumulator,
- * while for SIMD implementation it is likely more interesting to use the
- * two-loops algorithm variant.
  */
 static void compute_safe_ssd_integral_image_c(uint32_t *dst, ptrdiff_t 
dst_linesize_32,
   const uint8_t *s1, ptrdiff_t 
linesize1,
@@ -157,21 +153,32 @@ static void compute_safe_ssd_integral_image_c(uint32_t 
*dst, ptrdiff_t dst_lines
   int w, int h)
 {
 int x, y;
+const uint32_t *dst_top = dst - dst_linesize_32;
 
 /* SIMD-friendly assumptions allowed here */
 av_assert2(!(w & 0xf) && w >= 16 && h >= 1);
 
 for (y = 0; y < h; y++) {
-uint32_t acc = dst[-1] - dst[-dst_linesize_32 - 1];
-
-for (x = 0; x < w; x++) {
-const int d  = s1[x] - s2[x];
-acc += d * d;
-dst[x] = dst[-dst_linesize_32 + x] + acc;
+for (x = 0; x < w; x += 4) {
+const int d0 = s1[x] - s2[x];
+const int d1 = s1[x + 1] - s2[x + 1];
+const int d2 = s1[x + 2] - s2[x + 2];
+const int d3 = s1[x + 3] - s2[x + 3];
+
+dst[x] = dst_top[x] - dst_top[x - 1] + d0*d0;
+dst[x + 1] = dst_top[x + 1] - dst_top[x] + d1*d1;
+dst[x + 2] = dst_top[x + 2] - dst_top[x + 1] + d2*d2;
+dst[x + 3] = dst_top[x + 3] - dst_top[x + 2] + d3*d3;
+
+dst[x] += dst[x - 1];
+dst[x + 1] += dst[x];
+dst[x + 2] += dst[x + 1];
+dst[x + 3] += dst[x + 2];
 }
 s1  += linesize1;
 s2  += linesize2;
 dst += dst_linesize_32;
+dst_top += dst_linesize_32;
 }
 }
 
-- 
2.17.0

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


[FFmpeg-devel] [PATCH v2 05/10] checkasm: add vf_nlmeans test for ssd_integral_image

2018-05-07 Thread Clément Bœsch
---
 tests/checkasm/Makefile |   1 +
 tests/checkasm/checkasm.c   |   3 +
 tests/checkasm/checkasm.h   |   1 +
 tests/checkasm/vf_nlmeans.c | 113 
 4 files changed, 118 insertions(+)
 create mode 100644 tests/checkasm/vf_nlmeans.c

diff --git a/tests/checkasm/Makefile b/tests/checkasm/Makefile
index 0233d2f989..9484acbbd7 100644
--- a/tests/checkasm/Makefile
+++ b/tests/checkasm/Makefile
@@ -35,6 +35,7 @@ AVFILTEROBJS-$(CONFIG_BLEND_FILTER) += vf_blend.o
 AVFILTEROBJS-$(CONFIG_COLORSPACE_FILTER) += vf_colorspace.o
 AVFILTEROBJS-$(CONFIG_HFLIP_FILTER)  += vf_hflip.o
 AVFILTEROBJS-$(CONFIG_THRESHOLD_FILTER)  += vf_threshold.o
+AVFILTEROBJS-$(CONFIG_NLMEANS_FILTER)+= vf_nlmeans.o
 
 CHECKASMOBJS-$(CONFIG_AVFILTER) += $(AVFILTEROBJS-yes)
 
diff --git a/tests/checkasm/checkasm.c b/tests/checkasm/checkasm.c
index ba1d1d0253..721a0912fb 100644
--- a/tests/checkasm/checkasm.c
+++ b/tests/checkasm/checkasm.c
@@ -159,6 +159,9 @@ static const struct {
 #if CONFIG_HFLIP_FILTER
 { "vf_hflip", checkasm_check_vf_hflip },
 #endif
+#if CONFIG_NLMEANS_FILTER
+{ "vf_nlmeans", checkasm_check_nlmeans },
+#endif
 #if CONFIG_THRESHOLD_FILTER
 { "vf_threshold", checkasm_check_vf_threshold },
 #endif
diff --git a/tests/checkasm/checkasm.h b/tests/checkasm/checkasm.h
index dcab74de06..c45cfb46f8 100644
--- a/tests/checkasm/checkasm.h
+++ b/tests/checkasm/checkasm.h
@@ -62,6 +62,7 @@ void checkasm_check_huffyuvdsp(void);
 void checkasm_check_jpeg2000dsp(void);
 void checkasm_check_llviddsp(void);
 void checkasm_check_llviddspenc(void);
+void checkasm_check_nlmeans(void);
 void checkasm_check_pixblockdsp(void);
 void checkasm_check_sbrdsp(void);
 void checkasm_check_synth_filter(void);
diff --git a/tests/checkasm/vf_nlmeans.c b/tests/checkasm/vf_nlmeans.c
new file mode 100644
index 00..5e2c934226
--- /dev/null
+++ b/tests/checkasm/vf_nlmeans.c
@@ -0,0 +1,113 @@
+/*
+ * Copyright (c) 2018 Clément Bœsch 
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "checkasm.h"
+#include "libavfilter/vf_nlmeans.h"
+#include "libavutil/avassert.h"
+
+#define randomize_buffer(buf, size) do {\
+int i;  \
+for (i = 0; i < size / 4; i++)  \
+((uint32_t *)buf)[i] = rnd();   \
+} while (0)
+
+void checkasm_check_nlmeans(void)
+{
+NLMeansDSPContext dsp = {0};
+
+const int w = 123;  // source width
+const int h = 45;   // source height
+const int p = 3;// patch half size
+const int r = 2;// research window half size
+
+ff_nlmeans_init();
+
+/* See the filter's code for the explanations on the variables */
+if (check_func(dsp.compute_safe_ssd_integral_image, "ssd_integral_image")) 
{
+int offx, offy;
+const int e = p + r;
+const int ii_w = w + e*2;
+const int ii_h = h + e*2;
+const int ii_lz_32 = FFALIGN(ii_w + 1, 4);
+uint32_t *ii_orig_ref = av_mallocz_array(ii_h + 1, ii_lz_32 * 
sizeof(*ii_orig_ref));
+uint32_t *ii_ref = ii_orig_ref + ii_lz_32 + 1;
+uint32_t *ii_orig_new = av_mallocz_array(ii_h + 1, ii_lz_32 * 
sizeof(*ii_orig_new));
+uint32_t *ii_new = ii_orig_new + ii_lz_32 + 1;
+const int src_lz = FFALIGN(w, 16);
+uint8_t *src = av_mallocz_array(h, src_lz);
+
+declare_func(void, uint32_t *dst, ptrdiff_t dst_linesize_32,
+ const uint8_t *s1, ptrdiff_t linesize1,
+ const uint8_t *s2, ptrdiff_t linesize2,
+ int w, int h);
+
+randomize_buffer(src, h * src_lz);
+
+for (offy = -r; offy <= r; offy++) {
+for (offx = -r; offx <= r; offx++) {
+if (offx || offy) {
+const int s1x = e;
+const int s1y = e;
+const int s2x = e + offx;
+const int s2y = e + offy;
+const int startx_safe = FFMAX(s1x, s2x);
+const int starty_safe = FFMAX(s1y, s2y);
+const int u_endx_safe = FFMIN(s1x + w, s2x + w);
+const int endy_safe   = FFMIN(s1y + h, s2y + h);
+const int safe_pw = 

[FFmpeg-devel] [PATCH v2 02/10] lavfi/nlmeans: add SIMD-friendly assumptions for compute_safe_ssd_integral_image

2018-05-07 Thread Clément Bœsch
SIMD code will not have to deal with padding itself. Overwriting in that
function may have been possible but involve large overreading of the
sources. Instead, we simply make sure the width to process is always a
multiple of 16. Additionally, there must be some actual area to process
so the SIMD code can have its boundary checks after processing the first
pixels.
---
 libavfilter/vf_nlmeans.c | 25 ++---
 1 file changed, 18 insertions(+), 7 deletions(-)

diff --git a/libavfilter/vf_nlmeans.c b/libavfilter/vf_nlmeans.c
index d222d3913e..3f0a43ee72 100644
--- a/libavfilter/vf_nlmeans.c
+++ b/libavfilter/vf_nlmeans.c
@@ -157,6 +157,9 @@ static void compute_safe_ssd_integral_image_c(uint32_t 
*dst, int dst_linesize_32
 {
 int x, y;
 
+/* SIMD-friendly assumptions allowed here */
+av_assert2(!(w & 0xf) && w >= 16 && h >= 1);
+
 for (y = 0; y < h; y++) {
 uint32_t acc = dst[-1] - dst[-dst_linesize_32 - 1];
 
@@ -257,9 +260,16 @@ static void compute_ssd_integral_image(uint32_t *ii, int 
ii_linesize_32,
 // to compare the 2 sources pixels
 const int startx_safe = FFMAX(s1x, s2x);
 const int starty_safe = FFMAX(s1y, s2y);
-const int endx_safe   = FFMIN(s1x + w, s2x + w);
+const int u_endx_safe = FFMIN(s1x + w, s2x + w); // unaligned
 const int endy_safe   = FFMIN(s1y + h, s2y + h);
 
+// deduce the safe area width and height
+const int safe_pw = (u_endx_safe - startx_safe) & ~0xf;
+const int safe_ph = endy_safe - starty_safe;
+
+// adjusted end x position of the safe area after width of the safe area 
gets aligned
+const int endx_safe = startx_safe + safe_pw;
+
 // top part where only one of s1 and s2 is still readable, or none at all
 compute_unsafe_ssd_integral_image(ii, ii_linesize_32,
   0, 0,
@@ -273,24 +283,25 @@ static void compute_ssd_integral_image(uint32_t *ii, int 
ii_linesize_32,
   0, starty_safe,
   src, linesize,
   offx, offy, e, w, h,
-  startx_safe, endy_safe - starty_safe);
+  startx_safe, safe_ph);
 
 // main and safe part of the integral
 av_assert1(startx_safe - s1x >= 0); av_assert1(startx_safe - s1x < w);
 av_assert1(starty_safe - s1y >= 0); av_assert1(starty_safe - s1y < h);
 av_assert1(startx_safe - s2x >= 0); av_assert1(startx_safe - s2x < w);
 av_assert1(starty_safe - s2y >= 0); av_assert1(starty_safe - s2y < h);
-compute_safe_ssd_integral_image_c(ii + starty_safe*ii_linesize_32 + 
startx_safe, ii_linesize_32,
-  src + (starty_safe - s1y) * linesize + 
(startx_safe - s1x), linesize,
-  src + (starty_safe - s2y) * linesize + 
(startx_safe - s2x), linesize,
-  endx_safe - startx_safe, endy_safe - 
starty_safe);
+if (safe_pw && safe_ph)
+compute_safe_ssd_integral_image_c(ii + starty_safe*ii_linesize_32 + 
startx_safe, ii_linesize_32,
+  src + (starty_safe - s1y) * linesize 
+ (startx_safe - s1x), linesize,
+  src + (starty_safe - s2y) * linesize 
+ (startx_safe - s2x), linesize,
+  safe_pw, safe_ph);
 
 // right part of the integral
 compute_unsafe_ssd_integral_image(ii, ii_linesize_32,
   endx_safe, starty_safe,
   src, linesize,
   offx, offy, e, w, h,
-  ii_w - endx_safe, endy_safe - 
starty_safe);
+  ii_w - endx_safe, safe_ph);
 
 // bottom part where only one of s1 and s2 is still readable, or none at 
all
 compute_unsafe_ssd_integral_image(ii, ii_linesize_32,
-- 
2.17.0

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


[FFmpeg-devel] [PATCH v2 04/10] lavfi/nlmeans: add AArch64 SIMD for compute_safe_ssd_integral_image

2018-05-07 Thread Clément Bœsch
ssd_integral_image_c: 49204.6
ssd_integral_image_neon: 28346.8
---
 libavfilter/aarch64/Makefile  |  3 +
 libavfilter/aarch64/vf_nlmeans_init.c | 33 +++
 libavfilter/aarch64/vf_nlmeans_neon.S | 80 +++
 libavfilter/vf_nlmeans.c  | 26 ++---
 libavfilter/vf_nlmeans.h  | 35 
 5 files changed, 170 insertions(+), 7 deletions(-)
 create mode 100644 libavfilter/aarch64/Makefile
 create mode 100644 libavfilter/aarch64/vf_nlmeans_init.c
 create mode 100644 libavfilter/aarch64/vf_nlmeans_neon.S
 create mode 100644 libavfilter/vf_nlmeans.h

diff --git a/libavfilter/aarch64/Makefile b/libavfilter/aarch64/Makefile
new file mode 100644
index 00..b58daa3a3f
--- /dev/null
+++ b/libavfilter/aarch64/Makefile
@@ -0,0 +1,3 @@
+OBJS-$(CONFIG_NLMEANS_FILTER)+= aarch64/vf_nlmeans_init.o
+
+NEON-OBJS-$(CONFIG_NLMEANS_FILTER)   += aarch64/vf_nlmeans_neon.o
diff --git a/libavfilter/aarch64/vf_nlmeans_init.c 
b/libavfilter/aarch64/vf_nlmeans_init.c
new file mode 100644
index 00..a1edefb144
--- /dev/null
+++ b/libavfilter/aarch64/vf_nlmeans_init.c
@@ -0,0 +1,33 @@
+/*
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/aarch64/cpu.h"
+#include "libavfilter/vf_nlmeans.h"
+
+void ff_compute_safe_ssd_integral_image_neon(uint32_t *dst, ptrdiff_t 
dst_linesize_32,
+ const uint8_t *s1, ptrdiff_t 
linesize1,
+ const uint8_t *s2, ptrdiff_t 
linesize2,
+ int w, int h);
+
+av_cold void ff_nlmeans_init_aarch64(NLMeansDSPContext *dsp)
+{
+int cpu_flags = av_get_cpu_flags();
+
+if (have_neon(cpu_flags))
+dsp->compute_safe_ssd_integral_image = 
ff_compute_safe_ssd_integral_image_neon;
+}
diff --git a/libavfilter/aarch64/vf_nlmeans_neon.S 
b/libavfilter/aarch64/vf_nlmeans_neon.S
new file mode 100644
index 00..6308a428db
--- /dev/null
+++ b/libavfilter/aarch64/vf_nlmeans_neon.S
@@ -0,0 +1,80 @@
+/*
+ * Copyright (c) 2018 Clément Bœsch 
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/aarch64/asm.S"
+
+// acc_sum_store(ABCD) = {X+A, X+A+B, X+A+B+C, X+A+B+C+D}
+.macro acc_sum_store x, xb
+dup v24.4S, v24.4S[3]   // 
...X -> 
+ext v25.16B, v26.16B, \xb, #12  // 
ext(,ABCD,12)=0ABC
+add v24.4S, v24.4S, \x  // 
+ABCD={X+A,X+B,X+C,X+D}
+add v24.4S, v24.4S, v25.4S  // 
{X+A,X+B+A,X+C+B,X+D+C}   (+0ABC)
+ext v25.16B, v26.16B, v25.16B, #12  // 
ext(,0ABC,12)=00AB
+add v24.4S, v24.4S, v25.4S  // 
{X+A,X+B+A,X+C+B+A,X+D+C+B}   (+00AB)
+ext v25.16B, v26.16B, v25.16B, #12  // 
ext(,00AB,12)=000A
+add v24.4S, v24.4S, v25.4S  // 
{X+A,X+B+A,X+C+B+A,X+D+C+B+A} (+000A)
+st1 {v24.4S}, [x0], #16 // 
write 4x32-bit final values
+.endm
+
+function ff_compute_safe_ssd_integral_image_neon, export=1
+moviv26.4S, #0  // 
used as zero for the "rotations" in acc_sum_store
+sub x3, x3, w6, UXTW// s1 
padding (s1_linesize - 

[FFmpeg-devel] [PATCH v2 03/10] lavfi/nlmeans: use ptrdiff_t for linesizes

2018-05-07 Thread Clément Bœsch
Similarly to previous commit, this will help writing SIMD code by not
having manual zero-extension in SIMD code
---
 libavfilter/vf_nlmeans.c | 26 +-
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/libavfilter/vf_nlmeans.c b/libavfilter/vf_nlmeans.c
index 3f0a43ee72..b081a4e5af 100644
--- a/libavfilter/vf_nlmeans.c
+++ b/libavfilter/vf_nlmeans.c
@@ -60,9 +60,9 @@ typedef struct NLMeansContext {
 uint32_t *ii_orig;  // integral image
 uint32_t *ii;   // integral image starting 
after the 0-line and 0-column
 int ii_w, ii_h; // width and height of the 
integral image
-int ii_lz_32;   // linesize in 32-bit units of 
the integral image
+ptrdiff_t ii_lz_32; // linesize in 32-bit units of 
the integral image
 struct weighted_avg *wa;// weighted average of every 
pixel
-int wa_linesize;// linesize for wa in struct 
size unit
+ptrdiff_t wa_linesize;  // linesize for wa in struct 
size unit
 double weight_lut[WEIGHT_LUT_SIZE]; // lookup table mapping 
(scaled) patch differences to their associated weights
 double pdiff_lut_scale; // scale factor for patch 
differences before looking into the LUT
 int max_meaningful_diff;// maximum difference 
considered (if the patch difference is too high we ignore the pixel)
@@ -150,9 +150,9 @@ static inline int get_integral_patch_value(const uint32_t 
*ii, int ii_lz_32, int
  * while for SIMD implementation it is likely more interesting to use the
  * two-loops algorithm variant.
  */
-static void compute_safe_ssd_integral_image_c(uint32_t *dst, int 
dst_linesize_32,
-  const uint8_t *s1, int linesize1,
-  const uint8_t *s2, int linesize2,
+static void compute_safe_ssd_integral_image_c(uint32_t *dst, ptrdiff_t 
dst_linesize_32,
+  const uint8_t *s1, ptrdiff_t 
linesize1,
+  const uint8_t *s2, ptrdiff_t 
linesize2,
   int w, int h)
 {
 int x, y;
@@ -198,9 +198,9 @@ static void compute_safe_ssd_integral_image_c(uint32_t 
*dst, int dst_linesize_32
  * @param w width to compute
  * @param h height to compute
  */
-static inline void compute_unsafe_ssd_integral_image(uint32_t *dst, int 
dst_linesize_32,
+static inline void compute_unsafe_ssd_integral_image(uint32_t *dst, ptrdiff_t 
dst_linesize_32,
  int startx, int starty,
- const uint8_t *src, int 
linesize,
+ const uint8_t *src, 
ptrdiff_t linesize,
  int offx, int offy, int 
r, int sw, int sh,
  int w, int h)
 {
@@ -240,8 +240,8 @@ static inline void 
compute_unsafe_ssd_integral_image(uint32_t *dst, int dst_line
  * @param h source height
  * @param e research padding edge
  */
-static void compute_ssd_integral_image(uint32_t *ii, int ii_linesize_32,
-   const uint8_t *src, int linesize, int 
offx, int offy,
+static void compute_ssd_integral_image(uint32_t *ii, ptrdiff_t ii_linesize_32,
+   const uint8_t *src, ptrdiff_t linesize, 
int offx, int offy,
int e, int w, int h)
 {
 // ii has a surrounding padding of thickness "e"
@@ -367,7 +367,7 @@ static int config_input(AVFilterLink *inlink)
 
 struct thread_data {
 const uint8_t *src;
-int src_linesize;
+ptrdiff_t src_linesize;
 int startx, starty;
 int endx, endy;
 const uint32_t *ii_start;
@@ -379,7 +379,7 @@ static int nlmeans_slice(AVFilterContext *ctx, void *arg, 
int jobnr, int nb_jobs
 int x, y;
 NLMeansContext *s = ctx->priv;
 const struct thread_data *td = arg;
-const int src_linesize = td->src_linesize;
+const ptrdiff_t src_linesize = td->src_linesize;
 const int process_h = td->endy - td->starty;
 const int slice_start = (process_h *  jobnr   ) / nb_jobs;
 const int slice_end   = (process_h * (jobnr+1)) / nb_jobs;
@@ -403,8 +403,8 @@ static int nlmeans_slice(AVFilterContext *ctx, void *arg, 
int jobnr, int nb_jobs
 }
 
 static int nlmeans_plane(AVFilterContext *ctx, int w, int h, int p, int r,
- uint8_t *dst, int dst_linesize,
- const uint8_t *src, int src_linesize)
+ uint8_t *dst, ptrdiff_t dst_linesize,
+ const uint8_t *src, ptrdiff_t 

[FFmpeg-devel] [PATCH v2 01/10] lavfi/nlmeans: random code shuffling to help compiler

2018-05-07 Thread Clément Bœsch
This makes nlmeans_slice() slightly faster at least on GCC 7.3.
---
 libavfilter/vf_nlmeans.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/libavfilter/vf_nlmeans.c b/libavfilter/vf_nlmeans.c
index e4952e187e..d222d3913e 100644
--- a/libavfilter/vf_nlmeans.c
+++ b/libavfilter/vf_nlmeans.c
@@ -368,7 +368,6 @@ static int nlmeans_slice(AVFilterContext *ctx, void *arg, 
int jobnr, int nb_jobs
 int x, y;
 NLMeansContext *s = ctx->priv;
 const struct thread_data *td = arg;
-const uint8_t *src = td->src;
 const int src_linesize = td->src_linesize;
 const int process_h = td->endy - td->starty;
 const int slice_start = (process_h *  jobnr   ) / nb_jobs;
@@ -377,14 +376,15 @@ static int nlmeans_slice(AVFilterContext *ctx, void *arg, 
int jobnr, int nb_jobs
 const int endy   = td->starty + slice_end;
 
 for (y = starty; y < endy; y++) {
+const uint8_t *src = td->src + y*src_linesize;
+struct weighted_avg *wa = s->wa + y*s->wa_linesize;
 for (x = td->startx; x < td->endx; x++) {
 const int patch_diff_sq = get_integral_patch_value(td->ii_start, 
s->ii_lz_32, x, y, td->p);
 if (patch_diff_sq < s->max_meaningful_diff) {
-struct weighted_avg *wa = >wa[y*s->wa_linesize + x];
 const int weight_lut_idx = patch_diff_sq * s->pdiff_lut_scale;
 const double weight = s->weight_lut[weight_lut_idx]; // 
exp(-patch_diff_sq * s->pdiff_scale)
-wa->total_weight += weight;
-wa->sum += weight * src[y*src_linesize + x];
+wa[x].total_weight += weight;
+wa[x].sum += weight * src[x];
 }
 }
 }
-- 
2.17.0

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


[FFmpeg-devel] Misc improvements in nlmeans filter [v2]

2018-05-07 Thread Clément Bœsch
Changes since v1:

- fixed float operation in double as pointed out by Moritz
- fix broken commit split as pointed out by Michael
- added patch 10: "use unsigned for the integral patch"
- misc instruction shuffling in AArch64 SIMD for better performances

I plan to push this soon unless someone wants more time to review.

BTW, x86 SIMD patch welcome, the filter badly needs some performance
improvements. Also, any suggestion on how not to make it spend 80% of
the time in nlmeans_slice() welcome.

Regards,


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


Re: [FFmpeg-devel] [PATCH] avformat/segafilmenc - set keyframe bit correctly

2018-05-07 Thread Gyan Doshi



On 5/6/2018 10:23 AM, Gyan Doshi wrote:



On 5/6/2018 4:39 AM, James Almer wrote:

On 5/5/2018 8:06 PM, Michael Niedermayer wrote:

On Sat, May 05, 2018 at 05:16:09PM +0530, Gyan Doshi wrote:

Since the muxer author hasn't made the change, the patch is submitted.

Reference:

http://www.ffmpeg.org/pipermail/ffmpeg-devel/2018-April/228602.html




A micro bump should be enough.


Micro version bumped.


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


Re: [FFmpeg-devel] [PATCH] Added the possibility to pass an externally created CUDA context to libavutil/hwcontext.c/av_hwdevice_ctx_create() for decoding with NVDEC

2018-05-07 Thread Timo Rothenpieler

Am 07.05.2018 um 18:25 schrieb Oscar Amoros Huguet:

Have a look at this, looks pretty interesting:

/**
 *   @brief  This function decodes a frame and returns the locked frame 
buffers
 *   This makes the buffers available for use by the application without 
the buffers
 *   getting overwritten, even if subsequent decode calls are made. The 
frame buffers
 *   remain locked, until ::UnlockFrame() is called
 */
 bool DecodeLockFrame(const uint8_t *pData, int nSize, uint8_t ***pppFrame, 
int *pnFrameReturned, uint32_t flags = 0, int64_t **ppTimestamp = NULL, int64_t 
timestamp = 0, CUstream stream = 0);

Oscar


I'm not sure what API docs you are referring to here.
Google has never seen them either.

But CUVIDPROCPARAMS, which is passed to cuvidMapVideoFrame, does indeed have
CUstream output_stream;/**< IN: stream object used by cuvidMapVideoFrame */
So setting the stream there would be easily possible.



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] libavutil/encryption_info: Allow multiple init info.

2018-05-07 Thread Jacob Trimble
On Fri, Apr 27, 2018 at 5:30 PM, Jacob Trimble  wrote:
> On Fri, Apr 27, 2018 at 10:33 AM, Jacob Trimble  wrote:
>> On Mon, Apr 23, 2018 at 11:03 AM, Jacob Trimble  wrote:
>>> While integrating my encryption info changes, I noticed a problem with
>>> the init info structs.  I implemented them as side-data on the Stream.
>>> But this means there can only be one per stream.  However, there can
>>> be multiple 'pssh' atoms in a single stream (e.g. for key rotation or
>>> multiple key systems). (sorry for not noticing sooner)
>>>
>>> Attached is a patch to fix this by making the init info a
>>> singly-linked-list.  It is ABI compatible and is still easy to use and
>>> understand.  The alternative would be to break ABI and have the
>>> side-data methods return an array of pointers.  I could do that
>>> instead if that is preferable.
>>
>> Ping
>
> Noticed a bug, fixed.

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


Re: [FFmpeg-devel] [PATCH 02/13] avformat/mxfenc: Bump minor versions for S377-1-2009

2018-05-07 Thread Carl Eugen Hoyos
2018-05-07 12:38 GMT+02:00, Michael Niedermayer :

> diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
> index c0db10b3c2..00dfce977b 100644
> --- a/libavformat/mxfenc.c
> +++ b/libavformat/mxfenc.c
> @@ -691,7 +691,7 @@ static void mxf_write_preface(AVFormatContext *s)
>
>  // write version
>  mxf_write_local_tag(pb, 2, 0x3B05);
> -avio_wb16(pb, 258); // v1.2
> +avio_wb16(pb, 259); // v1.2

I find it surprising that the comment doesn't change here.

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


Re: [FFmpeg-devel] [PATCH]lavc/qdrw: Read PixMap palette

2018-05-07 Thread Carl Eugen Hoyos
2018-05-05 2:26 GMT+02:00, Carl Eugen Hoyos :

> Attached patch fixes ticket #6195 for me.

I'll push this if there are no comments.

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


Re: [FFmpeg-devel] [PATCH] Added the possibility to pass an externally created CUDA context to libavutil/hwcontext.c/av_hwdevice_ctx_create() for decoding with NVDEC

2018-05-07 Thread Oscar Amoros Huguet
Have a look at this, looks pretty interesting:

/**
*   @brief  This function decodes a frame and returns the locked frame 
buffers
*   This makes the buffers available for use by the application without the 
buffers
*   getting overwritten, even if subsequent decode calls are made. The 
frame buffers
*   remain locked, until ::UnlockFrame() is called
*/
bool DecodeLockFrame(const uint8_t *pData, int nSize, uint8_t ***pppFrame, 
int *pnFrameReturned, uint32_t flags = 0, int64_t **ppTimestamp = NULL, int64_t 
timestamp = 0, CUstream stream = 0);

Oscar

-Original Message-
From: ffmpeg-devel  On Behalf Of Oscar Amoros 
Huguet
Sent: Monday, May 7, 2018 6:21 PM
To: FFmpeg development discussions and patches 
Subject: Re: [FFmpeg-devel] [PATCH] Added the possibility to pass an externally 
created CUDA context to libavutil/hwcontext.c/av_hwdevice_ctx_create() for 
decoding with NVDEC

Removing the need for the memcpy itself would clearly be the best.

Looking at NSIGHT, I see that NVDEC internally calls a color space 
transformation kernel on the default stream, and does not synchronize with the 
calling CPU thread. The cuMemcpy calls you have right now, use the same default 
stream, and do block with the calling CPU thread. So they perform an implicit 
synchronization with the CPU thread.

This means, that if you remove the Memcpy's, and the user wants to make any 
cuda call, over the results of this kernel, to make it safely, they have two 
options:
1 Either they use the same default stream (which is what I'm trying to avoid 
here).
2 Or the NvDecoder call "bool Decode(const uint8_t *pData, int nSize, uint8_t 
***pppFrame, int *pnFrameReturned, uint32_t flags = 0, int64_t **ppTimestamp = 
NULL, int64_t timestamp = 0, CUstream stream = 0)" uses the cuda stream 
specified by ffmpeg, as we where saying in the previous emails, instead of not 
specifying any stream and therefore always defaulting to the stream 0, or 
default stream. So Decode(..., ..., ..., ..., ..., ..., ..., cuda_stream)"

The second option has another benefit. If the ffmpeg user, specifies it's own 
non-default stream, then, this kernel joins the "overlapping world", and can 
overlap with any other cuda task. Saving even more time.

Hope it helps!

If there are other places where cuMemcpy is called, (we don't use it, but I 
think I saw it somewhere in the code) I think it would be nice to have the 
option to use a custom cuda stream, and keep it as is otherwise just by not 
setting a custom stream.

P.S: I had thoughts of talking to NVIDIA to know if there is a way to not call 
this kernel, and get whatever comes from the encoder directly, so we can 
transform it to the format we need. That is, calling one kernel instead of two. 
I'll let you know if we do, in case this becomes an option. I wonder what 
uint32_t flags is used for though. It's not explained in the headers. 

-Original Message-
From: ffmpeg-devel  On Behalf Of Timo 
Rothenpieler
Sent: Monday, May 7, 2018 5:13 PM
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH] Added the possibility to pass an externally 
created CUDA context to libavutil/hwcontext.c/av_hwdevice_ctx_create() for 
decoding with NVDEC

Am 07.05.2018 um 17:05 schrieb Oscar Amoros Huguet:
> To clarify a bit what I was saying in the last email. When I said CUDA 
> non-blocking streams, I meant non-default streams. All non-blocking 
> streams are non-default streams, but non-default streams can be 
> blocking or non-bloking with respect to the default streams.
> https://docs.nvidia.com/cuda/cuda-runtime-api/stream-sync-behavior.htm
> l
> 
> So, using cuMemcpyAsync, would allow the memory copies to overlap with 
> any other copy or kernel execution, enqueued in any other non-default 
> stream.
> https://devblogs.nvidia.com/how-overlap-data-transfers-cuda-cc/
> 
> If cuStreamSynchronize has to be called right after the last cuMemcpyAsync 
> call, I see different ways of implementing this, but probably you will most 
> likely prefer the following:
> 
> Add the cuMemcpyAsync to the list of cuda functions.
> Add a field in AVCUDADeviceContext of type CUstream, and set it to 0 (zero) 
> by default. Let's name it "CUstream cuda_stream"?
> Call always cuMemcpyAsync instead of cuMemcpy, passing cuda_stream as 
> the last parameter. cuMemcpyAsync(..., ..., ..., cuda_stream); After 
> the last cuMemcpyAsync, call cuStreamSynchronize on cuda_stream.
> cuStreamSynchronize(cuda_stream);
> 
> If the user does not change the context and the stream, the behavior will be 
> exactly the same as it is now. No synchronization hazards. Because passing 
> "0" as the cuda stream, makes the calls blocking, as if they weren't 
> asynchronous calls.
> 
> But, if the user wants the copies to overlap with the rest of it's 
> application, he can set it's own cuda context, and it's own non-default 
> 

Re: [FFmpeg-devel] [PATCH] Added the possibility to pass an externally created CUDA context to libavutil/hwcontext.c/av_hwdevice_ctx_create() for decoding with NVDEC

2018-05-07 Thread Oscar Amoros Huguet
Removing the need for the memcpy itself would clearly be the best.

Looking at NSIGHT, I see that NVDEC internally calls a color space 
transformation kernel on the default stream, and does not synchronize with the 
calling CPU thread. The cuMemcpy calls you have right now, use the same default 
stream, and do block with the calling CPU thread. So they perform an implicit 
synchronization with the CPU thread.

This means, that if you remove the Memcpy's, and the user wants to make any 
cuda call, over the results of this kernel, to make it safely, they have two 
options:
1 Either they use the same default stream (which is what I'm trying to avoid 
here).
2 Or the NvDecoder call "bool Decode(const uint8_t *pData, int nSize, uint8_t 
***pppFrame, int *pnFrameReturned, uint32_t flags = 0, int64_t **ppTimestamp = 
NULL, int64_t timestamp = 0, CUstream stream = 0)" uses the cuda stream 
specified by ffmpeg, as we where saying in the previous emails, instead of not 
specifying any stream and therefore always defaulting to the stream 0, or 
default stream. So Decode(..., ..., ..., ..., ..., ..., ..., cuda_stream)"

The second option has another benefit. If the ffmpeg user, specifies it's own 
non-default stream, then, this kernel joins the "overlapping world", and can 
overlap with any other cuda task. Saving even more time.

Hope it helps!

If there are other places where cuMemcpy is called, (we don't use it, but I 
think I saw it somewhere in the code) I think it would be nice to have the 
option to use a custom cuda stream, and keep it as is otherwise just by not 
setting a custom stream.

P.S: I had thoughts of talking to NVIDIA to know if there is a way to not call 
this kernel, and get whatever comes from the encoder directly, so we can 
transform it to the format we need. That is, calling one kernel instead of two. 
I'll let you know if we do, in case this becomes an option. I wonder what 
uint32_t flags is used for though. It's not explained in the headers. 

-Original Message-
From: ffmpeg-devel  On Behalf Of Timo 
Rothenpieler
Sent: Monday, May 7, 2018 5:13 PM
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH] Added the possibility to pass an externally 
created CUDA context to libavutil/hwcontext.c/av_hwdevice_ctx_create() for 
decoding with NVDEC

Am 07.05.2018 um 17:05 schrieb Oscar Amoros Huguet:
> To clarify a bit what I was saying in the last email. When I said CUDA 
> non-blocking streams, I meant non-default streams. All non-blocking 
> streams are non-default streams, but non-default streams can be 
> blocking or non-bloking with respect to the default streams. 
> https://docs.nvidia.com/cuda/cuda-runtime-api/stream-sync-behavior.htm
> l
> 
> So, using cuMemcpyAsync, would allow the memory copies to overlap with 
> any other copy or kernel execution, enqueued in any other non-default 
> stream. 
> https://devblogs.nvidia.com/how-overlap-data-transfers-cuda-cc/
> 
> If cuStreamSynchronize has to be called right after the last cuMemcpyAsync 
> call, I see different ways of implementing this, but probably you will most 
> likely prefer the following:
> 
> Add the cuMemcpyAsync to the list of cuda functions.
> Add a field in AVCUDADeviceContext of type CUstream, and set it to 0 (zero) 
> by default. Let's name it "CUstream cuda_stream"?
> Call always cuMemcpyAsync instead of cuMemcpy, passing cuda_stream as 
> the last parameter. cuMemcpyAsync(..., ..., ..., cuda_stream); After 
> the last cuMemcpyAsync, call cuStreamSynchronize on cuda_stream. 
> cuStreamSynchronize(cuda_stream);
> 
> If the user does not change the context and the stream, the behavior will be 
> exactly the same as it is now. No synchronization hazards. Because passing 
> "0" as the cuda stream, makes the calls blocking, as if they weren't 
> asynchronous calls.
> 
> But, if the user wants the copies to overlap with the rest of it's 
> application, he can set it's own cuda context, and it's own non-default 
> stream.
> 
> In any of the cases, ffmpeg does not have to handle cuda stream creation and 
> destruction, which makes it simpler.
> 
> Hope you like it!

A different idea I'm looking at right now is to get rid of the memcpy entirely, 
turning the mapped cuvid frame into an AVFrame itself, with a buffer_ref that 
unmaps the cuvid frame when freeing it, instead of allocating a whole new 
buffer and copying it over.
I'm not sure how that will play out with available free surfaces, but I will 
test.

I'll also add the stream basically like you described, as it seems useful to 
have around anyway.

If previously mentioned approach does not work, I'll implement this like 
described, probably for all cuMemCpy* in ffmpeg, as it at least does run the 
2/3 plane copys asynchronous. Not sure if it can be changed to actually do them 
in parallel.

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org

Re: [FFmpeg-devel] [PATCH 7/9] lavfi/nlmeans: switch from double to float

2018-05-07 Thread Clément Bœsch
On Sun, May 06, 2018 at 04:53:54PM +0200, Moritz Barsnick wrote:
> On Sun, May 06, 2018 at 13:40:58 +0200, Clément Bœsch wrote:
> > Overall speed appears to be 1.1x faster with no noticeable quality impact.
> 
> Probably platform dependant?
> 
> >  struct weighted_avg {
> > -double total_weight;
> > -double sum;
> > +float total_weight;
> > +float sum;
> >  };
> 
> I believe these calculaions in nlmeans_plane() will promote to double
> before being cast back to float:
> 
>// Also weight the centered pixel
> wa->total_weight += 1.0;
> wa->sum += 1.0 * src[y*src_linesize + x];
> 
> (At least the second one. The first one - just an assignment of a
> constant - is covered by the preprocessor, IIUC.) They need to use
> "1.0f".
> 

It doesn't really matter here actually, in "lavfi/nlmeans: move final
weighted averaging out of nlmeans_plane" you can see that this code
represents 0.24% of the CPU time. I fixed it locally anyway, thanks.

> (There are others, but only in init(), which don't matter for
> performance.)

Yeah, I left these to double on purpose.

-- 
Clément B.


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


Re: [FFmpeg-devel] [PATCH 2/9] lavfi/nlmeans: add SIMD-friendly assumptions for compute_safe_ssd_integral_image

2018-05-07 Thread Clément Bœsch
On Mon, May 07, 2018 at 12:14:37AM +0200, Michael Niedermayer wrote:
> On Sun, May 06, 2018 at 01:40:53PM +0200, Clément Bœsch wrote:
> > SIMD code will not have to deal with padding itself. Overwriting in that
> > function may have been possible but involve large overreading of the
> > sources. Instead, we simply make sure the width to process is always a
> > multiple of 16. Additionally, there must be some actual area to process
> > so the SIMD code can have its boundary checks after processing the first
> > pixels.
> > ---
> >  libavfilter/vf_nlmeans.c | 25 ++---
> >  1 file changed, 18 insertions(+), 7 deletions(-)
> > 
> > diff --git a/libavfilter/vf_nlmeans.c b/libavfilter/vf_nlmeans.c
> > index d222d3913e..21f981a605 100644
> > --- a/libavfilter/vf_nlmeans.c
> > +++ b/libavfilter/vf_nlmeans.c
> > @@ -157,6 +157,9 @@ static void compute_safe_ssd_integral_image_c(uint32_t 
> > *dst, int dst_linesize_32
> >  {
> >  int x, y;
> >  
> > +/* SIMD-friendly assumptions allowed here */
> > +av_assert2(!(w & 0xf) && w >= 16 && h >= 1);
> > +
> >  for (y = 0; y < h; y++) {
> >  uint32_t acc = dst[-1] - dst[-dst_linesize_32 - 1];
> >  
> > @@ -257,9 +260,16 @@ static void compute_ssd_integral_image(uint32_t *ii, 
> > int ii_linesize_32,
> >  // to compare the 2 sources pixels
> >  const int startx_safe = FFMAX(s1x, s2x);
> >  const int starty_safe = FFMAX(s1y, s2y);
> > -const int endx_safe   = FFMIN(s1x + w, s2x + w);
> > +const int u_endx_safe = FFMIN(s1x + w, s2x + w); // unaligned
> >  const int endy_safe   = FFMIN(s1y + h, s2y + h);
> >  
> > +// deduce the safe area width and height
> > +const int safe_pw = (u_endx_safe - startx_safe) & ~0xf;
> > +const int safe_ph = endy_safe - starty_safe;
> > +
> > +// adjusted end x position of the safe area after width of the safe 
> > area gets aligned
> > +const int endx_safe = startx_safe + safe_pw;
> > +
> >  // top part where only one of s1 and s2 is still readable, or none at 
> > all
> >  compute_unsafe_ssd_integral_image(ii, ii_linesize_32,
> >0, 0,
> > @@ -273,24 +283,25 @@ static void compute_ssd_integral_image(uint32_t *ii, 
> > int ii_linesize_32,
> >0, starty_safe,
> >src, linesize,
> >offx, offy, e, w, h,
> > -  startx_safe, endy_safe - 
> > starty_safe);
> > +  startx_safe, safe_ph);
> >  
> >  // main and safe part of the integral
> >  av_assert1(startx_safe - s1x >= 0); av_assert1(startx_safe - s1x < w);
> >  av_assert1(starty_safe - s1y >= 0); av_assert1(starty_safe - s1y < h);
> >  av_assert1(startx_safe - s2x >= 0); av_assert1(startx_safe - s2x < w);
> >  av_assert1(starty_safe - s2y >= 0); av_assert1(starty_safe - s2y < h);
> > -compute_safe_ssd_integral_image_c(ii + starty_safe*ii_linesize_32 + 
> > startx_safe, ii_linesize_32,
> > -  src + (starty_safe - s1y) * linesize 
> > + (startx_safe - s1x), linesize,
> > -  src + (starty_safe - s2y) * linesize 
> > + (startx_safe - s2x), linesize,
> > -  endx_safe - startx_safe, endy_safe - 
> > starty_safe);
> > +if (safe_pw && safe_ph)
> > +dsp->compute_safe_ssd_integral_image(ii + 
> > starty_safe*ii_linesize_32 + startx_safe, ii_linesize_32,
> > + src + (starty_safe - s1y) * 
> > linesize + (startx_safe - s1x), linesize,
> > + src + (starty_safe - s2y) * 
> > linesize + (startx_safe - s2x), linesize,
> > + safe_pw, safe_ph);
> 
> 
> i think this is or i am missing some change
> 
> libavfilter/vf_nlmeans.c: In function ‘compute_ssd_integral_image’:
> libavfilter/vf_nlmeans.c:294:9: error: ‘dsp’ undeclared (first use in this 
> function)
>  dsp->compute_safe_ssd_integral_image(ii + starty_safe*ii_linesize_32 
> + startx_safe, ii_linesize_32,
>  ^
> libavfilter/vf_nlmeans.c:294:9: note: each undeclared identifier is reported 
> only once for each function it appears in
> libavfilter/vf_nlmeans.c: At top level:
> libavfilter/vf_nlmeans.c:153:13: warning: ‘compute_safe_ssd_integral_image_c’ 
> defined but not used [-Wunused-function]
>  static void compute_safe_ssd_integral_image_c(uint32_t *dst, int 
> dst_linesize_32,
>  ^
> make: *** [libavfilter/vf_nlmeans.o] Error 1
> make: *** Waiting for unfinished jobs

Yeah I made a mistake while splitting commit, this is fixed locally. At
this step it's supposed to still be calling
compute_safe_ssd_integral_image_c() directly (but its last 2 parameters
changed).

-- 
Clément B.


signature.asc
Description: PGP signature

[FFmpeg-devel] [PATCH 1/1] configure: add pkg-config check for libmysofa

2018-05-07 Thread Reino Wijnsma
From 8082ba451d089790f0719c4ec6788796b2079e9d Mon Sep 17 00:00:00 2001
From: Reino17 
Date: Mon, 7 May 2018 17:28:10 +0200
Subject: [PATCH] configure: add pkg-config check for libmysofa

This does require libmysofa with today's latest commit 
(https://github.com/hoene/libmysofa/commit/08f243d1ec35f6f794aedeb4b187d9f9353bdbc1).
They already had a pkg-config file, but the dependencies weren't setup right. 
Until now.
---
 configure | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/configure b/configure
index 7c14323..2d61731 100755
--- a/configure
+++ b/configure
@@ -6007,7 +6007,8 @@ enabled libmfx&& { check_pkg_config libmfx 
libmfx "mfx/mfxvideo.h" M
{ require libmfx "mfx/mfxvideo.h" MFXInit 
"-llibmfx $advapi32_extralibs" && warn "using libmfx without pkg-config"; } }
 enabled libmodplug&& require_pkg_config libmodplug libmodplug 
libmodplug/modplug.h ModPlug_Load
 enabled libmp3lame&& require "libmp3lame >= 3.98.3" lame/lame.h 
lame_set_VBR_quality -lmp3lame $libm_extralibs
-enabled libmysofa && require libmysofa "mysofa.h" mysofa_load -lmysofa 
$zlib_extralibs
+enabled libmysofa && { check_pkg_config libmysofa libmysofa mysofa.h 
mysofa_load ||
+   require libmysofa mysofa.h mysofa_load -lmysofa 
$zlib_extralibs; }
 enabled libnpp&& { check_lib libnpp npp.h nppGetLibVersion -lnppig 
-lnppicc -lnppc ||
check_lib libnpp npp.h nppGetLibVersion -lnppi 
-lnppc ||
die "ERROR: libnpp not found"; }
-- 
2.8.3


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


Re: [FFmpeg-devel] [PATCH] Added the possibility to pass an externally created CUDA context to libavutil/hwcontext.c/av_hwdevice_ctx_create() for decoding with NVDEC

2018-05-07 Thread Timo Rothenpieler

Am 07.05.2018 um 17:05 schrieb Oscar Amoros Huguet:

To clarify a bit what I was saying in the last email. When I said CUDA 
non-blocking streams, I meant non-default streams. All non-blocking streams are 
non-default streams, but non-default streams can be blocking or non-bloking 
with respect to the default streams. 
https://docs.nvidia.com/cuda/cuda-runtime-api/stream-sync-behavior.html

So, using cuMemcpyAsync, would allow the memory copies to overlap with any 
other copy or kernel execution, enqueued in any other non-default stream. 
https://devblogs.nvidia.com/how-overlap-data-transfers-cuda-cc/

If cuStreamSynchronize has to be called right after the last cuMemcpyAsync 
call, I see different ways of implementing this, but probably you will most 
likely prefer the following:

Add the cuMemcpyAsync to the list of cuda functions.
Add a field in AVCUDADeviceContext of type CUstream, and set it to 0 (zero) by default. 
Let's name it "CUstream cuda_stream"?
Call always cuMemcpyAsync instead of cuMemcpy, passing cuda_stream as the last 
parameter. cuMemcpyAsync(..., ..., ..., cuda_stream);
After the last cuMemcpyAsync, call cuStreamSynchronize on cuda_stream. 
cuStreamSynchronize(cuda_stream);

If the user does not change the context and the stream, the behavior will be exactly the 
same as it is now. No synchronization hazards. Because passing "0" as the cuda 
stream, makes the calls blocking, as if they weren't asynchronous calls.

But, if the user wants the copies to overlap with the rest of it's application, 
he can set it's own cuda context, and it's own non-default stream.

In any of the cases, ffmpeg does not have to handle cuda stream creation and 
destruction, which makes it simpler.

Hope you like it!


A different idea I'm looking at right now is to get rid of the memcpy 
entirely, turning the mapped cuvid frame into an AVFrame itself, with a 
buffer_ref that unmaps the cuvid frame when freeing it, instead of 
allocating a whole new buffer and copying it over.
I'm not sure how that will play out with available free surfaces, but I 
will test.


I'll also add the stream basically like you described, as it seems 
useful to have around anyway.


If previously mentioned approach does not work, I'll implement this like 
described, probably for all cuMemCpy* in ffmpeg, as it at least does run 
the 2/3 plane copys asynchronous. Not sure if it can be changed to 
actually do them in parallel.




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] Added the possibility to pass an externally created CUDA context to libavutil/hwcontext.c/av_hwdevice_ctx_create() for decoding with NVDEC

2018-05-07 Thread Oscar Amoros Huguet
To clarify a bit what I was saying in the last email. When I said CUDA 
non-blocking streams, I meant non-default streams. All non-blocking streams are 
non-default streams, but non-default streams can be blocking or non-bloking 
with respect to the default streams. 
https://docs.nvidia.com/cuda/cuda-runtime-api/stream-sync-behavior.html

So, using cuMemcpyAsync, would allow the memory copies to overlap with any 
other copy or kernel execution, enqueued in any other non-default stream. 
https://devblogs.nvidia.com/how-overlap-data-transfers-cuda-cc/

If cuStreamSynchronize has to be called right after the last cuMemcpyAsync 
call, I see different ways of implementing this, but probably you will most 
likely prefer the following:

Add the cuMemcpyAsync to the list of cuda functions.
Add a field in AVCUDADeviceContext of type CUstream, and set it to 0 (zero) by 
default. Let's name it "CUstream cuda_stream"?
Call always cuMemcpyAsync instead of cuMemcpy, passing cuda_stream as the last 
parameter. cuMemcpyAsync(..., ..., ..., cuda_stream);
After the last cuMemcpyAsync, call cuStreamSynchronize on cuda_stream. 
cuStreamSynchronize(cuda_stream);

If the user does not change the context and the stream, the behavior will be 
exactly the same as it is now. No synchronization hazards. Because passing "0" 
as the cuda stream, makes the calls blocking, as if they weren't asynchronous 
calls.

But, if the user wants the copies to overlap with the rest of it's application, 
he can set it's own cuda context, and it's own non-default stream.

In any of the cases, ffmpeg does not have to handle cuda stream creation and 
destruction, which makes it simpler.

Hope you like it!

Oscar

-Original Message-
From: Oscar Amoros Huguet 
Sent: Monday, May 7, 2018 2:05 PM
To: FFmpeg development discussions and patches 
Subject: Re: [FFmpeg-devel] [PATCH] Added the possibility to pass an externally 
created CUDA context to libavutil/hwcontext.c/av_hwdevice_ctx_create() for 
decoding with NVDEC

Hi!

Even if there is need to have a syncronization before leaving the ffmpeg call, 
callin cuMemcpyAsync will allow the copies to overlap with any other task on 
the gpu, that was enqueued using any other non-blocking cuda stream. That’s 
exactly what we want to achieve.

This would benefit automatically any other app that uses non-blocking cuda 
streams, as independent cuda workflows.

Oscar

Enviat des del meu iPhone

El 7 maig 2018, a les 13:54, Timo Rothenpieler  va 
escriure:

>>> Additionally, could you give your opinion on the feature we also may
> want to add in the future, that we mentioned in the previous email?
> Basically, we may want to add one more CUDA function, specifically 
> cuMemcpy2DAsync, and the possibility to set a CUStream in 
> AVCUDADeviceContext, so it is used with cuMemcpy2DAsync instead of 
> cuMemcpy2D in "nvdec_retrieve_data" in file libavcodec/nvdec.c. In our 
> use case this would save up to  0.72 ms (GPU time) per frame, in case 
> of decoding 8 fullhd frames, and up to 0.5 ms (GPU time) per frame, in 
> case of decoding two 4k frames. This may sound too little, but for us 
> is significant. Our software needs to do many things in a maximum of 
> 33ms with CUDA on the GPU per frame, and we have little GPU time left.
>> 
>> This is interesting and I'm considering making that the default, as 
>> it would fit well with the current infrastructure, delaying the sync 
>> call to the moment the frame leaves avcodec, which with the internal 
>> re-ordering and delay should give plenty of time for the copy to finish.
> 
> I'm not sure if/how well this works with the mapped cuvid frames though.
> The frame would already be unmapped and potentially re-used again 
> before the async copy completes. So it would need an immediately call 
> to Sync right after the 3 async copy calls, making the entire effort 
> pointless.
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [GSOC] [PATCH] SRCNN filter

2018-05-07 Thread Pedro Arthur
2018-05-07 0:30 GMT-03:00 Steven Liu :
> Hi Sergey,
>
> How should i test this filter?
> I tested it some days ago, the picture get worse from 2nd frame.
> input resolution 640x480 to 1280x720;
>
> ffmpeg -i input -vf srcnn output
Hi,
The filter expects the input upscaled by 2x, therefore the proper
command would be

ffmpeg -i input -vf "scale=2*iw:2*ih, srcnn, scale=1280:720"

The default filter is trained for 2x upscale, anything different from
that may generate bad results.

>
>> On May 7, 2018, at 09:33, Pedro Arthur  wrote:
>>
>> 2018-05-06 17:27 GMT-03:00 James Almer :
>>> On 5/5/2018 5:38 PM, James Almer wrote:
 On 4/10/2018 2:16 PM, Sergey Lavrushkin wrote:
> diff --git a/libavfilter/vf_srcnn.c b/libavfilter/vf_srcnn.c
> new file mode 100644
> index 00..d9b4891f7f
> --- /dev/null
> +++ b/libavfilter/vf_srcnn.c
> @@ -0,0 +1,420 @@
> +/*
> + * Copyright (c) 2018 Sergey Lavrushkin
> + *
> + * 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
> + */
> +
> +/**
> + * @file
> + * Filter implementing image super-resolution using deep convolutional 
> networks.
> + * https://arxiv.org/abs/1501.00092
> + */
> +
> +#include "avfilter.h"
> +#include "formats.h"
> +#include "internal.h"
> +#include "libavutil/opt.h"
> +#include "unistd.h"

 This broke msvc. It should be (if anything) , and wrapped
 inside a HAVE_UNISTD_H preprocessor check.
>>>
>>> I (accidentally) applied this change as part of an unrelated commit, so
>>> that's dealt with at least.
>>>

> +static av_cold int init(AVFilterContext* context)
> +{
> +SRCNNContext *srcnn_context = context->priv;
> +AVIOContext* config_file_context;
> +int64_t file_size, srcnn_size;
> +
> +/// Check specified confguration file name and read network weights 
> from it
> +if (!srcnn_context->config_file_path){
> +av_log(context, AV_LOG_INFO, "configuration file for network was 
> not specified, using default weights for x2 upsampling\n");
> +
> +/// Create convolution kernels and copy default weights
> +srcnn_context->conv1.input_channels = 1;
> +srcnn_context->conv1.output_channels = 64;
> +srcnn_context->conv1.size = 9;
> +CHECK_ALLOCATION(allocate_copy_conv_data(_context->conv1, 
> conv1_kernel, conv1_biases), )
> +
> +srcnn_context->conv2.input_channels = 64;
> +srcnn_context->conv2.output_channels = 32;
> +srcnn_context->conv2.size = 1;
> +CHECK_ALLOCATION(allocate_copy_conv_data(_context->conv2, 
> conv2_kernel, conv2_biases), )
> +
> +srcnn_context->conv3.input_channels = 32;
> +srcnn_context->conv3.output_channels = 1;
> +srcnn_context->conv3.size = 5;
> +CHECK_ALLOCATION(allocate_copy_conv_data(_context->conv3, 
> conv3_kernel, conv3_biases), )
> +}
> +else if (access(srcnn_context->config_file_path, R_OK) != -1){

 This seems to be the function needed from unistd.h

 Looking at configure and libavformat/file.c it's apparently not
 available everywhere (we have a HAVE_ACCESS define, and also check for
 mode constants like R_OK).
>>>
>>> MSVC does not have access(), so i have temporarily made this filter
>>> depend on its presence until a proper fix is applied. That target has
>>> been broken for a few days now and that shouldn't be the case.
>>> It should be a matter or doing the same thing as in libavformat/file.c,
>>> i guess, or perhaps use _access() instead, which is available in MSVC.
>> Thanks.
>>
>>
>> @Sergey can you provide a definitive fix?
>>
>>> ___
>>> ffmpeg-devel mailing list
>>> ffmpeg-devel@ffmpeg.org
>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> 

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

2018-05-07 Thread James Almer
On 5/7/2018 10:59 AM, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol 
> ---
>  libavfilter/Makefile  |   1 +
>  libavfilter/allfilters.c  |   1 +
>  libavfilter/vf_fftdnoiz.c | 393 
> ++
>  3 files changed, 395 insertions(+)
>  create mode 100644 libavfilter/vf_fftdnoiz.c

Missing configure dependency on fft (also changelog and such).
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


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

2018-05-07 Thread Paul B Mahol
Signed-off-by: Paul B Mahol 
---
 libavfilter/Makefile  |   1 +
 libavfilter/allfilters.c  |   1 +
 libavfilter/vf_fftdnoiz.c | 393 ++
 3 files changed, 395 insertions(+)
 create mode 100644 libavfilter/vf_fftdnoiz.c

diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index a416fa1fae..92f526a275 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -201,6 +201,7 @@ OBJS-$(CONFIG_EQ_FILTER) += vf_eq.o
 OBJS-$(CONFIG_EROSION_FILTER)+= vf_neighbor.o
 OBJS-$(CONFIG_EXTRACTPLANES_FILTER)  += vf_extractplanes.o
 OBJS-$(CONFIG_FADE_FILTER)   += vf_fade.o
+OBJS-$(CONFIG_FFTDNOIZ_FILTER)   += vf_fftdnoiz.o
 OBJS-$(CONFIG_FFTFILT_FILTER)+= vf_fftfilt.o
 OBJS-$(CONFIG_FIELD_FILTER)  += vf_field.o
 OBJS-$(CONFIG_FIELDHINT_FILTER)  += vf_fieldhint.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 42f956b3bf..f3a76c4652 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -193,6 +193,7 @@ extern AVFilter ff_vf_eq;
 extern AVFilter ff_vf_erosion;
 extern AVFilter ff_vf_extractplanes;
 extern AVFilter ff_vf_fade;
+extern AVFilter ff_vf_fftdnoiz;
 extern AVFilter ff_vf_fftfilt;
 extern AVFilter ff_vf_field;
 extern AVFilter ff_vf_fieldhint;
diff --git a/libavfilter/vf_fftdnoiz.c b/libavfilter/vf_fftdnoiz.c
new file mode 100644
index 00..eac3f2642a
--- /dev/null
+++ b/libavfilter/vf_fftdnoiz.c
@@ -0,0 +1,393 @@
+/*
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include 
+
+#include "libavutil/avassert.h"
+#include "libavutil/common.h"
+#include "libavutil/imgutils.h"
+#include "libavutil/opt.h"
+#include "libavutil/pixdesc.h"
+#include "internal.h"
+#include "libavcodec/avfft.h"
+
+typedef struct PlaneContext {
+int planewidth, planeheight;
+int nox, noy;
+int b;
+int o;
+float n;
+
+float *buffer;
+FFTComplex *hdata, *vdata;
+int data_linesize;
+int buffer_linesize;
+
+FFTContext *fft, *ifft;
+} PlaneContext;
+
+typedef struct FFTdnoizContext {
+const AVClass *class;
+
+float sigma;
+float amount;
+int   block_bits;
+float overlap;
+int   planesf;
+
+int nb_planes;
+PlaneContext planes[4];
+} FFTdnoizContext;
+
+#define OFFSET(x) offsetof(FFTdnoizContext, x)
+#define FLAGS AV_OPT_FLAG_FILTERING_PARAM|AV_OPT_FLAG_VIDEO_PARAM
+static const AVOption fftdnoiz_options[] = {
+{ "sigma",   "set noise sigma",  OFFSET(sigma),  
AV_OPT_TYPE_FLOAT, {.dbl=2},0,   7, .flags = FLAGS },
+{ "amount",  "set amount of denoising",  OFFSET(amount), 
AV_OPT_TYPE_FLOAT, {.dbl=1}, 0.01,   1, .flags = FLAGS },
+{ "block",   "set block log2(size)", OFFSET(block_bits), 
AV_OPT_TYPE_INT,   {.i64=5},4,   6, .flags = FLAGS },
+{ "overlap", "set block overlap",OFFSET(overlap),
AV_OPT_TYPE_FLOAT, {.dbl=0.}, 0.2, 0.8, .flags = FLAGS },
+{ "planes",  "set planes to filter", OFFSET(planesf),
AV_OPT_TYPE_INT,   {.i64=7},0,  15, .flags = FLAGS },
+{ NULL }
+};
+
+AVFILTER_DEFINE_CLASS(fftdnoiz);
+
+static int config_input(AVFilterLink *inlink)
+{
+AVFilterContext *ctx = inlink->dst;
+const AVPixFmtDescriptor *desc;
+FFTdnoizContext *s = ctx->priv;
+int i;
+
+desc = av_pix_fmt_desc_get(inlink->format);
+
+s->planes[1].planewidth = s->planes[2].planewidth = 
AV_CEIL_RSHIFT(inlink->w, desc->log2_chroma_w);
+s->planes[0].planewidth = s->planes[3].planewidth = inlink->w;
+s->planes[1].planeheight = s->planes[2].planeheight = 
AV_CEIL_RSHIFT(inlink->h, desc->log2_chroma_h);
+s->planes[0].planeheight = s->planes[3].planeheight = inlink->h;
+
+s->nb_planes = av_pix_fmt_count_planes(inlink->format);
+
+for (i = 0; i < s->nb_planes; i++) {
+PlaneContext *p = >planes[i];
+int size;
+
+p->b = 1 << s->block_bits;
+p->n = 1.f / (p->b * p->b);
+p->o = p->b * s->overlap;
+size = p->b - p->o;
+p->nox = (p->planewidth  + (size - 1)) / size;
+p->noy = (p->planeheight + (size - 1)) / size;
+
+av_log(ctx, AV_LOG_DEBUG, "nox:%d noy:%d 

[FFmpeg-devel] [PATCH 1/1] avfilter/drawtext: present 'hms' formatted 'pts' in 24h format

2018-05-07 Thread vdixit
From: Vishwanath Dixit 

HMS is formatted as HH:MM:SS.mmm, but, HH part is not limited to
24 hours. For example, the the drawn text may look like this:
243029:20:30.342. To present the timestamp in more readable and
user friendly format, this patch provides an additional option
to limit the hour part in the range 0-23.

Note: Actually the above required format can be obtained with
format options 'localtime' and 'gmtime', but,  milliseconds part
is not supported in those formats.
---
 doc/filters.texi  | 4 
 libavfilter/vf_drawtext.c | 8 
 2 files changed, 12 insertions(+)

diff --git a/doc/filters.texi b/doc/filters.texi
index 33e27e1..6e306f1 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -8134,6 +8134,10 @@ local time zone time.
 
 The second argument is an offset added to the timestamp.
 
+If the format is set to @code{hms}, a third argument @code{24HH} may be
+supplied to present the hour part of the formatted timestamp in 24h format
+(00-23).
+
 If the format is set to @code{localtime} or @code{gmtime},
 a third argument may be supplied: a strftime() format string.
 By default, @var{-MM-DD HH:MM:SS} format will be used.
diff --git a/libavfilter/vf_drawtext.c b/libavfilter/vf_drawtext.c
index e8905a4..3affa73 100644
--- a/libavfilter/vf_drawtext.c
+++ b/libavfilter/vf_drawtext.c
@@ -916,6 +916,14 @@ static int func_pts(AVFilterContext *ctx, AVBPrint *bp,
 sign = '-';
 ms = -ms;
 }
+if (argc >= 3) {
+if (!strcmp(argv[2], "24HH")) {
+ms %= 24 * 60 * 60 * 1000;
+} else {
+av_log(ctx, AV_LOG_ERROR, "Invalid argument '%s'\n", 
argv[2]);
+return AVERROR(EINVAL);
+}
+}
 av_bprintf(bp, "%c%02d:%02d:%02d.%03d", sign,
(int)(ms / (60 * 60 * 1000)),
(int)(ms / (60 * 1000)) % 60,
-- 
1.9.1

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


Re: [FFmpeg-devel] [PATCH] Added the possibility to pass an externally created CUDA context to libavutil/hwcontext.c/av_hwdevice_ctx_create() for decoding with NVDEC

2018-05-07 Thread Timo Rothenpieler
>> Additionally, could you give your opinion on the feature we also may
want to add in the future, that we mentioned in the previous email?
Basically, we may want to add one more CUDA function, specifically
cuMemcpy2DAsync, and the possibility to set a CUStream in
AVCUDADeviceContext, so it is used with cuMemcpy2DAsync instead of
cuMemcpy2D in "nvdec_retrieve_data" in file libavcodec/nvdec.c. In our
use case this would save up to  0.72 ms (GPU time) per frame, in case of
decoding 8 fullhd frames, and up to 0.5 ms (GPU time) per frame, in case
of decoding two 4k frames. This may sound too little, but for us is
significant. Our software needs to do many things in a maximum of 33ms
with CUDA on the GPU per frame, and we have little GPU time left.
> 
> This is interesting and I'm considering making that the default, as it
> would fit well with the current infrastructure, delaying the sync call
> to the moment the frame leaves avcodec, which with the internal
> re-ordering and delay should give plenty of time for the copy to finish.

I'm not sure if/how well this works with the mapped cuvid frames though.
The frame would already be unmapped and potentially re-used again before
the async copy completes. So it would need an immediately call to Sync
right after the 3 async copy calls, making the entire effort pointless.



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] Added the possibility to pass an externally created CUDA context to libavutil/hwcontext.c/av_hwdevice_ctx_create() for decoding with NVDEC

2018-05-07 Thread Timo Rothenpieler
On 26.04.2018 18:03, Oscar Amoros Huguet wrote:
> Thanks Mark,
> 
> You are right, we can implement in our code a sort of "av_hwdevice_ctx_set" 
> (which does not exist), by using av_hwdevice_ctx_alloc() + 
> av_hwdevice_ctx_init(). We actually use av_hwdevice_ctx_alloc in our code to 
> use the feature we implemented already. We are not sure about license 
> implications though, we link dynamically to work with LGPL. I guess both 
> calls are public, since they are not in "internal" labelled files.
> 
> We are perfectly ok with using av_hwdevice_ctx_alloc() + 
> av_hwdevice_ctx_init() outside ffmpeg, to use our own CUDA context. By doing 
> so, in the current ffmpeg code, there is an internal flag " 
> AVCUDADeviceContextInternal.is_allocated" that is not set to 1, therefore, 
> the cuda context is not destroyed by ffmpeg in "cuda_device_uninit", which is 
> the desired behavior.
> 
> In fact, this flag implies that the context was not allocated by ffmpeg. 
> Maybe this is the right flag to be used to avoid push/pop pairs when the CUDA 
> context is not created by ffmpeg. What do you think?
> 
> We can adapt all of the push/pop pairs on the code, to follow this policy, 
> whichever flag is used.
> 
> About the performance effects of this push/pop calls, we have seen with 
> NVIDIA profiling tools (NSIGHT for Visual Studio plugin), that the CUDA 
> runtime detects that the context you wat to set is the same as the one 
> currently set, so the push call does nothing and lasts 0.0016 ms in average 
> (CPU time). But for some reason, the cuCtxPopCurrent call, does take some 
> more time, and uses 0.02 ms of CPU time per call. This is 0,16 ms total per 
> frame when decoding 8 feeds. This is small, but it's easy to remove. 

I'm not a fan of touching every single bit of CUDA-related code for
this. Push/Pop, specially for the context that's already active, should
be free. If it's not, that's something I'd complain to nvidia about.

For your specific usecase, you could build FFmpeg with a custom version
of the ffnvcodec headers, that has a custom function for the push/pop
ctx functions, practically noops.

> Additionally, could you give your opinion on the feature we also may want to 
> add in the future, that we mentioned in the previous email? Basically, we may 
> want to add one more CUDA function, specifically cuMemcpy2DAsync, and the 
> possibility to set a CUStream in AVCUDADeviceContext, so it is used with 
> cuMemcpy2DAsync instead of cuMemcpy2D in "nvdec_retrieve_data" in file 
> libavcodec/nvdec.c. In our use case this would save up to  0.72 ms (GPU time) 
> per frame, in case of decoding 8 fullhd frames, and up to 0.5 ms (GPU time) 
> per frame, in case of decoding two 4k frames. This may sound too little, but 
> for us is significant. Our software needs to do many things in a maximum of 
> 33ms with CUDA on the GPU per frame, and we have little GPU time left.

This is interesting and I'm considering making that the default, as it
would fit well with the current infrastructure, delaying the sync call
to the moment the frame leaves avcodec, which with the internal
re-ordering and delay should give plenty of time for the copy to finish.



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


[FFmpeg-devel] [PATCH 01/13] avformat/mxfenc: Correct KAG alignment of preface

2018-05-07 Thread Michael Niedermayer
Signed-off-by: Michael Niedermayer 
---
 libavformat/mxfenc.c|  1 +
 tests/ref/fate/copy-trac4914|  4 ++--
 tests/ref/fate/mxf-reel_name|  2 +-
 tests/ref/fate/time_base|  2 +-
 tests/ref/lavf/mxf  | 12 ++--
 tests/ref/lavf/mxf_d10  |  4 ++--
 tests/ref/lavf/mxf_dv25 |  4 ++--
 tests/ref/lavf/mxf_dvcpro50 |  4 ++--
 tests/ref/lavf/mxf_opatom   |  2 +-
 tests/ref/lavf/mxf_opatom_audio |  4 ++--
 10 files changed, 20 insertions(+), 19 deletions(-)

diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
index 3bb70326fe..c0db10b3c2 100644
--- a/libavformat/mxfenc.c
+++ b/libavformat/mxfenc.c
@@ -1757,6 +1757,7 @@ static int mxf_write_partition(AVFormatContext *s, int 
bodysid,
 mxf_write_klv_fill(s);
 start = avio_tell(s->pb);
 mxf_write_primer_pack(s);
+mxf_write_klv_fill(s);
 mxf_write_header_metadata_sets(s);
 pos = avio_tell(s->pb);
 header_byte_count = pos - start + klv_fill_size(pos);
diff --git a/tests/ref/fate/copy-trac4914 b/tests/ref/fate/copy-trac4914
index a8f287fafa..06eac9e621 100644
--- a/tests/ref/fate/copy-trac4914
+++ b/tests/ref/fate/copy-trac4914
@@ -1,5 +1,5 @@
-05fdc4a6e28abb2c26e96224682d2684 *tests/data/fate/copy-trac4914.mxf
-560697 tests/data/fate/copy-trac4914.mxf
+9097dd426106c40288262b53cc6fdb83 *tests/data/fate/copy-trac4914.mxf
+561209 tests/data/fate/copy-trac4914.mxf
 #tb 0: 1001/3
 #media_type 0: video
 #codec_id 0: rawvideo
diff --git a/tests/ref/fate/mxf-reel_name b/tests/ref/fate/mxf-reel_name
index fb9586097a..7350d2c0bf 100644
--- a/tests/ref/fate/mxf-reel_name
+++ b/tests/ref/fate/mxf-reel_name
@@ -1 +1 @@
-dda6c54b642b8794a87d809fdb361f95
+625c69eb3801368737266128efdd0a8c
diff --git a/tests/ref/fate/time_base b/tests/ref/fate/time_base
index 4dd14084d3..75ec4368a4 100644
--- a/tests/ref/fate/time_base
+++ b/tests/ref/fate/time_base
@@ -1 +1 @@
-f97551f884df5ab709c5869c66c7b9bc
+0979b614a34f668eb47278448b254000
diff --git a/tests/ref/lavf/mxf b/tests/ref/lavf/mxf
index 7318447ecb..1aff1a0509 100644
--- a/tests/ref/lavf/mxf
+++ b/tests/ref/lavf/mxf
@@ -1,9 +1,9 @@
-d4140129463dec64bdb4a7d7ad1b0c82 *./tests/data/lavf/lavf.mxf
-525369 ./tests/data/lavf/lavf.mxf
+47c67e4309c680ce91df5396541ee31e *./tests/data/lavf/lavf.mxf
+525881 ./tests/data/lavf/lavf.mxf
 ./tests/data/lavf/lavf.mxf CRC=0x8dddfaab
-a27bb8cd5e185ea13b0a8daa4eb221cd *./tests/data/lavf/lavf.mxf
-560697 ./tests/data/lavf/lavf.mxf
+8e5f8bc13d7c888f4b6320f9869d49d5 *./tests/data/lavf/lavf.mxf
+561209 ./tests/data/lavf/lavf.mxf
 ./tests/data/lavf/lavf.mxf CRC=0xf21b1b48
-395bf0047c97ceca96935357166b94c7 *./tests/data/lavf/lavf.mxf
-525369 ./tests/data/lavf/lavf.mxf
+c49f8d4743c8dcc33fa01e6dcb995a38 *./tests/data/lavf/lavf.mxf
+525881 ./tests/data/lavf/lavf.mxf
 ./tests/data/lavf/lavf.mxf CRC=0x8dddfaab
diff --git a/tests/ref/lavf/mxf_d10 b/tests/ref/lavf/mxf_d10
index 2384d427b0..3af1d7e2d7 100644
--- a/tests/ref/lavf/mxf_d10
+++ b/tests/ref/lavf/mxf_d10
@@ -1,3 +1,3 @@
-f4694941b0cd5b5e3c91064d84dbd345 *./tests/data/lavf/lavf.mxf_d10
-5330989 ./tests/data/lavf/lavf.mxf_d10
+3c256050ae20973760dd4e72d854d0dc *./tests/data/lavf/lavf.mxf_d10
+5331501 ./tests/data/lavf/lavf.mxf_d10
 ./tests/data/lavf/lavf.mxf_d10 CRC=0x6c74d488
diff --git a/tests/ref/lavf/mxf_dv25 b/tests/ref/lavf/mxf_dv25
index e836b14240..9d95083393 100644
--- a/tests/ref/lavf/mxf_dv25
+++ b/tests/ref/lavf/mxf_dv25
@@ -1,3 +1,3 @@
-1ca8143bf6cf322fd39f6e856959d502 *./tests/data/lavf/lavf.mxf_dv25
-3833389 ./tests/data/lavf/lavf.mxf_dv25
+aed946d56c81da2f01974b3805d56f87 *./tests/data/lavf/lavf.mxf_dv25
+3833901 ./tests/data/lavf/lavf.mxf_dv25
 ./tests/data/lavf/lavf.mxf_dv25 CRC=0xbdaf7f52
diff --git a/tests/ref/lavf/mxf_dvcpro50 b/tests/ref/lavf/mxf_dvcpro50
index bb3d6b928a..2965be97c3 100644
--- a/tests/ref/lavf/mxf_dvcpro50
+++ b/tests/ref/lavf/mxf_dvcpro50
@@ -1,3 +1,3 @@
-987fd4b2abb36433fba0e35f4092efc6 *./tests/data/lavf/lavf.mxf_dvcpro50
-7430189 ./tests/data/lavf/lavf.mxf_dvcpro50
+e9cecd6f83c7bff8c41195ce23b3d0b2 *./tests/data/lavf/lavf.mxf_dvcpro50
+7430701 ./tests/data/lavf/lavf.mxf_dvcpro50
 ./tests/data/lavf/lavf.mxf_dvcpro50 CRC=0xe3bbe4b4
diff --git a/tests/ref/lavf/mxf_opatom b/tests/ref/lavf/mxf_opatom
index 1cc612e627..6369e91198 100644
--- a/tests/ref/lavf/mxf_opatom
+++ b/tests/ref/lavf/mxf_opatom
@@ -1,3 +1,3 @@
-b8fe60f7457b83709f33357d04c8db0c *./tests/data/lavf/lavf.mxf_opatom
+e8f8bce1c9c92c678f0e9b3350984282 *./tests/data/lavf/lavf.mxf_opatom
 4717113 ./tests/data/lavf/lavf.mxf_opatom
 ./tests/data/lavf/lavf.mxf_opatom CRC=0xf55aa22a
diff --git a/tests/ref/lavf/mxf_opatom_audio b/tests/ref/lavf/mxf_opatom_audio
index deed55e526..57c957853a 100644
--- a/tests/ref/lavf/mxf_opatom_audio
+++ b/tests/ref/lavf/mxf_opatom_audio
@@ -1,3 +1,3 @@
-e7da52bd591e6eddb4e1af381a4e5bd4 *./tests/data/lavf/lavf.mxf_opatom_audio
-101945 ./tests/data/lavf/lavf.mxf_opatom_audio

[FFmpeg-devel] [PATCH 09/13] avformat/mxfenc: Add Padding Bits

2018-05-07 Thread Michael Niedermayer
Signed-off-by: Michael Niedermayer 
---
 libavformat/mxfenc.c| 7 ++-
 tests/ref/fate/copy-trac4914| 2 +-
 tests/ref/fate/mxf-reel_name| 2 +-
 tests/ref/fate/time_base| 2 +-
 tests/ref/lavf/mxf  | 6 +++---
 tests/ref/lavf/mxf_d10  | 2 +-
 tests/ref/lavf/mxf_dv25 | 2 +-
 tests/ref/lavf/mxf_dvcpro50 | 2 +-
 tests/ref/lavf/mxf_opatom   | 2 +-
 tests/ref/lavf/mxf_opatom_audio | 2 +-
 10 files changed, 17 insertions(+), 12 deletions(-)

diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
index 722830615e..f2be76cc86 100644
--- a/libavformat/mxfenc.c
+++ b/libavformat/mxfenc.c
@@ -500,6 +500,7 @@ static const MXFLocalTagPair mxf_local_tag_batch[] = {
 { 0x3302, 
{0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x01,0x04,0x01,0x05,0x01,0x05,0x00,0x00,0x00}},
 /* Horizontal Subsampling */
 { 0x3308, 
{0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x02,0x04,0x01,0x05,0x01,0x10,0x00,0x00,0x00}},
 /* Vertical Subsampling */
 { 0x3303, 
{0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x01,0x04,0x01,0x05,0x01,0x06,0x00,0x00,0x00}},
 /* Color Siting */
+{ 0x3307, 
{0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x02,0x04,0x18,0x01,0x04,0x00,0x00,0x00,0x00}},
 /* Padding Bits */
 { 0x3304, 
{0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x01,0x04,0x01,0x05,0x03,0x03,0x00,0x00,0x00}},
 /* Black Ref level */
 { 0x3305, 
{0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x01,0x04,0x01,0x05,0x03,0x04,0x00,0x00,0x00}},
 /* White Ref level */
 { 0x3306, 
{0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x02,0x04,0x01,0x05,0x03,0x05,0x00,0x00,0x00}},
 /* Color Range */
@@ -1147,7 +1148,7 @@ static void mxf_write_cdci_common(AVFormatContext *s, 
AVStream *st, const UID ke
 int stored_height = (st->codecpar->height+15)/16*16;
 int display_height;
 int f1, f2;
-unsigned desc_size = size+8+8+8+8+8+8+8+5+16+4+12+20+5 + 5*8;
+unsigned desc_size = size+8+8+8+8+8+8+8+5+16+4+12+20+5 + 5*8 + 6;
 if (sc->interlaced && sc->field_dominance)
 desc_size += 5;
 if (sc->signal_standard)
@@ -1228,6 +1229,10 @@ static void mxf_write_cdci_common(AVFormatContext *s, 
AVStream *st, const UID ke
 mxf_write_local_tag(pb, 1, 0x3303);
 avio_w8(pb, sc->color_siting);
 
+// Padding Bits
+mxf_write_local_tag(pb, 2, 0x3307);
+avio_wb16(pb, 0);
+
 if (st->codecpar->color_range != AVCOL_RANGE_UNSPECIFIED) {
 int black = 0,
 white = (1

[FFmpeg-devel] [PATCH 13/13] avformat/mxfenc: Write transfer characteristic

2018-05-07 Thread Michael Niedermayer
Signed-off-by: Michael Niedermayer 
---
 libavformat/mxfenc.c| 39 +
 tests/ref/fate/copy-trac4914|  2 +-
 tests/ref/fate/mxf-reel_name|  2 +-
 tests/ref/fate/time_base|  2 +-
 tests/ref/lavf/mxf  |  6 ++---
 tests/ref/lavf/mxf_d10  |  2 +-
 tests/ref/lavf/mxf_dv25 |  2 +-
 tests/ref/lavf/mxf_dvcpro50 |  2 +-
 tests/ref/lavf/mxf_opatom   |  2 +-
 tests/ref/lavf/mxf_opatom_audio |  2 +-
 10 files changed, 50 insertions(+), 11 deletions(-)

diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
index eda26e1a3f..8443334512 100644
--- a/libavformat/mxfenc.c
+++ b/libavformat/mxfenc.c
@@ -492,6 +492,7 @@ static const MXFLocalTagPair mxf_local_tag_batch[] = {
 { 0x320B, 
{0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x01,0x04,0x01,0x05,0x01,0x0E,0x00,0x00,0x00}},
 /* Presentation Y offset */
 { 0x3217, 
{0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x05,0x04,0x01,0x03,0x02,0x07,0x00,0x00,0x00}},
 /* Display F2 offset */
 { 0x320E, 
{0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x01,0x04,0x01,0x01,0x01,0x01,0x00,0x00,0x00}},
 /* Aspect Ratio */
+{ 0x3210, 
{0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x02,0x04,0x01,0x02,0x01,0x01,0x01,0x02,0x00}},
 /* Transfer characteristic */
 { 0x3213, 
{0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x02,0x04,0x18,0x01,0x02,0x00,0x00,0x00,0x00}},
 /* Image Start Offset */
 { 0x3214, 
{0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x02,0x04,0x18,0x01,0x03,0x00,0x00,0x00,0x00}},
 /* Image End Offset */
 { 0x3201, 
{0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x02,0x04,0x01,0x06,0x01,0x00,0x00,0x00,0x00}},
 /* Picture Essence Coding */
@@ -1143,6 +1144,34 @@ static const UID mxf_aes3_descriptor_key  = { 
0x06,0x0E,0x2B,0x34,0x02,0x53,
 static const UID mxf_cdci_descriptor_key  = { 
0x06,0x0E,0x2B,0x34,0x02,0x53,0x01,0x01,0x0D,0x01,0x01,0x01,0x01,0x01,0x28,0x00 
};
 static const UID mxf_generic_sound_descriptor_key = { 
0x06,0x0E,0x2B,0x34,0x02,0x53,0x01,0x01,0x0D,0x01,0x01,0x01,0x01,0x01,0x42,0x00 
};
 
+static int get_trc(UID ul, enum AVColorTransferCharacteristic trc)
+{
+switch (trc){
+case AVCOL_TRC_GAMMA28   :
+case AVCOL_TRC_GAMMA22   :
+memcpy(ul, 
(UID){0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x04,0x01,0x01,0x01,0x01,0x01,0x00,0x00},
 16);
+return 0;
+case AVCOL_TRC_BT709 :
+case AVCOL_TRC_SMPTE170M :
+memcpy(ul, 
(UID){0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x04,0x01,0x01,0x01,0x01,0x02,0x00,0x00},
 16);
+return 0;
+case AVCOL_TRC_SMPTE240M :
+memcpy(ul, 
(UID){0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x04,0x01,0x01,0x01,0x01,0x03,0x00,0x00},
 16);
+return 0;
+case AVCOL_TRC_BT1361_ECG:
+memcpy(ul, 
(UID){0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x06,0x04,0x01,0x01,0x01,0x01,0x05,0x00,0x00},
 16);
+return 0;
+case AVCOL_TRC_LINEAR:
+memcpy(ul, 
(UID){0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x06,0x04,0x01,0x01,0x01,0x01,0x06,0x00,0x00},
 16);
+return 0;
+case AVCOL_TRC_SMPTE428  :
+memcpy(ul, 
(UID){0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x08,0x04,0x01,0x01,0x01,0x01,0x07,0x00,0x00},
 16);
+return 0;
+default:
+return -1;
+}
+}
+
 static void mxf_write_cdci_common(AVFormatContext *s, AVStream *st, const UID 
key, unsigned size)
 {
 MXFStreamContext *sc = st->priv_data;
@@ -1152,6 +1181,8 @@ static void mxf_write_cdci_common(AVFormatContext *s, 
AVStream *st, const UID ke
 int display_height;
 int f1, f2;
 unsigned desc_size = size+8+8+8+8+8+8+8+5+16+4+12+20+5 + 5*8 + 6;
+UID transfer_ul = {0};
+
 if (sc->interlaced && sc->field_dominance)
 desc_size += 5;
 if (sc->signal_standard)
@@ -1164,6 +1195,8 @@ static void mxf_write_cdci_common(AVFormatContext *s, 
AVStream *st, const UID ke
 desc_size += 8 * 3;
 if (s->oformat == _mxf_d10_muxer)
 desc_size += 8 + 8 + 8;
+if (get_trc(transfer_ul, st->codecpar->color_trc) >= 0)
+desc_size += 20;
 
 mxf_write_generic_desc(s, st, key, desc_size);
 
@@ -1305,6 +1338,12 @@ static void mxf_write_cdci_common(AVFormatContext *s, 
AVStream *st, const UID ke
 avio_wb32(pb, sc->aspect_ratio.num);
 avio_wb32(pb, sc->aspect_ratio.den);
 
+//Transfer characteristic
+if (transfer_ul[0]) {
+mxf_write_local_tag(pb, 16, 0x3210);
+avio_write(pb, transfer_ul, 16);
+};
+
 mxf_write_local_tag(pb, 16, 0x3201);
 avio_write(pb, *sc->codec_ul, 16);
 
diff --git a/tests/ref/fate/copy-trac4914 b/tests/ref/fate/copy-trac4914
index 4cadb21adc..a805699374 100644
--- a/tests/ref/fate/copy-trac4914
+++ b/tests/ref/fate/copy-trac4914
@@ -1,4 +1,4 @@
-ccce4918a1a4682cf431e7bb14b8120d *tests/data/fate/copy-trac4914.mxf
+ed7921a1218fce5ca0fd27217ddd7863 *tests/data/fate/copy-trac4914.mxf
 561721 tests/data/fate/copy-trac4914.mxf
 #tb 0: 1001/3
 #media_type 0: video
diff --git a/tests/ref/fate/mxf-reel_name 

[FFmpeg-devel] [PATCH 11/13] avformat/mxfenc: Write Audio Ref Level for D10

2018-05-07 Thread Michael Niedermayer
Signed-off-by: Michael Niedermayer 
---
 libavformat/mxfenc.c| 8 
 tests/ref/fate/copy-trac4914| 2 +-
 tests/ref/fate/mxf-reel_name| 2 +-
 tests/ref/fate/time_base| 2 +-
 tests/ref/lavf/mxf  | 6 +++---
 tests/ref/lavf/mxf_d10  | 2 +-
 tests/ref/lavf/mxf_dv25 | 2 +-
 tests/ref/lavf/mxf_dvcpro50 | 2 +-
 tests/ref/lavf/mxf_opatom   | 2 +-
 tests/ref/lavf/mxf_opatom_audio | 2 +-
 10 files changed, 19 insertions(+), 11 deletions(-)

diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
index adf5527534..d57f5372c6 100644
--- a/libavformat/mxfenc.c
+++ b/libavformat/mxfenc.c
@@ -507,6 +507,7 @@ static const MXFLocalTagPair mxf_local_tag_batch[] = {
 // Generic Sound Essence Descriptor
 { 0x3D02, 
{0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x04,0x04,0x02,0x03,0x01,0x04,0x00,0x00,0x00}},
 /* Locked/Unlocked */
 { 0x3D03, 
{0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x05,0x04,0x02,0x03,0x01,0x01,0x01,0x00,0x00}},
 /* Audio sampling rate */
+{ 0x3D04, 
{0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x01,0x04,0x02,0x01,0x01,0x03,0x00,0x00,0x00}},
 /* Audio Ref Level */
 { 0x3D07, 
{0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x05,0x04,0x02,0x01,0x01,0x04,0x00,0x00,0x00}},
 /* ChannelCount */
 { 0x3D01, 
{0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x04,0x04,0x02,0x03,0x03,0x04,0x00,0x00,0x00}},
 /* Quantization bits */
 { 0x3D06, 
{0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x02,0x04,0x02,0x04,0x02,0x00,0x00,0x00,0x00}},
 /* Sound Essence Compression */
@@ -1333,6 +1334,8 @@ static void 
mxf_write_generic_sound_common(AVFormatContext *s, AVStream *st, con
 
 if (s->oformat == _mxf_opatom_muxer)
 duration_size = 12;
+if (s->oformat == _mxf_d10_muxer)
+size += 5;
 
 mxf_write_generic_desc(s, st, key, size+duration_size+5+12+8+8);
 
@@ -1350,6 +1353,11 @@ static void 
mxf_write_generic_sound_common(AVFormatContext *s, AVStream *st, con
 avio_wb32(pb, st->codecpar->sample_rate);
 avio_wb32(pb, 1);
 
+if (s->oformat == _mxf_d10_muxer) {
+mxf_write_local_tag(pb, 1, 0x3D04);
+avio_w8(pb, 0);
+}
+
 mxf_write_local_tag(pb, 4, 0x3D07);
 if (mxf->channel_count == -1) {
 if (show_warnings && (s->oformat == _mxf_d10_muxer) && 
(st->codecpar->channels != 4) && (st->codecpar->channels != 8))
diff --git a/tests/ref/fate/copy-trac4914 b/tests/ref/fate/copy-trac4914
index e3266abeb9..8bd8a23eef 100644
--- a/tests/ref/fate/copy-trac4914
+++ b/tests/ref/fate/copy-trac4914
@@ -1,4 +1,4 @@
-298afac2f4ddfed331294981160023f0 *tests/data/fate/copy-trac4914.mxf
+0576133def482f672d56369bc945f9d2 *tests/data/fate/copy-trac4914.mxf
 561721 tests/data/fate/copy-trac4914.mxf
 #tb 0: 1001/3
 #media_type 0: video
diff --git a/tests/ref/fate/mxf-reel_name b/tests/ref/fate/mxf-reel_name
index b9beffef66..8c3469de61 100644
--- a/tests/ref/fate/mxf-reel_name
+++ b/tests/ref/fate/mxf-reel_name
@@ -1 +1 @@
-471e8a7d012fb2b00835aadd5fe648c7
+a1a1e8df772ef28380ce95f12e7e8cb8
diff --git a/tests/ref/fate/time_base b/tests/ref/fate/time_base
index acda7c5fcf..aed683221d 100644
--- a/tests/ref/fate/time_base
+++ b/tests/ref/fate/time_base
@@ -1 +1 @@
-68608a7f54b8fe3a85cd387e64bab764
+8149dfa839d55d7f0c127d66ebe86433
diff --git a/tests/ref/lavf/mxf b/tests/ref/lavf/mxf
index 9f5818e0af..c2bc32bcf6 100644
--- a/tests/ref/lavf/mxf
+++ b/tests/ref/lavf/mxf
@@ -1,9 +1,9 @@
-408b3758c11af3210c722a52d2754d8c *./tests/data/lavf/lavf.mxf
+0e342e262c9ad13b3d4758e3666f453e *./tests/data/lavf/lavf.mxf
 526393 ./tests/data/lavf/lavf.mxf
 ./tests/data/lavf/lavf.mxf CRC=0x8dddfaab
-76d3bec8f170e389da50a82075c8bf83 *./tests/data/lavf/lavf.mxf
+9d30acfb4cd73cfa6e46a01eea625521 *./tests/data/lavf/lavf.mxf
 561721 ./tests/data/lavf/lavf.mxf
 ./tests/data/lavf/lavf.mxf CRC=0xf21b1b48
-caa15603349cb79d11b75a7c6ad633ab *./tests/data/lavf/lavf.mxf
+76dfdb299f0ae2ed5094405dcd130d25 *./tests/data/lavf/lavf.mxf
 526393 ./tests/data/lavf/lavf.mxf
 ./tests/data/lavf/lavf.mxf CRC=0x8dddfaab
diff --git a/tests/ref/lavf/mxf_d10 b/tests/ref/lavf/mxf_d10
index e73cd5d24f..fae3f40168 100644
--- a/tests/ref/lavf/mxf_d10
+++ b/tests/ref/lavf/mxf_d10
@@ -1,3 +1,3 @@
-eb9412edd406c02e4d2ac2380748186b *./tests/data/lavf/lavf.mxf_d10
+7bad01ac8e0f223477f89a7443708ca8 *./tests/data/lavf/lavf.mxf_d10
 5332013 ./tests/data/lavf/lavf.mxf_d10
 ./tests/data/lavf/lavf.mxf_d10 CRC=0x6c74d488
diff --git a/tests/ref/lavf/mxf_dv25 b/tests/ref/lavf/mxf_dv25
index 8635484f17..c54b556a4d 100644
--- a/tests/ref/lavf/mxf_dv25
+++ b/tests/ref/lavf/mxf_dv25
@@ -1,3 +1,3 @@
-eddb23aba03c1c0499928bca27d43795 *./tests/data/lavf/lavf.mxf_dv25
+10abfd24b120f93b79d3da0f0677c449 *./tests/data/lavf/lavf.mxf_dv25
 3834413 ./tests/data/lavf/lavf.mxf_dv25
 ./tests/data/lavf/lavf.mxf_dv25 CRC=0xbdaf7f52
diff --git a/tests/ref/lavf/mxf_dvcpro50 b/tests/ref/lavf/mxf_dvcpro50
index 5df967054c..cd581528a1 100644
--- a/tests/ref/lavf/mxf_dvcpro50
+++ b/tests/ref/lavf/mxf_dvcpro50

[FFmpeg-devel] [PATCH 05/13] avformat/mxfenc: Fix stored width

2018-05-07 Thread Michael Niedermayer
This fixes the width to have computations matching the height

Signed-off-by: Michael Niedermayer 
---
 libavformat/mxfenc.c  |   3 +-
 .../ref/fate/concat-demuxer-extended-lavf-mxf |   2 +-
 .../fate/concat-demuxer-extended-lavf-mxf_d10 |   2 +-
 .../ref/fate/concat-demuxer-simple1-lavf-mxf  | 242 +-
 .../fate/concat-demuxer-simple1-lavf-mxf_d10  | 140 +-
 tests/ref/seek/lavf-mxf   |  44 ++--
 tests/ref/seek/lavf-mxf_d10   |  54 ++--
 tests/ref/seek/lavf-mxf_dv25  |  54 ++--
 tests/ref/seek/lavf-mxf_dvcpro50  |  54 ++--
 tests/ref/seek/lavf-mxf_opatom_audio  |  54 ++--
 10 files changed, 325 insertions(+), 324 deletions(-)

diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
index f0fd406493..9140302b81 100644
--- a/libavformat/mxfenc.c
+++ b/libavformat/mxfenc.c
@@ -1131,6 +1131,7 @@ static void mxf_write_cdci_common(AVFormatContext *s, 
AVStream *st, const UID ke
 {
 MXFStreamContext *sc = st->priv_data;
 AVIOContext *pb = s->pb;
+int stored_width  = (st->codecpar->width +15)/16*16;
 int stored_height = (st->codecpar->height+15)/16*16;
 int display_height;
 int f1, f2;
@@ -1143,7 +1144,7 @@ static void mxf_write_cdci_common(AVFormatContext *s, 
AVStream *st, const UID ke
 mxf_write_generic_desc(s, st, key, desc_size);
 
 mxf_write_local_tag(pb, 4, 0x3203);
-avio_wb32(pb, st->codecpar->width);
+avio_wb32(pb, stored_width);
 
 mxf_write_local_tag(pb, 4, 0x3202);
 avio_wb32(pb, stored_height>>sc->interlaced);
diff --git a/tests/ref/fate/concat-demuxer-extended-lavf-mxf 
b/tests/ref/fate/concat-demuxer-extended-lavf-mxf
index c47f14faa1..13170c6eaf 100644
--- a/tests/ref/fate/concat-demuxer-extended-lavf-mxf
+++ b/tests/ref/fate/concat-demuxer-extended-lavf-mxf
@@ -1 +1 @@
-7e53f4c5cb0c9afda2771c9f0c697d9c 
*tests/data/fate/concat-demuxer-extended-lavf-mxf.ffprobe
+7c8c500ea386b41e9025487fb4380f5c 
*tests/data/fate/concat-demuxer-extended-lavf-mxf.ffprobe
diff --git a/tests/ref/fate/concat-demuxer-extended-lavf-mxf_d10 
b/tests/ref/fate/concat-demuxer-extended-lavf-mxf_d10
index 75d386e3c1..c3c8591c93 100644
--- a/tests/ref/fate/concat-demuxer-extended-lavf-mxf_d10
+++ b/tests/ref/fate/concat-demuxer-extended-lavf-mxf_d10
@@ -1 +1 @@
-44810fc20072d9d7011b0d2afe59 
*tests/data/fate/concat-demuxer-extended-lavf-mxf_d10.ffprobe
+d87c3a2394c60046636e43848fa8b4f6 
*tests/data/fate/concat-demuxer-extended-lavf-mxf_d10.ffprobe
diff --git a/tests/ref/fate/concat-demuxer-simple1-lavf-mxf 
b/tests/ref/fate/concat-demuxer-simple1-lavf-mxf
index 1174a1e183..4f1d12fe26 100644
--- a/tests/ref/fate/concat-demuxer-simple1-lavf-mxf
+++ b/tests/ref/fate/concat-demuxer-simple1-lavf-mxf
@@ -1,124 +1,124 @@
-video|0|0|0.00|-1|-0.04|1|0.04|N/A|N/A|24801|6144|K_
-audio|1|0|0.00|0|0.00|1920|0.04|N/A|N/A|3840|31232|K_
-video|0|3|0.12|0|0.00|1|0.04|N/A|N/A|16743|35840|__
-audio|1|1920|0.04|1920|0.04|1920|0.04|N/A|N/A|3840|52736|K_
-video|0|1|0.04|1|0.04|1|0.04|N/A|N/A|13812|57344|__
-audio|1|3840|0.08|3840|0.08|1920|0.04|N/A|N/A|3840|71680|K_
-video|0|2|0.08|2|0.08|1|0.04|N/A|N/A|13607|76288|__
-audio|1|5760|0.12|5760|0.12|1920|0.04|N/A|N/A|3840|90112|K_
-video|0|6|0.24|3|0.12|1|0.04|N/A|N/A|16158|94720|__
-audio|1|7680|0.16|7680|0.16|1920|0.04|N/A|N/A|3840|04|K_
-video|0|4|0.16|4|0.16|1|0.04|N/A|N/A|13943|115712|__
-audio|1|9600|0.20|9600|0.20|1920|0.04|N/A|N/A|3840|130048|K_
-video|0|5|0.20|5|0.20|1|0.04|N/A|N/A|11223|134656|__
-audio|1|11520|0.24|11520|0.24|1920|0.04|N/A|N/A|3840|145920|K_
-video|0|9|0.36|6|0.24|1|0.04|N/A|N/A|20298|150528|__
-audio|1|13440|0.28|13440|0.28|1920|0.04|N/A|N/A|3840|171008|K_
-video|0|7|0.28|7|0.28|1|0.04|N/A|N/A|13341|175616|__
-audio|1|15360|0.32|15360|0.32|1920|0.04|N/A|N/A|3840|189440|K_
-video|0|8|0.32|8|0.32|1|0.04|N/A|N/A|12362|194048|__
-audio|1|17280|0.36|17280|0.36|1920|0.04|N/A|N/A|3840|206848|K_
-video|0|12|0.48|9|0.36|1|0.04|N/A|N/A|24786|211456|K_
-audio|1|19200|0.40|19200|0.40|1920|0.04|N/A|N/A|3840|236544|K_
-video|0|10|0.40|10|0.40|1|0.04|N/A|N/A|13377|241152|__
-audio|1|21120|0.44|21120|0.44|1920|0.04|N/A|N/A|3840|254976|K_
-video|0|11|0.44|11|0.44|1|0.04|N/A|N/A|15624|259584|__
-audio|1|23040|0.48|23040|0.48|1920|0.04|N/A|N/A|3840|275456|K_
-video|0|15|0.60|12|0.48|1|0.04|N/A|N/A|22597|280064|__
-audio|1|24960|0.52|24960|0.52|1920|0.04|N/A|N/A|3840|303104|K_
-video|0|13|0.52|13|0.52|1|0.04|N/A|N/A|15028|307712|__
-audio|1|26880|0.56|26880|0.56|1920|0.04|N/A|N/A|3840|323072|K_

[FFmpeg-devel] [PATCH 12/13] avformat/mxfenc: Add Stored F2 Offset / Image Start/End Offset for D10

2018-05-07 Thread Michael Niedermayer
Signed-off-by: Michael Niedermayer 
---
 libavformat/mxfenc.c| 18 ++
 tests/ref/fate/copy-trac4914|  2 +-
 tests/ref/fate/mxf-reel_name|  2 +-
 tests/ref/fate/time_base|  2 +-
 tests/ref/lavf/mxf  |  6 +++---
 tests/ref/lavf/mxf_d10  |  2 +-
 tests/ref/lavf/mxf_dv25 |  2 +-
 tests/ref/lavf/mxf_dvcpro50 |  2 +-
 tests/ref/lavf/mxf_opatom   |  2 +-
 tests/ref/lavf/mxf_opatom_audio |  2 +-
 10 files changed, 29 insertions(+), 11 deletions(-)

diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
index d57f5372c6..eda26e1a3f 100644
--- a/libavformat/mxfenc.c
+++ b/libavformat/mxfenc.c
@@ -492,6 +492,8 @@ static const MXFLocalTagPair mxf_local_tag_batch[] = {
 { 0x320B, 
{0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x01,0x04,0x01,0x05,0x01,0x0E,0x00,0x00,0x00}},
 /* Presentation Y offset */
 { 0x3217, 
{0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x05,0x04,0x01,0x03,0x02,0x07,0x00,0x00,0x00}},
 /* Display F2 offset */
 { 0x320E, 
{0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x01,0x04,0x01,0x01,0x01,0x01,0x00,0x00,0x00}},
 /* Aspect Ratio */
+{ 0x3213, 
{0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x02,0x04,0x18,0x01,0x02,0x00,0x00,0x00,0x00}},
 /* Image Start Offset */
+{ 0x3214, 
{0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x02,0x04,0x18,0x01,0x03,0x00,0x00,0x00,0x00}},
 /* Image End Offset */
 { 0x3201, 
{0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x02,0x04,0x01,0x06,0x01,0x00,0x00,0x00,0x00}},
 /* Picture Essence Coding */
 { 0x3212, 
{0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x02,0x04,0x01,0x03,0x01,0x06,0x00,0x00,0x00}},
 /* Field Dominance (Opt) */
 { 0x3215, 
{0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x05,0x04,0x05,0x01,0x13,0x00,0x00,0x00,0x00}},
 /* Signal Standard */
@@ -1160,6 +1162,8 @@ static void mxf_write_cdci_common(AVFormatContext *s, 
AVStream *st, const UID ke
 desc_size += 8;
 if (st->codecpar->color_range != AVCOL_RANGE_UNSPECIFIED)
 desc_size += 8 * 3;
+if (s->oformat == _mxf_d10_muxer)
+desc_size += 8 + 8 + 8;
 
 mxf_write_generic_desc(s, st, key, desc_size);
 
@@ -1169,6 +1173,20 @@ static void mxf_write_cdci_common(AVFormatContext *s, 
AVStream *st, const UID ke
 mxf_write_local_tag(pb, 4, 0x3202);
 avio_wb32(pb, stored_height>>sc->interlaced);
 
+if (s->oformat == _mxf_d10_muxer) {
+//Stored F2 Offset
+mxf_write_local_tag(pb, 4, 0x3216);
+avio_wb32(pb, 0);
+
+//Image Start Offset
+mxf_write_local_tag(pb, 4, 0x3213);
+avio_wb32(pb, 0);
+
+//Image End Offset
+mxf_write_local_tag(pb, 4, 0x3214);
+avio_wb32(pb, 0);
+}
+
 //Sampled width
 mxf_write_local_tag(pb, 4, 0x3205);
 avio_wb32(pb, st->codecpar->width);
diff --git a/tests/ref/fate/copy-trac4914 b/tests/ref/fate/copy-trac4914
index 8bd8a23eef..4cadb21adc 100644
--- a/tests/ref/fate/copy-trac4914
+++ b/tests/ref/fate/copy-trac4914
@@ -1,4 +1,4 @@
-0576133def482f672d56369bc945f9d2 *tests/data/fate/copy-trac4914.mxf
+ccce4918a1a4682cf431e7bb14b8120d *tests/data/fate/copy-trac4914.mxf
 561721 tests/data/fate/copy-trac4914.mxf
 #tb 0: 1001/3
 #media_type 0: video
diff --git a/tests/ref/fate/mxf-reel_name b/tests/ref/fate/mxf-reel_name
index 8c3469de61..1a1731e431 100644
--- a/tests/ref/fate/mxf-reel_name
+++ b/tests/ref/fate/mxf-reel_name
@@ -1 +1 @@
-a1a1e8df772ef28380ce95f12e7e8cb8
+1ab725f1bbf60e4ac127859727735784
diff --git a/tests/ref/fate/time_base b/tests/ref/fate/time_base
index aed683221d..9ba0e92b58 100644
--- a/tests/ref/fate/time_base
+++ b/tests/ref/fate/time_base
@@ -1 +1 @@
-8149dfa839d55d7f0c127d66ebe86433
+bedb164d507d07714c2a908f4ddb240a
diff --git a/tests/ref/lavf/mxf b/tests/ref/lavf/mxf
index c2bc32bcf6..d20bded186 100644
--- a/tests/ref/lavf/mxf
+++ b/tests/ref/lavf/mxf
@@ -1,9 +1,9 @@
-0e342e262c9ad13b3d4758e3666f453e *./tests/data/lavf/lavf.mxf
+b445776832c7deba50665282a5987f2c *./tests/data/lavf/lavf.mxf
 526393 ./tests/data/lavf/lavf.mxf
 ./tests/data/lavf/lavf.mxf CRC=0x8dddfaab
-9d30acfb4cd73cfa6e46a01eea625521 *./tests/data/lavf/lavf.mxf
+d130f0a9c7404fe4f2e7c975d8fd6a52 *./tests/data/lavf/lavf.mxf
 561721 ./tests/data/lavf/lavf.mxf
 ./tests/data/lavf/lavf.mxf CRC=0xf21b1b48
-76dfdb299f0ae2ed5094405dcd130d25 *./tests/data/lavf/lavf.mxf
+41cd471fe44cd27ec558980c20b71676 *./tests/data/lavf/lavf.mxf
 526393 ./tests/data/lavf/lavf.mxf
 ./tests/data/lavf/lavf.mxf CRC=0x8dddfaab
diff --git a/tests/ref/lavf/mxf_d10 b/tests/ref/lavf/mxf_d10
index fae3f40168..51f26c7b85 100644
--- a/tests/ref/lavf/mxf_d10
+++ b/tests/ref/lavf/mxf_d10
@@ -1,3 +1,3 @@
-7bad01ac8e0f223477f89a7443708ca8 *./tests/data/lavf/lavf.mxf_d10
+d92737f6cceeb61ec6a79dd7a054 *./tests/data/lavf/lavf.mxf_d10
 5332013 ./tests/data/lavf/lavf.mxf_d10
 ./tests/data/lavf/lavf.mxf_d10 CRC=0x6c74d488
diff --git a/tests/ref/lavf/mxf_dv25 b/tests/ref/lavf/mxf_dv25
index c54b556a4d..f6dc12e09b 100644
--- a/tests/ref/lavf/mxf_dv25
+++ 

[FFmpeg-devel] [PATCH 04/13] avformat/mxfenc: Add object model version

2018-05-07 Thread Michael Niedermayer
Signed-off-by: Michael Niedermayer 
---
 libavformat/mxfenc.c| 7 ++-
 tests/ref/fate/copy-trac4914| 2 +-
 tests/ref/fate/mxf-reel_name| 2 +-
 tests/ref/fate/time_base| 2 +-
 tests/ref/lavf/mxf  | 6 +++---
 tests/ref/lavf/mxf_d10  | 2 +-
 tests/ref/lavf/mxf_dv25 | 2 +-
 tests/ref/lavf/mxf_dvcpro50 | 2 +-
 tests/ref/lavf/mxf_opatom   | 2 +-
 tests/ref/lavf/mxf_opatom_audio | 2 +-
 10 files changed, 17 insertions(+), 12 deletions(-)

diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
index 73015816eb..f0fd406493 100644
--- a/libavformat/mxfenc.c
+++ b/libavformat/mxfenc.c
@@ -422,6 +422,7 @@ static const MXFLocalTagPair mxf_local_tag_batch[] = {
 { 0x3C0A, 
{0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x01,0x01,0x01,0x15,0x02,0x00,0x00,0x00,0x00}},
 /* Instance UID */
 { 0x3B02, 
{0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x02,0x07,0x02,0x01,0x10,0x02,0x04,0x00,0x00}},
 /* Last Modified Date */
 { 0x3B05, 
{0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x02,0x03,0x01,0x02,0x01,0x05,0x00,0x00,0x00}},
 /* Version */
+{ 0x3B07, 
{0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x02,0x03,0x01,0x02,0x01,0x04,0x00,0x00,0x00}},
 /* Object Model Version */
 { 0x3B06, 
{0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x02,0x06,0x01,0x01,0x04,0x06,0x04,0x00,0x00}},
 /* Identifications reference */
 { 0x3B03, 
{0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x02,0x06,0x01,0x01,0x04,0x02,0x01,0x00,0x00}},
 /* Content Storage reference */
 { 0x3B09, 
{0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x05,0x01,0x02,0x02,0x03,0x00,0x00,0x00,0x00}},
 /* Operational Pattern UL */
@@ -681,7 +682,7 @@ static void mxf_write_preface(AVFormatContext *s)
 
 mxf_write_metadata_key(pb, 0x012f00);
 PRINT_KEY(s, "preface key", pb->buf_ptr - 16);
-klv_encode_ber_length(pb, 130 + 16LL * 
DESCRIPTOR_COUNT(mxf->essence_container_count));
+klv_encode_ber_length(pb, 138 + 16LL * 
DESCRIPTOR_COUNT(mxf->essence_container_count));
 
 // write preface set uid
 mxf_write_local_tag(pb, 16, 0x3C0A);
@@ -696,6 +697,10 @@ static void mxf_write_preface(AVFormatContext *s)
 mxf_write_local_tag(pb, 2, 0x3B05);
 avio_wb16(pb, 259); // v1.2
 
+// Object Model Version
+mxf_write_local_tag(pb, 4, 0x3B07);
+avio_wb32(pb, 1);
+
 // write identification_refs
 mxf_write_local_tag(pb, 16 + 8, 0x3B06);
 mxf_write_refs_count(pb, 1);
diff --git a/tests/ref/fate/copy-trac4914 b/tests/ref/fate/copy-trac4914
index e5b9ee293e..0d8f09176f 100644
--- a/tests/ref/fate/copy-trac4914
+++ b/tests/ref/fate/copy-trac4914
@@ -1,4 +1,4 @@
-da66943da7ede9d7409c78befa3c1b95 *tests/data/fate/copy-trac4914.mxf
+2bbcbc55eebf305aec776bce60d09f91 *tests/data/fate/copy-trac4914.mxf
 561209 tests/data/fate/copy-trac4914.mxf
 #tb 0: 1001/3
 #media_type 0: video
diff --git a/tests/ref/fate/mxf-reel_name b/tests/ref/fate/mxf-reel_name
index a22d058868..b1a8840d7a 100644
--- a/tests/ref/fate/mxf-reel_name
+++ b/tests/ref/fate/mxf-reel_name
@@ -1 +1 @@
-d35f74e97bb8a3d5cadc1df69d82dcf9
+581d38fa877b2db15615989f335e9eaf
diff --git a/tests/ref/fate/time_base b/tests/ref/fate/time_base
index 13c7eca627..75ec4368a4 100644
--- a/tests/ref/fate/time_base
+++ b/tests/ref/fate/time_base
@@ -1 +1 @@
-6222dfa98933f06afb9992ab6c21486c
+0979b614a34f668eb47278448b254000
diff --git a/tests/ref/lavf/mxf b/tests/ref/lavf/mxf
index c9a1ce8544..a09c8e1bab 100644
--- a/tests/ref/lavf/mxf
+++ b/tests/ref/lavf/mxf
@@ -1,9 +1,9 @@
-707059147bb7569509cf3b697b54d701 *./tests/data/lavf/lavf.mxf
+e3f486ec383f9df4e4e7063959c88dd5 *./tests/data/lavf/lavf.mxf
 525881 ./tests/data/lavf/lavf.mxf
 ./tests/data/lavf/lavf.mxf CRC=0x8dddfaab
-5af94bc17e47190a1e2943a461c836ff *./tests/data/lavf/lavf.mxf
+4de1237dea5f8377eed4c8effe037ffb *./tests/data/lavf/lavf.mxf
 561209 ./tests/data/lavf/lavf.mxf
 ./tests/data/lavf/lavf.mxf CRC=0xf21b1b48
-523ed9d06ab7a4090f9a29fa7abf7a03 *./tests/data/lavf/lavf.mxf
+73dec65269c3f5ebe67e4e7fa6f2f6b7 *./tests/data/lavf/lavf.mxf
 525881 ./tests/data/lavf/lavf.mxf
 ./tests/data/lavf/lavf.mxf CRC=0x8dddfaab
diff --git a/tests/ref/lavf/mxf_d10 b/tests/ref/lavf/mxf_d10
index 2e6e13f1ce..62b96b4ba6 100644
--- a/tests/ref/lavf/mxf_d10
+++ b/tests/ref/lavf/mxf_d10
@@ -1,3 +1,3 @@
-07a242f1881f0349e4ed10a4f1584ddb *./tests/data/lavf/lavf.mxf_d10
+ea6d7025d72df9aaf63bdbc2be8c82dc *./tests/data/lavf/lavf.mxf_d10
 5331501 ./tests/data/lavf/lavf.mxf_d10
 ./tests/data/lavf/lavf.mxf_d10 CRC=0x6c74d488
diff --git a/tests/ref/lavf/mxf_dv25 b/tests/ref/lavf/mxf_dv25
index e192f91fe2..323abc330b 100644
--- a/tests/ref/lavf/mxf_dv25
+++ b/tests/ref/lavf/mxf_dv25
@@ -1,3 +1,3 @@
-8117b64eaee48b9b6f8be964afbed8e0 *./tests/data/lavf/lavf.mxf_dv25
+2f8cb1656178419950a9a3505cae3f5b *./tests/data/lavf/lavf.mxf_dv25
 3833901 ./tests/data/lavf/lavf.mxf_dv25
 ./tests/data/lavf/lavf.mxf_dv25 CRC=0xbdaf7f52
diff --git a/tests/ref/lavf/mxf_dvcpro50 b/tests/ref/lavf/mxf_dvcpro50
index 4d6b45de90..5e93737904 100644
--- 

[FFmpeg-devel] [PATCH 06/13] avformat/mxfenc: Add Sample width/height/x offset/y offset, Display x offset and F2 offset

2018-05-07 Thread Michael Niedermayer
Signed-off-by: Michael Niedermayer 
---
 libavformat/mxfenc.c| 39 +++--
 tests/ref/fate/copy-trac4914|  4 ++--
 tests/ref/fate/mxf-reel_name|  2 +-
 tests/ref/fate/time_base|  2 +-
 tests/ref/lavf/mxf  | 12 +-
 tests/ref/lavf/mxf_d10  |  4 ++--
 tests/ref/lavf/mxf_dv25 |  4 ++--
 tests/ref/lavf/mxf_dvcpro50 |  4 ++--
 tests/ref/lavf/mxf_opatom   |  4 ++--
 tests/ref/lavf/mxf_opatom_audio |  4 ++--
 10 files changed, 57 insertions(+), 22 deletions(-)

diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
index 9140302b81..e79e1ec7e6 100644
--- a/libavformat/mxfenc.c
+++ b/libavformat/mxfenc.c
@@ -480,9 +480,16 @@ static const MXFLocalTagPair mxf_local_tag_batch[] = {
 { 0x320D, 
{0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x02,0x04,0x01,0x03,0x02,0x05,0x00,0x00,0x00}},
 /* Video Line Map */
 { 0x3203, 
{0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x01,0x04,0x01,0x05,0x02,0x02,0x00,0x00,0x00}},
 /* Stored Width */
 { 0x3202, 
{0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x01,0x04,0x01,0x05,0x02,0x01,0x00,0x00,0x00}},
 /* Stored Height */
+{ 0x3216, 
{0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x05,0x04,0x01,0x03,0x02,0x08,0x00,0x00,0x00}},
 /* Stored F2 Offset */
+{ 0x3205, 
{0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x01,0x04,0x01,0x05,0x01,0x08,0x00,0x00,0x00}},
 /* Sampled Width */
+{ 0x3204, 
{0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x01,0x04,0x01,0x05,0x01,0x07,0x00,0x00,0x00}},
 /* Sampled Height */
+{ 0x3206, 
{0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x01,0x04,0x01,0x05,0x01,0x09,0x00,0x00,0x00}},
 /* Sampled X Offset */
+{ 0x3207, 
{0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x01,0x04,0x01,0x05,0x01,0x0A,0x00,0x00,0x00}},
 /* Sampled Y Offset */
 { 0x3209, 
{0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x01,0x04,0x01,0x05,0x01,0x0C,0x00,0x00,0x00}},
 /* Display Width */
 { 0x3208, 
{0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x01,0x04,0x01,0x05,0x01,0x0B,0x00,0x00,0x00}},
 /* Display Height */
+{ 0x320A, 
{0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x01,0x04,0x01,0x05,0x01,0x0D,0x00,0x00,0x00}},
 /* Display X offset */
 { 0x320B, 
{0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x01,0x04,0x01,0x05,0x01,0x0E,0x00,0x00,0x00}},
 /* Presentation Y offset */
+{ 0x3217, 
{0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x05,0x04,0x01,0x03,0x02,0x07,0x00,0x00,0x00}},
 /* Display F2 offset */
 { 0x320E, 
{0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x01,0x04,0x01,0x01,0x01,0x01,0x00,0x00,0x00}},
 /* Aspect Ratio */
 { 0x3201, 
{0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x02,0x04,0x01,0x06,0x01,0x00,0x00,0x00,0x00}},
 /* Picture Essence Coding */
 { 0x3212, 
{0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x02,0x04,0x01,0x03,0x01,0x06,0x00,0x00,0x00}},
 /* Field Dominance (Opt) */
@@ -1135,11 +1142,13 @@ static void mxf_write_cdci_common(AVFormatContext *s, 
AVStream *st, const UID ke
 int stored_height = (st->codecpar->height+15)/16*16;
 int display_height;
 int f1, f2;
-unsigned desc_size = size+8+8+8+8+8+8+8+5+16+4+12+20+5;
+unsigned desc_size = size+8+8+8+8+8+8+8+5+16+4+12+20+5 + 5*8;
 if (sc->interlaced && sc->field_dominance)
 desc_size += 5;
 if (sc->signal_standard)
 desc_size += 5;
+if (sc->interlaced)
+desc_size += 8;
 
 mxf_write_generic_desc(s, st, key, desc_size);
 
@@ -1149,6 +1158,22 @@ static void mxf_write_cdci_common(AVFormatContext *s, 
AVStream *st, const UID ke
 mxf_write_local_tag(pb, 4, 0x3202);
 avio_wb32(pb, stored_height>>sc->interlaced);
 
+//Sampled width
+mxf_write_local_tag(pb, 4, 0x3205);
+avio_wb32(pb, st->codecpar->width);
+
+//Samples height
+mxf_write_local_tag(pb, 4, 0x3204);
+avio_wb32(pb, st->codecpar->height>>sc->interlaced);
+
+//Sampled X Offset
+mxf_write_local_tag(pb, 4, 0x3206);
+avio_wb32(pb, 0);
+
+//Sampled Y Offset
+mxf_write_local_tag(pb, 4, 0x3207);
+avio_wb32(pb, 0);
+
 mxf_write_local_tag(pb, 4, 0x3209);
 avio_wb32(pb, st->codecpar->width);
 
@@ -1162,10 +1187,20 @@ static void mxf_write_cdci_common(AVFormatContext *s, 
AVStream *st, const UID ke
 mxf_write_local_tag(pb, 4, 0x3208);
 avio_wb32(pb, display_height>>sc->interlaced);
 
-// presentation Y offset
+// display X offset
+mxf_write_local_tag(pb, 4, 0x320A);
+avio_wb32(pb, 0);
+
+// display Y offset
 mxf_write_local_tag(pb, 4, 0x320B);
 avio_wb32(pb, (st->codecpar->height - display_height)>>sc->interlaced);
 
+if (sc->interlaced) {
+//Display F2 Offset
+mxf_write_local_tag(pb, 4, 0x3217);
+avio_wb32(pb, -((st->codecpar->height - display_height)&1));
+}
+
 // component depth
 mxf_write_local_tag(pb, 4, 0x3301);
 avio_wb32(pb, sc->component_depth);
diff --git a/tests/ref/fate/copy-trac4914 b/tests/ref/fate/copy-trac4914
index 0d8f09176f..8f060eec38 100644
--- a/tests/ref/fate/copy-trac4914
+++ b/tests/ref/fate/copy-trac4914
@@ -1,5 +1,5 @@

[FFmpeg-devel] [PATCH 03/13] avformat/mxfenc: Add Product Version, Toolkit version and Platform

2018-05-07 Thread Michael Niedermayer
Signed-off-by: Michael Niedermayer 
---
 libavformat/mxfenc.c| 28 +++-
 tests/ref/fate/copy-trac4914|  2 +-
 tests/ref/fate/mxf-reel_name|  2 +-
 tests/ref/fate/time_base|  2 +-
 tests/ref/lavf/mxf  |  6 +++---
 tests/ref/lavf/mxf_d10  |  2 +-
 tests/ref/lavf/mxf_dv25 |  2 +-
 tests/ref/lavf/mxf_dvcpro50 |  2 +-
 tests/ref/lavf/mxf_opatom   |  2 +-
 tests/ref/lavf/mxf_opatom_audio |  2 +-
 10 files changed, 38 insertions(+), 12 deletions(-)

diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
index 00dfce977b..73015816eb 100644
--- a/libavformat/mxfenc.c
+++ b/libavformat/mxfenc.c
@@ -431,9 +431,12 @@ static const MXFLocalTagPair mxf_local_tag_batch[] = {
 { 0x3C09, 
{0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x02,0x05,0x20,0x07,0x01,0x01,0x00,0x00,0x00}},
 /* This Generation UID */
 { 0x3C01, 
{0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x02,0x05,0x20,0x07,0x01,0x02,0x01,0x00,0x00}},
 /* Company Name */
 { 0x3C02, 
{0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x02,0x05,0x20,0x07,0x01,0x03,0x01,0x00,0x00}},
 /* Product Name */
+{ 0x3C03, 
{0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x02,0x05,0x20,0x07,0x01,0x04,0x00,0x00,0x00}},
 /* Product Version */
 { 0x3C04, 
{0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x02,0x05,0x20,0x07,0x01,0x05,0x01,0x00,0x00}},
 /* Version String */
 { 0x3C05, 
{0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x02,0x05,0x20,0x07,0x01,0x07,0x00,0x00,0x00}},
 /* Product ID */
 { 0x3C06, 
{0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x02,0x07,0x02,0x01,0x10,0x02,0x03,0x00,0x00}},
 /* Modification Date */
+{ 0x3C07, 
{0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x02,0x05,0x20,0x07,0x01,0x0A,0x00,0x00,0x00}},
 /* Toolkit Version */
+{ 0x3C08, 
{0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x02,0x05,0x20,0x07,0x01,0x06,0x01,0x00,0x00}},
 /* Platform */
 // Content Storage
 { 0x1901, 
{0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x02,0x06,0x01,0x01,0x04,0x05,0x01,0x00,0x00}},
 /* Package strong reference batch */
 { 0x1902, 
{0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x02,0x06,0x01,0x01,0x04,0x05,0x02,0x00,0x00}},
 /* Package strong reference batch */
@@ -776,6 +779,22 @@ static void mxf_write_local_tag_utf16(AVIOContext *pb, int 
tag, const char *valu
 avio_put_str16be(pb, value);
 }
 
+static void store_version(AVFormatContext *s){
+AVIOContext *pb = s->pb;
+
+if (s->flags & AVFMT_FLAG_BITEXACT) {
+avio_wb16(pb, 0); // major
+avio_wb16(pb, 0); // minor
+avio_wb16(pb, 0); // tertiary
+} else {
+avio_wb16(pb, LIBAVFORMAT_VERSION_MAJOR); // major
+avio_wb16(pb, LIBAVFORMAT_VERSION_MINOR); // minor
+avio_wb16(pb, LIBAVFORMAT_VERSION_MICRO); // tertiary
+}
+avio_wb16(pb, 0); // patch
+avio_wb16(pb, 0); // release
+}
+
 static void mxf_write_identification(AVFormatContext *s)
 {
 MXFContext *mxf = s->priv_data;
@@ -790,7 +809,7 @@ static void mxf_write_identification(AVFormatContext *s)
 
 version = s->flags & AVFMT_FLAG_BITEXACT ?
 "0.0.0" : AV_STRINGIFY(LIBAVFORMAT_VERSION);
-length = 72 + mxf_utf16_local_tag_length(company) +
+length = 100 +mxf_utf16_local_tag_length(company) +
   mxf_utf16_local_tag_length(product) +
   mxf_utf16_local_tag_length(version);
 klv_encode_ber_length(pb, length);
@@ -805,6 +824,10 @@ static void mxf_write_identification(AVFormatContext *s)
 mxf_write_uuid(pb, Identification, 1);
 mxf_write_local_tag_utf16(pb, 0x3C01, company); // Company Name
 mxf_write_local_tag_utf16(pb, 0x3C02, product); // Product Name
+
+mxf_write_local_tag(pb, 10, 0x3C03); // Product Version
+store_version(s);
+
 mxf_write_local_tag_utf16(pb, 0x3C04, version); // Version String
 
 // write product uid
@@ -814,6 +837,9 @@ static void mxf_write_identification(AVFormatContext *s)
 // modification date
 mxf_write_local_tag(pb, 8, 0x3C06);
 avio_wb64(pb, mxf->timestamp);
+
+mxf_write_local_tag(pb, 10, 0x3C07); // Toolkit Version
+store_version(s);
 }
 
 static void mxf_write_content_storage(AVFormatContext *s, MXFPackage 
*packages, int package_count)
diff --git a/tests/ref/fate/copy-trac4914 b/tests/ref/fate/copy-trac4914
index 0964f96fdd..e5b9ee293e 100644
--- a/tests/ref/fate/copy-trac4914
+++ b/tests/ref/fate/copy-trac4914
@@ -1,4 +1,4 @@
-6da61d6b9b654c9b1e8f70be01fae7f7 *tests/data/fate/copy-trac4914.mxf
+da66943da7ede9d7409c78befa3c1b95 *tests/data/fate/copy-trac4914.mxf
 561209 tests/data/fate/copy-trac4914.mxf
 #tb 0: 1001/3
 #media_type 0: video
diff --git a/tests/ref/fate/mxf-reel_name b/tests/ref/fate/mxf-reel_name
index ecd818f539..a22d058868 100644
--- a/tests/ref/fate/mxf-reel_name
+++ b/tests/ref/fate/mxf-reel_name
@@ -1 +1 @@
-3d81a5c7479617d2f082a828db5e1d80
+d35f74e97bb8a3d5cadc1df69d82dcf9
diff --git a/tests/ref/fate/time_base b/tests/ref/fate/time_base
index a1c578acfa..13c7eca627 100644
--- a/tests/ref/fate/time_base

[FFmpeg-devel] [PATCH 07/13] avformat/mxfenc: Add vertical subsampling support

2018-05-07 Thread Michael Niedermayer
Signed-off-by: Michael Niedermayer 
---
 libavformat/mxfenc.c| 11 +++
 tests/ref/fate/copy-trac4914|  2 +-
 tests/ref/fate/mxf-reel_name|  2 +-
 tests/ref/fate/time_base|  2 +-
 tests/ref/lavf/mxf  |  6 +++---
 tests/ref/lavf/mxf_d10  |  2 +-
 tests/ref/lavf/mxf_dv25 |  2 +-
 tests/ref/lavf/mxf_dvcpro50 |  2 +-
 tests/ref/lavf/mxf_opatom   |  2 +-
 tests/ref/lavf/mxf_opatom_audio |  2 +-
 10 files changed, 22 insertions(+), 11 deletions(-)

diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
index e79e1ec7e6..8039be846a 100644
--- a/libavformat/mxfenc.c
+++ b/libavformat/mxfenc.c
@@ -88,6 +88,7 @@ typedef struct MXFStreamContext {
 int color_siting;
 int signal_standard;
 int h_chroma_sub_sample;
+int v_chroma_sub_sample;
 int temporal_reordering;
 AVRational aspect_ratio; ///< display aspect ratio
 int closed_gop;  ///< gop is closed, used in mpeg-2 frame parsing
@@ -497,6 +498,7 @@ static const MXFLocalTagPair mxf_local_tag_batch[] = {
 // CDCI Picture Essence Descriptor
 { 0x3301, 
{0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x02,0x04,0x01,0x05,0x03,0x0A,0x00,0x00,0x00}},
 /* Component Depth */
 { 0x3302, 
{0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x01,0x04,0x01,0x05,0x01,0x05,0x00,0x00,0x00}},
 /* Horizontal Subsampling */
+{ 0x3308, 
{0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x02,0x04,0x01,0x05,0x01,0x10,0x00,0x00,0x00}},
 /* Vertical Subsampling */
 { 0x3303, 
{0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x01,0x04,0x01,0x05,0x01,0x06,0x00,0x00,0x00}},
 /* Color Siting */
 // Generic Sound Essence Descriptor
 { 0x3D02, 
{0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x04,0x04,0x02,0x03,0x01,0x04,0x00,0x00,0x00}},
 /* Locked/Unlocked */
@@ -1149,6 +1151,8 @@ static void mxf_write_cdci_common(AVFormatContext *s, 
AVStream *st, const UID ke
 desc_size += 5;
 if (sc->interlaced)
 desc_size += 8;
+if (sc->v_chroma_sub_sample)
+desc_size += 8;
 
 mxf_write_generic_desc(s, st, key, desc_size);
 
@@ -1209,6 +1213,12 @@ static void mxf_write_cdci_common(AVFormatContext *s, 
AVStream *st, const UID ke
 mxf_write_local_tag(pb, 4, 0x3302);
 avio_wb32(pb, sc->h_chroma_sub_sample);
 
+// vertical subsampling
+if (sc->v_chroma_sub_sample) {
+mxf_write_local_tag(pb, 4, 0x3308);
+avio_wb32(pb, sc->v_chroma_sub_sample);
+}
+
 // color siting
 mxf_write_local_tag(pb, 1, 0x3303);
 avio_w8(pb, sc->color_siting);
@@ -2273,6 +2283,7 @@ static int mxf_write_header(AVFormatContext *s)
 if (pix_desc) {
 sc->component_depth = pix_desc->comp[0].depth;
 sc->h_chroma_sub_sample = 1 << pix_desc->log2_chroma_w;
+sc->v_chroma_sub_sample = 1 << pix_desc->log2_chroma_h;
 }
 switch (ff_choose_chroma_location(s, st)) {
 case AVCHROMA_LOC_TOPLEFT: sc->color_siting = 0; break;
diff --git a/tests/ref/fate/copy-trac4914 b/tests/ref/fate/copy-trac4914
index 8f060eec38..a50a7ecd86 100644
--- a/tests/ref/fate/copy-trac4914
+++ b/tests/ref/fate/copy-trac4914
@@ -1,4 +1,4 @@
-07932de23a28c175e259a8eb1cbfa052 *tests/data/fate/copy-trac4914.mxf
+16e212762efcb66302386c196af2a361 *tests/data/fate/copy-trac4914.mxf
 561721 tests/data/fate/copy-trac4914.mxf
 #tb 0: 1001/3
 #media_type 0: video
diff --git a/tests/ref/fate/mxf-reel_name b/tests/ref/fate/mxf-reel_name
index 7d64903b72..7a9ff7cf58 100644
--- a/tests/ref/fate/mxf-reel_name
+++ b/tests/ref/fate/mxf-reel_name
@@ -1 +1 @@
-acccd2f4898bcea3e0f68d8ca132e6ff
+a6dfa4a37d4d5681ef04a88e9a6b6e6c
diff --git a/tests/ref/fate/time_base b/tests/ref/fate/time_base
index 44db02ee59..23b36b98c1 100644
--- a/tests/ref/fate/time_base
+++ b/tests/ref/fate/time_base
@@ -1 +1 @@
-939abc1a1671fbbdab249ba944fe5b85
+f7e24ab873f0b524f327b1003991dd83
diff --git a/tests/ref/lavf/mxf b/tests/ref/lavf/mxf
index 600c976cc2..8b1599578b 100644
--- a/tests/ref/lavf/mxf
+++ b/tests/ref/lavf/mxf
@@ -1,9 +1,9 @@
-64e49d7e44904049efb1085f0c8ebd51 *./tests/data/lavf/lavf.mxf
+24083dc0939d1d45e4bf27e738816a6f *./tests/data/lavf/lavf.mxf
 526393 ./tests/data/lavf/lavf.mxf
 ./tests/data/lavf/lavf.mxf CRC=0x8dddfaab
-1bc3cd75f2e3a7e1b4586544fa015db1 *./tests/data/lavf/lavf.mxf
+ed1ef4bd833c30ff37cf7b83d6ef1439 *./tests/data/lavf/lavf.mxf
 561721 ./tests/data/lavf/lavf.mxf
 ./tests/data/lavf/lavf.mxf CRC=0xf21b1b48
-0d805c05a9b0078727b3e8797dcaea95 *./tests/data/lavf/lavf.mxf
+a56f5638b1f9c0ffaa74cb1cee6c3455 *./tests/data/lavf/lavf.mxf
 526393 ./tests/data/lavf/lavf.mxf
 ./tests/data/lavf/lavf.mxf CRC=0x8dddfaab
diff --git a/tests/ref/lavf/mxf_d10 b/tests/ref/lavf/mxf_d10
index ae29dcbc58..07b7c24667 100644
--- a/tests/ref/lavf/mxf_d10
+++ b/tests/ref/lavf/mxf_d10
@@ -1,3 +1,3 @@
-5074cc111fe19d9442e2a962dcf9e72d *./tests/data/lavf/lavf.mxf_d10
+ad23b67a8eea7f0f0c67c4b059d3c516 *./tests/data/lavf/lavf.mxf_d10
 5332013 

[FFmpeg-devel] [PATCH 08/13] avformat/mxfenc: add white/black ref /color range

2018-05-07 Thread Michael Niedermayer
Signed-off-by: Michael Niedermayer 
---
 libavformat/mxfenc.c| 22 ++
 tests/ref/fate/copy-trac4914|  2 +-
 tests/ref/fate/mxf-reel_name|  2 +-
 tests/ref/fate/time_base|  2 +-
 tests/ref/lavf/mxf  |  6 +++---
 tests/ref/lavf/mxf_d10  |  2 +-
 tests/ref/lavf/mxf_dv25 |  2 +-
 tests/ref/lavf/mxf_dvcpro50 |  2 +-
 tests/ref/lavf/mxf_opatom   |  2 +-
 tests/ref/lavf/mxf_opatom_audio |  2 +-
 10 files changed, 33 insertions(+), 11 deletions(-)

diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
index 8039be846a..722830615e 100644
--- a/libavformat/mxfenc.c
+++ b/libavformat/mxfenc.c
@@ -500,6 +500,9 @@ static const MXFLocalTagPair mxf_local_tag_batch[] = {
 { 0x3302, 
{0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x01,0x04,0x01,0x05,0x01,0x05,0x00,0x00,0x00}},
 /* Horizontal Subsampling */
 { 0x3308, 
{0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x02,0x04,0x01,0x05,0x01,0x10,0x00,0x00,0x00}},
 /* Vertical Subsampling */
 { 0x3303, 
{0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x01,0x04,0x01,0x05,0x01,0x06,0x00,0x00,0x00}},
 /* Color Siting */
+{ 0x3304, 
{0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x01,0x04,0x01,0x05,0x03,0x03,0x00,0x00,0x00}},
 /* Black Ref level */
+{ 0x3305, 
{0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x01,0x04,0x01,0x05,0x03,0x04,0x00,0x00,0x00}},
 /* White Ref level */
+{ 0x3306, 
{0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x02,0x04,0x01,0x05,0x03,0x05,0x00,0x00,0x00}},
 /* Color Range */
 // Generic Sound Essence Descriptor
 { 0x3D02, 
{0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x04,0x04,0x02,0x03,0x01,0x04,0x00,0x00,0x00}},
 /* Locked/Unlocked */
 { 0x3D03, 
{0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x05,0x04,0x02,0x03,0x01,0x01,0x01,0x00,0x00}},
 /* Audio sampling rate */
@@ -1153,6 +1156,8 @@ static void mxf_write_cdci_common(AVFormatContext *s, 
AVStream *st, const UID ke
 desc_size += 8;
 if (sc->v_chroma_sub_sample)
 desc_size += 8;
+if (st->codecpar->color_range != AVCOL_RANGE_UNSPECIFIED)
+desc_size += 8 * 3;
 
 mxf_write_generic_desc(s, st, key, desc_size);
 
@@ -1223,6 +1228,23 @@ static void mxf_write_cdci_common(AVFormatContext *s, 
AVStream *st, const UID ke
 mxf_write_local_tag(pb, 1, 0x3303);
 avio_w8(pb, sc->color_siting);
 
+if (st->codecpar->color_range != AVCOL_RANGE_UNSPECIFIED) {
+int black = 0,
+white = (1codecpar->color_range == AVCOL_RANGE_MPEG) {
+black = 1   << (sc->component_depth - 4);
+white = 235 << (sc->component_depth - 8);
+color = (14 << (sc->component_depth - 4)) + 1;
+}
+mxf_write_local_tag(pb, 4, 0x3304);
+avio_wb32(pb, black);
+mxf_write_local_tag(pb, 4, 0x3305);
+avio_wb32(pb, white);
+mxf_write_local_tag(pb, 4, 0x3306);
+avio_wb32(pb, color);
+}
+
 if (sc->signal_standard) {
 mxf_write_local_tag(pb, 1, 0x3215);
 avio_w8(pb, sc->signal_standard);
diff --git a/tests/ref/fate/copy-trac4914 b/tests/ref/fate/copy-trac4914
index a50a7ecd86..f868753d45 100644
--- a/tests/ref/fate/copy-trac4914
+++ b/tests/ref/fate/copy-trac4914
@@ -1,4 +1,4 @@
-16e212762efcb66302386c196af2a361 *tests/data/fate/copy-trac4914.mxf
+2296e01ba6794ab91c78d8bc1215a801 *tests/data/fate/copy-trac4914.mxf
 561721 tests/data/fate/copy-trac4914.mxf
 #tb 0: 1001/3
 #media_type 0: video
diff --git a/tests/ref/fate/mxf-reel_name b/tests/ref/fate/mxf-reel_name
index 7a9ff7cf58..50023ce52a 100644
--- a/tests/ref/fate/mxf-reel_name
+++ b/tests/ref/fate/mxf-reel_name
@@ -1 +1 @@
-a6dfa4a37d4d5681ef04a88e9a6b6e6c
+c5752bf1b72694455e1b348cad8660c5
diff --git a/tests/ref/fate/time_base b/tests/ref/fate/time_base
index 23b36b98c1..979aa08972 100644
--- a/tests/ref/fate/time_base
+++ b/tests/ref/fate/time_base
@@ -1 +1 @@
-f7e24ab873f0b524f327b1003991dd83
+6aac6c1a2e367e43d665bdb974bb7679
diff --git a/tests/ref/lavf/mxf b/tests/ref/lavf/mxf
index 8b1599578b..df1c2607c7 100644
--- a/tests/ref/lavf/mxf
+++ b/tests/ref/lavf/mxf
@@ -1,9 +1,9 @@
-24083dc0939d1d45e4bf27e738816a6f *./tests/data/lavf/lavf.mxf
+b2c881236ca2791a6f378545d82a891b *./tests/data/lavf/lavf.mxf
 526393 ./tests/data/lavf/lavf.mxf
 ./tests/data/lavf/lavf.mxf CRC=0x8dddfaab
-ed1ef4bd833c30ff37cf7b83d6ef1439 *./tests/data/lavf/lavf.mxf
+b14305ee249cc9a7f1708737dbd6daa7 *./tests/data/lavf/lavf.mxf
 561721 ./tests/data/lavf/lavf.mxf
 ./tests/data/lavf/lavf.mxf CRC=0xf21b1b48
-a56f5638b1f9c0ffaa74cb1cee6c3455 *./tests/data/lavf/lavf.mxf
+0c8ddc85308c8e00d588c33f2458d4be *./tests/data/lavf/lavf.mxf
 526393 ./tests/data/lavf/lavf.mxf
 ./tests/data/lavf/lavf.mxf CRC=0x8dddfaab
diff --git a/tests/ref/lavf/mxf_d10 b/tests/ref/lavf/mxf_d10
index 07b7c24667..3f91f9c30e 100644
--- a/tests/ref/lavf/mxf_d10
+++ b/tests/ref/lavf/mxf_d10
@@ -1,3 +1,3 @@
-ad23b67a8eea7f0f0c67c4b059d3c516 

[FFmpeg-devel] [PATCH 02/13] avformat/mxfenc: Bump minor versions for S377-1-2009

2018-05-07 Thread Michael Niedermayer
Signed-off-by: Michael Niedermayer 
---
 libavformat/mxfenc.c| 4 ++--
 tests/ref/fate/copy-trac4914| 2 +-
 tests/ref/fate/mxf-reel_name| 2 +-
 tests/ref/fate/time_base| 2 +-
 tests/ref/lavf/mxf  | 6 +++---
 tests/ref/lavf/mxf_d10  | 2 +-
 tests/ref/lavf/mxf_dv25 | 2 +-
 tests/ref/lavf/mxf_dvcpro50 | 2 +-
 tests/ref/lavf/mxf_opatom   | 2 +-
 tests/ref/lavf/mxf_opatom_audio | 2 +-
 10 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
index c0db10b3c2..00dfce977b 100644
--- a/libavformat/mxfenc.c
+++ b/libavformat/mxfenc.c
@@ -691,7 +691,7 @@ static void mxf_write_preface(AVFormatContext *s)
 
 // write version
 mxf_write_local_tag(pb, 2, 0x3B05);
-avio_wb16(pb, 258); // v1.2
+avio_wb16(pb, 259); // v1.2
 
 // write identification_refs
 mxf_write_local_tag(pb, 16 + 8, 0x3B06);
@@ -1710,7 +1710,7 @@ static int mxf_write_partition(AVFormatContext *s, int 
bodysid,
 
 // write partition value
 avio_wb16(pb, 1); // majorVersion
-avio_wb16(pb, 2); // minorVersion
+avio_wb16(pb, 3); // minorVersion
 avio_wb32(pb, KAG_SIZE); // KAGSize
 
 avio_wb64(pb, partition_offset); // ThisPartition
diff --git a/tests/ref/fate/copy-trac4914 b/tests/ref/fate/copy-trac4914
index 06eac9e621..0964f96fdd 100644
--- a/tests/ref/fate/copy-trac4914
+++ b/tests/ref/fate/copy-trac4914
@@ -1,4 +1,4 @@
-9097dd426106c40288262b53cc6fdb83 *tests/data/fate/copy-trac4914.mxf
+6da61d6b9b654c9b1e8f70be01fae7f7 *tests/data/fate/copy-trac4914.mxf
 561209 tests/data/fate/copy-trac4914.mxf
 #tb 0: 1001/3
 #media_type 0: video
diff --git a/tests/ref/fate/mxf-reel_name b/tests/ref/fate/mxf-reel_name
index 7350d2c0bf..ecd818f539 100644
--- a/tests/ref/fate/mxf-reel_name
+++ b/tests/ref/fate/mxf-reel_name
@@ -1 +1 @@
-625c69eb3801368737266128efdd0a8c
+3d81a5c7479617d2f082a828db5e1d80
diff --git a/tests/ref/fate/time_base b/tests/ref/fate/time_base
index 75ec4368a4..a1c578acfa 100644
--- a/tests/ref/fate/time_base
+++ b/tests/ref/fate/time_base
@@ -1 +1 @@
-0979b614a34f668eb47278448b254000
+39441bec6d05cd65adc0f5b8557fe8ad
diff --git a/tests/ref/lavf/mxf b/tests/ref/lavf/mxf
index 1aff1a0509..a5f3db200d 100644
--- a/tests/ref/lavf/mxf
+++ b/tests/ref/lavf/mxf
@@ -1,9 +1,9 @@
-47c67e4309c680ce91df5396541ee31e *./tests/data/lavf/lavf.mxf
+0c59c7eb43abd8fbd9eab41dc0bec1d0 *./tests/data/lavf/lavf.mxf
 525881 ./tests/data/lavf/lavf.mxf
 ./tests/data/lavf/lavf.mxf CRC=0x8dddfaab
-8e5f8bc13d7c888f4b6320f9869d49d5 *./tests/data/lavf/lavf.mxf
+6b0e6f16dfd1ba0524bf14f16d50b86d *./tests/data/lavf/lavf.mxf
 561209 ./tests/data/lavf/lavf.mxf
 ./tests/data/lavf/lavf.mxf CRC=0xf21b1b48
-c49f8d4743c8dcc33fa01e6dcb995a38 *./tests/data/lavf/lavf.mxf
+b9e4dbb9a9b65fadf47509ef2b094fe5 *./tests/data/lavf/lavf.mxf
 525881 ./tests/data/lavf/lavf.mxf
 ./tests/data/lavf/lavf.mxf CRC=0x8dddfaab
diff --git a/tests/ref/lavf/mxf_d10 b/tests/ref/lavf/mxf_d10
index 3af1d7e2d7..6db0d0ea10 100644
--- a/tests/ref/lavf/mxf_d10
+++ b/tests/ref/lavf/mxf_d10
@@ -1,3 +1,3 @@
-3c256050ae20973760dd4e72d854d0dc *./tests/data/lavf/lavf.mxf_d10
+bac717411fd88894e71db6b5268a75bc *./tests/data/lavf/lavf.mxf_d10
 5331501 ./tests/data/lavf/lavf.mxf_d10
 ./tests/data/lavf/lavf.mxf_d10 CRC=0x6c74d488
diff --git a/tests/ref/lavf/mxf_dv25 b/tests/ref/lavf/mxf_dv25
index 9d95083393..b17542bbce 100644
--- a/tests/ref/lavf/mxf_dv25
+++ b/tests/ref/lavf/mxf_dv25
@@ -1,3 +1,3 @@
-aed946d56c81da2f01974b3805d56f87 *./tests/data/lavf/lavf.mxf_dv25
+06549669b096e58a3a57279004532ed2 *./tests/data/lavf/lavf.mxf_dv25
 3833901 ./tests/data/lavf/lavf.mxf_dv25
 ./tests/data/lavf/lavf.mxf_dv25 CRC=0xbdaf7f52
diff --git a/tests/ref/lavf/mxf_dvcpro50 b/tests/ref/lavf/mxf_dvcpro50
index 2965be97c3..64115766b6 100644
--- a/tests/ref/lavf/mxf_dvcpro50
+++ b/tests/ref/lavf/mxf_dvcpro50
@@ -1,3 +1,3 @@
-e9cecd6f83c7bff8c41195ce23b3d0b2 *./tests/data/lavf/lavf.mxf_dvcpro50
+6b3297c1f3af13398719ffd4e194e87b *./tests/data/lavf/lavf.mxf_dvcpro50
 7430701 ./tests/data/lavf/lavf.mxf_dvcpro50
 ./tests/data/lavf/lavf.mxf_dvcpro50 CRC=0xe3bbe4b4
diff --git a/tests/ref/lavf/mxf_opatom b/tests/ref/lavf/mxf_opatom
index 6369e91198..153537e14a 100644
--- a/tests/ref/lavf/mxf_opatom
+++ b/tests/ref/lavf/mxf_opatom
@@ -1,3 +1,3 @@
-e8f8bce1c9c92c678f0e9b3350984282 *./tests/data/lavf/lavf.mxf_opatom
+e1568a9638de2883ca8cfa63c044432c *./tests/data/lavf/lavf.mxf_opatom
 4717113 ./tests/data/lavf/lavf.mxf_opatom
 ./tests/data/lavf/lavf.mxf_opatom CRC=0xf55aa22a
diff --git a/tests/ref/lavf/mxf_opatom_audio b/tests/ref/lavf/mxf_opatom_audio
index 57c957853a..ffddde0f3a 100644
--- a/tests/ref/lavf/mxf_opatom_audio
+++ b/tests/ref/lavf/mxf_opatom_audio
@@ -1,3 +1,3 @@
-2fc8da147ec62c5ba98598bbb2737515 *./tests/data/lavf/lavf.mxf_opatom_audio
+63a33b96d0a8e10d5e9dd6c1dfd2b63b *./tests/data/lavf/lavf.mxf_opatom_audio
 102457 

[FFmpeg-devel] [PATCH 10/13] avformat/mxfenc: Set color siting to 0 for D10-MXF

2018-05-07 Thread Michael Niedermayer
Signed-off-by: Michael Niedermayer 
---
 libavformat/mxfenc.c  |   1 +
 .../ref/fate/concat-demuxer-extended-lavf-mxf |   2 +-
 .../fate/concat-demuxer-extended-lavf-mxf_d10 |   2 +-
 .../ref/fate/concat-demuxer-simple1-lavf-mxf  | 242 +-
 .../fate/concat-demuxer-simple1-lavf-mxf_d10  | 140 +-
 tests/ref/seek/lavf-mxf   |  44 ++--
 tests/ref/seek/lavf-mxf_d10   |  54 ++--
 tests/ref/seek/lavf-mxf_dv25  |  54 ++--
 tests/ref/seek/lavf-mxf_dvcpro50  |  54 ++--
 tests/ref/seek/lavf-mxf_opatom|  54 ++--
 tests/ref/seek/lavf-mxf_opatom_audio  |  54 ++--
 11 files changed, 351 insertions(+), 350 deletions(-)

diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
index f2be76cc86..adf5527534 100644
--- a/libavformat/mxfenc.c
+++ b/libavformat/mxfenc.c
@@ -2361,6 +2361,7 @@ static int mxf_write_header(AVFormatContext *s)
 mxf->edit_unit_byte_count += 
klv_fill_size(mxf->edit_unit_byte_count);
 
 sc->signal_standard = 1;
+sc->color_siting = 0;
 }
 if (mxf->signal_standard >= 0)
 sc->signal_standard = mxf->signal_standard;
diff --git a/tests/ref/fate/concat-demuxer-extended-lavf-mxf 
b/tests/ref/fate/concat-demuxer-extended-lavf-mxf
index 13170c6eaf..2fb5fce4b1 100644
--- a/tests/ref/fate/concat-demuxer-extended-lavf-mxf
+++ b/tests/ref/fate/concat-demuxer-extended-lavf-mxf
@@ -1 +1 @@
-7c8c500ea386b41e9025487fb4380f5c 
*tests/data/fate/concat-demuxer-extended-lavf-mxf.ffprobe
+a6fb9c37dc71cb43eb9664a8ae9f1c66 
*tests/data/fate/concat-demuxer-extended-lavf-mxf.ffprobe
diff --git a/tests/ref/fate/concat-demuxer-extended-lavf-mxf_d10 
b/tests/ref/fate/concat-demuxer-extended-lavf-mxf_d10
index c3c8591c93..60d729b3da 100644
--- a/tests/ref/fate/concat-demuxer-extended-lavf-mxf_d10
+++ b/tests/ref/fate/concat-demuxer-extended-lavf-mxf_d10
@@ -1 +1 @@
-d87c3a2394c60046636e43848fa8b4f6 
*tests/data/fate/concat-demuxer-extended-lavf-mxf_d10.ffprobe
+cb7c8eac6f8917e39658e1fa4a250da8 
*tests/data/fate/concat-demuxer-extended-lavf-mxf_d10.ffprobe
diff --git a/tests/ref/fate/concat-demuxer-simple1-lavf-mxf 
b/tests/ref/fate/concat-demuxer-simple1-lavf-mxf
index 4f1d12fe26..d18e35b7ba 100644
--- a/tests/ref/fate/concat-demuxer-simple1-lavf-mxf
+++ b/tests/ref/fate/concat-demuxer-simple1-lavf-mxf
@@ -1,124 +1,124 @@
-video|0|0|0.00|-1|-0.04|1|0.04|N/A|N/A|24801|6656|K_
-audio|1|0|0.00|0|0.00|1920|0.04|N/A|N/A|3840|31744|K_
-video|0|3|0.12|0|0.00|1|0.04|N/A|N/A|16743|36352|__
-audio|1|1920|0.04|1920|0.04|1920|0.04|N/A|N/A|3840|53248|K_
-video|0|1|0.04|1|0.04|1|0.04|N/A|N/A|13812|57856|__
-audio|1|3840|0.08|3840|0.08|1920|0.04|N/A|N/A|3840|72192|K_
-video|0|2|0.08|2|0.08|1|0.04|N/A|N/A|13607|76800|__
-audio|1|5760|0.12|5760|0.12|1920|0.04|N/A|N/A|3840|90624|K_
-video|0|6|0.24|3|0.12|1|0.04|N/A|N/A|16158|95232|__
-audio|1|7680|0.16|7680|0.16|1920|0.04|N/A|N/A|3840|111616|K_
-video|0|4|0.16|4|0.16|1|0.04|N/A|N/A|13943|116224|__
-audio|1|9600|0.20|9600|0.20|1920|0.04|N/A|N/A|3840|130560|K_
-video|0|5|0.20|5|0.20|1|0.04|N/A|N/A|11223|135168|__
-audio|1|11520|0.24|11520|0.24|1920|0.04|N/A|N/A|3840|146432|K_
-video|0|9|0.36|6|0.24|1|0.04|N/A|N/A|20298|151040|__
-audio|1|13440|0.28|13440|0.28|1920|0.04|N/A|N/A|3840|171520|K_
-video|0|7|0.28|7|0.28|1|0.04|N/A|N/A|13341|176128|__
-audio|1|15360|0.32|15360|0.32|1920|0.04|N/A|N/A|3840|189952|K_
-video|0|8|0.32|8|0.32|1|0.04|N/A|N/A|12362|194560|__
-audio|1|17280|0.36|17280|0.36|1920|0.04|N/A|N/A|3840|207360|K_
-video|0|12|0.48|9|0.36|1|0.04|N/A|N/A|24786|211968|K_
-audio|1|19200|0.40|19200|0.40|1920|0.04|N/A|N/A|3840|237056|K_
-video|0|10|0.40|10|0.40|1|0.04|N/A|N/A|13377|241664|__
-audio|1|21120|0.44|21120|0.44|1920|0.04|N/A|N/A|3840|255488|K_
-video|0|11|0.44|11|0.44|1|0.04|N/A|N/A|15624|260096|__
-audio|1|23040|0.48|23040|0.48|1920|0.04|N/A|N/A|3840|275968|K_
-video|0|15|0.60|12|0.48|1|0.04|N/A|N/A|22597|280576|__
-audio|1|24960|0.52|24960|0.52|1920|0.04|N/A|N/A|3840|303616|K_
-video|0|13|0.52|13|0.52|1|0.04|N/A|N/A|15028|308224|__
-audio|1|26880|0.56|26880|0.56|1920|0.04|N/A|N/A|3840|323584|K_
-video|0|14|0.56|14|0.56|1|0.04|N/A|N/A|14014|328192|__
-audio|1|28800|0.60|28800|0.60|1920|0.04|N/A|N/A|3840|342528|K_
-video|0|18|0.72|15|0.60|1|0.04|N/A|N/A|20731|347136|__
-audio|1|30720|0.64|30720|0.64|1920|0.04|N/A|N/A|3840|368128|K_
-video|0|16|0.64|16|0.64|1|0.04|N/A|N/A|11946|372736|__

Re: [FFmpeg-devel] [PATCH 1/3] avformat/utils: function to get the formatted ntp time

2018-05-07 Thread Dixit, Vishwanath

On 5/7/18 1:59 AM, Michael Niedermayer wrote:
> On Sun, May 06, 2018 at 06:04:35PM +, Dixit, Vishwanath wrote:
>>
>>
>> On 4/28/18 6:38 AM, Michael Niedermayer wrote:
>>> On Fri, Apr 27, 2018 at 08:00:23AM +, Dixit, Vishwanath wrote:


 On 4/27/18 5:15 AM, Michael Niedermayer wrote:
> On Thu, Apr 26, 2018 at 11:05:59AM +, Dixit, Vishwanath wrote:
>>
>>
>> On 4/26/18 1:04 AM, Michael Niedermayer wrote:
>>> On Tue, Apr 24, 2018 at 02:46:56PM +0530, vdi...@akamai.com wrote:
 From: Vishwanath Dixit 

 This utility function creates 64-bit NTP time format as per the RFC
 5905.
 A simple explaination of 64-bit NTP time format is here
 http://www.beaglesoft.com/Manual/page53.htm
 ---
  libavformat/internal.h |  8 
  libavformat/utils.c| 20 
  2 files changed, 28 insertions(+)

 diff --git a/libavformat/internal.h b/libavformat/internal.h
 index 3582682..e9f758f 100644
 --- a/libavformat/internal.h
 +++ b/libavformat/internal.h
 @@ -240,6 +240,14 @@ void ff_read_frame_flush(AVFormatContext *s);
  uint64_t ff_ntp_time(void);
  
  /**
 + * Get the NTP time stamp formatted as per the RFC-5905.
 + *
 + * @param ntp_time NTP time in micro seconds (since NTP epoch)
 + * @return the formatted NTP time stamp
 + */
 +uint64_t ff_time_ntp_format(uint64_t ntp_time);
 +
 +/**
   * Append the media-specific SDP fragment for the media stream c
   * to the buffer buff.
   *
 diff --git a/libavformat/utils.c b/libavformat/utils.c
 index c25eab4..b59d426 100644
 --- a/libavformat/utils.c
 +++ b/libavformat/utils.c
 @@ -4637,6 +4637,26 @@ uint64_t ff_ntp_time(void)
  return (av_gettime() / 1000) * 1000 + NTP_OFFSET_US;
  }
  
 +uint64_t ff_time_ntp_format(uint64_t ntp_time)
 +{
 +uint64_t ntp_ts, frac_part;
 +uint32_t sec, usec;
 +
 +//current ntp time in seconds and micro seconds
>>>
 +sec = ntp_time / 100;
>>>
>>> This can be truncated
>> Yes, but the truncated part is not getting discarded, as the following 
>> line is taking care of that. Please correct me if I have not understood 
>> what you have intended to say here.
>
> ok, correcting you then :)
> sec is 32bit
> not all values of "ntp_time / 100;" fit in 32bit
> there is no check for this it just produces a wrong result
 Yes, you are right. But, I can use only the LS 32bits of the result in the 
 following code. It is a limitation of 64-bit NTP time format and the issue 
 is going to occur in 2036. Not sure how to handle it here. At most, I can 
 print a warning message when the result gets truncated. Could you please 
 suggest any alternative option?
>>>
>>> i cant make it work after 2036 as that seems what the design is limited at.
>>> But the error can be detected and handled
>> Yes, the error can be detected and one possible way I can think of handling 
>> that error, is to truncate LS bits instead of MS bits. But, this solution 
>> also will not be completely error free. Honestly, I am not able to find any 
>> useful ways of handling the error, apart from displaying a warning message. 
>> Request you to let me know if you have any solution in mind.
>
> I dont know the oppinion of others, but a warning message seems usefull
> in this case
Thanks for all the review inputs. I have made the suggested updates and have 
submitted the revised patch set with version V2.
>
> thx


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


[FFmpeg-devel] [PATCH v2 1/3] avformat/utils: function to get the formatted ntp time

2018-05-07 Thread vdixit
From: Vishwanath Dixit 

This utility function creates 64-bit NTP time format as per the RFC
5905.
A simple explaination of 64-bit NTP time format is here
http://www.beaglesoft.com/Manual/page53.htm
---
 libavformat/internal.h |  8 
 libavformat/utils.c| 22 ++
 2 files changed, 30 insertions(+)

diff --git a/libavformat/internal.h b/libavformat/internal.h
index 3582682..0b8120b 100644
--- a/libavformat/internal.h
+++ b/libavformat/internal.h
@@ -240,6 +240,14 @@ void ff_read_frame_flush(AVFormatContext *s);
 uint64_t ff_ntp_time(void);
 
 /**
+ * Get the NTP time stamp formatted as per the RFC-5905.
+ *
+ * @param ntp_time NTP time in micro seconds (since NTP epoch)
+ * @return the formatted NTP time stamp
+ */
+uint64_t ff_get_formatted_ntp_time(uint64_t ntp_time_us);
+
+/**
  * Append the media-specific SDP fragment for the media stream c
  * to the buffer buff.
  *
diff --git a/libavformat/utils.c b/libavformat/utils.c
index c25eab4..4001292 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -4637,6 +4637,28 @@ uint64_t ff_ntp_time(void)
 return (av_gettime() / 1000) * 1000 + NTP_OFFSET_US;
 }
 
+uint64_t ff_get_formatted_ntp_time(uint64_t ntp_time_us)
+{
+uint64_t ntp_ts, frac_part, sec;
+uint32_t usec;
+
+//current ntp time in seconds and micro seconds
+sec = ntp_time_us / 100;
+usec = ntp_time_us % 100;
+
+//encoding in ntp timestamp format
+frac_part = usec * 0xULL;
+frac_part /= 100;
+
+if (sec > 0xULL)
+av_log(NULL, AV_LOG_WARNING, "NTP time format roll over detected\n");
+
+ntp_ts = sec << 32;
+ntp_ts |= frac_part;
+
+return ntp_ts;
+}
+
 int av_get_frame_filename2(char *buf, int buf_size, const char *path, int 
number, int flags)
 {
 const char *p;
-- 
1.9.1

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


[FFmpeg-devel] [PATCH v2 3/3] avformat/dashenc: configuring container format options

2018-05-07 Thread vdixit
From: Vishwanath Dixit 

---
 doc/muxers.texi   | 4 
 libavformat/dashenc.c | 7 +++
 2 files changed, 11 insertions(+)

diff --git a/doc/muxers.texi b/doc/muxers.texi
index db81901..e9082a4 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -282,6 +282,10 @@ corrects that index value.
 Typically this logic is needed in live streaming use cases. The network 
bandwidth
 fluctuations are common during long run streaming. Each fluctuation can cause
 the segment indexes fall behind the expected real time position.
+@item -format_options @var{options_list}
+Set container format (mp4/webm) options using a @code{:} separated list of
+key=value parameters. Values containing @code{:} special characters must be
+escaped.
 @end table
 
 @anchor{framecrc}
diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 1dd6333..e27b61c 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -125,6 +125,7 @@ typedef struct DASHContext {
 int streaming;
 int64_t timeout;
 int index_correction;
+char *format_options_str;
 } DASHContext;
 
 static struct codec_string {
@@ -1017,6 +1018,11 @@ static int dash_init(AVFormatContext *s)
 av_dict_free();
 os->init_start_pos = 0;
 
+if (c->format_options_str) {
+ret = av_dict_parse_string(, c->format_options_str, "=", ":", 
0);
+if (ret < 0)
+return ret;
+}
 if (!strcmp(os->format_name, "mp4")) {
 if (c->streaming)
 av_dict_set(, "movflags", 
"frag_every_frame+dash+delay_moov", 0);
@@ -1538,6 +1544,7 @@ static const AVOption options[] = {
 { "streaming", "Enable/Disable streaming mode of output. Each frame will 
be moof fragment", OFFSET(streaming), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, E },
 { "timeout", "set timeout for socket I/O operations", OFFSET(timeout), 
AV_OPT_TYPE_DURATION, { .i64 = -1 }, -1, INT_MAX, .flags = E },
 { "index_correction", "Enable/Disable segment index correction logic", 
OFFSET(index_correction), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, E },
+{ "format_options","set list of options for the container format 
(mp4/webm) used for dash", OFFSET(format_options_str), AV_OPT_TYPE_STRING, 
{.str = NULL},  0, 0, E},
 { NULL },
 };
 
-- 
1.9.1

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


[FFmpeg-devel] [PATCH v2 2/3] avformat/movenc: creating producer reference time (PRFT) box

2018-05-07 Thread vdixit
From: Vishwanath Dixit 

The producer reference time box supplies relative wall-clock times
at which movie fragments, or files containing movie fragments
(such as segments) were produced.
The box is mainly useful in live streaming use cases. A media player
can parse the box and utilize the time fields to measure and improve
the latency during real time playout.
---
 doc/muxers.texi  | 10 ++
 libavformat/movenc.c | 50 ++
 libavformat/movenc.h |  9 +
 3 files changed, 69 insertions(+)

diff --git a/doc/muxers.texi b/doc/muxers.texi
index 6f03bba..db81901 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -1329,6 +1329,16 @@ be negative. This enables the initial sample to have 
DTS/CTS of zero, and
 reduces the need for edit lists for some cases such as video tracks with
 B-frames. Additionally, eases conformance with the DASH-IF interoperability
 guidelines.
+@item -write_prft
+Write producer time reference box (PRFT) with a specified time source for the
+NTP field in the PRFT box. Set value as @samp{wallclock} to specify timesource
+as wallclock time and @samp{pts} to specify timesource as input packets' PTS
+values.
+
+Setting value to @samp{pts} is applicable only for a live encoding use case,
+where PTS values are set as as wallclock time at the source. For example, an
+encoding use case with decklink capture source where @option{video_pts} and
+@option{audio_pts} are set to @samp{abs_wallclock}.
 @end table
 
 @subsection Example
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 0b44fd6..7e616e8 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -98,6 +98,9 @@ static const AVOption options[] = {
 { "encryption_kid", "The media encryption key identifier (hex)", 
offsetof(MOVMuxContext, encryption_kid), AV_OPT_TYPE_BINARY, .flags = 
AV_OPT_FLAG_ENCODING_PARAM },
 { "use_stream_ids_as_track_ids", "use stream ids as track ids", 
offsetof(MOVMuxContext, use_stream_ids_as_track_ids), AV_OPT_TYPE_BOOL, {.i64 = 
0}, 0, 1, AV_OPT_FLAG_ENCODING_PARAM},
 { "write_tmcd", "force or disable writing tmcd", offsetof(MOVMuxContext, 
write_tmcd), AV_OPT_TYPE_BOOL, {.i64 = -1}, -1, 1, AV_OPT_FLAG_ENCODING_PARAM},
+{ "write_prft", "Write producer reference time box with specified time 
source", offsetof(MOVMuxContext, write_prft), AV_OPT_TYPE_INT, {.i64 = 
MOV_PRFT_NONE}, 0, MOV_PRFT_NB-1, AV_OPT_FLAG_ENCODING_PARAM, "prft"},
+{ "wallclock", NULL, 0, AV_OPT_TYPE_CONST, {.i64 = 
MOV_PRFT_SRC_WALLCLOCK}, 0, 0, AV_OPT_FLAG_ENCODING_PARAM, "prft"},
+{ "pts", NULL, 0, AV_OPT_TYPE_CONST, {.i64 = MOV_PRFT_SRC_PTS}, 0, 0, 
AV_OPT_FLAG_ENCODING_PARAM, "prft"},
 { NULL },
 };
 
@@ -4514,6 +4517,49 @@ static int mov_write_sidx_tags(AVIOContext *pb, 
MOVMuxContext *mov,
 return 0;
 }
 
+static int mov_write_prft_tag(AVIOContext *pb, MOVMuxContext *mov, int tracks)
+{
+int64_t pos = avio_tell(pb), pts_us, ntp_ts;
+MOVTrack *first_track;
+
+/* PRFT should be associated with at most one track. So, choosing only the
+ * first track. */
+if (tracks > 0)
+return 0;
+first_track = &(mov->tracks[0]);
+
+if (!first_track->entry) {
+av_log(mov->fc, AV_LOG_WARNING, "Unable to write PRFT, no entries in 
the track\n");
+return 0;
+}
+
+if (first_track->cluster[0].pts == AV_NOPTS_VALUE) {
+av_log(mov->fc, AV_LOG_WARNING, "Unable to write PRFT, first PTS is 
invalid\n");
+return 0;
+}
+
+if (mov->write_prft == MOV_PRFT_SRC_WALLCLOCK) {
+ntp_ts = ff_get_formatted_ntp_time(ff_ntp_time());
+} else if (mov->write_prft == MOV_PRFT_SRC_PTS) {
+pts_us = av_rescale_q(first_track->cluster[0].pts,
+  first_track->st->time_base, AV_TIME_BASE_Q);
+ntp_ts = ff_get_formatted_ntp_time(pts_us + NTP_OFFSET_US);
+} else {
+av_log(mov->fc, AV_LOG_WARNING, "Unsupported PRFT box configuration: 
%d\n",
+   mov->write_prft);
+return 0;
+}
+
+avio_wb32(pb, 0);   // Size place holder
+ffio_wfourcc(pb, "prft");   // Type
+avio_w8(pb, 1); // Version
+avio_wb24(pb, 0);   // Flags
+avio_wb32(pb, first_track->track_id);   // reference track ID
+avio_wb64(pb, ntp_ts);  // NTP time stamp
+avio_wb64(pb, first_track->cluster[0].pts); //media time
+return update_size(pb, pos);
+}
+
 static int mov_write_moof_tag(AVIOContext *pb, MOVMuxContext *mov, int tracks,
   int64_t mdat_size)
 {
@@ -4528,6 +4574,9 @@ static int mov_write_moof_tag(AVIOContext *pb, 
MOVMuxContext *mov, int tracks,
 if (mov->flags & FF_MOV_FLAG_DASH && !(mov->flags & 
FF_MOV_FLAG_GLOBAL_SIDX))
 mov_write_sidx_tags(pb, mov, tracks, moof_size + 8 + mdat_size);
 
+if (mov->write_prft > MOV_PRFT_NONE && 

Re: [FFmpeg-devel] [PATCH 1/3] lavf/network: fix doxygen comments.

2018-05-07 Thread Michael Niedermayer
On Sun, May 06, 2018 at 11:12:12PM +0800, Jun Zhao wrote:
> Signed-off-by: Jun Zhao 
> ---
>  libavformat/network.h | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/libavformat/network.h b/libavformat/network.h
> index e3fda4d..efaa789 100644
> --- a/libavformat/network.h
> +++ b/libavformat/network.h
> @@ -87,9 +87,9 @@ int ff_network_wait_fd(int fd, int write);
>   * This works similarly to ff_network_wait_fd, but waits up to 'timeout' 
> microseconds
>   * Uses ff_network_wait_fd in a loop
>   *
> - * @fd Socket descriptor
> - * @write Set 1 to wait for socket able to be read, 0 to be written
> - * @timeout Timeout interval, in microseconds. Actual precision is 10 
> mcs, due to ff_network_wait_fd usage
> + * @param fd Socket descriptor
> + * @param write Set 1 to wait for socket able to be read, 0 to be written
> + * @param timeout Timeout interval, in microseconds. Actual precision is 
> 10 mcs, due to ff_network_wait_fd usage
>   * @param int_cb Interrupt callback, is checked before each 
> ff_network_wait_fd call
>   * @return 0 if data can be read/written, AVERROR(ETIMEDOUT) if timeout 
> expired, or negative error code
>   */
> @@ -98,7 +98,7 @@ int ff_network_wait_fd_timeout(int fd, int write, int64_t 
> timeout, AVIOInterrupt
>  /**
>   * Waits for up to 'timeout' microseconds. If the usert's int_cb is set and
>   * triggered, return before that.
> - * @timeout Timeout in microseconds. Maybe have lower actual precision.
> + * @param timeout Timeout in microseconds. Maybe have lower actual precision.
>   * @param int_cb Interrupt callback, is checked regularly.
>   * @return AVERROR(ETIMEDOUT) if timeout expirted, AVERROR_EXIT if 
> interrupted by int_cb
>   */

LGTM

thx

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

Many things microsoft did are stupid, but not doing something just because
microsoft did it is even more stupid. If everything ms did were stupid they
would be bankrupt already.


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


Re: [FFmpeg-devel] [PATCH 1/9] lavfi/nlmeans: random code shuffling to help compiler

2018-05-07 Thread Michael Niedermayer
On Sun, May 06, 2018 at 01:40:52PM +0200, Clément Bœsch wrote:
> This makes nlmeans_slice() slightly faster at least on GCC 7.3.
> ---
>  libavfilter/vf_nlmeans.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)

LGTM

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Modern terrorism, a quick summary: Need oil, start war with country that
has oil, kill hundread thousand in war. Let country fall into chaos,
be surprised about raise of fundamantalists. Drop more bombs, kill more
people, be surprised about them taking revenge and drop even more bombs
and strip your own citizens of their rights and freedoms. to be continued


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


Re: [FFmpeg-devel] [PATCH v3] avformat/mxfenc: add h264 profiles

2018-05-07 Thread Tomas Härdin
sön 2018-05-06 klockan 21:31 +0200 skrev Thomas Mundt:
> 2018-05-06 13:32 GMT+02:00 Tomas Härdin :
> 
> > fre 2018-05-04 klockan 01:52 +0200 skrev Thomas Mundt:
> > > Hi,
> > > 
> > > this is a better version of the patch.
> > > 10 bit and TFF are mandatory for AVC Intra only. Other profiles
> > > differ.
> > > 
> > > diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
> > > index 3bb7032..81513dc 100644
> > > --- a/libavformat/mxfenc.c
> > > +++ b/libavformat/mxfenc.c
> > > @@ -1947,22 +1947,31 @@ static const struct {
> > >  int frame_size;
> > >  int profile;
> > >  uint8_t interlaced;
> > > +int long_gop;
> > 
> > A comment here explaining the difference between -1, 0 and 1 would
> > be
> > nice. The rest looks OK, but I didn't read the relevant specs to be
> > 100% sure
> > 
> > 
> 
> New patch attached.

Looks OK

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