Re: [FFmpeg-devel] [PATCH v2 1/2] fftools/ffmpeg: fix progress log message in case pts is not available

[Tobias Rapp]

On 01.03.2018 22:08, Michael Niedermayer wrote:

On Wed, Feb 28, 2018 at 09:47:15AM +0100, Tobias Rapp wrote:

On 27.02.2018 19:03, Michael Niedermayer wrote:

On Tue, Feb 27, 2018 at 08:49:19AM +0100, Tobias Rapp wrote:

On 27.02.2018 01:12, Michael Niedermayer wrote:

On Mon, Feb 26, 2018 at 05:09:04PM +0100, Tobias Rapp wrote:

Move time string formatting into inline function. Also fixes out_time
sign prefix for progress report.

Signed-off-by: Tobias Rapp 
---
  fftools/ffmpeg.c | 48 +++-
  1 file changed, 31 insertions(+), 17 deletions(-)


[...]

+{
+const char *hours_sign;
+int hours, mins;
+double secs;
+
+if (pts == AV_NOPTS_VALUE) {
+snprintf(buf, AV_TS_MAX_STRING_SIZE, "N/A");
+} else {
+hours_sign = (pts < 0) ? "-" : "";
+secs = (double)FFABS(pts) / AV_TIME_BASE;
+mins = (int)secs / 60;
+secs = secs - mins * 60;
+hours = mins / 60;
+mins %= 60;


This is not the same code, also with double it can produce inexact
results and results differing between platforms


I changed secs to double to handle the cases with different number of
sub-second digits more easily. Would it be OK to output two digits after the
decimal point in both cases? The progress report contains the precise
out_time_ms value anyway.


iam not sure iam guessing correctly what you mean by "both cases"
you mean if its unneeded as in .00 ?
I guess that would be ok


There are two places within print_report() that output
hour/minute/seconds-formatted time. One is using HH:MM:SS.ZZ format and the
other one is using HH:MM:SS.ZZ format. Would it be OK to output
HH:MM:SS.ZZ (two digits after the decimal separator) in both places like in
the attached patch version?


iam not sure if the reduction of precission is a problem for some use case or 
not
But such a change doesnt belong in a patch factorizing the code.
It should be done seperately, if its changed


Factorizing the code *and* keeping the exact same behavior in both cases 
is pointless in my eyes as it just increases the amount and complexity 
of code for low benefit.


So please either consider this v3 patch or the original one posted in 
https://ffmpeg.org/pipermail/ffmpeg-devel/2018-February/225775.html


All I wanted to get fixed was the large negative value printed at the 
start of transcoding ... *sigh*


Regards,
Tobias

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

Re: [FFmpeg-devel] [PATCH 3/3] avcodec/nvenc: Declare support for P016

[Timo Rothenpieler]

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

It's definitely better than the current situation, and I can't think of
a scenario where it breaks something that's not already broken.
So LGTM from me.

The other patches also look sensible to me, but I'm not the one to Ok them.



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

Re: [FFmpeg-devel] [PATCH 2/3 v1.2] avcodec/vaapi: add fields for VAAPI VC-1 interlaced decoding

[Hendrik Leppkes]

On Fri, Mar 2, 2018 at 2:23 AM, Jun Zhao  wrote:
>
>
> On 2018/3/2 6:43, Mark Thompson wrote:
>> On 01/03/18 08:07, Jerome Borsboom wrote:
>>> v1.1->v1.2: Changed ifdefs around vc1_get_INTCOMPFIELD, vc1_get_LUMSCALE2,
>>> and vc1_get_LUMSHIFT2 to av_unused.
>>>
>>> avcodec/vaapi: add fields for VAAPI VC-1 interlaced decoding
>>>
>>> Pass necessary bitstream elements to the VAAPI VC-1 decoder in order
>>> to start doing interlaced decoding in hardware.
>>>
>>> Signed-off-by: Jerome Borsboom 
>>> ---
>>>  libavcodec/vaapi_vc1.c | 163 
>>> -
>>>  1 file changed, 134 insertions(+), 29 deletions(-)
>> Wrt hashes, here is fate/vc1/ilaced_twomv.vc1 from a few different decoders:
>>
>> libavcodec software decoder:
>>
>> 0,  0,  0,1,  3110400, 0x764f8856
>> 0,  2,  2,1,  3110400, 0x3b615b79
>> 0,  3,  3,1,  3110400, 0x4fbb6f84
>> 0,  4,  4,1,  3110400, 0xc1ca8532
>> 0,  5,  5,1,  3110400, 0xb6e7d363
>> 0,  6,  6,1,  3110400, 0x1beb5c34
>> 0,  7,  7,1,  3110400, 0xcb8cb061
>> 0,  8,  8,1,  3110400, 0x13ddbd61
>> 0,  9,  9,1,  3110400, 0xde8f052f
>> 0, 10, 10,1,  3110400, 0x4d4072db
>> 0, 11, 11,1,  3110400, 0x4e5d29e3
>> 0, 12, 12,1,  3110400, 0x75300531
>> 0, 13, 13,1,  3110400, 0x1114285a
>>
>> VAAPI, "Intel i965 driver for Intel(R) Coffee Lake - 2.1.1.pre1 
>> (2.0.0-140-gff23e69)":
>>
>> 0,  0,  0,1,  3110400, 0xc95e8861
>> 0,  2,  2,1,  3110400, 0xf58b5cbf
>> 0,  3,  3,1,  3110400, 0x2f866f33
>> 0,  4,  4,1,  3110400, 0x05c18415
>> 0,  5,  5,1,  3110400, 0x94dff199
>> 0,  6,  6,1,  3110400, 0xf31fda77
>> 0,  7,  7,1,  3110400, 0x60b1b2da
>> 0,  8,  8,1,  3110400, 0x748993f5
>> 0,  9,  9,1,  3110400, 0x750fdf14
>> 0, 10, 10,1,  3110400, 0x0879792c
>> 0, 11, 11,1,  3110400, 0x7e0e60fa
>> 0, 12, 12,1,  3110400, 0xda5bd837
>> 0, 13, 13,1,  3110400, 0xb6346ccf
>>
>> VAAPI, "Mesa Gallium driver 18.1.0-devel for AMD Radeon (TM) RX 460 Graphics 
>> (POLARIS11 / DRM 3.23.0 / 4.15.7, LLVM 4.0.1)":
>>
>> 0,  0,  0,1,  3110400, 0xc95e8861
>> 0,  2,  2,1,  3110400, 0xafefc967
>> 0,  3,  3,1,  3110400, 0x1d736d3b
>> 0,  4,  4,1,  3110400, 0x4f0fe807
>> 0,  5,  5,1,  3110400, 0x758c6e9b
>> 0,  6,  6,1,  3110400, 0x56a5c92a
>> 0,  7,  7,1,  3110400, 0xa60fcf66
>> 0,  8,  8,1,  3110400, 0x0c638017
>> 0,  9,  9,1,  3110400, 0x3fe3310c
>> 0, 10, 10,1,  3110400, 0x3d2ea8de
>> 0, 11, 11,1,  3110400, 0xe2f8de62
>> 0, 12, 12,1,  3110400, 0xa309cd68
>> 0, 13, 13,1,  3110400, 0x8602abb1
>>
>> Microsoft decoder (thanks to Hendrik for these):
>>
>> 0,  0,  0,1,  3110400, 0xc95e8861
>> 0,  2,  2,1,  3110400, 0xf58b5cbf
>> 0,  3,  3,1,  3110400, 0x2f866f33
>> 0,  4,  4,1,  3110400, 0x05c18415
>> 0,  5,  5,1,  3110400, 0x4077ca93
>> 0,  6,  6,1,  3110400, 0x44d105fc
>> 0,  7,  7,1,  3110400, 0xa0608374
>> 0,  8,  8,1,  3110400, 0x407689dc
>> 0,  9,  9,1,  3110400, 0x4707d00a
>> 0, 10, 10,1,  3110400, 0x74986831
>> 0, 11, 11,1,  3110400, 0xa5912619
>> 0, 12, 12,1,  3110400, 0x44aa5565
>> 0, 13, 13,1,  3110400, 0xb9752774
>>
>> The VAAPI hardware implementations agree with the Microsoft decoder for the 
>> initial four (Intel) or one (AMD) frames, while the software decoder doesn't 
>> agree at all.  Unfortunately the AMD output is completely broken after the 
>> first frame, but the Intel output does look sensible through the whole 
>> sequence.  So, while this could probably be improved in drivers just as it 
>> could in the software decoder, the FATE test is not relevant here so this 
>> discussion shouldn't block anything.
>>
>> As such, I'm happy to apply all of this as it is now.  Does anyone have any 
>> further comments, especially about the VC-1 parts of this change?  If not, 
>> I'll apply the whole set this weekend.
>>
>> Thanks,
>>
>> - Mark
> I am OK to merge

[FFmpeg-devel] add hevc_sao for checkasm

[Yingming Fan]

Hi there.

We are working on add some neon optimization for hevc decoder. But before 
submit neon codes i'd like to submit some checkasm codes. First one will be 
checkasm codes of SAO.

Yingming Fan

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

[FFmpeg-devel] [PATCH] checkasm/hevc_sao : add hevc_sao for checkasm

[Yingming Fan]

---
 tests/checkasm/Makefile   |   2 +-
 tests/checkasm/checkasm.c |   1 +
 tests/checkasm/checkasm.h |   1 +
 tests/checkasm/hevc_sao.c | 158 ++
 4 files changed, 161 insertions(+), 1 deletion(-)
 create mode 100644 tests/checkasm/hevc_sao.c

diff --git a/tests/checkasm/Makefile b/tests/checkasm/Makefile
index 77bdcf6e65..0520e264e2 100644
--- a/tests/checkasm/Makefile
+++ b/tests/checkasm/Makefile
@@ -23,7 +23,7 @@ AVCODECOBJS-$(CONFIG_EXR_DECODER)   += exrdsp.o
 AVCODECOBJS-$(CONFIG_HUFFYUV_DECODER)   += huffyuvdsp.o
 AVCODECOBJS-$(CONFIG_JPEG2000_DECODER)  += jpeg2000dsp.o
 AVCODECOBJS-$(CONFIG_PIXBLOCKDSP)   += pixblockdsp.o
-AVCODECOBJS-$(CONFIG_HEVC_DECODER)  += hevc_add_res.o hevc_idct.o
+AVCODECOBJS-$(CONFIG_HEVC_DECODER)  += hevc_add_res.o hevc_idct.o 
hevc_sao.o
 AVCODECOBJS-$(CONFIG_UTVIDEO_DECODER)   += utvideodsp.o
 AVCODECOBJS-$(CONFIG_V210_ENCODER)  += v210enc.o
 AVCODECOBJS-$(CONFIG_VP9_DECODER)   += vp9dsp.o
diff --git a/tests/checkasm/checkasm.c b/tests/checkasm/checkasm.c
index a4b8aff984..fe81d139c6 100644
--- a/tests/checkasm/checkasm.c
+++ b/tests/checkasm/checkasm.c
@@ -116,6 +116,7 @@ static const struct {
 #if CONFIG_HEVC_DECODER
 { "hevc_add_res", checkasm_check_hevc_add_res },
 { "hevc_idct", checkasm_check_hevc_idct },
+{ "hevc_sao", checkasm_check_hevc_sao },
 #endif
 #if CONFIG_HUFFYUV_DECODER
 { "huffyuvdsp", checkasm_check_huffyuvdsp },
diff --git a/tests/checkasm/checkasm.h b/tests/checkasm/checkasm.h
index 3de38e6717..8b9d96bc15 100644
--- a/tests/checkasm/checkasm.h
+++ b/tests/checkasm/checkasm.h
@@ -57,6 +57,7 @@ void checkasm_check_h264pred(void);
 void checkasm_check_h264qpel(void);
 void checkasm_check_hevc_add_res(void);
 void checkasm_check_hevc_idct(void);
+void checkasm_check_hevc_sao(void);
 void checkasm_check_huffyuvdsp(void);
 void checkasm_check_jpeg2000dsp(void);
 void checkasm_check_llviddsp(void);
diff --git a/tests/checkasm/hevc_sao.c b/tests/checkasm/hevc_sao.c
new file mode 100644
index 00..e2a0a54e9b
--- /dev/null
+++ b/tests/checkasm/hevc_sao.c
@@ -0,0 +1,158 @@
+/*
+ * Copyright (c) 2018 Yingming Fan 
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 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 General Public License for more details.
+ *
+ * You should have received a copy of the GNU 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/intreadwrite.h"
+
+#include "libavcodec/avcodec.h"
+
+#include "libavcodec/hevcdsp.h"
+
+#include "checkasm.h"
+
+static const uint32_t pixel_mask[3] = { 0x, 0x01ff01ff, 0x03ff03ff };
+static const uint32_t sao_size[5] = {8, 16, 32, 48, 64};
+
+#define SIZEOF_PIXEL ((bit_depth + 7) / 8)
+#define PIXEL_STRIDE (2*MAX_PB_SIZE + AV_INPUT_BUFFER_PADDING_SIZE) //same 
with sao_edge src_stride
+#define BUF_SIZE (PIXEL_STRIDE * (64+2) * 2) //+2 for top and bottom row, *2 
for high bit depth
+#define OFFSET_THRESH (1 << (bit_depth - 5))
+#define OFFSET_LENGTH 5
+
+#define randomize_buffers(buf0, buf1, size) \
+do {\
+uint32_t mask = pixel_mask[bit_depth - 8];  \
+int i;  \
+if (bit_depth == 8) {   \
+for (i = 0; i < size; i += 4) { \
+uint32_t r = rnd() & mask;  \
+AV_WN32A(buf0 + i, r);  \
+AV_WN32A(buf1 + i, r);  \
+}   \
+} else {\
+for (i = 0; i < size; i += 2) { \
+uint32_t r = rnd() & mask;  \
+AV_WN32A((uint16_t *)buf0 + i, r);  \
+AV_WN32A((uint16_t *)buf1 + i, r);  \
+}   \
+}   \
+} while (0)
+
+#define randomize_buffers2(buf, size)   \
+do {\
+uint32_t max_offset = OFFSET_THRESH;\
+int i;  \
+if (bit_depth == 8) {   \
+fo

[FFmpeg-devel] [PATCH v2] lavu/frame: add QP side data

[wm4]

This adds a way for an API user to transfer QP data and metadata without
having to keep the reference to AVFrame, and without having to
explicitly care about QP APIs. It might also provide a way to finally
remove the deprecated QP related fields. In the end, the QP table should
be handled in a very similar way to e.g. AV_FRAME_DATA_MOTION_VECTORS.

There are two side data types, because I didn't care about having to
repack the QP data so the table and the metadata are in a single
AVBufferRef. Otherwise it would have either required a copy on decoding
(extra slowdown for something as obscure as the QP data), or would have
required making intrusive changes to the codecs which support export of
this data.

The new side data types are added under deprecation guards, because I
don't intend to change the status of the QP export as being deprecated
(as it was before this patch too).
---
 libavutil/frame.c  | 59 ++
 libavutil/frame.h  | 17 +++
 tests/ref/fate/exif-image-embedded |  6 
 tests/ref/fate/exif-image-jpg  | 34 +-
 4 files changed, 96 insertions(+), 20 deletions(-)

diff --git a/libavutil/frame.c b/libavutil/frame.c
index 0db2a2d57b..ea13cd3ed6 100644
--- a/libavutil/frame.c
+++ b/libavutil/frame.c
@@ -46,8 +46,17 @@ MAKE_ACCESSORS(AVFrame, frame, enum AVColorRange, 
color_range)
av_get_channel_layout_nb_channels((frame)->channel_layout))
 
 #if FF_API_FRAME_QP
+struct qp_properties {
+int stride;
+int type;
+};
+
 int av_frame_set_qp_table(AVFrame *f, AVBufferRef *buf, int stride, int 
qp_type)
 {
+struct qp_properties *p;
+AVFrameSideData *sd;
+AVBufferRef *ref;
+
 FF_DISABLE_DEPRECATION_WARNINGS
 av_buffer_unref(&f->qp_table_buf);
 
@@ -57,20 +66,56 @@ FF_DISABLE_DEPRECATION_WARNINGS
 f->qscale_type  = qp_type;
 FF_ENABLE_DEPRECATION_WARNINGS
 
+av_frame_remove_side_data(f, AV_FRAME_DATA_QP_TABLE_PROPERTIES);
+av_frame_remove_side_data(f, AV_FRAME_DATA_QP_TABLE_DATA);
+
+ref = av_buffer_ref(buf);
+if (!av_frame_new_side_data_from_buf(f, AV_FRAME_DATA_QP_TABLE_DATA, ref)) 
{
+av_buffer_unref(&ref);
+return AVERROR(ENOMEM);
+}
+
+sd = av_frame_new_side_data(f, AV_FRAME_DATA_QP_TABLE_PROPERTIES,
+sizeof(struct qp_properties));
+if (!sd)
+return AVERROR(ENOMEM);
+
+p = (struct qp_properties *)sd->data;
+p->stride = stride;
+p->type = qp_type;
+
 return 0;
 }
 
 int8_t *av_frame_get_qp_table(AVFrame *f, int *stride, int *type)
 {
-FF_DISABLE_DEPRECATION_WARNINGS
-*stride = f->qstride;
-*type   = f->qscale_type;
+AVBufferRef *buf = NULL;
 
-if (!f->qp_table_buf)
-return NULL;
+*stride = 0;
+*type   = 0;
 
-return f->qp_table_buf->data;
+FF_DISABLE_DEPRECATION_WARNINGS
+if (f->qp_table_buf) {
+*stride = f->qstride;
+*type   = f->qscale_type;
+buf = f->qp_table_buf;
 FF_ENABLE_DEPRECATION_WARNINGS
+} else {
+AVFrameSideData *sd;
+struct qp_properties *p;
+sd = av_frame_get_side_data(f, AV_FRAME_DATA_QP_TABLE_PROPERTIES);
+if (!sd)
+return NULL;
+p = (struct qp_properties *)sd->data;
+sd = av_frame_get_side_data(f, AV_FRAME_DATA_QP_TABLE_DATA);
+if (!sd)
+return NULL;
+*stride = p->stride;
+*type   = p->type;
+buf = sd->buf;
+}
+
+return buf ? buf->data : NULL;
 }
 #endif
 
@@ -787,6 +832,8 @@ const char *av_frame_side_data_name(enum 
AVFrameSideDataType type)
 case AV_FRAME_DATA_CONTENT_LIGHT_LEVEL: return "Content light 
level metadata";
 case AV_FRAME_DATA_GOP_TIMECODE:return "GOP timecode";
 case AV_FRAME_DATA_ICC_PROFILE: return "ICC profile";
+case AV_FRAME_DATA_QP_TABLE_PROPERTIES: return "QP table 
properties";
+case AV_FRAME_DATA_QP_TABLE_DATA:   return "QP table data";
 }
 return NULL;
 }
diff --git a/libavutil/frame.h b/libavutil/frame.h
index ddbac3156d..9d57d6ce66 100644
--- a/libavutil/frame.h
+++ b/libavutil/frame.h
@@ -141,6 +141,23 @@ enum AVFrameSideDataType {
  * metadata key entry "name".
  */
 AV_FRAME_DATA_ICC_PROFILE,
+
+#if FF_API_FRAME_QP
+/**
+ * Implementation-specific description of the format of 
AV_FRAME_QP_TABLE_DATA.
+ * The contents of this side data are undocumented and internal; use
+ * av_frame_set_qp_table() and av_frame_get_qp_table() to access this in a
+ * meaningful way instead.
+ */
+AV_FRAME_DATA_QP_TABLE_PROPERTIES,
+
+/**
+ * Raw QP table data. Its format is described by
+ * AV_FRAME_DATA_QP_TABLE_PROPERTIES. Use av_frame_set_qp_table() and
+ * av_frame_get_qp_table() to access this instead.
+ */
+AV_FRAME_DATA_QP_TABLE_DATA,
+#endif
 };
 
 enum AVActiveFormatDescription {
diff --git a/tes

Re: [FFmpeg-devel] [PATCH] checkasm/hevc_sao : add hevc_sao for checkasm

[Yingming Fan]

If you want to test checkasm of hevc_sao, please use `checkasm 
--test=hevc_sao`, or `checkasm --test=hevc_sao --bench`.



> On 2 Mar 2018, at 7:03 PM, Yingming Fan  wrote:
> 
> ---
> tests/checkasm/Makefile   |   2 +-
> tests/checkasm/checkasm.c |   1 +
> tests/checkasm/checkasm.h |   1 +
> tests/checkasm/hevc_sao.c | 158 ++
> 4 files changed, 161 insertions(+), 1 deletion(-)
> create mode 100644 tests/checkasm/hevc_sao.c
> 
> diff --git a/tests/checkasm/Makefile b/tests/checkasm/Makefile
> index 77bdcf6e65..0520e264e2 100644
> --- a/tests/checkasm/Makefile
> +++ b/tests/checkasm/Makefile
> @@ -23,7 +23,7 @@ AVCODECOBJS-$(CONFIG_EXR_DECODER)   += exrdsp.o
> AVCODECOBJS-$(CONFIG_HUFFYUV_DECODER)   += huffyuvdsp.o
> AVCODECOBJS-$(CONFIG_JPEG2000_DECODER)  += jpeg2000dsp.o
> AVCODECOBJS-$(CONFIG_PIXBLOCKDSP)   += pixblockdsp.o
> -AVCODECOBJS-$(CONFIG_HEVC_DECODER)  += hevc_add_res.o hevc_idct.o
> +AVCODECOBJS-$(CONFIG_HEVC_DECODER)  += hevc_add_res.o hevc_idct.o 
> hevc_sao.o
> AVCODECOBJS-$(CONFIG_UTVIDEO_DECODER)   += utvideodsp.o
> AVCODECOBJS-$(CONFIG_V210_ENCODER)  += v210enc.o
> AVCODECOBJS-$(CONFIG_VP9_DECODER)   += vp9dsp.o
> diff --git a/tests/checkasm/checkasm.c b/tests/checkasm/checkasm.c
> index a4b8aff984..fe81d139c6 100644
> --- a/tests/checkasm/checkasm.c
> +++ b/tests/checkasm/checkasm.c
> @@ -116,6 +116,7 @@ static const struct {
> #if CONFIG_HEVC_DECODER
> { "hevc_add_res", checkasm_check_hevc_add_res },
> { "hevc_idct", checkasm_check_hevc_idct },
> +{ "hevc_sao", checkasm_check_hevc_sao },
> #endif
> #if CONFIG_HUFFYUV_DECODER
> { "huffyuvdsp", checkasm_check_huffyuvdsp },
> diff --git a/tests/checkasm/checkasm.h b/tests/checkasm/checkasm.h
> index 3de38e6717..8b9d96bc15 100644
> --- a/tests/checkasm/checkasm.h
> +++ b/tests/checkasm/checkasm.h
> @@ -57,6 +57,7 @@ void checkasm_check_h264pred(void);
> void checkasm_check_h264qpel(void);
> void checkasm_check_hevc_add_res(void);
> void checkasm_check_hevc_idct(void);
> +void checkasm_check_hevc_sao(void);
> void checkasm_check_huffyuvdsp(void);
> void checkasm_check_jpeg2000dsp(void);
> void checkasm_check_llviddsp(void);
> diff --git a/tests/checkasm/hevc_sao.c b/tests/checkasm/hevc_sao.c
> new file mode 100644
> index 00..e2a0a54e9b
> --- /dev/null
> +++ b/tests/checkasm/hevc_sao.c
> @@ -0,0 +1,158 @@
> +/*
> + * Copyright (c) 2018 Yingming Fan 
> + *
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 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 General Public License for more details.
> + *
> + * You should have received a copy of the GNU 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/intreadwrite.h"
> +
> +#include "libavcodec/avcodec.h"
> +
> +#include "libavcodec/hevcdsp.h"
> +
> +#include "checkasm.h"
> +
> +static const uint32_t pixel_mask[3] = { 0x, 0x01ff01ff, 0x03ff03ff };
> +static const uint32_t sao_size[5] = {8, 16, 32, 48, 64};
> +
> +#define SIZEOF_PIXEL ((bit_depth + 7) / 8)
> +#define PIXEL_STRIDE (2*MAX_PB_SIZE + AV_INPUT_BUFFER_PADDING_SIZE) //same 
> with sao_edge src_stride
> +#define BUF_SIZE (PIXEL_STRIDE * (64+2) * 2) //+2 for top and bottom row, *2 
> for high bit depth
> +#define OFFSET_THRESH (1 << (bit_depth - 5))
> +#define OFFSET_LENGTH 5
> +
> +#define randomize_buffers(buf0, buf1, size) \
> +do {\
> +uint32_t mask = pixel_mask[bit_depth - 8];  \
> +int i;  \
> +if (bit_depth == 8) {   \
> +for (i = 0; i < size; i += 4) { \
> +uint32_t r = rnd() & mask;  \
> +AV_WN32A(buf0 + i, r);  \
> +AV_WN32A(buf1 + i, r);  \
> +}   \
> +} else {\
> +for (i = 0; i < size; i += 2) { \
> +uint32_t r = rnd() & mask;  \
> +AV_WN32A((uint16_t *)buf0 + i, r);  \
> +AV_WN32A((uint16_t *)buf1 + i, r);  \
> +}   \
> +} 

[FFmpeg-devel] [PATCH] https://trac.ffmpeg.org/ticket/7030 fix

[Yuri Palich]

From 7056d06412214bd601afb4b423d20ab6100e6ac5 Mon Sep 17 00:00:00 2001
From: palich2000 
Date: Fri, 2 Mar 2018 11:48:22 +
Subject: [PATCH] https://trac.ffmpeg.org/ticket/7030 fix

---
 libavcodec/qsvenc_h264.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/libavcodec/qsvenc_h264.c b/libavcodec/qsvenc_h264.c
index 09e4c0e..5f60675 100644
--- a/libavcodec/qsvenc_h264.c
+++ b/libavcodec/qsvenc_h264.c
@@ -34,6 +34,7 @@
 #include "qsv.h"
 #include "qsv_internal.h"
 #include "qsvenc.h"
+#include "hwaccel.h"

 typedef struct QSVH264EncContext {
 AVClass *class;
@@ -169,6 +170,16 @@ static const AVCodecDefault qsv_enc_defaults[] = {
 { NULL },
 };

+#define HWACCEL_QSV(codec) \
+HW_CONFIG_HWACCEL(1, 1, 1, QSV,  QSV,  ff_ ## codec ##
_qsv_hwaccel)
+
+const AVHWAccel ff_h264_qsv_hwaccel = {
+.name = "h264_qsv",
+.type = AVMEDIA_TYPE_VIDEO,
+.id   = AV_CODEC_ID_H264,
+.pix_fmt  = AV_PIX_FMT_QSV
+};
+
 AVCodec ff_h264_qsv_encoder = {
 .name   = "h264_qsv",
 .long_name  = NULL_IF_CONFIG_SMALL("H.264 / AVC / MPEG-4 AVC /
MPEG-4 part 10 (Intel Quick Sync Video acceleration)"),
@@ -186,5 +197,9 @@ AVCodec ff_h264_qsv_encoder = {
 .priv_class = &class,
 .defaults   = qsv_enc_defaults,
 .caps_internal  = FF_CODEC_CAP_INIT_CLEANUP,
+.hw_configs= (const AVCodecHWConfigInternal*[]) {
+   HWACCEL_QSV(h264),
+NULL
+},
 .wrapper_name   = "qsv",
 };
-- 
1.8.3.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] https://trac.ffmpeg.org/ticket/7030 fix

[Hendrik Leppkes]

On Fri, Mar 2, 2018 at 12:54 PM, Yuri Palich  wrote:
> From 7056d06412214bd601afb4b423d20ab6100e6ac5 Mon Sep 17 00:00:00 2001
> From: palich2000 
> Date: Fri, 2 Mar 2018 11:48:22 +
> Subject: [PATCH] https://trac.ffmpeg.org/ticket/7030 fix
>
> ---
>  libavcodec/qsvenc_h264.c | 15 +++
>  1 file changed, 15 insertions(+)
>
> diff --git a/libavcodec/qsvenc_h264.c b/libavcodec/qsvenc_h264.c
> index 09e4c0e..5f60675 100644
> --- a/libavcodec/qsvenc_h264.c
> +++ b/libavcodec/qsvenc_h264.c
> @@ -34,6 +34,7 @@
>  #include "qsv.h"
>  #include "qsv_internal.h"
>  #include "qsvenc.h"
> +#include "hwaccel.h"
>
>  typedef struct QSVH264EncContext {
>  AVClass *class;
> @@ -169,6 +170,16 @@ static const AVCodecDefault qsv_enc_defaults[] = {
>  { NULL },
>  };
>
> +#define HWACCEL_QSV(codec) \
> +HW_CONFIG_HWACCEL(1, 1, 1, QSV,  QSV,  ff_ ## codec ##
> _qsv_hwaccel)
> +
> +const AVHWAccel ff_h264_qsv_hwaccel = {
> +.name = "h264_qsv",
> +.type = AVMEDIA_TYPE_VIDEO,
> +.id   = AV_CODEC_ID_H264,
> +.pix_fmt  = AV_PIX_FMT_QSV
> +};
> +

Didn't we intentionally get rid of those fake hwaccels some time ago?

>  AVCodec ff_h264_qsv_encoder = {
>  .name   = "h264_qsv",
>  .long_name  = NULL_IF_CONFIG_SMALL("H.264 / AVC / MPEG-4 AVC /
> MPEG-4 part 10 (Intel Quick Sync Video acceleration)"),
> @@ -186,5 +197,9 @@ AVCodec ff_h264_qsv_encoder = {
>  .priv_class = &class,
>  .defaults   = qsv_enc_defaults,
>  .caps_internal  = FF_CODEC_CAP_INIT_CLEANUP,
> +.hw_configs= (const AVCodecHWConfigInternal*[]) {
> +   HWACCEL_QSV(h264),
> +NULL
> +},
>  .wrapper_name   = "qsv",
>  };
> --
> 1.8.3.1
> ___
> 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] https://trac.ffmpeg.org/ticket/7030 fix

[Yuri Palich]

How can I get qsv to work without them?
​
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/mxg: return reference counted packets

[James Almer]

On 2/27/2018 12:09 AM, James Almer wrote:
> Signed-off-by: James Almer 
> ---
>  libavformat/mxg.c | 17 +++--
>  1 file changed, 11 insertions(+), 6 deletions(-)
> 
> diff --git a/libavformat/mxg.c b/libavformat/mxg.c
> index 6fbf99cfa3..fe5879ecf0 100644
> --- a/libavformat/mxg.c
> +++ b/libavformat/mxg.c
> @@ -169,11 +169,14 @@ static int mxg_read_packet(AVFormatContext *s, AVPacket 
> *pkt)
>  continue;
>  }
>  
> +size = mxg->buffer_ptr - mxg->soi_ptr;
> +ret = av_new_packet(pkt, size);
> +if (ret < 0)
> +return ret;
> +memcpy(pkt->data, mxg->soi_ptr, size);
> +
>  pkt->pts = pkt->dts = mxg->dts;
>  pkt->stream_index = 0;
> -pkt->buf  = NULL;
> -pkt->size = mxg->buffer_ptr - mxg->soi_ptr;
> -pkt->data = mxg->soi_ptr;
>  
>  if (mxg->soi_ptr - mxg->buffer > mxg->cache_size) {
>  if (mxg->cache_size > 0) {
> @@ -206,12 +209,14 @@ static int mxg_read_packet(AVFormatContext *s, AVPacket 
> *pkt)
>  mxg->buffer_ptr += size;
>  
>  if (marker == APP13 && size >= 16) { /* audio data */
> +ret = av_new_packet(pkt, size - 14);
> +if (ret < 0)
> +return ret;
> +memcpy(pkt->data, startmarker_ptr + 16, size - 14);
> +
>  /* time (GMT) of first sample in usec since 1970, 
> little-endian */
>  pkt->pts = pkt->dts = AV_RL64(startmarker_ptr + 8);
>  pkt->stream_index = 1;
> -pkt->buf  = NULL;
> -pkt->size = size - 14;
> -pkt->data = startmarker_ptr + 16;
>  
>  if (startmarker_ptr - mxg->buffer > mxg->cache_size) {
>  if (mxg->cache_size > 0) {

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

Re: [FFmpeg-devel] [PATCH] avformat/mxg: return reference counted packets

[wm4]

On Tue, 27 Feb 2018 00:09:47 -0300
James Almer  wrote:

> Signed-off-by: James Almer 
> ---
>  libavformat/mxg.c | 17 +++--
>  1 file changed, 11 insertions(+), 6 deletions(-)
> 
> diff --git a/libavformat/mxg.c b/libavformat/mxg.c
> index 6fbf99cfa3..fe5879ecf0 100644
> --- a/libavformat/mxg.c
> +++ b/libavformat/mxg.c
> @@ -169,11 +169,14 @@ static int mxg_read_packet(AVFormatContext *s, AVPacket 
> *pkt)
>  continue;
>  }
>  
> +size = mxg->buffer_ptr - mxg->soi_ptr;
> +ret = av_new_packet(pkt, size);
> +if (ret < 0)
> +return ret;
> +memcpy(pkt->data, mxg->soi_ptr, size);
> +
>  pkt->pts = pkt->dts = mxg->dts;
>  pkt->stream_index = 0;
> -pkt->buf  = NULL;
> -pkt->size = mxg->buffer_ptr - mxg->soi_ptr;
> -pkt->data = mxg->soi_ptr;
>  
>  if (mxg->soi_ptr - mxg->buffer > mxg->cache_size) {
>  if (mxg->cache_size > 0) {
> @@ -206,12 +209,14 @@ static int mxg_read_packet(AVFormatContext *s, AVPacket 
> *pkt)
>  mxg->buffer_ptr += size;
>  
>  if (marker == APP13 && size >= 16) { /* audio data */
> +ret = av_new_packet(pkt, size - 14);
> +if (ret < 0)
> +return ret;
> +memcpy(pkt->data, startmarker_ptr + 16, size - 14);
> +
>  /* time (GMT) of first sample in usec since 1970, 
> little-endian */
>  pkt->pts = pkt->dts = AV_RL64(startmarker_ptr + 8);
>  pkt->stream_index = 1;
> -pkt->buf  = NULL;
> -pkt->size = size - 14;
> -pkt->data = startmarker_ptr + 16;
>  
>  if (startmarker_ptr - mxg->buffer > mxg->cache_size) {
>  if (mxg->cache_size > 0) {

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

Re: [FFmpeg-devel] [PATCH v2] lavu/frame: add QP side data

[James Almer]

On 3/2/2018 8:16 AM, wm4 wrote:
> This adds a way for an API user to transfer QP data and metadata without
> having to keep the reference to AVFrame, and without having to
> explicitly care about QP APIs. It might also provide a way to finally
> remove the deprecated QP related fields. In the end, the QP table should
> be handled in a very similar way to e.g. AV_FRAME_DATA_MOTION_VECTORS.
> 
> There are two side data types, because I didn't care about having to
> repack the QP data so the table and the metadata are in a single
> AVBufferRef. Otherwise it would have either required a copy on decoding
> (extra slowdown for something as obscure as the QP data), or would have
> required making intrusive changes to the codecs which support export of
> this data.

Why not add an AVBufferRef pointer to the qp_properties struct instead?
You don't need to merge the properties fields into the buffer data.

> 
> The new side data types are added under deprecation guards, because I
> don't intend to change the status of the QP export as being deprecated
> (as it was before this patch too).
> ---
>  libavutil/frame.c  | 59 
> ++
>  libavutil/frame.h  | 17 +++
>  tests/ref/fate/exif-image-embedded |  6 
>  tests/ref/fate/exif-image-jpg  | 34 +-
>  4 files changed, 96 insertions(+), 20 deletions(-)
> 
> diff --git a/libavutil/frame.c b/libavutil/frame.c
> index 0db2a2d57b..ea13cd3ed6 100644
> --- a/libavutil/frame.c
> +++ b/libavutil/frame.c
> @@ -46,8 +46,17 @@ MAKE_ACCESSORS(AVFrame, frame, enum AVColorRange, 
> color_range)
> av_get_channel_layout_nb_channels((frame)->channel_layout))
>  
>  #if FF_API_FRAME_QP
> +struct qp_properties {
> +int stride;
> +int type;
> +};
> +
>  int av_frame_set_qp_table(AVFrame *f, AVBufferRef *buf, int stride, int 
> qp_type)
>  {
> +struct qp_properties *p;
> +AVFrameSideData *sd;
> +AVBufferRef *ref;
> +
>  FF_DISABLE_DEPRECATION_WARNINGS
>  av_buffer_unref(&f->qp_table_buf);
>  
> @@ -57,20 +66,56 @@ FF_DISABLE_DEPRECATION_WARNINGS
>  f->qscale_type  = qp_type;
>  FF_ENABLE_DEPRECATION_WARNINGS
>  
> +av_frame_remove_side_data(f, AV_FRAME_DATA_QP_TABLE_PROPERTIES);
> +av_frame_remove_side_data(f, AV_FRAME_DATA_QP_TABLE_DATA);
> +
> +ref = av_buffer_ref(buf);
> +if (!av_frame_new_side_data_from_buf(f, AV_FRAME_DATA_QP_TABLE_DATA, 
> ref)) {
> +av_buffer_unref(&ref);
> +return AVERROR(ENOMEM);
> +}
> +
> +sd = av_frame_new_side_data(f, AV_FRAME_DATA_QP_TABLE_PROPERTIES,
> +sizeof(struct qp_properties));
> +if (!sd)
> +return AVERROR(ENOMEM);
> +
> +p = (struct qp_properties *)sd->data;
> +p->stride = stride;
> +p->type = qp_type;
> +
>  return 0;
>  }
>  
>  int8_t *av_frame_get_qp_table(AVFrame *f, int *stride, int *type)
>  {
> -FF_DISABLE_DEPRECATION_WARNINGS
> -*stride = f->qstride;
> -*type   = f->qscale_type;
> +AVBufferRef *buf = NULL;
>  
> -if (!f->qp_table_buf)
> -return NULL;
> +*stride = 0;
> +*type   = 0;
>  
> -return f->qp_table_buf->data;
> +FF_DISABLE_DEPRECATION_WARNINGS
> +if (f->qp_table_buf) {
> +*stride = f->qstride;
> +*type   = f->qscale_type;
> +buf = f->qp_table_buf;
>  FF_ENABLE_DEPRECATION_WARNINGS
> +} else {
> +AVFrameSideData *sd;
> +struct qp_properties *p;
> +sd = av_frame_get_side_data(f, AV_FRAME_DATA_QP_TABLE_PROPERTIES);
> +if (!sd)
> +return NULL;
> +p = (struct qp_properties *)sd->data;
> +sd = av_frame_get_side_data(f, AV_FRAME_DATA_QP_TABLE_DATA);
> +if (!sd)
> +return NULL;
> +*stride = p->stride;
> +*type   = p->type;
> +buf = sd->buf;
> +}
> +
> +return buf ? buf->data : NULL;
>  }
>  #endif
>  
> @@ -787,6 +832,8 @@ const char *av_frame_side_data_name(enum 
> AVFrameSideDataType type)
>  case AV_FRAME_DATA_CONTENT_LIGHT_LEVEL: return "Content light 
> level metadata";
>  case AV_FRAME_DATA_GOP_TIMECODE:return "GOP timecode";
>  case AV_FRAME_DATA_ICC_PROFILE: return "ICC profile";
> +case AV_FRAME_DATA_QP_TABLE_PROPERTIES: return "QP table 
> properties";
> +case AV_FRAME_DATA_QP_TABLE_DATA:   return "QP table data";
>  }
>  return NULL;
>  }
> diff --git a/libavutil/frame.h b/libavutil/frame.h
> index ddbac3156d..9d57d6ce66 100644
> --- a/libavutil/frame.h
> +++ b/libavutil/frame.h
> @@ -141,6 +141,23 @@ enum AVFrameSideDataType {
>   * metadata key entry "name".
>   */
>  AV_FRAME_DATA_ICC_PROFILE,
> +
> +#if FF_API_FRAME_QP
> +/**
> + * Implementation-specific description of the format of 
> AV_FRAME_QP_TABLE_DATA.
> + * The contents of this side data are undocumented and internal; use
> + * av_

Re: [FFmpeg-devel] [PATCH] avformat/mxg: return reference counted packets

[James Almer]

On 3/2/2018 12:10 PM, wm4 wrote:
> On Tue, 27 Feb 2018 00:09:47 -0300
> James Almer  wrote:
> 
>> Signed-off-by: James Almer 
>> ---
>>  libavformat/mxg.c | 17 +++--
>>  1 file changed, 11 insertions(+), 6 deletions(-)
>>
>> diff --git a/libavformat/mxg.c b/libavformat/mxg.c
>> index 6fbf99cfa3..fe5879ecf0 100644
>> --- a/libavformat/mxg.c
>> +++ b/libavformat/mxg.c
>> @@ -169,11 +169,14 @@ static int mxg_read_packet(AVFormatContext *s, 
>> AVPacket *pkt)
>>  continue;
>>  }
>>  
>> +size = mxg->buffer_ptr - mxg->soi_ptr;
>> +ret = av_new_packet(pkt, size);
>> +if (ret < 0)
>> +return ret;
>> +memcpy(pkt->data, mxg->soi_ptr, size);
>> +
>>  pkt->pts = pkt->dts = mxg->dts;
>>  pkt->stream_index = 0;
>> -pkt->buf  = NULL;
>> -pkt->size = mxg->buffer_ptr - mxg->soi_ptr;
>> -pkt->data = mxg->soi_ptr;
>>  
>>  if (mxg->soi_ptr - mxg->buffer > mxg->cache_size) {
>>  if (mxg->cache_size > 0) {
>> @@ -206,12 +209,14 @@ static int mxg_read_packet(AVFormatContext *s, 
>> AVPacket *pkt)
>>  mxg->buffer_ptr += size;
>>  
>>  if (marker == APP13 && size >= 16) { /* audio data */
>> +ret = av_new_packet(pkt, size - 14);
>> +if (ret < 0)
>> +return ret;
>> +memcpy(pkt->data, startmarker_ptr + 16, size - 14);
>> +
>>  /* time (GMT) of first sample in usec since 1970, 
>> little-endian */
>>  pkt->pts = pkt->dts = AV_RL64(startmarker_ptr + 8);
>>  pkt->stream_index = 1;
>> -pkt->buf  = NULL;
>> -pkt->size = size - 14;
>> -pkt->data = startmarker_ptr + 16;
>>  
>>  if (startmarker_ptr - mxg->buffer > mxg->cache_size) {
>>  if (mxg->cache_size > 0) {
> 
> LGTM if FATE passes.

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

Re: [FFmpeg-devel] [PATCH v2] lavu/frame: add QP side data

[wm4]

On Fri, 2 Mar 2018 13:11:35 -0300
James Almer  wrote:

> On 3/2/2018 8:16 AM, wm4 wrote:
> > This adds a way for an API user to transfer QP data and metadata without
> > having to keep the reference to AVFrame, and without having to
> > explicitly care about QP APIs. It might also provide a way to finally
> > remove the deprecated QP related fields. In the end, the QP table should
> > be handled in a very similar way to e.g. AV_FRAME_DATA_MOTION_VECTORS.
> > 
> > There are two side data types, because I didn't care about having to
> > repack the QP data so the table and the metadata are in a single
> > AVBufferRef. Otherwise it would have either required a copy on decoding
> > (extra slowdown for something as obscure as the QP data), or would have
> > required making intrusive changes to the codecs which support export of
> > this data.  
> 
> Why not add an AVBufferRef pointer to the qp_properties struct instead?
> You don't need to merge the properties fields into the buffer data.

Not sure what you mean. The whole purpose of this is _not_ to add new
pointers because it'd require an API user to deal with extra fields
just for QP. I want to pretend that QP doesn't exist.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v3 0/2] libavfilter/vf_fps: Rewrite using activate callback

[Calvin Walton]

Ping?

I've been using this patch set in my production system for the past
week. There I've been running some fairly complicated filter pipelines
generated by scripts with good results - it's working reliably (no
stalls/hangs) and has solved my memory usage issue.

Calvin.

On Thu, 2018-02-22 at 14:10 -0500, Calvin Walton wrote:
> This revision of the patch fixes statistics by counting the number of
> times each frame has been output, rather than trying to guess at the
> time each frame is output whether it was a duplicate or drop.
> 
> I ended up leaving the conditional check
> if (s->status && s->frames_count == 0) {
> at the bottom of the activate function. I think I agree that the
> condition will always be true, based on the code flow, but the if
> statement documents the condition just as well as an assert would, and
> it's not like the EOF handling is in a hot path where we'd want to
> compile out the check.
> 
> Calvin Walton (2):
>   libavfilter/vf_fps: Rewrite using activate callback
>   libavfilter/vf_fps: Minor cleanups
> 
>  libavfilter/vf_fps.c | 392 
> ++-
>  1 file changed, 202 insertions(+), 190 deletions(-)
> 

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

[FFmpeg-devel] [PATCH] Add manu/modl to mov_read_udta_string.

[Tianqiang Liu]

From: Tianqiang Liu 

Documentation: http://mp4ra.org/atoms.html

---
 libavformat/mov.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index f01116874c..00b3b25944 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -336,6 +336,8 @@ static int mov_read_udta_string(MOVContext *c, AVIOContext 
*pb, MOVAtom atom)
 case MKTAG( 'l','d','e','s'): key = "synopsis";  break;
 case MKTAG( 'l','o','c','i'):
 return mov_metadata_loci(c, pb, atom.size);
+case MKTAG( 'm','a','n','u'): key = "make"; break;
+case MKTAG( 'm','o','d','l'): key = "model"; break;
 case MKTAG( 'p','c','s','t'): key = "podcast";
 parse = mov_metadata_int8_no_padding; break;
 case MKTAG( 'p','g','a','p'): key = "gapless_playback";
-- 
2.16.2.395.g2e18187dfd-goog

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

Re: [FFmpeg-devel] [PATCH v2] lavu/frame: add QP side data

[James Almer]

On 3/2/2018 1:47 PM, wm4 wrote:
> On Fri, 2 Mar 2018 13:11:35 -0300
> James Almer  wrote:
> 
>> On 3/2/2018 8:16 AM, wm4 wrote:
>>> This adds a way for an API user to transfer QP data and metadata without
>>> having to keep the reference to AVFrame, and without having to
>>> explicitly care about QP APIs. It might also provide a way to finally
>>> remove the deprecated QP related fields. In the end, the QP table should
>>> be handled in a very similar way to e.g. AV_FRAME_DATA_MOTION_VECTORS.
>>>
>>> There are two side data types, because I didn't care about having to
>>> repack the QP data so the table and the metadata are in a single
>>> AVBufferRef. Otherwise it would have either required a copy on decoding
>>> (extra slowdown for something as obscure as the QP data), or would have
>>> required making intrusive changes to the codecs which support export of
>>> this data.  
>>
>> Why not add an AVBufferRef pointer to the qp_properties struct instead?
>> You don't need to merge the properties fields into the buffer data.
> 
> Not sure what you mean. The whole purpose of this is _not_ to add new
> pointers because it'd require an API user to deal with extra fields
> just for QP. I want to pretend that QP doesn't exist.

I mean keep the buffer and the int fields all in a single opaque (for
the user) struct handled by a single side data type. The user still only
needs to worry about using the get/set functions and nothing else.

See the attached, untested PoC to get an idea of what i mean.

If I'm really missing the entire point of this patch (Which i don't
discard may be the case), then ignore this.
diff --git a/libavutil/frame.c b/libavutil/frame.c
index 0db2a2d57b..b349ff84fe 100644
--- a/libavutil/frame.c
+++ b/libavutil/frame.c
@@ -46,8 +46,28 @@ MAKE_ACCESSORS(AVFrame, frame, enum AVColorRange, 
color_range)
av_get_channel_layout_nb_channels((frame)->channel_layout))
 
 #if FF_API_FRAME_QP
+struct qp_properties {
+AVBufferRef *buf;
+int stride;
+int type;
+};
+
+// Free the qp_properties struct and the QP data buffer
+// To be used as the free() function for the side data buffer.
+static void frame_qp_free(void *opaque, uint8_t *data)
+{
+struct qp_properties *p = (struct qp_properties *)data;
+
+av_buffer_unref(&p->buf);
+av_free(data);
+}
+
 int av_frame_set_qp_table(AVFrame *f, AVBufferRef *buf, int stride, int 
qp_type)
 {
+struct qp_properties *p = NULL;
+AVFrameSideData *sd;
+AVBufferRef *sd_buf = NULL, *ref = NULL;
+
 FF_DISABLE_DEPRECATION_WARNINGS
 av_buffer_unref(&f->qp_table_buf);
 
@@ -57,20 +77,69 @@ FF_DISABLE_DEPRECATION_WARNINGS
 f->qscale_type  = qp_type;
 FF_ENABLE_DEPRECATION_WARNINGS
 
+av_frame_remove_side_data(f, AV_FRAME_DATA_QP_TABLE);
+
+// Create a new QP data table ref for the side data
+ref = av_buffer_ref(buf);
+if (!ref)
+return AVERROR(ENOMEM);
+
+// Alloc the qp_properties struct
+p = av_malloc(sizeof(struct qp_properties));
+if (!p)
+goto fail;
+
+// Create a buffer to be used in side data, containing the qp_properties 
struct.
+// Use a custom free() function to properly unref the QP table buffer when 
the side data
+// is removed.
+sd_buf = av_buffer_create((uint8_t *)p, sizeof(struct qp_properties), 
frame_qp_free, NULL, 0);
+if (!sd_buf)
+goto fail;
+
+// Add the buffer containing the qp_properties struct as side data
+sd = av_frame_new_side_data_from_buf(f, AV_FRAME_DATA_QP_TABLE, sd_buf);
+if (!sd)
+goto fail;
+
+// Fill the prop fields and the QP table buffer.
+p->stride = stride;
+p->type = qp_type;
+p->buf = ref;
+
 return 0;
+fail:
+av_buffer_unref(&ref);
+av_buffer_unref(&sd_buf);
+av_free(p);
+return AVERROR(ENOMEM);
 }
 
 int8_t *av_frame_get_qp_table(AVFrame *f, int *stride, int *type)
 {
-FF_DISABLE_DEPRECATION_WARNINGS
-*stride = f->qstride;
-*type   = f->qscale_type;
+AVBufferRef *buf = NULL;
 
-if (!f->qp_table_buf)
-return NULL;
+*stride = 0;
+*type   = 0;
 
-return f->qp_table_buf->data;
+FF_DISABLE_DEPRECATION_WARNINGS
+if (f->qp_table_buf) {
+*stride = f->qstride;
+*type   = f->qscale_type;
+buf = f->qp_table_buf;
 FF_ENABLE_DEPRECATION_WARNINGS
+} else {
+AVFrameSideData *sd;
+struct qp_properties *p;
+sd = av_frame_get_side_data(f, AV_FRAME_DATA_QP_TABLE);
+if (!sd)
+return NULL;
+p = (struct qp_properties *)sd->data;
+*stride = p->stride;
+*type   = p->type;
+buf = p->buf;
+}
+
+return buf ? buf->data : NULL;
 }
 #endif
 
@@ -787,6 +856,7 @@ const char *av_frame_side_data_name(enum 
AVFrameSideDataType type)
 case AV_FRAME_DATA_CONTENT_LIGHT_LEVEL: return "Content light 
level metadata";
 case AV_FRAME_DATA_GOP_TIMECODE:return "GOP timecode";
 case AV_FRAME_DATA_ICC_PR

Re: [FFmpeg-devel] [PATCH v3 0/2] libavfilter/vf_fps: Rewrite using activate callback

[Nicolas George]

Calvin Walton (2018-03-02):
> Ping?
> 
> I've been using this patch set in my production system for the past
> week. There I've been running some fairly complicated filter pipelines
> generated by scripts with good results - it's working reliably (no
> stalls/hangs) and has solved my memory usage issue.

Sorry, I was busy on other occupations. I will get back to it as soon as
possible.

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] [PATCH v2] lavu/frame: add QP side data

[wm4]

On Fri, 2 Mar 2018 14:30:28 -0300
James Almer  wrote:

> On 3/2/2018 1:47 PM, wm4 wrote:
> > On Fri, 2 Mar 2018 13:11:35 -0300
> > James Almer  wrote:
> > 
> >> On 3/2/2018 8:16 AM, wm4 wrote:
> >>> This adds a way for an API user to transfer QP data and metadata without
> >>> having to keep the reference to AVFrame, and without having to
> >>> explicitly care about QP APIs. It might also provide a way to finally
> >>> remove the deprecated QP related fields. In the end, the QP table should
> >>> be handled in a very similar way to e.g. AV_FRAME_DATA_MOTION_VECTORS.
> >>>
> >>> There are two side data types, because I didn't care about having to
> >>> repack the QP data so the table and the metadata are in a single
> >>> AVBufferRef. Otherwise it would have either required a copy on decoding
> >>> (extra slowdown for something as obscure as the QP data), or would have
> >>> required making intrusive changes to the codecs which support export of
> >>> this data.  
> >>
> >> Why not add an AVBufferRef pointer to the qp_properties struct instead?
> >> You don't need to merge the properties fields into the buffer data.
> > 
> > Not sure what you mean. The whole purpose of this is _not_ to add new
> > pointers because it'd require an API user to deal with extra fields
> > just for QP. I want to pretend that QP doesn't exist.
> 
> I mean keep the buffer and the int fields all in a single opaque (for
> the user) struct handled by a single side data type. The user still only
> needs to worry about using the get/set functions and nothing else.
> 
> See the attached, untested PoC to get an idea of what i mean.
> 
> If I'm really missing the entire point of this patch (Which i don't
> discard may be the case), then ignore this.

That would be nice, but unfortunately it's not allowed. An API user can
treat side data as byte arrays, and e.g. copy & restore it somewhere
(presumably even if the data is opaque and implementation defined).

So the side data can't contain any pointers. The user could copy
the byte data, unref the AVBufferRef, and later add it back as side
data using the copied bytes. Then it'd contain a dangling pointer.

The side data merging (which we even still provide as API) would be an
application for that - it's for AVPacket, but there's nothing that
prevents the same assumptions with AVFrames.

Unless we decide that at least AVFrame side data can contain pointers,
and the user must strictly use the AVBufferRef to manage the life time
of the data. Maybe I'm just overthinking this.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] checkasm/hevc_sao : add hevc_sao for checkasm

[Martin Vignali]

2018-03-02 12:48 GMT+01:00 Yingming Fan :

> If you want to test checkasm of hevc_sao, please use `checkasm
> --test=hevc_sao`, or `checkasm --test=hevc_sao --bench`.
>
>
>
> > On 2 Mar 2018, at 7:03 PM, Yingming Fan  wrote:
> >
> > ---
> > tests/checkasm/Makefile   |   2 +-
> > tests/checkasm/checkasm.c |   1 +
> > tests/checkasm/checkasm.h |   1 +
> > tests/checkasm/hevc_sao.c | 158 ++
> 
> > 4 files changed, 161 insertions(+), 1 deletion(-)
> > create mode 100644 tests/checkasm/hevc_sao.c
> >
>

You should add the checkasm test to fate
in file : ./tests/fate/checkasm.mak

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

Re: [FFmpeg-devel] [PATCH v2] lavu/frame: add QP side data

[James Almer]

On 3/2/2018 3:19 PM, wm4 wrote:
> On Fri, 2 Mar 2018 14:30:28 -0300
> James Almer  wrote:
> 
>> On 3/2/2018 1:47 PM, wm4 wrote:
>>> On Fri, 2 Mar 2018 13:11:35 -0300
>>> James Almer  wrote:
>>>
 On 3/2/2018 8:16 AM, wm4 wrote:
> This adds a way for an API user to transfer QP data and metadata without
> having to keep the reference to AVFrame, and without having to
> explicitly care about QP APIs. It might also provide a way to finally
> remove the deprecated QP related fields. In the end, the QP table should
> be handled in a very similar way to e.g. AV_FRAME_DATA_MOTION_VECTORS.
>
> There are two side data types, because I didn't care about having to
> repack the QP data so the table and the metadata are in a single
> AVBufferRef. Otherwise it would have either required a copy on decoding
> (extra slowdown for something as obscure as the QP data), or would have
> required making intrusive changes to the codecs which support export of
> this data.  

 Why not add an AVBufferRef pointer to the qp_properties struct instead?
 You don't need to merge the properties fields into the buffer data.
>>>
>>> Not sure what you mean. The whole purpose of this is _not_ to add new
>>> pointers because it'd require an API user to deal with extra fields
>>> just for QP. I want to pretend that QP doesn't exist.
>>
>> I mean keep the buffer and the int fields all in a single opaque (for
>> the user) struct handled by a single side data type. The user still only
>> needs to worry about using the get/set functions and nothing else.
>>
>> See the attached, untested PoC to get an idea of what i mean.
>>
>> If I'm really missing the entire point of this patch (Which i don't
>> discard may be the case), then ignore this.
> 
> That would be nice, but unfortunately it's not allowed. An API user can
> treat side data as byte arrays, and e.g. copy & restore it somewhere
> (presumably even if the data is opaque and implementation defined).
> 
> So the side data can't contain any pointers. The user could copy
> the byte data, unref the AVBufferRef, and later add it back as side
> data using the copied bytes. Then it'd contain a dangling pointer.

Afaik, ref counting was added for frame side data because
sizeof(AVFrameSideData) is not part of the ABI, meaning that users are
not supposed to manipulate side data with anything except the provided
API functions (new, remove, get, and now new_from_buf). Or at least that
was agreed in the relevant thread from some time ago.
This is not the case for AVPacketSideData, which is probably why it
never got a ref count upgrade.

> 
> The side data merging (which we even still provide as API) would be an
> application for that - it's for AVPacket, but there's nothing that
> prevents the same assumptions with AVFrames.
> 
> Unless we decide that at least AVFrame side data can contain pointers,
> and the user must strictly use the AVBufferRef to manage the life time
> of the data. Maybe I'm just overthinking this.

As i said, since the user is not expected to manipulate the side data
manually, then i don't see why it can't have pointers of any kind.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2] lavu/frame: add QP side data

[wm4]

On Fri, 2 Mar 2018 15:36:02 -0300
James Almer  wrote:

> On 3/2/2018 3:19 PM, wm4 wrote:
> > On Fri, 2 Mar 2018 14:30:28 -0300
> > James Almer  wrote:
> >   
> >> On 3/2/2018 1:47 PM, wm4 wrote:  
> >>> On Fri, 2 Mar 2018 13:11:35 -0300
> >>> James Almer  wrote:
> >>>  
>  On 3/2/2018 8:16 AM, wm4 wrote:  
> > This adds a way for an API user to transfer QP data and metadata without
> > having to keep the reference to AVFrame, and without having to
> > explicitly care about QP APIs. It might also provide a way to finally
> > remove the deprecated QP related fields. In the end, the QP table should
> > be handled in a very similar way to e.g. AV_FRAME_DATA_MOTION_VECTORS.
> >
> > There are two side data types, because I didn't care about having to
> > repack the QP data so the table and the metadata are in a single
> > AVBufferRef. Otherwise it would have either required a copy on decoding
> > (extra slowdown for something as obscure as the QP data), or would have
> > required making intrusive changes to the codecs which support export of
> > this data.
> 
>  Why not add an AVBufferRef pointer to the qp_properties struct instead?
>  You don't need to merge the properties fields into the buffer data.  
> >>>
> >>> Not sure what you mean. The whole purpose of this is _not_ to add new
> >>> pointers because it'd require an API user to deal with extra fields
> >>> just for QP. I want to pretend that QP doesn't exist.  
> >>
> >> I mean keep the buffer and the int fields all in a single opaque (for
> >> the user) struct handled by a single side data type. The user still only
> >> needs to worry about using the get/set functions and nothing else.
> >>
> >> See the attached, untested PoC to get an idea of what i mean.
> >>
> >> If I'm really missing the entire point of this patch (Which i don't
> >> discard may be the case), then ignore this.  
> > 
> > That would be nice, but unfortunately it's not allowed. An API user can
> > treat side data as byte arrays, and e.g. copy & restore it somewhere
> > (presumably even if the data is opaque and implementation defined).
> > 
> > So the side data can't contain any pointers. The user could copy
> > the byte data, unref the AVBufferRef, and later add it back as side
> > data using the copied bytes. Then it'd contain a dangling pointer.  
> 
> Afaik, ref counting was added for frame side data because
> sizeof(AVFrameSideData) is not part of the ABI, meaning that users are
> not supposed to manipulate side data with anything except the provided
> API functions (new, remove, get, and now new_from_buf). Or at least that
> was agreed in the relevant thread from some time ago.
> This is not the case for AVPacketSideData, which is probably why it
> never got a ref count upgrade.

I disagree. It appears the user is free to do with the side data
whatever he pleases, as long as he doesn't violate the underlying ABI
constraints (such as changing the sizer of side data backed by a
struct). But since all side data comes with a size, the data can be
freely copied around.

The side data merging I mentioned is an use case of this.

> > 
> > The side data merging (which we even still provide as API) would be an
> > application for that - it's for AVPacket, but there's nothing that
> > prevents the same assumptions with AVFrames.
> > 
> > Unless we decide that at least AVFrame side data can contain pointers,
> > and the user must strictly use the AVBufferRef to manage the life time
> > of the data. Maybe I'm just overthinking this.  
> 
> As i said, since the user is not expected to manipulate the side data
> manually, then i don't see why it can't have pointers of any kind.

If you think it's OK and others agree, I don't mind. Better to have a
single QP side data than 2.

If we do this, we should probably add a note to this effect.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] parseutils: add support for ms and us suffix for AV_OPT_TYPE_DURATION

[Michael Niedermayer]

On Thu, Mar 01, 2018 at 09:41:20PM +0100, Aurelien Jacobs wrote:
> supported suffixes are:
> - s: seconds (default when no suffix specified)
> - m or ms: milliseconds
> - u or us: microseconds
> ---
>  libavutil/parseutils.c | 15 +--
>  1 file changed, 13 insertions(+), 2 deletions(-)

can some of this and the si_prefixes related code in eval.c be
factored ?

either way this LGTM

thanks

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

The greatest way to live with honor in this world is to be what we pretend
to be. -- Socrates


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

Re: [FFmpeg-devel] [PATCH v2] lavu/frame: add QP side data

[Michael Niedermayer]

On Fri, Mar 02, 2018 at 03:36:02PM -0300, James Almer wrote:
> On 3/2/2018 3:19 PM, wm4 wrote:
> > On Fri, 2 Mar 2018 14:30:28 -0300
> > James Almer  wrote:
> > 
> >> On 3/2/2018 1:47 PM, wm4 wrote:
> >>> On Fri, 2 Mar 2018 13:11:35 -0300
> >>> James Almer  wrote:
> >>>
>  On 3/2/2018 8:16 AM, wm4 wrote:
> > This adds a way for an API user to transfer QP data and metadata without
> > having to keep the reference to AVFrame, and without having to
> > explicitly care about QP APIs. It might also provide a way to finally
> > remove the deprecated QP related fields. In the end, the QP table should
> > be handled in a very similar way to e.g. AV_FRAME_DATA_MOTION_VECTORS.
> >
> > There are two side data types, because I didn't care about having to
> > repack the QP data so the table and the metadata are in a single
> > AVBufferRef. Otherwise it would have either required a copy on decoding
> > (extra slowdown for something as obscure as the QP data), or would have
> > required making intrusive changes to the codecs which support export of
> > this data.  
> 
>  Why not add an AVBufferRef pointer to the qp_properties struct instead?
>  You don't need to merge the properties fields into the buffer data.
> >>>
> >>> Not sure what you mean. The whole purpose of this is _not_ to add new
> >>> pointers because it'd require an API user to deal with extra fields
> >>> just for QP. I want to pretend that QP doesn't exist.
> >>
> >> I mean keep the buffer and the int fields all in a single opaque (for
> >> the user) struct handled by a single side data type. The user still only
> >> needs to worry about using the get/set functions and nothing else.
> >>
> >> See the attached, untested PoC to get an idea of what i mean.
> >>
> >> If I'm really missing the entire point of this patch (Which i don't
> >> discard may be the case), then ignore this.
> > 
> > That would be nice, but unfortunately it's not allowed. An API user can
> > treat side data as byte arrays, and e.g. copy & restore it somewhere
> > (presumably even if the data is opaque and implementation defined).
> > 
> > So the side data can't contain any pointers. The user could copy
> > the byte data, unref the AVBufferRef, and later add it back as side
> > data using the copied bytes. Then it'd contain a dangling pointer.
> 
> Afaik, ref counting was added for frame side data because
> sizeof(AVFrameSideData) is not part of the ABI, meaning that users are
> not supposed to manipulate side data with anything except the provided
> API functions (new, remove, get, and now new_from_buf). Or at least that
> was agreed in the relevant thread from some time ago.
> This is not the case for AVPacketSideData, which is probably why it
> never got a ref count upgrade.
> 
> > 
> > The side data merging (which we even still provide as API) would be an
> > application for that - it's for AVPacket, but there's nothing that
> > prevents the same assumptions with AVFrames.
> > 
> > Unless we decide that at least AVFrame side data can contain pointers,
> > and the user must strictly use the AVBufferRef to manage the life time
> > of the data. Maybe I'm just overthinking this.
> 
> As i said, since the user is not expected to manipulate the side data
> manually, then i don't see why it can't have pointers of any kind.

The user has to pass the data she gets from the demuxer to the decoder,
from the decoder to filters from there to an encoder and then to a muxer.

If byte per byte copying of side data is not possible anymore how would
the user do this ?
Consider the user is most likely not basing her whole app on AVPackets
So she has to turn an AVPacket into something that can be passed within
the framework and language the application uses. 
So some form of generic array <-> side data copy or (de)serialization
would likely be needed

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

When the tyrant has disposed of foreign enemies by conquest or treaty, and
there is nothing more to fear from them, then he is always stirring up
some war or other, in order that the people may require a leader. -- Plato


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

Re: [FFmpeg-devel] [PATCH v2] lavu/frame: add QP side data

[James Almer]

On 3/2/2018 5:54 PM, Michael Niedermayer wrote:
> On Fri, Mar 02, 2018 at 03:36:02PM -0300, James Almer wrote:
>> On 3/2/2018 3:19 PM, wm4 wrote:
>>> On Fri, 2 Mar 2018 14:30:28 -0300
>>> James Almer  wrote:
>>>
 On 3/2/2018 1:47 PM, wm4 wrote:
> On Fri, 2 Mar 2018 13:11:35 -0300
> James Almer  wrote:
>
>> On 3/2/2018 8:16 AM, wm4 wrote:
>>> This adds a way for an API user to transfer QP data and metadata without
>>> having to keep the reference to AVFrame, and without having to
>>> explicitly care about QP APIs. It might also provide a way to finally
>>> remove the deprecated QP related fields. In the end, the QP table should
>>> be handled in a very similar way to e.g. AV_FRAME_DATA_MOTION_VECTORS.
>>>
>>> There are two side data types, because I didn't care about having to
>>> repack the QP data so the table and the metadata are in a single
>>> AVBufferRef. Otherwise it would have either required a copy on decoding
>>> (extra slowdown for something as obscure as the QP data), or would have
>>> required making intrusive changes to the codecs which support export of
>>> this data.  
>>
>> Why not add an AVBufferRef pointer to the qp_properties struct instead?
>> You don't need to merge the properties fields into the buffer data.
>
> Not sure what you mean. The whole purpose of this is _not_ to add new
> pointers because it'd require an API user to deal with extra fields
> just for QP. I want to pretend that QP doesn't exist.

 I mean keep the buffer and the int fields all in a single opaque (for
 the user) struct handled by a single side data type. The user still only
 needs to worry about using the get/set functions and nothing else.

 See the attached, untested PoC to get an idea of what i mean.

 If I'm really missing the entire point of this patch (Which i don't
 discard may be the case), then ignore this.
>>>
>>> That would be nice, but unfortunately it's not allowed. An API user can
>>> treat side data as byte arrays, and e.g. copy & restore it somewhere
>>> (presumably even if the data is opaque and implementation defined).
>>>
>>> So the side data can't contain any pointers. The user could copy
>>> the byte data, unref the AVBufferRef, and later add it back as side
>>> data using the copied bytes. Then it'd contain a dangling pointer.
>>
>> Afaik, ref counting was added for frame side data because
>> sizeof(AVFrameSideData) is not part of the ABI, meaning that users are
>> not supposed to manipulate side data with anything except the provided
>> API functions (new, remove, get, and now new_from_buf). Or at least that
>> was agreed in the relevant thread from some time ago.
>> This is not the case for AVPacketSideData, which is probably why it
>> never got a ref count upgrade.
>>
>>>
>>> The side data merging (which we even still provide as API) would be an
>>> application for that - it's for AVPacket, but there's nothing that
>>> prevents the same assumptions with AVFrames.
>>>
>>> Unless we decide that at least AVFrame side data can contain pointers,
>>> and the user must strictly use the AVBufferRef to manage the life time
>>> of the data. Maybe I'm just overthinking this.
>>
>> As i said, since the user is not expected to manipulate the side data
>> manually, then i don't see why it can't have pointers of any kind.
> 
> The user has to pass the data she gets from the demuxer to the decoder,
> from the decoder to filters from there to an encoder and then to a muxer.
> 
> If byte per byte copying of side data is not possible anymore how would
> the user do this ?

AVFrame side data is supposedly ref counted. Shouldn't av_frame_ref()
and av_frame_copy_props() both create new references of all source side
data as they do for the actual frame data and countless other
AVBufferRefs defined in AVFrame, and not do a memcpy of
AVFrameSideData->data from src to dst frame?

> Consider the user is most likely not basing her whole app on AVPackets
> So she has to turn an AVPacket into something that can be passed within
> the framework and language the application uses. 
> So some form of generic array <-> side data copy or (de)serialization
> would likely be needed

This is not about AVPackets. Those currently can be freely manipulated
as the user wishes.

It was established back when AVFrame refcounting was introduced that
users are not to manipulate frame side data manually, and must only use
the provided API.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2] lavu/frame: add QP side data

[wm4]

On Fri, 2 Mar 2018 18:17:30 -0300
James Almer  wrote:

> On 3/2/2018 5:54 PM, Michael Niedermayer wrote:
> > On Fri, Mar 02, 2018 at 03:36:02PM -0300, James Almer wrote:  
> >> On 3/2/2018 3:19 PM, wm4 wrote:  
> >>> On Fri, 2 Mar 2018 14:30:28 -0300
> >>> James Almer  wrote:
> >>>  
>  On 3/2/2018 1:47 PM, wm4 wrote:  
> > On Fri, 2 Mar 2018 13:11:35 -0300
> > James Almer  wrote:
> >  
> >> On 3/2/2018 8:16 AM, wm4 wrote:  
> >>> This adds a way for an API user to transfer QP data and metadata 
> >>> without
> >>> having to keep the reference to AVFrame, and without having to
> >>> explicitly care about QP APIs. It might also provide a way to finally
> >>> remove the deprecated QP related fields. In the end, the QP table 
> >>> should
> >>> be handled in a very similar way to e.g. AV_FRAME_DATA_MOTION_VECTORS.
> >>>
> >>> There are two side data types, because I didn't care about having to
> >>> repack the QP data so the table and the metadata are in a single
> >>> AVBufferRef. Otherwise it would have either required a copy on 
> >>> decoding
> >>> (extra slowdown for something as obscure as the QP data), or would 
> >>> have
> >>> required making intrusive changes to the codecs which support export 
> >>> of
> >>> this data.
> >>
> >> Why not add an AVBufferRef pointer to the qp_properties struct instead?
> >> You don't need to merge the properties fields into the buffer data.  
> >
> > Not sure what you mean. The whole purpose of this is _not_ to add new
> > pointers because it'd require an API user to deal with extra fields
> > just for QP. I want to pretend that QP doesn't exist.  
> 
>  I mean keep the buffer and the int fields all in a single opaque (for
>  the user) struct handled by a single side data type. The user still only
>  needs to worry about using the get/set functions and nothing else.
> 
>  See the attached, untested PoC to get an idea of what i mean.
> 
>  If I'm really missing the entire point of this patch (Which i don't
>  discard may be the case), then ignore this.  
> >>>
> >>> That would be nice, but unfortunately it's not allowed. An API user can
> >>> treat side data as byte arrays, and e.g. copy & restore it somewhere
> >>> (presumably even if the data is opaque and implementation defined).
> >>>
> >>> So the side data can't contain any pointers. The user could copy
> >>> the byte data, unref the AVBufferRef, and later add it back as side
> >>> data using the copied bytes. Then it'd contain a dangling pointer.  
> >>
> >> Afaik, ref counting was added for frame side data because
> >> sizeof(AVFrameSideData) is not part of the ABI, meaning that users are
> >> not supposed to manipulate side data with anything except the provided
> >> API functions (new, remove, get, and now new_from_buf). Or at least that
> >> was agreed in the relevant thread from some time ago.
> >> This is not the case for AVPacketSideData, which is probably why it
> >> never got a ref count upgrade.
> >>  
> >>>
> >>> The side data merging (which we even still provide as API) would be an
> >>> application for that - it's for AVPacket, but there's nothing that
> >>> prevents the same assumptions with AVFrames.
> >>>
> >>> Unless we decide that at least AVFrame side data can contain pointers,
> >>> and the user must strictly use the AVBufferRef to manage the life time
> >>> of the data. Maybe I'm just overthinking this.  
> >>
> >> As i said, since the user is not expected to manipulate the side data
> >> manually, then i don't see why it can't have pointers of any kind.  
> > 
> > The user has to pass the data she gets from the demuxer to the decoder,
> > from the decoder to filters from there to an encoder and then to a muxer.
> > 
> > If byte per byte copying of side data is not possible anymore how would
> > the user do this ?  
> 
> AVFrame side data is supposedly ref counted. Shouldn't av_frame_ref()
> and av_frame_copy_props() both create new references of all source side
> data as they do for the actual frame data and countless other
> AVBufferRefs defined in AVFrame, and not do a memcpy of
> AVFrameSideData->data from src to dst frame?

Whether it's refcounted or not doesn't matter at all.

> > Consider the user is most likely not basing her whole app on AVPackets
> > So she has to turn an AVPacket into something that can be passed within
> > the framework and language the application uses. 
> > So some form of generic array <-> side data copy or (de)serialization
> > would likely be needed  
> 
> This is not about AVPackets. Those currently can be freely manipulated
> as the user wishes.
> 
> It was established back when AVFrame refcounting was introduced that
> users are not to manipulate frame side data manually, and must only use
> the provided API.

Is that even documented anywhere? Sigh.
___
ffmpeg

Re: [FFmpeg-devel] [PATCH v2] lavu/frame: add QP side data

[Michael Niedermayer]

On Fri, Mar 02, 2018 at 06:17:30PM -0300, James Almer wrote:
> On 3/2/2018 5:54 PM, Michael Niedermayer wrote:
> > On Fri, Mar 02, 2018 at 03:36:02PM -0300, James Almer wrote:
> >> On 3/2/2018 3:19 PM, wm4 wrote:
> >>> On Fri, 2 Mar 2018 14:30:28 -0300
> >>> James Almer  wrote:
> >>>
>  On 3/2/2018 1:47 PM, wm4 wrote:
> > On Fri, 2 Mar 2018 13:11:35 -0300
> > James Almer  wrote:
> >
> >> On 3/2/2018 8:16 AM, wm4 wrote:
> >>> This adds a way for an API user to transfer QP data and metadata 
> >>> without
> >>> having to keep the reference to AVFrame, and without having to
> >>> explicitly care about QP APIs. It might also provide a way to finally
> >>> remove the deprecated QP related fields. In the end, the QP table 
> >>> should
> >>> be handled in a very similar way to e.g. AV_FRAME_DATA_MOTION_VECTORS.
> >>>
> >>> There are two side data types, because I didn't care about having to
> >>> repack the QP data so the table and the metadata are in a single
> >>> AVBufferRef. Otherwise it would have either required a copy on 
> >>> decoding
> >>> (extra slowdown for something as obscure as the QP data), or would 
> >>> have
> >>> required making intrusive changes to the codecs which support export 
> >>> of
> >>> this data.  
> >>
> >> Why not add an AVBufferRef pointer to the qp_properties struct instead?
> >> You don't need to merge the properties fields into the buffer data.
> >
> > Not sure what you mean. The whole purpose of this is _not_ to add new
> > pointers because it'd require an API user to deal with extra fields
> > just for QP. I want to pretend that QP doesn't exist.
> 
>  I mean keep the buffer and the int fields all in a single opaque (for
>  the user) struct handled by a single side data type. The user still only
>  needs to worry about using the get/set functions and nothing else.
> 
>  See the attached, untested PoC to get an idea of what i mean.
> 
>  If I'm really missing the entire point of this patch (Which i don't
>  discard may be the case), then ignore this.
> >>>
> >>> That would be nice, but unfortunately it's not allowed. An API user can
> >>> treat side data as byte arrays, and e.g. copy & restore it somewhere
> >>> (presumably even if the data is opaque and implementation defined).
> >>>
> >>> So the side data can't contain any pointers. The user could copy
> >>> the byte data, unref the AVBufferRef, and later add it back as side
> >>> data using the copied bytes. Then it'd contain a dangling pointer.
> >>
> >> Afaik, ref counting was added for frame side data because
> >> sizeof(AVFrameSideData) is not part of the ABI, meaning that users are
> >> not supposed to manipulate side data with anything except the provided
> >> API functions (new, remove, get, and now new_from_buf). Or at least that
> >> was agreed in the relevant thread from some time ago.
> >> This is not the case for AVPacketSideData, which is probably why it
> >> never got a ref count upgrade.
> >>
> >>>
> >>> The side data merging (which we even still provide as API) would be an
> >>> application for that - it's for AVPacket, but there's nothing that
> >>> prevents the same assumptions with AVFrames.
> >>>
> >>> Unless we decide that at least AVFrame side data can contain pointers,
> >>> and the user must strictly use the AVBufferRef to manage the life time
> >>> of the data. Maybe I'm just overthinking this.
> >>
> >> As i said, since the user is not expected to manipulate the side data
> >> manually, then i don't see why it can't have pointers of any kind.
> > 
> > The user has to pass the data she gets from the demuxer to the decoder,
> > from the decoder to filters from there to an encoder and then to a muxer.
> > 
> > If byte per byte copying of side data is not possible anymore how would
> > the user do this ?
> 
> AVFrame side data is supposedly ref counted. Shouldn't av_frame_ref()
> and av_frame_copy_props() both create new references of all source side
> data as they do for the actual frame data and countless other
> AVBufferRefs defined in AVFrame, and not do a memcpy of
> AVFrameSideData->data from src to dst frame?
> 
> > Consider the user is most likely not basing her whole app on AVPackets
> > So she has to turn an AVPacket into something that can be passed within
> > the framework and language the application uses. 
> > So some form of generic array <-> side data copy or (de)serialization
> > would likely be needed
> 
> This is not about AVPackets. Those currently can be freely manipulated
> as the user wishes.

AVPacket between the (de)mxuer/(de)coder, AVFrames between the remaining
parts. I worded this inprecisse without realizing


> 
> It was established back when AVFrame refcounting was introduced that
> users are not to manipulate frame side data manually, and must only use
> the provided API.

I dont think treating side data for AVPackets d

Re: [FFmpeg-devel] [PATCH v2] lavu/frame: add QP side data

[James Almer]

On 3/2/2018 6:27 PM, wm4 wrote:
> On Fri, 2 Mar 2018 18:17:30 -0300
> James Almer  wrote:
> 
>> On 3/2/2018 5:54 PM, Michael Niedermayer wrote:
>>> On Fri, Mar 02, 2018 at 03:36:02PM -0300, James Almer wrote:  
 On 3/2/2018 3:19 PM, wm4 wrote:  
> On Fri, 2 Mar 2018 14:30:28 -0300
> James Almer  wrote:
>  
>> On 3/2/2018 1:47 PM, wm4 wrote:  
>>> On Fri, 2 Mar 2018 13:11:35 -0300
>>> James Almer  wrote:
>>>  
 On 3/2/2018 8:16 AM, wm4 wrote:  
> This adds a way for an API user to transfer QP data and metadata 
> without
> having to keep the reference to AVFrame, and without having to
> explicitly care about QP APIs. It might also provide a way to finally
> remove the deprecated QP related fields. In the end, the QP table 
> should
> be handled in a very similar way to e.g. AV_FRAME_DATA_MOTION_VECTORS.
>
> There are two side data types, because I didn't care about having to
> repack the QP data so the table and the metadata are in a single
> AVBufferRef. Otherwise it would have either required a copy on 
> decoding
> (extra slowdown for something as obscure as the QP data), or would 
> have
> required making intrusive changes to the codecs which support export 
> of
> this data.

 Why not add an AVBufferRef pointer to the qp_properties struct instead?
 You don't need to merge the properties fields into the buffer data.  
>>>
>>> Not sure what you mean. The whole purpose of this is _not_ to add new
>>> pointers because it'd require an API user to deal with extra fields
>>> just for QP. I want to pretend that QP doesn't exist.  
>>
>> I mean keep the buffer and the int fields all in a single opaque (for
>> the user) struct handled by a single side data type. The user still only
>> needs to worry about using the get/set functions and nothing else.
>>
>> See the attached, untested PoC to get an idea of what i mean.
>>
>> If I'm really missing the entire point of this patch (Which i don't
>> discard may be the case), then ignore this.  
>
> That would be nice, but unfortunately it's not allowed. An API user can
> treat side data as byte arrays, and e.g. copy & restore it somewhere
> (presumably even if the data is opaque and implementation defined).
>
> So the side data can't contain any pointers. The user could copy
> the byte data, unref the AVBufferRef, and later add it back as side
> data using the copied bytes. Then it'd contain a dangling pointer.  

 Afaik, ref counting was added for frame side data because
 sizeof(AVFrameSideData) is not part of the ABI, meaning that users are
 not supposed to manipulate side data with anything except the provided
 API functions (new, remove, get, and now new_from_buf). Or at least that
 was agreed in the relevant thread from some time ago.
 This is not the case for AVPacketSideData, which is probably why it
 never got a ref count upgrade.
  
>
> The side data merging (which we even still provide as API) would be an
> application for that - it's for AVPacket, but there's nothing that
> prevents the same assumptions with AVFrames.
>
> Unless we decide that at least AVFrame side data can contain pointers,
> and the user must strictly use the AVBufferRef to manage the life time
> of the data. Maybe I'm just overthinking this.  

 As i said, since the user is not expected to manipulate the side data
 manually, then i don't see why it can't have pointers of any kind.  
>>>
>>> The user has to pass the data she gets from the demuxer to the decoder,
>>> from the decoder to filters from there to an encoder and then to a muxer.
>>>
>>> If byte per byte copying of side data is not possible anymore how would
>>> the user do this ?  
>>
>> AVFrame side data is supposedly ref counted. Shouldn't av_frame_ref()
>> and av_frame_copy_props() both create new references of all source side
>> data as they do for the actual frame data and countless other
>> AVBufferRefs defined in AVFrame, and not do a memcpy of
>> AVFrameSideData->data from src to dst frame?
> 
> Whether it's refcounted or not doesn't matter at all.

I guess I'm missing something here, but if everyone else thinks having
pointers in side data is not possible then I'm not going to argue any
further.
With the new av_frame_new_side_data_from_buf() allowing us to create
side data using AVBufferRef with custom free() functions, this seems
like a no brainer now.

There's also the opaque pointer in AVBufferRef to hold custom
data/structs. Would that be good to work around the problems or side
data copying you're worried about?

> 
>>> Consider the user is most likely not basing her whole app on AVPackets
>>> So she has to turn an AVPacket into something that can be pass

Re: [FFmpeg-devel] [PATCH 1/1] libavformat/dashenc: Option to set timeout for socket I/O operation

[Michael Niedermayer]

On Fri, Mar 02, 2018 at 12:27:40PM +0530, rpata...@akamai.com wrote:
> From: Ravindra Patagar 
> 
> Signed-off-by: Ravindra 
> ---
>  doc/muxers.texi   | 2 ++
>  libavformat/dashenc.c | 4 
>  2 files changed, 6 insertions(+)
> 
> diff --git a/doc/muxers.texi b/doc/muxers.texi
> index e41f8c6..c456a42 100644
> --- a/doc/muxers.texi
> +++ b/doc/muxers.texi
> @@ -264,6 +264,8 @@ of the adaptation sets and a,b,c,d and e are the indices 
> of the mapped streams.
>  To map all video (or audio) streams to an AdaptationSet, "v" (or "a") can be 
> used as stream identifier instead of IDs.
>  
>  When no assignment is defined, this defaults to an AdaptationSet for each 
> stream.
> +@item -timeout @var{timeout}
> +Set timeout (in microseconds) for socket I/O operations. Applicable only for 
> HTTP output.
>  @end table
>  
>  @anchor{framecrc}
> diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
> index 83e0cff..3b4346d 100644
> --- a/libavformat/dashenc.c
> +++ b/libavformat/dashenc.c
> @@ -117,6 +117,7 @@ typedef struct DASHContext {
>  AVIOContext *mpd_out;
>  AVIOContext *m3u8_out;
>  int streaming;
> +int timeout;
>  } DASHContext;
>  
>  static struct codec_string {
> @@ -269,6 +270,8 @@ static void set_http_options(AVDictionary **options, 
> DASHContext *c)
>  av_dict_set(options, "user_agent", c->user_agent, 0);
>  if (c->http_persistent)
>  av_dict_set_int(options, "multiple_requests", 1, 0);
> +if (c->timeout >= 0)
> +av_dict_set_int(options, "timeout", c->timeout, 0);
>  }
>  
>  static void get_hls_playlist_name(char *playlist_name, int string_size,
> @@ -1418,6 +1421,7 @@ static const AVOption options[] = {
>  { "http_persistent", "Use persistent HTTP connections", 
> OFFSET(http_persistent), AV_OPT_TYPE_BOOL, {.i64 = 0 }, 0, 1, E },
>  { "hls_playlist", "Generate HLS playlist files(master.m3u8, 
> media_%d.m3u8)", OFFSET(hls_playlist), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, 
> E },
>  { "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 (in microseconds) for socket I/O operations", 
> OFFSET(timeout), AV_OPT_TYPE_INT, { .i64 = -1 }, -1, INT_MAX, .flags = E },
>  { NULL },

newly added time* options should use AV_OPT_TYPE_DURATION for consistency


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

Old school: Use the lowest level language in which you can solve the problem
conveniently.
New school: Use the highest level language in which the latest supercomputer
can solve the problem without the user falling asleep waiting.


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

Re: [FFmpeg-devel] [PATCH v2] lavu/frame: add QP side data

[James Almer]

On 3/2/2018 6:38 PM, Michael Niedermayer wrote:
> On Fri, Mar 02, 2018 at 06:17:30PM -0300, James Almer wrote:
>> On 3/2/2018 5:54 PM, Michael Niedermayer wrote:
>>> On Fri, Mar 02, 2018 at 03:36:02PM -0300, James Almer wrote:
 On 3/2/2018 3:19 PM, wm4 wrote:
> On Fri, 2 Mar 2018 14:30:28 -0300
> James Almer  wrote:
>
>> On 3/2/2018 1:47 PM, wm4 wrote:
>>> On Fri, 2 Mar 2018 13:11:35 -0300
>>> James Almer  wrote:
>>>
 On 3/2/2018 8:16 AM, wm4 wrote:
> This adds a way for an API user to transfer QP data and metadata 
> without
> having to keep the reference to AVFrame, and without having to
> explicitly care about QP APIs. It might also provide a way to finally
> remove the deprecated QP related fields. In the end, the QP table 
> should
> be handled in a very similar way to e.g. AV_FRAME_DATA_MOTION_VECTORS.
>
> There are two side data types, because I didn't care about having to
> repack the QP data so the table and the metadata are in a single
> AVBufferRef. Otherwise it would have either required a copy on 
> decoding
> (extra slowdown for something as obscure as the QP data), or would 
> have
> required making intrusive changes to the codecs which support export 
> of
> this data.  

 Why not add an AVBufferRef pointer to the qp_properties struct instead?
 You don't need to merge the properties fields into the buffer data.
>>>
>>> Not sure what you mean. The whole purpose of this is _not_ to add new
>>> pointers because it'd require an API user to deal with extra fields
>>> just for QP. I want to pretend that QP doesn't exist.
>>
>> I mean keep the buffer and the int fields all in a single opaque (for
>> the user) struct handled by a single side data type. The user still only
>> needs to worry about using the get/set functions and nothing else.
>>
>> See the attached, untested PoC to get an idea of what i mean.
>>
>> If I'm really missing the entire point of this patch (Which i don't
>> discard may be the case), then ignore this.
>
> That would be nice, but unfortunately it's not allowed. An API user can
> treat side data as byte arrays, and e.g. copy & restore it somewhere
> (presumably even if the data is opaque and implementation defined).
>
> So the side data can't contain any pointers. The user could copy
> the byte data, unref the AVBufferRef, and later add it back as side
> data using the copied bytes. Then it'd contain a dangling pointer.

 Afaik, ref counting was added for frame side data because
 sizeof(AVFrameSideData) is not part of the ABI, meaning that users are
 not supposed to manipulate side data with anything except the provided
 API functions (new, remove, get, and now new_from_buf). Or at least that
 was agreed in the relevant thread from some time ago.
 This is not the case for AVPacketSideData, which is probably why it
 never got a ref count upgrade.

>
> The side data merging (which we even still provide as API) would be an
> application for that - it's for AVPacket, but there's nothing that
> prevents the same assumptions with AVFrames.
>
> Unless we decide that at least AVFrame side data can contain pointers,
> and the user must strictly use the AVBufferRef to manage the life time
> of the data. Maybe I'm just overthinking this.

 As i said, since the user is not expected to manipulate the side data
 manually, then i don't see why it can't have pointers of any kind.
>>>
>>> The user has to pass the data she gets from the demuxer to the decoder,
>>> from the decoder to filters from there to an encoder and then to a muxer.
>>>
>>> If byte per byte copying of side data is not possible anymore how would
>>> the user do this ?
>>
>> AVFrame side data is supposedly ref counted. Shouldn't av_frame_ref()
>> and av_frame_copy_props() both create new references of all source side
>> data as they do for the actual frame data and countless other
>> AVBufferRefs defined in AVFrame, and not do a memcpy of
>> AVFrameSideData->data from src to dst frame?
>>
>>> Consider the user is most likely not basing her whole app on AVPackets
>>> So she has to turn an AVPacket into something that can be passed within
>>> the framework and language the application uses. 
>>> So some form of generic array <-> side data copy or (de)serialization
>>> would likely be needed
>>
>> This is not about AVPackets. Those currently can be freely manipulated
>> as the user wishes.
> 
> AVPacket between the (de)mxuer/(de)coder, AVFrames between the remaining
> parts. I worded this inprecisse without realizing
> 
> 
>>
>> It was established back when AVFrame refcounting was introduced that
>> users are not to manipulate frame side data manually, and must only use

Re: [FFmpeg-devel] [PATCH] parseutils: add support for ms and us suffix for AV_OPT_TYPE_DURATION

[Aurelien Jacobs]

On Fri, Mar 02, 2018 at 09:39:48PM +0100, Michael Niedermayer wrote:
> On Thu, Mar 01, 2018 at 09:41:20PM +0100, Aurelien Jacobs wrote:
> > supported suffixes are:
> > - s: seconds (default when no suffix specified)
> > - m or ms: milliseconds
> > - u or us: microseconds
> > ---
> >  libavutil/parseutils.c | 15 +--
> >  1 file changed, 13 insertions(+), 2 deletions(-)
> 
> can some of this and the si_prefixes related code in eval.c be
> factored ?

I've had a look at this, but this would increase code complexity
in both eval.c and parseutils.c with no advantage, so I deceided not to.
Anyway, 'u' and 'm' SI prefix are the only ones that make any sense for
AV_OPT_TYPE_DURATION and supporting more prefix than those "thanks" to
common code, might add confusion for end user.

BTW, while looking at si_prefixes, I noticed that both 'k' and 'K' are
supported for meaning "kilo", which is wrong in the SI. Only 'k' is
a prefix for "kilo", 'K' is a unit for "Kelvin".
Not sure if there is actually a good reason for having 'K', if it is
needed for backward compatibility, or if it should be removed...

> either way this LGTM

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

Re: [FFmpeg-devel] [PATCH] parseutils: add support for ms and us suffix for AV_OPT_TYPE_DURATION

[Rostislav Pehlivanov]

On 2 March 2018 at 21:57, Aurelien Jacobs  wrote:

> On Fri, Mar 02, 2018 at 09:39:48PM +0100, Michael Niedermayer wrote:
> > On Thu, Mar 01, 2018 at 09:41:20PM +0100, Aurelien Jacobs wrote:
> > > supported suffixes are:
> > > - s: seconds (default when no suffix specified)
> > > - m or ms: milliseconds
> > > - u or us: microseconds
> > > ---
> > >  libavutil/parseutils.c | 15 +--
> > >  1 file changed, 13 insertions(+), 2 deletions(-)
> >
> > can some of this and the si_prefixes related code in eval.c be
> > factored ?
>
> I've had a look at this, but this would increase code complexity
> in both eval.c and parseutils.c with no advantage, so I deceided not to.
> Anyway, 'u' and 'm' SI prefix are the only ones that make any sense for
> AV_OPT_TYPE_DURATION and supporting more prefix than those "thanks" to
> common code, might add confusion for end user.
>
> BTW, while looking at si_prefixes, I noticed that both 'k' and 'K' are
> supported for meaning "kilo", which is wrong in the SI. Only 'k' is
> a prefix for "kilo", 'K' is a unit for "Kelvin".
> Not sure if there is actually a good reason for having 'K', if it is
> needed for backward compatibility, or if it should be removed...
>
> > either way this LGTM
>
> Great. Applied.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

I think that was a bit premature, I really think "m" should be for minutes
while "ms" should be for milliseconds.
Could you post a patch which does that?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2 1/2] fftools/ffmpeg: fix progress log message in case pts is not available

[Michael Niedermayer]

On Fri, Mar 02, 2018 at 09:07:06AM +0100, Tobias Rapp wrote:
> On 01.03.2018 22:08, Michael Niedermayer wrote:
> >On Wed, Feb 28, 2018 at 09:47:15AM +0100, Tobias Rapp wrote:
> >>On 27.02.2018 19:03, Michael Niedermayer wrote:
> >>>On Tue, Feb 27, 2018 at 08:49:19AM +0100, Tobias Rapp wrote:
> On 27.02.2018 01:12, Michael Niedermayer wrote:
> >On Mon, Feb 26, 2018 at 05:09:04PM +0100, Tobias Rapp wrote:
> >>Move time string formatting into inline function. Also fixes out_time
> >>sign prefix for progress report.
> >>
> >>Signed-off-by: Tobias Rapp 
> >>---
> >>  fftools/ffmpeg.c | 48 +++-
> >>  1 file changed, 31 insertions(+), 17 deletions(-)
> >>
> >[...]
> >>+{
> >>+const char *hours_sign;
> >>+int hours, mins;
> >>+double secs;
> >>+
> >>+if (pts == AV_NOPTS_VALUE) {
> >>+snprintf(buf, AV_TS_MAX_STRING_SIZE, "N/A");
> >>+} else {
> >>+hours_sign = (pts < 0) ? "-" : "";
> >>+secs = (double)FFABS(pts) / AV_TIME_BASE;
> >>+mins = (int)secs / 60;
> >>+secs = secs - mins * 60;
> >>+hours = mins / 60;
> >>+mins %= 60;
> >
> >This is not the same code, also with double it can produce inexact
> >results and results differing between platforms
> 
> I changed secs to double to handle the cases with different number of
> sub-second digits more easily. Would it be OK to output two digits after 
> the
> decimal point in both cases? The progress report contains the precise
> out_time_ms value anyway.
> >>>
> >>>iam not sure iam guessing correctly what you mean by "both cases"
> >>>you mean if its unneeded as in .00 ?
> >>>I guess that would be ok
> >>
> >>There are two places within print_report() that output
> >>hour/minute/seconds-formatted time. One is using HH:MM:SS.ZZ format and the
> >>other one is using HH:MM:SS.ZZ format. Would it be OK to output
> >>HH:MM:SS.ZZ (two digits after the decimal separator) in both places like in
> >>the attached patch version?
> >
> >iam not sure if the reduction of precission is a problem for some use case 
> >or not
> >But such a change doesnt belong in a patch factorizing the code.
> >It should be done seperately, if its changed
> 
> Factorizing the code *and* keeping the exact same behavior in both cases is
> pointless in my eyes as it just increases the amount and complexity of code
> for low benefit.

You could first make the formatting the same and then factorize it.
not saying that should be done, just that this should be the easy was to
factor it out

> 
> So please either consider this v3 patch or the original one posted in
> https://ffmpeg.org/pipermail/ffmpeg-devel/2018-February/225775.html

iam not against this, but it seems others where

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

Opposition brings concord. Out of discord comes the fairest harmony.
-- Heraclitus


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

Re: [FFmpeg-devel] [PATCH v2 1/2] fftools/ffmpeg: fix progress log message in case pts is not available

[wm4]

On Fri, 2 Mar 2018 22:48:07 +0100
Michael Niedermayer  wrote:

> On Fri, Mar 02, 2018 at 09:07:06AM +0100, Tobias Rapp wrote:
> > On 01.03.2018 22:08, Michael Niedermayer wrote:  
> > >On Wed, Feb 28, 2018 at 09:47:15AM +0100, Tobias Rapp wrote:  
> > >>On 27.02.2018 19:03, Michael Niedermayer wrote:  
> > >>>On Tue, Feb 27, 2018 at 08:49:19AM +0100, Tobias Rapp wrote:  
> > On 27.02.2018 01:12, Michael Niedermayer wrote:  
> > >On Mon, Feb 26, 2018 at 05:09:04PM +0100, Tobias Rapp wrote:  
> > >>Move time string formatting into inline function. Also fixes out_time
> > >>sign prefix for progress report.
> > >>
> > >>Signed-off-by: Tobias Rapp 
> > >>---
> > >>  fftools/ffmpeg.c | 48 
> > >> +++-
> > >>  1 file changed, 31 insertions(+), 17 deletions(-)
> > >>  
> > >[...]  
> > >>+{
> > >>+const char *hours_sign;
> > >>+int hours, mins;
> > >>+double secs;
> > >>+
> > >>+if (pts == AV_NOPTS_VALUE) {
> > >>+snprintf(buf, AV_TS_MAX_STRING_SIZE, "N/A");
> > >>+} else {
> > >>+hours_sign = (pts < 0) ? "-" : "";
> > >>+secs = (double)FFABS(pts) / AV_TIME_BASE;
> > >>+mins = (int)secs / 60;
> > >>+secs = secs - mins * 60;
> > >>+hours = mins / 60;
> > >>+mins %= 60;  
> > >
> > >This is not the same code, also with double it can produce inexact
> > >results and results differing between platforms  
> > 
> > I changed secs to double to handle the cases with different number of
> > sub-second digits more easily. Would it be OK to output two digits 
> > after the
> > decimal point in both cases? The progress report contains the precise
> > out_time_ms value anyway.  
> > >>>
> > >>>iam not sure iam guessing correctly what you mean by "both cases"
> > >>>you mean if its unneeded as in .00 ?
> > >>>I guess that would be ok  
> > >>
> > >>There are two places within print_report() that output
> > >>hour/minute/seconds-formatted time. One is using HH:MM:SS.ZZ format and 
> > >>the
> > >>other one is using HH:MM:SS.ZZ format. Would it be OK to output
> > >>HH:MM:SS.ZZ (two digits after the decimal separator) in both places like 
> > >>in
> > >>the attached patch version?  
> > >
> > >iam not sure if the reduction of precission is a problem for some use case 
> > >or not
> > >But such a change doesnt belong in a patch factorizing the code.
> > >It should be done seperately, if its changed  
> > 
> > Factorizing the code *and* keeping the exact same behavior in both cases is
> > pointless in my eyes as it just increases the amount and complexity of code
> > for low benefit.  
> 
> You could first make the formatting the same and then factorize it.
> not saying that should be done, just that this should be the easy was to
> factor it out
> 
> > 
> > So please either consider this v3 patch or the original one posted in
> > https://ffmpeg.org/pipermail/ffmpeg-devel/2018-February/225775.html  
> 
> iam not against this, but it seems others where

My comments were meant as minor suggestion for improvement (as I
stated, unfortunately only in my second reply), not a demand to rewrite
everything. If he just wants to push that first patch, fine with me.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] parseutils: add support for ms and us suffix for AV_OPT_TYPE_DURATION

[Aurelien Jacobs]

On Fri, Mar 02, 2018 at 10:02:58PM +, Rostislav Pehlivanov wrote:
> On 2 March 2018 at 21:57, Aurelien Jacobs  wrote:
> 
> > On Fri, Mar 02, 2018 at 09:39:48PM +0100, Michael Niedermayer wrote:
> > > On Thu, Mar 01, 2018 at 09:41:20PM +0100, Aurelien Jacobs wrote:
> > > > supported suffixes are:
> > > > - s: seconds (default when no suffix specified)
> > > > - m or ms: milliseconds
> > > > - u or us: microseconds
> > > > ---
> > > >  libavutil/parseutils.c | 15 +--
> > > >  1 file changed, 13 insertions(+), 2 deletions(-)
> > >
> > > can some of this and the si_prefixes related code in eval.c be
> > > factored ?
> >
> > I've had a look at this, but this would increase code complexity
> > in both eval.c and parseutils.c with no advantage, so I deceided not to.
> > Anyway, 'u' and 'm' SI prefix are the only ones that make any sense for
> > AV_OPT_TYPE_DURATION and supporting more prefix than those "thanks" to
> > common code, might add confusion for end user.
> >
> > BTW, while looking at si_prefixes, I noticed that both 'k' and 'K' are
> > supported for meaning "kilo", which is wrong in the SI. Only 'k' is
> > a prefix for "kilo", 'K' is a unit for "Kelvin".
> > Not sure if there is actually a good reason for having 'K', if it is
> > needed for backward compatibility, or if it should be removed...
> >
> > > either way this LGTM
> >
> > Great. Applied.
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> 
> I think that was a bit premature, I really think "m" should be for minutes
> while "ms" should be for milliseconds.

What you (or I) think is not relevant here. We are simply implementing
an internationnal standard that define precisely what those letters mean
so that people all around the world can communicate without ambiguity.

Minute is not an SI unit but still accepted for use along with SI units,
and the standard symbol for minutes is 'min'.
'm' is the prefix for milli and nothing else.

This is detailed here:
https://www.bipm.org/en/publications/si-brochure/table6.html

If you think having support for minute is really useful, I can have a
look at supporting 'min'.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] parseutils: add support for ms and us suffix for AV_OPT_TYPE_DURATION

[Hendrik Leppkes]

On Fri, Mar 2, 2018 at 11:19 PM, Aurelien Jacobs  wrote:
> On Fri, Mar 02, 2018 at 10:02:58PM +, Rostislav Pehlivanov wrote:
>> On 2 March 2018 at 21:57, Aurelien Jacobs  wrote:
>>
>> > On Fri, Mar 02, 2018 at 09:39:48PM +0100, Michael Niedermayer wrote:
>> > > On Thu, Mar 01, 2018 at 09:41:20PM +0100, Aurelien Jacobs wrote:
>> > > > supported suffixes are:
>> > > > - s: seconds (default when no suffix specified)
>> > > > - m or ms: milliseconds
>> > > > - u or us: microseconds
>> > > > ---
>> > > >  libavutil/parseutils.c | 15 +--
>> > > >  1 file changed, 13 insertions(+), 2 deletions(-)
>> > >
>> > > can some of this and the si_prefixes related code in eval.c be
>> > > factored ?
>> >
>> > I've had a look at this, but this would increase code complexity
>> > in both eval.c and parseutils.c with no advantage, so I deceided not to.
>> > Anyway, 'u' and 'm' SI prefix are the only ones that make any sense for
>> > AV_OPT_TYPE_DURATION and supporting more prefix than those "thanks" to
>> > common code, might add confusion for end user.
>> >
>> > BTW, while looking at si_prefixes, I noticed that both 'k' and 'K' are
>> > supported for meaning "kilo", which is wrong in the SI. Only 'k' is
>> > a prefix for "kilo", 'K' is a unit for "Kelvin".
>> > Not sure if there is actually a good reason for having 'K', if it is
>> > needed for backward compatibility, or if it should be removed...
>> >
>> > > either way this LGTM
>> >
>> > Great. Applied.
>> > ___
>> > ffmpeg-devel mailing list
>> > ffmpeg-devel@ffmpeg.org
>> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>> >
>>
>> I think that was a bit premature, I really think "m" should be for minutes
>> while "ms" should be for milliseconds.
>
> What you (or I) think is not relevant here. We are simply implementing
> an internationnal standard that define precisely what those letters mean
> so that people all around the world can communicate without ambiguity.
>

Why is it not relevant what we think? Who said this has to follow
strict SI rules?

It should use postfixes which are the most logical and intuitive, and
when someone reads "5m" he is the most likely to assume minutes, not
milliseconds.

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

Re: [FFmpeg-devel] [PATCH v2] lavu/frame: add QP side data

[wm4]

On Fri, 2 Mar 2018 18:39:27 -0300
James Almer  wrote:

> On 3/2/2018 6:27 PM, wm4 wrote:
> > On Fri, 2 Mar 2018 18:17:30 -0300
> > James Almer  wrote:
> >   
> >> On 3/2/2018 5:54 PM, Michael Niedermayer wrote:  
> >>> On Fri, Mar 02, 2018 at 03:36:02PM -0300, James Almer wrote:
>  On 3/2/2018 3:19 PM, wm4 wrote:
> > On Fri, 2 Mar 2018 14:30:28 -0300
> > James Almer  wrote:
> >
> >> On 3/2/2018 1:47 PM, wm4 wrote:
> >>> On Fri, 2 Mar 2018 13:11:35 -0300
> >>> James Almer  wrote:
> >>>
>  On 3/2/2018 8:16 AM, wm4 wrote:
> > This adds a way for an API user to transfer QP data and metadata 
> > without
> > having to keep the reference to AVFrame, and without having to
> > explicitly care about QP APIs. It might also provide a way to 
> > finally
> > remove the deprecated QP related fields. In the end, the QP table 
> > should
> > be handled in a very similar way to e.g. 
> > AV_FRAME_DATA_MOTION_VECTORS.
> >
> > There are two side data types, because I didn't care about having to
> > repack the QP data so the table and the metadata are in a single
> > AVBufferRef. Otherwise it would have either required a copy on 
> > decoding
> > (extra slowdown for something as obscure as the QP data), or would 
> > have
> > required making intrusive changes to the codecs which support 
> > export of
> > this data.  
> 
>  Why not add an AVBufferRef pointer to the qp_properties struct 
>  instead?
>  You don't need to merge the properties fields into the buffer data.  
>    
> >>>
> >>> Not sure what you mean. The whole purpose of this is _not_ to add new
> >>> pointers because it'd require an API user to deal with extra fields
> >>> just for QP. I want to pretend that QP doesn't exist.
> >>
> >> I mean keep the buffer and the int fields all in a single opaque (for
> >> the user) struct handled by a single side data type. The user still 
> >> only
> >> needs to worry about using the get/set functions and nothing else.
> >>
> >> See the attached, untested PoC to get an idea of what i mean.
> >>
> >> If I'm really missing the entire point of this patch (Which i don't
> >> discard may be the case), then ignore this.
> >
> > That would be nice, but unfortunately it's not allowed. An API user can
> > treat side data as byte arrays, and e.g. copy & restore it somewhere
> > (presumably even if the data is opaque and implementation defined).
> >
> > So the side data can't contain any pointers. The user could copy
> > the byte data, unref the AVBufferRef, and later add it back as side
> > data using the copied bytes. Then it'd contain a dangling pointer.
> 
>  Afaik, ref counting was added for frame side data because
>  sizeof(AVFrameSideData) is not part of the ABI, meaning that users are
>  not supposed to manipulate side data with anything except the provided
>  API functions (new, remove, get, and now new_from_buf). Or at least that
>  was agreed in the relevant thread from some time ago.
>  This is not the case for AVPacketSideData, which is probably why it
>  never got a ref count upgrade.
> 
> >
> > The side data merging (which we even still provide as API) would be an
> > application for that - it's for AVPacket, but there's nothing that
> > prevents the same assumptions with AVFrames.
> >
> > Unless we decide that at least AVFrame side data can contain pointers,
> > and the user must strictly use the AVBufferRef to manage the life time
> > of the data. Maybe I'm just overthinking this.
> 
>  As i said, since the user is not expected to manipulate the side data
>  manually, then i don't see why it can't have pointers of any kind.
> >>>
> >>> The user has to pass the data she gets from the demuxer to the decoder,
> >>> from the decoder to filters from there to an encoder and then to a muxer.
> >>>
> >>> If byte per byte copying of side data is not possible anymore how would
> >>> the user do this ?
> >>
> >> AVFrame side data is supposedly ref counted. Shouldn't av_frame_ref()
> >> and av_frame_copy_props() both create new references of all source side
> >> data as they do for the actual frame data and countless other
> >> AVBufferRefs defined in AVFrame, and not do a memcpy of
> >> AVFrameSideData->data from src to dst frame?  
> > 
> > Whether it's refcounted or not doesn't matter at all.  
> 
> I guess I'm missing something here, but if everyone else thinks having
> pointers in side data is not possible then I'm not going to argue any
> further.

I think there's a real issue with API users potentially "transporting"
side data across their own framework's data types, and assum

Re: [FFmpeg-devel] [PATCH] parseutils: add support for ms and us suffix for AV_OPT_TYPE_DURATION

[Marton Balint]

On Fri, 2 Mar 2018, Hendrik Leppkes wrote:


On Fri, Mar 2, 2018 at 11:19 PM, Aurelien Jacobs  wrote:

On Fri, Mar 02, 2018 at 10:02:58PM +, Rostislav Pehlivanov wrote:

On 2 March 2018 at 21:57, Aurelien Jacobs  wrote:

> On Fri, Mar 02, 2018 at 09:39:48PM +0100, Michael Niedermayer wrote:
> > On Thu, Mar 01, 2018 at 09:41:20PM +0100, Aurelien Jacobs wrote:
> > > supported suffixes are:
> > > - s: seconds (default when no suffix specified)
> > > - m or ms: milliseconds
> > > - u or us: microseconds


I don't see much benefit in accepting the SI prefixes without actual unit, 
the purpose of this whoule patch is intuitive and readable command line, 
and an SI prefix alone, without a unit is not intuitive. So I'd drop the 
SI-prefix-only variants.


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

[FFmpeg-devel] [PATCH] swscale: Introduce a helper to identify semi-planar formats

[Philip Langdale]

This cleans up the ever-more-unreadable list of semi-planar
exclusions for selecting the planar copy wrapper.
---
 libswscale/swscale_internal.h | 7 +++
 libswscale/swscale_unscaled.c | 7 +--
 2 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/libswscale/swscale_internal.h b/libswscale/swscale_internal.h
index 0f51df95d7..d3d9da9a34 100644
--- a/libswscale/swscale_internal.h
+++ b/libswscale/swscale_internal.h
@@ -676,6 +676,13 @@ static av_always_inline int isPlanarYUV(enum AVPixelFormat 
pix_fmt)
 return ((desc->flags & AV_PIX_FMT_FLAG_PLANAR) && isYUV(pix_fmt));
 }
 
+static av_always_inline int isSemiPlanarYUV(enum AVPixelFormat pix_fmt)
+{
+const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(pix_fmt);
+av_assert0(desc);
+return (isPlanarYUV(pix_fmt) && desc->comp[1].plane == 
desc->comp[2].plane);
+}
+
 static av_always_inline int isRGB(enum AVPixelFormat pix_fmt)
 {
 const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(pix_fmt);
diff --git a/libswscale/swscale_unscaled.c b/libswscale/swscale_unscaled.c
index 766c9b4872..13f9cd83e3 100644
--- a/libswscale/swscale_unscaled.c
+++ b/libswscale/swscale_unscaled.c
@@ -1930,12 +1930,7 @@ void ff_get_unscaled_swscale(SwsContext *c)
 (isPlanarYUV(srcFormat) && isPlanarYUV(dstFormat) &&
  c->chrDstHSubSample == c->chrSrcHSubSample &&
  c->chrDstVSubSample == c->chrSrcVSubSample &&
- dstFormat != AV_PIX_FMT_NV12 && dstFormat != AV_PIX_FMT_NV21 &&
- dstFormat != AV_PIX_FMT_P010LE && dstFormat != AV_PIX_FMT_P010BE &&
- dstFormat != AV_PIX_FMT_P016LE && dstFormat != AV_PIX_FMT_P016BE &&
- srcFormat != AV_PIX_FMT_NV12 && srcFormat != AV_PIX_FMT_NV21 &&
- srcFormat != AV_PIX_FMT_P010LE && srcFormat != AV_PIX_FMT_P010BE &&
- srcFormat != AV_PIX_FMT_P016LE && srcFormat != AV_PIX_FMT_P016BE))
+ !isSemiPlanarYUV(srcFormat) && !isSemiPlanarYUV(dstFormat)))
 {
 if (isPacked(c->srcFormat))
 c->swscale = packedCopyWrapper;
-- 
2.14.1

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

[FFmpeg-devel] [PATCH] ffmpeg: Initialize a potential gap in ctts_data in mov_build_index

[Matthew Wolenetz]

From c40925a0d3ec1397cd6ed7d29bae573c5bdf1ec2 Mon Sep 17 00:00:00 2001
From: Matt Wolenetz 
Date: Fri, 2 Mar 2018 15:12:41 -0800
Subject: [PATCH] ffmpeg: Initialize a potential gap in ctts_data in
 mov_build_index

mov_read_ctts ignores ctts entries having count <= 0. Generally, the
aggregate of all ctts entries' count fields resulting from mov_read_ctts
can be less than the corresponding sample_count.

mov_build_index attempts to normalize any existing ctts_data counts to
be 1, to make a 1-1 mapping of a ctts_data entry to a sample.

That 1-1 mapping left a tail of uninitialized ctts_data entries when the
aggregate, normalized ctts_count < sample_count.

Even more generally, later usage of ctts_data may depend on the entire
ctts_allocated_size having been initialized.

This change memsets the entire allocation of the normalized ctts_data in
mov_build_index, to prevent use of uninitialized data later.

BUG=816787

Change-Id: I7fd7db255e3aeed076ee32c90cb2df211741c052
Reviewed-on: https://chromium-review.googlesource.com/947110
Reviewed-by: Xiaohan Wang 
---
 libavformat/mov.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index f01116874c..05dfaf340e 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -3745,6 +3745,9 @@ static void mov_build_index(MOVContext *mov, AVStream *st)
 av_free(ctts_data_old);
 return;
 }
+
+memset((uint8_t*)(sc->ctts_data), 0, sc->ctts_allocated_size);
+
 for (i = 0; i < ctts_count_old &&
 sc->ctts_count < sc->sample_count; i++)
 for (j = 0; j < ctts_data_old[i].count &&
-- 
2.16.2.395.g2e18187dfd-goog

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

Re: [FFmpeg-devel] [PATCH 2/3] swscale: Add p016 output support and generalise yuv420p1x to p010

[Michael Niedermayer]

On Thu, Mar 01, 2018 at 08:26:52PM -0800, Philip Langdale wrote:
> To make the best use of existing code, I generalised the wrapper
> that currently does yuv420p10 to p010 to support any mixture of
> input and output sizes between 10 and 16 bits. This had the side
> effect of yielding a working code path for all yuv420p1x formats
> to p01x.
> 
> Signed-off-by: Philip Langdale 
> ---
>  libswscale/output.c   | 31 +++
>  libswscale/swscale_unscaled.c | 35 +--
>  libswscale/utils.c|  4 ++--
>  3 files changed, 58 insertions(+), 12 deletions(-)

this needs updates to fate

should be ok with that and if the output looks correct

thx

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

"You are 36 times more likely to die in a bathtub than at the hands of a
terrorist. Also, you are 2.5 times more likely to become a president and
2 times more likely to become an astronaut, than to die in a terrorist
attack." -- Thoughty2



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

[FFmpeg-devel] [PATCH 1/7] avcodec/mediacodecdec_common: refactor mediacodec_dec_parse_format()

[Matthieu Bouron]

---
 libavcodec/mediacodecdec_common.c | 82 ++-
 1 file changed, 30 insertions(+), 52 deletions(-)

diff --git a/libavcodec/mediacodecdec_common.c 
b/libavcodec/mediacodecdec_common.c
index b44abaef7f..ab26df04bd 100644
--- a/libavcodec/mediacodecdec_common.c
+++ b/libavcodec/mediacodecdec_common.c
@@ -339,11 +339,22 @@ done:
 return ret;
 }
 
