[FFmpeg-devel] [PATCH, v2] lavf/vf_vpp_qsv: add support for QSV transpose filter

2019-03-18 Thread Linjie Fu
Add transpose support for qsv_vpp with rotate and hflip:
- rotate: [0, 3] support clockwise rotation of 0, 90, 180, 270;
- hflip:  [0, 1] support horizontal flip;

Configure with:
{"cclock_hflip","clock","cclock","clock_hflip","reversal","hflip","vflip"}

Limitation:
If pipeline contains resize, mirroring and other, VPP skips other filters
in MSDK when IOPattern equals d3d->d3d. So "cclock_hflip, clock_hflip, vflip"
will not work in d3d->d3d condition.

CMD:
ffmpeg -hwaccel qsv -c:v h264_qsv -i input.h264
-vf 'format=qsv,vpp_qsv=transpose=clock' -c:v h264_qsv output.h264

ffmpeg -init_hw_device qsv=hw -filter_hw_device hw -c:v h264_qsv -i input.h264
-vf 'hwupload=extra_hw_frames=64,format=qsv,vpp_qsv=transpose=cclock_hflip'
-f rawvideo -pix_fmt nv12 ./transpose.yuv

Signed-off-by: Linjie Fu 
---
[v2]: modify the name, combine rotate and hflip into transpose, swap
width and height when enabling clock or cclock.

 libavfilter/vf_vpp_qsv.c | 95 +++-
 1 file changed, 93 insertions(+), 2 deletions(-)

diff --git a/libavfilter/vf_vpp_qsv.c b/libavfilter/vf_vpp_qsv.c
index 41a9f38962..834eb87073 100644
--- a/libavfilter/vf_vpp_qsv.c
+++ b/libavfilter/vf_vpp_qsv.c
@@ -36,12 +36,15 @@
 #include "libavformat/avformat.h"
 
 #include "qsvvpp.h"
+#include "transpose.h"
 
 #define OFFSET(x) offsetof(VPPContext, x)
 #define FLAGS (AV_OPT_FLAG_VIDEO_PARAM | AV_OPT_FLAG_FILTERING_PARAM)
 
 /* number of video enhancement filters */
-#define ENH_FILTERS_COUNT (5)
+#define ENH_FILTERS_COUNT (7)
+#define QSV_HAVE_ROTATION  QSV_VERSION_ATLEAST(1, 17)
+#define QSV_HAVE_MIRRORING QSV_VERSION_ATLEAST(1, 19)
 
 typedef struct VPPContext{
 const AVClass *class;
@@ -54,6 +57,8 @@ typedef struct VPPContext{
 mfxExtVPPDenoise denoise_conf;
 mfxExtVPPDetail detail_conf;
 mfxExtVPPProcAmp procamp_conf;
+mfxExtVPPRotation rotation_conf;
+mfxExtVPPMirroring mirroring_conf;
 
 int out_width;
 int out_height;
@@ -70,6 +75,10 @@ typedef struct VPPContext{
 int crop_x;
 int crop_y;
 
+int transpose;
+int rotate; /* rotate angle : [0, 90, 180, 270] */
+int hflip;  /* flip mode : 0 = off, 1 = HORIZONTAL flip */
+
 /* param for the procamp */
 intprocamp;/* enable procamp */
 float  hue;
@@ -95,6 +104,15 @@ static const AVOption options[] = {
 { "contrast","ProcAmp contrast", OFFSET(contrast),
AV_OPT_TYPE_FLOAT,{ .dbl = 1.0 }, 0.0, 10.0, .flags = FLAGS},
 { "brightness",  "ProcAmp brightness",   OFFSET(brightness),  
AV_OPT_TYPE_FLOAT,{ .dbl = 0.0 }, -100.0, 100.0, .flags = FLAGS},
 
+{ "transpose",  "set transpose direction",   OFFSET(transpose),   
AV_OPT_TYPE_INT,  { .i64 = -1 }, -1, 6, FLAGS, "transpose"},
+{ "cclock_hflip",  "rotate counter-clockwise with horizontal flip",  
0, AV_OPT_TYPE_CONST, { .i64 = TRANSPOSE_CCLOCK_FLIP }, .flags=FLAGS, .unit = 
"transpose" },
+{ "clock", "rotate clockwise",   
0, AV_OPT_TYPE_CONST, { .i64 = TRANSPOSE_CLOCK   }, .flags=FLAGS, .unit = 
"transpose" },
+{ "cclock","rotate counter-clockwise",   
0, AV_OPT_TYPE_CONST, { .i64 = TRANSPOSE_CCLOCK  }, .flags=FLAGS, .unit = 
"transpose" },
+{ "clock_hflip",   "rotate clockwise with horizontal flip",  
0, AV_OPT_TYPE_CONST, { .i64 = TRANSPOSE_CLOCK_FLIP  }, .flags=FLAGS, .unit = 
"transpose" },
+{ "reversal",  "rotate by half-turn",
0, AV_OPT_TYPE_CONST, { .i64 = TRANSPOSE_REVERSAL}, .flags=FLAGS, .unit = 
"transpose" },
+{ "hflip", "flip horizontally",  
0, AV_OPT_TYPE_CONST, { .i64 = TRANSPOSE_HFLIP   }, .flags=FLAGS, .unit = 
"transpose" },
+{ "vflip", "flip vertically",
0, AV_OPT_TYPE_CONST, { .i64 = TRANSPOSE_VFLIP   }, .flags=FLAGS, .unit = 
"transpose" },
+
 { "cw",   "set the width crop area expression",   OFFSET(cw), 
AV_OPT_TYPE_STRING, { .str = "iw" }, CHAR_MIN, CHAR_MAX, FLAGS },
 { "ch",   "set the height crop area expression",  OFFSET(ch), 
AV_OPT_TYPE_STRING, { .str = "ih" }, CHAR_MIN, CHAR_MAX, FLAGS },
 { "cx",   "set the x crop area expression",   OFFSET(cx), 
AV_OPT_TYPE_STRING, { .str = "(in_w-out_w)/2" }, CHAR_MIN, CHAR_MAX, FLAGS },
@@ -322,8 +340,81 @@ static int config_output(AVFilterLink *outlink)
 param.ext_buf[param.num_ext_buf++] = (mfxExtBuffer*)>procamp_conf;
 }
 
+if (vpp->transpose >= 0) {
+switch (vpp->transpose) {
+case TRANSPOSE_CCLOCK_FLIP:
+vpp->rotate = MFX_ANGLE_270;
+vpp->hflip  = MFX_MIRRORING_HORIZONTAL;
+break;
+case TRANSPOSE_CLOCK:
+vpp->rotate = MFX_ANGLE_90;
+vpp->hflip  = MFX_MIRRORING_DISABLED;
+  

Re: [FFmpeg-devel] [PATCH] avcodec/tiff: Add support for recognizing DNG files

2019-03-18 Thread Nick Renieris
Yes, obviously this is not complete. As was said, the DNG spec is huge
and I did bring up this concern in a personal email to Paul a few days
ago.
I was told that:
> 3 months should be enough to finish most of specification, note you work on 
> real world DNG files, so if some feature from spec is not present in any file 
> you have less work to do
which I absolutely agree with.
The context of my contribution in this case is GSoC, so let's talk
about that: Wouldn't it be better if by the end of GSoC, FFmpeg could
open all or most of the DNG files that actually exist out there,
instead of having only specific parts of the spec implemented
thoroughly?

>A design that can only extract one image of many or one stream or one channel. 
>Cannot preserve all information so it fails that simple use case.

> Shouldn't, ideally, these image files be demuxed as two image streams? 
> Perhaps with the "main" image as the first stream.

Ideally, yes of course.
Realistically, I think the images with NewSubFileType != 0 and
NewSubFileType != 4 are of secondary interest to decode, as they are
commonly simply reduced resolution images of their counterparts.
In any case, it will probably not be hard to add once the important
parts are implemented.

> Still wrong, There are DNG images without thumbnails.

I suspected so but didn't have any examples to test with.
I just found one. The following happens if -subimage 1 is used:

[tiff @ 0x7fffe4099180] DNG images are not supported
[tiff @ 0x7fffe4099180] Decoding embedded TIFF thumbnail in DNG image
[tiff @ 0x7fffe4099180] This format is not supported (bpp=14, bppcount=1)

Is this a problem? If so:
I'm still not done reading the spec(s), but as far as I understand it,
there is no way that a DNG image with NewSubFileType != 1 would be in
a standard TIFF format that we can decode right now. Therefore, I
propose a check for this in decode_frame (would also check if dng_mode
is enabled) to prevent the above non-user friendly error from
happening.

I suspect NewSubFileType is not the right way to go though since the
actual image format is not specified with it. I looked at the tags
from some DNGs and I can't narrow it down to any other better field
for this.

Any better ideas? Should I perhaps just let it succeed or fail based
on the existing decoding code, as it does above? The error checking in
that code is the absolute truth of what is actually implemented after
all.

> I've used their libdng for a project. It's a big LGPL library implementing 
> pretty much everything, but no distro really ships it, so it'd have to be 
> embedded or built manually by the user.

Definitely something to consider. Given the posted GSoC project idea,
I assumed it was not possible/preferable for it to be embedded.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [PATCH 3/3] cbs_vp9: Validate sizes when splitting small fragments

2019-03-18 Thread Mark Thompson
---
 libavcodec/cbs_vp9.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/libavcodec/cbs_vp9.c b/libavcodec/cbs_vp9.c
index 237416a06f..cd046afa46 100644
--- a/libavcodec/cbs_vp9.c
+++ b/libavcodec/cbs_vp9.c
@@ -416,6 +416,9 @@ static int cbs_vp9_split_fragment(CodedBitstreamContext 
*ctx,
 uint8_t superframe_header;
 int err;
 
+if (frag->data_size == 0)
+return 0;
+
 // Last byte in the packet.
 superframe_header = frag->data[frag->data_size - 1];
 
@@ -427,6 +430,12 @@ static int cbs_vp9_split_fragment(CodedBitstreamContext 
*ctx,
 
 index_size = 2 + (((superframe_header & 0x18) >> 3) + 1) *
   ((superframe_header & 0x07) + 1);
+if (index_size > frag->data_size) {
+av_log(ctx->log_ctx, AV_LOG_ERROR, "Superframe index (%"
+   SIZE_SPECIFIER" bytes) is larger than whole frame (%"
+   SIZE_SPECIFIER" bytes).\n", index_size, frag->data_size);
+return AVERROR_INVALIDDATA;
+}
 
 err = init_get_bits(, frag->data + frag->data_size - index_size,
 8 * index_size);
-- 
2.19.2

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


[FFmpeg-devel] [PATCH 2/3] lavc/qsvdec: Add VP9 decoder support

2019-03-18 Thread Mark Thompson
From: Zhong Li 

VP9 decoder is supported on Intel kabyLake+ platforms with MSDK Version 1.19+

Signed-off-by: Zhong Li 
---
Tested on Coffee Lake.


 Changelog |  1 +
 configure |  6 ++
 libavcodec/allcodecs.c|  1 +
 libavcodec/qsv.c  |  5 +
 libavcodec/qsvdec_other.c | 31 ++-
 5 files changed, 43 insertions(+), 1 deletion(-)

diff --git a/Changelog b/Changelog
index 4d80e5b54f..bcb00f0a03 100644
--- a/Changelog
+++ b/Changelog
@@ -19,6 +19,7 @@ version :
 - ARBC decoder
 - libaribb24 based ARIB STD-B24 caption support (profiles A and C)
 - Support decoding of HEVC 4:4:4 content in nvdec and cuviddec
+- Intel libmfx VP9 decoding
 
 
 version 4.1:
diff --git a/configure b/configure
index 938ff10da5..2d4e7cedaf 100755
--- a/configure
+++ b/configure
@@ -3060,6 +3060,8 @@ vp8_v4l2m2m_decoder_deps="v4l2_m2m vp8_v4l2_m2m"
 vp8_v4l2m2m_encoder_deps="v4l2_m2m vp8_v4l2_m2m"
 vp9_cuvid_decoder_deps="cuvid"
 vp9_mediacodec_decoder_deps="mediacodec"
+vp9_qsv_decoder_deps="MFX_CODEC_VP9"
+vp9_qsv_decoder_select="qsvdec"
 vp9_rkmpp_decoder_deps="rkmpp"
 vp9_vaapi_encoder_deps="VAEncPictureParameterBufferVP9"
 vp9_vaapi_encoder_select="vaapi_encode"
@@ -6172,6 +6174,10 @@ enabled liblensfun&& require_pkg_config 
liblensfun lensfun lensfun.h lf_
 # can find the libraries and headers through other means.
 enabled libmfx&& { check_pkg_config libmfx libmfx "mfx/mfxvideo.h" 
MFXInit ||
{ require libmfx "mfx/mfxvideo.h" MFXInit 
"-llibmfx $advapi32_extralibs" && warn "using libmfx without pkg-config"; } }
+if enabled libmfx; then
+   check_cc MFX_CODEC_VP9 "mfx/mfxvp9.h mfx/mfxstructures.h" "MFX_CODEC_VP9"
+fi
+
 enabled libmodplug&& require_pkg_config libmodplug libmodplug 
libmodplug/modplug.h ModPlug_Load
 enabled libmp3lame&& require "libmp3lame >= 3.98.3" lame/lame.h 
lame_set_VBR_quality -lmp3lame $libm_extralibs
 enabled libmysofa && { check_pkg_config libmysofa libmysofa mysofa.h 
mysofa_load ||
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index b26aeca239..c539792fa2 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -775,6 +775,7 @@ extern AVCodec ff_vp8_v4l2m2m_encoder;
 extern AVCodec ff_vp8_vaapi_encoder;
 extern AVCodec ff_vp9_cuvid_decoder;
 extern AVCodec ff_vp9_mediacodec_decoder;
+extern AVCodec ff_vp9_qsv_decoder;
 extern AVCodec ff_vp9_vaapi_encoder;
 
 // The iterate API is not usable with ossfuzz due to the excessive size of 
binaries created
diff --git a/libavcodec/qsv.c b/libavcodec/qsv.c
index bb0d79588c..389fdcff41 100644
--- a/libavcodec/qsv.c
+++ b/libavcodec/qsv.c
@@ -60,6 +60,11 @@ int ff_qsv_codec_id_to_mfx(enum AVCodecID codec_id)
 #endif
 case AV_CODEC_ID_MJPEG:
 return MFX_CODEC_JPEG;
+#if QSV_VERSION_ATLEAST(1, 19)
+case AV_CODEC_ID_VP9:
+return MFX_CODEC_VP9;
+#endif
+
 default:
 break;
 }
diff --git a/libavcodec/qsvdec_other.c b/libavcodec/qsvdec_other.c
index 03251d2c85..d7a6d79f63 100644
--- a/libavcodec/qsvdec_other.c
+++ b/libavcodec/qsvdec_other.c
@@ -1,5 +1,5 @@
 /*
- * Intel MediaSDK QSV based MPEG-2, VC-1 and VP8 decoders
+ * Intel MediaSDK QSV based MPEG-2, VC-1, VP8 and VP9 decoders
  *
  * copyright (c) 2015 Anton Khirnov
  *
@@ -255,3 +255,32 @@ AVCodec ff_vp8_qsv_decoder = {
 .wrapper_name   = "qsv",
 };
 #endif
+
+#if CONFIG_VP9_QSV_DECODER
+static const AVClass vp9_qsv_class = {
+.class_name = "vp9_qsv",
+.item_name  = av_default_item_name,
+.option = options,
+.version= LIBAVUTIL_VERSION_INT,
+};
+
+AVCodec ff_vp9_qsv_decoder = {
+.name   = "vp9_qsv",
+.long_name  = NULL_IF_CONFIG_SMALL("VP9 video (Intel Quick Sync Video 
acceleration)"),
+.priv_data_size = sizeof(QSVOtherContext),
+.type   = AVMEDIA_TYPE_VIDEO,
+.id = AV_CODEC_ID_VP9,
+.init   = qsv_decode_init,
+.decode = qsv_decode_frame,
+.flush  = qsv_decode_flush,
+.close  = qsv_decode_close,
+.capabilities   = AV_CODEC_CAP_DELAY | AV_CODEC_CAP_DR1 | 
AV_CODEC_CAP_AVOID_PROBING | AV_CODEC_CAP_HYBRID,
+.priv_class = _qsv_class,
+.pix_fmts   = (const enum AVPixelFormat[]){ AV_PIX_FMT_NV12,
+AV_PIX_FMT_P010,
+AV_PIX_FMT_QSV,
+AV_PIX_FMT_NONE },
+.hw_configs = ff_qsv_hw_configs,
+.wrapper_name   = "qsv",
+};
+#endif
-- 
2.19.2

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


[FFmpeg-devel] [PATCH 1/3] vp9_parser: Return stream properties

2019-03-18 Thread Mark Thompson
Rewrites the parser entirely, using CBS for header parsing.  A new
entrypoint to the CBS code is added to avoid any copy overhead.
---
On 18/03/2019 03:22, Li, Zhong wrote:
> If you think that case can be resolved for VP9 parser, could you please 
> provide more details?

Since all the infrastructure is already available it seemed easier to just do 
it than to try to explain it all needs to fit together.

- Mark


 libavcodec/cbs_vp9.c|  62 ++
 libavcodec/cbs_vp9.h|  12 +
 libavcodec/vp9_parser.c | 113 +++-
 3 files changed, 152 insertions(+), 35 deletions(-)

diff --git a/libavcodec/cbs_vp9.c b/libavcodec/cbs_vp9.c
index 0b5f137ed8..237416a06f 100644
--- a/libavcodec/cbs_vp9.c
+++ b/libavcodec/cbs_vp9.c
@@ -690,3 +690,65 @@ const CodedBitstreamType ff_cbs_type_vp9 = {
 
 .close = _vp9_close,
 };
+
+int ff_cbs_vp9_parse_headers(CodedBitstreamContext *ctx,
+ VP9RawFrameHeader *header,
+ const uint8_t *data, size_t data_size)
+{
+GetBitContext gbc;
+uint8_t superframe_header;
+int err;
+
+if (data_size < 1)
+return AVERROR_INVALIDDATA;
+
+superframe_header = data[data_size - 1];
+if ((superframe_header & 0xe0) == 0xc0) {
+VP9RawSuperframeIndex sfi;
+size_t index_size, pos;
+int i;
+
+index_size = 2 + (((superframe_header & 0x18) >> 3) + 1) *
+  ((superframe_header & 0x07) + 1);
+if (index_size > data_size)
+return AVERROR_INVALIDDATA;
+
+err = init_get_bits(, data + data_size - index_size,
+8 * index_size);
+if (err < 0)
+return err;
+
+err = cbs_vp9_read_superframe_index(ctx, , );
+if (err < 0)
+return err;
+
+pos = 0;
+for (i = 0; i <= sfi.frames_in_superframe_minus_1; i++) {
+if (pos + sfi.frame_sizes[i] + index_size > data_size)
+return AVERROR_INVALIDDATA;
+
+err = init_get_bits(, data + pos,
+8 * sfi.frame_sizes[i]);
+if (err < 0)
+return err;
+
+memset(header, 0, sizeof(*header));
+err = cbs_vp9_read_uncompressed_header(ctx, , header);
+if (err < 0)
+return err;
+
+pos += sfi.frame_sizes[i];
+}
+
+} else {
+err = init_get_bits(, data, 8 * data_size);
+if (err < 0)
+return err;
+
+err = cbs_vp9_read_uncompressed_header(ctx, , header);
+if (err < 0)
+return err;
+}
+
+return 0;
+}
diff --git a/libavcodec/cbs_vp9.h b/libavcodec/cbs_vp9.h
index 4c9b2f880d..0b7e8dd71b 100644
--- a/libavcodec/cbs_vp9.h
+++ b/libavcodec/cbs_vp9.h
@@ -214,4 +214,16 @@ typedef struct CodedBitstreamVP9Context {
 } CodedBitstreamVP9Context;
 
 
+/**
+ * Entrypoint for VP9 parser.
+ *
+ * Parses headers only in a VP9 frame, and does not require refcounting.
+ *
+ * The data may contain multiple frames in a superframe; all will be parsed
+ * but the returned information will be for the final frame.
+ */
+int ff_cbs_vp9_parse_headers(CodedBitstreamContext *ctx,
+ VP9RawFrameHeader *header,
+ const uint8_t *data, size_t data_size);
+
 #endif /* AVCODEC_CBS_VP9_H */
diff --git a/libavcodec/vp9_parser.c b/libavcodec/vp9_parser.c
index c957a75667..5dd4d8d434 100644
--- a/libavcodec/vp9_parser.c
+++ b/libavcodec/vp9_parser.c
@@ -1,8 +1,5 @@
 /*
- * VP9 compatible video decoder
- *
- * Copyright (C) 2013 Ronald S. Bultje 
- * Copyright (C) 2013 Clément Bœsch 
+ * VP9 parser
  *
  * This file is part of FFmpeg.
  *
@@ -21,50 +18,96 @@
  * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
  */
 
-#include "libavutil/intreadwrite.h"
-#include "libavcodec/get_bits.h"
+#include "libavutil/avassert.h"
+#include "cbs.h"
+#include "cbs_vp9.h"
 #include "parser.h"
 
-static int parse(AVCodecParserContext *ctx,
- AVCodecContext *avctx,
- const uint8_t **out_data, int *out_size,
- const uint8_t *data, int size)
+typedef struct VP9ParserContext {
+CodedBitstreamContext *cbc;
+VP9RawFrameHeader frame_header;
+} VP9ParserContext;
+
+static const enum AVPixelFormat vp9_pix_fmts[3][2][2] = {
+{ // 8-bit.
+{ AV_PIX_FMT_YUV444P, AV_PIX_FMT_YUV440P },
+{ AV_PIX_FMT_YUV422P, AV_PIX_FMT_YUV420P },
+},
+{ // 10-bit.
+{ AV_PIX_FMT_YUV444P10, AV_PIX_FMT_YUV440P10 },
+{ AV_PIX_FMT_YUV422P10, AV_PIX_FMT_YUV420P10 },
+},
+{ // 12-bit.
+{ AV_PIX_FMT_YUV444P12, AV_PIX_FMT_YUV440P12 },
+{ AV_PIX_FMT_YUV422P12, AV_PIX_FMT_YUV420P12 },
+},
+};
+
+static int vp9_parser_parse(AVCodecParserContext *ctx,
+AVCodecContext *avctx,
+

Re: [FFmpeg-devel] [PATCH] libavformat/movenc: mov: added subtitle codec tags to codec tag list

2019-03-18 Thread James Almer
On 2/25/2019 7:50 AM, Paweł Wegner wrote:
> This fixes avformat_query_codec incorrectly returning 0 for
> mov container and mov_text subtitles.
> 
> Signed-off-by: Paweł Wegner 
> ---
>  libavformat/movenc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavformat/movenc.c b/libavformat/movenc.c
> index 77943304b5..8969d5b170 100644
> --- a/libavformat/movenc.c
> +++ b/libavformat/movenc.c
> @@ -6858,7 +6858,7 @@ AVOutputFormat ff_mov_muxer = {
>  .deinit= mov_free,
>  .flags = AVFMT_GLOBALHEADER | AVFMT_ALLOW_FLUSH | 
> AVFMT_TS_NEGATIVE,
>  .codec_tag = (const AVCodecTag* const []){
> -ff_codec_movvideo_tags, ff_codec_movaudio_tags, 0
> +ff_codec_movvideo_tags, ff_codec_movaudio_tags, 
> ff_codec_movsubtitle_tags, 0
>  },
>  .check_bitstream   = mov_check_bitstream,
>  .priv_class= _muxer_class,

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


Re: [FFmpeg-devel] [PATCH] pngdec: add ability to check chunk CRC

2019-03-18 Thread Michael Niedermayer
On Fri, Mar 08, 2019 at 03:15:40PM +0100, Lynne wrote:
> 7 Mar 2019, 21:22 by mich...@niedermayer.cc:
> 
> > On Thu, Mar 07, 2019 at 07:26:32PM +0100, Lynne wrote:
> >
> >> By default now, if AV_EF_CRCCHECK or AV_EF_IGNORE_ERR are enabled the 
> >> decoder
> >> will skip the chunk and carry on with the next one. This should make the   
> >> 
> >> decoder able to decode more corrupt files because the functions which 
> >> decode
> >> individual chunks will very likely error out if fed invalid data and stop 
> >> the
> >> decoding of the entire image.
> >> Should this be made default? CRC verification doesn't take long even for 
> >> very
> >> large files.  
> >> Also fix the length check for chunk size. It needs to take into account the
> >> 4 byte tag as well as the 4 byte CRC.
> >>
> >> pngdec.c |   19 ++-
> >>  1 file changed, 18 insertions(+), 1 deletion(-)
> >> 4255c91468cee2bc2fa757fae69762ff5ee5774a  
> >> 0001-pngdec-add-ability-to-check-chunk-CRC.patch
> >> From 7aff99d12faf557753c5ee860a9672c7a09a26e3 Mon Sep 17 00:00:00 2001
> >> From: Lynne <>> d...@lynne.ee >> >
> >> Date: Thu, 7 Mar 2019 18:15:23 +
> >> Subject: [PATCH] pngdec: add ability to check chunk CRC
> >>
> >> By default now, if AV_EF_CRCCHECK or AV_EF_IGNORE_ERR are enabled the 
> >> decoder
> >> will skip the chunk and carry on with the next one. This should make the
> >> decoder able to decode more corrupt files because the functions which 
> >> decode
> >> individual chunks will very likely error out if fed invalid data and stop 
> >> the
> >> decoding of the entire image.
> >> Should this be made default? CRC verification doesn't take long even for 
> >> very
> >> large files.
> >>
> >
> > i would tend toward enabling it by default but maybe first post some
> > numbers of how much this changes decode time 
> >
> 
> For the largest png I found: 
> https://vk.com/doc218587497_437472325?hash=51300ca9ba40f462ac=1bcf9a57b0d989da1f
>  
> 
> 
> There was no increase in decoding time, it took 2.3 seconds on my machine
> with and without -err_detect crccheck.
> 
> With -err_detect crccheck perf reported 2.52% spent in av_crc
> 
> 
> >> Also fix the length check for chunk size. It needs to take into account the
> >> 4 byte tag as well as the 4 byte CRC.
> >>
> >
> > this should be a seperate patch as its unrelated
> >
> 
> removed and attached new patch file
> 
> Maybe always enabling the CRC check isn't worth it since if you download from
> the internet you could either get a full error-free file or an incomplete one
> rather than a corrupt one. Maybe only for torrents with huge png files where
> not all chunks have been downloaded yet, or broken hard drives, but the 
> ignore_err
> flag could be manually enabled in those cases.

>  pngdec.c |   17 +
>  1 file changed, 17 insertions(+)
> 57ccb0b81aeca1e08bc0f1475c048007d7f32c26  
> 0001-pngdec-add-ability-to-check-chunk-CRC.patch
> From b911d3cb36828ad3c910ca6bf8b96a58ce398191 Mon Sep 17 00:00:00 2001
> From: Lynne 
> Date: Thu, 7 Mar 2019 18:15:23 +
> Subject: [PATCH] pngdec: add ability to check chunk CRC
> 
> By default now, if AV_EF_CRCCHECK or AV_EF_IGNORE_ERR are enabled the decoder
> will skip the chunk and carry on with the next one. This should make the
> decoder able to decode more corrupt files because the functions which decode
> individual chunks will very likely error out if fed invalid data and stop the
> decoding of the entire image.
> ---
>  libavcodec/pngdec.c | 17 +
>  1 file changed, 17 insertions(+)
> 
> diff --git a/libavcodec/pngdec.c b/libavcodec/pngdec.c
> index 189bb9a4c1..9743f1cb76 100644
> --- a/libavcodec/pngdec.c
> +++ b/libavcodec/pngdec.c
> @@ -23,6 +23,7 @@
>  
>  #include "libavutil/avassert.h"
>  #include "libavutil/bprint.h"
> +#include "libavutil/crc.h"
>  #include "libavutil/imgutils.h"
>  #include "libavutil/stereo3d.h"
>  #include "libavutil/mastering_display_metadata.h"
> @@ -1169,6 +1170,7 @@ static int handle_p_frame_apng(AVCodecContext *avctx, 
> PNGDecContext *s,
>  static int decode_frame_common(AVCodecContext *avctx, PNGDecContext *s,
> AVFrame *p, AVPacket *avpkt)
>  {
> +const AVCRC *crc_tab = av_crc_get_table(AV_CRC_32_IEEE_LE);
>  AVDictionary **metadatap = NULL;
>  uint32_t tag, length;
>  int decode_next_dat = 0;
> @@ -1203,6 +1205,21 @@ static int decode_frame_common(AVCodecContext *avctx, 
> PNGDecContext *s,
>  ret = AVERROR_INVALIDDATA;
>  goto fail;
>  }
> +if (avctx->err_recognition & (AV_EF_CRCCHECK | AV_EF_IGNORE_ERR)) {

The usage of AV_EF_IGNORE_ERR is incorrect.
the code does the opposite of what the flag means
what the code does is handle errors when the flag says dont


> +uint32_t crc_sig = AV_RB32(s->gb.buffer 

Re: [FFmpeg-devel] [PATCH 1/2] h2645_parse: Propagate NAL header parsing errors

2019-03-18 Thread Derek Buitenhuis
On 18/03/2019 20:44, Michael Niedermayer wrote:
> do you have a sample for h264 ? (or only teh one for hevc) ?

On hand, just HEVC.

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


Re: [FFmpeg-devel] [PATCH] libavdevice/v4l2: Return EAGAIN when receiving a frame of unexpected size

2019-03-18 Thread Alexander Strasser
Hi Nicolas!

On 2019-03-18 00:24 +0100, Nicolas George wrote:
> Alexander Strasser (12019-03-18):
> > I tested the EAGAIN version and it worked. I also tested returning a
> 
> ffmpeg.c uses the non-blocking mode.

That would explain it. I now tested, the FFERROR_REDO approach,
and I think it works fine. As I don't have it available anymore,
I can't test with the device that gave me the errors. So I modified
the code to create the error condition.

Using FFERROR_REDO would work for blocking mode as well as non-blocking,
right?

It handles the error on a lower level inside the libs and doesn't
bubble up to the lib user AFAICT.


> > zero-sized packet, like in the case where V4L flags the data as corrupt,
> > that worked too. See commit 28f20d2ff487aa589643d8f70eaf614b78839685
> > 
> > Do you think the zero-sized packet would be better than returning
> > FFERROR_REDO?
> 
> I think it depends on what happens exactly with that frame? What is the
> partial packet returned? Is there a timestamp? Etc.

As mentioned above I can't dump more data to get a clue. I guess
the frame was just truncated and the timestamps were correct.

As we wouldn't pass on frame data to the user anyway, I would actually
prefer the FFERROR_REDO version.


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


Re: [FFmpeg-devel] [PATCH] libavformat/movenc: mov: added subtitle codec tags to codec tag list

2019-03-18 Thread Paweł Wegner
On Wed, Mar 13, 2019 at 12:08 PM Paweł Wegner 
wrote:

> On Mon, Mar 4, 2019 at 10:52 AM Paweł Wegner 
> wrote:
>
>> On Mon, Mar 4, 2019 at 10:50 AM Paweł Wegner 
>> wrote:
>>
>>> ping
>>>
>>> On Mon, Feb 25, 2019 at 11:50 AM Paweł Wegner 
>>> wrote:
>>>
 This fixes avformat_query_codec incorrectly returning 0 for
 mov container and mov_text subtitles.

 Signed-off-by: Paweł Wegner 
 ---
  libavformat/movenc.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/libavformat/movenc.c b/libavformat/movenc.c
 index 77943304b5..8969d5b170 100644
 --- a/libavformat/movenc.c
 +++ b/libavformat/movenc.c
 @@ -6858,7 +6858,7 @@ AVOutputFormat ff_mov_muxer = {
  .deinit= mov_free,
  .flags = AVFMT_GLOBALHEADER | AVFMT_ALLOW_FLUSH |
 AVFMT_TS_NEGATIVE,
  .codec_tag = (const AVCodecTag* const []){
 -ff_codec_movvideo_tags, ff_codec_movaudio_tags, 0
 +ff_codec_movvideo_tags, ff_codec_movaudio_tags,
 ff_codec_movsubtitle_tags, 0
  },
  .check_bitstream   = mov_check_bitstream,
  .priv_class= _muxer_class,
 --
 2.17.1

 Sorry for top posted ping.
>>
> ping x2
>
ping x3
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] Fix sdp size check on fmtp integer parameters

2019-03-18 Thread Carl Eugen Hoyos
2019-03-18 16:08 GMT+01:00, Olivier Maignial :

> +char * end_ptr = NULL;

Assuming you have to send a new patch anyway,
please make this "char *end_ptr"...

> +long int val = strtol(value, _ptr, 10);

> +if (value[0] == '\n' || end_ptr[0] != '\0')
> +{

... and merge these lines.

Thank you, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] h2645_parse: Fix loglevel for NAL header parsing

2019-03-18 Thread Michael Niedermayer
On Mon, Mar 18, 2019 at 07:19:06PM +, Derek Buitenhuis wrote:
> We don't treat this as an error.
> 
> Signed-off-by: Derek Buitenhuis 
> ---
>  libavcodec/h2645_parse.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavcodec/h2645_parse.c b/libavcodec/h2645_parse.c
> index 942f2c5d71..24658b3dfa 100644
> --- a/libavcodec/h2645_parse.c
> +++ b/libavcodec/h2645_parse.c
> @@ -499,7 +499,7 @@ int ff_h2645_packet_split(H2645Packet *pkt, const uint8_t 
> *buf, int length,
>  ret = h264_parse_nal_header(nal, logctx);
>  if (ret <= 0 || nal->size <= 0 || nal->size_bits <= 0) {
>  if (ret < 0) {
> -av_log(logctx, AV_LOG_ERROR, "Invalid NAL unit %d, 
> skipping.\n",
> +av_log(logctx, AV_LOG_WARNING, "Invalid NAL unit %d, 
> skipping.\n",
> nal->type);
>  }
>  pkt->nb_nals--;

LGTM

thx

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

No snowflake in an avalanche ever feels responsible. -- Voltaire


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


Re: [FFmpeg-devel] [PATCH] Fix sdp size check on fmtp integer parameters

2019-03-18 Thread Michael Niedermayer
On Mon, Mar 18, 2019 at 04:08:40PM +0100, Olivier Maignial wrote:
> RFC-4566 do not give any limit of size on interger parameters given in fmtp 
> line.
> By reading some more RFCs it is possible to find examples where some integers 
> parameters are greater than 32 (see RFC-6416, 7.4)
> ---
>  libavformat/rtpdec_mpeg4.c | 17 +
>  1 file changed, 13 insertions(+), 4 deletions(-)
> 
> diff --git a/libavformat/rtpdec_mpeg4.c b/libavformat/rtpdec_mpeg4.c
> index 994ab49..4b86f4a 100644
> --- a/libavformat/rtpdec_mpeg4.c
> +++ b/libavformat/rtpdec_mpeg4.c
> @@ -289,15 +289,24 @@ static int parse_fmtp(AVFormatContext *s,
>  for (i = 0; attr_names[i].str; ++i) {
>  if (!av_strcasecmp(attr, attr_names[i].str)) {
>  if (attr_names[i].type == ATTR_NAME_TYPE_INT) {
> -int val = atoi(value);
> -if (val > 32) {
> +char * end_ptr = NULL;
> +long int val = strtol(value, _ptr, 10);
> +if (value[0] == '\n' || end_ptr[0] != '\0')
> +{
>  av_log(s, AV_LOG_ERROR,
> -   "The %s field size is invalid (%d)\n",
> +   "The %s field value is not a number (%s)\n",
> +   attr, value);
> +return AVERROR_INVALIDDATA;
> +}
> +
> +if (val > INT_MAX || val < INT_MIN) {
> +av_log(s, AV_LOG_ERROR,
> +   "The %s field size is invalid (%ld)\n",
> attr, val);
>  return AVERROR_INVALIDDATA;
>  }

does this also work as intended if int is 64bit ? (it can be)


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

In a rich man's house there is no place to spit but his face.
-- Diogenes of Sinope


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


Re: [FFmpeg-devel] [PATCH 1/2] h2645_parse: Propagate NAL header parsing errors

2019-03-18 Thread Michael Niedermayer
On Mon, Mar 18, 2019 at 03:46:09PM +, Derek Buitenhuis wrote:
> If we don't propagate these errors, h264dec and hevcdec can get up to all 
> sorts of
> weirdness, especially threaded, while trying to continue on with things they 
> shouldn't.
> Can cause stuff like:

do you have a sample for h264 ? (or only teh one for hevc) ?

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

No snowflake in an avalanche ever feels responsible. -- Voltaire


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


Re: [FFmpeg-devel] [PATCH] h2645_parse: Fix loglevel for NAL header parsing

2019-03-18 Thread James Almer
On 3/18/2019 4:19 PM, Derek Buitenhuis wrote:
> We don't treat this as an error.
> 
> Signed-off-by: Derek Buitenhuis 
> ---
>  libavcodec/h2645_parse.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavcodec/h2645_parse.c b/libavcodec/h2645_parse.c
> index 942f2c5d71..24658b3dfa 100644
> --- a/libavcodec/h2645_parse.c
> +++ b/libavcodec/h2645_parse.c
> @@ -499,7 +499,7 @@ int ff_h2645_packet_split(H2645Packet *pkt, const uint8_t 
> *buf, int length,
>  ret = h264_parse_nal_header(nal, logctx);
>  if (ret <= 0 || nal->size <= 0 || nal->size_bits <= 0) {
>  if (ret < 0) {
> -av_log(logctx, AV_LOG_ERROR, "Invalid NAL unit %d, 
> skipping.\n",
> +av_log(logctx, AV_LOG_WARNING, "Invalid NAL unit %d, 
> skipping.\n",
> nal->type);
>  }
>  pkt->nb_nals--;

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


[FFmpeg-devel] [PATCH] avcodec/hevcdec: decode at most one slice reporting being the first in the picture

2019-03-18 Thread James Almer
Fixes deadlocks when decoding packets containing more than one of the 
aforementioned
slices when using frame threads.

Signed-off-by: James Almer 
---
See the discussion in the 
http://ffmpeg.org/pipermail/ffmpeg-devel/2019-March/241192.html
thread.

Alternative fixes that don't discard the second slice in this scenario welcome.

 libavcodec/hevcdec.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
index 967f8f1def..86adab0ae1 100644
--- a/libavcodec/hevcdec.c
+++ b/libavcodec/hevcdec.c
@@ -2927,6 +2927,10 @@ static int decode_nal_unit(HEVCContext *s, const 
H2645NAL *nal)
 }
 
 if (s->sh.first_slice_in_pic_flag) {
+if (s->ref) {
+av_log(s->avctx, AV_LOG_ERROR, "Two slices reporting being the 
first in the same frame.\n");
+goto fail;
+}
 if (s->max_ra == INT_MAX) {
 if (s->nal_unit_type == HEVC_NAL_CRA_NUT || IS_BLA(s)) {
 s->max_ra = s->poc;
-- 
2.21.0

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


Re: [FFmpeg-devel] [PATCH 1/2] h2645_parse: Propagate NAL header parsing errors

2019-03-18 Thread Derek Buitenhuis
On 18/03/2019 18:38, James Almer wrote:
> So, what i'm seeing here is two slice NALs in the same packet (which
> means processed in the same decode_nal_units() loop in hevcdec.c)
> reporting being the "first slice segment in the pic". And that's
> seemingly making the threading logic shit itself.

[...]

> In between them are two NALs, both with valid starting codes but invalid
> data (first bit is 1 when it's a bitstream requirement for it to be 0),
> but they ultimately have nothing to do with the issue in this file. Your
> patch works around this simply because it aborts the NAL splitting
> before it gets to the second slice NAL, and the whole packet gets discarded.

Yes, this is correct, and arguably also not a wrong solution, just 'less good'
for broken files.

> This is among other things a muxing mistake, since if you remux this
> into raw hevc (ffmpeg -i nal_header_deadlock.mp4 -c:v copy -an
> nal_header_deadlock.hevc) and try to decode that, the hevc parser will
> split it into proper packets with one slice/pic NAL each and the
> deadlock will not happen (see hevc_find_frame_end() in hevc_parser.c).

Yes, very obviously so, but shouldn't explode the parser/decoder. 

> The following change fixes this for me by preventing the decoder from
> trying to decode more than one "first" slice for the same frame:

Fixes it for me, too, and makes sense.

>> diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
>> index 967f8f1def..9492108c77 100644
>> --- a/libavcodec/hevcdec.c
>> +++ b/libavcodec/hevcdec.c
>> @@ -2927,6 +2927,10 @@ static int decode_nal_unit(HEVCContext *s, const 
>> H2645NAL *nal)
>>  }
>>
>>  if (s->sh.first_slice_in_pic_flag) {
>> +if (s->ref) {
>> +av_log(s->avctx, AV_LOG_ERROR, "Two slices reporting being 
>> the first in the picture.\n");
>> +goto fail;
>> +}
>>  if (s->max_ra == INT_MAX) {
>>  if (s->nal_unit_type == HEVC_NAL_CRA_NUT || IS_BLA(s)) {
>>  s->max_ra = s->poc;

[...]

> But it will however discard the second slice, despite its only apparent
> problem being showing up in the wrong packet, so it's probably still not
> ideal.

Not deadlocking is more ideal than not. I'm not particularily concerned with 
making
broken files look as best as possible, myself, but I know this sentiment is not
shared around here.

I'm content with it as-is, unless someone can offer a better one.

> Another solution would be to enable the parser for mp4 input, so the
> packetization in the input will be ignored, but that'll slow down
> demuxing for every single file.

Agree this would be a poor solution...

> Someone else that knows hevc and/or threading might want to look at this
> and fix this in a better way.

Does anyone? I'm not sure anyone still around could be considered an expert on
the HEVC decoder...

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


[FFmpeg-devel] [PATCH] h2645_parse: Fix loglevel for NAL header parsing

2019-03-18 Thread Derek Buitenhuis
We don't treat this as an error.

Signed-off-by: Derek Buitenhuis 
---
 libavcodec/h2645_parse.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/h2645_parse.c b/libavcodec/h2645_parse.c
index 942f2c5d71..24658b3dfa 100644
--- a/libavcodec/h2645_parse.c
+++ b/libavcodec/h2645_parse.c
@@ -499,7 +499,7 @@ int ff_h2645_packet_split(H2645Packet *pkt, const uint8_t 
*buf, int length,
 ret = h264_parse_nal_header(nal, logctx);
 if (ret <= 0 || nal->size <= 0 || nal->size_bits <= 0) {
 if (ret < 0) {
-av_log(logctx, AV_LOG_ERROR, "Invalid NAL unit %d, 
skipping.\n",
+av_log(logctx, AV_LOG_WARNING, "Invalid NAL unit %d, 
skipping.\n",
nal->type);
 }
 pkt->nb_nals--;
-- 
2.20.1

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


[FFmpeg-devel] [PATCH] Fix sdp size check on fmtp integer parameters

2019-03-18 Thread Olivier Maignial
RFC-4566 do not give any limit of size on interger parameters given in fmtp 
line.
By reading some more RFCs it is possible to find examples where some integers 
parameters are greater than 32 (see RFC-6416, 7.4)
---
 libavformat/rtpdec_mpeg4.c | 17 +
 1 file changed, 13 insertions(+), 4 deletions(-)

diff --git a/libavformat/rtpdec_mpeg4.c b/libavformat/rtpdec_mpeg4.c
index 994ab49..4b86f4a 100644
--- a/libavformat/rtpdec_mpeg4.c
+++ b/libavformat/rtpdec_mpeg4.c
@@ -289,15 +289,24 @@ static int parse_fmtp(AVFormatContext *s,
 for (i = 0; attr_names[i].str; ++i) {
 if (!av_strcasecmp(attr, attr_names[i].str)) {
 if (attr_names[i].type == ATTR_NAME_TYPE_INT) {
-int val = atoi(value);
-if (val > 32) {
+char * end_ptr = NULL;
+long int val = strtol(value, _ptr, 10);
+if (value[0] == '\n' || end_ptr[0] != '\0')
+{
 av_log(s, AV_LOG_ERROR,
-   "The %s field size is invalid (%d)\n",
+   "The %s field value is not a number (%s)\n",
+   attr, value);
+return AVERROR_INVALIDDATA;
+}
+
+if (val > INT_MAX || val < INT_MIN) {
+av_log(s, AV_LOG_ERROR,
+   "The %s field size is invalid (%ld)\n",
attr, val);
 return AVERROR_INVALIDDATA;
 }
 *(int *)((char *)data+
-attr_names[i].offset) = val;
+attr_names[i].offset) = (int) val;
 } else if (attr_names[i].type == ATTR_NAME_TYPE_STR) {
 char *val = av_strdup(value);
 if (!val)
-- 
2.7.4

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


Re: [FFmpeg-devel] [PATCH v3 3/6] lavc/qsvdec: Replace current parser with MFXVideoDECODE_DecodeHeader()

2019-03-18 Thread Gurulev, Dmitry
> -Original Message-
> From: Rogozhkin, Dmitry V
> Sent: Saturday, March 16, 2019 4:18 AM
> To: Li, Zhong ; ffmpeg-devel@ffmpeg.org; Gurulev, Dmitry
> 
> Subject: Re: [FFmpeg-devel] [PATCH v3 3/6] lavc/qsvdec: Replace current parser
> with MFXVideoDECODE_DecodeHeader()
> 
> On Mon, 2019-03-11 at 17:23 +0800, Li, Zhong wrote:
> > > -Original Message-
> > > From: Rogozhkin, Dmitry V
> > > Sent: Saturday, March 9, 2019 8:48 AM
> > > To: ffmpeg-devel@ffmpeg.org
> > > Cc: Li, Zhong 
> > > Subject: Re: [FFmpeg-devel] [PATCH v3 3/6] lavc/qsvdec: Replace
> > > current parser with MFXVideoDECODE_DecodeHeader()
> > >
> > > On Fri, 2019-03-08 at 15:40 +0800, Zhong Li wrote:
> > > > Using MSDK parser can improve qsv decoder pass rate in some cases
> > > > (E.g:
> > > > sps declares a wrong level_idc, smaller than it should be).
> > > > And it is necessary for adding new qsv decoders such as MJPEG and
> > > > VP9
> > > > since current parser can't provide enough information.
> > > > Actually using MFXVideoDECODE_DecodeHeader() was disscussed at
> > > > https://ffmpeg.org/pipermail/ffmpeg-devel/2015-July/175734.html
> > > > and
> > > > merged as commit 1acb19d, but was overwritten when merged libav
> > > > patches (commit: 1f26a23) without any explain.
> > > >
> > > > v2: split decode header from decode_init, and call it for
> > > > everyframe to detect format/resoultion change. It can fix some
> > > > regression issues such as hevc 10bits decoding.
> > > >
> > > > Signed-off-by: Zhong Li 
> > > > ---
> > > >  libavcodec/qsvdec.c   | 172 --
> > > > 
> > > > 
> > > >  libavcodec/qsvdec.h   |   2 +
> > > >  libavcodec/qsvdec_h2645.c |   1 +
> > > >  libavcodec/qsvdec_other.c |   1 +
> > > >  4 files changed, 93 insertions(+), 83 deletions(-)
> > > >
> > > > diff --git a/libavcodec/qsvdec.c b/libavcodec/qsvdec.c index
> > > > 4a0be811fb..b78026e14d 100644
> > > > --- a/libavcodec/qsvdec.c
> > > > +++ b/libavcodec/qsvdec.c
> > > > @@ -120,19 +120,17 @@ static inline unsigned int
> > > > qsv_fifo_size(const
> > > > AVFifoBuffer* fifo)
> > > >  return av_fifo_size(fifo) / qsv_fifo_item_size();
> > > >  }
> > > >
> > > > -static int qsv_decode_init(AVCodecContext *avctx, QSVContext *q)
> > > > +static int qsv_decode_preinit(AVCodecContext *avctx, QSVContext
> > > > *q,
> > > > enum AVPixelFormat *pix_fmts, mfxVideoParam *param)
> > > >  {
> > > > -const AVPixFmtDescriptor *desc;
> > > >  mfxSession session = NULL;
> > > >  int iopattern = 0;
> > > > -mfxVideoParam param = { 0 };
> > > > -int frame_width  = avctx->coded_width;
> > > > -int frame_height = avctx->coded_height;
> > > >  int ret;
> > > >
> > > > -desc = av_pix_fmt_desc_get(avctx->sw_pix_fmt);
> > > > -if (!desc)
> > > > -return AVERROR_BUG;
> > > > +ret = ff_get_format(avctx, pix_fmts);
> > > > +if (ret < 0) {
> > > > +q->orig_pix_fmt = avctx->pix_fmt = AV_PIX_FMT_NONE;
> > > > +return ret;
> > > > +}
> > > >
> > > >  if (!q->async_fifo) {
> > > >  q->async_fifo = av_fifo_alloc(q->async_depth *
> > > > qsv_fifo_item_size()); @@ -170,48 +168,72 @@ static int
> > > > qsv_decode_init(AVCodecContext *avctx, QSVContext *q)
> > > >  return ret;
> > > >  }
> > > >
> > > > -ret = ff_qsv_codec_id_to_mfx(avctx->codec_id);
> > > > -if (ret < 0)
> > > > -return ret;
> > > > +param->IOPattern   = q->iopattern;
> > > > +param->AsyncDepth  = q->async_depth;
> > > > +param->ExtParam= q->ext_buffers;
> > > > +param->NumExtParam = q->nb_ext_buffers;
> > > >
> > > > -param.mfx.CodecId  = ret;
> > > > -param.mfx.CodecProfile = ff_qsv_profile_to_mfx(avctx-
> > > > >codec_id,
> > > > avctx->profile);
> > > > -param.mfx.CodecLevel   = avctx->level ==
> > >
> > > FF_LEVEL_UNKNOWN ?
> > > > MFX_LEVEL_UNKNOWN : avctx->level;
> > > > -
> > > > -param.mfx.FrameInfo.BitDepthLuma   = desc->comp[0].depth;
> > > > -param.mfx.FrameInfo.BitDepthChroma = desc->comp[0].depth;
> > > > -param.mfx.FrameInfo.Shift  = desc->comp[0].depth >
> > >
> > > 8;
> > > > -param.mfx.FrameInfo.FourCC = q->fourcc;
> > > > -param.mfx.FrameInfo.Width  = frame_width;
> > > > -param.mfx.FrameInfo.Height = frame_height;
> > > > -param.mfx.FrameInfo.ChromaFormat   =
> > >
> > > MFX_CHROMAFORMAT_YUV420;
> > > > -
> > > > -switch (avctx->field_order) {
> > > > -case AV_FIELD_PROGRESSIVE:
> > > > -param.mfx.FrameInfo.PicStruct =
> > >
> > > MFX_PICSTRUCT_PROGRESSIVE;
> > > > -break;
> > > > -case AV_FIELD_TT:
> > > > -param.mfx.FrameInfo.PicStruct =
> > >
> > > MFX_PICSTRUCT_FIELD_TFF;
> > > > -break;
> > > > -case AV_FIELD_BB:
> > > > -param.mfx.FrameInfo.PicStruct =
> > >
> > > MFX_PICSTRUCT_FIELD_BFF;
> > > > -break;
> > > > -default:
> > > > -param.mfx.FrameInfo.PicStruct =
> > >

Re: [FFmpeg-devel] [PATCH v3 3/6] lavc/qsvdec: Replace current parser with MFXVideoDECODE_DecodeHeader()

2019-03-18 Thread Gurulev, Dmitry
> -Original Message-
> From: Rogozhkin, Dmitry V
> Sent: Saturday, March 16, 2019 4:17 AM
> To: Li, Zhong ; ffmpeg-devel@ffmpeg.org; Gurulev, Dmitry
> 
> Subject: Re: [FFmpeg-devel] [PATCH v3 3/6] lavc/qsvdec: Replace current parser
> with MFXVideoDECODE_DecodeHeader()
> 
> On Thu, 2019-03-14 at 19:03 +0800, Li, Zhong wrote:
> > > From: Rogozhkin, Dmitry V
> > > Sent: Tuesday, March 12, 2019 7:37 AM
> > > To: Li, Zhong ; ffmpeg-devel@ffmpeg.org
> > > Subject: Re: [FFmpeg-devel] [PATCH v3 3/6] lavc/qsvdec: Replace
> > > current parser with MFXVideoDECODE_DecodeHeader()
> > >
> > > On Mon, 2019-03-11 at 17:23 +0800, Li, Zhong wrote:
> > > > > -Original Message-
> > > > > From: Rogozhkin, Dmitry V
> > > > > Sent: Saturday, March 9, 2019 8:48 AM
> > > > > To: ffmpeg-devel@ffmpeg.org
> > > > > Cc: Li, Zhong 
> > > > > Subject: Re: [FFmpeg-devel] [PATCH v3 3/6] lavc/qsvdec: Replace
> > > > > current parser with MFXVideoDECODE_DecodeHeader()
> > > > >
> > > > > On Fri, 2019-03-08 at 15:40 +0800, Zhong Li wrote:
> > > > > > Using MSDK parser can improve qsv decoder pass rate in some
> > > > > > cases
> > > > > > (E.g:
> > > > > > sps declares a wrong level_idc, smaller than it should be).
> > > > > > And it is necessary for adding new qsv decoders such as MJPEG
> > > > > > and
> > > > > > VP9
> > > > > > since current parser can't provide enough information.
> > > > > > Actually using MFXVideoDECODE_DecodeHeader() was disscussed at
> > > > > > https://ffmpeg.org/pipermail/ffmpeg-devel/2015-July/175734.ht
> > > > > > ml
> > > > > > and
> > > > > > merged as commit 1acb19d, but was overwritten when merged
> > > > > > libav patches (commit: 1f26a23) without any explain.
> > > > > >
> > > > > > v2: split decode header from decode_init, and call it for
> > > > > > everyframe to detect format/resoultion change. It can fix some
> > > > > > regression issues such as hevc 10bits decoding.
> > > > > >
> > > > > > Signed-off-by: Zhong Li 
> > > > > > ---
> > > > > >  libavcodec/qsvdec.c   | 172
> > >
> > > --
> > > > > > 
> > > > > > 
> > > > > >  libavcodec/qsvdec.h   |   2 +
> > > > > >  libavcodec/qsvdec_h2645.c |   1 +
> > > > > >  libavcodec/qsvdec_other.c |   1 +
> > > > > >  4 files changed, 93 insertions(+), 83 deletions(-)
> > > > > >
> > > > > > diff --git a/libavcodec/qsvdec.c b/libavcodec/qsvdec.c index
> > > > > > 4a0be811fb..b78026e14d 100644
> > > > > > --- a/libavcodec/qsvdec.c
> > > > > > +++ b/libavcodec/qsvdec.c
> > > > > > @@ -120,19 +120,17 @@ static inline unsigned int
> > > > > > qsv_fifo_size(const
> > > > > > AVFifoBuffer* fifo)
> > > > > >  return av_fifo_size(fifo) / qsv_fifo_item_size();
> > > > > >  }
> > > > > >
> > > > > > -static int qsv_decode_init(AVCodecContext *avctx, QSVContext
> > > > > > *q)
> > > > > > +static int qsv_decode_preinit(AVCodecContext *avctx,
> > > > > > QSVContext
> > > > > > *q,
> > > > > > enum AVPixelFormat *pix_fmts, mfxVideoParam *param)
> > > > > >  {
> > > > > > -const AVPixFmtDescriptor *desc;
> > > > > >  mfxSession session = NULL;
> > > > > >  int iopattern = 0;
> > > > > > -mfxVideoParam param = { 0 };
> > > > > > -int frame_width  = avctx->coded_width;
> > > > > > -int frame_height = avctx->coded_height;
> > > > > >  int ret;
> > > > > >
> > > > > > -desc = av_pix_fmt_desc_get(avctx->sw_pix_fmt);
> > > > > > -if (!desc)
> > > > > > -return AVERROR_BUG;
> > > > > > +ret = ff_get_format(avctx, pix_fmts);
> > > > > > +if (ret < 0) {
> > > > > > +q->orig_pix_fmt = avctx->pix_fmt = AV_PIX_FMT_NONE;
> > > > > > +return ret;
> > > > > > +}
> > > > > >
> > > > > >  if (!q->async_fifo) {
> > > > > >  q->async_fifo = av_fifo_alloc(q->async_depth *
> > > > > > qsv_fifo_item_size()); @@ -170,48 +168,72 @@ static int
> > > > > > qsv_decode_init(AVCodecContext *avctx, QSVContext *q)
> > > > > >  return ret;
> > > > > >  }
> > > > > >
> > > > > > -ret = ff_qsv_codec_id_to_mfx(avctx->codec_id);
> > > > > > -if (ret < 0)
> > > > > > -return ret;
> > > > > > +param->IOPattern   = q->iopattern;
> > > > > > +param->AsyncDepth  = q->async_depth;
> > > > > > +param->ExtParam= q->ext_buffers;
> > > > > > +param->NumExtParam = q->nb_ext_buffers;
> > > > > >
> > > > > > -param.mfx.CodecId  = ret;
> > > > > > -param.mfx.CodecProfile = ff_qsv_profile_to_mfx(avctx-
> > > > > > > codec_id,
> > > > > >
> > > > > > avctx->profile);
> > > > > > -param.mfx.CodecLevel   = avctx->level ==
> > > > >
> > > > > FF_LEVEL_UNKNOWN ?
> > > > > > MFX_LEVEL_UNKNOWN : avctx->level;
> > > > > > -
> > > > > > -param.mfx.FrameInfo.BitDepthLuma   =
> > >
> > > desc->comp[0].depth;
> > > > > > -param.mfx.FrameInfo.BitDepthChroma = desc-
> > > > > > >comp[0].depth;
> > > > > > -param.mfx.FrameInfo.Shift  =
> > >
> > > desc->comp[0].depth >
> > > > >
> > > > > 8;
> > > > > > -

Re: [FFmpeg-devel] [PATCH 1/2] h2645_parse: Propagate NAL header parsing errors

2019-03-18 Thread James Almer
On 3/18/2019 12:52 PM, Derek Buitenhuis wrote:
> On 18/03/2019 15:50, James Almer wrote:
>> This will abort the splitting process when it's meant to only discard
>> the faulty NAL. Even the log message stats it's skipping it.
> 
> The log message also claims to be AV_LOG_ERROR.
> 
> Also there are no comments indicating why this is right, or any commit I
> could find.
> 
> If you feel you can fix this in hevcdec.c, feel free... I couldn't figure
> out where it was blowing up, specifically.
> 
> - Derek

So, what i'm seeing here is two slice NALs in the same packet (which
means processed in the same decode_nal_units() loop in hevcdec.c)
reporting being the "first slice segment in the pic". And that's
seemingly making the threading logic shit itself.
In between them are two NALs, both with valid starting codes but invalid
data (first bit is 1 when it's a bitstream requirement for it to be 0),
but they ultimately have nothing to do with the issue in this file. Your
patch works around this simply because it aborts the NAL splitting
before it gets to the second slice NAL, and the whole packet gets discarded.

This is among other things a muxing mistake, since if you remux this
into raw hevc (ffmpeg -i nal_header_deadlock.mp4 -c:v copy -an
nal_header_deadlock.hevc) and try to decode that, the hevc parser will
split it into proper packets with one slice/pic NAL each and the
deadlock will not happen (see hevc_find_frame_end() in hevc_parser.c).

The following change fixes this for me by preventing the decoder from
trying to decode more than one "first" slice for the same frame:

> diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
> index 967f8f1def..9492108c77 100644
> --- a/libavcodec/hevcdec.c
> +++ b/libavcodec/hevcdec.c
> @@ -2927,6 +2927,10 @@ static int decode_nal_unit(HEVCContext *s, const 
> H2645NAL *nal)
>  }
> 
>  if (s->sh.first_slice_in_pic_flag) {
> +if (s->ref) {
> +av_log(s->avctx, AV_LOG_ERROR, "Two slices reporting being 
> the first in the picture.\n");
> +goto fail;
> +}
>  if (s->max_ra == INT_MAX) {
>  if (s->nal_unit_type == HEVC_NAL_CRA_NUT || IS_BLA(s)) {
>  s->max_ra = s->poc;

But it will however discard the second slice, despite its only apparent
problem being showing up in the wrong packet, so it's probably still not
ideal.
Another solution would be to enable the parser for mp4 input, so the
packetization in the input will be ignored, but that'll slow down
demuxing for every single file.

Someone else that knows hevc and/or threading might want to look at this
and fix this in a better way.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] 32bit transcoding app running out of memory

2019-03-18 Thread Simone Donadini
Hi Ronald,

actually the problem was occurring transcoding quicktime files with ProRes 
settings and not with h264.
Changing the number of threads would not solve the problem.
I noticed that memory usage would keep growing as long i reached a certain 
point at which i would get a message like "Delay between the first packet and 
last packet in the muxing queue is 10004900 > 1000: forcing output".  When 
transcoding 8k files i would not get to this point as at 4GB the app would 
crash.
The solution at the moment is to set the output format context's 
"max_interleave_delta" at a value lower than 1000 after the output context 
is allocated and before avformat_write_header(). Doing this i am forcing the 
encoder to output frames, memory usage is kept steady, and i managed to 
transcode 8k files with no errors.
But is this a correct workaround? Or should i set some flag too?
I tried also to set the output context flag to AVFMT_FLAG_SHORTEST but i am not 
getting the same result. 

Thank you,
bye,
Simone.



From: Simone Donadini
Sent: Friday, March 15, 2019 11:42 AM
To: FFmpeg development discussions and patches
Subject: RE: [FFmpeg-devel] 32bit transcoding app running out of memory

Hi Ronald,
yes, we are using our own codec wrapped inside FFmpeg.
Thank you for your suggestion, i will try with limiting the number of threads 
launched by FFmpeg.
Simone.


From: ffmpeg-devel [ffmpeg-devel-boun...@ffmpeg.org] on behalf of Ronald S. 
Bultje [rsbul...@gmail.com]
Sent: Friday, March 15, 2019 11:24 AM
To: FFmpeg development discussions and patches
Subject: Re: [FFmpeg-devel] 32bit transcoding app running out of memory

Hi,

On Thu, Mar 14, 2019 at 7:52 AM Simone Donadini <
simone.donad...@avolites.com> wrote:

> > 2019-03-14 11:28 GMT+01:00, Simone Donadini <
> simone.donad...@avolites.com>:
> > > While transcoding video files with larger resolution (8K) the app,
> > > which is 32bit, will run out of memory (>4GB).
> > > It does not look like a memory leak, as memory usage will grow as long
> as
> > > transcoding a certain amount of frames and then it will stay steady. It
> > > looks like the amount of memory usage depends on the resolution of the
> >
> > > frame, but even with a 8K frame using >4GB is not expected.
> >
> > Why do you think so?
>
> With our codec one encoded frame 7680x4320 should be ~100MB.
>

Am I right in interpreting this as that you're not actually using an
existing FFMpeg encoder, but rather your own codec's encoder wrapped into
FFmpeg by yourself?

> h264 8K @60fps

I think several dozen frame allocations in the decoder (b/c of frame
threading) can happen, depending on the machine. 8*4*1.5*2=96MB/frame
(assuming 10bits 8K, you didn't mention), so for 3 dozen (assuming
n_threads=20-30), we're talking 3.6GB. To limit, use ffmpeg -thread_type
none -i .. or ffmpeg -threads $n -i .. where $n is a smaller number (e.g. 2
or 4) than the default (which is system-dependent).

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


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


Re: [FFmpeg-devel] [PATCH 0/2] HEVC/H.264 Parsing / Deadlock Fix

2019-03-18 Thread Derek Buitenhuis
On 18/03/2019 15:55, Carl Eugen Hoyos wrote:
> The first 500k of this file allow to reproduce the issue,
> so I believe the sample is too big.

Sure, I can trim it. I'll resend the test + file once a solution
is agreed upon.

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


Re: [FFmpeg-devel] [PATCH 0/2] HEVC/H.264 Parsing / Deadlock Fix

2019-03-18 Thread Carl Eugen Hoyos
2019-03-18 16:46 GMT+01:00, Derek Buitenhuis :
> FATE sample is located here:
> http://chromashift.org/nal_header_deadlock.mp4

The first 500k of this file allow to reproduce the issue,
so I believe the sample is too big.

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


Re: [FFmpeg-devel] [PATCH 1/2] h2645_parse: Propagate NAL header parsing errors

2019-03-18 Thread Derek Buitenhuis
On 18/03/2019 15:50, James Almer wrote:
> This will abort the splitting process when it's meant to only discard
> the faulty NAL. Even the log message stats it's skipping it.

The log message also claims to be AV_LOG_ERROR.

Also there are no comments indicating why this is right, or any commit I
could find.

If you feel you can fix this in hevcdec.c, feel free... I couldn't figure
out where it was blowing up, specifically.

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


Re: [FFmpeg-devel] [PATCH 1/2] h2645_parse: Propagate NAL header parsing errors

2019-03-18 Thread James Almer
On 3/18/2019 12:46 PM, Derek Buitenhuis wrote:
> If we don't propagate these errors, h264dec and hevcdec can get up to all 
> sorts of
> weirdness, especially threaded, while trying to continue on with things they 
> shouldn't.
> Can cause stuff like:
> 
> [hevc @ 0x577107c0] get_buffer() cannot be called after 
> ff_thread_finish_setup()
> [hevc @ 0x577107c0] thread_get_buffer() failed
> [hevc @ 0x577107c0] Error parsing NAL unit #5.
> Error while decoding stream #0:0: Cannot allocate memory
> 
> 
> Signed-off-by: Derek Buitenhuis 
> ---
>  libavcodec/h2645_parse.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/libavcodec/h2645_parse.c b/libavcodec/h2645_parse.c
> index 942f2c5d71..175c986c71 100644
> --- a/libavcodec/h2645_parse.c
> +++ b/libavcodec/h2645_parse.c
> @@ -503,6 +503,8 @@ int ff_h2645_packet_split(H2645Packet *pkt, const uint8_t 
> *buf, int length,
> nal->type);
>  }
>  pkt->nb_nals--;
> +if (ret < 0)
> +return ret;

This will abort the splitting process when it's meant to only discard
the faulty NAL. Even the log message stats it's skipping it.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [PATCH 2/2] FATE: Add test for HEVC NAL header parsing deadlock

2019-03-18 Thread Derek Buitenhuis
Signed-off-by: Derek Buitenhuis 
---
 tests/fate/hevc.mak |  3 +++
 tests/ref/fate/hevc-nal-header-deadlock | 12 
 2 files changed, 15 insertions(+)
 create mode 100644 tests/ref/fate/hevc-nal-header-deadlock

diff --git a/tests/fate/hevc.mak b/tests/fate/hevc.mak
index db3ea19340..20e2183d64 100644
--- a/tests/fate/hevc.mak
+++ b/tests/fate/hevc.mak
@@ -253,6 +253,9 @@ fate-hevc-extradata-reload: CMD = framemd5 -i 
$(TARGET_SAMPLES)/hevc/extradata-r
 fate-hevc-monochrome-crop: CMD = probeframes -show_entries 
frame=width,height:stream=width,height 
$(TARGET_SAMPLES)/hevc/hevc-monochrome.hevc
 FATE_HEVC_FFPROBE-$(call DEMDEC, HEVC, HEVC) += fate-hevc-monochrome-crop
 
+fate-hevc-nal-header-deadlock: CMD = threads=2 framemd5 -i 
$(TARGET_SAMPLES)/hevc/nal_header_deadlock.mp4 -sws_flags bitexact -t 00:00.20 
-an
+FATE_HEVC += fate-hevc-nal-header-deadlock
+
 FATE_SAMPLES_AVCONV += $(FATE_HEVC-yes)
 FATE_SAMPLES_FFPROBE += $(FATE_HEVC_FFPROBE-yes)
 
diff --git a/tests/ref/fate/hevc-nal-header-deadlock 
b/tests/ref/fate/hevc-nal-header-deadlock
new file mode 100644
index 00..8ce7a066c7
--- /dev/null
+++ b/tests/ref/fate/hevc-nal-header-deadlock
@@ -0,0 +1,12 @@
+#format: frame checksums
+#version: 2
+#hash: MD5
+#tb 0: 1/15
+#media_type 0: video
+#codec_id 0: rawvideo
+#dimensions 0: 1920x1080
+#sar 0: 0/1
+#stream#, dts,pts, duration, size, hash
+0,  0,  0,1,  3110400, c88154281ada839d3f209b0eab012577
+0,  1,  1,1,  3110400, a2623ba4639cf246b803c08e7233112f
+0,  2,  2,1,  3110400, 9208fcdb16664e91ada77d15cc29ace9
-- 
2.20.1

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


[FFmpeg-devel] [PATCH 0/2] HEVC/H.264 Parsing / Deadlock Fix

2019-03-18 Thread Derek Buitenhuis
FATE sample is located here:
http://chromashift.org/nal_header_deadlock.mp4
md5sum is: 166f5959a67fccf3017eaeb010a64fcf

Since it causes a deadlock in FFmpeg, please be careful if opening in
e.g. a browser.

Derek Buitenhuis (2):
  h2645_parse: Propagate NAL header parsing errors
  FATE: Add test for HEVC NAL header parsing deadlock

 libavcodec/h2645_parse.c|  2 ++
 tests/fate/hevc.mak |  3 +++
 tests/ref/fate/hevc-nal-header-deadlock | 12 
 3 files changed, 17 insertions(+)
 create mode 100644 tests/ref/fate/hevc-nal-header-deadlock

-- 
2.20.1

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


[FFmpeg-devel] [PATCH 1/2] h2645_parse: Propagate NAL header parsing errors

2019-03-18 Thread Derek Buitenhuis
If we don't propagate these errors, h264dec and hevcdec can get up to all sorts 
of
weirdness, especially threaded, while trying to continue on with things they 
shouldn't.
Can cause stuff like:

[hevc @ 0x577107c0] get_buffer() cannot be called after 
ff_thread_finish_setup()
[hevc @ 0x577107c0] thread_get_buffer() failed
[hevc @ 0x577107c0] Error parsing NAL unit #5.
Error while decoding stream #0:0: Cannot allocate memory


Signed-off-by: Derek Buitenhuis 
---
 libavcodec/h2645_parse.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/libavcodec/h2645_parse.c b/libavcodec/h2645_parse.c
index 942f2c5d71..175c986c71 100644
--- a/libavcodec/h2645_parse.c
+++ b/libavcodec/h2645_parse.c
@@ -503,6 +503,8 @@ int ff_h2645_packet_split(H2645Packet *pkt, const uint8_t 
*buf, int length,
nal->type);
 }
 pkt->nb_nals--;
+if (ret < 0)
+return ret;
 }
 }
 
-- 
2.20.1

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


Re: [FFmpeg-devel] [PATCH 2/2] swscale/ppc: Add av_unused to template vars only used in one includer

2019-03-18 Thread Carl Eugen Hoyos
2019-03-18 12:56 GMT+01:00, Lauri Kasanen :
> Signed-off-by: Lauri Kasanen 
> ---
>  libswscale/ppc/swscale_ppc_template.c | 21 +++--
>  1 file changed, 11 insertions(+), 10 deletions(-)
>
> diff --git a/libswscale/ppc/swscale_ppc_template.c
> b/libswscale/ppc/swscale_ppc_template.c
> index 3964a7a..aff2dd7 100644
> --- a/libswscale/ppc/swscale_ppc_template.c
> +++ b/libswscale/ppc/swscale_ppc_template.c
> @@ -44,7 +44,7 @@ static void FUNC(yuv2planeX_8_16)(const int16_t *filter,
> int filterSize,
>  for (j = 0; j < filterSize; j++) {
>  unsigned int joffset=j<<1;
>  unsigned int xoffset=x<<1;
> -vector unsigned char perm;
> +vector unsigned char av_unused perm;
>  vector signed short l1,vLumFilter;
>  LOAD_FILTER(vLumFilter,filter);
>  vLumFilter = vec_splat(vLumFilter, 0);
> @@ -133,8 +133,8 @@ static void FUNC(hScale_real)(SwsContext *c, int16_t
> *dst, int dstW,
>  case 8:
>  for (i = 0; i < dstW; i++) {
>  register int srcPos = filterPos[i];
> -vector unsigned char src_vF, src_v0, src_v1;
> -vector unsigned char permS;
> +vector unsigned char src_vF, av_unused src_v0, av_unused
> src_v1;
> +vector unsigned char av_unused permS;
>  vector signed short src_v, filter_v;
>  vector signed int val_v, val_s;
>  FIRST_LOAD(src_v0, srcPos, src, permS);
> @@ -173,18 +173,19 @@ static void FUNC(hScale_real)(SwsContext *c, int16_t
> *dst, int dstW,
>
>  default:
>  for (i = 0; i < dstW; i++) {
> -register int j, offset = i * 2 * filterSize;
> +register int j, av_unused offset = i * 2 * filterSize;
>  register int srcPos = filterPos[i];
>
>  vector signed int val_s, val_v = (vector signed int)vzero;
> -vector signed short filter_v0R;
> -vector unsigned char permF, src_v0, permS;
> +vector signed short av_unused filter_v0R;
> +vector unsigned char av_unused permF, av_unused src_v0,
> av_unused permS;
>  FIRST_LOAD(filter_v0R, offset, filter, permF);
>  FIRST_LOAD(src_v0, srcPos, src, permS);
>
>  for (j = 0; j < filterSize - 15; j += 16) {
> -vector unsigned char src_v1, src_vF;
> -vector signed short filter_v1R, filter_v2R, filter_v0,
> filter_v1, src_vA, src_vB;
> +vector unsigned char av_unused src_v1, src_vF;
> +vector signed short av_unused filter_v1R, av_unused
> filter_v2R,
> +filter_v0, filter_v1, src_vA,
> src_vB;
>  vector signed int val_acc;
>  LOAD_SRCV(srcPos, j, src, permS, src_v0, src_v1,
> src_vF);
>  src_vA = // vec_unpackh sign-extends...
> @@ -201,8 +202,8 @@ static void FUNC(hScale_real)(SwsContext *c, int16_t
> *dst, int dstW,
>
>  if (j < filterSize - 7) {
>  // loading src_v0 is useless, it's already done above
> -vector unsigned char src_v1, src_vF;
> -vector signed short src_v, filter_v1R, filter_v;
> +vector unsigned char av_unused src_v1, src_vF;
> +vector signed short src_v, av_unused filter_v1R,
> filter_v;

lgtm if you prefer this approach over some ifdeffery.

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


[FFmpeg-devel] [PATCH] avcodec/libdav1d: use a reference to the allocated buffer instead of wrapping the Dav1dPicture

2019-03-18 Thread James Almer
Removes an av_malloc() per frame.

Signed-off-by: James Almer 
---
 libavcodec/libdav1d.c | 20 
 1 file changed, 4 insertions(+), 16 deletions(-)

diff --git a/libavcodec/libdav1d.c b/libavcodec/libdav1d.c
index d9079cbbef..30c6eccfef 100644
--- a/libavcodec/libdav1d.c
+++ b/libavcodec/libdav1d.c
@@ -149,18 +149,11 @@ static void libdav1d_data_free(const uint8_t *data, void 
*opaque) {
 av_buffer_unref();
 }
 
-static void libdav1d_frame_free(void *opaque, uint8_t *data) {
-Dav1dPicture *p = opaque;
-
-dav1d_picture_unref(p);
-av_free(p);
-}
-
 static int libdav1d_receive_frame(AVCodecContext *c, AVFrame *frame)
 {
 Libdav1dContext *dav1d = c->priv_data;
 Dav1dData *data = >data;
-Dav1dPicture *p;
+Dav1dPicture pic = { 0 }, *p = 
 int res;
 
 if (!data->sz) {
@@ -194,10 +187,6 @@ static int libdav1d_receive_frame(AVCodecContext *c, 
AVFrame *frame)
 return res;
 }
 
-p = av_mallocz(sizeof(*p));
-if (!p)
-return AVERROR(ENOMEM);
-
 res = dav1d_get_picture(dav1d->c, p);
 if (res < 0) {
 if (res == AVERROR(EINVAL))
@@ -205,17 +194,15 @@ static int libdav1d_receive_frame(AVCodecContext *c, 
AVFrame *frame)
 else if (res == AVERROR(EAGAIN) && c->internal->draining)
 res = AVERROR_EOF;
 
-av_free(p);
 return res;
 }
 
 av_assert0(p->data[0] != NULL);
 
-frame->buf[0] = av_buffer_create(NULL, 0, libdav1d_frame_free,
- p, AV_BUFFER_FLAG_READONLY);
+// This requires the custom allocator above
+frame->buf[0] = av_buffer_ref(p->allocator_data);
 if (!frame->buf[0]) {
 dav1d_picture_unref(p);
-av_free(p);
 return AVERROR(ENOMEM);
 }
 
@@ -310,6 +297,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
 
 res = 0;
 fail:
+dav1d_picture_unref(p);
 if (res < 0)
 av_frame_unref(frame);
 return res;
-- 
2.21.0

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


Re: [FFmpeg-devel] [PATCH 1/2] swscale/ppc: Clean up some mixed decl warnings

2019-03-18 Thread Lauri Kasanen
On Mon, 18 Mar 2019 14:06:15 +0100
Carl Eugen Hoyos  wrote:
> 
> This looks good to me if you tested it and it reduces the number of warnings.

Tested on power8. With these two patches, swscale/ppc has no warnings.

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


Re: [FFmpeg-devel] [PATCH 1/2] swscale/ppc: Clean up some mixed decl warnings

2019-03-18 Thread Carl Eugen Hoyos
2019-03-18 12:56 GMT+01:00, Lauri Kasanen :
> Signed-off-by: Lauri Kasanen 
> ---
>  libswscale/ppc/swscale_altivec.c  | 6 +++---
>  libswscale/ppc/swscale_ppc_template.c | 9 +
>  libswscale/ppc/swscale_vsx.c  | 6 +++---
>  3 files changed, 11 insertions(+), 10 deletions(-)
>
> diff --git a/libswscale/ppc/swscale_altivec.c
> b/libswscale/ppc/swscale_altivec.c
> index d72ed1e..3cd9782 100644
> --- a/libswscale/ppc/swscale_altivec.c
> +++ b/libswscale/ppc/swscale_altivec.c
> @@ -43,10 +43,10 @@
>
>  #define yuv2planeX_8(d1, d2, l1, src, x, perm, filter) do {\
>  vector signed short ls;\
> +vector signed int   vf1, vf2, i1, i2;\
>  GET_LS(l1, x, perm, src);\
> -vector signed int   i1  = vec_mule(filter, ls);\
> -vector signed int   i2  = vec_mulo(filter, ls);\
> -vector signed int   vf1, vf2;\
> +i1  = vec_mule(filter, ls);\
> +i2  = vec_mulo(filter, ls);\
>  vf1 = vec_mergeh(i1, i2);\
>  vf2 = vec_mergel(i1, i2);\
>  d1 = vec_add(d1, vf1);\
> diff --git a/libswscale/ppc/swscale_ppc_template.c
> b/libswscale/ppc/swscale_ppc_template.c
> index 11decab..3964a7a 100644
> --- a/libswscale/ppc/swscale_ppc_template.c
> +++ b/libswscale/ppc/swscale_ppc_template.c
> @@ -184,16 +184,17 @@ static void FUNC(hScale_real)(SwsContext *c, int16_t
> *dst, int dstW,
>
>  for (j = 0; j < filterSize - 15; j += 16) {
>  vector unsigned char src_v1, src_vF;
> -vector signed short filter_v1R, filter_v2R, filter_v0,
> filter_v1;
> +vector signed short filter_v1R, filter_v2R, filter_v0,
> filter_v1, src_vA, src_vB;
> +vector signed int val_acc;
>  LOAD_SRCV(srcPos, j, src, permS, src_v0, src_v1,
> src_vF);
> -vector signed short src_vA = // vec_unpackh
> sign-extends...
> +src_vA = // vec_unpackh sign-extends...
>   (vector signed
> short)(VEC_MERGEH((vector unsigned char)vzero, src_vF));
> -vector signed short src_vB = // vec_unpackh
> sign-extends...
> +src_vB = // vec_unpackh sign-extends...
>   (vector signed
> short)(VEC_MERGEL((vector unsigned char)vzero, src_vF));
>  GET_VFD(i, j, filter, filter_v0R, filter_v1R, permF,
> filter_v0, 0);
>  GET_VFD(i, j, filter, filter_v1R, filter_v2R, permF,
> filter_v1, 16);
>
> -vector signed int val_acc = vec_msums(src_vA,
> filter_v0, val_v);
> +val_acc = vec_msums(src_vA, filter_v0, val_v);
>  val_v = vec_msums(src_vB, filter_v1, val_acc);
>  UPDATE_PTR(filter_v2R, filter_v0R, src_v1, src_v0);
>  }
> diff --git a/libswscale/ppc/swscale_vsx.c b/libswscale/ppc/swscale_vsx.c
> index f6c7f1d..01eb46c 100644
> --- a/libswscale/ppc/swscale_vsx.c
> +++ b/libswscale/ppc/swscale_vsx.c
> @@ -42,10 +42,10 @@
>
>  #define yuv2planeX_8(d1, d2, l1, src, x, perm, filter) do {\
>  vector signed short ls;\
> +vector signed int   vf1, vf2, i1, i2;\
>  GET_LS(l1, x, perm, src);\
> -vector signed int   i1  = vec_mule(filter, ls);\
> -vector signed int   i2  = vec_mulo(filter, ls);\
> -vector signed int   vf1, vf2;\
> +i1  = vec_mule(filter, ls);\
> +i2  = vec_mulo(filter, ls);\
>  vf1 = vec_mergeh(i1, i2);\
>  vf2 = vec_mergel(i1, i2);\
>  d1 = vec_add(d1, vf1);\

This looks good to me if you tested it and it reduces the number of warnings.

Thank you, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [PATCH 2/2] swscale/ppc: Add av_unused to template vars only used in one includer

2019-03-18 Thread Lauri Kasanen
Signed-off-by: Lauri Kasanen 
---
 libswscale/ppc/swscale_ppc_template.c | 21 +++--
 1 file changed, 11 insertions(+), 10 deletions(-)

diff --git a/libswscale/ppc/swscale_ppc_template.c 
b/libswscale/ppc/swscale_ppc_template.c
index 3964a7a..aff2dd7 100644
--- a/libswscale/ppc/swscale_ppc_template.c
+++ b/libswscale/ppc/swscale_ppc_template.c
@@ -44,7 +44,7 @@ static void FUNC(yuv2planeX_8_16)(const int16_t *filter, int 
filterSize,
 for (j = 0; j < filterSize; j++) {
 unsigned int joffset=j<<1;
 unsigned int xoffset=x<<1;
-vector unsigned char perm;
+vector unsigned char av_unused perm;
 vector signed short l1,vLumFilter;
 LOAD_FILTER(vLumFilter,filter);
 vLumFilter = vec_splat(vLumFilter, 0);
@@ -133,8 +133,8 @@ static void FUNC(hScale_real)(SwsContext *c, int16_t *dst, 
int dstW,
 case 8:
 for (i = 0; i < dstW; i++) {
 register int srcPos = filterPos[i];
-vector unsigned char src_vF, src_v0, src_v1;
-vector unsigned char permS;
+vector unsigned char src_vF, av_unused src_v0, av_unused 
src_v1;
+vector unsigned char av_unused permS;
 vector signed short src_v, filter_v;
 vector signed int val_v, val_s;
 FIRST_LOAD(src_v0, srcPos, src, permS);
@@ -173,18 +173,19 @@ static void FUNC(hScale_real)(SwsContext *c, int16_t 
*dst, int dstW,
 
 default:
 for (i = 0; i < dstW; i++) {
-register int j, offset = i * 2 * filterSize;
+register int j, av_unused offset = i * 2 * filterSize;
 register int srcPos = filterPos[i];
 
 vector signed int val_s, val_v = (vector signed int)vzero;
-vector signed short filter_v0R;
-vector unsigned char permF, src_v0, permS;
+vector signed short av_unused filter_v0R;
+vector unsigned char av_unused permF, av_unused src_v0, 
av_unused permS;
 FIRST_LOAD(filter_v0R, offset, filter, permF);
 FIRST_LOAD(src_v0, srcPos, src, permS);
 
 for (j = 0; j < filterSize - 15; j += 16) {
-vector unsigned char src_v1, src_vF;
-vector signed short filter_v1R, filter_v2R, filter_v0, 
filter_v1, src_vA, src_vB;
+vector unsigned char av_unused src_v1, src_vF;
+vector signed short av_unused filter_v1R, av_unused 
filter_v2R,
+filter_v0, filter_v1, src_vA, src_vB;
 vector signed int val_acc;
 LOAD_SRCV(srcPos, j, src, permS, src_v0, src_v1, src_vF);
 src_vA = // vec_unpackh sign-extends...
@@ -201,8 +202,8 @@ static void FUNC(hScale_real)(SwsContext *c, int16_t *dst, 
int dstW,
 
 if (j < filterSize - 7) {
 // loading src_v0 is useless, it's already done above
-vector unsigned char src_v1, src_vF;
-vector signed short src_v, filter_v1R, filter_v;
+vector unsigned char av_unused src_v1, src_vF;
+vector signed short src_v, av_unused filter_v1R, filter_v;
 LOAD_SRCV8(srcPos, j, src, permS, src_v0, src_v1, src_vF);
 src_v = // vec_unpackh sign-extends...
 (vector signed short)(VEC_MERGEH((vector unsigned 
char)vzero, src_vF));
-- 
2.6.2

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


[FFmpeg-devel] [PATCH 1/2] swscale/ppc: Clean up some mixed decl warnings

2019-03-18 Thread Lauri Kasanen
Signed-off-by: Lauri Kasanen 
---
 libswscale/ppc/swscale_altivec.c  | 6 +++---
 libswscale/ppc/swscale_ppc_template.c | 9 +
 libswscale/ppc/swscale_vsx.c  | 6 +++---
 3 files changed, 11 insertions(+), 10 deletions(-)

diff --git a/libswscale/ppc/swscale_altivec.c b/libswscale/ppc/swscale_altivec.c
index d72ed1e..3cd9782 100644
--- a/libswscale/ppc/swscale_altivec.c
+++ b/libswscale/ppc/swscale_altivec.c
@@ -43,10 +43,10 @@
 
 #define yuv2planeX_8(d1, d2, l1, src, x, perm, filter) do {\
 vector signed short ls;\
+vector signed int   vf1, vf2, i1, i2;\
 GET_LS(l1, x, perm, src);\
-vector signed int   i1  = vec_mule(filter, ls);\
-vector signed int   i2  = vec_mulo(filter, ls);\
-vector signed int   vf1, vf2;\
+i1  = vec_mule(filter, ls);\
+i2  = vec_mulo(filter, ls);\
 vf1 = vec_mergeh(i1, i2);\
 vf2 = vec_mergel(i1, i2);\
 d1 = vec_add(d1, vf1);\
diff --git a/libswscale/ppc/swscale_ppc_template.c 
b/libswscale/ppc/swscale_ppc_template.c
index 11decab..3964a7a 100644
--- a/libswscale/ppc/swscale_ppc_template.c
+++ b/libswscale/ppc/swscale_ppc_template.c
@@ -184,16 +184,17 @@ static void FUNC(hScale_real)(SwsContext *c, int16_t 
*dst, int dstW,
 
 for (j = 0; j < filterSize - 15; j += 16) {
 vector unsigned char src_v1, src_vF;
-vector signed short filter_v1R, filter_v2R, filter_v0, 
filter_v1;
+vector signed short filter_v1R, filter_v2R, filter_v0, 
filter_v1, src_vA, src_vB;
+vector signed int val_acc;
 LOAD_SRCV(srcPos, j, src, permS, src_v0, src_v1, src_vF);
-vector signed short src_vA = // vec_unpackh sign-extends...
+src_vA = // vec_unpackh sign-extends...
  (vector signed 
short)(VEC_MERGEH((vector unsigned char)vzero, src_vF));
-vector signed short src_vB = // vec_unpackh sign-extends...
+src_vB = // vec_unpackh sign-extends...
  (vector signed 
short)(VEC_MERGEL((vector unsigned char)vzero, src_vF));
 GET_VFD(i, j, filter, filter_v0R, filter_v1R, permF, 
filter_v0, 0);
 GET_VFD(i, j, filter, filter_v1R, filter_v2R, permF, 
filter_v1, 16);
 
-vector signed int val_acc = vec_msums(src_vA, filter_v0, 
val_v);
+val_acc = vec_msums(src_vA, filter_v0, val_v);
 val_v = vec_msums(src_vB, filter_v1, val_acc);
 UPDATE_PTR(filter_v2R, filter_v0R, src_v1, src_v0);
 }
diff --git a/libswscale/ppc/swscale_vsx.c b/libswscale/ppc/swscale_vsx.c
index f6c7f1d..01eb46c 100644
--- a/libswscale/ppc/swscale_vsx.c
+++ b/libswscale/ppc/swscale_vsx.c
@@ -42,10 +42,10 @@
 
 #define yuv2planeX_8(d1, d2, l1, src, x, perm, filter) do {\
 vector signed short ls;\
+vector signed int   vf1, vf2, i1, i2;\
 GET_LS(l1, x, perm, src);\
-vector signed int   i1  = vec_mule(filter, ls);\
-vector signed int   i2  = vec_mulo(filter, ls);\
-vector signed int   vf1, vf2;\
+i1  = vec_mule(filter, ls);\
+i2  = vec_mulo(filter, ls);\
 vf1 = vec_mergeh(i1, i2);\
 vf2 = vec_mergel(i1, i2);\
 d1 = vec_add(d1, vf1);\
-- 
2.6.2

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


Re: [FFmpeg-devel] [PATCH v7] mpeg12enc: Use Closed Captions if available

2019-03-18 Thread Mathieu Duponchelle
Yay, thanks!

On 3/16/19 12:04 AM, Michael Niedermayer wrote:
> no
> will apply
>
> thx
>
> [...]
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] avformat/aiffdec: parse replaygain metadata

2019-03-18 Thread Paul B Mahol
On 3/18/19, Moritz Barsnick  wrote:
> On Wed, Mar 13, 2019 at 10:17:40 +0100, Moritz Barsnick wrote:
>> Signed-off-by: Moritz Barsnick 
>> ---
>> Tested against sample provided here:
>> https://ffmpeg.org/pipermail/ffmpeg-user/2019-March/043717.html
>>
>>  libavformat/aiffdec.c | 5 +
>>  1 file changed, 5 insertions(+)
>
> Friendly ping.

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


Re: [FFmpeg-devel] [PATCH v5] lavc/qsvenc: add BRC sliding window setting

2019-03-18 Thread Hendrik Leppkes
On Mon, Mar 18, 2019 at 7:29 AM Zhong Li  wrote:
>
> WinBRCMaxAvgKbps is to specify maximum average bitrate over a
> sliding window with size of WinBRCSize
>
> WinBRCMaxAvgKbps will be ignored in CBR mode and equal to TargetKbps.
>

How are these modes different to ffmpeg rc_max_rate in conjunction
with rc_buffer_size, which are typically used for a VBV-like buffering
scheme in H264/5, which also seems to be a sliding window as I
understand it?

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


Re: [FFmpeg-devel] [PATCH] avcodec/tiff: Add support for recognizing DNG files

2019-03-18 Thread Michael Niedermayer
On Mon, Mar 18, 2019 at 09:13:01AM +0100, Moritz Barsnick wrote:
> On Sun, Mar 17, 2019 at 23:05:01 +0100, Paul B Mahol wrote:
> > Still wrong, You can decode images you linked just fine (albeit with
> > incorrect colors) with command:
> > 
> > ffmpeg -subimage 1 -i IMAGE.dng rest of command.
> 
> Shouldn't, ideally, these image files be demuxed as two image streams?
> Perhaps with the "main" image as the first stream.

probably something like this, yes
I think a good test for what "should" be done is to ask what "works"
consider converting the data from one format to another, all data
that source and destination supports should be preserved.

A design that can only extract one image of many or one stream or one
channel. Cannot preserve all information so it fails that simple
use case.

thx

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

Dictatorship naturally arises out of democracy, and the most aggravated
form of tyranny and slavery out of the most extreme liberty. -- Plato


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


Re: [FFmpeg-devel] [PATCH v5] avformat/smoothstreamingenc:add bitrate calculate

2019-03-18 Thread Liu Steven


> 在 2019年3月18日,上午8:52,Jun Li  写道:
> 
> On Fri, Mar 15, 2019 at 6:04 PM Jun Li  wrote:
> 
>> Calculate bitrate based on fragment size, only applied when
>> bitrate is not set, for example rtsp source.
>> 
>> Signed-off-by: Jun Li 
>> ---
>> libavformat/smoothstreamingenc.c | 32 +++-
>> 1 file changed, 27 insertions(+), 5 deletions(-)
>> 
>> diff --git a/libavformat/smoothstreamingenc.c
>> b/libavformat/smoothstreamingenc.c
>> index 094712af27..bd7f841dc7 100644
>> --- a/libavformat/smoothstreamingenc.c
>> +++ b/libavformat/smoothstreamingenc.c
>> @@ -320,11 +320,13 @@ static int ism_write_header(AVFormatContext *s)
>> AVDictionary *opts = NULL;
>> 
>> if (!s->streams[i]->codecpar->bit_rate) {
>> -av_log(s, AV_LOG_ERROR, "No bit rate set for stream %d\n", i);
>> -ret = AVERROR(EINVAL);
>> -goto fail;
>> +av_log(s, AV_LOG_WARNING, "No bit rate set for stream %d\n",
>> i);
>> +// create a tmp name for the directory of fragments
>> +snprintf(os->dirname, sizeof(os->dirname),
>> "%s/QualityLevels(Tmp_%d)", s->url, i);
>> +} else {
>> +snprintf(os->dirname, sizeof(os->dirname),
>> "%s/QualityLevels(%"PRId64")", s->url, s->streams[i]->codecpar->bit_rate);
>> }
>> -snprintf(os->dirname, sizeof(os->dirname),
>> "%s/QualityLevels(%"PRId64")", s->url, s->streams[i]->codecpar->bit_rate);
>> +
>> if (mkdir(os->dirname, 0777) == -1 && errno != EEXIST) {
>> ret = AVERROR(errno);
>> av_log(s, AV_LOG_ERROR, "mkdir failed\n");
>> @@ -519,7 +521,7 @@ static int ism_flush(AVFormatContext *s, int final)
>> 
>> for (i = 0; i < s->nb_streams; i++) {
>> OutputStream *os = >streams[i];
>> -char filename[1024], target_filename[1024], header_filename[1024];
>> +char filename[1024], target_filename[1024],
>> header_filename[1024], curr_dirname[1024];
>> int64_t size;
>> int64_t start_ts, duration, moof_size;
>> if (!os->packets_written)
>> @@ -541,6 +543,26 @@ static int ism_flush(AVFormatContext *s, int final)
>> size = os->tail_pos - os->cur_start_pos;
>> if ((ret = parse_fragment(s, filename, _ts, ,
>> _size, size)) < 0)
>> break;
>> +
>> +if (!s->streams[i]->codecpar->bit_rate) {
>> +int64_t bitrate = (int64_t) size * 8 * AV_TIME_BASE /
>> av_rescale_q(duration, s->streams[i]->time_base, AV_TIME_BASE_Q);
>> +if (!bitrate) {
>> +av_log(s, AV_LOG_ERROR, "calculating bitrate got
>> zero.\n");
>> +ret = AVERROR(EINVAL);
>> +return ret;
>> +}
>> +
>> +av_log(s, AV_LOG_DEBUG, "calculated bitrate: %"PRId64"\n",
>> bitrate);
>> +s->streams[i]->codecpar->bit_rate = bitrate;
>> +memcpy(curr_dirname, os->dirname, sizeof(os->dirname));
>> +snprintf(os->dirname, sizeof(os->dirname),
>> "%s/QualityLevels(%"PRId64")", s->url, s->streams[i]->codecpar->bit_rate);
>> +snprintf(filename, sizeof(filename), "%s/temp", os->dirname);
>> +
>> +// rename the tmp folder back to the correct name since we
>> now have the bitrate
>> +if ((ret = ff_rename((const char*)curr_dirname,  os->dirname,
>> s)) < 0)
>> +return ret;
>> +}
>> +
>> snprintf(header_filename, sizeof(header_filename),
>> "%s/FragmentInfo(%s=%"PRIu64")", os->dirname, os->stream_type_tag,
>> start_ts);
>> snprintf(target_filename, sizeof(target_filename),
>> "%s/Fragments(%s=%"PRIu64")", os->dirname, os->stream_type_tag, start_ts);
>> copy_moof(s, filename, header_filename, moof_size);
>> --
>> 2.17.1
>> 
> 
> 
> Ping.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel


LGTM


Thanks

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


Re: [FFmpeg-devel] [PATCH] avcodec/tiff: Add support for recognizing DNG files

2019-03-18 Thread Lauri Kasanen
On Mon, 18 Mar 2019 09:13:01 +0100
Moritz Barsnick  wrote:

> On Sun, Mar 17, 2019 at 23:05:01 +0100, Paul B Mahol wrote:
> > Still wrong, You can decode images you linked just fine (albeit with
> > incorrect colors) with command:
> > 
> > ffmpeg -subimage 1 -i IMAGE.dng rest of command.
> 
> Shouldn't, ideally, these image files be demuxed as two image streams?
> Perhaps with the "main" image as the first stream.

The DNG spec is pretty massive, and there's a huge amount of
variations. There can easily be far more than two streams, there could
be several "main" images and several previews in different sizes. Their
order can vary too, it's not always the thumbnail first; thumbnails can
also be omitted entirely. There's also several different
encodings/compression types for the "main" images.

I've used their libdng for a project. It's a big LGPL library
implementing pretty much everything, but no distro really ships it, so
it'd have to be embedded or built manually by the user.

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


Re: [FFmpeg-devel] [PATCH] avcodec/tiff: Add support for recognizing DNG files

2019-03-18 Thread Paul B Mahol
On 3/18/19, velocit...@gmail.com  wrote:
> From: Nick Renieris 
>
> Prints "DNG images are not supported" if it finds a TIFF image with
> the 'DNGVersion' tag.  In DNG images with the .tiff extension, it
> solves the issue where the TIFF thumbnail in IFD 0 was incorrectly
> parsed (related confusion: [1]).  The user can still decode those
> with the -subimage option.  Also prints the DNG version of the file
> on the debug channel.
>
> Additionally:
>  - Renamed TIFF_WHITE_LEVEL to DNG_WHITE_LEVEL since it is specified
>in the DNG spec.
>  - Added/changed some comments to be more precise in differentiating
>between TIFF, TIFF/EP and DNG values.
>
> Related to ticket: https://trac.ffmpeg.org/ticket/4364
>
> ---
>
> [1]:
> https://superuser.com/questions/546879/creating-video-from-dng-images-with-ffmpeg
>
> Signed-off-by: Nick Renieris 
> ---
>  libavcodec/tiff.c  | 29 -
>  libavcodec/tiff.h  | 18 +-
>  libavformat/img2.c |  1 +
>  3 files changed, 42 insertions(+), 6 deletions(-)
>
> diff --git a/libavcodec/tiff.c b/libavcodec/tiff.c
> index 112f5b52f4..41c63900fd 100644
> --- a/libavcodec/tiff.c
> +++ b/libavcodec/tiff.c
> @@ -70,6 +70,7 @@ typedef struct TiffContext {
>  int fill_order;
>  uint32_t res[4];
>
> +int dng_mode; /** denotes that this is a DNG image */
>  int is_bayer;
>  uint8_t pattern[4];
>  unsigned white_level;
> @@ -1077,7 +1078,7 @@ static int tiff_decode_tag(TiffContext *s, AVFrame
> *frame)
>  case TIFF_SUB_IFDS:
>  s->sub_ifd = value;
>  break;
> -case TIFF_WHITE_LEVEL:
> +case DNG_WHITE_LEVEL:
>  s->white_level = value;
>  break;
>  case TIFF_CFA_PATTERN_DIM:
> @@ -1322,6 +1323,20 @@ static int tiff_decode_tag(TiffContext *s, AVFrame
> *frame)
>  case TIFF_SOFTWARE_NAME:
>  ADD_METADATA(count, "software", NULL);
>  break;
> +case DNG_VERSION:
> +if (count == 4) {
> +unsigned int ver[4];
> +ver[0] = ff_tget(>gb, type, s->le);
> +ver[1] = ff_tget(>gb, type, s->le);
> +ver[2] = ff_tget(>gb, type, s->le);
> +ver[3] = ff_tget(>gb, type, s->le);
> +
> +av_log(s->avctx, AV_LOG_DEBUG, "DNG file, version
> %u.%u.%u.%u\n",
> +ver[0], ver[1], ver[2], ver[3]);
> +
> +s->dng_mode = 1;
> +}
> +break;
>  default:
>  if (s->avctx->err_recognition & AV_EF_EXPLODE) {
>  av_log(s->avctx, AV_LOG_ERROR,
> @@ -1375,6 +1390,7 @@ again:
>  s->fill_order  = 0;
>  s->white_level = 0;
>  s->is_bayer= 0;
> +s->dng_mode= 0;
>  free_geotags(s);
>
>  // Reset these offsets so we can tell if they were set this frame
> @@ -1389,6 +1405,17 @@ again:
>  return ret;
>  }
>
> +if (s->dng_mode) {
> +av_log(avctx, AV_LOG_ERROR, "DNG images are not supported\n");
> +
> +if (s->get_subimage) {
> +av_log(avctx, AV_LOG_INFO, "Decoding embedded TIFF thumbnail in
> DNG image\n");
> +} else {
> +av_log(avctx, AV_LOG_INFO, "Consider using -subimage for
> decoding the embedded thumbail instead\n");
> +return AVERROR_INVALIDDATA;
> +}
> +}
> +
>  if (s->sub_ifd && s->get_subimage) {
>  off = s->sub_ifd;
>  if (off >= UINT_MAX - 14 || avpkt->size < off + 14) {
> diff --git a/libavcodec/tiff.h b/libavcodec/tiff.h
> index 4b08650108..3cede299f6 100644
> --- a/libavcodec/tiff.h
> +++ b/libavcodec/tiff.h
> @@ -20,7 +20,7 @@
>
>  /**
>   * @file
> - * TIFF tables
> + * TIFF constants & data structures
>   *
>   * For more information about the TIFF format, check the official docs at:
>   * http://partners.adobe.com/public/developer/tiff/index.html
> @@ -33,7 +33,7 @@
>  #include 
>  #include "tiff_common.h"
>
> -/** abridged list of TIFF tags */
> +/** abridged list of TIFF and TIFF/EP tags */
>  enum TiffTags {
>  TIFF_SUBFILE= 0xfe,
>  TIFF_WIDTH  = 0x100,
> @@ -85,10 +85,17 @@ enum TiffTags {
>  TIFF_GEO_KEY_DIRECTORY  = 0x87AF,
>  TIFF_GEO_DOUBLE_PARAMS  = 0x87B0,
>  TIFF_GEO_ASCII_PARAMS   = 0x87B1,
> -TIFF_WHITE_LEVEL= 0xC61D,
>  };
>
> -/** list of TIFF compression types */
> +/** abridged list of DNG tags */
> +enum DngTags
> +{
> +DNG_VERSION = 0xC612,
> +DNG_BACKWARD_VERSION= 0xC613,
> +DNG_WHITE_LEVEL = 0xC61D,
> +};
> +
> +/** list of TIFF, TIFF/EP and DNG compression types */
>  enum TiffCompr {
>  TIFF_RAW = 1,
>  TIFF_CCITT_RLE,
> @@ -151,6 +158,7 @@ enum TiffGeoTagKey {
>  TIFF_VERTICAL_UNITS_GEOKEY   = 4099
>  };
>
> +/** list of TIFF, TIFF/AP and DNG PhotometricInterpretation
> (TIFF_PHOTOMETRIC) values */
>  enum TiffPhotometric {
>  TIFF_PHOTOMETRIC_NONE   = -1,
>  TIFF_PHOTOMETRIC_WHITE_IS_ZERO,  /* mono or grayscale, 0 is white
> */
> @@ -163,7 +171,7 @@ 

Re: [FFmpeg-devel] [PATCH] avformat/aiffdec: parse replaygain metadata

2019-03-18 Thread Moritz Barsnick
On Wed, Mar 13, 2019 at 10:17:40 +0100, Moritz Barsnick wrote:
> Signed-off-by: Moritz Barsnick 
> ---
> Tested against sample provided here:
> https://ffmpeg.org/pipermail/ffmpeg-user/2019-March/043717.html
> 
>  libavformat/aiffdec.c | 5 +
>  1 file changed, 5 insertions(+)

Friendly ping.

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


Re: [FFmpeg-devel] [PATCH] avcodec/tiff: Add support for recognizing DNG files

2019-03-18 Thread Moritz Barsnick
On Sun, Mar 17, 2019 at 23:05:01 +0100, Paul B Mahol wrote:
> Still wrong, You can decode images you linked just fine (albeit with
> incorrect colors) with command:
> 
> ffmpeg -subimage 1 -i IMAGE.dng rest of command.

Shouldn't, ideally, these image files be demuxed as two image streams?
Perhaps with the "main" image as the first stream.

Just wondering,
Moritz
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [PATCH v5] lavc/qsvenc: add BRC sliding window setting

2019-03-18 Thread Zhong Li
WinBRCMaxAvgKbps is to specify maximum average bitrate over a
sliding window with size of WinBRCSize

WinBRCMaxAvgKbps will be ignored in CBR mode and equal to TargetKbps.

Signed-off-by: Zhong Li 
---
 libavcodec/qsvenc.c | 12 
 libavcodec/qsvenc.h |  5 +
 2 files changed, 17 insertions(+)

diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
index 5aa020d47b..16d2aa887a 100644
--- a/libavcodec/qsvenc.c
+++ b/libavcodec/qsvenc.c
@@ -267,6 +267,11 @@ static void dump_video_param(AVCodecContext *avctx, 
QSVEncContext *q,
 #endif
 #endif
 
+#if QSV_HAVE_CO3
+av_log(avctx, AV_LOG_VERBOSE,"WinBRCMaxAvgKbps: %"PRIu32"; WinBRCSize: 
%"PRId32"\n",
+   co3->WinBRCMaxAvgKbps, co3->WinBRCSize);
+#endif
+
 if (avctx->codec_id == AV_CODEC_ID_H264) {
 av_log(avctx, AV_LOG_VERBOSE, "Entropy coding: %s; 
MaxDecFrameBuffering: %"PRIu16"\n",
co->CAVLC == MFX_CODINGOPTION_ON ? "CAVLC" : "CABAC", 
co->MaxDecFrameBuffering);
@@ -742,7 +747,14 @@ FF_ENABLE_DEPRECATION_WARNINGS
 #if QSV_HAVE_CO3
 q->extco3.Header.BufferId  = MFX_EXTBUFF_CODING_OPTION3;
 q->extco3.Header.BufferSz  = sizeof(q->extco3);
+q->extco3.WinBRCMaxAvgKbps = q->win_brc_max_avg_kbps;
+q->extco3.WinBRCSize   = q->win_brc_size;
 q->extparam_internal[q->nb_extparam_internal++] = (mfxExtBuffer 
*)>extco3;
+#else
+if (q->win_brc_max_avg_kbps || q->win_brc_size) {
+av_log(avctx, AV_LOG_ERROR, "BRC sliding window setting is 
unsupported\n");
+return AVERROR(ENOSYS);
+}
 #endif
 }
 
diff --git a/libavcodec/qsvenc.h b/libavcodec/qsvenc.h
index 00afbd80aa..2c44cb836c 100644
--- a/libavcodec/qsvenc.h
+++ b/libavcodec/qsvenc.h
@@ -89,6 +89,8 @@
 { "adaptive_b", "Adaptive B-frame placement", 
OFFSET(qsv.adaptive_b), AV_OPT_TYPE_INT, { .i64 = -1 }, -1,  1, VE 
}, \
 { "b_strategy", "Strategy to choose between I/P/B-frames", 
OFFSET(qsv.b_strategy),AV_OPT_TYPE_INT, { .i64 = -1 }, -1,  1, VE 
}, \
 { "forced_idr", "Forcing I frames as IDR frames", 
OFFSET(qsv.forced_idr), AV_OPT_TYPE_BOOL,{ .i64 = 0  },  0,  1, VE 
}, \
+{ "win_max_rate",   "maximum average bitrate (in kbps) over a sliding window", 
OFFSET(qsv.win_brc_max_avg_kbps), AV_OPT_TYPE_INT, { .i64 = 0 }, 0, INT_MAX, VE 
},   \
+{ "win_brc_size",   "sliding window size of win_max_rate", 
OFFSET(qsv.win_brc_size), AV_OPT_TYPE_INT, { .i64 = 0 }, 0, INT_MAX, VE 
},
 
 typedef int SetEncodeCtrlCB (AVCodecContext *avctx,
  const AVFrame *frame, mfxEncodeCtrl* enc_ctrl);
@@ -169,6 +171,9 @@ typedef struct QSVEncContext {
 int repeat_pps;
 int low_power;
 
+int win_brc_max_avg_kbps;
+int win_brc_size;
+
 int a53_cc;
 
 #if QSV_HAVE_MF
-- 
2.17.1

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