date:20180301

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

2018-03-01 Thread Steven Liu



> On 2 Mar 2018, at 14:56, rpata...@akamai.com wrote:
> 
> From: Ravindra Patagar 
> 
> Signed-off-by: Ravindra 
> ---
> doc/muxers.texi  | 3 +++
> libavformat/hlsenc.c | 5 -
> 2 files changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/doc/muxers.texi b/doc/muxers.texi
> index c156ec0..e41f8c6 100644
> --- a/doc/muxers.texi
> +++ b/doc/muxers.texi
> @@ -964,6 +964,9 @@ publishing it repeatedly every after 30 segments i.e. 
> every after 60s.
> @item http_persistent
> Use persistent HTTP connections. Applicable only for HTTP output.
> 
> +@item timeout
> +Set timeout (in microseconds) for socket I/O operations. Applicable only for 
> HTTP output.
> +
> @end table
> 
> @anchor{ico}
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> index 08fe0aa..e69985a 100644
> --- a/libavformat/hlsenc.c
> +++ b/libavformat/hlsenc.c
> @@ -224,6 +224,7 @@ typedef struct HLSContext {
> int http_persistent;
> AVIOContext *m3u8_out;
> AVIOContext *sub_m3u8_out;
> +int timeout;
> } HLSContext;
> 
> static int mkdir_p(const char *path) {
> @@ -305,7 +306,8 @@ static void set_http_options(AVFormatContext *s, 
> AVDictionary **options, HLSCont
> 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 write_codec_attr(AVStream *st, VariantStream *vs) {
> @@ -2792,6 +2794,7 @@ static const AVOption options[] = {
> {"master_pl_name", "Create HLS master playlist with this name", 
> OFFSET(master_pl_name), AV_OPT_TYPE_STRING, {.str = NULL},  0, 0,E},
> {"master_pl_publish_rate", "Publish master play list every after this 
> many segment intervals", OFFSET(master_publish_rate), AV_OPT_TYPE_INT, {.i64 
> = 0}, 0, UINT_MAX, E},
> {"http_persistent", "Use persistent HTTP connections", 
> OFFSET(http_persistent), 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 },
> };
> 
> -- 
> 1.9.1
> 

LGTM


Thanks
Steven

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

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

2018-03-01 Thread rpatagar

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 },
 };
 
-- 
1.9.1

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

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

2018-03-01 Thread rpatagar

From: Ravindra Patagar 

Signed-off-by: Ravindra 
---
 doc/muxers.texi  | 3 +++
 libavformat/hlsenc.c | 5 -
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/doc/muxers.texi b/doc/muxers.texi
index c156ec0..e41f8c6 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -964,6 +964,9 @@ publishing it repeatedly every after 30 segments i.e. every 
after 60s.
 @item http_persistent
 Use persistent HTTP connections. Applicable only for HTTP output.
 
+@item timeout
+Set timeout (in microseconds) for socket I/O operations. Applicable only for 
HTTP output.
+
 @end table
 
 @anchor{ico}
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 08fe0aa..e69985a 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -224,6 +224,7 @@ typedef struct HLSContext {
 int http_persistent;
 AVIOContext *m3u8_out;
 AVIOContext *sub_m3u8_out;
+int timeout;
 } HLSContext;
 
 static int mkdir_p(const char *path) {
@@ -305,7 +306,8 @@ static void set_http_options(AVFormatContext *s, 
AVDictionary **options, HLSCont
 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 write_codec_attr(AVStream *st, VariantStream *vs) {
@@ -2792,6 +2794,7 @@ static const AVOption options[] = {
 {"master_pl_name", "Create HLS master playlist with this name", 
OFFSET(master_pl_name), AV_OPT_TYPE_STRING, {.str = NULL},  0, 0,E},
 {"master_pl_publish_rate", "Publish master play list every after this many 
segment intervals", OFFSET(master_publish_rate), AV_OPT_TYPE_INT, {.i64 = 0}, 
0, UINT_MAX, E},
 {"http_persistent", "Use persistent HTTP connections", 
OFFSET(http_persistent), 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 },
 };
 
-- 
1.9.1

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

[FFmpeg-devel] [PATCH v2 1/1] avformat/dashenc: fix for segment open issue when persistent connection is enabled

2018-03-01 Thread vdixit

From: Vishwanath Dixit 

---
 libavformat/dashenc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 83e0cff..489e458 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -1308,7 +1308,7 @@ static int dash_write_packet(AVFormatContext *s, AVPacket 
*pkt)
 flush_init_segment(s, os);
 
 //open the output context when the first frame of a segment is ready
-if (!c->single_file && !os->out) {
+if (!c->single_file && os->packets_written == 1) {
 AVDictionary *opts = NULL;
 const char *proto = avio_find_protocol_name(s->url);
 int use_rename = proto && !strcmp(proto, "file");
-- 
1.9.1

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

[FFmpeg-devel] [PATCH 1/3] avcodec/hevcdec: Declare that nvdec supports 12bit decoding

2018-03-01 Thread Philip Langdale

Signed-off-by: Philip Langdale 
---
 libavcodec/hevcdec.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
index fc4eb781dc..c8877626d2 100644
--- a/libavcodec/hevcdec.c
+++ b/libavcodec/hevcdec.c
@@ -404,6 +404,11 @@ static enum AVPixelFormat get_format(HEVCContext *s, const 
HEVCSPS *sps)
 #if CONFIG_HEVC_VIDEOTOOLBOX_HWACCEL
 *fmt++ = AV_PIX_FMT_VIDEOTOOLBOX;
 #endif
+#if CONFIG_HEVC_NVDEC_HWACCEL
+*fmt++ = AV_PIX_FMT_CUDA;
+#endif
+break;
+case AV_PIX_FMT_YUV420P12:
 #if CONFIG_HEVC_NVDEC_HWACCEL
 *fmt++ = AV_PIX_FMT_CUDA;
 #endif
-- 
2.14.1

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

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

2018-03-01 Thread Philip Langdale

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(-)

diff --git a/libswscale/output.c b/libswscale/output.c
index f30bce8dd3..0af2fffea4 100644
--- a/libswscale/output.c
+++ b/libswscale/output.c
@@ -180,6 +180,34 @@ yuv2planeX_16_c_template(const int16_t *filter, int 
filterSize,
 }
 }
 
+static void yuv2p016cX_c(SwsContext *c, const int16_t *chrFilter, int 
chrFilterSize,
+ const int16_t **chrUSrc, const int16_t **chrVSrc,
+ uint8_t *dest8, int chrDstW)
+{
+uint16_t *dest = (uint16_t*)dest8;
+const int32_t **uSrc = (const int32_t **)chrUSrc;
+const int32_t **vSrc = (const int32_t **)chrVSrc;
+int shift = 15;
+int big_endian = c->dstFormat == AV_PIX_FMT_P016BE;
+int i, j;
+
+for (i = 0; i < chrDstW; i++) {
+int u = 1 << (shift - 1);
+int v = 1 << (shift - 1);
+
+/* See yuv2planeX_16_c_template for details. */
+u -= 0x4000;
+v -= 0x4000;
+for (j = 0; j < chrFilterSize; j++) {
+u += uSrc[j][i] * (unsigned)chrFilter[j];
+v += vSrc[j][i] * (unsigned)chrFilter[j];
+}
+
+output_pixel([2*i]  , u, 0x8000, int);
+output_pixel([2*i+1], v, 0x8000, int);
+}
+}
+
 #undef output_pixel
 
 #define output_pixel(pos, val) \
@@ -2257,6 +2285,9 @@ av_cold void ff_sws_init_output_funcs(SwsContext *c,
 } else if (is16BPS(dstFormat)) {
 *yuv2planeX = isBE(dstFormat) ? yuv2planeX_16BE_c  : yuv2planeX_16LE_c;
 *yuv2plane1 = isBE(dstFormat) ? yuv2plane1_16BE_c  : yuv2plane1_16LE_c;
+if (dstFormat == AV_PIX_FMT_P016LE || dstFormat == AV_PIX_FMT_P016BE) {
+  *yuv2nv12cX = yuv2p016cX_c;
+}
 } else if (isNBPS(dstFormat)) {
 if (desc->comp[0].depth == 9) {
 *yuv2planeX = isBE(dstFormat) ? yuv2planeX_9BE_c  : 
yuv2planeX_9LE_c;
diff --git a/libswscale/swscale_unscaled.c b/libswscale/swscale_unscaled.c
index 5ec2116bcf..766c9b4872 100644
--- a/libswscale/swscale_unscaled.c
+++ b/libswscale/swscale_unscaled.c
@@ -180,16 +180,28 @@ static int nv12ToPlanarWrapper(SwsContext *c, const 
uint8_t *src[],
 return srcSliceH;
 }
 
-static int planarToP010Wrapper(SwsContext *c, const uint8_t *src8[],
+static int planarToP01xWrapper(SwsContext *c, const uint8_t *src8[],
int srcStride[], int srcSliceY,
int srcSliceH, uint8_t *dstParam8[],
int dstStride[])
 {
+const AVPixFmtDescriptor *src_format = av_pix_fmt_desc_get(c->srcFormat);
+const AVPixFmtDescriptor *dst_format = av_pix_fmt_desc_get(c->dstFormat);
 const uint16_t **src = (const uint16_t**)src8;
 uint16_t *dstY = (uint16_t*)(dstParam8[0] + dstStride[0] * srcSliceY);
 uint16_t *dstUV = (uint16_t*)(dstParam8[1] + dstStride[1] * srcSliceY / 2);
 int x, y;
 
+/* Calculate net shift required for values. */
+const int shift[3] = {
+dst_format->comp[0].depth + dst_format->comp[0].shift -
+src_format->comp[0].depth - src_format->comp[0].shift,
+dst_format->comp[1].depth + dst_format->comp[1].shift -
+src_format->comp[1].depth - src_format->comp[1].shift,
+dst_format->comp[2].depth + dst_format->comp[2].shift -
+src_format->comp[2].depth - src_format->comp[2].shift,
+};
+
 av_assert0(!(srcStride[0] % 2 || srcStride[1] % 2 || srcStride[2] % 2 ||
  dstStride[0] % 2 || dstStride[1] % 2));
 
@@ -197,7 +209,7 @@ static int planarToP010Wrapper(SwsContext *c, const uint8_t 
*src8[],
 uint16_t *tdstY = dstY;
 const uint16_t *tsrc0 = src[0];
 for (x = c->srcW; x > 0; x--) {
-*tdstY++ = *tsrc0++ << 6;
+*tdstY++ = *tsrc0++ << shift[0];
 }
 src[0] += srcStride[0] / 2;
 dstY += dstStride[0] / 2;
@@ -207,8 +219,8 @@ static int planarToP010Wrapper(SwsContext *c, const uint8_t 
*src8[],
 const uint16_t *tsrc1 = src[1];
 const uint16_t *tsrc2 = src[2];
 for (x = c->srcW / 2; x > 0; x--) {
-*tdstUV++ = *tsrc1++ << 6;
-*tdstUV++ = *tsrc2++ << 6;
+*tdstUV++ = *tsrc1++ << shift[1];
+*tdstUV++ = *tsrc2++ << shift[2];
 }
 src[1] += srcStride[1] / 2;
 src[2] += srcStride[2] / 2;
@@ -1738,14 +1750,17 @@ void ff_get_unscaled_swscale(SwsContext *c)
 !(flags &

[FFmpeg-devel] [PATCH 0/3] nvdec/nvenc: Better handling for > 10bit content

2018-03-01 Thread Philip Langdale

nvdec: Declare that nvdec can (potentially) handle 12bit hevc

nvenc: Claim support for p016 as an input format. It will be truncated,
but it would be truncated by swscale anyway, as we don't do any dithering
for 10bit outputs. This allows for full transcoding of 12bit content to
10bit output, and avoids the current problem where yuv420p12 input is
preferrentially converted to yuv444p16 before being passed to nvenc.

Philip Langdale (3):
  avcodec/hevcdec: Declare that nvdec supports 12bit decoding
  swscale: Add p016 output support and generalise yuv420p1x to p010
  avcodec/nvenc: Declare support for P016

 libavcodec/hevcdec.c  |  5 +
 libavcodec/nvenc.c|  5 -
 libswscale/output.c   | 31 +++
 libswscale/swscale_unscaled.c | 35 +--
 libswscale/utils.c|  4 ++--
 5 files changed, 67 insertions(+), 13 deletions(-)

-- 
2.14.1

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

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

2018-03-01 Thread Philip Langdale

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;
-- 
2.14.1

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

[FFmpeg-devel] [PATCH] lavc/qsvenc: provide detail error message if parameters invalid

2018-03-01 Thread Zhong Li

Currently always shows "Selected ratecontrol mode is not supported by
the QSV runtime. Choose a different mode", but sometimes it is not
accurate.

Signed-off-by: Zhong Li 
---
 libavcodec/qsvenc.c | 31 +--
 1 file changed, 25 insertions(+), 6 deletions(-)

diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
index 74c273c..9710f5b 100644
--- a/libavcodec/qsvenc.c
+++ b/libavcodec/qsvenc.c
@@ -348,15 +348,34 @@ static int select_rc_mode(AVCodecContext *avctx, 
QSVEncContext *q)
 return 0;
 }
 
-static int rc_supported(QSVEncContext *q)
+static int check_enc_param(AVCodecContext *avctx, QSVEncContext *q)
 {
 mfxVideoParam param_out = { .mfx.CodecId = q->param.mfx.CodecId };
 mfxStatus ret;
 
+#define UNMATCH(x) (param_out.mfx.x != q->param.mfx.x)
+
 ret = MFXVideoENCODE_Query(q->session, >param, _out);
-if (ret < 0 ||
-param_out.mfx.RateControlMethod != q->param.mfx.RateControlMethod)
+
+if (ret < 0) {
+if (UNMATCH(CodecId))
+av_log(avctx, AV_LOG_ERROR, "Current codec type is unsupported\n");
+if (UNMATCH(CodecProfile))
+av_log(avctx, AV_LOG_ERROR, "Current profile is unsupported\n");
+if (UNMATCH(RateControlMethod))
+av_log(avctx, AV_LOG_ERROR, "Selected ratecontrol mode is 
unsupported\n");
+if (UNMATCH(LowPower))
+  av_log(avctx, AV_LOG_ERROR, "Low power mode is unsupported\n");
+if (UNMATCH(FrameInfo.FrameRateExtN) || 
UNMATCH(FrameInfo.FrameRateExtN))
+  av_log(avctx, AV_LOG_ERROR, "Current frame rate is 
unsupported\n");
+if (UNMATCH(FrameInfo.PicStruct))
+  av_log(avctx, AV_LOG_ERROR, "Current picture structure is 
unsupported\n");
+if (UNMATCH(FrameInfo.Width) || UNMATCH(FrameInfo.Height))
+  av_log(avctx, AV_LOG_ERROR, "Current resolution is 
unsupported\n");
+if (UNMATCH(FrameInfo.FourCC))
+  av_log(avctx, AV_LOG_ERROR, "Current pixel format is 
unsupported\n");
 return 0;
+}
 return 1;
 }
 
@@ -634,10 +653,10 @@ FF_ENABLE_DEPRECATION_WARNINGS
 #endif
 }
 
-if (!rc_supported(q)) {
+if (!check_enc_param(avctx,q)) {
 av_log(avctx, AV_LOG_ERROR,
-   "Selected ratecontrol mode is not supported by the QSV "
-   "runtime. Choose a different mode.\n");
+   "some encoding parameters are not supported by the QSV "
+   "runtime. Please double check the input parameters.\n");
 return AVERROR(ENOSYS);
 }
 
-- 
1.8.3.1

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

Re: [FFmpeg-devel] [PATCH v2] avformat/hlsenc: add reference stream index for split segment

2018-03-01 Thread Steven Liu



> On 28 Feb 2018, at 12:50, Jeyapal, Karthick  wrote:
> 
> 
> 
> On 2/28/18 10:18 AM, Steven Liu wrote:
>> fix ticket: #7044
>> Get the first video stream to reference for split segment
>> when there have more than one video stream
>> 
>> Signed-off-by: Steven Liu 
>> ---
>> libavformat/hlsenc.c | 8 +++-
>> 1 file changed, 7 insertions(+), 1 deletion(-)
>> 
>> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
>> index ff064732a1..08fe0aa7a0 100644
>> --- a/libavformat/hlsenc.c
>> +++ b/libavformat/hlsenc.c
>> @@ -129,6 +129,7 @@ typedef struct VariantStream {
>> int nb_entries;
>> int discontinuity_set;
>> int discontinuity;
>> +int reference_stream_index;
>> 
>> HLSSegment *segments;
>> HLSSegment *last_segment;
>> @@ -2141,7 +2142,7 @@ static int hls_write_packet(AVFormatContext *s, 
>> AVPacket *pkt)
>> if (vs->has_video) {
>> can_split = st->codecpar->codec_type == AVMEDIA_TYPE_VIDEO &&
>> ((pkt->flags & AV_PKT_FLAG_KEY) || (hls->flags & 
>> HLS_SPLIT_BY_TIME));
>> -is_ref_pkt = st->codecpar->codec_type == AVMEDIA_TYPE_VIDEO;
>> +is_ref_pkt = (st->codecpar->codec_type == AVMEDIA_TYPE_VIDEO) && 
>> (pkt->stream_index == vs->reference_stream_index);
>> }
>> if (pkt->pts == AV_NOPTS_VALUE)
>> is_ref_pkt = can_split = 0;
>> @@ -2497,6 +2498,11 @@ static int hls_init(AVFormatContext *s)
>> 
>> for (j = 0; j < vs->nb_streams; j++) {
>> vs->has_video += vs->streams[j]->codecpar->codec_type == 
>> AVMEDIA_TYPE_VIDEO;
>> +/* Get one video stream to reference for split segments
>> + * so use the first video stream index. */
>> +if ((vs->has_video == 1) && 
>> (vs->streams[j]->codecpar->codec_type == AVMEDIA_TYPE_VIDEO)) {
>> +vs->reference_stream_index = j;
>> +}
>> vs->has_subtitle += vs->streams[j]->codecpar->codec_type == 
>> AVMEDIA_TYPE_SUBTITLE;
>> }
>> 
> LGTM
Pushed
> 
> Regards,
> Karthick
> 
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Thanks
Steven





___
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

2018-03-01 Thread Jun Zhao



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 this part, in fact, I have a similar patches

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

2018-03-01 Thread Michael Niedermayer

On Thu, Mar 01, 2018 at 04:58:22PM +0100, 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.
> 
> 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  | 55 
> +-
>  libavutil/frame.h  | 17 
>  tests/ref/fate/exif-image-embedded |  6 +
>  tests/ref/fate/exif-image-jpg  | 34 +--
>  4 files changed, 92 insertions(+), 20 deletions(-)
> 
> diff --git a/libavutil/frame.c b/libavutil/frame.c
> index 3ecd739317..a9e76504eb 100644
> --- a/libavutil/frame.c
> +++ b/libavutil/frame.c
> @@ -51,8 +51,16 @@ 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;
> +
>  FF_DISABLE_DEPRECATION_WARNINGS
>  av_buffer_unref(>qp_table_buf);
>  
> @@ -62,20 +70,53 @@ 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);
> +

> +if (!frame_new_side_data(f, AV_FRAME_DATA_QP_TABLE_DATA, 
> av_buffer_ref(buf)))
> +return AVERROR(ENOMEM);
> +

This does not build anymore after 6731f60598963da357ff77dafe9e5e903629bde9


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

"Nothing to hide" only works if the folks in power share the values of
you and everyone you know entirely and always will -- Tom Scott



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

[FFmpeg-devel] [PATCH V2] doc/bitstream_filters: correct dump_extra bsfs docs.

2018-03-01 Thread Jun Zhao


From 0a0a10824511ef9d5b3c49ee652a918603841826 Mon Sep 17 00:00:00 2001
From: Jun Zhao 
Date: Fri, 23 Feb 2018 13:53:05 +0800
Subject: [PATCH V2] doc/bitstream_filters: correct dump_extra bsfs docs.

Update dump_extra bit stream filter docs to follow current
code implement.

Signed-off-by: Jun Zhao 
Reviewed-by: Steven Liu 
---
 doc/bitstream_filters.texi | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/doc/bitstream_filters.texi b/doc/bitstream_filters.texi
index cfd81fa12d..b7ea549322 100644
--- a/doc/bitstream_filters.texi
+++ b/doc/bitstream_filters.texi
@@ -50,21 +50,22 @@ DTS-HD.
 
 Add extradata to the beginning of the filtered packets.
 
+@table @option
+@item freq
 The additional argument specifies which packets should be filtered.
 It accepts the values:
 @table @samp
-@item a
-add extradata to all key packets, but only if @var{local_header} is
-set in the @option{flags2} codec context field
-
 @item k
+@item keyframe
 add extradata to all key packets
 
 @item e
+@item all
 add extradata to all packets
 @end table
+@end table
 
-If not specified it is assumed @samp{k}.
+If not specified it is assumed @samp{e}.
 
 For example the following @command{ffmpeg} command forces a global
 header (thus disabling individual packet headers) in the H.264 packets
-- 
2.14.1

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

Re: [FFmpeg-devel] [PATCH 1/2] doc/bitstream_filters: correct dump_extra bsfs docs.

2018-03-01 Thread Jun Zhao



On 2018/2/28 20:37, Steven Liu wrote:
>
>> On 28 Feb 2018, at 08:26, Jun Zhao  wrote:
>>
>> ping
>>
>> On 2018/2/23 15:12, Jun Zhao wrote:
>>
> Signed-off-by: Jun Zhao 
> ---
>  doc/bitstream_filters.texi | 9 +
>  1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/doc/bitstream_filters.texi b/doc/bitstream_filters.texi
> index 5efb8e0ee8..9c7d86eb39 100644
> --- a/doc/bitstream_filters.texi
> +++ b/doc/bitstream_filters.texi
> @@ -50,19 +50,20 @@ DTS-HD.
>  
>  Add extradata to the beginning of the filtered packets.
>  
> +@table @option
> +@item freq
>  The additional argument specifies which packets should be filtered.
>  It accepts the values:
>  @table @samp
> -@item a
> -add extradata to all key packets, but only if @var{local_header} is
> -set in the @option{flags2} codec context field
> -
>  @item k
> +@item keyframe
>  add extradata to all key packets
>  
>  @item e
> +@item all
>  add extradata to all packets
>  @end table
> +@end table
>  
>  If not specified it is assumed @samp{k}.
>  
Please ignore the patch, I think now the code use default value "e/all",
not "k/keyframe", will submit V2 fix this part, Tks.

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

Re: [FFmpeg-devel] [PATCH 5/9] sbc: implement SBC encoder (low-complexity subband codec)

2018-03-01 Thread Rostislav Pehlivanov

On 1 March 2018 at 20:45, Aurelien Jacobs  wrote

>
> So what I propose is to rename sbc_delay to sbc_latency (for example),
> and to add a opus_latecy using AV_OPT_TYPE_DURATION that will deprecate
> opus_delay. I think that's the best way forward if you care about
> consistency.
>

Yeah, that's great as long as that patch gets accepted.


"unlike everything else" ???
> What is everything else ?
> Do you have codecs example other than Opus that use foat milliseconds ?
>

I didn't mention they had to allow configuring the latency, I was referring
to audio codecs in general. So that leaves, like I said, pretty much all
audio codecs made since ever. Suprisingly including bluetooth ones. Given
how much of a pain they are you'd think they use beardseconds.
___
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

2018-03-01 Thread Mark Thompson

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
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 1/2] avformat/mxfdec: fix opAtom audio demuxing

2018-03-01 Thread Marton Balint

Consider edit rate when determining edit_units_per_packet and also make sure
that checks are done in edit rate time base and not in stream time base.

Fixes some errors reported with the sample in ticket #5863.

Signed-off-by: Marton Balint 
---
 libavformat/mxfdec.c | 15 ++-
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index e0a4b5bd11..d4291f5dc7 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -275,7 +275,7 @@ typedef struct MXFContext {
 int parsing_backward;
 int64_t last_forward_tell;
 int last_forward_partition;
-int current_edit_unit;
+int64_t current_edit_unit;
 int nb_index_tables;
 MXFIndexTable *index_tables;
 int edit_units_per_packet;  ///< how many edit units to read at a time 
(PCM, OPAtom)
@@ -2786,6 +2786,7 @@ static AVStream* mxf_get_opatom_stream(MXFContext *mxf)
 static void mxf_handle_small_eubc(AVFormatContext *s)
 {
 MXFContext *mxf = s->priv_data;
+MXFTrack *track;
 
 /* assuming non-OPAtom == frame wrapped
  * no sane writer would wrap 2 byte PCM packets with 20 byte headers.. */
@@ -2805,7 +2806,8 @@ static void mxf_handle_small_eubc(AVFormatContext *s)
 /* TODO: We could compute this from the ratio between the audio
  *   and video edit rates for 48 kHz NTSC we could use the
  *   1802-1802-1802-1802-1801 pattern. */
-mxf->edit_units_per_packet = 1920;
+track = st->priv_data;
+mxf->edit_units_per_packet = FFMAX(1, track->edit_rate.num / 
track->edit_rate.den / 25);
 }
 
 /**
@@ -3263,7 +3265,7 @@ static int mxf_read_packet_old(AVFormatContext *s, 
AVPacket *pkt)
  * truncate the packet since it's probably very large (>2 GiB 
is common) */
 avpriv_request_sample(s,
   "OPAtom misinterpreted as OP1a? "
-  "KLV for edit unit %i extending into "
+  "KLV for edit unit %"PRId64" extending 
into "
   "next edit unit",
   mxf->current_edit_unit);
 klv.length = next_ofs - avio_tell(s->pb);
@@ -3307,6 +3309,7 @@ static int mxf_read_packet(AVFormatContext *s, AVPacket 
*pkt)
 int64_t ret64, pos, next_pos;
 AVStream *st;
 MXFIndexTable *t;
+MXFTrack *track;
 int edit_units;
 
 if (mxf->op != OPAtom)
@@ -3317,14 +3320,16 @@ static int mxf_read_packet(AVFormatContext *s, AVPacket 
*pkt)
 if (!st)
 return AVERROR_EOF;
 
+track = st->priv_data;
+
 /* OPAtom - clip wrapped demuxing */
 /* NOTE: mxf_read_header() makes sure nb_index_tables > 0 for OPAtom */
 t = >index_tables[0];
 
-if (mxf->current_edit_unit >= st->duration)
+if (mxf->current_edit_unit >= track->original_duration)
 return AVERROR_EOF;
 
-edit_units = FFMIN(mxf->edit_units_per_packet, st->duration - 
mxf->current_edit_unit);
+edit_units = FFMIN(mxf->edit_units_per_packet, track->original_duration - 
mxf->current_edit_unit);
 
 if ((ret = mxf_edit_unit_absolute_offset(mxf, t, mxf->current_edit_unit, 
NULL, , 1)) < 0)
 return ret;
-- 
2.13.6

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

[FFmpeg-devel] [PATCH 2/2] avformat/mxfdec: use binary search in mxf_absolute_bodysid_offset

2018-03-01 Thread Marton Balint

Signed-off-by: Marton Balint 
---
 libavformat/mxfdec.c | 22 ++
 1 file changed, 14 insertions(+), 8 deletions(-)

diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index d4291f5dc7..70091e0dc9 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -1347,24 +1347,30 @@ static int mxf_get_sorted_table_segments(MXFContext 
*mxf, int *nb_sorted_segment
  */
 static int mxf_absolute_bodysid_offset(MXFContext *mxf, int body_sid, int64_t 
offset, int64_t *offset_out)
 {
-int x;
 MXFPartition *last_p = NULL;
+int a, b, m, m0;
 
 if (offset < 0)
 return AVERROR(EINVAL);
 
-for (x = 0; x < mxf->partitions_count; x++) {
-MXFPartition *p = >partitions[x];
+a = -1;
+b = mxf->partitions_count;
 
-if (p->body_sid != body_sid)
-continue;
+while (b - a > 1) {
+m0 = m = (a + b) >> 1;
 
-if (p->body_offset > offset)
-break;
+while (m < b && mxf->partitions[m].body_sid != body_sid)
+m++;
 
-last_p = p;
+if (m < b && mxf->partitions[m].body_offset <= offset)
+a = m;
+else
+b = m0;
 }
 
+if (a >= 0)
+last_p = >partitions[a];
+
 if (last_p && (!last_p->essence_length || last_p->essence_length > (offset 
- last_p->body_offset))) {
 *offset_out = last_p->essence_offset + (offset - last_p->body_offset);
 return 0;
-- 
2.13.6

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

Re: [FFmpeg-devel] [PATCH 02/10] avformat/mxfdec: fix essence_offset calculation

2018-03-01 Thread Marton Balint



On Tue, 27 Feb 2018, Marton Balint wrote:



On Thu, 22 Feb 2018, Paul B Mahol wrote:


On 2/22/18, Tomas Haerdin  wrote:

ons 2018-02-21 klockan 23:06 +0100 skrev Marton Balint:

On Wed, 21 Feb 2018, Tomas Haerdin wrote:

> loer 2018-02-17 klockan 22:45 +0100 skrev Marton Balint:
> > The reference point for a KAG is the first byte of the key of a
> > Partition Pack.
> >
> > Fixes ticket #2817.
> > Fixes ticket #5317.
> >
> > > Signed-off-by: Marton Balint 
> >
> > ---
> >  libavformat/mxfdec.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
> > index fcae863ef4..95767ccba4 100644
> > --- a/libavformat/mxfdec.c
> > +++ b/libavformat/mxfdec.c
> > @@ -2875,8 +2875,8 @@ static int mxf_read_header(AVFormatContext *s)
> >   *   for OPAtom we still need the actual
> > essence_offset though (the KL's length can vary)
> >   */
> >  int64_t op1a_essence_offset =
> > - 

round_to_kag(mxf->current_partition->this_partition

> > +
> > - 

mxf->current_partition->pack_length,   mxf->current_partition->kag_size)

> > +
> > +mxf->current_partition->this_partition +
> > + 
round_to_kag(mxf->current_partition->pack_length, 
mxf->current_partition->kag_size)

> > +
> > 

round_to_kag(mxf->current_partition->header_byte_count,

> > mxf->current_partition->kag_size) +
> > 
round_to_kag(mxf->current_partition->index_byte_count, 
mxf->current_partition->kag_size);

>
> This seems like a rather elemental miscalculation, that I wrote even. I
> took a look at S377m, it had this to say:
>
> > The first gridline in any partition is the first byte of the key of
> > the partition pack that defines that
> > partition.
>
> Each partition starts at ThisPartition (plus run-in) so this patch
> should be correct. What's perhaps more suspect is the calculation
> itself. It should *always* be possible to locate where Op1a essence
> starts, by scanning to the first essence KLV. MXF is flexible enough
> that having some sketchy calculation for where it *might* be is
> probably not correct. One is free to insert any amount of padding

The next patch more or less handles this by checking for a system item
key and explicitly setting the offset if that is found. An essence alone
however might not be the first essence, it is also possible that we
already skipped an unknown essence key, or an unknown system item key, so
I decided to keep the code as is if the first recognized essence is not a
system item.


Sounds reasonable I guess. I'm going to reiterate that I consider
continuing to maintain mxfdec is a mistake. A wrapper around
bmxlib/libMXF would be much easier to maintain


YOu are lazy and evil! People please ignore him!


I plan to apply the series soon, unless there are other comments :)


Applied.

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

Re: [FFmpeg-devel] Fix memset size on ctts_data in mov_read_trun()

2018-03-01 Thread Michael Niedermayer

On Tue, Feb 27, 2018 at 01:11:56PM -0800, Xiaohan Wang (王消寒) wrote:
> Sure. Updated!
> 
> On Tue, Feb 27, 2018 at 2:38 AM, Michael Niedermayer  > wrote:
> 
> > On Mon, Feb 26, 2018 at 10:37:51AM -0800, Xiaohan Wang (王消寒) wrote:
> > > Thanks! Updated the patch. Please take a look again.
> > >
> > > On Sat, Feb 24, 2018 at 7:04 PM, Michael Niedermayer
> >  > > > wrote:
> > >
> > > > On Fri, Feb 23, 2018 at 05:12:05PM -0800, Xiaohan Wang (王消寒) wrote:
> > > > > Michael: Dale and I dig into history a bit more and we don't
> > understand
> > > > why
> > > > > the code is changed to the current state around memset. This new
> > patch
> > > > > reverted the change back to the previous state which we felt is much
> > > > > cleaner. Please see the CL description for details and take a look
> > at the
> > > > > new patch. Thanks!
> > > > >
> > > > > On Wed, Feb 21, 2018 at 1:14 PM, Xiaohan Wang (王消寒) <
> > xhw...@chromium.org
> > > > >
> > > > > wrote:
> > > > >
> > > > > > jstebbins: kindly ping!
> > > > > >
> > > > > > On Fri, Feb 16, 2018 at 2:42 PM, Xiaohan Wang (王消寒) <
> > > > xhw...@chromium.org>
> > > > > > wrote:
> > > > > >
> > > > > >> +jstebbins@ who wrote that code.
> > > > > >>
> > > > > >> On Fri, Feb 16, 2018 at 12:30 PM, Michael Niedermayer <
> > > > > >> mich...@niedermayer.cc> wrote:
> > > > > >>
> > > > > >>> On Thu, Feb 15, 2018 at 12:10:33PM -0800, Xiaohan Wang (王消寒)
> > wrote:
> > > > > >>> >
> > > > > >>>
> > > > > >>> >  mov.c |3 ++-
> > > > > >>> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > > > > >>> > 5597d0b095f8b15eb11503010a51c2bc2c022413
> > > > > >>> 0001-ffmpeg-Fix-memset-size-on-ctts_data-in-mov_read_trun.patch
> > > > > >>> > From 7c1e6b50ebe35b2a38c4f1d0a988e31eccbd0ead Mon Sep 17
> > 00:00:00
> > > > 2001
> > > > > >>> > From: Xiaohan Wang 
> > > > > >>> > Date: Thu, 15 Feb 2018 12:05:53 -0800
> > > > > >>> > Subject: [PATCH] ffmpeg: Fix memset size on ctts_data in
> > > > > >>> mov_read_trun()
> > > > > >>> >
> > > > > >>> > The allocated size of sc->ctts_data is
> > > > > >>> > (st->nb_index_entries + entries) * sizeof(*sc->ctts_data).
> > > > > >>> >
> > > > > >>> > The size to memset at offset sc->ctts_data + sc->ctts_count
> > should
> > > > be
> > > > > >>> > (st->nb_index_entries + entries - sc->ctts_count) *
> > > > > >>> sizeof(*sc->ctts_data))
> > > > > >>> >
> > > > > >>> > The current code missed |entries| I believe.
> > > > > >>>
> > > > > >>> shouldnt "entries" be read by this function later and so shouldnt
> > > > need a
> > > > > >>> memset?
> > > > > >>> I didnt write this, but it looks a bit to me as if it was
> > intended to
> > > > > >>> only
> > > > > >>> clear the area that would not be read later
> > > > > >>>
> > > > > >>
> > > > > >> I thought we only had sc->ctts_count entries before
> > av_fast_realloc,
> > > > so
> > > > > >> memset everything starting from sc->ctts_data + sc->ctts_count
> > > > couldn't
> > > > > >> go wrong. But I am not familiar with this code and that could
> > totally
> > > > be
> > > > > >> wrong. I added jstebbins@ who wrote the code and hopefully we
> > can get
> > > > > >> expert opinion there.
> > > > > >>
> > > > > >>
> > > > > >>> [...]
> > > > > >>> --
> > > > > >>> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC7
> > > > 87040B0FAB
> > > > > >>>
> > > > > >>> No great genius has ever existed without some touch of madness.
> > --
> > > > > >>> Aristotle
> > > > > >>>
> > > > > >>> ___
> > > > > >>> ffmpeg-devel mailing list
> > > > > >>> ffmpeg-devel@ffmpeg.org
> > > > > >>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> > > > > >>>
> > > > > >>>
> > > > > >>
> > > > > >
> > > >
> > > > >  mov.c |5 +++--
> > > > >  1 file changed, 3 insertions(+), 2 deletions(-)
> > > > > e5bbe55f0b1260f787f431b5c45e6ca49a7d2d1e
> > 0001-Fix-memset-size-on-ctts_
> > > > data-in-mov_read_trun-round-.patch
> > > > > From f34b35ec5749c17b21f80665a0b8859bce3e84ab Mon Sep 17 00:00:00
> > 2001
> > > > > From: Xiaohan Wang 
> > > > > Date: Fri, 23 Feb 2018 10:51:30 -0800
> > > > > Subject: [PATCH] Fix memset size on ctts_data in mov_read_trun()
> > (round
> > > > 2)
> > > > >
> > > > > The allocated size of sc->ctts_data is
> > > > > (st->nb_index_entries + entries) * sizeof(*sc->ctts_data).
> > > > >
> > > > > The size to memset at offset sc->ctts_data + sc->ctts_count should be
> > > > > (st->nb_index_entries + entries - sc->ctts_count) *
> > > > > sizeof(*sc->ctts_data))
> > > > >
> > > > > The current code missed |entries| I believe, which was introduced in
> > > > > https://patchwork.ffmpeg.org/patch/5541/.
> > > > >
> > > > > However, after offline discussion, it seems the original code is much
> > > > > more clear to read (before https://patchwork.ffmpeg.org/patch/5541/
> > ).
> > > > >
> > > > > Hence this CL revert the memset logic to it's previous state by
> > > > >

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

2018-03-01 Thread Michael Niedermayer

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

[...]

thx
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

There will always be a question for which you do not know the correct answer.


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

Re: [FFmpeg-devel] In a stream, is there a way to wait some time before playing next packet after the previous one ended?

2018-03-01 Thread kprz


On 18/02/28 11:33 PM, Carl Eugen Hoyos wrote:


If you send this as a patch made with "git format-patch" to this
mailing list, it may be easier to test and answer your questions.


Good to know about that. I'll keep that in mind and use when/if all else fails.


For some use-cases, setting time-stamps will be enough, for
most cases, inserting silence (which should not be hard) will
be necessary.


Thanks for the suggestion and confirming my suspicions regarding options 
available.
So, I will try 'inserting silence' approach.
Ideally, it will result in a working patch candidate.

-kprz

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

Re: [FFmpeg-devel] [PATCH] frame: add an av_frame_new_side_data_from_buf function

2018-03-01 Thread Rostislav Pehlivanov

On 1 March 2018 at 19:19, James Almer  wrote:

> On 3/1/2018 3:58 PM, Rostislav Pehlivanov wrote:
> > Also fixes a theoretical memory leak in av_frame_new_side_data_from_buf
> > where if ret was successfully allocated but the realloc call failed,
> > ret wouldn't be freed.
>
> Currently, if realloc fails, ret is never allocated to begin with.
>
> There's no leak at all in any circumstances right now. That change
> you're trying to make is unnecessary.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

I see what you mean, I don't remember why I moved that back in November.

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

Re: [FFmpeg-devel] [PATCH 5/9] sbc: implement SBC encoder (low-complexity subband codec)

2018-03-01 Thread Aurelien Jacobs

On Thu, Mar 01, 2018 at 01:27:06AM +, Rostislav Pehlivanov wrote:
> On 28 February 2018 at 23:34, Aurelien Jacobs  wrote:
> 
> > On Wed, Feb 28, 2018 at 12:59:40AM +, Rostislav Pehlivanov wrote:
> > > On 27 February 2018 at 23:56, Aurelien Jacobs  wrote:
> > >
> > > >
> > > > So I've updated the patch with only a msbc and a delay option and
> > > > I've added some sane parameters decisions, mainly based on the
> > following
> > > > study :
> > > > https://pdfs.semanticscholar.org/1f19/561d03bc88b67728375566c95bbf77
> > > > e730d5.pdf
> > > > This seems to give pretty good results.
> > > >
> > > >
> > > I think you ought to use a float for this, like:
> > >
> > > >{ "sbc_delay", "Maximum delay in milliseconds", offsetof(,
> > > ), AV_OPT_TYPE_FLOAT, { .dbl =  },
> > ,
> > > , ,  },
> >
> > Why would I want to use float for this ??
> > AV_OPT_TYPE_DURATION is more appropriate for this. It has microsecond
> > precision which is more than enough, and you can still use a "float"
> > string as a parameter (eg. -sbc_delay 0.0035 for a 3.5 ms maximum delay).
> >
> >
> The unit is the issue. AV_OPT_TYPE_DURATION expects a duration in seconds,
> but all codecs (except .ape) have frame sizes expressible in a (near)
> integer amount of milliseconds, this included.

AV_OPT_TYPE_DURATION supports various input format. There is no reason
it can't support milliseconds or microseconds input.
I've just sent a patch to implement exactly this.

> Take a look at both Opus
> encoders, they both use a unit of milliseconds in their avopts to set frame
> durations. Having a codec which uses seconds unlike everything else isn't
> right (and we the same issue just a month ago with a timeout option).
> You don't have to use a float, you can use an int as well as long as frame
> sizes are an integer number of milliseconds.

"unlike everything else" ???
What is everything else ?
Do you have codecs example other than Opus that use foat milliseconds ?

I don't see much in avcodec, but in avformat there are various similar
examples:
- http: reconnect_delay_max (INT in seconds)
- gifdec: min_delay, max_gif_delay... (INT in hundredths of seconds)
- mpegenc: preload (INT in microseconds)

That's what happens when each codec/muxer uses a simple number type
(INT or FLOAT) and picks it's prefered unit. Total inconsistency !

That's what AV_OPT_TYPE_DURATION avoids, by preventing each codec to
pick a unit (it gives microseconds to everyone which should fit pretty
much all situations) and by allowing users to enter parameters in a
convinient way whatever the most appropiate unit is.
Consitency across the codebase using a common parameter parser and
a common internal unit (microsecond).

So what I propose is to rename sbc_delay to sbc_latency (for example),
and to add a opus_latecy using AV_OPT_TYPE_DURATION that will deprecate
opus_delay. I think that's the best way forward if you care about
consistency.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

2018-03-01 Thread Aurelien Jacobs

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(-)

diff --git a/libavutil/parseutils.c b/libavutil/parseutils.c
index 7ca07b37a1..44c845577a 100644
--- a/libavutil/parseutils.c
+++ b/libavutil/parseutils.c
@@ -590,7 +590,7 @@ int av_parse_time(int64_t *timeval, const char *timestr, 
int duration)
 int64_t t, now64;
 time_t now;
 struct tm dt = { 0 }, tmbuf;
-int today = 0, negative = 0, microseconds = 0;
+int today = 0, negative = 0, microseconds = 0, suffix = 100;
 int i;
 static const char * const date_fmt[] = {
 "%Y - %m - %d",
@@ -689,6 +689,17 @@ int av_parse_time(int64_t *timeval, const char *timestr, 
int duration)
 
 if (duration) {
 t = dt.tm_hour * 3600 + dt.tm_min * 60 + dt.tm_sec;
+if (*q == 'm') {
+suffix = 1000;
+microseconds /= 1000;
+q++;
+} else if (*q == 'u') {
+suffix = 1;
+microseconds = 0;
+q++;
+}
+if (*q == 's')
+q++;
 } else {
 int is_utc = *q == 'Z' || *q == 'z';
 int tzoffset = 0;
@@ -724,7 +735,7 @@ int av_parse_time(int64_t *timeval, const char *timestr, 
int duration)
 if (*q)
 return AVERROR(EINVAL);
 
-t *= 100;
+t *= suffix;
 t += microseconds;
 *timeval = negative ? -t : t;
 return 0;
-- 
2.16.2

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

Re: [FFmpeg-devel] [PATCH] frame: add an av_frame_new_side_data_from_buf function

2018-03-01 Thread James Almer

On 3/1/2018 3:58 PM, Rostislav Pehlivanov wrote:
> Also fixes a theoretical memory leak in av_frame_new_side_data_from_buf
> where if ret was successfully allocated but the realloc call failed,
> ret wouldn't be freed.

Currently, if realloc fails, ret is never allocated to begin with.

There's no leak at all in any circumstances right now. That change
you're trying to make is unnecessary.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/wmaprodec: support decoding up to 16 channels of xma

2018-03-01 Thread Paul B Mahol

On 2/27/18, Maxton  wrote:
> On 2018-02-27 4:10, Carl Eugen Hoyos wrote:
>> 2018-02-27 9:26 GMT+01:00 Maxton :
>>> I looked at the code in avcodec/wmaprodec.c and noticed that
>>> the maximum number of channels was set to 8, but I think this
>>> is a mistake as the number of channels should logically be
>>>
>>>XMA_MAX_STREAMS * XMA_MAX_CHANNELS_STREAM
>> Doesn't your explanation indicate you should (move the definition
>> and) change "8" into this calculation?
>
> That is certainly more clear. I've attached an updated patch.
>
> Best
> Maxton
>
>

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

[FFmpeg-devel] [PATCH] frame: add an av_frame_new_side_data_from_buf function

2018-03-01 Thread Rostislav Pehlivanov

Also fixes a theoretical memory leak in av_frame_new_side_data_from_buf
where if ret was successfully allocated but the realloc call failed,
ret wouldn't be freed.

Signed-off-by: Rostislav Pehlivanov 
---
 libavutil/frame.c | 42 +-
 libavutil/frame.h | 16 
 2 files changed, 37 insertions(+), 21 deletions(-)

diff --git a/libavutil/frame.c b/libavutil/frame.c
index 662a7e5ab5..4951e48045 100644
--- a/libavutil/frame.c
+++ b/libavutil/frame.c
@@ -26,11 +26,6 @@
 #include "mem.h"
 #include "samplefmt.h"
 
-
-static AVFrameSideData *frame_new_side_data(AVFrame *frame,
-enum AVFrameSideDataType type,
-AVBufferRef *buf);
-
 #if FF_API_FRAME_GET_SET
 MAKE_ACCESSORS(AVFrame, frame, int64_t, best_effort_timestamp)
 MAKE_ACCESSORS(AVFrame, frame, int64_t, pkt_duration)
@@ -356,8 +351,10 @@ FF_ENABLE_DEPRECATION_WARNINGS
 }
 memcpy(sd_dst->data, sd_src->data, sd_src->size);
 } else {
-sd_dst = frame_new_side_data(dst, sd_src->type, 
av_buffer_ref(sd_src->buf));
+AVBufferRef *ref = av_buffer_ref(sd_src->buf);
+sd_dst = av_frame_new_side_data_from_buf(dst, sd_src->type, ref);
 if (!sd_dst) {
+av_buffer_unref();
 wipe_side_data(dst);
 return AVERROR(ENOMEM);
 }
@@ -642,9 +639,9 @@ AVBufferRef *av_frame_get_plane_buffer(AVFrame *frame, int 
plane)
 return NULL;
 }
 
-static AVFrameSideData *frame_new_side_data(AVFrame *frame,
-enum AVFrameSideDataType type,
-AVBufferRef *buf)
+AVFrameSideData *av_frame_new_side_data_from_buf(AVFrame *frame,
+ enum AVFrameSideDataType type,
+ AVBufferRef *buf)
 {
 AVFrameSideData *ret, **tmp;
 
@@ -652,18 +649,20 @@ static AVFrameSideData *frame_new_side_data(AVFrame 
*frame,
 return NULL;
 
 if (frame->nb_side_data > INT_MAX / sizeof(*frame->side_data) - 1)
-goto fail;
+return NULL;
+
+ret = av_mallocz(sizeof(*ret));
+if (!ret)
+return NULL;
 
 tmp = av_realloc(frame->side_data,
  (frame->nb_side_data + 1) * sizeof(*frame->side_data));
-if (!tmp)
-goto fail;
+if (!tmp) {
+av_free(ret);
+return NULL;
+}
 frame->side_data = tmp;
 
-ret = av_mallocz(sizeof(*ret));
-if (!ret)
-goto fail;
-
 ret->buf = buf;
 ret->data = ret->buf->data;
 ret->size = buf->size;
@@ -672,17 +671,18 @@ static AVFrameSideData *frame_new_side_data(AVFrame 
*frame,
 frame->side_data[frame->nb_side_data++] = ret;
 
 return ret;
-fail:
-av_buffer_unref();
-return NULL;
 }
 
 AVFrameSideData *av_frame_new_side_data(AVFrame *frame,
 enum AVFrameSideDataType type,
 int size)
 {
-
-return frame_new_side_data(frame, type, av_buffer_alloc(size));
+AVFrameSideData *ret;
+AVBufferRef *buf = av_buffer_alloc(size);
+ret = av_frame_new_side_data_from_buf(frame, type, buf);
+if (!ret)
+av_buffer_unref();
+return ret;
 }
 
 AVFrameSideData *av_frame_get_side_data(const AVFrame *frame,
diff --git a/libavutil/frame.h b/libavutil/frame.h
index d54bd9a354..59cee8ceab 100644
--- a/libavutil/frame.h
+++ b/libavutil/frame.h
@@ -800,6 +800,22 @@ AVFrameSideData *av_frame_new_side_data(AVFrame *frame,
 enum AVFrameSideDataType type,
 int size);
 
+/**
+ * Add a new side data to a frame from an existing AVBufferRef
+ *
+ * @param frame a frame to which the side data should be added
+ * @param type  the type of the added side data
+ * @param buf   an AVBufferRef to add as side data. The ownership of
+ *  the reference is transferred to the frame.
+ *
+ * @return newly added side data on success, NULL on error. On failure
+ * the frame is unchanged and the AVBufferRef remains owned by
+ * the caller.
+ */
+AVFrameSideData *av_frame_new_side_data_from_buf(AVFrame *frame,
+ enum AVFrameSideDataType type,
+ AVBufferRef *buf);
+
 /**
  * @return a pointer to the side data of a given type on success, NULL if there
  * is no side data with such type in this frame.
-- 
2.16.2

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

Re: [FFmpeg-devel] [PATCH] frame: add an av_frame_new_side_data_from_buf function

2018-03-01 Thread James Almer

On 3/1/2018 2:09 PM, Rostislav Pehlivanov wrote:
> Signed-off-by: Rostislav Pehlivanov 
> ---
> 
> Yeah, that sounds better, thanks.
> 
>  libavutil/frame.c | 45 +
>  libavutil/frame.h | 16 
>  2 files changed, 41 insertions(+), 20 deletions(-)
> 
> diff --git a/libavutil/frame.c b/libavutil/frame.c
> index 662a7e5ab5..a49c853493 100644
> --- a/libavutil/frame.c
> +++ b/libavutil/frame.c
> @@ -26,11 +26,6 @@
>  #include "mem.h"
>  #include "samplefmt.h"
>  
> -
> -static AVFrameSideData *frame_new_side_data(AVFrame *frame,
> -enum AVFrameSideDataType type,
> -AVBufferRef *buf);
> -
>  #if FF_API_FRAME_GET_SET
>  MAKE_ACCESSORS(AVFrame, frame, int64_t, best_effort_timestamp)
>  MAKE_ACCESSORS(AVFrame, frame, int64_t, pkt_duration)
> @@ -356,8 +351,10 @@ FF_ENABLE_DEPRECATION_WARNINGS
>  }
>  memcpy(sd_dst->data, sd_src->data, sd_src->size);
>  } else {
> -sd_dst = frame_new_side_data(dst, sd_src->type, 
> av_buffer_ref(sd_src->buf));
> +AVBufferRef *ref = av_buffer_ref(sd_src->buf);
> +sd_dst = av_frame_new_side_data_from_buf(dst, sd_src->type, ref);
>  if (!sd_dst) {
> +av_buffer_unref();
>  wipe_side_data(dst);
>  return AVERROR(ENOMEM);
>  }
> @@ -642,9 +639,9 @@ AVBufferRef *av_frame_get_plane_buffer(AVFrame *frame, 
> int plane)
>  return NULL;
>  }
>  
> -static AVFrameSideData *frame_new_side_data(AVFrame *frame,
> -enum AVFrameSideDataType type,
> -AVBufferRef *buf)
> +AVFrameSideData *av_frame_new_side_data_from_buf(AVFrame *frame,
> + enum AVFrameSideDataType 
> type,
> + AVBufferRef *buf)
>  {
>  AVFrameSideData *ret, **tmp;
>  
> @@ -652,18 +649,20 @@ static AVFrameSideData *frame_new_side_data(AVFrame 
> *frame,
>  return NULL;
>  
>  if (frame->nb_side_data > INT_MAX / sizeof(*frame->side_data) - 1)
> -goto fail;
> +return NULL;
> +
> +ret = av_mallocz(sizeof(*ret));
> +if (!ret)
> +return NULL;
>  
>  tmp = av_realloc(frame->side_data,
>   (frame->nb_side_data + 1) * sizeof(*frame->side_data));
> -if (!tmp)
> -goto fail;
> +if (!tmp) {
> +av_free(tmp);

tmp?

And I still think this change is unrelated and needs to be in a separate
patch.

> +return NULL;
> +}
>  frame->side_data = tmp;
>  
> -ret = av_mallocz(sizeof(*ret));
> -if (!ret)
> -goto fail;
> -
>  ret->buf = buf;
>  ret->data = ret->buf->data;
>  ret->size = buf->size;
> @@ -672,17 +671,23 @@ static AVFrameSideData *frame_new_side_data(AVFrame 
> *frame,
>  frame->side_data[frame->nb_side_data++] = ret;
>  
>  return ret;
> -fail:
> -av_buffer_unref();
> -return NULL;
>  }
>  
>  AVFrameSideData *av_frame_new_side_data(AVFrame *frame,
>  enum AVFrameSideDataType type,
>  int size)
>  {
> +AVFrameSideData *ret;
> +AVBufferRef *buf = av_buffer_alloc(size);
> +if (!buf)
> +return NULL;
>  
> -return frame_new_side_data(frame, type, av_buffer_alloc(size));
> +ret = av_frame_new_side_data_from_buf(frame, type, buf);
> +if (!ret) {
> +av_buffer_unref();
> +return NULL;

Again, just return ret, regardless of successful allocation or not.

> +}
> +return ret;
>  }
>  
>  AVFrameSideData *av_frame_get_side_data(const AVFrame *frame,
> diff --git a/libavutil/frame.h b/libavutil/frame.h
> index d54bd9a354..59cee8ceab 100644
> --- a/libavutil/frame.h
> +++ b/libavutil/frame.h
> @@ -800,6 +800,22 @@ AVFrameSideData *av_frame_new_side_data(AVFrame *frame,
>  enum AVFrameSideDataType type,
>  int size);
>  
> +/**
> + * Add a new side data to a frame from an existing AVBufferRef
> + *
> + * @param frame a frame to which the side data should be added
> + * @param type  the type of the added side data
> + * @param buf   an AVBufferRef to add as side data. The ownership of
> + *  the reference is transferred to the frame.
> + *
> + * @return newly added side data on success, NULL on error. On failure
> + * the frame is unchanged and the AVBufferRef remains owned by
> + * the caller.
> + */
> +AVFrameSideData *av_frame_new_side_data_from_buf(AVFrame *frame,
> + enum AVFrameSideDataType 
> type,
> + AVBufferRef *buf);
> +
>  /**
>   * @return a pointer to the side data of a

Re: [FFmpeg-devel] [PATCH v2] libavformat/tls: pass numeric hostnames to tls_connect_cbs()

2018-03-01 Thread Stefan _

bump, this is a minor patch
> Hadn't seen that one, it does indeed describe this exact problem.
> I've included it in the commit message, new patch attached.
>
> On 20.02.2018 at 22:30 Carl Eugen Hoyos wrote:
>> 2018-02-20 19:40 GMT+01:00 Stefan _ :
>>
>>> attached patch fixes a small issue with the libtls backend.
>> Please mention ticket #7029 if it is related.
>>
>> Carl Eugen
>> ___
>> 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] frame: add an av_frame_new_side_data_from_buf function

2018-03-01 Thread Rostislav Pehlivanov

Signed-off-by: Rostislav Pehlivanov 
---

Yeah, that sounds better, thanks.

 libavutil/frame.c | 45 +
 libavutil/frame.h | 16 
 2 files changed, 41 insertions(+), 20 deletions(-)

diff --git a/libavutil/frame.c b/libavutil/frame.c
index 662a7e5ab5..a49c853493 100644
--- a/libavutil/frame.c
+++ b/libavutil/frame.c
@@ -26,11 +26,6 @@
 #include "mem.h"
 #include "samplefmt.h"
 
-
-static AVFrameSideData *frame_new_side_data(AVFrame *frame,
-enum AVFrameSideDataType type,
-AVBufferRef *buf);
-
 #if FF_API_FRAME_GET_SET
 MAKE_ACCESSORS(AVFrame, frame, int64_t, best_effort_timestamp)
 MAKE_ACCESSORS(AVFrame, frame, int64_t, pkt_duration)
@@ -356,8 +351,10 @@ FF_ENABLE_DEPRECATION_WARNINGS
 }
 memcpy(sd_dst->data, sd_src->data, sd_src->size);
 } else {
-sd_dst = frame_new_side_data(dst, sd_src->type, 
av_buffer_ref(sd_src->buf));
+AVBufferRef *ref = av_buffer_ref(sd_src->buf);
+sd_dst = av_frame_new_side_data_from_buf(dst, sd_src->type, ref);
 if (!sd_dst) {
+av_buffer_unref();
 wipe_side_data(dst);
 return AVERROR(ENOMEM);
 }
@@ -642,9 +639,9 @@ AVBufferRef *av_frame_get_plane_buffer(AVFrame *frame, int 
plane)
 return NULL;
 }
 
-static AVFrameSideData *frame_new_side_data(AVFrame *frame,
-enum AVFrameSideDataType type,
-AVBufferRef *buf)
+AVFrameSideData *av_frame_new_side_data_from_buf(AVFrame *frame,
+ enum AVFrameSideDataType type,
+ AVBufferRef *buf)
 {
 AVFrameSideData *ret, **tmp;
 
@@ -652,18 +649,20 @@ static AVFrameSideData *frame_new_side_data(AVFrame 
*frame,
 return NULL;
 
 if (frame->nb_side_data > INT_MAX / sizeof(*frame->side_data) - 1)
-goto fail;
+return NULL;
+
+ret = av_mallocz(sizeof(*ret));
+if (!ret)
+return NULL;
 
 tmp = av_realloc(frame->side_data,
  (frame->nb_side_data + 1) * sizeof(*frame->side_data));
-if (!tmp)
-goto fail;
+if (!tmp) {
+av_free(tmp);
+return NULL;
+}
 frame->side_data = tmp;
 
-ret = av_mallocz(sizeof(*ret));
-if (!ret)
-goto fail;
-
 ret->buf = buf;
 ret->data = ret->buf->data;
 ret->size = buf->size;
@@ -672,17 +671,23 @@ static AVFrameSideData *frame_new_side_data(AVFrame 
*frame,
 frame->side_data[frame->nb_side_data++] = ret;
 
 return ret;
-fail:
-av_buffer_unref();
-return NULL;
 }
 
 AVFrameSideData *av_frame_new_side_data(AVFrame *frame,
 enum AVFrameSideDataType type,
 int size)
 {
+AVFrameSideData *ret;
+AVBufferRef *buf = av_buffer_alloc(size);
+if (!buf)
+return NULL;
 
-return frame_new_side_data(frame, type, av_buffer_alloc(size));
+ret = av_frame_new_side_data_from_buf(frame, type, buf);
+if (!ret) {
+av_buffer_unref();
+return NULL;
+}
+return ret;
 }
 
 AVFrameSideData *av_frame_get_side_data(const AVFrame *frame,
diff --git a/libavutil/frame.h b/libavutil/frame.h
index d54bd9a354..59cee8ceab 100644
--- a/libavutil/frame.h
+++ b/libavutil/frame.h
@@ -800,6 +800,22 @@ AVFrameSideData *av_frame_new_side_data(AVFrame *frame,
 enum AVFrameSideDataType type,
 int size);
 
+/**
+ * Add a new side data to a frame from an existing AVBufferRef
+ *
+ * @param frame a frame to which the side data should be added
+ * @param type  the type of the added side data
+ * @param buf   an AVBufferRef to add as side data. The ownership of
+ *  the reference is transferred to the frame.
+ *
+ * @return newly added side data on success, NULL on error. On failure
+ * the frame is unchanged and the AVBufferRef remains owned by
+ * the caller.
+ */
+AVFrameSideData *av_frame_new_side_data_from_buf(AVFrame *frame,
+ enum AVFrameSideDataType type,
+ AVBufferRef *buf);
+
 /**
  * @return a pointer to the side data of a given type on success, NULL if there
  * is no side data with such type in this frame.
-- 
2.16.2

___
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

2018-03-01 Thread Moritz Barsnick

On Thu, Mar 01, 2018 at 09:07:17 +0100, Jerome Borsboom wrote:
> v1.1->v1.2: Changed ifdefs around vc1_get_INTCOMPFIELD, vc1_get_LUMSCALE2,
> and vc1_get_LUMSHIFT2 to av_unused.

When emailing like this, you need to place the additional (manually
edited?) comments below the patch's '---' line. Otherwise they will
become part of the commit message when pushing. (Changes between
reviews and comments like "Please ignore the previous patch" are
obviously not meant for the commit message.)

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

Down here.

>  libavcodec/vaapi_vc1.c | 163 
> -
>  1 file changed, 134 insertions(+), 29 deletions(-)
> 
> diff --git a/libavcodec/vaapi_vc1.c b/libavcodec/vaapi_vc1.c
[...]

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

Re: [FFmpeg-devel] [PATCH] frame: add an av_frame_new_side_data_from_buf function

2018-03-01 Thread James Almer

On 3/1/2018 1:48 PM, Rostislav Pehlivanov wrote:
> Signed-off-by: Rostislav Pehlivanov 
> ---
> 
> Changed so that the function will not create a new reference.
> 
>  libavutil/frame.c | 45 +
>  libavutil/frame.h | 17 +
>  2 files changed, 42 insertions(+), 20 deletions(-)
> 
> diff --git a/libavutil/frame.c b/libavutil/frame.c
> index 662a7e5ab5..a49c853493 100644
> --- a/libavutil/frame.c
> +++ b/libavutil/frame.c
> @@ -26,11 +26,6 @@
>  #include "mem.h"
>  #include "samplefmt.h"
>  
> -
> -static AVFrameSideData *frame_new_side_data(AVFrame *frame,
> -enum AVFrameSideDataType type,
> -AVBufferRef *buf);
> -
>  #if FF_API_FRAME_GET_SET
>  MAKE_ACCESSORS(AVFrame, frame, int64_t, best_effort_timestamp)
>  MAKE_ACCESSORS(AVFrame, frame, int64_t, pkt_duration)
> @@ -356,8 +351,10 @@ FF_ENABLE_DEPRECATION_WARNINGS
>  }
>  memcpy(sd_dst->data, sd_src->data, sd_src->size);
>  } else {
> -sd_dst = frame_new_side_data(dst, sd_src->type, 
> av_buffer_ref(sd_src->buf));
> +AVBufferRef *ref = av_buffer_ref(sd_src->buf);
> +sd_dst = av_frame_new_side_data_from_buf(dst, sd_src->type, ref);
>  if (!sd_dst) {
> +av_buffer_unref();
>  wipe_side_data(dst);
>  return AVERROR(ENOMEM);
>  }
> @@ -642,9 +639,9 @@ AVBufferRef *av_frame_get_plane_buffer(AVFrame *frame, 
> int plane)
>  return NULL;
>  }
>  
> -static AVFrameSideData *frame_new_side_data(AVFrame *frame,
> -enum AVFrameSideDataType type,
> -AVBufferRef *buf)
> +AVFrameSideData *av_frame_new_side_data_from_buf(AVFrame *frame,
> + enum AVFrameSideDataType 
> type,
> + AVBufferRef *buf)
>  {
>  AVFrameSideData *ret, **tmp;
>  
> @@ -652,18 +649,20 @@ static AVFrameSideData *frame_new_side_data(AVFrame 
> *frame,
>  return NULL;
>  
>  if (frame->nb_side_data > INT_MAX / sizeof(*frame->side_data) - 1)
> -goto fail;
> +return NULL;
> +
> +ret = av_mallocz(sizeof(*ret));
> +if (!ret)
> +return NULL;
>  
>  tmp = av_realloc(frame->side_data,
>   (frame->nb_side_data + 1) * sizeof(*frame->side_data));
> -if (!tmp)
> -goto fail;
> +if (!tmp) {
> +av_free(tmp);
> +return NULL;
> +}
>  frame->side_data = tmp;
>  
> -ret = av_mallocz(sizeof(*ret));
> -if (!ret)
> -goto fail;
> -

Moving this up in the function is an unrelated change.

Also there's not a lot to win from doing it. Even if realloc succeeded
and malloc failed, the next time you try to add a new side data the
realloc would effectively be a noop as new size == current size.

>  ret->buf = buf;
>  ret->data = ret->buf->data;
>  ret->size = buf->size;
> @@ -672,17 +671,23 @@ static AVFrameSideData *frame_new_side_data(AVFrame 
> *frame,
>  frame->side_data[frame->nb_side_data++] = ret;
>  
>  return ret;
> -fail:
> -av_buffer_unref();
> -return NULL;
>  }
>  
>  AVFrameSideData *av_frame_new_side_data(AVFrame *frame,
>  enum AVFrameSideDataType type,
>  int size)
>  {
> +AVFrameSideData *ret;
> +AVBufferRef *buf = av_buffer_alloc(size);
> +if (!buf)
> +return NULL;
>  
> -return frame_new_side_data(frame, type, av_buffer_alloc(size));
> +ret = av_frame_new_side_data_from_buf(frame, type, buf);
> +if (!ret) {
> +av_buffer_unref();
> +return NULL;
> +}
> +return ret;

if (!ret)
av_buffer_unref();

return ret;

>  }
>  
>  AVFrameSideData *av_frame_get_side_data(const AVFrame *frame,
> diff --git a/libavutil/frame.h b/libavutil/frame.h
> index d54bd9a354..6745e7d7b2 100644
> --- a/libavutil/frame.h
> +++ b/libavutil/frame.h
> @@ -800,6 +800,23 @@ AVFrameSideData *av_frame_new_side_data(AVFrame *frame,
>  enum AVFrameSideDataType type,
>  int size);
>  
> +/**
> + * Add a new side data to a frame from an existing AVBufferRef
> + *
> + * The ownership is not changed, its up to users to create and pass a
> + * new reference if they still need the AVBufferRef.

This is confusing. The ownership of whatever buffer ref you pass *does*
change on success.

> + * On error, nothing will be changed and the function will return NULL.
> + *
> + * @param frame a frame to which the side data should be added
> + * @param type type of the added side data
> + * @param buf the AVBufferRef to add as side data
> + *
> + * @return newly added side data on success, NULL on error

Try

[FFmpeg-devel] [PATCH] frame: add an av_frame_new_side_data_from_buf function

2018-03-01 Thread Rostislav Pehlivanov

Signed-off-by: Rostislav Pehlivanov 
---

Changed so that the function will not create a new reference.

 libavutil/frame.c | 45 +
 libavutil/frame.h | 17 +
 2 files changed, 42 insertions(+), 20 deletions(-)

diff --git a/libavutil/frame.c b/libavutil/frame.c
index 662a7e5ab5..a49c853493 100644
--- a/libavutil/frame.c
+++ b/libavutil/frame.c
@@ -26,11 +26,6 @@
 #include "mem.h"
 #include "samplefmt.h"
 
-
-static AVFrameSideData *frame_new_side_data(AVFrame *frame,
-enum AVFrameSideDataType type,
-AVBufferRef *buf);
-
 #if FF_API_FRAME_GET_SET
 MAKE_ACCESSORS(AVFrame, frame, int64_t, best_effort_timestamp)
 MAKE_ACCESSORS(AVFrame, frame, int64_t, pkt_duration)
@@ -356,8 +351,10 @@ FF_ENABLE_DEPRECATION_WARNINGS
 }
 memcpy(sd_dst->data, sd_src->data, sd_src->size);
 } else {
-sd_dst = frame_new_side_data(dst, sd_src->type, 
av_buffer_ref(sd_src->buf));
+AVBufferRef *ref = av_buffer_ref(sd_src->buf);
+sd_dst = av_frame_new_side_data_from_buf(dst, sd_src->type, ref);
 if (!sd_dst) {
+av_buffer_unref();
 wipe_side_data(dst);
 return AVERROR(ENOMEM);
 }
@@ -642,9 +639,9 @@ AVBufferRef *av_frame_get_plane_buffer(AVFrame *frame, int 
plane)
 return NULL;
 }
 
-static AVFrameSideData *frame_new_side_data(AVFrame *frame,
-enum AVFrameSideDataType type,
-AVBufferRef *buf)
+AVFrameSideData *av_frame_new_side_data_from_buf(AVFrame *frame,
+ enum AVFrameSideDataType type,
+ AVBufferRef *buf)
 {
 AVFrameSideData *ret, **tmp;
 
@@ -652,18 +649,20 @@ static AVFrameSideData *frame_new_side_data(AVFrame 
*frame,
 return NULL;
 
 if (frame->nb_side_data > INT_MAX / sizeof(*frame->side_data) - 1)
-goto fail;
+return NULL;
+
+ret = av_mallocz(sizeof(*ret));
+if (!ret)
+return NULL;
 
 tmp = av_realloc(frame->side_data,
  (frame->nb_side_data + 1) * sizeof(*frame->side_data));
-if (!tmp)
-goto fail;
+if (!tmp) {
+av_free(tmp);
+return NULL;
+}
 frame->side_data = tmp;
 
-ret = av_mallocz(sizeof(*ret));
-if (!ret)
-goto fail;
-
 ret->buf = buf;
 ret->data = ret->buf->data;
 ret->size = buf->size;
@@ -672,17 +671,23 @@ static AVFrameSideData *frame_new_side_data(AVFrame 
*frame,
 frame->side_data[frame->nb_side_data++] = ret;
 
 return ret;
-fail:
-av_buffer_unref();
-return NULL;
 }
 
 AVFrameSideData *av_frame_new_side_data(AVFrame *frame,
 enum AVFrameSideDataType type,
 int size)
 {
+AVFrameSideData *ret;
+AVBufferRef *buf = av_buffer_alloc(size);
+if (!buf)
+return NULL;
 
-return frame_new_side_data(frame, type, av_buffer_alloc(size));
+ret = av_frame_new_side_data_from_buf(frame, type, buf);
+if (!ret) {
+av_buffer_unref();
+return NULL;
+}
+return ret;
 }
 
 AVFrameSideData *av_frame_get_side_data(const AVFrame *frame,
diff --git a/libavutil/frame.h b/libavutil/frame.h
index d54bd9a354..6745e7d7b2 100644
--- a/libavutil/frame.h
+++ b/libavutil/frame.h
@@ -800,6 +800,23 @@ AVFrameSideData *av_frame_new_side_data(AVFrame *frame,
 enum AVFrameSideDataType type,
 int size);
 
+/**
+ * Add a new side data to a frame from an existing AVBufferRef
+ *
+ * The ownership is not changed, its up to users to create and pass a
+ * new reference if they still need the AVBufferRef.
+ * On error, nothing will be changed and the function will return NULL.
+ *
+ * @param frame a frame to which the side data should be added
+ * @param type type of the added side data
+ * @param buf the AVBufferRef to add as side data
+ *
+ * @return newly added side data on success, NULL on error
+ */
+AVFrameSideData *av_frame_new_side_data_from_buf(AVFrame *frame,
+ enum AVFrameSideDataType type,
+ AVBufferRef *buf);
+
 /**
  * @return a pointer to the side data of a given type on success, NULL if there
  * is no side data with such type in this frame.
-- 
2.16.2

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

[FFmpeg-devel] [PATCH 1/2] lavu/frame: fix inconsistent qp_table_buf deprecation

2018-03-01 Thread wm4

Everything related to the QP data is deprecated, with qp_table_buf being
an inconsistent exception. Some parts were under the deprecation guards,
some not. It probably didn't even compile.
---
 libavutil/frame.c | 7 ---
 libavutil/frame.h | 1 +
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/libavutil/frame.c b/libavutil/frame.c
index 662a7e5ab5..3ecd739317 100644
--- a/libavutil/frame.c
+++ b/libavutil/frame.c
@@ -53,11 +53,10 @@ MAKE_ACCESSORS(AVFrame, frame, enum AVColorRange, 
color_range)
 #if FF_API_FRAME_QP
 int av_frame_set_qp_table(AVFrame *f, AVBufferRef *buf, int stride, int 
qp_type)
 {
+FF_DISABLE_DEPRECATION_WARNINGS
 av_buffer_unref(>qp_table_buf);
 
 f->qp_table_buf = buf;
-
-FF_DISABLE_DEPRECATION_WARNINGS
 f->qscale_table = buf->data;
 f->qstride  = stride;
 f->qscale_type  = qp_type;
@@ -71,12 +70,12 @@ int8_t *av_frame_get_qp_table(AVFrame *f, int *stride, int 
*type)
 FF_DISABLE_DEPRECATION_WARNINGS
 *stride = f->qstride;
 *type   = f->qscale_type;
-FF_ENABLE_DEPRECATION_WARNINGS
 
 if (!f->qp_table_buf)
 return NULL;
 
 return f->qp_table_buf->data;
+FF_ENABLE_DEPRECATION_WARNINGS
 }
 #endif
 
@@ -523,7 +522,9 @@ void av_frame_unref(AVFrame *frame)
 av_freep(>extended_buf);
 av_dict_free(>metadata);
 #if FF_API_FRAME_QP
+FF_DISABLE_DEPRECATION_WARNINGS
 av_buffer_unref(>qp_table_buf);
+FF_ENABLE_DEPRECATION_WARNINGS
 #endif
 
 av_buffer_unref(>hw_frames_ctx);
diff --git a/libavutil/frame.h b/libavutil/frame.h
index d54bd9a354..4c3225b8bd 100644
--- a/libavutil/frame.h
+++ b/libavutil/frame.h
@@ -529,6 +529,7 @@ typedef struct AVFrame {
 attribute_deprecated
 int qscale_type;
 
+attribute_deprecated
 AVBufferRef *qp_table_buf;
 #endif
 /**
-- 
2.16.1

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

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

2018-03-01 Thread 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  | 55 +-
 libavutil/frame.h  | 17 
 tests/ref/fate/exif-image-embedded |  6 +
 tests/ref/fate/exif-image-jpg  | 34 +--
 4 files changed, 92 insertions(+), 20 deletions(-)

diff --git a/libavutil/frame.c b/libavutil/frame.c
index 3ecd739317..a9e76504eb 100644
--- a/libavutil/frame.c
+++ b/libavutil/frame.c
@@ -51,8 +51,16 @@ 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;
+
 FF_DISABLE_DEPRECATION_WARNINGS
 av_buffer_unref(>qp_table_buf);
 
@@ -62,20 +70,53 @@ 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);
+
+if (!frame_new_side_data(f, AV_FRAME_DATA_QP_TABLE_DATA, 
av_buffer_ref(buf)))
+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
 
@@ -789,6 +830,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 4c3225b8bd..7c428cdfae 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/tests/ref/fate/exif-image-embedded 
b/tests/ref/fate/exif-image-embedded
index

Re: [FFmpeg-devel] [PATCH] frame: add an av_frame_new_side_data_from_buf function

2018-03-01 Thread Nicolas George

James Almer (2018-03-01):
> I prefer if the function takes ownership of the reference rather than
> create a new one on success.
> If it creates a new one, then the caller still needs to do something
> with the reference passed to the function afterwards regardless of
> outcome, as shown in your changes to av_frame_new_side_data().
> This is also extra overhead and one more point of failure for the
> function (creating the reference) for no real gain. Let the user decide
> if they want to keep the reference they passed or if they have no use
> for it and would rather have the side data take ownership of it.

I second all these arguments. Making an extra reference can always be
done by the caller. Avoiding the extra reference would not be possible.

It would have been nice to think of a consistent naming scheme for that,
though.

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] frame: add an av_frame_new_side_data_from_buf function

2018-03-01 Thread James Almer

On 3/1/2018 10:55 AM, Rostislav Pehlivanov wrote:
> Signed-off-by: Rostislav Pehlivanov 
> ---
> 
> Sending again, forgot to amend.
> 
> Updated with description of that the function will do.
> Originally the function made a reference from the bufferref but someone
> said that it shouldn't. I don't think that this is very useful so I've
> changed it back so that it refs the buffer (and leaves it up to API users
> to unref it if they no longer need it).
> The function will still do nothing in case it fails and returns NULL.
> Also, the previous version still had the old function forward declared,
> fixed that by removing it.

I prefer if the function takes ownership of the reference rather than
create a new one on success.
If it creates a new one, then the caller still needs to do something
with the reference passed to the function afterwards regardless of
outcome, as shown in your changes to av_frame_new_side_data().
This is also extra overhead and one more point of failure for the
function (creating the reference) for no real gain. Let the user decide
if they want to keep the reference they passed or if they have no use
for it and would rather have the side data take ownership of it.

I'll leave the choice to wm4 anyway since he's the one interested in
this addition the most.

> 
>  libavutil/frame.c | 43 ---
>  libavutil/frame.h | 16 
>  2 files changed, 40 insertions(+), 19 deletions(-)
> 
> diff --git a/libavutil/frame.c b/libavutil/frame.c
> index 662a7e5ab5..869b7866c8 100644
> --- a/libavutil/frame.c
> +++ b/libavutil/frame.c
> @@ -26,11 +26,6 @@
>  #include "mem.h"
>  #include "samplefmt.h"
>  
> -
> -static AVFrameSideData *frame_new_side_data(AVFrame *frame,
> -enum AVFrameSideDataType type,
> -AVBufferRef *buf);
> -
>  #if FF_API_FRAME_GET_SET
>  MAKE_ACCESSORS(AVFrame, frame, int64_t, best_effort_timestamp)
>  MAKE_ACCESSORS(AVFrame, frame, int64_t, pkt_duration)
> @@ -356,7 +351,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
>  }
>  memcpy(sd_dst->data, sd_src->data, sd_src->size);
>  } else {
> -sd_dst = frame_new_side_data(dst, sd_src->type, 
> av_buffer_ref(sd_src->buf));
> +sd_dst = av_frame_new_side_data_from_buf(dst, sd_src->type, 
> sd_src->buf);
>  if (!sd_dst) {
>  wipe_side_data(dst);
>  return AVERROR(ENOMEM);
> @@ -642,29 +637,30 @@ AVBufferRef *av_frame_get_plane_buffer(AVFrame *frame, 
> int plane)
>  return NULL;
>  }
>  
> -static AVFrameSideData *frame_new_side_data(AVFrame *frame,
> -enum AVFrameSideDataType type,
> -AVBufferRef *buf)
> +AVFrameSideData *av_frame_new_side_data_from_buf(AVFrame *frame,
> + enum AVFrameSideDataType 
> type,
> + AVBufferRef *buf)
>  {
> -AVFrameSideData *ret, **tmp;
> +AVFrameSideData *ret, **tmp = NULL;
> +AVBufferRef *ref = av_buffer_ref(buf);
>  
> -if (!buf)
> -return NULL;
> +if (!buf || !ref)
> +goto fail;
>  
>  if (frame->nb_side_data > INT_MAX / sizeof(*frame->side_data) - 1)
>  goto fail;
>  
> +ret = av_mallocz(sizeof(*ret));
> +if (!ret)
> +goto fail;
> +
>  tmp = av_realloc(frame->side_data,
>   (frame->nb_side_data + 1) * sizeof(*frame->side_data));
>  if (!tmp)
>  goto fail;
>  frame->side_data = tmp;
>  
> -ret = av_mallocz(sizeof(*ret));
> -if (!ret)
> -goto fail;
> -
> -ret->buf = buf;
> +ret->buf  = ref;
>  ret->data = ret->buf->data;
>  ret->size = buf->size;
>  ret->type = type;
> @@ -673,7 +669,8 @@ static AVFrameSideData *frame_new_side_data(AVFrame 
> *frame,
>  
>  return ret;
>  fail:
> -av_buffer_unref();
> +av_buffer_unref();
> +av_free(tmp);
>  return NULL;
>  }
>  
> @@ -681,8 +678,16 @@ AVFrameSideData *av_frame_new_side_data(AVFrame *frame,
>  enum AVFrameSideDataType type,
>  int size)
>  {
> +AVFrameSideData *ret;
> +AVBufferRef *buf = av_buffer_alloc(size);
> +if (!buf)
> +return NULL;
>  
> -return frame_new_side_data(frame, type, av_buffer_alloc(size));
> +ret = av_frame_new_side_data_from_buf(frame, type, buf);
> +av_buffer_unref();
> +if (!ret)
> +return NULL;
> +return ret;
>  }
>  
>  AVFrameSideData *av_frame_get_side_data(const AVFrame *frame,
> diff --git a/libavutil/frame.h b/libavutil/frame.h
> index d54bd9a354..504ddce073 100644
> --- a/libavutil/frame.h
> +++ b/libavutil/frame.h
> @@ -800,6 +800,22 @@ AVFrameSideData *av_frame_new_side_data(AVFrame *frame,
>

[FFmpeg-devel] [PATCH] frame: add an av_frame_new_side_data_from_buf function

2018-03-01 Thread Rostislav Pehlivanov

Signed-off-by: Rostislav Pehlivanov 
---

Sending again, forgot to amend.

Updated with description of that the function will do.
Originally the function made a reference from the bufferref but someone
said that it shouldn't. I don't think that this is very useful so I've
changed it back so that it refs the buffer (and leaves it up to API users
to unref it if they no longer need it).
The function will still do nothing in case it fails and returns NULL.
Also, the previous version still had the old function forward declared,
fixed that by removing it.

 libavutil/frame.c | 43 ---
 libavutil/frame.h | 16 
 2 files changed, 40 insertions(+), 19 deletions(-)

diff --git a/libavutil/frame.c b/libavutil/frame.c
index 662a7e5ab5..869b7866c8 100644
--- a/libavutil/frame.c
+++ b/libavutil/frame.c
@@ -26,11 +26,6 @@
 #include "mem.h"
 #include "samplefmt.h"
 
-
-static AVFrameSideData *frame_new_side_data(AVFrame *frame,
-enum AVFrameSideDataType type,
-AVBufferRef *buf);
-
 #if FF_API_FRAME_GET_SET
 MAKE_ACCESSORS(AVFrame, frame, int64_t, best_effort_timestamp)
 MAKE_ACCESSORS(AVFrame, frame, int64_t, pkt_duration)
@@ -356,7 +351,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
 }
 memcpy(sd_dst->data, sd_src->data, sd_src->size);
 } else {
-sd_dst = frame_new_side_data(dst, sd_src->type, 
av_buffer_ref(sd_src->buf));
+sd_dst = av_frame_new_side_data_from_buf(dst, sd_src->type, 
sd_src->buf);
 if (!sd_dst) {
 wipe_side_data(dst);
 return AVERROR(ENOMEM);
@@ -642,29 +637,30 @@ AVBufferRef *av_frame_get_plane_buffer(AVFrame *frame, 
int plane)
 return NULL;
 }
 
-static AVFrameSideData *frame_new_side_data(AVFrame *frame,
-enum AVFrameSideDataType type,
-AVBufferRef *buf)
+AVFrameSideData *av_frame_new_side_data_from_buf(AVFrame *frame,
+ enum AVFrameSideDataType type,
+ AVBufferRef *buf)
 {
-AVFrameSideData *ret, **tmp;
+AVFrameSideData *ret, **tmp = NULL;
+AVBufferRef *ref = av_buffer_ref(buf);
 
-if (!buf)
-return NULL;
+if (!buf || !ref)
+goto fail;
 
 if (frame->nb_side_data > INT_MAX / sizeof(*frame->side_data) - 1)
 goto fail;
 
+ret = av_mallocz(sizeof(*ret));
+if (!ret)
+goto fail;
+
 tmp = av_realloc(frame->side_data,
  (frame->nb_side_data + 1) * sizeof(*frame->side_data));
 if (!tmp)
 goto fail;
 frame->side_data = tmp;
 
-ret = av_mallocz(sizeof(*ret));
-if (!ret)
-goto fail;
-
-ret->buf = buf;
+ret->buf  = ref;
 ret->data = ret->buf->data;
 ret->size = buf->size;
 ret->type = type;
@@ -673,7 +669,8 @@ static AVFrameSideData *frame_new_side_data(AVFrame *frame,
 
 return ret;
 fail:
-av_buffer_unref();
+av_buffer_unref();
+av_free(tmp);
 return NULL;
 }
 
@@ -681,8 +678,16 @@ AVFrameSideData *av_frame_new_side_data(AVFrame *frame,
 enum AVFrameSideDataType type,
 int size)
 {
+AVFrameSideData *ret;
+AVBufferRef *buf = av_buffer_alloc(size);
+if (!buf)
+return NULL;
 
-return frame_new_side_data(frame, type, av_buffer_alloc(size));
+ret = av_frame_new_side_data_from_buf(frame, type, buf);
+av_buffer_unref();
+if (!ret)
+return NULL;
+return ret;
 }
 
 AVFrameSideData *av_frame_get_side_data(const AVFrame *frame,
diff --git a/libavutil/frame.h b/libavutil/frame.h
index d54bd9a354..504ddce073 100644
--- a/libavutil/frame.h
+++ b/libavutil/frame.h
@@ -800,6 +800,22 @@ AVFrameSideData *av_frame_new_side_data(AVFrame *frame,
 enum AVFrameSideDataType type,
 int size);
 
+/**
+ * Add a new side data to a frame from an existing AVBufferRef
+ *
+ * A new reference of the buffer will be created and used.
+ * On error, nothing will be changed and the function will return NULL.
+ *
+ * @param frame a frame to which the side data should be added
+ * @param type type of the added side data
+ * @param buf the AVBufferRef to add as side data
+ *
+ * @return newly added side data on success, NULL on error
+ */
+AVFrameSideData *av_frame_new_side_data_from_buf(AVFrame *frame,
+ enum AVFrameSideDataType type,
+ AVBufferRef *buf);
+
 /**
  * @return a pointer to the side data of a given type on success, NULL if there
  * is no side data with such type in this frame.
-- 
2.16.2

___
ffmpeg-devel

[FFmpeg-devel] [PATCH] frame: add an av_frame_new_side_data_from_buf function

2018-03-01 Thread Rostislav Pehlivanov

Signed-off-by: Rostislav Pehlivanov 
---

Updated with description of that the function will do.
Originally the function made a reference from the bufferref but someone
said that it shouldn't. I don't think that this is very useful so I've
changed it back so that it refs the buffer (and leaves it up to API users
to unref it if they no longer need it).
The function will still do nothing in case it fails and returns NULL.
Also, the previous version still had the old function forward declared,
fixed that by removing it.

 libavutil/frame.c | 42 +++---
 libavutil/frame.h | 16 
 2 files changed, 39 insertions(+), 19 deletions(-)

diff --git a/libavutil/frame.c b/libavutil/frame.c
index 662a7e5ab5..12a26fb150 100644
--- a/libavutil/frame.c
+++ b/libavutil/frame.c
@@ -26,11 +26,6 @@
 #include "mem.h"
 #include "samplefmt.h"
 
-
-static AVFrameSideData *frame_new_side_data(AVFrame *frame,
-enum AVFrameSideDataType type,
-AVBufferRef *buf);
-
 #if FF_API_FRAME_GET_SET
 MAKE_ACCESSORS(AVFrame, frame, int64_t, best_effort_timestamp)
 MAKE_ACCESSORS(AVFrame, frame, int64_t, pkt_duration)
@@ -356,7 +351,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
 }
 memcpy(sd_dst->data, sd_src->data, sd_src->size);
 } else {
-sd_dst = frame_new_side_data(dst, sd_src->type, 
av_buffer_ref(sd_src->buf));
+sd_dst = av_frame_new_side_data_from_buf(dst, sd_src->type, 
sd_src->buf);
 if (!sd_dst) {
 wipe_side_data(dst);
 return AVERROR(ENOMEM);
@@ -642,29 +637,30 @@ AVBufferRef *av_frame_get_plane_buffer(AVFrame *frame, 
int plane)
 return NULL;
 }
 
-static AVFrameSideData *frame_new_side_data(AVFrame *frame,
-enum AVFrameSideDataType type,
-AVBufferRef *buf)
+AVFrameSideData *av_frame_new_side_data_from_buf(AVFrame *frame,
+ enum AVFrameSideDataType type,
+ AVBufferRef *buf)
 {
-AVFrameSideData *ret, **tmp;
+AVFrameSideData *ret, **tmp = NULL;
+AVBufferRef *ref = av_buffer_ref(buf);
 
-if (!buf)
-return NULL;
+if (!buf || !ref)
+goto fail;
 
 if (frame->nb_side_data > INT_MAX / sizeof(*frame->side_data) - 1)
 goto fail;
 
+ret = av_mallocz(sizeof(*ret));
+if (!ret)
+goto fail;
+
 tmp = av_realloc(frame->side_data,
  (frame->nb_side_data + 1) * sizeof(*frame->side_data));
 if (!tmp)
 goto fail;
 frame->side_data = tmp;
 
-ret = av_mallocz(sizeof(*ret));
-if (!ret)
-goto fail;
-
-ret->buf = buf;
+ret->buf  = ref;
 ret->data = ret->buf->data;
 ret->size = buf->size;
 ret->type = type;
@@ -673,7 +669,8 @@ static AVFrameSideData *frame_new_side_data(AVFrame *frame,
 
 return ret;
 fail:
-av_buffer_unref();
+av_buffer_unref();
+av_free(tmp);
 return NULL;
 }
 
@@ -681,8 +678,15 @@ AVFrameSideData *av_frame_new_side_data(AVFrame *frame,
 enum AVFrameSideDataType type,
 int size)
 {
+AVBufferRef *buf = av_buffer_alloc(size);
+if (!buf)
+return NULL;
 
-return frame_new_side_data(frame, type, av_buffer_alloc(size));
+AVFrameSideData *ret = av_frame_new_side_data_from_buf(frame, type, buf);
+av_buffer_unref();
+if (!ref)
+return NULL;
+return ret;
 }
 
 AVFrameSideData *av_frame_get_side_data(const AVFrame *frame,
diff --git a/libavutil/frame.h b/libavutil/frame.h
index d54bd9a354..504ddce073 100644
--- a/libavutil/frame.h
+++ b/libavutil/frame.h
@@ -800,6 +800,22 @@ AVFrameSideData *av_frame_new_side_data(AVFrame *frame,
 enum AVFrameSideDataType type,
 int size);
 
+/**
+ * Add a new side data to a frame from an existing AVBufferRef
+ *
+ * A new reference of the buffer will be created and used.
+ * On error, nothing will be changed and the function will return NULL.
+ *
+ * @param frame a frame to which the side data should be added
+ * @param type type of the added side data
+ * @param buf the AVBufferRef to add as side data
+ *
+ * @return newly added side data on success, NULL on error
+ */
+AVFrameSideData *av_frame_new_side_data_from_buf(AVFrame *frame,
+ enum AVFrameSideDataType type,
+ AVBufferRef *buf);
+
 /**
  * @return a pointer to the side data of a given type on success, NULL if there
  * is no side data with such type in this frame.
-- 
2.16.2

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

Re: [FFmpeg-devel] [PATCH] frame: add an av_frame_new_side_data_from_buf function

2018-03-01 Thread wm4

On Thu,  1 Mar 2018 12:32:14 +
Rostislav Pehlivanov  wrote:

> Signed-off-by: Rostislav Pehlivanov 
> ---
>  libavutil/frame.c | 39 ---
>  libavutil/frame.h | 13 +
>  2 files changed, 37 insertions(+), 15 deletions(-)
> 
> diff --git a/libavutil/frame.c b/libavutil/frame.c
> index 662a7e5ab5..601906fcc2 100644
> --- a/libavutil/frame.c
> +++ b/libavutil/frame.c
> @@ -356,8 +356,10 @@ FF_ENABLE_DEPRECATION_WARNINGS
>  }
>  memcpy(sd_dst->data, sd_src->data, sd_src->size);
>  } else {
> -sd_dst = frame_new_side_data(dst, sd_src->type, 
> av_buffer_ref(sd_src->buf));
> +AVBufferRef *buf = av_buffer_ref(sd_src->buf);
> +sd_dst = av_frame_new_side_data_from_buf(dst, sd_src->type, buf);
>  if (!sd_dst) {
> +av_buffer_unref();
>  wipe_side_data(dst);
>  return AVERROR(ENOMEM);
>  }
> @@ -642,9 +644,9 @@ AVBufferRef *av_frame_get_plane_buffer(AVFrame *frame, 
> int plane)
>  return NULL;
>  }
>  
> -static AVFrameSideData *frame_new_side_data(AVFrame *frame,
> -enum AVFrameSideDataType type,
> -AVBufferRef *buf)
> +AVFrameSideData *av_frame_new_side_data_from_buf(AVFrame *frame,
> + enum AVFrameSideDataType 
> type,
> + AVBufferRef *buf)
>  {
>  AVFrameSideData *ret, **tmp;
>  
> @@ -652,18 +654,20 @@ static AVFrameSideData *frame_new_side_data(AVFrame 
> *frame,
>  return NULL;
>  
>  if (frame->nb_side_data > INT_MAX / sizeof(*frame->side_data) - 1)
> -goto fail;
> +return NULL;
> +
> +ret = av_mallocz(sizeof(*ret));
> +if (!ret)
> +return NULL;
>  
>  tmp = av_realloc(frame->side_data,
>   (frame->nb_side_data + 1) * sizeof(*frame->side_data));
> -if (!tmp)
> -goto fail;
> +if (!tmp) {
> +av_free(ret);
> +return NULL;
> +}
>  frame->side_data = tmp;
>  
> -ret = av_mallocz(sizeof(*ret));
> -if (!ret)
> -goto fail;
> -
>  ret->buf = buf;
>  ret->data = ret->buf->data;
>  ret->size = buf->size;
> @@ -672,17 +676,22 @@ static AVFrameSideData *frame_new_side_data(AVFrame 
> *frame,
>  frame->side_data[frame->nb_side_data++] = ret;
>  
>  return ret;
> -fail:
> -av_buffer_unref();
> -return NULL;
>  }
>  
>  AVFrameSideData *av_frame_new_side_data(AVFrame *frame,
>  enum AVFrameSideDataType type,
>  int size)
>  {
> +AVBufferRef *buf = av_buffer_alloc(size);
> +if (!buf)
> +return NULL;
>  
> -return frame_new_side_data(frame, type, av_buffer_alloc(size));
> +AVFrameSideData *ret = av_frame_new_side_data_from_buf(frame, type, buf);
> +if (!ref) {
> +av_buffer_unref();
> +return NULL;
> +}
> +return ret;
>  }
>  
>  AVFrameSideData *av_frame_get_side_data(const AVFrame *frame,
> diff --git a/libavutil/frame.h b/libavutil/frame.h
> index d54bd9a354..1e3c40a30e 100644
> --- a/libavutil/frame.h
> +++ b/libavutil/frame.h
> @@ -800,6 +800,19 @@ AVFrameSideData *av_frame_new_side_data(AVFrame *frame,
>  enum AVFrameSideDataType type,
>  int size);
>  
> +/**
> + * Add a new side data to a frame from an existing AVBufferRef
> + *
> + * @param frame a frame to which the side data should be added
> + * @param type type of the added side data
> + * @param buf the AVBufferRef to add as side data
> + *
> + * @return newly added side data on success, NULL on error
> + */

Doesn't describe what happens to buf at all. Does the function create a
new reference? Does it take over ownership? If so, what happens on
error?

> +AVFrameSideData *av_frame_new_side_data_from_buf(AVFrame *frame,
> + enum AVFrameSideDataType 
> type,
> + AVBufferRef *buf);
> +
>  /**
>   * @return a pointer to the side data of a given type on success, NULL if 
> there
>   * is no side data with such type in this frame.

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

[FFmpeg-devel] [PATCH] frame: add an av_frame_new_side_data_from_buf function

2018-03-01 Thread Rostislav Pehlivanov

Signed-off-by: Rostislav Pehlivanov 
---
 libavutil/frame.c | 39 ---
 libavutil/frame.h | 13 +
 2 files changed, 37 insertions(+), 15 deletions(-)

diff --git a/libavutil/frame.c b/libavutil/frame.c
index 662a7e5ab5..601906fcc2 100644
--- a/libavutil/frame.c
+++ b/libavutil/frame.c
@@ -356,8 +356,10 @@ FF_ENABLE_DEPRECATION_WARNINGS
 }
 memcpy(sd_dst->data, sd_src->data, sd_src->size);
 } else {
-sd_dst = frame_new_side_data(dst, sd_src->type, 
av_buffer_ref(sd_src->buf));
+AVBufferRef *buf = av_buffer_ref(sd_src->buf);
+sd_dst = av_frame_new_side_data_from_buf(dst, sd_src->type, buf);
 if (!sd_dst) {
+av_buffer_unref();
 wipe_side_data(dst);
 return AVERROR(ENOMEM);
 }
@@ -642,9 +644,9 @@ AVBufferRef *av_frame_get_plane_buffer(AVFrame *frame, int 
plane)
 return NULL;
 }
 
-static AVFrameSideData *frame_new_side_data(AVFrame *frame,
-enum AVFrameSideDataType type,
-AVBufferRef *buf)
+AVFrameSideData *av_frame_new_side_data_from_buf(AVFrame *frame,
+ enum AVFrameSideDataType type,
+ AVBufferRef *buf)
 {
 AVFrameSideData *ret, **tmp;
 
@@ -652,18 +654,20 @@ static AVFrameSideData *frame_new_side_data(AVFrame 
*frame,
 return NULL;
 
 if (frame->nb_side_data > INT_MAX / sizeof(*frame->side_data) - 1)
-goto fail;
+return NULL;
+
+ret = av_mallocz(sizeof(*ret));
+if (!ret)
+return NULL;
 
 tmp = av_realloc(frame->side_data,
  (frame->nb_side_data + 1) * sizeof(*frame->side_data));
-if (!tmp)
-goto fail;
+if (!tmp) {
+av_free(ret);
+return NULL;
+}
 frame->side_data = tmp;
 
-ret = av_mallocz(sizeof(*ret));
-if (!ret)
-goto fail;
-
 ret->buf = buf;
 ret->data = ret->buf->data;
 ret->size = buf->size;
@@ -672,17 +676,22 @@ static AVFrameSideData *frame_new_side_data(AVFrame 
*frame,
 frame->side_data[frame->nb_side_data++] = ret;
 
 return ret;
-fail:
-av_buffer_unref();
-return NULL;
 }
 
 AVFrameSideData *av_frame_new_side_data(AVFrame *frame,
 enum AVFrameSideDataType type,
 int size)
 {
+AVBufferRef *buf = av_buffer_alloc(size);
+if (!buf)
+return NULL;
 
-return frame_new_side_data(frame, type, av_buffer_alloc(size));
+AVFrameSideData *ret = av_frame_new_side_data_from_buf(frame, type, buf);
+if (!ref) {
+av_buffer_unref();
+return NULL;
+}
+return ret;
 }
 
 AVFrameSideData *av_frame_get_side_data(const AVFrame *frame,
diff --git a/libavutil/frame.h b/libavutil/frame.h
index d54bd9a354..1e3c40a30e 100644
--- a/libavutil/frame.h
+++ b/libavutil/frame.h
@@ -800,6 +800,19 @@ AVFrameSideData *av_frame_new_side_data(AVFrame *frame,
 enum AVFrameSideDataType type,
 int size);
 
+/**
+ * Add a new side data to a frame from an existing AVBufferRef
+ *
+ * @param frame a frame to which the side data should be added
+ * @param type type of the added side data
+ * @param buf the AVBufferRef to add as side data
+ *
+ * @return newly added side data on success, NULL on error
+ */
+AVFrameSideData *av_frame_new_side_data_from_buf(AVFrame *frame,
+ enum AVFrameSideDataType type,
+ AVBufferRef *buf);
+
 /**
  * @return a pointer to the side data of a given type on success, NULL if there
  * is no side data with such type in this frame.
-- 
2.16.2

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

Re: [FFmpeg-devel] [PATCH] Revert "Remove battleforthenet widget"

2018-03-01 Thread wm4

On Thu, 1 Mar 2018 11:49:16 +
Ricardo Constantino  wrote:

> On 1 March 2018 at 01:19, Michael Niedermayer 
> wrote:
> 
> > On Wed, Feb 28, 2018 at 12:33:55PM -0900, Lou Logan wrote:  
> > > On Wed, Feb 28, 2018, at 11:25 AM, Jan Ekström wrote:  
> > > >
> > > > Looking at how much it got updated the last time when it misbehaved
> > > > shows really well how that worked the last time. Sorry if I sound
> > > > facetious, but I do use ffmpeg-all.html a lot and it got /really/
> > > > irritating.  
> > >
> > > +1.
> > >
> > > I object to the patch. The widget is annoyingly intrusive,  
> >
> > How is it intrusive if it is displayed once and never shows
> > again for 60 days (which is how its configured) if you close it ?
> >  
> 
> > It will show again if you delete the cookie it uses to keep track of
> > you closing it i think. But MANY webpages will display silly first time
> > notes if you loose cookies regularly.
> >  
> 
> 
> Many people remove cookies from non-regular sites on closing the browser.
> Why would people suddenly need to keep a cookie in order to not get nagged
> on ffmpeg.org?
> 
> 
> >
> >  
> > > but as a compromise I would not block a small, resized, temporary simple  
> > image banner in the bottom of the menu:  
> > >
> > >  > f6v>  
> >
> > If you put this there, its of course better than nothing
> > but i dont know if this is wise as a replacement for the widget.
> >  
> 
> It seems a very welcome alternative. Banners are way less annoying than
> fullscreen popups.
> 
> 
> >
> > As a user i much rather would want to be told that theres a problem in the
> > future straight in the face and how i might be able to help fight against
> > it.
> > Instead of a banner i wont realize is there and wont click on and wont
> > realize
> > what it is about before iam hit with slower speed or increased fees from
> > an ISP or increased fees from random companies who need to pay for fast
> > lanes
> > to keep operating
> >  
> 
> You can link whatever's the campaign webpage in the banner and whoever
> cares will go see it.
> Don't assume people will care more if you plaster it in their face and
> block what they were reading.
> 
> 
> >
> > Its in fact a slightly sinister scheme, people could end up paying alot
> > more
> > for their internet connection without realizing that they do. That is if
> > they
> > end up paying all the companies who in the future may have to pay for their
> > connections not to be slowed down. The end user pays, the ISPs get the
> > money
> > but the path is not neccesarily direct.
> >  
> 
> There's a lot more places where people can get their armchair politics
> satisfied than ffmpeg.org.
> A banner or a news post would make more sense.
> 

Yeah, I agree a banner of some sort would be less intrusive and still
get noticed. We'd also not have to run foreign JS (that already proved
to be buggy before). Seems like the best choice.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter/avf_concat: add next command

2018-03-01 Thread Nicolas George

Liu Steven (2018-02-28):
> LGTM

LGTM too, pushed.

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] Revert "Remove battleforthenet widget"

2018-03-01 Thread Ronald S. Bultje

Hi,

On Thu, Mar 1, 2018 at 6:49 AM, Ricardo Constantino 
wrote:

> There's a lot more places where people can get their armchair politics
> satisfied than ffmpeg.org.
>

I 100% agree with this ...

> A banner or a news post would make more sense.

... but I pretty strongly disagree with this.

Let's assume that I care about kittens. After all, we all know Youtube is
the biggest video website in the world, and Youtube is filled primarily
with cat videos. We should care about kittens, it's the center of our
industry. Can I now advertise for my local kitten shelter on ffmpeg.org
using a popup, banner or news post?

Again, please: no advertising, no politics. It was fun while it lasted but
it's turning into something semi-permanent now, I really have significant
issues with this.

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

Re: [FFmpeg-devel] [PATCH] Revert "Remove battleforthenet widget"

2018-03-01 Thread Ricardo Constantino

On 1 March 2018 at 01:19, Michael Niedermayer 
wrote:

> On Wed, Feb 28, 2018 at 12:33:55PM -0900, Lou Logan wrote:
> > On Wed, Feb 28, 2018, at 11:25 AM, Jan Ekström wrote:
> > >
> > > Looking at how much it got updated the last time when it misbehaved
> > > shows really well how that worked the last time. Sorry if I sound
> > > facetious, but I do use ffmpeg-all.html a lot and it got /really/
> > > irritating.
> >
> > +1.
> >
> > I object to the patch. The widget is annoyingly intrusive,
>
> How is it intrusive if it is displayed once and never shows
> again for 60 days (which is how its configured) if you close it ?
>

> It will show again if you delete the cookie it uses to keep track of
> you closing it i think. But MANY webpages will display silly first time
> notes if you loose cookies regularly.
>


Many people remove cookies from non-regular sites on closing the browser.
Why would people suddenly need to keep a cookie in order to not get nagged
on ffmpeg.org?


>
>
> > but as a compromise I would not block a small, resized, temporary simple
> image banner in the bottom of the menu:
> >
> >  f6v>
>
> If you put this there, its of course better than nothing
> but i dont know if this is wise as a replacement for the widget.
>

It seems a very welcome alternative. Banners are way less annoying than
fullscreen popups.


>
> As a user i much rather would want to be told that theres a problem in the
> future straight in the face and how i might be able to help fight against
> it.
> Instead of a banner i wont realize is there and wont click on and wont
> realize
> what it is about before iam hit with slower speed or increased fees from
> an ISP or increased fees from random companies who need to pay for fast
> lanes
> to keep operating
>

You can link whatever's the campaign webpage in the banner and whoever
cares will go see it.
Don't assume people will care more if you plaster it in their face and
block what they were reading.


>
> Its in fact a slightly sinister scheme, people could end up paying alot
> more
> for their internet connection without realizing that they do. That is if
> they
> end up paying all the companies who in the future may have to pay for their
> connections not to be slowed down. The end user pays, the ISPs get the
> money
> but the path is not neccesarily direct.
>

There's a lot more places where people can get their armchair politics
satisfied than ffmpeg.org.
A banner or a news post would make more sense.


>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Rewriting code that is poorly written but fully understood is good.
> Rewriting code that one doesnt understand is a sign that one is less smart
> then the original author, trying to rewrite it will not make it better.
>
> ___
> 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 2/3 v1.2] avcodec/vaapi: add fields for VAAPI VC-1 interlaced decoding

2018-03-01 Thread Jerome Borsboom

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(-)

diff --git a/libavcodec/vaapi_vc1.c b/libavcodec/vaapi_vc1.c
index 525376790e..97b23917f6 100644
--- a/libavcodec/vaapi_vc1.c
+++ b/libavcodec/vaapi_vc1.c
@@ -44,7 +44,8 @@ static inline int vc1_has_MVTYPEMB_bitplane(const VC1Context 
*v)
 {
 if (v->mv_type_is_raw)
 return 0;
-return v->s.pict_type == AV_PICTURE_TYPE_P &&
+return v->fcm == PROGRESSIVE &&
+   (v->s.pict_type == AV_PICTURE_TYPE_P && !v->p_frame_skipped) &&
(v->mv_mode == MV_PMODE_MIXED_MV ||
 (v->mv_mode == MV_PMODE_INTENSITY_COMP &&
  v->mv_mode2 == MV_PMODE_MIXED_MV));
@@ -55,8 +56,9 @@ static inline int vc1_has_SKIPMB_bitplane(const VC1Context *v)
 {
 if (v->skip_is_raw)
 return 0;
-return v->s.pict_type == AV_PICTURE_TYPE_P ||
-   (v->s.pict_type == AV_PICTURE_TYPE_B && !v->bi_type);
+return (v->fcm == PROGRESSIVE || v->fcm == ILACE_FRAME) &&
+   ((v->s.pict_type == AV_PICTURE_TYPE_P && !v->p_frame_skipped) ||
+(v->s.pict_type == AV_PICTURE_TYPE_B && !v->bi_type));
 }
 
 /** Check whether the DIRECTMB bitplane is present */
@@ -64,7 +66,8 @@ static inline int vc1_has_DIRECTMB_bitplane(const VC1Context 
*v)
 {
 if (v->dmb_is_raw)
 return 0;
-return v->s.pict_type == AV_PICTURE_TYPE_B && !v->bi_type;
+return (v->fcm == PROGRESSIVE || v->fcm == ILACE_FRAME) &&
+   (v->s.pict_type == AV_PICTURE_TYPE_B && !v->bi_type);
 }
 
 /** Check whether the ACPRED bitplane is present */
@@ -89,6 +92,25 @@ static inline int vc1_has_OVERFLAGS_bitplane(const 
VC1Context *v)
v->condover == CONDOVER_SELECT;
 }
 
+/** Check whether the FIELDTX bitplane is present */
+static inline int vc1_has_FIELDTX_bitplane(const VC1Context *v)
+{
+if (v->fieldtx_is_raw)
+return 0;
+return v->fcm == ILACE_FRAME &&
+   (v->s.pict_type == AV_PICTURE_TYPE_I ||
+(v->s.pict_type == AV_PICTURE_TYPE_B && v->bi_type));
+}
+
+/** Check whether the FORWARDMB bitplane is present */
+static inline int vc1_has_FORWARDMB_bitplane(const VC1Context *v)
+{
+if (v->fmb_is_raw)
+return 0;
+return v->fcm == ILACE_FIELD &&
+   (v->s.pict_type == AV_PICTURE_TYPE_B && !v->bi_type);
+}
+
 /** Reconstruct bitstream PTYPE (7.1.1.4, index into Table-35) */
 static int vc1_get_PTYPE(const VC1Context *v)
 {
@@ -101,10 +123,22 @@ static int vc1_get_PTYPE(const VC1Context *v)
 return 0;
 }
 
+/** Reconstruct bitstream FPTYPE (9.1.1.42, index into Table-105) */
+static int vc1_get_FPTYPE(const VC1Context *v)
+{
+const MpegEncContext *s = >s;
+switch (s->pict_type) {
+case AV_PICTURE_TYPE_I: return 0;
+case AV_PICTURE_TYPE_P: return 3;
+case AV_PICTURE_TYPE_B: return v->bi_type ? 7 : 4;
+}
+return 0;
+}
+
 /** Reconstruct bitstream MVMODE (7.1.1.32) */
 static inline VAMvModeVC1 vc1_get_MVMODE(const VC1Context *v)
 {
-if (v->s.pict_type == AV_PICTURE_TYPE_P ||
+if ((v->s.pict_type == AV_PICTURE_TYPE_P && !v->p_frame_skipped) ||
 (v->s.pict_type == AV_PICTURE_TYPE_B && !v->bi_type))
 return get_VAMvModeVC1(v->mv_mode);
 return 0;
@@ -113,11 +147,77 @@ static inline VAMvModeVC1 vc1_get_MVMODE(const VC1Context 
*v)
 /** Reconstruct bitstream MVMODE2 (7.1.1.33) */
 static inline VAMvModeVC1 vc1_get_MVMODE2(const VC1Context *v)
 {
-if (v->s.pict_type == AV_PICTURE_TYPE_P && v->mv_mode == 
MV_PMODE_INTENSITY_COMP)
+if ((v->s.pict_type == AV_PICTURE_TYPE_P && !v->p_frame_skipped) &&
+v->mv_mode == MV_PMODE_INTENSITY_COMP)
 return get_VAMvModeVC1(v->mv_mode2);
 return 0;
 }
 
+av_unused static inline int vc1_get_INTCOMPFIELD(const VC1Context *v)
+{
+if ((v->s.pict_type == AV_PICTURE_TYPE_P && !v->p_frame_skipped) &&
+v->fcm == ILACE_FIELD &&
+v->mv_mode == MV_PMODE_INTENSITY_COMP)
+switch (v->intcompfield) {
+case 1: return 1;
+case 2: return 2;
+case 3: return 0;
+}
+return 0;
+}
+
+static inline int vc1_get_LUMSCALE(const VC1Context *v)
+{
+if (v->s.pict_type == AV_PICTURE_TYPE_P && !v->p_frame_skipped) {
+if ((v->fcm == PROGRESSIVE && v->mv_mode == MV_PMODE_INTENSITY_COMP) ||
+(v->fcm == ILACE_FRAME && v->intcomp))
+return v->lumscale;
+else if (v->fcm == ILACE_FIELD && v->mv_mode == 
MV_PMODE_INTENSITY_COMP)
+switch (v->intcompfield) {
+case 1: return v->lumscale;
+case 2: return v->lumscale2;

47 matches

Mail list logo