Re: [FFmpeg-devel] [PATCH] lavc/vaapi_encode: Don't pass VAConfigAttribEncPackedHeaders with value set to 0

[Eoff, Ullysses A]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of Mark 
> Thompson
> Sent: Tuesday, February 13, 2018 11:54 AM
> To: FFmpeg development discussions and patches 
> Subject: Re: [FFmpeg-devel] [PATCH] lavc/vaapi_encode: Don't pass 
> VAConfigAttribEncPackedHeaders with value set to 0
> 
> On 13/02/18 18:52, Mark Thompson wrote:
> > On 13/02/18 08:24, Haihao Xiang wrote:
> >> Recent Intel i965 driver commit strictly disallows application to set
> >> unsupported attribute values, VA_ENC_PACKED_HEADER_NONE (0) is not used
> >> in Intel i965 driver, so application shouldn't pass this value to the
> >> driver. On the other hand, VA_ENC_PACKED_HEADER_NONE (0) means the
> >> driver doesn't support any packed header mode, so application also
> >> shouldn't pass packed header to driver if a driver returns
> >> VA_ENC_PACKED_HEADER_NONE (0), the driver should work without
> >> VAConfigAttribEncPackedHeaders set for this case.
> >>
> >> In addition, VA_ATTRIB_NOT_SUPPORTED and VA_ENC_PACKED_HEADER_NONE make
> >> thing messy, we will deprecate VA_ENC_PACKED_HEADER_NONE in the
> >> future. See https://github.com/intel/libva/issues/178 for more information.
> >>
> >> This fixes broken vp9 encoder on Kably Lake with Intel I965 driver.
> >>
> >> Signed-off-by: Haihao Xiang 
> >> ---
> >>  libavcodec/vaapi_encode.c | 4 
> >>  1 file changed, 4 insertions(+)
> >>
> >> diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
> >> index e371f5761ee..1d30aabed40 100644
> >> --- a/libavcodec/vaapi_encode.c
> >> +++ b/libavcodec/vaapi_encode.c
> >> @@ -,6 +,10 @@ static av_cold int 
> >> vaapi_encode_config_attributes(AVCodecContext *avctx)
> >> ctx->va_packed_headers, attr[i].value);
> >>  ctx->va_packed_headers &= attr[i].value;
> >>  }
> >> +
> >> +if (!ctx->va_packed_headers)
> >> +continue;
> >> +
> >>  ctx->config_attributes[ctx->nb_config_attributes++] =
> >>  (VAConfigAttrib) {
> >>  .type  = VAConfigAttribEncPackedHeaders,
> >>
> >
> > This seems wrong to me: the driver has indicated that packed headers are 
> > supported, so the user is providing this attribute to
> indicate to the driver that they will not use any of them.  Compare the VP8 
> case, where the driver does not support them and says so -
> there we correctly don't provide the attribute (though maybe the commentary 
> could be clearer on that).
> 
> Right, I hadn't realised you had already made a change so that encoding is 
> currently broken.  I've made
>  to revert the 
> API/ABI-breaking part of the change.
> 
> Thanks,
> 
> - Mark

I prefer this patch over the one for intel-vaapi-driver.

The va.h documentation for VA_ENC_PACKED_HEADER_NONE
says "Driver does not support any packed headers mode".
Hence, it's only valid for reporting to client that packed headers
are "unsupported".  Unfortunately, VA_ENC_PACKED_HEADER_NONE 
is redundant/ambiguous since there is also
VA_ATTRIB_NOT_SUPPORTED to relay the same information.
This is why we want to deprecate VA_ENC_PACKED_HEADER_NONE
in VAAPI.

I don't think it's correct for clients to send
VA_ENC_PACKED_HEADER_NONE attribute value to the driver
when the driver reports packed headers are "supported".  It
goes against VA_ENC_PACKED_HEADER_NONE's documented
purpose.  AFAIK, libavcodec is the only library that does this.  It
is better to just omit the attribute altogether if client does not
want to use any of the "supported" packed headers.  And this
patch solves that.

In the future, it's probably worth amending VAAPI to allow for
drivers to relay when packed headers are required vs. optional,
too.

U. Artie

> ___
> 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 1/2] avformat/utils: free existing extradata before trying to allocate a new one

[James Almer]

This prevents leaks in the rare cases the function is called when extradata
already exists.

Signed-off-by: James Almer 
---
 libavformat/utils.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavformat/utils.c b/libavformat/utils.c
index 72531d4185..31340a484b 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -3245,6 +3245,7 @@ int ff_alloc_extradata(AVCodecParameters *par, int size)
 {
 int ret;
 
+av_freep(&par->extradata);
 if (size < 0 || size >= INT32_MAX - AV_INPUT_BUFFER_PADDING_SIZE) {
 par->extradata = NULL;
 par->extradata_size = 0;
-- 
2.16.2

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

[FFmpeg-devel] [PATCH 2/2] avformat/utils: simplify ff_alloc_extradata()

[James Almer]

Cosmetic refactor

Signed-off-by: James Almer 
---
 libavformat/utils.c | 26 +++---
 1 file changed, 11 insertions(+), 15 deletions(-)

diff --git a/libavformat/utils.c b/libavformat/utils.c
index 31340a484b..3ca1ca2441 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -3243,24 +3243,20 @@ static int tb_unreliable(AVCodecContext *c)
 
 int ff_alloc_extradata(AVCodecParameters *par, int size)
 {
-int ret;
-
 av_freep(&par->extradata);
-if (size < 0 || size >= INT32_MAX - AV_INPUT_BUFFER_PADDING_SIZE) {
-par->extradata = NULL;
-par->extradata_size = 0;
+par->extradata_size = 0;
+
+if (size < 0 || size >= INT32_MAX - AV_INPUT_BUFFER_PADDING_SIZE)
 return AVERROR(EINVAL);
-}
+
 par->extradata = av_malloc(size + AV_INPUT_BUFFER_PADDING_SIZE);
-if (par->extradata) {
-memset(par->extradata + size, 0, AV_INPUT_BUFFER_PADDING_SIZE);
-par->extradata_size = size;
-ret = 0;
-} else {
-par->extradata_size = 0;
-ret = AVERROR(ENOMEM);
-}
-return ret;
+if (!par->extradata)
+return AVERROR(ENOMEM);
+
+memset(par->extradata + size, 0, AV_INPUT_BUFFER_PADDING_SIZE);
+par->extradata_size = size;
+
+return 0;
 }
 
 int ff_get_extradata(AVFormatContext *s, AVCodecParameters *par, AVIOContext 
*pb, int size)
-- 
2.16.2

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

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

[Xiang, Haihao]

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

Re: [FFmpeg-devel] [PATCH] lavf/oggparseflac: Free flac extradata before reallocating.

[Matthew Wolenetz]

Perhaps true, but there are a ton of paths to ff_alloc_extradata that are
not included in Chromium. Such a wider, general, fix seems more appropriate
to land upstream first with more testing.
For now, this is a particular known case that's occurring in Chromium that
needs fixing.

On Mon, Mar 5, 2018 at 2:10 PM, James Almer  wrote:

> On 3/5/2018 6:54 PM, Matthew Wolenetz wrote:
> >
> > 0001-lavf-oggparseflac-Free-flac-extradata-before-realloc.patch
> >
> >
> > From 5d28b92d9d164b104e9a47b8183cd7ddedfde366 Mon Sep 17 00:00:00 2001
> > From: Matt Wolenetz 
> > Date: Mon, 5 Mar 2018 12:36:28 -0800
> > Subject: [PATCH] lavf/oggparseflac: Free flac extradata before
> reallocating.
> >
> > Otherwise ff_alloc_extradata() just leaks any existing allocated
> > memory.
>
> Maybe ff_alloc_extradata() is the one that should free any existing
> extradata instead of littering the tree with av_freep() calls before
> every ff_alloc_extradata() call. Otherwise you'll keep patching up
> demuxers as your fuzzer generates files for them.
>
> >
> > BUG=789835
> >
> > Change-Id: I8e1c21a16749d28c7f050f5f5d8bffda3b419638
> > Reviewed-on: https://chromium-review.googlesource.com/949415
> > Reviewed-by: Xiaohan Wang 
> > ---
> >  libavformat/oggparseflac.c | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/libavformat/oggparseflac.c b/libavformat/oggparseflac.c
> > index b5f1416a3c..6cb3468022 100644
> > --- a/libavformat/oggparseflac.c
> > +++ b/libavformat/oggparseflac.c
> > @@ -61,6 +61,7 @@ flac_header (AVFormatContext * s, int idx)
> >  st->codecpar->codec_id = AV_CODEC_ID_FLAC;
> >  st->need_parsing = AVSTREAM_PARSE_HEADERS;
> >
> > +av_freep(&st->codecpar->extradata);
> >  if (ff_alloc_extradata(st->codecpar, FLAC_STREAMINFO_SIZE) < 0)
> >  return AVERROR(ENOMEM);
> >  memcpy(st->codecpar->extradata, streaminfo_start,
> st->codecpar->extradata_size);
> > -- 2.16.2.395.g2e18187dfd-goog
> >
> >
> >
> > ___
> > 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

[FFmpeg-devel] [PATCH] lavc/vorbisdec: Allow avcodec_open2 to call .close

[Matthew Wolenetz]

From 7471c1d223b860c13793abfd93174d1557f77d6f Mon Sep 17 00:00:00 2001
From: Matt Wolenetz 
Date: Mon, 5 Mar 2018 15:59:18 -0800
Subject: [PATCH] lavc/vorbisdec: Allow avcodec_open2 to call .close

If there is a decoder initialization failure detected in avcodec_open2
after .init is called, allow graceful decoder .close to prevent leaking
vorbis decoder allocations such as those from vorbis_parse_setup_*.

BUG=772699
---
 libavcodec/vorbisdec.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavcodec/vorbisdec.c b/libavcodec/vorbisdec.c
index 2a4f482031..00e9cd8a13 100644
--- a/libavcodec/vorbisdec.c
+++ b/libavcodec/vorbisdec.c
@@ -1862,6 +1862,7 @@ AVCodec ff_vorbis_decoder = {
 .decode  = vorbis_decode_frame,
 .flush   = vorbis_decode_flush,
 .capabilities= AV_CODEC_CAP_DR1,
+.caps_internal   = FF_CODEC_CAP_INIT_CLEANUP,
 .channel_layouts = ff_vorbis_channel_layouts,
 .sample_fmts = (const enum AVSampleFormat[]) { AV_SAMPLE_FMT_FLTP,
AV_SAMPLE_FMT_NONE },
-- 
2.16.2.395.g2e18187dfd-goog

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

Re: [FFmpeg-devel] [PATCH] lavc/qsvenc: disable h264 look_ahead by default

[Mark Thompson]

On 01/03/18 05:20, Zhong Li wrote:
> Look_ahead can provide quality improvements, but would better disable it by 
> default due to some reasons:
> 1. It is only available for some codecs (e.g. HEVC is not supported) on Intel
>Haswell and plus platforms. Thus means it will be failed on some platforms.
> 2. It significantly increases encoding latency and memory consumption.
> 3. It may overwrite some other options such as CBR and CAVLC.
> 
> Signed-off-by: Zhong Li 
> ---
>  libavcodec/qsvenc_h264.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavcodec/qsvenc_h264.c b/libavcodec/qsvenc_h264.c
> index 09e4c0e..e01a2a3 100644
> --- a/libavcodec/qsvenc_h264.c
> +++ b/libavcodec/qsvenc_h264.c
> @@ -109,7 +109,7 @@ static const AVOption options[] = {
>  { "max_dec_frame_buffering", "Maximum number of frames buffered in the 
> DPB", OFFSET(qsv.max_dec_frame_buffering), AV_OPT_TYPE_INT, { .i64 = 0 },   
> 0, UINT16_MAX, VE },
>  
>  #if QSV_HAVE_LA
> -{ "look_ahead",   "Use VBR algorithm with look ahead",
> OFFSET(qsv.look_ahead),   AV_OPT_TYPE_INT, { .i64 = 1 }, 0, 1, VE },
> +{ "look_ahead",   "Use VBR algorithm with look ahead",
> OFFSET(qsv.look_ahead),   AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 1, VE },
>  { "look_ahead_depth", "Depth of look ahead in number frames", 
> OFFSET(qsv.look_ahead_depth), AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 100, VE },
>  #endif
>  #if QSV_HAVE_LA_DS
> 

I agree with everything you've said, so applied.

(I held off from making essentially this change in previous merges for 
compatibility with existing command-lines, but I think given that the next 
release will be a new major version that shouldn't block it now.)

Thanks,

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

[FFmpeg-devel] [PATCH] avutil/parseutils: only accept full us duration, do not accept mss duration

[Marton Balint]

Accepting 'u' suffix for a time specification is neither intuitive nor
consistent (now that we don't accept m). Also there was a bug in the code
accepting an extra 's' even after 'ms'.

Signed-off-by: Marton Balint 
---
 libavutil/parseutils.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/libavutil/parseutils.c b/libavutil/parseutils.c
index 95274f564f..924c49d52c 100644
--- a/libavutil/parseutils.c
+++ b/libavutil/parseutils.c
@@ -693,12 +693,11 @@ int av_parse_time(int64_t *timeval, const char *timestr, 
int duration)
 suffix = 1000;
 microseconds /= 1000;
 q += 2;
-} else if (*q == 'u') {
+} else if (q[0] == 'u' && q[1] == 's') {
 suffix = 1;
 microseconds = 0;
-q++;
-}
-if (*q == 's')
+q += 2;
+} else if (*q == 's')
 q++;
 } else {
 int is_utc = *q == 'Z' || *q == 'z';
-- 
2.13.6

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

Re: [FFmpeg-devel] [PATCH] libavformat/mov.c: use calculated dts offset when seeking in streams

[Sasi Inguva]

This patch seems to be doing the wrong thing and breaking seek tests for us.

As far as I understand , seeking for most containers is based on "decoding
timestamp". Unless  AV_SEEK_TO_PTS flag is specified in container, which is
not for most containers and MOV.  So if PTS and DTS are like such,
Pts  Dts
 0  -2   : frame0
 1  -1   : frame1
 2   0   : frame2
 3   1   : frame3
...
Seeking  to "0" timestamp without any flags, I should expect frame2 . But
instead this patch will give me frame0 . The patch's intention seems to be
seeking based on PTS (subtracting by the sc->time_offset essentially is a
mapping from PTS to DTS) .

To fix your specific issue https://trac.ffmpeg.org/ticket/6139

,
you can use AV_SEEK_BACKWARD flag while seeking in seek_to_start
http://git.videolan.org/?p=ffmpeg.git;a=blob;f=fftools/ffmpeg.c;h=ee7258fcd1f65b6670f19686b51d5b41ee72f7ac;hb=HEAD#l4165


On Sun, Oct 29, 2017 at 4:11 AM, Peter Große  wrote:

> From: Jonas Licht 
>
> Subtract the calculated dts offset from the requested timestamp before
> seeking. This fixes an error "Error while filtering: Operation not
> permitted" observed with a short file which contains only one key frame
> and starts with negative timestamps.
>
> Then, av_index_search_timestamp() returns a valid negative timestamp,
> but mov_seek_stream bails out with AVERROR_INVALIDDATA.
>
> Fixes ticket #6139.
>
> Signed-off-by: Jonas Licht 
> Signed-off-by: Peter Große 
> ---
>
> Compared to the other seek results in this test, the values are not
> that far off.
>
>  libavformat/mov.c|  6 --
>  tests/ref/seek/extra-mp4 | 16 
>  2 files changed, 12 insertions(+), 10 deletions(-)
>
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index 2ee67561e4..60a0f4ccf4 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -6882,10 +6882,12 @@ static int mov_seek_fragment(AVFormatContext *s,
> AVStream *st, int64_t timestamp
>  static int mov_seek_stream(AVFormatContext *s, AVStream *st, int64_t
> timestamp, int flags)
>  {
>  MOVStreamContext *sc = st->priv_data;
> -int sample, time_sample;
> +int sample, time_sample, ret;
>  unsigned int i;
>
> -int ret = mov_seek_fragment(s, st, timestamp);
> +timestamp -= sc->time_offset;
> +
> +ret = mov_seek_fragment(s, st, timestamp);
>  if (ret < 0)
>  return ret;
>
> diff --git a/tests/ref/seek/extra-mp4 b/tests/ref/seek/extra-mp4
> index c25544c095..c17ce4003c 100644
> --- a/tests/ref/seek/extra-mp4
> +++ b/tests/ref/seek/extra-mp4
> @@ -28,10 +28,10 @@ ret: 0 st: 0 flags:0 dts: 50.63 pts:
> 50.73 pos:5926157 size:  13
>  ret: 0 st: 0 flags:0 dts: 50.67 pts: 50.67 pos:5927464
> size:   150
>  ret: 0 st: 0 flags:0 dts: 50.70 pts: 50.70 pos:5927614
> size:   176
>  ret: 0 st:-1 flags:1  ts: 153.470835
> -ret: 0 st: 0 flags:1 dts: 153.47 pts: 153.50 pos:15867700
> size: 96169
> -ret: 0 st: 0 flags:0 dts: 153.50 pts: 153.53 pos:15963869
> size:   785
> -ret: 0 st: 0 flags:0 dts: 153.53 pts: 153.63 pos:15964654
> size:  3135
> -ret: 0 st: 0 flags:0 dts: 153.57 pts: 153.57 pos:15967789
> size:   859
> +ret: 0 st: 0 flags:1 dts: 151.97 pts: 152.00 pos:15705355
> size:146924
> +ret: 0 st: 0 flags:0 dts: 152.00 pts: 152.10 pos:15852279
> size:  1355
> +ret: 0 st: 0 flags:0 dts: 152.03 pts: 152.03 pos:15853634
> size:   211
> +ret: 0 st: 0 flags:0 dts: 152.07 pts: 152.07 pos:15853845
> size:   217
>  ret: 0 st: 0 flags:0  ts: 76.365000
>  ret: 0 st: 0 flags:1 dts: 77.83 pts: 77.87 pos:8659657
> size: 41182
>  ret: 0 st: 0 flags:0 dts: 77.87 pts: 77.97 pos:8700839
> size:  4197
> @@ -83,10 +83,10 @@ ret: 0 st: 0 flags:0 dts: 101.33 pts:
> 101.43 pos:11049548 size:
>  ret: 0 st: 0 flags:0 dts: 101.37 pts: 101.37 pos:11053072
> size:   562
>  ret: 0 st: 0 flags:0 dts: 101.40 pts: 101.40 pos:11053634
> size:   599
>  ret: 0 st:-1 flags:0  ts: 25.306672
> -ret: 0 st: 0 flags:1 dts: 27.40 pts: 27.43 pos:2674605
> size:127383
> -ret: 0 st: 0 flags:0 dts: 27.43 pts: 27.47 pos:2801988
> size:68
> -ret: 0 st: 0 flags:0 dts: 27.47 pts: 27.50 pos:2802268
> size:  1754
> -ret: 0 st: 0 flags:0 dts: 27.50 pts: 27.53 pos:2804022
> size:  4071
> +ret: 0 st: 0 flags:1 dts: 25.30 pts: 25.33 pos:2607246
> size: 40273
> +ret: 0 st: 0 flags:0 dts: 25.33 pts: 25.43 pos:2647519
> size:  2959
> +ret: 0 st: 0 flags:0 dts: 25.37 pts: 25.37 pos:2650478
> size:   197
> +ret: 0 st: 0 flags:0 dts: 25.40 pts: 25.40 pos:2650675
> size:   230
>  ret: 0 st:-1 flags:1  ts: 128.

Re: [FFmpeg-devel] [PATCH 3/3] mpegvideo_parser: fix indentation of an if statement

[Jan Ekström]

On Sun, Feb 11, 2018 at 4:37 PM, Jan Ekström  wrote:
> From: Masaki Tanaka 
>
> ---
>  libavcodec/mpegvideo_parser.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/mpegvideo_parser.c b/libavcodec/mpegvideo_parser.c
> index 4f554b684e..ecf7c28e72 100644
> --- a/libavcodec/mpegvideo_parser.c
> +++ b/libavcodec/mpegvideo_parser.c
> @@ -63,7 +63,7 @@ static void mpegvideo_extract_headers(AVCodecParserContext 
> *s,
>  s->output_picture_number = (buf[0] << 2) | (buf[1] >> 6);
>  s->pict_type = (buf[1] >> 3) & 7;
>  if (bytes_left >= 4)
> -vbv_delay = ((buf[1] & 0x07) << 13) | (buf[2] << 5) | 
> (buf[3]  >> 3);
> +vbv_delay = ((buf[1] & 0x07) << 13) | (buf[2] << 5) | 
> (buf[3] >> 3);
>  }
>  break;
>  case SEQ_START_CODE:
> --
> 2.14.3
>

Ping.

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

Re: [FFmpeg-devel] [PATCH 2/3] mpegvideo_parser: parse the output picture number

[Jan Ekström]

On Sun, Feb 11, 2018 at 8:31 PM, Jan Ekström  wrote:
> On Sun, Feb 11, 2018 at 7:52 PM, Michael Niedermayer
>  wrote:
>>
>> should be ok unless its intended to also restore the MSB
>>
>
> The value seemed to be 10bit and if the pointer is at the position
> right after the picture_start_code, then `buf[0] << 2` would move the
> 8 bits left of data two bits leftwards, and `buf[1] >> 6` would then
> move the topmost bits of the following byte to be the bottom-most
> bits.
>
> Unless you mean that there's a forgotten `(uint16_t)` there as the end
> value has 10 bits of effective data, making the correct way of doing
> it something a la `(((uint16_t)buf[0]) << 2) | (((uint16_t)buf[1]) >>
> 6)`?
>

Ping regarding this part.

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

Re: [FFmpeg-devel] [PATCH] lavf/oggparseflac: Free flac extradata before reallocating.

[James Almer]

On 3/5/2018 6:54 PM, Matthew Wolenetz wrote:
> 
> 0001-lavf-oggparseflac-Free-flac-extradata-before-realloc.patch
> 
> 
> From 5d28b92d9d164b104e9a47b8183cd7ddedfde366 Mon Sep 17 00:00:00 2001
> From: Matt Wolenetz 
> Date: Mon, 5 Mar 2018 12:36:28 -0800
> Subject: [PATCH] lavf/oggparseflac: Free flac extradata before reallocating.
> 
> Otherwise ff_alloc_extradata() just leaks any existing allocated
> memory.

Maybe ff_alloc_extradata() is the one that should free any existing
extradata instead of littering the tree with av_freep() calls before
every ff_alloc_extradata() call. Otherwise you'll keep patching up
demuxers as your fuzzer generates files for them.

> 
> BUG=789835
> 
> Change-Id: I8e1c21a16749d28c7f050f5f5d8bffda3b419638
> Reviewed-on: https://chromium-review.googlesource.com/949415
> Reviewed-by: Xiaohan Wang 
> ---
>  libavformat/oggparseflac.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/libavformat/oggparseflac.c b/libavformat/oggparseflac.c
> index b5f1416a3c..6cb3468022 100644
> --- a/libavformat/oggparseflac.c
> +++ b/libavformat/oggparseflac.c
> @@ -61,6 +61,7 @@ flac_header (AVFormatContext * s, int idx)
>  st->codecpar->codec_id = AV_CODEC_ID_FLAC;
>  st->need_parsing = AVSTREAM_PARSE_HEADERS;
>  
> +av_freep(&st->codecpar->extradata);
>  if (ff_alloc_extradata(st->codecpar, FLAC_STREAMINFO_SIZE) < 0)
>  return AVERROR(ENOMEM);
>  memcpy(st->codecpar->extradata, streaminfo_start, 
> st->codecpar->extradata_size);
> -- 2.16.2.395.g2e18187dfd-goog
> 
> 
> 
> ___
> 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] lavf/oggparseflac: Free flac extradata before reallocating.

[Matthew Wolenetz]

From 5d28b92d9d164b104e9a47b8183cd7ddedfde366 Mon Sep 17 00:00:00 2001
From: Matt Wolenetz 
Date: Mon, 5 Mar 2018 12:36:28 -0800
Subject: [PATCH] lavf/oggparseflac: Free flac extradata before reallocating.

Otherwise ff_alloc_extradata() just leaks any existing allocated
memory.

BUG=789835

Change-Id: I8e1c21a16749d28c7f050f5f5d8bffda3b419638
Reviewed-on: https://chromium-review.googlesource.com/949415
Reviewed-by: Xiaohan Wang 
---
 libavformat/oggparseflac.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavformat/oggparseflac.c b/libavformat/oggparseflac.c
index b5f1416a3c..6cb3468022 100644
--- a/libavformat/oggparseflac.c
+++ b/libavformat/oggparseflac.c
@@ -61,6 +61,7 @@ flac_header (AVFormatContext * s, int idx)
 st->codecpar->codec_id = AV_CODEC_ID_FLAC;
 st->need_parsing = AVSTREAM_PARSE_HEADERS;
 
+av_freep(&st->codecpar->extradata);
 if (ff_alloc_extradata(st->codecpar, FLAC_STREAMINFO_SIZE) < 0)
 return AVERROR(ENOMEM);
 memcpy(st->codecpar->extradata, streaminfo_start, st->codecpar->extradata_size);
-- 
2.16.2.395.g2e18187dfd-goog

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

Re: [FFmpeg-devel] [PATCH] parseutils: accept only full "ms" and "us" prefixes

[Rostislav Pehlivanov]

On 5 March 2018 at 16:47, Aurelien Jacobs  wrote:

> On Sat, Mar 03, 2018 at 08:19:43PM +, Rostislav Pehlivanov wrote:
> > The commit which added those was pushed prematurely before anyone could
> object
> > to illogical suffixes like just m for milliseconds.
>
> What you call illogical is following the same convention as pretty much
> all numeric parameters in ffmpeg. (bitrate, bufsize, framerate...)
> So it is at least consistent.
>
> > Without this, we'd be locked
> > into never being able to implement the "m" suffix for minutes.
>
> I will always be against using "m" for minute, but you can use "min" if
> you want.
>
> > Signed-off-by: Rostislav Pehlivanov 
> > ---
> >  libavutil/parseutils.c | 10 --
> >  1 file changed, 4 insertions(+), 6 deletions(-)
> >
> > diff --git a/libavutil/parseutils.c b/libavutil/parseutils.c
> > index 44c845577a..1b81757aab 100644
> > --- a/libavutil/parseutils.c
> > +++ b/libavutil/parseutils.c
> > @@ -689,17 +689,15 @@ int av_parse_time(int64_t *timeval, const char
> *timestr, int duration)
> >
> >  if (duration) {
> >  t = dt.tm_hour * 3600 + dt.tm_min * 60 + dt.tm_sec;
> > -if (*q == 'm') {
> > +if (q[0] == 'm' && q[1] == 's') {
> >  suffix = 1000;
> >  microseconds /= 1000;
> > -q++;
> > -} else if (*q == 'u') {
> > +q += 2;
> > +} else if (q[0] == 'u' && q[1] == 's') {
> >  suffix = 1;
> >  microseconds = 0;
> > -q++;
> > +q += 2;
> >  }
> > -if (*q == 's')
> > -q++;
> >  } else {
> >  int is_utc = *q == 'Z' || *q == 'z';
> >  int tzoffset = 0;
>
> Why do you remove support for using just 's' as a unit without prefix ?
> I've seen no one complaining about it and I can't see any issue with it.
>
> Also I don't like that this patch makes AV_OPT_TYPE_DURATION
> inconsistant with every other numeric parameters, that all accept a SI
> prefix without unit.
> (that include opus_delay for which "3.5" and "3500m" are equivalent)
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

Dropped the "us" requirement and applied the patch.
Keeping the SI requirement where it doesn't make sense (and preventing us
from extending the option to something that does make sense) is worse than
being inconsistent.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 7/9] sbcenc: add MMX optimizations

[Rostislav Pehlivanov]

On 24 February 2018 at 12:05, Aurelien Jacobs  wrote:

> On Thu, Feb 22, 2018 at 05:21:57PM +, Rostislav Pehlivanov wrote:
> > On 21 February 2018 at 22:37, Aurelien Jacobs  wrote:
> > [...]
> > > +;***
> > > +;void ff_sbc_analyze_4(const int16_t *in, int32_t *out, const int16_t
> > > *consts);
> > > +;***
> > > +INIT_MMX mmx
> > > +cglobal sbc_analyze_4, 3, 3, 4, in, out, consts
> > > +movq  m0, [inq]
> > > +movq  m1, [inq+8]
> > > +pmaddwd   m0, [constsq]
> > > +pmaddwd   m1, [constsq+8]
> > > +paddd m0, [scale_mask]
> > > +paddd m1, [scale_mask]
> > > +
> > > +movq  m2, [inq+16]
> > > +movq  m3, [inq+24]
> > > +pmaddwd   m2, [constsq+16]
> > > +pmaddwd   m3, [constsq+24]
> > > +paddd m0, m2
> > > +paddd m1, m3
> > > +
> > > +movq  m2, [inq+32]
> > > +movq  m3, [inq+40]
> > > +pmaddwd   m2, [constsq+32]
> > > +pmaddwd   m3, [constsq+40]
> > > +paddd m0, m2
> > > +paddd m1, m3
> > > +
> > > +movq  m2, [inq+48]
> > > +movq  m3, [inq+56]
> > > +pmaddwd   m2, [constsq+48]
> > > +pmaddwd   m3, [constsq+56]
> > > +paddd m0, m2
> > > +paddd m1, m3
> > > +
> > > +movq  m2, [inq+64]
> > > +movq  m3, [inq+72]
> > > +pmaddwd   m2, [constsq+64]
> > > +pmaddwd   m3, [constsq+72]
> > > +paddd m0, m2
> > > +paddd m1, m3
> > >
> >
> > You can macro the top 3 blocks
> >
> > [...]
> > > +;***
> > > +;void ff_sbc_analyze_8(const int16_t *in, int32_t *out, const int16_t
> > > *consts);
> > > +;***
> > > +INIT_MMX mmx
> > > +cglobal sbc_analyze_8, 3, 3, 4, in, out, consts
> > > +movq  m0, [inq]
> > > +movq  m1, [inq+8]
> > > +movq  m2, [inq+16]
> > > +movq  m3, [inq+24]
> > > +pmaddwd   m0, [constsq]
> > > +pmaddwd   m1, [constsq+8]
> > > +pmaddwd   m2, [constsq+16]
> > > +pmaddwd   m3, [constsq+24]
> > > +paddd m0, [scale_mask]
> > > +paddd m1, [scale_mask]
> > > +paddd m2, [scale_mask]
> > > +paddd m3, [scale_mask]
> > > +
> > > +movq  m4, [inq+32]
> > > +movq  m5, [inq+40]
> > > +movq  m6, [inq+48]
> > > +movq  m7, [inq+56]
> > > +pmaddwd   m4, [constsq+32]
> > > +pmaddwd   m5, [constsq+40]
> > > +pmaddwd   m6, [constsq+48]
> > > +pmaddwd   m7, [constsq+56]
> > > +paddd m0, m4
> > > +paddd m1, m5
> > > +paddd m2, m6
> > > +paddd m3, m7
> > > +
> > > +movq  m4, [inq+64]
> > > +movq  m5, [inq+72]
> > > +movq  m6, [inq+80]
> > > +movq  m7, [inq+88]
> > > +pmaddwd   m4, [constsq+64]
> > > +pmaddwd   m5, [constsq+72]
> > > +pmaddwd   m6, [constsq+80]
> > > +pmaddwd   m7, [constsq+88]
> > > +paddd m0, m4
> > > +paddd m1, m5
> > > +paddd m2, m6
> > > +paddd m3, m7
> > > +
> > > +movq  m4, [inq+96]
> > > +movq  m5, [inq+104]
> > > +movq  m6, [inq+112]
> > > +movq  m7, [inq+120]
> > > +pmaddwd   m4, [constsq+96]
> > > +pmaddwd   m5, [constsq+104]
> > > +pmaddwd   m6, [constsq+112]
> > > +pmaddwd   m7, [constsq+120]
> > > +paddd m0, m4
> > > +paddd m1, m5
> > > +paddd m2, m6
> > > +paddd m3, m7
> > > +
> > > +movq  m4, [inq+128]
> > > +movq  m5, [inq+136]
> > > +movq  m6, [inq+144]
> > > +movq  m7, [inq+152]
> > > +pmaddwd   m4, [constsq+128]
> > > +pmaddwd   m5, [constsq+136]
> > > +pmaddwd   m6, [constsq+144]
> > > +pmaddwd   m7, [constsq+152]
> > > +paddd m0, m4
> > > +paddd m1, m5
> > > +paddd m2, m6
> > > +paddd m3, m7
> > >
> >
> > And those 5 blocks
> >
> >
> > > +
> > > +psrad m0, 16; SBC_PROTO_FIXED_SCALE
> > > +psrad m1, 16; SBC_PROTO_FIXED_SCALE
> > > +psrad m2, 16; SBC_PROTO_FIXED_SCALE
> > > +psrad m3, 16; SBC_PROTO_FIXED_SCALE
> > > +
> > > +packssdw  m0, m0
> > > +packssdw  m1, m1
> > > +packssdw  m2, m2
> > > +packssdw  m3, m3
> > > +
> > > +movq  m4, m0
> > > +movq  m5, m0
> > > +pmaddwd   m4, [constsq+160]
> > > +pmaddwd   m5, [constsq+168]
> > > +
> > > +movq  m6, m1
> > 

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

[Rostislav Pehlivanov]

On 3 March 2018 at 16:20, Aurelien Jacobs  wrote:

> On Thu, Mar 01, 2018 at 10:46:07PM +, Rostislav Pehlivanov wrote:
> > On 1 March 2018 at 20:45, Aurelien Jacobs  wrote
> >
> > >
> > > So what I propose is to rename sbc_delay to sbc_latency (for example),
> > > and to add a opus_latecy using AV_OPT_TYPE_DURATION that will deprecate
> > > opus_delay. I think that's the best way forward if you care about
> > > consistency.
> > >
> >
> > Yeah, that's great as long as that patch gets accepted.
>
> Any other issue left ?
> If not, I will apply this patch series in a few days.
>

Go ahead, everything seems fine now.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] compat: remove in-tree NVidia headers

[Timo Rothenpieler]

Am 05.03.2018 um 21:17 schrieb Lou Logan:

On Mon, Mar 5, 2018, at 11:07 AM, Timo Rothenpieler wrote:


I tried to do that multiple times already, but trac won't let me login,
it just eventually runs into a Gateway Timeout if I try.


Weird. I can't duplicate that issue. Is anyone else experiencing this?

If you give me the info I can add it until we figure out the trac issue.


It worked now, added the necessary info.



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

Re: [FFmpeg-devel] [PATCH] configure: rename cuda to ffnvcodec

[Timo Rothenpieler]

Am 04.03.2018 um 20:15 schrieb Compn:

On Sat,  3 Mar 2018 22:39:45 +0100, Timo Rothenpieler
 wrote:


Right now, if someone configures ffmpeg with for example --enable-nvenc they 
will
get an error message complaining about missing cuda.
This is very confusing and already has lead people into installing the CUDA SDK,
even though it's not what they need.

This will make it complain about ffnvcodec instead.


i'm not objecting.

but if you put a error message that explains what a person needs when
it errors , that might also be a good idea (and it would also only be
a one or two line change).

-compn


I looked into doing that, but the code handling those errors in a 
generic way would need quite some ugly special cases to do that.


Still, I might look into giving a better error that at some point.

It being called cuda is inaccurate anyway, so renaming it to ffnvcodec 
is not too terrible.


So for now, I just pushed this, and will look into a more verbose error 
later.




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

Re: [FFmpeg-devel] patch for ticket #7053

[Rostislav Pehlivanov]

On 5 March 2018 at 13:04, Pierre Chatelier  wrote:

> Here is a patch proposition for https://trac.ffmpeg.org/ticket/7053
>
> Pierre Chatelier
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>
No, you need to template it with macros. No point in having hundreds of
duplicated lines.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/3] avformat/mov: Increase support for common encryption.

[Jacob Trimble]

On Mon, Feb 12, 2018 at 9:35 AM, Jacob Trimble  wrote:
> On Tue, Jan 30, 2018 at 11:27 AM, Jacob Trimble  wrote:
>> On Wed, Jan 24, 2018 at 5:46 PM, Michael Niedermayer
>>  wrote:
>>> On Wed, Jan 24, 2018 at 11:43:26AM -0800, Jacob Trimble wrote:
 On Mon, Jan 22, 2018 at 7:38 PM, Michael Niedermayer
  wrote
 > [...]
 >> This removes support for saio/saiz atoms, but it was incorrect before.
 >> A follow-up change will add correct support for those.
 >
 > This removal should be done by a seperate patch if it is done.
 > diff has matched up the removed function with a added one making this
 > hard to read as is
 >

 The problem is that the old code used the saiz atoms to parse the senc
 atom.  I split the patch up for readability, but the two patches need
 to be applied at the same time (or squashed) since the first breaks
 encrypted content.  But I can squash them again if it is preferable to
 not have a commit that intentionally breaks things.
>>>
>>> I didnt investigate this deeply so there is likely a better option that
>>> i miss but you could just remove the functions which become unused in a
>>> subsequent patch to prevent diff from messing the line matching up totally
>>>
>>
>> Done.
>>
>>>

 >
 >>
 >> Signed-off-by: Jacob Trimble 
 >> ---
 >>  libavformat/isom.h |  20 +-
 >>  libavformat/mov.c  | 432 
 >> ++---
 >>  tests/fate/mov.mak |   8 +
 >>  tests/ref/fate/mov-frag-encrypted  |  57 +
 >>  tests/ref/fate/mov-tenc-only-encrypted |  57 +
 >>  5 files changed, 422 insertions(+), 152 deletions(-)
 >>  create mode 100644 tests/ref/fate/mov-frag-encrypted
 >>  create mode 100644 tests/ref/fate/mov-tenc-only-encrypted
 >
 > This depends on other patches you posted, this should be mentioned or
 > all patches should be in the same patchset in order
 >

 This depends on
 http://ffmpeg.org/pipermail/ffmpeg-devel/2018-January/223754.html and
 the recently pushed change to libavutil/aes_ctr.  Should I add
 something to the commit message or is that enough?
>>>
>>> If you post a new version, then there should be a mail or comment explaining
>>> any dependancies on yet to be applied patches.
>>> It should not be in the commit messages or commited changes ideally
>>> This way people trying to test code dont need to guess what they need
>>> to apply first before a patchset
>>>
>>>
>>> [...]
 >> +static int get_current_encryption_info(MOVContext *c, 
 >> MOVEncryptionIndex **encryption_index, MOVStreamContext **sc)
 >>  {
 >> +MOVFragmentStreamInfo *frag_stream_info;
 >>  AVStream *st;
 >> -MOVStreamContext *sc;
 >> -size_t auxiliary_info_size;
 >> +int i;
 >>
 >> -if (c->decryption_key_len == 0 || c->fc->nb_streams < 1)
 >> -return 0;
 >> +frag_stream_info = get_current_frag_stream_info(&c->frag_index);
 >> +if (frag_stream_info) {
 >> +for (i = 0; i < c->fc->nb_streams; i++) {
 >> +if (c->fc->streams[i]->id == frag_stream_info->id) {
 >> +  st = c->fc->streams[i];
 >> +  break;
 >> +}
 >> +}
 >
 > the indention is inconsistent here
 >

 No it's not, it looks like it because the diff looks odd.  If you
 apply the patch, the indentation in this method is consistent.
>>>
>>> Indention depth is 4 in mov*.c
>>> the hunk seems to add lines with a depth of 2
>>> I would be surprised if this is not in the file after applying the patch
>>>
>>> personally i dont care about the depth that much but i know many other 
>>> people
>>> care so this needs to be fixed before this can be applied
>>
>> Didn't see that.  Fixed and did a grep for incorrect indentations.
>>
>>>
>>> [...]
>>>
>>> --
>>> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>>>
>>> Let us carefully observe those good qualities wherein our enemies excel us
>>> and endeavor to excel them, by avoiding what is faulty, and imitating what
>>> is excellent in them. -- Plutarch
>>>
>>> ___
>>> ffmpeg-devel mailing list
>>> ffmpeg-devel@ffmpeg.org
>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>>
>
> Ping.  This depends on
> http://ffmpeg.org/pipermail/ffmpeg-devel/2018-January/223754.html.

Ping again.  I know this is low priority, but I would like to get
these merged soon.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] compat: remove in-tree NVidia headers

[Lou Logan]

On Mon, Mar 5, 2018, at 11:07 AM, Timo Rothenpieler wrote:
>
> I tried to do that multiple times already, but trac won't let me login, 
> it just eventually runs into a Gateway Timeout if I try.

Weird. I can't duplicate that issue. Is anyone else experiencing this?

If you give me the info I can add it until we figure out the trac issue.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] ALS encoder

[Oleg Khokhlov]

Hi all.

I am student and my name is Oleg. I work on qualification task for GSoC 2018.
I should implement float-point support to als encoder.

A have some questions:
1)In documentation was written

"The floating-point sequence is modeled by the sum of an integer sequence
multiplied by a constant (ACF: Approximate Common Factor) and a
residual sequence."

and in another part was written:

"If the input signal is 32-bit floating-point, input values are
decomposed  into three
parts: An estimated common multiplier A, a truncated integer
multiplicand sequence Y,
and a difference signal Z.".

Can somebody explain what is ACF (I don`t find definition of this term
in google)
and how I can compute it?

2)What is the best method for testing encoder?


Link to documentation.
(https://drive.google.com/open?id=1iMqwUrhzdhWhm-IdNXx2P3djvS0wCtDt)

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

Re: [FFmpeg-devel] [PATCH] compat: remove in-tree NVidia headers

[Timo Rothenpieler]

Am 05.03.2018 um 20:46 schrieb Lou Logan:

On Tue, Feb 27, 2018, at 6:24 AM, Timo Rothenpieler wrote:


Patch applied.


Could you mention the new repo, and perhaps some simple instructions, on 
HWAccelIntro? I've seen a few confused users. I would but I'm not a HW user and 
I don't want to add anything incorrect.


I tried to do that multiple times already, but trac won't let me login, 
it just eventually runs into a Gateway Timeout if I try.




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

[FFmpeg-devel] patch for ticket #7053

[Pierre Chatelier]

Here is a patch proposition for https://trac.ffmpeg.org/ticket/7053

Pierre Chatelier
From 7cbc1bd47fb97e3498d92eda9c84144de2c06d01 Mon Sep 17 00:00:00 2001
From: Pierre Chatelier 
Date: Mon, 5 Mar 2018 13:57:00 +0100
Subject: [PATCH 1/1] added YUV422-12, -14, -16 bit depth, mono-8, -10, -12,
 -16 bit depth, rgb888 to bitpacked codec

---
 libavcodec/bitpacked.c   | 281 ++-
 libavformat/rtpdec_rfc4175.c |  51 +++-
 2 files changed, 330 insertions(+), 2 deletions(-)

diff --git a/libavcodec/bitpacked.c b/libavcodec/bitpacked.c
index f0b417d595..cf6275d963 100644
--- a/libavcodec/bitpacked.c
+++ b/libavcodec/bitpacked.c
@@ -55,6 +55,141 @@ static int bitpacked_decode_uyvy422(AVCodecContext *avctx, 
AVFrame *frame,
 return 0;
 }
 
+static int bitpacked_decode_gray8(AVCodecContext *avctx, AVFrame *frame,
+  AVPacket *avpkt)
+{
+int ret;
+
+/* there is no need to copy as the data already match
+ * a known pixel format */
+frame->buf[0] = av_buffer_ref(avpkt->buf);
+ret = av_image_fill_arrays(frame->data, frame->linesize, avpkt->data,
+   avctx->pix_fmt, avctx->width, avctx->height, 1);
+if (ret < 0) {
+av_buffer_unref(&frame->buf[0]);
+return ret;
+}
+
+return 0;
+}
+
+static int bitpacked_decode_gray10(AVCodecContext *avctx, AVFrame *frame,
+   AVPacket *avpkt)
+{
+uint64_t frame_size = (uint64_t)avctx->width * (uint64_t)avctx->height * 
10;
+uint64_t packet_size = (uint64_t)avpkt->size * 8;
+GetBitContext bc;
+uint16_t *g;
+int ret, i, j;
+
+ret = ff_get_buffer(avctx, frame, 0);
+if (ret < 0)
+return ret;
+
+if (frame_size > packet_size)
+return AVERROR_INVALIDDATA;
+
+ret = init_get_bits(&bc, avpkt->data, avctx->width * avctx->height * 10);
+if (ret)
+return ret;
+
+for (i = 0; i < avctx->height; i++) {
+g = (uint16_t*)(frame->data[0] + i * frame->linesize[0]);
+
+for (j = 0; j < avctx->width; j += 4)
+{
+  *g++ = get_bits(&bc, 10);
+  *g++ = get_bits(&bc, 10);
+  *g++ = get_bits(&bc, 10);
+  *g++ = get_bits(&bc, 10);
+}
+}
+
+
+return 0;
+}
+
+static int bitpacked_decode_gray12(AVCodecContext *avctx, AVFrame *frame,
+   AVPacket *avpkt)
+{
+uint64_t frame_size = (uint64_t)avctx->width * (uint64_t)avctx->height * 
12;
+uint64_t packet_size = (uint64_t)avpkt->size * 8;
+GetBitContext bc;
+uint16_t *g;
+int ret, i, j;
+
+ret = ff_get_buffer(avctx, frame, 0);
+if (ret < 0)
+return ret;
+
+if (frame_size > packet_size)
+return AVERROR_INVALIDDATA;
+
+ret = init_get_bits(&bc, avpkt->data, avctx->width * avctx->height * 12);
+if (ret)
+return ret;
+
+for (i = 0; i < avctx->height; i++) {
+g = (uint16_t*)(frame->data[0] + i * frame->linesize[0]);
+
+for (j = 0; j < avctx->width; j += 2)
+{
+  *g++ = get_bits(&bc, 12);
+  *g++ = get_bits(&bc, 12);
+}
+}
+
+return 0;
+}
+
+static int bitpacked_decode_gray16(AVCodecContext *avctx, AVFrame *frame,
+   AVPacket *avpkt)
+{
+uint64_t frame_size = (uint64_t)avctx->width * (uint64_t)avctx->height * 
16;
+uint64_t packet_size = (uint64_t)avpkt->size * 8;
+GetBitContext bc;
+uint16_t *g;
+int ret, i, j;
+
+ret = ff_get_buffer(avctx, frame, 0);
+if (ret < 0)
+return ret;
+
+if (frame_size > packet_size)
+return AVERROR_INVALIDDATA;
+
+ret = init_get_bits(&bc, avpkt->data, avctx->width * avctx->height * 16);
+if (ret)
+return ret;
+
+for (i = 0; i < avctx->height; i++) {
+g = (uint16_t*)(frame->data[0] + i * frame->linesize[0]);
+
+for (j = 0; j < avctx->width; j++)
+*g++ = get_bits(&bc, 16);
+}
+
+return 0;
+}
+
+static int bitpacked_decode_rgb24(AVCodecContext *avctx, AVFrame *frame,
+  AVPacket *avpkt)
+{
+int ret;
+
+/* there is no need to copy as the data already match
+ * a known pixel format */
+frame->buf[0] = av_buffer_ref(avpkt->buf);
+ret = av_image_fill_arrays(frame->data, frame->linesize, avpkt->data,
+   avctx->pix_fmt, avctx->width, avctx->height, 1);
+if (ret < 0) {
+av_buffer_unref(&frame->buf[0]);
+return ret;
+}
+
+return 0;
+}
+
 static int bitpacked_decode_yuv422p10(AVCodecContext *avctx, AVFrame *frame,
   AVPacket *avpkt)
 {
@@ -94,6 +229,123 @@ static int bitpacked_decode_yuv422p10(AVCodecContext 
*avctx, AVFrame *frame,
 return 0;
 }
 
+static int bitpacked_decode_yuv422p12(AVCodecContext *avctx, AVFrame *frame,
+  AVPacket *avpkt)
+{
+uint64_t fra

Re: [FFmpeg-devel] [PATCH] compat: remove in-tree NVidia headers

[Lou Logan]

On Tue, Feb 27, 2018, at 6:24 AM, Timo Rothenpieler wrote:
>
> Patch applied.

Could you mention the new repo, and perhaps some simple instructions, on 
HWAccelIntro? I've seen a few confused users. I would but I'm not a HW user and 
I don't want to add anything incorrect.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Michael Niedermayer]

On Mon, Mar 05, 2018 at 08:37:10AM +0800, Jun Zhao wrote:
> 
> 
> On 2018/3/4 6:16, Michael Niedermayer wrote:
> > On Sat, Mar 03, 2018 at 07:10:48PM -0300, James Almer wrote:
> >> On 3/3/2018 6:41 PM, Michael Niedermayer wrote:
> >>> On Fri, Mar 02, 2018 at 08:16:11AM +0800, Jun Zhao wrote:
>   bitstream_filters.texi |   11 ++-
>   1 file changed, 6 insertions(+), 5 deletions(-)
>  27c05404d9fabe5065e418c4cc09629d53aee1a1  
>  0001-doc-bitstream_filters-correct-dump_extra-bsfs-docs.patch
>  From 0a0a10824511ef9d5b3c49ee652a918603841826 Mon Sep 17 00:00:00 2001
>  From: Jun Zhao 
>  Date: Fri, 23 Feb 2018 13:53:05 +0800
>  Subject: [PATCH V2] doc/bitstream_filters: correct dump_extra bsfs docs.
> 
>  Update dump_extra bit stream filter docs to follow current
>  code implement.
> 
>  Signed-off-by: Jun Zhao 
>  Reviewed-by: Steven Liu 
>  ---
>   doc/bitstream_filters.texi | 11 ++-
>   1 file changed, 6 insertions(+), 5 deletions(-)
> >>> i  hoped a little that the a option could one day be
> >>> cleanly restored in the implementation.
> >>> but keeping the docs incorrect is not helping
> >> You mean adding it as it's defined in the removed portion of the doxy
> >> from this patch (local_header flag2)?
> >> Sounds like a better idea, as it would help replace the
> >> av_parser_change() call in ffmpeg.c with this bsf. I'll take a look.
> > yes
> Now, we can get specific help/option information for
> decoder/encoder/demuxer/muxer/filter
> like this:  ffmpeg -h encoder=libx264, how about implement specific bsf
> help like
> ffmpeg -h bsf=dump_filter? I think even if the guys forget update the
> man-page, we
> can get correct option information from cmd.
> 
> If is Ok, I will try to work for this. Thanks.

Improving help output should always be welcome

thx

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

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


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

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

[Vasile Toncu]

Hello,


The reinterlace behaves just like the tinterlace and in terms of fps is 
basically the same.


The ASM Opts are used with reinterlace only in case of CONFIG_GPL enabled.

There are two new modes, MODE_MERGE_BFF and MODE_MERGE_TFF for which I 
have documentation.


Also reinterlace processes the planes of a frame in separate threads.

I've tested it with diferent video formats, and the outputs are correct.

Previously there have been acceptance for using some methods form 
tinterlace. Those methods have nothing to do with old, GPL licensed 
code, and are doing some trivial stuff. One can check thread starting at 
[1].


[1] http://ffmpeg.org/pipermail/ffmpeg-devel/2018-February/224941.html

On 3/5/2018 2:53 PM, Paul B Mahol wrote:

On 3/5/18, Carl Eugen Hoyos  wrote:

2018-03-05 12:37 GMT+01:00, Paul B Mahol :

On 3/5/18, Vasile Toncu  wrote:

Hello,

Thanks for the review. I've made changes according to your guidance.

It would be great to know if the community will go on with our intention
of adding reinterlace as a alternative for tinterlace.

That being said, here is the new patch.

As already said, this is not acceptable.

There is no point in having 2 filters with near same funcionality.

If you consider the new filter ok, the existing filter will be removed
in the same push. I believe sending only the new filter makes
reviewing easier.

I'm ok with that, but next commits that do that and also do rename are
not available.

I'm also not sure can reinterlace filter be cosidered really safe from
standpoint that
it does not use any old GPL code.

Also bunch of stuff it does is trivial, both new and old GPL code so I
consider nobody
should care about its license.
___
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] parseutils: accept only full "ms" and "us" prefixes

[Aurelien Jacobs]

On Sat, Mar 03, 2018 at 08:19:43PM +, Rostislav Pehlivanov wrote:
> The commit which added those was pushed prematurely before anyone could object
> to illogical suffixes like just m for milliseconds.

What you call illogical is following the same convention as pretty much
all numeric parameters in ffmpeg. (bitrate, bufsize, framerate...)
So it is at least consistent.

> Without this, we'd be locked
> into never being able to implement the "m" suffix for minutes.

I will always be against using "m" for minute, but you can use "min" if
you want.

> Signed-off-by: Rostislav Pehlivanov 
> ---
>  libavutil/parseutils.c | 10 --
>  1 file changed, 4 insertions(+), 6 deletions(-)
> 
> diff --git a/libavutil/parseutils.c b/libavutil/parseutils.c
> index 44c845577a..1b81757aab 100644
> --- a/libavutil/parseutils.c
> +++ b/libavutil/parseutils.c
> @@ -689,17 +689,15 @@ int av_parse_time(int64_t *timeval, const char 
> *timestr, int duration)
>  
>  if (duration) {
>  t = dt.tm_hour * 3600 + dt.tm_min * 60 + dt.tm_sec;
> -if (*q == 'm') {
> +if (q[0] == 'm' && q[1] == 's') {
>  suffix = 1000;
>  microseconds /= 1000;
> -q++;
> -} else if (*q == 'u') {
> +q += 2;
> +} else if (q[0] == 'u' && q[1] == 's') {
>  suffix = 1;
>  microseconds = 0;
> -q++;
> +q += 2;
>  }
> -if (*q == 's')
> -q++;
>  } else {
>  int is_utc = *q == 'Z' || *q == 'z';
>  int tzoffset = 0;

Why do you remove support for using just 's' as a unit without prefix ?
I've seen no one complaining about it and I can't see any issue with it.

Also I don't like that this patch makes AV_OPT_TYPE_DURATION
inconsistant with every other numeric parameters, that all accept a SI
prefix without unit.
(that include opus_delay for which "3.5" and "3500m" are equivalent)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/opensrt: add Haivision Open SRT protocol

[Sven Dueking]

> -Ursprüngliche Nachricht-
> Von: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] Im Auftrag
> von Sven Dueking
> Gesendet: Dienstag, 27. Februar 2018 08:27
> An: 'FFmpeg development discussions and patches'
> Betreff: Re: [FFmpeg-devel] [PATCH] avformat/opensrt: add Haivision
> Open SRT protocol
> 
> 
> 
> > -Ursprüngliche Nachricht-
> > Von: Sven Dueking [mailto:s...@nablet.com]
> > Gesendet: Mittwoch, 21. Februar 2018 15:25
> > An: 'FFmpeg development discussions and patches'
> > Betreff: AW: [FFmpeg-devel] [PATCH] avformat/opensrt: add Haivision
> > Open SRT protocol
> >
> >
> >
> > > -Ursprüngliche Nachricht-
> > > Von: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] Im
> > > Auftrag von Michael Niedermayer
> > > Gesendet: Mittwoch, 21. Februar 2018 14:35
> > > An: FFmpeg development discussions and patches
> > > Betreff: Re: [FFmpeg-devel] [PATCH] avformat/opensrt: add Haivision
> > > Open SRT protocol
> > >
> > > On Wed, Feb 21, 2018 at 10:16:48AM +0100, Sven Dueking wrote:
> > > > protocol requires libsrt (https://github.com/Haivision/srt) to be
> > > > installed
> > > >
> > > > Signed-off-by: Sven Dueking 
> > > > ---
> > > >  MAINTAINERS |   1 +
> > > >  configure   |   5 +
> > > >  doc/protocols.texi  | 134 ++-
> > > >  libavformat/Makefile|   1 +
> > > >  libavformat/opensrt.c   | 589
> > > > 
> > > >  libavformat/protocols.c |   1 +
> > > >  6 files changed, 730 insertions(+), 1 deletion(-)  create mode
> > > > 100644 libavformat/opensrt.c
> > > >
> > > > diff --git a/MAINTAINERS b/MAINTAINERS index b691bd5..3e0355a
> > 100644
> > > > --- a/MAINTAINERS
> > > > +++ b/MAINTAINERS
> > > > @@ -499,6 +499,7 @@ Protocols:
> > > >http.cRonald S. Bultje
> > > >libssh.c  Lukasz Marek
> > > >mms*.cRonald S. Bultje
> > > > +  opensrt.c sven Dueking
> > > >udp.c Luca Abeni
> > > >icecast.c Marvin Scholz
> > > >
> > > > diff --git a/configure b/configure index 013308c..9a78bae 100755
> > > > --- a/configure
> > > > +++ b/configure
> > > > @@ -294,6 +294,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-opensrt enable Haivision Open SRT protocol
> [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] @@ -1648,6 +1649,7 @@ EXTERNAL_LIBRARY_LIST="
> > > >  mediacodec
> > > >  openal
> > > >  opengl
> > > > +opensrt
> > >
> > > there is something wrong with newlines this patch is corrupted and
> > > cannot be tested or applied
> > >
> > > [...]
> >
> > Hi Michael,
> >
> > Sorry, no idea why this happens. Patch attached.
> 
> Ping ?!
> 
> >
> > > --
> > > 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.
> 

Any chance to get feedback ? 
> ___
> 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] Revert "Remove battleforthenet widget"

[Nicolas George]

Kieran Kunhya (2018-03-05):
> Ladies and Gentleman I present you exhibit A, Michael

Wait, what? "exhibit"? When did this thread become a trial?

Regards,

-- 
  Nicolas George


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

[FFmpeg-devel] [PATCH] avcodec/openh264enc.c: generate IDR frame in response to I frame pict_type

[Valery Kot]

libx264 encoder uses AVFrame.pict_type (if provided by user) to use this
frame as key frame.

For openh264 encoder this functionality is missing, pict_type simply being
ignored.

Attached patch fixes it.

Valery
From f95943165c91dac13a644365f775aff3dd9edb11 Mon Sep 17 00:00:00 2001
From: vkot 
Date: Mon, 5 Mar 2018 13:51:51 +0100
Subject: [PATCH 3/3] avcodec/openh264enc.c: generate IDR frame in response to
 I frame pict_type

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

diff --git a/libavcodec/libopenh264enc.c b/libavcodec/libopenh264enc.c
index fdadb101f5..12e9ad49ed 100644
--- a/libavcodec/libopenh264enc.c
+++ b/libavcodec/libopenh264enc.c
@@ -245,6 +245,10 @@ static int svc_encode_frame(AVCodecContext *avctx, 
AVPacket *avpkt,
 }
 sp.iPicWidth  = avctx->width;
 sp.iPicHeight = avctx->height;
+
+if (frame->pict_type==AV_PICTURE_TYPE_I) {
+(*s->encoder)->ForceIntraFrame(s->encoder, true);
+}
 
 encoded = (*s->encoder)->EncodeFrame(s->encoder, &sp, &fbi);
 if (encoded != cmResultSuccess) {
-- 
2.15.1.windows.2

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

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

[Paul B Mahol]

On 3/5/18, Carl Eugen Hoyos  wrote:
> 2018-03-05 12:37 GMT+01:00, Paul B Mahol :
>> On 3/5/18, Vasile Toncu  wrote:
>>> Hello,
>>>
>>> Thanks for the review. I've made changes according to your guidance.
>>>
>>> It would be great to know if the community will go on with our intention
>>> of adding reinterlace as a alternative for tinterlace.
>>>
>>> That being said, here is the new patch.
>>
>> As already said, this is not acceptable.
>>
>> There is no point in having 2 filters with near same funcionality.
>
> If you consider the new filter ok, the existing filter will be removed
> in the same push. I believe sending only the new filter makes
> reviewing easier.

I'm ok with that, but next commits that do that and also do rename are
not available.

I'm also not sure can reinterlace filter be cosidered really safe from
standpoint that
it does not use any old GPL code.

Also bunch of stuff it does is trivial, both new and old GPL code so I
consider nobody
should care about its license.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Carl Eugen Hoyos]

2018-03-05 12:37 GMT+01:00, Paul B Mahol :
> On 3/5/18, Vasile Toncu  wrote:
>> Hello,
>>
>> Thanks for the review. I've made changes according to your guidance.
>>
>> It would be great to know if the community will go on with our intention
>> of adding reinterlace as a alternative for tinterlace.
>>
>> That being said, here is the new patch.
>
> As already said, this is not acceptable.
>
> There is no point in having 2 filters with near same funcionality.

If you consider the new filter ok, the existing filter will be removed
in the same push. I believe sending only the new filter makes
reviewing easier.

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

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

[Paul B Mahol]

On 3/5/18, Vasile Toncu  wrote:
> Hello,
>
> Thanks for the review. I've made changes according to your guidance.
>
> It would be great to know if the community will go on with our intention
> of adding reinterlace as a alternative for tinterlace.
>
> That being said, here is the new patch.

As already said, this is not acceptable.

There is no point in having 2 filters with near same funcionality.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Vasile Toncu]

Hello,

Thanks for the review. I've made changes according to your guidance.

It would be great to know if the community will go on with our intention 
of adding reinterlace as a alternative for tinterlace.


That being said, here is the new patch.

Regards,

-Vasile Toncu


From 7419be6fa213383ed0908976eedfb963837ed738 Mon Sep 17 00:00:00 2001
From: Vasile Toncu 
Date: Mon, 12 Feb 2018 14:16:27 +0200
Subject: [PATCH] Added reitnerlace filter.

---
 libavfilter/Makefile  |   1 +
 libavfilter/allfilters.c  |   1 +
 libavfilter/reinterlace.h | 141 +++
 libavfilter/vf_reinterlace.c  | 757 
++

 libavfilter/x86/Makefile  |   1 +
 libavfilter/x86/vf_reinterlace_init.c | 101 +
 6 files changed, 1002 insertions(+)
 create mode 100644 libavfilter/reinterlace.h
 create mode 100644 libavfilter/vf_reinterlace.c
 create mode 100644 libavfilter/x86/vf_reinterlace_init.c

diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 6a60836..c3095ba 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -286,6 +286,7 @@ OBJS-$(CONFIG_RANDOM_FILTER) += vf_random.o
 OBJS-$(CONFIG_READEIA608_FILTER) += vf_readeia608.o
 OBJS-$(CONFIG_READVITC_FILTER)   += vf_readvitc.o
 OBJS-$(CONFIG_REALTIME_FILTER)   += f_realtime.o
+OBJS-$(CONFIG_REINTERLACE_FILTER)    += vf_reinterlace.o
 OBJS-$(CONFIG_REMAP_FILTER)  += vf_remap.o framesync.o
 OBJS-$(CONFIG_REMOVEGRAIN_FILTER)    += vf_removegrain.o
 OBJS-$(CONFIG_REMOVELOGO_FILTER) += bbox.o lswsutils.o 
lavfutils.o vf_removelogo.o

diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 9adb109..60fb9b5 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -295,6 +295,7 @@ static void register_all(void)
 REGISTER_FILTER(READEIA608, readeia608, vf);
 REGISTER_FILTER(READVITC,   readvitc,   vf);
 REGISTER_FILTER(REALTIME,   realtime,   vf);
+    REGISTER_FILTER(REINTERLACE,    reinterlace,    vf);
 REGISTER_FILTER(REMAP,  remap,  vf);
 REGISTER_FILTER(REMOVEGRAIN,    removegrain,    vf);
 REGISTER_FILTER(REMOVELOGO, removelogo, vf);
diff --git a/libavfilter/reinterlace.h b/libavfilter/reinterlace.h
new file mode 100644
index 000..3413a7e
--- /dev/null
+++ b/libavfilter/reinterlace.h
@@ -0,0 +1,141 @@
+/*
+ * Copyright (c) 2017 Vasile Toncu 
+ * 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 Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 
02110-1301 USA

+ */
+
+#include 
+
+#include "avfilter.h"
+#include "formats.h"
+#include "internal.h"
+#include "video.h"
+#include "libavutil/avassert.h"
+#include "libavutil/imgutils.h"
+#include "libavutil/opt.h"
+#include "libavutil/pixdesc.h"
+
+#include "libavutil/bswap.h"
+
+enum FilterMode {
+    MODE_MERGE,
+    MODE_DROP_EVEN,
+    MODE_DROP_ODD,
+    MODE_PAD,
+    MODE_INTERLEAVE_TOP,
+    MODE_INTERLEAVE_BOTTOM,
+    MODE_INTERLACE_X2,
+    MODE_MERGE_X2,
+    MODE_MERGE_TFF,
+    MODE_MERGE_BFF,
+    MODE_NB
+};
+
+enum FilterFlags {
+    FLAG_NOTHING    = 0x00,
+    FLAG_VLPF   = 0x01,
+    FLAG_EXACT_TB   = 0x02,
+    FLAG_CVLPF  = 0x04,
+    FLAG_NB
+};
+
+static const AVRational standard_tbs[] = {
+    {1, 25},
+    {1, 30},
+    {1001, 3},
+};
+
+typedef struct {
+    const AVClass *class;
+    int mode;
+    int flags;
+
+    AVFrame *prev_frame, *current_frame;
+    int64_t current_frame_index;
+
+    void *black_vec[4];
+
+    int skip_next_frame;
+
+    void *thread_data;
+
+    uint8_t bit_depth;
+
+    void (*lowpass_line)(uint8_t *dstp, ptrdiff_t width, const uint8_t 
*srcp,

+ ptrdiff_t mref, ptrdiff_t pref, int clip_max);
+
+    AVRational preout_time_base;
+
+} ReInterlaceContext;
+
+#if CONFIG_GPL
+void ff_reinterlace_init_x86(ReInterlaceContext *reinterlace);
+#endif
+
+#define OFFSET(x) offsetof(ReInterlaceContext, x)
+#define FLAGS AV_OPT_FLAG_FILTERING_PARAM|AV_OPT_FLAG_VIDEO_PARAM
+
+static const AVOption reinterlace_options[] = {
+    { "mode", "set mode", OFFSET(mode), AV_OPT_TYPE_INT, 
{.i64=MODE_MERGE}, 0, MODE_NB - 1, FLAGS, "mode" },
+    { "merge", "merge frames",    

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

[rpatagar]

From: Ravindra 

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

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

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

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

[rpatagar]

From: Ravindra 

---
 doc/muxers.texi   | 2 ++
 libavformat/dashenc.c | 4 
 2 files changed, 6 insertions(+)

diff --git a/doc/muxers.texi b/doc/muxers.texi
index 3a63da7..cb75c26 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -264,6 +264,8 @@ of the adaptation sets and a,b,c,d and e are the indices of 
the mapped streams.
 To map all video (or audio) streams to an AdaptationSet, "v" (or "a") can be 
used as stream identifier instead of IDs.
 
 When no assignment is defined, this defaults to an AdaptationSet for each 
stream.
+@item -timeout @var{timeout}
+Set timeout for socket I/O operations. Applicable only for HTTP output.
 @end table
 
 @anchor{framecrc}
diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 79d63e5..9feb4f1 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -117,6 +117,7 @@ typedef struct DASHContext {
 AVIOContext *mpd_out;
 AVIOContext *m3u8_out;
 int streaming;
+int64_t timeout;
 } DASHContext;
 
 static struct codec_string {
@@ -269,6 +270,8 @@ static void set_http_options(AVDictionary **options, 
DASHContext *c)
 av_dict_set(options, "user_agent", c->user_agent, 0);
 if (c->http_persistent)
 av_dict_set_int(options, "multiple_requests", 1, 0);
+if (c->timeout >= 0)
+av_dict_set_int(options, "timeout", c->timeout, 0);
 }
 
 static void get_hls_playlist_name(char *playlist_name, int string_size,
@@ -1440,6 +1443,7 @@ static const AVOption options[] = {
 { "http_persistent", "Use persistent HTTP connections", 
OFFSET(http_persistent), AV_OPT_TYPE_BOOL, {.i64 = 0 }, 0, 1, E },
 { "hls_playlist", "Generate HLS playlist files(master.m3u8, 
media_%d.m3u8)", OFFSET(hls_playlist), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, E 
},
 { "streaming", "Enable/Disable streaming mode of output. Each frame will 
be moof fragment", OFFSET(streaming), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, E },
+{ "timeout", "set timeout for socket I/O operations", OFFSET(timeout), 
AV_OPT_TYPE_DURATION, { .i64 = -1 }, -1, INT_MAX, .flags = E },
 { NULL },
 };
 
-- 
1.9.1

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

[FFmpeg-devel] lavfi/silencedetect v3

[Gaullier Nicolas]

Hello,
I have not received any comment yet on my patchset v3 ("add mono mode" new 
feature + 4 fixes including a ticket), does it look good to you, could it be 
committed ?

http://ffmpeg.org/pipermail/ffmpeg-devel/2018-February/225494.html
http://ffmpeg.org/pipermail/ffmpeg-devel/2018-February/225495.html
http://ffmpeg.org/pipermail/ffmpeg-devel/2018-February/225496.html
http://ffmpeg.org/pipermail/ffmpeg-devel/2018-February/225497.html
http://ffmpeg.org/pipermail/ffmpeg-devel/2018-February/225498.html
http://ffmpeg.org/pipermail/ffmpeg-devel/2018-February/225499.html
http://ffmpeg.org/pipermail/ffmpeg-devel/2018-February/225500.html
http://ffmpeg.org/pipermail/ffmpeg-devel/2018-February/225501.html

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

Re: [FFmpeg-devel] [PATCH v2 2/2] fftools/ffmpeg: update print_report to use AVBPrint API

[Tobias Rapp]

On 26.02.2018 17:09, Tobias Rapp wrote:

Signed-off-by: Tobias Rapp 
---
  fftools/ffmpeg.c | 44 
  1 file changed, 20 insertions(+), 24 deletions(-)

[...]


Rebased on v1 of the patch and pushed. Thanks for review.

Regards,
Tobias

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

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

[Tobias Rapp]

On 02.03.2018 23:14, wm4 wrote:

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


On Fri, Mar 02, 2018 at 09:07:06AM +0100, Tobias Rapp wrote:

On 01.03.2018 22:08, Michael Niedermayer wrote:

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

On 27.02.2018 19:03, Michael Niedermayer wrote:

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

On 27.02.2018 01:12, Michael Niedermayer wrote:

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

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

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

[...]

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


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


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


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


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


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


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


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



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


iam not against this, but it seems others where


My comments were meant as minor suggestion for improvement (as I
stated, unfortunately only in my second reply), not a demand to rewrite
everything. If he just wants to push that first patch, fine with me.


I agree that factorization would make sense but it seems no agreement 
could be found on how exactly it should be implemented. So just pushed 
v1 of the patch which fixes the progress output strings followed by the 
AVBPrint clean-up patch.


Thanks,
Tobias

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