Re: [FFmpeg-devel] [PATCH] avformat/icoenc: Remove deprecated use of codec_name

[Paul B Mahol]

On 8/27/14, Michael Niedermayer  wrote:
> Signed-off-by: Michael Niedermayer 
> ---
>  libavformat/icoenc.c |3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/libavformat/icoenc.c b/libavformat/icoenc.c
> index dcf9065..53d4420 100644
> --- a/libavformat/icoenc.c
> +++ b/libavformat/icoenc.c
> @@ -61,7 +61,8 @@ static int ico_check_attributes(AVFormatContext *s, const
> AVCodecContext *c)
>  return AVERROR(EINVAL);
>  }
>  } else {
> -av_log(s, AV_LOG_ERROR, "Unsupported codec %s\n", c->codec_name);
> +const AVCodecDescriptor *codesc =
> avcodec_descriptor_get(c->codec_id);
> +av_log(s, AV_LOG_ERROR, "Unsupported codec %s\n", codesc ?
> codesc->name : "");
>  return AVERROR(EINVAL);
>  }
>
> --
> 1.7.9.5
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

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

Re: [FFmpeg-devel] [RFC] Bug bounties

[Clément Bœsch]

On Thu, Aug 28, 2014 at 02:15:45AM +0200, Michael Niedermayer wrote:
> On Wed, Aug 27, 2014 at 11:47:59PM +0200, Clément Bœsch wrote:
> > On Wed, Aug 27, 2014 at 10:16:12PM +0200, Michael Niedermayer wrote:
> > > Hi all
> > > 
> > > I was thinking about if we should put an
> > > automatic 50 USD bounty on every bug thats open since more than
> > > 12 month on trac, and limited to the first 20 claims so its limited
> > > to 1000 USD max expenses for us (for now)
> > > (also limited to real unique bugs of course)
> > 
> > What about the votes instead of time?
> > 
> > https://trac.ffmpeg.org/report/11
> 
> iam fine with any rating, no preferrance here but votes can be
> manipulated, time is alot harder though we shouldnt try to fix an
> issue where theres no issue. We could still switch to time when
> someone tries to manipulate the votes, if that ever happens ...
> 

In that case, maybe we (any recent ff developer) could just discuss in a
committee which bugs should be rewarded (with the help of the votes or
not). If it's like 10-15 bugs/reward to decide per year, I think we can
handle that.

For instance, Stefano was willing to work again on DVD input but sponsored
would help here. I support that initiative since it's a blocker for
replacing mencoder.

In the same spirit, #2391 (VobSub support) is regularly requested. Nicolas
could probably work on it, but given how hellish this can be, I think it
might be a good idea to propose some remuneration as a motivator.

Anyway, this tends to look like a bit like what ffmtech propose... And as
you asked initially, this might not be compatible with SPI anyway.

-- 
Clément B.


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

Re: [FFmpeg-devel] [PATCH] tests: Download lena.pnm if its missing from the source tree

[Derek Buitenhuis]

On 8/28/2014 2:25 AM, James Almer wrote:
> wget is not available on a standard Msys installation. Probably the same with 
> Cygwin.

bc isn't standard either and FATE uses it.

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

Re: [FFmpeg-devel] [RFC] Bug bounties

[Michael Niedermayer]

On Thu, Aug 28, 2014 at 11:50:37AM +0200, Clément Bœsch wrote:
> On Thu, Aug 28, 2014 at 02:15:45AM +0200, Michael Niedermayer wrote:
> > On Wed, Aug 27, 2014 at 11:47:59PM +0200, Clément Bœsch wrote:
> > > On Wed, Aug 27, 2014 at 10:16:12PM +0200, Michael Niedermayer wrote:
> > > > Hi all
> > > > 
> > > > I was thinking about if we should put an
> > > > automatic 50 USD bounty on every bug thats open since more than
> > > > 12 month on trac, and limited to the first 20 claims so its limited
> > > > to 1000 USD max expenses for us (for now)
> > > > (also limited to real unique bugs of course)
> > > 
> > > What about the votes instead of time?
> > > 
> > > https://trac.ffmpeg.org/report/11
> > 
> > iam fine with any rating, no preferrance here but votes can be
> > manipulated, time is alot harder though we shouldnt try to fix an
> > issue where theres no issue. We could still switch to time when
> > someone tries to manipulate the votes, if that ever happens ...
> > 
> 
> In that case, maybe we (any recent ff developer) could just discuss in a
> committee which bugs should be rewarded (with the help of the votes or
> not). If it's like 10-15 bugs/reward to decide per year, I think we can
> handle that.
> 

> For instance, Stefano was willing to work again on DVD input but sponsored
> would help here. I support that initiative since it's a blocker for
> replacing mencoder.
> 
> In the same spirit, #2391 (VobSub support) is regularly requested. Nicolas
> could probably work on it, but given how hellish this can be, I think it
> might be a good idea to propose some remuneration as a motivator.

yes but i dont think 50 USD for these would work as motivation
these are not bugs one can fix in a days work. Actually they arent
bugs at all but feature requests
I think for there to be a motvation the payment should be above the
minimum wage of the average western country


> 
> Anyway, this tends to look like a bit like what ffmtech propose... And as
> you asked initially, this might not be compatible with SPI anyway.

yes
if we choose to go ahead with this we will need to find out if this
is possible with SPI
I suggested in the past that if asking doesnt work its a matter of
trying. We can simlpy have a vounteer fix a bug and then ask SPI to
pay 50 USD for it. Theres of course the risk our volunteer wont get
anything and similarly that risk would stay for future such bounties
but hey some people like gambling so it might even increase
interrest ;)

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Republics decline into democracies and democracies degenerate into
despotisms. -- Aristotle


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

Re: [FFmpeg-devel] [PATCH] tests: Download lena.pnm if its missing from the source tree

[Carl Eugen Hoyos]

Andreas Cadhalpun  googlemail.com> writes:

> But I'm fine with moving lena.pnm to the FATE samples, 
> which are downloaded with 'make fate-rsync'.
> Attached patch removes tests/lena.pnm and adapts the 
> tests, assuming lena.pnm would be added to the top-level 
> of the SAMPLES directory.

As said, imo lena should be copied from either SAMPLES 
or tests/ to tests/data and used from there. This 
allows us to keep a very useful testfile in git master.

Carl Eugen

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

Re: [FFmpeg-devel] [RFC] Bug bounties

[Carl Eugen Hoyos]

Michael Niedermayer  gmx.at> writes:

> I was thinking about if we should put an automatic 
> 50 USD bounty on every bug thats open since more 
> than 12 month on trac, and limited to the first 
> 20 claims so its limited to 1000 USD max expenses 
> for us (for now)

I believe this is a good idea, age should definitely 
be a reason for a bounty, we can try votes as well 
if wanted.

The only point I would like to add is that the 
bounty should be claimed (reserved) in advance to 
make sure the ticket is still reproducible and we 
all agree that there is a bug at all.

Carl Eugen

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

Re: [FFmpeg-devel] [PATCH] tests: Download lena.pnm if its missing from the source tree

[Andreas Cadhalpun]

On 28.08.2014 14:01, Carl Eugen Hoyos wrote:

Andreas Cadhalpun  googlemail.com> writes:


But I'm fine with moving lena.pnm to the FATE samples,
which are downloaded with 'make fate-rsync'.
Attached patch removes tests/lena.pnm and adapts the
tests, assuming lena.pnm would be added to the top-level
of the SAMPLES directory.


As said, imo lena should be copied from either SAMPLES
or tests/ to tests/data and used from there. This
allows us to keep a very useful testfile in git master.


If it's made sure that lena.pnm doesn't end up in the distributed 
tarball, it could stay in git master as test file (although I'd find it 
better to use a free test file there).

But I'm not sure what copying it to tests/data would be good for?
The tests still could only be run if SAMPLES is present, or they would 
fail in the distributed tarball.


Best regards,
Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] tests: Download lena.pnm if its missing from the source tree

[Derek Buitenhuis]

On 8/28/2014 12:28 PM, Andreas Cadhalpun wrote:
> ffmpeg -f data -i http://samples.ffmpeg.org/image-samples/lena.pnm -c 
> copy -f data -map 0 -y lena.pnm
>>>
>>> From:
>>> 
>>
>> possible
>>
>> but would this make andreas / debian happy ?
> 
> No.

I think you've all missed Lou's point here. The point isn't to use the URL
via -i  during testing. The point was that you can use ffmpeg itself to
download the file to disk, instead of wget, and saves a dep from being added.

- Derek

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

Re: [FFmpeg-devel] [PATCH 2/3] build: rely on pkg-config for libx264 probing

[Clément Bœsch]

On Thu, Aug 21, 2014 at 02:34:42PM +0200, Clément Bœsch wrote:
> On Thu, Aug 21, 2014 at 02:24:40PM +0200, Clément Bœsch wrote:
> > On Thu, Aug 21, 2014 at 12:16:35PM +, Carl Eugen Hoyos wrote:
> > > Clément Bœsch  pkh.me> writes:
> > > 
> > > [...]
> > > 
> > > Sorry, I seem to have lost track of what you fear 
> > > will not work if pkg-config is used for x264 
> > > detection but will fallback to the current 
> > > system if pkg-config does not find the right 
> > > version.
> > 
> > It's simple really. You said earlier:
> > 
> > > > or do you actually want a real fallback when it is
> > > > present but didn't succeed?
> > >
> > > This is the preferred solution imo.
> > 
> > In this case, if pkg-config finds the system install, it will not honor
> > the user c/ld flags but the one from pkg-config.
> > 
> 
> BTW, now that I think of it, depending on where the --extra-{ld,cflags}
> are added in the compilation and linker flag, they *might* allow you to
> trick the detection.
> 
> Did you try the patch with pkg-config only detection?
> 
> And try to add --pkg-config=true to trick the detect function.
> 

So, I did try myself, and it does the trick. Here is a new proposed diff
(will submit patches from it):

diff --git a/RELEASE_NOTES b/RELEASE_NOTES
index 3fbf556..3f7a432 100644
--- a/RELEASE_NOTES
+++ b/RELEASE_NOTES
@@ -51,3 +51,4 @@
 
   • dctdnoiz filter now uses a block size of 8x8 instead of 16x16 by default
   • -vismv option is deprecated in favor of the codecview filter
+  • libx264 is now detected through pkg-config
diff --git a/configure b/configure
index 8e5f49b..03e9108 100755
--- a/configure
+++ b/configure
@@ -408,6 +408,7 @@ warn(){
 }
 
 die(){
+test -n "$WARNINGS" && printf "\n$WARNINGS"
 echolog "$@"
 cat &1; then
+warn "$pkg_config not found but $pkg library detection relies on it"
+return 1
+fi
 check_cmd $pkg_config --exists --print-errors $pkgandversion || return
 pkg_cflags=$($pkg_config --cflags $pkg_config_flags $pkg)
 pkg_libs=$($pkg_config --libs $pkg_config_flags $pkg)
@@ -1198,8 +1203,18 @@ require_cpp(){
 }
 
 require_pkg_config(){
-pkg="$1"
-check_pkg_config "$@" || die "ERROR: $pkg not found"
+pkgandversion="$1"
+pkg="${1%% *}"
+if ! $pkg_config --version >/dev/null 2>&1; then
+cat &1; then
-warn "$pkg_config not found, library detection may fail."
-pkg_config=false
-fi
-
 if test $doxygen != $doxygen_default && \
   ! $doxygen --version >/dev/null 2>&1; then
 warn "Specified doxygen \"$doxygen\" not found, API documentation will 
fail to build."
@@ -4851,9 +4861,7 @@ enabled libwavpack&& require libwavpack 
wavpack/wavpack.h WavpackOpenFil
 enabled libwebp   && require_pkg_config libwebp webp/encode.h 
WebPGetEncoderVersion &&
  { check_code cc webp/encode.h "WebPPicture wp; 
wp.use_argb++" ||
die "ERROR: libwebp too old."; }
-enabled libx264   && require libx264 x264.h x264_encoder_encode -lx264 
&&
- { check_cpp_condition x264.h "X264_BUILD >= 118" 
||
-   die "ERROR: libx264 must be installed and 
version must be >= 0.118."; }
+enabled libx264   && require_pkg_config "x264 >= 0.118" "stdint.h 
x264.h" x264_encoder_encode
 enabled libx265   && require_pkg_config x265 x265.h 
x265_encoder_encode &&
  { check_cpp_condition x265.h "X265_BUILD >= 17" ||
die "ERROR: libx265 version must be >= 17."; }


And basically, this is what happens:

 • If you don't have the required x264 (but pkg-config):

[~/src/ffmpeg]☭ dash ./configure --disable-everything --enable-gpl 
--enable-libx264 
ERROR: x264 >= 999.118 not found

If you think configure made a mistake, make sure you are using the latest
version from Git.  If the latest version fails, report the problem to the
ffmpeg-u...@ffmpeg.org mailing list or IRC #ffmpeg on irc.freenode.net.
Include the log file "config.log" produced by configure as this will help
solve the problem.

 • If you don't have pkg-config:

[~/src/ffmpeg]☭ dash ./configure --disable-everything --enable-gpl 
--enable-libx264 --pkg-config=pkg-config-nope
ERROR: pkg-config-nope not found but x264 detection relies on it.
   You should either install pkg-config (recommended), or use
   --pkg-config=true with the x264 linker flags specified through
   --extra-ldflags.


If you think configure made a mistake, make sure you are using the latest
version from Git.  If the latest version fails, report the problem to the
ffmpeg-u...@ffmpeg.org mailing list or IRC #ffmpeg on irc.freenode.net.
Include the log file "config.log" produced by configure as this will help
solve the problem.

 • Following the instructions above in case you don't want to use pkg-config:

[~/src/ffmpeg]☭ dash ./configure --disable-everything --enable-gpl 
--enable-

Re: [FFmpeg-devel] [PATCH] tests: Download lena.pnm if its missing from the source tree

[Andreas Cadhalpun]

On 28.08.2014 14:29, Derek Buitenhuis wrote:

On 8/28/2014 12:28 PM, Andreas Cadhalpun wrote:

ffmpeg -f data -i http://samples.ffmpeg.org/image-samples/lena.pnm -c copy -f 
data -map 0 -y lena.pnm


From:



possible

but would this make andreas / debian happy ?


No.


I think you've all missed Lou's point here. The point isn't to use the URL
via -i  during testing. The point was that you can use ffmpeg itself to
download the file to disk, instead of wget, and saves a dep from being added.


That's clear. But it doesn't work without internet connection.
So why not use fate-rsync, which is only run manually, when internet is 
available?


Best regards,
Andreas

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

Re: [FFmpeg-devel] [PATCH] avformat/icoenc: Remove deprecated use of codec_name

[Michael Niedermayer]

On Thu, Aug 28, 2014 at 11:38:32AM +0200, Paul B Mahol wrote:
> On 8/27/14, Michael Niedermayer  wrote:
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavformat/icoenc.c |3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavformat/icoenc.c b/libavformat/icoenc.c
> > index dcf9065..53d4420 100644
> > --- a/libavformat/icoenc.c
> > +++ b/libavformat/icoenc.c
> > @@ -61,7 +61,8 @@ static int ico_check_attributes(AVFormatContext *s, const
> > AVCodecContext *c)
> >  return AVERROR(EINVAL);
> >  }
> >  } else {
> > -av_log(s, AV_LOG_ERROR, "Unsupported codec %s\n", c->codec_name);
> > +const AVCodecDescriptor *codesc =
> > avcodec_descriptor_get(c->codec_id);
> > +av_log(s, AV_LOG_ERROR, "Unsupported codec %s\n", codesc ?
> > codesc->name : "");
> >  return AVERROR(EINVAL);
> >  }
> >
> > --
> > 1.7.9.5
> >
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> 
> ok

applied

thanks

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

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


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

Re: [FFmpeg-devel] [PATCH] tests: Download lena.pnm if its missing from the source tree

[Derek Buitenhuis]

On 8/28/2014 1:42 PM, Andreas Cadhalpun wrote:
> That's clear. But it doesn't work without internet connection.
> So why not use fate-rsync, which is only run manually, when internet is 
> available?

Probably because it entails reworking the vsynth build system stuff quite
a bit to placate a single complaining linux distro.

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

Re: [FFmpeg-devel] [FFmpeg-cvslog] avformat/rtpdec_asf: fix compiler warning about const qualifier being discarded

[Michael Niedermayer]

On Wed, Aug 27, 2014 at 07:58:53PM -0700, Timothy Gu wrote:
> On Wed, Aug 27, 2014 at 7:28 PM, Michael Niedermayer  wrote:
> > On Wed, Aug 27, 2014 at 06:17:36PM -0700, Timothy Gu wrote:
> >> Michael Niedermayer  writes:
> >>
> >> >
> >> > ffmpeg | branch: master | Michael Niedermayer  | Wed 
> >> > Aug 27 23:53:53 2014 +0200|
> >> > [e6516944a3d504f208911033b31afedb3d427267] | committer: Michael 
> >> > Niedermayer
> >> >
> >> > avformat/rtpdec_asf: fix compiler warning about const qualifier being
> >> > discarded
> >> >
> >> > Signed-off-by: Michael Niedermayer 
> >> >
> >> > > http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=e6516944a3d504f208911033b31afedb3d427267
> >> > ---
> >> >
> >> >  libavformat/rtpdec_asf.c |2 +-
> >> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >> >
> >> > diff --git a/libavformat/rtpdec_asf.c b/libavformat/rtpdec_asf.c
> >> > index 541b86f..8e19654 100644
> >> > --- a/libavformat/rtpdec_asf.c
> >> > +++ b/libavformat/rtpdec_asf.c
> >> >  @@ -188,7 +188,7@@ static int asfrtp_parse_packet(AVFormatContext *s,
> >> > PayloadContext *asf,
> >> >
> >> >  av_freep(&asf->buf);
> >> >
> >>
> >> > -ffio_init_context(pb, buf, len, 0, NULL, NULL, NULL, NULL);
> >> > +ffio_init_context(pb, (uint8_t *)buf, len, 0, NULL, NULL, NULL,
> >> > NULL);
> >>
> >> Wouldn't it be more correct to declare ffio_init_context's second
> >> argument const?
> >
> > ffio_init_context() can also be used for writing
> 
> Yes, but the function does not change *buf.
> 
> See 
> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavformat/aviobuf.c;h=9795ba46dfe5dc96ff303e4a5271da01d94ec7d9;hb=HEAD#l72
> 
> The function url_resetbuf() called in ffio_init_context() does not
> change *buf either:
> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavformat/aviobuf.c;h=9795ba46dfe5dc96ff303e4a5271da01d94ec7d9;hb=HEAD#l819

buf is assigned to AVIOContext.buffer, which is written to by some
functions using AVIOContext

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Good people do not need laws to tell them to act responsibly, while bad
people will find a way around the laws. -- Plato


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

Re: [FFmpeg-devel] [PATCH] tests: Download lena.pnm if its missing from the source tree

[Carl Eugen Hoyos]

Andreas Cadhalpun  googlemail.com> writes:

> So why not use fate-rsync

Because it downloads a few files more than Lena.

Carl Eugen

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

Re: [FFmpeg-devel] [PATCH 2/3] build: rely on pkg-config for libx264 probing

[Carl Eugen Hoyos]

Clément Bœsch  pkh.me> writes:

> > Did you try the patch with pkg-config only detection?
> > 
> > And try to add --pkg-config=true to trick the detect function.
> 
> So, I did try myself

Sorry, I was away and still didn't test all new 
tickets.

> [~/src/ffmpeg]☭ dash ./configure --disable-everything 
> --enable-gpl --enable-libx264 --pkg-config=/bin/true

> --extra-ldflags=-lx264

The extra-ldflags should not be necessary.

I still wonder why --pkg-config=/bin/true is 
necessary: If another version (than the one intended 
by the user) is found then he has a bad system 
installation (and has to use above work-around). 
But if no installation can be found, the work-around 
should be tested by configure.

Carl Eugen

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

Re: [FFmpeg-devel] [PATCH] tests: Download lena.pnm if its missing from the source tree

[Carl Eugen Hoyos]

Andreas Cadhalpun  googlemail.com> writes:

> But I'm not sure what copying it to tests/data would be good for?

So people can still run the limited tests without 
downloading the whole fate suite.

Carl Eugen

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

Re: [FFmpeg-devel] [PATCH] Adds support for constant quality mode in VP9.

[Michael Niedermayer]

On Wed, Aug 27, 2014 at 07:08:00PM -0700, James Zern wrote:
> On Wed, Aug 27, 2014 at 1:04 PM, Deb Mukherjee  wrote:
> > Changes in the parameter mapping for libvpx to support the constant
> > quality mode in VP9. The assumption in the patch is that if crf is
> > provided but bitrate is 0, then the 'constant quality' mode of VP9
> > is used. However if both are present, the 'constrained quality' mode
> > is used as before.
> > ---
> >  libavcodec/libvpxenc.c | 25 +++--
> >  1 file changed, 19 insertions(+), 6 deletions(-)
> >
> 
> lgtm. builds all right with a recent lib and seems to have the desired effect.

applied

btw, if you want a git write account send me your public SSH key

Thanks

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

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


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

Re: [FFmpeg-devel] [PATCH 2/3] build: rely on pkg-config for libx264 probing

[Clément Bœsch]

On Thu, Aug 28, 2014 at 01:18:55PM +, Carl Eugen Hoyos wrote:
> Clément Bœsch  pkh.me> writes:
> 
> > > Did you try the patch with pkg-config only detection?
> > > 
> > > And try to add --pkg-config=true to trick the detect function.
> > 
> > So, I did try myself
> 
> Sorry, I was away and still didn't test all new 
> tickets.
> 
> > [~/src/ffmpeg]☭ dash ./configure --disable-everything 
> > --enable-gpl --enable-libx264 --pkg-config=/bin/true
> 
> > --extra-ldflags=-lx264
> 
> The extra-ldflags should not be necessary.
> 

Well, it's incomplete depending on the situation so we don't want it in
the configure (Cf my mail about testing such things) and you're probably
setting --extra-ldflags already for your custom paths.

Also, you need to add --pkg-config=true anyway, so you can do the effort
to add -lx264 as well.

> I still wonder why --pkg-config=/bin/true is 
> necessary: If another version (than the one intended 
> by the user) is found then he has a bad system 
> installation (and has to use above work-around). 
> But if no installation can be found, the work-around 
> should be tested by configure.

Unless I misunderstood the question, it will; --pkg-config=true will just
make the fake pkg-config raise no flags, and then compilation will be
tried with those empty flags (and the --extra-{c,ld}flags).

-- 
Clément B.


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

Re: [FFmpeg-devel] [PATCH] tests: Download lena.pnm if its missing from the source tree

[Andreas Cadhalpun]

On 28.08.2014 15:16, Carl Eugen Hoyos wrote:

Andreas Cadhalpun  googlemail.com> writes:


But I'm not sure what copying it to tests/data would be good for?


So people can still run the limited tests without
downloading the whole fate suite.


With my patch that would still be possible, the limited tests would just 
be a bit more limited, i.e. not containing the vsynth2 tests.


Best regards,
Andreas

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

Re: [FFmpeg-devel] [PATCH] Include content of the news article in the website RSS

[Alexander Strasser]

Hi!

On 2014-05-23 00:28 +0200, Alexander Strasser wrote:
> On 2014-05-11 01:37 +0200, Gerion Entrup wrote:
> > Am Donnerstag 01 Mai 2014, 23:48:29 schrieb Alexander Strasser:
> > > alternative. What do you and/or others think of it?
> > >  
> > >   Besides validation I couldn't yet properly test what feed
> > > readers make of it. So please forgive me if it causes obvious
> > > problems with your reader.
> > (As said offline already) My reader works with it.

  My patch still works I think. I would like to commit it,
though it won't be flexible enough to add much other stuff
that needs more elaborate logic. I want to apply it, because
it is a neat feature to have now. Any objections to this?

  In the not-so-short term I intend to widen security checks
for the repo on the server to other files than just the Makefile.
I already started this work, but need to fix one known problem
before I can put it to work on the server.

>   I sent a new series for this:
> 
>   Subject: [PATCH 0/5] web: Extend RSS

  When what I described in the above paragraph is online,
I could push the better solution that I quoted above.


  Alexander

> > It would be nice to set the 
> > pubtime as well (an example: Wed, 07 May 2014 18:28:18 
> > CEST).
> > This command should work more less to build the date:
> > date '+%a, %d %b %Y %T %Z' -d parsed_date
> > (similar to date '+%c' btw) you have to keep in mind the locale, too.
> 
>   Good point. Actually I think I need to check where the time
> formatting code in my new patch is getting the locale from...
> 
> > See here 
> > (http://cyber.law.harvard.edu/rss/rss.html#optionalChannelElements) 
> > for the spec.
> 
> [...]


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

Re: [FFmpeg-devel] [PATCH] Include content of the news article in the website RSS

[Timothy Gu]

On Thu, Aug 28, 2014 at 7:26 AM, Alexander Strasser  wrote:
> Hi!
>
> On 2014-05-23 00:28 +0200, Alexander Strasser wrote:
>> On 2014-05-11 01:37 +0200, Gerion Entrup wrote:
>> > Am Donnerstag 01 Mai 2014, 23:48:29 schrieb Alexander Strasser:
>> > > alternative. What do you and/or others think of it?
>> > >
>> > >   Besides validation I couldn't yet properly test what feed
>> > > readers make of it. So please forgive me if it causes obvious
>> > > problems with your reader.
>> > (As said offline already) My reader works with it.
>
>   My patch still works I think. I would like to commit it,
> though it won't be flexible enough to add much other stuff
> that needs more elaborate logic. I want to apply it, because
> it is a neat feature to have now.

Good to hear you are still working on this.

> Any objections to this?

LGTM from me, assuming it is tested and works. I slightly prefer your
patch over Gerion's, but both are OK.

>
>   In the not-so-short term I intend to widen security checks
> for the repo on the server to other files than just the Makefile.
> I already started this work, but need to fix one known problem
> before I can put it to work on the server.

Yes, that would be much better. The awk and sed hack is getting too
cumbersome. Or we could just change the server host.

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

[FFmpeg-devel] [PATCH] lavu/avstring: check for overlong encodings

[Stefano Sabatini]

Fix reopened trac ticket #1163.
---
 libavutil/avstring.c | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/libavutil/avstring.c b/libavutil/avstring.c
index a63fb84..df27d5e 100644
--- a/libavutil/avstring.c
+++ b/libavutil/avstring.c
@@ -331,7 +331,10 @@ int av_utf8_decode(int32_t *codep, const uint8_t **bufp, 
const uint8_t *buf_end,
 const uint8_t *p = *bufp;
 uint32_t top;
 uint64_t code;
-int ret = 0;
+int ret = 0, tail_len;
+uint32_t overlong_encoding_mins[6] = {
+0x, 0x0080, 0x0800, 0x0001, 0x0020, 0x0400,
+};
 
 if (p >= buf_end)
 return 0;
@@ -346,8 +349,10 @@ int av_utf8_decode(int32_t *codep, const uint8_t **bufp, 
const uint8_t *buf_end,
 }
 top = (code & 128) >> 1;
 
+tail_len = 0;
 while (code & top) {
 int tmp;
+tail_len++;
 if (p >= buf_end) {
 (*bufp) ++;
 return AVERROR(EILSEQ); /* incomplete sequence */
@@ -364,6 +369,12 @@ int av_utf8_decode(int32_t *codep, const uint8_t **bufp, 
const uint8_t *buf_end,
 }
 code &= (top << 1) - 1;
 
+/* check for overlong encodings */
+if (code < overlong_encoding_mins[tail_len]) {
+ret = AVERROR(EILSEQ);
+goto end;
+}
+
 if (code >= 1<<31) {
 ret = AVERROR(EILSEQ);  /* out-of-range value */
 goto end;
-- 
1.8.3.2

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

Re: [FFmpeg-devel] [PATCH] tests: Download lena.pnm if its missing from the source tree

[Clément Bœsch]

On Thu, Aug 28, 2014 at 02:12:14PM +0200, Andreas Cadhalpun wrote:
> On 28.08.2014 14:01, Carl Eugen Hoyos wrote:
> >Andreas Cadhalpun  googlemail.com> writes:
> >
> >>But I'm fine with moving lena.pnm to the FATE samples,
> >>which are downloaded with 'make fate-rsync'.
> >>Attached patch removes tests/lena.pnm and adapts the
> >>tests, assuming lena.pnm would be added to the top-level
> >>of the SAMPLES directory.
> >
> >As said, imo lena should be copied from either SAMPLES
> >or tests/ to tests/data and used from there. This
> >allows us to keep a very useful testfile in git master.
> 
> If it's made sure that lena.pnm doesn't end up in the distributed tarball,
> it could stay in git master as test file (although I'd find it better to use
> a free test file there).
> But I'm not sure what copying it to tests/data would be good for?
> The tests still could only be run if SAMPLES is present, or they would fail
> in the distributed tarball.
> 

ffplay http://lucy.pkh.me/lena.pnm

File size and dimensions are the same, and we can of course keep the file
name since the person looks like Lena a bit.

Would that one be OK?

According to http://goo.gl/0K3qyP it should be OK as long as the
attribution is kept, which can be done in the commit message.

[...]

-- 
Clément B.


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

Re: [FFmpeg-devel] [libav-devel] Common mailing-list for API evolutions

[Anton Khirnov]

On Sun, 24 Aug 2014 00:28:56 +0200, =?utf-8?B?Q2zDqW1lbnQgQsWTc2No?= 
 wrote:
> Hi,
> 
> Kieran suggested tonight on #ffmpeg-devel to have a common mailing-list
> between the two projects to start communicating again in sane terms.
> 
> The proposition would be a mailing-list where the 2 projects would send
> the patches that will make API evolutions. So the projects can continue to
> drop or add codecs & filters without caring about the other, but will try
> to communicate more about the API, for the sake of our common users.
> 
> At first, I suggest that won't engage anything from any of the two
> projects (so we don't end up in a stalled states such as one project
> trying to block the other), but it could be seen as a way to introduce
> some common technical ground.
> 
> What do you think?

While some kind of non-hostile coexistence or even cooperation is desirable and
might even be possible, I have large doubts that this specific approach can
work.

First, some of your project's developers (most importantly your leader)
are being actively hostile to our project. That includes spreading FUD about us
all over the internet, stalking our new contributors, etc. I do not think any
kind of cooperation can work while this crap goes on.

Second, how do you propose this arrangement will actually function? As you
probably know, I see many of the API additions done in your project as ugly
hacks, and would be strongly opposed to having them in our tree in their current
form. Conversely, some API changes done in Libav were AFAIK rejected by your
leader. So -- what happens when one side proposes a change that the other side
fundamentally disagrees with.
And furthermore -- what would ensure that the code actually gets pushed to both
trees. Because otherwise there really is no point to this.

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

Re: [FFmpeg-devel] [libav-devel] Common mailing-list for API evolutions

[Clément Bœsch]

On Thu, Aug 28, 2014 at 06:58:57PM +0200, Anton Khirnov wrote:
[...]
> Second, how do you propose this arrangement will actually function? As you
> probably know, I see many of the API additions done in your project as ugly
> hacks, and would be strongly opposed to having them in our tree in their 
> current
> form. Conversely, some API changes done in Libav were AFAIK rejected by your
> leader. So -- what happens when one side proposes a change that the other side
> fundamentally disagrees with.

Note that the motivation here is not to have any "contract" (at least how
I envision it). This means that both sides will be free to ignore the
other or even not submit to the mailing-list. Basically, it's a DMZ for
people not willing to enter in any fight but still would like to smooth
the API issues between the two projects.

One example could be for example that you would submit a patchset about
codec parameters to that mailing-list. This will provide FFmpeg developers
some insight about your changes (this is interesting only for us), but on
the other hand since we will very likely integrate it we will be more
concerned about reviewing your changes and more inclined to raise issues
with it. You will of course be free to ignore completely, but that
provides an open communication ground, and would avoid the multiple cases
where FFmpeg fixed some problems in your code without notifying "the
Upstream".

Now the other way around, let's say I'm submitting a new API for
subtitles, it means you will hear about it. This means you will be able to
suggest changes so it is up to Libav expectations, and so might simplify
an eventual cherry-pick in the future. It also makes you aware of what's
available in FFmpeg. Again, I'm free to ignore it, even thought that might
not be in my interest.

[...]

-- 
Clément B.


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

Re: [FFmpeg-devel] [PATCH] tests: Download lena.pnm if its missing from the source tree

[Andreas Cadhalpun]

On 28.08.2014 17:53, Clément Bœsch wrote:

ffplay http://lucy.pkh.me/lena.pnm

File size and dimensions are the same, and we can of course keep the file
name since the person looks like Lena a bit.

Would that one be OK?

According to http://goo.gl/0K3qyP it should be OK as long as the
attribution is kept, which can be done in the commit message.


The licensing would be OK, but, seriously, do you want such an image in 
FFmpeg's source?


If you want to keep the original filename, why not use a real Lena [1] 
image, e.g.:

https://en.wikipedia.org/wiki/File:Lena_Zavaroni_927-0962.jpg
https://en.wikipedia.org/wiki/File:Headey,_Lena_(2007).jpg
https://en.wikipedia.org/wiki/File:Lena_Yada.jpg
https://en.wikipedia.org/wiki/File:Lena_Meyer-Landrut_at_PC_after_2010_Eurovision_2.jpg
https://en.wikipedia.org/wiki/File:LenaHasesSlim.jpg
https://en.wikipedia.org/wiki/File:AlexisBledelSept11TIFF.jpg

Any of these could be converted to a 256x256 ppm image.

Best regards,
Andreas


1: https://en.wikipedia.org/wiki/Lena

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

Re: [FFmpeg-devel] [PATCH] tests: Download lena.pnm if its missing from the source tree

[Nicolas George]

> On 28.08.2014 17:53, Clément Bœsch wrote:
> >ffplay http://lucy.pkh.me/lena.pnm

> >According to http://goo.gl/0K3qyP it should be OK as long as the
> >attribution is kept, which can be done in the commit message.

Clément, I believe this URL shortener will please you very much:

http://www.shadyurl.com/

Le primidi 11 fructidor, an CCXXII, Andreas Cadhalpun a écrit :
> If you want to keep the original filename, why not use a real Lena
> [1] image, e.g.:
> https://en.wikipedia.org/wiki/File:Lena_Zavaroni_927-0962.jpg
> https://en.wikipedia.org/wiki/File:Headey,_Lena_(2007).jpg
> https://en.wikipedia.org/wiki/File:Lena_Yada.jpg
> https://en.wikipedia.org/wiki/File:Lena_Meyer-Landrut_at_PC_after_2010_Eurovision_2.jpg
> https://en.wikipedia.org/wiki/File:LenaHasesSlim.jpg
> https://en.wikipedia.org/wiki/File:AlexisBledelSept11TIFF.jpg

They all are very arbitrary and random. If we want the portrait of a woman
that everybody knows and is certainly in the public domain, there is this
one:

display -crop 515x515+0+64 -resize 256x256 
http://upload.wikimedia.org/wikipedia/commons/thumb/e/ec/Mona_Lisa%2C_by_Leonardo_da_Vinci%2C_from_C2RMF_retouched.jpg/515px-Mona_Lisa%2C_by_Leonardo_da_Vinci%2C_from_C2RMF_retouched.jpg

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] add silenceremove filter

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---
 doc/filters.texi   |  55 +
 libavfilter/Makefile   |   1 +
 libavfilter/af_silenceremove.c | 461 +
 libavfilter/allfilters.c   |   1 +
 4 files changed, 518 insertions(+)
 create mode 100644 libavfilter/af_silenceremove.c

diff --git a/doc/filters.texi b/doc/filters.texi
index cca15fc..3fcf0e9 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -1881,6 +1881,61 @@ ffmpeg -i silence.mp3 -af silencedetect=noise=0.0001 -f 
null -
 @end example
 @end itemize
 
+@section silenceremove
+
+Removes silence from the beginning, middle or end of the audio.
+
+The filter accepts the following options:
+
+@table @option
+@item start_periods
+This value is used to indicate if audio should be trimmed at beginning of
+the audio. A value of zero indicates no silence should be trimmed from the
+beginning. When specifying an non-zero value, it trims audio up until it
+finds non-silence. Normally, when trimming silence from beginning of audio
+the @var{start_periods} will be @code{1} but it can be increased to higher
+values to trim all audio up to specific count of non-silence periods.
+
+@item start_duration
+Specify amount of time that non-silence must be detected before it stops
+trimming audio. By increasing the duration, burst of noise can be treated
+as silence and trimmed off.
+
+@item start_threshold
+This indicate what sample value should be treated as silence. For digital
+audio, a value of @code{0} may be fine but for audio recorded from analog,
+you may wish to increase the value to account for background noise.
+
+@item stop_periods
+Set the count for trimming silence from the end of audio.
+To remove silence from the middle of a file, specify a @var{stop_periods}
+that is negative. This value is the threated as a positive value and is also
+used to indicate the effect should restart processing as specified by
+@var{start_periods}, making it suitable for removing periods of silence
+in the middle of the audio.
+
+@item stop_duration
+Specify a duration of silence that must exist before audio is not copied any
+more. By specifying a higher duration, silence that is wanted can be left
+in the audio.
+
+@item stop_threshold
+This indicate what sample value should be treated as silence but for
+trimming silence from the end of audio.
+@end table
+
+@subsection Examples
+
+@itemize
+@item
+The following example shows how this filter can be used to start recording
+that does not contain the delay at the start which usually occurs between
+pressing the record button and the star of the performance:
+@example
+silenceremove=1:5:0.02
+@end example
+@end itemize
+
 @section treble
 
 Boost or cut treble (upper) frequencies of the audio using a two-pole
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index ce71ce1..3241b76 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -78,6 +78,7 @@ OBJS-$(CONFIG_PAN_FILTER)+= af_pan.o
 OBJS-$(CONFIG_REPLAYGAIN_FILTER) += af_replaygain.o
 OBJS-$(CONFIG_RESAMPLE_FILTER)   += af_resample.o
 OBJS-$(CONFIG_SILENCEDETECT_FILTER)  += af_silencedetect.o
+OBJS-$(CONFIG_SILENCEREMOVE_FILTER)  += af_silenceremove.o
 OBJS-$(CONFIG_TREBLE_FILTER) += af_biquads.o
 OBJS-$(CONFIG_VOLUME_FILTER) += af_volume.o
 OBJS-$(CONFIG_VOLUMEDETECT_FILTER)   += af_volumedetect.o
diff --git a/libavfilter/af_silenceremove.c b/libavfilter/af_silenceremove.c
new file mode 100644
index 000..ef509e2
--- /dev/null
+++ b/libavfilter/af_silenceremove.c
@@ -0,0 +1,461 @@
+/*
+ * Copyright (c) 2001 Heikki Leinonen
+ * Copyright (c) 2001 Chris Bagwell
+ * Copyright (c) 2003 Donnie Smith
+ * Copyright (c) 2014 Paul B Mahol
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/opt.h"
+#include "libavutil/timestamp.h"
+#include "audio.h"
+#include "formats.h"
+#include "avfilter.h"
+#include "internal.h"
+
+typedef struct SilenceRemoveContext {
+const AVClass *class;
+
+int mode;
+
+int start_periods;
+int64_t start_duration;
+double start_threshold;
+
+int stop_periods;
+int64_t stop_duration;
+double stop_threshold;
+
+double 

Re: [FFmpeg-devel] [RFC] Bug bounties

[Michael Niedermayer]

On Wed, Aug 27, 2014 at 04:27:15PM -0800, Lou Logan wrote:
> On Wed, 27 Aug 2014 22:16:12 +0200, Michael Niedermayer wrote:
> 
> > Hi all
> > 
> > I was thinking about if we should put an
> > automatic 50 USD bounty on every bug thats open since more than
> > 12 month on trac, and limited to the first 20 claims so its limited
> > to 1000 USD max expenses for us (for now)
> 
> We could look into bountysource as the infrastructure/platform. It
> might make it easier for users. They take a 10% cut upon withdrawl of
> awarded funds. They also have a "fundraiser" feature, but I didn't
> really read much about that.
> 
> I signed up the project a while ago just to take a look, and one of the
> employees contacted me several times via IRC so see if I had any
> questions or needed help, but my lazignorance ultimately prevailed and
> I didn't really do anything with it.
> 
> Here's the project page:
> 

this looks pretty cool
i am not sure how successfull this would be for us but i definitly
support the idea of trying this ...


> 
> It automatically lists each bug report.
> 
> I have no experience using bountysource as a user or developer. Does
> anyone have any experience with this?
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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

Re: [FFmpeg-devel] [PATCH] tests: Download lena.pnm if its missing from the source tree

[Andreas Cadhalpun]

On 28.08.2014 19:37, Nicolas George wrote:

On 28.08.2014 17:53, Clément Bœsch wrote:

ffplay http://lucy.pkh.me/lena.pnm



According to http://goo.gl/0K3qyP it should be OK as long as the
attribution is kept, which can be done in the commit message.


Clément, I believe this URL shortener will please you very much:

http://www.shadyurl.com/

Le primidi 11 fructidor, an CCXXII, Andreas Cadhalpun a écrit :

If you want to keep the original filename, why not use a real Lena
[1] image, e.g.:
https://en.wikipedia.org/wiki/File:Lena_Zavaroni_927-0962.jpg
https://en.wikipedia.org/wiki/File:Headey,_Lena_(2007).jpg
https://en.wikipedia.org/wiki/File:Lena_Yada.jpg
https://en.wikipedia.org/wiki/File:Lena_Meyer-Landrut_at_PC_after_2010_Eurovision_2.jpg
https://en.wikipedia.org/wiki/File:LenaHasesSlim.jpg
https://en.wikipedia.org/wiki/File:AlexisBledelSept11TIFF.jpg


They all are very arbitrary and random. If we want the portrait of a woman
that everybody knows and is certainly in the public domain, there is this
one:

display -crop 515x515+0+64 -resize 256x256 
http://upload.wikimedia.org/wikipedia/commons/thumb/e/ec/Mona_Lisa%2C_by_Leonardo_da_Vinci%2C_from_C2RMF_retouched.jpg/515px-Mona_Lisa%2C_by_Leonardo_da_Vinci%2C_from_C2RMF_retouched.jpg


Fine with me.

Best regards,
Andreas

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

Re: [FFmpeg-devel] [PATCH] tests: Download lena.pnm if its missing from the source tree

[Reimar Döffinger]

On Thu, Aug 28, 2014 at 02:42:45PM +0200, Andreas Cadhalpun wrote:
> On 28.08.2014 14:29, Derek Buitenhuis wrote:
> >On 8/28/2014 12:28 PM, Andreas Cadhalpun wrote:
> >>ffmpeg -f data -i http://samples.ffmpeg.org/image-samples/lena.pnm -c 
> >>copy -f data -map 0 -y lena.pnm
> 
> From:
> 
> >>>
> >>>possible
> >>>
> >>>but would this make andreas / debian happy ?
> >>
> >>No.
> >
> >I think you've all missed Lou's point here. The point isn't to use the URL
> >via -i  during testing. The point was that you can use ffmpeg itself to
> >download the file to disk, instead of wget, and saves a dep from being added.
> 
> That's clear. But it doesn't work without internet connection.
> So why not use fate-rsync, which is only run manually, when internet is
> available?

I completely lost track of the discussion, but this all so shouts
bikeshed and overkill.
If I may suggest another colour for the shed:
Put some random, freely licensed image where the Lena image
was, put the Lena one in the sample repository and run the
tests with either just one or both depending on what is available.
Disadvantages: increases runtime
Advantages: everyone running proper tests gets increased coverage
(especially if the image has quite different characteristics),
everyone else still gets a good bit of testing.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] tests: Download lena.pnm if its missing from the source tree

[Michael Niedermayer]

On Thu, Aug 28, 2014 at 07:47:11PM +0200, Andreas Cadhalpun wrote:
> On 28.08.2014 19:37, Nicolas George wrote:
> >>On 28.08.2014 17:53, Clément Bœsch wrote:
> >>>ffplay http://lucy.pkh.me/lena.pnm
> >
> >>>According to http://goo.gl/0K3qyP it should be OK as long as the
> >>>attribution is kept, which can be done in the commit message.
> >
> >Clément, I believe this URL shortener will please you very much:
> >
> >http://www.shadyurl.com/
> >
> >Le primidi 11 fructidor, an CCXXII, Andreas Cadhalpun a écrit :
> >>If you want to keep the original filename, why not use a real Lena
> >>[1] image, e.g.:
> >>https://en.wikipedia.org/wiki/File:Lena_Zavaroni_927-0962.jpg
> >>https://en.wikipedia.org/wiki/File:Headey,_Lena_(2007).jpg
> >>https://en.wikipedia.org/wiki/File:Lena_Yada.jpg
> >>https://en.wikipedia.org/wiki/File:Lena_Meyer-Landrut_at_PC_after_2010_Eurovision_2.jpg
> >>https://en.wikipedia.org/wiki/File:LenaHasesSlim.jpg
> >>https://en.wikipedia.org/wiki/File:AlexisBledelSept11TIFF.jpg
> >
> >They all are very arbitrary and random. If we want the portrait of a woman
> >that everybody knows and is certainly in the public domain, there is this
> >one:
> >
> >display -crop 515x515+0+64 -resize 256x256 
> >http://upload.wikimedia.org/wikipedia/commons/thumb/e/ec/Mona_Lisa%2C_by_Leonardo_da_Vinci%2C_from_C2RMF_retouched.jpg/515px-Mona_Lisa%2C_by_Leonardo_da_Vinci%2C_from_C2RMF_retouched.jpg
> 
> Fine with me.

iam really fine with any solution that people are happy with


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

Let us carefully observe those good qualities wherein our enemies excel us
and endeavor to excel them, by avoiding what is faulty, and imitating what
is excellent in them. -- Plutarch


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

Re: [FFmpeg-devel] [PATCH] tests: Download lena.pnm if its missing from the source tree

[Andreas Cadhalpun]

On 28.08.2014 19:49, Reimar Döffinger wrote:

I completely lost track of the discussion, but this all so shouts
bikeshed and overkill.
If I may suggest another colour for the shed:
Put some random, freely licensed image where the Lena image
was, put the Lena one in the sample repository and run the
tests with either just one or both depending on what is available.
Disadvantages: increases runtime
Advantages: everyone running proper tests gets increased coverage
(especially if the image has quite different characteristics),
everyone else still gets a good bit of testing.


I like this colour of the shed. ;)
 * move lena.pnm to the FATE samples
 * add e.g. mona_lisa.pnm and duplicate the vsynth2 tests (as vsynth4?)

Has someone a problem with this solution?

Best regards,
Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] tests: Download lena.pnm if its missing from the source tree

[Nicolas George]

Le primidi 11 fructidor, an CCXXII, Andreas Cadhalpun a écrit :
> I like this colour of the shed. ;)
>  * move lena.pnm to the FATE samples
>  * add e.g. mona_lisa.pnm and duplicate the vsynth2 tests (as vsynth4?)
> 
> Has someone a problem with this solution?

I find it very good.

Just a small nitpick: does the image have to be 256×256? If not, I suggest
to make mona_lisa.pnm 256×384 or 192×288, to avoid cropping the original.

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] tests: Download lena.pnm if its missing from the source tree

[Clément Bœsch]

On Thu, Aug 28, 2014 at 07:28:07PM +0200, Andreas Cadhalpun wrote:
> On 28.08.2014 17:53, Clément Bœsch wrote:
> >ffplay http://lucy.pkh.me/lena.pnm
> >
> >File size and dimensions are the same, and we can of course keep the file
> >name since the person looks like Lena a bit.
> >
> >Would that one be OK?
> >
> >According to http://goo.gl/0K3qyP it should be OK as long as the
> >attribution is kept, which can be done in the commit message.
> 
> The licensing would be OK, but, seriously, do you want such an image in
> FFmpeg's source?
> 
> If you want to keep the original filename, why not use a real Lena [1]
> image, e.g.:
> https://en.wikipedia.org/wiki/File:Lena_Zavaroni_927-0962.jpg
> https://en.wikipedia.org/wiki/File:Headey,_Lena_(2007).jpg
> https://en.wikipedia.org/wiki/File:Lena_Yada.jpg
> https://en.wikipedia.org/wiki/File:Lena_Meyer-Landrut_at_PC_after_2010_Eurovision_2.jpg
> https://en.wikipedia.org/wiki/File:LenaHasesSlim.jpg
> https://en.wikipedia.org/wiki/File:AlexisBledelSept11TIFF.jpg
> 

Joke aside, I just found this:
http://blog.ricbit.com/2009/11/lena-e-ilena.html

"e disponibilizou com a licença Creative Commons Attribution-Share Alike."


-- 
Clément B.


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

Re: [FFmpeg-devel] [PATCH] mark null encoder as ts-nonstrict , avoids error messages for null output

[Rodger Combs]

> On Thu, Aug 21, 2014 at 02:00:22PM +0200, Hendrik Leppkes wrote:
> > On Thu, Aug 21, 2014 at 1:38 PM, compn  > > wrote:
> > > https://gist.github.com/anonymous/0e26f490ec13d67996fd 
> > > 
> > >
> > > commit e94a44543a96b13aa6a23efce2f0378a5479d530
> > > Author: Rodger Combs  > > >
> > > Date:   Wed Aug 20 15:38:12 2014 -0700
> > >
> > > avformat/nullenc: mark null as timestamp-nonstrict
> > > This avoids unnecessary error messages for null output
> > >
> > > diff --git a/libavformat/nullenc.c b/libavformat/nullenc.c
> > > index 7c08c39..58b88a1 100644
> > > --- a/libavformat/nullenc.c
> > > +++ b/libavformat/nullenc.c
> > > @@ -32,5 +32,5 @@ AVOutputFormat ff_null_muxer = {
> > >  .audio_codec   = AV_NE(AV_CODEC_ID_PCM_S16BE, 
> > > AV_CODEC_ID_PCM_S16LE),
> > >  .video_codec   = AV_CODEC_ID_RAWVIDEO,
> > >  .write_packet  = null_write_packet,
> > > -.flags = AVFMT_VARIABLE_FPS | AVFMT_NOFILE | 
> > > AVFMT_NOTIMESTAMPS | AVFMT_RAWPICTURE,
> > > +.flags = AVFMT_TS_NONSTRICT | AVFMT_VARIABLE_FPS | 
> > > AVFMT_NOFILE | AVFMT_NOTIMESTAMPS | AVFMT_RAWPICTURE,
> > >  };
> > 
> > There is a lot of other muxers out there that also have NOTIMESTAMPS
> > set, and not this flag.
> > 
> > IMHO the code that complains about invalid timestamps should be
> > adjusted to not do it when NOTIMESTAMPS is set, instead of this.
> 
> maybe but for testing/fate at least we should retain timestamp
> checks, null is used alot for testing if one looks at trac
> iam not sure what is the best thing to do here

How about adding a lavf option? I could imagine a few ways that could be done, 
but my favorite is to make `AVFMT_NOTIMESTAMPS` imply `AVFMT_TS_NONSTRICT` (on 
the checking code's end), and add an option to re-enable the error (possibly 
downgraded to a warning?) even with non-strict encoders. We could also have the 
option disable the error with strict encoders (but that seems less sensible to 
me).

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

Re: [FFmpeg-devel] [libav-devel] Common mailing-list for API evolutions

[Alexander Strasser]

On 2014-08-28 18:58 +0200, Anton Khirnov wrote:
> On Sun, 24 Aug 2014 00:28:56 +0200, =?utf-8?B?Q2zDqW1lbnQgQsWTc2No?= 
>  wrote:
> > Kieran suggested tonight on #ffmpeg-devel to have a common mailing-list
> > between the two projects to start communicating again in sane terms.
> > 
> > The proposition would be a mailing-list where the 2 projects would send
> > the patches that will make API evolutions. So the projects can continue to
> > drop or add codecs & filters without caring about the other, but will try
> > to communicate more about the API, for the sake of our common users.
> > 
> > At first, I suggest that won't engage anything from any of the two
> > projects (so we don't end up in a stalled states such as one project
> > trying to block the other), but it could be seen as a way to introduce
> > some common technical ground.
> > 
> > What do you think?
> 
> While some kind of non-hostile coexistence or even cooperation is desirable 
> and
> might even be possible, I have large doubts that this specific approach can
> work.
> 
> First, some of your project's developers (most importantly your leader)
> are being actively hostile to our project. That includes spreading FUD about 
> us
> all over the internet, stalking our new contributors, etc. I do not think any
> kind of cooperation can work while this crap goes on.
> 
> Second, how do you propose this arrangement will actually function? As you
> probably know, I see many of the API additions done in your project as ugly
> hacks, and would be strongly opposed to having them in our tree in their 
> current
> form. Conversely, some API changes done in Libav were AFAIK rejected by your
> leader. So -- what happens when one side proposes a change that the other side
> fundamentally disagrees with.
> And furthermore -- what would ensure that the code actually gets pushed to 
> both
> trees. Because otherwise there really is no point to this.

  Please read what you wrote again; it is almost completely hostile
towards FFmpeg...

  Alexander


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

Re: [FFmpeg-devel] [RFC] Bug bounties

[Lou Logan]

On Thu, 28 Aug 2014 19:41:30 +0200, Michael Niedermayer wrote:

> this looks pretty cool
> i am not sure how successfull this would be for us but i definitly
> support the idea of trying this ...

I was thinking it would be more useful as a tool for users and
downstreams to offer bounties (but not necessarily as a tool for "SPI
donations for developer bug killing idea" due to the double fee hit).
Our current system of "user offers bounty, we add bounty keyword on
trac, nothing happens" is not effective.

Maybe I'll ask some other projects that are using it about their opinion
and how they use it. If we like it then I'll start mentioning it on the
bug tracker, etc, and figure out how to best implement it.

Here's the team page:
https://www.bountysource.com/teams/ffmpeg

Interested developers can register and I can add them to the FFmpeg
team. Or lazy people can just squawk here, or email me, and I can send
an invite.

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

Re: [FFmpeg-devel] [RFC] Bug bounties

[Anshul]

On 08/29/2014 01:34 AM, Lou Logan wrote:
> On Thu, 28 Aug 2014 19:41:30 +0200, Michael Niedermayer wrote:
>
>> this looks pretty cool
>> i am not sure how successfull this would be for us but i definitly
>> support the idea of trying this ...
> I was thinking it would be more useful as a tool for users and
> downstreams to offer bounties (but not necessarily as a tool for "SPI
> donations for developer bug killing idea" due to the double fee hit).
> Our current system of "user offers bounty, we add bounty keyword on
> trac, nothing happens" is not effective.
>
> Maybe I'll ask some other projects that are using it about their opinion
> and how they use it. If we like it then I'll start mentioning it on the
> bug tracker, etc, and figure out how to best implement it.
>
> Here's the team page:
> https://www.bountysource.com/teams/ffmpeg
>
> Interested developers can register and I can add them to the FFmpeg
> team. Or lazy people can just squawk here, or email me, and I can send
> an invite.
>
> Lou
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
can you please add me, my id is anshul1912
I have already registered.

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

Re: [FFmpeg-devel] [RFC] Bug bounties

[Michael Niedermayer]

On Thu, Aug 28, 2014 at 12:04:21PM -0800, Lou Logan wrote:
> On Thu, 28 Aug 2014 19:41:30 +0200, Michael Niedermayer wrote:
> 
> > this looks pretty cool
> > i am not sure how successfull this would be for us but i definitly
> > support the idea of trying this ...
> 
> I was thinking it would be more useful as a tool for users and
> downstreams to offer bounties (but not necessarily as a tool for "SPI
> donations for developer bug killing idea" due to the double fee hit).
> Our current system of "user offers bounty, we add bounty keyword on
> trac, nothing happens" is not effective.

yes


> 
> Maybe I'll ask some other projects that are using it about their opinion
> and how they use it. If we like it then I'll start mentioning it on the
> bug tracker, etc, and figure out how to best implement it.

please do & thanks

[...]

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

[FFmpeg-devel] [PATCH 2/2] Add missing "const" all over the place.

[Reimar Döffinger]

There is a risk that one in the code that is not always
compiled might break things.

Signed-off-by: Reimar Döffinger 
---
 ffserver.c  |  2 +-
 libavcodec/aaccoder.c   |  2 +-
 libavcodec/aic.c|  2 +-
 libavcodec/atrac3plus.c | 38 +++---
 libavcodec/dcaenc.h |  4 ++--
 libavcodec/evrcdata.h   |  2 +-
 libavcodec/g722dec.c|  2 +-
 libavcodec/indeo3.c |  4 ++--
 libavcodec/indeo4data.h |  2 +-
 libavcodec/mips/aaccoder_mips.c |  2 +-
 libavcodec/movtextenc.c |  2 +-
 libavcodec/ppc/fdctdsp.c|  2 +-
 libavcodec/sipr.c   |  2 +-
 libavcodec/siprdata.h   |  2 +-
 libavcodec/wavpackenc.h |  2 +-
 libavcodec/x86/mlpdsp.c |  4 ++--
 libavcodec/x86/videodsp_init.c  |  8 
 libavdevice/bktr.c  |  2 +-
 libavdevice/opengl_enc.c|  2 +-
 libavfilter/af_volume.c |  2 +-
 libavfilter/f_perms.c   |  2 +-
 libavfilter/vf_colormatrix.c|  2 +-
 libavfilter/vf_drawtext.c   |  2 +-
 libavfilter/vf_overlay.c|  2 +-
 libavfilter/vf_rotate.c |  4 ++--
 libavfilter/vf_subtitles.c  |  2 +-
 libavformat/libmodplug.c|  2 +-
 libavformat/mov_chan.c  |  2 +-
 libavformat/rtspcodes.h |  2 +-
 libavresample/audio_mix.c   |  2 +-
 libavutil/frame.c   |  2 +-
 libpostproc/postprocess.c   |  2 +-
 32 files changed, 57 insertions(+), 57 deletions(-)

diff --git a/ffserver.c b/ffserver.c
index c1c8530..dc7c5f2 100644
--- a/ffserver.c
+++ b/ffserver.c
@@ -91,7 +91,7 @@ enum HTTPState {
 RTSPSTATE_SEND_PACKET,
 };
 
-static const char *http_state[] = {
+static const char * const http_state[] = {
 "HTTP_WAIT_REQUEST",
 "HTTP_SEND_HEADER",
 
diff --git a/libavcodec/aaccoder.c b/libavcodec/aaccoder.c
index abdefb6..6f6e4b5 100644
--- a/libavcodec/aaccoder.c
+++ b/libavcodec/aaccoder.c
@@ -53,7 +53,7 @@ static const uint8_t run_value_bits_short[16] = {
 3, 3, 3, 3, 3, 3, 3, 6, 6, 6, 6, 6, 6, 6, 6, 9
 };
 
-static const uint8_t *run_value_bits[2] = {
+static const uint8_t * const run_value_bits[2] = {
 run_value_bits_long, run_value_bits_short
 };
 
diff --git a/libavcodec/aic.c b/libavcodec/aic.c
index 00be08b..3472301 100644
--- a/libavcodec/aic.c
+++ b/libavcodec/aic.c
@@ -132,7 +132,7 @@ static const uint8_t aic_c_ext_scan[192] = {
 177, 184, 176, 169, 162, 161, 168, 160,
 };
 
-static const uint8_t *aic_scan[NUM_BANDS] = {
+static const uint8_t * const aic_scan[NUM_BANDS] = {
 aic_y_scan, aic_c_scan, aic_y_ext_scan, aic_c_ext_scan
 };
 
diff --git a/libavcodec/atrac3plus.c b/libavcodec/atrac3plus.c
index 08c90cd..f7a42cc 100644
--- a/libavcodec/atrac3plus.c
+++ b/libavcodec/atrac3plus.c
@@ -84,52 +84,52 @@ av_cold void ff_atrac3p_init_vlcs(void)
 {
 int i, wl_vlc_offs, ct_vlc_offs, sf_vlc_offs, tab_offset;
 
-static int wl_nb_bits[4]  = { 2, 3, 5, 5 };
-static int wl_nb_codes[4] = { 3, 5, 8, 8 };
-static const uint8_t *wl_bits[4] = {
+static const int wl_nb_bits[4]  = { 2, 3, 5, 5 };
+static const int wl_nb_codes[4] = { 3, 5, 8, 8 };
+static const uint8_t * const wl_bits[4] = {
 atrac3p_wl_huff_bits1, atrac3p_wl_huff_bits2,
 atrac3p_wl_huff_bits3, atrac3p_wl_huff_bits4
 };
-static const uint8_t *wl_codes[4] = {
+static const uint8_t * const wl_codes[4] = {
 atrac3p_wl_huff_code1, atrac3p_wl_huff_code2,
 atrac3p_wl_huff_code3, atrac3p_wl_huff_code4
 };
-static const uint8_t *wl_xlats[4] = {
+static const uint8_t * const wl_xlats[4] = {
 atrac3p_wl_huff_xlat1, atrac3p_wl_huff_xlat2, NULL, NULL
 };
 
-static int ct_nb_bits[4]  = { 3, 4, 4, 4 };
-static int ct_nb_codes[4] = { 4, 8, 8, 8 };
-static const uint8_t *ct_bits[4]  = {
+static const int ct_nb_bits[4]  = { 3, 4, 4, 4 };
+static const int ct_nb_codes[4] = { 4, 8, 8, 8 };
+static const uint8_t * const ct_bits[4]  = {
 atrac3p_ct_huff_bits1, atrac3p_ct_huff_bits2,
 atrac3p_ct_huff_bits2, atrac3p_ct_huff_bits3
 };
-static const uint8_t *ct_codes[4] = {
+static const uint8_t * const ct_codes[4] = {
 atrac3p_ct_huff_code1, atrac3p_ct_huff_code2,
 atrac3p_ct_huff_code2, atrac3p_ct_huff_code3
 };
-static const uint8_t *ct_xlats[4] = {
+static const uint8_t * const ct_xlats[4] = {
 NULL, NULL, atrac3p_ct_huff_xlat1, NULL
 };
 
-static int sf_nb_bits[8]  = {  9,  9,  9,  9,  6,  6,  7,  7 };
-static int sf_nb_codes[8] = { 64, 64, 64, 64, 16, 16, 16, 16 };
-static const uint8_t  *sf_bits[8]  = {
+static const  int sf_nb_bits[8]  = {  9,  9,  9,  9,  6,  6,  7,  7 };
+static const  int sf_nb_codes[8] = { 64, 64, 64, 64, 16, 16, 16, 16 };
+static const uint8_t  * const sf_bits[8]  = {
 atrac3p_sf_huff_bits1, atrac3p_sf_huff_bits1, atrac3p_sf_huff_bits2,

[FFmpeg-devel] [PATCH 1/2] patcheck: check for pointer arrays that are not const.

[Reimar Döffinger]

Signed-off-by: Reimar Döffinger 
---
 tools/patcheck | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/patcheck b/tools/patcheck
index 3342c6a..cbdbf8d 100755
--- a/tools/patcheck
+++ b/tools/patcheck
@@ -42,6 +42,7 @@ hiegrep2(){
 cat $TMP
 }
 
+hiegrep 'static[^(]*\*[a-zA-Z_]*\[' 'pointer array is not const' $*
 hiegrep '[[:space:]]$''trailing whitespace' $*
 hiegrep "$(echo x | tr 'x' '\t')" 'tabs' $*
 #hiegrep ':\+$'  'Empty lines' $*
-- 
2.1.0

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

Re: [FFmpeg-devel] [PATCH 2/2] Add missing "const" all over the place.

[Timothy Gu]

On Aug 28, 2014 3:46 PM, "Reimar Döffinger" 
wrote:
>
> There is a risk that one in the code that is not always
> compiled might break things.

What do you mean by 'one in the code'?

[...]

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

Re: [FFmpeg-devel] [FFmpeg-cvslog] avformat/rtpdec_asf: fix compiler warning about const qualifier being discarded

[Timothy Gu]

On Aug 28, 2014 6:14 AM, "Michael Niedermayer"  wrote:
>
> buf is assigned to AVIOContext.buffer, which is written to by some
> functions using AVIOContext

Doesn't const only apply to this particular function? In other words,
doesn't const only guarantee that it is not changed inside this particular
function?

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

[FFmpeg-devel] [PATCH] doc/demuxers: document gif demuxer

[Lou Logan]

Signed-off-by: Lou Logan 
---
 doc/demuxers.texi | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/doc/demuxers.texi b/doc/demuxers.texi
index d51b9d0..7b96d85 100644
--- a/doc/demuxers.texi
+++ b/doc/demuxers.texi
@@ -174,6 +174,32 @@ See @url{http://quvi.sourceforge.net/} for more 
information.
 FFmpeg needs to be built with @code{--enable-libquvi} for this demuxer to be
 enabled.
 
+@section gif
+
+Animated GIF demuxer.
+
+It accepts the following options:
+
+@table @option
+@item min_delay
+Set the minimum valid delay between frames in hundredths of seconds.
+Range is 0 to 6000. Default value is 2.
+
+@item default_delay
+Set the default delay between frames in hundredths of seconds.
+Range is 0 to 6000. Default value is 10.
+
+@item ignore_loop
+If set to 1, ignore loop setting (Netscape Looping Application
+Extension). Default value is 1.
+@end table
+
+For example, with the overlay filter, place a continuously looping gif
+over another video:
+@example
+ffmpeg -i input.mp4 -ignore_loop 0 -i input.gif -filter_complex 
overlay=shortest=1 out.mkv
+@end example
+
 @section image2
 
 Image file demuxer.
-- 
2.0.4

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

Re: [FFmpeg-devel] [PATCH 2/2] Add missing "const" all over the place.

[Michael Niedermayer]

On Fri, Aug 29, 2014 at 12:45:34AM +0200, Reimar Döffinger wrote:
> There is a risk that one in the code that is not always
> compiled might break things.

builds fine here

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Democracy is the form of government in which you can choose your dictator


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] patcheck: check for pointer arrays that are not const.

[Michael Niedermayer]

On Fri, Aug 29, 2014 at 12:45:33AM +0200, Reimar Döffinger wrote:
> Signed-off-by: Reimar Döffinger 
> ---
>  tools/patcheck | 1 +
>  1 file changed, 1 insertion(+)

should be ok

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

Awnsering whenever a program halts or runs forever is
On a turing machine, in general impossible (turings halting problem).
On any real computer, always possible as a real computer has a finite number
of states N, and will either halt in less than N cycles or never halt.


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

Re: [FFmpeg-devel] [PATCH] doc/demuxers: document gif demuxer

[Timothy Gu]

On Aug 28, 2014 5:27 PM, "Lou Logan"  wrote:
>
> Signed-off-by: Lou Logan 
> ---
>  doc/demuxers.texi | 26 ++
>  1 file changed, 26 insertions(+)
>
> diff --git a/doc/demuxers.texi b/doc/demuxers.texi
> index d51b9d0..7b96d85 100644
> --- a/doc/demuxers.texi
> +++ b/doc/demuxers.texi
> @@ -174,6 +174,32 @@ See @url{http://quvi.sourceforge.net/} for more
information.
>  FFmpeg needs to be built with @code{--enable-libquvi} for this demuxer
to be
>  enabled.
>
> +@section gif
> +
> +Animated GIF demuxer.
> +
> +It accepts the following options:
> +
> +@table @option
> +@item min_delay
> +Set the minimum valid delay between frames in hundredths of seconds.
> +Range is 0 to 6000. Default value is 2.
> +
> +@item default_delay
> +Set the default delay between frames in hundredths of seconds.
> +Range is 0 to 6000. Default value is 10.
> +
> +@item ignore_loop

> +If set to 1, ignore loop setting (Netscape Looping Application
> +Extension). Default value is 1.

If it is 0 does it loop forever?

> +@end table
> +

> +For example, with the overlay filter, place a continuously looping gif

GIF

> +over another video:

Add: The shortest option for overlay filter is used to cut off the output
video at the length of the shortest input file, which is always
@file{file.mp4} as the GIF loops forever.

> +@example
> +ffmpeg -i input.mp4 -ignore_loop 0 -i input.gif -filter_complex
overlay=shortest=1 out.mkv
> +@end example
> +
>  @section image2
>
>  Image file demuxer.

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

Re: [FFmpeg-devel] [PATCH] tests: Download lena.pnm if its missing from the source tree

[Michael Niedermayer]

On Thu, Aug 28, 2014 at 08:55:40PM +0200, Clément Bœsch wrote:
> On Thu, Aug 28, 2014 at 07:28:07PM +0200, Andreas Cadhalpun wrote:
> > On 28.08.2014 17:53, Clément Bœsch wrote:
> > >ffplay http://lucy.pkh.me/lena.pnm
> > >
> > >File size and dimensions are the same, and we can of course keep the file
> > >name since the person looks like Lena a bit.
> > >
> > >Would that one be OK?
> > >
> > >According to http://goo.gl/0K3qyP it should be OK as long as the
> > >attribution is kept, which can be done in the commit message.
> > 
> > The licensing would be OK, but, seriously, do you want such an image in
> > FFmpeg's source?
> > 
> > If you want to keep the original filename, why not use a real Lena [1]
> > image, e.g.:
> > https://en.wikipedia.org/wiki/File:Lena_Zavaroni_927-0962.jpg
> > https://en.wikipedia.org/wiki/File:Headey,_Lena_(2007).jpg
> > https://en.wikipedia.org/wiki/File:Lena_Yada.jpg
> > https://en.wikipedia.org/wiki/File:Lena_Meyer-Landrut_at_PC_after_2010_Eurovision_2.jpg
> > https://en.wikipedia.org/wiki/File:LenaHasesSlim.jpg
> > https://en.wikipedia.org/wiki/File:AlexisBledelSept11TIFF.jpg
> > 
> 
> Joke aside, I just found this:
> http://blog.ricbit.com/2009/11/lena-e-ilena.html

these are all jpeg and not raw, for the purpose of research a raw
or lossessly compressed image would be better.
for regression tests it shouldnt matter though



[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If a bugfix only changes things apparently unrelated to the bug with no
further explanation, that is a good sign that the bugfix is wrong.


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

Re: [FFmpeg-devel] [PATCH 2/2] fate: Add basic tests for WebM Dash Manifest

[Michael Niedermayer]

On Mon, Aug 25, 2014 at 03:03:45PM -0700, Vignesh Venkatasubramanian wrote:
> Add fate tests that test out the functionality of WebM DASH
> Manifest XML generation. This patch contains the vpx.mak file
> changes and the reference gold XML files.
> ---
>  tests/fate/vpx.mak |  9 
>  tests/ref/fate/webm-dash-manifest  | 48 
> ++
>  .../webm-dash-manifest-unaligned-audio-streams | 30 ++
>  .../webm-dash-manifest-unaligned-video-streams | 30 ++
>  4 files changed, 117 insertions(+)
>  create mode 100644 tests/ref/fate/webm-dash-manifest
>  create mode 100644 tests/ref/fate/webm-dash-manifest-unaligned-audio-streams
>  create mode 100644 tests/ref/fate/webm-dash-manifest-unaligned-video-streams

applied

thanks

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

Republics decline into democracies and democracies degenerate into
despotisms. -- Aristotle


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

Re: [FFmpeg-devel] [FFmpeg-cvslog] fate: Add basic tests for WebM Dash Manifest

[James Almer]

> diff --git a/tests/fate/vpx.mak b/tests/fate/vpx.mak
> index 54be950..77c7c76 100644
> --- a/tests/fate/vpx.mak
> +++ b/tests/fate/vpx.mak
> @@ -28,6 +28,15 @@ fate-vp6f: CMD = framecrc -flags +bitexact -i 
> $(TARGET_SAMPLES)/flash-vp6/clip10
>  FATE_VP8-$(call DEMDEC, FLV, VP8) += fate-vp8-alpha
>  fate-vp8-alpha: CMD = framecrc -i 
> $(TARGET_SAMPLES)/vp8_alpha/vp8_video_with_alpha.webm -vcodec copy
>  
> +FATE_VP8-$(call DEMDEC, FLV, VP8) += fate-webm-dash-manifest
> +fate-webm-dash-manifest: CMD = run ffmpeg -f webm_dash_manifest -i 
> $(TARGET_SAMPLES)/vp8/dash_video1.webm -f webm_dash_manifest -i 
> $(TARGET_SAMPLES)/vp8/dash_video2.webm -f webm_dash_manifest -i 
> $(TARGET_SAMPLES)/vp8/dash_audio1.webm -f webm_dash_manifest -i 
> $(TARGET_SAMPLES)/vp8/dash_audio2.webm -c copy -map 0 -map 1 -map 2 -map 3 -f 
> webm_dash_manifest -adaptation_sets "id=0,streams=0,1 id=1,streams=2,3" -
> +
> +FATE_VP8-$(call DEMDEC, FLV, VP8) += 
> fate-webm-dash-manifest-unaligned-video-streams
> +fate-webm-dash-manifest-unaligned-video-streams: CMD = run ffmpeg -f 
> webm_dash_manifest -i $(TARGET_SAMPLES)/vp8/dash_video1.webm -f 
> webm_dash_manifest -i $(TARGET_SAMPLES)/vp8/dash_video3.webm -c copy -map 0 
> -map 1 -f webm_dash_manifest -adaptation_sets "id=0,streams=0,1" -
> +
> +FATE_VP8-$(call DEMDEC, FLV, VP8) += 
> fate-webm-dash-manifest-unaligned-audio-streams
> +fate-webm-dash-manifest-unaligned-audio-streams: CMD = run ffmpeg -f 
> webm_dash_manifest -i $(TARGET_SAMPLES)/vp8/dash_audio1.webm -f 
> webm_dash_manifest -i $(TARGET_SAMPLES)/vp8/dash_audio3.webm -c copy -map 0 
> -map 1 -f webm_dash_manifest -adaptation_sets "id=0,streams=0,1" -

Why are all these tests checking for the presence of the flv demuxer when they 
need the webm_dash_manifest demuxer?
Also, is the vp8 decoder necessary? This doesn't seem to actually process the 
streams.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [libav-devel] Common mailing-list for API evolutions

[Clément Bœsch]

On Fri, Aug 29, 2014 at 01:00:45AM +0200, Diego Biurrun wrote:
> On Sun, Aug 24, 2014 at 12:28:56AM +0200, Clément Bœsch wrote:
> > 
> > Kieran suggested tonight on #ffmpeg-devel to have a common mailing-list
> > between the two projects to start communicating again in sane terms.
> > 
> > The proposition would be a mailing-list where the 2 projects would send
> > the patches that will make API evolutions. So the projects can continue to
> > drop or add codecs & filters without caring about the other, but will try
> > to communicate more about the API, for the sake of our common users.
> > 
> > At first, I suggest that won't engage anything from any of the two
> > projects (so we don't end up in a stalled states such as one project
> > trying to block the other), but it could be seen as a way to introduce
> > some common technical ground.
> 
> Your use of "engaged" makes my English parser return ENOUNDERSTAND.
> 

"I suggest that won't force/constrain any of the two projects of anything"

[...]
> Often times API additions or changes are discussed on this mailing list.
> You FFmpeg people are all subscribed here; what stops you from replying
> on this mailing list?

It's not a neutral area. The goal is *not* to have an effective way of
designing & reviewing API, both projects already have this. It's a
proposition of an area where people from both projects (or even shared
downstream users) would be comfortable to talk to each others, and
eventually reach some agreements.

[...]

To be more specific about the why I'm suggesting this right now: Kieran
wanted such thing to be discussed "in real life" in one of those meetings.
Unfortunately, some of the main FFmpeg developers are not willing to do
this, partly because it's probably pointless, and partly because it's seen
as a threat (and various other reasons I won't expand on). Such discussion
is happening right now over a reliable medium, where everyone can
participate.

The point being that if Libav or FFmpeg folks are not able to discuss such
proposition here in sane terms, then there is no reason at all the outcome
could be more positive in real life, and so such meeting will not happen.

-- 
Clément B.


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

Re: [FFmpeg-devel] [PATCH] doc/demuxers: document gif demuxer

[Clément Bœsch]

On Thu, Aug 28, 2014 at 04:27:08PM -0800, Lou Logan wrote:
> Signed-off-by: Lou Logan 
> ---
>  doc/demuxers.texi | 26 ++
>  1 file changed, 26 insertions(+)
> 
> diff --git a/doc/demuxers.texi b/doc/demuxers.texi
> index d51b9d0..7b96d85 100644
> --- a/doc/demuxers.texi
> +++ b/doc/demuxers.texi
> @@ -174,6 +174,32 @@ See @url{http://quvi.sourceforge.net/} for more 
> information.
>  FFmpeg needs to be built with @code{--enable-libquvi} for this demuxer to be
>  enabled.
>  
> +@section gif
> +
> +Animated GIF demuxer.
> +
> +It accepts the following options:
> +
> +@table @option
> +@item min_delay
> +Set the minimum valid delay between frames in hundredths of seconds.
> +Range is 0 to 6000. Default value is 2.
> +
> +@item default_delay
> +Set the default delay between frames in hundredths of seconds.
> +Range is 0 to 6000. Default value is 10.
> +
> +@item ignore_loop
> +If set to 1, ignore loop setting (Netscape Looping Application
> +Extension). Default value is 1.

Can you add "This option prevents having a GIF streaming looping forever"
before the default value sentence?

[...]

-- 
Clément B.


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

Re: [FFmpeg-devel] [PATCH] doc/demuxers: document gif demuxer

[Clément Bœsch]

On Fri, Aug 29, 2014 at 07:47:41AM +0200, Clément Bœsch wrote:
> On Thu, Aug 28, 2014 at 04:27:08PM -0800, Lou Logan wrote:
> > Signed-off-by: Lou Logan 
> > ---
> >  doc/demuxers.texi | 26 ++
> >  1 file changed, 26 insertions(+)
> > 
> > diff --git a/doc/demuxers.texi b/doc/demuxers.texi
> > index d51b9d0..7b96d85 100644
> > --- a/doc/demuxers.texi
> > +++ b/doc/demuxers.texi
> > @@ -174,6 +174,32 @@ See @url{http://quvi.sourceforge.net/} for more 
> > information.
> >  FFmpeg needs to be built with @code{--enable-libquvi} for this demuxer to 
> > be
> >  enabled.
> >  
> > +@section gif
> > +
> > +Animated GIF demuxer.
> > +
> > +It accepts the following options:
> > +
> > +@table @option
> > +@item min_delay
> > +Set the minimum valid delay between frames in hundredths of seconds.
> > +Range is 0 to 6000. Default value is 2.
> > +
> > +@item default_delay
> > +Set the default delay between frames in hundredths of seconds.
> > +Range is 0 to 6000. Default value is 10.
> > +
> > +@item ignore_loop
> > +If set to 1, ignore loop setting (Netscape Looping Application
> > +Extension). Default value is 1.
> 
> Can you add "This option prevents having a GIF streaming looping forever"

a GIF stream*

-- 
Clément B.


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

[FFmpeg-devel] [PATCH] avformat/wtvdec: seek over broken chunks

[Peter Ross]

Fixes ticket #3898

Signed-off-by: Peter Ross 
---
 libavformat/wtvdec.c | 29 +++--
 1 file changed, 27 insertions(+), 2 deletions(-)

diff --git a/libavformat/wtvdec.c b/libavformat/wtvdec.c
index c70057c..4cb3295 100644
--- a/libavformat/wtvdec.c
+++ b/libavformat/wtvdec.c
@@ -751,6 +751,26 @@ enum {
 };
 
 /**
+ * Try to seek over a broken chunk
+ * @return <0 on error
+ */
+static int recover(WtvContext *wtv, uint64_t broken_pos)
+{
+AVIOContext *pb = wtv->pb;
+int i;
+for (i = 0; i < wtv->nb_index_entries; i++) {
+if (wtv->index_entries[i].pos > broken_pos) {
+int ret = avio_seek(pb, wtv->index_entries[i].pos, SEEK_SET);
+if (ret < 0)
+return ret;
+wtv->pts = wtv->index_entries[i].timestamp;
+return 0;
+ }
+ }
+ return AVERROR(EIO);
+}
+
+/**
  * Parse WTV chunks
  * @param mode SEEK_TO_DATA or SEEK_TO_PTS
  * @param seekts timestamp
@@ -767,8 +787,13 @@ static int parse_chunks(AVFormatContext *s, int mode, 
int64_t seekts, int *len_p
 
 ff_get_guid(pb, &g);
 len = avio_rl32(pb);
-if (len < 32)
-break;
+if (len < 32) {
+int ret;
+av_log(s, AV_LOG_WARNING, "encountered broken chunk\n");
+if ((ret = recover(wtv, avio_tell(pb) - 20)) < 0)
+return ret;
+continue;
+}
 sid = avio_rl32(pb) & 0x7FFF;
 avio_skip(pb, 8);
 consumed = 32;
-- 
1.9.1

-- Peter
(A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B)


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