Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: support http method for hls fmp4

[Steven Liu]

> On Apr 28, 2018, at 11:47, Steven Liu  wrote:
> 
> fix ticket: 7160
> 
> Signed-off-by: Steven Liu 
> ---
> libavformat/hlsenc.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> index c27a66ea79..09478e7c45 100644
> --- a/libavformat/hlsenc.c
> +++ b/libavformat/hlsenc.c
> @@ -2147,6 +2147,7 @@ static int hls_write_packet(AVFormatContext *s, 
> AVPacket *pkt)
> int range_length = 0;
> uint8_t *buffer = NULL;
> VariantStream *vs = NULL;
> +AVDictionary *options = NULL;
> 
> for (i = 0; i < hls->nb_varstreams; i++) {
> vs = >var_streams[i];
> @@ -2272,7 +2273,8 @@ static int hls_write_packet(AVFormatContext *s, 
> AVPacket *pkt)
> }
> vs->size = range_length;
> } else {
> -ret = hlsenc_io_open(s, >out, vs->avf->url, NULL);
> +set_http_options(s, , hls);
> +ret = hlsenc_io_open(s, >out, vs->avf->url, );
> if (ret < 0) {
> av_log(s, AV_LOG_ERROR, "Failed to open file '%s'\n",
>vs->avf->url);
> -- 
> 2.15.1
> 

Pushed

Thanks
Steven





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

Re: [FFmpeg-devel] [PATCH 1/2] libavformat/dashdec: Fix for ticket 7149 (Segfault when decoding dash streams)

[Steven Liu]

> On May 1, 2018, at 06:24, Colin NG  wrote:
> 
> - Add NULL pointer check for init_section
> ---
> libavformat/dashdec.c | 30 +++---
> 1 file changed, 23 insertions(+), 7 deletions(-)
> 
> diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
> index 42202e0..c6f350d 100644
> --- a/libavformat/dashdec.c
> +++ b/libavformat/dashdec.c
> @@ -1877,25 +1877,40 @@ fail:
> 
> static int init_section_compare_video(DASHContext *c)
> {
> +char *url =NULL;
> +int64_t url_offset = -1;
> +int64_t size = -1;
> int i = 0;
> -char *url = c->videos[0]->init_section->url;
> -int64_t url_offset = c->videos[0]->init_section->url_offset;
> -int64_t size = c->videos[0]->init_section->size;
> +
> +if (c->videos[0]->init_section == NULL)
> +return 0;
> +
> +url = c->videos[0]->init_section->url;
> +url_offset = c->videos[0]->init_section->url_offset;
> +size = c->videos[0]->init_section->size;
> for (i=0;in_videos;i++) {
> if (av_strcasecmp(c->videos[i]->init_section->url,url) || 
> c->videos[i]->init_section->url_offset != url_offset || 
> c->videos[i]->init_section->size != size) {
> return 0;
> }
> }
> +
> return 1;
> }
> 
> static int init_section_compare_audio(DASHContext *c)
> {
> +char *url =NULL;
> +int64_t url_offset = -1;
> +int64_t size = -1;
> int i = 0;
> -char *url = c->audios[0]->init_section->url;
> -int64_t url_offset = c->audios[0]->init_section->url_offset;
> -int64_t size = c->audios[0]->init_section->size;
> -for (i=0;in_audios;i++) {
> +
> +if (c->audios[0]->init_section == NULL)
> +return 0;
> +
> +url = c->audios[0]->init_section->url;
> +url_offset = c->audios[0]->init_section->url_offset;
> +size = c->audios[0]->init_section->size;
> +for (i=0; in_audios; i++) {
> if (av_strcasecmp(c->audios[i]->init_section->url,url) || 
> c->audios[i]->init_section->url_offset != url_offset || 
> c->audios[i]->init_section->size != size) {
> return 0;
> }
> @@ -1960,6 +1975,7 @@ static int dash_read_header(AVFormatContext *s)
> ++stream_index;
> }
> 
> +
> if (c->n_audios) {
> c->is_init_section_common_audio = init_section_compare_audio(c);
> }
> -- 
> 2.7.4
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Patschest pushed.

Thanks
Steven



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

Re: [FFmpeg-devel] [PATCH] lavc/qsv: suppress code scan complain

[Li, Zhong]

> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Mark Thompson
> Sent: Wednesday, May 9, 2018 10:39 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH] lavc/qsv: suppress code scan complain
> 
> On 09/05/18 07:13, Zhong Li wrote:
> > Suppress the complain "variables 'type' is used but maybe uninitialized".
> >
> > Signed-off-by: Zhong Li 
> > ---
> >  libavcodec/qsv.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/libavcodec/qsv.c b/libavcodec/qsv.c index
> > 45e1c25..b578da0 100644
> > --- a/libavcodec/qsv.c
> > +++ b/libavcodec/qsv.c
> > @@ -197,7 +197,7 @@ int ff_qsv_find_surface_idx(QSVFramesContext
> *ctx,
> > QSVFrame *frame)
> >
> >  enum AVPictureType ff_qsv_map_pictype(int mfx_pic_type)  {
> > -enum AVPictureType type;
> > +enum AVPictureType type = AV_PICTURE_TYPE_NONE;
> >  switch (mfx_pic_type & 0x7) {
> >  case MFX_FRAMETYPE_I:
> >  if (mfx_pic_type & MFX_FRAMETYPE_S)
> >
> 
> Might it be better to add a default case to the switch and assert that it's
> never reached?  I think if the pic type doesn't hit one of the existing cases
> then something must be very broken.

Agree, I've updated it. Thanks for review and sorry for late reply.

> 
> - Mark

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

[FFmpeg-devel] [PATCH]lavf/img2dec: Autodetect xwd images

[Carl Eugen Hoyos]

Hi!

Attached patch implements autodetection of xwd images.

Please comment, Carl Eugen
From c0e14393a570b84804c5d9c1208bc4a0a95f3641 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Thu, 24 May 2018 03:19:43 +0200
Subject: [PATCH] lavf/img2dec: Auto-detect xwd images.

---
 libavformat/Makefile |1 +
 libavformat/allformats.c |1 +
 libavformat/img2dec.c|   32 
 libavformat/version.h|2 +-
 4 files changed, 35 insertions(+), 1 deletion(-)

diff --git a/libavformat/Makefile b/libavformat/Makefile
index a5585dc..8fb075f 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -258,6 +258,7 @@ OBJS-$(CONFIG_IMAGE_SUNRAST_PIPE_DEMUXER) += img2dec.o img2.o
 OBJS-$(CONFIG_IMAGE_TIFF_PIPE_DEMUXER)+= img2dec.o img2.o
 OBJS-$(CONFIG_IMAGE_WEBP_PIPE_DEMUXER)+= img2dec.o img2.o
 OBJS-$(CONFIG_IMAGE_XPM_PIPE_DEMUXER) += img2dec.o img2.o
+OBJS-$(CONFIG_IMAGE_XWD_PIPE_DEMUXER) += img2dec.o img2.o
 OBJS-$(CONFIG_INGENIENT_DEMUXER) += ingenientdec.o rawdec.o
 OBJS-$(CONFIG_IPMOVIE_DEMUXER)   += ipmovie.o
 OBJS-$(CONFIG_IRCAM_DEMUXER) += ircamdec.o ircam.o pcm.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index a94364f..adcc8d9 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -476,6 +476,7 @@ extern AVInputFormat  ff_image_sunrast_pipe_demuxer;
 extern AVInputFormat  ff_image_tiff_pipe_demuxer;
 extern AVInputFormat  ff_image_webp_pipe_demuxer;
 extern AVInputFormat  ff_image_xpm_pipe_demuxer;
+extern AVInputFormat  ff_image_xwd_pipe_demuxer;
 
 /* external libraries */
 extern AVOutputFormat ff_chromaprint_muxer;
diff --git a/libavformat/img2dec.c b/libavformat/img2dec.c
index ffbc9a6..354b811 100644
--- a/libavformat/img2dec.c
+++ b/libavformat/img2dec.c
@@ -34,6 +34,7 @@
 #include "internal.h"
 #include "img2.h"
 #include "libavcodec/mjpeg.h"
+#include "libavcodec/xwd.h"
 #include "subtitles.h"
 
 #if HAVE_GLOB
@@ -974,6 +975,36 @@ static int xpm_probe(AVProbeData *p)
 return 0;
 }
 
+static int xwd_probe(AVProbeData *p)
+{
+const uint8_t *b = p->buf;
+unsigned width, bpp, bpad, lsize;
+
+if (   p->buf_size < XWD_HEADER_SIZE
+|| AV_RB32(b ) < XWD_HEADER_SIZE
+|| AV_RB32(b +  4) != XWD_VERSION // version
+|| AV_RB32(b +  8) != XWD_Z_PIXMAP// format
+|| AV_RB32(b + 12) > 32 || !AV_RB32(b + 12)   // depth
+|| AV_RB32(b + 16) == 0   // width
+|| AV_RB32(b + 20) == 0   // height
+|| AV_RB32(b + 28) > 1// byteorder
+|| AV_RB32(b + 32) & ~56 || av_popcount(AV_RB32(b + 32)) != 1 // bitmap unit
+|| AV_RB32(b + 36) > 1// bitorder
+|| AV_RB32(b + 40) & ~56 || av_popcount(AV_RB32(b + 40)) != 1 // padding
+|| AV_RB32(b + 44) > 32 || !AV_RB32(b + 44)   // bpp
+|| AV_RB32(b + 68) > 256) // colours
+return 0;
+
+width = AV_RB32(b + 16);
+bpad  = AV_RB32(b + 40);
+bpp   = AV_RB32(b + 44);
+lsize = AV_RB32(b + 48);
+if (lsize < FFALIGN(width * bpp, bpad) >> 3)
+return 0;
+
+return AVPROBE_SCORE_MAX / 2 + 1;
+}
+
 #define IMAGEAUTO_DEMUXER(imgname, codecid)\
 static const AVClass imgname ## _class = {\
 .class_name = AV_STRINGIFY(imgname) " demuxer",\
@@ -1016,3 +1047,4 @@ IMAGEAUTO_DEMUXER(svg, AV_CODEC_ID_SVG)
 IMAGEAUTO_DEMUXER(tiff,AV_CODEC_ID_TIFF)
 IMAGEAUTO_DEMUXER(webp,AV_CODEC_ID_WEBP)
 IMAGEAUTO_DEMUXER(xpm, AV_CODEC_ID_XPM)
+IMAGEAUTO_DEMUXER(xwd, AV_CODEC_ID_XWD)
diff --git a/libavformat/version.h b/libavformat/version.h
index e3975f5..b050747 100644
--- a/libavformat/version.h
+++ b/libavformat/version.h
@@ -32,7 +32,7 @@
 // Major bumping may affect Ticket5467, 5421, 5451(compatibility with Chromium)
 // Also please add any ticket numbers that you believe might be affected here
 #define LIBAVFORMAT_VERSION_MAJOR  58
-#define LIBAVFORMAT_VERSION_MINOR  16
+#define LIBAVFORMAT_VERSION_MINOR  17
 #define LIBAVFORMAT_VERSION_MICRO 100
 
 #define LIBAVFORMAT_VERSION_INT AV_VERSION_INT(LIBAVFORMAT_VERSION_MAJOR, \
-- 
1.7.10.4

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

Re: [FFmpeg-devel] [PATCH 2/2] lavu/hwcontext_vaapi: add nv21 map

[myp...@gmail.com]

2018-05-24 8:07 GMT+08:00 Mark Thompson :
> On 23/05/18 11:29, Jun Zhao wrote:
>> Signed-off-by: Jun Zhao 
>> ---
>>  libavutil/hwcontext_vaapi.c | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
>> index 5bdb02f..7b3cbea 100644
>> --- a/libavutil/hwcontext_vaapi.c
>> +++ b/libavutil/hwcontext_vaapi.c
>> @@ -100,6 +100,9 @@ static const struct {
>>  enum AVPixelFormat pix_fmt;
>>  } vaapi_format_map[] = {
>>  MAP(NV12, YUV420,  NV12),
>> +#ifdef VA_FOURCC_NV21
>> +MAP(NV21, YUV420,  NV21),// As NV12 with U and V reversed
>> +#endif
>>  MAP(YV12, YUV420,  YUV420P), // With U/V planes swapped.
>>  MAP(IYUV, YUV420,  YUV420P),
>>  #ifdef VA_FOURCC_I420
>>
>
> Sure, but why would anyone ever use this format?
>
> - Mark

I don't know why iHD driver return NV21 in fact, I just
want to remove an unknow enrty dump when map the pixel format
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] lavu/hwcontext_vaapi: dump more decoding error details.

[myp...@gmail.com]

2018-05-24 8:05 GMT+08:00 Mark Thompson :
> On 23/05/18 11:29, Jun Zhao wrote:
>> dump more decoding error details when sync surface fail.
>>
>> Signed-off-by: Jun Zhao 
>> ---
>>  libavutil/hwcontext_vaapi.c | 17 +
>>  1 file changed, 17 insertions(+)
>>
>> diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
>> index e55bb8d..5bdb02f 100644
>> --- a/libavutil/hwcontext_vaapi.c
>> +++ b/libavutil/hwcontext_vaapi.c
>> @@ -742,6 +742,23 @@ static int vaapi_map_frame(AVHWFramesContext *hwfc,
>>  av_log(hwfc, AV_LOG_ERROR, "Failed to sync surface "
>> "%#x: %d (%s).\n", surface_id, vas, vaErrorStr(vas));
>>  err = AVERROR(EIO);
>> +/* query decode detail error */
>> +if (vas == VA_STATUS_ERROR_DECODING_ERROR) {
>> +VASurfaceDecodeMBErrors *dec_err = NULL;
>> +int i;
>> +vas = vaQuerySurfaceError(hwctx->display, surface_id, 
>> VA_STATUS_ERROR_DECODING_ERROR,
>> +  (void **)_err);
>> +if (VA_STATUS_SUCCESS == vas) {
>> +if (NULL != dec_err) {
>
> Why this check?
maybe give a assert0?
>
>> +for (i = 0; dec_err[i].status != -1; i++) {
>
> How many items can be in this list?  We probably don't want to print more 
> than one in the error log if this can happen on every frame in a broken 
> stream.
Oh, from the API  define, "array is terminated if "status==-1" is
detected", so I don't know
the error entry number from VA-API level (but I checked the iHD source code,
I think iHD always return 2 error entries in this case). In current
FFmpeg VA-API
 HWaccel decoding logic, I believe if vaSyncSurface fail, FFmpeg will return the
error and exit, so we don't have a change to print the error message
every frame.

>> +  av_log(hwfc, AV_LOG_ERROR, "Decoding deatils 
>> error, "
>
> "Decoding error details:" maybe?
Ok, will change it
>
>> + "type: %d, start mb: %d, end md: %d, num 
>> mbs: %d.\n",
>> + dec_err[i].decode_error_type, 
>> dec_err[i].start_mb,
>> + dec_err[i].end_mb, dec_err[i].num_mb);
>> +}
>> +}
>> +}
>> +}
>>  goto fail;
>>  }
>>
>>
>
> What is the lifetime of the returned pointer here?  This can certainly be 
> called on any thread asynchronously.
Yes, I have the same thought about this API, basically, I think
vaQuerySurfaceError()
need to return the pointer and ask the caller to free the error
entries like getaddressinfo()/freeaddrinfo(),
and I think need to submit a patch to VA-API/iHD driver for this part.
>
> It's a bit nasty to have this in the generic code rather than the decoder: 
> very few actual uses are going to call SyncSurface directly on a decoder 
> output - rather they will pass it to some other component (another VAAPI one, 
> or export).  Could we instead put this inside the decoder, enabled by some 
> debug option?  (Some sort of "catch decoder errors earlier at a cost of 
> (possibly greatly) decreased performance" flag.)
I can give a case, when I debug the ticket #7200, I try to dump the
YUV but fail,
so I want to get more decoding error from iHD driver.

use the command like this: ./ffmpeg_g -hwaccel vaapi -vaapi_device
/dev/dri/renderD128 -hwaccel_flags allow_profile_mismatch -i test.ts
-f null /dev/null

I think give a decoder option in this case is a good suggestion, I
will check this way. 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] libavformat/mxfenc: Add some () to attempt to workaround build issue on osx

[Michael Niedermayer]

On Tue, May 22, 2018 at 06:13:47PM -0300, James Almer wrote:
> On 5/22/2018 3:57 PM, Michael Niedermayer wrote:
> > May fix ticket7209
> > 
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavformat/mxfenc.c | 12 ++--
> >  1 file changed, 6 insertions(+), 6 deletions(-)
> > 
> > diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
> > index 44425bf6c9..77f60f5874 100644
> > --- a/libavformat/mxfenc.c
> > +++ b/libavformat/mxfenc.c
> > @@ -1149,23 +1149,23 @@ 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);
> > +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);
> > +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);
> > +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);
> > +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);
> > +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);
> > +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;
> 
> Why not just declare these as static const like mxf_mpeg2_codec_uls or
> the descriptor keys right above this function?