+#define AMEDIAFORMAT_GET_INT32(name, key, mandatory) do {  
\
+int32_t value = 0; 
\
+if (ff_AMediaFormat_getInt32(s->format, key, &value)) {
\
+(name) = value;
\
+} else if (mandatory) {
\
+av_log(avctx, AV_LOG_ERROR, "Could not get %s from format %s\n", key, 
format); \
+ret = AVERROR_EXTERNAL;
\
+goto fail; 
\
+}  
\
+} while (0)
\
+
 static int mediacodec_dec_parse_format(AVCodecContext *avctx, 
MediaCodecDecContext *s)
 {
+int ret = 0;
 int width = 0;
 int height = 0;
-int32_t value = 0;
 char *format = NULL;
 
 if (!s->format) {
@@ -356,40 +367,16 @@ static int mediacodec_dec_parse_format(AVCodecContext 
*avctx, MediaCodecDecConte
 return AVERROR_EXTERNAL;
 }
 av_log(avctx, AV_LOG_DEBUG, "Parsing MediaFormat %s\n", format);
-av_freep(&format);
 
 /* Mandatory fields */
-if (!ff_AMediaFormat_getInt32(s->format, "width", &value)) {
-format = ff_AMediaFormat_toString(s->format);
-av_log(avctx, AV_LOG_ERROR, "Could not get %s from format %s\n", 
"width", format);
-av_freep(&format);
-return AVERROR_EXTERNAL;
-}
-s->width = value;
+AMEDIAFORMAT_GET_INT32(s->width,  "width", 1);
+AMEDIAFORMAT_GET_INT32(s->height, "height", 1);
 
-if (!ff_AMediaFormat_getInt32(s->format, "height", &value)) {
-format = ff_AMediaFormat_toString(s->format);
-av_log(avctx, AV_LOG_ERROR, "Could not get %s from format %s\n", 
"height", format);
-av_freep(&format);
-return AVERROR_EXTERNAL;
-}
-s->height = value;
+AMEDIAFORMAT_GET_INT32(s->stride, "stride", 1);
+s->stride = s->stride > 0 ? s->stride : s->width;
 
-if (!ff_AMediaFormat_getInt32(s->format, "stride", &value)) {
-format = ff_AMediaFormat_toString(s->format);
-av_log(avctx, AV_LOG_ERROR, "Could not get %s from format %s\n", 
"stride", format);
-av_freep(&format);
-return AVERROR_EXTERNAL;
-}
-s->stride = value > 0 ? value : s->width;
-
-if (!ff_AMediaFormat_getInt32(s->format, "slice-height", &value)) {
-format = ff_AMediaFormat_toString(s->format);
-av_log(avctx, AV_LOG_ERROR, "Could not get %s from format %s\n", 
"slice-height", format);
-av_freep(&format);
-return AVERROR_EXTERNAL;
-}
-s->slice_height = value > 0 ? value : s->height;
+AMEDIAFORMAT_GET_INT32(s->slice_height, "slice-height", 1);
+s->slice_height = s->slice_height > 0 ? s->slice_height : s->height;
 
 if (strstr(s->codec_name, "OMX.Nvidia.")) {
 s->slice_height = FFALIGN(s->height, 16);
@@ -398,32 +385,19 @@ static int mediacodec_dec_parse_format(AVCodecContext 
*avctx, MediaCodecDecConte
 s->stride = avctx->width;
 }
 
-if (!ff_AMediaFormat_getInt32(s->format, "color-format", &value)) {
-format = ff_AMediaFormat_toString(s->format);
-av_log(avctx, AV_LOG_ERROR, "Could not get %s from format %s\n", 
"color-format", format);
-av_freep(&format);
-return AVERROR_EXTERNAL;
-}
-s->color_format = value;
-
-s->pix_fmt = avctx->pix_fmt = mcdec_map_color_format(avctx, s, value);
+AMEDIAFORMAT_GET_INT32(s->color_format, "color-format", 1);
+s->pix_fmt = avctx->pix_fmt = mcdec_map_color_format(avctx, s, 
s->color_format);
 if (avctx->pix_fmt == AV_PIX_FMT_NONE) {
 av_log(avctx, AV_LOG_ERROR, "Output color format is not supported\n");
-return AVERROR(EINVAL);
+ret = AVERROR(EINVAL);
+goto fail;
 }
 
 /* Optional fields */
-if (ff_AMediaFormat_getInt32(s->format, "crop-top", &value))
-s->crop_top = value;
-
-if (ff_AMediaFormat_getInt32(s->format, "crop-bottom", &value))
-s->crop_bottom = value;
-
-if (ff_AMediaFormat_getInt32(s->format, "crop-left", &value))
-s->crop_left = value;
-
-if (ff_AMediaFormat_getInt32(s->format, "crop-right", &value))
-s->crop_right = value;
+AMEDIAFORMAT_GET_INT32(s->crop_top,"crop-top",0);
+AMEDIAFORMAT_GET_INT32(s->

[FFmpeg-devel] [PATCH 4/7] avcodec/mediacodec_wrapper: load and use MediaFormat.constainsKey()

[Matthieu Bouron]

Avoids triggering an exception in MediaFormat getter functions if the
key does not exists.
---
 libavcodec/mediacodec_wrapper.c | 39 +++
 1 file changed, 39 insertions(+)

diff --git a/libavcodec/mediacodec_wrapper.c b/libavcodec/mediacodec_wrapper.c
index dbc37bf463..9436b3c994 100644
--- a/libavcodec/mediacodec_wrapper.c
+++ b/libavcodec/mediacodec_wrapper.c
@@ -111,6 +111,8 @@ struct JNIAMediaFormatFields {
 
 jmethodID init_id;
 
+jmethodID contains_key_id;
+
 jmethodID get_integer_id;
 jmethodID get_long_id;
 jmethodID get_float_id;
@@ -132,6 +134,8 @@ static const struct FFJniField jni_amediaformat_mapping[] = 
{
 
 { "android/media/MediaFormat", "", "()V", FF_JNI_METHOD, 
offsetof(struct JNIAMediaFormatFields, init_id), 1 },
 
+{ "android/media/MediaFormat", "containsKey", "(Ljava/lang/String;)Z", 
FF_JNI_METHOD,offsetof(struct JNIAMediaFormatFields, contains_key_id), 1 },
+
 { "android/media/MediaFormat", "getInteger", "(Ljava/lang/String;)I", 
FF_JNI_METHOD, offsetof(struct JNIAMediaFormatFields, get_integer_id), 1 },
 { "android/media/MediaFormat", "getLong", "(Ljava/lang/String;)J", 
FF_JNI_METHOD, offsetof(struct JNIAMediaFormatFields, get_long_id), 1 },
 { "android/media/MediaFormat", "getFloat", "(Ljava/lang/String;)F", 
FF_JNI_METHOD, offsetof(struct JNIAMediaFormatFields, get_float_id), 1 },
@@ -738,6 +742,7 @@ int ff_AMediaFormat_getInt32(FFAMediaFormat* format, const 
char *name, int32_t *
 
 JNIEnv *env = NULL;
 jstring key = NULL;
+jboolean contains_key;
 
 av_assert0(format != NULL);
 
@@ -749,6 +754,12 @@ int ff_AMediaFormat_getInt32(FFAMediaFormat* format, const 
char *name, int32_t *
 goto fail;
 }
 
+contains_key = (*env)->CallBooleanMethod(env, format->object, 
format->jfields.contains_key_id, key);
+if (!contains_key || (ret = ff_jni_exception_check(env, 1, format)) < 0) {
+ret = 0;
+goto fail;
+}
+
 *out = (*env)->CallIntMethod(env, format->object, 
format->jfields.get_integer_id, key);
 if ((ret = ff_jni_exception_check(env, 1, format)) < 0) {
 ret = 0;
@@ -770,6 +781,7 @@ int ff_AMediaFormat_getInt64(FFAMediaFormat* format, const 
char *name, int64_t *
 
 JNIEnv *env = NULL;
 jstring key = NULL;
+jboolean contains_key;
 
 av_assert0(format != NULL);
 
@@ -781,6 +793,12 @@ int ff_AMediaFormat_getInt64(FFAMediaFormat* format, const 
char *name, int64_t *
 goto fail;
 }
 
+contains_key = (*env)->CallBooleanMethod(env, format->object, 
format->jfields.contains_key_id, key);
+if (!contains_key || (ret = ff_jni_exception_check(env, 1, format)) < 0) {
+ret = 0;
+goto fail;
+}
+
 *out = (*env)->CallLongMethod(env, format->object, 
format->jfields.get_long_id, key);
 if ((ret = ff_jni_exception_check(env, 1, format)) < 0) {
 ret = 0;
@@ -802,6 +820,7 @@ int ff_AMediaFormat_getFloat(FFAMediaFormat* format, const 
char *name, float *ou
 
 JNIEnv *env = NULL;
 jstring key = NULL;
+jboolean contains_key;
 
 av_assert0(format != NULL);
 
@@ -813,6 +832,12 @@ int ff_AMediaFormat_getFloat(FFAMediaFormat* format, const 
char *name, float *ou
 goto fail;
 }
 
+contains_key = (*env)->CallBooleanMethod(env, format->object, 
format->jfields.contains_key_id, key);
+if (!contains_key || (ret = ff_jni_exception_check(env, 1, format)) < 0) {
+ret = 0;
+goto fail;
+}
+
 *out = (*env)->CallFloatMethod(env, format->object, 
format->jfields.get_float_id, key);
 if ((ret = ff_jni_exception_check(env, 1, format)) < 0) {
 ret = 0;
@@ -834,6 +859,7 @@ int ff_AMediaFormat_getBuffer(FFAMediaFormat* format, const 
char *name, void** d
 
 JNIEnv *env = NULL;
 jstring key = NULL;
+jboolean contains_key;
 jobject result = NULL;
 
 av_assert0(format != NULL);
@@ -846,6 +872,12 @@ int ff_AMediaFormat_getBuffer(FFAMediaFormat* format, 
const char *name, void** d
 goto fail;
 }
 
+contains_key = (*env)->CallBooleanMethod(env, format->object, 
format->jfields.contains_key_id, key);
+if (!contains_key || (ret = ff_jni_exception_check(env, 1, format)) < 0) {
+ret = 0;
+goto fail;
+}
+
 result = (*env)->CallObjectMethod(env, format->object, 
format->jfields.get_bytebuffer_id, key);
 if ((ret = ff_jni_exception_check(env, 1, format)) < 0) {
 ret = 0;
@@ -885,6 +917,7 @@ int ff_AMediaFormat_getString(FFAMediaFormat* format, const 
char *name, const ch
 
 JNIEnv *env = NULL;
 jstring key = NULL;
+jboolean contains_key;
 jstring result = NULL;
 
 av_assert0(format != NULL);
@@ -897,6 +930,12 @@ int ff_AMediaFormat_getString(FFAMediaFormat* format, 
const char *name, const ch
 goto fail;
 }
 
+contains_key = (*env)->CallBooleanMethod(env, format->object, 
format->jfields.contains_key_id, key);
+if (!contains

[FFmpeg-devel] [PATCH 5/7] avcodec/mediacodecdec: add missing "libavutil/internal.h" include

[Matthieu Bouron]

libavutil/internal.h defines NULL_IF_CONFIG_SMALL.
---
 libavcodec/mediacodecdec.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavcodec/mediacodecdec.c b/libavcodec/mediacodecdec.c
index 363e12427e..ad09d16398 100644
--- a/libavcodec/mediacodecdec.c
+++ b/libavcodec/mediacodecdec.c
@@ -28,6 +28,7 @@
 #include "libavutil/opt.h"
 #include "libavutil/intreadwrite.h"
 #include "libavutil/pixfmt.h"
+#include "libavutil/internal.h"
 
 #include "avcodec.h"
 #include "decode.h"
-- 
2.16.2

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

[FFmpeg-devel] [PATCH 2/7] avcodec/mediacodecdec_common: remove spurious space

[Matthieu Bouron]

---
 libavcodec/mediacodecdec_common.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/libavcodec/mediacodecdec_common.c 
b/libavcodec/mediacodecdec_common.c
index ab26df04bd..195cc70ba7 100644
--- a/libavcodec/mediacodecdec_common.c
+++ b/libavcodec/mediacodecdec_common.c
@@ -415,7 +415,6 @@ fail:
 return ret;
 }
 
-
 static int mediacodec_dec_flush_codec(AVCodecContext *avctx, 
MediaCodecDecContext *s)
 {
 FFAMediaCodec *codec = s->codec;
-- 
2.16.2

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

[FFmpeg-devel] [PATCH 3/7] avcodec/mediacodecdec_common: remove unused field from MediaCodecDecContext

[Matthieu Bouron]

---
 libavcodec/mediacodecdec_common.c | 2 +-
 libavcodec/mediacodecdec_common.h | 1 -
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/libavcodec/mediacodecdec_common.c 
b/libavcodec/mediacodecdec_common.c
index 195cc70ba7..929db78361 100644
--- a/libavcodec/mediacodecdec_common.c
+++ b/libavcodec/mediacodecdec_common.c
@@ -386,7 +386,7 @@ static int mediacodec_dec_parse_format(AVCodecContext 
*avctx, MediaCodecDecConte
 }
 
 AMEDIAFORMAT_GET_INT32(s->color_format, "color-format", 1);
-s->pix_fmt = avctx->pix_fmt = mcdec_map_color_format(avctx, s, 
s->color_format);
+avctx->pix_fmt = mcdec_map_color_format(avctx, s, s->color_format);
 if (avctx->pix_fmt == AV_PIX_FMT_NONE) {
 av_log(avctx, AV_LOG_ERROR, "Output color format is not supported\n");
 ret = AVERROR(EINVAL);
diff --git a/libavcodec/mediacodecdec_common.h 
b/libavcodec/mediacodecdec_common.h
index 32d16d3e3a..85df507ffb 100644
--- a/libavcodec/mediacodecdec_common.h
+++ b/libavcodec/mediacodecdec_common.h
@@ -55,7 +55,6 @@ typedef struct MediaCodecDecContext {
 int stride;
 int slice_height;
 int color_format;
-enum AVPixelFormat pix_fmt;
 int crop_top;
 int crop_bottom;
 int crop_left;
-- 
2.16.2

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

[FFmpeg-devel] [PATCH 7/7] avcodec/mediacodecdec: factorize codec declarations

[Matthieu Bouron]

---
 libavcodec/mediacodecdec.c | 116 ++---
 1 file changed, 24 insertions(+), 92 deletions(-)

diff --git a/libavcodec/mediacodecdec.c b/libavcodec/mediacodecdec.c
index 4579da1fa5..5e9714ee6e 100644
--- a/libavcodec/mediacodecdec.c
+++ b/libavcodec/mediacodecdec.c
@@ -485,112 +485,44 @@ static const AVCodecHWConfigInternal 
*mediacodec_hw_configs[] = {
 NULL
 };
 
+#define DECLARE_MEDIACODEC_VDEC(short_name, full_name, codec_id, bsf)  
\
+AVCodec ff_##short_name##_mediacodec_decoder = {   
\
+.name   = #short_name "_mediacodec",   
\
+.long_name  = NULL_IF_CONFIG_SMALL(full_name "Android MediaCodec 
decoder"),\
+.type   = AVMEDIA_TYPE_VIDEO,  
\
+.id = codec_id,
\
+.priv_data_size = sizeof(MediaCodecH264DecContext),
\
+.init   = mediacodec_decode_init,  
\
+.receive_frame  = mediacodec_receive_frame,
\
+.flush  = mediacodec_decode_flush, 
\
+.close  = mediacodec_decode_close, 
\
+.capabilities   = AV_CODEC_CAP_DELAY | AV_CODEC_CAP_AVOID_PROBING | 
AV_CODEC_CAP_HARDWARE, \
+.caps_internal  = FF_CODEC_CAP_SETS_PKT_DTS,   
\
+.bsfs   = bsf, 
\
+.hw_configs = mediacodec_hw_configs,   
\
+.wrapper_name   = "mediacodec",
\
+}; 
\
+
 #if CONFIG_H264_MEDIACODEC_DECODER
-AVCodec ff_h264_mediacodec_decoder = {
-.name   = "h264_mediacodec",
-.long_name  = NULL_IF_CONFIG_SMALL("H.264 Android MediaCodec decoder"),
-.type   = AVMEDIA_TYPE_VIDEO,
-.id = AV_CODEC_ID_H264,
-.priv_data_size = sizeof(MediaCodecH264DecContext),
-.init   = mediacodec_decode_init,
-.receive_frame  = mediacodec_receive_frame,
-.flush  = mediacodec_decode_flush,
-.close  = mediacodec_decode_close,
-.capabilities   = AV_CODEC_CAP_DELAY | AV_CODEC_CAP_AVOID_PROBING | 
AV_CODEC_CAP_HARDWARE,
-.caps_internal  = FF_CODEC_CAP_SETS_PKT_DTS,
-.bsfs   = "h264_mp4toannexb",
-.hw_configs = mediacodec_hw_configs,
-.wrapper_name   = "mediacodec",
-};
+DECLARE_MEDIACODEC_VDEC(h264, "H.264", AV_CODEC_ID_H264, "h264_mp4toannexb")
 #endif
 
 #if CONFIG_HEVC_MEDIACODEC_DECODER
-AVCodec ff_hevc_mediacodec_decoder = {
-.name   = "hevc_mediacodec",
-.long_name  = NULL_IF_CONFIG_SMALL("H.265 Android MediaCodec decoder"),
-.type   = AVMEDIA_TYPE_VIDEO,
-.id = AV_CODEC_ID_HEVC,
-.priv_data_size = sizeof(MediaCodecH264DecContext),
-.init   = mediacodec_decode_init,
-.receive_frame  = mediacodec_receive_frame,
-.flush  = mediacodec_decode_flush,
-.close  = mediacodec_decode_close,
-.capabilities   = AV_CODEC_CAP_DELAY | AV_CODEC_CAP_AVOID_PROBING | 
AV_CODEC_CAP_HARDWARE,
-.caps_internal  = FF_CODEC_CAP_SETS_PKT_DTS,
-.bsfs   = "hevc_mp4toannexb",
-.hw_configs = mediacodec_hw_configs,
-.wrapper_name   = "mediacodec",
-};
+DECLARE_MEDIACODEC_VDEC(hevc, "H.265", AV_CODEC_ID_HEVC, "hevc_mp4toannexb")
 #endif
 
 #if CONFIG_MPEG2_MEDIACODEC_DECODER
-AVCodec ff_mpeg2_mediacodec_decoder = {
-.name   = "mpeg2_mediacodec",
-.long_name  = NULL_IF_CONFIG_SMALL("MPEG-2 Android MediaCodec 
decoder"),
-.type   = AVMEDIA_TYPE_VIDEO,
-.id = AV_CODEC_ID_MPEG2VIDEO,
-.priv_data_size = sizeof(MediaCodecH264DecContext),
-.init   = mediacodec_decode_init,
-.receive_frame  = mediacodec_receive_frame,
-.flush  = mediacodec_decode_flush,
-.close  = mediacodec_decode_close,
-.capabilities   = AV_CODEC_CAP_DELAY | AV_CODEC_CAP_AVOID_PROBING | 
AV_CODEC_CAP_HARDWARE,
-.caps_internal  = FF_CODEC_CAP_SETS_PKT_DTS,
-.hw_configs = mediacodec_hw_configs,
-.wrapper_name   = "mediacodec",
-};
+DECLARE_MEDIACODEC_VDEC(mpeg2, "MPEG-2", AV_CODEC_ID_MPEG2VIDEO, NULL)
 #endif
 
 #if CONFIG_MPEG4_MEDIACODEC_DECODER
-AVCodec ff_mpeg4_mediacodec_decoder = {
-.name   = "mpeg4_mediacodec",
-.long_name  = NULL_IF_CONFIG_SMALL("MPEG-4 Android MediaCodec 
decoder"),
-.type   = AVMEDIA_TYPE_VIDEO,
-

[FFmpeg-devel] [PATCH 6/7] avcodec/mediacodecdec: factorize common extradata functions

[Matthieu Bouron]

---
 libavcodec/mediacodecdec.c | 41 +
 1 file changed, 9 insertions(+), 32 deletions(-)

diff --git a/libavcodec/mediacodecdec.c b/libavcodec/mediacodecdec.c
index ad09d16398..4579da1fa5 100644
--- a/libavcodec/mediacodecdec.c
+++ b/libavcodec/mediacodecdec.c
@@ -264,34 +264,11 @@ done:
 }
 #endif
 
-#if CONFIG_MPEG2_MEDIACODEC_DECODER
-static int mpeg2_set_extradata(AVCodecContext *avctx, FFAMediaFormat *format)
-{
-int ret = 0;
-
-if (avctx->extradata) {
-ff_AMediaFormat_setBuffer(format, "csd-0", avctx->extradata, 
avctx->extradata_size);
-}
-
-return ret;
-}
-#endif
-
-#if CONFIG_MPEG4_MEDIACODEC_DECODER
-static int mpeg4_set_extradata(AVCodecContext *avctx, FFAMediaFormat *format)
-{
-int ret = 0;
-
-if (avctx->extradata) {
-ff_AMediaFormat_setBuffer(format, "csd-0", avctx->extradata, 
avctx->extradata_size);
-}
-
-return ret;
-}
-#endif
-
-#if CONFIG_VP8_MEDIACODEC_DECODER || CONFIG_VP9_MEDIACODEC_DECODER
-static int vpx_set_extradata(AVCodecContext *avctx, FFAMediaFormat *format)
+#if CONFIG_MPEG2_MEDIACODEC_DECODER || \
+CONFIG_MPEG4_MEDIACODEC_DECODER || \
+CONFIG_VP8_MEDIACODEC_DECODER   || \
+CONFIG_VP9_MEDIACODEC_DECODER
+static int common_set_extradata(AVCodecContext *avctx, FFAMediaFormat *format)
 {
 int ret = 0;
 
@@ -342,7 +319,7 @@ static av_cold int mediacodec_decode_init(AVCodecContext 
*avctx)
 case AV_CODEC_ID_MPEG2VIDEO:
 codec_mime = "video/mpeg2";
 
-ret = mpeg2_set_extradata(avctx, format);
+ret = common_set_extradata(avctx, format);
 if (ret < 0)
 goto done;
 break;
@@ -351,7 +328,7 @@ static av_cold int mediacodec_decode_init(AVCodecContext 
*avctx)
 case AV_CODEC_ID_MPEG4:
 codec_mime = "video/mp4v-es",
 
-ret = mpeg4_set_extradata(avctx, format);
+ret = common_set_extradata(avctx, format);
 if (ret < 0)
 goto done;
 break;
@@ -360,7 +337,7 @@ static av_cold int mediacodec_decode_init(AVCodecContext 
*avctx)
 case AV_CODEC_ID_VP8:
 codec_mime = "video/x-vnd.on2.vp8";
 
-ret = vpx_set_extradata(avctx, format);
+ret = common_set_extradata(avctx, format);
 if (ret < 0)
 goto done;
 break;
@@ -369,7 +346,7 @@ static av_cold int mediacodec_decode_init(AVCodecContext 
*avctx)
 case AV_CODEC_ID_VP9:
 codec_mime = "video/x-vnd.on2.vp9";
 
-ret = vpx_set_extradata(avctx, format);
+ret = common_set_extradata(avctx, format);
 if (ret < 0)
 goto done;
 break;
-- 
2.16.2

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

Re: [FFmpeg-devel] [PATCH 7/7] avcodec/mediacodecdec: factorize codec declarations

[Aman Gupta]

On Fri, Mar 2, 2018 at 4:13 PM, Matthieu Bouron 
wrote:

> ---
>  libavcodec/mediacodecdec.c | 116 ++
> ---
>  1 file changed, 24 insertions(+), 92 deletions(-)
>
> diff --git a/libavcodec/mediacodecdec.c b/libavcodec/mediacodecdec.c
> index 4579da1fa5..5e9714ee6e 100644
> --- a/libavcodec/mediacodecdec.c
> +++ b/libavcodec/mediacodecdec.c
> @@ -485,112 +485,44 @@ static const AVCodecHWConfigInternal
> *mediacodec_hw_configs[] = {
>  NULL
>  };
>
> +#define DECLARE_MEDIACODEC_VDEC(short_name, full_name, codec_id, bsf)
>   \
> +AVCodec ff_##short_name##_mediacodec_decoder = {
>\
> +.name   = #short_name "_mediacodec",
>  \
> +.long_name  = NULL_IF_CONFIG_SMALL(full_name "Android MediaCodec
> decoder"),\
> +.type   = AVMEDIA_TYPE_VIDEO,
>   \
> +.id = codec_id,
>   \
> +.priv_data_size = sizeof(MediaCodecH264DecContext),
>   \
> +.init   = mediacodec_decode_init,
>   \
> +.receive_frame  = mediacodec_receive_frame,
>   \
> +.flush  = mediacodec_decode_flush,
>  \
> +.close  = mediacodec_decode_close,
>  \
> +.capabilities   = AV_CODEC_CAP_DELAY | AV_CODEC_CAP_AVOID_PROBING |
> AV_CODEC_CAP_HARDWARE, \
> +.caps_internal  = FF_CODEC_CAP_SETS_PKT_DTS,
>  \
> +.bsfs   = bsf,
>  \
> +.hw_configs = mediacodec_hw_configs,
>  \
> +.wrapper_name   = "mediacodec",
>   \
> +};
>  \
> +
>  #if CONFIG_H264_MEDIACODEC_DECODER
> -AVCodec ff_h264_mediacodec_decoder = {
> -.name   = "h264_mediacodec",
> -.long_name  = NULL_IF_CONFIG_SMALL("H.264 Android MediaCodec
> decoder"),
> -.type   = AVMEDIA_TYPE_VIDEO,
> -.id = AV_CODEC_ID_H264,
> -.priv_data_size = sizeof(MediaCodecH264DecContext),
> -.init   = mediacodec_decode_init,
> -.receive_frame  = mediacodec_receive_frame,
> -.flush  = mediacodec_decode_flush,
> -.close  = mediacodec_decode_close,
> -.capabilities   = AV_CODEC_CAP_DELAY | AV_CODEC_CAP_AVOID_PROBING |
> AV_CODEC_CAP_HARDWARE,
> -.caps_internal  = FF_CODEC_CAP_SETS_PKT_DTS,
> -.bsfs   = "h264_mp4toannexb",
> -.hw_configs = mediacodec_hw_configs,
> -.wrapper_name   = "mediacodec",
> -};
> +DECLARE_MEDIACODEC_VDEC(h264, "H.264", AV_CODEC_ID_H264,
> "h264_mp4toannexb")
>  #endif
>
>  #if CONFIG_HEVC_MEDIACODEC_DECODER
> -AVCodec ff_hevc_mediacodec_decoder = {
> -.name   = "hevc_mediacodec",
> -.long_name  = NULL_IF_CONFIG_SMALL("H.265 Android MediaCodec
> decoder"),
> -.type   = AVMEDIA_TYPE_VIDEO,
> -.id = AV_CODEC_ID_HEVC,
> -.priv_data_size = sizeof(MediaCodecH264DecContext),
> -.init   = mediacodec_decode_init,
> -.receive_frame  = mediacodec_receive_frame,
> -.flush  = mediacodec_decode_flush,
> -.close  = mediacodec_decode_close,
> -.capabilities   = AV_CODEC_CAP_DELAY | AV_CODEC_CAP_AVOID_PROBING |
> AV_CODEC_CAP_HARDWARE,
> -.caps_internal  = FF_CODEC_CAP_SETS_PKT_DTS,
> -.bsfs   = "hevc_mp4toannexb",
> -.hw_configs = mediacodec_hw_configs,
> -.wrapper_name   = "mediacodec",
> -};
> +DECLARE_MEDIACODEC_VDEC(hevc, "H.265", AV_CODEC_ID_HEVC,
> "hevc_mp4toannexb")
>  #endif
>
>  #if CONFIG_MPEG2_MEDIACODEC_DECODER
> -AVCodec ff_mpeg2_mediacodec_decoder = {
> -.name   = "mpeg2_mediacodec",
> -.long_name  = NULL_IF_CONFIG_SMALL("MPEG-2 Android MediaCodec
> decoder"),
> -.type   = AVMEDIA_TYPE_VIDEO,
> -.id = AV_CODEC_ID_MPEG2VIDEO,
> -.priv_data_size = sizeof(MediaCodecH264DecContext),
> -.init   = mediacodec_decode_init,
> -.receive_frame  = mediacodec_receive_frame,
> -.flush  = mediacodec_decode_flush,
> -.close  = mediacodec_decode_close,
> -.capabilities   = AV_CODEC_CAP_DELAY | AV_CODEC_CAP_AVOID_PROBING |
> AV_CODEC_CAP_HARDWARE,
> -.caps_internal  = FF_CODEC_CAP_SETS_PKT_DTS,
> -.hw_configs = mediacodec_hw_configs,
> -.wrapper_name   = "mediacodec",
> -};
> +DECLARE_MEDIACODEC_VDEC(mpeg2, "MPEG-2", AV_CODEC_ID_MPEG2VIDEO, NULL)
>  #endif
>
>  #if CONFIG_MPEG4_MEDIACODEC_DECODER
> -AVCodec ff_mpeg4_mediacodec_decoder = {
> -.name   = "mpeg4_mediacodec",
> -.long_name  = NULL_IF_CONFIG_SMALL("MPEG-4 Android MediaCodec
> decoder"),
> -.type   = AVMEDIA_TYPE_VIDEO,
> -.id = AV_CODEC_ID_MPEG4,
> -.priv_data_size = sizeof(MediaCodecH264DecContext),
> -.init   = mediacodec_decode_init,
> -.receive_frame  = mediacode

[FFmpeg-devel] Win7 64b/mingw32 compilation fix

[Pierre Chatelier]

Hello,

I had an issue to compile ffmpeg under Win7 64 bits/mingw32
Adding an include was the solution.

Here is a patch

Pierre Chatelier
From 91f049a9424f80961a8bc3406dc60bccd1d516b9 Mon Sep 17 00:00:00 2001
From: Pierre Chatelier 
Date: Fri, 2 Mar 2018 11:28:48 +0100
Subject: [PATCH 1/1] fix compilation under Win7 64bits with mingw32 by added
  the EAI_MEMORY macro was mapped to ERROR_NOT_ENOUGH_MEMORY which
 was not defined

---
 libavformat/os_support.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavformat/os_support.c b/libavformat/os_support.c
index 86d0b8f306..f9bd5d9970 100644
--- a/libavformat/os_support.c
+++ b/libavformat/os_support.c
@@ -36,6 +36,7 @@
 #endif /* HAVE_SYS_TIME_H */
 #if HAVE_WINSOCK2_H
 #include 
+#include 
 #elif HAVE_SYS_SELECT_H
 #include 
 #endif /* HAVE_WINSOCK2_H */
-- 
2.16.2

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

Re: [FFmpeg-devel] [PATCH 7/7] avcodec/mediacodecdec: factorize codec declarations

[Aman Gupta]

On Fri, Mar 2, 2018 at 4:24 PM, Aman Gupta  wrote:

>
>
> On Fri, Mar 2, 2018 at 4:13 PM, Matthieu Bouron  > wrote:
>
>> ---
>>  libavcodec/mediacodecdec.c | 116 ++
>> ---
>>  1 file changed, 24 insertions(+), 92 deletions(-)
>>
>> diff --git a/libavcodec/mediacodecdec.c b/libavcodec/mediacodecdec.c
>> index 4579da1fa5..5e9714ee6e 100644
>> --- a/libavcodec/mediacodecdec.c
>> +++ b/libavcodec/mediacodecdec.c
>> @@ -485,112 +485,44 @@ static const AVCodecHWConfigInternal
>> *mediacodec_hw_configs[] = {
>>  NULL
>>  };
>>
>> +#define DECLARE_MEDIACODEC_VDEC(short_name, full_name, codec_id, bsf)
>> \
>> +AVCodec ff_##short_name##_mediacodec_decoder = {
>>\
>> +.name   = #short_name "_mediacodec",
>>\
>> +.long_name  = NULL_IF_CONFIG_SMALL(full_name "Android MediaCodec
>> decoder"),\
>>
>
Need a space in here between full_name and "Android"



> +.type   = AVMEDIA_TYPE_VIDEO,
>>   \
>> +.id = codec_id,
>>   \
>> +.priv_data_size = sizeof(MediaCodecH264DecContext),
>> \
>> +.init   = mediacodec_decode_init,
>>   \
>> +.receive_frame  = mediacodec_receive_frame,
>>   \
>> +.flush  = mediacodec_decode_flush,
>>\
>> +.close  = mediacodec_decode_close,
>>\
>> +.capabilities   = AV_CODEC_CAP_DELAY | AV_CODEC_CAP_AVOID_PROBING |
>> AV_CODEC_CAP_HARDWARE, \
>> +.caps_internal  = FF_CODEC_CAP_SETS_PKT_DTS,
>>\
>> +.bsfs   = bsf,
>>\
>> +.hw_configs = mediacodec_hw_configs,
>>\
>> +.wrapper_name   = "mediacodec",
>>   \
>> +};
>>\
>> +
>>  #if CONFIG_H264_MEDIACODEC_DECODER
>> -AVCodec ff_h264_mediacodec_decoder = {
>> -.name   = "h264_mediacodec",
>> -.long_name  = NULL_IF_CONFIG_SMALL("H.264 Android MediaCodec
>> decoder"),
>> -.type   = AVMEDIA_TYPE_VIDEO,
>> -.id = AV_CODEC_ID_H264,
>> -.priv_data_size = sizeof(MediaCodecH264DecContext),
>> -.init   = mediacodec_decode_init,
>> -.receive_frame  = mediacodec_receive_frame,
>> -.flush  = mediacodec_decode_flush,
>> -.close  = mediacodec_decode_close,
>> -.capabilities   = AV_CODEC_CAP_DELAY | AV_CODEC_CAP_AVOID_PROBING |
>> AV_CODEC_CAP_HARDWARE,
>> -.caps_internal  = FF_CODEC_CAP_SETS_PKT_DTS,
>> -.bsfs   = "h264_mp4toannexb",
>> -.hw_configs = mediacodec_hw_configs,
>> -.wrapper_name   = "mediacodec",
>> -};
>> +DECLARE_MEDIACODEC_VDEC(h264, "H.264", AV_CODEC_ID_H264,
>> "h264_mp4toannexb")
>>  #endif
>>
>>  #if CONFIG_HEVC_MEDIACODEC_DECODER
>> -AVCodec ff_hevc_mediacodec_decoder = {
>> -.name   = "hevc_mediacodec",
>> -.long_name  = NULL_IF_CONFIG_SMALL("H.265 Android MediaCodec
>> decoder"),
>> -.type   = AVMEDIA_TYPE_VIDEO,
>> -.id = AV_CODEC_ID_HEVC,
>> -.priv_data_size = sizeof(MediaCodecH264DecContext),
>> -.init   = mediacodec_decode_init,
>> -.receive_frame  = mediacodec_receive_frame,
>> -.flush  = mediacodec_decode_flush,
>> -.close  = mediacodec_decode_close,
>> -.capabilities   = AV_CODEC_CAP_DELAY | AV_CODEC_CAP_AVOID_PROBING |
>> AV_CODEC_CAP_HARDWARE,
>> -.caps_internal  = FF_CODEC_CAP_SETS_PKT_DTS,
>> -.bsfs   = "hevc_mp4toannexb",
>> -.hw_configs = mediacodec_hw_configs,
>> -.wrapper_name   = "mediacodec",
>> -};
>> +DECLARE_MEDIACODEC_VDEC(hevc, "H.265", AV_CODEC_ID_HEVC,
>> "hevc_mp4toannexb")
>>  #endif
>>
>>  #if CONFIG_MPEG2_MEDIACODEC_DECODER
>> -AVCodec ff_mpeg2_mediacodec_decoder = {
>> -.name   = "mpeg2_mediacodec",
>> -.long_name  = NULL_IF_CONFIG_SMALL("MPEG-2 Android MediaCodec
>> decoder"),
>> -.type   = AVMEDIA_TYPE_VIDEO,
>> -.id = AV_CODEC_ID_MPEG2VIDEO,
>> -.priv_data_size = sizeof(MediaCodecH264DecContext),
>> -.init   = mediacodec_decode_init,
>> -.receive_frame  = mediacodec_receive_frame,
>> -.flush  = mediacodec_decode_flush,
>> -.close  = mediacodec_decode_close,
>> -.capabilities   = AV_CODEC_CAP_DELAY | AV_CODEC_CAP_AVOID_PROBING |
>> AV_CODEC_CAP_HARDWARE,
>> -.caps_internal  = FF_CODEC_CAP_SETS_PKT_DTS,
>> -.hw_configs = mediacodec_hw_configs,
>> -.wrapper_name   = "mediacodec",
>> -};
>> +DECLARE_MEDIACODEC_VDEC(mpeg2, "MPEG-2", AV_CODEC_ID_MPEG2VIDEO, NULL)
>>  #endif
>>
>>  #if CONFIG_MPEG4_MEDIACODEC_DECODER
>> -AVCodec ff_mpeg4_mediacodec_decoder = {
>> -.name   = "mpeg4_mediacodec",
>> -.long_name  = NULL_IF_CONFIG_SMALL("MPEG-4 Andr

Re: [FFmpeg-devel] [PATCH] checkasm/hevc_sao : add hevc_sao for checkasm

[Yingming Fan]

Thank you for your remind and i have already sent another patch fix the issue.

Yingming Fan

> On 3 Mar 2018, at 2:23 AM, Martin Vignali  wrote:
> 
> 2018-03-02 12:48 GMT+01:00 Yingming Fan  >:
> 
>> If you want to test checkasm of hevc_sao, please use `checkasm
>> --test=hevc_sao`, or `checkasm --test=hevc_sao --bench`.
>> 
>> 
>> 
>>> On 2 Mar 2018, at 7:03 PM, Yingming Fan  wrote:
>>> 
>>> ---
>>> tests/checkasm/Makefile   |   2 +-
>>> tests/checkasm/checkasm.c |   1 +
>>> tests/checkasm/checkasm.h |   1 +
>>> tests/checkasm/hevc_sao.c | 158 ++
>> 
>>> 4 files changed, 161 insertions(+), 1 deletion(-)
>>> create mode 100644 tests/checkasm/hevc_sao.c
>>> 
>> 
> 
> You should add the checkasm test to fate
> in file : ./tests/fate/checkasm.mak
> 
> Martin
> ___
> 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

[FFmpeg-devel] [PATCH] checkasm/hevc_sao : add hevc_sao for checkasm

[Yingming Fan]

---
 tests/checkasm/Makefile   |   2 +-
 tests/checkasm/checkasm.c |   1 +
 tests/checkasm/checkasm.h |   1 +
 tests/checkasm/hevc_sao.c | 158 ++
 tests/fate/checkasm.mak   |   1 +
 5 files changed, 162 insertions(+), 1 deletion(-)
 create mode 100644 tests/checkasm/hevc_sao.c

diff --git a/tests/checkasm/Makefile b/tests/checkasm/Makefile
index 77bdcf6e65..0520e264e2 100644
--- a/tests/checkasm/Makefile
+++ b/tests/checkasm/Makefile
@@ -23,7 +23,7 @@ AVCODECOBJS-$(CONFIG_EXR_DECODER)   += exrdsp.o
 AVCODECOBJS-$(CONFIG_HUFFYUV_DECODER)   += huffyuvdsp.o
 AVCODECOBJS-$(CONFIG_JPEG2000_DECODER)  += jpeg2000dsp.o
 AVCODECOBJS-$(CONFIG_PIXBLOCKDSP)   += pixblockdsp.o
-AVCODECOBJS-$(CONFIG_HEVC_DECODER)  += hevc_add_res.o hevc_idct.o
+AVCODECOBJS-$(CONFIG_HEVC_DECODER)  += hevc_add_res.o hevc_idct.o 
hevc_sao.o
 AVCODECOBJS-$(CONFIG_UTVIDEO_DECODER)   += utvideodsp.o
 AVCODECOBJS-$(CONFIG_V210_ENCODER)  += v210enc.o
 AVCODECOBJS-$(CONFIG_VP9_DECODER)   += vp9dsp.o
diff --git a/tests/checkasm/checkasm.c b/tests/checkasm/checkasm.c
index a4b8aff984..fe81d139c6 100644
--- a/tests/checkasm/checkasm.c
+++ b/tests/checkasm/checkasm.c
@@ -116,6 +116,7 @@ static const struct {
 #if CONFIG_HEVC_DECODER
 { "hevc_add_res", checkasm_check_hevc_add_res },
 { "hevc_idct", checkasm_check_hevc_idct },
+{ "hevc_sao", checkasm_check_hevc_sao },
 #endif
 #if CONFIG_HUFFYUV_DECODER
 { "huffyuvdsp", checkasm_check_huffyuvdsp },
diff --git a/tests/checkasm/checkasm.h b/tests/checkasm/checkasm.h
index 3de38e6717..8b9d96bc15 100644
--- a/tests/checkasm/checkasm.h
+++ b/tests/checkasm/checkasm.h
@@ -57,6 +57,7 @@ void checkasm_check_h264pred(void);
 void checkasm_check_h264qpel(void);
 void checkasm_check_hevc_add_res(void);
 void checkasm_check_hevc_idct(void);
+void checkasm_check_hevc_sao(void);
 void checkasm_check_huffyuvdsp(void);
 void checkasm_check_jpeg2000dsp(void);
 void checkasm_check_llviddsp(void);
diff --git a/tests/checkasm/hevc_sao.c b/tests/checkasm/hevc_sao.c
new file mode 100644
index 00..e2a0a54e9b
--- /dev/null
+++ b/tests/checkasm/hevc_sao.c
@@ -0,0 +1,158 @@
+/*
+ * Copyright (c) 2018 Yingming Fan 
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 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 General Public License for more details.
+ *
+ * You should have received a copy of the GNU 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/intreadwrite.h"
+
+#include "libavcodec/avcodec.h"
+
+#include "libavcodec/hevcdsp.h"
+
+#include "checkasm.h"
+
+static const uint32_t pixel_mask[3] = { 0x, 0x01ff01ff, 0x03ff03ff };
+static const uint32_t sao_size[5] = {8, 16, 32, 48, 64};
+
+#define SIZEOF_PIXEL ((bit_depth + 7) / 8)
+#define PIXEL_STRIDE (2*MAX_PB_SIZE + AV_INPUT_BUFFER_PADDING_SIZE) //same 
with sao_edge src_stride
+#define BUF_SIZE (PIXEL_STRIDE * (64+2) * 2) //+2 for top and bottom row, *2 
for high bit depth
+#define OFFSET_THRESH (1 << (bit_depth - 5))
+#define OFFSET_LENGTH 5
+
+#define randomize_buffers(buf0, buf1, size) \
+do {\
+uint32_t mask = pixel_mask[bit_depth - 8];  \
+int i;  \
+if (bit_depth == 8) {   \
+for (i = 0; i < size; i += 4) { \
+uint32_t r = rnd() & mask;  \
+AV_WN32A(buf0 + i, r);  \
+AV_WN32A(buf1 + i, r);  \
+}   \
+} else {\
+for (i = 0; i < size; i += 2) { \
+uint32_t r = rnd() & mask;  \
+AV_WN32A((uint16_t *)buf0 + i, r);  \
+AV_WN32A((uint16_t *)buf1 + i, r);  \
+}   \
+}   \
+} while (0)
+
+#define randomize_buffers2(buf, size)   \
+do {\
+uint32_t max_offset = OFFSET_THRESH;\
+int i;  \
+if (bit_depth == 8) { 

Re: [FFmpeg-devel] [PATCH 2/3] swscale: Add p016 output support and generalise yuv420p1x to p010

[Philip Langdale]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sat, 3 Mar 2018 00:55:25 +0100
Michael Niedermayer  wrote:

> On Thu, Mar 01, 2018 at 08:26:52PM -0800, Philip Langdale wrote:
> > To make the best use of existing code, I generalised the wrapper
> > that currently does yuv420p10 to p010 to support any mixture of
> > input and output sizes between 10 and 16 bits. This had the side
> > effect of yielding a working code path for all yuv420p1x formats
> > to p01x.
> > 
> > Signed-off-by: Philip Langdale 
> > ---
> >  libswscale/output.c   | 31 +++
> >  libswscale/swscale_unscaled.c | 35
> > +-- libswscale/utils.c
> > |  4 ++-- 3 files changed, 58 insertions(+), 12 deletions(-)  
> 
> this needs updates to fate
> 
> should be ok with that and if the output looks correct
> 
> thx
> 
> [...]

Pushed with fate updates.

Thanks!

- --phil
-BEGIN PGP SIGNATURE-

iEYEARECAAYFAlqaKzgACgkQ+NaxlGp1aC4k8gCfVF1hBk02KNJmAyq+K8FMRVWX
3LEAoI4d540lJwsCpaTSwYkKSjiWYc/1
=WHQG
-END PGP SIGNATURE-
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/3] avcodec/nvenc: Declare support for P016

[Philip Langdale]

On Fri, 2 Mar 2018 11:14:21 +0100
Timo Rothenpieler  wrote:

> 
> It's definitely better than the current situation, and I can't think
> of a scenario where it breaks something that's not already broken.
> So LGTM from me.
> 
> The other patches also look sensible to me, but I'm not the one to Ok
> them.
> 

Pushed. Thanks.


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