Re: [FFmpeg-devel] [PATCH]lavc/mjpegdec: Read polarity field from AVI1 chunk

[Michael Niedermayer]

On Mon, May 09, 2016 at 02:44:23PM +0200, Carl Eugen Hoyos wrote:
> Hi!
> 
> Attached aptch fixes ticket #5523 for me, I only tested the files
> attached there.
> 
> Please comment, Carl Eugen

>  mjpegdec.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> e8ca5feb642e2a59d0d27bd31ff637253123fa34  
> 0001-lavc-mjpegdec-Read-polarity-field-from-AVI1-chunk.patch
> From 389009e064e9e2b4a1a35d1add0efe1b643c1a62 Mon Sep 17 00:00:00 2001
> From: Carl Eugen Hoyos 
> Date: Mon, 9 May 2016 14:40:22 +0200
> Subject: [PATCH] lavc/mjpegdec: Read polarity field from AVI1 chunk.
> 
> Fixes ticket #5523.
> ---
>  libavcodec/mjpegdec.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
> index 7d38fc2..74884f1 100644
> --- a/libavcodec/mjpegdec.c
> +++ b/libavcodec/mjpegdec.c
> @@ -1655,7 +1655,7 @@ static int mjpeg_decode_app(MJpegDecodeContext *s)
>  4bytes  field_size_less_padding
>  */
>  s->buggy_avid = 1;
> -i = get_bits(>gb, 8); len--;
> +s->interlace_polarity = get_bits(>gb, 8); len--;

this could set interlace_polarity  to values outside 0-1

[...]


-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Its not that you shouldnt use gotos but rather that you should write
readable code and code with gotos often but not always is less readable


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

Re: [FFmpeg-devel] [PATCH] avfilter: add loudnorm

[Kyle Swanson]

On Sat, May 14, 2016 at 5:49 PM, Paul B Mahol  wrote:
> On 5/14/16, Kyle Swanson  wrote:
>> Hi,
>>
>> If nobody else has any changes, can this please be pushed?
>
> What about removal of libebur128 dependency?
>

I figured loudnorm can be pushed now, and porting libebur128 to ffmpeg
and removing the dependency can be done next. Updates to the ebur128
and astats filter to use the new libebur128 ported code can be another
patch after that. That makes sense to me, but maybe there's a more
preferable way to do it.

>>
>> Thanks
>>
>> On Wed, May 11, 2016 at 1:35 PM, Kyle Swanson  wrote:
>>> Hi,
>>>
>>> Updated patch attached.
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2] hevc: Fix memory leak related to a53_caption data

[Michael Niedermayer]

On Tue, May 10, 2016 at 12:29:11PM -0500, Will Kelleher wrote:
> On 04/08, Will Kelleher wrote:
> > 
> > The leak is...continuous.  We only noticed it during long running decode
> > operations because the amount is small, but it definitely adds up.
> >
> Hi all,
> 
> I finally got some time to revisit this.
> 
> In the simple case where we are not decoding the HEVC bitstream, the
> parser never frees the caption data.  This patch adds a function
> similar to what the H.264 decoder is using to free SEI data. This
> gets called near the top of each parse_nal_units run to clear any
> SEI data from the previous picture.
> 
> This is almost a copy-paste from the H.264 solution.
> 
> I would love to get this in, because anyone using an HEVC input with
> bitstream caption data is going to see this leak.

applied

you are still missing the error path at EOF case though i think
or is there some reason this wont lead to a leak ?

but the code thats added looks correct

thanks

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

During times of universal deceit, telling the truth becomes a
revolutionary act. -- George Orwell


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

Re: [FFmpeg-devel] [PATCH] avfilter: add loudnorm

[Paul B Mahol]

On 5/14/16, Kyle Swanson  wrote:
> Hi,
>
> If nobody else has any changes, can this please be pushed?

What about removal of libebur128 dependency?

>
> Thanks
>
> On Wed, May 11, 2016 at 1:35 PM, Kyle Swanson  wrote:
>> Hi,
>>
>> Updated patch attached.
> ___
> 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] [PATCHv2] add signature filter for MPEG7 video signature

[Michael Niedermayer]

On Tue, May 03, 2016 at 07:01:51PM +0200, Gerion Entrup wrote:
> On Sonntag, 24. April 2016 01:44:51 CEST Michael Niedermayer wrote:
> > On Tue, Apr 19, 2016 at 04:37:16PM +0200, Gerion Entrup wrote:
> > > On Dienstag, 19. April 2016 13:25:53 CEST Moritz Barsnick wrote:
> > > +static int request_frame(AVFilterLink *outlink)
> > > +{
> > > +AVFilterContext *ctx = outlink->src;
> > > +SignatureContext *sc = ctx->priv;
> > > +int i, ret;
> > > +
> > > +for (i = 0; i < sc->nb_inputs; i++){
> > > +ret = ff_request_frame(ctx->inputs[i]);
> > > +// TODO handle this in a better way?
> > > +// Problem is the following:
> > > +// Assuming two inputs, inputA with 50 frames, inputB with 100 
> > > frames
> > > +// simply returning ret when < 0 would result in not filtering 
> > > inputB
> > > +// after 50 frames anymore, not wanted
> > > +// only returning ret at the end would result in only respecting 
> > > the error
> > > +// values of the last input, please comment
> > > +if (ret < 0 && ret != AVERROR_EOF)
> > > +return ret;
> > > +}
> > > +return ret;
> > > +}
> > 
> > i dont know what exactly you want to happen when the inputs mismatch
> > but handling it like other dualinput filters might be an option
> vf_decimate, vf_fieldmatch: a main input exists, that dominates
> vf_mergeplanes, vf_stack, f_streamselect: return value of 
> ff_framesync_request_frame is used
> af_amerge, af_join: as soon as one inputstream end, the filter quits, other 
> said, the first error is returned
> af_amix: AVERROR_EOF is catched and things happen, could be a possible 
> solution, but is audio related
> af_ladspa: beside other things, with multiinput the return value of 
> ff_request_frame is returned
> avf_concat, f_interleave: only values except AVERROR_EOF are handled, in some 
> way similar like my current solution but without the <0 check
> 
> I see not an analog usecase with any of these filters. If the inputs mismatch 
> absolutely nothing should happen.
> The filter (the algorithm) does not require inputs of same length.

ok, so what is the problem ?
the return code from your request_frame() is about your filter only
really. That is it is EOF when you are at EOF, that may be different
from when the inputs EOF
isnt it fine already as is ?

> 
> 
> > 
> > 
> > [...]
> > > +static av_cold void uninit(AVFilterContext *ctx)
> > > +{
> > > +SignatureContext *sic = ctx->priv;
> > > +StreamContext *sc, *sc2;
> > > +void* tmp;
> > > +FineSignature* finsig;
> > > +CourseSignature* cousig;
> > > +MatchingInfo match;
> > > +int i,j;
> > > +
> > > +//TODO export and especially lookup_signature can have a return 
> > > value to show some error etc.
> > > +//How could this be handled in this function?
> > 
> > why does it need to happen in uninit ?
> > EOF could be detected before uninit if it doesnt work here
> What would be another good place to call export and lookup? The process chart 
> would be something like:
> 
> [input1]-->[signature_computation with loop over all frames]-->[export]-.
>  
> -->[lookup]
> [input2]-->[signature_computation with loop over all frames]-->[export]-`
> 
> ATM signature_computation is done in filter_frame and export and lookup are 
> in uninit.

If your goal is to do/return something at EOF, then one way to do that
should be to wait until your inputs are EOF and then do/return that
before you return EOF

the calling application cannot know if a filter will still return
something after all its inputs are EOF it thus must attempt to
request until EOF is signaled by some means
you should be able to detect that i request_frame

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

Those who are too smart to engage in politics are punished by being
governed by those who are dumber. -- Plato 


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

Re: [FFmpeg-devel] [PATCH] Push hls_ts_options to every chunks (fix #5525)

[Michael Niedermayer]

On Mon, May 09, 2016 at 06:17:36PM +0200, Jack wrote:
> Signed-off-by: jack 
> ---
>  libavformat/hlsenc.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> index a9fa5d8..77712d0 100644
> --- a/libavformat/hlsenc.c
> +++ b/libavformat/hlsenc.c
> @@ -624,6 +624,11 @@ static int hls_start(AVFormatContext *s)
>  err = avformat_write_header(vtt_oc,NULL);
>  if (err < 0)
>  return err;
> +} else {
> +HLSContext *hls = s->priv_data;
> +av_dict_copy(, hls->format_options, 0);
> +avformat_write_header(hls->avf, );
> +av_dict_free();

why does resend_headers not resend the headers?

calling avformat_write_header() multiple times looks odd unless theres
something iam missing

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

If you think the mosad wants you dead since a long time then you are either
wrong or dead since a long time.


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

Re: [FFmpeg-devel] [PATCH] avfilter: add loudnorm

[Kyle Swanson]

Hi,

If nobody else has any changes, can this please be pushed?

Thanks

On Wed, May 11, 2016 at 1:35 PM, Kyle Swanson  wrote:
> Hi,
>
> Updated patch attached.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec: Add AVClass to AVCodecParameters

[Michael Niedermayer]

On Tue, May 10, 2016 at 10:40:50PM +0200, wm4 wrote:
> On Tue, 10 May 2016 22:21:12 +0200 (CEST)
> Marton Balint  wrote:
> 
> > On Tue, 10 May 2016, Michael Niedermayer wrote:
> > 
> > > On Tue, May 10, 2016 at 03:53:31PM +0200, wm4 wrote:  
> > >> On Tue, 10 May 2016 14:35:02 +0200
> > >> Michael Niedermayer  wrote:
> > >>  
> > >>> On Tue, May 10, 2016 at 02:02:52PM +0200, Hendrik Leppkes wrote:  
> >  On Tue, May 10, 2016 at 1:43 PM, Michael Niedermayer
> >   wrote:  
> > > On Tue, May 10, 2016 at 11:17:12AM +0100, Derek Buitenhuis wrote:  
> > >> On 5/10/2016 7:24 AM, Hendrik Leppkes wrote:  
> > >>> I don't like this, the struct is pretty cleanly defined and unlikely
> > >>> to be extended much over time.
> > >>> Most other structs have AVOptions so the CLI can interact with it, 
> > >>> but
> > >>> this struct is not meant to be modified by users, its just a direct
> > >>> line of communication between demuxer->decoder or encoder->muxer.  
> > >>
> > >> To me this mostly still feels like trying to make a demuxing library
> > >> something it isn't. It demuxes and muxes.
> > >>
> > >> You can argue that it should be easier than decoding a frame to get 
> > >> this
> > >> info (which I don't personally think is much trouble at all). 
> > >> However,
> > >> jamming it into libavformat for reasons like "we've always done 
> > >> this" and
> > >> "there's no better place" is not good design IMO.
> > >>
> > >> It sounds like what you really want is a higher level "easy" API. 
> > >> Don't
> > >> jam it in to existing decoupled APIs because it is convenient, IMO. 
> > >> That's
> > >> how horrible things like having ffmpeg.c functionality in 
> > >> libavformat came
> > >> to exist, and a decade of misery followed.  
> > >
> > > This patch adds an AVClass field to AVCodecParameters like we use in
> > > other public structures.
> > > i fail to see how this patch is related to your reply
> > >
> > > What the patch does, is it makes the API more consistent and easy to
> > > use. Users call the AVOption functions to set fields in the main
> > > public structures, if they do that for AVCodecParameters it would
> > > crash.
> > > Even an empty AVClass that doesnt list options would reduce that
> > > misery by at least not crashing but giving a clear error message.
> > >  
> > 
> >  We should not design our API around people not caring to read our API,
> >  because thats not a fight we can ever win.  
> > >>>
> > >>> APIs should be designed with the "Principle of least astonishment"
> > >>>
> > >>> its quite surprising that AVOption APIs work with most public API
> > >>> structures but crash with some
> > >>> (AVPacket is another and i am of the oppinon and stated that previously
> > >>>  IIRC that it too should have a AVClass as its first element, this is
> > >>>  just hard to add as it requires ABI bumping everything which is why
> > >>>  i didnt push much for that being done, it needs to be done at a
> > >>>  time we bump all stuff for more important reasons)
> > >>>
> > >>> also let me steal the text from wikipedia about the
> > >>> Principle_of_least_astonishment, as its IMO well written  
> > >>
> > >> Indeed, av_opt calls on structs which don't support it compile without
> > >> warning, but mysteriously crash at runtime. That's a violation of this
> > >> principle. And no, it doesn't mean that every struct should have an  
> > >  
> > >> AVClass, because that would be insane.  
> > >
> > > iam not seriously suggesting to add it to every public struct but
> > > playing devils advocate here why is that insane ?
> > > it would actually solve the problem and be consistent  
> > 
> > I also don't see why adding an AVClass for most public structs is so evil. 
> > Apart from the crash issue above, having an av_opt support for struct 
> > members is definitely good, only way to have that conveniently at the 
> > moment is to use AVClass.
> > 
> > Specifying the class separately from the object for each 
> > av_opt call would also be a bit ugly, so even I agree it is not 
> > perfect, I don't see a better way, and we already have AVClasses for some 
> > structs...
> > 
> > Does libav have any plans for AVClass?
> 
> Actually, this whole av_opt business if the evil part, not necessarily
> the AVClass thing. Why should av_opt essentially duplicate the API? The
> only real argument I can find is because ffmpeg.c needs it for command
> line parsing (!).
> 
> FFmpeg is a set of C libraries. It's not a scripting wrapper. It
> doesn't need to provide dynamic access to API that is already defined
> by public fields.
> 
> Especially not for something like AVCodecParameters, which is
> essentially a value type (plus an allocator function for ABI reasons).
> 
> AVOption usage might be 

Re: [FFmpeg-devel] [PATCH][libavfilter] codecview: improved options

[Michael Niedermayer]

On Fri, May 13, 2016 at 06:05:26PM +, Davinder Singh wrote:
> should fix fate :)
> 
> On Wed, May 11, 2016 at 6:32 PM Michael Niedermayer 
> wrote:
> 
> > On Wed, May 11, 2016 at 12:41:43PM +, Davinder Singh wrote:
> > > single patch
> > >
> > > On Sun, May 8, 2016 at 1:18 AM Davinder Singh 
> > wrote:
> > >
> > > > separated motion vector types (forward or backward) from frame picture
> > > > types as MVs are associated with picture types only in video coding.
> > > >
> > > > option `mv` can have two values:
> > > > forward predicted or backward predicted.
> > > >
> > > > option `frames` can have three values:
> > > > p-frames, i-frames and b-frames.
> > > >
> > > > ex:
> > > > only forward predicted mvs of all frames:
> > > > -vf codecview=mv=fp
> > > >
> > > > mvs (both forward or backward predicted) of P or B-frames:
> > > > -vf codecview=mv=fp+bp:frames=pf+bf
> > > >
> > > > Regards,
> > > > DSM_
> > > >
> >
> > >  doc/filters.texi   |   30 --
> > >  libavfilter/vf_codecview.c |   36 ++--
> > >  2 files changed, 50 insertions(+), 16 deletions(-)
> > > 6168c73a45d4b183a4478909e4f8f3b0e47d1738
> > 0001-vf_codecview-improved-filter-options.patch
> > > From 0c2c258bd14d5dd58351271cc8c8859cd5edbf26 Mon Sep 17 00:00:00 2001
> > > From: dsmudhar 
> > > Date: Wed, 11 May 2016 17:57:39 +0530
> > > Subject: [PATCH] vf_codecview: improved filter options
> >
> > this breaks make fate
> >
> > make fate-filter-codecview-mvs
> > TESTfilter-codecview-mvs
> > --- ./tests/ref/fate/filter-codecview-mvs   2016-05-11
> > 04:21:34.187662201 +0200
> > +++ tests/data/fate/filter-codecview-mvs2016-05-11
> > 14:58:43.732467592 +0200
> > @@ -1,65 +0,0 @@
> > -#tb 0: 32768/785647
> > -#media_type 0: video
> > -#codec_id 0: rawvideo
> > -#dimensions 0: 576x320
> > -#sar 0: 0/1
> > -0,  0,  0,1,   276480, 0x5f7a0d4f
> > -0,  1,  1,1,   276480, 0x5f7a0d4f
> > -0,  2,  2,1,   276480, 0x5f7a0d4f
> > -0,  3,  3,1,   276480, 0x5f7a0d4f
> > -0,  4,  4,1,   276480, 0x5f7a0d4f
> > -0,  5,  5,1,   276480, 0x5f7a0d4f
> > -0,  6,  6,1,   276480, 0x5f7a0d4f
> > -0,  7,  7,1,   276480, 0x5f7a0d4f
> > -0,  8,  8,1,   276480, 0x5f7a0d4f
> > -0,  9,  9,1,   276480, 0x5f7a0d4f
> > -0, 10, 10,1,   276480, 0x5f7a0d4f
> > -0, 11, 11,1,   276480, 0x5f7a0d4f
> > -0, 12, 12,1,   276480, 0x5f7a0d4f
> > -0, 13, 13,1,   276480, 0x5f7a0d4f
> > -0, 14, 14,1,   276480, 0x5f7a0d4f
> > -0, 15, 15,1,   276480, 0x5f7a0d4f
> > -0, 16, 16,1,   276480, 0xc3b80edf
> > -0, 17, 17,1,   276480, 0x5f7a0d4f
> > -0, 18, 18,1,   276480, 0x5f7a0d4f
> > -0, 19, 19,1,   276480, 0x5f7a0d4f
> > -0, 20, 20,1,   276480, 0xc3b80edf
> > -0, 21, 21,1,   276480, 0x5f7a0d4f
> > -0, 22, 22,1,   276480, 0x5f7a0d4f
> > -0, 23, 23,1,   276480, 0x5f7a0d4f
> > -0, 24, 24,1,   276480, 0xc3b80edf
> > -0, 25, 25,1,   276480, 0x5f7a0d4f
> > -0, 26, 26,1,   276480, 0x5f7a0d4f
> > -0, 27, 27,1,   276480, 0x5f7a0d4f
> > -0, 28, 28,1,   276480, 0xc3b80edf
> > -0, 29, 29,1,   276480, 0x5f7a0d4f
> > -0, 30, 30,1,   276480, 0x5f7a0d4f
> > -0, 31, 31,1,   276480, 0x5f7a0d4f
> > -0, 32, 32,1,   276480, 0xc3b80edf
> > -0, 33, 33,1,   276480, 0x75641594
> > -0, 34, 34,1,   276480, 0x32ee3526
> > -0, 35, 35,1,   276480, 0xcb53479a
> > -0, 36, 36,1,   276480, 0xe1be6e26
> > -0, 37, 37,1,   276480, 0x5ce39368
> > -0, 38, 38,1,   276480, 0x4ec1e418
> > -0, 39, 39,1,   276480, 0x23c418ae
> > -0, 40, 40,1,   276480, 0x036a5515
> > -0, 41, 41,1,   276480, 0x7946efbd
> > -0, 42, 42,1,   276480, 0xd9aa1382
> > -0, 43, 43,1,   276480, 0x3863f9c8
> > -0, 44, 44,1,   276480, 0x33e47330
> > -0, 45, 45,1,   276480, 0xff6e8038
> > -0, 46, 46,1,   276480, 0xed3ff087
> > -0, 47, 47,1,   276480, 0xe7834514
> > -0, 48, 48,  

Re: [FFmpeg-devel] [PATCH 04/10] avcodec/dca: don't set initial sample_fmt

[Michael Niedermayer]

On Sat, May 14, 2016 at 06:48:51PM +0300, foo86 wrote:
> On Fri, May 13, 2016 at 12:00:24PM +0200, Hendrik Leppkes wrote:
> > On Fri, May 13, 2016 at 11:48 AM, foo86  wrote:
> > > Valid sample_fmt will be set by dcadec_decode_frame() based on stream
> > > type.
> > > ---
> > >  libavcodec/dcadec.c | 3 ---
> > >  1 file changed, 3 deletions(-)
> > >
> > > diff --git a/libavcodec/dcadec.c b/libavcodec/dcadec.c
> > > index e3a4b0d..565242d 100644
> > > --- a/libavcodec/dcadec.c
> > > +++ b/libavcodec/dcadec.c
> > > @@ -374,9 +374,6 @@ static av_cold int dcadec_init(AVCodecContext *avctx)
> > >  break;
> > >  }
> > >
> > > -avctx->sample_fmt = AV_SAMPLE_FMT_S32P;
> > > -avctx->bits_per_raw_sample = 24;
> > > -
> > >  return 0;
> > >  }
> > >
> > 
> > Having an initial format for the most "common" types of streams is
> > generally sensible.
> 
> Do you suggest it should be changed to AV_SAMPLE_FMT_FLTP then? Core
> streams are probably the most "common".
> 

> I don't have a strong prefenence on this, but I thought that not having
> initial sample_fmt set will serve as useful indication to API user that
> sample_fmt can (and will) change after the frame is decoded.

i feel similarly ...

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

The misfortune of the wise is better than the prosperity of the fool.
-- Epicurus


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

Re: [FFmpeg-devel] [PATCH 03/10] avcodec/dca: print error message when no frame is found in packet

[Michael Niedermayer]

On Fri, May 13, 2016 at 12:48:25PM +0300, foo86 wrote:
> ---
>  libavcodec/dcadec.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)

applied

thx

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

Old school: Use the lowest level language in which you can solve the problem
conveniently.
New school: Use the highest level language in which the latest supercomputer
can solve the problem without the user falling asleep waiting.


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

Re: [FFmpeg-devel] [PATCH 03/11] avcodec/mips: loongson optimize h264dsp with mmi v2

[Michael Niedermayer]

On Fri, May 13, 2016 at 06:03:27PM +0800, 周晓勇 wrote:
> From 4adf70c0eb9a85fe6cbedb043ed8ce08024c48dc Mon Sep 17 00:00:00 2001
> From: ZhouXiaoyong 
> Date: Sat, 7 May 2016 14:16:28 +0800

> Subject: [PATCH 03/11] avcodec/mips: loongson optimize h264dsp with mmi v2

please provide more verbose commit messages
A commit message should state
what is changed
why it is changed
how it is changed
as well as what effects that has on user, compatibility, performance, ...

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

Those who are best at talking, realize last or never when they are wrong.


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

Re: [FFmpeg-devel] [PATCH] avformat: Add Pro-MPEG CoP #3-R2 FEC protocol

[Michael Niedermayer]

Hi

On Fri, May 13, 2016 at 04:30:34PM +0200, Vlad Tarca wrote:
> Pro-MPEG Code of Practice #3 release 2 forward error correction for 
> rtp_mpegts streams
> 
[...]
> +static const AVClass prompeg_class = {
> +.class_name = "prompeg",
> +.item_name  = av_default_item_name,
> +.option = options,
> +.version= LIBAVUTIL_VERSION_INT,
> +};
> +
> +static void xor64(const uint8_t *in1, const uint8_t *in2, uint8_t *out, int 
> size) {
> +const uint64_t *p1, *p2;
> +const uint8_t *q1, *q2;
> +uint64_t *px;
> +uint8_t *qx;
> +int i, n, s;
> +
> +n = size / sizeof (uint64_t);
> +s = n * sizeof (uint64_t);
> +
> +p1 = (uint64_t*) in1;
> +p2 = (uint64_t*) in2;
> +px = (uint64_t*) out;




> +
> +for (i = 0; i < n; i++) {
> +px[i] = p1[i] ^ p2[i];

this is a strict aliassing violation probably or at least it can
become one easily if any access to this array is different than
char* type
its ore robust to use union or AV_RN64A/AV_WN64A or similar


> +}
> +
> +if (s == size)
> +return;
> +
> +q1 = in1 + s;
> +q2 = in2 + s;
> +qx = out + s;
> +n = size - s;
> +
> +for (i = 0; i < n; i++) {
> +qx[i] = q1[i] ^ q2[i];
> +}
> +}
> +

> +static inline uint32_t rtp_get_ts(const uint8_t *buf) {
> +return (buf[4] << 24) | (buf[5] << 16) | (buf[6] << 8) | buf[7];

AV_RB32()


> +}
> +

> +static inline uint16_t rtp_get_sn(const uint8_t *buf) {
> +return (buf[2] << 8) | buf[3];

AV_RB16()

[...]

> +static int prompeg_init(URLContext *h, const uint8_t *buf, int size) {
> +PrompegContext *s = h->priv_data;
> +int i;
> +
> +s->packet_idx = 0;
> +s->packet_idx_max = s->l * s->d;
> +s->packet_size = size;
> +s->length_recovery = size - 12;
> +s->bitstring_size = (s->length_recovery + 8) * sizeof (uint8_t);
> +s->fec_buf_len = 1 + 2 * s->l; // row + column tmp + column out
> +s->rtp_buf_size = (12 + 16 + s->length_recovery) * sizeof (uint8_t);
> +s->fec_buf = NULL;
> +s->rtp_buf = NULL;

> +s->rtp_col_sn = av_get_random_seed() & 0x0fff;
> +s->rtp_row_sn = av_get_random_seed() & 0x0fff;

you need only one call, it contains enough bits
av_get_random_seed() is slow
also a bitexact mode as in AVFMT_FLAG_BITEXACT might be usefull


> +
> +s->fec_buf = av_malloc(s->fec_buf_len * sizeof (PrompegFec*));

av_malloc_array()


> +if (!s->fec_buf) {
> +goto fail;
> +}
> +for (i = 0; i < s->fec_buf_len; i++) {
> +s->fec_buf[i] = av_malloc(sizeof (PrompegFec));
> +if (!s->fec_buf[i]) {
> +goto fail;
> +}
> +s->fec_buf[i]->bitstring = av_malloc(s->bitstring_size);
> +if (!s->fec_buf[i]->bitstring) {

> +av_free(s->fec_buf[i]);
> +s->fec_buf[i] = NULL;

av_freep()


[...]

> +static int prompeg_write(URLContext *h, const uint8_t *buf, int size) {
> +PrompegContext *s = h->priv_data;
> +PrompegFec *fec_tmp;
> +uint8_t *bitstring = NULL;
> +int col_idx, col_out_idx, row_idx;
> +int ret;
> +
> +if (s->init && ((ret = prompeg_init(h, buf, size)) < 0))
> +goto fail;
> +
> +if ((ret = prompeg_create_bitstring(h, buf, size, )) < 0)
> +goto fail;
> +
> +col_idx = s->packet_idx % s->l;
> +row_idx = s->packet_idx / s->l % s->d;
> +
> +// FEC' (row) send block-aligned, xor
> +if (col_idx == 0) {
> +if (!s->first || s->packet_idx > 0) {
> +if ((ret = prompeg_write_fec(h, s->fec_row, PROMPEG_FEC_ROW)) < 
> 0)
> +goto fail;
> +}
> +memcpy(s->fec_row->bitstring, bitstring, s->bitstring_size);
> +s->fec_row->sn = rtp_get_sn(buf);
> +s->fec_row->ts = rtp_get_ts(buf);
> +} else {
> +xor64(s->fec_row->bitstring, bitstring, s->fec_row->bitstring,
> +s->bitstring_size);
> +}
> +
> +// FEC (column) xor
> +if (row_idx == 0) {
> +if (!s->first) {
> +// swap fec_col and fec_col_tmp
> +fec_tmp = s->fec_col[col_idx];
> +s->fec_col[col_idx] = s->fec_col_tmp[col_idx];
> +s->fec_col_tmp[col_idx] = fec_tmp;
> +}
> +memcpy(s->fec_col_tmp[col_idx]->bitstring, bitstring, 
> s->bitstring_size);
> +s->fec_col_tmp[col_idx]->sn = rtp_get_sn(buf);
> +s->fec_col_tmp[col_idx]->ts = rtp_get_ts(buf);
> +} else {
> +xor64(s->fec_col_tmp[col_idx]->bitstring, bitstring,
> +s->fec_col_tmp[col_idx]->bitstring, s->bitstring_size);
> +}
> +
> +// FEC (column) send block-aligned
> +if (!s->first && s->packet_idx % s->d == 0) {
> +col_out_idx = s->packet_idx / s->l;
> +if ((ret = prompeg_write_fec(h, s->fec_col[col_out_idx], 
> PROMPEG_FEC_COL)) < 0)
> +goto fail;
> +}
> +
> +if (++s->packet_idx >= s->packet_idx_max) {
> +s->packet_idx = 0;
> +if (s->first)
> +s->first = 

Re: [FFmpeg-devel] [PATCH][libavfilter] codecview: improved options

[Davinder Singh]

On Fri, May 13, 2016 at 11:35 PM Davinder Singh  wrote:

> should fix fate :)
>
*attached patch in that mail should fix fate.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 04/10] avcodec/dca: don't set initial sample_fmt

[foo86]

On Fri, May 13, 2016 at 12:00:24PM +0200, Hendrik Leppkes wrote:
> On Fri, May 13, 2016 at 11:48 AM, foo86  wrote:
> > Valid sample_fmt will be set by dcadec_decode_frame() based on stream
> > type.
> > ---
> >  libavcodec/dcadec.c | 3 ---
> >  1 file changed, 3 deletions(-)
> >
> > diff --git a/libavcodec/dcadec.c b/libavcodec/dcadec.c
> > index e3a4b0d..565242d 100644
> > --- a/libavcodec/dcadec.c
> > +++ b/libavcodec/dcadec.c
> > @@ -374,9 +374,6 @@ static av_cold int dcadec_init(AVCodecContext *avctx)
> >  break;
> >  }
> >
> > -avctx->sample_fmt = AV_SAMPLE_FMT_S32P;
> > -avctx->bits_per_raw_sample = 24;
> > -
> >  return 0;
> >  }
> >
> 
> Having an initial format for the most "common" types of streams is
> generally sensible.

Do you suggest it should be changed to AV_SAMPLE_FMT_FLTP then? Core
streams are probably the most "common".

I don't have a strong prefenence on this, but I thought that not having
initial sample_fmt set will serve as useful indication to API user that
sample_fmt can (and will) change after the frame is decoded.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Respect payload offset in av_grow_packet

[Michael Niedermayer]

On Fri, May 13, 2016 at 03:15:07PM +0300, Andriy Lysnevych wrote:
> The patch fixes the function when used with reference-counted packets
> that have payload offset.
> 
> Also this function is dangerous for not reference-counted packets
> because it just overwrites pkt->data. Probably it is better to
> restrict using it with not referenced-counted packets because you
> simply don't know how to do grow\realloc in this case.
> 
> h264_mp4toannexb and h265_mp4toannexb already call av_grow_packet on
> input packets that leads to memory leak in case of not reference
> counted packets.
> 
> ---
>  libavcodec/avpacket.c | 25 +++--
>  1 file changed, 15 insertions(+), 10 deletions(-)

Applying: Respect payload offset in av_grow_packet
fatal: corrupt patch at line 51
Repository lacks necessary blobs to fall back on 3-way merge.
Cannot fall back to three-way merge.
Patch failed at 0001 Respect payload offset in av_grow_packet
When you have resolved this problem run "git am --resolved".
If you would prefer to skip this patch, instead run "git am --skip".
To restore the original branch and stop patching run "git am --abort".

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

Everything should be made as simple as possible, but not simpler.
-- Albert Einstein


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

Re: [FFmpeg-devel] [PATCH] fate: add aecho test

[Michael Niedermayer]

On Sat, May 14, 2016 at 09:07:17AM +, Petru Rares Sincraian wrote:
> 
> 
> Hi there,
> 
> Here I add a new test for aecho filter.

>  fate/filter-audio.mak |5 
>  ref/fate/filter-aecho |  286 
> ++
>  2 files changed, 291 insertions(+)
> efd0670e8f0c0c23e9d1392052b03ac4b7e047f0  0001-fate-add-aecho-test.patch
> From 25e8de6f4caa08a1903a6756ca718ef06722d116 Mon Sep 17 00:00:00 2001
> From: Petru Rares Sincraian 
> Date: Sat, 14 May 2016 11:04:25 +0200
> Subject: [PATCH] fate: add aecho test

this fails on x86-32

--- ffmpeg/tests/ref/fate/filter-aecho 2016-05-14 13:33:43.477820778 +0200
+++ tests/data/fate/filter-aecho2016-05-14 15:16:00.441950067 +0200
@@ -46,241 +46,241 @@
 0,  40960,  40960, 1024, 4096, 0x7c4ce7e9
 0,  41984,  41984, 1024, 4096, 0x5eddeb19
 0,  43008,  43008, 1024, 4096, 0x351c08c4
-0,  44032,  44032, 1024, 4096, 0x30c6db8f
-0,  45056,  45056, 1024, 4096, 0x1c4b3258
-0,  46080,  46080, 1024, 4096, 0xe32d157e
+0,  44032,  44032, 1024, 4096, 0x4dd4db91
+0,  45056,  45056, 1024, 4096, 0x07ad3256
+0,  46080,  46080, 1024, 4096, 0xe6131580
 0,  47104,  47104, 1024, 4096, 0xbbe9e635
-0,  48128,  48128, 1024, 4096, 0x7e8214dc
-0,  49152,  49152, 1024, 4096, 0xd671e4c1
-0,  50176,  50176, 1024, 4096, 0xd268f457
-0,  51200,  51200, 1024, 4096, 0x6051018e
+0,  48128,  48128, 1024, 4096, 0x8f4014de
+0,  49152,  49152, 1024, 4096, 0xbc53e4bf
+0,  50176,  50176, 1024, 4096, 0xf2b6f459
+0,  51200,  51200, 1024, 4096, 0x83350192


you can test that with somethng like
./configure  --arch=x86_32 --target-os=linux --extra-cflags=-m32 
--extra-ldflags=-m32  --enable-cross-compile

aecho uses floats so rounding and precission differences can cause
differences between platforms
you could improve aecho so it does not depend on floats for filtering
of s16 samples
but maybe you can find parameters that give the same result on all
platforms without that
or a small reference file would need to be added and tiny_psnr used
for comparing

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The real ebay dictionary, page 3
"Rare item" - "Common item with rare defect or maybe just a lie"
"Professional" - "'Toy' made in china, not functional except as doorstop"
"Experts will know" - "The seller hopes you are not an expert"


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

[FFmpeg-devel] [PATCH] fate: add aecho test

[Petru Rares Sincraian]

Hi there,

Here I add a new test for aecho filter.From 25e8de6f4caa08a1903a6756ca718ef06722d116 Mon Sep 17 00:00:00 2001
From: Petru Rares Sincraian 
Date: Sat, 14 May 2016 11:04:25 +0200
Subject: [PATCH] fate: add aecho test

---
 tests/fate/filter-audio.mak |   5 +
 tests/ref/fate/filter-aecho | 286 
 2 files changed, 291 insertions(+)
 create mode 100644 tests/ref/fate/filter-aecho

diff --git a/tests/fate/filter-audio.mak b/tests/fate/filter-audio.mak
index 7f7e520..2d125bb 100644
--- a/tests/fate/filter-audio.mak
+++ b/tests/fate/filter-audio.mak
@@ -3,6 +3,11 @@ fate-filter-adelay: tests/data/asynth-44100-2.wav
 fate-filter-adelay: SRC = $(TARGET_PATH)/tests/data/asynth-44100-2.wav
 fate-filter-adelay: CMD = framecrc -i $(SRC) -af adelay=42
 
+FATE_AFILTER-$(call FILTERDEMDECENCMUX, AECHO, WAV, PCM_S16LE, PCM_S16LE, WAV) += fate-filter-aecho
+fate-filter-aecho: tests/data/asynth-44100-2.wav
+fate-filter-aecho: SRC = $(TARGET_PATH)/tests/data/asynth-44100-2.wav
+fate-filter-aecho: CMD = framecrc -i $(SRC) -af aecho=0.8:0.88:1000:0.4
+
 tests/data/hls-list.m3u8: TAG = GEN
 tests/data/hls-list.m3u8: ffmpeg$(PROGSSUF)$(EXESUF) | tests/data
 	$(M)$(TARGET_EXEC) $(TARGET_PATH)/$< \
diff --git a/tests/ref/fate/filter-aecho b/tests/ref/fate/filter-aecho
new file mode 100644
index 000..e7fd93a
--- /dev/null
+++ b/tests/ref/fate/filter-aecho
@@ -0,0 +1,286 @@
+#tb 0: 1/44100
+#media_type 0: audio
+#codec_id 0: pcm_s16le
+#sample_rate 0: 44100
+#channel_layout 0: 3
+0,  0,  0, 1024, 4096, 0x078eef35
+0,   1024,   1024, 1024, 4096, 0xa24bf529
+0,   2048,   2048, 1024, 4096, 0xd22c0198
+0,   3072,   3072, 1024, 4096, 0x09f9f4df
+0,   4096,   4096, 1024, 4096, 0x280aecab
+0,   5120,   5120, 1024, 4096, 0x1ea9e9a7
+0,   6144,   6144, 1024, 4096, 0xaf750540
+0,   7168,   7168, 1024, 4096, 0x0441013a
+0,   8192,   8192, 1024, 4096, 0x7c4ce7e9
+0,   9216,   9216, 1024, 4096, 0x5eddeb19
+0,  10240,  10240, 1024, 4096, 0x351c08c4
+0,  11264,  11264, 1024, 4096, 0xc3a405a6
+0,  12288,  12288, 1024, 4096, 0xfc520092
+0,  13312,  13312, 1024, 4096, 0x4fa8f123
+0,  14336,  14336, 1024, 4096, 0x221bf9cf
+0,  15360,  15360, 1024, 4096, 0x9804049c
+0,  16384,  16384, 1024, 4096, 0x9c91042a
+0,  17408,  17408, 1024, 4096, 0x78f8fc09
+0,  18432,  18432, 1024, 4096, 0xf87cf179
+0,  19456,  19456, 1024, 4096, 0xc7d2fe37
+0,  20480,  20480, 1024, 4096, 0xef880684
+0,  21504,  21504, 1024, 4096, 0x813f09be
+0,  22528,  22528, 1024, 4096, 0x3575ea13
+0,  23552,  23552, 1024, 4096, 0x7217ea0d
+0,  24576,  24576, 1024, 4096, 0x9838ff51
+0,  25600,  25600, 1024, 4096, 0xe087043c
+0,  26624,  26624, 1024, 4096, 0x4b10ea9f
+0,  27648,  27648, 1024, 4096, 0x050ced89
+0,  28672,  28672, 1024, 4096, 0x7228f295
+0,  29696,  29696, 1024, 4096, 0xc60101ee
+0,  30720,  30720, 1024, 4096, 0xa4ebf763
+0,  31744,  31744, 1024, 4096, 0x83c1
+0,  32768,  32768, 1024, 4096, 0x078eef35
+0,  33792,  33792, 1024, 4096, 0xa24bf529
+0,  34816,  34816, 1024, 4096, 0xd22c0198
+0,  35840,  35840, 1024, 4096, 0x09f9f4df
+0,  36864,  36864, 1024, 4096, 0x280aecab
+0,  37888,  37888, 1024, 4096, 0x1ea9e9a7
+0,  38912,  38912, 1024, 4096, 0xaf750540
+0,  39936,  39936, 1024, 4096, 0x0441013a
+0,  40960,  40960, 1024, 4096, 0x7c4ce7e9
+0,  41984,  41984, 1024, 4096, 0x5eddeb19
+0,  43008,  43008, 1024, 4096, 0x351c08c4
+0,  44032,  44032, 1024, 4096, 0x30c6db8f
+0,  45056,  45056, 1024, 4096, 0x1c4b3258
+0,  46080,  46080, 1024, 4096, 0xe32d157e
+0,  47104,  47104, 1024, 4096, 0xbbe9e635
+0,  48128,  48128, 1024, 4096, 0x7e8214dc
+0,  49152,  49152, 1024, 4096, 0xd671e4c1
+0,  50176,  50176, 1024, 4096, 0xd268f457
+0,  51200,  51200, 1024, 4096, 0x6051018e
+0,  52224,  52224, 1024, 4096, 0x2f31fe93
+0,  53248,  53248, 1024, 4096, 0xa72e0dca
+0,  54272,  54272, 1024, 4096, 0x609ffcf1
+0,  55296,  55296, 1024, 4096, 0xe020f453
+0,  56320,  56320, 1024, 4096, 0xb9c9f631
+0,  57344,  57344, 1024, 4096, 0xa8a4c6fd
+0,  58368,  58368, 1024, 4096, 0x1f40ffdd
+0,  59392,