possible but it would seperate the values from the switch/case, making
it harder to see what is stored by what.
If people prefer i can change it to that ?
I think its more readable as is / with the patch above though

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No great genius has ever existed without some touch of madness. -- Aristotle


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/2] lavu/hwcontext_vaapi: dump more decoding error details.

[Mark Thompson]

On 23/05/18 11:29, Jun Zhao wrote:
> dump more decoding error details when sync surface fail.
> 
> Signed-off-by: Jun Zhao 
> ---
>  libavutil/hwcontext_vaapi.c | 17 +
>  1 file changed, 17 insertions(+)
> 
> diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
> index e55bb8d..5bdb02f 100644
> --- a/libavutil/hwcontext_vaapi.c
> +++ b/libavutil/hwcontext_vaapi.c
> @@ -742,6 +742,23 @@ static int vaapi_map_frame(AVHWFramesContext *hwfc,
>  av_log(hwfc, AV_LOG_ERROR, "Failed to sync surface "
> "%#x: %d (%s).\n", surface_id, vas, vaErrorStr(vas));
>  err = AVERROR(EIO);
> +/* query decode detail error */
> +if (vas == VA_STATUS_ERROR_DECODING_ERROR) {
> +VASurfaceDecodeMBErrors *dec_err = NULL;
> +int i;
> +vas = vaQuerySurfaceError(hwctx->display, surface_id, 
> VA_STATUS_ERROR_DECODING_ERROR,
> +  (void **)_err);
> +if (VA_STATUS_SUCCESS == vas) {
> +if (NULL != dec_err) {

Why this check?

> +for (i = 0; dec_err[i].status != -1; i++) {

How many items can be in this list?  We probably don't want to print more than 
one in the error log if this can happen on every frame in a broken stream.

> +  av_log(hwfc, AV_LOG_ERROR, "Decoding deatils 
> error, "

"Decoding error details:" maybe?

> + "type: %d, start mb: %d, end md: %d, num 
> mbs: %d.\n",
> + dec_err[i].decode_error_type, 
> dec_err[i].start_mb,
> + dec_err[i].end_mb, dec_err[i].num_mb);
> +}
> +}
> +}
> +}
>  goto fail;
>  }
>  
> 

What is the lifetime of the returned pointer here?  This can certainly be 
called on any thread asynchronously.

It's a bit nasty to have this in the generic code rather than the decoder: very 
few actual uses are going to call SyncSurface directly on a decoder output - 
rather they will pass it to some other component (another VAAPI one, or 
export).  Could we instead put this inside the decoder, enabled by some debug 
option?  (Some sort of "catch decoder errors earlier at a cost of (possibly 
greatly) decreased performance" flag.)

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

Re: [FFmpeg-devel] [PATCH 2/2] lavu/hwcontext_vaapi: add nv21 map

[Mark Thompson]

On 23/05/18 11:29, Jun Zhao wrote:
> Signed-off-by: Jun Zhao 
> ---
>  libavutil/hwcontext_vaapi.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
> index 5bdb02f..7b3cbea 100644
> --- a/libavutil/hwcontext_vaapi.c
> +++ b/libavutil/hwcontext_vaapi.c
> @@ -100,6 +100,9 @@ static const struct {
>  enum AVPixelFormat pix_fmt;
>  } vaapi_format_map[] = {
>  MAP(NV12, YUV420,  NV12),
> +#ifdef VA_FOURCC_NV21
> +MAP(NV21, YUV420,  NV21),// As NV12 with U and V reversed
> +#endif
>  MAP(YV12, YUV420,  YUV420P), // With U/V planes swapped.
>  MAP(IYUV, YUV420,  YUV420P),
>  #ifdef VA_FOURCC_I420
> 

Sure, but why would anyone ever use this format?

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

Re: [FFmpeg-devel] [PATCH]lavc/j2kenc: Support AV_PIX_FMT_PAL8

[Michael Niedermayer]

On Tue, May 22, 2018 at 02:23:50AM +0200, Carl Eugen Hoyos wrote:
> Hi!
> 
> Attached patch allows pal8 encoding into j2k, tested with libopenjpeg,
> kakadu and jasper.
> 
> Please comment, Carl Eugen

>  j2kenc.c  |   40 
>  version.h |2 +-
>  2 files changed, 37 insertions(+), 5 deletions(-)
> ad57c6c2d2497b10b9a8a71642ba45740a0d1501  
> 0001-lavc-j2kenc-Support-AV_PIX_FMT_PAL8.patch
> From ffc9968279ecbf8b0b6659e9a07539edb9787e44 Mon Sep 17 00:00:00 2001
> From: Carl Eugen Hoyos 
> Date: Tue, 22 May 2018 02:21:04 +0200
> Subject: [PATCH] lavc/j2kenc: Support AV_PIX_FMT_PAL8.

should be ok but please wait a day or 2 so others can comment too

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Complexity theory is the science of finding the exact solution to an
approximation. Benchmarking OTOH is finding an approximation of the exact


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

[FFmpeg-devel] [PATCH] lavfi/tests: Fix 16-bit vf_blend test to avoid memory not aligned to 2 bytes

[Andrey Semashev]

Generic C implementation of vf_blend performs reads and writes of 16-bit
elements, which requires the buffers to be aligned to at least 2-byte
boundary.

Also, the change fixes source buffer overrun caused by src_offset being
added to to test handling of misaligned buffers.

Fixes: #7226
---
 tests/checkasm/vf_blend.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/checkasm/vf_blend.c b/tests/checkasm/vf_blend.c
index 912f3a2c38..a7578fec39 100644
--- a/tests/checkasm/vf_blend.c
+++ b/tests/checkasm/vf_blend.c
@@ -71,7 +71,7 @@
 w = WIDTH / depth; 
\

\
 for (i = 0; i < BUF_UNITS - 1; i++) {  
\
-int src_offset = i * SIZE_PER_UNIT + i; /* Test various alignments 
*/  \
+int src_offset = i * SIZE_PER_UNIT + (BUF_UNITS - 1 - i) * depth; 
/* Test various alignments */  \
 int dst_offset = i * SIZE_PER_UNIT; /* dst must be aligned */  
\
 randomize_buffers();   
\
 call_ref(top1 + src_offset, w, bot1 + src_offset, w,   
\
-- 
2.17.0

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

Re: [FFmpeg-devel] [PATCH v6 1/3] avcodec: add flags for packets with top/bottom field

[Patrick Keroulas]

- Original Message -
> From: "Rostislav Pehlivanov" 
> To: "FFmpeg development discussions and patches" 
> Sent: Wednesday, May 23, 2018 3:25:34 PM
> Subject: Re: [FFmpeg-devel] [PATCH v6 1/3] avcodec: add flags for packets 
> with top/bottom field

> On 23 May 2018 at 20:01, wm4  wrote:
> 
>> On Wed, 23 May 2018 14:29:38 -0400 (EDT)
>> Patrick Keroulas  wrote:
>> 
>> > - Original Message -
>> > > From: "wm4" 
>> > > To: ffmpeg-devel@ffmpeg.org
>> > > Sent: Wednesday, May 23, 2018 12:02:45 PM
>> > > Subject: Re: [FFmpeg-devel] [PATCH v6 1/3] avcodec: add flags for
>> packets with top/bottom field
>> > 
>> > > On Wed, 23 May 2018 16:46:17 +0100
>> > > Rostislav Pehlivanov  wrote:
>> > > 
>> > >> On 23 May 2018 at 16:18, wm4  wrote:
>> > >> 
>> > >> > On Tue, 22 May 2018 17:19:35 -0400 (EDT)
>> > >> > Patrick Keroulas  wrote:
>> > >> > 
>> > >> > > - Original Message -
>> > >> > > > From: "Rostislav Pehlivanov" 
>> > >> > > > To: "FFmpeg development discussions and patches" <
>> > >> > ffmpeg-devel@ffmpeg.org>
>> > >> > > > Sent: Friday, May 18, 2018 5:28:42 PM
>> > >> > > > Subject: Re: [FFmpeg-devel] [PATCH v6 1/3] avcodec: add flags
>> for
>> > >> > packets with top/bottom field
>> > >> > > 
>> > >> > > > On 18 May 2018 at 22:17, wm4  wrote:
>> > >> > > 
>> > >> > > 
>> > >> > > 
>> > >> > > > > But I think a new side data type would be much saner. We
>> could even
>> > >> > > > > just make it something generic, like AV_PKT_DATA_ANCILLARY or
>> > >> > > > > something. It's apparently just packet data which somehow
>> couldn't go
>> > >> > > > > into the packet data.
>> > >> > > 
>> > >> > > 
>> > >> > > > I agree, a generic ancillary side data type sounds better. It
>> would
>> > >> > have to
>> > >> > > > be handled the same way as mastering metadata (e.g. to allocate
>> it
>> > >> > you'd
>> > >> > > > need to use a separate function), since the size of the data
>> struct
>> > >> > can't
>> > >> > > > be part of the API if we intend to add fields later.
>> > >> > > > Patrick, if you're okay with that you should submit a patch
>> which bases
>> > >> > > > such side data on libavutil/mastering_display_metadata.h/.c
>> > >> > > 
>> > >> > > No problem for transmitting field flags through side data. But
>> the given
>> > >> > > example (libavutil/mastering_display_metadata.h/.c) attaches
>> data to
>> > >> > > AVFrame, not AVPacket, so I'm not sure where to place this
>> separate
>> > >> > > allocator function. Do you recommend to create a new
>> > >> > > libavcodec/ancillary.c/h utility?
>> > >> > 
>> > >> > The example you mentioned exists for AVPacket too (it's just not
>> easy
>> > >> > to see how it can end up in AVPacket, because no demuxer does that
>> > >> > directly).
>> > >> > 
>> > >> > Anyway, ancillary side data would just be an untyped byte array, so
>> I
>> > >> > don't think it needs any helpers. Just an addition to the packet
>> side
>> > >> > data enum (I think it's somewhere in avcodec.h).
>> > >> > ___
>> > >> > ffmpeg-devel mailing list
>> > >> > ffmpeg-devel@ffmpeg.org
>> > >> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>> > >> > 
>> > >> 
>> > >> I'd rather have it as a well defined typed array rather than a bunch
>> of
>> > >> bytes. Otherwise we'd start sending unknown side data info and users
>> > >> wouldn't know what to do with it.
>> > > 
>> > > Unless you're adding some meta object system for describing arbitrary
>> > > types at runtime I don't know how you'd do that.
>> > 
>> > Is that ok if I simply define a basic struct to hold the field?
>> > 
>> > Any suggestion on where to insert the definition of this data and the
>> > accessors in lavc? In a new source file?
>> 
>> If you make it a struct, then make a new file in libavutil, with
>> at least a helper to get the struct size (this is for ABI reasons, so
>> we can extend the struct later). But then this side data would need a
>> specific name, not a generic one like "ancillary".
>> 
>> The display mastering thing is valid for both packets and frames, which
>> might be confusing. The thing you add is needed for packets only.
>> 
>> I'd prefer the "ancillary" name and making it just a flat byte array
>> instead of a struct and something specific. The former would be like
>> extradata, just per packet.
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>> 
> 
> A flat array would be useless and very codec specific (e.g. if you throw
> that side data at one codec it would act in a different way than another
> codec), a struct is the way to go here. I don't mind adding another untyped
> data if 

Re: [FFmpeg-devel] [PATCH v6 1/3] avcodec: add flags for packets with top/bottom field

[Rostislav Pehlivanov]

On 23 May 2018 at 20:49, wm4  wrote:

> On Wed, 23 May 2018 20:25:34 +0100
> Rostislav Pehlivanov  wrote:
>
> > On 23 May 2018 at 20:01, wm4  wrote:
> >
> > > On Wed, 23 May 2018 14:29:38 -0400 (EDT)
> > > Patrick Keroulas  wrote:
> > >
> > > > - Original Message -
> > > > > From: "wm4" 
> > > > > To: ffmpeg-devel@ffmpeg.org
> > > > > Sent: Wednesday, May 23, 2018 12:02:45 PM
> > > > > Subject: Re: [FFmpeg-devel] [PATCH v6 1/3] avcodec: add flags for
> > > packets with top/bottom field
> > > >
> > > > > On Wed, 23 May 2018 16:46:17 +0100
> > > > > Rostislav Pehlivanov  wrote:
> > > > >
> > > > >> On 23 May 2018 at 16:18, wm4  wrote:
> > > > >>
> > > > >> > On Tue, 22 May 2018 17:19:35 -0400 (EDT)
> > > > >> > Patrick Keroulas  wrote:
> > > > >> >
> > > > >> > > - Original Message -
> > > > >> > > > From: "Rostislav Pehlivanov" 
> > > > >> > > > To: "FFmpeg development discussions and patches" <
> > > > >> > ffmpeg-devel@ffmpeg.org>
> > > > >> > > > Sent: Friday, May 18, 2018 5:28:42 PM
> > > > >> > > > Subject: Re: [FFmpeg-devel] [PATCH v6 1/3] avcodec: add
> flags
> > > for
> > > > >> > packets with top/bottom field
> > > > >> > >
> > > > >> > > > On 18 May 2018 at 22:17, wm4 
> wrote:
> > > > >> > >
> > > > >> > >
> > > > >> > >
> > > > >> > > > > But I think a new side data type would be much saner. We
> > > could even
> > > > >> > > > > just make it something generic, like
> AV_PKT_DATA_ANCILLARY or
> > > > >> > > > > something. It's apparently just packet data which
> somehow
> > > couldn't go
> > > > >> > > > > into the packet data.
> > > > >> > >
> > > > >> > >
> > > > >> > > > I agree, a generic ancillary side data type sounds better.
> It
> > > would
> > > > >> > have to
> > > > >> > > > be handled the same way as mastering metadata (e.g. to
> allocate
> > > it
> > > > >> > you'd
> > > > >> > > > need to use a separate function), since the size of the
> data
> > > struct
> > > > >> > can't
> > > > >> > > > be part of the API if we intend to add fields later.
> > > > >> > > > Patrick, if you're okay with that you should submit a
> patch
> > > which bases
> > > > >> > > > such side data on libavutil/mastering_display_metadata.h/.c
>
> > > > >> > >
> > > > >> > > No problem for transmitting field flags through side data.
> But
> > > the given
> > > > >> > > example (libavutil/mastering_display_metadata.h/.c)
> attaches
> > > data to
> > > > >> > > AVFrame, not AVPacket, so I'm not sure where to place this
> > > separate
> > > > >> > > allocator function. Do you recommend to create a new
> > > > >> > > libavcodec/ancillary.c/h utility?
> > > > >> >
> > > > >> > The example you mentioned exists for AVPacket too (it's just
> not
> > > easy
> > > > >> > to see how it can end up in AVPacket, because no demuxer does
> that
> > > > >> > directly).
> > > > >> >
> > > > >> > Anyway, ancillary side data would just be an untyped byte
> array, so
> > > I
> > > > >> > don't think it needs any helpers. Just an addition to the
> packet
> > > side
> > > > >> > data enum (I think it's somewhere in avcodec.h).
> > > > >> > ___
> > > > >> > ffmpeg-devel mailing list
> > > > >> > ffmpeg-devel@ffmpeg.org
> > > > >> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> > > > >> >
> > > > >>
> > > > >> I'd rather have it as a well defined typed array rather than a
> bunch
> > > of
> > > > >> bytes. Otherwise we'd start sending unknown side data info and
> users
> > > > >> wouldn't know what to do with it.
> > > > >
> > > > > Unless you're adding some meta object system for describing
> arbitrary
> > > > > types at runtime I don't know how you'd do that.
> > > >
> > > > Is that ok if I simply define a basic struct to hold the field?
> > > >
> > > > Any suggestion on where to insert the definition of this data and the
> > > > accessors in lavc? In a new source file?
> > >
> > > If you make it a struct, then make a new file in libavutil, with
> > > at least a helper to get the struct size (this is for ABI reasons, so
> > > we can extend the struct later). But then this side data would need a
> > > specific name, not a generic one like "ancillary".
> > >
> > > The display mastering thing is valid for both packets and frames, which
> > > might be confusing. The thing you add is needed for packets only.
> > >
> > > I'd prefer the "ancillary" name and making it just a flat byte array
> > > instead of a struct and something specific. The former would be like
> > > extradata, just per packet.
> > > ___
> > > ffmpeg-devel mailing list
> > > ffmpeg-devel@ffmpeg.org
> > > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> > >
> >
> > A flat array would be useless and very codec 

Re: [FFmpeg-devel] [PATCH v6 1/3] avcodec: add flags for packets with top/bottom field

[wm4]

On Wed, 23 May 2018 20:25:34 +0100
Rostislav Pehlivanov  wrote:

> On 23 May 2018 at 20:01, wm4  wrote:
> 
> > On Wed, 23 May 2018 14:29:38 -0400 (EDT)
> > Patrick Keroulas  wrote:
> >  
> > > - Original Message -  
> > > > From: "wm4" 
> > > > To: ffmpeg-devel@ffmpeg.org
> > > > Sent: Wednesday, May 23, 2018 12:02:45 PM
> > > > Subject: Re: [FFmpeg-devel] [PATCH v6 1/3] avcodec: add flags for  
> > packets with top/bottom field  
> > >  
> > > > On Wed, 23 May 2018 16:46:17 +0100
> > > > Rostislav Pehlivanov  wrote:
> > > >  
> > > >> On 23 May 2018 at 16:18, wm4  wrote:
> > > >>  
> > > >> > On Tue, 22 May 2018 17:19:35 -0400 (EDT)
> > > >> > Patrick Keroulas  wrote:
> > > >> >  
> > > >> > > - Original Message -  
> > > >> > > > From: "Rostislav Pehlivanov" 
> > > >> > > > To: "FFmpeg development discussions and patches" <  
> > > >> > ffmpeg-devel@ffmpeg.org>  
> > > >> > > > Sent: Friday, May 18, 2018 5:28:42 PM
> > > >> > > > Subject: Re: [FFmpeg-devel] [PATCH v6 1/3] avcodec: add flags  
> > for  
> > > >> > packets with top/bottom field  
> > > >> > >  
> > > >> > > > On 18 May 2018 at 22:17, wm4  wrote:  
> > > >> > >
> > > >> > >
> > > >> > >  
> > > >> > > > > But I think a new side data type would be much saner. We  
> > could even  
> > > >> > > > > just make it something generic, like AV_PKT_DATA_ANCILLARY or
> > > >> > > > > something. It's apparently just packet data which somehow  
> > couldn't go  
> > > >> > > > > into the packet data.  
> > > >> > >
> > > >> > >  
> > > >> > > > I agree, a generic ancillary side data type sounds better. It  
> > would  
> > > >> > have to  
> > > >> > > > be handled the same way as mastering metadata (e.g. to allocate  
> > it  
> > > >> > you'd  
> > > >> > > > need to use a separate function), since the size of the data  
> > struct  
> > > >> > can't  
> > > >> > > > be part of the API if we intend to add fields later.
> > > >> > > > Patrick, if you're okay with that you should submit a patch  
> > which bases  
> > > >> > > > such side data on libavutil/mastering_display_metadata.h/.c  
> > > >> > >
> > > >> > > No problem for transmitting field flags through side data. But  
> > the given  
> > > >> > > example (libavutil/mastering_display_metadata.h/.c) attaches  
> > data to  
> > > >> > > AVFrame, not AVPacket, so I'm not sure where to place this  
> > separate  
> > > >> > > allocator function. Do you recommend to create a new
> > > >> > > libavcodec/ancillary.c/h utility?  
> > > >> >
> > > >> > The example you mentioned exists for AVPacket too (it's just not  
> > easy  
> > > >> > to see how it can end up in AVPacket, because no demuxer does that
> > > >> > directly).
> > > >> >
> > > >> > Anyway, ancillary side data would just be an untyped byte array, so  
> > I  
> > > >> > don't think it needs any helpers. Just an addition to the packet  
> > side  
> > > >> > data enum (I think it's somewhere in avcodec.h).
> > > >> > ___
> > > >> > ffmpeg-devel mailing list
> > > >> > ffmpeg-devel@ffmpeg.org
> > > >> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> > > >> >  
> > > >>
> > > >> I'd rather have it as a well defined typed array rather than a bunch  
> > of  
> > > >> bytes. Otherwise we'd start sending unknown side data info and users
> > > >> wouldn't know what to do with it.  
> > > >
> > > > Unless you're adding some meta object system for describing arbitrary
> > > > types at runtime I don't know how you'd do that.  
> > >
> > > Is that ok if I simply define a basic struct to hold the field?
> > >
> > > Any suggestion on where to insert the definition of this data and the
> > > accessors in lavc? In a new source file?  
> >
> > If you make it a struct, then make a new file in libavutil, with
> > at least a helper to get the struct size (this is for ABI reasons, so
> > we can extend the struct later). But then this side data would need a
> > specific name, not a generic one like "ancillary".
> >
> > The display mastering thing is valid for both packets and frames, which
> > might be confusing. The thing you add is needed for packets only.
> >
> > I'd prefer the "ancillary" name and making it just a flat byte array
> > instead of a struct and something specific. The former would be like
> > extradata, just per packet.
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >  
> 
> A flat array would be useless and very codec specific (e.g. if you throw
> that side data at one codec it would act in a different way than another
> codec), a struct is the way to go here. I don't mind adding another untyped
> data if there was a reason, but 

Re: [FFmpeg-devel] [PATCH v6 1/3] avcodec: add flags for packets with top/bottom field

[Rostislav Pehlivanov]

On 23 May 2018 at 20:01, wm4  wrote:

> On Wed, 23 May 2018 14:29:38 -0400 (EDT)
> Patrick Keroulas  wrote:
>
> > - Original Message -
> > > From: "wm4" 
> > > To: ffmpeg-devel@ffmpeg.org
> > > Sent: Wednesday, May 23, 2018 12:02:45 PM
> > > Subject: Re: [FFmpeg-devel] [PATCH v6 1/3] avcodec: add flags for
> packets with top/bottom field
> >
> > > On Wed, 23 May 2018 16:46:17 +0100
> > > Rostislav Pehlivanov  wrote:
> > >
> > >> On 23 May 2018 at 16:18, wm4  wrote:
> > >>
> > >> > On Tue, 22 May 2018 17:19:35 -0400 (EDT)
> > >> > Patrick Keroulas  wrote:
> > >> >
> > >> > > - Original Message -
> > >> > > > From: "Rostislav Pehlivanov" 
> > >> > > > To: "FFmpeg development discussions and patches" <
> > >> > ffmpeg-devel@ffmpeg.org>
> > >> > > > Sent: Friday, May 18, 2018 5:28:42 PM
> > >> > > > Subject: Re: [FFmpeg-devel] [PATCH v6 1/3] avcodec: add flags
> for
> > >> > packets with top/bottom field
> > >> > >
> > >> > > > On 18 May 2018 at 22:17, wm4  wrote:
> > >> > >
> > >> > >
> > >> > >
> > >> > > > > But I think a new side data type would be much saner. We
> could even
> > >> > > > > just make it something generic, like AV_PKT_DATA_ANCILLARY or
> > >> > > > > something. It's apparently just packet data which somehow
> couldn't go
> > >> > > > > into the packet data.
> > >> > >
> > >> > >
> > >> > > > I agree, a generic ancillary side data type sounds better. It
> would
> > >> > have to
> > >> > > > be handled the same way as mastering metadata (e.g. to allocate
> it
> > >> > you'd
> > >> > > > need to use a separate function), since the size of the data
> struct
> > >> > can't
> > >> > > > be part of the API if we intend to add fields later.
> > >> > > > Patrick, if you're okay with that you should submit a patch
> which bases
> > >> > > > such side data on libavutil/mastering_display_metadata.h/.c
> > >> > >
> > >> > > No problem for transmitting field flags through side data. But
> the given
> > >> > > example (libavutil/mastering_display_metadata.h/.c) attaches
> data to
> > >> > > AVFrame, not AVPacket, so I'm not sure where to place this
> separate
> > >> > > allocator function. Do you recommend to create a new
> > >> > > libavcodec/ancillary.c/h utility?
> > >> >
> > >> > The example you mentioned exists for AVPacket too (it's just not
> easy
> > >> > to see how it can end up in AVPacket, because no demuxer does that
> > >> > directly).
> > >> >
> > >> > Anyway, ancillary side data would just be an untyped byte array, so
> I
> > >> > don't think it needs any helpers. Just an addition to the packet
> side
> > >> > data enum (I think it's somewhere in avcodec.h).
> > >> > ___
> > >> > ffmpeg-devel mailing list
> > >> > ffmpeg-devel@ffmpeg.org
> > >> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> > >> >
> > >>
> > >> I'd rather have it as a well defined typed array rather than a bunch
> of
> > >> bytes. Otherwise we'd start sending unknown side data info and users
> > >> wouldn't know what to do with it.
> > >
> > > Unless you're adding some meta object system for describing arbitrary
> > > types at runtime I don't know how you'd do that.
> >
> > Is that ok if I simply define a basic struct to hold the field?
> >
> > Any suggestion on where to insert the definition of this data and the
> > accessors in lavc? In a new source file?
>
> If you make it a struct, then make a new file in libavutil, with
> at least a helper to get the struct size (this is for ABI reasons, so
> we can extend the struct later). But then this side data would need a
> specific name, not a generic one like "ancillary".
>
> The display mastering thing is valid for both packets and frames, which
> might be confusing. The thing you add is needed for packets only.
>
> I'd prefer the "ancillary" name and making it just a flat byte array
> instead of a struct and something specific. The former would be like
> extradata, just per packet.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

A flat array would be useless and very codec specific (e.g. if you throw
that side data at one codec it would act in a different way than another
codec), a struct is the way to go here. I don't mind adding another untyped
data if there was a reason, but what we're trying to solve here is very
well defined - determine the field of each packet.

Patrick, like I said, use libavutil/mastering_display_metadata.c/h as a
template.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v6 1/3] avcodec: add flags for packets with top/bottom field

[wm4]

On Wed, 23 May 2018 14:29:38 -0400 (EDT)
Patrick Keroulas  wrote:

> - Original Message -
> > From: "wm4" 
> > To: ffmpeg-devel@ffmpeg.org
> > Sent: Wednesday, May 23, 2018 12:02:45 PM
> > Subject: Re: [FFmpeg-devel] [PATCH v6 1/3] avcodec: add flags for packets 
> > with top/bottom field  
> 
> > On Wed, 23 May 2018 16:46:17 +0100
> > Rostislav Pehlivanov  wrote:
> >   
> >> On 23 May 2018 at 16:18, wm4  wrote:
> >>   
> >> > On Tue, 22 May 2018 17:19:35 -0400 (EDT)
> >> > Patrick Keroulas  wrote:
> >> >   
> >> > > - Original Message -  
> >> > > > From: "Rostislav Pehlivanov" 
> >> > > > To: "FFmpeg development discussions and patches" <  
> >> > ffmpeg-devel@ffmpeg.org>  
> >> > > > Sent: Friday, May 18, 2018 5:28:42 PM
> >> > > > Subject: Re: [FFmpeg-devel] [PATCH v6 1/3] avcodec: add flags for  
> >> > packets with top/bottom field  
> >> > >   
> >> > > > On 18 May 2018 at 22:17, wm4  wrote:  
> >> > > 
> >> > > 
> >> > >   
> >> > > > > But I think a new side data type would be much saner. We could even
> >> > > > > just make it something generic, like AV_PKT_DATA_ANCILLARY or
> >> > > > > something. It's apparently just packet data which somehow couldn't 
> >> > > > > go
> >> > > > > into the packet data.  
> >> > > 
> >> > >   
> >> > > > I agree, a generic ancillary side data type sounds better. It would  
> >> > have to  
> >> > > > be handled the same way as mastering metadata (e.g. to allocate it  
> >> > you'd  
> >> > > > need to use a separate function), since the size of the data struct  
> >> > can't  
> >> > > > be part of the API if we intend to add fields later.
> >> > > > Patrick, if you're okay with that you should submit a patch which 
> >> > > > bases
> >> > > > such side data on libavutil/mastering_display_metadata.h/.c  
> >> > > 
> >> > > No problem for transmitting field flags through side data. But the 
> >> > > given
> >> > > example (libavutil/mastering_display_metadata.h/.c) attaches data to
> >> > > AVFrame, not AVPacket, so I'm not sure where to place this separate
> >> > > allocator function. Do you recommend to create a new
> >> > > libavcodec/ancillary.c/h utility?  
> >> > 
> >> > The example you mentioned exists for AVPacket too (it's just not easy
> >> > to see how it can end up in AVPacket, because no demuxer does that
> >> > directly).
> >> > 
> >> > Anyway, ancillary side data would just be an untyped byte array, so I
> >> > don't think it needs any helpers. Just an addition to the packet side
> >> > data enum (I think it's somewhere in avcodec.h).
> >> > ___
> >> > ffmpeg-devel mailing list
> >> > ffmpeg-devel@ffmpeg.org
> >> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >> >   
> >> 
> >> I'd rather have it as a well defined typed array rather than a bunch of
> >> bytes. Otherwise we'd start sending unknown side data info and users
> >> wouldn't know what to do with it.  
> > 
> > Unless you're adding some meta object system for describing arbitrary
> > types at runtime I don't know how you'd do that.  
> 
> Is that ok if I simply define a basic struct to hold the field?
> 
> Any suggestion on where to insert the definition of this data and the 
> accessors in lavc? In a new source file?

If you make it a struct, then make a new file in libavutil, with
at least a helper to get the struct size (this is for ABI reasons, so
we can extend the struct later). But then this side data would need a
specific name, not a generic one like "ancillary".

The display mastering thing is valid for both packets and frames, which
might be confusing. The thing you add is needed for packets only.

I'd prefer the "ancillary" name and making it just a flat byte array
instead of a struct and something specific. The former would be like
extradata, just per packet.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v6 1/3] avcodec: add flags for packets with top/bottom field

[Patrick Keroulas]

- Original Message -
> From: "wm4" 
> To: ffmpeg-devel@ffmpeg.org
> Sent: Wednesday, May 23, 2018 12:02:45 PM
> Subject: Re: [FFmpeg-devel] [PATCH v6 1/3] avcodec: add flags for packets 
> with top/bottom field

> On Wed, 23 May 2018 16:46:17 +0100
> Rostislav Pehlivanov  wrote:
> 
>> On 23 May 2018 at 16:18, wm4  wrote:
>> 
>> > On Tue, 22 May 2018 17:19:35 -0400 (EDT)
>> > Patrick Keroulas  wrote:
>> > 
>> > > - Original Message -
>> > > > From: "Rostislav Pehlivanov" 
>> > > > To: "FFmpeg development discussions and patches" <
>> > ffmpeg-devel@ffmpeg.org>
>> > > > Sent: Friday, May 18, 2018 5:28:42 PM
>> > > > Subject: Re: [FFmpeg-devel] [PATCH v6 1/3] avcodec: add flags for
>> > packets with top/bottom field
>> > > 
>> > > > On 18 May 2018 at 22:17, wm4  wrote:
>> > > 
>> > > 
>> > > 
>> > > > > But I think a new side data type would be much saner. We could even
>> > > > > just make it something generic, like AV_PKT_DATA_ANCILLARY or
>> > > > > something. It's apparently just packet data which somehow couldn't go
>> > > > > into the packet data.
>> > > 
>> > > 
>> > > > I agree, a generic ancillary side data type sounds better. It would
>> > have to
>> > > > be handled the same way as mastering metadata (e.g. to allocate it
>> > you'd
>> > > > need to use a separate function), since the size of the data struct
>> > can't
>> > > > be part of the API if we intend to add fields later.
>> > > > Patrick, if you're okay with that you should submit a patch which bases
>> > > > such side data on libavutil/mastering_display_metadata.h/.c
>> > > 
>> > > No problem for transmitting field flags through side data. But the given
>> > > example (libavutil/mastering_display_metadata.h/.c) attaches data to
>> > > AVFrame, not AVPacket, so I'm not sure where to place this separate
>> > > allocator function. Do you recommend to create a new
>> > > libavcodec/ancillary.c/h utility?
>> > 
>> > The example you mentioned exists for AVPacket too (it's just not easy
>> > to see how it can end up in AVPacket, because no demuxer does that
>> > directly).
>> > 
>> > Anyway, ancillary side data would just be an untyped byte array, so I
>> > don't think it needs any helpers. Just an addition to the packet side
>> > data enum (I think it's somewhere in avcodec.h).
>> > ___
>> > ffmpeg-devel mailing list
>> > ffmpeg-devel@ffmpeg.org
>> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>> > 
>> 
>> I'd rather have it as a well defined typed array rather than a bunch of
>> bytes. Otherwise we'd start sending unknown side data info and users
>> wouldn't know what to do with it.
> 
> Unless you're adding some meta object system for describing arbitrary
> types at runtime I don't know how you'd do that.

Is that ok if I simply define a basic struct to hold the field?

Any suggestion on where to insert the definition of this data and the 
accessors in lavc? In a new source file?

> ___
> 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 v6 1/3] avcodec: add flags for packets with top/bottom field

[wm4]

On Wed, 23 May 2018 16:46:17 +0100
Rostislav Pehlivanov  wrote:

> On 23 May 2018 at 16:18, wm4  wrote:
> 
> > On Tue, 22 May 2018 17:19:35 -0400 (EDT)
> > Patrick Keroulas  wrote:
> >  
> > > - Original Message -  
> > > > From: "Rostislav Pehlivanov" 
> > > > To: "FFmpeg development discussions and patches" <  
> > ffmpeg-devel@ffmpeg.org>  
> > > > Sent: Friday, May 18, 2018 5:28:42 PM
> > > > Subject: Re: [FFmpeg-devel] [PATCH v6 1/3] avcodec: add flags for  
> > packets with top/bottom field  
> > >  
> > > > On 18 May 2018 at 22:17, wm4  wrote:  
> > >
> > >
> > >  
> > > > > But I think a new side data type would be much saner. We could even
> > > > > just make it something generic, like AV_PKT_DATA_ANCILLARY or
> > > > > something. It's apparently just packet data which somehow couldn't go
> > > > > into the packet data.  
> > >
> > >  
> > > > I agree, a generic ancillary side data type sounds better. It would  
> > have to  
> > > > be handled the same way as mastering metadata (e.g. to allocate it  
> > you'd  
> > > > need to use a separate function), since the size of the data struct  
> > can't  
> > > > be part of the API if we intend to add fields later.
> > > > Patrick, if you're okay with that you should submit a patch which bases
> > > > such side data on libavutil/mastering_display_metadata.h/.c  
> > >
> > > No problem for transmitting field flags through side data. But the given
> > > example (libavutil/mastering_display_metadata.h/.c) attaches data to
> > > AVFrame, not AVPacket, so I'm not sure where to place this separate
> > > allocator function. Do you recommend to create a new
> > > libavcodec/ancillary.c/h utility?  
> >
> > The example you mentioned exists for AVPacket too (it's just not easy
> > to see how it can end up in AVPacket, because no demuxer does that
> > directly).
> >
> > Anyway, ancillary side data would just be an untyped byte array, so I
> > don't think it needs any helpers. Just an addition to the packet side
> > data enum (I think it's somewhere in avcodec.h).
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >  
> 
> I'd rather have it as a well defined typed array rather than a bunch of
> bytes. Otherwise we'd start sending unknown side data info and users
> wouldn't know what to do with it.

Unless you're adding some meta object system for describing arbitrary
types at runtime I don't know how you'd do that.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v6 1/3] avcodec: add flags for packets with top/bottom field

[Rostislav Pehlivanov]

On 23 May 2018 at 16:18, wm4  wrote:

> On Tue, 22 May 2018 17:19:35 -0400 (EDT)
> Patrick Keroulas  wrote:
>
> > - Original Message -
> > > From: "Rostislav Pehlivanov" 
> > > To: "FFmpeg development discussions and patches" <
> ffmpeg-devel@ffmpeg.org>
> > > Sent: Friday, May 18, 2018 5:28:42 PM
> > > Subject: Re: [FFmpeg-devel] [PATCH v6 1/3] avcodec: add flags for
> packets with top/bottom field
> >
> > > On 18 May 2018 at 22:17, wm4  wrote:
> >
> >
> >
> > > > But I think a new side data type would be much saner. We could even
> > > > just make it something generic, like AV_PKT_DATA_ANCILLARY or
> > > > something. It's apparently just packet data which somehow couldn't go
> > > > into the packet data.
> >
> >
> > > I agree, a generic ancillary side data type sounds better. It would
> have to
> > > be handled the same way as mastering metadata (e.g. to allocate it
> you'd
> > > need to use a separate function), since the size of the data struct
> can't
> > > be part of the API if we intend to add fields later.
> > > Patrick, if you're okay with that you should submit a patch which bases
> > > such side data on libavutil/mastering_display_metadata.h/.c
> >
> > No problem for transmitting field flags through side data. But the given
> > example (libavutil/mastering_display_metadata.h/.c) attaches data to
> > AVFrame, not AVPacket, so I'm not sure where to place this separate
> > allocator function. Do you recommend to create a new
> > libavcodec/ancillary.c/h utility?
>
> The example you mentioned exists for AVPacket too (it's just not easy
> to see how it can end up in AVPacket, because no demuxer does that
> directly).
>
> Anyway, ancillary side data would just be an untyped byte array, so I
> don't think it needs any helpers. Just an addition to the packet side
> data enum (I think it's somewhere in avcodec.h).
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

I'd rather have it as a well defined typed array rather than a bunch of
bytes. Otherwise we'd start sending unknown side data info and users
wouldn't know what to do with it.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavfi: add opencl tonemap filter.

[Niklas Haas]

On Mon, 21 May 2018 14:50:17 +0800, Ruiling Song  wrote:
> +float3 map_one_pixel_rgb(float3 rgb, float peak, float average) {
> +float sig = max(max(rgb.x, max(rgb.y, rgb.z)), 1e-6f);
> +// de-saturate
> +if (desat_param > 0.0f) {
> +float luma = get_luma_dst(rgb);
> +float base = 0.18f * dst_peak;
> +float coeff = max(sig - base, 1e-6f) / max(sig, 1e-6f);
> +coeff = native_powr(coeff, 10.0f / desat_param);
> +rgb = mix(rgb, (float3)luma, (float3)coeff);
> +sig = mix(sig, luma, coeff);
> +}
> +
> +float sig_old = sig;
> +float slope = min(1.0f, sdr_avg / average);
> +sig *= slope;
> +peak *= slope;
> +
> +sig = TONE_FUNC(sig, peak);
> +rgb *= (sig/sig_old);
> +return rgb;

Actually a better way to do this is to swap the order of the `slope`
adjustment  and the desaturation step. This prevents a problematic case
where very bright (badly mastered) sources ended up getting too
aggressively desaturated.

Some care needs to be taken when swapping the order in order to scale
the multiplication in the correct way. This should work:

  float3 map_one_pixel_rgb(float3 rgb, float peak, float average) {
  float sig = max(max(rgb.x, max(rgb.y, rgb.z)), 1e-6f);
  float sig_old = sig;
  float slope = min(1.0f, sdr_avg / average);
  sig *= slope;
  peak *= slope;

  // de-saturate
  if (desat_param > 0.0f) {
  float luma = get_luma_dst(rgb);
  float base = 0.18f * dst_peak;
  float coeff = max(sig - base, 1e-6f) / max(sig, 1e-6f);
  coeff = native_powr(coeff, 10.0f / desat_param);
  rgb = mix(rgb, (float3)luma, (float3)coeff);
  sig = mix(sig, luma * slope, coeff);
  }

  sig = TONE_FUNC(sig, peak);
  rgb *= (sig/sig_old);
  return rgb;

I found out about this while testing some pathological HLG sources
earlier today.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH][ticket #5522] lavc/cfhd: interlaced frame decoding added

[Paul B Mahol]

On 5/23/18, Carl Eugen Hoyos  wrote:
> 2018-05-23 0:21 GMT+02:00, Hendrik Leppkes :
>> On Tue, May 22, 2018 at 10:35 PM, Carl Eugen Hoyos 
>> wrote:
>>> 2018-05-22 17:40 GMT+02:00, Gagandeep Singh :
>>>
 +low= s->plane[plane].subband[0];
 +high   = s->plane[plane].subband[8];
 +output = s->plane[plane].l_h[6];
 +for (i = 0; i < lowpass_width; i++) {
 +vert_filter(output, lowpass_width, low, lowpass_width,
 high, highpass_stride, lowpass_height);
 +low++;
 +high++;
 +output++;
 +}

 -low= s->plane[plane].subband[0];
 -high   = s->plane[plane].subband[8];
 -output = s->plane[plane].l_h[6];
 -for (i = 0; i < lowpass_width; i++) {
 -vert_filter(output, lowpass_width, low, lowpass_width,
 high,
 highpass_stride, lowpass_height);
 -low++;
 -high++;
 -output++;
 -}
>>>
>>> The patch will get much more readable (and easier to review)
>>> if you do not re-indent, instead send a second patch with the
>>> cosmetic changes only.
>>>
>>
>> Except, no sane developer works like that.
>
> It's great to know that you are so much smarter than most developers,
> I will forward the next regression directly to you to fix it.

CoC violation. First warning given.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v6 1/3] avcodec: add flags for packets with top/bottom field

[wm4]

On Tue, 22 May 2018 17:19:35 -0400 (EDT)
Patrick Keroulas  wrote:

> - Original Message -
> > From: "Rostislav Pehlivanov" 
> > To: "FFmpeg development discussions and patches" 
> > Sent: Friday, May 18, 2018 5:28:42 PM
> > Subject: Re: [FFmpeg-devel] [PATCH v6 1/3] avcodec: add flags for packets 
> > with top/bottom field  
> 
> > On 18 May 2018 at 22:17, wm4  wrote:  
> 
> 
> 
> > > But I think a new side data type would be much saner. We could even
> > > just make it something generic, like AV_PKT_DATA_ANCILLARY or
> > > something. It's apparently just packet data which somehow couldn't go
> > > into the packet data.  
> 
> 
> > I agree, a generic ancillary side data type sounds better. It would have to
> > be handled the same way as mastering metadata (e.g. to allocate it you'd
> > need to use a separate function), since the size of the data struct can't
> > be part of the API if we intend to add fields later.
> > Patrick, if you're okay with that you should submit a patch which bases
> > such side data on libavutil/mastering_display_metadata.h/.c  
> 
> No problem for transmitting field flags through side data. But the given
> example (libavutil/mastering_display_metadata.h/.c) attaches data to
> AVFrame, not AVPacket, so I'm not sure where to place this separate
> allocator function. Do you recommend to create a new 
> libavcodec/ancillary.c/h utility?

The example you mentioned exists for AVPacket too (it's just not easy
to see how it can end up in AVPacket, because no demuxer does that
directly).

Anyway, ancillary side data would just be an untyped byte array, so I
don't think it needs any helpers. Just an addition to the packet side
data enum (I think it's somewhere in avcodec.h).
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH][ticket #5522] lavc/cfhd: interlaced frame decoding added

[wm4]

On Wed, 23 May 2018 00:21:56 +0200
Hendrik Leppkes  wrote:

> On Tue, May 22, 2018 at 10:35 PM, Carl Eugen Hoyos  wrote:
> > 2018-05-22 17:40 GMT+02:00, Gagandeep Singh :
> >  
> >> +low= s->plane[plane].subband[0];
> >> +high   = s->plane[plane].subband[8];
> >> +output = s->plane[plane].l_h[6];
> >> +for (i = 0; i < lowpass_width; i++) {
> >> +vert_filter(output, lowpass_width, low, lowpass_width,
> >> high, highpass_stride, lowpass_height);
> >> +low++;
> >> +high++;
> >> +output++;
> >> +}
> >>
> >> -low= s->plane[plane].subband[0];
> >> -high   = s->plane[plane].subband[8];
> >> -output = s->plane[plane].l_h[6];
> >> -for (i = 0; i < lowpass_width; i++) {
> >> -vert_filter(output, lowpass_width, low, lowpass_width, high,
> >> highpass_stride, lowpass_height);
> >> -low++;
> >> -high++;
> >> -output++;
> >> -}  
> >
> > The patch will get much more readable (and easier to review)
> > if you do not re-indent, instead send a second patch with the
> > cosmetic changes only.
> >  
> 
> Except, no sane developer works like that. In fact many editors will
> even indent for you automatically if you add new blocks, so splitting
> this is a really annoying task to perform.
> Instead, may I suggest a proper patch viewer which can ignore
> whitespace changes? It makes reading patches with indent changes
> trivial.

+1

We could add instructions to the docs how to make patches with
whitespace changes ignored.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] lavu/hwcontext_vaapi: add nv21 map

[wm4]

On Wed, 23 May 2018 18:29:20 +0800
Jun Zhao  wrote:

> Signed-off-by: Jun Zhao 
> ---
>  libavutil/hwcontext_vaapi.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
> index 5bdb02f..7b3cbea 100644
> --- a/libavutil/hwcontext_vaapi.c
> +++ b/libavutil/hwcontext_vaapi.c
> @@ -100,6 +100,9 @@ static const struct {
>  enum AVPixelFormat pix_fmt;
>  } vaapi_format_map[] = {
>  MAP(NV12, YUV420,  NV12),
> +#ifdef VA_FOURCC_NV21
> +MAP(NV21, YUV420,  NV21),// As NV12 with U and V reversed
> +#endif
>  MAP(YV12, YUV420,  YUV420P), // With U/V planes swapped.
>  MAP(IYUV, YUV420,  YUV420P),
>  #ifdef VA_FOURCC_I420

Why does this format exist and why is it "needed"?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH]lavc/hevc_ps: Use correct pix_fmt for 9 bit monochrome.

[Carl Eugen Hoyos]

Hi!

Attached patch uses the new AV_PIX_FMT_GRAY9 for monochrome hevc input.

Please comment, Carl Eugen
From 16a6f6b552d130600557fd19c7f86cd54c08c858 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Wed, 23 May 2018 15:04:24 +0200
Subject: [PATCH] lavc/hevc_ps: Use correct pix_fmt for 9 bit monochrome.

---
 libavcodec/hevc_ps.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
index f877fa5..bca3abb 100644
--- a/libavcodec/hevc_ps.c
+++ b/libavcodec/hevc_ps.c
@@ -825,7 +825,7 @@ static int map_pixel_format(AVCodecContext *avctx, HEVCSPS *sps)
 if (sps->chroma_format_idc == 3) sps->pix_fmt = AV_PIX_FMT_YUV444P;
break;
 case 9:
-if (sps->chroma_format_idc == 0) sps->pix_fmt = AV_PIX_FMT_GRAY16;
+if (sps->chroma_format_idc == 0) sps->pix_fmt = AV_PIX_FMT_GRAY9;
 if (sps->chroma_format_idc == 1) sps->pix_fmt = AV_PIX_FMT_YUV420P9;
 if (sps->chroma_format_idc == 2) sps->pix_fmt = AV_PIX_FMT_YUV422P9;
 if (sps->chroma_format_idc == 3) sps->pix_fmt = AV_PIX_FMT_YUV444P9;
-- 
1.7.10.4

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

Re: [FFmpeg-devel] [PATCH v2] lavc/qsv: suppress code scan complain

[Carl Eugen Hoyos]

2018-05-23 12:46 GMT+02:00, Zhong Li :
> Suppress the complain "variables 'type' is used but maybe uninitialized".
> ---
>  libavcodec/qsv.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/qsv.c b/libavcodec/qsv.c
> index 45e1c25..3ff4f2c 100644
> --- a/libavcodec/qsv.c
> +++ b/libavcodec/qsv.c
> @@ -31,6 +31,7 @@
>  #include "libavutil/hwcontext.h"
>  #include "libavutil/hwcontext_qsv.h"
>  #include "libavutil/imgutils.h"
> +#include "libavutil/avassert.h"
>
>  #include "avcodec.h"
>  #include "qsv_internal.h"
> @@ -197,7 +198,7 @@ int ff_qsv_find_surface_idx(QSVFramesContext *ctx,
> QSVFrame *frame)
>
>  enum AVPictureType ff_qsv_map_pictype(int mfx_pic_type)
>  {
> -enum AVPictureType type;
> +enum AVPictureType type = AV_PICTURE_TYPE_NONE;
>  switch (mfx_pic_type & 0x7) {
>  case MFX_FRAMETYPE_I:
>  if (mfx_pic_type & MFX_FRAMETYPE_S)
> @@ -214,6 +215,8 @@ enum AVPictureType ff_qsv_map_pictype(int mfx_pic_type)
>  else
>  type = AV_PICTURE_TYPE_P;
>  break;
> +default:
> +av_assert0(0);

I didn't test but I would have expected that exactly one
of these changes is sufficient to silence the warning, no?

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

Re: [FFmpeg-devel] [PATCH] lavfi: add opencl tonemap filter.

[Niklas Haas]

> Excellent explanation. I think I get your idea. Will refine the code per your 
> suggestion.
> But still some question, will people/tools tend to fill in the mastering 
> information for HLG video?
> I currently see no document that recommend to fill the mastering display for 
> HLG.
> I only have one HLG sample download from 4kmedia.org. seems it has no 
> mastering metadata.
> Do you have any more HLG videos that show it will often be filled in?
> My concern here is will all video players correctly parse the mastering 
> display metadata to decode HLG, or just skip it because most HLG video has no 
> metadata?

I think there's probably going to be three ways to approach this
situation. Part of the problem is surely the fact that HLG is sort of
designed to be "implicitly" tone-mapped. That is, the way the HLG
standard is written, you'd just always encode things so that 12.0 is the
brightest peak brightness, and a user with a 500 cd/m² peak TV would
just apply the HLG OOTF tuned for 500 cd/m² on the original signal as
received from the (e.g. blu-ray) source. Sure, the mastering engineer
may have used a 1500 cd/m² screen to master it, but since the HLG
OOTF-OOTF round-trip essentially constitutes a simple form of
tone-mapping, the overall result on-screen will look more or less
reasonable. (Certainly more reasonable than e.g. PQ)

So surely there's the camp of people that believe HLG doesn't need
mastering metadata and will therefore not include it, because the end
result without metadata looks more or less good enough. However, I
disagree with this result. First of all, it prevents color-accurate
round-trips. The HLG OOTF is inherently color-distorting, so in a
color-managed workflow with calibrated devices, this methodology will
not be sufficient to ensure perceptually accurate reproduction. The
second reason is that as I said, the HLG OOTF-OOTF interaction
essentially constitutes a simple form of tone-mapping; but we can do
significantly better. I believe our tone mapping algorithm produces a
far better result (visually) than applying the HLG OOTF as-is,
especially when going to an SDR display. (If you're using mpv, you can
test this by playing a HLG source once with --vf=format:peak=10 and once
with --vf=format:peak=1. In the latter case, the only tone mapping being
done is the implicit HLG tone mapping). Not only are HLG sources I've
found inconsistently encoded, but also I find that the inherent HLG
tone-mapping tends to over-saturate the signal (similar to the result we
get if the desaturation strength is 0.0) while also boosting the gamma.

So if we subscribe to the idea that we need metadata to do
color-accurate tone mapping and reproduction, then the question becomes:
what do we do for un-tagged sources? The obvious approach is to assume a
(display-referred) signal peak of 10.0 (thus corresponding to a display
peak of 1000 cd/m², i.e. the HLG reference device). But I think if I was
to make a HLG release of my own, I would definitely try and include the
most accurate tagging possible. For example, if we have a clip available
in both PQ and HLG, I would use the PQ version's mastering metadata for
HLG as well.

Finally, to put the nail in the coffin of the idea that HLG doesn't need
metadata, we should realize that the mastering metadata isn't just there
to help you tone map the brightness levels, it also includes the
display's gamut capabilities - and for a good reason. When doing
desaturation in order to fit the BT.2020 signal into a (typically far
less than BT.2020) display response, knowing the gamut limitations of
the signal can similarly help users do a far better job than having to
assume the worst case scenario - for much the same reason that knowing
the signal's actual peak brightness can help users do a far better job
tone-mapping than having to assume a worst-case peak of 10,000 cd/m².
Indeed, in the best case scenario (your own display's gamut and
brightness capabilities match or exceed the mastering display's), both
of these can just be no-ops.

So if mastering metadata is beneficial at all, then we should also agree
that mastering metadata is beneficial to BT.2020 + HLG sources, simply
for the gamut data alone. The fact that HLG is ill-defined without
knowing the mastering display's brightness is just icing on the cake at
this point.

> As what I do now is tone mapping from HDR to SDR, do you think it is 
> meaningful to add the metadata for SDR video?

The mastering metadata is still useful for the gamut information as
explained. Since you're (most likely) encoding a BT.2020 signal that
doesn't use the full gamut range of BT.2020, even for SDR curves it can
be a good idea to preserve it.

> And looks like using a peak of 100 in inverse_ootf() when tone-mapping to sdr 
> is just ok?

Sure. That won't blow up, but using HLG to store an SDR signal is sort
of wasteful/pointless. Might as well use an actual SDR curve and skip
the inverse_ootf step altogether.

> 
> Thanks again for your 

Re: [FFmpeg-devel] [PATCH] avcodec/hevc: export chroma sample location

[Hendrik Leppkes]

On Wed, Apr 11, 2018 at 1:46 PM, Hendrik Leppkes  wrote:
> ---
>  libavcodec/hevcdec.c | 11 +++
>  1 file changed, 11 insertions(+)
>
> diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
> index c8877626d2..e8227a510b 100644
> --- a/libavcodec/hevcdec.c
> +++ b/libavcodec/hevcdec.c
> @@ -344,6 +344,17 @@ static void export_stream_params(AVCodecContext *avctx, 
> const HEVCParamSets *ps,
>  avctx->colorspace  = AVCOL_SPC_UNSPECIFIED;
>  }
>
> +if (sps->chroma_format_idc == 1) {
> +if (sps->vui.chroma_loc_info_present_flag) {
> +if (sps->vui.chroma_sample_loc_type_top_field <= 5)
> +avctx->chroma_sample_location = 
> sps->vui.chroma_sample_loc_type_top_field + 1;
> +else
> +avctx->chroma_sample_location = AVCHROMA_LOC_UNSPECIFIED;
> +} else
> +avctx->chroma_sample_location = AVCHROMA_LOC_LEFT;
> +} else
> +avctx->chroma_sample_location = AVCHROMA_LOC_UNSPECIFIED;
> +
>  if (vps->vps_timing_info_present_flag) {
>  num = vps->vps_num_units_in_tick;
>  den = vps->vps_time_scale;

If there are no further comments, i'll apply this soon with the nit addressed.

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

[FFmpeg-devel] [PATCH v2] lavc/qsv: suppress code scan complain

[Zhong Li]

Suppress the complain "variables 'type' is used but maybe uninitialized".
---
 libavcodec/qsv.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/libavcodec/qsv.c b/libavcodec/qsv.c
index 45e1c25..3ff4f2c 100644
--- a/libavcodec/qsv.c
+++ b/libavcodec/qsv.c
@@ -31,6 +31,7 @@
 #include "libavutil/hwcontext.h"
 #include "libavutil/hwcontext_qsv.h"
 #include "libavutil/imgutils.h"
+#include "libavutil/avassert.h"
 
 #include "avcodec.h"
 #include "qsv_internal.h"
@@ -197,7 +198,7 @@ int ff_qsv_find_surface_idx(QSVFramesContext *ctx, QSVFrame 
*frame)
 
 enum AVPictureType ff_qsv_map_pictype(int mfx_pic_type)
 {
-enum AVPictureType type;
+enum AVPictureType type = AV_PICTURE_TYPE_NONE;
 switch (mfx_pic_type & 0x7) {
 case MFX_FRAMETYPE_I:
 if (mfx_pic_type & MFX_FRAMETYPE_S)
@@ -214,6 +215,8 @@ enum AVPictureType ff_qsv_map_pictype(int mfx_pic_type)
 else
 type = AV_PICTURE_TYPE_P;
 break;
+default:
+av_assert0(0);
 }
 
 return type;
-- 
1.8.3.1

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

[FFmpeg-devel] [PATCH 0/2] misc change for iHD open source driver

[Jun Zhao]

- Add nv21 map
- Report more details decoding error

Jun Zhao (2):
  lavu/hwcontext_vaapi: dump more decoding error details.
  lavu/hwcontext_vaapi: add nv21 map

 libavutil/hwcontext_vaapi.c | 20 
 1 file changed, 20 insertions(+)

-- 
2.7.4

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

[FFmpeg-devel] [PATCH 2/2] lavu/hwcontext_vaapi: add nv21 map

[Jun Zhao]

Signed-off-by: Jun Zhao 
---
 libavutil/hwcontext_vaapi.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
index 5bdb02f..7b3cbea 100644
--- a/libavutil/hwcontext_vaapi.c
+++ b/libavutil/hwcontext_vaapi.c
@@ -100,6 +100,9 @@ static const struct {
 enum AVPixelFormat pix_fmt;
 } vaapi_format_map[] = {
 MAP(NV12, YUV420,  NV12),
+#ifdef VA_FOURCC_NV21
+MAP(NV21, YUV420,  NV21),// As NV12 with U and V reversed
+#endif
 MAP(YV12, YUV420,  YUV420P), // With U/V planes swapped.
 MAP(IYUV, YUV420,  YUV420P),
 #ifdef VA_FOURCC_I420
-- 
2.7.4

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

[FFmpeg-devel] [PATCH 1/2] lavu/hwcontext_vaapi: dump more decoding error details.

[Jun Zhao]

dump more decoding error details when sync surface fail.

Signed-off-by: Jun Zhao 
---
 libavutil/hwcontext_vaapi.c | 17 +
 1 file changed, 17 insertions(+)

diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
index e55bb8d..5bdb02f 100644
--- a/libavutil/hwcontext_vaapi.c
+++ b/libavutil/hwcontext_vaapi.c
@@ -742,6 +742,23 @@ static int vaapi_map_frame(AVHWFramesContext *hwfc,
 av_log(hwfc, AV_LOG_ERROR, "Failed to sync surface "
"%#x: %d (%s).\n", surface_id, vas, vaErrorStr(vas));
 err = AVERROR(EIO);
+/* query decode detail error */
+if (vas == VA_STATUS_ERROR_DECODING_ERROR) {
+VASurfaceDecodeMBErrors *dec_err = NULL;
+int i;
+vas = vaQuerySurfaceError(hwctx->display, surface_id, 
VA_STATUS_ERROR_DECODING_ERROR,
+  (void **)_err);
+if (VA_STATUS_SUCCESS == vas) {
+if (NULL != dec_err) {
+for (i = 0; dec_err[i].status != -1; i++) {
+  av_log(hwfc, AV_LOG_ERROR, "Decoding deatils error, "
+ "type: %d, start mb: %d, end md: %d, num mbs: 
%d.\n",
+ dec_err[i].decode_error_type, 
dec_err[i].start_mb,
+ dec_err[i].end_mb, dec_err[i].num_mb);
+}
+}
+}
+}
 goto fail;
 }
 
-- 
2.7.4

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

Re: [FFmpeg-devel] [PATCH] libavformat/mxfenc: Add some () to attempt to workaround build issue on osx

[Jim DeLaHunt]

On 5/22/2018 3:57 PM, Michael Niedermayer wrote:

May fix ticket7209

Signed-off-by: Michael Niedermayer http://ffmpeg.org/mailman/listinfo/ffmpeg-devel>>
---
 libavformat/mxfenc.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
index 44425bf6c9..77f60f5874 100644
--- a/libavformat/mxfenc.c
+++ b/libavformat/mxfenc.c
@@ -1149,23 +1149,23 @@ 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);
+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);
+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);
+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);
+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);
+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);
+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;


I independently authored this change on my Mac OS X 10.11.6 system. It was 
effective in correcting the compile errors
in libavformat/mxfenc.o, and then make fate ran successfully.

--
--Jim DeLaHunt, j...@jdlh.com http://blog.jdlh.com/ (http://jdlh.com/)
  multilingual websites consultant

  355-1027 Davie St, Vancouver BC V6E 4L2, Canada
 Canada mobile +1-604-376-8953

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