Re: [FFmpeg-devel] [PATCH 1/2] avcodec/alacdec: split off decorrelate_stereo and append_extra_bits as alacdsp

[Michael Niedermayer]

On Sun, Oct 04, 2015 at 11:51:58PM +, Timothy Gu wrote:
> On Sun, Oct 4, 2015 at 2:21 PM Michael Niedermayer  wrote:
> 
> > there is a spec ?
> >
> 
> Don't think so for the codec itself.
> 
> 
> > i only know of soe reference source code and i looked yesterday
> > and it usesed the full 8 bits unless i missed something
> >
> 
>  https://alac.macosforge.org/trac/browser/trunk/codec/ALACEncoder.cpp says
> that mixRes (aka decorr_left_weight) can be up to 4.

in absence of a spec the decoder is the next best to understand the
limitations of a format.
A encoder is generally not a good choice because the limits of version
"1.0" of a encoder could differ fro version "1.1"

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

Observe your enemies, for they first find out your faults. -- Antisthenes


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/pngdec: initialize "foreground_alpha"

[Michael Niedermayer]

On Sun, Oct 04, 2015 at 09:21:55PM -0400, Ganesh Ajjanagadde wrote:
> Fixes CID 1322359, CID 1322358.
> 
> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  libavcodec/pngdec.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavcodec/pngdec.c b/libavcodec/pngdec.c
> index d180141..fe5 100644
> --- a/libavcodec/pngdec.c
> +++ b/libavcodec/pngdec.c
> @@ -1006,7 +1006,7 @@ static int handle_p_frame_apng(AVCodecContext *avctx, 
> PNGDecContext *s,
>  uint8_t *background = buffer + s->image_linesize * y + s->bpp * 
> s->x_offset;
>  for (x = s->x_offset; x < s->x_offset + s->cur_w; ++x, 
> foreground += s->bpp, background += s->bpp) {
>  size_t b;
> -uint8_t foreground_alpha, background_alpha, output_alpha;
> +uint8_t foreground_alpha = 0, background_alpha, output_alpha;

this looks very odd
have you checked that the reference png implementation and png spec
set foreground_alpha to 0 for cases that FFmpeg doesnt implement ? ;)

warnings can point to bugs and if so the bug should be fixed which
should make the warning disappear. If a warning doesnt point to a bug
then it should be silenced in some clean way

It seems you try to silence this one without really realizing
what is wrong with the codepath in which this warning occurs

I didnt write it but to me it seems the if() a few lines above is
intended to stop this codepath
see 'avpriv_request_sample(avctx, "Blending with pixel format %s",'

it doesnt work as blend_op is assumed to have only 2 values but
this is not checked for anywhere.
blend_op should be checked when/before it is set


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

I do not agree with what you have to say, but I'll defend to the death your
right to say it. -- 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] avcodec/pngdec: initialize "foreground_alpha"

[Ganesh Ajjanagadde]

On Sun, Oct 4, 2015 at 10:16 PM, Michael Niedermayer  wrote:
> On Sun, Oct 04, 2015 at 09:21:55PM -0400, Ganesh Ajjanagadde wrote:
>> Fixes CID 1322359, CID 1322358.
>>
>> Signed-off-by: Ganesh Ajjanagadde 
>> ---
>>  libavcodec/pngdec.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/libavcodec/pngdec.c b/libavcodec/pngdec.c
>> index d180141..fe5 100644
>> --- a/libavcodec/pngdec.c
>> +++ b/libavcodec/pngdec.c
>> @@ -1006,7 +1006,7 @@ static int handle_p_frame_apng(AVCodecContext *avctx, 
>> PNGDecContext *s,
>>  uint8_t *background = buffer + s->image_linesize * y + s->bpp * 
>> s->x_offset;
>>  for (x = s->x_offset; x < s->x_offset + s->cur_w; ++x, 
>> foreground += s->bpp, background += s->bpp) {
>>  size_t b;
>> -uint8_t foreground_alpha, background_alpha, output_alpha;
>> +uint8_t foreground_alpha = 0, background_alpha, 
>> output_alpha;
>
> this looks very odd
> have you checked that the reference png implementation and png spec
> set foreground_alpha to 0 for cases that FFmpeg doesnt implement ? ;)
>
> warnings can point to bugs and if so the bug should be fixed which
> should make the warning disappear. If a warning doesnt point to a bug
> then it should be silenced in some clean way
>
> It seems you try to silence this one without really realizing
> what is wrong with the codepath in which this warning occurs

I did not look at this deeply. Furthermore, I assumed that the
Coverity scan does not report false positives. More precisely, I
assumed (incorrectly) that when Coverity says a code path is reached,
etc it is based on an actual runtime input or a guaranteed static
analysis, and not simply on some heuristics. Good to know for future
use of Coverity.

>
> I didnt write it but to me it seems the if() a few lines above is
> intended to stop this codepath
> see 'avpriv_request_sample(avctx, "Blending with pixel format %s",'

Looking at this more carefully I agree with you, and so I drop this patch.

>
> it doesnt work as blend_op is assumed to have only 2 values but
> this is not checked for anywhere.
> blend_op should be checked when/before it is set
>
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> I do not agree with what you have to say, but I'll defend to the death your
> right to say it. -- Voltaire
>
> ___
> 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]vc1 Autodetection

[Michael Niedermayer]

On Sun, Oct 04, 2015 at 11:47:59PM +0200, Carl Eugen Hoyos wrote:
> Hi!
> 
> Attached is a patch implementing vc-1 autodetection.
> 
> Please review, Carl Eugen

>  Makefile  |2 -
>  rawdec.c  |4 ---
>  vc1dec.c  |   71 
> ++
>  version.h |2 -
>  4 files changed, 73 insertions(+), 6 deletions(-)

tools/probetest 100 10
...
testing size=65536
Failure of vc1 probing code with score=51 type=1 p=DF0 size=65536

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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

Re: [FFmpeg-devel] [PATCH] avcodec/pngdec: initialize "foreground_alpha"

[Michael Niedermayer]

On Sun, Oct 04, 2015 at 10:39:26PM -0400, Ganesh Ajjanagadde wrote:
> On Sun, Oct 4, 2015 at 10:16 PM, Michael Niedermayer  wrote:
> > On Sun, Oct 04, 2015 at 09:21:55PM -0400, Ganesh Ajjanagadde wrote:
> >> Fixes CID 1322359, CID 1322358.
> >>
> >> Signed-off-by: Ganesh Ajjanagadde 
> >> ---
> >>  libavcodec/pngdec.c | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/libavcodec/pngdec.c b/libavcodec/pngdec.c
> >> index d180141..fe5 100644
> >> --- a/libavcodec/pngdec.c
> >> +++ b/libavcodec/pngdec.c
> >> @@ -1006,7 +1006,7 @@ static int handle_p_frame_apng(AVCodecContext 
> >> *avctx, PNGDecContext *s,
> >>  uint8_t *background = buffer + s->image_linesize * y + s->bpp 
> >> * s->x_offset;
> >>  for (x = s->x_offset; x < s->x_offset + s->cur_w; ++x, 
> >> foreground += s->bpp, background += s->bpp) {
> >>  size_t b;
> >> -uint8_t foreground_alpha, background_alpha, output_alpha;
> >> +uint8_t foreground_alpha = 0, background_alpha, 
> >> output_alpha;
> >
> > this looks very odd
> > have you checked that the reference png implementation and png spec
> > set foreground_alpha to 0 for cases that FFmpeg doesnt implement ? ;)
> >
> > warnings can point to bugs and if so the bug should be fixed which
> > should make the warning disappear. If a warning doesnt point to a bug
> > then it should be silenced in some clean way
> >
> > It seems you try to silence this one without really realizing
> > what is wrong with the codepath in which this warning occurs
> 
> I did not look at this deeply. Furthermore, I assumed that the
> Coverity scan does not report false positives. More precisely, I
> assumed (incorrectly) that when Coverity says a code path is reached,
> etc it is based on an actual runtime input or a guaranteed static
> analysis, and not simply on some heuristics. Good to know for future
> use of Coverity.

50-70% of the coverity issues are "false positives" thats according
to my feeling from what ive seen, not a hard statistic


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

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


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

Re: [FFmpeg-devel] [PATCH] avcodec/pngdec: initialize "foreground_alpha"

[Ganesh Ajjanagadde]

On Sun, Oct 4, 2015 at 11:08 PM, Michael Niedermayer  wrote:
> On Sun, Oct 04, 2015 at 10:39:26PM -0400, Ganesh Ajjanagadde wrote:
>> On Sun, Oct 4, 2015 at 10:16 PM, Michael Niedermayer  
>> wrote:
>> > On Sun, Oct 04, 2015 at 09:21:55PM -0400, Ganesh Ajjanagadde wrote:
>> >> Fixes CID 1322359, CID 1322358.
>> >>
>> >> Signed-off-by: Ganesh Ajjanagadde 
>> >> ---
>> >>  libavcodec/pngdec.c | 2 +-
>> >>  1 file changed, 1 insertion(+), 1 deletion(-)
>> >>
>> >> diff --git a/libavcodec/pngdec.c b/libavcodec/pngdec.c
>> >> index d180141..fe5 100644
>> >> --- a/libavcodec/pngdec.c
>> >> +++ b/libavcodec/pngdec.c
>> >> @@ -1006,7 +1006,7 @@ static int handle_p_frame_apng(AVCodecContext 
>> >> *avctx, PNGDecContext *s,
>> >>  uint8_t *background = buffer + s->image_linesize * y + 
>> >> s->bpp * s->x_offset;
>> >>  for (x = s->x_offset; x < s->x_offset + s->cur_w; ++x, 
>> >> foreground += s->bpp, background += s->bpp) {
>> >>  size_t b;
>> >> -uint8_t foreground_alpha, background_alpha, output_alpha;
>> >> +uint8_t foreground_alpha = 0, background_alpha, 
>> >> output_alpha;
>> >
>> > this looks very odd
>> > have you checked that the reference png implementation and png spec
>> > set foreground_alpha to 0 for cases that FFmpeg doesnt implement ? ;)
>> >
>> > warnings can point to bugs and if so the bug should be fixed which
>> > should make the warning disappear. If a warning doesnt point to a bug
>> > then it should be silenced in some clean way
>> >
>> > It seems you try to silence this one without really realizing
>> > what is wrong with the codepath in which this warning occurs
>>
>> I did not look at this deeply. Furthermore, I assumed that the
>> Coverity scan does not report false positives. More precisely, I
>> assumed (incorrectly) that when Coverity says a code path is reached,
>> etc it is based on an actual runtime input or a guaranteed static
>> analysis, and not simply on some heuristics. Good to know for future
>> use of Coverity.
>
> 50-70% of the coverity issues are "false positives" thats according
> to my feeling from what ive seen, not a hard statistic

Thanks for the info; this is very useful to know.

>
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Its not that you shouldnt use gotos but rather that you should write
> readable code and code with gotos often but not always is less readable
>
> ___
> 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 1/9] dnxhddec: cleanup frame header parsing

[Christophe Gisquet]

Hi,

2015-10-03 19:50 GMT+02:00 Carl Eugen Hoyos :
> Looks unintended...

Indeed. Patch updated.

-- 
Christophe


0001-dnxhddec-cleanup-frame-header-parsing.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/alacdec: split off decorrelate_stereo and append_extra_bits as alacdsp

[Michael Niedermayer]

On Sun, Oct 04, 2015 at 12:44:56AM -0300, James Almer wrote:
> Signed-off-by: James Almer 
> ---
>  libavcodec/Makefile  |  2 +-
>  libavcodec/alac.c| 65 
> +++-
>  libavcodec/alacdsp.c | 57 +
>  libavcodec/alacdsp.h | 35 
>  4 files changed, 116 insertions(+), 43 deletions(-)
>  create mode 100644 libavcodec/alacdsp.c
>  create mode 100644 libavcodec/alacdsp.h

should be ok unless the functions exist already somewhere else

thx

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

It is what and why we do it that matters, not just one of them.


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

Re: [FFmpeg-devel] [PATCH] avfilter/f_ebur128: add dualmono measurement option

[Clément Bœsch]

On Wed, Sep 30, 2015 at 10:35:08AM -0500, Kyle Swanson wrote:
> ---
>  doc/filters.texi|  9 +
>  libavfilter/f_ebur128.c | 22 ++
>  2 files changed, 31 insertions(+)
> 

Applied with

-Treat mono input files as 'dual mono.' If a mono file is intended for playback
+Treat mono input files as "dual mono". If a mono file is intended for playback

[...]

Thanks

-- 
Clément B.


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

Re: [FFmpeg-devel] [PATCH] avformat/flacdec: support fast-seek

[Michael Niedermayer]

On Sun, Oct 04, 2015 at 01:50:45PM +0800, Ching-Yi Chan wrote:
> 2015-10-04 7:37 GMT+08:00 Michael Niedermayer :
> 
> > On Sat, Oct 03, 2015 at 01:14:26AM +0800, Ching-Yi Chan wrote:
> >
> > iam not sure changing the format flags is a great idea, i think no
> > other demuxer does that
> > that said, the documentation does not say that only the user can
> > change them so this is more a note that this looks a bit odd not that
> > it is wrong
> >
> > using a context to keep found_seektable state.
> 
> 
> > > +
> > > +reset_index_position(avio_tell(s->pb), st);
> > >  return 0;
> > >
> > >  fail:
> > > @@ -249,12 +283,33 @@ static av_unused int64_t
> > flac_read_timestamp(AVFormatContext *s, int stream_inde
> > >  return pts;
> > >  }
> > >
> > > +static int flac_seek(AVFormatContext *s, int stream_index, int64_t
> > timestamp, int flags) {
> > > +int index;
> > > +int64_t pos;
> > > +AVIndexEntry e;
> > > +if (!(s->flags_FLAG_FAST_SEEK)) {
> > > +return -1;
> > > +}
> > > +
> > > +index = av_index_search_timestamp(s->streams[0], timestamp, flags);
> > > +if(index<0 || index >= s->streams[0]->nb_index_entries)
> > > +return -1;
> > > +
> > > +e = s->streams[0]->index_entries[index];
> > > +pos = avio_seek(s->pb, e.pos, SEEK_SET);
> > > +if (pos >= 0) {
> >
> > > +return pos;
> >
> > if pos is larger than INT_MAX the this can overflow and be interpreted
> > as an error by the caller
> >
> >
> > fix it by returning 0

>  flacdec.c |   60 +++-
>  1 file changed, 59 insertions(+), 1 deletion(-)
> 99622a220e4bf069a4aa9e97836497aba54a8b7c  
> 0001-avformat-flacdec-support-fast-seek.patch
> From f96510987c03418b06b8724b92be83d8bff69c6f Mon Sep 17 00:00:00 2001
> From: "Ching Yi, Chan" 
> Date: Thu, 24 Sep 2015 13:04:40 +0800
> Subject: [PATCH] avformat/flacdec: support fast-seek

applied

thanks

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

The bravest are surely those who have the clearest vision
of what is before them, glory and danger alike, and yet
notwithstanding go out to meet it. -- Thucydides


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

Re: [FFmpeg-devel] [RFC] avformat/mxfenc: stop encoding if unfilled video packet

[Tomas Härdin]

On Mon, 2015-09-28 at 15:11 +0200, Tobias Rapp wrote:
> On 19.09.2015 22:49, Tomas Härdin wrote:
> > On Wed, 2015-09-16 at 14:33 +0200, Tobias Rapp wrote:
> >> Hi,
> >>
> >> attached patch fixes ticket #4759 but I guess it is a bit too hasty to
> >> always abort transcoding if a single frame cannot be written. I guess it
> >> would be better to check for some "exit_on_error" like flag set but
> >> couldn't find out how to achieve that.
> >>
> >> Any comments would be appreciated.
> >>
> >> Regards,
> >> Tobias
> >
> >
> >>  From 7d6f8de2a411817c970a19d8766e69b6eb604132 Mon Sep 17 00:00:00 2001
> >> From: Tobias Rapp 
> >> Date: Mon, 14 Sep 2015 12:06:22 +0200
> >> Subject: [PATCH] avformat/mxfenc: stop encoding if unfilled video packet
> >>   occurs
> >>
> >> Fixes ticket #4759.
> >> ---
> >>   libavformat/mxfenc.c | 14 +-
> >>   1 file changed, 9 insertions(+), 5 deletions(-)
> >>
> [...]
> >
> > Is this really better than not writing anything?
> >
> > /Tomas
> 
> (Sorry for the long delay in answering, I was caught by a flu last week.)
> 
> I want to transcode thousands of files and want to get some indication 
> from ffmpeg if the transcoding has been successful (all frames have been 
> transcoded) or not. Currently I am using the process exit code to verify 
> that.
> 
> There are two different user stories when using ffmpeg:
> a) "process the input data and exit with error as early as possible in 
> case of errors/problems"
> b) "process the input data and avoid exit with error as long as possible 
> in case of error/problems"
> 
> If I understand correctly I can basically switch between (a) and (b) 
> mode by passing the "-xerror" option to ffmpeg or not. So my plan is to 
> transcode all my files with "-xerror" and assume that >99% of the files 
> will pass. The small amount of failing ones can then be analyzed for 
> problems manually and possibly have a re-run without "-xerror".
> 
> Unfortunately the "-xerror" option affects only ffmpeg but not the 
> libraries, so I cannot use it do decide if "mxf_write_packet" should 
> return with an error when the video packet size doesn't match the CBR 
> constraints.

For me the most important thing is that anything dealing with MXF should
never write invalid files. I'm not sure whether the current code is
broken per se, but it does look suspicious. Perhaps someone else has a
better idea?

/Tomas


signature.asc
Description: This is a digitally signed message part
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec: remove old vdpau decoder implementation

[wm4]

On Sun, 4 Oct 2015 11:31:31 + (UTC)
Carl Eugen Hoyos  wrote:

> wm4  googlemail.com> writes:
> 
> > On Sat, 3 Oct 2015 22:23:21 +0200
> > Carl Eugen Hoyos  ag.or.at> wrote:
> > 
> > > On Saturday 03 October 2015 10:05:29 pm wm4 wrote:
> > > > Ping. Will push in 24 hours or so if nobody complains.
> > > 
> > > The reason I am against this is just that users told me 
> > > repeatedly (in person) that they switched from the dark 
> > > side to FFmpeg because this (and possibly) other API 
> > > was removed there.
> > 
> > As I've said several times, progress is not possible (or 
> > requires lots of wasted energy) if we don't drop obsolete 
> > APIs.
> 
> What makes the old API "obsolete"? You?

Existence of a better API that does everything the old API did. How is
this so hard to understand?

> > And at this point, the new vdpau API is definitely 
> > superior over the old one. I don't know
> > why anyone would want to use the old API.
> 
> Maybe other people (including other projects) prefer 
> to work on bug fixes and new features and don't want 
> to waste their time rewriting APIs every year?
> 
> > > I simply don't understand what the advantage is of 
> > > removing a few lines of code.
> > 
> > That's not a few lines, that's over 600 lines.
> 
> So why do we still need libavresample? It certainly has 
> more than 600 lines...

It wasn't my idea to duplicate Libav's effort of writing a resampler
library.

On the other hand, FFmpeg constantly keeps duplicate things that come
from Libav merges. Libav got rid of the old vdpau code already 2 years
ago, but FFmpeg reverted this.

I can't agree with this hysteric way of development.

> > To make it worse, it's all duplicated code
> 
> You are talking about the new API?
> 
> > duplicating functionality the vdpau hwaccel provides.
> 
> Yes, by duplicating the existing vdpau code in new 
> files, and duplicating the code again for every new 
> hardware acceleration.
> I do understand that this cannot be avoided, I just 
> don't understand why this is used as an argument.

Your point makes no sense. The code is duplicated for the same
decoding API.

> > Unlike the hwaccel code, it's not cleanly integrated 
> > either. Just look how intrusive it is, while hwaccel 
> > is basically just a bunch of callbacks in the right 
> > places (and works for multiple hwdec APIs, not
> > just vdpau).
> 
> And everytime a new hardware acceleration is added, new 
> callbacks are needeed...

They're not by far as intrusive is the vdpau code. The vdpau code was
just blindly hacked into all the decoders, while the new hwaccel API at
least provides _some_ abstraction and isolation of the API-specific
bits.

If you didn't like the new vdpau API, you should never have merged it.

> Is there really no way to convince you to invest your 
> time in something also useful for other users of FFmpeg?

Not wasting my time with these discussions would help. You know the old
vdpau code has to go one day. And it's been over 2 years since it was
deprecated (and also removed in Libav), and the most important API
users (vlc, kodi) use the new API. Why still refuse?

Apropos useful, the new vdpau API is almost intuitive to use. With the
old API, the only chance to understand how to use it was to
reverse-engineer mplayer code (yes, that's also how the new vdpau
hwaccel was written). I hope there will be further improvements to the
hwaccel code. It's annoying that it happens incrementally and very
slowly, but at least some progress.

Anyway, if this patch is still contended, we should use our fabulous
new voting system.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavformat/tls_securetransport: silence uninitialized value warning

[Michael Niedermayer]

On Sat, Oct 03, 2015 at 05:31:33PM -0500, Rodger Combs wrote:
> ---
>  libavformat/tls_securetransport.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/libavformat/tls_securetransport.c 
> b/libavformat/tls_securetransport.c
> index 73662d7..cdc7953 100644
> --- a/libavformat/tls_securetransport.c
> +++ b/libavformat/tls_securetransport.c
> @@ -350,7 +350,7 @@ static int map_ssl_error(OSStatus status, size_t 
> processed)
>  static int tls_read(URLContext *h, uint8_t *buf, int size)
>  {
>  TLSContext *c = h->priv_data;
> -size_t processed;
> +size_t processed = 0;
>  int ret = map_ssl_error(SSLRead(c->ssl_context, buf, size, ), 
> processed);
>  if (ret > 0)
>  return ret;
> @@ -362,7 +362,7 @@ static int tls_read(URLContext *h, uint8_t *buf, int size)
>  static int tls_write(URLContext *h, const uint8_t *buf, int size)
>  {
>  TLSContext *c = h->priv_data;
> -size_t processed;
> +size_t processed = 0;
>  int ret = map_ssl_error(SSLWrite(c->ssl_context, buf, size, ), 
> processed);

this looks wrong before and after the patch

SSL* must set processed before it is used in map_ssl_error() but
the code doesnt neccessarily do that

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

The real ebay dictionary, page 1
"Used only once"- "Some unspecified defect prevented a second use"
"In good condition" - "Can be repaird by experienced expert"
"As is" - "You wouldnt want it even if you were payed for it, if you knew ..."


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: remove old vdpau decoder implementation

[Carl Eugen Hoyos]

wm4  googlemail.com> writes:

> On Sat, 3 Oct 2015 22:23:21 +0200
> Carl Eugen Hoyos  ag.or.at> wrote:
> 
> > On Saturday 03 October 2015 10:05:29 pm wm4 wrote:
> > > Ping. Will push in 24 hours or so if nobody complains.
> > 
> > The reason I am against this is just that users told me 
> > repeatedly (in person) that they switched from the dark 
> > side to FFmpeg because this (and possibly) other API 
> > was removed there.
> 
> As I've said several times, progress is not possible (or 
> requires lots of wasted energy) if we don't drop obsolete 
> APIs.

What makes the old API "obsolete"? You?

> And at this point, the new vdpau API is definitely 
> superior over the old one. I don't know
> why anyone would want to use the old API.

Maybe other people (including other projects) prefer 
to work on bug fixes and new features and don't want 
to waste their time rewriting APIs every year?

> > I simply don't understand what the advantage is of 
> > removing a few lines of code.
> 
> That's not a few lines, that's over 600 lines.

So why do we still need libavresample? It certainly has 
more than 600 lines...

> To make it worse, it's all duplicated code

You are talking about the new API?

> duplicating functionality the vdpau hwaccel provides.

Yes, by duplicating the existing vdpau code in new 
files, and duplicating the code again for every new 
hardware acceleration.
I do understand that this cannot be avoided, I just 
don't understand why this is used as an argument.

> Unlike the hwaccel code, it's not cleanly integrated 
> either. Just look how intrusive it is, while hwaccel 
> is basically just a bunch of callbacks in the right 
> places (and works for multiple hwdec APIs, not
> just vdpau).

And everytime a new hardware acceleration is added, new 
callbacks are needeed...

Is there really no way to convince you to invest your 
time in something also useful for other users of FFmpeg?

Carl Eugen

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

Re: [FFmpeg-devel] [PATCH 8/9] dnxhd: add better support for CIDs 1270 to 1274

[Christophe Gisquet]

2015-10-03 18:59 GMT+02:00 Christophe Gisquet :
[SNIP]

There was a blank space in there (I think).

Patch updated

-- 
Christophe


0008-dnxhd-add-better-support-for-CIDs-1270-to-1274.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/alacdec: split off decorrelate_stereo and append_extra_bits as alacdsp

[Michael Niedermayer]

On Sun, Oct 04, 2015 at 01:31:27AM -0300, James Almer wrote:
> On 10/4/2015 12:44 AM, James Almer wrote:
> > Signed-off-by: James Almer 
> > ---
> >  libavcodec/Makefile  |  2 +-
> >  libavcodec/alac.c| 65 
> > +++-
> >  libavcodec/alacdsp.c | 57 +
> >  libavcodec/alacdsp.h | 35 
> >  4 files changed, 116 insertions(+), 43 deletions(-)
> >  create mode 100644 libavcodec/alacdsp.c
> >  create mode 100644 libavcodec/alacdsp.h
> > 
> > diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> > index b15e431..153c3f8 100644
> > --- a/libavcodec/Makefile
> > +++ b/libavcodec/Makefile
> > @@ -143,7 +143,7 @@ OBJS-$(CONFIG_AC3_ENCODER) += 
> > ac3enc_float.o ac3enc.o ac3tab.o \
> >ac3.o kbdwin.o
> >  OBJS-$(CONFIG_AC3_FIXED_ENCODER)   += ac3enc_fixed.o ac3enc.o ac3tab.o 
> > ac3.o
> >  OBJS-$(CONFIG_AIC_DECODER) += aic.o
> > -OBJS-$(CONFIG_ALAC_DECODER)+= alac.o alac_data.o
> > +OBJS-$(CONFIG_ALAC_DECODER)+= alac.o alac_data.o alacdsp.o
> >  OBJS-$(CONFIG_ALAC_ENCODER)+= alacenc.o alac_data.o
> >  OBJS-$(CONFIG_ALIAS_PIX_DECODER)   += aliaspixdec.o
> >  OBJS-$(CONFIG_ALIAS_PIX_ENCODER)   += aliaspixenc.o
> > diff --git a/libavcodec/alac.c b/libavcodec/alac.c
> > index 827c0db..b767438 100644
> > --- a/libavcodec/alac.c
> > +++ b/libavcodec/alac.c
> > @@ -57,6 +57,7 @@
> >  #include "unary.h"
> >  #include "mathops.h"
> >  #include "alac_data.h"
> > +#include "alacdsp.h"
> >  
> >  #define ALAC_EXTRADATA_SIZE 36
> >  
> > @@ -81,6 +82,8 @@ typedef struct ALACContext {
> >  
> >  int direct_output;
> >  int extra_bit_bug;
> > +
> > +ALACDSPContext dsp;
> >  } ALACContext;
> >  
> >  static inline unsigned int decode_scalar(GetBitContext *gb, int k, int bps)
> > @@ -230,35 +233,6 @@ static void lpc_prediction(int32_t *error_buffer, 
> > int32_t *buffer_out,
> >  }
> >  }
> >  
> > -static void decorrelate_stereo(int32_t *buffer[2], int nb_samples,
> > -   int decorr_shift, int decorr_left_weight)
> > -{
> > -int i;
> > -
> > -for (i = 0; i < nb_samples; i++) {
> > -int32_t a, b;
> > -
> > -a = buffer[0][i];
> > -b = buffer[1][i];
> > -
> > -a -= (b * decorr_left_weight) >> decorr_shift;
> > -b += a;
> > -
> > -buffer[0][i] = b;
> > -buffer[1][i] = a;
> > -}
> > -}
> > -
> > -static void append_extra_bits(int32_t *buffer[2], int32_t 
> > *extra_bits_buffer[2],
> > -  int extra_bits, int channels, int nb_samples)
> > -{
> > -int i, ch;
> > -
> > -for (ch = 0; ch < channels; ch++)
> > -for (i = 0; i < nb_samples; i++)
> > -buffer[ch][i] = (buffer[ch][i] << extra_bits) | 
> > extra_bits_buffer[ch][i];
> > -}
> > -
> >  static int decode_element(AVCodecContext *avctx, AVFrame *frame, int 
> > ch_index,
> >int channels)
> >  {
> > @@ -389,19 +363,24 @@ static int decode_element(AVCodecContext *avctx, 
> > AVFrame *frame, int ch_index,
> >  decorr_left_weight = 0;
> >  }
> >  
> > -if (alac->extra_bits && alac->extra_bit_bug) {
> > -append_extra_bits(alac->output_samples_buffer, 
> > alac->extra_bits_buffer,
> > -  alac->extra_bits, channels, alac->nb_samples);
> > -}
> > +if (channels == 2) {
> > +if (alac->extra_bits && alac->extra_bit_bug) {
> > +
> > alac->dsp.append_extra_bits_stereo(alac->output_samples_buffer, 
> > alac->extra_bits_buffer,
> > +   alac->extra_bits, channels, 
> > alac->nb_samples);
> > +}
> >  
> > -if (channels == 2 && decorr_left_weight) {
> > -decorrelate_stereo(alac->output_samples_buffer, alac->nb_samples,
> > -   decorr_shift, decorr_left_weight);
> > -}
> > +if (decorr_left_weight) {
> 
> So while i was writing a checkasm unit i started looking at the possible
> values for this, and found out that apparently it's either 0 or 1.
> Since the function below is not called when it's 0, wouldn't that mean
> it's a pointless argument?
> 
> I'll have to redo the asm function if that's the case, and change the
> prototype and boilerplate c version.

why would it only be 0 or 1 ?
(it sure could be in actual files but the syntax allows 8bit values)

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I do not agree with what you have to say, but I'll defend to the death your
right to say it. -- 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 9/9] dnxhdenc: fix scan used for bitstream generation

[Christophe Gisquet]

Hi,

Le 4 oct. 2015 04:16, "Michael Niedermayer"  a écrit :
>
> On Sat, Oct 03, 2015 at 06:59:22PM +0200, Christophe Gisquet wrote:
> > The functions related to bitstream reading must use the natural zigzag
> > order, and not the one permuted for use in the iDCT.
> >
> > This resulted in a bitstream where the AC coefficients were encoded in
> > an unexpected order.
> > ---
> >  libavcodec/dnxhdenc.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
>
> this still breaks
>
> ./ffmpeg -f lavfi -i testsrc=s=1440x1080  -vframes 1 -pix_fmt yuv422p
-vcodec dnxhd -vb 80M -flags +ildct file.mov

err, sorry badly split branch. This one is not part of the dnxhr support,
but new idct asm.

Please ignore, but I do need to fix it.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec: remove old vdpau decoder implementation

[Ronald S. Bultje]

Hi,

On Sat, Oct 3, 2015 at 4:23 PM, Carl Eugen Hoyos  wrote:

> On Saturday 03 October 2015 10:05:29 pm wm4 wrote:
> > Ping. Will push in 24 hours or so if nobody complains.
>
> The reason I am against this is just that users told me
> repeatedly (in person) that they switched from the dark
> side to FFmpeg because this (and possibly) other API
> was removed there.


Let's not call names. "They" are not "the dark side", they're Libav.

If users want to discuss the specifics of this new API, they should not
come to you, anonymously and untraceably (not to mention unverifiable), but
to the developer mailinglist which all of us read. It's hard to base any
future project decision on rumours.

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

Re: [FFmpeg-devel] [PATCH] avcodec: remove old vdpau decoder implementation

[compn]

On Sun, 4 Oct 2015 14:48:25 +0200
wm4  wrote:

> On Sun, 4 Oct 2015 11:31:31 + (UTC)
> Carl Eugen Hoyos  wrote:
> 
> > wm4  googlemail.com> writes:
> > 
> > > On Sat, 3 Oct 2015 22:23:21 +0200
> > > Carl Eugen Hoyos  ag.or.at> wrote:
> > > 
> > > > On Saturday 03 October 2015 10:05:29 pm wm4 wrote:
> > > > > Ping. Will push in 24 hours or so if nobody complains.
> > > > 
> > > > The reason I am against this is just that users told me 
> > > > repeatedly (in person) that they switched from the dark 
> > > > side to FFmpeg because this (and possibly) other API 
> > > > was removed there.
> > > 
> > > As I've said several times, progress is not possible (or 
> > > requires lots of wasted energy) if we don't drop obsolete 
> > > APIs.
> > 
> > What makes the old API "obsolete"? You?
> 
> Existence of a better API that does everything the old API did. How is
> this so hard to understand?

i think carl is asking whom did the deprecating in ffmpeg.

carl: if this new api works with kodi and mplayer, whats the problem?

are there still users of this api in 2015? yes or no?

carl, do you use this api? what for? to test vdpau?

carl is maintainer of this vdpau code, wm4.
its right there in MAINTAINERS.

http://ffmpeg.org/developer.html#Contributing
1.4 Development Policy

7. Do not commit changes to the build system (Makefiles, configure
script) which change behavior, defaults etc, without asking first. The
same applies to compiler warning fixes, trivial looking fixes and to
code maintained by other developers. We usually have a reason for doing
things the way we do. Send your changes as patches to the ffmpeg-devel
mailing list, and if the code maintainers say OK, you may commit. This
does not apply to files you wrote and/or maintain.

specifically says do not change code without maintainers approval,
twice.

feel free to change developer policy by rfc'ing a patch

i'm just trying to help.

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

Re: [FFmpeg-devel] [PATCH 1/2] checkasm: Fix compilation with --disable-avcodec

[Henrik Gramner]

On Sun, Oct 4, 2015 at 3:33 PM, Ronald S. Bultje  wrote:
> Just push it, I'm not sure I can come up with an airtight mechanism that is
> not mega-overdesigned into oblivion...

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

Re: [FFmpeg-devel] [PATCH] all: add _DEFAULT_SOURCE locally wherever needed

[Ganesh Ajjanagadde]

On Sat, Oct 3, 2015 at 9:07 AM, Ronald S. Bultje  wrote:
> Hi,
>
> On Sat, Oct 3, 2015 at 8:47 AM, wm4  wrote:
>
>> On Sat,  3 Oct 2015 07:41:00 -0500
>> Ganesh Ajjanagadde  wrote:
>>
>> > Glibc 2.20 onwards generates a deprecation warning for usage of
>> _BSD_SOURCE and _SVID_SOURCE.
>> > The solution from man feature_test_macros is to define both
>> _DEFAULT_SOURCE and the old macros.
>> > This solution is on the lines of the one in commit
>> af1818276ef271af98e2e2bbabb4dc875b4fa7d8.
>> >
>> > Signed-off-by: Ganesh Ajjanagadde 
>> > ---
>> >  libavformat/img2dec.c | 1 +
>> >  libavformat/udp.c | 1 +
>> >  libswscale/utils.c| 1 +
>> >  3 files changed, 3 insertions(+)
>> >
>> > diff --git a/libavformat/img2dec.c b/libavformat/img2dec.c
>> > index 1697579..0cbcf4a 100644
>> > --- a/libavformat/img2dec.c
>> > +++ b/libavformat/img2dec.c
>> > @@ -20,6 +20,7 @@
>> >   * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
>> 02110-1301 USA
>> >   */
>> >
>> > +#define _DEFAULT_SOURCE
>> >  #define _BSD_SOURCE
>> >  #include 
>> >  #include "libavutil/avstring.h"
>> > diff --git a/libavformat/udp.c b/libavformat/udp.c
>> > index d40ea97..1bda5af 100644
>> > --- a/libavformat/udp.c
>> > +++ b/libavformat/udp.c
>> > @@ -24,6 +24,7 @@
>> >   * UDP protocol
>> >   */
>> >
>> > +#define _DEFAULT_SOURCE
>> >  #define _BSD_SOURCE /* Needed for using struct ip_mreq with recent
>> glibc */
>> >
>> >  #include "avformat.h"
>> > diff --git a/libswscale/utils.c b/libswscale/utils.c
>> > index eb1c940..651b07a 100644
>> > --- a/libswscale/utils.c
>> > +++ b/libswscale/utils.c
>> > @@ -20,6 +20,7 @@
>> >
>> >  #include "config.h"
>> >
>> > +#define _DEFAULT_SOURCE
>> >  #define _SVID_SOURCE // needed for MAP_ANONYMOUS
>> >  #define _DARWIN_C_SOURCE // needed for MAP_ANON
>> >  #include 
>>
>> IMHO much better than the previous attempts, and likely minimize the
>> potential for regressions.
>
>
> Agreed. Patch OK, you can commit yourself if you feel safe :)

Please push - at the moment there is no universal consensus on write
privileges for me.

>
> Ronald
> ___
> 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] all: add _DEFAULT_SOURCE locally wherever needed

[Ronald S. Bultje]

Hi,

On Sun, Oct 4, 2015 at 10:27 AM, Ganesh Ajjanagadde 
wrote:

> On Sat, Oct 3, 2015 at 9:07 AM, Ronald S. Bultje 
> wrote:
> > Hi,
> >
> > On Sat, Oct 3, 2015 at 8:47 AM, wm4  wrote:
> >
> >> On Sat,  3 Oct 2015 07:41:00 -0500
> >> Ganesh Ajjanagadde  wrote:
> >>
> >> > Glibc 2.20 onwards generates a deprecation warning for usage of
> >> _BSD_SOURCE and _SVID_SOURCE.
> >> > The solution from man feature_test_macros is to define both
> >> _DEFAULT_SOURCE and the old macros.
> >> > This solution is on the lines of the one in commit
> >> af1818276ef271af98e2e2bbabb4dc875b4fa7d8.
> >> >
> >> > Signed-off-by: Ganesh Ajjanagadde 
> >> > ---
> >> >  libavformat/img2dec.c | 1 +
> >> >  libavformat/udp.c | 1 +
> >> >  libswscale/utils.c| 1 +
> >> >  3 files changed, 3 insertions(+)
> >> >
> >> > diff --git a/libavformat/img2dec.c b/libavformat/img2dec.c
> >> > index 1697579..0cbcf4a 100644
> >> > --- a/libavformat/img2dec.c
> >> > +++ b/libavformat/img2dec.c
> >> > @@ -20,6 +20,7 @@
> >> >   * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
> >> 02110-1301 USA
> >> >   */
> >> >
> >> > +#define _DEFAULT_SOURCE
> >> >  #define _BSD_SOURCE
> >> >  #include 
> >> >  #include "libavutil/avstring.h"
> >> > diff --git a/libavformat/udp.c b/libavformat/udp.c
> >> > index d40ea97..1bda5af 100644
> >> > --- a/libavformat/udp.c
> >> > +++ b/libavformat/udp.c
> >> > @@ -24,6 +24,7 @@
> >> >   * UDP protocol
> >> >   */
> >> >
> >> > +#define _DEFAULT_SOURCE
> >> >  #define _BSD_SOURCE /* Needed for using struct ip_mreq with
> recent
> >> glibc */
> >> >
> >> >  #include "avformat.h"
> >> > diff --git a/libswscale/utils.c b/libswscale/utils.c
> >> > index eb1c940..651b07a 100644
> >> > --- a/libswscale/utils.c
> >> > +++ b/libswscale/utils.c
> >> > @@ -20,6 +20,7 @@
> >> >
> >> >  #include "config.h"
> >> >
> >> > +#define _DEFAULT_SOURCE
> >> >  #define _SVID_SOURCE // needed for MAP_ANONYMOUS
> >> >  #define _DARWIN_C_SOURCE // needed for MAP_ANON
> >> >  #include 
> >>
> >> IMHO much better than the previous attempts, and likely minimize the
> >> potential for regressions.
> >
> >
> > Agreed. Patch OK, you can commit yourself if you feel safe :)
>
> Please push - at the moment there is no universal consensus on write
> privileges for me.


Applied.

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

Re: [FFmpeg-devel] [PATCHv2] ffplay: more robust mutex creation

[Ganesh Ajjanagadde]

On Sun, Oct 4, 2015 at 12:47 PM, Marton Balint  wrote:
>
>
> On Sun, 4 Oct 2015, Ganesh Ajjanagadde wrote:
>
>> SDL_CreateMutex can fail:
>> https://wiki.libsdl.org/SDL_CreateMutex.
>> This patch makes creation more robust in one instance.
>>
>> Signed-off-by: Ganesh Ajjanagadde 
>> ---
>> ffplay.c | 6 ++
>> 1 file changed, 6 insertions(+)
>>
>> diff --git a/ffplay.c b/ffplay.c
>> index c5a7895..84bd6ee 100644
>> --- a/ffplay.c
>> +++ b/ffplay.c
>> @@ -2817,6 +2817,12 @@ static int read_thread(void *arg)
>> int scan_all_pmts_set = 0;
>> int64_t pkt_ts;
>>
>> +if (!wait_mutex) {
>> +av_log(is, AV_LOG_FATAL, "SDL_CreateMutex(): %s\n",
>> SDL_GetError());
>
>
> VideoState has no AVClass, are you sure this works? All other instances use
> NULL.

Entirely possible; I just (naively) assumed logging does some magic
e.g void* pointers or something like that. You can use v1 then.

>
> Regards,
> Marton
> ___
> 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] avcodec: remove old vdpau decoder implementation

[wm4]

On Sun, 4 Oct 2015 09:25:23 -0400
compn  wrote:

> On Sun, 4 Oct 2015 14:48:25 +0200
> wm4  wrote:
> 
> > On Sun, 4 Oct 2015 11:31:31 + (UTC)
> > Carl Eugen Hoyos  wrote:
> > 
> > > wm4  googlemail.com> writes:
> > > 
> > > > On Sat, 3 Oct 2015 22:23:21 +0200
> > > > Carl Eugen Hoyos  ag.or.at> wrote:
> > > > 
> > > > > On Saturday 03 October 2015 10:05:29 pm wm4 wrote:
> > > > > > Ping. Will push in 24 hours or so if nobody complains.
> > > > > 
> > > > > The reason I am against this is just that users told me 
> > > > > repeatedly (in person) that they switched from the dark 
> > > > > side to FFmpeg because this (and possibly) other API 
> > > > > was removed there.
> > > > 
> > > > As I've said several times, progress is not possible (or 
> > > > requires lots of wasted energy) if we don't drop obsolete 
> > > > APIs.
> > > 
> > > What makes the old API "obsolete"? You?
> > 
> > Existence of a better API that does everything the old API did. How is
> > this so hard to understand?
> 
> i think carl is asking whom did the deprecating in ffmpeg.
> 
> carl: if this new api works with kodi and mplayer, whats the problem?
> 
> are there still users of this api in 2015? yes or no?
> 
> carl, do you use this api? what for? to test vdpau?
> 
> carl is maintainer of this vdpau code, wm4.
> its right there in MAINTAINERS.
> 
> http://ffmpeg.org/developer.html#Contributing
> 1.4 Development Policy
> 
> 7. Do not commit changes to the build system (Makefiles, configure
> script) which change behavior, defaults etc, without asking first. The
> same applies to compiler warning fixes, trivial looking fixes and to
> code maintained by other developers. We usually have a reason for doing
> things the way we do. Send your changes as patches to the ffmpeg-devel
> mailing list, and if the code maintainers say OK, you may commit. This
> does not apply to files you wrote and/or maintain.
> 
> specifically says do not change code without maintainers approval,
> twice.
> 
> feel free to change developer policy by rfc'ing a patch
> 
> i'm just trying to help.

Looks like Great Leader violated the developer policy multiple times
then.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Changelog: add note on ffplay dynamic volume control

[Marton Balint]

On Sat, 3 Oct 2015, Ganesh Ajjanagadde wrote:


Signed-off-by: Ganesh Ajjanagadde 
---
Changelog | 1 +
1 file changed, 1 insertion(+)

diff --git a/Changelog b/Changelog
index 4b18d00..2d1c842 100644
--- a/Changelog
+++ b/Changelog
@@ -15,6 +15,7 @@ version :
- maskedmerge filter
- Screenpresso SPV1 decoding
- chromaprint fingerprinting muxer
+- ffplay dynamic volume control


Applied, thanks.

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

[FFmpeg-devel] [PATCH] ffplay: log SDL error message

[Ganesh Ajjanagadde]

This patch logs the SDL error message on failure of creation of 
SDL_CreateMutex, SDL_CreateCond.

Signed-off-by: Ganesh Ajjanagadde 
---
 ffplay.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/ffplay.c b/ffplay.c
index 84bd6ee..39a1cbe 100644
--- a/ffplay.c
+++ b/ffplay.c
@@ -657,10 +657,14 @@ static int frame_queue_init(FrameQueue *f, PacketQueue 
*pktq, int max_size, int
 {
 int i;
 memset(f, 0, sizeof(FrameQueue));
-if (!(f->mutex = SDL_CreateMutex()))
+if (!(f->mutex = SDL_CreateMutex())) {
+av_log(f, AV_LOG_FATAL, "SDL_CreateMutex(): %s\n", SDL_GetError());
 return AVERROR(ENOMEM);
-if (!(f->cond = SDL_CreateCond()))
+}
+if (!(f->cond = SDL_CreateCond())) {
+av_log(f, AV_LOG_FATAL, "SDL_CreateCond(): %s\n", SDL_GetError());
 return AVERROR(ENOMEM);
+}
 f->pktq = pktq;
 f->max_size = FFMIN(max_size, FRAME_QUEUE_SIZE);
 f->keep_last = !!keep_last;
-- 
2.6.0

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

[FFmpeg-devel] [PATCH] ffplay: log SDL error message

[Ganesh Ajjanagadde]

This patch logs the SDL error message on failure of SDL_CreateThread.

Signed-off-by: Ganesh Ajjanagadde 
---
 ffplay.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/ffplay.c b/ffplay.c
index 03befdc..ad8ffd5 100644
--- a/ffplay.c
+++ b/ffplay.c
@@ -3182,6 +3182,7 @@ static VideoState *stream_open(const char *filename, 
AVInputFormat *iformat)
 is->av_sync_type = av_sync_type;
 is->read_tid = SDL_CreateThread(read_thread, is);
 if (!is->read_tid) {
+av_log(is, AV_LOG_FATAL, "SDL_CreateThread(): %s\n", SDL_GetError());
 fail:
 stream_close(is);
 return NULL;
-- 
2.6.0

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

[FFmpeg-devel] [PATCH] ffplay: log SDL error message

[Ganesh Ajjanagadde]

This patch logs the SDL error message on failure of SDL_CreateMutex.

Signed-off-by: Ganesh Ajjanagadde 
---
 ffplay.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/ffplay.c b/ffplay.c
index ad8ffd5..c00af91 100644
--- a/ffplay.c
+++ b/ffplay.c
@@ -3734,8 +3734,10 @@ static int lockmgr(void **mtx, enum AVLockOp op)
switch(op) {
   case AV_LOCK_CREATE:
   *mtx = SDL_CreateMutex();
-  if(!*mtx)
+  if(!*mtx) {
+  av_log(NULL, AV_LOG_FATAL, "SDL_CreateMutex(): %s\n", 
SDL_GetError());
   return 1;
+  }
   return 0;
   case AV_LOCK_OBTAIN:
   return !!SDL_LockMutex(*mtx);
-- 
2.6.0

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

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/alacdec: split off decorrelate_stereo and append_extra_bits as alacdsp

[James Almer]

On 10/4/2015 7:35 AM, Michael Niedermayer wrote:
> On Sun, Oct 04, 2015 at 01:31:27AM -0300, James Almer wrote:
>>> +if (decorr_left_weight) {
>>
>> So while i was writing a checkasm unit i started looking at the possible
>> values for this, and found out that apparently it's either 0 or 1.
>> Since the function below is not called when it's 0, wouldn't that mean
>> it's a pointless argument?
>>
>> I'll have to redo the asm function if that's the case, and change the
>> prototype and boilerplate c version.
> 
> why would it only be 0 or 1 ?
> (it sure could be in actual files but the syntax allows 8bit values)

Our encoder at least does as much (see alac_stereo_decorrelation() in
alacenc.c). Haven't tried others, so unless someone that knows the spec
chimes in I'll leave it as is.

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

Re: [FFmpeg-devel] modify ffplay for dumpstream in rtsp?

[Nicolas George]

Le duodi 12 vendémiaire, an CCXXIV, compn a écrit :
> he wants to play and dump at the same time. like vlc can. 
> 
> should this functionality be added to ffmpeg or ffplay?

ffmpeg can already display video on the fly, with the opengl, xv and sdl
devices.

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] [PATCH] ffplay: log SDL error message

[Ganesh Ajjanagadde]

On Sun, Oct 4, 2015 at 12:33 PM, Ganesh Ajjanagadde
 wrote:
> This patch logs the SDL error message on failure of SDL_CreateMutex.
>
> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  ffplay.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/ffplay.c b/ffplay.c
> index ad8ffd5..c00af91 100644
> --- a/ffplay.c
> +++ b/ffplay.c
> @@ -3734,8 +3734,10 @@ static int lockmgr(void **mtx, enum AVLockOp op)
> switch(op) {
>case AV_LOCK_CREATE:
>*mtx = SDL_CreateMutex();
> -  if(!*mtx)
> +  if(!*mtx) {
> +  av_log(NULL, AV_LOG_FATAL, "SDL_CreateMutex(): %s\n", 
> SDL_GetError());
>return 1;
> +  }
>return 0;
>case AV_LOCK_OBTAIN:
>return !!SDL_LockMutex(*mtx);
> --
> 2.6.0
>

I can squash these all into a single patch if that is preferred.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]select attribute of tee pseudo demuxer may contain multiple stream specifiers

[Nicolas George]

Le decadi 10 vendémiaire, an CCXXIV, Bodecs Bela a écrit :
> thank you for your feedback, I have altered the patch accordingly. I have
> enclosed the updated patch file.

Please remember not to top-post on these mailing-lists.

See interleaved comments below.

> From bcbd5e3e1a850fef1002d3a63c06fc52b2a3d169 Mon Sep 17 00:00:00 2001
> From: Bela Bodecs 
> Date: Thu, 1 Oct 2015 13:00:50 +0200
> Subject: [PATCH 1/1] select attribute of tee pseudo demuxer may contain
>  multiple stream specifiers
> MIME-Version: 1.0
> Content-Type: multipart/mixed; boundary="1.8.3.1"
> 
> This is a multi-part message in MIME format.
> --1.8.3.1
> Content-Type: text/plain; charset=UTF-8; format=fixed
> Content-Transfer-Encoding: 8bit
> 
> ---
>  doc/muxers.texi   |  3 ++-
>  libavformat/tee.c | 32 +++-
>  2 files changed, 25 insertions(+), 10 deletions(-)
> 
> 
> --1.8.3.1
> Content-Type: text/x-patch; 
> name="0001-select-attribute-of-tee-pseudo-demuxer-may-contain-m.patch"
> Content-Transfer-Encoding: 8bit
> Content-Disposition: attachment; 
> filename="0001-select-attribute-of-tee-pseudo-demuxer-may-contain-m.patch"

This is rather strange. I wonder how you managed to produce this patch.

> 
> diff --git a/doc/muxers.texi b/doc/muxers.texi
> index d75d7de..113b76a 100644
> --- a/doc/muxers.texi
> +++ b/doc/muxers.texi
> @@ -1224,7 +1224,8 @@ Several bitstream filters can be specified, separated 
> by ",".
>  @item select
>  Select the streams that should be mapped to the slave output,
>  specified by a stream specifier. If not specified, this defaults to
> -all the input streams.
> +all the input streams. You may use multiple stream specifiers 
> +separated by commas (@code{,}) e.g.: @code{a:0,v}
>  @end table
>  
>  @subsection Examples
> diff --git a/libavformat/tee.c b/libavformat/tee.c
> index e3d466a..7d67652 100644
> --- a/libavformat/tee.c
> +++ b/libavformat/tee.c
> @@ -47,6 +47,7 @@ static const char *const slave_opt_open  = "[";
>  static const char *const slave_opt_close = "]";
>  static const char *const slave_opt_delim = ":]"; /* must have the close too 
> */
>  static const char *const slave_bsfs_spec_sep = "/";
> +static const char *const slave_select_sep = ",";
>  
>  static const AVClass tee_muxer_class = {
>  .class_name = "Tee muxer",
> @@ -142,7 +143,9 @@ static int open_slave(AVFormatContext *avf, char *slave, 
> TeeSlave *tee_slave)
>  AVFormatContext *avf2 = NULL;
>  AVStream *st, *st2;
>  int stream_count;
> -
> +int fullret;
> +char *subselect = NULL, *next_subselect = NULL, *first_subselect;
> +
>  if ((ret = parse_slave_options(avf, slave, , )) < 0)
>  return ret;
>  
> @@ -172,15 +175,26 @@ static int open_slave(AVFormatContext *avf, char 
> *slave, TeeSlave *tee_slave)
>  for (i = 0; i < avf->nb_streams; i++) {
>  st = avf->streams[i];
>  if (select) {
> -ret = avformat_match_stream_specifier(avf, avf->streams[i], 
> select);
> -if (ret < 0) {
> -av_log(avf, AV_LOG_ERROR,
> -   "Invalid stream specifier '%s' for output '%s'\n",
> -   select, slave);
> -goto end;
> -}
> +fullret = 0;

> +first_subselect = select;
> +next_subselect = NULL;
> +while (subselect = av_strtok(first_subselect, slave_select_sep, 
> _subselect)) {
> +first_subselect = NULL;

I was about to say "LGTM", but I just noticed this: av_strtok(), just like
strtok(), is destructive: it replace the delimiters by a NUL character in
the original string. If it is called again with the same string, it will
only see the first token.

Unless I am mistaken, this is what will happen here: if the specifier is
"0,1", the stream #0 will be matched on the first round of the loop, but
then stream #1 will only see select as "0", no longer "0,1".

Fixing it can be done easily enough, though. For example with av_strdup() on
the string (but beware of the leaks).

I am a bit surprised you did not catch this during testing. Maybe I am
missing something.

> +
> +ret = avformat_match_stream_specifier(avf, avf->streams[i], 
> subselect);
> +if (ret < 0) {
> +av_log(avf, AV_LOG_ERROR,
> +"Invalid stream specifier '%s' for output '%s'\n",
> +subselect, slave);
> +goto end;
> +}
> +if (ret != 0) {
> +fullret = 1; // match
> +break;
> +}
>  
> -if (ret == 0) { /* no match */
> +}
> +if (fullret == 0) { /* no match */
>  tee_slave->stream_map[i] = -1;
>  continue;
>  }
> 

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature

Re: [FFmpeg-devel] [PATCH]select attribute of tee pseudo demuxer may contain multiple stream specifiers

[Bodecs Bela]

See my interleaved comments below.


2015.10.04. 18:50 keltezéssel, Nicolas George írta:

Le decadi 10 vendémiaire, an CCXXIV, Bodecs Bela a écrit :

thank you for your feedback, I have altered the patch accordingly. I have
enclosed the updated patch file.

Please remember not to top-post on these mailing-lists.

I am very sorry. I won't do it again.


See interleaved comments below.


 From bcbd5e3e1a850fef1002d3a63c06fc52b2a3d169 Mon Sep 17 00:00:00 2001
From: Bela Bodecs 
Date: Thu, 1 Oct 2015 13:00:50 +0200
Subject: [PATCH 1/1] select attribute of tee pseudo demuxer may contain
  multiple stream specifiers
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="1.8.3.1"

This is a multi-part message in MIME format.
--1.8.3.1
Content-Type: text/plain; charset=UTF-8; format=fixed
Content-Transfer-Encoding: 8bit

---
  doc/muxers.texi   |  3 ++-
  libavformat/tee.c | 32 +++-
  2 files changed, 25 insertions(+), 10 deletions(-)


--1.8.3.1
Content-Type: text/x-patch; 
name="0001-select-attribute-of-tee-pseudo-demuxer-may-contain-m.patch"
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment; 
filename="0001-select-attribute-of-tee-pseudo-demuxer-may-contain-m.patch"

This is rather strange. I wonder how you managed to produce this patch.

git add libavformat/tee.c
git add doc/muxers.texi
git commit -m "select attribute of tee pseudo demuxer may contain 
multiple stream specifiers"

git format-patch -n -o /tmp/ --attach  origin




diff --git a/doc/muxers.texi b/doc/muxers.texi
index d75d7de..113b76a 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -1224,7 +1224,8 @@ Several bitstream filters can be specified, separated by 
",".
  @item select
  Select the streams that should be mapped to the slave output,
  specified by a stream specifier. If not specified, this defaults to
-all the input streams.
+all the input streams. You may use multiple stream specifiers
+separated by commas (@code{,}) e.g.: @code{a:0,v}
  @end table
  
  @subsection Examples

diff --git a/libavformat/tee.c b/libavformat/tee.c
index e3d466a..7d67652 100644
--- a/libavformat/tee.c
+++ b/libavformat/tee.c
@@ -47,6 +47,7 @@ static const char *const slave_opt_open  = "[";
  static const char *const slave_opt_close = "]";
  static const char *const slave_opt_delim = ":]"; /* must have the close too */
  static const char *const slave_bsfs_spec_sep = "/";
+static const char *const slave_select_sep = ",";
  
  static const AVClass tee_muxer_class = {

  .class_name = "Tee muxer",
@@ -142,7 +143,9 @@ static int open_slave(AVFormatContext *avf, char *slave, 
TeeSlave *tee_slave)
  AVFormatContext *avf2 = NULL;
  AVStream *st, *st2;
  int stream_count;
-
+int fullret;
+char *subselect = NULL, *next_subselect = NULL, *first_subselect;
+
  if ((ret = parse_slave_options(avf, slave, , )) < 0)
  return ret;
  
@@ -172,15 +175,26 @@ static int open_slave(AVFormatContext *avf, char *slave, TeeSlave *tee_slave)

  for (i = 0; i < avf->nb_streams; i++) {
  st = avf->streams[i];
  if (select) {
-ret = avformat_match_stream_specifier(avf, avf->streams[i], 
select);
-if (ret < 0) {
-av_log(avf, AV_LOG_ERROR,
-   "Invalid stream specifier '%s' for output '%s'\n",
-   select, slave);
-goto end;
-}
+fullret = 0;
+first_subselect = select;
+next_subselect = NULL;
+while (subselect = av_strtok(first_subselect, slave_select_sep, 
_subselect)) {
+first_subselect = NULL;

I was about to say "LGTM", but I just noticed this: av_strtok(), just like
strtok(), is destructive: it replace the delimiters by a NUL character in
the original string. If it is called again with the same string, it will
only see the first token.

Unless I am mistaken, this is what will happen here: if the specifier is
"0,1", the stream #0 will be matched on the first round of the loop, but
then stream #1 will only see select as "0", no longer "0,1".

Fixing it can be done easily enough, though. For example with av_strdup() on
the string (but beware of the leaks).

I am a bit surprised you did not catch this during testing. Maybe I am
missing something.

You would be right unless I used

first_subselect = NULL;

right after the while statement, so the next round av_strtok will go 
further, because the first parameter will be null, not the same string 
and next_subselect will point the next start.
Yes it is destructive, but we never use this string (select) again in 
this function.
I swear, I have really tested it, I use it on my own  in my production 
environment.



+
+ret = avformat_match_stream_specifier(avf, avf->streams[i], 
subselect);
+if (ret < 0) {
+av_log(avf, AV_LOG_ERROR,
+"Invalid 

Re: [FFmpeg-devel] [PATCH] avcodec: remove old vdpau decoder implementation

[compn]

On Sun, 4 Oct 2015 09:27:05 -0700
Philip Langdale  wrote:

> On Sun, 4 Oct 2015 09:25:23 -0400
> compn  wrote:
> > carl is maintainer of this vdpau code, wm4.
> > its right there in MAINTAINERS.
> 
> As am I, for better or worse.
> 
> Perhaps Carl and I can talk about this at the GSoC summit. I support
> this clean up, but I'd also like Carl to be on-board with it.

right, thats what i was getting at. i didnt mention you
maintaining vdpau because i meant carl was maintainer of original vdpau.

which is what this patch was changing, original vdpau code.

i hope you two can work it out. :)

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

Re: [FFmpeg-devel] [PATCH] concatdec: fix metadata memleak on error

[Nicolas George]

Le duodi 12 vendémiaire, an CCXXIV, Marton Balint a écrit :
> Fixes Coverity CID 1323077.
> 
> Signed-off-by: Marton Balint 
> ---
>  libavformat/concatdec.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)

Sorry, missed it in my inbox. LGTM too.

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] [PATCH 1/2] checkasm: Fix compilation with --disable-avcodec

[Ronald S. Bultje]

Hi,

On Sun, Oct 4, 2015 at 9:31 AM, Henrik Gramner  wrote:

> On Thu, Oct 1, 2015 at 8:05 PM, Henrik Gramner  wrote:
> > On Thu, Oct 1, 2015 at 7:57 PM, Ronald S. Bultje 
> wrote:
> >> Does this mean these macros are defined and 1 when AVCODEC=0?
> >>
> >> That seems like a bug?
> >
> > Yes, they are., but I have no idea what the intended behavior of the
> > CONFIG_* variables are.
>
> Ping.
>
> Should we push this? Change the logic of how the CONFIG_* variables
> are assigned in the first place? Or take a Third Option?


Just push it, I'm not sure I can come up with an airtight mechanism that is
not mega-overdesigned into oblivion...

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

Re: [FFmpeg-devel] [PATCH 1/2] checkasm: Fix compilation with --disable-avcodec

[Henrik Gramner]

On Thu, Oct 1, 2015 at 8:05 PM, Henrik Gramner  wrote:
> On Thu, Oct 1, 2015 at 7:57 PM, Ronald S. Bultje  wrote:
>> Does this mean these macros are defined and 1 when AVCODEC=0?
>>
>> That seems like a bug?
>
> Yes, they are., but I have no idea what the intended behavior of the
> CONFIG_* variables are.

Ping.

Should we push this? Change the logic of how the CONFIG_* variables
are assigned in the first place? Or take a Third Option?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] modify ffplay for dumpstream in rtsp?

[Marton Balint]

On Sat, 3 Oct 2015, compn wrote:


On Sat, 3 Oct 2015 10:45:25 +0200
Nicolas George  wrote:


Le duodi 12 vendémiaire, an CCXXIV, Jan Panteltje a écrit :
> I was thinking about adding a command line option to ffplay to
> enable the 'dump to stdout' modification, but am taken aback by why
> I do not understand the double speed effect in playback.
The double speed effect is probably caused by you saving the packets
payloads but not their headers. The result is an elementary stream,


yes, ffplay uses some default fps for raw h264.


limitations, and I am pretty sure it can already be done in a
different but more robust way.

Most importantly, if ffplay is capable of playing the stream, then
ffmpeg should be able to read and manipulate it


he wants to play and dump at the same time. like vlc can. 


should this functionality be added to ffmpeg or ffplay?



A bitstream filter maybe?

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

Re: [FFmpeg-devel] [PATCHv2] ffplay: more robust thread creation

[Marton Balint]

On Sat, 3 Oct 2015, Ganesh Ajjanagadde wrote:


SDL_CreateThread can fail:
https://wiki.libsdl.org/SDL_CreateThread.
This patch makes thread creation more robust in one instance.

Signed-off-by: Ganesh Ajjanagadde 
---
ffplay.c | 16 
1 file changed, 12 insertions(+), 4 deletions(-)



Applied, thanks.

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

[FFmpeg-devel] [PATCHv2] ffplay: more robust mutex creation

[Ganesh Ajjanagadde]

SDL_CreateMutex can fail:
https://wiki.libsdl.org/SDL_CreateMutex.
This patch makes creation more robust in one instance.

Signed-off-by: Ganesh Ajjanagadde 
---
 ffplay.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/ffplay.c b/ffplay.c
index c5a7895..84bd6ee 100644
--- a/ffplay.c
+++ b/ffplay.c
@@ -2817,6 +2817,12 @@ static int read_thread(void *arg)
 int scan_all_pmts_set = 0;
 int64_t pkt_ts;
 
+if (!wait_mutex) {
+av_log(is, AV_LOG_FATAL, "SDL_CreateMutex(): %s\n", SDL_GetError());
+ret = AVERROR(ENOMEM);
+goto fail;
+}
+
 memset(st_index, -1, sizeof(st_index));
 is->last_video_stream = is->video_stream = -1;
 is->last_audio_stream = is->audio_stream = -1;
-- 
2.6.0

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

Re: [FFmpeg-devel] [PATCH] ffplay: log SDL error message

[Ganesh Ajjanagadde]

On Sun, Oct 4, 2015 at 12:16 PM, Ganesh Ajjanagadde
 wrote:
> This patch logs the SDL error message on failure of creation of 
> SDL_CreateMutex, SDL_CreateCond.
>
> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  ffplay.c | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/ffplay.c b/ffplay.c
> index 84bd6ee..39a1cbe 100644
> --- a/ffplay.c
> +++ b/ffplay.c
> @@ -657,10 +657,14 @@ static int frame_queue_init(FrameQueue *f, PacketQueue 
> *pktq, int max_size, int
>  {
>  int i;
>  memset(f, 0, sizeof(FrameQueue));
> -if (!(f->mutex = SDL_CreateMutex()))
> +if (!(f->mutex = SDL_CreateMutex())) {
> +av_log(f, AV_LOG_FATAL, "SDL_CreateMutex(): %s\n", SDL_GetError());
>  return AVERROR(ENOMEM);
> -if (!(f->cond = SDL_CreateCond()))
> +}
> +if (!(f->cond = SDL_CreateCond())) {
> +av_log(f, AV_LOG_FATAL, "SDL_CreateCond(): %s\n", SDL_GetError());
>  return AVERROR(ENOMEM);
> +}
>  f->pktq = pktq;
>  f->max_size = FFMIN(max_size, FRAME_QUEUE_SIZE);
>  f->keep_last = !!keep_last;
> --
> 2.6.0
>

Commit message: "of creation of" -> "of". I can submit updated patch
for this if desired.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/alacdec: split off decorrelate_stereo and append_extra_bits as alacdsp

[James Almer]

On 10/4/2015 8:04 AM, Michael Niedermayer wrote:
> On Sun, Oct 04, 2015 at 12:44:56AM -0300, James Almer wrote:
>> Signed-off-by: James Almer 
>> ---
>>  libavcodec/Makefile  |  2 +-
>>  libavcodec/alac.c| 65 
>> +++-
>>  libavcodec/alacdsp.c | 57 +
>>  libavcodec/alacdsp.h | 35 
>>  4 files changed, 116 insertions(+), 43 deletions(-)
>>  create mode 100644 libavcodec/alacdsp.c
>>  create mode 100644 libavcodec/alacdsp.h
> 
> should be ok unless the functions exist already somewhere else

Not that i could find.

> thx
> 

Pushed.

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

[FFmpeg-devel] [PATCH] ffplay: more robust condition variable creation

[Ganesh Ajjanagadde]

SDL_CreateCond can fail:
https://wiki.libsdl.org/SDL_CreateCond.
This patch makes creation more robust in one instance.

Signed-off-by: Ganesh Ajjanagadde 
---
 ffplay.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/ffplay.c b/ffplay.c
index 39a1cbe..03befdc 100644
--- a/ffplay.c
+++ b/ffplay.c
@@ -3168,7 +3168,10 @@ static VideoState *stream_open(const char *filename, 
AVInputFormat *iformat)
 packet_queue_init(>subtitleq) < 0)
 goto fail;
 
-is->continue_read_thread = SDL_CreateCond();
+if (!(is->continue_read_thread = SDL_CreateCond())) {
+av_log(is, AV_LOG_FATAL, "SDL_CreateCond(): %s\n", SDL_GetError());
+goto fail;
+}
 
 init_clock(>vidclk, >videoq.serial);
 init_clock(>audclk, >audioq.serial);
-- 
2.6.0

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

Re: [FFmpeg-devel] [PATCH] avcodec: remove old vdpau decoder implementation

[Philip Langdale]

On Sun, 4 Oct 2015 09:25:23 -0400
compn  wrote:

> carl: if this new api works with kodi and mplayer, whats the problem?
> 
> are there still users of this api in 2015? yes or no?
> 
> carl, do you use this api? what for? to test vdpau?

I'm curious about this too. Traditionally, mplayer *is* the long
tail of api usage, and even it was updated to use the new API a long
time ago. The change I made recently simply removed some usage of old
API structs to carry new API data, and that was a trivial cleanup - it
has not been possible to use the actual old API for a long time.

While hwaccel is still confusing from the client side, the
implementation inside avcodec is far far superior, as wm4 says. When I
added hevc vdpau support, I simply had to implement the hwaccel hooks
and make one change in the hevc parser to expose one metadata item. I
didn't need to touch anything else. I can only imagine how horrible it
would have been to make work in the old API - needing to work out how
to expose the parser separate from the decoding logic and all the other
messy things that the other codecs had to deal with.

There is a non-trivial cost associated with keeping all those
convoluted #ifdefs, and I think the reality is that those costs were
actually not being paid - meaning that the old API probably didn't
work, given that no application, that I'm aware of, was using it. Not
mplayer, not kodi, not vlc, not ffmpeg-vdpau.c. And there's no FATE for
it either (or the new one, of course).

> carl is maintainer of this vdpau code, wm4.
> its right there in MAINTAINERS.

As am I, for better or worse.

Perhaps Carl and I can talk about this at the GSoC summit. I support
this clean up, but I'd also like Carl to be on-board with it.

Thanks,

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

Re: [FFmpeg-devel] [PATCH] avcodec: use HAVE_THREADS header guards to silence -Wunused-function

[Ronald S. Bultje]

Hi,

On Sat, Oct 3, 2015 at 2:25 PM, Michael Niedermayer 
wrote:

> On Sat, Oct 03, 2015 at 11:13:35AM -0400, Ronald S. Bultje wrote:
> > Hi,
> >
> > On Thu, Sep 17, 2015 at 7:51 AM, Michael Niedermayer 
> > wrote:
> >
> > > On Thu, Sep 17, 2015 at 06:54:37AM -0400, Ganesh Ajjanagadde wrote:
> > > > On Thu, Sep 17, 2015 at 6:17 AM, Michael Niedermayer <
> michae...@gmx.at>
> > > wrote:
> > > > > On Wed, Sep 16, 2015 at 10:22:27PM -0400, Ganesh Ajjanagadde wrote:
> > > > >> When compiled with --disable-pthreads, e.g
> > > > >>
> > >
> http://fate.ffmpeg.org/report.cgi?time=20150917015044=alpha-debian-qemu-gcc-4.7
> > > ,
> > > > >> a bunch of -Wunused-functions are reported due to missing header
> > > guards
> > > > >> around threading related functions.
> > > > >> This patch should silence such warnings.
> > > > >>
> > > > >> Signed-off-by: Ganesh Ajjanagadde 
> > > > >> ---
> > > > >>  libavcodec/alac.c  | 2 ++
> > > > >>  libavcodec/exr.c   | 2 ++
> > > > >>  libavcodec/ffv1dec.c   | 4 
> > > > >>  libavcodec/flacdec.c   | 2 ++
> > > > >>  libavcodec/h264.c  | 2 ++
> > > > >>  libavcodec/huffyuvdec.c| 2 ++
> > > > >>  libavcodec/mdec.c  | 2 ++
> > > > >>  libavcodec/mimic.c | 4 
> > > > >>  libavcodec/mpeg12dec.c | 2 ++
> > > > >>  libavcodec/mpeg4videodec.c | 2 ++
> > > > >>  libavcodec/pngdec.c| 2 ++
> > > > >>  libavcodec/takdec.c| 2 ++
> > > > >>  libavcodec/tta.c   | 2 ++
> > > > >>  libavcodec/vp3.c   | 4 
> > > > >>  libavcodec/vp8.c   | 2 ++
> > > > >>  libavcodec/vp9.c   | 2 ++
> > > > >>  libavcodec/wavpack.c   | 2 ++
> > > > >>  17 files changed, 40 insertions(+)
> > > > >
> > > > > av_unused might be simpler to silence these warnings than #if
> > > >
> > > > I do not think this is consistent at the moment across the codebase;
> > > > sometimes we use header guards and sometimes we use av_unused. Please
> > > > tell me if what the rationale is for either of them; I am fine either
> > > > way. Any half decent compiler should anyway remove unused functions
> > > > when compiled with optimizations.
> > >
> > > #ifs will be more work to maintain as they can break build if a new
> > > function call or function is added. av_unused cannot break build
> > > #ifs also make the code harder to read, especially if there are
> > > already some #ifs there before
> > >
> > > #ifs make sense for non static symbols as they cannot be removed by
> > > the compiler or linker generally
> > >
> > > #ifs could also be used to structure code in a file if for some
> > > reason its unwanted to split it in several files
> > > #ifs also gurantee that code is removed and this makes sense in
> > > performance critical code
> > > #ifs can be used for any group of lines not just functions/variables
> > > as for av_unused
> >
> >
> > Michael, how strong is your objection here? Me and wm4 seem to have a
> > slight preference for #if over av_unused, since av_unused runs the risk
> of
> > rotting with code over time.
>
> iam almost neutral to the #if vs ununsed vs nothing question.
> i just felt that av_unused would be less work to maintain than #if,
> iam fine with any of the 3


It seems like nobody has objections to this approach, and a few have
expressed minor unease with wide usage of av_unused for this, so I've
applied this version.

Thanks Ganesh!

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

Re: [FFmpeg-devel] [PATCHv2] ffplay: more robust mutex creation

[Marton Balint]

On Sun, 4 Oct 2015, Ganesh Ajjanagadde wrote:


SDL_CreateMutex can fail:
https://wiki.libsdl.org/SDL_CreateMutex.
This patch makes creation more robust in one instance.

Signed-off-by: Ganesh Ajjanagadde 
---
ffplay.c | 6 ++
1 file changed, 6 insertions(+)

diff --git a/ffplay.c b/ffplay.c
index c5a7895..84bd6ee 100644
--- a/ffplay.c
+++ b/ffplay.c
@@ -2817,6 +2817,12 @@ static int read_thread(void *arg)
int scan_all_pmts_set = 0;
int64_t pkt_ts;

+if (!wait_mutex) {
+av_log(is, AV_LOG_FATAL, "SDL_CreateMutex(): %s\n", SDL_GetError());


VideoState has no AVClass, are you sure this works? All other instances 
use NULL.


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

Re: [FFmpeg-devel] [PATCH] concatdec: fix metadata memleak on error

[Ronald S. Bultje]

Hi,

On Sat, Oct 3, 2015 at 5:59 PM, Marton Balint  wrote:

> Fixes Coverity CID 1323077.
>
> Signed-off-by: Marton Balint 
> ---
>  libavformat/concatdec.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/libavformat/concatdec.c b/libavformat/concatdec.c
> index 88b6dbe..832b7f4 100644
> --- a/libavformat/concatdec.c
> +++ b/libavformat/concatdec.c
> @@ -389,16 +389,16 @@ static int concat_read_header(AVFormatContext *avf)
>  file->outpoint = dur;
>  } else if (!strcmp(keyword, "file_packet_metadata")) {
>  char *metadata;
> -metadata = av_get_token((const char **), SPACE_CHARS);
> -if (!metadata) {
> -av_log(avf, AV_LOG_ERROR, "Line %d: packet metadata
> required\n", line);
> -FAIL(AVERROR_INVALIDDATA);
> -}
>  if (!file) {
>  av_log(avf, AV_LOG_ERROR, "Line %d: %s without file\n",
> line, keyword);
>  FAIL(AVERROR_INVALIDDATA);
>  }
> +metadata = av_get_token((const char **), SPACE_CHARS);
> +if (!metadata) {
> +av_log(avf, AV_LOG_ERROR, "Line %d: packet metadata
> required\n", line);
> +FAIL(AVERROR_INVALIDDATA);
> +}
>  if ((ret = av_dict_parse_string(>metadata, metadata,
> "=", "", 0)) < 0) {
>  av_log(avf, AV_LOG_ERROR, "Line %d: failed to parse
> metadata string\n", line);
>  av_freep();
> --
> 2.1.4


OK.

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

[FFmpeg-devel] [PATCH] avfilter/vf_stereo3d: add x86 SIMD for anaglyph outputs

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---
 libavfilter/stereo3d.h |  36 
 libavfilter/vf_stereo3d.c  |  70 ---
 libavfilter/x86/Makefile   |   2 +
 libavfilter/x86/vf_stereo3d.asm| 172 +
 libavfilter/x86/vf_stereo3d_init.c |  37 
 5 files changed, 285 insertions(+), 32 deletions(-)
 create mode 100644 libavfilter/stereo3d.h
 create mode 100644 libavfilter/x86/vf_stereo3d.asm
 create mode 100644 libavfilter/x86/vf_stereo3d_init.c

diff --git a/libavfilter/stereo3d.h b/libavfilter/stereo3d.h
new file mode 100644
index 000..e7a8456
--- /dev/null
+++ b/libavfilter/stereo3d.h
@@ -0,0 +1,36 @@
+/*
+ * Copyright (c) 2015 Paul B Mahol
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#ifndef LIBAVFILTER_STEREO3D_H
+#define LIBAVFILTER_STEREO3D_H
+
+#include 
+#include 
+
+typedef struct Stereo3DDSPContext {
+void (*anaglyph)(uint8_t *dst, uint8_t *lsrc, uint8_t *rsrc,
+ ptrdiff_t dst_linesize, ptrdiff_t l_linesize, ptrdiff_t 
r_linesize,
+ int width, int height,
+ const int *ana_matrix_r, const int *ana_matrix_g, const 
int *ana_matrix_b);
+} Stereo3DDSPContext;
+
+void ff_stereo3d_init_x86(Stereo3DDSPContext *dsp);
+
+#endif /* LIBAVFILTER_STEREO3D_H */
diff --git a/libavfilter/vf_stereo3d.c b/libavfilter/vf_stereo3d.c
index f9d344a..8e9cc83 100644
--- a/libavfilter/vf_stereo3d.c
+++ b/libavfilter/vf_stereo3d.c
@@ -30,6 +30,7 @@
 #include "formats.h"
 #include "internal.h"
 #include "video.h"
+#include "stereo3d.h"
 
 enum StereoCode {
 ANAGLYPH_RC_GRAY,   // anaglyph red/cyan gray
@@ -150,6 +151,7 @@ typedef struct Stereo3DContext {
 double ts_unit;
 int blanks;
 int in_off_left[4], in_off_right[4];
+Stereo3DDSPContext dsp;
 } Stereo3DContext;
 
 #define OFFSET(x) offsetof(Stereo3DContext, x)
@@ -300,6 +302,37 @@ static int query_formats(AVFilterContext *ctx)
 return ff_set_common_formats(ctx, fmts_list);
 }
 
+static inline uint8_t ana_convert(const int *coeff, const uint8_t *left, const 
uint8_t *right)
+{
+int sum;
+
+sum  = coeff[0] * left[0] + coeff[3] * right[0]; //red in
+sum += coeff[1] * left[1] + coeff[4] * right[1]; //green in
+sum += coeff[2] * left[2] + coeff[5] * right[2]; //blue in
+
+return av_clip_uint8(sum >> 16);
+}
+
+static void anaglyph(uint8_t *dst, uint8_t *lsrc, uint8_t *rsrc,
+ ptrdiff_t dst_linesize, ptrdiff_t l_linesize, ptrdiff_t 
r_linesize,
+ int width, int height,
+ const int *ana_matrix_r, const int *ana_matrix_g, const 
int *ana_matrix_b)
+{
+int x, y, o;
+
+for (y = 0; y < height; y++) {
+for (o = 0, x = 0; x < width; x++, o+= 3) {
+dst[o] = ana_convert(ana_matrix_r, lsrc + o, rsrc + o);
+dst[o + 1] = ana_convert(ana_matrix_g, lsrc + o, rsrc + o);
+dst[o + 2] = ana_convert(ana_matrix_b, lsrc + o, rsrc + o);
+}
+
+dst  += dst_linesize;
+lsrc += l_linesize;
+rsrc += r_linesize;
+}
+}
+
 static int config_output(AVFilterLink *outlink)
 {
 AVFilterContext *ctx = outlink->src;
@@ -517,38 +550,11 @@ static int config_output(AVFilterLink *outlink)
 s->hsub = desc->log2_chroma_w;
 s->vsub = desc->log2_chroma_h;
 
-return 0;
-}
-
-static inline uint8_t ana_convert(const int *coeff, const uint8_t *left, const 
uint8_t *right)
-{
-int sum;
-
-sum  = coeff[0] * left[0] + coeff[3] * right[0]; //red in
-sum += coeff[1] * left[1] + coeff[4] * right[1]; //green in
-sum += coeff[2] * left[2] + coeff[5] * right[2]; //blue in
-
-return av_clip_uint8(sum >> 16);
-}
+s->dsp.anaglyph = anaglyph;
+if (ARCH_X86)
+ff_stereo3d_init_x86(>dsp);
 
-static void anaglyph(uint8_t *dst, uint8_t *lsrc, uint8_t *rsrc,
- ptrdiff_t dst_linesize, ptrdiff_t l_linesize, ptrdiff_t 
r_linesize,
- int width, int height,
- const int *ana_matrix_r, const int *ana_matrix_g, const 
int *ana_matrix_b)
-{
-int x, y, o;
-
-for (y = 0; y < height; y++) {
-for (o = 0, x = 0; x < width; x++, o+= 3) {
-dst[o

Re: [FFmpeg-devel] [PATCH]select attribute of tee pseudo demuxer may contain multiple stream specifiers

[Nicolas George]

Le tridi 13 vendémiaire, an CCXXIV, Bodecs Bela a écrit :
> git format-patch -n -o /tmp/ --attach  origin

Thanks. Any particular reason to use --attach? It is not a big issue, just a
matter of curiosity.

> >>@@ -172,15 +175,26 @@ static int open_slave(AVFormatContext *avf, char 
> >>*slave, TeeSlave *tee_slave)
> >>  for (i = 0; i < avf->nb_streams; i++) {
> >>  st = avf->streams[i];
> >>  if (select) {
> >>-ret = avformat_match_stream_specifier(avf, avf->streams[i], 
> >>select);
> >>-if (ret < 0) {
> >>-av_log(avf, AV_LOG_ERROR,
> >>-   "Invalid stream specifier '%s' for output '%s'\n",
> >>-   select, slave);
> >>-goto end;
> >>-}
> >>+fullret = 0;
> >>+first_subselect = select;
> >>+next_subselect = NULL;
> >>+while (subselect = av_strtok(first_subselect, 
> >>slave_select_sep, _subselect)) {
> >>+first_subselect = NULL;

> You would be right unless I used
> 
> first_subselect = NULL;
> 
> right after the while statement, so the next round av_strtok will go
> further, because the first parameter will be null, not the same string and
> next_subselect will point the next start.
> Yes it is destructive, but we never use this string (select) again in this
> function.

I suspect we are talking at cross-purpose here. The "first_subselect = NULL"
you are talking about is in the while loop for av_strtok(), it is indeed the
normal way of using av_strtok().

But I was talking about the surrounding for loop that goes over all the
streams. I left the code quoted above for reference. For i=0, the code is
valid, but as soon as i>=1, "first_subselect = select" will use a truncated
string

> I swear, I have really tested it, I use it on my own  in my production
> environment.

I do not believe that you neglected to test it (nor that you are lying, of
course!), I am just really surprised. Just to be sure, I just tested, adding
a debug log just after "first_subselect = select", with the following
command-line:

./ffmpeg_g -lavfi 'testsrc=r=5;testsrc=r=7;testsrc=r=11' \
  -c:v rawvideo -f tee '[f=framecrc:select=0,1]-'

I get the following output:

select = '0,1'
select = '0'
Last message repeated 1 times
[tee @ 0x36143e0] Input stream #1 is not mapped to any slave.
[tee @ 0x36143e0] Input stream #2 is not mapped to any slave.

The second "select =" line shows that it is working with a truncated line,
and stream #1 should be mapped. Indeed, if I swap the specifiers: "1,0", it
maps #0 and #1: #0 is matched first while the string is still intact, #1 is
matched by the truncated string.

Regards,

-- 
  Nicolas George


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

[FFmpeg-devel] [PATCH] libavformat/tls_securetransport: fix argument evalulation order UB

[Rodger Combs]

---
 libavformat/tls_securetransport.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/libavformat/tls_securetransport.c 
b/libavformat/tls_securetransport.c
index 73662d7..6ad266a 100644
--- a/libavformat/tls_securetransport.c
+++ b/libavformat/tls_securetransport.c
@@ -350,8 +350,9 @@ static int map_ssl_error(OSStatus status, size_t processed)
 static int tls_read(URLContext *h, uint8_t *buf, int size)
 {
 TLSContext *c = h->priv_data;
-size_t processed;
-int ret = map_ssl_error(SSLRead(c->ssl_context, buf, size, ), 
processed);
+size_t processed = 0;
+int ret = SSLRead(c->ssl_context, buf, size, );
+ret = map_ssl_error(ret, processed);
 if (ret > 0)
 return ret;
 if (ret == 0)
@@ -362,8 +363,9 @@ static int tls_read(URLContext *h, uint8_t *buf, int size)
 static int tls_write(URLContext *h, const uint8_t *buf, int size)
 {
 TLSContext *c = h->priv_data;
-size_t processed;
-int ret = map_ssl_error(SSLWrite(c->ssl_context, buf, size, ), 
processed);
+size_t processed = 0;
+int ret = SSLWrite(c->ssl_context, buf, size, );
+ret = map_ssl_error(ret, processed);
 if (ret > 0)
 return ret;
 if (ret == 0)
-- 
2.6.0

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

Re: [FFmpeg-devel] [PATCH] checkasm: add alacdsp tests

[Henrik Gramner]

On Sun, Oct 4, 2015 at 8:45 PM, James Almer  wrote:
> +#define randomize_buffers()\
> +do {   \
> +int i; \
> +for (i = 0; i < BUF_SIZE * MAX_CHANNELS; i += 4) { \
> +uint32_t r = rnd() & 0x7F; \
> +AV_WN32A(ref_buf + i, r);  \
> +AV_WN32A(new_buf + i, r);  \
> +}  \
> +} while (0)

No negative values possible even though the type is int32_t?

> +static void check_decorrelate_stereo(void)
[...]
> +LOCAL_ALIGNED_16(uint8_t, ref_buf, [BUF_SIZE*MAX_CHANNELS]);
> +LOCAL_ALIGNED_16(uint8_t, new_buf, [BUF_SIZE*MAX_CHANNELS]);
> +uint8_t *ref[] = { _buf[BUF_SIZE*0], _buf[BUF_SIZE*1] };
> +uint8_t *new[] = { _buf[BUF_SIZE*0], _buf[BUF_SIZE*1] };

Wouldn't int32_t instead of uint8_t simplify things a lot? Then there
wouldn't be any need to typecast things later on and the AV_WN32A
stuff could be dropped from randomize_buffers().

> +call_ref((int32_t **)ref, BUF_SIZE / sizeof(int32_t), shift, weight);
> +call_new((int32_t **)new, BUF_SIZE / sizeof(int32_t), shift, weight);

Can len be a value that isn't mod16? If so then that parameter could
be randomized within certain constraints to test that behavior as
well.

All above points apply to append_extra_bits as well.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavformat/tls_securetransport: fix argument evalulation order UB

[Michael Niedermayer]

On Sun, Oct 04, 2015 at 02:37:52PM -0500, Rodger Combs wrote:
> ---
>  libavformat/tls_securetransport.c | 10 ++
>  1 file changed, 6 insertions(+), 4 deletions(-)

applied

thanks

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

Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data


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

[FFmpeg-devel] [PATCH] checkasm: add alacdsp tests

[James Almer]

Signed-off-by: James Almer 
---
 tests/checkasm/Makefile   |   1 +
 tests/checkasm/alacdsp.c  | 114 ++
 tests/checkasm/checkasm.c |   3 ++
 tests/checkasm/checkasm.h |   1 +
 4 files changed, 119 insertions(+)
 create mode 100644 tests/checkasm/alacdsp.c

diff --git a/tests/checkasm/Makefile b/tests/checkasm/Makefile
index f30e9c4..bf0dc9f 100644
--- a/tests/checkasm/Makefile
+++ b/tests/checkasm/Makefile
@@ -1,4 +1,5 @@
 # libavcodec tests
+AVCODECOBJS-$(CONFIG_ALAC_DECODER)  += alacdsp.o
 AVCODECOBJS-$(CONFIG_BSWAPDSP) += bswapdsp.o
 AVCODECOBJS-$(CONFIG_FLACDSP)  += flacdsp.o
 AVCODECOBJS-$(CONFIG_H264PRED) += h264pred.o
diff --git a/tests/checkasm/alacdsp.c b/tests/checkasm/alacdsp.c
new file mode 100644
index 000..a321b3b
--- /dev/null
+++ b/tests/checkasm/alacdsp.c
@@ -0,0 +1,114 @@
+/*
+ * Copyright (c) 2015 James Almer
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with FFmpeg; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+ */
+
+#include 
+#include "checkasm.h"
+#include "libavcodec/alacdsp.h"
+#include "libavutil/common.h"
+#include "libavutil/internal.h"
+#include "libavutil/intreadwrite.h"
+
+#define BUF_SIZE 1024
+#define MAX_CHANNELS 2
+
+#define randomize_buffers()\
+do {   \
+int i; \
+for (i = 0; i < BUF_SIZE * MAX_CHANNELS; i += 4) { \
+uint32_t r = rnd() & 0x7FFF;   \
+AV_WN32A(ref_buf + i, r);  \
+AV_WN32A(new_buf + i, r);  \
+}  \
+} while (0)
+
+static void check_decorrelate_stereo(void)
+{
+LOCAL_ALIGNED_16(uint8_t, ref_buf, [BUF_SIZE*MAX_CHANNELS]);
+LOCAL_ALIGNED_16(uint8_t, new_buf, [BUF_SIZE*MAX_CHANNELS]);
+uint8_t *ref[] = { _buf[BUF_SIZE*0], _buf[BUF_SIZE*1] };
+uint8_t *new[] = { _buf[BUF_SIZE*0], _buf[BUF_SIZE*1] };
+ALACDSPContext c;
+
+ff_alacdsp_init();
+if (check_func(c.decorrelate_stereo, "alac_decorrelate_stereo")) {
+int shift = rnd() & 0x1F;
+declare_func(void, int32_t **buf, int len, int shift, int weight);
+
+randomize_buffers();
+call_ref((int32_t **)ref, BUF_SIZE / sizeof(int32_t), shift, 1);
+call_new((int32_t **)new, BUF_SIZE / sizeof(int32_t), shift, 1);
+if (memcmp(*ref, *new, BUF_SIZE * MAX_CHANNELS))
+fail();
+bench_new((int32_t **)new, BUF_SIZE / sizeof(int32_t), shift, 1);
+}
+
+report("decorrelate_stereo");
+}
+
+#undef randomize_buffers
+#define randomize_buffers()\
+do {   \
+int i, j;  \
+for (i = 0; i < BUF_SIZE; i += 4) {\
+for (j = 0; j < ch; j++) { \
+uint32_t r = rnd() & 0x7F; \
+AV_WN32A(ref[j] + i, r);   \
+AV_WN32A(new[j] + i, r);   \
+r = rnd() & 0xFF;  \
+AV_WN32A(ref_ebb[j] + i, r);   \
+AV_WN32A(new_ebb[j] + i, r);   \
+}  \
+}  \
+} while (0)
+
+static void check_append_extra_bits(void)
+{
+LOCAL_ALIGNED_16(uint8_t, ref_buf, [BUF_SIZE*MAX_CHANNELS*2]);
+LOCAL_ALIGNED_16(uint8_t, new_buf, [BUF_SIZE*MAX_CHANNELS*2]);
+uint8_t *ref[] = { _buf[BUF_SIZE*0], _buf[BUF_SIZE*1] };
+uint8_t *new[] = { _buf[BUF_SIZE*0], _buf[BUF_SIZE*1] };
+uint8_t *ref_ebb[] = { _buf[BUF_SIZE*2], _buf[BUF_SIZE*3] };
+uint8_t *new_ebb[] = { _buf[BUF_SIZE*2], _buf[BUF_SIZE*3] };
+ALACDSPContext c;
+static const char * const channels[2] = { "mono", "stereo" };
+int ch;
+
+ff_alacdsp_init();
+for (ch = 1; ch <= 2; ch++) {
+if (check_func(c.append_extra_bits[ch-1], "alac_append_extra_bits_%s", 
channels[ch-1])) {
+declare_func(void, int32_t **buf, int32_t **ebb, int ebits, int 
ch, int len);
+
+randomize_buffers();
+call_ref((int32_t **)ref, (int32_t **)ref_ebb, 8, ch, BUF_SIZE / 
sizeof(int32_t));
+call_new((int32_t **)new, (int32_t 

Re: [FFmpeg-devel] [PATCH]select attribute of tee pseudo demuxer may contain multiple stream specifiers

[Bodecs Bela]

2015.10.04. 20:06 keltezéssel, Nicolas George írta:

Le tridi 13 vendémiaire, an CCXXIV, Bodecs Bela a écrit :

git format-patch -n -o /tmp/ --attach  origin

Thanks. Any particular reason to use --attach? It is not a big issue, just a
matter of curiosity.
I thought I should use it this way to be able to send the created patch 
file later with any mailer.





@@ -172,15 +175,26 @@ static int open_slave(AVFormatContext *avf, char *slave, 
TeeSlave *tee_slave)
  for (i = 0; i < avf->nb_streams; i++) {
  st = avf->streams[i];
  if (select) {
-ret = avformat_match_stream_specifier(avf, avf->streams[i], 
select);
-if (ret < 0) {
-av_log(avf, AV_LOG_ERROR,
-   "Invalid stream specifier '%s' for output '%s'\n",
-   select, slave);
-goto end;
-}
+fullret = 0;
+first_subselect = select;
+next_subselect = NULL;
+while (subselect = av_strtok(first_subselect, slave_select_sep, 
_subselect)) {
+first_subselect = NULL;

You would be right unless I used

first_subselect = NULL;

right after the while statement, so the next round av_strtok will go
further, because the first parameter will be null, not the same string and
next_subselect will point the next start.
Yes it is destructive, but we never use this string (select) again in this
function.

I suspect we are talking at cross-purpose here. The "first_subselect = NULL"
you are talking about is in the while loop for av_strtok(), it is indeed the
normal way of using av_strtok().

But I was talking about the surrounding for loop that goes over all the
streams. I left the code quoted above for reference. For i=0, the code is
valid, but as soon as i>=1, "first_subselect = select" will use a truncated
string


I swear, I have really tested it, I use it on my own  in my production
environment.

I do not believe that you neglected to test it (nor that you are lying, of
course!), I am just really surprised. Just to be sure, I just tested, adding
a debug log just after "first_subselect = select", with the following
command-line:

./ffmpeg_g -lavfi 'testsrc=r=5;testsrc=r=7;testsrc=r=11' \
   -c:v rawvideo -f tee '[f=framecrc:select=0,1]-'

I get the following output:

select = '0,1'
select = '0'
 Last message repeated 1 times
[tee @ 0x36143e0] Input stream #1 is not mapped to any slave.
[tee @ 0x36143e0] Input stream #2 is not mapped to any slave.

The second "select =" line shows that it is working with a truncated line,
and stream #1 should be mapped. Indeed, if I swap the specifiers: "1,0", it
maps #0 and #1: #0 is matched first while the string is still intact, #1 is
matched by the truncated string.

Regards,




you are right. It is my mistake that I did not test it thoughtfully. It 
was bad luck why I did not receive error still now.
I will correct the patch  as soon as possible and send it again. I think 
I will use the av_strdup() to correct it. (and av_free, of course)


thank you,

Bela Bodecs



___
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]vc1 Autodetection

[Carl Eugen Hoyos]

Hi!

Attached is a patch implementing vc-1 autodetection.

Please review, Carl Eugen
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 2971912..d118019 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -440,7 +440,7 @@ OBJS-$(CONFIG_TTA_DEMUXER)   += tta.o apetag.o 
img2.o
 OBJS-$(CONFIG_TTY_DEMUXER)   += tty.o sauce.o
 OBJS-$(CONFIG_TXD_DEMUXER)   += txd.o
 OBJS-$(CONFIG_UNCODEDFRAMECRC_MUXER) += uncodedframecrcenc.o framehash.o
-OBJS-$(CONFIG_VC1_DEMUXER)   += rawdec.o
+OBJS-$(CONFIG_VC1_DEMUXER)   += rawdec.o vc1dec.o
 OBJS-$(CONFIG_VC1_MUXER) += rawenc.o
 OBJS-$(CONFIG_VC1T_DEMUXER)  += vc1test.o
 OBJS-$(CONFIG_VC1T_MUXER)+= vc1testenc.o
diff --git a/libavformat/rawdec.c b/libavformat/rawdec.c
index 16fb221..7098ebd 100644
--- a/libavformat/rawdec.c
+++ b/libavformat/rawdec.c
@@ -205,7 +205,3 @@ static int mjpeg_probe(AVProbeData *p)
 
 FF_DEF_RAWVIDEO_DEMUXER2(mjpeg, "raw MJPEG video", mjpeg_probe, 
"mjpg,mjpeg,mpo", AV_CODEC_ID_MJPEG, AVFMT_GENERIC_INDEX|AVFMT_NOTIMESTAMPS)
 #endif
-
-#if CONFIG_VC1_DEMUXER
-FF_DEF_RAWVIDEO_DEMUXER2(vc1, "raw VC-1", NULL, "vc1", AV_CODEC_ID_VC1, 
AVFMT_GENERIC_INDEX|AVFMT_NOTIMESTAMPS)
-#endif
diff --git a/libavformat/vc1dec.c b/libavformat/vc1dec.c
index e69de29..580c166 100644
--- a/libavformat/vc1dec.c
+++ b/libavformat/vc1dec.c
@@ -0,0 +1,71 @@
+/*
+ * VC-1 demuxer
+ * Copyright (c) 2015 Carl Eugen Hoyos
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "avformat.h"
+#include "rawdec.h"
+#include "libavutil/intreadwrite.h"
+#include "libavcodec/vc1_common.h"
+
+static int vc1_probe(AVProbeData *p)
+{
+int seq = 0, entry = 0, frame = 0, i;
+int profile, level, chromaformat;
+
+for (i = 0; i < p->buf_size + 5; i++) {
+uint32_t code = AV_RB32(p->buf + i);
+if ((code & 0xffe0) == 0x100) {
+int type = code & 0x11F;
+i += 4;
+switch (type) {
+case VC1_CODE_SEQHDR: {
+profile = (p->buf[i] & 0xc0) >> 6;
+if (profile != PROFILE_ADVANCED)
+continue;
+level = (p->buf[i] & 0x38) >> 3;
+if (level >= 5)
+continue;
+chromaformat = (p->buf[i] & 0x6) >> 1;
+if (chromaformat != 1)
+continue;
+seq++;
+i += 6;
+break;
+}
+case VC1_CODE_ENTRYPOINT:
+entry++;
+i += 2;
+break;
+case VC1_CODE_FRAME:
+case VC1_CODE_FIELD:
+case VC1_CODE_SLICE:
+if (seq && entry)
+frame++;
+break;
+}
+}
+}
+
+if (frame)
+return AVPROBE_SCORE_EXTENSION + 1;
+return 0;
+}
+
+FF_DEF_RAWVIDEO_DEMUXER2(vc1, "raw VC-1", vc1_probe, "vc1", AV_CODEC_ID_VC1, 
AVFMT_GENERIC_INDEX|AVFMT_NOTIMESTAMPS)
diff --git a/libavformat/version.h b/libavformat/version.h
index f7a2e09..76e2f55 100644
--- a/libavformat/version.h
+++ b/libavformat/version.h
@@ -31,7 +31,7 @@
 
 #define LIBAVFORMAT_VERSION_MAJOR  57
 #define LIBAVFORMAT_VERSION_MINOR   3
-#define LIBAVFORMAT_VERSION_MICRO 100
+#define LIBAVFORMAT_VERSION_MICRO 101
 
 #define LIBAVFORMAT_VERSION_INT AV_VERSION_INT(LIBAVFORMAT_VERSION_MAJOR, \
LIBAVFORMAT_VERSION_MINOR, \
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/alacdec: split off decorrelate_stereo and append_extra_bits as alacdsp

[Timothy Gu]

On Sun, Oct 4, 2015 at 2:21 PM Michael Niedermayer  wrote:

> there is a spec ?
>

Don't think so for the codec itself.


> i only know of soe reference source code and i looked yesterday
> and it usesed the full 8 bits unless i missed something
>

 https://alac.macosforge.org/trac/browser/trunk/codec/ALACEncoder.cpp says
that mixRes (aka decorr_left_weight) can be up to 4.

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

Re: [FFmpeg-devel] [PATCHv2] ffplay: more robust mutex creation

[Ganesh Ajjanagadde]

On Sun, Oct 4, 2015 at 6:47 PM, Marton Balint  wrote:
>
>
> On Sun, 4 Oct 2015, Ganesh Ajjanagadde wrote:
>
>> On Sun, Oct 4, 2015 at 12:47 PM, Marton Balint  wrote:
>>>
>>>
>>>
>>> On Sun, 4 Oct 2015, Ganesh Ajjanagadde wrote:
>>>
 SDL_CreateMutex can fail:
 https://wiki.libsdl.org/SDL_CreateMutex.
 This patch makes creation more robust in one instance.

 Signed-off-by: Ganesh Ajjanagadde 
 ---
 ffplay.c | 6 ++
 1 file changed, 6 insertions(+)

 diff --git a/ffplay.c b/ffplay.c
 index c5a7895..84bd6ee 100644
 --- a/ffplay.c
 +++ b/ffplay.c
 @@ -2817,6 +2817,12 @@ static int read_thread(void *arg)
 int scan_all_pmts_set = 0;
 int64_t pkt_ts;

 +if (!wait_mutex) {
 +av_log(is, AV_LOG_FATAL, "SDL_CreateMutex(): %s\n",
 SDL_GetError());
>>>
>>>
>>>
>>> VideoState has no AVClass, are you sure this works? All other instances
>>> use
>>> NULL.
>>
>>
>> Entirely possible; I just (naively) assumed logging does some magic
>> e.g void* pointers or something like that. You can use v1 then.
>
>
> Applied v1. The other paches you sent seems to have the same problem, and I
> just noticed that some of your earlier patches I have already applied also
> has this issue. Could you please send fixes for those as well?
>
> Also send a patch series if you can, it is easier for me to review.

Thanks for the review. I have sent a complete patch series now with
the fixes to the old commits and the new patches. I have squashed the
introduction of error messages into a single patch, as logically it is
a single change.

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

Re: [FFmpeg-devel] [PATCHv2] avcodec/dvenc: silence -Wdiscarded-qualifiers

[Ganesh Ajjanagadde]

On Sun, Sep 20, 2015 at 9:09 AM, Ganesh Ajjanagadde
 wrote:
> s->frame is non-const, so this casts them explicitly.
> This suppresses -Wdiscarded-qualifiers seen in e.g
> http://fate.ffmpeg.org/log.cgi?time=20150919100330=compile=x86_64-archlinux-gcc-enableshared.
>
> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  libavcodec/dvenc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/dvenc.c b/libavcodec/dvenc.c
> index 5de12cc..14b8758 100644
> --- a/libavcodec/dvenc.c
> +++ b/libavcodec/dvenc.c
> @@ -721,7 +721,7 @@ static int dvvideo_encode_frame(AVCodecContext *c, 
> AVPacket *pkt,
>  return ret;
>
>  c->pix_fmt= s->sys->pix_fmt;
> -s->frame  = frame;
> +s->frame  = (AVFrame *)frame;
>  #if FF_API_CODED_FRAME
>  FF_DISABLE_DEPRECATION_WARNINGS
>  c->coded_frame->key_frame = 1;
> --
> 2.5.2
>

ping. I do not know whether there is a better way of doing this that
avoids the cast; hopefully someone with expertise on this can check.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 3/3] ffplay: use correct context for av_log

[Ganesh Ajjanagadde]

Recent commits c3e8de1c248f8c742dd9e61a0c71ee56bba22c28 and
8dc6e92c3dc67a85026f3010045c7a28b1c0adc8 used av_log incorrectly.
This fixes such usage.

Signed-off-by: Ganesh Ajjanagadde 
---
 ffplay.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/ffplay.c b/ffplay.c
index cf0640e..79f430d 100644
--- a/ffplay.c
+++ b/ffplay.c
@@ -456,12 +456,12 @@ static int packet_queue_init(PacketQueue *q)
 memset(q, 0, sizeof(PacketQueue));
 q->mutex = SDL_CreateMutex();
 if (!q->mutex) {
-av_log(q, AV_LOG_FATAL, "SDL_CreateMutex(): %s\n", SDL_GetError());
+av_log(NULL, AV_LOG_FATAL, "SDL_CreateMutex(): %s\n", SDL_GetError());
 return AVERROR(ENOMEM);
 }
 q->cond = SDL_CreateCond();
 if (!q->cond) {
-av_log(q, AV_LOG_FATAL, "SDL_CreateCond(): %s\n", SDL_GetError());
+av_log(NULL, AV_LOG_FATAL, "SDL_CreateCond(): %s\n", SDL_GetError());
 return AVERROR(ENOMEM);
 }
 q->abort_request = 1;
@@ -2089,7 +2089,7 @@ static int decoder_start(Decoder *d, int (*fn)(void *), 
void *arg)
 packet_queue_start(d->queue);
 d->decoder_tid = SDL_CreateThread(fn, arg);
 if (!d->decoder_tid) {
-av_log(d, AV_LOG_ERROR, "SDL_CreateThread(): %s\n", SDL_GetError());
+av_log(NULL, AV_LOG_ERROR, "SDL_CreateThread(): %s\n", SDL_GetError());
 return AVERROR(ENOMEM);
 }
 return 0;
-- 
2.6.0

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

Re: [FFmpeg-devel] [PATCH] avfilter/vf_stereo3d: add x86 SIMD for anaglyph outputs

[Ronald S. Bultje]

Hi,

On Sun, Oct 4, 2015 at 3:46 PM, Paul B Mahol  wrote:

> +.loop:
> +movd m10, [ana_matrix_rq+ 0]
> +movd m11, [ana_matrix_rq+ 4]
> +movd m12, [ana_matrix_rq+ 8]
> +movd m13, [ana_matrix_rq+12]
> +movd m14, [ana_matrix_rq+16]
> +movd m15, [ana_matrix_rq+20]
> +pshufd   m10, m10, q
> +pshufd   m11, m11, q
> +pshufd   m12, m12, q
> +pshufd   m13, m13, q
> +pshufd   m14, m14, q
> +pshufd   m15, m15, q
>
[..]

> +movd m10, [ana_matrix_bq+ 0]
> +movd m11, [ana_matrix_bq+ 4]
> +movd m12, [ana_matrix_bq+ 8]
> +movd m13, [ana_matrix_bq+12]
> +movd m14, [ana_matrix_bq+16]
> +movd m15, [ana_matrix_bq+20]
> +pshufd   m10, m10, q
> +pshufd   m11, m11, q
> +pshufd   m12, m12, q
> +pshufd   m13, m13, q
> +pshufd   m14, m14, q
> +pshufd   m15, m15, q
>

So, you want more registers, right? :-D. OK, so let's talk stack usage. you
want aligned stack here to put all these constants so you don't need to
recreate them in each loop cycle iteration.

change:
cglobal name, n_args, n_gprs, n_xmms, arg1, arg2, arg3
to:
cglobal name, n_args, n_gprs, n_xmms, aligned_memory_in_bytes, arg1, arg2,
arg3

In your case, add memory of 6*mmsize*3.

Now, in the function, prepare the stack space first:

movd m10, [ana_matrix_rq+0]
[etc for the other r args]
pshufd m10, m10, q
[etc for the other r args]
mova [rsp+mmsize*0], m10
[etc for the others into rsp+mmsize*1-5]

now do the same for g/b in mmsize*6-11 and 12-17

Now as pshufb argument, use [rsp+mmsize*0-17].

> +packusdw m1, m1
> +packuswb m1, m1
> +pshufb   m7, m1, [rshuf]

Try to do r/g/b all at the same time (especially now that you have more
registers available since m10-15 are free), and packusdw r/g together, and
then packuswb r/g and b/nothing together, so that you have a single output
register instead of 3. That saves you the pors at the end also.

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

Re: [FFmpeg-devel] [PATCH] concatdec: fix metadata memleak on error

[Marton Balint]

On Sun, 4 Oct 2015, Nicolas George wrote:


Le duodi 12 vendémiaire, an CCXXIV, Marton Balint a écrit :

Fixes Coverity CID 1323077.

Signed-off-by: Marton Balint 
---
 libavformat/concatdec.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)


Sorry, missed it in my inbox. LGTM too.


Thanks, pushed.

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

Re: [FFmpeg-devel] [PATCHv2] ffplay: more robust mutex creation

[Marton Balint]

On Sun, 4 Oct 2015, Ganesh Ajjanagadde wrote:


On Sun, Oct 4, 2015 at 12:47 PM, Marton Balint  wrote:



On Sun, 4 Oct 2015, Ganesh Ajjanagadde wrote:


SDL_CreateMutex can fail:
https://wiki.libsdl.org/SDL_CreateMutex.
This patch makes creation more robust in one instance.

Signed-off-by: Ganesh Ajjanagadde 
---
ffplay.c | 6 ++
1 file changed, 6 insertions(+)

diff --git a/ffplay.c b/ffplay.c
index c5a7895..84bd6ee 100644
--- a/ffplay.c
+++ b/ffplay.c
@@ -2817,6 +2817,12 @@ static int read_thread(void *arg)
int scan_all_pmts_set = 0;
int64_t pkt_ts;

+if (!wait_mutex) {
+av_log(is, AV_LOG_FATAL, "SDL_CreateMutex(): %s\n",
SDL_GetError());



VideoState has no AVClass, are you sure this works? All other instances use
NULL.


Entirely possible; I just (naively) assumed logging does some magic
e.g void* pointers or something like that. You can use v1 then.


Applied v1. The other paches you sent seems to have the same problem, and 
I just noticed that some of your earlier patches I have already applied 
also has this issue. Could you please send fixes for those as well?


Also send a patch series if you can, it is easier for me to review.

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

[FFmpeg-devel] [PATCH] checkasm: add alacdsp tests

[James Almer]

Signed-off-by: James Almer 
---
 tests/checkasm/Makefile   |   1 +
 tests/checkasm/alacdsp.c  | 119 ++
 tests/checkasm/checkasm.c |   3 ++
 tests/checkasm/checkasm.h |   1 +
 4 files changed, 124 insertions(+)
 create mode 100644 tests/checkasm/alacdsp.c

diff --git a/tests/checkasm/Makefile b/tests/checkasm/Makefile
index f30e9c4..c29ceef 100644
--- a/tests/checkasm/Makefile
+++ b/tests/checkasm/Makefile
@@ -1,4 +1,5 @@
 # libavcodec tests
+AVCODECOBJS-$(CONFIG_ALAC_DECODER) += alacdsp.o
 AVCODECOBJS-$(CONFIG_BSWAPDSP) += bswapdsp.o
 AVCODECOBJS-$(CONFIG_FLACDSP)  += flacdsp.o
 AVCODECOBJS-$(CONFIG_H264PRED) += h264pred.o
diff --git a/tests/checkasm/alacdsp.c b/tests/checkasm/alacdsp.c
new file mode 100644
index 000..cbf03f8
--- /dev/null
+++ b/tests/checkasm/alacdsp.c
@@ -0,0 +1,119 @@
+/*
+ * Copyright (c) 2015 James Almer
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with FFmpeg; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+ */
+
+#include 
+#include "checkasm.h"
+#include "libavcodec/alacdsp.h"
+#include "libavcodec/mathops.h"
+#include "libavutil/common.h"
+#include "libavutil/internal.h"
+
+#define BUF_SIZE 256
+#define MAX_CHANNELS 2
+
+#define randomize_buffers()   \
+do {  \
+int i;\
+for (i = 0; i < BUF_SIZE*MAX_CHANNELS; i++) { \
+int32_t r = sign_extend(rnd(), 24);   \
+ref_buf[i] = r;   \
+new_buf[i] = r;   \
+} \
+} while (0)
+
+static void check_decorrelate_stereo(void)
+{
+LOCAL_ALIGNED_16(int32_t, ref_buf, [BUF_SIZE*MAX_CHANNELS]);
+LOCAL_ALIGNED_16(int32_t, new_buf, [BUF_SIZE*MAX_CHANNELS]);
+int32_t *ref[2] = { _buf[BUF_SIZE*0], _buf[BUF_SIZE*1] };
+int32_t *new[2] = { _buf[BUF_SIZE*0], _buf[BUF_SIZE*1] };
+ALACDSPContext c;
+
+ff_alacdsp_init();
+if (check_func(c.decorrelate_stereo, "alac_decorrelate_stereo")) {
+int len= (rnd() & 0xFF) + 1;
+int shift  =  rnd() & 0x1F;
+int weight =  rnd() & 0xFF;
+declare_func(void, int32_t *buf[2], int len, int shift, int weight);
+
+randomize_buffers();
+call_ref(ref, len, shift, weight);
+call_new(new, len, shift, weight);
+if (memcmp(ref[0], new[0], len * sizeof(int32_t)) ||
+memcmp(ref[1], new[1], len * sizeof(int32_t)))
+fail();
+bench_new(new, BUF_SIZE, shift, weight);
+}
+
+report("decorrelate_stereo");
+}
+
+#undef randomize_buffers
+#define randomize_buffers()   \
+do {  \
+int i, j; \
+for (i = 0; i < BUF_SIZE; i++) {  \
+for (j = 0; j < ch; j++) {\
+int32_t r = sign_extend(rnd(), 24);   \
+ref[j][i] = r;\
+new[j][i] = r;\
+r = rnd() & 0xFF; \
+ref_ebb[j][i] = r;\
+new_ebb[j][i] = r;\
+} \
+} \
+} while (0)
+
+static void check_append_extra_bits(void)
+{
+LOCAL_ALIGNED_16(int32_t, ref_buf, [BUF_SIZE*MAX_CHANNELS*2]);
+LOCAL_ALIGNED_16(int32_t, new_buf, [BUF_SIZE*MAX_CHANNELS*2]);
+int32_t *ref[2] = { _buf[BUF_SIZE*0], _buf[BUF_SIZE*1] };
+int32_t *new[2] = { _buf[BUF_SIZE*0], _buf[BUF_SIZE*1] };
+int32_t *ref_ebb[2] = { _buf[BUF_SIZE*2], _buf[BUF_SIZE*3] };
+int32_t *new_ebb[2] = { _buf[BUF_SIZE*2], _buf[BUF_SIZE*3] };
+ALACDSPContext c;
+static const char * const channels[2] = { "mono", "stereo" };
+int ch;
+
+ff_alacdsp_init();
+for (ch = 1; ch <= 2; ch++) {
+if (check_func(c.append_extra_bits[ch-1], "alac_append_extra_bits_%s", 
channels[ch-1])) {
+int len= (rnd() & 0xFF) + 1;
+declare_func(void, int32_t *buf[2], int32_t *ebb[2], int ebits, 
int ch, int len);
+
+

[FFmpeg-devel] [PATCH 1/3] ffplay: log SDL error messages

[Ganesh Ajjanagadde]

This logs the SDL error messages on failure of creation of SDL_CreateMutex,
SDL_CreateCond, and SDL_CreateThread.

Signed-off-by: Ganesh Ajjanagadde 
---
 ffplay.c | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/ffplay.c b/ffplay.c
index 3223ceb..8c9f6b1 100644
--- a/ffplay.c
+++ b/ffplay.c
@@ -657,10 +657,14 @@ static int frame_queue_init(FrameQueue *f, PacketQueue 
*pktq, int max_size, int
 {
 int i;
 memset(f, 0, sizeof(FrameQueue));
-if (!(f->mutex = SDL_CreateMutex()))
+if (!(f->mutex = SDL_CreateMutex())) {
+av_log(NULL, AV_LOG_FATAL, "SDL_CreateMutex(): %s\n", SDL_GetError());
 return AVERROR(ENOMEM);
-if (!(f->cond = SDL_CreateCond()))
+}
+if (!(f->cond = SDL_CreateCond())) {
+av_log(NULL, AV_LOG_FATAL, "SDL_CreateCond(): %s\n", SDL_GetError());
 return AVERROR(ENOMEM);
+}
 f->pktq = pktq;
 f->max_size = FFMIN(max_size, FRAME_QUEUE_SIZE);
 f->keep_last = !!keep_last;
@@ -3175,6 +3179,7 @@ static VideoState *stream_open(const char *filename, 
AVInputFormat *iformat)
 is->av_sync_type = av_sync_type;
 is->read_tid = SDL_CreateThread(read_thread, is);
 if (!is->read_tid) {
+av_log(NULL, AV_LOG_FATAL, "SDL_CreateThread(): %s\n", SDL_GetError());
 fail:
 stream_close(is);
 return NULL;
@@ -3726,8 +3731,10 @@ static int lockmgr(void **mtx, enum AVLockOp op)
switch(op) {
   case AV_LOCK_CREATE:
   *mtx = SDL_CreateMutex();
-  if(!*mtx)
+  if(!*mtx) {
+  av_log(NULL, AV_LOG_FATAL, "SDL_CreateMutex(): %s\n", 
SDL_GetError());
   return 1;
+  }
   return 0;
   case AV_LOCK_OBTAIN:
   return !!SDL_LockMutex(*mtx);
-- 
2.6.0

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

[FFmpeg-devel] [PATCH 2/3] ffplay: more robust condition variable creation

[Ganesh Ajjanagadde]

SDL_CreateCond can fail:
https://wiki.libsdl.org/SDL_CreateCond.
This patch makes creation more robust in one instance.

Signed-off-by: Ganesh Ajjanagadde 
---
 ffplay.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/ffplay.c b/ffplay.c
index 8c9f6b1..cf0640e 100644
--- a/ffplay.c
+++ b/ffplay.c
@@ -3168,7 +3168,10 @@ static VideoState *stream_open(const char *filename, 
AVInputFormat *iformat)
 packet_queue_init(>subtitleq) < 0)
 goto fail;
 
-is->continue_read_thread = SDL_CreateCond();
+if (!(is->continue_read_thread = SDL_CreateCond())) {
+av_log(NULL, AV_LOG_FATAL, "SDL_CreateCond(): %s\n", SDL_GetError());
+goto fail;
+}
 
 init_clock(>vidclk, >videoq.serial);
 init_clock(>audclk, >audioq.serial);
-- 
2.6.0

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

[FFmpeg-devel] [PATCH] avcodec/pngdec: initialize "foreground_alpha"

[Ganesh Ajjanagadde]

Fixes CID 1322359, CID 1322358.

Signed-off-by: Ganesh Ajjanagadde 
---
 libavcodec/pngdec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/pngdec.c b/libavcodec/pngdec.c
index d180141..fe5 100644
--- a/libavcodec/pngdec.c
+++ b/libavcodec/pngdec.c
@@ -1006,7 +1006,7 @@ static int handle_p_frame_apng(AVCodecContext *avctx, 
PNGDecContext *s,
 uint8_t *background = buffer + s->image_linesize * y + s->bpp * 
s->x_offset;
 for (x = s->x_offset; x < s->x_offset + s->cur_w; ++x, foreground 
+= s->bpp, background += s->bpp) {
 size_t b;
-uint8_t foreground_alpha, background_alpha, output_alpha;
+uint8_t foreground_alpha = 0, background_alpha, output_alpha;
 uint8_t output[4];
 
 // Since we might be blending alpha onto alpha, we use the 
following equations:
-- 
2.6.0

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

[FFmpeg-devel] [PATCH] avutil/attributes: add av_warn_unused_result

[Ganesh Ajjanagadde]

GCC 3.4 introduced an attribute warn_unused_result to warn when a programmer
discards the return value. Applying this judiciously across the codebase can 
help
in fixing a lot of problems. At a high level, functions which return error codes
should always be checked. More concretely, consider the functions ff_add_format
and the like in avfilter/formats.h. A quick examination shows that a large 
portion
of libavfilter fails to handle the associated errors, usually AVERROR(ENOMEM).
The above example was where I observed the utility of this, but it should be
useful in many places across the code base.

Signed-off-by: Ganesh Ajjanagadde 
---
 libavutil/attributes.h | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/libavutil/attributes.h b/libavutil/attributes.h
index b4b5f13..3b94466 100644
--- a/libavutil/attributes.h
+++ b/libavutil/attributes.h
@@ -52,6 +52,12 @@
 #endif
 #endif
 
+#if AV_GCC_VERSION_AT_LEAST(3,4)
+#define av_warn_unused_result __attribute__((warn_unused_result))
+#else
+#define av_warn_unused_result
+#endif
+
 #if AV_GCC_VERSION_AT_LEAST(3,1)
 #define av_noinline __attribute__((noinline))
 #elif defined(_MSC_VER)
-- 
2.6.0

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