[FFmpeg-devel] [PATCH 1/2] cbs_h265: read/write HEVC PREFIX SEI

[Haihao Xiang]

Similar to cbs_h264, cbs_h265_{read, write}_nal_unit() can handle HEVC
prefix SEI NAL units now. Currently mastering display colour volume SEI
message is added only, we may add more SEI message if needed later

Signed-off-by: Haihao Xiang 
---
 libavcodec/cbs_h2645.c|  43 ++
 libavcodec/cbs_h265.h |  38 +
 libavcodec/cbs_h265_syntax_template.c | 150 ++
 3 files changed, 231 insertions(+)

diff --git a/libavcodec/cbs_h2645.c b/libavcodec/cbs_h2645.c
index 5585831cf6..6fc5832966 100644
--- a/libavcodec/cbs_h2645.c
+++ b/libavcodec/cbs_h2645.c
@@ -29,6 +29,7 @@
 #include "h264_sei.h"
 #include "h2645_parse.h"
 #include "hevc.h"
+#include "hevc_sei.h"
 
 
 static int cbs_read_ue_golomb(CodedBitstreamContext *ctx, GetBitContext *gbc,
@@ -465,6 +466,26 @@ static void cbs_h265_free_slice(void *unit, uint8_t 
*content)
 av_freep(&content);
 }
 
+static void cbs_h265_free_sei_payload(H265RawSEIPayload *payload)
+{
+switch (payload->payload_type) {
+case HEVC_SEI_TYPE_MASTERING_DISPLAY_INFO:
+break;
+default:
+av_buffer_unref(&payload->payload.other.data_ref);
+break;
+}
+}
+
+static void cbs_h265_free_sei(void *unit, uint8_t *content)
+{
+H265RawSEI *sei = (H265RawSEI*)content;
+int i;
+for (i = 0; i < sei->payload_count; i++)
+cbs_h265_free_sei_payload(&sei->payload[i]);
+av_freep(&content);
+}
+
 static int cbs_h2645_fragment_add_nals(CodedBitstreamContext *ctx,
CodedBitstreamFragment *frag,
const H2645Packet *packet)
@@ -972,6 +993,20 @@ static int cbs_h265_read_nal_unit(CodedBitstreamContext 
*ctx,
 }
 break;
 
+case HEVC_NAL_SEI_PREFIX:
+err = ff_cbs_alloc_unit_content(ctx, unit, sizeof(H265RawSEI),
+&cbs_h265_free_sei);
+
+if (err < 0)
+return err;
+
+err = cbs_h265_read_sei(ctx, &gbc, unit->content);
+
+if (err < 0)
+return err;
+
+break;
+
 default:
 return AVERROR(ENOSYS);
 }
@@ -1212,6 +1247,14 @@ static int cbs_h265_write_nal_unit(CodedBitstreamContext 
*ctx,
 }
 break;
 
+case HEVC_NAL_SEI_PREFIX:
+err = cbs_h265_write_sei(ctx, pbc, unit->content);
+
+if (err < 0)
+return err;
+
+break;
+
 default:
 av_log(ctx->log_ctx, AV_LOG_ERROR, "Write unimplemented for "
"NAL unit type %"PRIu32".\n", unit->type);
diff --git a/libavcodec/cbs_h265.h b/libavcodec/cbs_h265.h
index 33e71fc234..e37c1b8d94 100644
--- a/libavcodec/cbs_h265.h
+++ b/libavcodec/cbs_h265.h
@@ -25,6 +25,14 @@
 #include "cbs_h2645.h"
 #include "hevc.h"
 
+enum {
+// This limit is arbitrary - it is sufficient for one message of each
+// type plus some repeats, and will therefore easily cover all sane
+// streams.  However, it is possible to make technically-valid streams
+// for which it will fail (for example, by including a large number of
+// user-data-unregistered messages).
+H265_MAX_SEI_PAYLOADS = 64,
+};
 
 typedef struct H265RawNALUnitHeader {
 uint8_t forbidden_zero_bit;
@@ -516,6 +524,36 @@ typedef struct H265RawSlice {
 AVBufferRef *data_ref;
 } H265RawSlice;
 
+typedef struct H265RawSEIMasteringDiplayColorVolume {
+struct {
+uint16_t x;
+uint16_t y;
+} display_primaries[3];
+uint16_t white_point_x;
+uint16_t white_point_y;
+uint32_t max_display_mastering_luminance;
+uint32_t min_display_mastering_luminance;
+} H265RawSEIMasteringDiplayColorVolume;
+
+typedef struct H265RawSEIPayload {
+uint32_t payload_type;
+uint32_t payload_size;
+union {
+H265RawSEIMasteringDiplayColorVolume mastering_display;
+struct {
+uint8_t *data;
+size_t data_length;
+AVBufferRef *data_ref;
+} other;
+} payload;
+} H265RawSEIPayload;
+
+typedef struct H265RawSEI {
+H265RawNALUnitHeader nal_unit_header;
+
+H265RawSEIPayload payload[H265_MAX_SEI_PAYLOADS];
+uint8_t payload_count;
+} H265RawSEI;
 
 typedef struct CodedBitstreamH265Context {
 // Reader/writer context in common with the H.264 implementation.
diff --git a/libavcodec/cbs_h265_syntax_template.c 
b/libavcodec/cbs_h265_syntax_template.c
index 140c827c9d..cbe8f30be0 100644
--- a/libavcodec/cbs_h265_syntax_template.c
+++ b/libavcodec/cbs_h265_syntax_template.c
@@ -1501,3 +1501,153 @@ static int 
FUNC(slice_segment_header)(CodedBitstreamContext *ctx, RWContext *rw,
 
 return 0;
 }
+
+static int FUNC(sei_mastering_display)(CodedBitstreamContext *ctx, RWContext 
*rw,
+   H265RawSEIMasteringDiplayColorVolume 
*current)
+{
+int err, i;
+
+for (i = 0; i < 3; i++) {
+xu(16, display_primaries_x, current->display_primaries[i].x, 0, 5);
+xu(1

[FFmpeg-devel] [PATCH 2/2] vaapi_encode_h265: Insert mastering display colour colume if needed

[Haihao Xiang]

'-sei xxx' is added to control SEI insertion, so far only mastering
display colour colume is available for testing. Another patch is
required to change mastering display settings later.

Signed-off-by: Haihao Xiang 
---
 libavcodec/vaapi_encode_h265.c | 94 +-
 1 file changed, 93 insertions(+), 1 deletion(-)

diff --git a/libavcodec/vaapi_encode_h265.c b/libavcodec/vaapi_encode_h265.c
index 5203c6871d..a8cb6a6d8b 100644
--- a/libavcodec/vaapi_encode_h265.c
+++ b/libavcodec/vaapi_encode_h265.c
@@ -29,10 +29,14 @@
 #include "cbs.h"
 #include "cbs_h265.h"
 #include "hevc.h"
+#include "hevc_sei.h"
 #include "internal.h"
 #include "put_bits.h"
 #include "vaapi_encode.h"
 
+enum {
+SEI_MASTERING_DISPLAY   = 0x01,
+};
 
 typedef struct VAAPIEncodeH265Context {
 unsigned int ctu_width;
@@ -47,6 +51,9 @@ typedef struct VAAPIEncodeH265Context {
 H265RawSPS sps;
 H265RawPPS pps;
 H265RawSlice slice;
+H265RawSEI sei;
+
+H265RawSEIMasteringDiplayColorVolume mastering_display;
 
 int64_t last_idr_frame;
 int pic_order_cnt;
@@ -58,6 +65,7 @@ typedef struct VAAPIEncodeH265Context {
 CodedBitstreamContext *cbc;
 CodedBitstreamFragment current_access_unit;
 int aud_needed;
+int sei_needed;
 } VAAPIEncodeH265Context;
 
 typedef struct VAAPIEncodeH265Options {
@@ -65,6 +73,7 @@ typedef struct VAAPIEncodeH265Options {
 int aud;
 int profile;
 int level;
+int sei;
 } VAAPIEncodeH265Options;
 
 
@@ -175,6 +184,61 @@ fail:
 return err;
 }
 
+static int vaapi_encode_h265_write_extra_header(AVCodecContext *avctx,
+VAAPIEncodePicture *pic,
+int index, int *type,
+char *data, size_t *data_len)
+{
+VAAPIEncodeContext  *ctx = avctx->priv_data;
+VAAPIEncodeH265Context *priv = ctx->priv_data;
+VAAPIEncodeH265Options  *opt = ctx->codec_options;
+CodedBitstreamFragment   *au = &priv->current_access_unit;
+int err, i;
+
+if (priv->sei_needed) {
+if (priv->aud_needed) {
+err = vaapi_encode_h265_add_nal(avctx, au, &priv->aud);
+if (err < 0)
+goto fail;
+priv->aud_needed = 0;
+}
+
+memset(&priv->sei, 0, sizeof(priv->sei));
+priv->sei.nal_unit_header.nal_unit_type = HEVC_NAL_SEI_PREFIX;
+priv->sei.nal_unit_header.nuh_temporal_id_plus1 = 1;
+i = 0;
+
+if (opt->sei & SEI_MASTERING_DISPLAY && pic->type == PICTURE_TYPE_IDR) 
{
+priv->sei.payload[i].payload_type = 
HEVC_SEI_TYPE_MASTERING_DISPLAY_INFO;
+priv->sei.payload[i].payload.mastering_display = 
priv->mastering_display;
+++i;
+}
+
+priv->sei.payload_count = i;
+av_assert0(priv->sei.payload_count > 0);
+
+err = vaapi_encode_h265_add_nal(avctx, au, &priv->sei);
+if (err < 0)
+goto fail;
+priv->sei_needed = 0;
+
+err = vaapi_encode_h265_write_access_unit(avctx, data, data_len, au);
+if (err < 0)
+goto fail;
+
+ff_cbs_fragment_uninit(priv->cbc, au);
+
+*type = VAEncPackedHeaderRawData;
+return 0;
+} else {
+return AVERROR_EOF;
+}
+
+fail:
+ff_cbs_fragment_uninit(priv->cbc, au);
+return err;
+}
+
 static int vaapi_encode_h265_init_sequence_params(AVCodecContext *avctx)
 {
 VAAPIEncodeContext*ctx = avctx->priv_data;
@@ -587,6 +651,23 @@ static int 
vaapi_encode_h265_init_picture_params(AVCodecContext *avctx,
 priv->aud_needed = 0;
 }
 
+if ((opt->sei & SEI_MASTERING_DISPLAY) &&
+(pic->type == PICTURE_TYPE_I || pic->type == PICTURE_TYPE_IDR)) {
+// hard-coded value for testing, change it later
+for (i = 0; i < 3; i++) {
+priv->mastering_display.display_primaries[i].x = 5;
+priv->mastering_display.display_primaries[i].y = 5;
+}
+
+priv->mastering_display.white_point_x = 5;
+priv->mastering_display.white_point_y = 5;
+
+priv->mastering_display.max_display_mastering_luminance = 5000;
+priv->mastering_display.min_display_mastering_luminance = 1000;
+
+priv->sei_needed = 1;
+}
+
 vpic->decoded_curr_pic = (VAPictureHEVC) {
 .picture_id= pic->recon_surface,
 .pic_order_cnt = priv->pic_order_cnt,
@@ -895,6 +976,8 @@ static const VAAPIEncodeType vaapi_encode_type_h265 = {
 
 .slice_header_type = VAEncPackedHeaderHEVC_Slice,
 .write_slice_header= &vaapi_encode_h265_write_slice_header,
+
+.write_extra_header= &vaapi_encode_h265_write_extra_header,
 };
 
 static av_cold int vaapi_encode_h265_init(AVCodecContext *avctx)
@@ -943,7 +1026,8 @@ static av_cold int vaapi_encode_h265_init(AVCodecContext 
*avctx)
 
 ctx->va_packed_headers =
 VA_ENC_PACKED_

[FFmpeg-devel] [PATCH] avformat/dashdec.c: dash refair seg size error,

[dongsheng wang]

From: dongsheng7 


the seg size is 25 - 10 + 1 = 16, not 15(=25-10).

Signed-off-by: dongshengwang 
---
 libavformat/dashdec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
index 6304ad933b..b07ed4f8f2 100644
--- a/libavformat/dashdec.c
+++ b/libavformat/dashdec.c
@@ -588,7 +588,7 @@ static struct fragment * get_Fragment(char *range)
 char *str_end_offset;
 char *str_offset = av_strtok(range, "-", &str_end_offset);
 seg->url_offset = strtoll(str_offset, NULL, 10);
-seg->size = strtoll(str_end_offset, NULL, 10) - seg->url_offset;
+seg->size = strtoll(str_end_offset, NULL, 10) - seg->url_offset + 1;
 }
 
 return seg;
-- 
2.15.1 (Apple Git-101)

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

Re: [FFmpeg-devel] [PATCH 2/8] cbs_h265: Use helper macro for maximum values of fixed-width elements

[Xiang, Haihao]

On Tue, 2018-03-13 at 07:51 +0800, Jun Zhao wrote:
> 
> On 2018/3/12 20:47, Mark Thompson wrote:
> > On 12/03/18 00:41, Jun Zhao wrote:
> > > On 2018/3/12 2:30, Mark Thompson wrote:
> > > > Apply the same logic as the previous patch to H.265.  There are no cases
> > > > which currently overflow here, but this is still more consistent.
> > > > ---
> > > >  libavcodec/cbs_h265_syntax_template.c | 16 
> > > >  1 file changed, 8 insertions(+), 8 deletions(-)
> > > > 
> > > > diff --git a/libavcodec/cbs_h265_syntax_template.c
> > > > b/libavcodec/cbs_h265_syntax_template.c
> > > > index dae7f2dd46..140c827c9d 100644
> > > > --- a/libavcodec/cbs_h265_syntax_template.c
> > > > +++ b/libavcodec/cbs_h265_syntax_template.c
> > > > @@ -665,7 +665,7 @@ static int
> > > > FUNC(sps_scc_extension)(CodedBitstreamContext *ctx, RWContext *rw,
> > > >: current-
> > > > >bit_depth_chroma_minus8 + 8;
> > > >  for (i = 0; i <= current-
> > > > >sps_num_palette_predictor_initializer_minus1; i++)
> > > >  u(bit_depth,
> > > > sps_palette_predictor_initializers[comp][i],
> > > > -  0, (1 << bit_depth) - 1);
> > > > +  0, MAX_UINT_BITS(bit_depth));
> > > >  }
> > > >  }
> > > >  }
> > > > @@ -827,7 +827,7 @@ static int FUNC(sps)(CodedBitstreamContext *ctx,
> > > > RWContext *rw,
> > > >  for (i = 0; i < current->num_long_term_ref_pics_sps; i++) {
> > > >  u(current->log2_max_pic_order_cnt_lsb_minus4 + 4,
> > > >lt_ref_pic_poc_lsb_sps[i],
> > > > -  0, (1 << (current->log2_max_pic_order_cnt_lsb_minus4 +
> > > > 4)) - 1);
> > > > +  0, MAX_UINT_BITS(current-
> > > > >log2_max_pic_order_cnt_lsb_minus4 + 4));
> > > >  flag(used_by_curr_pic_lt_sps_flag[i]);
> > > >  }
> > > >  }
> > > > @@ -845,7 +845,7 @@ static int FUNC(sps)(CodedBitstreamContext *ctx,
> > > > RWContext *rw,
> > > >  flag(sps_multilayer_extension_flag);
> > > >  flag(sps_3d_extension_flag);
> > > >  flag(sps_scc_extension_flag);
> > > > -u(4, sps_extension_4bits, 0, (1 << 4) - 1);
> > > > +u(4, sps_extension_4bits, 0, MAX_UINT_BITS(4));
> > > >  }
> > > >  
> > > >  if (current->sps_range_extension_flag)
> > > > @@ -925,7 +925,7 @@ static int
> > > > FUNC(pps_scc_extension)(CodedBitstreamContext *ctx, RWContext *rw,
> > > >: current-
> > > > >chroma_bit_depth_entry_minus8 + 8;
> > > >  for (i = 0; i < current-
> > > > >pps_num_palette_predictor_initializer; i++)
> > > >  u(bit_depth,
> > > > pps_palette_predictor_initializers[comp][i],
> > > > -  0, (1 << bit_depth) - 1);
> > > > +  0, MAX_UINT_BITS(bit_depth));
> > > >  }
> > > >  }
> > > >  }
> > > > @@ -1038,7 +1038,7 @@ static int FUNC(pps)(CodedBitstreamContext *ctx,
> > > > RWContext *rw,
> > > >  flag(pps_multilayer_extension_flag);
> > > >  flag(pps_3d_extension_flag);
> > > >  flag(pps_scc_extension_flag);
> > > > -u(4, pps_extension_4bits, 0, (1 << 4) - 1);
> > > > +u(4, pps_extension_4bits, 0, MAX_UINT_BITS(4));
> > > >  }
> > > >  if (current->pps_range_extension_flag)
> > > >  CHECK(FUNC(pps_range_extension)(ctx, rw, current));
> > > > @@ -1274,7 +1274,7 @@ static int
> > > > FUNC(slice_segment_header)(CodedBitstreamContext *ctx, RWContext *rw,
> > > >  const H265RawSTRefPicSet *rps;
> > > >  
> > > >  u(sps->log2_max_pic_order_cnt_lsb_minus4 + 4,
> > > > slice_pic_order_cnt_lsb,
> > > > -  0, (1 << (sps->log2_max_pic_order_cnt_lsb_minus4 + 4)) -
> > > > 1);
> > > > +  0, MAX_UINT_BITS(sps->log2_max_pic_order_cnt_lsb_minus4 +
> > > > 4));
> > > >  
> > > >  flag(short_term_ref_pic_set_sps_flag);
> > > >  if (!current->short_term_ref_pic_set_sps_flag) {
> > > > @@ -1321,7 +1321,7 @@ static int
> > > > FUNC(slice_segment_header)(CodedBitstreamContext *ctx, RWContext *rw,
> > > >  ++num_pic_total_curr;
> > > >  } else {
> > > >  u(sps->log2_max_pic_order_cnt_lsb_minus4 + 4,
> > > > poc_lsb_lt[i],
> > > > -  0, (1 << (sps-
> > > > >log2_max_pic_order_cnt_lsb_minus4 + 4)) - 1);
> > > > +  0, MAX_UINT_BITS(sps-
> > > > >log2_max_pic_order_cnt_lsb_minus4 + 4));
> > > >  flag(used_by_curr_pic_lt_flag[i]);
> > > >  if (current->used_by_curr_pic_lt_flag[i])
> > > >  ++num_pic_total_curr;
> > > > @@ -1487,7 +1487,7 @@ static int
> > > > FUNC(slice_segment_header)(CodedBitstreamContext *ctx, RWContext *rw,
> > > >  ue(offset_len_minus1, 0, 31);
> > > >

Re: [FFmpeg-devel] [PATCH] avformat/dashdec.c: dash refair seg size error,

[Steven Liu]

> On 20 Apr 2018, at 15:37, dongsheng wang  wrote:
> 
> From: dongsheng7 
> 
> 
> the seg size is 25 - 10 + 1 = 16, not 15(=25-10).
LGTM

> 
> Signed-off-by: dongshengwang 
> ---
> libavformat/dashdec.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
> index 6304ad933b..b07ed4f8f2 100644
> --- a/libavformat/dashdec.c
> +++ b/libavformat/dashdec.c
> @@ -588,7 +588,7 @@ static struct fragment * get_Fragment(char *range)
> char *str_end_offset;
> char *str_offset = av_strtok(range, "-", &str_end_offset);
> seg->url_offset = strtoll(str_offset, NULL, 10);
> -seg->size = strtoll(str_end_offset, NULL, 10) - seg->url_offset;
> +seg->size = strtoll(str_end_offset, NULL, 10) - seg->url_offset + 1;
> }
> 
> return seg;
> -- 
> 2.15.1 (Apple Git-101)
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Thanks
Steven



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

Re: [FFmpeg-devel] [PATCH v2 2/2] avformat/utils: refactor upstream_stream_timings

[Rodger Combs]

Both patches LGTM.

> On Apr 19, 2018, at 18:51, Aman Gupta  wrote:
> 
> From: Aman Gupta 
> 
> ---
> libavformat/utils.c | 21 ++---
> 1 file changed, 10 insertions(+), 11 deletions(-)
> 
> diff --git a/libavformat/utils.c b/libavformat/utils.c
> index 705b79031d..c25eab4d49 100644
> --- a/libavformat/utils.c
> +++ b/libavformat/utils.c
> @@ -2620,7 +2620,6 @@ static void update_stream_timings(AVFormatContext *ic)
> int64_t start_time, start_time1, start_time_text, end_time, end_time1, 
> end_time_text;
> int64_t duration, duration1, duration_text, filesize;
> int i;
> -AVStream *st;
> AVProgram *p;
> 
> start_time = INT64_MAX;
> @@ -2631,21 +2630,22 @@ static void update_stream_timings(AVFormatContext *ic)
> duration_text = INT64_MIN;
> 
> for (i = 0; i < ic->nb_streams; i++) {
> -st = ic->streams[i];
> +AVStream *st = ic->streams[i];
> +int is_text = st->codecpar->codec_type == AVMEDIA_TYPE_SUBTITLE ||
> +  st->codecpar->codec_type == AVMEDIA_TYPE_DATA;
> if (st->start_time != AV_NOPTS_VALUE && st->time_base.den) {
> start_time1 = av_rescale_q(st->start_time, st->time_base,
>AV_TIME_BASE_Q);
> -if (st->codecpar->codec_type == AVMEDIA_TYPE_SUBTITLE || 
> st->codecpar->codec_type == AVMEDIA_TYPE_DATA) {
> -if (start_time1 < start_time_text)
> -start_time_text = start_time1;
> -} else
> +if (is_text)
> +start_time_text = FFMIN(start_time_text, start_time1);
> +else
> start_time = FFMIN(start_time, start_time1);
> end_time1 = av_rescale_q_rnd(st->duration, st->time_base,
>  AV_TIME_BASE_Q,
>  
> AV_ROUND_NEAR_INF|AV_ROUND_PASS_MINMAX);
> if (end_time1 != AV_NOPTS_VALUE && (end_time1 > 0 ? start_time1 
> <= INT64_MAX - end_time1 : start_time1 >= INT64_MIN - end_time1)) {
> end_time1 += start_time1;
> -if (st->codecpar->codec_type == AVMEDIA_TYPE_SUBTITLE || 
> st->codecpar->codec_type == AVMEDIA_TYPE_DATA)
> +if (is_text)
> end_time_text = FFMAX(end_time_text, end_time1);
> else
> end_time = FFMAX(end_time, end_time1);
> @@ -2660,7 +2660,7 @@ static void update_stream_timings(AVFormatContext *ic)
> if (st->duration != AV_NOPTS_VALUE) {
> duration1 = av_rescale_q(st->duration, st->time_base,
>  AV_TIME_BASE_Q);
> -if (st->codecpar->codec_type == AVMEDIA_TYPE_SUBTITLE || 
> st->codecpar->codec_type == AVMEDIA_TYPE_DATA)
> +if (is_text)
> duration_text = FFMAX(duration_text, duration1);
> else
> duration = FFMAX(duration, duration1);
> @@ -2671,11 +2671,10 @@ static void update_stream_timings(AVFormatContext *ic)
> else if (start_time > start_time_text)
> av_log(ic, AV_LOG_VERBOSE, "Ignoring outlier non primary stream 
> starttime %f\n", start_time_text / (float)AV_TIME_BASE);
> 
> -if (end_time == INT64_MIN || (end_time < end_time_text && end_time_text 
> - (uint64_t)end_time < AV_TIME_BASE)) {
> +if (end_time == INT64_MIN || (end_time < end_time_text && end_time_text 
> - (uint64_t)end_time < AV_TIME_BASE))
> end_time = end_time_text;
> -} else if (end_time < end_time_text) {
> +else if (end_time < end_time_text)
> av_log(ic, AV_LOG_VERBOSE, "Ignoring outlier non primary stream 
> endtime %f\n", end_time_text / (float)AV_TIME_BASE);
> -}
> 
>  if (duration == INT64_MIN || (duration < duration_text && duration_text 
> - duration < AV_TIME_BASE))
>  duration = duration_text;
> -- 
> 2.14.2
> 

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

Re: [FFmpeg-devel] [PATCH v2 1/2] avformat/utils: ignore outlier durations on subtitle/data streams as well

[Michael Niedermayer]

On Thu, Apr 19, 2018 at 04:51:33PM -0700, Aman Gupta wrote:
> From: Aman Gupta 
> 
> Similar to 4c9c4fe8b21, but for durations. This fixes #7151, where
> the report duration and bitrate on a mpegts stream is wildly off
> due to the dvb_teletext stream's timings.
> ---
>  libavformat/utils.c | 14 --
>  1 file changed, 12 insertions(+), 2 deletions(-)

patches should be ok

thx

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Avoid a single point of failure, be that a person or equipment.


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

Re: [FFmpeg-devel] [PATCH] avcodec/videotoolbox: fix kVTCouldNotFindVideoDecoderErr trying to decode HEVC on iOS

[Rodger Combs]

If there was a way to indicate this to consumers, or expose an option to turn 
this off, I'd say it should have that... but there's no good infrastructure to 
do that in an hwaccel, so whatever.
One nit; otherwise LGTM.

> On Apr 19, 2018, at 17:34, Aman Gupta  wrote:
> 
> From: Aman Gupta 
> 
> Older iOS devices don't have a hardware HEVC decoder, but the
> software decoder offered by VideoToolbox is well-optimized and
> performs much better than the ffmpeg decoder.
> ---
> libavcodec/videotoolbox.c | 12 ++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/libavcodec/videotoolbox.c b/libavcodec/videotoolbox.c
> index 57b6698e1b..8671608a35 100644
> --- a/libavcodec/videotoolbox.c
> +++ b/libavcodec/videotoolbox.c
> @@ -36,6 +36,9 @@
> #ifndef kVTVideoDecoderSpecification_RequireHardwareAcceleratedVideoDecoder
> #  define kVTVideoDecoderSpecification_RequireHardwareAcceleratedVideoDecoder 
> CFSTR("RequireHardwareAcceleratedVideoDecoder")
> #endif
> +#ifndef kVTVideoDecoderSpecification_EnableHardwareAcceleratedVideoDecoder
> +#  define kVTVideoDecoderSpecification_EnableHardwareAcceleratedVideoDecoder 
> CFSTR("EnableHardwareAcceleratedVideoDecoder")
> +#endif
> 
> #if !HAVE_KCMVIDEOCODECTYPE_HEVC
> enum { kCMVideoCodecType_HEVC = 'hvc1' };
> @@ -709,7 +712,9 @@ static CFDictionaryRef 
> videotoolbox_decoder_config_create(CMVideoCodecType codec
>
> &kCFTypeDictionaryValueCallBacks);
> 
> CFDictionarySetValue(config_info,
> - 
> kVTVideoDecoderSpecification_RequireHardwareAcceleratedVideoDecoder,
> + codec_type == kCMVideoCodecType_HEVC ?
> +
> kVTVideoDecoderSpecification_EnableHardwareAcceleratedVideoDecoder :
> +
> kVTVideoDecoderSpecification_RequireHardwareAcceleratedVideoDecoder,
>  kCFBooleanTrue);
> 
> CFMutableDictionaryRef avc_info;
> @@ -833,6 +838,9 @@ static int videotoolbox_start(AVCodecContext *avctx)
> case kVTVideoDecoderUnsupportedDataFormatErr:
> av_log(avctx, AV_LOG_VERBOSE, "VideoToolbox does not support this 
> format.\n");
> return AVERROR(ENOSYS);
> +case kVTCouldNotFindVideoDecoderErr:
> +av_log(avctx, AV_LOG_VERBOSE, "VideoToolbox decoder for this format 
> not found.\n");
> +return AVERROR(ENOSYS);
> case kVTVideoDecoderMalfunctionErr:
> av_log(avctx, AV_LOG_VERBOSE, "VideoToolbox malfunction.\n");
> return AVERROR(EINVAL);
> @@ -842,7 +850,7 @@ static int videotoolbox_start(AVCodecContext *avctx)
> case 0:
> return 0;
> default:
> -av_log(avctx, AV_LOG_VERBOSE, "Unknown VideoToolbox session creation 
> error %u\n", (unsigned)status);
> +av_log(avctx, AV_LOG_VERBOSE, "Unknown VideoToolbox session creation 
> error %d\n", (int)status);

Bit tangential; should be its own commit. Maybe just combine the two logging 
changes.

> return AVERROR_UNKNOWN;
> }
> }
> -- 
> 2.14.2
> 

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

Re: [FFmpeg-devel] [PATCH 0/8] Vulkan mapping and filtering infrastructure

[Michael Niedermayer]

On Fri, Apr 20, 2018 at 05:30:02AM +0100, Rostislav Pehlivanov wrote:
> The plan is to eventually be able to apply effects and encode entirely
> on the GPU.
> 
> Rostislav Pehlivanov (8):
>   hwcontext_internal: add ff_hwframe_map_replace
>   hwcontext_opencl: use ff_hwframe_map_replace()
>   lavu: add a Vulkan hwcontext
>   lavfi: add common Vulkan filtering code
>   lavfi: add a Vulkan avgblur filter
>   lavfi: add a Vulkan chromatic aberration filter
>   lavfi: add a Vulkan overlay filter
>   lavfi: add a Vulkan scale filter

This seems to break build here on ubuntu linux x86-64

Thats just with my normal build, no attempt to enable any vulkan stuff

AR  libavdevice/libavdevice.a
CC  libavfilter/vf_chromaticaberration_vulkan.o
In file included from libavfilter/vulkan.h:29:0,
 from libavfilter/vf_chromaticaberration_vulkan.c:20:
./libavutil/hwcontext_vulkan.h:25:27: fatal error: vulkan/vulkan.h: No such 
file or directory
 #include 
   ^
compilation terminated.
make: *** [libavfilter/vf_chromaticaberration_vulkan.o] Error 1



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

If you fake or manipulate statistics in a paper in physics you will never
get a job again.
If you fake or manipulate statistics in a paper in medicin you will get
a job for life at the pharma industry.


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

Re: [FFmpeg-devel] [PATCH] avcodec/videotoolbox: fix kVTCouldNotFindVideoDecoderErr trying to decode HEVC on iOS

[wm4]

On Fri, 20 Apr 2018 03:43:30 -0500
Rodger Combs  wrote:

> If there was a way to indicate this to consumers, or expose an option to turn 
> this off, I'd say it should have that... but there's no good infrastructure 
> to do that in an hwaccel, so whatever.
> One nit; otherwise LGTM.
> 

I guess it's OK as long as the Apple decoder really is faster than
FFmpeg with frame threading, and it supports all features a hw decoder
also would.

The whole point of hwaccel is to get a speed advantage over the
internal decoder.

Some mechanism to indicate that a sw decoder is used (even if it's
"better") would still be good.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] Add support for unequal duration for VOD playlist

[Somsak Sriprayoonsakul]

(Sorry for spamming, forgot the sign off part)

This patch make ffmpeg able to create a single HLS m3u8 with different
duration in the same manifest for VOD playlist ype.

This has benefit on optimizing HLS stream to start faster, having
initially shorter duration. The later part of the
stream could have longer duration, which lower server load (less number
of files, less
connection initiation needed on server side which is very significant in
this HTTPS era).

The similar capability was already exists in ffmpeg hlsenc.c, but only
for
live playlist. I just fix it a little bit to make it support VOD
playlist..

To create such VOD stream

ffmpeg -i input -c:v libx264 -c:a aac \
  -hls_init_time 2 -hls_time 8 \
  -hls_list_size 5 -hls_playlist_type vod \
  -f hls output_vod.m3u8

VOD playlist will use hls_list_size as the intended number of chunk to
use the hls_init_time.

Signed-off-by: Somsak Sriprayoonsakul 
---
 libavformat/hlsenc.c | 30 --
 1 file changed, 16 insertions(+), 14 deletions(-)

diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index c27a66ea79..b6260b262d 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -1026,26 +1026,28 @@ static int hls_append_segment(struct AVFormatContext 
*s, HLSContext *hls,
 
 vs->last_segment = en;
 
-// EVENT or VOD playlists imply sliding window cannot be used
-if (hls->pl_type != PLAYLIST_TYPE_NONE)
+// EVENT playlists imply sliding window cannot be used
+if ( (hls->pl_type == PLAYLIST_TYPE_EVENT) || (hls->pl_type == 
PLAYLIST_TYPE_NB) )
 hls->max_nb_segments = 0;
 
 if (hls->max_nb_segments && vs->nb_entries >= hls->max_nb_segments) {
-en = vs->segments;
-vs->initial_prog_date_time += en->duration;
-vs->segments = en->next;
-if (en && hls->flags & HLS_DELETE_SEGMENTS &&
+if( hls->pl_type != PLAYLIST_TYPE_VOD ) {
+en = vs->segments;
+vs->initial_prog_date_time += en->duration;
+vs->segments = en->next;
+if (en && hls->flags & HLS_DELETE_SEGMENTS &&
 #if FF_API_HLS_WRAP
-!(hls->flags & HLS_SINGLE_FILE || hls->wrap)) {
+!(hls->flags & HLS_SINGLE_FILE || hls->wrap)) {
 #else
-!(hls->flags & HLS_SINGLE_FILE)) {
+!(hls->flags & HLS_SINGLE_FILE)) {
 #endif
-en->next = vs->old_segments;
-vs->old_segments = en;
-if ((ret = hls_delete_old_segments(s, hls, vs)) < 0)
-return ret;
-} else
-av_free(en);
+en->next = vs->old_segments;
+vs->old_segments = en;
+if ((ret = hls_delete_old_segments(s, hls, vs)) < 0)
+return ret;
+} else
+av_free(en);
+}
 } else
 vs->nb_entries++;
 
-- 
2.14.1

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

Re: [FFmpeg-devel] FFmpeg 3.5 / 4.0

[Michael Niedermayer]

On Fri, Apr 20, 2018 at 02:31:59AM +0200, Michael Niedermayer wrote:
> On Thu, Apr 19, 2018 at 01:31:33PM +0200, Hendrik Leppkes wrote:
> > On Wed, Apr 18, 2018 at 11:15 PM, Michael Niedermayer
> >  wrote:
> > > On Wed, Apr 18, 2018 at 04:09:41PM +0200, Hendrik Leppkes wrote:
> > >> On Mon, Apr 16, 2018 at 1:24 PM, Michael Niedermayer
> > >>  wrote:
> > >> > On Sat, Apr 14, 2018 at 02:04:43PM +0200, Michael Niedermayer wrote:
> > >> >> On Fri, Apr 13, 2018 at 12:53:08AM +0200, Michael Niedermayer wrote:
> > >> >> > On Mon, Feb 19, 2018 at 02:50:08AM +0100, Michael Niedermayer wrote:
> > >> >> > > Hi
> > >> >> > >
> > >> >> > > Its 4 months since 3.4 was branched so its time for a new major 
> > >> >> > > release
> > >> >> > >
> > >> >> > > Is 4.0 or 3.5 preferred ?
> > >> >> > > Any name suggestions ?
> > >> >> > >
> > >> >> > > If there are no objections i will likely make that release in the 
> > >> >> > > next weeks
> > >> >> >
> > >> >> > more time has passed than intended ...
> > >> >> >
> > >> >> > what issues do remain that need to be fixed before the release ?
> > >> >> > I see fate.ffmpeg.org is not looking that well (compared to most
> > >> >> > releases in the past) i remember this being pretty much green 
> > >> >> > longer ago
> > >> >> > do people want these to be fixed before the release ?
> > >> >>
> > >> >> ok, so, my plan is to create a release/4.0 branch from master in the 
> > >> >> next
> > >> >> 24-48 hours unless theres some issue brought to my attention (CC me 
> > >> >> just to
> > >> >> be sure if theres an issue)
> > >> >>
> > >> >> then wait 2 days or so and backport any newly found bugfixes to 
> > >> >> release/4.0
> > >> >> and then make the release finally
> > >> >>
> > >> >> delays at any point are possible due to issues, lack of time or other.
> > >> >>
> > >> >> as name i think kierans suggestion of Wu would make sense. IIRC we had
> > >> >> no name suggested by more than 1 developer. Please correct me if i
> > >> >> miscounted i did only briefly re-check the mails in the thread.
> > >> >
> > >> >
> > >> > release/4.0 branched
> > >> > next is the release in a few days.
> > >> > If theres something i should wait for please say so and CC me
> > >> > also please backport all bugfixes to 4.0
> > >>
> > >> I have two more fixes that should really go in 4.0, one is the
> > >> tls_schannel fix that I plan to push soon (I'm the author of that
> > >> module, so unless someone says otherwise soon), and the MSVC configure
> > >> breakage introduced in the last 2 days.
> > >> Not sure when you planned to tag, but hopefully both of those are
> > >> resolved by tomorrow afternoon.
> > >
> > > well i had a bad headache today and iam a bit behind now with stuff
> > > so i likely wont be ready before tomorrow evening either.
> > 
> > Both of my changes have been applied, so nothing on my side any longer.
> 
> ok, i wanted to make the release today but its getting later than ideal.
> No point in rushing this by a few hours i guess
> 
> so next target is tomorrow early afternoon.
> delays are very possible of course if anything delays it
> 
> ill do a bit more testing before i go to sleep
> 
> Btw if someone wants to write anything like release notes or a news
> entry ...

4.0 release made, ill leave writing the news entry to people who
can write english without a spell checker

4.0.1 is planned to be released in 2 weeks.
Sooner if major bugs are found, later if something delays it or
theres nothing major.
So please continue pushing bugfixes to release/4.0 (and older release
branches if you like)

Thanks

[...]


-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Rewriting code that is poorly written but fully understood is good.
Rewriting code that one doesnt understand is a sign that one is less smart
then the original author, trying to rewrite it will not make it better.


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

Re: [FFmpeg-devel] [PATCH 0/8] Vulkan mapping and filtering infrastructure

[Rostislav Pehlivanov]

On 20 April 2018 at 10:05, Michael Niedermayer 
wrote:

> On Fri, Apr 20, 2018 at 05:30:02AM +0100, Rostislav Pehlivanov wrote:
> > The plan is to eventually be able to apply effects and encode entirely
> > on the GPU.
> >
> > Rostislav Pehlivanov (8):
> >   hwcontext_internal: add ff_hwframe_map_replace
> >   hwcontext_opencl: use ff_hwframe_map_replace()
> >   lavu: add a Vulkan hwcontext
> >   lavfi: add common Vulkan filtering code
> >   lavfi: add a Vulkan avgblur filter
> >   lavfi: add a Vulkan chromatic aberration filter
> >   lavfi: add a Vulkan overlay filter
> >   lavfi: add a Vulkan scale filter
>
> This seems to break build here on ubuntu linux x86-64
>
> Thats just with my normal build, no attempt to enable any vulkan stuff
>
> AR  libavdevice/libavdevice.a
> CC  libavfilter/vf_chromaticaberration_vulkan.o
> In file included from libavfilter/vulkan.h:29:0,
>  from libavfilter/vf_chromaticaberration_vulkan.c:20:
> ./libavutil/hwcontext_vulkan.h:25:27: fatal error: vulkan/vulkan.h: No
> such file or directory
>  #include 
>^
> compilation terminated.
> make: *** [libavfilter/vf_chromaticaberration_vulkan.o] Error 1
>
>
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> If you fake or manipulate statistics in a paper in physics you will never
> get a job again.
> If you fake or manipulate statistics in a paper in medicin you will get
> a job for life at the pharma industry.
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>
Thanks for testing, had a typo in configure:
-chromaticabberation_vulkan_filter_deps="vulkan libshaderc"
+chromaticaberration_vulkan_filter_deps="vulkan libshaderc"
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/3] lavc: Add VP9 metadata bitstream filter

[Moritz Barsnick]

On Sun, Apr 08, 2018 at 18:48:23 +0100, Mark Thompson wrote:
> Can adjust the colour information.
> ---
>  configure  |   1 +
>  libavcodec/Makefile|   1 +
>  libavcodec/bitstream_filters.c |   1 +
>  libavcodec/vp9_metadata_bsf.c  | 162 
> +
>  4 files changed, 165 insertions(+)
>  create mode 100644 libavcodec/vp9_metadata_bsf.c

A doc entry would be appreciated.

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

Re: [FFmpeg-devel] HLS Segmenting/Fragmentation Questions

[Ronak Patel]

Hey guys,

So I think this may be my own lack of knowledge in the encoder.

Because we were specifying -b:a 32k in our encoding step, I thought the byte 
ranges should align properly, but I’ve since learned that is incorrect.

The compression is still variable in terms of bytes.

Therefore this is correct.

I did see other issues that I’ll send a separate email about.

Thanks

Ronak

Sent from my iPhone

> On Apr 19, 2018, at 11:47 PM, Jeyapal, Karthick  wrote:
> 
> 
> 
>> On 4/20/18 2:20 AM, Ronak wrote:
>> Hi,
>> 
>> I've been testing FFMPEG's HLS fragmented MP4 options with some M4A audio 
>> files.
>> 
>> I've noticed that if I ask ffmpeg to fragment an 11 minute file vs a 10 hour 
>> file, the byte ranges are different, even if the channel count/sampling 
>> rate/bit rate and codec are the same.
>> 
>> Here's an example of what I'm talking about:
>> 
>> #EXTM3U
>> #EXT-X-VERSION:6
>> #EXT-X-TARGETDURATION:10
>> #EXT-X-MEDIA-SEQUENCE:1
>> #EXT-X-MAP:URI="someAudio.m4s",BYTERANGE="738@0"
>> #EXTINF:9.798821,
>> #EXT-X-BYTERANGE:38977@738
>> someAudio.m4s
>> #EXTINF:9.798821,
>> #EXT-X-BYTERANGE:38735@39715
>> someAudio.m4s
>> #EXTINF:9.798821,
>> #EXT-X-BYTERANGE:38650@78450
>> someAudio.m4s
>> #EXTINF:9.798821,
>> #EXT-X-BYTERANGE:38688@117100
>> someAudio.m4s
>> #EXTINF:9.798821,
>> #EXT-X-BYTERANGE:38820@155788
>> someAudio.m4s
>> 
>> And 
>> 
>> #EXTM3U
>> #EXT-X-VERSION:6
>> #EXT-X-TARGETDURATION:10
>> #EXT-X-MEDIA-SEQUENCE:1
>> #EXT-X-MAP:URI="someOtherAudio.m4s",BYTERANGE="738@0"
>> #EXTINF:9.798821,
>> #EXT-X-BYTERANGE:38724@738
>> someOtherAudio.m4s
>> #EXTINF:9.798821,
>> #EXT-X-BYTERANGE:38812@39462
>> someOtherAudio.m4s
>> #EXTINF:9.798821,
>> #EXT-X-BYTERANGE:38632@78274
>> someOtherAudio.m4s
>> #EXTINF:9.798821,
>> #EXT-X-BYTERANGE:38804@116906
>> someOtherAudio.m4s
>> #EXTINF:9.798821,
>> #EXT-X-BYTERANGE:38720@155710
>> someOtherAudio.m4s
>> 
>> Why would these byte ranges be different? I've been trying to look through 
>> the libavformat source code 
>> (https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/hlsenc.c 
>> ) but it 
>> looks like this determination is done in whoever calls hls_write_packet.
> Yes, you are right. It is determined by the AV encoder(say AAC encoder in 
> your case). HLS segmenter will just cut at the segment boundaries and it 
> doesn't worry about the number of bytes that are present in that segment.
>> 
>> Thanks,
>> 
>> Ronak
>> 
>> ___
>> 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 mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/dashenc: change the hls version from 6 to 7

[Ronak Patel]

Awesome guys thanks for the fix! That was fast!

Sent from my iPhone

> On Apr 19, 2018, at 11:41 PM, Jeyapal, Karthick  wrote:
> 
> 
> 
>> On 4/20/18 9:02 AM, Steven Liu wrote:
>> reference hls support fmp4 file from  draft-pantos-http-live-streaming-20
>> the spec describes version 7 of hls protocol
>> 
>> Suggested-by: Ronak 
>> Signed-off-by: Steven Liu 
>> ---
>> libavformat/dashenc.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
>> index 9e72636f0e..fefe3ce0ca 100644
>> --- a/libavformat/dashenc.c
>> +++ b/libavformat/dashenc.c
>> @@ -827,7 +827,7 @@ static int write_manifest(AVFormatContext *s, int final)
>> }
>> av_dict_free(&opts);
>> 
>> -ff_hls_write_playlist_version(out, 6);
>> +ff_hls_write_playlist_version(out, 7);
>> 
>> for (i = 0; i < s->nb_streams; i++) {
>> char playlist_file[64];
> LGTM. Thanks for the fix.
> 
> 
> ___
> 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] web/index: add news entry for release 4.0

[James Almer]

Signed-off-by: James Almer 
---
 src/index | 50 ++
 1 file changed, 50 insertions(+)

diff --git a/src/index b/src/index
index 2b44762..bbfca29 100644
--- a/src/index
+++ b/src/index
@@ -37,6 +37,56 @@
 News
   
 
+  April 20th, 2018, FFmpeg 4.0 "Wu"
+  
+FFmpeg 4.0 "Wu", a new
+major release, is now available! Some of the highlights:
+  
+  
+Bitstream filters for editing metadata in H.264, HEVC and MPEG-2 
streams
+Experimental MagicYUV encoder
+TiVo ty/ty+ demuxer
+Intel QSV-accelerated MJPEG encoding
+native aptX and aptX HD encoder and decoder
+NVIDIA NVDEC-accelerated H.264, HEVC, MJPEG, MPEG-1/2/4, VC1, VP8/9 
hwaccel decoding
+Intel QSV-accelerated overlay filter
+mcompand audio filter
+acontrast audio filter
+OpenCL overlay filter
+video mix filter
+video normalize filter
+audio lv2 wrapper filter
+VAAPI MJPEG and VP8 decoding
+AMD AMF H.264 and HEVC encoders
+video fillborders filter
+video setrange filter
+support LibreSSL (via libtls)
+Dropped support for building for Windows XP. The minimum supported 
Windows version is Windows Vista.
+deconvolve video filter
+entropy video filter
+hilbert audio filter source
+aiir audio filter
+Removed the ffserver program
+Removed the ffmenc and ffmdec muxer and demuxer
+VideoToolbox HEVC encoder and hwaccel
+VAAPI-accelerated ProcAmp (color balance), denoise and sharpness 
filters
+Add android_camera indev
+codec2 en/decoding via libcodec2
+native SBC encoder and decoder
+drmeter audio filter
+hapqa_extract bitstream filter
+filter_units bitstream filter
+AV1 Support through libaom
+E-AC-3 dependent frames support
+bitstream filter for extracting E-AC-3 core
+Haivision SRT protocol via libsrt
+vfrdet filter
+  
+  
+We strongly recommend users, distributors, and system integrators to
+upgrade unless they use current git master.
+  
+
   October 15th, 2017, FFmpeg 3.4 "Cantor"
   
 FFmpeg 3.4 "Cantor", a new
-- 
2.17.0

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

Re: [FFmpeg-devel] [PATCH 1/6] reitnerlace - tinterlace-like filter under LGPL

[Vasile Toncu]

Signed-off-by: Vasile Toncu 
---
 libavfilter/Makefile    |   2 +-
 libavfilter/interlace.h |  68 ---
 libavfilter/vf_interlace.c  | 366 


 libavfilter/vf_tinterlace.c |  26 +++
 libavfilter/x86/Makefile    |   2 +-
 libavfilter/x86/vf_interlace_init.c |  88 -
 6 files changed, 28 insertions(+), 524 deletions(-)
 delete mode 100644 libavfilter/interlace.h
 delete mode 100644 libavfilter/vf_interlace.c
 delete mode 100644 libavfilter/x86/vf_interlace_init.c

diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 3a9fb02..cfb0f1d 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -231,7 +231,7 @@ OBJS-$(CONFIG_HYSTERESIS_FILTER) += 
vf_hysteresis.o framesync.o

 OBJS-$(CONFIG_IDET_FILTER)   += vf_idet.o
 OBJS-$(CONFIG_IL_FILTER) += vf_il.o
 OBJS-$(CONFIG_INFLATE_FILTER)    += vf_neighbor.o
-OBJS-$(CONFIG_INTERLACE_FILTER)  += vf_interlace.o
+OBJS-$(CONFIG_INTERLACE_FILTER)  += vf_tinterlace.o
 OBJS-$(CONFIG_INTERLEAVE_FILTER) += f_interleave.o
 OBJS-$(CONFIG_KERNDEINT_FILTER)  += vf_kerndeint.o
 OBJS-$(CONFIG_LENSCORRECTION_FILTER) += vf_lenscorrection.o
diff --git a/libavfilter/interlace.h b/libavfilter/interlace.h
deleted file mode 100644
index b41f0d5..000
--- a/libavfilter/interlace.h
+++ /dev/null
@@ -1,68 +0,0 @@
-/*
- * This file is part of FFmpeg.
- *
- * FFmpeg is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * FFmpeg is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License along
- * with FFmpeg; if not, write to the Free Software Foundation, Inc.,
- * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
- */
-
-/**
- * @file
- * progressive to interlaced content filter, inspired by heavy debugging of
- * tinterlace filter.
- */
-
-#ifndef AVFILTER_INTERLACE_H
-#define AVFILTER_INTERLACE_H
-
-#include "libavutil/bswap.h"
-#include "libavutil/common.h"
-#include "libavutil/imgutils.h"
-#include "libavutil/opt.h"
-#include "libavutil/pixdesc.h"
-
-#include "avfilter.h"
-#include "formats.h"
-#include "internal.h"
-#include "video.h"
-
-enum ScanMode {
-    MODE_TFF = 0,
-    MODE_BFF = 1,
-};
-
-enum FieldType {
-    FIELD_UPPER = 0,
-    FIELD_LOWER = 1,
-};
-
-enum VLPFilter {
-    VLPF_OFF = 0,
-    VLPF_LIN = 1,
-    VLPF_CMP = 2,
-};
-
-typedef struct InterlaceContext {
-    const AVClass *class;
-    enum ScanMode scan;    // top or bottom field first scanning
-    int lowpass;   // enable or disable low pass filtering
-    AVFrame *cur, *next;   // the two frames from which the new one is 
obtained

-    const AVPixFmtDescriptor *csp;
-    void (*lowpass_line)(uint8_t *dstp, ptrdiff_t linesize, const 
uint8_t *srcp,

- ptrdiff_t mref, ptrdiff_t pref, int clip_max);
-} InterlaceContext;
-
-void ff_interlace_init(InterlaceContext *interlace, int depth);
-void ff_interlace_init_x86(InterlaceContext *interlace, int depth);
-
-#endif /* AVFILTER_INTERLACE_H */
diff --git a/libavfilter/vf_interlace.c b/libavfilter/vf_interlace.c
deleted file mode 100644
index 24c422d..000
--- a/libavfilter/vf_interlace.c
+++ /dev/null
@@ -1,366 +0,0 @@
-/*
- * Copyright (c) 2003 Michael Zucchi 
- * Copyright (c) 2010 Baptiste Coudurier
- * Copyright (c) 2011 Stefano Sabatini
- * Copyright (c) 2013 Vittorio Giovara 
- * Copyright (c) 2017 Thomas Mundt 
- *
- * This file is part of FFmpeg.
- *
- * FFmpeg is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * FFmpeg is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License along
- * with FFmpeg; if not, write to the Free Software Foundation, Inc.,
- * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
- */
-
-/**
- * @file
- * progressive to interlaced content filter, inspired by heavy 
debugging of tinterlace filter

- */
-
-#include "libavutil/common.h"
-#include "libavutil/opt.h"
-#include "libavutil/imgutils.h"
-#include "libavutil/avassert.h"
-
-#include "formats.h"
-#include "avfilter.h"
-#include "interlace.

Re: [FFmpeg-devel] [PATCH] web/index: add news entry for release 4.0

[Thomas Volkert]

On 20.04.2018 16:27, James Almer wrote:
[..]
> +  
> +Bitstream filters for editing metadata in H.264, HEVC and MPEG-2 
> streams
> +Experimental MagicYUV encoder
> +TiVo ty/ty+ demuxer
> +Intel QSV-accelerated MJPEG encoding
> +native aptX and aptX HD encoder and decoder
> +NVIDIA NVDEC-accelerated H.264, HEVC, MJPEG, MPEG-1/2/4, VC1, VP8/9 
> hwaccel decoding
> +Intel QSV-accelerated overlay filter
> +mcompand audio filter
> +acontrast audio filter
> +OpenCL overlay filter
> +video mix filter
> +video normalize filter
> +audio lv2 wrapper filter
> +VAAPI MJPEG and VP8 decoding
> +AMD AMF H.264 and HEVC encoders
> +video fillborders filter
> +video setrange filter
> +support LibreSSL (via libtls)
> +Dropped support for building for Windows XP. The minimum supported 
> Windows version is Windows Vista.
> +deconvolve video filter
> +entropy video filter
> +hilbert audio filter source
> +aiir audio filter
> +Removed the ffserver program
> +Removed the ffmenc and ffmdec muxer and demuxer
> +VideoToolbox HEVC encoder and hwaccel
> +VAAPI-accelerated ProcAmp (color balance), denoise and sharpness 
> filters
> +Add android_camera indev
> +codec2 en/decoding via libcodec2
> +native SBC encoder and decoder
> +drmeter audio filter
> +hapqa_extract bitstream filter
> +filter_units bitstream filter
> +AV1 Support through libaom
> +E-AC-3 dependent frames support
> +bitstream filter for extracting E-AC-3 core
> +Haivision SRT protocol via libsrt
> +vfrdet filter
> +  

There are some lines missing?

Best regards,
Thomas.

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

Re: [FFmpeg-devel] [PATCH 1/1] segafilm: fetch duration from the container

[James Almer]

On 4/20/2018 2:39 AM, Misty De Meo wrote:
> On Thu, Apr 19, 2018 at 8:31 PM, James Almer  wrote:
>>
>>> +film->sample_table[i].duration = AV_RB32(&scratch[12]);
>>
>> While for video tracks this field seems to report the same packet
>> durations that were being calculated pre patch, this field for audio
>> tracks is always 1.
>>
>> Before this patch a codec copy of the sample logo-capcom.cpk in the FATE
>> suite gave:
>>
>> 1,  0,  0,22048,44096, 0xafd250ae
>> 0,  2,  2,2,11080, 0xac3a462b
>> 0,  4,  4,2,11300, 0xd8ee7f3e
>> 0,  6,  6,2,21612, 0x73c3a3f9, F=0x0
>> 0,  8,  8,2,21628, 0x00a5b4b9, F=0x0
>> 0, 10, 10,2,14772, 0x1332b44f
>> 0, 12, 12,2,14744, 0x5ce5d59b
>> 0, 14, 14,2,14736, 0xd5ac2877
>> 1,  22048,  22048,11028,22056, 0xe08a0f01
>>
>> Whereas after applying it becomes:
>>
>> 1,  0,  0,1,44096, 0xafd250ae
>> 0,  2,  2,2,11080, 0xac3a462b
>> 0,  4,  4,2,11300, 0xd8ee7f3e
>> 0,  6,  6,2,21612, 0x73c3a3f9, F=0x0
>> 0,  8,  8,2,21628, 0x00a5b4b9, F=0x0
>> 0, 10, 10,2,14772, 0x1332b44f
>> 0, 12, 12,2,14744, 0x5ce5d59b
>> 0, 14, 14,2,14736, 0xd5ac2877
>> 1,  22048,  22048,1,22056, 0xe08a0f01
>>
>> For reference, decoding it always gives the following with or without
>> this patch:
>>
>> 0,  0,  0,1,   215040, 0x067c5362
>> 1,  0,  0,22048,88192, 0x23bb50ae
>> 0,  2,  2,1,   215040, 0xd9eacb98
>> 0,  4,  4,1,   215040, 0x3c8a4cbd
>> 0,  6,  6,1,   215040, 0xbdf996e1
>> 0,  8,  8,1,   215040, 0x1b7fa123
>> 0, 10, 10,1,   215040, 0x834b4a8d
>> 0, 12, 12,1,   215040, 0xf4b1bebe
>> 0, 14, 14,1,   215040, 0x088c3802
>> 1,  22048,  22048,11028,44112, 0x79600f01
>>
>> Is this change desired/intended?
> 
> This is actually intended; since that value is what's in the original
> container, it's what should get passed through, especially for stream
> copying back into a new FILM file.

Maybe the muxer should ignore the input packet duration when writing
this field in that case, and hardcode it to 1. A duration of 1 for an
audio track with these presentation times is not correct.

You should set this value only for video. If pkt->duration is not set,
libavformat will calculate it on its own.

> 
>>
>> Also, unrelated to this patch, but as you can see decoding outputs one
>> extra video frame at the beginning that codec copy doesn't. this is
>> because packet keyframes are being set wrong: A 0 in the top bit of the
>> sample info dword on each sample table entry signals an Intra coded
>> frame, whereas 1 signals an Inter coded frame. The demuxer is assuming
>> the opposite.
> 
> Here's a thread with context on the change to the intra setting:
> http://ffmpeg.org/pipermail/ffmpeg-devel/2018-March/227014.html
> 
> The keyframe logic was intentionally inverted in
> cfe1a9d311de6c36641cf295004cdbc77d7b600c

I don't understand the reasoning to invert the logic here. The current
behavior is clearly not right. We're marking Inter coded frames as key
frames and Intra coded frames as non keyframes. The result as you can
see is at least one frame/packet lost during codec copy.

Setting pkt->flags was the only change that patch should have introduced.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] web/index: add news entry for release 4.0

[James Almer]

On 4/20/2018 11:58 AM, Thomas Volkert wrote:
> 
> On 20.04.2018 16:27, James Almer wrote:
> [..]
>> +  
>> +Bitstream filters for editing metadata in H.264, HEVC and MPEG-2 
>> streams
>> +Experimental MagicYUV encoder
>> +TiVo ty/ty+ demuxer
>> +Intel QSV-accelerated MJPEG encoding
>> +native aptX and aptX HD encoder and decoder
>> +NVIDIA NVDEC-accelerated H.264, HEVC, MJPEG, MPEG-1/2/4, VC1, VP8/9 
>> hwaccel decoding
>> +Intel QSV-accelerated overlay filter
>> +mcompand audio filter
>> +acontrast audio filter
>> +OpenCL overlay filter
>> +video mix filter
>> +video normalize filter
>> +audio lv2 wrapper filter
>> +VAAPI MJPEG and VP8 decoding
>> +AMD AMF H.264 and HEVC encoders
>> +video fillborders filter
>> +video setrange filter
>> +support LibreSSL (via libtls)
>> +Dropped support for building for Windows XP. The minimum supported 
>> Windows version is Windows Vista.
>> +deconvolve video filter
>> +entropy video filter
>> +hilbert audio filter source
>> +aiir audio filter
>> +Removed the ffserver program
>> +Removed the ffmenc and ffmdec muxer and demuxer
>> +VideoToolbox HEVC encoder and hwaccel
>> +VAAPI-accelerated ProcAmp (color balance), denoise and sharpness 
>> filters
>> +Add android_camera indev
>> +codec2 en/decoding via libcodec2
>> +native SBC encoder and decoder
>> +drmeter audio filter
>> +hapqa_extract bitstream filter
>> +filter_units bitstream filter
>> +AV1 Support through libaom
>> +E-AC-3 dependent frames support
>> +bitstream filter for extracting E-AC-3 core
>> +Haivision SRT protocol via libsrt
>> +vfrdet filter
>> +  
> 
> There are some lines missing?
> 
> Best regards,
> Thomas.

Yes, i removed some since i wanted a shorter list with "highlights" as
the news entry states.
Any specific line from Changelog you wanted listed?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] web/index: add news entry for release 4.0

[Thomas Volkert]

On 20.04.2018 17:07, James Almer wrote:
> On 4/20/2018 11:58 AM, Thomas Volkert wrote:
>> On 20.04.2018 16:27, James Almer wrote:
>> [..]
>>> +  
>>> +Bitstream filters for editing metadata in H.264, HEVC and MPEG-2 
>>> streams
>>> +Experimental MagicYUV encoder
>>> +TiVo ty/ty+ demuxer
>>> +Intel QSV-accelerated MJPEG encoding
>>> +native aptX and aptX HD encoder and decoder
>>> +NVIDIA NVDEC-accelerated H.264, HEVC, MJPEG, MPEG-1/2/4, VC1, 
>>> VP8/9 hwaccel decoding
>>> +Intel QSV-accelerated overlay filter
>>> +mcompand audio filter
>>> +acontrast audio filter
>>> +OpenCL overlay filter
>>> +video mix filter
>>> +video normalize filter
>>> +audio lv2 wrapper filter
>>> +VAAPI MJPEG and VP8 decoding
>>> +AMD AMF H.264 and HEVC encoders
>>> +video fillborders filter
>>> +video setrange filter
>>> +support LibreSSL (via libtls)
>>> +Dropped support for building for Windows XP. The minimum supported 
>>> Windows version is Windows Vista.
>>> +deconvolve video filter
>>> +entropy video filter
>>> +hilbert audio filter source
>>> +aiir audio filter
>>> +Removed the ffserver program
>>> +Removed the ffmenc and ffmdec muxer and demuxer
>>> +VideoToolbox HEVC encoder and hwaccel
>>> +VAAPI-accelerated ProcAmp (color balance), denoise and sharpness 
>>> filters
>>> +Add android_camera indev
>>> +codec2 en/decoding via libcodec2
>>> +native SBC encoder and decoder
>>> +drmeter audio filter
>>> +hapqa_extract bitstream filter
>>> +filter_units bitstream filter
>>> +AV1 Support through libaom
>>> +E-AC-3 dependent frames support
>>> +bitstream filter for extracting E-AC-3 core
>>> +Haivision SRT protocol via libsrt
>>> +vfrdet filter
>>> +  
>> There are some lines missing?
>>
>> Best regards,
>> Thomas.
> Yes, i removed some since i wanted a shorter list with "highlights" as
> the news entry states.
> Any specific line from Changelog you wanted listed?
No, I am fine with your list in general, I just wanted to make sure that
the lines weren't lost by accident.
As soon as this list is final, I will reuse it on Facebook.
Thanks.

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

Re: [FFmpeg-devel] [PATCH] web/index: add news entry for release 4.0

[Steven Liu]

2018-04-20 22:27 GMT+08:00 James Almer :
> Signed-off-by: James Almer 
> ---
>  src/index | 50 ++
>  1 file changed, 50 insertions(+)
>
> diff --git a/src/index b/src/index
> index 2b44762..bbfca29 100644
> --- a/src/index
> +++ b/src/index
> @@ -37,6 +37,56 @@
>  News
>
>
> +  April 20th, 2018, FFmpeg 4.0 "Wu"
> +  
> +FFmpeg 4.0 "Wu", a new
> +major release, is now available! Some of the highlights:
> +  
> +  
> +Bitstream filters for editing metadata in H.264, HEVC and MPEG-2 
> streams
> +Experimental MagicYUV encoder
> +TiVo ty/ty+ demuxer
> +Intel QSV-accelerated MJPEG encoding
> +native aptX and aptX HD encoder and decoder
> +NVIDIA NVDEC-accelerated H.264, HEVC, MJPEG, MPEG-1/2/4, VC1, VP8/9 
> hwaccel decoding
> +Intel QSV-accelerated overlay filter
> +mcompand audio filter
> +acontrast audio filter
> +OpenCL overlay filter
> +video mix filter
> +video normalize filter
> +audio lv2 wrapper filter
> +VAAPI MJPEG and VP8 decoding
> +AMD AMF H.264 and HEVC encoders
> +video fillborders filter
> +video setrange filter
> +support LibreSSL (via libtls)
> +Dropped support for building for Windows XP. The minimum supported 
> Windows version is Windows Vista.
> +deconvolve video filter
> +entropy video filter
> +hilbert audio filter source
> +aiir audio filter
> +Removed the ffserver program
> +Removed the ffmenc and ffmdec muxer and demuxer
> +VideoToolbox HEVC encoder and hwaccel
> +VAAPI-accelerated ProcAmp (color balance), denoise and sharpness 
> filters
> +Add android_camera indev
> +codec2 en/decoding via libcodec2
> +native SBC encoder and decoder
> +drmeter audio filter
> +hapqa_extract bitstream filter
> +filter_units bitstream filter
> +AV1 Support through libaom
> +E-AC-3 dependent frames support
> +bitstream filter for extracting E-AC-3 core
> +Haivision SRT protocol via libsrt
> +vfrdet filter
> +  
> +  
> +We strongly recommend users, distributors, and system integrators to
> +upgrade unless they use current git master.
> +  
> +
>October 15th, 2017, FFmpeg 3.4 "Cantor"
>
>  FFmpeg 3.4 "Cantor", a new
> --
> 2.17.0


What about add HLS Muxer support fragment mp4 and HLS Muxer support
Variant Streams?

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

Re: [FFmpeg-devel] [PATCH 1/1] segafilm: fetch duration from the container

[Gyan Doshi]

On 4/20/2018 8:35 PM, James Almer wrote:



I don't understand the reasoning to invert the logic here. The current
behavior is clearly not right. We're marking Inter coded frames as key
frames and Intra coded frames as non keyframes.


This behaviour was how it was originally. See the sample attached to 
#7091. Before inversion, first frame on that file is not marked as KF 
but all remaining frames are.


If you streamcopy the FATE sample to a new CPK starting at a frame 
currently not marked as KF, with -copyinkf, you should see 
artifact/incorrect decoding in the output.



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

Re: [FFmpeg-devel] [PATCH] web/index: add news entry for release 4.0

[James Almer]

On 4/20/2018 12:21 PM, Steven Liu wrote:
> 2018-04-20 22:27 GMT+08:00 James Almer :
>> Signed-off-by: James Almer 
>> ---
>>  src/index | 50 ++
>>  1 file changed, 50 insertions(+)
>>
>> diff --git a/src/index b/src/index
>> index 2b44762..bbfca29 100644
>> --- a/src/index
>> +++ b/src/index
>> @@ -37,6 +37,56 @@
>>  News
>>
>>
>> +  April 20th, 2018, FFmpeg 4.0 "Wu"
>> +  
>> +FFmpeg 4.0 "Wu", a new
>> +major release, is now available! Some of the highlights:
>> +  
>> +  
>> +Bitstream filters for editing metadata in H.264, HEVC and MPEG-2 
>> streams
>> +Experimental MagicYUV encoder
>> +TiVo ty/ty+ demuxer
>> +Intel QSV-accelerated MJPEG encoding
>> +native aptX and aptX HD encoder and decoder
>> +NVIDIA NVDEC-accelerated H.264, HEVC, MJPEG, MPEG-1/2/4, VC1, VP8/9 
>> hwaccel decoding
>> +Intel QSV-accelerated overlay filter
>> +mcompand audio filter
>> +acontrast audio filter
>> +OpenCL overlay filter
>> +video mix filter
>> +video normalize filter
>> +audio lv2 wrapper filter
>> +VAAPI MJPEG and VP8 decoding
>> +AMD AMF H.264 and HEVC encoders
>> +video fillborders filter
>> +video setrange filter
>> +support LibreSSL (via libtls)
>> +Dropped support for building for Windows XP. The minimum supported 
>> Windows version is Windows Vista.
>> +deconvolve video filter
>> +entropy video filter
>> +hilbert audio filter source
>> +aiir audio filter
>> +Removed the ffserver program
>> +Removed the ffmenc and ffmdec muxer and demuxer
>> +VideoToolbox HEVC encoder and hwaccel
>> +VAAPI-accelerated ProcAmp (color balance), denoise and sharpness 
>> filters
>> +Add android_camera indev
>> +codec2 en/decoding via libcodec2
>> +native SBC encoder and decoder
>> +drmeter audio filter
>> +hapqa_extract bitstream filter
>> +filter_units bitstream filter
>> +AV1 Support through libaom
>> +E-AC-3 dependent frames support
>> +bitstream filter for extracting E-AC-3 core
>> +Haivision SRT protocol via libsrt
>> +vfrdet filter
>> +  
>> +  
>> +We strongly recommend users, distributors, and system integrators to
>> +upgrade unless they use current git master.
>> +  
>> +
>>October 15th, 2017, FFmpeg 3.4 "Cantor"
>>
>>  FFmpeg 3.4 "Cantor", a new
>> --
>> 2.17.0
> 
> 
> What about add HLS Muxer support fragment mp4 and HLS Muxer support
> Variant Streams?

This list is based on the contents of Changelog. What you mention is not
there. But I can add it if it was indeed introduced in this release and
you want it listed.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/1] segafilm: fetch duration from the container

[James Almer]

On 4/20/2018 12:34 PM, Gyan Doshi wrote:
> 
> 
> On 4/20/2018 8:35 PM, James Almer wrote:
> 
> 
>> I don't understand the reasoning to invert the logic here. The current
>> behavior is clearly not right. We're marking Inter coded frames as key
>> frames and Intra coded frames as non keyframes.
> 
> This behaviour was how it was originally. See the sample attached to
> #7091. Before inversion, first frame on that file is not marked as KF
> but all remaining frames are.
> 
> If you streamcopy the FATE sample to a new CPK starting at a frame
> currently not marked as KF, with -copyinkf, you should see
> artifact/incorrect decoding in the output.

Wouldn't this hint that the file in question is broken? I see it was
generated with our muxer, which is indeed setting keyframes wrong.

In line 72 from segafilmenc.c I see

if (pkt->keyframe)
info1 |= (1 << 31);

So basically, a fifteen years old demuxer got its logic inverted to
match the behavior of an evidently faulty month old muxer.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/1] segafilm: fetch duration from the container

[Paul B Mahol]

On 4/20/18, James Almer  wrote:
> On 4/20/2018 12:34 PM, Gyan Doshi wrote:
>>
>>
>> On 4/20/2018 8:35 PM, James Almer wrote:
>>
>>
>>> I don't understand the reasoning to invert the logic here. The current
>>> behavior is clearly not right. We're marking Inter coded frames as key
>>> frames and Intra coded frames as non keyframes.
>>
>> This behaviour was how it was originally. See the sample attached to
>> #7091. Before inversion, first frame on that file is not marked as KF
>> but all remaining frames are.
>>
>> If you streamcopy the FATE sample to a new CPK starting at a frame
>> currently not marked as KF, with -copyinkf, you should see
>> artifact/incorrect decoding in the output.
>
> Wouldn't this hint that the file in question is broken? I see it was
> generated with our muxer, which is indeed setting keyframes wrong.
>
> In line 72 from segafilmenc.c I see
>
> if (pkt->keyframe)
> info1 |= (1 << 31);
>
> So basically, a fifteen years old demuxer got its logic inverted to
> match the behavior of an evidently faulty month old muxer.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>


Take real sample from game, if first frame is not marked as keyframe,
demuxer is wrong.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/1] segafilm: fetch duration from the container

[Gyan Doshi]

On 4/20/2018 9:22 PM, James Almer wrote:


Wouldn't this hint that the file in question is broken?


I don't follow. If the inversion was a mistake, then frames currently 
not marked by demuxer are in fact keyframes and a stream decoded from 
that frame onwards should show correct output. I see precisely the 
opposite. Output generated by streamcopying from currently marked KF 
decode correctly and those generated by streamcopying from currently 
marked non-KF decode incorrectly*.


This should rule out errors in the muxer as well.

* ffmpeg -i logo-capcom.cpk -ss 5.4 -c copy -copyinkf -an copy-test.cpk 
&& ffplay copy-test.cpk



It's very much possible I'm missing something but I don't see what.

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

Re: [FFmpeg-devel] [PATCH 1/1] segafilm: fetch duration from the container

[James Almer]

On 4/20/2018 1:09 PM, Paul B Mahol wrote:
> On 4/20/18, James Almer  wrote:
>> On 4/20/2018 12:34 PM, Gyan Doshi wrote:
>>>
>>>
>>> On 4/20/2018 8:35 PM, James Almer wrote:
>>>
>>>
 I don't understand the reasoning to invert the logic here. The current
 behavior is clearly not right. We're marking Inter coded frames as key
 frames and Intra coded frames as non keyframes.
>>>
>>> This behaviour was how it was originally. See the sample attached to
>>> #7091. Before inversion, first frame on that file is not marked as KF
>>> but all remaining frames are.
>>>
>>> If you streamcopy the FATE sample to a new CPK starting at a frame
>>> currently not marked as KF, with -copyinkf, you should see
>>> artifact/incorrect decoding in the output.
>>
>> Wouldn't this hint that the file in question is broken? I see it was
>> generated with our muxer, which is indeed setting keyframes wrong.
>>
>> In line 72 from segafilmenc.c I see
>>
>> if (pkt->keyframe)
>> info1 |= (1 << 31);
>>
>> So basically, a fifteen years old demuxer got its logic inverted to
>> match the behavior of an evidently faulty month old muxer.
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
> 
> 
> Take real sample from game, if first frame is not marked as keyframe,
> demuxer is wrong.

That's exactly what happens right now with the capcom logo sample in the
FATE suite, as i mentioned earlier.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/1] segafilm: fetch duration from the container

[Gyan Doshi]

On 4/20/2018 9:39 PM, Gyan Doshi wrote:


It's very much possible I'm missing something but I don't see what.


Yup. I see that the decoder sets the frame flags correctly. The ticket 
sample file is wrongly muxed, and so the inversion is wrong.


Will send patch tomorrow unless someone gets to it first.

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

[FFmpeg-devel] [PATCH] Added the possibility to pass an externally created CUDA context to libavutil/hwcontext.c/av_hwdevice_ctx_create() for decoding with NVDEC

[Oscar Amoros Huguet]

Hi!

We changed 4 files in ffmpeg, libavcodec/nvdec.c, libavutil/hwcontext.c, 
libavutil/hwcontext_cuda.h, libavutil/hwcontext_cuda.c.

The purpose of this modification is very simple. We needed, for performance 
reasons (per frame execution time), that nvdec.c used the same CUDA context as 
we use in our software.

The reason for this is not so simple, and two fold:
- We wanted to remove the overhead of having the GPU constantly switching 
contexts, as we use up to 8 nvdec instances at the same time, plus a lot of 
CUDA computations.
- For video syncronization and buffering purposes, after decoding we need to 
download the frame from GPU to CPU, but in a non blocking and overlapped (with 
computation and other transfers) manner, so the impact of the transfer is 
almost zero.

In order to do the later, we need to be able to synchronize our manually 
created CUDA stream with the CUDA stream being used by ffmpeg, which by default 
is the Legacy default stream. 
To do so, we need to be in the same CUDA context, otherwise we don't have 
access to the Legacy CUDA stream being used by ffmpeg.

The conseqüence is, that without changin ffmpeg code, the transfer of the frame 
from GPU to CPU, could not be asynchronous, because if made asynchronous, it 
overlapped with the device to device cuMemcpy made internally by ffmpeg, and 
therefore, the resulting frames where (many times) a mix of two frames.

So what did we change?

- Outside of the ffmpeg code, we allocate an AVBufferRef with 
av_hwdevice_ctx_alloc(AV_HWDEVICE_TYPE_CUDA), and we access the 
AVCUDADeviceContext associated, to set the CUDA context (cuda_ctx).
- We modified libavutil/hwcontext.c call av_hwdevice_ctx_create() so it detects 
that the AVBufferRef being passed, was allocaded externally. We don't check 
that AVHWDeviceType is AV_HWDEVICE_TYPE_CUDA. Let us know if you think we 
should check that, otherwise go back to default behavior.
- If the AVBufferRef was allocated, then we skip the allocation call, and pass 
the data as AVHWDeviceContext type to cuda_device_create.
- We modified libavutil/hwcontext_cuda.c in several parts:
- cuda_device_create detects if there is a cuda context already present in the 
AVCUDADeviceContext, and if so, sets the new parameter 
AVCUDADeviceContext.is_ctx_externally_allocated to 1.
- This way, all the succesive calls to this file, take into account that ffmpeg 
is not responsible for either the creation, thread binding/unbinding and 
destruction of the CUDA context.
- Also, we skip context push and pop if the context was passed externally 
(specially in non initialization calls), to reduce the number of calls to the 
CUDA runtime, and improve the execution times of the CPU threads using ffmpeg.

With this, we managed to have all the CUDA calls in the aplication, in the same 
CUDA context. Also, we use CUDA default stream per-thread, so in order to synch 
with the CUDA stream used by ffmpeg, we only had to put the GPU to CPU copy, to 
the globally accessible cudaStreamPerThread CUDA stream.

So, of 33ms of available time we have per frame, we save more than 6ms, that 
where being used by the blocking copies from GPU to CPU.

We considered further optimizing the code, by changing ffmpeg so it can 
internally access the cudaStreamPerThread, and cuMemcpyAsynch, so the 
DevicetoDevice copies are aslo asynchronous and overlapped with the rest of the 
computation, but the time saved is much lower, and we have other optimizations 
to do in our code, that can save more time.

Nevetheless, if you find interesting this last optimization, let us know.

Also, please, let us know any thing we did wrong or missed.

Thanks! 
   
---
 libavcodec/nvdec.c | 14 +--
 libavutil/hwcontext.c  | 15 ---
 libavutil/hwcontext_cuda.c | 97 --
 libavutil/hwcontext_cuda.h |  1 +
 4 files changed, 80 insertions(+), 47 deletions(-)

diff --git a/libavcodec/nvdec.c b/libavcodec/nvdec.c
index ab3cb88..af92218 100644
--- a/libavcodec/nvdec.c
+++ b/libavcodec/nvdec.c
@@ -39,6 +39,7 @@ typedef struct NVDECDecoder {
 
 AVBufferRef *hw_device_ref;
 CUcontextcuda_ctx;
+int  is_ctx_externally_allocated;
 
 CudaFunctions *cudl;
 CuvidFunctions *cvdl;
@@ -188,6 +189,7 @@ static int nvdec_decoder_create(AVBufferRef **out, 
AVBufferRef *hw_device_ref,
 goto fail;
 }
 decoder->cuda_ctx = device_hwctx->cuda_ctx;
+decoder->is_ctx_externally_allocated = 
device_hwctx->is_ctx_externally_allocated;
 decoder->cudl = device_hwctx->internal->cuda_dl;
 
 ret = cuvid_load_functions(&decoder->cvdl, logctx);
@@ -370,9 +372,11 @@ static int nvdec_retrieve_data(void *logctx, AVFrame 
*frame)
 unsigned int offset = 0;
 int ret = 0;
 
-err = decoder->cudl->cuCtxPushCurrent(decoder->cuda_ctx);
-if (err != CUDA_SUCCESS)
-return AVERROR_UNKNOWN;
+if (!decoder->is_ctx_externally_allocated) {
+err = decoder->cudl->cuCtxPushCu

Re: [FFmpeg-devel] [PATCH] Support for Ambisonics and OpusProjection* API.

[Drew Allen]

Hello all,

Attached is a revised patch based on your suggestions.

Rostislav Pehlivanov - I'm not sure how to address your concerns. My patch
provides support for the ambisonics features already approved and present
in Opus 1.3. If there are ways I can change my patch, please let me know.

Cheers,
Drew

On Mon, Apr 9, 2018 at 10:57 AM Drew Allen  wrote:

> Friendly weekly ping about this patch.
>
> Can someone please let me know if I need to do anything more to submit
> this patch? Thanks!
>
> On Mon, Apr 2, 2018 at 9:13 AM Drew Allen  wrote:
>
>> Friendly ping to allow this to push to the member list, please.
>>
>> On Wed, Mar 28, 2018 at 2:58 PM Drew Allen  wrote:
>>
>>> Hello all,
>>>
>>> My name is Andrew Allen and I'm a contributor to Opus, supporting new
>>> channel mappings 2 and 3 for ambisonics compression. I've attached a patch
>>> to support the new OpusProjectionEncoder and OpusProjectionDecoder APIs for
>>> handling the new channel mapping 3 in OPUS.
>>>
>>> Please let me know of any changes I should make or if there are any
>>> questions I can help answer.
>>>
>>> Cheers,
>>> Drew
>>>
>>
From 35f9b25fbe5dd086b6fab0276d00491b4783cd64 Mon Sep 17 00:00:00 2001
From: Andrew Allen 
Date: Wed, 28 Mar 2018 14:48:46 -0700
Subject: [PATCH] Support for Ambisonics and OpusProjection* API.

---
 libavcodec/libopusdec.c | 159 -
 libavcodec/libopusenc.c | 253 ++--
 libavcodec/opus.c   |  18 ++-
 3 files changed, 350 insertions(+), 80 deletions(-)

diff --git a/libavcodec/libopusdec.c b/libavcodec/libopusdec.c
index 2a97811d18..5caf8f3f53 100644
--- a/libavcodec/libopusdec.c
+++ b/libavcodec/libopusdec.c
@@ -21,6 +21,9 @@
 
 #include 
 #include 
+#ifdef OPUS_HAVE_OPUS_PROJECTION_H
+#include 
+#endif
 
 #include "libavutil/internal.h"
 #include "libavutil/intreadwrite.h"
@@ -33,9 +36,89 @@
 #include "mathops.h"
 #include "libopus.h"
 
+typedef struct OpusGenericDecoder {
+#ifdef OPUS_HAVE_OPUS_PROJECTION_H
+OpusProjectionDecoder *pr;
+#endif
+OpusMSDecoder *ms;
+} OpusGenericDecoder;
+
+static int libopus_generic_decoder_init(OpusGenericDecoder *enc, int Fs,
+int channels, int nb_streams,
+int nb_coupled, uint8_t *mapping,
+uint8_t *dmatrix) {
+int err;
+if (dmatrix != NULL) {
+#ifdef OPUS_HAVE_OPUS_PROJECTION_H
+opus_int32 size;
+size = 2 * channels * (nb_streams + nb_coupled);
+enc->pr = opus_projection_decoder_create(Fs, channels, nb_streams,
+nb_coupled, dmatrix, size, &err);
+#else
+err = OPUS_UNIMPLEMENTED;
+#endif
+return err;
+}
+enc->ms = opus_multistream_decoder_create(Fs, channels, nb_streams,
+nb_coupled, mapping, &err);
+return err;
+}
+
+static void libopus_generic_decoder_cleanup(OpusGenericDecoder *enc)
+{
+#ifdef OPUS_HAVE_OPUS_PROJECTION_H
+if (enc->pr) opus_projection_decoder_destroy(enc->pr);
+#endif
+if (enc->ms) opus_multistream_decoder_destroy(enc->ms);
+}
+
+static int libopus_generic_decode(OpusGenericDecoder *enc,
+const unsigned char *data, opus_int32 len, opus_int16 *pcm,
+int frame_size, int decode_fec) {
+int ret;
+
+#ifdef OPUS_HAVE_OPUS_PROJECTION_H
+if (enc->pr){
+ret=opus_projection_decode(enc->pr, data, len, pcm, frame_size,
+decode_fec);
+return ret;
+}
+#endif
+ret=opus_multistream_decode(enc->ms, data, len, pcm, frame_size,
+decode_fec);
+return ret;
+}
+
+static int libopus_generic_decode_float(OpusGenericDecoder *enc,
+const unsigned char *data, opus_int32 len, float *pcm, int frame_size,
+int decode_fec) {
+int ret;
+
+#ifdef OPUS_HAVE_OPUS_PROJECTION_H
+if (enc->pr){
+ret=opus_projection_decode_float(enc->pr, data, len, pcm, frame_size,
+decode_fec);
+return ret;
+}
+#endif
+ret=opus_multistream_decode_float(enc->ms, data, len, pcm, frame_size,
+decode_fec);
+return ret;
+}
+
+#ifdef OPUS_HAVE_OPUS_PROJECTION_H
+# define libopus_generic_decoder_ctl(enc, request) \
+((enc)->pr != NULL ? \
+opus_projection_decoder_ctl((enc)->pr, request) : \
+opus_multistream_decoder_ctl((enc)->ms, request))
+#else
+# define libopus_generic_decoder_ctl(enc, request) \
+opus_multistream_decoder_ctl((enc)->ms, request)
+#endif
+
 struct libopus_context {
 AVClass *class;
-OpusMSDecoder *dec;
+OpusGenericDecoder dec;
 int pre_skip;
 #ifndef OPUS_SET_GAIN
 union { int i; double d; } gain;
@@ -46,12 +129,17 @@ struct libopus_context {
 };
 
 #define OPUS_HEAD_SIZE 19
+#ifdef OPUS_HAVE_OPUS_PROJECTION_H
+# define OPUS_MAX_CHANNELS 18
+#else
+# define OPUS_MAX_CHANNELS 8
+#endif
 
 static av_cold int libopus_decode_init(AVCodecContext *avc)
 {
 struct libopus_context *opus = avc->priv_data;
 int ret, channel_map = 0, gain_db = 0, nb

Re: [FFmpeg-devel] [PATCH] Support for Ambisonics and OpusProjection* API.

[Rostislav Pehlivanov]

On 20 April 2018 at 18:23, Drew Allen 
wrote:

> Hello all,
>
> Attached is a revised patch based on your suggestions.
>
> Rostislav Pehlivanov - I'm not sure how to address your concerns. My patch
> provides support for the ambisonics features already approved and present
> in Opus 1.3. If there are ways I can change my patch, please let me know.
>
> Cheers,
> Drew
>
> On Mon, Apr 9, 2018 at 10:57 AM Drew Allen  wrote:
>
> > Friendly weekly ping about this patch.
> >
> > Can someone please let me know if I need to do anything more to submit
> > this patch? Thanks!
> >
> > On Mon, Apr 2, 2018 at 9:13 AM Drew Allen  wrote:
> >
> >> Friendly ping to allow this to push to the member list, please.
> >>
> >> On Wed, Mar 28, 2018 at 2:58 PM Drew Allen  wrote:
> >>
> >>> Hello all,
> >>>
> >>> My name is Andrew Allen and I'm a contributor to Opus, supporting new
> >>> channel mappings 2 and 3 for ambisonics compression. I've attached a
> patch
> >>> to support the new OpusProjectionEncoder and OpusProjectionDecoder
> APIs for
> >>> handling the new channel mapping 3 in OPUS.
> >>>
> >>> Please let me know of any changes I should make or if there are any
> >>> questions I can help answer.
> >>>
> >>> Cheers,
> >>> Drew
> >>>
> >>
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>
I am sorry, I don't agree that this should be merged quite yet.

First of all, the draft upon which how the channel family is interpreted
(draft-ietf-codec-ambisonics-04) isn't finalized yet. What if it changes
after we make a release? We can't really change it. This affects both
encoding and decoding.

Second, the API isn't in any libopus release yet. What if we make a
release, the draft changes, so the API in libopus needs to be changed. Or
the API in the current git master of libopus changes? We can't rely on an
unstable API in a library.

Third, this patch makes the decoder always do demixing with the data in
extradata. What if someone wants to just decode and do their own demixing
with positional information? We'd break decoding for anyone who's depending
on the behaviour if we were to change this so the decoder outputs raw
ambisonics. We never do any mixing or conversions in decoders. Hence
ambisonics data needs to be exposed directly, and anyone wanting to demix
it should use a filter (there's an unmerged filter to do that) or do it
themselves.
What we need to do to properly handle ambisonics is:
1. Be able to describe ambisonics. This needs a new API.
2. Be able to expose the demixing matrix via frame side data.
3. Have a filter which can use both to provide a demixed output, better yet
with positional information.

I think the draft should become an RFC first. That gives us enough time to
work on 1.), which should take the longest time to do and agree on. 2.) is
trivial and 3.) is from what I know mostly done.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH v2 1/3] avcodec/bitpacked: move ff_get_buffer

[Patrick Keroulas]

From: Damien Riegel 

ff_get_buffer is used to allocate a buffer to hold frame's content. This
function was called in the function in charge of decoding an AVPacket
containing raw video with the yuv422 pixel format and a depth of 10-bit.

RFC4175 supports both progressive and interlaced mode. But the
interlaced mode doesn't consist of interlaced frames, only of fields.
FFmpeg cannot handle fields on their own, so the codec has to recreate
interlaced frames based on two consecutive fields.

As the function `bitpacked_decode_yuv422p10` will need to be called
twice to do that, it cannot be in charge of the buffer allocation, so
move it into its caller.

Signed-off-by: Damien Riegel 
---
 libavcodec/bitpacked.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/libavcodec/bitpacked.c b/libavcodec/bitpacked.c
index f0b417d..85d4bdd 100644
--- a/libavcodec/bitpacked.c
+++ b/libavcodec/bitpacked.c
@@ -64,9 +64,6 @@ static int bitpacked_decode_yuv422p10(AVCodecContext *avctx, 
AVFrame *frame,
 uint16_t *y, *u, *v;
 int ret, i, j;
 
-ret = ff_get_buffer(avctx, frame, 0);
-if (ret < 0)
-return ret;
 
 if (frame_size > packet_size)
 return AVERROR_INVALIDDATA;
@@ -128,6 +125,12 @@ static int bitpacked_decode(AVCodecContext *avctx, void 
*data, int *got_frame,
 frame->pict_type = AV_PICTURE_TYPE_I;
 frame->key_frame = 1;
 
+if (avctx->pix_fmt == AV_PIX_FMT_YUV422P10) {
+res = ff_get_buffer(avctx, frame, 0);
+if (res < 0)
+return res;
+}
+
 res = bc->decode(avctx, frame, avpkt);
 if (res)
 return res;
-- 
2.7.4

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

[FFmpeg-devel] [PATCH v2 2/3] avcodec/bitpacked: add interlace support

[Patrick Keroulas]

From: Damien Riegel 

This codec is already capable of depacking some combinations of pixel
formats and depth as defined in the RFC4175. The only difference between
progressive and interlace is that either a packet will contain the whole
frame, or only a field of the frame.

There is no mechanism for interlaced frames reconstruction at the rtp
demux level, so it has to be handled by the codec which needs to
partially recompose an AVFrame with every incoming field AVPacket.
A frame is ouput only when the frame is completed with the 2nd field
(bottom).

Signed-off-by: Damien Riegel 
Signed-off-by: Patrick Keroulas 
---

Change v1 -> v2:
 Replaced field packets cloning with partial frame decoding.

 @ Rostislav Pehlivanov: Regarding your comment on v1 (thank you for
 that), I think we can avoid using the bottom field flag because the
 interlaced/progressive format is determined once, at the decoder
 initialization, more precisely when the sdp is parsed. RFC4175
 doesn't define any dynamic flag to switch from one to another.
 So there is no doubt that 'not top field' means 'bottom field'.

---
 libavcodec/avcodec.h   |   4 ++
 libavcodec/bitpacked.c | 115 ++---
 2 files changed, 103 insertions(+), 16 deletions(-)

diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index fb0c6fa..350e8d9 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -1480,6 +1480,10 @@ typedef struct AVPacket {
  */
 #define AV_PKT_FLAG_DISPOSABLE 0x0010
 
+/**
+ * The packet contains a top field.
+ */
+#define AV_PKT_FLAG_TOP_FIELD  0x0010
 
 enum AVSideDataParamChangeFlags {
 AV_SIDE_DATA_PARAM_CHANGE_CHANNEL_COUNT  = 0x0001,
diff --git a/libavcodec/bitpacked.c b/libavcodec/bitpacked.c
index 85d4bdd..84381bd 100644
--- a/libavcodec/bitpacked.c
+++ b/libavcodec/bitpacked.c
@@ -33,15 +33,20 @@
 
 struct BitpackedContext {
 int (*decode)(AVCodecContext *avctx, AVFrame *frame,
-  AVPacket *pkt);
+  AVPacket *pkt, int top_field);
+AVFrame *cur_interlaced_frame;
+int prev_top_field;
 };
 
 /* For this format, it's a simple passthrough */
 static int bitpacked_decode_uyvy422(AVCodecContext *avctx, AVFrame *frame,
-AVPacket *avpkt)
+AVPacket *avpkt, int top_field)
 {
 int ret;
 
+if (frame->interlaced_frame)
+return AVERROR_PATCHWELCOME;
+
 /* there is no need to copy as the data already match
  * a known pixel format */
 frame->buf[0] = av_buffer_ref(avpkt->buf);
@@ -56,17 +61,22 @@ static int bitpacked_decode_uyvy422(AVCodecContext *avctx, 
AVFrame *frame,
 }
 
 static int bitpacked_decode_yuv422p10(AVCodecContext *avctx, AVFrame *frame,
-  AVPacket *avpkt)
+  AVPacket *avpkt, int top_field)
 {
 uint64_t frame_size = (uint64_t)avctx->width * (uint64_t)avctx->height * 
20;
 uint64_t packet_size = (uint64_t)avpkt->size * 8;
+int interlaced = frame->interlaced_frame;
 GetBitContext bc;
 uint16_t *y, *u, *v;
 int ret, i, j;
 
-
-if (frame_size > packet_size)
+/* check packet size depending on the interlaced/progressive format */
+if (interlaced) {
+if ((frame_size >> 1) > packet_size)
+return AVERROR_INVALIDDATA;
+} else if (frame_size > packet_size) {
 return AVERROR_INVALIDDATA;
+}
 
 if (avctx->width % 2)
 return AVERROR_PATCHWELCOME;
@@ -75,7 +85,18 @@ static int bitpacked_decode_yuv422p10(AVCodecContext *avctx, 
AVFrame *frame,
 if (ret)
 return ret;
 
-for (i = 0; i < avctx->height; i++) {
+/*
+ * if the frame is interlaced, the avpkt we are getting is either the top
+ * or the bottom field. If it's the bottom field, it contains all the odd
+ * lines of the recomposed frame, so we start at offset 1.
+ */
+i = (interlaced && !top_field) ? 1 : 0;
+
+/*
+ * Packets from interlaced frames contain either even lines, or odd
+ * lines, so increment by two in that case.
+ */
+for (; i < avctx->height; interlaced ? i += 2 : i++) {
 y = (uint16_t*)(frame->data[0] + i * frame->linesize[0]);
 u = (uint16_t*)(frame->data[1] + i * frame->linesize[1]);
 v = (uint16_t*)(frame->data[2] + i * frame->linesize[2]);
@@ -100,17 +121,35 @@ static av_cold int bitpacked_init_decoder(AVCodecContext 
*avctx)
 
 if (avctx->codec_tag == MKTAG('U', 'Y', 'V', 'Y')) {
 if (avctx->bits_per_coded_sample == 16 &&
-avctx->pix_fmt == AV_PIX_FMT_UYVY422)
+avctx->pix_fmt == AV_PIX_FMT_UYVY422) {
+
+if (avctx->field_order > AV_FIELD_PROGRESSIVE) {
+av_log(avctx, AV_LOG_ERROR, "interlaced not yet supported for 
8-bit\n");
+return AVERROR_PATCHWELCOME;
+}
+
 bc->decode = bitpacked_decode_uyvy422;
-else if (avctx->bits_per_coded_sa

[FFmpeg-devel] [PATCH v2 3/3] avformat/rtpdec_rfc4175: handle interlace format

[Patrick Keroulas]

From: Damien Riegel 

In order to handle the interlaced formats, the demuxer has only a few
things to do:
 - parse the SDP correctly and propagate the information
 - check the field bit in the RFC4175 header, and pass that information
   to the decoder

In interlaced mode, received data only consist of fields, and their
heights are half of the frame size, so some adjustments must be done
here and there to take that into account.

Signed-off-by: Damien Riegel 
---
 libavformat/rtpdec_rfc4175.c | 23 +--
 1 file changed, 21 insertions(+), 2 deletions(-)

diff --git a/libavformat/rtpdec_rfc4175.c b/libavformat/rtpdec_rfc4175.c
index e9c62c1..55a36eb 100644
--- a/libavformat/rtpdec_rfc4175.c
+++ b/libavformat/rtpdec_rfc4175.c
@@ -31,6 +31,8 @@ struct PayloadContext {
 int depth;
 int width;
 int height;
+int interlaced;
+int field;
 
 uint8_t *frame;
 unsigned int frame_size;
@@ -65,10 +67,18 @@ static int rfc4175_parse_format(AVStream *stream, 
PayloadContext *data)
 return AVERROR_INVALIDDATA;
 }
 
+if (data->interlaced)
+stream->codecpar->field_order = AV_FIELD_TT;
+else
+stream->codecpar->field_order = AV_FIELD_PROGRESSIVE;
+
 stream->codecpar->format = pixfmt;
 stream->codecpar->codec_tag = tag;
 stream->codecpar->bits_per_coded_sample = bits_per_sample;
-data->frame_size = data->width * data->height * data->pgroup / data->xinc;
+if (data->interlaced)
+data->frame_size = data->width * (data->height / 2) * data->pgroup / 
data->xinc;
+else
+data->frame_size = data->width * data->height * data->pgroup / 
data->xinc;
 
 return 0;
 }
@@ -85,6 +95,8 @@ static int rfc4175_parse_fmtp(AVFormatContext *s, AVStream 
*stream,
 data->sampling = av_strdup(value);
 else if (!strncmp(attr, "depth", 5))
 data->depth = atoi(value);
+else if (!strncmp(attr, "interlace", 9))
+data->interlaced = 1;
 
 return 0;
 }
@@ -131,7 +143,11 @@ static int rfc4175_finalize_packet(PayloadContext *data, 
AVPacket *pkt,
av_freep(&data->frame);
}
 
+   /* In the packet header, the field is set to 0 for top field
+* and 1 for bottom */
+   pkt->flags |= data->field ? 0 : AV_PKT_FLAG_TOP_FIELD;
data->frame = NULL;
+   data->field = 0;
 
return ret;
 }
@@ -141,7 +157,7 @@ static int rfc4175_handle_packet(AVFormatContext *ctx, 
PayloadContext *data,
  const uint8_t * buf, int len,
  uint16_t seq, int flags)
 {
-int length, line, offset, cont;
+int length, line, offset, cont, field;
 const uint8_t *headers = buf + 2; /* skip extended seqnum */
 const uint8_t *payload = buf + 2;
 int payload_len = len - 2;
@@ -194,11 +210,14 @@ static int rfc4175_handle_packet(AVFormatContext *ctx, 
PayloadContext *data,
 return AVERROR_INVALIDDATA;
 
 length = (headers[0] << 8) | headers[1];
+field = (headers[2] & 0x80);
 line = ((headers[2] & 0x7f) << 8) | headers[3];
 offset = ((headers[4] & 0x7f) << 8) | headers[5];
 cont = headers[4] & 0x80;
 headers += 6;
 
+data->field = field;
+
 if (length % data->pgroup)
 return AVERROR_INVALIDDATA;
 
-- 
2.7.4

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

Re: [FFmpeg-devel] [PATCH] web/index: add news entry for release 4.0

[Michael Niedermayer]

On Fri, Apr 20, 2018 at 11:27:54AM -0300, James Almer wrote:
> Signed-off-by: James Almer 
> ---
>  src/index | 50 ++
>  1 file changed, 50 insertions(+)

This or any variant (for example with more/less entries) LGTM

thanks

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

He who knows, does not speak. He who speaks, does not know. -- Lao Tsu


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

Re: [FFmpeg-devel] [PATCH v2 2/3] avcodec/bitpacked: add interlace support

[Rostislav Pehlivanov]

On 20 April 2018 at 20:02, Patrick Keroulas <
patrick.kerou...@savoirfairelinux.com> wrote:

> From: Damien Riegel 
>
> This codec is already capable of depacking some combinations of pixel
> formats and depth as defined in the RFC4175. The only difference between
> progressive and interlace is that either a packet will contain the whole
> frame, or only a field of the frame.
>
> There is no mechanism for interlaced frames reconstruction at the rtp
> demux level, so it has to be handled by the codec which needs to
> partially recompose an AVFrame with every incoming field AVPacket.
> A frame is ouput only when the frame is completed with the 2nd field
> (bottom).
>
> Signed-off-by: Damien Riegel 
> Signed-off-by: Patrick Keroulas 
> ---
>
> Change v1 -> v2:
>  Replaced field packets cloning with partial frame decoding.
>
>  @ Rostislav Pehlivanov: Regarding your comment on v1 (thank you for
>  that), I think we can avoid using the bottom field flag because the
>  interlaced/progressive format is determined once, at the decoder
>  initialization, more precisely when the sdp is parsed. RFC4175
>  doesn't define any dynamic flag to switch from one to another.
>  So there is no doubt that 'not top field' means 'bottom field'.
>
>
Doesn't matter what RFC4175 says, the decoder needs to be able to handle
any field order sent at any time, including switching to progressive. This
isn't a theoretical situation. What if there's packet loss or the user
switches streams? What if the user doesn't use the decoder for RFC4175 but
rather uses it as a generic unpacker to decode something packed.


  */
>  #define AV_PKT_FLAG_DISPOSABLE 0x0010
>
> +/**
> + * The packet contains a top field.
> + */
> +#define AV_PKT_FLAG_TOP_FIELD  0x0010
>

 This is wrong, AV_PKT_FLAG_DISPOSABLE == AV_PKT_FLAG_TOP_FIELD.


I think there must be a BOTTOM_FIELD flag along with a top field flag, with
neither of them flag meaning packet carries progressive.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] web/index: add news entry for release 4.0

[Rostislav Pehlivanov]

On 20 April 2018 at 20:16, Michael Niedermayer 
wrote:

> On Fri, Apr 20, 2018 at 11:27:54AM -0300, James Almer wrote:
> > Signed-off-by: James Almer 
> > ---
> >  src/index | 50 ++
> >  1 file changed, 50 insertions(+)
>
> This or any variant (for example with more/less entries) LGTM
>
> thanks
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> He who knows, does not speak. He who speaks, does not know. -- Lao Tsu
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>
+1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] web/index: add news entry for release 4.0

[James Almer]

On 4/20/2018 4:41 PM, Rostislav Pehlivanov wrote:
> On 20 April 2018 at 20:16, Michael Niedermayer 
> wrote:
> 
>> On Fri, Apr 20, 2018 at 11:27:54AM -0300, James Almer wrote:
>>> Signed-off-by: James Almer 
>>> ---
>>>  src/index | 50 ++
>>>  1 file changed, 50 insertions(+)
>>
>> This or any variant (for example with more/less entries) LGTM
>>
>> thanks
>>
>> [...]
>> --
>> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>>
>> He who knows, does not speak. He who speaks, does not know. -- Lao Tsu
>>
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
>>
> +1

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

Re: [FFmpeg-devel] avdevice/sdl output : fix window_size and add new option (WIP)

[Moritz Barsnick]

On Sun, Apr 08, 2018 at 17:28:24 +0200, Martin Vignali wrote:

> - 001 : Fix -window_size option
> Before this patch, window_size is always set to the source size
> In other word, -window_size option have no effect.

Makes sense, since the option was already there.

> - 002 : Add option to set the position of the window
> the default behaviour doesn't change (set the position to undefined)

A -window_size syntax such as 1024x768+100+100 would seem intuitive to
me (old Unix/X11 user), but perhaps that's just me, and I guess
AV_OPT_TYPE_IMAGE_SIZE doesn't support that.

> Comments Welcome

-window_size: works for me
-window_enable_quit 0: works for me
-window_pos_x/-window_pos_y: doesn't work for me, but I can only test
 remote X11 (Xwayland) via ssh

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

[FFmpeg-devel] [PATCH] Add system and real time to benchmarking.

[Mark Wachsler]

The -benchmark and -benchmark_all options now show user, system, and real time,
instead of just user time.
---
 fftools/ffmpeg.c | 50 ++--
 1 file changed, 36 insertions(+), 14 deletions(-)

diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 4dbe72186d..d37171d567 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -120,8 +120,14 @@ const char *const forced_keyframes_const_names[] = {
 NULL
 };
 
+typedef struct TimeStamps {
+  int64_t real_usec;
+  int64_t user_usec;
+  int64_t sys_usec;
+} TimeStamps;
+
 static void do_video_stats(OutputStream *ost, int frame_size);
-static int64_t getutime(void);
+static TimeStamps get_time_stamps(void);
 static int64_t getmaxrss(void);
 static int ifilter_has_all_input_formats(FilterGraph *fg);
 
@@ -133,7 +139,7 @@ static int64_t decode_error_stat[2];
 
 static int want_sdp = 1;
 
-static int current_time;
+static TimeStamps current_time;
 AVIOContext *progress_avio = NULL;
 
 static uint8_t *subtitle_out;
@@ -653,7 +659,7 @@ static void abort_codec_experimental(AVCodec *c, int 
encoder)
 static void update_benchmark(const char *fmt, ...)
 {
 if (do_benchmark_all) {
-int64_t t = getutime();
+TimeStamps t = get_time_stamps();
 va_list va;
 char buf[1024];
 
@@ -661,7 +667,11 @@ static void update_benchmark(const char *fmt, ...)
 va_start(va, fmt);
 vsnprintf(buf, sizeof(buf), fmt, va);
 va_end(va);
-av_log(NULL, AV_LOG_INFO, "bench: %8"PRIu64" %s \n", t - 
current_time, buf);
+av_log(NULL, AV_LOG_INFO,
+   "bench: %8" PRIu64 " user %8" PRIu64 " sys %8" PRIu64 " 
real %s \n",
+   t.user_usec - current_time.user_usec,
+   t.sys_usec - current_time.sys_usec,
+   t.real_usec - current_time.real_usec, buf);
 }
 current_time = t;
 }
@@ -4715,23 +4725,30 @@ static int transcode(void)
 return ret;
 }
 
-
-static int64_t getutime(void)
-{
+static TimeStamps get_time_stamps(void) {
+  TimeStamps time_stamps;
+  time_stamps.real_usec = av_gettime_relative();
 #if HAVE_GETRUSAGE
 struct rusage rusage;
 
 getrusage(RUSAGE_SELF, &rusage);
-return (rusage.ru_utime.tv_sec * 100LL) + rusage.ru_utime.tv_usec;
+time_stamps.user_usec =
+(rusage.ru_utime.tv_sec * 100LL) + rusage.ru_utime.tv_usec;
+time_stamps.sys_usec =
+(rusage.ru_stime.tv_sec * 100LL) + rusage.ru_stime.tv_usec;
 #elif HAVE_GETPROCESSTIMES
 HANDLE proc;
 FILETIME c, e, k, u;
 proc = GetCurrentProcess();
 GetProcessTimes(proc, &c, &e, &k, &u);
-return ((int64_t) u.dwHighDateTime << 32 | u.dwLowDateTime) / 10;
+time_stamps.user_usec =
+((int64_t)u.dwHighDateTime << 32 | u.dwLowDateTime) / 10;
+time_stamps.sys_usec =
+((int64_t)k.dwHighDateTime << 32 | k.dwLowDateTime) / 10;
 #else
-return av_gettime_relative();
+time_stamps.user_usec = time_stamps.sys_usec = 0;
 #endif
+return time_stamps;
 }
 
 static int64_t getmaxrss(void)
@@ -4759,7 +4776,7 @@ static void log_callback_null(void *ptr, int level, const 
char *fmt, va_list vl)
 int main(int argc, char **argv)
 {
 int i, ret;
-int64_t ti;
+TimeStamps ti;
 
 init_dynload();
 
@@ -4811,12 +4828,17 @@ int main(int argc, char **argv)
 want_sdp = 0;
 }
 
-current_time = ti = getutime();
+current_time = ti = get_time_stamps();
 if (transcode() < 0)
 exit_program(1);
-ti = getutime() - ti;
 if (do_benchmark) {
-av_log(NULL, AV_LOG_INFO, "bench: utime=%0.3fs\n", ti / 100.0);
+  current_time = get_time_stamps();
+  int64_t utime = current_time.user_usec - ti.user_usec;
+  int64_t stime = current_time.sys_usec - ti.sys_usec;
+  int64_t rtime = current_time.real_usec - ti.real_usec;
+  av_log(NULL, AV_LOG_INFO,
+ "bench: utime=%0.3fs stime=%0.3fs rtime=%0.3fs\n",
+ utime / 100.0, stime / 100.0, rtime / 100.0);
 }
 av_log(NULL, AV_LOG_DEBUG, "%"PRIu64" frames successfully decoded, 
%"PRIu64" decoding errors\n",
decode_error_stat[0], decode_error_stat[1]);
-- 
2.17.0.484.g0c8726318c-goog

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

Re: [FFmpeg-devel] [PATCH 1/6] reitnerlace - tinterlace-like filter under LGPL

[Moritz Barsnick]

On Fri, Apr 20, 2018 at 17:44:17 +0300, Vasile Toncu wrote:
> -typedef struct InterlaceContext {
> -    const AVClass *class;
> -    enum ScanMode scan;    // top or bottom field first scanning
> -    int lowpass;   // enable or disable low pass filtering
> -    AVFrame *cur, *next;   // the two frames from which the new one is 
> obtained
> -    const AVPixFmtDescriptor *csp;
> -    void (*lowpass_line)(uint8_t *dstp, ptrdiff_t linesize, const 
> uint8_t *srcp,

This patch is still corrupted by your mailer, by introducing line
breaks. Please attach it as a file, or use "git send-email"

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

Re: [FFmpeg-devel] [PATCH 2/3] avformat/mov: Fix parsing of saio/siaz atoms in encrypted content.

[Michael Niedermayer]

On Thu, Apr 19, 2018 at 03:04:57PM -0700, Jacob Trimble wrote:
> On Thu, Apr 19, 2018 at 2:07 AM, Michael Niedermayer
>  wrote:
> > On Tue, Jan 09, 2018 at 10:27:28AM -0800, Jacob Trimble wrote:
> >> On Mon, Jan 8, 2018 at 5:39 PM, Carl Eugen Hoyos  
> >> wrote:
> >> > 2018-01-08 23:34 GMT+01:00 Jacob Trimble 
> >> > :
> >> >> On Fri, Jan 5, 2018 at 3:41 PM, Carl Eugen Hoyos  
> >> >> wrote:
> >> >>> 2018-01-05 23:58 GMT+01:00 Jacob Trimble 
> >> >>> :
> >>  On Fri, Jan 5, 2018 at 2:01 PM, Carl Eugen Hoyos  
> >>  wrote:
> >> > 2018-01-05 22:29 GMT+01:00 Jacob Trimble 
> >> > :
> >> >> On Fri, Jan 5, 2018 at 12:41 PM, Carl Eugen Hoyos 
> >> >>  wrote:
> >> >>> 2018-01-05 20:49 GMT+01:00 Jacob Trimble 
> >> >>> :
> >> >>>
> >>  +entry_count = avio_rb32(pb);
> >>  +encryption_index->auxiliary_offsets = 
> >>  av_malloc_array(sizeof(size_t), entry_count);
> >> >>>
> >> >>> (sizeof(variable) instead of sizeof(type), please.)
> >> >>>
> >> >>> But since this could be used for a dos attack, please change this
> >> >>> to something similar to 1112ba01.
> >> >>> If it is easy to avoid it, very short files should not allocate
> >> >>> gigabytes.
> >> >>
> >> >> Switched to calculating the size based on the number of remaining
> >> >> bytes and returning an error if it doesn't match what is read.
> >> >
> >> > Sorry if I miss something:
> >> >
> >> >> +entry_count = (atom.size - 8 - (has_saio_type ? 8 : 0)) / 
> >> >> (version == 0 ? 4 : 8);
> >> >> +if (avio_rb32(pb) != entry_count) {
> >> >> +av_log(c->fc, AV_LOG_ERROR, "incorrect entry_count in 
> >> >> saio\n");
> >> >> +return AVERROR_INVALIDDATA;
> >> >> +}
> >> >> +encryption_index->auxiliary_offsets =
> >> >> +
> >> >> av_malloc_array(sizeof(*encryption_index->auxiliary_offsets), 
> >> >> entry_count);
> >> >
> >> > Does this avoid a 1G allocation for a file of a few bytes?
> >> >
> >> > Didn't you simply increase the number of needed bytes to change in a 
> >> > valid
> >> > mov file to behave maliciously from one to two?
> >> 
> >>  From what I can tell, the mov_read_default method (which is what reads
> >>  child atoms) will verify "atom.size" to fit inside the parent atom.
> >>  This means that for "atom.size" to be excessively large for the file
> >>  size, the input would need to be non-seekable (since I think the
> >>  top-level atom uses the file size) and all the atoms would need to
> >>  have invalid sizes.
> >> >>>
> >> >>> (I did not check this but I am not convinced the sample I fixed last
> >> >>> week is so sophisticated.)
> >> >>>
> >>  But technically I guess it is possible.
> >> >>>
> >> >>> Thank you.
> >> >>>
> >>  But this is basically malloc some number of bytes then read that many
> >>  bytes.  The only alternative I can think of (in the face of
> >>  non-seekable inputs) is to try-read in chunks until we hit EOF or the
> >>  end of the expected size.  This seems like a lot of extra work that is
> >> >>>
> >>  not mirrored elsewhere.
> >> >>>
> >> >>> On the contrary.
> >> >>>
> >> >>> But you are right, I forgot to write that you have to add an "if 
> >> >>> (!eof)"
> >> >>> to the reading loops, see the function that above commit changed.
> >> >>>
> >>  There are several cases where this isn't explicitly checked.
> >> >>>
> >> >>> Yes, and they will be fixed, please don't add another one.
> >> >>>
> >>  Also, how does this attack work?  If the number is way too big, well
> >>  get EOM and error out.
> >> >>>
> >> >>> Which not only causes dos but also makes checking for other (if you
> >> >>> like: more dangerous) issues more difficult which is bad. We already
> >> >>> know that there are cases where the issue is hard to avoid, I believe
> >> >>> this is not such a case.
> >> >>>
> >> >>> It is possible to create (valid) samples that allocate a huge amount
> >> >>> of memory but very small files should not immediately allocate an
> >> >>> amount of several G.
> >> >>
> >> >> Done.
> >> >
> >> > +entry_count = avio_rb32(pb);
> >> >
> >> > This has to be checked for later overflow, same in other spots.
> >>
> >> Done
> >>
> >> >
> >> > +encryption_index->auxiliary_offsets =
> >> > +av_malloc_array(sizeof(*encryption_index->auxiliary_offsets),
> >> > entry_count);
> >> >
> >> > I believe you forgot to remove these two lines.
> >>
> >> Yep, done.
> >>
> >> >
> >> > Note that I chose "1024*1024" arbitrarily to avoid a speed-loss for
> >> > (most likely) all valid files when fixing the dos in 1112ba01.
> >> > I don't know what a good lower limit for your use-case can be, or
> >> > if only using av_fast_realloc() - without the high starting value -
> >> > makes sense.
> >>
> >> Ok, for the saio atoms, it will likely be small (changed it t

Re: [FFmpeg-devel] [PATCH 3/8] lavu: add a Vulkan hwcontext

[Rostislav Pehlivanov]

On 20 April 2018 at 05:30, Rostislav Pehlivanov  wrote:

> This commit adds a Vulkan hwcontext, currently capable of mapping DRM and
> VAAPI frames but additional functionality can be added later to support
> importing of D3D11 surfaces as well as exporting to various other APIs.
>
> This context requires the newest stable version of the Vulkan API,
> and once the new extension for DRM surfaces makes it in will also require
> it (in order to properly and fully import them).
>
> It makes use of every part of the Vulkan spec in order to ensure fastest
> possible uploading, downloading and mapping of frames. On AMD, it will
> also make use of mapping host memory frames in order to upload
> very efficiently and with minimal CPU to hardware.
>
> To be useful for non-RGB images an implementation with the YUV images
> extension is needed. All current implementations support that with the
> exception of AMD, though support is coming soon for Mesa.
>
> Signed-off-by: Rostislav Pehlivanov 
> ---
>  configure  |   12 +
>  doc/APIchanges |3 +
>  libavutil/Makefile |3 +
>  libavutil/hwcontext.c  |4 +
>  libavutil/hwcontext.h  |1 +
>  libavutil/hwcontext_internal.h |1 +
>  libavutil/hwcontext_vulkan.c   | 2125 
>  libavutil/hwcontext_vulkan.h   |  133 ++
>  libavutil/pixdesc.c|4 +
>  libavutil/pixfmt.h |4 +
>  libavutil/version.h|2 +-
>  11 files changed, 2291 insertions(+), 1 deletion(-)
>  create mode 100644 libavutil/hwcontext_vulkan.c
>  create mode 100644 libavutil/hwcontext_vulkan.h
>
> diff --git a/configure b/configure
> index dee507cb6a..cd88f7eae1 100755
> --- a/configure
> +++ b/configure
> @@ -297,6 +297,7 @@ External library support:
>--enable-opengl  enable OpenGL rendering [no]
>--enable-openssl enable openssl, needed for https support
> if gnutls or libtls is not used [no]
> +  --enable-vulkan  enable Vulkan code [no]
>--disable-sndio  disable sndio support [autodetect]
>--disable-schannel   disable SChannel SSP, needed for TLS support on
> Windows if openssl and gnutls are not used
> [autodetect]
> @@ -1761,6 +1762,7 @@ HWACCEL_LIBRARY_LIST="
>  mmal
>  omx
>  opencl
> +vulkan
>  "
>
>  DOCUMENT_LIST="
> @@ -2217,6 +2219,7 @@ HAVE_LIST="
>  opencl_dxva2
>  opencl_vaapi_beignet
>  opencl_vaapi_intel_media
> +vulkan_drm_mod
>  perl
>  pod2man
>  texi2html
> @@ -6322,6 +6325,15 @@ enabled vdpau &&
>
>  enabled crystalhd && check_lib crystalhd "stdint.h
> libcrystalhd/libcrystalhd_if.h" DtsCrystalHDVersion -lcrystalhd
>
> +enabled vulkan &&
> +check_lib vulkan "vulkan/vulkan.h" vkCreateInstance -lvulkan &&
> +check_cpp_condition vulkan vulkan/vulkan.h "defined
> VK_API_VERSION_1_1"
> +
> +if enabled_all vulkan libdrm ; then
> +check_cpp_condition vulkan vulkan/vulkan.h "defined
> VK_EXT_EXTERNAL_MEMORY_DMA_BUF_EXTENSION_NAME"
> +enable vulkan_drm_mod
> +fi


If anyone's wanting to test this keep in mind there's a mistake here, it
should be VK_EXT_IMAGE_DRM_FORMAT_MODIFIER_EXTENSION_NAME and not
VK_EXT_EXTERNAL_MEMORY_DMA_BUF_EXTENSION_NAME. I have it on good authority
the spec will get changed soon so this check will be gone.
Also a change from the WIP patch is this supports forward mapping to DRM.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel