[FFmpeg-devel] [PATCH]lavf/flacdec: Return maximum score if a valid streaminfo header was found

[Carl Eugen Hoyos]

Hi!

I implemented this patch to fix ticket #6208 but it turned out the flac probe 
function wasn't the issue. Still looks like a good idea to me.

Please comment, Carl Eugen
From acc7558a3585d99776523ed670747597c4de99fb Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Wed, 1 Mar 2017 09:34:37 +0100
Subject: [PATCH 1/2] lavf/flacdec: Return maximum score if the streaminfo
 header is valid.

---
 libavformat/flacdec.c |9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/libavformat/flacdec.c b/libavformat/flacdec.c
index 66baba5..c75eba8 100644
--- a/libavformat/flacdec.c
+++ b/libavformat/flacdec.c
@@ -233,7 +233,14 @@ static int flac_probe(AVProbeData *p)
 return raw_flac_probe(p);
 if (p->buf_size < 4 || memcmp(p->buf, "fLaC", 4))
 return 0;
-return AVPROBE_SCORE_EXTENSION;
+if (   p->buf[4] & 0x7f != FLAC_METADATA_TYPE_STREAMINFO
+|| AV_RB24(p->buf + 5) != FLAC_STREAMINFO_SIZE
+|| AV_RB16(p->buf + 8) < 16
+|| AV_RB16(p->buf + 8) > AV_RB16(p->buf + 10)
+|| !(AV_RB24(p->buf + 18) >> 4)
+|| AV_RB24(p->buf + 18) >> 4 > 655350)
+return AVPROBE_SCORE_EXTENSION / 8;
+return AVPROBE_SCORE_MAX;
 }
 
 static av_unused int64_t flac_read_timestamp(AVFormatContext *s, int 
stream_index,
-- 
1.7.10.4

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

[FFmpeg-devel] [PATCH]lavf/cavsvideodec: Return a lower score if only one frame was found

[Carl Eugen Hoyos]

Hi!

Attached patch fixes ticket #6208.

Please comment, Carl Eugen
From 901443bd61d33f62a4fd904aad5f270d0a018a8a Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Wed, 1 Mar 2017 09:35:16 +0100
Subject: [PATCH 2/2] lavf/cavsvideodec: Return a lower score if only one
 frame was found.

Fixes ticket #6208.
---
 libavformat/cavsvideodec.c |5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/libavformat/cavsvideodec.c b/libavformat/cavsvideodec.c
index b4da58e..fa920ad 100644
--- a/libavformat/cavsvideodec.c
+++ b/libavformat/cavsvideodec.c
@@ -61,8 +61,11 @@ static int cavsvideo_probe(AVProbeData *p)
 }
 }
 }
-if(seq && seq*9<=pic*10)
+if (seq && seq * 9 <= pic * 10 && pic > 1) {
 return AVPROBE_SCORE_EXTENSION+1;
+} else if (seq && seq * 9 <= pic * 10) {
+return AVPROBE_SCORE_EXTENSION - 1;
+}
 return 0;
 }
 
-- 
1.7.10.4

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

Re: [FFmpeg-devel] [PATCH]Makefile: Clean compat subdirectory

[Carl Eugen Hoyos]

2017-03-01 2:14 GMT+01:00 Michael Niedermayer :
> On Tue, Feb 21, 2017 at 02:38:22PM +0100, Carl Eugen Hoyos wrote:
>> Hi!
>>
>> Attached patch fixes ticket #5546 here.
>>
>> Please comment, Carl Eugen
>
>>  Makefile |2 ++
>>  1 file changed, 2 insertions(+)
>> 47464e0891035a702d5228a79e40b4855e6262a1  
>> 0001-Makefile-Clean-compat-subdirectory.patch
>> From 175f3ba7b6034670965e62beef26294efdbc858f Mon Sep 17 00:00:00 2001
>> From: Carl Eugen Hoyos 
>> Date: Tue, 21 Feb 2017 14:36:15 +0100
>> Subject: [PATCH] Makefile: Clean compat subdirectory.
>
> probably ok

Patch applied.

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

Re: [FFmpeg-devel] [PATCH]lavf/matroska: Support codec id V_FFV1 for FFV1.

[Carl Eugen Hoyos]

2017-03-01 4:40 GMT+01:00 Michael Niedermayer :
> On Tue, Feb 28, 2017 at 08:45:44PM +0100, Carl Eugen Hoyos wrote:
>> Hi!
>>
>> Attached patch fixes ticket #6206 here.
>>
>> Please comment, Carl Eugen
>
> previous ffmpeg versions dont play these files

What do you suggest?

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

Re: [FFmpeg-devel] [PATCH] (for discussion): cuvid: allow to crop and resize in decoder

[Timo Rothenpieler]

>> We recently just had all sorts of discussions what decoders should and
>> should not do, I don't think scaling in a decoder is a good thing to
>> start doing here.
> 
> scaling in some decoders is mandated by some specs
> some standards support reduced resolution which can switch from frame
> to frame without the decoder output changing
> There is also the possiblity of scalability where the reference stream
> has lower resolution IIRC.
> 
> This is kind of different of course but, scaling code in decoders is
> part of some specifications.

Would like to bring this back up.
I'd like to merge this, as specially the scaling is freely done by the
video asic, offering a possibility to scale without requiring non-free
libnpp. And cropping so far is not possible at all.

Yes, scaling and cropping is not something a decoder usually does, but
it exposes a hardware feature that has no other way of accessing it,
which offers valuable functionality to users.



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

Re: [FFmpeg-devel] [PATCH] doc: clarify development rules

[wm4]

On Sat, 25 Feb 2017 21:23:27 +0100 (CET)
Marton Balint  wrote:

> On Sat, 25 Feb 2017, Rostislav Pehlivanov wrote:
> 
> > On 25 February 2017 at 18:35, Marton Balint  wrote:
> >  
> >>
> >> On Sat, 25 Feb 2017, wm4 wrote:
> >>
> >> I'm documenting existing practice.  
> >>>
> >>> I'm pulling the "6 months" timeout out of my ass, but I think it's
> >>> pretty suitable.
> >>> ---  
> 
> [...]
> 
> > This is the way it has been done for years and its the way the project has
> > been able to move as rapidly as it has. That would slow down anything large
> > from being developed in the codebase, like encoders or decoders for a new
> > format, which are usually being developed by a single person who
> > understands the code better than anybody. I am okay with it being an
> > unwritten rule, anyone who needs to know about it knows about it and
> > everyone that knows about it knows that moderation is the key. But
> > forbidding it will kill the project.  
> 
> I only want to have a chance to review before patches got pushed. I am not 
> saying we should explicitly demand a review for each patch. So this 
> normally should only cause any developer an additional sent email to the 
> ML and 1-2 days of delay. With git, I don't think this is that much 
> additional work.
> 
> Of course, I could just subscribe to csvlog as well, and give post-commit 
> reviews if I want, it is just better to do it earlier, and less chance of 
> revert wars, because with the 'written' rule above I just as easily revert 
> anything in unmaintained code without a discussion, and remain within the 
> 'rules'.
> 
> 
> >> If this gets pushed, I am inclined to clean up the MAINTAINERS file and
> >> remove everybody who is no longer "active", and assume maintainership of
> >> parts I actively use and care about, but which has no maintainership
> >> anymore.
> >>  
> >
> > So you're okay as long as maintainers gets sorted out? You might as well do
> > it, its what's the file is supposed to reflect.  
> 
> I still prefer if this is not applied. MAINTAINERS file might be cleaned 
> up regardless of this patch, however I think we should at least ping 
> everybody we are trying to remove from it.

As I said in another reply, I'm only documenting existing practice. We
can still change the rules in a separate patch (which of course will be
major drama etc. in which I don't necessarily want to be involved).

Or are there any doubts that this patch does what I claim it does
(documenting existing practice)?

Apart from that, I don't even know whether I can push this patch, or
what I have to do to get clear rejection/approval. The MAINTAINERS
file has ironically no maintainer.

So far, the score is 1 approval, and 2 invalid rejects. I guess I'll
push it on Friday morning if nobody rejects it by then.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] doc: clarify development rules

[Carl Eugen Hoyos]

2017-02-25 15:59 GMT+01:00 wm4 :
> I'm documenting existing practice.

> -@subheading Always wait long enough before pushing changes
> +@subheading Always wait long enough before pushing changes to code actively 
> maintained by others

I suspect this is missing an exception for security issues if you want to
document the actual practice.

> +@subheading Pushing patches without sending them to the mailing list
> +If you're the maintainer of a file, or the file is not actively maintained by
> +anyone, or the file is not covered by the MAINTAINERS file, you can just push
> +them without asking for permission, and without sending them to ffmpeg-devel.
> +This right only applies to developers with git push access, of course.

> +A maintainer is considered not active if he hasn't posted a mail to 
> ffmpeg-devel
> +for longer than 6 months, and hasn't pushed a patch in that time period 
> himself.

Unfortunately, there are maintainers who are happy to review patches
sent to improve their code but the files were not touched for more than
six months so they did not seem active for more than six months.

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

Re: [FFmpeg-devel] [PATCH] doc: clarify development rules

[Carl Eugen Hoyos]

2017-02-25 16:03 GMT+01:00 Ivan Kalvachev :

> I do prefer all the code to go though the maillist.
> Even trivial changes.

This is not how we have done it for more than a decade
and I am against changing our (extremely successful) practice.

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

Re: [FFmpeg-devel] [PATCH] doc: clarify development rules

[Carl Eugen Hoyos]

2017-02-25 19:35 GMT+01:00 Marton Balint :

> Instead of this, I'd prefer all patches on the ML.

This would mean we changed from a policy that we successful
applied for over a decade to a policy of which we - to the best
of my knowledge - know that it does not work well.

> Exceptions can be OKish
> (e.g. libav merges, which are hard as they are, or very trivial fixes), but
> I definitely would not make unreviewed pushes an encouraged and written
> policy.

I was under the impression that this - luckily - already was
written policy.

> If this gets pushed, I am inclined to clean up the MAINTAINERS file and
> remove everybody who is no longer "active"

While a cleanup is of course ok, please note that there MAINTAINERS
who are willing to maintain but had no reason to do so for longer than
six months.

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

Re: [FFmpeg-devel] [PATCH] doc: clarify development rules

[Carl Eugen Hoyos]

2017-02-25 21:23 GMT+01:00 Marton Balint :

> Of course, I could just subscribe to csvlog as well

I was under the impression that if you want commit rights,
you are required to be subscribed to -cvslog.

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

Re: [FFmpeg-devel] [PATCH] doc: clarify development rules

[wm4]

On Wed, 1 Mar 2017 12:20:10 +0100
Carl Eugen Hoyos  wrote:

> 2017-02-25 15:59 GMT+01:00 wm4 :
> > I'm documenting existing practice.  
> 
> > -@subheading Always wait long enough before pushing changes
> > +@subheading Always wait long enough before pushing changes to code 
> > actively maintained by others  
> 
> I suspect this is missing an exception for security issues if you want to
> document the actual practice.

I can add to the end of the subheading:

  Critical security issues are an exception. These can be pushed after
  the patch has been for 24 hours on the mailing list and the maintainer
  didn't respond yet, and nobody has rejected the patch. In addition,
  if another committer has approved the patch and acknowledged the
  urgency of the fix, the patch can be pushed immediately.

Maybe a bit long, but should cover all bases.

> > +@subheading Pushing patches without sending them to the mailing list
> > +If you're the maintainer of a file, or the file is not actively maintained 
> > by
> > +anyone, or the file is not covered by the MAINTAINERS file, you can just 
> > push
> > +them without asking for permission, and without sending them to 
> > ffmpeg-devel.
> > +This right only applies to developers with git push access, of course.  
> 
> > +A maintainer is considered not active if he hasn't posted a mail to 
> > ffmpeg-devel
> > +for longer than 6 months, and hasn't pushed a patch in that time period 
> > himself.  
> 
> Unfortunately, there are maintainers who are happy to review patches
> sent to improve their code but the files were not touched for more than
> six months so they did not seem active for more than six months.

So what is a reasonable method of determining whether a maintainer is
reachable?

The worst part is that not even "active" maintainers always respond,
even if you go a timeout.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] Revert "avutil/frame: Disallow zero sized frame side data"

[Michael Niedermayer]

Found a case where we use size==0, the other related commits
remain needed, and should be sufficient to fix the original issue

This reverts commit 7e4f32f4e4b93c95dcc872cb844c5548e69f352e.
---
 libavutil/frame.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/libavutil/frame.c b/libavutil/frame.c
index 69ee240758..8811dcdcfe 100644
--- a/libavutil/frame.c
+++ b/libavutil/frame.c
@@ -668,8 +668,6 @@ AVFrameSideData *av_frame_new_side_data(AVFrame *frame,
 enum AVFrameSideDataType type,
 int size)
 {
-if (size <= 0)
-return NULL;
 
 return frame_new_side_data(frame, type, av_buffer_alloc(size));
 }
-- 
2.11.0

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

Re: [FFmpeg-devel] [PATCH]lavc/internal: Constify AVPacket* in AVCodecInternal.

[Michael Niedermayer]

On Sun, Feb 26, 2017 at 12:38:14PM +0100, Carl Eugen Hoyos wrote:
> Hi!
> 
> Attached patch fixes another warning when compiling libavcodec/utils.o.
> 
> Please comment, Carl Eugen

if it doesnt produce any new warnings elsewere then its probably ok

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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

Re: [FFmpeg-devel] [PATCH] doc: clarify development rules

[Carl Eugen Hoyos]

2017-03-01 12:36 GMT+01:00 wm4 :
> On Wed, 1 Mar 2017 12:20:10 +0100
> Carl Eugen Hoyos  wrote:
>
>> 2017-02-25 15:59 GMT+01:00 wm4 :
>> > I'm documenting existing practice.
>>
>> > -@subheading Always wait long enough before pushing changes
>> > +@subheading Always wait long enough before pushing changes
>> > to code actively maintained by others
>>
>> I suspect this is missing an exception for security issues if you want to
>> document the actual practice.
>
> I can add to the end of the subheading:
>
>   Critical security issues are an exception. These can be pushed after
>   the patch has been for 24 hours on the mailing list and the maintainer
>   didn't respond yet, and nobody has rejected the patch. In addition,
>   if another committer has approved the patch and acknowledged the
>   urgency of the fix, the patch can be pushed immediately.

I will most likely not fix a (real) security issue, but above seems quite
unpractical to me (and unreasonable for real security issues).

> Maybe a bit long, but should cover all bases.
>
>> > +@subheading Pushing patches without sending them to the mailing list
>> > +If you're the maintainer of a file, or the file is not actively 
>> > maintained by
>> > +anyone, or the file is not covered by the MAINTAINERS file, you can just 
>> > push
>> > +them without asking for permission, and without sending them to 
>> > ffmpeg-devel.
>> > +This right only applies to developers with git push access, of course.
>>
>> > +A maintainer is considered not active if he hasn't posted a mail to 
>> > ffmpeg-devel
>> > +for longer than 6 months, and hasn't pushed a patch in that time period 
>> > himself.
>>
>> Unfortunately, there are maintainers who are happy to review patches
>> sent to improve their code but the files were not touched for more than
>> six months so they did not seem active for more than six months.
>
> So what is a reasonable method of determining whether a maintainer
> is reachable?

I fear there is no strict definition, patches can always be reverted though
if a maintainer requests that.

I am just (slightly) against writing "after six months, you are no more a
maintainer".

> The worst part is that not even "active" maintainers always respond,
> even if you go a timeout.

Then you push after the timeout (if no delay was requested).

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

Re: [FFmpeg-devel] [PATCH]lavf/matroska: Support codec id V_FFV1 for FFV1.

[Michael Niedermayer]

On Wed, Mar 01, 2017 at 09:43:57AM +0100, Carl Eugen Hoyos wrote:
> 2017-03-01 4:40 GMT+01:00 Michael Niedermayer :
> > On Tue, Feb 28, 2017 at 08:45:44PM +0100, Carl Eugen Hoyos wrote:
> >> Hi!
> >>
> >> Attached patch fixes ticket #6206 here.
> >>
> >> Please comment, Carl Eugen
> >
> > previous ffmpeg versions dont play these files
> 
> What do you suggest?

support this at the demuxer side, backport such support then
wait till its supported widely before switching the default in the
muxer


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

Good people do not need laws to tell them to act responsibly, while bad
people will find a way around the laws. -- 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] avcodec/avpacket: Check metadata key in av_packet_unpack_dictionary()

[Michael Niedermayer]

On Mon, Feb 27, 2017 at 04:12:09AM +0100, Michael Niedermayer wrote:
> Fixes timeout
> Fixes: 501/clusterfuzz-testcase-5672752870588416
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/avpacket.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

applied

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

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


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

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/h264_direct: Fix runtime error: left shift of negative value -14

[Michael Niedermayer]

On Tue, Feb 28, 2017 at 04:28:29AM +0100, Michael Niedermayer wrote:
> Fixes: 682/clusterfuzz-testcase-4799120021651456
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/h264_direct.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

applied

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

Good people do not need laws to tell them to act responsibly, while bad
people will find a way around the laws. -- 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]lavf/matroska: Support codec id V_FFV1 for FFV1.

[Hendrik Leppkes]

On Wed, Mar 1, 2017 at 1:07 PM, Michael Niedermayer
 wrote:
> On Wed, Mar 01, 2017 at 09:43:57AM +0100, Carl Eugen Hoyos wrote:
>> 2017-03-01 4:40 GMT+01:00 Michael Niedermayer :
>> > On Tue, Feb 28, 2017 at 08:45:44PM +0100, Carl Eugen Hoyos wrote:
>> >> Hi!
>> >>
>> >> Attached patch fixes ticket #6206 here.
>> >>
>> >> Please comment, Carl Eugen
>> >
>> > previous ffmpeg versions dont play these files
>>
>> What do you suggest?
>
> support this at the demuxer side, backport such support then
> wait till its supported widely before switching the default in the
> muxer

FFV1 didn't have any mapping in matroska before this, so what exactly
is there to support?
Also, format support is technically a feature, so back-porting seems
ill-advised.

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

Re: [FFmpeg-devel] [PATCH]lavf/matroska: Support codec id V_FFV1 for FFV1.

[Carl Eugen Hoyos]

2017-03-01 13:18 GMT+01:00 Hendrik Leppkes :

> FFV1 didn't have any mapping in matroska before this

I believe it is safe to say that many people used ffv1 in mkv
and they would be surprised if their new files suddenly didn't
play in vlc.

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

Re: [FFmpeg-devel] [PATCH 2/2] avcodec/vp8: Check for bitsteam end in decode_mb_row_no_filter()

[Michael Niedermayer]

On Tue, Feb 28, 2017 at 10:19:05PM -0500, Ronald S. Bultje wrote:
> Hi Michael,
> 
> On Tue, Feb 28, 2017 at 11:29 AM, Michael Niedermayer <
> mich...@niedermayer.cc> wrote:
> 
> > On Tue, Feb 28, 2017 at 07:44:12AM -0500, Ronald S. Bultje wrote:
> > > Hi,
> > >
> > > On Mon, Feb 27, 2017 at 10:28 PM, Michael Niedermayer <
> > > mich...@niedermayer.cc> wrote:
> > >
> > > > Fixes: 686/clusterfuzz-testcase-5853946876788736
> > > >
> > > > Found-by: continuous fuzzing process https://github.com/google/oss-
> > > > fuzz/tree/master/targets/ffmpeg
> > > > Signed-off-by: Michael Niedermayer 
> > > > ---
> > > >  libavcodec/vp8.c | 20 ++--
> > > >  libavcodec/vp8.h |  2 +-
> > > >  2 files changed, 15 insertions(+), 7 deletions(-)
> > > >
> > > > diff --git a/libavcodec/vp8.c b/libavcodec/vp8.c
> > > > index c1c3eb7072..cc158528ef 100644
> > > > --- a/libavcodec/vp8.c
> > > > +++ b/libavcodec/vp8.c
> > > > @@ -2275,7 +2275,7 @@ static void vp8_decode_mv_mb_modes(
> > AVCodecContext
> > > > *avctx, VP8Frame *cur_frame,
> > > >  #define update_pos(td, mb_y, mb_x) while(0)
> > > >  #endif
> > > >
> > > > -static av_always_inline void decode_mb_row_no_filter(AVCodecContext
> > > > *avctx, void *tdata,
> > > > +static av_always_inline int decode_mb_row_no_filter(AVCodecContext
> > > > *avctx, void *tdata,
> > > >  int jobnr, int threadnr, int
> > > > is_vp7)
> > > >  {
> > > >  VP8Context *s = avctx->priv_data;
> > > > @@ -2291,6 +2291,10 @@ static av_always_inline void
> > > > decode_mb_row_no_filter(AVCodecContext *avctx, void
> > > >  curframe->tf.f->data[1] +  8 * mb_y * s->uvlinesize,
> > > >  curframe->tf.f->data[2] +  8 * mb_y * s->uvlinesize
> > > >  };
> > > > +
> > > > +if (c->end <= c->buffer && c->bits >= 0)
> > > > + return AVERROR_INVALIDDATA;
> > >
> > >
> > > From vp56.h:
> > >
> > > if(bits >= 0 && c->buffer < c->end) {
> > > code_word |= bytestream_get_be16(&c->buffer) << bits;
> > > bits -= 16;
> > > }
> > >
> > > So this looks supicious, c->end should never be more than 1 byte beyond
> > > c->buffer (which is padded by AV_INPUT_BUFFER_PADDING_SIZE). What is the
> > > real issue?
> >
> > The real issue is that the code runs with blindfolds and hands tied
> > behind its back, so it doesnt know when its running toward a wall
> > and in fact it doesnt stop running when it hits the wall not even
> > once it starved, its even running in its grave.
> >
> > You can feed the code with approximately a header with huge resolution
> > and 0 bytes of actual image and it wont notice, and after a really long
> > time it still wont notice it is decoding a image out of a non existing
> > bitstream.
> >
> > That check checks if the end of the bitstream is reached and returns
> > an error in that case. That way the test sample finished in 10sec
> > instead of not finishing within the time i waited
> 
> 
> Ah, that explains things.
> 
> The commit message uses "fuzz" and "fix" in the same sentence construction,
> suggesting a security issue. You're now telling me there is in fact no
> security issue. That suggests the commit message is wrong.
> 
> I'm fine with the patch as is, but change the commit message. I would
> suggest still referring to the filename, but avoiding the word "fix" since
> it doesn't fix anything - since there is no bug. And then explain (in the

ive added "Timeout" after fix as thats what is "fixed", should avoid
the ambiguity


> commit message) that this shortcuts (i.e. speeds up) the error and
> return-to-user when decoding a truncated frame. No error message is
> necessary, it'll be something silly like "truncated bitstream" which
> clobbers my terminal when I'm fuzzing and is otherwise virtually useless.

added the suggeted text

applied

thx

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

Concerning the gods, I have no means of knowing whether they exist or not
or of what sort they may be, because of the obscurity of the subject, and
the brevity of human life -- Protagoras


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

Re: [FFmpeg-devel] [PATCH]lavf/matroska: Support codec id V_FFV1 for FFV1.

[Michael Niedermayer]

On Wed, Mar 01, 2017 at 01:18:09PM +0100, Hendrik Leppkes wrote:
> On Wed, Mar 1, 2017 at 1:07 PM, Michael Niedermayer
>  wrote:
> > On Wed, Mar 01, 2017 at 09:43:57AM +0100, Carl Eugen Hoyos wrote:
> >> 2017-03-01 4:40 GMT+01:00 Michael Niedermayer :
> >> > On Tue, Feb 28, 2017 at 08:45:44PM +0100, Carl Eugen Hoyos wrote:
> >> >> Hi!
> >> >>
> >> >> Attached patch fixes ticket #6206 here.
> >> >>
> >> >> Please comment, Carl Eugen
> >> >
> >> > previous ffmpeg versions dont play these files
> >>
> >> What do you suggest?
> >
> > support this at the demuxer side, backport such support then
> > wait till its supported widely before switching the default in the
> > muxer
> 
> FFV1 didn't have any mapping in matroska before this, so what exactly
> is there to support?

mkv supports all avi identifers,  i assume that is what was used before


> Also, format support is technically a feature, so back-porting seems
> ill-advised.

I think backporting format identifers, fourccs and such is safe.
And this one should be back ported


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

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


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

[FFmpeg-devel] [PATCH] configure: convert MSVC ident to utf-8 if possible

[Timo Rothenpieler]

---
 configure | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/configure b/configure
index 0199fec..398d530 100755
--- a/configure
+++ b/configure
@@ -4095,7 +4095,11 @@ probe_cc(){
 disable stripping
 elif $_cc -nologo- 2>&1 | grep -q Microsoft; then
 _type=msvc
-_ident=$($_cc 2>&1 | head -n1)
+if command -v iconv >/dev/null 2>&1; then
+_ident=$($_cc 2>&1 | head -n1 | iconv -sc -f CP850 -t UTF-8)
+else
+_ident=$($_cc 2>&1 | head -n1)
+fi
 _DEPCMD='$(DEP$(1)) $(DEP$(1)FLAGS) $($(1)DEP_FLAGS) $< 2>&1 | awk 
'\''/including/ { sub(/^.*file: */, ""); gsub(/\\/, "/"); if (!match($$0, / /)) 
print "$@:", $$0 }'\'' > $(@:.o=.d)'
 _DEPFLAGS='$(CPPFLAGS) $(CFLAGS) -showIncludes -Zs'
 _cflags_speed="-O2"
-- 
2.8.3

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

Re: [FFmpeg-devel] [PATCH]lavf/matroska: Support codec id V_FFV1 for FFV1.

[Reto Kromer]

Michael Niedermayer wrote:

>> FFV1 didn't have any mapping in matroska before this, so
>> what exactly is there to support?
>
>mkv supports all avi identifers,  i assume that is what was
>used before
>
>> Also, format support is technically a feature, so back-
>> porting seems ill-advised.
>
>I think backporting format identifers, fourccs and such is
>safe.
>And this one should be back ported

I fully agree that this one should be back-ported.

Best regards, Reto

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

Re: [FFmpeg-devel] [PATCH]lavf/matroska: Support codec id V_FFV1 for FFV1.

[wm4]

On Wed, 1 Mar 2017 13:07:12 +0100
Michael Niedermayer  wrote:

> On Wed, Mar 01, 2017 at 09:43:57AM +0100, Carl Eugen Hoyos wrote:
> > 2017-03-01 4:40 GMT+01:00 Michael Niedermayer :  
> > > On Tue, Feb 28, 2017 at 08:45:44PM +0100, Carl Eugen Hoyos wrote:  
> > >> Hi!
> > >>
> > >> Attached patch fixes ticket #6206 here.
> > >>
> > >> Please comment, Carl Eugen  
> > >
> > > previous ffmpeg versions dont play these files  
> > 
> > What do you suggest?  
> 
> support this at the demuxer side, backport such support then
> wait till its supported widely before switching the default in the
> muxer

So if I understand this right:
- the patch will change the muxer output to use V_FFV1 instead of using
  avi-compat muxing
- you demand that we wait with this because older ffmpeg versions would
  choke on the new version

So what about all the other muxers that exist in the wild and that will
break on this file? Will you fix them too? I think this suggestion of
waiting until FFmpeg can eat the new output and only then changing the
output is possibly slightly self-centric, and also assumes everyone is
going to update their copy of FFmpeg.

If you're afraid that this change could break demuxers, you probably
shouldn't change it at all.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] doc: clarify development rules

[wm4]

On Wed, 1 Mar 2017 13:06:29 +0100
Carl Eugen Hoyos  wrote:

> 2017-03-01 12:36 GMT+01:00 wm4 :
> > On Wed, 1 Mar 2017 12:20:10 +0100
> > Carl Eugen Hoyos  wrote:
> >  
> >> 2017-02-25 15:59 GMT+01:00 wm4 :  
> >> > I'm documenting existing practice.  
> >>  
> >> > -@subheading Always wait long enough before pushing changes
> >> > +@subheading Always wait long enough before pushing changes
> >> > to code actively maintained by others  
> >>
> >> I suspect this is missing an exception for security issues if you want to
> >> document the actual practice.  
> >
> > I can add to the end of the subheading:
> >
> >   Critical security issues are an exception. These can be pushed after
> >   the patch has been for 24 hours on the mailing list and the maintainer
> >   didn't respond yet, and nobody has rejected the patch. In addition,
> >   if another committer has approved the patch and acknowledged the
> >   urgency of the fix, the patch can be pushed immediately.  
> 
> I will most likely not fix a (real) security issue, but above seems quite
> unpractical to me (and unreasonable for real security issues).

How is that impractical? What do you suggest?

I certainly hope you're not suggesting that security-sensitive changes
to code the patch author does not maintain can be pushed without reviews
at all.

> > Maybe a bit long, but should cover all bases.
> >  
> >> > +@subheading Pushing patches without sending them to the mailing list
> >> > +If you're the maintainer of a file, or the file is not actively 
> >> > maintained by
> >> > +anyone, or the file is not covered by the MAINTAINERS file, you can 
> >> > just push
> >> > +them without asking for permission, and without sending them to 
> >> > ffmpeg-devel.
> >> > +This right only applies to developers with git push access, of course.  
> >>  
> >> > +A maintainer is considered not active if he hasn't posted a mail to 
> >> > ffmpeg-devel
> >> > +for longer than 6 months, and hasn't pushed a patch in that time period 
> >> > himself.  
> >>
> >> Unfortunately, there are maintainers who are happy to review patches
> >> sent to improve their code but the files were not touched for more than
> >> six months so they did not seem active for more than six months.  
> >
> > So what is a reasonable method of determining whether a maintainer
> > is reachable?  
> 
> I fear there is no strict definition, patches can always be reverted though
> if a maintainer requests that.
> 
> I am just (slightly) against writing "after six months, you are no more a
> maintainer".

That's not what I wrote.

It merely means that if you have showed no sign of activity after 6
months, the timeout can be skipped.

> > The worst part is that not even "active" maintainers always respond,
> > even if you go a timeout.  
> 
> Then you push after the timeout (if no delay was requested).

michaelni didn't wait when pushing his vp56.c patches (didn't even send
them to the mailing list), even though it was a mid-sized (i.e. not
small) change. The maintainer of vp56.c is still reachable by mail, but
hasn't posted or contributed anything to ffmpeg in 3.5 years. michaelni
didn't wait for the timeout, which does not match with what you seem to
demand.

Please explain what the rules of this project are.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavf/matroska: Support codec id V_FFV1 for FFV1.

[Michael Niedermayer]

On Wed, Mar 01, 2017 at 01:36:26PM +0100, wm4 wrote:
> On Wed, 1 Mar 2017 13:07:12 +0100
> Michael Niedermayer  wrote:
> 
> > On Wed, Mar 01, 2017 at 09:43:57AM +0100, Carl Eugen Hoyos wrote:
> > > 2017-03-01 4:40 GMT+01:00 Michael Niedermayer :  
> > > > On Tue, Feb 28, 2017 at 08:45:44PM +0100, Carl Eugen Hoyos wrote:  
> > > >> Hi!
> > > >>
> > > >> Attached patch fixes ticket #6206 here.
> > > >>
> > > >> Please comment, Carl Eugen  
> > > >
> > > > previous ffmpeg versions dont play these files  
> > > 
> > > What do you suggest?  
> > 
> > support this at the demuxer side, backport such support then
> > wait till its supported widely before switching the default in the
> > muxer
> 
> So if I understand this right:
> - the patch will change the muxer output to use V_FFV1 instead of using
>   avi-compat muxing
> - you demand that we wait with this because older ffmpeg versions would
>   choke on the new version
> 
> So what about all the other muxers that exist in the wild and that will
> break on this file? Will you fix them too? I think this suggestion of
> waiting until FFmpeg can eat the new output and only then changing the
> output is possibly slightly self-centric, and also assumes everyone is
> going to update their copy of FFmpeg.

You seem to be reading things in the mail that it didnt say.

A reply to "What do you suggest?" is a suggestion not a demand
and
The suggestion does not refer to FFmpeg and it was not intended to
imply to refer to FFmpeg, especially the
"wait till its supported widely" was intended to refer to all software.

Its bad if we generate files by default noone can play back
I dont know how widespread V_FFV1 support is but i assume its not
widespread yet at all


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

If a bugfix only changes things apparently unrelated to the bug with no
further explanation, that is a good sign that the bugfix is 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]lavf/matroska: Support codec id V_FFV1 for FFV1.

[wm4]

On Wed, 1 Mar 2017 14:26:34 +0100
Michael Niedermayer  wrote:

> On Wed, Mar 01, 2017 at 01:36:26PM +0100, wm4 wrote:
> > On Wed, 1 Mar 2017 13:07:12 +0100
> > Michael Niedermayer  wrote:
> >   
> > > On Wed, Mar 01, 2017 at 09:43:57AM +0100, Carl Eugen Hoyos wrote:  
> > > > 2017-03-01 4:40 GMT+01:00 Michael Niedermayer : 
> > > >
> > > > > On Tue, Feb 28, 2017 at 08:45:44PM +0100, Carl Eugen Hoyos wrote:
> > > > >> Hi!
> > > > >>
> > > > >> Attached patch fixes ticket #6206 here.
> > > > >>
> > > > >> Please comment, Carl Eugen
> > > > >
> > > > > previous ffmpeg versions dont play these files
> > > > 
> > > > What do you suggest?
> > > 
> > > support this at the demuxer side, backport such support then
> > > wait till its supported widely before switching the default in the
> > > muxer  
> > 
> > So if I understand this right:
> > - the patch will change the muxer output to use V_FFV1 instead of using
> >   avi-compat muxing
> > - you demand that we wait with this because older ffmpeg versions would
> >   choke on the new version
> > 
> > So what about all the other muxers that exist in the wild and that will
> > break on this file? Will you fix them too? I think this suggestion of
> > waiting until FFmpeg can eat the new output and only then changing the
> > output is possibly slightly self-centric, and also assumes everyone is
> > going to update their copy of FFmpeg.  
> 
> You seem to be reading things in the mail that it didnt say.

Well, I didn't read the following (what's quoted) into it.

> A reply to "What do you suggest?" is a suggestion not a demand
> and
> The suggestion does not refer to FFmpeg and it was not intended to
> imply to refer to FFmpeg, especially the
> "wait till its supported widely" was intended to refer to all software.

Indeed, backporting support FFmpeg will not help that much.

So we either live with the fact that this change will break tons of
consumers, or we just don't make it.

> Its bad if we generate files by default noone can play back
> I dont know how widespread V_FFV1 support is but i assume its not
> widespread yet at all

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

Re: [FFmpeg-devel] Hardware Encode H264

[Ricardo Constantino]

Wrong mailing list. You're looking for
http://ffmpeg.org/mailman/listinfo/ffmpeg-user.

Also, your e-mail client sending HTML e-mails as plain text for some reason
which makes them quite unreadable.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavf/matroska: Support codec id V_FFV1 for FFV1.

[Jerome Martinez]

Le 01/03/2017 à 09:43, Carl Eugen Hoyos a écrit :

2017-03-01 4:40 GMT+01:00 Michael Niedermayer :

On Tue, Feb 28, 2017 at 08:45:44PM +0100, Carl Eugen Hoyos wrote:

Hi!

Attached patch fixes ticket #6206 here.

Please comment, Carl Eugen

previous ffmpeg versions dont play these files

What do you suggest?


My suggestion:
- support by the demuxer
- for the muxer, support only if a specific explicit option is set, 
default stays AVI compatibility layer (no break in playback by old players).


then in 12 (or 24, or 36 months), the time that new FFmpeg versions 
propagate everywhere (we also open tickets for other demuxers in order 
to get the support of such files), the default is changed to V_FFV1.


Sorry I don't know enough FFmpeg for doing the corresponding patch myself.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 1/2] swresample/resample: use uniform normalization

[Muhammad Faiz]

this gives better frequency response

Signed-off-by: Muhammad Faiz 
---
 libswresample/resample.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/libswresample/resample.c b/libswresample/resample.c
index 8e2f769..b0d14d1 100644
--- a/libswresample/resample.c
+++ b/libswresample/resample.c
@@ -149,6 +149,7 @@ static int build_filter(ResampleContext *c, void *filter, 
double factor, int tap
 double *tab = av_malloc_array(tap_count+1,  sizeof(*tab));
 double *sin_lut = av_malloc_array(ph_nb, sizeof(*sin_lut));
 const int center= (tap_count-1)/2;
+double norm = 0;
 int ret = AVERROR(ENOMEM);
 
 if (!tab || !sin_lut)
@@ -160,10 +161,9 @@ static int build_filter(ResampleContext *c, void *filter, 
double factor, int tap
 
 if (factor == 1.0) {
 for (ph = 0; ph < ph_nb; ph++)
-sin_lut[ph] = sin(M_PI * ph / phase_count);
+sin_lut[ph] = sin(M_PI * ph / phase_count) * (center & 1 ? 1 : -1);
 }
 for(ph = 0; ph < ph_nb; ph++) {
-double norm = 0;
 s = sin_lut[ph];
 for(i=0;i<=tap_count;i++) {
 x = M_PI * ((double)(i - center) - (double)ph / phase_count) * 
factor;
@@ -194,7 +194,7 @@ static int build_filter(ResampleContext *c, void *filter, 
double factor, int tap
 
 tab[i] = y;
 s = -s;
-if (i < tap_count)
+if (!ph && i < tap_count)
 norm += y;
 }
 
@@ -211,7 +211,7 @@ static int build_filter(ResampleContext *c, void *filter, 
double factor, int tap
 else {
 for (i = 1; i <= tap_count; i++)
 ((int16_t*)filter)[(phase_count-ph) * alloc + tap_count-i] 
=
-av_clip_int16(lrintf(tab[i] * scale / (norm - tab[0] + 
tab[tap_count])));
+av_clip_int16(lrintf(tab[i] * scale / norm));
 }
 break;
 case AV_SAMPLE_FMT_S32P:
@@ -225,7 +225,7 @@ static int build_filter(ResampleContext *c, void *filter, 
double factor, int tap
 else {
 for (i = 1; i <= tap_count; i++)
 ((int32_t*)filter)[(phase_count-ph) * alloc + tap_count-i] 
=
-av_clipl_int32(llrint(tab[i] * scale / (norm - tab[0] 
+ tab[tap_count])));
+av_clipl_int32(llrint(tab[i] * scale / norm));
 }
 break;
 case AV_SAMPLE_FMT_FLTP:
@@ -238,7 +238,7 @@ static int build_filter(ResampleContext *c, void *filter, 
double factor, int tap
 }
 else {
 for (i = 1; i <= tap_count; i++)
-((float*)filter)[(phase_count-ph) * alloc + tap_count-i] = 
tab[i] * scale / (norm - tab[0] + tab[tap_count]);
+((float*)filter)[(phase_count-ph) * alloc + tap_count-i] = 
tab[i] * scale / norm;
 }
 break;
 case AV_SAMPLE_FMT_DBLP:
@@ -251,7 +251,7 @@ static int build_filter(ResampleContext *c, void *filter, 
double factor, int tap
 }
 else {
 for (i = 1; i <= tap_count; i++)
-((double*)filter)[(phase_count-ph) * alloc + tap_count-i] 
= tab[i] * scale / (norm - tab[0] + tab[tap_count]);
+((double*)filter)[(phase_count-ph) * alloc + tap_count-i] 
= tab[i] * scale / norm;
 }
 break;
 }
-- 
2.9.3

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

[FFmpeg-devel] [PATCH 2/2] fate: update libswresample fate

[Muhammad Faiz]

on 'swresample/resample: use uniform normalization'
also update other fates that depend on resampling

Signed-off-by: Muhammad Faiz 
---
 tests/fate/libswresample.mak | 276 +--
 tests/ref/acodec/roqaudio|   2 +-
 tests/ref/acodec/s302m   |   6 +-
 tests/ref/lavf/dv_fmt|   8 +-
 tests/ref/lavf/gxf   |   8 +-
 tests/ref/lavf/mxf   |  12 +-
 6 files changed, 156 insertions(+), 156 deletions(-)

diff --git a/tests/fate/libswresample.mak b/tests/fate/libswresample.mak
index cc50693..f2967cd 100644
--- a/tests/fate/libswresample.mak
+++ b/tests/fate/libswresample.mak
@@ -26,34 +26,34 @@ endef
 #you can use this if you need to update it!
 #make -k  `make fate-list | grep swr` | egrep 'TEST|stddev' | tr '\n' '@' | 
sed 's#TEST *\([^@]*\)@stddev: *\([0-9.]*\)[^b@]*bytes: *\([0-9]*\) */ 
*\([0-9]*\)@#fate-\1: CMP_TARGET = \2@fate-\1: SIZE_TOLERANCE = \3 - \4@@#g' | 
tr '@' '\n'
 
-fate-swr-resample-dblp-2626-44100: CMP_TARGET = 1352.68
+fate-swr-resample-dblp-2626-44100: CMP_TARGET = 1352.69
 fate-swr-resample-dblp-2626-44100: SIZE_TOLERANCE = 31512 - 20480
 
-fate-swr-resample-dblp-2626-48000: CMP_TARGET = 1352.65
+fate-swr-resample-dblp-2626-48000: CMP_TARGET = 1352.66
 fate-swr-resample-dblp-2626-48000: SIZE_TOLERANCE = 31512 - 20480
 
-fate-swr-resample-dblp-2626-8000: CMP_TARGET = 1353.08
+fate-swr-resample-dblp-2626-8000: CMP_TARGET = 1353.09
 fate-swr-resample-dblp-2626-8000: SIZE_TOLERANCE = 31512 - 20482
 
-fate-swr-resample-dblp-2626-96000: CMP_TARGET = 1352.67
+fate-swr-resample-dblp-2626-96000: CMP_TARGET = 1352.68
 fate-swr-resample-dblp-2626-96000: SIZE_TOLERANCE = 31512 - 20480
 
 fate-swr-resample-dblp-44100-2626: CMP_TARGET = 185.82
 fate-swr-resample-dblp-44100-2626: SIZE_TOLERANCE = 529200 - 20490
 
-fate-swr-resample-dblp-44100-48000: CMP_TARGET = 9.70
+fate-swr-resample-dblp-44100-48000: CMP_TARGET = 9.69
 fate-swr-resample-dblp-44100-48000: SIZE_TOLERANCE = 529200 - 20482
 
 fate-swr-resample-dblp-44100-8000: CMP_TARGET = 75.45
 fate-swr-resample-dblp-44100-8000: SIZE_TOLERANCE = 529200 - 20486
 
-fate-swr-resample-dblp-44100-96000: CMP_TARGET = 11.47
+fate-swr-resample-dblp-44100-96000: CMP_TARGET = 11.46
 fate-swr-resample-dblp-44100-96000: SIZE_TOLERANCE = 529200 - 20482
 
 fate-swr-resample-dblp-48000-2626: CMP_TARGET = 456.51
 fate-swr-resample-dblp-48000-2626: SIZE_TOLERANCE = 576000 - 20510
 
-fate-swr-resample-dblp-48000-44100: CMP_TARGET = 1.02
+fate-swr-resample-dblp-48000-44100: CMP_TARGET = 1.00
 fate-swr-resample-dblp-48000-44100: SIZE_TOLERANCE = 576000 - 20480
 
 fate-swr-resample-dblp-48000-8000: CMP_TARGET = 62.38
@@ -77,43 +77,43 @@ fate-swr-resample-dblp-8000-96000: SIZE_TOLERANCE = 96000 - 
20480
 fate-swr-resample-dblp-96000-2626: CMP_TARGET = 675.08
 fate-swr-resample-dblp-96000-2626: SIZE_TOLERANCE = 1152000 - 20474
 
-fate-swr-resample-dblp-96000-44100: CMP_TARGET = 1.45
+fate-swr-resample-dblp-96000-44100: CMP_TARGET = 1.44
 fate-swr-resample-dblp-96000-44100: SIZE_TOLERANCE = 1152000 - 20480
 
-fate-swr-resample-dblp-96000-48000: CMP_TARGET = 1.00
+fate-swr-resample-dblp-96000-48000: CMP_TARGET = 0.99
 fate-swr-resample-dblp-96000-48000: SIZE_TOLERANCE = 1152000 - 20480
 
 fate-swr-resample-dblp-96000-8000: CMP_TARGET = 58.57
 fate-swr-resample-dblp-96000-8000: SIZE_TOLERANCE = 1152000 - 20496
 
-fate-swr-resample-fltp-2626-44100: CMP_TARGET = 1352.68
+fate-swr-resample-fltp-2626-44100: CMP_TARGET = 1352.69
 fate-swr-resample-fltp-2626-44100: SIZE_TOLERANCE = 31512 - 20480
 
-fate-swr-resample-fltp-2626-48000: CMP_TARGET = 1352.65
+fate-swr-resample-fltp-2626-48000: CMP_TARGET = 1352.66
 fate-swr-resample-fltp-2626-48000: SIZE_TOLERANCE = 31512 - 20480
 
-fate-swr-resample-fltp-2626-8000: CMP_TARGET = 1353.08
+fate-swr-resample-fltp-2626-8000: CMP_TARGET = 1353.09
 fate-swr-resample-fltp-2626-8000: SIZE_TOLERANCE = 31512 - 20482
 
-fate-swr-resample-fltp-2626-96000: CMP_TARGET = 1352.67
+fate-swr-resample-fltp-2626-96000: CMP_TARGET = 1352.68
 fate-swr-resample-fltp-2626-96000: SIZE_TOLERANCE = 31512 - 20480
 
 fate-swr-resample-fltp-44100-2626: CMP_TARGET = 185.82
 fate-swr-resample-fltp-44100-2626: SIZE_TOLERANCE = 529200 - 20490
 
-fate-swr-resample-fltp-44100-48000: CMP_TARGET = 9.70
+fate-swr-resample-fltp-44100-48000: CMP_TARGET = 9.69
 fate-swr-resample-fltp-44100-48000: SIZE_TOLERANCE = 529200 - 20482
 
 fate-swr-resample-fltp-44100-8000: CMP_TARGET = 75.45
 fate-swr-resample-fltp-44100-8000: SIZE_TOLERANCE = 529200 - 20486
 
-fate-swr-resample-fltp-44100-96000: CMP_TARGET = 11.47
+fate-swr-resample-fltp-44100-96000: CMP_TARGET = 11.46
 fate-swr-resample-fltp-44100-96000: SIZE_TOLERANCE = 529200 - 20482
 
 fate-swr-resample-fltp-48000-2626: CMP_TARGET = 456.51
 fate-swr-resample-fltp-48000-2626: SIZE_TOLERANCE = 576000 - 20510
 
-fate-swr-resample-fltp-48000-44100: CMP_TARGET = 1.02
+fate-swr-resample-fltp-48000-44100: CMP_TARGET = 1.00
 fate-swr-resample-fltp-48000-44100: SIZE_TOLERANCE = 

Re: [FFmpeg-devel] [PATCH 1/2] swresample/resample: use uniform normalization

[Muhammad Faiz]

On Wed, Mar 1, 2017 at 9:24 PM, Muhammad Faiz  wrote:
> this gives better frequency response
>
> Signed-off-by: Muhammad Faiz 
> ---
>  libswresample/resample.c | 14 +++---
>  1 file changed, 7 insertions(+), 7 deletions(-)
>

Test case, from 44100 to 705600 (16*44100)
ffmpeg -filter_complex "aevalsrc='if(n-300,0,1)',
aresample=osr=705600:filter_size=16" -f f32le - | ./freq-resp >
freq-resp.txt

#include 
#include 
#include 

#define BITS 16
#define OSR 705600
#define ISR 44100
#define LENGTH (1 << BITS)

int main(int argc, char **argv)
{
static FFTComplex buf[LENGTH];
int k;
FFTContext *fft = av_fft_init(BITS, 0);

for (k = 0; k < LENGTH; k++)
fread(buf+k, sizeof(float), 1, stdin);

av_fft_permute(fft, buf);
av_fft_calc(fft, buf);

for (k = 0; k <= LENGTH/2; k++)
printf("%.17f %.17f\n", (double) k * OSR / LENGTH, 20.0 * log10(hypot(buf[k].re, buf[k].im) * ISR / OSR));

return 0;
}
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavf/matroska: Support codec id V_FFV1 for FFV1.

[wm4]

On Wed, 1 Mar 2017 15:00:27 +0100
Jerome Martinez  wrote:

> Le 01/03/2017 à 09:43, Carl Eugen Hoyos a écrit :
> > 2017-03-01 4:40 GMT+01:00 Michael Niedermayer :  
> >> On Tue, Feb 28, 2017 at 08:45:44PM +0100, Carl Eugen Hoyos wrote:  
> >>> Hi!
> >>>
> >>> Attached patch fixes ticket #6206 here.
> >>>
> >>> Please comment, Carl Eugen  
> >> previous ffmpeg versions dont play these files  
> > What do you suggest?  
> 
> My suggestion:
> - support by the demuxer
> - for the muxer, support only if a specific explicit option is set, 
> default stays AVI compatibility layer (no break in playback by old players).

Sounds like a good idea.

> then in 12 (or 24, or 36 months), the time that new FFmpeg versions 
> propagate everywhere (we also open tickets for other demuxers in order 
> to get the support of such files), the default is changed to V_FFV1.

There are other demuxers than the FFmpeg one. Actually I suspect most
trouble will be with ancient mkvmerge versions floating around and that
everyone seems to want to use.

> Sorry I don't know enough FFmpeg for doing the corresponding patch myself.
> ___
> 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 2/2] fate: update libswresample fate

[James Almer]

On 3/1/2017 11:25 AM, Muhammad Faiz wrote:
> on 'swresample/resample: use uniform normalization'
> also update other fates that depend on resampling
> 
> Signed-off-by: Muhammad Faiz 
> ---
>  tests/fate/libswresample.mak | 276 
> +--
>  tests/ref/acodec/roqaudio|   2 +-
>  tests/ref/acodec/s302m   |   6 +-
>  tests/ref/lavf/dv_fmt|   8 +-
>  tests/ref/lavf/gxf   |   8 +-
>  tests/ref/lavf/mxf   |  12 +-
>  6 files changed, 156 insertions(+), 156 deletions(-)

If the previous patch generates the changes reflected here, then the two
should be squashed and pushed as a single commit. Purposely breaking FATE
should be avoided for the sake of easier bisecting.

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

[FFmpeg-devel] [PATCH] swresample/resample: use uniform normalization

[Muhammad Faiz]

this gives better frequency response

update swresample fate and other fates
that depend on resampling

Signed-off-by: Muhammad Faiz 
---
 libswresample/resample.c |  14 +--
 tests/fate/libswresample.mak | 276 +--
 tests/ref/acodec/roqaudio|   2 +-
 tests/ref/acodec/s302m   |   6 +-
 tests/ref/lavf/dv_fmt|   8 +-
 tests/ref/lavf/gxf   |   8 +-
 tests/ref/lavf/mxf   |  12 +-
 7 files changed, 163 insertions(+), 163 deletions(-)

diff --git a/libswresample/resample.c b/libswresample/resample.c
index 8e2f769..b0d14d1 100644
--- a/libswresample/resample.c
+++ b/libswresample/resample.c
@@ -149,6 +149,7 @@ static int build_filter(ResampleContext *c, void *filter, 
double factor, int tap
 double *tab = av_malloc_array(tap_count+1,  sizeof(*tab));
 double *sin_lut = av_malloc_array(ph_nb, sizeof(*sin_lut));
 const int center= (tap_count-1)/2;
+double norm = 0;
 int ret = AVERROR(ENOMEM);
 
 if (!tab || !sin_lut)
@@ -160,10 +161,9 @@ static int build_filter(ResampleContext *c, void *filter, 
double factor, int tap
 
 if (factor == 1.0) {
 for (ph = 0; ph < ph_nb; ph++)
-sin_lut[ph] = sin(M_PI * ph / phase_count);
+sin_lut[ph] = sin(M_PI * ph / phase_count) * (center & 1 ? 1 : -1);
 }
 for(ph = 0; ph < ph_nb; ph++) {
-double norm = 0;
 s = sin_lut[ph];
 for(i=0;i<=tap_count;i++) {
 x = M_PI * ((double)(i - center) - (double)ph / phase_count) * 
factor;
@@ -194,7 +194,7 @@ static int build_filter(ResampleContext *c, void *filter, 
double factor, int tap
 
 tab[i] = y;
 s = -s;
-if (i < tap_count)
+if (!ph && i < tap_count)
 norm += y;
 }
 
@@ -211,7 +211,7 @@ static int build_filter(ResampleContext *c, void *filter, 
double factor, int tap
 else {
 for (i = 1; i <= tap_count; i++)
 ((int16_t*)filter)[(phase_count-ph) * alloc + tap_count-i] 
=
-av_clip_int16(lrintf(tab[i] * scale / (norm - tab[0] + 
tab[tap_count])));
+av_clip_int16(lrintf(tab[i] * scale / norm));
 }
 break;
 case AV_SAMPLE_FMT_S32P:
@@ -225,7 +225,7 @@ static int build_filter(ResampleContext *c, void *filter, 
double factor, int tap
 else {
 for (i = 1; i <= tap_count; i++)
 ((int32_t*)filter)[(phase_count-ph) * alloc + tap_count-i] 
=
-av_clipl_int32(llrint(tab[i] * scale / (norm - tab[0] 
+ tab[tap_count])));
+av_clipl_int32(llrint(tab[i] * scale / norm));
 }
 break;
 case AV_SAMPLE_FMT_FLTP:
@@ -238,7 +238,7 @@ static int build_filter(ResampleContext *c, void *filter, 
double factor, int tap
 }
 else {
 for (i = 1; i <= tap_count; i++)
-((float*)filter)[(phase_count-ph) * alloc + tap_count-i] = 
tab[i] * scale / (norm - tab[0] + tab[tap_count]);
+((float*)filter)[(phase_count-ph) * alloc + tap_count-i] = 
tab[i] * scale / norm;
 }
 break;
 case AV_SAMPLE_FMT_DBLP:
@@ -251,7 +251,7 @@ static int build_filter(ResampleContext *c, void *filter, 
double factor, int tap
 }
 else {
 for (i = 1; i <= tap_count; i++)
-((double*)filter)[(phase_count-ph) * alloc + tap_count-i] 
= tab[i] * scale / (norm - tab[0] + tab[tap_count]);
+((double*)filter)[(phase_count-ph) * alloc + tap_count-i] 
= tab[i] * scale / norm;
 }
 break;
 }
diff --git a/tests/fate/libswresample.mak b/tests/fate/libswresample.mak
index cc50693..f2967cd 100644
--- a/tests/fate/libswresample.mak
+++ b/tests/fate/libswresample.mak
@@ -26,34 +26,34 @@ endef
 #you can use this if you need to update it!
 #make -k  `make fate-list | grep swr` | egrep 'TEST|stddev' | tr '\n' '@' | 
sed 's#TEST *\([^@]*\)@stddev: *\([0-9.]*\)[^b@]*bytes: *\([0-9]*\) */ 
*\([0-9]*\)@#fate-\1: CMP_TARGET = \2@fate-\1: SIZE_TOLERANCE = \3 - \4@@#g' | 
tr '@' '\n'
 
-fate-swr-resample-dblp-2626-44100: CMP_TARGET = 1352.68
+fate-swr-resample-dblp-2626-44100: CMP_TARGET = 1352.69
 fate-swr-resample-dblp-2626-44100: SIZE_TOLERANCE = 31512 - 20480
 
-fate-swr-resample-dblp-2626-48000: CMP_TARGET = 1352.65
+fate-swr-resample-dblp-2626-48000: CMP_TARGET = 1352.66
 fate-swr-resample-dblp-2626-48000: SIZE_TOLERANCE = 31512 - 20480
 
-fate-swr-resample-dblp-2626-8000: CMP_TARGET = 1353.08
+fate-swr-resample-dblp-2626-8000: CMP_TARGET = 1353.09
 fate-swr-resample-dblp-2626-8000: SIZE_TOLERANCE = 31512 - 20482
 
-fate-swr-resample-dblp-2626-96000: CMP_TARGET = 1352.67
+fate-swr-resample-dblp-2626-96000: CMP_TARGET = 1352.68
 fate-swr-resample-dblp-2626-96000: SIZE_TOLERANCE = 31512 - 20480
 
 fate-swr-resample-

Re: [FFmpeg-devel] [PATCH 2/2] fate: update libswresample fate

[Muhammad Faiz]

On Wed, Mar 1, 2017 at 10:15 PM, James Almer  wrote:
> On 3/1/2017 11:25 AM, Muhammad Faiz wrote:
>> on 'swresample/resample: use uniform normalization'
>> also update other fates that depend on resampling
>>
>> Signed-off-by: Muhammad Faiz 
>> ---
>>  tests/fate/libswresample.mak | 276 
>> +--
>>  tests/ref/acodec/roqaudio|   2 +-
>>  tests/ref/acodec/s302m   |   6 +-
>>  tests/ref/lavf/dv_fmt|   8 +-
>>  tests/ref/lavf/gxf   |   8 +-
>>  tests/ref/lavf/mxf   |  12 +-
>>  6 files changed, 156 insertions(+), 156 deletions(-)
>
> If the previous patch generates the changes reflected here, then the two
> should be squashed and pushed as a single commit. Purposely breaking FATE
> should be avoided for the sake of easier bisecting.
>

OK, will post squashed patch
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavf/matroska: Support codec id V_FFV1 for FFV1.

[Jerome Martinez]

Le 01/03/2017 à 15:51, wm4 a écrit :

On Wed, 1 Mar 2017 15:00:27 +0100
Jerome Martinez  wrote:

[...]

then in 12 (or 24, or 36 months), the time that new FFmpeg versions
propagate everywhere (we also open tickets for other demuxers in order
to get the support of such files), the default is changed to V_FFV1.

There are other demuxers than the FFmpeg one. Actually I suspect most
trouble will be with ancient mkvmerge versions floating around and that
everyone seems to want to use.


I think the people loving ancient mkvmerge versions are not the ones 
using lossless formats, so it is not blocking from my point of view.

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

Re: [FFmpeg-devel] [PATCH]lavf/matroska: Support codec id V_FFV1 for FFV1.

[James Almer]

On 2/28/2017 4:45 PM, Carl Eugen Hoyos wrote:
> Hi!
> 
> Attached patch fixes ticket #6206 here.
> 
> Please comment, Carl Eugen

This doesn't consider the CodecPrivate contents for FFV1 v3 and above. It's
only valid for v1 and v2.

> 
> 
> 0001-lavf-matroska-Support-new-codec-id-V_FFV1-for-FFV1.patch
> 
> 
> From 10caa3898fa76f5a76dce7e3795a7a0d475870c1 Mon Sep 17 00:00:00 2001
> From: Carl Eugen Hoyos 
> Date: Tue, 28 Feb 2017 20:36:12 +0100
> Subject: [PATCH] lavf/matroska: Support new codec id V_FFV1 for FFV1.
> 
> Fixes ticket #6206.
> ---
>  libavformat/matroska.c |1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/libavformat/matroska.c b/libavformat/matroska.c
> index fda96fb..7905fd1 100644
> --- a/libavformat/matroska.c
> +++ b/libavformat/matroska.c
> @@ -77,6 +77,7 @@ const CodecTags ff_mkv_codec_tags[]={
>  {"S_HDMV/TEXTST", AV_CODEC_ID_HDMV_TEXT_SUBTITLE},
>  
>  {"V_DIRAC"  , AV_CODEC_ID_DIRAC},
> +{"V_FFV1"   , AV_CODEC_ID_FFV1},
>  {"V_MJPEG"  , AV_CODEC_ID_MJPEG},
>  {"V_MPEG1"  , AV_CODEC_ID_MPEG1VIDEO},
>  {"V_MPEG2"  , AV_CODEC_ID_MPEG2VIDEO},
> -- 1.7.10.4
> 
> 
> 
> ___
> 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 3/3] avcodec/interplayvideo: Fix timeout from lack of bitstream end check

[Michael Niedermayer]

Fixes: 697/clusterfuzz-testcase-6111250582863872

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavcodec/interplayvideo.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/libavcodec/interplayvideo.c b/libavcodec/interplayvideo.c
index 8d2f3ab48c..df3314d4b7 100644
--- a/libavcodec/interplayvideo.c
+++ b/libavcodec/interplayvideo.c
@@ -928,6 +928,8 @@ static void ipvideo_decode_opcodes(IpvideoContext *s, 
AVFrame *frame)
 init_get_bits(&gb, s->decoding_map, s->decoding_map_size * 8);
 for (y = 0; y < s->avctx->height; y += 8) {
 for (x = 0; x < s->avctx->width; x += 8) {
+if (get_bits_left(&gb) < 4)
+return;
 opcode = get_bits(&gb, 4);
 
 ff_tlog(s->avctx,
-- 
2.11.0

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

[FFmpeg-devel] [PATCH 1/3] avcodec/mjpegdec: Fix runtime error: left shift of negative value -511

[Michael Niedermayer]

Fixes: 693/clusterfuzz-testcase-6109776066904064

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavcodec/mjpegdec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
index 69469c5229..2b5adfc61b 100644
--- a/libavcodec/mjpegdec.c
+++ b/libavcodec/mjpegdec.c
@@ -1157,7 +1157,7 @@ static int ljpeg_decode_yuv_scan(MJpegDecodeContext *s, 
int predictor,
 if (s->interlaced && s->bottom_field)
 ptr16 += linesize >> 1;
 pred &= mask;
-*ptr16= pred + (dc << point_transform);
+*ptr16= pred + ((unsigned)dc << point_transform);
 }
 if (++x == h) {
 x = 0;
-- 
2.11.0

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

[FFmpeg-devel] [PATCH 2/3] avcodec/mpegaudiodec_template: Fix runtime error: signed integer overflow: 2053224902 + 2053224902 cannot be represented in type 'int'

[Michael Niedermayer]

Fixes: 696/clusterfuzz-testcase-5853632270434304

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavcodec/mpegaudiodec_template.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/mpegaudiodec_template.c 
b/libavcodec/mpegaudiodec_template.c
index a389318a2a..a3729a9e29 100644
--- a/libavcodec/mpegaudiodec_template.c
+++ b/libavcodec/mpegaudiodec_template.c
@@ -457,7 +457,7 @@ static av_cold int decode_init(AVCodecContext * avctx)
 
 /* 12 points IMDCT. We compute it "by hand" by factorizing obvious
cases. */
-static void imdct12(INTFLOAT *out, INTFLOAT *in)
+static void imdct12(INTFLOAT *out, SUINTFLOAT *in)
 {
 SUINTFLOAT in0, in1, in2, in3, in4, in5, t1, t2;
 
-- 
2.11.0

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

Re: [FFmpeg-devel] [PATCH 1/3] avformat/oggdec: remove unused parameter of ogg_restore()

[Michael Niedermayer]

On Tue, Feb 28, 2017 at 03:31:10PM +0100, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer 
> ---
>  libavformat/oggdec.c | 13 +
>  1 file changed, 5 insertions(+), 8 deletions(-)

patchset applied

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

Freedom in capitalist society always remains about the same as it was in
ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin


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

Re: [FFmpeg-devel] [PATCH]lavf/cavsvideodec: Return a lower score if only one frame was found

[Michael Niedermayer]

On Wed, Mar 01, 2017 at 09:40:08AM +0100, Carl Eugen Hoyos wrote:
> Hi!
> 
> Attached patch fixes ticket #6208.
> 
> Please comment, Carl Eugen

breaks tickets/3400/akiyo_cif.avs

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Many things microsoft did are stupid, but not doing something just because
microsoft did it is even more stupid. If everything ms did were stupid they
would be bankrupt already.


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

[FFmpeg-devel] [PATCH] omx: Add support for specifying H.264 profile [v5]

[Takayuki 'January June' Suwa]

From: Takayuki 'January June' Suwa 

This adds "-profile[:v] profile_name"-style option.
---
 libavcodec/omx.c | 33 +
 1 file changed, 33 insertions(+)

diff --git a/libavcodec/omx.c b/libavcodec/omx.c
index 16df50e..c0d64e2 100644
--- a/libavcodec/omx.c
+++ b/libavcodec/omx.c
@@ -226,6 +226,7 @@ typedef struct OMXCodecContext {
 int output_buf_size;
 
 int input_zerocopy;
+int profile;
 } OMXCodecContext;
 
 static void append_buffer(pthread_mutex_t *mutex, pthread_cond_t *cond,
@@ -523,6 +524,34 @@ static av_cold int omx_component_init(AVCodecContext 
*avctx, const char *role)
 CHECK(err);
 avc.nBFrames = 0;
 avc.nPFrames = avctx->gop_size - 1;
+switch (s->profile) {
+case FF_PROFILE_H264_BASELINE:
+avc.eProfile = OMX_VIDEO_AVCProfileBaseline;
+break;
+case FF_PROFILE_H264_MAIN:
+avc.eProfile = OMX_VIDEO_AVCProfileMain;
+break;
+case FF_PROFILE_H264_HIGH:
+avc.eProfile = OMX_VIDEO_AVCProfileHigh;
+break;
+default:
+break;
+case FF_PROFILE_UNKNOWN:
+switch (avctx->profile) {
+case FF_PROFILE_H264_BASELINE:
+avc.eProfile = OMX_VIDEO_AVCProfileBaseline;
+break;
+case FF_PROFILE_H264_MAIN:
+avc.eProfile = OMX_VIDEO_AVCProfileMain;
+break;
+case FF_PROFILE_H264_HIGH:
+avc.eProfile = OMX_VIDEO_AVCProfileHigh;
+break;
+default:
+break;
+}
+break;
+}
 err = OMX_SetParameter(s->handle, OMX_IndexParamVideoAvc, &avc);
 CHECK(err);
 }
@@ -884,6 +913,10 @@ static const AVOption options[] = {
 { "omx_libname", "OpenMAX library name", OFFSET(libname), 
AV_OPT_TYPE_STRING, { 0 }, 0, 0, VDE },
 { "omx_libprefix", "OpenMAX library prefix", OFFSET(libprefix), 
AV_OPT_TYPE_STRING, { 0 }, 0, 0, VDE },
 { "zerocopy", "Try to avoid copying input frames if possible", 
OFFSET(input_zerocopy), AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 1, VE },
+{ "profile",  "Set the encoding profile", OFFSET(profile), 
AV_OPT_TYPE_INT,   { .i64 = FF_PROFILE_UNKNOWN },   FF_PROFILE_UNKNOWN, 
FF_PROFILE_H264_HIGH, VE, "profile" },
+{ "baseline", "", 0,   
AV_OPT_TYPE_CONST, { .i64 = FF_PROFILE_H264_BASELINE }, 0, 0, VE, "profile" },
+{ "main", "", 0,   
AV_OPT_TYPE_CONST, { .i64 = FF_PROFILE_H264_MAIN }, 0, 0, VE, "profile" },
+{ "high", "", 0,   
AV_OPT_TYPE_CONST, { .i64 = FF_PROFILE_H264_HIGH }, 0, 0, VE, "profile" },
 { NULL }
 };
 
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavc/internal: Constify AVPacket* in AVCodecInternal.

[Carl Eugen Hoyos]

2017-03-01 13:04 GMT+01:00 Michael Niedermayer :
> On Sun, Feb 26, 2017 at 12:38:14PM +0100, Carl Eugen Hoyos wrote:
>> Hi!
>>
>> Attached patch fixes another warning when compiling libavcodec/utils.o.
>>
>> Please comment, Carl Eugen
>
> if it doesnt produce any new warnings elsewere then its probably ok

It produces additional warnings without one of the two patches attached
to "lavc/avpacket: Make pkt parameter of av_packet_get_side_data() const."
With both patches applied, all warnings disappear.

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

Re: [FFmpeg-devel] [PATCH]lavf/cavsvideodec: Return a lower score if only one frame was found

[Carl Eugen Hoyos]

2017-03-01 19:01 GMT+01:00 Michael Niedermayer :
> On Wed, Mar 01, 2017 at 09:40:08AM +0100, Carl Eugen Hoyos wrote:
>> Hi!
>>
>> Attached patch fixes ticket #6208.
>>
>> Please comment, Carl Eugen
>
> breaks tickets/3400/akiyo_cif.avs

I feared so.

Not sure I can fix this, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavf/matroska: Support codec id V_FFV1 for FFV1.

[Carl Eugen Hoyos]

2017-03-01 17:56 GMT+01:00 James Almer :
> On 2/28/2017 4:45 PM, Carl Eugen Hoyos wrote:
>> Hi!
>>
>> Attached patch fixes ticket #6206 here.
>>
>> Please comment, Carl Eugen
>
> This doesn't consider the CodecPrivate contents for FFV1 v3
> and above. It's only valid for v1 and v2.

Is this comment meant for the muxer or the demuxer part?

How can I reproduce the issue you see?
For me, everything works as specified for default strictness.

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

[FFmpeg-devel] [PATCH]lavf/matroska: Support QDMC

[Carl Eugen Hoyos]

Hi!

Attached patch allows muxing and demuxing of QDMC in mkv.

Please comment, Carl Eugen
From 8d383886e19dbfd362497144fc9610ecdcedc144 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Wed, 1 Mar 2017 23:22:40 +0100
Subject: [PATCH] lavf/matroska: Support QDMC.

---
 libavformat/matroska.c|1 +
 libavformat/matroskaenc.c |1 +
 2 files changed, 2 insertions(+)

diff --git a/libavformat/matroska.c b/libavformat/matroska.c
index fda96fb..248d7b5 100644
--- a/libavformat/matroska.c
+++ b/libavformat/matroska.c
@@ -48,6 +48,7 @@ const CodecTags ff_mkv_codec_tags[]={
 {"A_PCM/INT/LIT", AV_CODEC_ID_PCM_S24LE},
 {"A_PCM/INT/LIT", AV_CODEC_ID_PCM_S32LE},
 {"A_PCM/INT/LIT", AV_CODEC_ID_PCM_U8},
+{"A_QUICKTIME/QDMC" , AV_CODEC_ID_QDMC},
 {"A_QUICKTIME/QDM2" , AV_CODEC_ID_QDM2},
 {"A_REAL/14_4"  , AV_CODEC_ID_RA_144},
 {"A_REAL/28_8"  , AV_CODEC_ID_RA_288},
diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
index 7cb8893..21f6e08 100644
--- a/libavformat/matroskaenc.c
+++ b/libavformat/matroskaenc.c
@@ -2528,6 +2528,7 @@ static const AVCodecTag additional_audio_tags[] = {
 { AV_CODEC_ID_PCM_S16BE, 0x },
 { AV_CODEC_ID_PCM_S24BE, 0x },
 { AV_CODEC_ID_PCM_S32BE, 0x },
+{ AV_CODEC_ID_QDMC,  0x },
 { AV_CODEC_ID_QDM2,  0x },
 { AV_CODEC_ID_RA_144,0x },
 { AV_CODEC_ID_RA_288,0x },
-- 
1.7.10.4

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

[FFmpeg-devel] [PATCH]lavc/bitstream_filter: Make a cast explicit

[Carl Eugen Hoyos]

Hi!

Attached patch silences one of three warnings when compiling 
bitstream_filter.o, I suspect this cast is necessary.

Please comment, Carl Eugen
From 15963817149fd4249f7812b42566eaf23afac6ce Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Wed, 1 Mar 2017 23:35:14 +0100
Subject: [PATCH] lavc/bitstream_filter: Make a cast explicit.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Fixes the following gcc warning:
libavcodec/bitstream_filter.c:133:14: warning: assignment discards ‘const’ 
qualifier from pointer target type
---
 libavcodec/bitstream_filter.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/bitstream_filter.c b/libavcodec/bitstream_filter.c
index 02878e3..0b19fe3 100644
--- a/libavcodec/bitstream_filter.c
+++ b/libavcodec/bitstream_filter.c
@@ -130,7 +130,7 @@ int av_bitstream_filter_filter(AVBitStreamFilterContext 
*bsfc,
 return ret;
 }
 
-pkt.data = buf;
+pkt.data = (uint8_t *)buf;
 pkt.size = buf_size;
 
 ret = av_bsf_send_packet(priv->ctx, &pkt);
-- 
1.7.10.4

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

Re: [FFmpeg-devel] [PATCH]lavf/matroska: Support codec id V_FFV1 for FFV1.

[Carl Eugen Hoyos]

2017-03-01 13:07 GMT+01:00 Michael Niedermayer :
> On Wed, Mar 01, 2017 at 09:43:57AM +0100, Carl Eugen Hoyos wrote:
>> 2017-03-01 4:40 GMT+01:00 Michael Niedermayer :
>> > On Tue, Feb 28, 2017 at 08:45:44PM +0100, Carl Eugen Hoyos wrote:
>> >> Hi!
>> >>
>> >> Attached patch fixes ticket #6206 here.
>> >>
>> >> Please comment, Carl Eugen
>> >
>> > previous ffmpeg versions dont play these files
>>
>> What do you suggest?
>
> support this at the demuxer side, backport such support then
> wait till its supported widely before switching the default in the
> muxer

Agree, new patch attached.

Thank you, Carl Eugen
From 5b50e8409463b746e38b35f7ca82c6b54b3be9ee Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Wed, 1 Mar 2017 23:40:35 +0100
Subject: [PATCH] lavf/matroska: Support codec ID V_FFV1 for demuxing.

Fixes ticket #6206.
---
 libavformat/matroska.c|1 +
 libavformat/matroskaenc.c |2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/libavformat/matroska.c b/libavformat/matroska.c
index fda96fb..7905fd1 100644
--- a/libavformat/matroska.c
+++ b/libavformat/matroska.c
@@ -77,6 +77,7 @@ const CodecTags ff_mkv_codec_tags[]={
 {"S_HDMV/TEXTST", AV_CODEC_ID_HDMV_TEXT_SUBTITLE},
 
 {"V_DIRAC"  , AV_CODEC_ID_DIRAC},
+{"V_FFV1"   , AV_CODEC_ID_FFV1},
 {"V_MJPEG"  , AV_CODEC_ID_MJPEG},
 {"V_MPEG1"  , AV_CODEC_ID_MPEG1VIDEO},
 {"V_MPEG2"  , AV_CODEC_ID_MPEG2VIDEO},
diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
index 7cb8893..1622b44 100644
--- a/libavformat/matroskaenc.c
+++ b/libavformat/matroskaenc.c
@@ -1138,7 +1138,7 @@ static int mkv_write_track(AVFormatContext *s, MatroskaMuxContext *mkv,
 // if none are found, use AVI codes
 if (par->codec_id != AV_CODEC_ID_RAWVIDEO || par->codec_tag) {
 for (j = 0; ff_mkv_codec_tags[j].id != AV_CODEC_ID_NONE; j++) {
-if (ff_mkv_codec_tags[j].id == par->codec_id) {
+if (ff_mkv_codec_tags[j].id == par->codec_id && par->codec_id != AV_CODEC_ID_FFV1) {
 put_ebml_string(pb, MATROSKA_ID_CODECID, ff_mkv_codec_tags[j].str);
 native_id = 1;
 break;
-- 
1.7.10.4

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

[FFmpeg-devel] libavcodec/psd : add support for rgb/gray float

[Martin Vignali]

Hello,

In attach patch for decoding float data (rgb/gray only) inside psd
Like in the openexr decoder, float data is convert to uint16
A gamma conversion can be apply before uint16 conversion (with an option)

the function : static inline uint16_t psd_flt2uint(uint32_t v)
is a copy/paste of exr_flt_uint of the exr decoder.
Probably need to be move somewhere (but i don't know the best place for that)

Sample can be found here :
https://we.tl/85kvceapTL


Comments welcome

Martin


0001-libavcodec-psd-add-support-for-rgb-gray-float.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH]lavc/sheervideo: Fix Y prediction for interlaced frames with alpha

[Carl Eugen Hoyos]

Hi!

Attached patch fixes ticket #6210 visually.

Please review, Carl Eugen
From 305b1916d99465896abbd1fbf401c6e4fba062a5 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Wed, 1 Mar 2017 23:45:10 +0100
Subject: [PATCH] lavc/sheervideo: Fix Y prediction for interlaced frames with
 transparency.

Based on 260de8a2 by Paul B Mahol.
Fixes ticket #6210.
---
 libavcodec/sheervideo.c |6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/libavcodec/sheervideo.c b/libavcodec/sheervideo.c
index e8f008b..9d2da7f 100644
--- a/libavcodec/sheervideo.c
+++ b/libavcodec/sheervideo.c
@@ -2185,7 +2185,7 @@ static void decode_aybri(AVCodecContext *avctx, AVFrame 
*p, GetBitContext *gb)
 dst_v[x] = get_bits(gb, 8);
 }
 } else {
-int pred[4] = { 125, 125, -128, -128 };
+int pred[4] = { 125, s->alt ? 125 : -146, -128, -128 };
 
 for (x = 0; x < avctx->width; x++) {
 int a, y, u, v;
@@ -2263,7 +2263,7 @@ static void decode_aybr(AVCodecContext *avctx, AVFrame 
*p, GetBitContext *gb)
 dst_v[x] = get_bits(gb, 8);
 }
 } else {
-int pred[4] = { 125, 125, -128, -128 };
+int pred[4] = { 125, s->alt ? 125 : -146, -128, -128 };
 
 for (x = 0; x < avctx->width; x++) {
 int a, y, u, v;
@@ -2959,6 +2959,7 @@ static int decode_frame(AVCodecContext *avctx,
 }
 break;
 case MKTAG('A', 'Y', 'B', 'R'):
+s->alt = 1;
 case MKTAG('A', 'Y', 'b', 'R'):
 avctx->pix_fmt = AV_PIX_FMT_YUVA444P;
 s->decode_frame = decode_aybr;
@@ -2968,6 +2969,7 @@ static int decode_frame(AVCodecContext *avctx,
 }
 break;
 case MKTAG('A', 'y', 'B', 'R'):
+s->alt = 1;
 case MKTAG('A', 'y', 'b', 'R'):
 avctx->pix_fmt = AV_PIX_FMT_YUVA444P;
 s->decode_frame = decode_aybri;
-- 
1.7.10.4

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

Re: [FFmpeg-devel] [PATCH] lavf/dashenc: update bitrates on dash_write_trailer

[Przemysław Sobala]

23 lut 2017 21:39 "Przemysław Sobala" 
napisał(a):

On Wednesday, February 22, 2017, Przemysław Sobala <
przemyslaw.sob...@gmail.com> wrote:

> From: Przemysław Sobala 
>
> Provides a way to change bandwidth (bitrate) parameter after CRF H.264
> encoding (details: http://ffmpeg.org/pipermail/li
> bav-user/2017-February/010141.html)
>
> Signed-off-by: Przemysław Sobala 
> ---
>  libavformat/dashenc.c | 42 ++
>  1 file changed, 30 insertions(+), 12 deletions(-)
>
> diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
> index fa56505..011d2ea 100644
> --- a/libavformat/dashenc.c
> +++ b/libavformat/dashenc.c
> @@ -561,6 +561,30 @@ static int write_manifest(AVFormatContext *s, int
> final)
>  return 0;
>  }
>
> +static int set_bitrate(AVFormatContext *s)
> +{
> +DASHContext *c = s->priv_data;
> +int i;
> +
> +for (i = 0; i < s->nb_streams; i++) {
> +OutputStream *os = &c->streams[i];
> +
> +os->bit_rate = s->streams[i]->codecpar->bit_rate;
> +if (os->bit_rate) {
> +snprintf(os->bandwidth_str, sizeof(os->bandwidth_str),
> + " bandwidth=\"%d\"", os->bit_rate);
> +} else {
> +int level = s->strict_std_compliance >= FF_COMPLIANCE_STRICT ?
> +AV_LOG_ERROR : AV_LOG_WARNING;
> +av_log(s, level, "No bit rate set for stream %d\n", i);
> +if (s->strict_std_compliance >= FF_COMPLIANCE_STRICT)
> +return AVERROR(EINVAL);
> +}
> +}
> +
> +return 0;
> +}
> +
>  static int dash_init(AVFormatContext *s)
>  {
>  DASHContext *c = s->priv_data;
> @@ -597,6 +621,10 @@ static int dash_init(AVFormatContext *s)
>  if (!c->streams)
>  return AVERROR(ENOMEM);
>
> +ret = set_bitrate(s);
> +if (ret < 0)
> +return ret;
> +
>  for (i = 0; i < s->nb_streams; i++) {
>  OutputStream *os = &c->streams[i];
>  AVFormatContext *ctx;
> @@ -604,18 +632,6 @@ static int dash_init(AVFormatContext *s)
>  AVDictionary *opts = NULL;
>  char filename[1024];
>
> -os->bit_rate = s->streams[i]->codecpar->bit_rate;
> -if (os->bit_rate) {
> -snprintf(os->bandwidth_str, sizeof(os->bandwidth_str),
> - " bandwidth=\"%d\"", os->bit_rate);
> -} else {
> -int level = s->strict_std_compliance >= FF_COMPLIANCE_STRICT ?
> -AV_LOG_ERROR : AV_LOG_WARNING;
> -av_log(s, level, "No bit rate set for stream %d\n", i);
> -if (s->strict_std_compliance >= FF_COMPLIANCE_STRICT)
> -return AVERROR(EINVAL);
> -}
> -
>  ctx = avformat_alloc_context();
>  if (!ctx)
>  return AVERROR(ENOMEM);
> @@ -981,6 +997,8 @@ static int dash_write_trailer(AVFormatContext *s)
>  {
>  DASHContext *c = s->priv_data;
>
> +set_bitrate(s);
> +
>  if (s->nb_streams > 0) {
>  OutputStream *os = &c->streams[0];
>  // If no segments have been written so far, try to do a crude
> --
> 2.7.4
>
>
Any comment on this?

--
Best regards
Przemysław Sobala


ping?

--
Regards
Przemysław Sobala
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] libavcodec/psd : add support for rgb/gray float

[Carl Eugen Hoyos]

2017-03-01 23:42 GMT+01:00 Martin Vignali :
> Hello,
>
> In attach patch for decoding float data (rgb/gray only) inside psd
> Like in the openexr decoder, float data is convert to uint16
> A gamma conversion can be apply before uint16 conversion (with an option)
>
> the function : static inline uint16_t psd_flt2uint(uint32_t v)
> is a copy/paste of exr_flt_uint of the exr decoder.
> Probably need to be move somewhere (but i don't know the best place for that)

If no other suggestions are made, move it to libavcodec/internal.h
and make it av_always_inline.

Is the buffer always necessary, or can the transformation be done
in-place?

> Sample can be found here :
> https://we.tl/85kvceapTL

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

Re: [FFmpeg-devel] [PATCH] Remove qmin and qmax constraints for nvenc vbr

[Ganapathy Raman Kasi]

Thanks for review. If qmin and qmax are not set, nvenc will assume default of 
qmin 15 and qmax 51 which is good enough for most content. Setting qmin 5 would 
be similar to qmin of 15 at lower bitrates as ratecontrol may not  reach below 
QP 15. 

Ganapathy

-Original Message-
From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of Philip 
Langdale
Sent: Tuesday, February 28, 2017 5:54 AM
To: Miroslav Slugeň 
Cc: FFmpeg development discussions and patches 
Subject: Re: [FFmpeg-devel] [PATCH] Remove qmin and qmax constraints for nvenc 
vbr

On Tue, 28 Feb 2017 11:54:32 +0100
Miroslav Slugeň  wrote:

> Dne 28.2.2017 v 10:44 Timo Rothenpieler napsal(a):
> > Am 28.02.2017 um 01:24 schrieb Ganapathy Raman Kasi:  
> >> Can someone please help review patch. Thanks.  
> > I have seen an marked it, but I don't have time to review and test 
> > stuff right now.
> > Will get to it eventually.
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> I tested this patch, it looks like there is no difference when you set 
> -qmin 5 -qmax 51 or leave it unset.
> 
> BUT this patch is correct, NVENC doesn't require QMIN and QMAX for 
> 2pass vbr.
> 
> M.
> 
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Patch looks good to me too. Timo, I can push it if you don't mind not testing 
it yourself.


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

---
This email message is for the sole use of the intended recipient(s) and may 
contain
confidential information.  Any unauthorized review, use, disclosure or 
distribution
is prohibited.  If you are not the intended recipient, please contact the 
sender by
reply email and destroy all copies of the original message.
---
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavf/matroska: Support codec id V_FFV1 for FFV1.

[James Almer]

On 3/1/2017 7:18 PM, Carl Eugen Hoyos wrote:
> 2017-03-01 17:56 GMT+01:00 James Almer :
>> On 2/28/2017 4:45 PM, Carl Eugen Hoyos wrote:
>>> Hi!
>>>
>>> Attached patch fixes ticket #6206 here.
>>>
>>> Please comment, Carl Eugen
>>
>> This doesn't consider the CodecPrivate contents for FFV1 v3
>> and above. It's only valid for v1 and v2.
> 
> Is this comment meant for the muxer or the demuxer part?
> 
> How can I reproduce the issue you see?
> For me, everything works as specified for default strictness.

Ah, i see there's generic code to read and write CodecPrivate elements
to and from raw extradata for native codecids where no special handling
is required.

In any case, the spec says

"For FFV1 versions 2 or less, Private Data SHOULD NOT be written."

The ffv1 encoder creates extradata for v2 and newer, so the muxer
should have a custom case for ffv1 in order to detect v2 streams and
avoid writing said extradata.

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

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

[FFmpeg-devel] [PATCH 2/2] avcodec/mpeg4videodec: Improve the overflow checks in mpeg4_decode_sprite_trajectory()

[Michael Niedermayer]

Also clear the state on errors

Fixes integer overflows in 701/clusterfuzz-testcase-6594719951880192

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavcodec/mpeg4videodec.c | 16 +++-
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/libavcodec/mpeg4videodec.c b/libavcodec/mpeg4videodec.c
index 9f9374d550..568263ecdf 100644
--- a/libavcodec/mpeg4videodec.c
+++ b/libavcodec/mpeg4videodec.c
@@ -375,7 +375,7 @@ static int mpeg4_decode_sprite_trajectory(Mpeg4DecContext 
*ctx, GetBitContext *g
 FFABS(s->sprite_offset[1][1]) >= INT_MAX >> shift_c
 ) {
 avpriv_request_sample(s->avctx, "Too large sprite shift or 
offset");
-return AVERROR_PATCHWELCOME;
+goto overflow;
 }
 
 for (i = 0; i < 2; i++) {
@@ -385,17 +385,23 @@ static int mpeg4_decode_sprite_trajectory(Mpeg4DecContext 
*ctx, GetBitContext *g
 s->sprite_delta[1][i]  *= 1 << shift_y;
 ctx->sprite_shift[i] = 16;
 
-if (llabs(s->sprite_offset[i][0] + s->sprite_delta[i][0] * 
(int64_t)w) >= INT_MAX ||
-llabs(s->sprite_offset[i][0] + s->sprite_delta[i][1] * 
(int64_t)h) >= INT_MAX ||
-llabs(s->sprite_offset[i][0] + s->sprite_delta[i][0] * 
(int64_t)w + s->sprite_delta[i][1] * (int64_t)h) >= INT_MAX) {
+}
+for (i = 0; i < 2; i++) {
+if (llabs(s->sprite_offset[0][i] + s->sprite_delta[i][0] * 
(w+16LL)) >= INT_MAX ||
+llabs(s->sprite_offset[0][i] + s->sprite_delta[i][1] * 
(h+16LL)) >= INT_MAX ||
+llabs(s->sprite_offset[0][i] + s->sprite_delta[i][0] * 
(w+16LL) + s->sprite_delta[i][1] * (h+16LL)) >= INT_MAX) {
 avpriv_request_sample(s->avctx, "Overflow on sprite points");
-return AVERROR_PATCHWELCOME;
+goto overflow;
 }
 }
 s->real_sprite_warping_points = ctx->num_sprite_warping_points;
 }
 
 return 0;
+overflow:
+memset(s->sprite_offset, 0, sizeof(s->sprite_offset));
+memset(s->sprite_delta, 0, sizeof(s->sprite_delta));
+return AVERROR_PATCHWELCOME;
 }
 
 static int decode_new_pred(Mpeg4DecContext *ctx, GetBitContext *gb) {
-- 
2.11.0

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

[FFmpeg-devel] [PATCH 1/2] avcodec/vp56: Require a correctly decoded frame before using vp56_conceal_mb()

[Michael Niedermayer]

Fixes timeout with 700/clusterfuzz-testcase-5660909504561152
Fixes timeout with 702/clusterfuzz-testcase-4553541576294400

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavcodec/vp56.c | 14 +-
 libavcodec/vp56.h |  3 +++
 2 files changed, 16 insertions(+), 1 deletion(-)

diff --git a/libavcodec/vp56.c b/libavcodec/vp56.c
index a9a1a0c1d5..52b6329fcb 100644
--- a/libavcodec/vp56.c
+++ b/libavcodec/vp56.c
@@ -612,8 +612,12 @@ int ff_vp56_decode_frame(AVCodecContext *avctx, void 
*data, int *got_frame,
 }
 }
 
+s->discard_frame = 0;
 avctx->execute2(avctx, ff_vp56_decode_mbs, 0, 0, (avctx->pix_fmt == 
AV_PIX_FMT_YUVA420P) + 1);
 
+if (s->discard_frame)
+return AVERROR_INVALIDDATA;
+
 if ((res = av_frame_ref(data, p)) < 0)
 return res;
 *got_frame = 1;
@@ -699,8 +703,13 @@ static int ff_vp56_decode_mbs(AVCodecContext *avctx, void 
*data,
 for (mb_col=0; mb_colmb_width; mb_col++) {
 if (!damaged) {
 int ret = vp56_decode_mb(s, mb_row, mb_col, is_alpha);
-if (ret < 0)
+if (ret < 0) {
 damaged = 1;
+if (!s->have_undamaged_frame) {
+s->discard_frame = 1;
+return AVERROR_INVALIDDATA;
+}
+}
 }
 if (damaged)
 vp56_conceal_mb(s, mb_row, mb_col, is_alpha);
@@ -717,6 +726,9 @@ static int ff_vp56_decode_mbs(AVCodecContext *avctx, void 
*data,
 }
 }
 
+if (!damaged)
+s->have_undamaged_frame = 1;
+
 next:
 if (p->key_frame || s->golden_frame) {
 av_frame_unref(s->frames[VP56_FRAME_GOLDEN]);
diff --git a/libavcodec/vp56.h b/libavcodec/vp56.h
index 34d48228fd..e5c5bea963 100644
--- a/libavcodec/vp56.h
+++ b/libavcodec/vp56.h
@@ -203,6 +203,9 @@ struct vp56_context {
 VLC runv_vlc[2];
 VLC ract_vlc[2][3][6];
 unsigned int nb_null[2][2];   /* number of consecutive NULL DC/AC */
+
+int have_undamaged_frame;
+int discard_frame;
 };
 
 
-- 
2.11.0

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

Re: [FFmpeg-devel] [PATCH]lavf/flacdec: Return maximum score if a valid streaminfo header was found

[Michael Niedermayer]

On Wed, Mar 01, 2017 at 09:38:58AM +0100, Carl Eugen Hoyos wrote:
> Hi!
> 
> I implemented this patch to fix ticket #6208 but it turned out the flac probe 
> function wasn't the issue. Still looks like a good idea to me.
> 
> Please comment, Carl Eugen

>  flacdec.c |9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 64259ee8c398e244db4174257a3f1bbad6160ca7  
> 0001-lavf-flacdec-Return-maximum-score-if-the-streaminfo-.patch
> From acc7558a3585d99776523ed670747597c4de99fb Mon Sep 17 00:00:00 2001
> From: Carl Eugen Hoyos 
> Date: Wed, 1 Mar 2017 09:34:37 +0100
> Subject: [PATCH 1/2] lavf/flacdec: Return maximum score if the streaminfo
>  header is valid.
> 
> ---
>  libavformat/flacdec.c |9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)

if this works with all flac files you have then its probably ok
but i wouldnt be surprised if some of this will need to be tuned
based on future tickets

thx

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

It is dangerous to be right in matters on which the established authorities
are wrong. -- Voltaire


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/3] avcodec/h264idct_template: Fix several runtime error: signed integer overflow

[Michael Niedermayer]

On Tue, Feb 28, 2017 at 10:07:36PM +0100, Michael Niedermayer wrote:
> Fixes: 689/clusterfuzz-testcase-6029352737177600
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/h264idct_template.c | 18 +-
>  1 file changed, 9 insertions(+), 9 deletions(-)

patchset applied

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

Dictatorship naturally arises out of democracy, and the most aggravated
form of tyranny and slavery out of the most extreme liberty. -- 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] avcodec/vp56: Clear dimensions in case of failure in the middle of a resolution change

[Michael Niedermayer]

On Wed, Mar 01, 2017 at 04:28:23AM +0100, Michael Niedermayer wrote:
> Similar code is used elsewhere in vp56 to force a more complete reinit in the 
> future.
> Fixes null pointer dereference
> Fixes: 707/clusterfuzz-testcase-4717453097566208
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/vp56.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)

applied

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

Opposition brings concord. Out of discord comes the fairest harmony.
-- Heraclitus


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

Re: [FFmpeg-devel] [PATCH v2 1/3] ffmpeg_opt: pass output framerate as a hint to the encoder

[Michael Niedermayer]

On Mon, Feb 27, 2017 at 09:50:31AM +0100, Tobias Rapp wrote:
> On 26.02.2017 16:09, Michael Niedermayer wrote:
> >On Mon, Feb 20, 2017 at 04:05:00PM +0100, Tobias Rapp wrote:
> >>On 20.02.2017 15:09, Mark Thompson wrote:
> >>>On 06/02/17 12:33, Tobias Rapp wrote:
> Sets framerate field in output codec context if explicitly specified on
> the command-line.
> 
> Signed-off-by: Tobias Rapp 
> ---
> ffmpeg_opt.c | 2 ++
> 1 file changed, 2 insertions(+)
> 
> diff --git a/ffmpeg_opt.c b/ffmpeg_opt.c
> index 6a47d32..3b532da 100644
> --- a/ffmpeg_opt.c
> +++ b/ffmpeg_opt.c
> @@ -1535,6 +1535,8 @@ static OutputStream 
> *new_video_stream(OptionsContext *o, AVFormatContext *oc, in
> av_log(NULL, AV_LOG_FATAL, "Invalid framerate value: %s\n", 
>  frame_rate);
> exit_program(1);
> }
> +if (frame_rate && ost->frame_rate.num && ost->frame_rate.den)
> +video_enc->framerate = ost->frame_rate;
> if (frame_rate && video_sync_method == VSYNC_PASSTHROUGH)
> av_log(NULL, AV_LOG_ERROR, "Using -vsync 0 and -r can produce 
>  invalid output files\n");
> 
> 
> >>>
> >>>Is there a reason not to always set this, rather than only when it is 
> >>>specified explicitly on the command line as you have?
> >>>
> >>>(Like 
> >>>,
> >>> though that is after the current merge point and I don't know if it 
> >>>interacts with anything else.)
> >>
> >>I just tried to be extra cautious. Merging Libav commit
> >>d10102d23c9467d4eb84f58e0cd12be284b982f6 would provide a more
> >>general solution and might be preferred.
> >
> >that one would change fate results, are the changed results better or
> >worse ?
> 
> I rebased unto current master and run fate with the attached change
> to ffmpeg.c applied but couldn't find any changed reference files.
> 

> Which fate tests had some changes and which platform did you check?

there was a commit in origin/master that broke the tests, i realized
that after sending the mail but was too busy to reply immedeaty and
then forgot

[...]


-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

You can kill me, but you cannot change the truth.


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

[FFmpeg-devel] Convert audio to DBFS

[Chau Pham]

Hi there


I am doing audio converting and use ffmpeg.

I looked into a ffmpeg sample program  demuxing_decoding.c

and inside decode_packet function



...

size_t unpadded_linesize = frame->nb_samples * 
av_get_bytes_per_sample((AVSampleFormat)frame->format);
fwrite(frame->extended_data[0], 1, unpadded_linesize, audio_dst_file);
..

I would like to convert audio packet to DBFS (Decibels full scale).

Could someone help me?
I will appreciate any suggestion from you.

Thank in advance.
Jobi




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

Re: [FFmpeg-devel] [PATCH v3 2/2] rtp: rfc4175: add handler for YCbCr-4:2:2

[Damien Riegel]

On Wed, Mar 01, 2017 at 12:12:42AM +0100, Thomas Volkert wrote:
> 
> On 28.02.2017 19:39, Damien Riegel wrote:
> > This adds partial support for the RFC 4175 (raw video over RTP). The
> > only supported formats are the YCbCr-4:2:2 8 bit because it's natively
> > supported by FFmpeg with pixel format UYVY, and 10 bit which requires
> > the vrawdepay codec to convert the payload in a format handled by
> > FFmpeg.
> >
> > Signed-off-by: Damien Riegel 
> > ---
> > Changes in v3:
> >  - rename rawvideo to rfc4175
> >
> >  
> 
> >  libavformat/rtpdec_rfc4175.c | 236 
> > +++
> >  
> 
> I would use a more meaningful file name here - I think we always tried
> to avoid using the rfc number of the RTP payload format definition as
> part of the file name. We rather used the codec name or something
> similar. (There is only exception - RFC 2190 for H.263)

I changed it because of a suggestion in previous version (or maybe I got
that wrong). I can change it back to "rawvideo", or to whatever name is
preferred.

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

Re: [FFmpeg-devel] libavcodec/psd : add support for rgb/gray float

[wm4]

On Wed, 1 Mar 2017 23:42:28 +0100
Martin Vignali  wrote:

> Hello,
> 
> In attach patch for decoding float data (rgb/gray only) inside psd
> Like in the openexr decoder, float data is convert to uint16
> A gamma conversion can be apply before uint16 conversion (with an option)
> 
> the function : static inline uint16_t psd_flt2uint(uint32_t v)
> is a copy/paste of exr_flt_uint of the exr decoder.
> Probably need to be move somewhere (but i don't know the best place for that)
> 
> Sample can be found here :
> https://we.tl/85kvceapTL

Time to think about a float pixfmt? I find it weird that we support
excessively obscure pixfmts like AV_PIX_FMT_BGR4_BYTE, but then have
hacks like this one if the codec uses float data.

(I'm just commenting, not arguing for/against your actual patch.)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel