Re: [FFmpeg-devel] [PATCH] libavcodec/libaomenc.c: Added code for computing PSNR/SSIM for libaom encoder.Updated the patch to read the AV_PICTURE_TYPE_I flag for AOM.

[James Almer]

On 9/26/2018 10:42 PM, Sam John wrote:
> ---
>  libavcodec/libaomenc.c | 83 ++
>  1 file changed, 75 insertions(+), 8 deletions(-)
> 
> diff --git a/libavcodec/libaomenc.c b/libavcodec/libaomenc.c
> index 6a79d9b873..4e75ca0b18 100644
> --- a/libavcodec/libaomenc.c
> +++ b/libavcodec/libaomenc.c
> @@ -50,6 +50,9 @@ struct FrameListData {
>  unsigned long duration;  /**< duration to show frame
>(in timebase units) */
>  uint32_t flags;  /**< flags for this frame */
> +uint64_t sse[4];
> +int have_sse;/**< true if we have pending sse[] */
> +uint64_t frame_number;
>  struct FrameListData *next;
>  };
>  
> @@ -68,6 +71,9 @@ typedef struct AOMEncoderContext {
>  int static_thresh;
>  int drop_threshold;
>  int noise_sensitivity;
> +uint64_t sse[4];
> +int have_sse; /**< true if we have pending sse[] */
> +uint64_t frame_number;
>  } AOMContext;
>  
>  static const char *const ctlidstr[] = {
> @@ -289,7 +295,8 @@ static av_cold int aom_init(AVCodecContext *avctx,
>  {
>  AOMContext *ctx = avctx->priv_data;
>  struct aom_codec_enc_cfg enccfg = { 0 };
> -aom_codec_flags_t flags = 0;
> +aom_codec_flags_t flags =
> +(avctx->flags & AV_CODEC_FLAG_PSNR) ? AOM_CODEC_USE_PSNR : 0;
>  AVCPBProperties *cpb_props;
>  int res;
>  aom_img_fmt_t img_fmt;
> @@ -499,13 +506,23 @@ static av_cold int aom_init(AVCodecContext *avctx,
>  }
>  
>  static inline void cx_pktcpy(struct FrameListData *dst,
> - const struct aom_codec_cx_pkt *src)
> + const struct aom_codec_cx_pkt *src,
> + AOMContext *ctx)
>  {
>  dst->pts  = src->data.frame.pts;
>  dst->duration = src->data.frame.duration;
>  dst->flags= src->data.frame.flags;
>  dst->sz   = src->data.frame.sz;
>  dst->buf  = src->data.frame.buf;
> +dst->have_sse = 0;
> +dst->frame_number = ++ctx->frame_number;
> +dst->have_sse = ctx->have_sse;
> +if (ctx->have_sse) {
> +/* associate last-seen SSE to the frame. */
> +/* Transfers ownership from ctx to dst. */
> +memcpy(dst->sse, ctx->sse, sizeof(dst->sse));
> +ctx->have_sse = 0;
> +}
>  }
>  
>  /**
> @@ -519,6 +536,7 @@ static int storeframe(AVCodecContext *avctx, struct 
> FrameListData *cx_frame,
>AVPacket *pkt)
>  {
>  AOMContext *ctx = avctx->priv_data;
> +int pict_type;
>  int ret = ff_alloc_packet2(avctx, pkt, cx_frame->sz, 0);
>  if (ret < 0) {
>  av_log(avctx, AV_LOG_ERROR,
> @@ -527,11 +545,51 @@ static int storeframe(AVCodecContext *avctx, struct 
> FrameListData *cx_frame,
>  }
>  memcpy(pkt->data, cx_frame->buf, pkt->size);
>  pkt->pts = pkt->dts = cx_frame->pts;
> -
> -if (!!(cx_frame->flags & AOM_FRAME_IS_KEY))
> +FF_DISABLE_DEPRECATION_WARNINGS
> +avctx->coded_frame->pts   = cx_frame->pts;
> +avctx->coded_frame->key_frame = !!(cx_frame->flags & AOM_FRAME_IS_KEY);
> +FF_ENABLE_DEPRECATION_WARNINGS

Again please, don't add deprecated code. avctx->coded_frame is not meant
to be used in new modules, and is present in old modules only until
removal for backwards compatibility.

> +
> +if (!!(cx_frame->flags & AOM_FRAME_IS_KEY)) {
> +pict_type = AV_PICTURE_TYPE_I;
> +FF_DISABLE_DEPRECATION_WARNINGS
> +avctx->coded_frame->pict_type = pict_type;
> +FF_ENABLE_DEPRECATION_WARNINGS
>  pkt->flags |= AV_PKT_FLAG_KEY;
> +} else {
> +#ifdef AOM_FRAME_IS_INTRAONLY

Nice, glad to see this was implemented.

If no one else is against it I'm fine keeping the #else case for the
time being even if it may flag intra frames as inter in the encoder
stats since i plan on bumping the minimum required version as soon as a
new libaom release is tagged. A lot of development has taken place and
plenty of API was added that makes 1.0.0 unoptimal.

> +if (cx_frame->flags & AOM_FRAME_IS_INTRAONLY)
> +pict_type = AV_PICTURE_TYPE_I;
> +else
> +pict_type = AV_PICTURE_TYPE_P;
> +#else

Nit: You can reduce duplication by removing the two lines below and
moving the #else one line up.

> +pict_type = AV_PICTURE_TYPE_P;
> +#endif
> +
> +FF_DISABLE_DEPRECATION_WARNINGS
> +avctx->coded_frame->pict_type = pict_type;
> +FF_ENABLE_DEPRECATION_WARNINGS
> +}
>  
> -if (avctx->flags & AV_CODEC_FLAG_GLOBAL_HEADER) {
> +ff_side_data_set_encoder_stats(pkt, 0, cx_frame->sse + 1,
> +   cx_frame->have_sse ? 3 : 0, pict_type);
> +
> +if (cx_frame->have_sse) {
> +int i;
> +/* Beware of the Y/U/V/all order! */
> +FF_DISABLE_DEPRECATION_WARNINGS
> +avctx->coded_frame->error[0] = cx_frame->sse[1];
> +avctx->coded_frame->error[1] = cx_frame->sse[2];
> +

[FFmpeg-devel] [PATCH] libavcodec/libaomenc.c: Added code for computing PSNR/SSIM for libaom encoder.Updated the patch to read the AV_PICTURE_TYPE_I flag for AOM.

[Sam John]

---
 libavcodec/libaomenc.c | 83 ++
 1 file changed, 75 insertions(+), 8 deletions(-)

diff --git a/libavcodec/libaomenc.c b/libavcodec/libaomenc.c
index 6a79d9b873..4e75ca0b18 100644
--- a/libavcodec/libaomenc.c
+++ b/libavcodec/libaomenc.c
@@ -50,6 +50,9 @@ struct FrameListData {
 unsigned long duration;  /**< duration to show frame
   (in timebase units) */
 uint32_t flags;  /**< flags for this frame */
+uint64_t sse[4];
+int have_sse;/**< true if we have pending sse[] */
+uint64_t frame_number;
 struct FrameListData *next;
 };
 
@@ -68,6 +71,9 @@ typedef struct AOMEncoderContext {
 int static_thresh;
 int drop_threshold;
 int noise_sensitivity;
+uint64_t sse[4];
+int have_sse; /**< true if we have pending sse[] */
+uint64_t frame_number;
 } AOMContext;
 
 static const char *const ctlidstr[] = {
@@ -289,7 +295,8 @@ static av_cold int aom_init(AVCodecContext *avctx,
 {
 AOMContext *ctx = avctx->priv_data;
 struct aom_codec_enc_cfg enccfg = { 0 };
-aom_codec_flags_t flags = 0;
+aom_codec_flags_t flags =
+(avctx->flags & AV_CODEC_FLAG_PSNR) ? AOM_CODEC_USE_PSNR : 0;
 AVCPBProperties *cpb_props;
 int res;
 aom_img_fmt_t img_fmt;
@@ -499,13 +506,23 @@ static av_cold int aom_init(AVCodecContext *avctx,
 }
 
 static inline void cx_pktcpy(struct FrameListData *dst,
- const struct aom_codec_cx_pkt *src)
+ const struct aom_codec_cx_pkt *src,
+ AOMContext *ctx)
 {
 dst->pts  = src->data.frame.pts;
 dst->duration = src->data.frame.duration;
 dst->flags= src->data.frame.flags;
 dst->sz   = src->data.frame.sz;
 dst->buf  = src->data.frame.buf;
+dst->have_sse = 0;
+dst->frame_number = ++ctx->frame_number;
+dst->have_sse = ctx->have_sse;
+if (ctx->have_sse) {
+/* associate last-seen SSE to the frame. */
+/* Transfers ownership from ctx to dst. */
+memcpy(dst->sse, ctx->sse, sizeof(dst->sse));
+ctx->have_sse = 0;
+}
 }
 
 /**
@@ -519,6 +536,7 @@ static int storeframe(AVCodecContext *avctx, struct 
FrameListData *cx_frame,
   AVPacket *pkt)
 {
 AOMContext *ctx = avctx->priv_data;
+int pict_type;
 int ret = ff_alloc_packet2(avctx, pkt, cx_frame->sz, 0);
 if (ret < 0) {
 av_log(avctx, AV_LOG_ERROR,
@@ -527,11 +545,51 @@ static int storeframe(AVCodecContext *avctx, struct 
FrameListData *cx_frame,
 }
 memcpy(pkt->data, cx_frame->buf, pkt->size);
 pkt->pts = pkt->dts = cx_frame->pts;
-
-if (!!(cx_frame->flags & AOM_FRAME_IS_KEY))
+FF_DISABLE_DEPRECATION_WARNINGS
+avctx->coded_frame->pts   = cx_frame->pts;
+avctx->coded_frame->key_frame = !!(cx_frame->flags & AOM_FRAME_IS_KEY);
+FF_ENABLE_DEPRECATION_WARNINGS
+
+if (!!(cx_frame->flags & AOM_FRAME_IS_KEY)) {
+pict_type = AV_PICTURE_TYPE_I;
+FF_DISABLE_DEPRECATION_WARNINGS
+avctx->coded_frame->pict_type = pict_type;
+FF_ENABLE_DEPRECATION_WARNINGS
 pkt->flags |= AV_PKT_FLAG_KEY;
+} else {
+#ifdef AOM_FRAME_IS_INTRAONLY
+if (cx_frame->flags & AOM_FRAME_IS_INTRAONLY)
+pict_type = AV_PICTURE_TYPE_I;
+else
+pict_type = AV_PICTURE_TYPE_P;
+#else
+pict_type = AV_PICTURE_TYPE_P;
+#endif
+
+FF_DISABLE_DEPRECATION_WARNINGS
+avctx->coded_frame->pict_type = pict_type;
+FF_ENABLE_DEPRECATION_WARNINGS
+}
 
-if (avctx->flags & AV_CODEC_FLAG_GLOBAL_HEADER) {
+ff_side_data_set_encoder_stats(pkt, 0, cx_frame->sse + 1,
+   cx_frame->have_sse ? 3 : 0, pict_type);
+
+if (cx_frame->have_sse) {
+int i;
+/* Beware of the Y/U/V/all order! */
+FF_DISABLE_DEPRECATION_WARNINGS
+avctx->coded_frame->error[0] = cx_frame->sse[1];
+avctx->coded_frame->error[1] = cx_frame->sse[2];
+avctx->coded_frame->error[2] = cx_frame->sse[3];
+avctx->coded_frame->error[3] = 0;// alpha
+FF_ENABLE_DEPRECATION_WARNINGS
+for (i = 0; i < 3; ++i) {
+avctx->error[i] += cx_frame->sse[i + 1];
+}
+cx_frame->have_sse = 0;
+}
+
+   if (avctx->flags & AV_CODEC_FLAG_GLOBAL_HEADER) {
 ret = av_bsf_send_packet(ctx->bsf, pkt);
 if (ret < 0) {
 av_log(avctx, AV_LOG_ERROR, "extract_extradata filter "
@@ -585,7 +643,7 @@ static int queue_frames(AVCodecContext *avctx, AVPacket 
*pkt_out)
 /* avoid storing the frame when the list is empty and we 
haven't yet
  * provided a frame for output */
 av_assert0(!ctx->coded_frame_list);
-cx_pktcpy(_frame, pkt);
+cx_pktcpy(_frame, pkt, ctx);
 size = storeframe(avctx, _frame, pkt_out);
 if (size < 

Re: [FFmpeg-devel] [PATCH V1] ffmpeg: fix video_delay warning for HEVC/MPEG4 decoding

[myp...@gmail.com]

On Wed, Sep 26, 2018 at 11:36 PM Carl Eugen Hoyos 
wrote:
>
> 2018-09-26 11:49 GMT+02:00, Jun Zhao :
> > For HEVC/MPEG4, we also need video_delay from the decoder, when decoding
> > some HEVC/MPEG4 clips, got numerous log like:
> > "video_delay is larger in decoder than demuxer", similar ticket: #3711
>
> Can you provide such a hevc sample?
>
Hi, Carl:

The HEVC clips have some license  issue, so I can't provide the clips,
sorry about  this.

I use the test clips from
https://software.intel.com/en-us/stress-bitstreams-and-encoder, now is
http://vicuesoft.com/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH V2] ffmpeg: fix video_delay warning for HEVC/MPEG4 decoding

[myp...@gmail.com]

On Thu, Sep 27, 2018 at 4:09 AM Michael Niedermayer 
wrote:

> On Wed, Sep 26, 2018 at 06:03:19PM +0800, Jun Zhao wrote:
> > For HEVC/MPEG4, we also need video_delay from the decoder, when decoding
> > some HEVC/MPEG4 clips, got numerous log like:
> > "video_delay is larger in decoder than demuxer", similar ticket: #3711
>
> for mpeg4 this looks incorrect.
>
> What your patch does is simply override the "demuxer side" but the patch
> never explains why this would be the correct solution or why the demuxer
> side gets the value wrong
>
> Obviously if something (like the "demuxer side") gets a value wrong the
> obvious solution is to fix that. For H264 determining the delay is rather
> hard in some corner cases (as a result of the field that would signal the
> delay being optional and not available in all streams)
>
> So please either fix the code that is responsible for this being set
> wrong in mpeg4 or explain why we should hack around it instead of
> fixing it.
>
> thx
>
> So I need to dig in and root cause, I agree.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 4/4] lavc/h265_profile_level: Add unit test

[Mark Thompson]

Operates in the same way as the h264-levels test.
---
 libavcodec/Makefile|   1 +
 libavcodec/tests/h265_levels.c | 297 +
 tests/fate/libavcodec.mak  |   5 +
 3 files changed, 303 insertions(+)
 create mode 100644 libavcodec/tests/h265_levels.c

diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index b9cc20b5ef..0cc435d201 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -1143,6 +1143,7 @@ TESTPROGS-$(CONFIG_IIRFILTER) += iirfilter
 TESTPROGS-$(HAVE_MMX) += motion
 TESTPROGS-$(CONFIG_MPEGVIDEO) += mpeg12framerate
 TESTPROGS-$(CONFIG_H264_METADATA_BSF) += h264_levels
+TESTPROGS-$(CONFIG_HEVC_METADATA_BSF) += h265_levels
 TESTPROGS-$(CONFIG_RANGECODER)+= rangecoder
 TESTPROGS-$(CONFIG_SNOW_ENCODER)  += snowenc
 
diff --git a/libavcodec/tests/h265_levels.c b/libavcodec/tests/h265_levels.c
new file mode 100644
index 00..66d72c63a3
--- /dev/null
+++ b/libavcodec/tests/h265_levels.c
@@ -0,0 +1,297 @@
+/*
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/common.h"
+#include "libavcodec/h265_profile_level.h"
+
+static const struct {
+int width;
+int height;
+int level_idc;
+} test_sizes[] = {
+// First level usable at standard sizes, from H.265 table A.9.
+{  176,  144,  30 }, // QCIF
+{  352,  288,  60 }, // CIF
+{  640,  480,  90 }, // VGA
+{  720,  480,  90 }, // NTSC
+{  720,  576,  90 }, // PAL
+{ 1024,  768,  93 }, // XGA
+{ 1280,  720,  93 }, // 720p
+{ 1280, 1024, 120 }, // SXGA
+{ 1920, 1080, 120 }, // 1080p
+{ 2048, 1080, 120 }, // 2Kx1080
+{ 2048, 1536, 150 }, // 4XGA
+{ 3840, 2160, 150 }, // 4K
+{ 7680, 4320, 180 }, // 8K
+
+// Overly wide or tall sizes.
+{ 1,   512,  30 },
+{ 1,  1024,  63 },
+{ 1,  2048,  90 },
+{ 1,  4096, 120 },
+{ 1,  8192, 150 },
+{ 1, 16384, 180 },
+{ 1, 32768,   0 },
+{   512, 1,  30 },
+{  1024, 1,  63 },
+{  2048, 1,  90 },
+{  4096, 1, 120 },
+{  8192, 1, 150 },
+{ 16384, 1, 180 },
+{ 32768, 1,   0 },
+{  2800,   256,  93 },
+{  2816,   128, 120 },
+{   256,  4208, 120 },
+{   128,  4224, 150 },
+{  8432,   256, 150 },
+{  8448,   128, 180 },
+{   256, 16880, 180 },
+{   128, 16896,   0 },
+};
+
+static const struct {
+int width;
+int height;
+int dpb_size;
+int level_idc;
+} test_dpb[] = {
+// First level usable for some DPB sizes.
+
+// L1:   176 * 144 = 25344 <=  36864 * 3/4 = 27648
+// L2: <= 122880 * 1/4 = 30720
+{  176,  144,  8,  30 },
+{  176,  144,  9,  60 },
+
+// L2:   352 * 288 = 101376 <= 122880
+// L2.1:<= 245760 * 1/2 = 122880
+// L3:  <= 552960 * 1/4 = 138240
+{  352,  288,  6,  60 },
+{  352,  288,  7,  63 },
+{  352,  288, 13,  90 },
+
+// L3.1: 1280 * 720 = 921600 <= 983040
+// L4:   <= 2228224 * 1/2 = 1114112
+// L5:   <= 8912896 * 1/4 = 2228224
+{ 1280,  720,  6,  93 },
+{ 1280,  720, 12, 120 },
+{ 1280,  720, 16, 150 },
+
+// L5:   3840 * 2160 = 8294400 <= 8912896
+// L6: <= 35651584 * 1/4 = 8912896
+{ 3840, 2160,  6, 150 },
+{ 3840, 2160,  7, 180 },
+{ 3840, 2160, 16, 180 },
+};
+
+static const H265RawProfileTierLevel profile_main = {
+// CpbNalFactor = 1100
+.general_profile_space = 0,
+.general_profile_idc   = 1,
+.general_tier_flag = 0,
+.general_profile_compatibility_flag[1] = 1,
+};
+
+static const H265RawProfileTierLevel profile_main_12 = {
+// CpbNalFactor = 1650
+.general_profile_space = 0,
+.general_profile_idc   = 4,
+.general_tier_flag = 0,
+.general_profile_compatibility_flag[4]= 1,
+.general_max_12bit_constraint_flag= 1,
+.general_max_10bit_constraint_flag= 0,
+.general_max_8bit_constraint_flag = 0,
+.general_max_422chroma_constraint_flag= 1,
+.general_max_420chroma_constraint_flag= 1,
+

[FFmpeg-devel] [PATCH 3/4] lavc/h265_profile_level: Do not allow high tier at level < 4

[Mark Thompson]

---
 libavcodec/h265_profile_level.c | 18 --
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/libavcodec/h265_profile_level.c b/libavcodec/h265_profile_level.c
index 692252bb4d..126f8dbc2a 100644
--- a/libavcodec/h265_profile_level.c
+++ b/libavcodec/h265_profile_level.c
@@ -175,7 +175,7 @@ const H265LevelDescriptor *ff_h265_guess_level(const 
H265RawProfileTierLevel *pt
int max_dec_pic_buffering)
 {
 const H265ProfileDescriptor *profile;
-int pic_size, lbr_flag, hbr_factor;
+int pic_size, tier_flag, lbr_flag, hbr_factor;
 int i;
 
 if (ptl)
@@ -189,10 +189,13 @@ const H265LevelDescriptor *ff_h265_guess_level(const 
H265RawProfileTierLevel *pt
 
 pic_size = width * height;
 
-if (ptl)
-lbr_flag = ptl->general_lower_bit_rate_constraint_flag;
-else
-lbr_flag = profile->lower_bit_rate > 0;
+if (ptl) {
+tier_flag = ptl->general_tier_flag;
+lbr_flag  = ptl->general_lower_bit_rate_constraint_flag;
+} else {
+tier_flag = 0;
+lbr_flag  = profile->lower_bit_rate > 0;
+}
 if (profile->profile_idc == 1 || profile->profile_idc == 2) {
 hbr_factor = 1;
 } else if (profile->high_throughput) {
@@ -208,6 +211,9 @@ const H265LevelDescriptor *ff_h265_guess_level(const 
H265RawProfileTierLevel *pt
 const H265LevelDescriptor *level = _levels[i];
 int max_br, max_dpb_size;
 
+if (tier_flag && !level->max_br_high)
+continue;
+
 if (pic_size > level->max_luma_ps)
 continue;
 if (width  * width  > 8 * level->max_luma_ps)
@@ -222,7 +228,7 @@ const H265LevelDescriptor *ff_h265_guess_level(const 
H265RawProfileTierLevel *pt
 if (tile_cols > level->max_tile_cols)
 continue;
 
-if (ptl && ptl->general_tier_flag)
+if (tier_flag)
 max_br = level->max_br_high;
 else
 max_br = level->max_br_main;
-- 
2.18.0

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

[FFmpeg-devel] [PATCH 2/4] lavc/h265_profile_level: Fix DPB size calculation

[Mark Thompson]

The maxDpbPicBuf value which is used in the DPB size calculation depends
on the profile (it's usually 6, but 7 for screen-extended profiles).
---
 libavcodec/h265_profile_level.c | 86 -
 libavcodec/h265_profile_level.h |  1 +
 2 files changed, 44 insertions(+), 43 deletions(-)

diff --git a/libavcodec/h265_profile_level.c b/libavcodec/h265_profile_level.c
index 6604ca254d..692252bb4d 100644
--- a/libavcodec/h265_profile_level.c
+++ b/libavcodec/h265_profile_level.c
@@ -43,76 +43,76 @@ static const H265ProfileDescriptor h265_profiles[] = {
 // profile_idc   8bit   one-picture
 //   HT-profile  | 422chroma| lower-bit-rate
 //   |  14bit|  | 420chroma |  | CpbVclFactor MinCrScaleFactor
-//   |  |  12bit |  |  | monochrome|| CpbNalFactor|
+//   |  |  12bit |  |  | monochrome|| CpbNalFactor| maxDpbPicBuf
 //   |  |  |  10bit |  |  | intra  || | FormatCapabilityFactor
-{ "Monochrome", //  |  |  |  |  |  || | | |
-  4, 0, 2, 1, 1, 1, 1, 1, 1, 0, 0, 1,  667,  733, 1.000, 1.0 },
+{ "Monochrome", //  |  |  |  |  |  || | | |   |
+  4, 0, 2, 1, 1, 1, 1, 1, 1, 0, 0, 1,  667,  733, 1.000, 1.0, 6 },
 { "Monochrome 12",
-  4, 0, 2, 1, 0, 0, 1, 1, 1, 0, 0, 1, 1000, 1100, 1.500, 1.0 },
+  4, 0, 2, 1, 0, 0, 1, 1, 1, 0, 0, 1, 1000, 1100, 1.500, 1.0, 6 },
 { "Monochrome 16",
-  4, 0, 2, 0, 0, 0, 1, 1, 1, 0, 0, 1, 1333, 1467, 2.000, 1.0 },
+  4, 0, 2, 0, 0, 0, 1, 1, 1, 0, 0, 1, 1333, 1467, 2.000, 1.0, 6 },
 { "Main",
-  1, 0, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 1000, 1100, 1.500, 1.0 },
+  1, 0, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 1000, 1100, 1.500, 1.0, 6 },
 { "Screen-Extended Main",
-  9, 0, 1, 1, 1, 1, 1, 1, 0, 0, 0, 1, 1000, 1100, 1.500, 1.0 },
+  9, 0, 1, 1, 1, 1, 1, 1, 0, 0, 0, 1, 1000, 1100, 1.500, 1.0, 7 },
 { "Main 10",
-  2, 0, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 1000, 1100, 1.875, 1.0 },
+  2, 0, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 1000, 1100, 1.875, 1.0, 6 },
 { "Screen-Extended Main 10",
-  9, 0, 1, 1, 1, 0, 1, 1, 0, 0, 0, 1, 1000, 1100, 1.875, 1.0 },
+  9, 0, 1, 1, 1, 0, 1, 1, 0, 0, 0, 1, 1000, 1100, 1.875, 1.0, 7 },
 { "Main 12",
-  4, 0, 2, 1, 0, 0, 1, 1, 0, 0, 0, 1, 1500, 1650, 2.250, 1.0 },
+  4, 0, 2, 1, 0, 0, 1, 1, 0, 0, 0, 1, 1500, 1650, 2.250, 1.0, 6 },
 { "Main Still Picture",
-  3, 0, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 1000, 1100, 1.500, 1.0 },
+  3, 0, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 1000, 1100, 1.500, 1.0, 6 },
 { "Main 4:2:2 10",
-  4, 0, 2, 1, 1, 0, 1, 0, 0, 0, 0, 1, 1667, 1833, 2.500, 0.5 },
+  4, 0, 2, 1, 1, 0, 1, 0, 0, 0, 0, 1, 1667, 1833, 2.500, 0.5, 6 },
 { "Main 4:2:2 12",
-  4, 0, 2, 1, 0, 0, 1, 0, 0, 0, 0, 1, 2000, 2200, 3.000, 0.5 },
+  4, 0, 2, 1, 0, 0, 1, 0, 0, 0, 0, 1, 2000, 2200, 3.000, 0.5, 6 },
 { "Main 4:4:4",
-  4, 0, 2, 1, 1, 1, 0, 0, 0, 0, 0, 1, 2000, 2200, 3.000, 0.5 },
+  4, 0, 2, 1, 1, 1, 0, 0, 0, 0, 0, 1, 2000, 2200, 3.000, 0.5, 6 },
 { "High Throughput 4:4:4",
-  5, 1, 1, 1, 1, 1, 0, 0, 0, 0, 0, 1, 2000, 2200, 3.000, 0.5 },
+  5, 1, 1, 1, 1, 1, 0, 0, 0, 0, 0, 1, 2000, 2200, 3.000, 0.5, 6 },
 { "Screen-Extended Main 4:4:4",
-  9, 0, 1, 1, 1, 1, 0, 0, 0, 0, 0, 1, 2000, 2200, 3.000, 0.5 },
+  9, 0, 1, 1, 1, 1, 0, 0, 0, 0, 0, 1, 2000, 2200, 3.000, 0.5, 7 },
 { "Screen-Extended High Throughput 4:4:4",
-  9, 1, 1, 1, 1, 1, 0, 0, 0, 0, 0, 1, 2000, 2200, 3.000, 0.5 },
+  9, 1, 1, 1, 1, 1, 0, 0, 0, 0, 0, 1, 2000, 2200, 3.000, 0.5, 7 },
 { "Main 4:4:4 10",
-  4, 0, 2, 1, 1, 0, 0, 0, 0, 0, 0, 1, 2500, 2750, 3.750, 0.5 },
+  4, 0, 2, 1, 1, 0, 0, 0, 0, 0, 0, 1, 2500, 2750, 3.750, 0.5, 6 },
 { "High Throughput 4:4:4 10",
-  5, 1, 1, 1, 1, 0, 0, 0, 0, 0, 0, 1, 2500, 2750, 3.750, 0.5 },
+  5, 1, 1, 1, 1, 0, 0, 0, 0, 0, 0, 1, 2500, 2750, 3.750, 0.5, 6 },
 { "Screen-Extended Main 4:4:4 10",
-  9, 0, 1, 1, 1, 0, 0, 0, 0, 0, 0, 1, 2500, 2750, 3.750, 0.5 },
+  9, 0, 1, 1, 1, 0, 0, 0, 0, 0, 0, 1, 2500, 2750, 3.750, 0.5, 7 },
 { "Screen-Extended High Throughput 4:4:4 10",
-  9, 1, 1, 1, 1, 0, 0, 0, 0, 0, 0, 1, 2500, 2750, 3.750, 0.5 },
+  9, 1, 1, 1, 1, 0, 0, 0, 0, 0, 0, 1, 2500, 2750, 3.750, 0.5, 7 },
 { "Main 4:4:4 12",
-  4, 0, 2, 1, 0, 0, 0, 0, 0, 0, 0, 1, 3000, 3300, 4.500, 0.5 },
+  4, 0, 2, 1, 0, 0, 0, 0, 0, 0, 0, 1, 3000, 3300, 4.500, 0.5, 6 },
 { "High Throughput 4:4:4 14",
-  5, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 1, 3500, 3850, 5.250, 0.5 },
+  5, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 1, 3500, 3850, 5.250, 0.5, 6 },
 { "Screen-Extended High Throughput 4:4:4 14",
-  9, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 1, 3500, 3850, 5.250, 0.5 },
+  9, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 1, 3500, 3850, 5.250, 0.5, 7 },
 { "Main Intra",
-  4, 0, 2, 1, 1, 1, 1, 1, 0, 1, 0, 2, 1000, 1100, 1.500, 1.0 },
+  4, 0, 2, 1, 1, 1, 1, 1, 0, 1, 0, 2, 1000, 1100, 1.500, 

[FFmpeg-devel] [PATCH 1/4] fate/libavcodec: Fix config dependency of h264_levels test

[Mark Thompson]

---
 tests/fate/libavcodec.mak | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/fate/libavcodec.mak b/tests/fate/libavcodec.mak
index aa4c36b112..5dde1243fa 100644
--- a/tests/fate/libavcodec.mak
+++ b/tests/fate/libavcodec.mak
@@ -46,7 +46,7 @@ fate-dct8x8: libavcodec/tests/dct$(EXESUF)
 fate-dct8x8: CMD = run libavcodec/tests/dct
 fate-dct8x8: CMP = null
 
-FATE_LIBAVCODEC-$(CONFIG_H264_VAAPI_ENCODER) += fate-h264-levels
+FATE_LIBAVCODEC-$(CONFIG_H264_METADATA_BSF) += fate-h264-levels
 fate-h264-levels: libavcodec/tests/h264_levels$(EXESUF)
 fate-h264-levels: CMD = run libavcodec/tests/h264_levels
 fate-h264-levels: REF = /dev/null
-- 
2.18.0

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

Re: [FFmpeg-devel] [PATCH v2 2/3] lavc: Add coded bitstream read/write support for AV1

[Mark Thompson]

On 23/09/18 23:33, Mark Thompson wrote:
> On 18/09/18 01:25, James Almer wrote:
>> On 9/17/2018 8:47 PM, Mark Thompson wrote:
>>> ...
>>
>> Looks good now. Thanks!
> 
> Great.  Does anyone else have any comments?  I'll push this in two days if 
> there isn't anything further.

And pushed.

Thank you for all your help with this!

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

Re: [FFmpeg-devel] [PATCH] libavformat/segment: strftime date sub-directories

[Steven Liu]

> On Sep 27, 2018, at 06:10, Michael Niedermayer  wrote:
> 
> On Wed, Sep 26, 2018 at 10:07:58AM +0100, James Courtier-Dutton wrote:
>> On 26 September 2018 at 00:18, Steven Liu  wrote:
>> 
>>> 
>>> 
 On Sep 26, 2018, at 06:49, James Courtier-Dutton 
>>> wrote:
 On 25 September 2018 at 23:24, Steven Liu  wrote:
>>> yes, the error message is confusing, maybe change it here is better.
 
 +av_log(oc, AV_LOG_ERROR, "Could not create directory %s\n",
>>> dir);
 
>>> 
>>> 
>> Attached patch has the changed error message.
> 
>> segment.c |   15 +++
>> 1 file changed, 15 insertions(+)
>> a026d4ed5e2ba0505f93a3eece153a567707b812  
>> 0001-avformat-segment-strftime-date-sub-directories.patch
>> From 8d8ea7d1f87a77ee23b6681a714da378b5361e4d Mon Sep 17 00:00:00 2001
>> From: James Courtier-Dutton 
>> Date: Wed, 26 Sep 2018 10:05:13 +0100
>> Subject: [PATCH] avformat/segment: strftime date sub-directories
>> 
>> Automatically create sub-directories if needed based on date.
>> E.g.
>> ffmpeg ... -timelimit 2147483647 -f segment -strftime 1 -segment_time 10 
>> "%Y/%m/%d/%Y-%m-%d_%H-%M-%S.mkv"
>> 
>> Signed-off-by: James Courtier-Dutton 
>> ---
>> libavformat/segment.c | 15 +++
>> 1 file changed, 15 insertions(+)
>> 
>> diff --git a/libavformat/segment.c b/libavformat/segment.c
>> index 7fb4dc7..0e17380 100644
>> --- a/libavformat/segment.c
>> +++ b/libavformat/segment.c
>> @@ -200,12 +200,27 @@ static int set_segment_filename(AVFormatContext *s)
>> if (seg->use_strftime) {
>> time_t now0;
>> struct tm *tm, tmpbuf;
>> +const char *dir;
>> +char *fn_copy;
>> time();
>> tm = localtime_r(, );
>> if (!strftime(buf, sizeof(buf), s->url, tm)) {
>> av_log(oc, AV_LOG_ERROR, "Could not get segment filename with 
>> strftime\n");
>> return AVERROR(EINVAL);
>> }
>> +/* Automatically create directories if needed */
>> +/* E.g. %Y/%m/%d/%Y-%m-%d_%H-%M-%S.mkv */
>> +fn_copy = av_strdup(buf);
>> +if (!fn_copy) {
>> +return AVERROR(ENOMEM);
>> +}
>> +dir = av_dirname(fn_copy);
>> +if (ff_mkdir_p(dir) == -1 && errno != EEXIST) {
>> +av_log(oc, AV_LOG_ERROR, "Could not create directory %s\n", 
>> dir);
>> +av_free(fn_copy);
>> +return AVERROR(errno);
>> +}
>> +av_free(fn_copy);
> 
> How does this interact with urls that are not the file protocol ?
> 
> I see that this starts out with s->url and then seems to simply treat it as
> if it was a local file. Its quite possible iam missing something but url != 
> filename
There will have no error message, and cannot create directory on the HTTP 
server.
And the same problem is in hlsenc, I think this is a good question, let me 
think about how to fix it.
> 
> [...]
> 
> 
> -- 
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> 
> Modern terrorism, a quick summary: Need oil, start war with country that
> has oil, kill hundread thousand in war. Let country fall into chaos,
> be surprised about raise of fundamantalists. Drop more bombs, kill more
> people, be surprised about them taking revenge and drop even more bombs
> and strip your own citizens of their rights and freedoms. to be continued
> ___
> 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] [FFmpeg-cvslog] lavc/h264_levels: Avoid integer overflow in bitrate

[Mark Thompson]

On 26/09/18 23:18, Carl Eugen Hoyos wrote:
> 2018-09-27 0:15 GMT+02:00, Mark Thompson :
>> On 26/09/18 22:43, Carl Eugen Hoyos wrote:
>>> 2018-09-25 0:16 GMT+02:00, Mark Thompson :
 ffmpeg | branch: master | Mark Thompson  | Mon Sep 24
 23:03:32
 2018 +0100| [581b4125aa187f2cf848d7a27e6128573c80dc64] | committer: Mark
 Thompson

 lavc/h264_levels: Avoid integer overflow in bitrate

 Fixes CID #1439656.

> http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=581b4125aa187f2cf848d7a27e6128573c80dc64
 ---

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

 diff --git a/libavcodec/h264_levels.c b/libavcodec/h264_levels.c
 index 6b4e18a914..737b7dcf06 100644
 --- a/libavcodec/h264_levels.c
 +++ b/libavcodec/h264_levels.c
 @@ -105,7 +105,7 @@ const H264LevelDescriptor *ff_h264_guess_level(int
 profile_idc,
  if (level->constraint_set3_flag && no_cs3f)
  continue;

 -if (bitrate > level->max_br * h264_get_br_factor(profile_idc))
 +if (bitrate > (int64_t)level->max_br *
 h264_get_br_factor(profile_idc))
>>>
>>> If the overflow is possible at all (I doubt it), wouldn't it be cleaner
>>> to change the type of cpb_br_nal_factor to uint32_t?
>>
>> Some of the largest cases overflow 32-bit signed int - e.g. level 6.2 in
>> High 10 allows up to 80 * 3600 = 288000 bps.  (High profile or lower
>> doesn't have a cpbBrNalFactor large enough to hit this case.)
> 
> But max_br is already unsigned, what's wrong with making cpb_br_nal_factor
> also unsigned?

Making the whole calculation int64_t avoids the possibility that a future level 
or profile addition would cause this expression to overflow the 32-bit unsigned 
case as well and require further changes, the need for which would probably not 
be noticed immediately.  (H.265 does have cases larger than 2^32 here.)

>> I used int64_t because that's the type of bitrate, on the other side of the
>> comparison.
> 
> Does that simplify things for the compiler?

It's might be slightly better on 64-bit machines (no need to zero-extend the 
32-bit unsigned value) and slightly worse on 32-bit (additional handling of the 
top half), but I think the point above is more important.

Thanks,

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

Re: [FFmpeg-devel] [FFmpeg-cvslog] h264_metadata: Avoid integer overflow in bitrate

[Mark Thompson]

On 26/09/18 22:50, Carl Eugen Hoyos wrote:
> 2018-09-25 0:16 GMT+02:00, Mark Thompson :
>> ffmpeg | branch: master | Mark Thompson  | Mon Sep 24 
>> 22:45:50
>> 2018 +0100| [321294adb788b5e143fcec776cdf1daf79ed921c] | committer: Mark
>> Thompson
>>
>> h264_metadata: Avoid integer overflow in bitrate
>>
>> Fixes CID #1439664.
>>
>>> http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=321294adb788b5e143fcec776cdf1daf79ed921c
>> ---
>>
>>  libavcodec/h264_metadata_bsf.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/libavcodec/h264_metadata_bsf.c b/libavcodec/h264_metadata_bsf.c
>> index 991fcfa537..bf37528234 100644
>> --- a/libavcodec/h264_metadata_bsf.c
>> +++ b/libavcodec/h264_metadata_bsf.c
>> @@ -226,10 +226,10 @@ static int h264_metadata_update_sps(AVBSFContext *bsf,
>>
>>  if (sps->vui.nal_hrd_parameters_present_flag) {
>>  bit_rate =
>> (sps->vui.nal_hrd_parameters.bit_rate_value_minus1[0] + 1) *
>> - (1 << (sps->vui.nal_hrd_parameters.bit_rate_scale +
>> 6));
> 
> How can this overflow?

bit_rate_value_minus1 can be up to UINT32_MAX - 1 and bit_rate_scale can be up 
to 15, so the product can get to just under 2^53.  While that isn't valid for 
any level, the fields come from untrusted user input.

>> +(INT64_C(1) <<
>> (sps->vui.nal_hrd_parameters.bit_rate_scale + 6));
>>  } else if (sps->vui.vcl_hrd_parameters_present_flag) {
>>  bit_rate =
>> (sps->vui.vcl_hrd_parameters.bit_rate_value_minus1[0] + 1) *
>> - (1 << (sps->vui.vcl_hrd_parameters.bit_rate_scale +
>> 6));
> 
> Same here: Isn't the maximum (15+6) ?

While the first shift can't overflow, the whole expression can as noted above.  
Coverity was complaining specifically about the shift rather than the whole 
expression, so it seemed sensible to put the int64_t cast here.

>> +(INT64_C(1) <<
>> (sps->vui.vcl_hrd_parameters.bit_rate_scale + 6));
>>  // Adjust for VCL vs. NAL limits.
>>  bit_rate = bit_rate * 6 / 5;
>>  } else {

Thanks,

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

Re: [FFmpeg-devel] [PATCH 2/3] avformat/utils: Do not use "i" as a context pointer, "i" is normally the integer counter in loops

[Carl Eugen Hoyos]

2018-09-27 0:00 GMT+02:00, Michael Niedermayer :
> This avoids surprising developers. Its bad to surprise developers with
> such unexpected things.

+1

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

Re: [FFmpeg-devel] [FFmpeg-cvslog] lavc/h264_levels: Avoid integer overflow in bitrate

[Carl Eugen Hoyos]

2018-09-27 0:15 GMT+02:00, Mark Thompson :
> On 26/09/18 22:43, Carl Eugen Hoyos wrote:
>> 2018-09-25 0:16 GMT+02:00, Mark Thompson :
>>> ffmpeg | branch: master | Mark Thompson  | Mon Sep 24
>>> 23:03:32
>>> 2018 +0100| [581b4125aa187f2cf848d7a27e6128573c80dc64] | committer: Mark
>>> Thompson
>>>
>>> lavc/h264_levels: Avoid integer overflow in bitrate
>>>
>>> Fixes CID #1439656.
>>>
 http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=581b4125aa187f2cf848d7a27e6128573c80dc64
>>> ---
>>>
>>>  libavcodec/h264_levels.c | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/libavcodec/h264_levels.c b/libavcodec/h264_levels.c
>>> index 6b4e18a914..737b7dcf06 100644
>>> --- a/libavcodec/h264_levels.c
>>> +++ b/libavcodec/h264_levels.c
>>> @@ -105,7 +105,7 @@ const H264LevelDescriptor *ff_h264_guess_level(int
>>> profile_idc,
>>>  if (level->constraint_set3_flag && no_cs3f)
>>>  continue;
>>>
>>> -if (bitrate > level->max_br * h264_get_br_factor(profile_idc))
>>> +if (bitrate > (int64_t)level->max_br *
>>> h264_get_br_factor(profile_idc))
>>
>> If the overflow is possible at all (I doubt it), wouldn't it be cleaner
>> to change the type of cpb_br_nal_factor to uint32_t?
>
> Some of the largest cases overflow 32-bit signed int - e.g. level 6.2 in
> High 10 allows up to 80 * 3600 = 288000 bps.  (High profile or lower
> doesn't have a cpbBrNalFactor large enough to hit this case.)

But max_br is already unsigned, what's wrong with making cpb_br_nal_factor
also unsigned?

> I used int64_t because that's the type of bitrate, on the other side of the
> comparison.

Does that simplify things for the compiler?

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

Re: [FFmpeg-devel] [PATCH 2/3] avformat/utils: Do not use "i" as a context pointer, "i" is normally the integer counter in loops

[James Almer]

On 9/26/2018 7:00 PM, Michael Niedermayer wrote:
> This avoids surprising developers. Its bad to surprise developers with
> such unexpected things.
> 
> Signed-off-by: Michael Niedermayer 
> ---
>  libavformat/utils.c | 42 +-
>  1 file changed, 21 insertions(+), 21 deletions(-)
> 
> diff --git a/libavformat/utils.c b/libavformat/utils.c
> index 7e5783c14c..c1835b1ab5 100644
> --- a/libavformat/utils.c
> +++ b/libavformat/utils.c
> @@ -3461,7 +3461,7 @@ static int extract_extradata_check(AVStream *st)
>  
>  static int extract_extradata_init(AVStream *st)
>  {
> -AVStreamInternal *i = st->internal;
> +AVStreamInternal *avsti = st->internal;

How about sti instead? AVStream is usually set as st.

>  const AVBitStreamFilter *f;
>  int ret;
>  
> @@ -3474,66 +3474,66 @@ static int extract_extradata_init(AVStream *st)
>  if (!ret)
>  goto finish;
>  
> -i->extract_extradata.pkt = av_packet_alloc();
> -if (!i->extract_extradata.pkt)
> +avsti->extract_extradata.pkt = av_packet_alloc();
> +if (!avsti->extract_extradata.pkt)
>  return AVERROR(ENOMEM);
>  
> -ret = av_bsf_alloc(f, >extract_extradata.bsf);
> +ret = av_bsf_alloc(f, >extract_extradata.bsf);
>  if (ret < 0)
>  goto fail;
>  
> -ret = avcodec_parameters_copy(i->extract_extradata.bsf->par_in,
> +ret = avcodec_parameters_copy(avsti->extract_extradata.bsf->par_in,
>st->codecpar);
>  if (ret < 0)
>  goto fail;
>  
> -i->extract_extradata.bsf->time_base_in = st->time_base;
> +avsti->extract_extradata.bsf->time_base_in = st->time_base;
>  
> -ret = av_bsf_init(i->extract_extradata.bsf);
> +ret = av_bsf_init(avsti->extract_extradata.bsf);
>  if (ret < 0)
>  goto fail;
>  
>  finish:
> -i->extract_extradata.inited = 1;
> +avsti->extract_extradata.inited = 1;
>  
>  return 0;
>  fail:
> -av_bsf_free(>extract_extradata.bsf);
> -av_packet_free(>extract_extradata.pkt);
> +av_bsf_free(>extract_extradata.bsf);
> +av_packet_free(>extract_extradata.pkt);
>  return ret;
>  }
>  
>  static int extract_extradata(AVStream *st, AVPacket *pkt)
>  {
> -AVStreamInternal *i = st->internal;
> +AVStreamInternal *avsti = st->internal;
>  AVPacket *pkt_ref;
>  int ret;
>  
> -if (!i->extract_extradata.inited) {
> +if (!avsti->extract_extradata.inited) {
>  ret = extract_extradata_init(st);
>  if (ret < 0)
>  return ret;
>  }
>  
> -if (i->extract_extradata.inited && !i->extract_extradata.bsf)
> +if (avsti->extract_extradata.inited && !avsti->extract_extradata.bsf)
>  return 0;
>  
> -pkt_ref = i->extract_extradata.pkt;
> +pkt_ref = avsti->extract_extradata.pkt;
>  ret = av_packet_ref(pkt_ref, pkt);
>  if (ret < 0)
>  return ret;
>  
> -ret = av_bsf_send_packet(i->extract_extradata.bsf, pkt_ref);
> +ret = av_bsf_send_packet(avsti->extract_extradata.bsf, pkt_ref);
>  if (ret < 0) {
>  av_packet_unref(pkt_ref);
>  return ret;
>  }
>  
> -while (ret >= 0 && !i->avctx->extradata) {
> +while (ret >= 0 && !avsti->avctx->extradata) {
>  int extradata_size;
>  uint8_t *extradata;
>  
> -ret = av_bsf_receive_packet(i->extract_extradata.bsf, pkt_ref);
> +ret = av_bsf_receive_packet(avsti->extract_extradata.bsf, pkt_ref);
>  if (ret < 0) {
>  if (ret != AVERROR(EAGAIN) && ret != AVERROR_EOF)
>  return ret;
> @@ -3544,13 +3544,13 @@ static int extract_extradata(AVStream *st, AVPacket 
> *pkt)
>  _size);
>  
>  if (extradata) {
> -i->avctx->extradata = av_mallocz(extradata_size + 
> AV_INPUT_BUFFER_PADDING_SIZE);
> -if (!i->avctx->extradata) {
> +avsti->avctx->extradata = av_mallocz(extradata_size + 
> AV_INPUT_BUFFER_PADDING_SIZE);
> +if (!avsti->avctx->extradata) {
>  av_packet_unref(pkt_ref);
>  return AVERROR(ENOMEM);
>  }
> -memcpy(i->avctx->extradata, extradata, extradata_size);
> -i->avctx->extradata_size = extradata_size;
> +memcpy(avsti->avctx->extradata, extradata, extradata_size);
> +avsti->avctx->extradata_size = extradata_size;
>  }
>  av_packet_unref(pkt_ref);
>  }

This is going to make eventual merges a pain, but ok.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [FFmpeg-cvslog] lavc/h264_levels: Avoid integer overflow in bitrate

[Mark Thompson]

On 26/09/18 22:43, Carl Eugen Hoyos wrote:
> 2018-09-25 0:16 GMT+02:00, Mark Thompson :
>> ffmpeg | branch: master | Mark Thompson  | Mon Sep 24 
>> 23:03:32
>> 2018 +0100| [581b4125aa187f2cf848d7a27e6128573c80dc64] | committer: Mark
>> Thompson
>>
>> lavc/h264_levels: Avoid integer overflow in bitrate
>>
>> Fixes CID #1439656.
>>
>>> http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=581b4125aa187f2cf848d7a27e6128573c80dc64
>> ---
>>
>>  libavcodec/h264_levels.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/libavcodec/h264_levels.c b/libavcodec/h264_levels.c
>> index 6b4e18a914..737b7dcf06 100644
>> --- a/libavcodec/h264_levels.c
>> +++ b/libavcodec/h264_levels.c
>> @@ -105,7 +105,7 @@ const H264LevelDescriptor *ff_h264_guess_level(int
>> profile_idc,
>>  if (level->constraint_set3_flag && no_cs3f)
>>  continue;
>>
>> -if (bitrate > level->max_br * h264_get_br_factor(profile_idc))
>> +if (bitrate > (int64_t)level->max_br *
>> h264_get_br_factor(profile_idc))
> 
> If the overflow is possible at all (I doubt it), wouldn't it be cleaner
> to change the type of cpb_br_nal_factor to uint32_t?

Some of the largest cases overflow 32-bit signed int - e.g. level 6.2 in High 
10 allows up to 80 * 3600 = 288000 bps.  (High profile or lower doesn't 
have a cpbBrNalFactor large enough to hit this case.)

I used int64_t because that's the type of bitrate, on the other side of the 
comparison.

Thanks,

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

Re: [FFmpeg-devel] [PATCH 3/3] avformat/utils: Fix potential integer overflow in extract_extradata()

[James Almer]

On 9/26/2018 7:00 PM, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer 
> ---
>  libavformat/utils.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/libavformat/utils.c b/libavformat/utils.c
> index c1835b1ab5..3e99478ad9 100644
> --- a/libavformat/utils.c
> +++ b/libavformat/utils.c
> @@ -3544,7 +3544,9 @@ static int extract_extradata(AVStream *st, AVPacket 
> *pkt)
>  _size);
>  
>  if (extradata) {
> -avsti->avctx->extradata = av_mallocz(extradata_size + 
> AV_INPUT_BUFFER_PADDING_SIZE);
> +av_assert0(!avsti->avctx->extradata);
> +if ((unsigned)extradata_size <= INT_MAX - 
> AV_INPUT_BUFFER_PADDING_SIZE)
> +avsti->avctx->extradata = av_mallocz(extradata_size + 
> AV_INPUT_BUFFER_PADDING_SIZE);

There's a FF_MAX_EXTRADATA_SIZE define in internal.h

>  if (!avsti->avctx->extradata) {
>  av_packet_unref(pkt_ref);
>  return AVERROR(ENOMEM);
> 

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

Re: [FFmpeg-devel] [PATCH] libavformat/segment: strftime date sub-directories

[Michael Niedermayer]

On Wed, Sep 26, 2018 at 10:07:58AM +0100, James Courtier-Dutton wrote:
> On 26 September 2018 at 00:18, Steven Liu  wrote:
> 
> >
> >
> > > On Sep 26, 2018, at 06:49, James Courtier-Dutton 
> > wrote:
> > > On 25 September 2018 at 23:24, Steven Liu  wrote:
> > yes, the error message is confusing, maybe change it here is better.
> > >
> > > +av_log(oc, AV_LOG_ERROR, "Could not create directory %s\n",
> > dir);
> > >
> >
> >
> Attached patch has the changed error message.

>  segment.c |   15 +++
>  1 file changed, 15 insertions(+)
> a026d4ed5e2ba0505f93a3eece153a567707b812  
> 0001-avformat-segment-strftime-date-sub-directories.patch
> From 8d8ea7d1f87a77ee23b6681a714da378b5361e4d Mon Sep 17 00:00:00 2001
> From: James Courtier-Dutton 
> Date: Wed, 26 Sep 2018 10:05:13 +0100
> Subject: [PATCH] avformat/segment: strftime date sub-directories
> 
> Automatically create sub-directories if needed based on date.
> E.g.
> ffmpeg ... -timelimit 2147483647 -f segment -strftime 1 -segment_time 10 
> "%Y/%m/%d/%Y-%m-%d_%H-%M-%S.mkv"
> 
> Signed-off-by: James Courtier-Dutton 
> ---
>  libavformat/segment.c | 15 +++
>  1 file changed, 15 insertions(+)
> 
> diff --git a/libavformat/segment.c b/libavformat/segment.c
> index 7fb4dc7..0e17380 100644
> --- a/libavformat/segment.c
> +++ b/libavformat/segment.c
> @@ -200,12 +200,27 @@ static int set_segment_filename(AVFormatContext *s)
>  if (seg->use_strftime) {
>  time_t now0;
>  struct tm *tm, tmpbuf;
> +const char *dir;
> +char *fn_copy;
>  time();
>  tm = localtime_r(, );
>  if (!strftime(buf, sizeof(buf), s->url, tm)) {
>  av_log(oc, AV_LOG_ERROR, "Could not get segment filename with 
> strftime\n");
>  return AVERROR(EINVAL);
>  }
> +/* Automatically create directories if needed */
> +/* E.g. %Y/%m/%d/%Y-%m-%d_%H-%M-%S.mkv */
> +fn_copy = av_strdup(buf);
> +if (!fn_copy) {
> +return AVERROR(ENOMEM);
> +}
> +dir = av_dirname(fn_copy);
> +if (ff_mkdir_p(dir) == -1 && errno != EEXIST) {
> +av_log(oc, AV_LOG_ERROR, "Could not create directory %s\n", dir);
> +av_free(fn_copy);
> +return AVERROR(errno);
> +}
> +av_free(fn_copy);

How does this interact with urls that are not the file protocol ?

I see that this starts out with s->url and then seems to simply treat it as
if it was a local file. Its quite possible iam missing something but url != 
filename

[...]


-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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

[FFmpeg-devel] [PATCH 2/3] avformat/utils: Do not use "i" as a context pointer, "i" is normally the integer counter in loops

[Michael Niedermayer]

This avoids surprising developers. Its bad to surprise developers with
such unexpected things.

Signed-off-by: Michael Niedermayer 
---
 libavformat/utils.c | 42 +-
 1 file changed, 21 insertions(+), 21 deletions(-)

diff --git a/libavformat/utils.c b/libavformat/utils.c
index 7e5783c14c..c1835b1ab5 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -3461,7 +3461,7 @@ static int extract_extradata_check(AVStream *st)
 
 static int extract_extradata_init(AVStream *st)
 {
-AVStreamInternal *i = st->internal;
+AVStreamInternal *avsti = st->internal;
 const AVBitStreamFilter *f;
 int ret;
 
@@ -3474,66 +3474,66 @@ static int extract_extradata_init(AVStream *st)
 if (!ret)
 goto finish;
 
-i->extract_extradata.pkt = av_packet_alloc();
-if (!i->extract_extradata.pkt)
+avsti->extract_extradata.pkt = av_packet_alloc();
+if (!avsti->extract_extradata.pkt)
 return AVERROR(ENOMEM);
 
-ret = av_bsf_alloc(f, >extract_extradata.bsf);
+ret = av_bsf_alloc(f, >extract_extradata.bsf);
 if (ret < 0)
 goto fail;
 
-ret = avcodec_parameters_copy(i->extract_extradata.bsf->par_in,
+ret = avcodec_parameters_copy(avsti->extract_extradata.bsf->par_in,
   st->codecpar);
 if (ret < 0)
 goto fail;
 
-i->extract_extradata.bsf->time_base_in = st->time_base;
+avsti->extract_extradata.bsf->time_base_in = st->time_base;
 
-ret = av_bsf_init(i->extract_extradata.bsf);
+ret = av_bsf_init(avsti->extract_extradata.bsf);
 if (ret < 0)
 goto fail;
 
 finish:
-i->extract_extradata.inited = 1;
+avsti->extract_extradata.inited = 1;
 
 return 0;
 fail:
-av_bsf_free(>extract_extradata.bsf);
-av_packet_free(>extract_extradata.pkt);
+av_bsf_free(>extract_extradata.bsf);
+av_packet_free(>extract_extradata.pkt);
 return ret;
 }
 
 static int extract_extradata(AVStream *st, AVPacket *pkt)
 {
-AVStreamInternal *i = st->internal;
+AVStreamInternal *avsti = st->internal;
 AVPacket *pkt_ref;
 int ret;
 
-if (!i->extract_extradata.inited) {
+if (!avsti->extract_extradata.inited) {
 ret = extract_extradata_init(st);
 if (ret < 0)
 return ret;
 }
 
-if (i->extract_extradata.inited && !i->extract_extradata.bsf)
+if (avsti->extract_extradata.inited && !avsti->extract_extradata.bsf)
 return 0;
 
-pkt_ref = i->extract_extradata.pkt;
+pkt_ref = avsti->extract_extradata.pkt;
 ret = av_packet_ref(pkt_ref, pkt);
 if (ret < 0)
 return ret;
 
-ret = av_bsf_send_packet(i->extract_extradata.bsf, pkt_ref);
+ret = av_bsf_send_packet(avsti->extract_extradata.bsf, pkt_ref);
 if (ret < 0) {
 av_packet_unref(pkt_ref);
 return ret;
 }
 
-while (ret >= 0 && !i->avctx->extradata) {
+while (ret >= 0 && !avsti->avctx->extradata) {
 int extradata_size;
 uint8_t *extradata;
 
-ret = av_bsf_receive_packet(i->extract_extradata.bsf, pkt_ref);
+ret = av_bsf_receive_packet(avsti->extract_extradata.bsf, pkt_ref);
 if (ret < 0) {
 if (ret != AVERROR(EAGAIN) && ret != AVERROR_EOF)
 return ret;
@@ -3544,13 +3544,13 @@ static int extract_extradata(AVStream *st, AVPacket 
*pkt)
 _size);
 
 if (extradata) {
-i->avctx->extradata = av_mallocz(extradata_size + 
AV_INPUT_BUFFER_PADDING_SIZE);
-if (!i->avctx->extradata) {
+avsti->avctx->extradata = av_mallocz(extradata_size + 
AV_INPUT_BUFFER_PADDING_SIZE);
+if (!avsti->avctx->extradata) {
 av_packet_unref(pkt_ref);
 return AVERROR(ENOMEM);
 }
-memcpy(i->avctx->extradata, extradata, extradata_size);
-i->avctx->extradata_size = extradata_size;
+memcpy(avsti->avctx->extradata, extradata, extradata_size);
+avsti->avctx->extradata_size = extradata_size;
 }
 av_packet_unref(pkt_ref);
 }
-- 
2.19.0

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

[FFmpeg-devel] [PATCH 3/3] avformat/utils: Fix potential integer overflow in extract_extradata()

[Michael Niedermayer]

Signed-off-by: Michael Niedermayer 
---
 libavformat/utils.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/libavformat/utils.c b/libavformat/utils.c
index c1835b1ab5..3e99478ad9 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -3544,7 +3544,9 @@ static int extract_extradata(AVStream *st, AVPacket *pkt)
 _size);
 
 if (extradata) {
-avsti->avctx->extradata = av_mallocz(extradata_size + 
AV_INPUT_BUFFER_PADDING_SIZE);
+av_assert0(!avsti->avctx->extradata);
+if ((unsigned)extradata_size <= INT_MAX - 
AV_INPUT_BUFFER_PADDING_SIZE)
+avsti->avctx->extradata = av_mallocz(extradata_size + 
AV_INPUT_BUFFER_PADDING_SIZE);
 if (!avsti->avctx->extradata) {
 av_packet_unref(pkt_ref);
 return AVERROR(ENOMEM);
-- 
2.19.0

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

[FFmpeg-devel] [PATCH 1/3] avformat/utils: Do not ignore failure in extract_extradata_init()

[Michael Niedermayer]

We check for the documented explanation of the "Ignore code" in 
extract_extradata_check() already

Signed-off-by: Michael Niedermayer 
---
 libavformat/utils.c | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/libavformat/utils.c b/libavformat/utils.c
index c973a7e0c5..7e5783c14c 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -3489,13 +3489,9 @@ static int extract_extradata_init(AVStream *st)
 
 i->extract_extradata.bsf->time_base_in = st->time_base;
 
-/* if init fails here, we assume extracting extradata is just not
- * supported for this codec, so we return success */
 ret = av_bsf_init(i->extract_extradata.bsf);
-if (ret < 0) {
-av_bsf_free(>extract_extradata.bsf);
-ret = 0;
-}
+if (ret < 0)
+goto fail;
 
 finish:
 i->extract_extradata.inited = 1;
-- 
2.19.0

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

Re: [FFmpeg-devel] [FFmpeg-cvslog] h264_metadata: Avoid integer overflow in bitrate

[Carl Eugen Hoyos]

2018-09-25 0:16 GMT+02:00, Mark Thompson :
> ffmpeg | branch: master | Mark Thompson  | Mon Sep 24 22:45:50
> 2018 +0100| [321294adb788b5e143fcec776cdf1daf79ed921c] | committer: Mark
> Thompson
>
> h264_metadata: Avoid integer overflow in bitrate
>
> Fixes CID #1439664.
>
>> http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=321294adb788b5e143fcec776cdf1daf79ed921c
> ---
>
>  libavcodec/h264_metadata_bsf.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/h264_metadata_bsf.c b/libavcodec/h264_metadata_bsf.c
> index 991fcfa537..bf37528234 100644
> --- a/libavcodec/h264_metadata_bsf.c
> +++ b/libavcodec/h264_metadata_bsf.c
> @@ -226,10 +226,10 @@ static int h264_metadata_update_sps(AVBSFContext *bsf,
>
>  if (sps->vui.nal_hrd_parameters_present_flag) {
>  bit_rate =
> (sps->vui.nal_hrd_parameters.bit_rate_value_minus1[0] + 1) *
> - (1 << (sps->vui.nal_hrd_parameters.bit_rate_scale +
> 6));

How can this overflow?

> +(INT64_C(1) <<
> (sps->vui.nal_hrd_parameters.bit_rate_scale + 6));
>  } else if (sps->vui.vcl_hrd_parameters_present_flag) {
>  bit_rate =
> (sps->vui.vcl_hrd_parameters.bit_rate_value_minus1[0] + 1) *
> - (1 << (sps->vui.vcl_hrd_parameters.bit_rate_scale +
> 6));

Same here: Isn't the maximum (15+6) ?

> +(INT64_C(1) <<
> (sps->vui.vcl_hrd_parameters.bit_rate_scale + 6));
>  // Adjust for VCL vs. NAL limits.
>  bit_rate = bit_rate * 6 / 5;
>  } else {

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

Re: [FFmpeg-devel] [FFmpeg-cvslog] lavc/h264_levels: Avoid integer overflow in bitrate

[Carl Eugen Hoyos]

2018-09-25 0:16 GMT+02:00, Mark Thompson :
> ffmpeg | branch: master | Mark Thompson  | Mon Sep 24 23:03:32
> 2018 +0100| [581b4125aa187f2cf848d7a27e6128573c80dc64] | committer: Mark
> Thompson
>
> lavc/h264_levels: Avoid integer overflow in bitrate
>
> Fixes CID #1439656.
>
>> http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=581b4125aa187f2cf848d7a27e6128573c80dc64
> ---
>
>  libavcodec/h264_levels.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/h264_levels.c b/libavcodec/h264_levels.c
> index 6b4e18a914..737b7dcf06 100644
> --- a/libavcodec/h264_levels.c
> +++ b/libavcodec/h264_levels.c
> @@ -105,7 +105,7 @@ const H264LevelDescriptor *ff_h264_guess_level(int
> profile_idc,
>  if (level->constraint_set3_flag && no_cs3f)
>  continue;
>
> -if (bitrate > level->max_br * h264_get_br_factor(profile_idc))
> +if (bitrate > (int64_t)level->max_br *
> h264_get_br_factor(profile_idc))

If the overflow is possible at all (I doubt it), wouldn't it be cleaner
to change the type of cpb_br_nal_factor to uint32_t?

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

Re: [FFmpeg-devel] [PATCH]lavf/matroskadec: Simplify string length calculation slightly

[Carl Eugen Hoyos]

2018-09-19 19:18 GMT+02:00, Carl Eugen Hoyos :

> Attached patch removes useless sizeof's, we require sizeof(char)==1 afaict.

I will push this if there are no objections.

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

Re: [FFmpeg-devel] [PATCH]lavf/mpeg: Allow demuxing hevc

[Jan Ekström]

On Wed, Sep 26, 2018 at 11:46 PM, Carl Eugen Hoyos  wrote:
> Hi!
>
> A HandBrake user provided a program stream with hevc, attached
> patch allows demuxing without auto-detection.
>
> Please comment, Carl Eugen
>

Verified that the identifier matches ITU-T H.222 2014/10 (and what's
in mpegts.{c,h}).

> An HEVC video stream or HEVC temporal video sub-bitstream shall be an element 
> of an ITU-T H.222.0 |
> ISO/IEC 13818-1 program and the stream_type for this elementary stream shall 
> be equal to 0x24.

Not sure if another part of the specification notes that this should
only be utilized in MPEG-TS, but since we also have the AVC/H.264
identifier in MPEG-PS I would guess it's OK?

In general it seems like at least a few of these identifiers are
shared between both MPEG-2 Systems formats, so we might want to merge
the matching ones into a single shared list.

Best regards,
Jan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avdevice/decklink: Add option to align Capture start time

[Marton Balint]

On Tue, 25 Sep 2018, Jeyapal, Karthick wrote:



On 9/24/18 7:42 PM, Devin Heitmueller wrote:

Hello Karthick,



On Sep 24, 2018, at 7:49 AM, Karthick J  wrote:

From: Karthick Jeyapal 

This option is useful for maintaining input synchronization across N
different hardware devices deployed for 'N-way' redundancy.
The system time of different hardware devices should be synchronized
with protocols such as NTP or PTP, before using this option.


I can certainly see the usefulness of such a feature, but is the 
decklink module really the right place for this?  This feels like 
something that should be done through a filter (either as a multimedia 
filter or a BSF).

Hi Devin,

Thank you very much for the feedback. I agree with you that if it can be 
done through a filter, then it is certainly a better place to do it. But 
I as far I understand it can't be implemented reliably in a filter, 
without imposing additional restrictions and/or added complexities. This 
is primarily due to the fact the frames might take different times to 
pass through the pipeline thread in each hardware and reach the filter 
function at different times and hence losing some synchronization w.r.t 
system time. In other words, some modules in the pipeline contains CPU 
intensive code(such as video decode), before it reaches the filter 
function. The thread that needs to do this should be very lightweight 
without any CPU intensive operations. And for better reliability it 
needs to be done as soon as the frame is received from the driver. For 
example, the video frame(captured by decklink device) could take 
different times to pass through V210 decoder due to HW differences 
and/or CPU load due to other encoder threads. This unpredictable decoder 
delay kind of rules out multimedia filters for this kind of operation. 
Now a bitstream filter(BSF) can mitigate this issue to some extent as it 
sits before a decoder. We will still need to insert a thread(and 
associated buffering) in the BSF, so that the decoder is decoupled from 
this time-sensitive thread. But still it doesn't provide any guarantee 
against CPU intensive operations performed in the capture plugin. For 
example, the Decklink plugin performs some VANC processing which could 
be CPU intensive in a low-end 2-core Intel processor. Or even if we 
assume Decklink plugin doesn't perform any CPU intensive operations, we 
cannot guarantee the same for other capture device plugins. Another 
option to implement this in filters would be to use "copyts" and drop 
the frames based of PTS/DTS value instead of system time. But then this 
imposes a restriction that "copyts" needs to be used mandatorily. If 
somebody needs to use it without "copyts", then it won't work. My 
understanding on ffmpeg is limited, and hence the above explanation may 
not be entirely correct. So, please feel free to correct me.


How about adding such an option to ffmpeg.c? You still can use wallclock 
timestamps in decklink, and then drop the frames (packets) in ffmpeg.c 
before the timestamps are touched.


Another approch might be to store the wallclock frame time as some kind of 
metadata (as it is done for "timecode") and then add the possiblity to 
f_select to drop based on this. However the evaluation engine has no 
concept of complex objects (like frame, or frame metadata) so this 
probably needs additional work.


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

[FFmpeg-devel] [PATCH]lavf/mpeg: Allow demuxing hevc

[Carl Eugen Hoyos]

Hi!

A HandBrake user provided a program stream with hevc, attached
patch allows demuxing without auto-detection.

Please comment, Carl Eugen
From c0d3208edbf2243fd7c554e1ac0fa0afe0591778 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Wed, 26 Sep 2018 22:39:18 +0200
Subject: [PATCH] lavf/mpeg: Support demuxing HEVC in mpeg-ps.

---
 libavformat/mpeg.c |3 +++
 libavformat/mpeg.h |1 +
 2 files changed, 4 insertions(+)

diff --git a/libavformat/mpeg.c b/libavformat/mpeg.c
index 159ea41..d4369b4 100644
--- a/libavformat/mpeg.c
+++ b/libavformat/mpeg.c
@@ -544,6 +544,9 @@ redo:
 } else if (es_type == STREAM_TYPE_VIDEO_H264) {
 codec_id = AV_CODEC_ID_H264;
 type = AVMEDIA_TYPE_VIDEO;
+} else if (es_type == STREAM_TYPE_VIDEO_HEVC) {
+codec_id = AV_CODEC_ID_HEVC;
+type = AVMEDIA_TYPE_VIDEO;
 } else if (es_type == STREAM_TYPE_AUDIO_AC3) {
 codec_id = AV_CODEC_ID_AC3;
 type = AVMEDIA_TYPE_AUDIO;
diff --git a/libavformat/mpeg.h b/libavformat/mpeg.h
index 617e36c..b635295 100644
--- a/libavformat/mpeg.h
+++ b/libavformat/mpeg.h
@@ -55,6 +55,7 @@
 #define STREAM_TYPE_AUDIO_AAC   0x0f
 #define STREAM_TYPE_VIDEO_MPEG4 0x10
 #define STREAM_TYPE_VIDEO_H264  0x1b
+#define STREAM_TYPE_VIDEO_HEVC  0x24
 #define STREAM_TYPE_VIDEO_CAVS  0x42
 
 #define STREAM_TYPE_AUDIO_AC3   0x81
-- 
1.7.10.4

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

Re: [FFmpeg-devel] [PATCH V2] ffmpeg: fix video_delay warning for HEVC/MPEG4 decoding

[Michael Niedermayer]

On Wed, Sep 26, 2018 at 06:03:19PM +0800, Jun Zhao wrote:
> For HEVC/MPEG4, we also need video_delay from the decoder, when decoding
> some HEVC/MPEG4 clips, got numerous log like:
> "video_delay is larger in decoder than demuxer", similar ticket: #3711

for mpeg4 this looks incorrect. 

What your patch does is simply override the "demuxer side" but the patch
never explains why this would be the correct solution or why the demuxer
side gets the value wrong

Obviously if something (like the "demuxer side") gets a value wrong the
obvious solution is to fix that. For H264 determining the delay is rather
hard in some corner cases (as a result of the field that would signal the
delay being optional and not available in all streams) 

So please either fix the code that is responsible for this being set
wrong in mpeg4 or explain why we should hack around it instead of
fixing it.

thx

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

Take away the freedom of one citizen and you will be jailed, take away
the freedom of all citizens and you will be congratulated by your peers
in Parliament.


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

Re: [FFmpeg-devel] [PATCH 1/4] avformat/matroskaenc: remove unnecessary additional codec tags

[Carl Eugen Hoyos]

2018-09-21 23:29 GMT+02:00, James Almer :
> They are listed in riff.c already.
>
> Signed-off-by: James Almer 
> ---
>  libavformat/matroskaenc.c | 3 ---
>  1 file changed, 3 deletions(-)
>
> diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
> index a0e2f426f7..61efe2e3f8 100644
> --- a/libavformat/matroskaenc.c
> +++ b/libavformat/matroskaenc.c
> @@ -2735,7 +2735,6 @@ static int mkv_check_bitstream(struct AVFormatContext
> *s, const AVPacket *pkt)
>
>  static const AVCodecTag additional_audio_tags[] = {
>  { AV_CODEC_ID_ALAC,  0X },
> -{ AV_CODEC_ID_EAC3,  0X },
>  { AV_CODEC_ID_MLP,   0x },
>  { AV_CODEC_ID_OPUS,  0x },
>  { AV_CODEC_ID_PCM_S16BE, 0x },
> @@ -2754,8 +2753,6 @@ static const AVCodecTag additional_video_tags[] = {
>  { AV_CODEC_ID_RV10,  0x },
>  { AV_CODEC_ID_RV20,  0x },
>  { AV_CODEC_ID_RV30,  0x },
> -{ AV_CODEC_ID_RV40,  0x },
> -{ AV_CODEC_ID_VP9,   0x },
>  { AV_CODEC_ID_NONE,  0x }

No objections, sorry for the delay.

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

Re: [FFmpeg-devel] [PATCH] libaomdec: add row_mt option

[Tristan Matthews]

On Wed, Sep 26, 2018 at 9:43 AM Hendrik Leppkes  wrote:

> On Wed, Sep 26, 2018 at 2:27 PM Tristan Matthews 
> wrote:
> >
> > Partially fixes #7456
> > ---
>
> row-mt is enabled by default in recent libaom versions, and they even
> removed the option for it from aomdec, so do we really need that
> option?
>

I'm fine with dropping the option (unless someone has a good reason for
wanting to disable row_mt), but I'd still suggest doing the explicit codec
control call.

Best,
Tristan


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

Re: [FFmpeg-devel] [PATCH 1/4] avformat/matroskaenc: remove unnecessary additional codec tags

[James Almer]

On 9/21/2018 8:01 PM, James Almer wrote:
> On 9/21/2018 7:44 PM, Carl Eugen Hoyos wrote:
>>
>>
>>> Am 21.09.2018 um 23:29 schrieb James Almer :
>>>
>>> They are listed in riff.c already.
>>>
>>> Signed-off-by: James Almer 
>>> ---
>>> libavformat/matroskaenc.c | 3 ---
>>> 1 file changed, 3 deletions(-)
>>>
>>> diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
>>> index a0e2f426f7..61efe2e3f8 100644
>>> --- a/libavformat/matroskaenc.c
>>> +++ b/libavformat/matroskaenc.c
>>> @@ -2735,7 +2735,6 @@ static int mkv_check_bitstream(struct AVFormatContext 
>>> *s, const AVPacket *pkt)
>>>
>>> static const AVCodecTag additional_audio_tags[] = {
>>> { AV_CODEC_ID_ALAC,  0X },
>>> -{ AV_CODEC_ID_EAC3,  0X },
>>> { AV_CODEC_ID_MLP,   0x },
>>> { AV_CODEC_ID_OPUS,  0x },
>>> { AV_CODEC_ID_PCM_S16BE, 0x },
>>> @@ -2754,8 +2753,6 @@ static const AVCodecTag additional_video_tags[] = {
>>> { AV_CODEC_ID_RV10,  0x },
>>> { AV_CODEC_ID_RV20,  0x },
>>> { AV_CODEC_ID_RV30,  0x },
>>> -{ AV_CODEC_ID_RV40,  0x },
>>> -{ AV_CODEC_ID_VP9,   0x },
>>
>> I cannot test atm but this patch does not look ok to me.
> 
> Could you explain why? ff_mkv_codec_tags[] has a comment that says
> "If you add a tag here that is not in ff_codec_bmp_tags[] or
> ff_codec_wav_tags[], add it also to additional_audio_tags[] or
> additional_video_tags[] in matroskaenc.c"
> 
> The three codec ids I'm removing here, as far as i could check, are
> listed in one of the two tables from riff.c. Is there something else not
> explained in the Matroska sources that I'm missing?

Ping. I'll push this patch soon otherwise.

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

Re: [FFmpeg-devel] [PATCH V1] ffmpeg: fix video_delay warning for HEVC/MPEG4 decoding

[Carl Eugen Hoyos]

2018-09-26 11:49 GMT+02:00, Jun Zhao :
> For HEVC/MPEG4, we also need video_delay from the decoder, when decoding
> some HEVC/MPEG4 clips, got numerous log like:
> "video_delay is larger in decoder than demuxer", similar ticket: #3711

Can you provide such a hevc sample?

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

Re: [FFmpeg-devel] [PATCH 2/9] avcodec/gdv: Replace divisions by shifts in rescale()

[Nicolas George]

Michael Niedermayer (2018-09-24):
> CC-ing you so you dont miss this (though its not important)
> 
> if i hear nothing from anyone i will apply the patchset as is.
> IIUC james is ok with that. 
> But as said i can redo it with unsigned if people want.
> Just dont want to spend time redoing a patchset when maybe everyone is fine
> with it after the discussions. (its hard to read peoples preferance from
> silence ...)

Sorry, I did miss it indeed. I just wanted to mention the benefit of
using unsigned; I think the person working on the file has final say in
this kind of case.

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] avformat/matroskaenc: add reserve free space option

[Dave Rice]

> On Sep 12, 2018, at 11:56 AM, Sigríður Regína Sigurþórsdóttir 
>  wrote:
> 
> On Thu, Sep 6, 2018 at 3:31 PM James Almer  > wrote:
>> 
>> On 9/6/2018 4:18 PM, James Darnley wrote:
>>> On 2018-09-06 19:39, Sigríður Regína Sigurþórsdóttir wrote:
 +if (s->metadata_header_padding) {
 +if (s->metadata_header_padding == 1)
 +s->metadata_header_padding++;
 +put_ebml_void(pb, s->metadata_header_padding);
 +}
>>> 
>>> Unfortunately I was forced to make the default -1 so you want to check
>>> that the value is greater than 0 rather than just true.
>>> 
>>> Furthermore I think you will still want to add to Changelog making a
>>> note that the matroska muxer will now listen to metadata_header_padding.
>> 
>> No, this kind of change doesn't justify a Changelog entry as mentioned
>> before.
>> 
>>> That may also want a micro version bump so that library users can check.
>> 
>> Micro version bump is ok.
> 
> 
> Thank you.
> 
> Here is an updated patch with a bump and a change to make sure the value is > 
> 0.
> 
> 
> 
> From 08e140fa0b23274a4db18ce0b201e45fe7c1ac97 Mon Sep 17 00:00:00 2001
> From: Sigga Regina mailto:siggareg...@gmail.com>>
> Date: Wed, 12 Sep 2018 11:47:47 -0400
> Subject: [PATCH] avformat/matroskaenc: add reserve free space option
> 
> ---
> libavformat/matroskaenc.c | 5 +
> libavformat/version.h | 2 +-
> 2 files changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
> index 09a62e1..3f5febf 100644
> --- a/libavformat/matroskaenc.c
> +++ b/libavformat/matroskaenc.c
> @@ -2005,6 +2005,11 @@ static int mkv_write_header(AVFormatContext *s)
> ret = AVERROR(ENOMEM);
> goto fail;
> }
> +if (s->metadata_header_padding > 0) {
> +  if (s->metadata_header_padding == 1)
> +s->metadata_header_padding++;
> +  put_ebml_void(pb, s->metadata_header_padding);
> +}
> if ((pb->seekable & AVIO_SEEKABLE_NORMAL) && mkv->reserve_cues_space) {
> mkv->cues_pos = avio_tell(pb);
> if (mkv->reserve_cues_space == 1)
> diff --git a/libavformat/version.h b/libavformat/version.h
> index 4d21583..d7a1a35 100644
> --- a/libavformat/version.h
> +++ b/libavformat/version.h
> @@ -33,7 +33,7 @@
> // Also please add any ticket numbers that you believe might be affected here
> #define LIBAVFORMAT_VERSION_MAJOR  58
> #define LIBAVFORMAT_VERSION_MINOR  18
> -#define LIBAVFORMAT_VERSION_MICRO 100
> +#define LIBAVFORMAT_VERSION_MICRO 101
> 
> #define LIBAVFORMAT_VERSION_INT AV_VERSION_INT(LIBAVFORMAT_VERSION_MAJOR, \
>LIBAVFORMAT_VERSION_MINOR, \
> -- 
> 2.10.1 (Apple Git-78)
> <0001-avformat-matroskaenc-add-reserve-free-space-option 
> (1).patch>___

ping on this, as reserving such space in Matroska headers for later edits to 
the Tracks element would be helpful.
Dave Rice


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

Re: [FFmpeg-devel] [PATCH] libaomdec: add row_mt option

[Hendrik Leppkes]

On Wed, Sep 26, 2018 at 2:27 PM Tristan Matthews  wrote:
>
> Partially fixes #7456
> ---

row-mt is enabled by default in recent libaom versions, and they even
removed the option for it from aomdec, so do we really need that
option?

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

[FFmpeg-devel] [PATCH 1/1] Trying to fix trac ticket #7359

[Nick Ryan]

Signed-off-by: Nick Ryan 
---
 libavformat/mov.c | 19 ---
 1 file changed, 16 insertions(+), 3 deletions(-)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index 67015a72a1..587513e06e 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -7605,15 +7605,15 @@ static int mov_switch_root(AVFormatContext *s, int64_t 
target, int index)
 
 if (index >= 0 && index < mov->frag_index.nb_items)
 target = mov->frag_index.item[index].moof_offset;
-if (avio_seek(s->pb, target, SEEK_SET) != target) {
+if (target >= 0 && avio_seek(s->pb, target, SEEK_SET) != target) {
 av_log(mov->fc, AV_LOG_ERROR, "root atom offset 0x%"PRIx64": partial 
file\n", target);
 return AVERROR_INVALIDDATA;
 }
 
 mov->next_root_atom = 0;
-if (index < 0 || index >= mov->frag_index.nb_items)
+if ((index < 0 && target >= 0) || index >= mov->frag_index.nb_items)
 index = search_frag_moof_offset(>frag_index, target);
-if (index < mov->frag_index.nb_items) {
+if (index >= 0 && index < mov->frag_index.nb_items) {
 if (index + 1 < mov->frag_index.nb_items)
 mov->next_root_atom = mov->frag_index.item[index + 1].moof_offset;
 if (mov->frag_index.item[index].headers_read)
@@ -7663,9 +7663,22 @@ static int mov_read_packet(AVFormatContext *s, AVPacket 
*pkt)
 AVIndexEntry *sample;
 AVStream *st = NULL;
 int64_t current_index;
+int i;
 int ret;
 mov->fc = s;
  retry:
+if (s->pb->pos == 0) {
+mov->frag_index.nb_items = 0;
+mov->frag_index.current = -1;
+for (i = 0; i < s->nb_streams; i++) {
+AVStream *avst = s->streams[i];
+avst->index_entries = NULL;
+avst->index_entries_allocated_size = 0;
+avst->nb_index_entries = 0;
+}
+if ((ret = mov_switch_root(s, -1, -1)) < 0)
+return ret;
+}
 sample = mov_find_next_sample(s, );
 if (!sample || (mov->next_root_atom && sample->pos > mov->next_root_atom)) 
{
 if (!mov->next_root_atom)
-- 
2.17.1 (Apple Git-112)

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

[FFmpeg-devel] [PATCH 0/1] Trying to fix trac ticket #7359

[Nick Ryan]

Hello,

With reference to:

https://trac.ffmpeg.org/ticket/7359

I believe another way this issue manifests itself is using ffplay and trying to 
seek forward 10 seconds with the right arrow key: playback freezes. 

I have dug into this and developed a hack which seems to resolve the issue, BUT 
I have no idea if this is a valid, correct fix.

I have a local m3u8 file which was showing this problem and I can now 
programmatically seek to the correct point. I can also seek correctly via 
ffplay and ffmpeg. I have also tried the URL from the trak ticket and this now 
works as well. All current fate samples tests pass.

I submit the patch here for anyone that knows more about the codebase. I am 
happy to rework etc. as required. At the very least it might help anyone 
experiencing this problem in the meantime if they wish to run a patched ffmpeg 
version.

Within hls.c when hls_read_seek() is called it resets the stream position as 
follows:

/* Reset the pos, to let the mpegts demuxer know we've seeked. */
pls->pb.pos = 0;
 
There is support for this in the mpegts handle_packets() code to check if the 
position has been reset and clear out any PES packets:

 if (avio_tell(s->pb) != ts->last_pos) {
int i;
av_log(ts->stream, AV_LOG_TRACE, "Skipping after seek\n");
/* seek detected, flush pes buffer */
 
I have basically tried to do the same ‘reset’ logic within mov.c  
mov_read_packet() and force a search for the next mov root.

Regards,

Nick



Nick Ryan (1):
  Trying to fix trac ticket #7359

 libavformat/mov.c | 19 ---
 1 file changed, 16 insertions(+), 3 deletions(-)

-- 
2.17.1 (Apple Git-112)

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

[FFmpeg-devel] [PATCH] libaomdec: add row_mt option

[Tristan Matthews]

Partially fixes #7456
---
 libavcodec/libaomdec.c | 62 ++
 1 file changed, 62 insertions(+)

diff --git a/libavcodec/libaomdec.c b/libavcodec/libaomdec.c
index 2530c9f76b..6740f98be1 100644
--- a/libavcodec/libaomdec.c
+++ b/libavcodec/libaomdec.c
@@ -23,20 +23,63 @@
  * AV1 decoder support via libaom
  */
 
+#define AOM_DISABLE_CTRL_TYPECHECKS 1
 #include 
 #include 
 
 #include "libavutil/common.h"
 #include "libavutil/imgutils.h"
+#include "libavutil/opt.h"
 
 #include "avcodec.h"
 #include "internal.h"
 #include "profiles.h"
 
 typedef struct AV1DecodeContext {
+AVClass *class;
 struct aom_codec_ctx decoder;
+int row_mt;
 } AV1DecodeContext;
 
+static const char *const ctlidstr[] = {
+[AV1D_SET_ROW_MT]  = "AV1D_SET_ROW_MT",
+};
+
+
+static av_cold void log_decoder_error(AVCodecContext *avctx, const char *desc)
+{
+AV1DecodeContext *ctx= avctx->priv_data;
+const char *error  = aom_codec_error(>decoder);
+const char *detail = aom_codec_error_detail(>decoder);
+
+av_log(avctx, AV_LOG_ERROR, "%s: %s\n", desc, error);
+if (detail)
+av_log(avctx, AV_LOG_ERROR, "  Additional information: %s\n", detail);
+}
+
+static av_cold int codecctl_int(AVCodecContext *avctx,
+enum aom_dec_control_id id, int val)
+{
+AV1DecodeContext *ctx = avctx->priv_data;
+char buf[80];
+int width = -30;
+int res;
+
+snprintf(buf, sizeof(buf), "%s:", ctlidstr[id]);
+av_log(avctx, AV_LOG_DEBUG, "  %*s%d\n", width, buf, val);
+
+res = aom_codec_control(>decoder, id, val);
+if (res != AOM_CODEC_OK) {
+snprintf(buf, sizeof(buf), "Failed to set %s codec control",
+ ctlidstr[id]);
+log_decoder_error(avctx, buf);
+return AVERROR(EINVAL);
+}
+
+return 0;
+}
+
+
 static av_cold int aom_init(AVCodecContext *avctx,
 const struct aom_codec_iface *iface)
 {
@@ -56,6 +99,10 @@ static av_cold int aom_init(AVCodecContext *avctx,
 return AVERROR(EINVAL);
 }
 
+// codec control failures are currently treated only as warnings
+av_log(avctx, AV_LOG_DEBUG, "aom_codec_control\n");
+codecctl_int(avctx, AV1D_SET_ROW_MT, ctx->row_mt);
+
 return 0;
 }
 
@@ -220,6 +267,20 @@ static av_cold int av1_init(AVCodecContext *avctx)
 return aom_init(avctx, _codec_av1_dx_algo);
 }
 
+#define OFFSET(x) offsetof(AV1DecodeContext, x)
+#define VD AV_OPT_FLAG_VIDEO_PARAM | AV_OPT_FLAG_DECODING_PARAM
+static const AVOption options[] = {
+{ "row-mt", "Enable row-based multithreading", OFFSET(row_mt), 
AV_OPT_TYPE_BOOL, {.i64 = 1}, 0, 1, VD},
+{ NULL },
+};
+
+static const AVClass class_aom = {
+.class_name = "libaom-av1 decoder",
+.item_name  = av_default_item_name,
+.option = options,
+.version= LIBAVUTIL_VERSION_INT,
+};
+
 AVCodec ff_libaom_av1_decoder = {
 .name   = "libaom-av1",
 .long_name  = NULL_IF_CONFIG_SMALL("libaom AV1"),
@@ -231,5 +292,6 @@ AVCodec ff_libaom_av1_decoder = {
 .decode = aom_decode,
 .capabilities   = AV_CODEC_CAP_AUTO_THREADS | AV_CODEC_CAP_DR1,
 .profiles   = NULL_IF_CONFIG_SMALL(ff_av1_profiles),
+.priv_class = _aom,
 .wrapper_name   = "libaom",
 };
-- 
2.17.1

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

[FFmpeg-devel] [PATCH 1/1] possible fix to correct (improve) bitrate estimation for streams in fragmented MP4 when calculation is based on trex_data

[Nick Ryan]

Signed-off-by: Nick Ryan 
---
 libavformat/mov.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index 540e5ca057..67015a72a1 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -7459,14 +7459,14 @@ static int mov_read_header(AVFormatContext *s)
 for (i = 0; i < s->nb_streams; i++) {
 AVStream *st = s->streams[i];
 MOVStreamContext *sc = st->priv_data;
-if (st->duration > 0) {
+if (sc->duration_for_fps > 0) {
 if (sc->data_size > INT64_MAX / sc->time_scale / 8) {
 av_log(s, AV_LOG_ERROR, "Overflow during bit rate 
calculation %"PRId64" * 8 * %d\n",
sc->data_size, sc->time_scale);
 mov_read_close(s);
 return AVERROR_INVALIDDATA;
 }
-st->codecpar->bit_rate = sc->data_size * 8 * sc->time_scale / 
st->duration;
+st->codecpar->bit_rate = sc->data_size * 8 * sc->time_scale / 
sc->duration_for_fps;
 }
 }
 }
-- 
2.17.1 (Apple Git-112)

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

[FFmpeg-devel] [PATCH 0/1] mov.c: improvement to fMP4 bitrate estimation

[Nick Ryan]

Current code estimates bitrate by taking size of a single fragment and dividing 
by the total duration.
This patch changes calculation to be based on duration used for framerate 
estimation.

Nick Ryan (1):
  possible fix to correct (improve) bitrate estimation for streams in
fragmented MP4 when calculation is based on trex_data

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

-- 
2.17.1 (Apple Git-112)

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

[FFmpeg-devel] [PATCH 0/1] mov.c: improvement to fMP4 bitrate estimation

[Nick Ryan]

Current code estimates bitrate by taking size of a single fragment and dividing 
by the total duration.
This patch changes calculation to be based on duration used for framerate 
estimation.

Example ffprobes BEFORE patch (note video stream 15 kb/s, audio stream 0 kb/s):

ffprobe version N-91996-g94aed2265a Copyright (c) 2007-2018 the FFmpeg 
developers
  built with Apple LLVM version 10.0.0 (clang-1000.11.45.2)
  configuration: 
  libavutil  56. 19.101 / 56. 19.101
  libavcodec 58. 30.100 / 58. 30.100
  libavformat58. 18.102 / 58. 18.102
  libavdevice58.  4.103 / 58.  4.103
  libavfilter 7. 32.100 /  7. 32.100
  libswscale  5.  2.100 /  5.  2.100
  libswresample   3.  2.100 /  3.  2.100
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 
'/Users/nick/media/v-a-hls/video/video.mp4':
  Metadata:
major_brand : isom
minor_version   : 0
compatible_brands: iso8mp41dashavc1cmfc
creation_time   : 2018-08-30T11:28:56.00Z
  Duration: 00:11:24.00, start: 0.00, bitrate: 999 kb/s
Stream #0:0(und): Video: h264 (Constrained Baseline) (avc1 / 0x31637661), 
yuv420p, 1024x576 [SAR 1:1 DAR 16:9], 15 kb/s, 25 fps, 25 tbr, 12800 tbn, 50 
tbc (default)
Metadata:
  creation_time   : 2018-08-30T11:28:56.00Z
  handler_name: VideoHandler
  encoder : AVC Coding



ffprobe version N-91996-g94aed2265a Copyright (c) 2007-2018 the FFmpeg 
developers
  built with Apple LLVM version 10.0.0 (clang-1000.11.45.2)
  configuration: 
  libavutil  56. 19.101 / 56. 19.101
  libavcodec 58. 30.100 / 58. 30.100
  libavformat58. 18.102 / 58. 18.102
  libavdevice58.  4.103 / 58.  4.103
  libavfilter 7. 32.100 /  7. 32.100
  libswscale  5.  2.100 /  5.  2.100
  libswresample   3.  2.100 /  3.  2.100
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 
'/Users/nick/media/v-a-hls/audio/audio.mp4':
  Metadata:
major_brand : isom
minor_version   : 0
compatible_brands: iso8mp41dashcmfc
creation_time   : 2018-08-30T11:28:56.00Z
  Duration: 00:11:24.00, start: -0.023220, bitrate: 59 kb/s
Stream #0:0(und): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, stereo, 
fltp, 0 kb/s (default)
Metadata:
  creation_time   : 2018-08-30T11:28:56.00Z
  handler_name: SoundHandler


Example ffprobes AFTER patch (note video stream 1027 kb/s, audio stream 4 kb/s):


ffprobe version N-91996-g94aed2265a Copyright (c) 2007-2018 the FFmpeg 
developers
  built with Apple LLVM version 10.0.0 (clang-1000.11.45.2)
  configuration: 
  libavutil  56. 19.101 / 56. 19.101
  libavcodec 58. 30.100 / 58. 30.100
  libavformat58. 18.102 / 58. 18.102
  libavdevice58.  4.103 / 58.  4.103
  libavfilter 7. 32.100 /  7. 32.100
  libswscale  5.  2.100 /  5.  2.100
  libswresample   3.  2.100 /  3.  2.100
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 
'/Users/nick/media/v-a-hls/video/video.mp4':
  Metadata:
major_brand : isom
minor_version   : 0
compatible_brands: iso8mp41dashavc1cmfc
creation_time   : 2018-08-30T11:28:56.00Z
  Duration: 00:11:24.00, start: 0.00, bitrate: 999 kb/s
Stream #0:0(und): Video: h264 (Constrained Baseline) (avc1 / 0x31637661), 
yuv420p, 1024x576 [SAR 1:1 DAR 16:9], 1027 kb/s, 25 fps, 25 tbr, 12800 tbn, 50 
tbc (default)
Metadata:
  creation_time   : 2018-08-30T11:28:56.00Z
  handler_name: VideoHandler
  encoder : AVC Coding



ffprobe version N-91996-g94aed2265a Copyright (c) 2007-2018 the FFmpeg 
developers
  built with Apple LLVM version 10.0.0 (clang-1000.11.45.2)
  configuration: 
  libavutil  56. 19.101 / 56. 19.101
  libavcodec 58. 30.100 / 58. 30.100
  libavformat58. 18.102 / 58. 18.102
  libavdevice58.  4.103 / 58.  4.103
  libavfilter 7. 32.100 /  7. 32.100
  libswscale  5.  2.100 /  5.  2.100
  libswresample   3.  2.100 /  3.  2.100
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 
'/Users/nick/media/v-a-hls/audio/audio.mp4':
  Metadata:
major_brand : isom
minor_version   : 0
compatible_brands: iso8mp41dashcmfc
creation_time   : 2018-08-30T11:28:56.00Z
  Duration: 00:11:24.00, start: -0.023220, bitrate: 59 kb/s
Stream #0:0(und): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, stereo, 
fltp, 4 kb/s (default)
Metadata:
  creation_time   : 2018-08-30T11:28:56.00Z
  handler_name: SoundHandler





Nick Ryan (1):
  possible fix to correct (improve) bitrate estimation for streams in
fragmented MP4 when calculation is based on trex_data

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

-- 
2.17.1 (Apple Git-112)

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

Re: [FFmpeg-devel] [PATCH 2/2] fate: add api-h264-slice test

[Michael Niedermayer]

On Wed, Sep 26, 2018 at 10:35:05AM +0100, jos...@ob-encoder.com wrote:
> From: Josh de Kock 
> 
> This test ensures that you are able to send N number of slice NALUs in slice 
> threaded mode to be decoded simultaneously
> ---
>  tests/api/Makefile  |   1 +
>  tests/api/api-h264-slice-test.c | 208 +
>  tests/fate/api.mak  |   4 +
>  tests/ref/fate/api-h264-slice   | 309 
>  4 files changed, 522 insertions(+)
>  create mode 100644 tests/api/api-h264-slice-test.c
>  create mode 100644 tests/ref/fate/api-h264-slice

fails on mingw32:
src/tests/api/api-h264-slice-test.c:35:22: fatal error: sys/mman.h: No such 
file or directory
 #include 
  ^
compilation terminated.
make: *** [tests/api/api-h264-slice-test.o] Error 1


fails on linux x86-32
segfaults without debug symbols, with debug symbols it gives wrong results:

...
-0,282,282,1,   152064, 0fd5bb9259e8c27aba7670b08cd9a26b
-0,283,283,1,   152064, 43d6df9fd672b13e2c59db924e9fe30b
-0,284,284,1,   152064, 3aaf3b87705c46495c9d1b9f4ea706bf
-0,285,285,1,   152064, 0d2ba631f5c716d9c5e5b2a75d3b6433
-0,286,286,1,   152064, bf29cc016dce85e621aaa7647fae1544
-0,287,287,1,   152064, 3374284a808d79e9be32bf3610b0fd17
-0,288,288,1,   152064, ea3f305e76009f3bf2cd5014d339eafa
-0,289,289,1,   152064, 95ce7320a841a71b5a8871cef385ce41
-0,290,290,1,   152064, 88613d96dbda681edab4ed41c3f08536
-0,291,291,1,   152064, b9e9e9045b91c4f7917274088de64a5e
-0,292,292,1,   152064, e0b90055449e7403289a8dda9c02add0
-0,293,293,1,   152064, 367ee1603fa7778dad3e99be8db779ee
-0,294,294,1,   152064, 6bb0eaa6140d673b452eee6ac6c262c2
-0,295,295,1,   152064, 9af4ef919ae61e1597db1b9acd6af95a
-0,296,296,1,   152064, e8f29872e86e54ac26b5fb0a20f10d3e
-0,297,297,1,   152064, 09aaad95cd7d173bfe609b79440cbfc8
-0,298,298,1,   152064, c03abe502be10f76e33d93e1c40cc674
-0,299,299,1,   152064, 3e7e315be8aef281714a63f4cf086085
+0,  0, 692286055952568832,1, 1432681200, `{¦
+0, 4294967297, 692284681563034112,1, 1432681200, `{¦
+0, 8589934594, 692283032295592448,1, 1432681200, `{¦
+0, 12884901891, 692283307173499392,1, 1432681200, `{¦
+0, 17179869188, 693347084673372672,1, 1432681200, `{¦
+0, 21474836485, 693474078266380800,1, 1432681200, `{¦
+0, 25769803782, 695678873957978624,1, 1432681200, `{¦
+0, 30064771079, 692277809615360512,1, 1432681200, `{¦
+0, 34359738376, 695683272004489728,1, 1432681200, `{¦
+0, 38654705673, 695678873957978624,1, 1432681200, `{¦
+0, 42949672970, 693474078266380800,1, 1432681200, `{¦
+0, 47244640267, 693347084673372672,1, 1432681200, `{¦
+0, 51539607564, 692277809615360512,1, 1432681200, `{¦
+0, 55834574861, 692277809615360512,1, 1432681200, `{¦
+0, 60129542158, 695678873957978624,1, 1432681200, `{¦
...



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

Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope


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

[FFmpeg-devel] [PATCH V2] ffmpeg: fix video_delay warning for HEVC/MPEG4 decoding

[Jun Zhao]

For HEVC/MPEG4, we also need video_delay from the decoder, when decoding
some HEVC/MPEG4 clips, got numerous log like:
"video_delay is larger in decoder than demuxer", similar ticket: #3711

fix ticket: #6019

Signed-off-by: Lin Xie
Signed-off-by: Jun Zhao 
---
 fftools/ffmpeg.c |4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 934dc71..7e939d0 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -2389,7 +2389,9 @@ static int decode_video(InputStream *ist, AVPacket *pkt, 
int *got_output, int64_
 // The following line may be required in some cases where there is no 
parser
 // or the parser does not has_b_frames correctly
 if (ist->st->codecpar->video_delay < ist->dec_ctx->has_b_frames) {
-if (ist->dec_ctx->codec_id == AV_CODEC_ID_H264) {
+if (ist->dec_ctx->codec_id == AV_CODEC_ID_H264 ||
+ist->dec_ctx->codec_id == AV_CODEC_ID_HEVC ||
+ist->dec_ctx->codec_id == AV_CODEC_ID_MPEG4) {
 ist->st->codecpar->video_delay = ist->dec_ctx->has_b_frames;
 } else
 av_log(ist->dec_ctx, AV_LOG_WARNING,
-- 
1.7.1

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

Re: [FFmpeg-devel] [PATCH 4/4] Delay freeing of hls stream data

[Steven Liu]

Carl Eugen Hoyos  于2018年9月26日周三 下午4:22写道：
>
>
>
> > Am 26.09.2018 um 08:00 schrieb Amit Kale :
> >
> > This patch delays freeing of hls stream data, so that it's available for 
> > bandwidth calculation.
>
> > Otherwise the previous patches would cause a segfault in this code.
>
> This means that your patchset was not split correctly: No part of your 
> patchset should introduce known bugs.
> The patchset is therefore not ok yet.
Ok, i got it.
>
> 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 V1] ffmpeg: fix video_delay warning for HEVC/MPEG4 decoding

[Jun Zhao]

For HEVC/MPEG4, we also need video_delay from the decoder, when decoding
some HEVC/MPEG4 clips, got numerous log like:
"video_delay is larger in decoder than demuxer", similar ticket: #3711

fix ticket: #6109

Signed-off-by: Lin Xie
Signed-off-by: Jun Zhao 
---
 fftools/ffmpeg.c |4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 934dc71..7e939d0 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -2389,7 +2389,9 @@ static int decode_video(InputStream *ist, AVPacket *pkt, 
int *got_output, int64_
 // The following line may be required in some cases where there is no 
parser
 // or the parser does not has_b_frames correctly
 if (ist->st->codecpar->video_delay < ist->dec_ctx->has_b_frames) {
-if (ist->dec_ctx->codec_id == AV_CODEC_ID_H264) {
+if (ist->dec_ctx->codec_id == AV_CODEC_ID_H264 ||
+ist->dec_ctx->codec_id == AV_CODEC_ID_HEVC ||
+ist->dec_ctx->codec_id == AV_CODEC_ID_MPEG4) {
 ist->st->codecpar->video_delay = ist->dec_ctx->has_b_frames;
 } else
 av_log(ist->dec_ctx, AV_LOG_WARNING,
-- 
1.7.1

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

Re: [FFmpeg-devel] [PATCH] libavformat/segment: strftime date sub-directories

[Steven Liu]

James Courtier-Dutton  于2018年9月26日周三 下午5:08写道：
>
> On 26 September 2018 at 00:18, Steven Liu  wrote:
>
> >
> >
> > > On Sep 26, 2018, at 06:49, James Courtier-Dutton 
> > wrote:
> > > On 25 September 2018 at 23:24, Steven Liu  wrote:
> > yes, the error message is confusing, maybe change it here is better.
> > >
> > > +av_log(oc, AV_LOG_ERROR, "Could not create directory %s\n",
> > dir);
> > >
> >
> >
> Attached patch has the changed error message.
LGTM
> ___
> 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/2] fate: add api-h264-slice test

[joshdk]

From: Josh de Kock 

This test ensures that you are able to send N number of slice NALUs in slice 
threaded mode to be decoded simultaneously
---
 tests/api/Makefile  |   1 +
 tests/api/api-h264-slice-test.c | 208 +
 tests/fate/api.mak  |   4 +
 tests/ref/fate/api-h264-slice   | 309 
 4 files changed, 522 insertions(+)
 create mode 100644 tests/api/api-h264-slice-test.c
 create mode 100644 tests/ref/fate/api-h264-slice

diff --git a/tests/api/Makefile b/tests/api/Makefile
index 759dd9d243..b5c4ccae23 100644
--- a/tests/api/Makefile
+++ b/tests/api/Makefile
@@ -1,5 +1,6 @@
 APITESTPROGS-$(call ENCDEC, FLAC, FLAC) += api-flac
 APITESTPROGS-$(call DEMDEC, H264, H264) += api-h264
+APITESTPROGS-$(call DEMDEC, H264, H264) += api-h264-slice
 APITESTPROGS-yes += api-seek
 APITESTPROGS-yes += api-codec-param
 APITESTPROGS-$(call DEMDEC, H263, H263) += api-band
diff --git a/tests/api/api-h264-slice-test.c b/tests/api/api-h264-slice-test.c
new file mode 100644
index 00..c357291eee
--- /dev/null
+++ b/tests/api/api-h264-slice-test.c
@@ -0,0 +1,208 @@
+/*
+ * Copyright (c) 2001 Fabrice Bellard
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to 
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+#define MAX_SLICES 8
+
+// ./fate 2 ./crew_cif out.y4m
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+static int header = 0;
+static FILE *ofd;
+
+static void decode(AVCodecContext *dec_ctx, AVFrame *frame,
+   AVPacket *pkt)
+{
+static long int frame_cnt = 0;
+int ret;
+
+ret = avcodec_send_packet(dec_ctx, pkt);
+if (ret < 0) {
+fprintf(stderr, "Error sending a packet for decoding: %s\n", 
av_err2str(ret));
+exit(1);
+}
+
+while (ret >= 0) {
+const AVPixFmtDescriptor *desc;
+char *sum;
+struct AVHashContext *hash;
+
+ret = avcodec_receive_frame(dec_ctx, frame);
+if (ret == AVERROR(EAGAIN) || ret == AVERROR_EOF) {
+return;
+} else if (ret < 0) {
+fprintf(stderr, "Error during decoding: %s\n", av_err2str(ret));
+exit(1);
+}
+
+if (!header) {
+printf(
+"#format: frame checksums\n"
+"#version: 2\n"
+"#hash: MD5\n"
+"#tb 0: 1/30\n"
+"#media_type 0: video\n"
+"#codec_id 0: rawvideo\n"
+"#dimensions 0: 352x288\n"
+"#sar 0: 128/117\n"
+"#stream#, dts,pts, duration, size, hash\n");
+header = 1;
+}
+desc = av_pix_fmt_desc_get(dec_ctx->pix_fmt);
+av_hash_alloc(, "md5");
+av_hash_init(hash);
+sum = av_mallocz(av_hash_get_size(hash) * 2 + 1);
+
+for (int i = 0; i < frame->height; i++)
+av_hash_update(hash, >data[0][i * frame->linesize[0]], 
frame->width);
+for (int i = 0; i < frame->height >> desc->log2_chroma_h; i++)
+av_hash_update(hash, >data[1][i * frame->linesize[1]], 
frame->width >> desc->log2_chroma_w);
+for (int i = 0; i < frame->height >> desc->log2_chroma_h; i++)
+av_hash_update(hash, >data[2][i * frame->linesize[2]], 
frame->width >> desc->log2_chroma_w);
+
+av_hash_final_hex(hash, sum, av_hash_get_size(hash) * 2 + 1);
+printf("0, %10"PRId64", %10"PRId64",1, %8d, %s\n",
+frame_cnt, frame_cnt,
+(frame->width * frame->height + 2 * (frame->height >> 
desc->log2_chroma_h) * (frame->width >> desc->log2_chroma_w)), sum); 
+frame_cnt += 1;
+av_free(hash);
+av_free(sum);
+}
+}
+
+int main(int argc, char **argv)
+{
+const AVCodec *codec;
+AVCodecContext *c = NULL;
+AVFrame *frame;
+unsigned int threads;
+AVPacket *pkt;
+int fd = 0;
+char nal[MAX_SLICES * UINT16_MAX + 

[FFmpeg-devel] [PATCH 1/2] lavc/h264dec: don't error out when receiving multiple IDR slices

[joshdk]

From: Josh de Kock 

This error isn't particularly helpful as checking for mixed IDR/non-IDR
NALUs would need to be done at a higher level to actually be accurate.
Removing the error allows an API user to send individual slice NALUs
(i.e. incomplete frames) so they can take advantage of slice
threading. The ticket which this error was added for (#4408) no
longer segfaults after removing this error (as the bug was likely
fixed more properly elsewhere).
---
 libavcodec/h264dec.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/libavcodec/h264dec.c b/libavcodec/h264dec.c
index 7b4c5c76ea..00d922fbe9 100644
--- a/libavcodec/h264dec.c
+++ b/libavcodec/h264dec.c
@@ -657,11 +657,6 @@ static int decode_nal_units(H264Context *h, const uint8_t 
*buf, int buf_size)
 goto end;
 }
 if(!idr_cleared) {
-if (h->current_slice && (avctx->active_thread_type & 
FF_THREAD_SLICE)) {
-av_log(h, AV_LOG_ERROR, "invalid mixed IDR / non IDR 
frames cannot be decoded in slice multithreading mode\n");
-ret = AVERROR_INVALIDDATA;
-goto end;
-}
 idr(h); // FIXME ensure we don't lose some frames if there is 
reordering
 }
 idr_cleared = 1;
-- 
2.17.1

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

Re: [FFmpeg-devel] [PATCH] libavformat/segment: strftime date sub-directories

[James Courtier-Dutton]

On 26 September 2018 at 00:18, Steven Liu  wrote:

>
>
> > On Sep 26, 2018, at 06:49, James Courtier-Dutton 
> wrote:
> > On 25 September 2018 at 23:24, Steven Liu  wrote:
> yes, the error message is confusing, maybe change it here is better.
> >
> > +av_log(oc, AV_LOG_ERROR, "Could not create directory %s\n",
> dir);
> >
>
>
Attached patch has the changed error message.
From 8d8ea7d1f87a77ee23b6681a714da378b5361e4d Mon Sep 17 00:00:00 2001
From: James Courtier-Dutton 
Date: Wed, 26 Sep 2018 10:05:13 +0100
Subject: [PATCH] avformat/segment: strftime date sub-directories

Automatically create sub-directories if needed based on date.
E.g.
ffmpeg ... -timelimit 2147483647 -f segment -strftime 1 -segment_time 10 "%Y/%m/%d/%Y-%m-%d_%H-%M-%S.mkv"

Signed-off-by: James Courtier-Dutton 
---
 libavformat/segment.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/libavformat/segment.c b/libavformat/segment.c
index 7fb4dc7..0e17380 100644
--- a/libavformat/segment.c
+++ b/libavformat/segment.c
@@ -200,12 +200,27 @@ static int set_segment_filename(AVFormatContext *s)
 if (seg->use_strftime) {
 time_t now0;
 struct tm *tm, tmpbuf;
+const char *dir;
+char *fn_copy;
 time();
 tm = localtime_r(, );
 if (!strftime(buf, sizeof(buf), s->url, tm)) {
 av_log(oc, AV_LOG_ERROR, "Could not get segment filename with strftime\n");
 return AVERROR(EINVAL);
 }
+/* Automatically create directories if needed */
+/* E.g. %Y/%m/%d/%Y-%m-%d_%H-%M-%S.mkv */
+fn_copy = av_strdup(buf);
+if (!fn_copy) {
+return AVERROR(ENOMEM);
+}
+dir = av_dirname(fn_copy);
+if (ff_mkdir_p(dir) == -1 && errno != EEXIST) {
+av_log(oc, AV_LOG_ERROR, "Could not create directory %s\n", dir);
+av_free(fn_copy);
+return AVERROR(errno);
+}
+av_free(fn_copy);
 } else if (av_get_frame_filename(buf, sizeof(buf),
  s->url, seg->segment_idx) < 0) {
 av_log(oc, AV_LOG_ERROR, "Invalid segment filename template '%s'\n", s->url);
-- 
2.7.4

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

Re: [FFmpeg-devel] [PATCH 4/4] Delay freeing of hls stream data

[Carl Eugen Hoyos]

> Am 26.09.2018 um 08:00 schrieb Amit Kale :
> 
> This patch delays freeing of hls stream data, so that it's available for 
> bandwidth calculation.

> Otherwise the previous patches would cause a segfault in this code.

This means that your patchset was not split correctly: No part of your patchset 
should introduce known bugs.
The patchset is therefore not ok yet.

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

Re: [FFmpeg-devel] [PATCH] libaomdec: add row_mt option

[Paul B Mahol]

On 9/26/18, Tristan Matthews  wrote:
> Partially fixes #7456
> ---
>  libavcodec/libaomdec.c | 62 ++
>  1 file changed, 62 insertions(+)
>
> diff --git a/libavcodec/libaomdec.c b/libavcodec/libaomdec.c
> index 2530c9f76b..15cda2940a 100644
> --- a/libavcodec/libaomdec.c
> +++ b/libavcodec/libaomdec.c
> @@ -23,20 +23,63 @@
>   * AV1 decoder support via libaom
>   */
>
> +#define AOM_DISABLE_CTRL_TYPECHECKS 1
>  #include 
>  #include 
>
>  #include "libavutil/common.h"
>  #include "libavutil/imgutils.h"
> +#include "libavutil/opt.h"
>
>  #include "avcodec.h"
>  #include "internal.h"
>  #include "profiles.h"
>
>  typedef struct AV1DecodeContext {
> +AVClass *class;
>  struct aom_codec_ctx decoder;
> +int row_mt;
>  } AV1DecodeContext;
>
> +static const char *const ctlidstr[] = {
> +[AV1D_SET_ROW_MT]  = "AV1D_SET_ROW_MT",
> +};
> +
> +
> +static av_cold void log_decoder_error(AVCodecContext *avctx, const char
> *desc)
> +{
> +AV1DecodeContext *ctx= avctx->priv_data;
> +const char *error  = aom_codec_error(>decoder);
> +const char *detail = aom_codec_error_detail(>decoder);
> +
> +av_log(avctx, AV_LOG_ERROR, "%s: %s\n", desc, error);
> +if (detail)
> +av_log(avctx, AV_LOG_ERROR, "  Additional information: %s\n",
> detail);
> +}
> +
> +static av_cold int codecctl_int(AVCodecContext *avctx,
> +enum aom_dec_control_id id, int val)
> +{
> +AV1DecodeContext *ctx = avctx->priv_data;
> +char buf[80];
> +int width = -30;
> +int res;
> +
> +snprintf(buf, sizeof(buf), "%s:", ctlidstr[id]);
> +av_log(avctx, AV_LOG_DEBUG, "  %*s%d\n", width, buf, val);
> +
> +res = aom_codec_control(>decoder, id, val);
> +if (res != AOM_CODEC_OK) {
> +snprintf(buf, sizeof(buf), "Failed to set %s codec control",
> + ctlidstr[id]);
> +log_decoder_error(avctx, buf);
> +return AVERROR(EINVAL);
> +}
> +
> +return 0;
> +}
> +
> +
>  static av_cold int aom_init(AVCodecContext *avctx,
>  const struct aom_codec_iface *iface)
>  {
> @@ -56,6 +99,10 @@ static av_cold int aom_init(AVCodecContext *avctx,
>  return AVERROR(EINVAL);
>  }
>
> +// codec control failures are currently treated only as warnings
> +av_log(avctx, AV_LOG_DEBUG, "aom_codec_control\n");
> +codecctl_int(avctx, AV1D_SET_ROW_MT, ctx->row_mt);
> +
>  return 0;
>  }
>
> @@ -220,6 +267,20 @@ static av_cold int av1_init(AVCodecContext *avctx)
>  return aom_init(avctx, _codec_av1_dx_algo);
>  }
>
> +#define OFFSET(x) offsetof(AV1DecodeContext, x)
> +#define VD AV_OPT_FLAG_VIDEO_PARAM | AV_OPT_FLAG_DECODING_PARAM
> +static const AVOption options[] = {
> +{ "row-mt", "Enable row-based multithreading", OFFSET(row_mt),
> AV_OPT_TYPE_INT, {.i64 = 1}, 0, 1, VD},

AV_OPT_TYPE_BOOL

> +{ NULL },
> +};
> +
> +static const AVClass class_aom = {
> +.class_name = "libaom-av1 decoder",
> +.item_name  = av_default_item_name,
> +.option = options,
> +.version= LIBAVUTIL_VERSION_INT,
> +};
> +
>  AVCodec ff_libaom_av1_decoder = {
>  .name   = "libaom-av1",
>  .long_name  = NULL_IF_CONFIG_SMALL("libaom AV1"),
> @@ -231,5 +292,6 @@ AVCodec ff_libaom_av1_decoder = {
>  .decode = aom_decode,
>  .capabilities   = AV_CODEC_CAP_AUTO_THREADS | AV_CODEC_CAP_DR1,
>  .profiles   = NULL_IF_CONFIG_SMALL(ff_av1_profiles),
> +.priv_class = _aom,
>  .wrapper_name   = "libaom",
>  };
> --
> 2.17.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] PATCH[0/4]

[Steven Liu]

Amit Kale  于2018年9月26日周三 下午1:50写道：
>
> Hi,
>
> I am sending an HLS manifest file output patch containing fixes broken down 
> in four parts as follows
> 0001-Fix-computation-of-vs-start_pos.patch
> 0002-Add-a-new-hls_flag-peak_segment_bw.patch
> 0003-Adds-a-new-hls_flag-avg_bw.patch
> 0004-fix-master_pl-segfault.patch
>
> The overall description is that these patches correct bandwidth values in the 
> HLS manifest files output by ffmpeg. These are currently based on average 
> bandwidth. These patches enable the bandwidth values to be calculated based 
> on the number of bytes present in each stream in each segment file.
>
> Thanks.
> -Amit
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Patchset  LGTM

Thanks

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

[FFmpeg-devel] [PATCH 4/4] Delay freeing of hls stream data

[Amit Kale]

This patch delays freeing of hls stream data, so that it's available for 
bandwidth calculation. Otherwise the previous patches would cause a segfault in 
this code.

Signed-off-by: Amit Kale
---

Index: ffmpeg/libavformat/hlsenc.c
===
--- ffmpeg.orig/libavformat/hlsenc.c
+++ ffmpeg/libavformat/hlsenc.c
@@ -2447,10 +2447,13 @@ failed:
 av_freep(>vtt_m3u8_name);
 avformat_free_context(vtt_oc);
 }
+av_free(old_filename);
 
+}

+for (i = 0; i < hls->nb_varstreams; i++) {
+vs = >var_streams[i];
 hls_free_segments(vs->segments);
 hls_free_segments(vs->old_segments);
-av_free(old_filename);
 av_freep(>m3u8_name);
 av_freep(>streams);
 av_freep(>agroup);
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 1/4] Reset vs->start_pos when beginning a new file

[Amit Kale]

Reset vs->start_pos when beginning a new file.

Signed-off-by: Amit Kale
---
 libavformat/hlsenc.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

Index: ffmpeg/libavformat/hlsenc.c
===
--- ffmpeg.orig/libavformat/hlsenc.c
+++ ffmpeg/libavformat/hlsenc.c
@@ -2289,7 +2289,10 @@ static int hls_write_packet(AVFormatCont
 }
 
 if (hls->segment_type != SEGMENT_TYPE_FMP4) {

-vs->start_pos = new_start_pos;
+if (hls->flags & HLS_SINGLE_FILE)
+vs->start_pos = new_start_pos;
+else
+vs->start_pos = 0;
 } else {
 vs->start_pos += vs->size;
 }
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel