Re: [FFmpeg-devel] [PATCH] checkasm/hevc_mc : add hevc_mc for checkasm

[Shengbin Meng]

> On Apr 9, 2018, at 10:12, Yingming Fan  wrote:
> 
> From: Yingming Fan 
> 
> ---
> Hi, there.
> I plane to submit our arm32 neon codes for qpel and epel.
> While before this i will submit hevc_mc checkasm codes.
> This hevc_mc checkasm codes check every qpel and epel function, including 8 
> 10 and 12 bit.
> Passed test by using 'checkasm --test=hevc_mc' under Linux x86_64 MacOS 
> x86_64 and Linux arm64 platform.
> Also passed FATE test. 
> 
> tests/checkasm/Makefile   |   2 +-
> tests/checkasm/checkasm.c |   1 +
> tests/checkasm/checkasm.h |   1 +
> tests/checkasm/hevc_mc.c  | 547 ++
> tests/fate/checkasm.mak   |   1 +
> 5 files changed, 551 insertions(+), 1 deletion(-)
> create mode 100644 tests/checkasm/hevc_mc.c
> 
> diff --git a/tests/checkasm/Makefile b/tests/checkasm/Makefile
> index 0233d2f989..e6c94cd676 100644
> --- a/tests/checkasm/Makefile
> +++ b/tests/checkasm/Makefile
> @@ -23,7 +23,7 @@ AVCODECOBJS-$(CONFIG_EXR_DECODER)   += exrdsp.o
> AVCODECOBJS-$(CONFIG_HUFFYUV_DECODER)   += huffyuvdsp.o
> AVCODECOBJS-$(CONFIG_JPEG2000_DECODER)  += jpeg2000dsp.o
> AVCODECOBJS-$(CONFIG_PIXBLOCKDSP)   += pixblockdsp.o
> -AVCODECOBJS-$(CONFIG_HEVC_DECODER)  += hevc_add_res.o hevc_idct.o 
> hevc_sao.o
> +AVCODECOBJS-$(CONFIG_HEVC_DECODER)  += hevc_add_res.o hevc_idct.o 
> hevc_sao.o hevc_mc.o
> AVCODECOBJS-$(CONFIG_UTVIDEO_DECODER)   += utvideodsp.o
> AVCODECOBJS-$(CONFIG_V210_ENCODER)  += v210enc.o
> AVCODECOBJS-$(CONFIG_VP9_DECODER)   += vp9dsp.o
> diff --git a/tests/checkasm/checkasm.c b/tests/checkasm/checkasm.c
> index 20ce56932f..b95efc674d 100644
> --- a/tests/checkasm/checkasm.c
> +++ b/tests/checkasm/checkasm.c
> @@ -117,6 +117,7 @@ static const struct {
> { "hevc_add_res", checkasm_check_hevc_add_res },
> { "hevc_idct", checkasm_check_hevc_idct },
> { "hevc_sao", checkasm_check_hevc_sao },
> +{ "hevc_mc", checkasm_check_hevc_mc },
> #endif
> #if CONFIG_HUFFYUV_DECODER
> { "huffyuvdsp", checkasm_check_huffyuvdsp },
> diff --git a/tests/checkasm/checkasm.h b/tests/checkasm/checkasm.h
> index dcab74de06..5a4a612da7 100644
> --- a/tests/checkasm/checkasm.h
> +++ b/tests/checkasm/checkasm.h
> @@ -58,6 +58,7 @@ void checkasm_check_h264qpel(void);
> void checkasm_check_hevc_add_res(void);
> void checkasm_check_hevc_idct(void);
> void checkasm_check_hevc_sao(void);
> +void checkasm_check_hevc_mc(void);
> void checkasm_check_huffyuvdsp(void);
> void checkasm_check_jpeg2000dsp(void);
> void checkasm_check_llviddsp(void);
> diff --git a/tests/checkasm/hevc_mc.c b/tests/checkasm/hevc_mc.c
> new file mode 100644
> index 00..018f322c11
> --- /dev/null
> +++ b/tests/checkasm/hevc_mc.c
> @@ -0,0 +1,547 @@
> +/*
> + * Copyright (c) 2018 Yingming Fan 
> + *
> + * 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.
> + */
> +
> +#include 
> +
> +#include "libavutil/intreadwrite.h"
> +
> +#include "libavcodec/avcodec.h"
> +
> +#include "libavcodec/hevcdsp.h"
> +
> +#include "checkasm.h"
> +
> +static const uint32_t pixel_mask[3] = { 0x, 0x03ff03ff, 0x0fff0fff };
> +static const uint32_t idx_width_map[8][2] = {{1, 4}, {3, 8}, {4, 12}, {5, 
> 16}, {6, 24}, {7, 32}, {8, 48}, {9, 64}};
Why not include block width 2 and 6? I notice that there are already some 
optimization code for that.

> +#define SIZEOF_PIXEL ((bit_depth + 7) / 8)
> +#define PIXEL_STRIDE (AV_INPUT_BUFFER_PADDING_SIZE + MAX_PB_SIZE + 
> AV_INPUT_BUFFER_PADDING_SIZE)
> +#define BUF_SIZE ((MAX_PB_SIZE+4+4) * PIXEL_STRIDE * 2)
> +
> +#define randomize_buffers(buf0, buf1, size) \
> +do {\
> +uint32_t mask = pixel_mask[(bit_depth - 8) >> 1];   \
> +int k;  \
> +for (k = 0; k < size; k += 4) { \
> +uint32_t r = rnd() & mask;  \
> +AV_WN32A(buf0 + k, r);  \
> +AV_WN32A(buf1 + k, r);  \
> +}   \
> +} while (0)
> +
> +#define randomize_buffers2(buf0, buf1, size)\
> +do {  

Re: [FFmpeg-devel] [PATCH 1/5] avcodec/cinepak: move some checks prior to frame allocation

[Tomas Härdin]

tis 2018-04-17 klockan 02:13 +0200 skrev Michael Niedermayer:
> Speeds up decoding from 8 to 3 seconds for 
> 6302/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_CINEPAK_fuzzer-5626371985375232
> Fixes: Timeout
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/cinepak.c | 27 ++-
>  1 file changed, 22 insertions(+), 5 deletions(-)
> 
> diff --git a/libavcodec/cinepak.c b/libavcodec/cinepak.c
> index 89e940ae0d..ba0589582f 100644
> --- a/libavcodec/cinepak.c
> +++ b/libavcodec/cinepak.c
> @@ -315,14 +315,11 @@ static int cinepak_decode_strip (CinepakContext *s,
>  return AVERROR_INVALIDDATA;
>  }
>  
> -static int cinepak_decode (CinepakContext *s)
> +static int cinepak_predecode_check (CinepakContext *s)
>  {
> -const uint8_t  *eod = (s->data + s->size);
> -int   i, result, strip_size, frame_flags, num_strips;
> -int   y0 = 0;
> +int   num_strips;
>  int   encoded_buf_size;
>  
> -frame_flags = s->data[0];
>  num_strips  = AV_RB16 (&s->data[8]);
>  encoded_buf_size = AV_RB24(&s->data[1]);
>  
> @@ -353,6 +350,21 @@ static int cinepak_decode (CinepakContext *s)
>  s->sega_film_skip_bytes = 0;
>  }
>  
> +if (s->size < 10 + s->sega_film_skip_bytes + num_strips * 12)
> +return AVERROR_INVALIDDATA;

Looks like an extra check, not just moving existing checks as the
commit message implies

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

Re: [FFmpeg-devel] [PATCH 2/5] avcodec/cinepak: Skip empty frames

[Tomas Härdin]

tis 2018-04-17 klockan 02:13 +0200 skrev Michael Niedermayer:
> Speeds up decoding from 3 to 0.1 seconds for 
> 6302/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_CINEPAK_fuzzer-5626371985375232
> Fixes: Timeout
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/cinepak.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/libavcodec/cinepak.c b/libavcodec/cinepak.c
> index ba0589582f..17e3afc35c 100644
> --- a/libavcodec/cinepak.c
> +++ b/libavcodec/cinepak.c
> @@ -444,6 +444,7 @@ static int cinepak_decode_frame(AVCodecContext *avctx,
>  const uint8_t *buf = avpkt->data;
>  int ret = 0, buf_size = avpkt->size;
>  CinepakContext *s = avctx->priv_data;
> +int num_strips;
>  
>  s->data = buf;
>  s->size = buf_size;
> @@ -451,6 +452,12 @@ static int cinepak_decode_frame(AVCodecContext *avctx,
>  if (s->size < 10)
>  return AVERROR_INVALIDDATA;
>  
> +num_strips = AV_RB16 (&s->data[8]);
> +
> +//Empty frame, do not waste time
> +if (!num_strips)
> +return buf_size;

Won't this break in case of palette changes?

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

Re: [FFmpeg-devel] [PATCH 1/1] [RFC] ffprobe: report DAR even if SAR is undefined

[Michael Niedermayer]

On Tue, Apr 17, 2018 at 08:32:57AM +0300, Timo Teras wrote:
> On Tue, 17 Apr 2018 01:02:43 +0200
> Michael Niedermayer  wrote:
> 
> > On Mon, Apr 16, 2018 at 07:56:34PM +0200, Marton Balint wrote:
> > > 
> > > On Mon, 16 Apr 2018, Timo Teras wrote:
> > >   
> > > >On Sun, 15 Apr 2018 16:42:01 +0200 (CEST)
> > > >Marton Balint  wrote:
> > > >  
> > > >>On Sun, 15 Apr 2018, Timo Teräs wrote:
> > > >>  
> > > >>> Calculate DAR with assumed SAR 1:1 when SAR is undefined. Same
> > > >>> assumption is done in ffplay to create the play window. Usually
> > > >>> DAR is more useful metadata than SAR when e.g. choosing which
> > > >>> media of multiple versions to use to fit the display.  
> > > >>
> > > >>I don't think it's good idea to generally assume 1:1
> > > >>display_aspect_ratio for every undefined sample aspect ratio. It
> > > >>depends heavily on your actual use case. If MOV/MP4 specifies that
> > > >>1:1 SAR should be used, then maybe you should fix
> > > >>av_guess_sample_aspect_ratio instead, and return 1:1 there if the
> > > >>format context is MOV/MP4. You may add a demuxer (AVFMT) flag to
> > > >>signal that such behaviour should be used, and
> > > >>av_guess_sample_aspect_ratio can check for that demuxer flag.  
> > > >
> > > >Looking at code, av_guess_sample_aspect_ratio() is used only in
> > > >ffplay and ffprobe.
> > > >
> > > >ffplay implicitly assumes undefined SAR is 1:1 to create the
> > > >playback window properly; this happens in calculate_display_rect()
> > > >when "bad" aspect_ratio is reset to 1.0.
> > > >
> > > >I would expect same logic would have been useful in ffprobe. This
> > > >would help to report back to user what ffplay is going to do with
> > > >the video. Or at least give a hint on how to categorize the clip.
> > > >SAR 1:1 is pretty good guess for most formats.  
> > > 
> > > I really don't see why don't you fix your application instead which
> > > parses ffprobe output? If you see N/A aspect ratio, use 1:1.
> > > 
> > > To be frank, I am not sure if ffprobe should use
> > > av_guess_aspect_ratio when it displays stream metadata. It is only
> > > there now to av_reduce the aspect  
> > 
> > > ratios and to sanitize some invalid aspect ratios to 0/1. FFprobe's
> > > job is to return stream metadata as is, not to make guesses.  
> > 
> > a very minor somewhat on topic nitpick, 0/0 would be mathamtically
> > more correct as unknown than 0/1. If one doesnt immedeatly see why, 
> > one can look at width/height vs height/width to see one of many
> > reasons why
> 
> See my earlier patch that changes it to report as "N/A". This is what

i meant the function. Which cannot output N/A as it outputs a "rational
number" not a string.
and for such numbers 0/0 closer represents undefined than 0/1 in a
mathematical sense

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

"I am not trying to be anyone's saviour, I'm trying to think about the
 future and not be sad" - Elon Musk



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

Re: [FFmpeg-devel] [PATCH 1/1] [RFC] ffprobe: report DAR even if SAR is undefined

[Hendrik Leppkes]

On Tue, Apr 17, 2018 at 11:06 AM, Michael Niedermayer
 wrote:
> On Tue, Apr 17, 2018 at 08:32:57AM +0300, Timo Teras wrote:
>> On Tue, 17 Apr 2018 01:02:43 +0200
>> Michael Niedermayer  wrote:
>>
>> > On Mon, Apr 16, 2018 at 07:56:34PM +0200, Marton Balint wrote:
>> > >
>> > > On Mon, 16 Apr 2018, Timo Teras wrote:
>> > >
>> > > >On Sun, 15 Apr 2018 16:42:01 +0200 (CEST)
>> > > >Marton Balint  wrote:
>> > > >
>> > > >>On Sun, 15 Apr 2018, Timo Teräs wrote:
>> > > >>
>> > > >>> Calculate DAR with assumed SAR 1:1 when SAR is undefined. Same
>> > > >>> assumption is done in ffplay to create the play window. Usually
>> > > >>> DAR is more useful metadata than SAR when e.g. choosing which
>> > > >>> media of multiple versions to use to fit the display.
>> > > >>
>> > > >>I don't think it's good idea to generally assume 1:1
>> > > >>display_aspect_ratio for every undefined sample aspect ratio. It
>> > > >>depends heavily on your actual use case. If MOV/MP4 specifies that
>> > > >>1:1 SAR should be used, then maybe you should fix
>> > > >>av_guess_sample_aspect_ratio instead, and return 1:1 there if the
>> > > >>format context is MOV/MP4. You may add a demuxer (AVFMT) flag to
>> > > >>signal that such behaviour should be used, and
>> > > >>av_guess_sample_aspect_ratio can check for that demuxer flag.
>> > > >
>> > > >Looking at code, av_guess_sample_aspect_ratio() is used only in
>> > > >ffplay and ffprobe.
>> > > >
>> > > >ffplay implicitly assumes undefined SAR is 1:1 to create the
>> > > >playback window properly; this happens in calculate_display_rect()
>> > > >when "bad" aspect_ratio is reset to 1.0.
>> > > >
>> > > >I would expect same logic would have been useful in ffprobe. This
>> > > >would help to report back to user what ffplay is going to do with
>> > > >the video. Or at least give a hint on how to categorize the clip.
>> > > >SAR 1:1 is pretty good guess for most formats.
>> > >
>> > > I really don't see why don't you fix your application instead which
>> > > parses ffprobe output? If you see N/A aspect ratio, use 1:1.
>> > >
>> > > To be frank, I am not sure if ffprobe should use
>> > > av_guess_aspect_ratio when it displays stream metadata. It is only
>> > > there now to av_reduce the aspect
>> >
>> > > ratios and to sanitize some invalid aspect ratios to 0/1. FFprobe's
>> > > job is to return stream metadata as is, not to make guesses.
>> >
>> > a very minor somewhat on topic nitpick, 0/0 would be mathamtically
>> > more correct as unknown than 0/1. If one doesnt immedeatly see why,
>> > one can look at width/height vs height/width to see one of many
>> > reasons why
>>
>> See my earlier patch that changes it to report as "N/A". This is what
>
> i meant the function. Which cannot output N/A as it outputs a "rational
> number" not a string.
> and for such numbers 0/0 closer represents undefined than 0/1 in a
> mathematical sense
>

Internally we have been using 0/1 for undefined aspect ratios since
like forever, I'm not sure why that was chosen, but maybe to avoid an
accidental division by zero?

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

Re: [FFmpeg-devel] [PATCH 1/1] [RFC] ffprobe: report DAR even if SAR is undefined

[Nicolas George]

Hendrik Leppkes (2018-04-17):
> Internally we have been using 0/1 for undefined aspect ratios since
> like forever, I'm not sure why that was chosen, but maybe to avoid an
> accidental division by zero?

There is the need for two special values: unknown/undefined and
invalid/broken.

Possible magic values are 0/1, x/0.

I think 0/1 is fine for unknown/undefined and 0/0 for invalid/broken.
But I am too lazy to check what is implemented right now.

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] [PATCH 1/1] [RFC] ffprobe: report DAR even if SAR is undefined

[Timo Teras]

On Tue, 17 Apr 2018 11:06:58 +0200
Michael Niedermayer  wrote:

> On Tue, Apr 17, 2018 at 08:32:57AM +0300, Timo Teras wrote:
> > See my earlier patch that changes it to report as "N/A". This is
> > what  
> 
> i meant the function. Which cannot output N/A as it outputs a
> "rational number" not a string.
> and for such numbers 0/0 closer represents undefined than 0/1 in a
> mathematical sense

I suppose so. But seems the established de facto standard is to use 0/1
for undefined. Seems that denominator 0 means error or invalid. And
numerator 0 with any denominator means unknown.

This is documented for av_image_check_sar(),
av_guess_sample_aspect_ratio(), AVCodecParameters.sample_aspect_ratio
and various other places. And whole lot of stuff works based on this.

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

Re: [FFmpeg-devel] [PATCH 1/1] [RFC] ffprobe: report DAR even if SAR is undefined

[Michael Niedermayer]

On Tue, Apr 17, 2018 at 11:16:36AM +0200, Hendrik Leppkes wrote:
> On Tue, Apr 17, 2018 at 11:06 AM, Michael Niedermayer
>  wrote:
> > On Tue, Apr 17, 2018 at 08:32:57AM +0300, Timo Teras wrote:
> >> On Tue, 17 Apr 2018 01:02:43 +0200
> >> Michael Niedermayer  wrote:
> >>
> >> > On Mon, Apr 16, 2018 at 07:56:34PM +0200, Marton Balint wrote:
> >> > >
> >> > > On Mon, 16 Apr 2018, Timo Teras wrote:
> >> > >
> >> > > >On Sun, 15 Apr 2018 16:42:01 +0200 (CEST)
> >> > > >Marton Balint  wrote:
> >> > > >
> >> > > >>On Sun, 15 Apr 2018, Timo Teräs wrote:
> >> > > >>
> >> > > >>> Calculate DAR with assumed SAR 1:1 when SAR is undefined. Same
> >> > > >>> assumption is done in ffplay to create the play window. Usually
> >> > > >>> DAR is more useful metadata than SAR when e.g. choosing which
> >> > > >>> media of multiple versions to use to fit the display.
> >> > > >>
> >> > > >>I don't think it's good idea to generally assume 1:1
> >> > > >>display_aspect_ratio for every undefined sample aspect ratio. It
> >> > > >>depends heavily on your actual use case. If MOV/MP4 specifies that
> >> > > >>1:1 SAR should be used, then maybe you should fix
> >> > > >>av_guess_sample_aspect_ratio instead, and return 1:1 there if the
> >> > > >>format context is MOV/MP4. You may add a demuxer (AVFMT) flag to
> >> > > >>signal that such behaviour should be used, and
> >> > > >>av_guess_sample_aspect_ratio can check for that demuxer flag.
> >> > > >
> >> > > >Looking at code, av_guess_sample_aspect_ratio() is used only in
> >> > > >ffplay and ffprobe.
> >> > > >
> >> > > >ffplay implicitly assumes undefined SAR is 1:1 to create the
> >> > > >playback window properly; this happens in calculate_display_rect()
> >> > > >when "bad" aspect_ratio is reset to 1.0.
> >> > > >
> >> > > >I would expect same logic would have been useful in ffprobe. This
> >> > > >would help to report back to user what ffplay is going to do with
> >> > > >the video. Or at least give a hint on how to categorize the clip.
> >> > > >SAR 1:1 is pretty good guess for most formats.
> >> > >
> >> > > I really don't see why don't you fix your application instead which
> >> > > parses ffprobe output? If you see N/A aspect ratio, use 1:1.
> >> > >
> >> > > To be frank, I am not sure if ffprobe should use
> >> > > av_guess_aspect_ratio when it displays stream metadata. It is only
> >> > > there now to av_reduce the aspect
> >> >
> >> > > ratios and to sanitize some invalid aspect ratios to 0/1. FFprobe's
> >> > > job is to return stream metadata as is, not to make guesses.
> >> >
> >> > a very minor somewhat on topic nitpick, 0/0 would be mathamtically
> >> > more correct as unknown than 0/1. If one doesnt immedeatly see why,
> >> > one can look at width/height vs height/width to see one of many
> >> > reasons why
> >>
> >> See my earlier patch that changes it to report as "N/A". This is what
> >
> > i meant the function. Which cannot output N/A as it outputs a "rational
> > number" not a string.
> > and for such numbers 0/0 closer represents undefined than 0/1 in a
> > mathematical sense
> >
> 
> Internally we have been using 0/1 for undefined aspect ratios since
> like forever,

> I'm not sure why that was chosen, but maybe to avoid an
> accidental division by zero?

that doesnt work at all

aspects are likely as often multiplied as well as divided by.
so 0 doesnt really avoid the issue

And 0/0 requires very significantly fewer checks, this is why i
suggest it

Just try

1. convert aspect from width/height to height/width
0/0 -> 0/0 works, 0/1 -> 1/0 fails

2. take the average of 2 aspects (as a arbitrary operation, the behavior is 
similar in other operations)
(a/b + c/d)/2 ==  (ad + cb) / db2
if one if 0/0 result is 0/0, if one is 0/1 its nonsense

3. find the height from the aspect and width
height = width / aspect
with floats that will give you NaN correctly for a 0/0 aspect.
with 0/1 it will give infinite
now compare this to the opposite, finding width from height and aspect
width = height * aspect
0/0 will give Nan again
0/1 will give 0
its different for each case with 0/1 but behaving the same with 0/0
   
4. compare 2 aspects
this can be done by looking at the factor between them and how far it is
from 1.0 or by using the difference comapring to 0.0
with floats 0/0 will give NaN in all cases
with floats 0/1 will give 0, infinite and everything in between depending
on which is 0/1 and what variant is used to compare
with rationals 0/0 will give 0/0 still undefined as difference in all cases
with rationals 0/1 will give a similarly wide range of values as floats

Thats why i suggest 0/0 as undefined. it behaves much more consistent with
"undefined" in computations. If you put undefined aspect into a computation
you will almost always get the same "0/0" undefined out without any need for
checks. OTOH 0/1 often needs checks and carefully placed ones for the results 
not
to be just wrong

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

[Vasile Toncu]

On 12.04.2018 19:45, Thomas Mundt wrote:


You need to write separate AVOption interlace_options and AVFilter
avfilter_vf_interlace in vf_tinterlace.c
Have a look at this patch:
https://git.ffmpeg.org/gitweb/ffmpeg.git/commitdiff/88e0e2054d911b38662f681bdc267e08312d313a

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

Hello,

Here is the new patch in accordance with the one that you suggested as a 
model. Please review it and tell me when should I proceed with the next 
patch. The next patch will add vf_reinterlace.


Thank you,
Vasile


From b72b643201187bf5d31d7bec9b5064d1b01c8179 Mon Sep 17 00:00:00 2001
From: Vasile Toncu 
Date: Tue, 17 Apr 2018 13:48:28 +0300
Subject: [PATCH] Removed vf_interlace.c

---
 libavfilter/Makefile    |   2 +-
 libavfilter/vf_interlace.c  | 366 


 libavfilter/vf_tinterlace.c |  26 
 3 files changed, 27 insertions(+), 367 deletions(-)
 delete mode 100644 libavfilter/vf_interlace.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/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.h"
-#include "internal.h"
-#include "video.h"
-
-#define OFFSET(x) offsetof(InterlaceContext, x)
-#define FLAGS AV_OPT_FLAG_FILTERING_PARAM|AV_OPT_FLAG_VIDEO_PARAM
-static const AVOption interlace_options[] = {
-    { "scan", "scanning mode", OFFSET(scan),
-    AV_OPT_TYPE_INT,   {.i64 = MODE_TFF }, 0, 1, .flags = FLAGS, 
.unit = "scan" },

-    { "tff", "top field first", 0,
-    AV_OPT_TYPE_CONST, {.i64 = MODE_TFF }, INT_MIN, INT_MAX, .flags 
= FLAGS, .unit = "scan" },

-    { "bff", "bottom field first", 0,
-    AV_OPT_TYPE_CONST, {.i64 = MODE_BFF }, INT_MIN, INT_MAX, .flags 
= FLAGS, .unit = "scan" },

-    { "lowpass", "set vertical low-pass filter", OFFSET(lowpass),
-    AV_OPT_TYPE_INT,   {.i64 = VLPF_LIN }, 0, 2, .flags = FLAGS, 
.unit = "lowpass" },

-    { "off", "disable vertical low-pass filter", 0,
-    AV_OPT_TYPE_CONST, {.i64 = VLPF_OFF }, INT_MIN, INT_MAX, .flags 
= FLAGS, .unit = "lowpass" },

-    { "linear",  "linear vertical low-pass filter",  0,
-    AV_OPT_TYPE_CONST, {.i64 = VLPF_LIN }, INT_MIN, INT_MAX, .flags 
= FLAGS, .unit = "lowpass" },

-    { "complex", "complex vertical low-pass filter", 0,
-    AV_OPT_TYPE_CONST, {.i64 = VLPF_CMP }, INT_MIN, INT_MAX, .flags 
= FLAGS, .unit = "lowpass" },

-    { NULL }
-};
-
-AVFILTER_DEFINE_CLASS(interlace);
-
-static void lowpass_line_c(uint8_t *dstp, ptrdiff_t linesize,
-   const uint8_t *srcp, ptrdiff_t mref,
-   ptrdiff_t pref, int clip_max)
-{
-    const uint8_t *srcp_above = srcp + mref;
-    const uint8_t *srcp_below = srcp + pref;
-    int i;
-    for (i = 0; i < linesize; i++) {
-    // this calculation is an intege

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

[Paul B Mahol]

On 4/17/18, Vasile Toncu  wrote:
>
>
> On 12.04.2018 19:45, Thomas Mundt wrote:
>>
>> You need to write separate AVOption interlace_options and AVFilter
>> avfilter_vf_interlace in vf_tinterlace.c
>> Have a look at this patch:
>> https://git.ffmpeg.org/gitweb/ffmpeg.git/commitdiff/88e0e2054d911b38662f681bdc267e08312d313a
>>
>> Regards,
>> Thomas
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> Hello,
>
> Here is the new patch in accordance with the one that you suggested as a
> model. Please review it and tell me when should I proceed with the next
> patch. The next patch will add vf_reinterlace.
>
> Thank you,
> Vasile
>
>
>  From b72b643201187bf5d31d7bec9b5064d1b01c8179 Mon Sep 17 00:00:00 2001
> From: Vasile Toncu 
> Date: Tue, 17 Apr 2018 13:48:28 +0300
> Subject: [PATCH] Removed vf_interlace.c
>
> ---
>   libavfilter/Makefile|   2 +-
>   libavfilter/vf_interlace.c  | 366
> 
>   libavfilter/vf_tinterlace.c |  26 
>   3 files changed, 27 insertions(+), 367 deletions(-)
>   delete mode 100644 libavfilter/vf_interlace.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/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.h"
> -#include "internal.h"
> -#include "video.h"
> -
> -#define OFFSET(x) offsetof(InterlaceContext, x)
> -#define FLAGS AV_OPT_FLAG_FILTERING_PARAM|AV_OPT_FLAG_VIDEO_PARAM
> -static const AVOption interlace_options[] = {
> -{ "scan", "scanning mode", OFFSET(scan),
> -AV_OPT_TYPE_INT,   {.i64 = MODE_TFF }, 0, 1, .flags = FLAGS,
> .unit = "scan" },
> -{ "tff", "top field first", 0,
> -AV_OPT_TYPE_CONST, {.i64 = MODE_TFF }, INT_MIN, INT_MAX, .flags
> = FLAGS, .unit = "scan" },
> -{ "bff", "bottom field first", 0,
> -AV_OPT_TYPE_CONST, {.i64 = MODE_BFF }, INT_MIN, INT_MAX, .flags
> = FLAGS, .unit = "scan" },
> -{ "lowpass", "set vertical low-pass filter", OFFSET(lowpass),
> -AV_OPT_TYPE_INT,   {.i64 = VLPF_LIN }, 0, 2, .flags = FLAGS,
> .unit = "lowpass" },
> -{ "off", "disable vertical low-pass filter", 0,
> -AV_OPT_TYPE_CONST, {.i64 = VLPF_OFF }, INT_MIN, INT_MAX, .flags
> = FLAGS, .unit = "lowpass" },
> -{ "linear",  "linear vertical low-pass filter",  0,
> -AV_OPT_TYPE_CONST, {.i64 = VLPF_LIN }, INT_MIN, INT_MAX, .flags
> = FLAGS, .unit = "lowpass" },
> -{ "complex", "complex vertical low-pass filter", 0,
> -AV_OPT_TYPE_CONST, {.i64 = VLPF_CMP }, INT_MIN, INT_MAX, .flags
> = FLAGS, .unit = "lowpass" },
> -{ NULL }
> -};
> -
> -AVFILTER_DEFINE_CLASS(interlace);
> -
> -static void lowpass_line_c(uint8_t *dstp, ptrdiff_t linesize,
> -   

[FFmpeg-devel] [PATCH] avformat/mpegts: also ignore new stream in PMT while seeking

[Yuusei KUWANA]

avformat/mpegts: also ignore new stream in PMT while seeking

Signed-off-by: Yuusei KUWANA 
---
 libavformat/mpegts.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
index 37a6aa8..bd75494 100644
--- a/libavformat/mpegts.c
+++ b/libavformat/mpegts.c
@@ -2043,6 +2043,8 @@ static void pmt_cb(MpegTSFilter *filter, const uint8_t 
*section, int section_len
 pid &= 0x1fff;
 if (pid == ts->current_pid)
 goto out;
+if (ts->skip_changes)
+goto out;
 
 /* now create stream */
 if (ts->pids[pid] && ts->pids[pid]->type == MPEGTS_PES) {
@@ -2066,6 +2068,8 @@ static void pmt_cb(MpegTSFilter *filter, const uint8_t 
*section, int section_len
 }
 } else {
 int idx = ff_find_stream_index(ts->stream, pid);
+if (ts->skip_changes)
+goto out;
 if (idx >= 0) {
 st = ts->stream->streams[idx];
 } else {
-- 
2.7.4

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

Re: [FFmpeg-devel] [PATCH 1/5] avcodec/cinepak: move some checks prior to frame allocation

[Michael Niedermayer]

On Tue, Apr 17, 2018 at 10:32:16AM +0200, Tomas Härdin wrote:
> tis 2018-04-17 klockan 02:13 +0200 skrev Michael Niedermayer:
> > Speeds up decoding from 8 to 3 seconds for 
> > 6302/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_CINEPAK_fuzzer-5626371985375232
> > Fixes: Timeout
> > 
> > Found-by: continuous fuzzing process 
> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavcodec/cinepak.c | 27 ++-
> >  1 file changed, 22 insertions(+), 5 deletions(-)
> > 
> > diff --git a/libavcodec/cinepak.c b/libavcodec/cinepak.c
> > index 89e940ae0d..ba0589582f 100644
> > --- a/libavcodec/cinepak.c
> > +++ b/libavcodec/cinepak.c
> > @@ -315,14 +315,11 @@ static int cinepak_decode_strip (CinepakContext *s,
> >  return AVERROR_INVALIDDATA;
> >  }
> >  
> > -static int cinepak_decode (CinepakContext *s)
> > +static int cinepak_predecode_check (CinepakContext *s)
> >  {
> > -const uint8_t  *eod = (s->data + s->size);
> > -int   i, result, strip_size, frame_flags, num_strips;
> > -int   y0 = 0;
> > +int   num_strips;
> >  int   encoded_buf_size;
> >  
> > -frame_flags = s->data[0];
> >  num_strips  = AV_RB16 (&s->data[8]);
> >  encoded_buf_size = AV_RB24(&s->data[1]);
> >  
> > @@ -353,6 +350,21 @@ static int cinepak_decode (CinepakContext *s)
> >  s->sega_film_skip_bytes = 0;
> >  }
> >  
> > +if (s->size < 10 + s->sega_film_skip_bytes + num_strips * 12)
> > +return AVERROR_INVALIDDATA;
> 
> Looks like an extra check, not just moving existing checks as the
> commit message implies

its from this:
for (i=0; i < num_strips; i++) {
if ((s->data + 12) > eod)
return AVERROR_INVALIDDATA;
...

But i can split this in a separte patch if you prefer ?


[...]
-- 
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 2/5] avcodec/cinepak: Skip empty frames

[Michael Niedermayer]

On Tue, Apr 17, 2018 at 10:36:40AM +0200, Tomas Härdin wrote:
> tis 2018-04-17 klockan 02:13 +0200 skrev Michael Niedermayer:
> > Speeds up decoding from 3 to 0.1 seconds for 
> > 6302/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_CINEPAK_fuzzer-5626371985375232
> > Fixes: Timeout
> > 
> > Found-by: continuous fuzzing process 
> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavcodec/cinepak.c | 7 +++
> >  1 file changed, 7 insertions(+)
> > 
> > diff --git a/libavcodec/cinepak.c b/libavcodec/cinepak.c
> > index ba0589582f..17e3afc35c 100644
> > --- a/libavcodec/cinepak.c
> > +++ b/libavcodec/cinepak.c
> > @@ -444,6 +444,7 @@ static int cinepak_decode_frame(AVCodecContext *avctx,
> >  const uint8_t *buf = avpkt->data;
> >  int ret = 0, buf_size = avpkt->size;
> >  CinepakContext *s = avctx->priv_data;
> > +int num_strips;
> >  
> >  s->data = buf;
> >  s->size = buf_size;
> > @@ -451,6 +452,12 @@ static int cinepak_decode_frame(AVCodecContext *avctx,
> >  if (s->size < 10)
> >  return AVERROR_INVALIDDATA;
> >  
> > +num_strips = AV_RB16 (&s->data[8]);
> > +
> > +//Empty frame, do not waste time
> > +if (!num_strips)
> > +return buf_size;
> 
> Won't this break in case of palette changes?

well, iam not even sure this branch occurs in real
world undamaged files but i think you are correct, it could potentially loose
a palette, ill fix this

Thanks

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

When you are offended at any man's fault, turn to yourself and study your
own failings. Then you will forget your anger. -- Epictetus


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

Re: [FFmpeg-devel] [FFmpeg-cvslog] ffplay: only use hardware accelerated SDL texture formats

[Michael Niedermayer]

On Tue, Apr 17, 2018 at 01:27:48AM +0200, Marton Balint wrote:
> 
> 
> On Mon, 16 Apr 2018, Michael Niedermayer wrote:
> 
> >Hi
> >
> >On Sat, Nov 04, 2017 at 06:28:58PM +, Marton Balint wrote:
> >>ffmpeg | branch: master | Marton Balint  | Sat Oct 28 
> >>22:46:08 2017 +0200| [415038f2bd321a3b41564d4e0c6c17d7a096c397] | 
> >>committer: Marton Balint
> >>
> >>ffplay: only use hardware accelerated SDL texture formats
> >
> >This breaks ffplay playing some files like:
> >./ffplay fate-suite//cvid/catfight-cvid-pal8-partial.mov -noframedrop
> >
> >The output is completely black since this commit
> 
> Seems like a bug in swscale (pal8 -> bgra conversion), the alpha is 0
> instead of 255.

the file seems to store alpha = 0
SDL seems to treat alpha=0 different between PAL8 and RGBA, or maybe iam
missing something

try this:

diff --git a/libavformat/qtpalette.c b/libavformat/qtpalette.c
index 666c6b7351..51a134d30a 100644
--- a/libavformat/qtpalette.c
+++ b/libavformat/qtpalette.c
@@ -104,6 +104,7 @@ int ff_get_qtpalette(int codec_id, AVIOContext *pb, 
uint32_t *palette)
 avio_r8(pb);
 b = avio_r8(pb);
 avio_r8(pb);
+a = 0xFF;
 palette[i] = (a << 24 ) | (r << 16) | (g << 8) | (b);
 }
 }
 
swscale does not introduce the alpha=0 its there before

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

What does censorship reveal? It reveals fear. -- Julian Assange


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

Re: [FFmpeg-devel] Respect AR and NM overrides for Windows builds.

[Derek Buitenhuis]

On 4/17/2018 12:28 AM, Dale Curtis wrote:
> Necessary for clang-cl cross compiling builds to work on Linux.

Looks fairly reasonable, I think.

Are you manually overriding these?

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

Re: [FFmpeg-devel] [PATCH] swresample/arm: avoid conditional branch to PLT in THUMB-2.

[Michael Niedermayer]

On Mon, Apr 16, 2018 at 01:13:21PM -0700, Rahul Chaudhry wrote:
> Hi Michael,
> 
> While it is true that some linkers support the conditional branch to PLT in
> Thumb mode, it is of very limited use, since it uses an R_ARM_THM_JUMP19
> relocation and does not have a good range. If I switch my linker to ld.bfd for
> the original issue, it fails for another library with a "relocation truncated
> to fit" error message because the PLT entry is out of range of the conditional
> branch and cannot be handled by the R_ARM_THM_JUMP19 relocation.
> 
> It is cleaner and more stable (for all linkers) to convert the conditional
> branch to an unconditional one which uses an R_ARM_THM_JUMP24 relocation and
> has a range of 16MB.

why does it go through the PLT at all ?


[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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

[FFmpeg-devel] [PATCH] aac: Rework extradata parsing code

[Vittorio Giovara]

- enable the parsing code
- use the new buffer instead of replacing the context one
- do not push/pop configuration, just discard the exiting one
- propagate errors correctly
---

ping


 libavcodec/aacdec_template.c | 22 --
 1 file changed, 8 insertions(+), 14 deletions(-)

diff --git a/libavcodec/aacdec_template.c b/libavcodec/aacdec_template.c
index cf97181092..0c899285dd 100644
--- a/libavcodec/aacdec_template.c
+++ b/libavcodec/aacdec_template.c
@@ -3324,20 +3324,14 @@ static int aac_decode_frame(AVCodecContext
*avctx, void *data,
AV_PKT_DATA_JP_DUALMONO,
&jp_dualmono_size);

-if (new_extradata && 0) {
-av_free(avctx->extradata);
-avctx->extradata = av_mallocz(new_extradata_size +
-  AV_INPUT_BUFFER_PADDING_SIZE);
-if (!avctx->extradata)
-return AVERROR(ENOMEM);
-avctx->extradata_size = new_extradata_size;
-memcpy(avctx->extradata, new_extradata, new_extradata_size);
-push_output_configuration(ac);
-if (decode_audio_specific_config(ac, ac->avctx, &ac->oc[1].m4ac,
- avctx->extradata,
- avctx->extradata_size*8LL, 1) < 0) {
-pop_output_configuration(ac);
-return AVERROR_INVALIDDATA;
+if (new_extradata) {
+/* discard previous configuration */
+ac->oc[1].status = OC_NONE;
+err = decode_audio_specific_config(ac, ac->avctx, &ac->oc[1].m4ac,
+   new_extradata,
+   new_extradata_size * 8LL, 1);
+if (err < 0) {
+return err;
 }
 }

-- 
2.17.0


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

[Thomas Mundt]

Hi,

2018-04-17 13:33 GMT+02:00 Vasile Toncu :

>
>
> On 12.04.2018 19:45, Thomas Mundt wrote:
>
>>
>> You need to write separate AVOption interlace_options and AVFilter
>> avfilter_vf_interlace in vf_tinterlace.c
>> Have a look at this patch:
>> https://git.ffmpeg.org/gitweb/ffmpeg.git/commitdiff/88e0e205
>> 4d911b38662f681bdc267e08312d313a
>>
>> Regards,
>> Thomas
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
> Hello,
>
> Here is the new patch in accordance with the one that you suggested as a
> model. Please review it and tell me when should I proceed with the next
> patch. The next patch will add vf_reinterlace.
>
> Thank you,
> Vasile
>
>
> From b72b643201187bf5d31d7bec9b5064d1b01c8179 Mon Sep 17 00:00:00 2001
> From: Vasile Toncu 
> Date: Tue, 17 Apr 2018 13:48:28 +0300
> Subject: [PATCH] Removed vf_interlace.c
>
> ---
>  libavfilter/Makefile|   2 +-
>  libavfilter/vf_interlace.c  | 366 --
> --
>  libavfilter/vf_tinterlace.c |  26 
>  3 files changed, 27 insertions(+), 367 deletions(-)
>  delete mode 100644 libavfilter/vf_interlace.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/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.h"
> -#include "internal.h"
> -#include "video.h"
> -
> -#define OFFSET(x) offsetof(InterlaceContext, x)
> -#define FLAGS AV_OPT_FLAG_FILTERING_PARAM|AV_OPT_FLAG_VIDEO_PARAM
> -static const AVOption interlace_options[] = {
> -{ "scan", "scanning mode", OFFSET(scan),
> -AV_OPT_TYPE_INT,   {.i64 = MODE_TFF }, 0, 1, .flags = FLAGS,
> .unit = "scan" },
> -{ "tff", "top field first", 0,
> -AV_OPT_TYPE_CONST, {.i64 = MODE_TFF }, INT_MIN, INT_MAX, .flags =
> FLAGS, .unit = "scan" },
> -{ "bff", "bottom field first", 0,
> -AV_OPT_TYPE_CONST, {.i64 = MODE_BFF }, INT_MIN, INT_MAX, .flags =
> FLAGS, .unit = "scan" },
> -{ "lowpass", "set vertical low-pass filter", OFFSET(lowpass),
> -AV_OPT_TYPE_INT,   {.i64 = VLPF_LIN }, 0, 2, .flags = FLAGS,
> .unit = "lowpass" },
> -{ "off", "disable vertical low-pass filter", 0,
> -AV_OPT_TYPE_CONST, {.i64 = VLPF_OFF }, INT_MIN, INT_MAX, .flags =
> FLAGS, .unit = "lowpass" },
> -{ "linear",  "linear vertical low-pass filter",  0,
> -AV_OPT_TYPE_CONST, {.i64 = VLPF_LIN }, INT_MIN, INT_MAX, .flags =
> FLAGS, .unit = "lowpass" },
> -{ "complex", "complex vertical low-pass filter", 0,
> -AV_OPT_TYPE_CONST, {.i64 = VLPF_CMP }, INT_MIN, INT_MAX, .flags =
> FLAGS, .unit = "lowpass" },
> -{ NULL }
> -};
> -
> -AVFILTER_DEFINE_CLASS(interlace);
> -
> -static void lowpass_line_c(uint8_t *dstp, ptrdiff_t linesize,
> -  

Re: [FFmpeg-devel] [PATCH] libavformat/http: Fix memory leak in get_cookies.

[Richard Shaffer]

On Fri, Apr 13, 2018 at 4:42 PM,  wrote:

> From: Richard Shaffer 
>
> ---
>  libavformat/http.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/libavformat/http.c b/libavformat/http.c
> index 983034f083..b4a1919f24 100644
> --- a/libavformat/http.c
> +++ b/libavformat/http.c
> @@ -1103,6 +1103,7 @@ static int get_cookies(HTTPContext *s, char
> **cookies, const char *path,
>  snprintf(*cookies, str_size, "%s; %s=%s", tmp,
> cookie_entry->key, cookie_entry->value);
>  av_free(tmp);
>  }
> +av_dict_free(&cookie_params);
>  }
>
>  av_free(set_cookies);
> --
> 2.15.1 (Apple Git-101)
>
> Would one of the maintainers mind looking at and applying this? It's a
one-line change to fix a memory leak.

Thanks,

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

Re: [FFmpeg-devel] [PATCH] ffprobe: report unavailable SAR correctly in stream info

[Rostislav Pehlivanov]

On 14 April 2018 at 21:20, Rostislav Pehlivanov  wrote:

>
>
> On 12 April 2018 at 09:07, Timo Teräs  wrote:
>
>> av_guess_sample_aspect_ratio() will return undefined or missing
>> value as {0,1}. This fixes show_stream() to check numerator to
>> display 'N/A' when appropriate. show_frame() does this already
>> correctly.
>>
>> Signed-off-by: Timo Teräs 
>> ---
>>  fftools/ffprobe.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
>> index 82dfe4f58a..8b2a18b6b1 100644
>> --- a/fftools/ffprobe.c
>> +++ b/fftools/ffprobe.c
>> @@ -2521,7 +2521,7 @@ static int show_stream(WriterContext *w,
>> AVFormatContext *fmt_ctx, int stream_id
>>  #endif
>>  print_int("has_b_frames", par->video_delay);
>>  sar = av_guess_sample_aspect_ratio(fmt_ctx, stream, NULL);
>> -if (sar.den) {
>> +if (sar.num) {
>>  print_q("sample_aspect_ratio", sar, ':');
>>  av_reduce(&dar.num, &dar.den,
>>par->width  * sar.num,
>> --
>> 2.17.0
>>
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
>
> LGTM
>

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

Re: [FFmpeg-devel] [PATCH] swresample/arm: avoid conditional branch to PLT in THUMB-2.

[Rahul Chaudhry]

On Tue, Apr 17, 2018 at 6:17 AM, Michael Niedermayer
 wrote:
> why does it go through the PLT at all ?

You're right. The branches don't have to go through the PLT at all.

Here's an alternate patch that modifies the branches to skip the PLT
and jump directly to the targets.

Note that unlike the previous patch, this patch changes semantics.
When branches were going through PLT, the targets could be overridden
at runtime by another shared library or the main executable. With
this patch, they can no longer be overridden. The branches will always
go to the corresponding functions defined in this assembly file.

--- libswresample/arm/audio_convert_neon.S
+++ libswresample/arm/audio_convert_neon.S
@@ -22,6 +22,7 @@
 #include "libavutil/arm/asm.S"

 function swri_oldapi_conv_flt_to_s16_neon, export=1
+_swri_oldapi_conv_flt_to_s16_neon:
 subsr2,  r2,  #8
 vld1.32 {q0}, [r1,:128]!
 vcvt.s32.f32q8,  q0,  #31
@@ -66,6 +67,7 @@ function swri_oldapi_conv_flt_to_s16_neon, export=1
 endfunc

 function swri_oldapi_conv_fltp_to_s16_2ch_neon, export=1
+_swri_oldapi_conv_fltp_to_s16_2ch_neon:
 ldm r1,  {r1, r3}
 subsr2,  r2,  #8
 vld1.32 {q0}, [r1,:128]!
@@ -133,8 +135,8 @@ function swri_oldapi_conv_fltp_to_s16_nch_neon, export=1
 cmp r3,  #2
 itt lt
 ldrlt   r1,  [r1]
-blt X(swri_oldapi_conv_flt_to_s16_neon)
-beq X(swri_oldapi_conv_fltp_to_s16_2ch_neon)
+blt _swri_oldapi_conv_flt_to_s16_neon
+beq _swri_oldapi_conv_fltp_to_s16_2ch_neon

 push{r4-r8, lr}
 cmp r3,  #4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [FFmpeg-cvslog] ffplay: only use hardware accelerated SDL texture formats

[Marton Balint]

On Tue, 17 Apr 2018, Michael Niedermayer wrote:


On Tue, Apr 17, 2018 at 01:27:48AM +0200, Marton Balint wrote:



On Mon, 16 Apr 2018, Michael Niedermayer wrote:


Hi

On Sat, Nov 04, 2017 at 06:28:58PM +, Marton Balint wrote:

ffmpeg | branch: master | Marton Balint  | Sat Oct 28 22:46:08 
2017 +0200| [415038f2bd321a3b41564d4e0c6c17d7a096c397] | committer: Marton Balint

ffplay: only use hardware accelerated SDL texture formats


This breaks ffplay playing some files like:
./ffplay fate-suite//cvid/catfight-cvid-pal8-partial.mov -noframedrop

The output is completely black since this commit


Seems like a bug in swscale (pal8 -> bgra conversion), the alpha is 0
instead of 255.


the file seems to store alpha = 0
SDL seems to treat alpha=0 different between PAL8 and RGBA, or maybe iam
missing something


Old code negotiated RGB24 format for render which silently dropped the 
alpha channel. This seems to be because of a bug in pick_format:


libavfilter/avfiltergraph.c, pick_format():
int has_alpha= av_pix_fmt_desc_get(ref->format)->nb_components % 2 == 0;

libavutil/pixdesc.c:
#define pixdesc_has_alpha(pixdesc) \
((pixdesc)->nb_components == 2 || (pixdesc)->nb_components == 4 || 
(pixdesc)->flags & AV_PIX_FMT_FLAG_PAL)




try this:

diff --git a/libavformat/qtpalette.c b/libavformat/qtpalette.c
index 666c6b7351..51a134d30a 100644
--- a/libavformat/qtpalette.c
+++ b/libavformat/qtpalette.c
@@ -104,6 +104,7 @@ int ff_get_qtpalette(int codec_id, AVIOContext *pb, 
uint32_t *palette)
avio_r8(pb);
b = avio_r8(pb);
avio_r8(pb);
+a = 0xFF;
palette[i] = (a << 24 ) | (r << 16) | (g << 8) | (b);
}
}



Obviously this fixes it. Why do we think that the first value is 
alpha? Parsing it was added in 0d59ae32c23 but according to the QuickTime 
specs the first int16 should be simply 0, not alpha:


https://developer.apple.com/standards/qtff-2001.pdf
(page 36, top)

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

[FFmpeg-devel] [PATCH] mov: Properly abide by the track's media duration

[Derek Buitenhuis]

The track's media duration from the mdhd atom takes precedence
over both the stts and elst atom for calculating and setting
the track's total duraion.

Technically, we shouldn't be using the stts atom at all for
calculating stream durations.

This fixes incorrect stream and final packet durations on files
with edit lists that are longer than the media duration.

Signed-off-by: Derek Buitenhuis 
---
Personally I'd have removed the incorrect setting of the stream
duration in the stts reading code...
---
 libavformat/mov.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index 1340bf3..8a8cd6d 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -2931,7 +2931,7 @@ static int mov_read_stts(MOVContext *c, AVIOContext *pb, 
MOVAtom atom)
 
 st->nb_frames= total_sample_count;
 if (duration)
-st->duration= duration;
+st->duration= FFMIN(st->duration, duration);
 sc->track_end = duration;
 return 0;
 }
@@ -3670,8 +3670,8 @@ static void mov_fix_index(MOVContext *mov, AVStream *st)
 }
 }
 
-// Update av stream length
-st->duration = edit_list_dts_entry_end - start_dts;
+// Update av stream length, if it ends up shorter than the track's media 
duration
+st->duration = FFMIN(st->duration, edit_list_dts_entry_end - start_dts);
 msc->start_pad = st->skip_samples;
 
 // Free the old index and the old CTTS structures
-- 
1.8.3.1

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

Re: [FFmpeg-devel] [PATCH] libavformat/http: Fix memory leak in get_cookies.

[wm4]

On Tue, 17 Apr 2018 10:48:16 -0700
Richard Shaffer  wrote:

> On Fri, Apr 13, 2018 at 4:42 PM,  wrote:
> 
> > From: Richard Shaffer 
> >
> > ---
> >  libavformat/http.c | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/libavformat/http.c b/libavformat/http.c
> > index 983034f083..b4a1919f24 100644
> > --- a/libavformat/http.c
> > +++ b/libavformat/http.c
> > @@ -1103,6 +1103,7 @@ static int get_cookies(HTTPContext *s, char
> > **cookies, const char *path,
> >  snprintf(*cookies, str_size, "%s; %s=%s", tmp,
> > cookie_entry->key, cookie_entry->value);
> >  av_free(tmp);
> >  }
> > +av_dict_free(&cookie_params);
> >  }
> >
> >  av_free(set_cookies);
> > --
> > 2.15.1 (Apple Git-101)
> >
> > Would one of the maintainers mind looking at and applying this? It's a  
> one-line change to fix a memory leak.

Not a maintainer, but the "official" maintainer hasn't cared about this
code for a long time (despite being active FFmpeg contributor). Pushed.

I think there are some more leaks of this allocation, though.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] aac: Rework extradata parsing code

[wm4]

On Tue, 17 Apr 2018 11:47:00 -0400
Vittorio Giovara  wrote:

> - enable the parsing code
> - use the new buffer instead of replacing the context one
> - do not push/pop configuration, just discard the exiting one
> - propagate errors correctly
> ---
> 
> ping
> 
> 
>  libavcodec/aacdec_template.c | 22 --
>  1 file changed, 8 insertions(+), 14 deletions(-)
> 
> diff --git a/libavcodec/aacdec_template.c b/libavcodec/aacdec_template.c
> index cf97181092..0c899285dd 100644
> --- a/libavcodec/aacdec_template.c
> +++ b/libavcodec/aacdec_template.c
> @@ -3324,20 +3324,14 @@ static int aac_decode_frame(AVCodecContext
> *avctx, void *data,
> AV_PKT_DATA_JP_DUALMONO,
> &jp_dualmono_size);
> 
> -if (new_extradata && 0) {
> -av_free(avctx->extradata);
> -avctx->extradata = av_mallocz(new_extradata_size +
> -  AV_INPUT_BUFFER_PADDING_SIZE);
> -if (!avctx->extradata)
> -return AVERROR(ENOMEM);
> -avctx->extradata_size = new_extradata_size;
> -memcpy(avctx->extradata, new_extradata, new_extradata_size);
> -push_output_configuration(ac);
> -if (decode_audio_specific_config(ac, ac->avctx, &ac->oc[1].m4ac,
> - avctx->extradata,
> - avctx->extradata_size*8LL, 1) < 0) {
> -pop_output_configuration(ac);
> -return AVERROR_INVALIDDATA;
> +if (new_extradata) {
> +/* discard previous configuration */
> +ac->oc[1].status = OC_NONE;
> +err = decode_audio_specific_config(ac, ac->avctx, &ac->oc[1].m4ac,
> +   new_extradata,
> +   new_extradata_size * 8LL, 1);
> +if (err < 0) {
> +return err;
>  }
>  }
> 

Generally LGTM. Is there a proper test for this? (Apparently not...)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavformat/http: Fix memory leak in get_cookies.

[Richard Shaffer]

On Tue, Apr 17, 2018 at 1:04 PM, wm4  wrote:

> On Tue, 17 Apr 2018 10:48:16 -0700
> Richard Shaffer  wrote:
>
> > On Fri, Apr 13, 2018 at 4:42 PM,  wrote:
> >
> > > From: Richard Shaffer 
> > >
> > > ---
> > >  libavformat/http.c | 1 +
> > >  1 file changed, 1 insertion(+)
> > >
> > > diff --git a/libavformat/http.c b/libavformat/http.c
> > > index 983034f083..b4a1919f24 100644
> > > --- a/libavformat/http.c
> > > +++ b/libavformat/http.c
> > > @@ -1103,6 +1103,7 @@ static int get_cookies(HTTPContext *s, char
> > > **cookies, const char *path,
> > >  snprintf(*cookies, str_size, "%s; %s=%s", tmp,
> > > cookie_entry->key, cookie_entry->value);
> > >  av_free(tmp);
> > >  }
> > > +av_dict_free(&cookie_params);
> > >  }
> > >
> > >  av_free(set_cookies);
> > > --
> > > 2.15.1 (Apple Git-101)
> > >
> > > Would one of the maintainers mind looking at and applying this? It's
> a
> > one-line change to fix a memory leak.
>
> Not a maintainer, but the "official" maintainer hasn't cared about this
> code for a long time (despite being active FFmpeg contributor). Pushed.
>
> I think there are some more leaks of this allocation, though.
>

Yeah. Darn. I missed see the break statements inside the nested ifs. Those
are a rare case, since they're only executed if an allocation fails, but
they should still be handled. I'll send another patch for that. Maybe I can
refactor the while loop so that there aren't so many breaks or continues. I
did go over the rest of that loop, and I don't see any other cases where
the dictionary isn't freed.

Thanks for committing anyway. At least it fixes the most common code path.


> ___
> 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] avfilter: add deblock filter

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---
 doc/filters.texi |  23 +++
 libavfilter/Makefile |   1 +
 libavfilter/allfilters.c |   1 +
 libavfilter/vf_deblock.c | 366 +++
 4 files changed, 391 insertions(+)
 create mode 100644 libavfilter/vf_deblock.c

diff --git a/doc/filters.texi b/doc/filters.texi
index 77a1d49520..2ec6e85e81 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -7078,6 +7078,29 @@ e.g. banding detection threshold is triggered for all 
color components.
 The default is disabled.
 @end table
 
+@section deblock
+
+Remove blocking artifacts from input video.
+
+The filter accepts the following options:
+
+@table @option
+@item filter
+Set filter type, can be @var{weak} or @var{strong}. Default is @var{strong}.
+
+@item block
+Set size of block, allowed range is from 4 to 512.
+
+@item alpha
+@item beta
+@item gamma
+@item delta
+Set blocking detection thresholds.
+
+@item planes
+Set planes to filter. Default is to filter all available planes.
+@end table
+
 @anchor{decimate}
 @section decimate
 
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 7fc3de3bb2..0cd964ee6f 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -173,6 +173,7 @@ OBJS-$(CONFIG_CURVES_FILTER) += vf_curves.o
 OBJS-$(CONFIG_DATASCOPE_FILTER)  += vf_datascope.o
 OBJS-$(CONFIG_DCTDNOIZ_FILTER)   += vf_dctdnoiz.o
 OBJS-$(CONFIG_DEBAND_FILTER) += vf_deband.o
+OBJS-$(CONFIG_DEBLOCK_FILTER)+= vf_deblock.o
 OBJS-$(CONFIG_DECIMATE_FILTER)   += vf_decimate.o
 OBJS-$(CONFIG_DECONVOLVE_FILTER) += vf_convolve.o framesync.o
 OBJS-$(CONFIG_DEFLATE_FILTER)+= vf_neighbor.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index bd55463bfc..643eec287d 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -165,6 +165,7 @@ extern AVFilter ff_vf_curves;
 extern AVFilter ff_vf_datascope;
 extern AVFilter ff_vf_dctdnoiz;
 extern AVFilter ff_vf_deband;
+extern AVFilter ff_vf_deblock;
 extern AVFilter ff_vf_decimate;
 extern AVFilter ff_vf_deconvolve;
 extern AVFilter ff_vf_deflate;
diff --git a/libavfilter/vf_deblock.c b/libavfilter/vf_deblock.c
new file mode 100644
index 00..f40550437f
--- /dev/null
+++ b/libavfilter/vf_deblock.c
@@ -0,0 +1,366 @@
+/*
+ * Copyright (c) 2018 Paul B Mahol
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/imgutils.h"
+#include "libavutil/opt.h"
+#include "libavutil/pixdesc.h"
+
+#include "avfilter.h"
+#include "formats.h"
+#include "internal.h"
+#include "video.h"
+
+enum FilterType { WEAK, STRONG, NB_FILTER };
+
+typedef struct DeblockContext {
+const AVClass *class;
+const AVPixFmtDescriptor *desc;
+int filter;
+int block;
+int planes;
+float alpha;
+float beta;
+float gamma;
+float delta;
+
+int ath;
+int bth;
+int gth;
+int dth;
+int max;
+int depth;
+int nb_planes;
+int width[4];
+int height[4];
+
+void (*deblockh)(uint8_t *dst, ptrdiff_t linesize, int width, int height,
+ int block, int ath, int bth, int gth, int dth, int max);
+void (*deblockv)(uint8_t *dst, ptrdiff_t linesize, int width, int height,
+ int block, int ath, int bth, int gth, int dth, int max);
+} DeblockContext;
+
+static int query_formats(AVFilterContext *ctx)
+{
+static const enum AVPixelFormat pixel_fmts[] = {
+AV_PIX_FMT_YUVA444P, AV_PIX_FMT_YUV444P, AV_PIX_FMT_YUV440P,
+AV_PIX_FMT_YUVJ444P, AV_PIX_FMT_YUVJ440P,
+AV_PIX_FMT_YUVA422P, AV_PIX_FMT_YUV422P, AV_PIX_FMT_YUVA420P, 
AV_PIX_FMT_YUV420P,
+AV_PIX_FMT_YUVJ422P, AV_PIX_FMT_YUVJ420P,
+AV_PIX_FMT_YUVJ411P, AV_PIX_FMT_YUV411P, AV_PIX_FMT_YUV410P,
+AV_PIX_FMT_YUV420P9, AV_PIX_FMT_YUV422P9, AV_PIX_FMT_YUV444P9,
+AV_PIX_FMT_YUV420P10, AV_PIX_FMT_YUV422P10, AV_PIX_FMT_YUV444P10,
+AV_PIX_FMT_YUV420P12, AV_PIX_FMT_YUV422P12, AV_PIX_FMT_YUV444P12, 
AV_PIX_FMT_YUV440P12,
+AV_PIX_FMT_YUV420P14, AV_PIX_FMT_YUV422P14, AV_PIX_FMT_YUV444P14,
+AV_PIX_FMT_YUV420P16, AV_PIX_FMT_YUV422P16, AV_PIX_FMT_YUV444P16,
+AV_PIX_FMT_YUVA420P9

Re: [FFmpeg-devel] [PATCH] lavf/http.c: Don't write chunked-transfer-trailer to listening server context.

[Stephan Holljes]

On Thu, Apr 12, 2018 at 2:07 AM, Stephan Holljes
 wrote:
> ---
> I found this bug while working on my qualification task. When closing
> a listening HTTP AVIOContext http_shutdown() tries to write the
> chunked-transfer-encoding trailer to the listening Context.
>
>  libavformat/http.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/http.c b/libavformat/http.c
> index 983034f083..248fa085bf 100644
> --- a/libavformat/http.c
> +++ b/libavformat/http.c
> @@ -1623,7 +1623,7 @@ static int http_shutdown(URLContext *h, int flags)
>  HTTPContext *s = h->priv_data;
>
>  /* signal end of chunked encoding if used */
> -if (((flags & AVIO_FLAG_WRITE) && s->chunked_post) ||
> +if (((flags & AVIO_FLAG_WRITE) && s->chunked_post && !s->listen) ||
>  ((flags & AVIO_FLAG_READ) && s->chunked_post && s->listen)) {
>  ret = ffurl_write(s->hd, footer, sizeof(footer) - 1);
>  ret = ret > 0 ? 0 : ret;
> --
> 2.16.2
>

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

Re: [FFmpeg-devel] [PATCH 2/2] lavf/tcp.c: Free allocated client URLContext in case of error.

[Stephan Holljes]

On Fri, Mar 30, 2018 at 3:13 PM, Stephan Holljes
 wrote:
> On Fri, Jan 12, 2018 at 8:47 PM, Michael Niedermayer
>  wrote:
>> On Fri, Jan 12, 2018 at 07:16:30PM +0100, Stephan Holljes wrote:
>>> Signed-off-by: Stephan Holljes 
>>> ---
>>>  libavformat/tcp.c | 4 +++-
>>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> patchset is probably ok
>>
>> [...]
>>
>> --
>> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>>
>> It is what and why we do it that matters, not just one of them.
>>
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
>
> Ping

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

Re: [FFmpeg-devel] Respect AR and NM overrides for Windows builds.

[Dale Curtis]

Yes, to cross-compile on Linux you need to use llvm-ar and llvm-nm. This is
pretty chromium specific, but you can get the gist of what's necessary from
this Chromium change:

https://chromium-review.googlesource.com/c/chromium/third_party/ffmpeg/+/1013323/4/chromium/scripts/build_ffmpeg.py

- dale

On Tue, Apr 17, 2018 at 6:00 AM Derek Buitenhuis 
wrote:

> On 4/17/2018 12:28 AM, Dale Curtis wrote:
> > Necessary for clang-cl cross compiling builds to work on Linux.
>
> Looks fairly reasonable, I think.
>
> Are you manually overriding these?
>
> - Derek
> ___
> 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] libavformat/http: Refactor and fix additional leaks in get_cookies.

[rshaffer]

From: Richard Shaffer 

This refactors get_cookies to simplify some code paths, specifically for
skipping logic in the while loop or exiting it. It also simplifies the logic
for appending additional values to *cookies by replacing strlen/malloc/snprintf
with one call av_asnprintf.

This refactor fixes a bug where the cookie_params AVDictionary would get leaked
if we failed to allocate a new buffer for writing to *cookies.
---
 libavformat/http.c | 64 +++---
 1 file changed, 27 insertions(+), 37 deletions(-)

diff --git a/libavformat/http.c b/libavformat/http.c
index b4a1919f24..183214c444 100644
--- a/libavformat/http.c
+++ b/libavformat/http.c
@@ -1015,7 +1015,8 @@ static int process_line(URLContext *h, char *line, int 
line_count,
 /**
  * Create a string containing cookie values for use as a HTTP cookie header
  * field value for a particular path and domain from the cookie values stored 
in
- * the HTTP protocol context. The cookie string is stored in *cookies.
+ * the HTTP protocol context. The cookie string is stored in *cookies, and may
+ * be NULL if there are no valid cookies.
  *
  * @return a negative value if an error condition occurred, 0 otherwise
  */
@@ -1025,15 +1026,19 @@ static int get_cookies(HTTPContext *s, char **cookies, 
const char *path,
 // cookie strings will look like Set-Cookie header field values.  Multiple
 // Set-Cookie fields will result in multiple values delimited by a newline
 int ret = 0;
-char *cookie, *set_cookies = av_strdup(s->cookies), *next = set_cookies;
-
-if (!set_cookies) return AVERROR(EINVAL);
+char *cookie, *set_cookies, *next;
 
 // destroy any cookies in the dictionary.
 av_dict_free(&s->cookie_dict);
 
+if (!s->cookies)
+return 0;
+
+if (!(next = set_cookies = av_strdup(s->cookies)))
+return AVERROR(ENOMEM);
+
 *cookies = NULL;
-while ((cookie = av_strtok(next, "\n", &next))) {
+while ((cookie = av_strtok(next, "\n", &next)) && !ret) {
 AVDictionary *cookie_params = NULL;
 AVDictionaryEntry *cookie_entry, *e;
 
@@ -1043,23 +1048,19 @@ static int get_cookies(HTTPContext *s, char **cookies, 
const char *path,
 
 // continue on to the next cookie if this one cannot be parsed
 if (parse_set_cookie(cookie, &cookie_params))
-continue;
+goto skip_cookie;
 
 // if the cookie has no value, skip it
 cookie_entry = av_dict_get(cookie_params, "", NULL, 
AV_DICT_IGNORE_SUFFIX);
-if (!cookie_entry || !cookie_entry->value) {
-av_dict_free(&cookie_params);
-continue;
-}
+if (!cookie_entry || !cookie_entry->value)
+goto skip_cookie;
 
 // if the cookie has expired, don't add it
 if ((e = av_dict_get(cookie_params, "expires", NULL, 0)) && e->value) {
 struct tm tm_buf = {0};
 if (!parse_set_cookie_expiry_time(e->value, &tm_buf)) {
-if (av_timegm(&tm_buf) < av_gettime() / 100) {
-av_dict_free(&cookie_params);
-continue;
-}
+if (av_timegm(&tm_buf) < av_gettime() / 100)
+goto skip_cookie;
 }
 }
 
@@ -1067,42 +1068,31 @@ static int get_cookies(HTTPContext *s, char **cookies, 
const char *path,
 if ((e = av_dict_get(cookie_params, "domain", NULL, 0)) && e->value) {
 // find the offset comparison is on the min domain (b.com, not 
a.b.com)
 int domain_offset = strlen(domain) - strlen(e->value);
-if (domain_offset < 0) {
-av_dict_free(&cookie_params);
-continue;
-}
+if (domain_offset < 0)
+goto skip_cookie;
 
 // match the cookie domain
-if (av_strcasecmp(&domain[domain_offset], e->value)) {
-av_dict_free(&cookie_params);
-continue;
-}
+if (av_strcasecmp(&domain[domain_offset], e->value))
+goto skip_cookie;
 }
 
 // ensure this cookie matches the path
 e = av_dict_get(cookie_params, "path", NULL, 0);
-if (!e || av_strncasecmp(path, e->value, strlen(e->value))) {
-av_dict_free(&cookie_params);
-continue;
-}
+if (!e || av_strncasecmp(path, e->value, strlen(e->value)))
+goto skip_cookie;
 
 // cookie parameters match, so copy the value
 if (!*cookies) {
-if (!(*cookies = av_asprintf("%s=%s", cookie_entry->key, 
cookie_entry->value))) {
-ret = AVERROR(ENOMEM);
-break;
-}
+*cookies = av_asprintf("%s=%s", cookie_entry->key, 
cookie_entry->value);
 } else {
 char *tmp = *cookies;
-size_t str_size = strlen(cookie_entry->key) + 
strlen(cookie_entry->value) + strlen(*co

Re: [FFmpeg-devel] [PATCH] avformat/hls: remove redundant code

[Richard Shaffer]

On Mon, Apr 16, 2018 at 10:24 PM, Steven Liu  wrote:

>
>
> > On 16 Apr 2018, at 08:37, Jun Zhao  wrote:
> >
> >
> >
> > On 2018/4/13 20:29, Steven Liu wrote:
> >> 2018-04-13 16:19 GMT+08:00 Jun Zhao :
> >>>
> >>> On 2018/4/12 16:48, Steven Liu wrote:
>  Signed-off-by: Steven Liu 
>  ---
>  libavformat/hls.c | 27 +--
>  1 file changed, 9 insertions(+), 18 deletions(-)
> 
>  diff --git a/libavformat/hls.c b/libavformat/hls.c
>  index ae0545a086..74f0c2ccc5 100644
>  --- a/libavformat/hls.c
>  +++ b/libavformat/hls.c
>  @@ -945,14 +945,8 @@ static struct segment *next_segment(struct
> playlist *pls)
>  return pls->segments[n];
>  }
> 
>  -enum ReadFromURLMode {
>  -READ_NORMAL,
>  -READ_COMPLETE,
>  -};
>  -
>  static int read_from_url(struct playlist *pls, struct segment *seg,
>  - uint8_t *buf, int buf_size,
>  - enum ReadFromURLMode mode)
>  + uint8_t *buf, int buf_size)
>  {
>  int ret;
> 
>  @@ -960,12 +954,9 @@ static int read_from_url(struct playlist *pls,
> struct segment *seg,
>  if (seg->size >= 0)
>  buf_size = FFMIN(buf_size, seg->size - pls->cur_seg_offset);
> 
>  -if (mode == READ_COMPLETE) {
>  -ret = avio_read(pls->input, buf, buf_size);
>  -if (ret != buf_size)
>  -av_log(NULL, AV_LOG_ERROR, "Could not read complete
> segment.\n");
>  -} else
>  -ret = avio_read(pls->input, buf, buf_size);
>  +ret = avio_read(pls->input, buf, buf_size);
>  +if (ret != buf_size)
>  +av_log(NULL, AV_LOG_ERROR, "Could not read complete
> segment.\n");
> 
>  if (ret > 0)
>  pls->cur_seg_offset += ret;
>  @@ -1085,7 +1076,7 @@ static void intercept_id3(struct playlist *pls,
> uint8_t *buf,
>  while (1) {
>  /* see if we can retrieve enough data for ID3 header */
>  if (*len < ID3v2_HEADER_SIZE && buf_size >=
> ID3v2_HEADER_SIZE) {
>  -bytes = read_from_url(pls, seg, buf + *len,
> ID3v2_HEADER_SIZE - *len, READ_COMPLETE);
>  +bytes = read_from_url(pls, seg, buf + *len,
> ID3v2_HEADER_SIZE - *len);
>  if (bytes > 0) {
> 
>  if (bytes == ID3v2_HEADER_SIZE - *len)
>  @@ -1137,7 +1128,7 @@ static void intercept_id3(struct playlist *pls,
> uint8_t *buf,
> 
>  if (remaining > 0) {
>  /* read the rest of the tag in */
>  -if (read_from_url(pls, seg, pls->id3_buf +
> id3_buf_pos, remaining, READ_COMPLETE) != remaining)
>  +if (read_from_url(pls, seg, pls->id3_buf +
> id3_buf_pos, remaining) != remaining)
>  break;
>  id3_buf_pos += remaining;
>  av_log(pls->ctx, AV_LOG_DEBUG, "Stripped additional
> %d HLS ID3 bytes\n", remaining);
>  @@ -1151,7 +1142,7 @@ static void intercept_id3(struct playlist *pls,
> uint8_t *buf,
> 
>  /* re-fill buffer for the caller unless EOF */
>  if (*len >= 0 && (fill_buf || *len == 0)) {
>  -bytes = read_from_url(pls, seg, buf + *len, buf_size - *len,
> READ_NORMAL);
>  +bytes = read_from_url(pls, seg, buf + *len, buf_size - *len);
> 
>  /* ignore error if we already had some data */
>  if (bytes >= 0)
>  @@ -1311,7 +1302,7 @@ static int update_init_section(struct playlist
> *pls, struct segment *seg)
>  av_fast_malloc(&pls->init_sec_buf, &pls->init_sec_buf_size,
> sec_size);
> 
>  ret = read_from_url(pls, seg->init_section, pls->init_sec_buf,
>  -pls->init_sec_buf_size, READ_COMPLETE);
>  +pls->init_sec_buf_size);
> >>> Didn't care ret < pls->init_sec_buf_size ?
> >> avio_read is full size read, so it will return error, or
> >> init_sec_buf_size, as your question, maybe it will happen then the
> >> read_from_url called avio_read_partiall.
> > Thanks the clarify, I think the patch is Ok now.
> pushed
>  ff_format_io_close(pls->parent, &pls->input);
> 
>  if (ret < 0)
>  @@ -1506,7 +1497,7 @@ reload:
>  }
> 
>  seg = current_segment(v);
>  -ret = read_from_url(v, seg, buf, buf_size, READ_NORMAL);
>  +ret = read_from_url(v, seg, buf, buf_size);
>  if (ret > 0) {
>  if (just_opened && v->is_id3_timestamped != 0) {
>  /* Intercept ID3 tags here, elementary audio streams are
> required
> >>> LGTM except one question.
> >>> ___
> >>> ffmpeg-devel mailing list
> >>> ffmpeg-devel@ffmpeg.org
> >>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >> ___
> >> ffmpeg

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

[Michael Niedermayer]

On Tue, Apr 03, 2018 at 04:08:51PM -0700, Jacob Trimble wrote:
> >>
> >> Ping again.  I know this is low priority, but I would like to get
> >> these merged soon.
> >
> > Ping.  Despite being almost 2 months old, these patches still apply
> > cleanly.  Please take a look.  These have been in review for almost 3
> > months.
> 
> Ping (going to keep pinging this until someone merges this or tells me
> why not).  Day after tomorrow this will be in review for 4 months!!!
> 
> Also noticed a bug when integrating this, so here is an updated patch.

>  libavformat/isom.h |   14 +
>  libavformat/mov.c  |  396 
> ++---
>  tests/fate/mov.mak |8 
>  tests/ref/fate/mov-frag-encrypted  |   57 
>  tests/ref/fate/mov-tenc-only-encrypted |   57 
>  5 files changed, 450 insertions(+), 82 deletions(-)
> 9f1b7e04bc8001ad9faa59485090189f529cbf24  
> 0001-avformat-mov-Increase-support-for-v7.patch
> From 282effab6026341c49a52950cf8ba11afc9dc6aa Mon Sep 17 00:00:00 2001
> From: Jacob Trimble 
> Date: Wed, 6 Dec 2017 16:17:54 -0800
> Subject: [PATCH] avformat/mov: Increase support for common encryption.

maybe iam missing something but applying this to master seems to cause
fate to fail


--- ./tests/ref/fate/mov-3elist-encrypted   2018-04-17 14:20:30.560366780 
+0200
+++ tests/data/fate/mov-3elist-encrypted2018-04-18 03:53:32.872157901 
+0200
@@ -1,57 +0,0 @@
-#format: frame checksums
-#version: 2
-#hash: MD5
-#tb 0: 1/24
-#media_type 0: video
-#codec_id 0: rawvideo
-#dimensions 0: 640x480
-#sar 0: 0/1
-#stream#, dts,pts, duration, size, hash
-0,  0,  0,1,   460800, 80fbbdec589e15e6c493b44d243f92a9
-0,  1,  1,1,   460800, f4b23293bb2ecf69cc3570853d8c56a1
-0,  2,  2,1,   460800, 0c03ce2c1c6ec405d7455465ecd559a3
-0,  3,  3,1,   460800, 7921791695537fba2c3c123da4834cb9
-0,  4,  4,1,   460800, 30c8e2903a561b84d4cbaf95c668d236
-0,  5,  5,1,   460800, 7ff42e998217c17592ddf6b584f26cef
-0,  6,  6,1,   460800, 5e402c48bf097db2d31b82bb4194a382
-0,  7,  7,1,   460800, 824c49e92c8ae6d99a0207b514dd756c
-0,  8,  8,1,   460800, 24f189216a1d9cf2313b2d6dbe3dbdd3
-0,  9,  9,1,   460800, 519179a8e74275d26b183374637e003f
-0, 10, 10,1,   460800, f18331ddcef0adf5b069bfa98baf8db4
-0, 11, 11,1,   460800, 081f61688690d47db5384e5d5a70
-0, 12, 12,1,   460800, 90dbf019b9035433371a8df41a9268b7
-0, 13, 13,1,   460800, bb5adfb9c66732898b34186eca1667ba
-0, 14, 14,1,   460800, cc08cfd64f37783ecddaf143f6ad78bc
-0, 15, 15,1,   460800, b8ae21d024fe4df903d56f4521993c72
-0, 16, 16,1,   460800, b45a99907f045dcadf0a2befc11555e3
-0, 17, 17,1,   460800, 603ba935845e65ab6cccbbec88bbf60d
-0, 18, 18,1,   460800, df80c8d3e6a77258a306903f17995a18
-0, 19, 19,1,   460800, 4b7e90c0a5fd0e0cd958d47f0afac636
-0, 20, 20,1,   460800, 9feb6e36182f1745be6387edea240eb6
-0, 21, 21,1,   460800, 86e6de4bd0a5ff7558f4cf6c1ec3930d
-0, 22, 22,1,   460800, 726b69df77edbe7b503d4698656d1320
-0, 23, 23,1,   460800, d282fb7a953ac205b0a43d00c2d60a33
-0, 24, 24,1,   460800, eece3daa70cc20208dd75d91ac84c8fd
-0, 25, 25,1,   460800, c86d23e73bcce351fc315fb1f13348da
-0, 26, 26,1,   460800, 93497b4f7c5ad9d61212239b7c9d2770
-0, 27, 27,1,   460800, eb217d2c12de67903835a8c58f620488
-0, 28, 28,1,   460800, d966480867bb54c8cd044f18388ed486
-0, 29, 29,1,   460800, 3ea6207942b3181fdd8e8aa6cae1062a
-0, 30, 30,1,   460800, 2620df54aca086ec0fb9527c6e6f5135
-0, 31, 31,1,   460800, 43bb7320f0bb583188dc965ddbfade90
-0, 32, 32,1,   460800, 0cddaa04645f804e02f65b0836412113
-0, 33, 33,1,   460800, 83b2dc95807289d7f4a4632bf18c2e97
-0, 34, 34,1,   460800, 98134d0e41e6dd12827049ccf33b4669
-0, 35, 35,1,   460800, 56f55631731fa39c7acbab0afeb2eb1b
-0, 36, 36,1,   460800, 379c1105be09d836a515dc909455ddf4
-0, 37, 37,1,   460800, 1df87c47e9d98731faf1c3885b77e5da
-0, 38, 38,1,   460800, 9a8734bcbfdb4d97e530683b8b556a26
-0, 39, 39,1,   460800, c7a7990d0cddc5adfbe27da7a42e025e
-0, 40, 40,1,   460800, 0c81e46011e03be410feaf056207fd55
-0,

Re: [FFmpeg-devel] [PATCH] avformat/hls: remove redundant code

[Steven Liu]

> On 18 Apr 2018, at 09:01, Richard Shaffer  wrote:
> 
> On Mon, Apr 16, 2018 at 10:24 PM, Steven Liu  wrote:
> 
>> 
>> 
>>> On 16 Apr 2018, at 08:37, Jun Zhao  wrote:
>>> 
>>> 
>>> 
>>> On 2018/4/13 20:29, Steven Liu wrote:
 2018-04-13 16:19 GMT+08:00 Jun Zhao :
> 
> On 2018/4/12 16:48, Steven Liu wrote:
>> Signed-off-by: Steven Liu 
>> ---
>> libavformat/hls.c | 27 +--
>> 1 file changed, 9 insertions(+), 18 deletions(-)
>> 
>> diff --git a/libavformat/hls.c b/libavformat/hls.c
>> index ae0545a086..74f0c2ccc5 100644
>> --- a/libavformat/hls.c
>> +++ b/libavformat/hls.c
>> @@ -945,14 +945,8 @@ static struct segment *next_segment(struct
>> playlist *pls)
>>return pls->segments[n];
>> }
>> 
>> -enum ReadFromURLMode {
>> -READ_NORMAL,
>> -READ_COMPLETE,
>> -};
>> -
>> static int read_from_url(struct playlist *pls, struct segment *seg,
>> - uint8_t *buf, int buf_size,
>> - enum ReadFromURLMode mode)
>> + uint8_t *buf, int buf_size)
>> {
>>int ret;
>> 
>> @@ -960,12 +954,9 @@ static int read_from_url(struct playlist *pls,
>> struct segment *seg,
>>if (seg->size >= 0)
>>buf_size = FFMIN(buf_size, seg->size - pls->cur_seg_offset);
>> 
>> -if (mode == READ_COMPLETE) {
>> -ret = avio_read(pls->input, buf, buf_size);
>> -if (ret != buf_size)
>> -av_log(NULL, AV_LOG_ERROR, "Could not read complete
>> segment.\n");
>> -} else
>> -ret = avio_read(pls->input, buf, buf_size);
>> +ret = avio_read(pls->input, buf, buf_size);
>> +if (ret != buf_size)
>> +av_log(NULL, AV_LOG_ERROR, "Could not read complete
>> segment.\n");
>> 
>>if (ret > 0)
>>pls->cur_seg_offset += ret;
>> @@ -1085,7 +1076,7 @@ static void intercept_id3(struct playlist *pls,
>> uint8_t *buf,
>>while (1) {
>>/* see if we can retrieve enough data for ID3 header */
>>if (*len < ID3v2_HEADER_SIZE && buf_size >=
>> ID3v2_HEADER_SIZE) {
>> -bytes = read_from_url(pls, seg, buf + *len,
>> ID3v2_HEADER_SIZE - *len, READ_COMPLETE);
>> +bytes = read_from_url(pls, seg, buf + *len,
>> ID3v2_HEADER_SIZE - *len);
>>if (bytes > 0) {
>> 
>>if (bytes == ID3v2_HEADER_SIZE - *len)
>> @@ -1137,7 +1128,7 @@ static void intercept_id3(struct playlist *pls,
>> uint8_t *buf,
>> 
>>if (remaining > 0) {
>>/* read the rest of the tag in */
>> -if (read_from_url(pls, seg, pls->id3_buf +
>> id3_buf_pos, remaining, READ_COMPLETE) != remaining)
>> +if (read_from_url(pls, seg, pls->id3_buf +
>> id3_buf_pos, remaining) != remaining)
>>break;
>>id3_buf_pos += remaining;
>>av_log(pls->ctx, AV_LOG_DEBUG, "Stripped additional
>> %d HLS ID3 bytes\n", remaining);
>> @@ -1151,7 +1142,7 @@ static void intercept_id3(struct playlist *pls,
>> uint8_t *buf,
>> 
>>/* re-fill buffer for the caller unless EOF */
>>if (*len >= 0 && (fill_buf || *len == 0)) {
>> -bytes = read_from_url(pls, seg, buf + *len, buf_size - *len,
>> READ_NORMAL);
>> +bytes = read_from_url(pls, seg, buf + *len, buf_size - *len);
>> 
>>/* ignore error if we already had some data */
>>if (bytes >= 0)
>> @@ -1311,7 +1302,7 @@ static int update_init_section(struct playlist
>> *pls, struct segment *seg)
>>av_fast_malloc(&pls->init_sec_buf, &pls->init_sec_buf_size,
>> sec_size);
>> 
>>ret = read_from_url(pls, seg->init_section, pls->init_sec_buf,
>> -pls->init_sec_buf_size, READ_COMPLETE);
>> +pls->init_sec_buf_size);
> Didn't care ret < pls->init_sec_buf_size ?
 avio_read is full size read, so it will return error, or
 init_sec_buf_size, as your question, maybe it will happen then the
 read_from_url called avio_read_partiall.
>>> Thanks the clarify, I think the patch is Ok now.
>> pushed
>>ff_format_io_close(pls->parent, &pls->input);
>> 
>>if (ret < 0)
>> @@ -1506,7 +1497,7 @@ reload:
>>}
>> 
>>seg = current_segment(v);
>> -ret = read_from_url(v, seg, buf, buf_size, READ_NORMAL);
>> +ret = read_from_url(v, seg, buf, buf_size);
>>if (ret > 0) {
>>if (just_opened && v->is_id3_timestamped != 0) {
>>/* Intercept ID3 tags here, elementary audio streams are
>> required
> LGTM except one question.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-

Re: [FFmpeg-devel] [PATCH] avfilter: add deblock filter

[Gyan Doshi]

On 4/18/2018 2:25 AM, Paul B Mahol wrote:


+@item block
+Set size of block, allowed range is from 4 to 512.


Is this along each dimension? What happens if value is greater than 
width or height? Please indicate default value.



+@item alpha
+@item beta
+@item gamma
+@item delta
+Set blocking detection thresholds.


What do these mean? What's the range? Please indicate default values.



Can you add an one or two examples, showing the various options in use?

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

Re: [FFmpeg-devel] avformat/mpegts: set AV_DISPOSITION_DESCRIPTIONS for OIPF cases

[Łukasz Krzciuk]

Any updates on this?

Regards,

*Łukasz Krzciuk*
Developer

Vewd
ul. Grabarska 2, Pegaz 2A, 50-079 Wrocław, Polska


On Mon, Apr 16, 2018 at 9:16 AM, Łukasz Krzciuk  wrote:

> I agree, AV_LOG_INFO has been changed to AV_LOG_DEBUG.
>
> Regards,
>
> *Łukasz Krzciuk*
> Developer
>
> Vewd
> ul. Grabarska 2, Pegaz 2A, 50-079 Wrocław, Polska
>
>
> On Fri, Apr 13, 2018 at 5:50 PM, Michael Niedermayer <
> mich...@niedermayer.cc> wrote:
>
>> On Fri, Apr 13, 2018 at 03:44:40PM +0200, Łukasz Krzciuk wrote:
>> > Hi,
>> >
>> > this change is needed according to OIPF spec: 8.4.2 AVComponent,
>> > audioDescription case:
>> >
>> >1. an audio component with an ISO_639_language_descriptor in the PMT
>> >with the audio_type field set to 0x03
>> >2. a supplementary_audio_descriptor with the editorial_classification
>> >field set to 0x01
>> >3. an ac-3_descriptor or an enhanced_ac-3_descriptor with a
>> >component_type field with the service_type flags set to Visually
>> Impaired
>> >
>> >
>> > Regards,
>> >
>> > *Łukasz Krzciuk*
>> > Developer
>> >
>> > Vewd
>> > ul. Grabarska 2, Pegaz 2A, 50-079 Wrocław, Polska
>>
>> >  mpegts.c |   30 ++
>> >  1 file changed, 30 insertions(+)
>> > 863b7bca7f23f9ea337fde33f5bb9265ef3b4270
>> 0001-avformat-mpegts-set-AV_DISPOSITION_DESCRIPTIONS-for-.patch
>> > From 12ef5cdd9c443b1601dc98d910feac87233b1040 Mon Sep 17 00:00:00 2001
>> > From: =?UTF-8?q?=C5=81ukasz=20Krzciuk?= 
>> > Date: Fri, 13 Apr 2018 14:57:57 +0200
>> > Subject: [PATCH] avformat/mpegts: set AV_DISPOSITION_DESCRIPTIONS for
>> OIPF
>> >  cases
>> >
>> > 1. an audio component with an ISO_639_language_descriptor in the PMT
>> with the
>> > audio_type field set to 0x03
>> > 2. a supplementary_audio_descriptor with the editorial_classification
>> field set
>> > to 0x01
>> > 3. an ac-3_descriptor or an enhanced_ac-3_descriptor with a
>> component_type field
>> > with the service_type flags set to Visually Impaired
>> > ---
>> >  libavformat/mpegts.c | 30 ++
>> >  1 file changed, 30 insertions(+)
>> >
>> > diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
>> > index 37a6aa8..df2b3aa 100644
>> > --- a/libavformat/mpegts.c
>> > +++ b/libavformat/mpegts.c
>> > @@ -1835,6 +1835,7 @@ int ff_parse_mpeg2_descriptor(AVFormatContext
>> *fc, AVStream *st, int stream_type
>> >  break;
>> >  case 0x03:
>> >  st->disposition |= AV_DISPOSITION_VISUAL_IMPAIRED;
>> > +st->disposition |= AV_DISPOSITION_DESCRIPTIONS;
>> >  break;
>> >  }
>> >  }
>> > @@ -1910,6 +1911,7 @@ int ff_parse_mpeg2_descriptor(AVFormatContext
>> *fc, AVStream *st, int stream_type
>> >  switch ((flags >> 2) & 0x1F) { /* editorial_classification
>> */
>> >  case 0x01:
>> >  st->disposition |= AV_DISPOSITION_VISUAL_IMPAIRED;
>> > +st->disposition |= AV_DISPOSITION_DESCRIPTIONS;
>> >  break;
>> >  case 0x02:
>> >  st->disposition |= AV_DISPOSITION_HEARING_IMPAIRED;
>> > @@ -1934,6 +1936,34 @@ int ff_parse_mpeg2_descriptor(AVFormatContext
>> *fc, AVStream *st, int stream_type
>> >  }
>> >  }
>> >  break;
>> > +case 0x6a: /* ac-3_descriptor */
>> > +{
>> > +int component_type_flag = get8(pp, desc_end) & (1 << 7);
>> > +if (component_type_flag) {
>> > +int component_type = get8(pp, desc_end);
>> > +int service_type_mask = 0x38;  // 0b00111000
>> > +int service_type = ((component_type &
>> service_type_mask) >> 3);
>> > +if (service_type == 0x02 /* 0b010 */) {
>> > +st->disposition |= AV_DISPOSITION_DESCRIPTIONS;
>> > +av_log(ts->stream, AV_LOG_INFO, "New track
>> disposition for id %u: %u\n", st->id, st->disposition);
>>
>> AV_LOG_INFO is likely too noisy for normal usecases
>>
>> thx
>>
>> [...]
>>
>> --
>> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>>
>> Rewriting code that is poorly written but fully understood is good.
>> Rewriting code that one doesnt understand is a sign that one is less smart
>> then the original author, trying to rewrite it will not make it better.
>>
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
>>
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel