Re: [FFmpeg-devel] [PATCH]Fix pnm encoding with bpc set

[Reimar Döffinger]

On 25.08.2014, at 19:33, Christophe Gisquet  
wrote:
> Hi,
> 
> 2014-08-25 6:41 GMT+02:00 Reimar Döffinger :
>> The colorspace is supposed to be authoritative.
>> If it says 16 bit, then showing it as 16 bit must work properly.
>> The only intention of bits_per_raw_sample is to indicate that there is no 
>> point in storing some of the lower bits if you have the option.
> 
> ie, actually writing a smaller bitdepth, like what was achieved for
> ppm by my patch and Carl Eugen's ?
> 
> I find this very inconvenient for 2 things:
> - you force an additional roundtrip to 16bps when going eg 12bps to
> 12bps, while forcing 16bps just moves the scaling from the decoder to
> outside (ok that's one additional copy)

There is no "round trip" really just an additional shift on reading and writing.

> - you need to maintain different buffers for predictive codecs (ie
> both the encoder and the decoder), one being what is actually coded,
> and the other for the output of the decoder/input of the encoder
> (though it is not an actual full copy and can just be done in coding
> units eg MB)

Currently no relevant codecs use 12 bits, which is the reason why 9 and 10 bits 
exist as separate formats while 12 bits does not.
For simple formats, doing a val = (val << 4) | (val >> 12) before each store is 
completely acceptable.
Amd for reference frames you certainly do not need an actual full copy, that 
would be silly, you just need to add a shift after each load.

> I don't think I can have time both for convincing you and CE of this,
> then implement fixes everywhere needed, then introduce incompatible
> APIs, so just read this as a statement of my opinion, and let's close
> the subject. I have understood this line of thought is futile.

I don't have a particular opinion on what the design should be, I am just 
describing how it was intended.

>> That can be solved by a common function if necessary, alternatively a 12 bit 
>> colorspace could be added, but the cost/benefit is questionable.
> 
> I think at this point they all have in common "sample storage rounded
> to the upper bytecount" and "raw_bits is indicative of what they
> hold". Adding them is just going to make the scalers more tentacular.
> But my opinion of moving the scaling from the decoder to a specialized
> function also does this.

There is the additional issue that it (just like changing the meaning of raw 
bits) will require each application to add support for it.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavf/matroskadec: Ensure cues_end is initialized

[Reimar Döffinger]

On 25.08.2014, at 18:15, Vignesh Venkatasubramanian  wrote:

> avio_seek(matroska->ctx->pb, before_pos, SEEK_SET);
> +if (cues_start == -1 || cues_end == -1) return -1;

Shouldn't this use something more descriptive than -1?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] tests: switch to a test image that is under public domain

[Clément Bœsch]

On Tue, Aug 26, 2014 at 01:42:17AM +0200, Michael Niedermayer wrote:
> From: Andreas Cadhalpun 
> 
> ---
>  LICENSE.md |1 +
>  tests/Makefile |2 +-
>  tests/flower.pnm   |  Bin 0 -> 196623 bytes
>  tests/lena.pnm |  109 
> 
>  tests/ref/fate/force_key_frames|8 +-
>  tests/ref/fate/sub2video   |  100 -
>  tests/ref/seek/vsynth2-asv1|   40 +-
>  tests/ref/seek/vsynth2-asv2|   40 +-
>  tests/ref/seek/vsynth2-ffv1|   40 +-
>  tests/ref/seek/vsynth2-flashsv |   40 +-
>  tests/ref/seek/vsynth2-flv |   40 +-
>  tests/ref/seek/vsynth2-h261|   40 +-
>  tests/ref/seek/vsynth2-h263|   40 +-
>  tests/ref/seek/vsynth2-h263p   |   40 +-
>  tests/ref/seek/vsynth2-huffyuv |   40 +-
>  tests/ref/seek/vsynth2-jpegls  |   40 +-
>  tests/ref/seek/vsynth2-ljpeg   |   40 +-
>  tests/ref/seek/vsynth2-mjpeg   |   40 +-
>  tests/ref/seek/vsynth2-mpeg1   |   40 +-
>  tests/ref/seek/vsynth2-mpeg1b  |   40 +-
>  tests/ref/seek/vsynth2-mpeg2-422   |   40 +-
>  tests/ref/seek/vsynth2-mpeg2-idct-int  |   40 +-
>  tests/ref/seek/vsynth2-mpeg2-ilace |   40 +-
>  tests/ref/seek/vsynth2-mpeg2-ivlc-qprd |   40 +-
>  tests/ref/seek/vsynth2-mpeg2-thread|   40 +-
>  tests/ref/seek/vsynth2-mpeg2-thread-ivlc   |   40 +-
>  tests/ref/seek/vsynth2-mpeg4   |   48 ++--
>  tests/ref/seek/vsynth2-mpeg4-adap  |   40 +-
>  tests/ref/seek/vsynth2-mpeg4-adv   |   40 +-
>  tests/ref/seek/vsynth2-mpeg4-error |   40 +-
>  tests/ref/seek/vsynth2-mpeg4-nr|   40 +-
>  tests/ref/seek/vsynth2-mpeg4-nsse  |   40 +-
>  tests/ref/seek/vsynth2-mpeg4-qpel  |   40 +-
>  tests/ref/seek/vsynth2-mpeg4-qprd  |   40 +-
>  tests/ref/seek/vsynth2-mpeg4-rc|   40 +-
>  tests/ref/seek/vsynth2-mpeg4-thread|   40 +-
>  tests/ref/seek/vsynth2-msmpeg4 |   40 +-
>  tests/ref/seek/vsynth2-msmpeg4v2   |   40 +-
>  tests/ref/seek/vsynth2-roqvideo|2 +-
>  tests/ref/seek/vsynth2-rv10|   55 +++---
>  tests/ref/seek/vsynth2-rv20|   54 +++---
>  tests/ref/seek/vsynth2-snow|   40 +-
>  tests/ref/seek/vsynth2-snow-ll |   40 +-
>  tests/ref/seek/vsynth2-svq1|   48 ++--
>  tests/ref/seek/vsynth2-wmv1|   40 +-
>  tests/ref/seek/vsynth2-wmv2|   40 +-
>  tests/ref/vsynth/vsynth2-amv   |8 +-
>  tests/ref/vsynth/vsynth2-asv1  |8 +-
>  tests/ref/vsynth/vsynth2-asv2  |8 +-
>  tests/ref/vsynth/vsynth2-avui  |4 +-
>  tests/ref/vsynth/vsynth2-cljr  |6 +-
>  tests/ref/vsynth/vsynth2-dnxhd-1080i   |6 +-
>  tests/ref/vsynth/vsynth2-dnxhd-720p|6 +-
>  tests/ref/vsynth/vsynth2-dnxhd-720p-10bit  |6 +-
>  tests/ref/vsynth/vsynth2-dnxhd-720p-rd |6 +-
>  tests/ref/vsynth/vsynth2-dv|6 +-
>  tests/ref/vsynth/vsynth2-dv-411|6 +-
>  tests/ref/vsynth/vsynth2-dv-50 |6 +-
>  tests/ref/vsynth/vsynth2-ffv1  |6 +-
>  tests/ref/vsynth/vsynth2-ffv1.0|6 +-
>  tests/ref/vsynth/vsynth2-ffvhuff   |6 +-
>  tests/ref/vsynth/vsynth2-ffvhuff420p12 |8 +-
>  tests/ref/vsynth/vsynth2-ffvhuff422p10left |8 +-
>  tests/ref/vsynth/vsynth2-ffvhuff444|8 +-
>  tests/ref/vsynth/vsynth2-ffvhuff444p16 |8 +-
>  tests/ref/vsynth/vsynth2-flashsv   |8 +-
>  tests/ref/vsynth/vsynth2-flashsv2  |8 +-
>  tests/ref/vsynth/vsynth2-flv   |8 +-
>  tests/ref/vsynth/vsynth2-h261  |8 +-
>  tests/ref/vsynth/vsynth2-h261-trellis  |8 +-
>  tests/ref/vsynth/vsynth2-h263  |8 +-
>  tests/ref/vsynth/vsynth2-h263-obmc |8 +-
>  tests/ref/vsynth/vsynth2-h263p |8 +-
>  tests/ref/vsynth/vsynth2-huffyuv   |6 +-
>  tests/ref/vsynth/vsynth2-huffyuvbgr24  |8 +-
>  tests/ref/vsynth/vsynth2-huffyuvbgra   |8 +-
>  tests/ref/vsynth/vsynth2-jpeg2000  |8 +-
>  tests/ref/vsynth/vsynth2-jpeg2000-97   |8 +-
>  tests/ref/vsynth/vsynth2-jpegls|8 +-
>  tests/ref/vsynth/vsynth2-ljpeg |6 +-
>  tests/ref/vsynth/vsyn

Re: [FFmpeg-devel] [PATCH] tests: switch to a test image that is under public domain

[Andreas Cadhalpun]

On 26.08.2014 01:42, Michael Niedermayer wrote:

From: Andreas Cadhalpun 

---
  LICENSE.md |1 +
  tests/Makefile |2 +-
  tests/flower.pnm   |  Bin 0 -> 196623 bytes
  tests/lena.pnm |  109 

[...]

  128 files changed, 1161 insertions(+), 1268 deletions(-)
  create mode 100644 tests/flower.pnm
  delete mode 100644 tests/lena.pnm

diff --git a/LICENSE.md b/LICENSE.md
index e78d932..ccd494f 100644
--- a/LICENSE.md
+++ b/LICENSE.md
@@ -64,6 +64,7 @@ There are a handful of files under other licensing terms, 
namely:
You must also indicate any changes including additions and deletions to
those three files in the documentation.

+tests/flower.pnm is under public domain


It is disputed whether or not the laws in Germany/Austria allow placing 
work in the public domain [1].

To avoid any doubt, it would be better to change this to something like:

tests/flower.pnm copyrighted by Michael Niedermayer is placed in the 
public domain by licensing it under CCO, see:

https://creativecommons.org/publicdomain/zero/1.0/legalcode

Best regards,
Andreas

1: 
https://de.wikipedia.org/wiki/Gemeinfreiheit#Entlassung_in_die_Gemeinfreiheit

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

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

[Michael Niedermayer]

Signed-off-by: Michael Niedermayer 
---
 tests/Makefile |5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/tests/Makefile b/tests/Makefile
index 07557f9..2f095df 100644
--- a/tests/Makefile
+++ b/tests/Makefile
@@ -24,13 +24,16 @@ $(VREF): tests/videogen$(HOSTEXESUF) | tests/vsynth1
 $(AREF): tests/audiogen$(HOSTEXESUF) | tests/data
$(M)./$< $@
 
+$(SRC_PATH)/tests/lena.pnm:
+   wget -O $@  http://samples.ffmpeg.org/image-samples/lena.pnm
+
 tests/data/asynth-%.wav: tests/audiogen$(HOSTEXESUF) | tests/data
$(M)./$< $@ $(subst -, ,$*)
 
 tests/data/vsynth1.yuv: tests/videogen$(HOSTEXESUF) | tests/data
$(M)$< $@
 
-tests/data/vsynth2.yuv: tests/rotozoom$(HOSTEXESUF) | tests/data
+tests/data/vsynth2.yuv: tests/rotozoom$(HOSTEXESUF) $(SRC_PATH)/tests/lena.pnm 
| tests/data
$(M)$< $(SRC_PATH)/tests/lena.pnm $@
 
 tests/data/vsynth3.yuv: tests/videogen$(HOSTEXESUF) | tests/data
-- 
1.7.9.5

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

Re: [FFmpeg-devel] [PATCH] tests: switch to a test image that is under public domain

[Michael Niedermayer]

On Tue, Aug 26, 2014 at 11:16:24AM +0200, Clément Bœsch wrote:
> On Tue, Aug 26, 2014 at 01:42:17AM +0200, Michael Niedermayer wrote:
> > From: Andreas Cadhalpun 
> > 
> > ---
> >  LICENSE.md |1 +
> >  tests/Makefile |2 +-
> >  tests/flower.pnm   |  Bin 0 -> 196623 bytes
> >  tests/lena.pnm |  109 
> > 
> >  tests/ref/fate/force_key_frames|8 +-
> >  tests/ref/fate/sub2video   |  100 -
> >  tests/ref/seek/vsynth2-asv1|   40 +-
> >  tests/ref/seek/vsynth2-asv2|   40 +-
> >  tests/ref/seek/vsynth2-ffv1|   40 +-
> >  tests/ref/seek/vsynth2-flashsv |   40 +-
> >  tests/ref/seek/vsynth2-flv |   40 +-
> >  tests/ref/seek/vsynth2-h261|   40 +-
> >  tests/ref/seek/vsynth2-h263|   40 +-
> >  tests/ref/seek/vsynth2-h263p   |   40 +-
> >  tests/ref/seek/vsynth2-huffyuv |   40 +-
> >  tests/ref/seek/vsynth2-jpegls  |   40 +-
> >  tests/ref/seek/vsynth2-ljpeg   |   40 +-
> >  tests/ref/seek/vsynth2-mjpeg   |   40 +-
> >  tests/ref/seek/vsynth2-mpeg1   |   40 +-
> >  tests/ref/seek/vsynth2-mpeg1b  |   40 +-
> >  tests/ref/seek/vsynth2-mpeg2-422   |   40 +-
> >  tests/ref/seek/vsynth2-mpeg2-idct-int  |   40 +-
> >  tests/ref/seek/vsynth2-mpeg2-ilace |   40 +-
> >  tests/ref/seek/vsynth2-mpeg2-ivlc-qprd |   40 +-
> >  tests/ref/seek/vsynth2-mpeg2-thread|   40 +-
> >  tests/ref/seek/vsynth2-mpeg2-thread-ivlc   |   40 +-
> >  tests/ref/seek/vsynth2-mpeg4   |   48 ++--
> >  tests/ref/seek/vsynth2-mpeg4-adap  |   40 +-
> >  tests/ref/seek/vsynth2-mpeg4-adv   |   40 +-
> >  tests/ref/seek/vsynth2-mpeg4-error |   40 +-
> >  tests/ref/seek/vsynth2-mpeg4-nr|   40 +-
> >  tests/ref/seek/vsynth2-mpeg4-nsse  |   40 +-
> >  tests/ref/seek/vsynth2-mpeg4-qpel  |   40 +-
> >  tests/ref/seek/vsynth2-mpeg4-qprd  |   40 +-
> >  tests/ref/seek/vsynth2-mpeg4-rc|   40 +-
> >  tests/ref/seek/vsynth2-mpeg4-thread|   40 +-
> >  tests/ref/seek/vsynth2-msmpeg4 |   40 +-
> >  tests/ref/seek/vsynth2-msmpeg4v2   |   40 +-
> >  tests/ref/seek/vsynth2-roqvideo|2 +-
> >  tests/ref/seek/vsynth2-rv10|   55 +++---
> >  tests/ref/seek/vsynth2-rv20|   54 +++---
> >  tests/ref/seek/vsynth2-snow|   40 +-
> >  tests/ref/seek/vsynth2-snow-ll |   40 +-
> >  tests/ref/seek/vsynth2-svq1|   48 ++--
> >  tests/ref/seek/vsynth2-wmv1|   40 +-
> >  tests/ref/seek/vsynth2-wmv2|   40 +-
> >  tests/ref/vsynth/vsynth2-amv   |8 +-
> >  tests/ref/vsynth/vsynth2-asv1  |8 +-
> >  tests/ref/vsynth/vsynth2-asv2  |8 +-
> >  tests/ref/vsynth/vsynth2-avui  |4 +-
> >  tests/ref/vsynth/vsynth2-cljr  |6 +-
> >  tests/ref/vsynth/vsynth2-dnxhd-1080i   |6 +-
> >  tests/ref/vsynth/vsynth2-dnxhd-720p|6 +-
> >  tests/ref/vsynth/vsynth2-dnxhd-720p-10bit  |6 +-
> >  tests/ref/vsynth/vsynth2-dnxhd-720p-rd |6 +-
> >  tests/ref/vsynth/vsynth2-dv|6 +-
> >  tests/ref/vsynth/vsynth2-dv-411|6 +-
> >  tests/ref/vsynth/vsynth2-dv-50 |6 +-
> >  tests/ref/vsynth/vsynth2-ffv1  |6 +-
> >  tests/ref/vsynth/vsynth2-ffv1.0|6 +-
> >  tests/ref/vsynth/vsynth2-ffvhuff   |6 +-
> >  tests/ref/vsynth/vsynth2-ffvhuff420p12 |8 +-
> >  tests/ref/vsynth/vsynth2-ffvhuff422p10left |8 +-
> >  tests/ref/vsynth/vsynth2-ffvhuff444|8 +-
> >  tests/ref/vsynth/vsynth2-ffvhuff444p16 |8 +-
> >  tests/ref/vsynth/vsynth2-flashsv   |8 +-
> >  tests/ref/vsynth/vsynth2-flashsv2  |8 +-
> >  tests/ref/vsynth/vsynth2-flv   |8 +-
> >  tests/ref/vsynth/vsynth2-h261  |8 +-
> >  tests/ref/vsynth/vsynth2-h261-trellis  |8 +-
> >  tests/ref/vsynth/vsynth2-h263  |8 +-
> >  tests/ref/vsynth/vsynth2-h263-obmc |8 +-
> >  tests/ref/vsynth/vsynth2-h263p |8 +-
> >  tests/ref/vsynth/vsynth2-huffyuv   |6 +-
> >  tests/ref/vsynth/vsynth2-huffyuvbgr24  |8 +-
> >  tests/ref/vsynth/vsynth2-huffyuvbgra   |8 +-
> >  tests/ref/vsynth/v

Re: [FFmpeg-devel] [PATCH] tests: switch to a test image that is under public domain

[Michael Niedermayer]

On Tue, Aug 26, 2014 at 12:32:32PM +0200, Andreas Cadhalpun wrote:
> On 26.08.2014 01:42, Michael Niedermayer wrote:
> >From: Andreas Cadhalpun 
> >
> >---
> >  LICENSE.md |1 +
> >  tests/Makefile |2 +-
> >  tests/flower.pnm   |  Bin 0 -> 196623 bytes
> >  tests/lena.pnm |  109 
> > 
> [...]
> >  128 files changed, 1161 insertions(+), 1268 deletions(-)
> >  create mode 100644 tests/flower.pnm
> >  delete mode 100644 tests/lena.pnm
> >
> >diff --git a/LICENSE.md b/LICENSE.md
> >index e78d932..ccd494f 100644
> >--- a/LICENSE.md
> >+++ b/LICENSE.md
> >@@ -64,6 +64,7 @@ There are a handful of files under other licensing terms, 
> >namely:
> >You must also indicate any changes including additions and deletions to
> >those three files in the documentation.
> >
> >+tests/flower.pnm is under public domain
> 
> It is disputed whether or not the laws in Germany/Austria allow
> placing work in the public domain [1].
> To avoid any doubt, it would be better to change this to something like:
> 
> tests/flower.pnm copyrighted by Michael Niedermayer is placed in the
> public domain by licensing it under CCO, see:
> https://creativecommons.org/publicdomain/zero/1.0/legalcode

yes, you can use flower.pnm under CC0 too



[..]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I have often repented speaking, but never of holding my tongue.
-- Xenocrates


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: switch to a test image that is under public domain

[Clément Bœsch]

On Tue, Aug 26, 2014 at 01:52:19PM +0200, Michael Niedermayer wrote:
[...]
> > I'm fine with the patch, even though Lena has a special meaning in video
> > processing...
> 
> yep, i wonder if this is the best solution after sleepng over it.
> the lena image is well known, also people know how girls look,
> people will recognize artiacts easily in it.
> Noone would easily notice if a flower has a different color tone or
> some spots. So it may be better to actually try to keep using lena
> 

Yes. Also, the picture is really under fair use in FFmpeg…

See also https://en.wikipedia.org/wiki/File:Lenna.png#Fair_use_for_Playboy

> In that light ive posted a naive patch that just downloads lena.pnm
> if its missing, a 3rd alternative to that would be to move it to the
> fate suite as andreas initially suggested.

It's really insane to wget this in a code that worked without access to
the net. The wget is unexpected here. Also, this is probably not going to
help for the package since the goal is to run the tests depending on the
picture.

[...]

-- 
Clément B.


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

Re: [FFmpeg-devel] [PATCH] tests: switch to a test image that is under public domain

[Andreas Cadhalpun]

On 26.08.2014 14:11, Clément Bœsch wrote:

On Tue, Aug 26, 2014 at 01:52:19PM +0200, Michael Niedermayer wrote:
[...]

I'm fine with the patch, even though Lena has a special meaning in video
processing...


yep, i wonder if this is the best solution after sleepng over it.
the lena image is well known, also people know how girls look,
people will recognize artiacts easily in it.
Noone would easily notice if a flower has a different color tone or
some spots. So it may be better to actually try to keep using lena



Yes. Also, the picture is really under fair use in FFmpeg…

See also https://en.wikipedia.org/wiki/File:Lenna.png#Fair_use_for_Playboy


Yes, it falls under fair use for FFmpeg. But Debian only accepts files 
with a DFSG-free license [1], which lena.pnm lacks.



In that light ive posted a naive patch that just downloads lena.pnm
if its missing, a 3rd alternative to that would be to move it to the
fate suite as andreas initially suggested.


It's really insane to wget this in a code that worked without access to
the net. The wget is unexpected here. Also, this is probably not going to
help for the package since the goal is to run the tests depending on the
picture.


Downloading lena.pnm won't work for example on Debian's build daemons, 
which don't allow access to the internet during package build.
Moving this file to the external fate samples would be fine, because 
these test are not run, when building the Debian package, anyway.


Best regards,
Andreas


1: https://www.debian.org/social_contract#guidelines

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

Re: [FFmpeg-devel] [PATCH] tests: switch to a test image that is under public domain

[Michael Niedermayer]

On Tue, Aug 26, 2014 at 02:22:08PM +0200, Andreas Cadhalpun wrote:
> On 26.08.2014 14:11, Clément Bœsch wrote:
> >On Tue, Aug 26, 2014 at 01:52:19PM +0200, Michael Niedermayer wrote:
> >[...]
> >>>I'm fine with the patch, even though Lena has a special meaning in video
> >>>processing...
> >>
> >>yep, i wonder if this is the best solution after sleepng over it.
> >>the lena image is well known, also people know how girls look,
> >>people will recognize artiacts easily in it.
> >>Noone would easily notice if a flower has a different color tone or
> >>some spots. So it may be better to actually try to keep using lena
> >>
> >
> >Yes. Also, the picture is really under fair use in FFmpeg…
> >
> >See also https://en.wikipedia.org/wiki/File:Lenna.png#Fair_use_for_Playboy
> 
> Yes, it falls under fair use for FFmpeg. But Debian only accepts
> files with a DFSG-free license [1], which lena.pnm lacks.
> 

> >>In that light ive posted a naive patch that just downloads lena.pnm
> >>if its missing, a 3rd alternative to that would be to move it to the
> >>fate suite as andreas initially suggested.
> >
> >It's really insane to wget this in a code that worked without access to
> >the net. The wget is unexpected here. Also, this is probably not going to
> >help for the package since the goal is to run the tests depending on the
> >picture.
> 
> Downloading lena.pnm won't work for example on Debian's build
> daemons, which don't allow access to the internet during package
> build.

the build daemons run make fate ?
because the download should only happen when the file is needed
and its only needed for the tests


> Moving this file to the external fate samples would be fine, because
> these test are not run, when building the Debian package, anyway.
> 
> Best regards,
> Andreas
> 
> 
> 1: https://www.debian.org/social_contract#guidelines
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Avoid a single point of failure, be that a person or equipment.


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: switch to a test image that is under public domain

[Michael Niedermayer]

On Tue, Aug 26, 2014 at 02:27:45PM +0200, Michael Niedermayer wrote:
> On Tue, Aug 26, 2014 at 02:22:08PM +0200, Andreas Cadhalpun wrote:
> > On 26.08.2014 14:11, Clément Bœsch wrote:
> > >On Tue, Aug 26, 2014 at 01:52:19PM +0200, Michael Niedermayer wrote:
> > >[...]
> > >>>I'm fine with the patch, even though Lena has a special meaning in video
> > >>>processing...
> > >>
> > >>yep, i wonder if this is the best solution after sleepng over it.
> > >>the lena image is well known, also people know how girls look,
> > >>people will recognize artiacts easily in it.
> > >>Noone would easily notice if a flower has a different color tone or
> > >>some spots. So it may be better to actually try to keep using lena
> > >>
> > >
> > >Yes. Also, the picture is really under fair use in FFmpeg…
> > >
> > >See also https://en.wikipedia.org/wiki/File:Lenna.png#Fair_use_for_Playboy
> > 
> > Yes, it falls under fair use for FFmpeg. But Debian only accepts
> > files with a DFSG-free license [1], which lena.pnm lacks.
> > 
> 
> > >>In that light ive posted a naive patch that just downloads lena.pnm
> > >>if its missing, a 3rd alternative to that would be to move it to the
> > >>fate suite as andreas initially suggested.
> > >
> > >It's really insane to wget this in a code that worked without access to
> > >the net. The wget is unexpected here. Also, this is probably not going to
> > >help for the package since the goal is to run the tests depending on the
> > >picture.
> > 
> > Downloading lena.pnm won't work for example on Debian's build
> > daemons, which don't allow access to the internet during package
> > build.
> 
> the build daemons run make fate ?
> because the download should only happen when the file is needed
> and its only needed for the tests
> 
> 
> > Moving this file to the external fate samples would be fine, because
> > these test are not run, when building the Debian package, anyway.

also if the build daemons do run the tests, they wont have it
through the external fate samples then either if they have no net
access

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

DNS cache poisoning attacks, popular search engine, Google internet authority
dont be evil, please


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: switch to a test image that is under public domain

[Clément Bœsch]

On Tue, Aug 26, 2014 at 02:27:45PM +0200, Michael Niedermayer wrote:
> On Tue, Aug 26, 2014 at 02:22:08PM +0200, Andreas Cadhalpun wrote:
> > On 26.08.2014 14:11, Clément Bœsch wrote:
> > >On Tue, Aug 26, 2014 at 01:52:19PM +0200, Michael Niedermayer wrote:
> > >[...]
> > >>>I'm fine with the patch, even though Lena has a special meaning in video
> > >>>processing...
> > >>
> > >>yep, i wonder if this is the best solution after sleepng over it.
> > >>the lena image is well known, also people know how girls look,
> > >>people will recognize artiacts easily in it.
> > >>Noone would easily notice if a flower has a different color tone or
> > >>some spots. So it may be better to actually try to keep using lena
> > >>
> > >
> > >Yes. Also, the picture is really under fair use in FFmpeg…
> > >
> > >See also https://en.wikipedia.org/wiki/File:Lenna.png#Fair_use_for_Playboy
> > 
> > Yes, it falls under fair use for FFmpeg. But Debian only accepts
> > files with a DFSG-free license [1], which lena.pnm lacks.
> > 
> 
> > >>In that light ive posted a naive patch that just downloads lena.pnm
> > >>if its missing, a 3rd alternative to that would be to move it to the
> > >>fate suite as andreas initially suggested.
> > >
> > >It's really insane to wget this in a code that worked without access to
> > >the net. The wget is unexpected here. Also, this is probably not going to
> > >help for the package since the goal is to run the tests depending on the
> > >picture.
> > 
> > Downloading lena.pnm won't work for example on Debian's build
> > daemons, which don't allow access to the internet during package
> > build.
> 
> the build daemons run make fate ?
> because the download should only happen when the file is needed
> and its only needed for the tests
> 

make fate works without samples.

Also, if I'm offline and use git clean, I can't run make anymore even if i
still have the samples in a dedicated directory.

Last, it adds a wget dependency.

[...]

-- 
Clément B.


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

Re: [FFmpeg-devel] [PATCH] tests: switch to a test image that is under public domain

[Nicolas George]

Le nonidi 9 fructidor, an CCXXII, Clément Bœsch a écrit :
> Last, it adds a wget dependency.

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

:)

Also:

aimlin /tmp $ apt-get source libav >& /dev/null 
aimlin /tmp $ ls -l libav-10.4/tests/lena.pnm 
-rw-r--r-- 1 cigaes cigaes 196668 Aug 17 16:31 libav-10.4/tests/lena.pnm

(Of course it does not prove anything beyond the fact that people do not
really care about such tiny licensing details, which is good. Unless someone
actually raised the issue as an objection to FFmpeg in Debian?)

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: switch to a test image that is under public domain

[Michael Niedermayer]

On Tue, Aug 26, 2014 at 02:32:00PM +0200, Clément Bœsch wrote:
> On Tue, Aug 26, 2014 at 02:27:45PM +0200, Michael Niedermayer wrote:
> > On Tue, Aug 26, 2014 at 02:22:08PM +0200, Andreas Cadhalpun wrote:
> > > On 26.08.2014 14:11, Clément Bœsch wrote:
> > > >On Tue, Aug 26, 2014 at 01:52:19PM +0200, Michael Niedermayer wrote:
> > > >[...]
> > > >>>I'm fine with the patch, even though Lena has a special meaning in 
> > > >>>video
> > > >>>processing...
> > > >>
> > > >>yep, i wonder if this is the best solution after sleepng over it.
> > > >>the lena image is well known, also people know how girls look,
> > > >>people will recognize artiacts easily in it.
> > > >>Noone would easily notice if a flower has a different color tone or
> > > >>some spots. So it may be better to actually try to keep using lena
> > > >>
> > > >
> > > >Yes. Also, the picture is really under fair use in FFmpeg…
> > > >
> > > >See also 
> > > >https://en.wikipedia.org/wiki/File:Lenna.png#Fair_use_for_Playboy
> > > 
> > > Yes, it falls under fair use for FFmpeg. But Debian only accepts
> > > files with a DFSG-free license [1], which lena.pnm lacks.
> > > 
> > 
> > > >>In that light ive posted a naive patch that just downloads lena.pnm
> > > >>if its missing, a 3rd alternative to that would be to move it to the
> > > >>fate suite as andreas initially suggested.
> > > >
> > > >It's really insane to wget this in a code that worked without access to
> > > >the net. The wget is unexpected here. Also, this is probably not going to
> > > >help for the package since the goal is to run the tests depending on the
> > > >picture.
> > > 
> > > Downloading lena.pnm won't work for example on Debian's build
> > > daemons, which don't allow access to the internet during package
> > > build.
> > 
> > the build daemons run make fate ?
> > because the download should only happen when the file is needed
> > and its only needed for the tests
> > 
> 
> make fate works without samples.
> 
> Also, if I'm offline and use git clean, I can't run make anymore even if i
> still have the samples in a dedicated directory.
> 
> Last, it adds a wget dependency.

the idea was to add the download rule to the makefile as in the
patch but leave lena.pnm in git.
That way debian could simply drop the file and still have working
make test (when there is net access)

either way, i suggest that until we have a consensus, andreas
should probably pick any of the solutions for debian so theres
no delay on the debian side

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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

Re: [FFmpeg-devel] [PATCH] Adds support for setting aq_mode in libvpx encoder

[Michael Niedermayer]

On Tue, Aug 26, 2014 at 03:39:26AM +0200, Michael Niedermayer wrote:
> On Mon, Aug 25, 2014 at 05:17:39PM -0700, Deb Mukherjee wrote:
> > Sets aq_mode in the [0, 3] range for the libvpx encode wrapper.
> > 0: none
> > 1: variance aq
> > 2: complexity aq
> > 3: cyclic refresh aq
> > ---
> >  doc/encoders.texi  | 5 -
> >  libavcodec/libvpxenc.c | 9 +
> >  2 files changed, 13 insertions(+), 1 deletion(-)
> 
> breaks build:
> libavcodec/libvpxenc.c:127:6: error: ‘VP9E_SET_AQ_MODE’ undeclared here (not 
> in a function)
> libavcodec/libvpxenc.c:127:5: error: array index in initializer not of 
> integer type
> libavcodec/libvpxenc.c:127:5: error: (near initialization for ‘ctlidstr’)
> make: *** [libavcodec/libvpxenc.o] Error 1

james configure patch fixed this

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Avoid a single point of failure, be that a person or equipment.


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: switch to a test image that is under public domain

[Andreas Cadhalpun]

On 26.08.2014 14:39, Michael Niedermayer wrote:

On Tue, Aug 26, 2014 at 02:32:00PM +0200, Clément Bœsch wrote:

On Tue, Aug 26, 2014 at 02:27:45PM +0200, Michael Niedermayer wrote:

On Tue, Aug 26, 2014 at 02:22:08PM +0200, Andreas Cadhalpun wrote:

On 26.08.2014 14:11, Clément Bœsch wrote:

On Tue, Aug 26, 2014 at 01:52:19PM +0200, Michael Niedermayer wrote:
[...]

I'm fine with the patch, even though Lena has a special meaning in video
processing...


yep, i wonder if this is the best solution after sleepng over it.
the lena image is well known, also people know how girls look,
people will recognize artiacts easily in it.
Noone would easily notice if a flower has a different color tone or
some spots. So it may be better to actually try to keep using lena



Yes. Also, the picture is really under fair use in FFmpeg…

See also https://en.wikipedia.org/wiki/File:Lenna.png#Fair_use_for_Playboy


Yes, it falls under fair use for FFmpeg. But Debian only accepts
files with a DFSG-free license [1], which lena.pnm lacks.




In that light ive posted a naive patch that just downloads lena.pnm
if its missing, a 3rd alternative to that would be to move it to the
fate suite as andreas initially suggested.


It's really insane to wget this in a code that worked without access to
the net. The wget is unexpected here. Also, this is probably not going to
help for the package since the goal is to run the tests depending on the
picture.


Downloading lena.pnm won't work for example on Debian's build
daemons, which don't allow access to the internet during package
build.


the build daemons run make fate ?
because the download should only happen when the file is needed
and its only needed for the tests



make fate works without samples.

Also, if I'm offline and use git clean, I can't run make anymore even if i
still have the samples in a dedicated directory.

Last, it adds a wget dependency.


the idea was to add the download rule to the makefile as in the
patch but leave lena.pnm in git.
That way debian could simply drop the file and still have working
make test (when there is net access)


That would be bad, because it would work, when I test it (with internet 
access), but then fail on the build daemons.
Also it's better not having to repack, because then anyone can verify 
that the Debian tarball matches the signatures for the original one.



either way, i suggest that until we have a consensus, andreas
should probably pick any of the solutions for debian so theres
no delay on the debian side


I would prefer having a solution applied in ffmpeg.git first.

If the lena.pnm image is considered better for testing, then it should 
be added to the fate samples for download, which are anyway used by most 
developers. As long as it is not in the distributed tarball it is no 
problem.


If having an example image in the tarball is important, the flower.pnm 
(or any other free image) can be added, even if no test needs it.


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

Re: [FFmpeg-devel] [PATCH] lavf/matroskadec: Ensure cues_end is initialized

[ooe]

  

 


  
   
  
Original Message  

  
   
  


  
  From: Reimar 
DöffingerSent: Tuesday, 26 August 2014 
08:31To: FFmpeg development discussions and 
patchesReply To: FFmpeg development discussions 
and patchesSubject: Re: [FFmpeg-devel] [PATCH] 
lavf/matroskadec: Ensure cues_end is 
initializedOn 25.08.2014, at 18:15, Vignesh 
Venkatasubramanian  wrote:> 
avio_seek(matroska->ctx->pb, before_pos, SEEK_SET);> +if 
(cues_start == -1 || cues_end == -1) return -1;Shouldn't this 
use something more descriptive than 
-1?___ffmpeg-devel 
mailing 
listffmpeg-devel@ffmpeg.orghttp://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] tests: switch to a test image that is under public domain

[Andreas Cadhalpun]

On 26.08.2014 14:40, Nicolas George wrote:

Also:

aimlin /tmp $ apt-get source libav >& /dev/null
aimlin /tmp $ ls -l libav-10.4/tests/lena.pnm
-rw-r--r-- 1 cigaes cigaes 196668 Aug 17 16:31 libav-10.4/tests/lena.pnm

(Of course it does not prove anything beyond the fact that people do not
really care about such tiny licensing details, which is good. Unless someone
actually raised the issue as an objection to FFmpeg in Debian?)


People actually do care:
https://bugs.debian.org/758442

I would have filed a similar bug against Debian's Libav package, but I 
didn't want to give an excuse for a flamewar.


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

Re: [FFmpeg-devel] [PATCH] tests: switch to a test image that is under public domain

[Derek Buitenhuis]

On 8/26/2014 12:42 AM, Michael Niedermayer wrote:

[...]

>  tests/lena.pnm |  109 
> 

I'm sorry but this is beyond stupid.

We can't use the defacto DSP testing image because it is not *FREE* enough
for Debian? It is utterly asinine to remove it because Debian doesn't want
to distribute Lena with source deb. They can remove it themselves.

As for the Debian build daemon, it has no internet access anyway, and a
asynth and vsynth only run is of dubious value.

Muh freedums, I tell ya whut.

P.S. Maybe someone should inform the Debian guys of all the hundred(s) of
patents that FFmpeg implements as well. ;)

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

Re: [FFmpeg-devel] [PATCH] tests: switch to a test image that is under public domain

[Andreas Cadhalpun]

On 26.08.2014 16:15, Derek Buitenhuis wrote:

On 8/26/2014 12:42 AM, Michael Niedermayer wrote:

[...]


  tests/lena.pnm |  109 


I'm sorry but this is beyond stupid.


I don't think so.


We can't use the defacto DSP testing image because it is not *FREE* enough
for Debian? It is utterly asinine to remove it because Debian doesn't want
to distribute Lena with source deb. They can remove it themselves.


You could still use it, just like all the other samples which need to be 
downloaded with 'make fate-rsync'.
Why do you think it necessary to ship this sample in the FFmpeg source 
tarball, while all others aren't there, already.



As for the Debian build daemon, it has no internet access anyway, and a
asynth and vsynth only run is of dubious value.


It is quite useful, e.g. it detected that gcc-4.9 broke FFmpeg's flac 
support [1].



Muh freedums, I tell ya whut.

P.S. Maybe someone should inform the Debian guys of all the hundred(s) of
patents that FFmpeg implements as well. ;)


Patents are a different issue and no DFSG criterion.

Best regards,
Andreas

1: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60902

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

Re: [FFmpeg-devel] [PATCH] tests: switch to a test image that is under public domain

[Derek Buitenhuis]

On 8/26/2014 3:47 PM, Andreas Cadhalpun wrote:
>> We can't use the defacto DSP testing image because it is not *FREE* enough
>> for Debian? It is utterly asinine to remove it because Debian doesn't want
>> to distribute Lena with source deb. They can remove it themselves.
> 
> You could still use it, just like all the other samples which need to be 
> downloaded with 'make fate-rsync'.
> Why do you think it necessary to ship this sample in the FFmpeg source 
> tarball, while all others aren't there, already.
> 
>> As for the Debian build daemon, it has no internet access anyway, and a
>> asynth and vsynth only run is of dubious value.
> 
> It is quite useful, e.g. it detected that gcc-4.9 broke FFmpeg's flac 
> support [1].

These two conflict. Either we distribute it with the tarball, or Debian's
build daemon doesn't run the tests.

Freetards gonna freetard I guess...

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

Re: [FFmpeg-devel] [PATCH] tests: switch to a test image that is under public domain

[Andreas Cadhalpun]

On 26.08.2014 16:50, Derek Buitenhuis wrote:

On 8/26/2014 3:47 PM, Andreas Cadhalpun wrote:

We can't use the defacto DSP testing image because it is not *FREE* enough
for Debian? It is utterly asinine to remove it because Debian doesn't want
to distribute Lena with source deb. They can remove it themselves.


You could still use it, just like all the other samples which need to be
downloaded with 'make fate-rsync'.
Why do you think it necessary to ship this sample in the FFmpeg source
tarball, while all others aren't there, already.


As for the Debian build daemon, it has no internet access anyway, and a
asynth and vsynth only run is of dubious value.


It is quite useful, e.g. it detected that gcc-4.9 broke FFmpeg's flac
support [1].


These two conflict. Either we distribute it with the tarball, or Debian's
build daemon doesn't run the tests.


All the other tests that don't need lena.pnm still can be run, e.g. the 
acodec-flac test, which is quite useful.


Best regards,
Andreas
___
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

[Vignesh Venkatasubramanian]

On Mon, Aug 25, 2014 at 4:35 PM, Lou Logan  wrote:
> On Mon, 25 Aug 2014 16:26:16 -0700, Vignesh Venkatasubramanian wrote:
>
>> i sent the files associated with this fate test as a tarball to this
>> mailing list and got a reply saying "message is awaiting moderator
>> approval because the attachment is > 500kb". could you please check?
>
> The samples were submitted to the mailing list, but I rejected the
> message with a note to provide links to the files instead of attaching
> them due to the file sizes. Please check to see if the message was
> marked as spam.
>

sorry. i did not get that email. it's not in my spam folder either.
anyway, here is a link to the tarball:
https://drive.google.com/file/d/0Bx8Q1nhO9b6MdjducEZyUks5VHc/edit?usp=sharing

could you please unpack the files into vp8/ directory in fate samples
suite? thanks.

> Although this is a high volume list (in my opinion), I thought 5 MB was
> too big for a single email message; especially with our number of
> subscribers I did not believe it would be appreciated by many readers.
>
> Current size limit per message is 550 kb. This of course can be
> changed if desired and can be discussed in another message or in
> #ffmpeg-devel.
>
> Lou
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel



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

Re: [FFmpeg-devel] [PATCH] tests: switch to a test image that is under public domain

[James Almer]

On 26/08/14 9:39 AM, Michael Niedermayer wrote:
> either way, i suggest that until we have a consensus, andreas
> should probably pick any of the solutions for debian so theres
> no delay on the debian side

How is this a problem for Debian? lena.pnm is also available on Libav's 
git tree and it doesn't seem to be an issue for them.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] tests: switch to a test image that is under public domain

[Andreas Cadhalpun]

Hi,

On 26.08.2014 18:26, James Almer wrote:

On 26/08/14 9:39 AM, Michael Niedermayer wrote:

either way, i suggest that until we have a consensus, andreas
should probably pick any of the solutions for debian so theres
no delay on the debian side


How is this a problem for Debian? lena.pnm is also available on Libav's
git tree and it doesn't seem to be an issue for them.


It seems nobody noticed this so far. It is hard to detect, because 
nowhere in the source is mentioned that tests/lena.pnm is not licensed 
under LPGL-2.1+, so one assumes it is. I only noticed this, after seeing 
a similar bug filed for a different package [1].


Of course, this should also be fixed in the Debian Libav package.

Best regards,
Andreas

1: https://bugs.debian.org/758442


___
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 Tue, Aug 26, 2014 at 08:26:10AM -0700, Vignesh Venkatasubramanian wrote:
> On Mon, Aug 25, 2014 at 4:35 PM, Lou Logan  wrote:
> > On Mon, 25 Aug 2014 16:26:16 -0700, Vignesh Venkatasubramanian wrote:
> >
> >> i sent the files associated with this fate test as a tarball to this
> >> mailing list and got a reply saying "message is awaiting moderator
> >> approval because the attachment is > 500kb". could you please check?
> >
> > The samples were submitted to the mailing list, but I rejected the
> > message with a note to provide links to the files instead of attaching
> > them due to the file sizes. Please check to see if the message was
> > marked as spam.
> >
> 
> sorry. i did not get that email. it's not in my spam folder either.
> anyway, here is a link to the tarball:
> https://drive.google.com/file/d/0Bx8Q1nhO9b6MdjducEZyUks5VHc/edit?usp=sharing
> 
> could you please unpack the files into vp8/ directory in fate samples
> suite? thanks.

done

[...]
-- 
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] tests: switch to a test image that is under public domain

[Michael Niedermayer]

On Tue, Aug 26, 2014 at 01:42:17AM +0200, Michael Niedermayer wrote:
> From: Andreas Cadhalpun 

in absence of any better ideas or pictures i intend to apply this soon

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

Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User
questions about the command line tools should be sent to the ffmpeg-user ML.
And questions about how to use libav* should be sent to the libav-user ML.


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

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

[Deb Mukherjee]

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 | 20 +++-
 1 file changed, 15 insertions(+), 5 deletions(-)

diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
index 830a793..3a36855 100644
--- a/libavcodec/libvpxenc.c
+++ b/libavcodec/libvpxenc.c
@@ -300,10 +300,15 @@ static av_cold int vpx_init(AVCodecContext *avctx,
 enccfg.g_pass = VPX_RC_ONE_PASS;
 
 if (avctx->rc_min_rate == avctx->rc_max_rate &&
-avctx->rc_min_rate == avctx->bit_rate && avctx->bit_rate)
+avctx->rc_min_rate == avctx->bit_rate && avctx->bit_rate) {
 enccfg.rc_end_usage = VPX_CBR;
-else if (ctx->crf)
+} else if (ctx->crf >= 0) {
 enccfg.rc_end_usage = VPX_CQ;
+#if CONFIG_LIBVPX_VP9_ENCODER
+if (!avctx->bit_rate && avctx->codec_id == AV_CODEC_ID_VP9)
+enccfg.rc_end_usage = VPX_Q;
+#endif
+}
 
 if (avctx->bit_rate) {
 enccfg.rc_target_bitrate = av_rescale_rnd(avctx->bit_rate, 1, 1000,
@@ -311,7 +316,11 @@ static av_cold int vpx_init(AVCodecContext *avctx,
 } else {
 if (enccfg.rc_end_usage == VPX_CQ) {
 enccfg.rc_target_bitrate = 100;
+#if CONFIG_LIBVPX_VP9_ENCODER
+} else if (enccfg.rc_end_usage != VPX_Q) {
+#else
 } else {
+#endif
 avctx->bit_rate = enccfg.rc_target_bitrate * 1000;
 av_log(avctx, AV_LOG_WARNING,
"Neither bitrate nor constrained quality specified, using 
default bitrate of %dkbit/sec\n",
@@ -324,7 +333,7 @@ static av_cold int vpx_init(AVCodecContext *avctx,
 if (avctx->qmax >= 0)
 enccfg.rc_max_quantizer = avctx->qmax;
 
-if (enccfg.rc_end_usage == VPX_CQ) {
+if (enccfg.rc_end_usage == VPX_CQ || enccfg.rc_end_usage == VPX_Q) {
 if (ctx->crf < enccfg.rc_min_quantizer || ctx->crf > 
enccfg.rc_max_quantizer) {
 av_log(avctx, AV_LOG_ERROR,
"CQ level must be between minimum and maximum quantizer 
value (%d-%d)\n",
@@ -430,7 +439,8 @@ static av_cold int vpx_init(AVCodecContext *avctx,
 if (avctx->codec_id == AV_CODEC_ID_VP8)
 codecctl_int(avctx, VP8E_SET_TOKEN_PARTITIONS,  
av_log2(avctx->slices));
 codecctl_int(avctx, VP8E_SET_STATIC_THRESHOLD,  avctx->mb_threshold);
-codecctl_int(avctx, VP8E_SET_CQ_LEVEL,  ctx->crf);
+if (ctx->crf >= 0)
+codecctl_int(avctx, VP8E_SET_CQ_LEVEL,  ctx->crf);
 if (ctx->max_intra_rate >= 0)
 codecctl_int(avctx, VP8E_SET_MAX_INTRA_BITRATE_PCT, 
ctx->max_intra_rate);
 
@@ -775,7 +785,7 @@ static int vp8_encode(AVCodecContext *avctx, AVPacket *pkt,
  "by the bool decoder, meaning that partitions can be 
decoded even " \
  "though earlier partitions have been lost. Note that 
intra predicition" \
  " is still done over the partition boundary.",   
0, AV_OPT_TYPE_CONST, {.i64 = VPX_ERROR_RESILIENT_PARTITIONS}, 0, 0, VE, "er"}, 
\
-{ "crf",  "Select the quality for constant quality mode", 
offsetof(VP8Context, crf), AV_OPT_TYPE_INT, {.i64 = 0}, 0, 63, VE }, \
+{ "crf",  "Select the quality for constant quality mode", 
offsetof(VP8Context, crf), AV_OPT_TYPE_INT, {.i64 = -1}, -1, 63, VE }, \
 
 #define LEGACY_OPTIONS \
 {"speed", "", offsetof(VP8Context, cpu_used), AV_OPT_TYPE_INT, {.i64 = 1}, 
-16, 16, VE}, \
-- 
2.1.0.rc2.206.gedb03e5

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

Re: [FFmpeg-devel] [PATCH] tests: switch to a test image that is under public domain

[Michael Niedermayer]

On Tue, Aug 26, 2014 at 07:28:13PM +0200, Michael Niedermayer wrote:
> On Tue, Aug 26, 2014 at 01:42:17AM +0200, Michael Niedermayer wrote:
> > From: Andreas Cadhalpun 
> 
> in absence of any better ideas or pictures i intend to apply this soon

of course if people object to this then we can also leave
lena and document that its used under fair use and may or may not be
public domain & GPL compatible

and no iam not happy about this but thats just how it is if i
understand it correctly and IANAL



[...]

-- 
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] libx264: fix -b_qfactor and -chromaoffset

[Hii]

Hi,

On 2014-08-25 01:24, Michael Niedermayer wrote:
> On Sat, Aug 23, 2014 at 08:59:41PM +0800, Hii wrote:
>> Currently -b_qfactor and -chromaoffset have no effect in libx264,
>> the attached patch is an attempt to fix the issue.
>>
>> Move the corresponding lines after x264_param_default_preset() to
>> prevent them being overwritten by it, make the two parameters
>> functional.
>> Also make b_qfactor changeable by x264's tunings after the move.
>>
>> (feel free to edit the commit message as I am not a native English 
speaker.)

>>
>>
>
>>   libx264.c |6 --
>>   1 file changed, 4 insertions(+), 2 deletions(-)
>> affb26a7840db085fb82ac8e24e5fe5770774113 
0001-libx264-fix-b_qfactor-and-chromaoffset.patch

>>  From d8597d3f708c21deae40b21754173763c5a13658 Mon Sep 17 00:00:00 2001
>> From: Hii 
>> Date: Sat, 23 Aug 2014 17:08:02 +0800
>> Subject: [PATCH] libx264: fix -b_qfactor and -chromaoffset
>>
>> ---
>>   libavcodec/libx264.c | 6 --
>>   1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
>> index 7793581..8aff14d 100644
>> --- a/libavcodec/libx264.c
>> +++ b/libavcodec/libx264.c
>> @@ -371,8 +371,6 @@ static av_cold int X264_init(AVCodecContext *avctx)
>>
>>   x4->params.b_deblocking_filter = avctx->flags & 
CODEC_FLAG_LOOP_FILTER;

>>
>> -x4->params.rc.f_pb_factor = avctx->b_quant_factor;
>> -x4->params.analyse.i_chroma_qp_offset = avctx->chromaoffset;
>>   if (x4->preset || x4->tune)
>>   if (x264_param_default_preset(&x4->params, x4->preset, 
x4->tune) < 0) {

>>   int i;
>> @@ -430,6 +428,9 @@ static av_cold int X264_init(AVCodecContext *avctx)
>>
>>   if (avctx->i_quant_factor > 0)
>>   x4->params.rc.f_ip_factor = 1 / 
fabs(avctx->i_quant_factor);

>> +if (avctx->b_quant_factor > 0)
>> +x4->params.rc.f_pb_factor = avctx->b_quant_factor;
>
>> +x4->params.analyse.i_chroma_qp_offset = avctx->chromaoffset;
>
> i think this would unconditionally override i_chroma_qp_offset
> from x264_param_default_preset()
>
> all others are only overridde when explicitly set by the user

Here's another try.
From 402a0d7752891f1682c30deab2d7052ce35b7303 Mon Sep 17 00:00:00 2001
From: Hii 
Date: Tue, 26 Aug 2014 14:55:14 +0800
Subject: [PATCH] libx264: fix -b_qfactor and -chromaoffset

---
 libavcodec/libx264.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
index 7793581..8830f59 100644
--- a/libavcodec/libx264.c
+++ b/libavcodec/libx264.c
@@ -371,8 +371,6 @@ static av_cold int X264_init(AVCodecContext *avctx)
 
 x4->params.b_deblocking_filter = avctx->flags & 
CODEC_FLAG_LOOP_FILTER;
 
-x4->params.rc.f_pb_factor = avctx->b_quant_factor;
-x4->params.analyse.i_chroma_qp_offset = avctx->chromaoffset;
 if (x4->preset || x4->tune)
 if (x264_param_default_preset(&x4->params, x4->preset, x4->tune) < 0) {
 int i;
@@ -430,6 +428,10 @@ static av_cold int X264_init(AVCodecContext *avctx)
 
 if (avctx->i_quant_factor > 0)
 x4->params.rc.f_ip_factor = 1 / fabs(avctx->i_quant_factor);
+if (avctx->b_quant_factor > 0)
+x4->params.rc.f_pb_factor = avctx->b_quant_factor;
+if (avctx->chromaoffset)
+x4->params.analyse.i_chroma_qp_offset = avctx->chromaoffset;
 
 if (avctx->me_method == ME_EPZS)
 x4->params.analyse.i_me_method = X264_ME_DIA;
@@ -827,6 +829,7 @@ static const AVCodecDefault x264_defaults[] = {
 { "flags2",   "0" },
 { "g","-1" },
 { "i_qfactor","-1" },
+{ "b_qfactor","-1" },
 { "qmin", "-1" },
 { "qmax", "-1" },
 { "qdiff","-1" },
-- 
1.9.0.msysgit.0

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

[FFmpeg-devel] [PATCH] avformat/rtpdec_h261: sanity checks

[Thomas Volkert]

From: ThomasVolkert 

---
 libavformat/rtpdec_h261.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavformat/rtpdec_h261.c b/libavformat/rtpdec_h261.c
index c1d79a8..b902d2a 100644
--- a/libavformat/rtpdec_h261.c
+++ b/libavformat/rtpdec_h261.c
@@ -117,8 +117,8 @@ int ff_h261_handle_packet(AVFormatContext *ctx, 
PayloadContext *data,
 sbit  =  (buf[0] >> 5) & 0x07;
 ebit  =  (buf[0] >> 2) & 0x07;
 gobn  =  (buf[1] >> 4) & 0x0f;
-mbap  = ((buf[1] << 1) & 0x1e) | ((buf[1] >> 7) & 0x01);
-quant =  (buf[1] >> 4) & 0x0f;
+mbap  = ((buf[1] << 1) & 0x1e) | ((buf[2] >> 7) & 0x01);
+quant =  (buf[2] >> 2) & 0x1f;
 
 /* pass the H.261 payload header and continue with the actual payload */
 buf += RTP_H261_PAYLOAD_HEADER_SIZE;
-- 
1.9.1

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

Re: [FFmpeg-devel] [PATCH] tests: switch to a test image that is under public domain

[Andreas Cadhalpun]

On 26.08.2014 19:45, Michael Niedermayer wrote:

On Tue, Aug 26, 2014 at 07:28:13PM +0200, Michael Niedermayer wrote:

On Tue, Aug 26, 2014 at 01:42:17AM +0200, Michael Niedermayer wrote:

From: Andreas Cadhalpun 


in absence of any better ideas or pictures i intend to apply this soon


of course if people object to this then we can also leave
lena and document that its used under fair use and may or may not be
public domain & GPL compatible


Why do you think it might be public domain or GPL compatible?
It's quite clear that it is copyrighted and since it is from 1972, the 
copyright didn't expire yet.


Best regards,
Andreas

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

Re: [FFmpeg-devel] [PATCH] libx264: fix -b_qfactor and -chromaoffset

[Michael Niedermayer]

On Tue, Aug 26, 2014 at 02:58:32PM +0800, Hii wrote:
> Hi,
> 
> On 2014-08-25 01:24, Michael Niedermayer wrote:
> > On Sat, Aug 23, 2014 at 08:59:41PM +0800, Hii wrote:
> >> Currently -b_qfactor and -chromaoffset have no effect in libx264,
> >> the attached patch is an attempt to fix the issue.
> >>
> >> Move the corresponding lines after x264_param_default_preset() to
> >> prevent them being overwritten by it, make the two parameters
> >> functional.
> >> Also make b_qfactor changeable by x264's tunings after the move.
> >>
> >> (feel free to edit the commit message as I am not a native
> English speaker.)
> >>
> >>
> >
> >>   libx264.c |6 --
> >>   1 file changed, 4 insertions(+), 2 deletions(-)
> >> affb26a7840db085fb82ac8e24e5fe5770774113
> 0001-libx264-fix-b_qfactor-and-chromaoffset.patch
> >>  From d8597d3f708c21deae40b21754173763c5a13658 Mon Sep 17 00:00:00 2001
> >> From: Hii 
> >> Date: Sat, 23 Aug 2014 17:08:02 +0800
> >> Subject: [PATCH] libx264: fix -b_qfactor and -chromaoffset
> >>
> >> ---
> >>   libavcodec/libx264.c | 6 --
> >>   1 file changed, 4 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
> >> index 7793581..8aff14d 100644
> >> --- a/libavcodec/libx264.c
> >> +++ b/libavcodec/libx264.c
> >> @@ -371,8 +371,6 @@ static av_cold int X264_init(AVCodecContext *avctx)
> >>
> >>   x4->params.b_deblocking_filter = avctx->flags &
> CODEC_FLAG_LOOP_FILTER;
> >>
> >> -x4->params.rc.f_pb_factor = avctx->b_quant_factor;
> >> -x4->params.analyse.i_chroma_qp_offset = avctx->chromaoffset;
> >>   if (x4->preset || x4->tune)
> >>   if (x264_param_default_preset(&x4->params, x4->preset,
> x4->tune) < 0) {
> >>   int i;
> >> @@ -430,6 +428,9 @@ static av_cold int X264_init(AVCodecContext *avctx)
> >>
> >>   if (avctx->i_quant_factor > 0)
> >>   x4->params.rc.f_ip_factor = 1 /
> fabs(avctx->i_quant_factor);
> >> +if (avctx->b_quant_factor > 0)
> >> +x4->params.rc.f_pb_factor = avctx->b_quant_factor;
> >
> >> +x4->params.analyse.i_chroma_qp_offset = avctx->chromaoffset;
> >
> > i think this would unconditionally override i_chroma_qp_offset
> > from x264_param_default_preset()
> >
> > all others are only overridde when explicitly set by the user
> 
> Here's another try.

>  libx264.c |7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 20824b7c002625f609c6d6a76de27e0910e2a70e  
> 0001-libx264-fix-b_qfactor-and-chromaoffset.patch
> From 402a0d7752891f1682c30deab2d7052ce35b7303 Mon Sep 17 00:00:00 2001
> From: Hii 
> Date: Tue, 26 Aug 2014 14:55:14 +0800
> Subject: [PATCH] libx264: fix -b_qfactor and -chromaoffset

applied
thanks

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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

Re: [FFmpeg-devel] [PATCH] tests: switch to a test image that is under public domain

[Michael Niedermayer]

On Tue, Aug 26, 2014 at 08:12:58PM +0200, Andreas Cadhalpun wrote:
> On 26.08.2014 19:45, Michael Niedermayer wrote:
> >On Tue, Aug 26, 2014 at 07:28:13PM +0200, Michael Niedermayer wrote:
> >>On Tue, Aug 26, 2014 at 01:42:17AM +0200, Michael Niedermayer wrote:
> >>>From: Andreas Cadhalpun 
> >>
> >>in absence of any better ideas or pictures i intend to apply this soon
> >
> >of course if people object to this then we can also leave
> >lena and document that its used under fair use and may or may not be
> >public domain & GPL compatible
> 
> Why do you think it might be public domain or GPL compatible?
> It's quite clear that it is copyrighted and since it is from 1972,
> the copyright didn't expire yet.

IANAL

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I have often repented speaking, but never of holding my tongue.
-- Xenocrates


signature.asc
Description: Digital signature
___
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.

[James Zern]

On Tue, Aug 26, 2014 at 10:30 AM, 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 | 20 +++-
>  1 file changed, 15 insertions(+), 5 deletions(-)
>
> diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
> index 830a793..3a36855 100644
> --- a/libavcodec/libvpxenc.c
> +++ b/libavcodec/libvpxenc.c
> @@ -300,10 +300,15 @@ static av_cold int vpx_init(AVCodecContext *avctx,
>  enccfg.g_pass = VPX_RC_ONE_PASS;
>
>  if (avctx->rc_min_rate == avctx->rc_max_rate &&
> -avctx->rc_min_rate == avctx->bit_rate && avctx->bit_rate)
> +avctx->rc_min_rate == avctx->bit_rate && avctx->bit_rate) {
>  enccfg.rc_end_usage = VPX_CBR;
> -else if (ctx->crf)
> +} else if (ctx->crf >= 0) {
>  enccfg.rc_end_usage = VPX_CQ;
> +#if CONFIG_LIBVPX_VP9_ENCODER
> +if (!avctx->bit_rate && avctx->codec_id == AV_CODEC_ID_VP9)
> +enccfg.rc_end_usage = VPX_Q;
> +#endif
> +}
>
>  if (avctx->bit_rate) {
>  enccfg.rc_target_bitrate = av_rescale_rnd(avctx->bit_rate, 1, 1000,
> @@ -311,7 +316,11 @@ static av_cold int vpx_init(AVCodecContext *avctx,
>  } else {
>  if (enccfg.rc_end_usage == VPX_CQ) {
>  enccfg.rc_target_bitrate = 100;
> +#if CONFIG_LIBVPX_VP9_ENCODER
> +} else if (enccfg.rc_end_usage != VPX_Q) {

you could bring this up a level and avoid the '#else'

> +#else
>  } else {
> +#endif
>  avctx->bit_rate = enccfg.rc_target_bitrate * 1000;
>  av_log(avctx, AV_LOG_WARNING,
> "Neither bitrate nor constrained quality specified, using 
> default bitrate of %dkbit/sec\n",
> @@ -324,7 +333,7 @@ static av_cold int vpx_init(AVCodecContext *avctx,
>  if (avctx->qmax >= 0)
>  enccfg.rc_max_quantizer = avctx->qmax;
>
> -if (enccfg.rc_end_usage == VPX_CQ) {
> +if (enccfg.rc_end_usage == VPX_CQ || enccfg.rc_end_usage == VPX_Q) {

This still needs to be if def'd.

>  if (ctx->crf < enccfg.rc_min_quantizer || ctx->crf > 
> enccfg.rc_max_quantizer) {
>  av_log(avctx, AV_LOG_ERROR,
> "CQ level must be between minimum and maximum 
> quantizer value (%d-%d)\n",
> @@ -430,7 +439,8 @@ static av_cold int vpx_init(AVCodecContext *avctx,
>  if (avctx->codec_id == AV_CODEC_ID_VP8)
>  codecctl_int(avctx, VP8E_SET_TOKEN_PARTITIONS,  
> av_log2(avctx->slices));
>  codecctl_int(avctx, VP8E_SET_STATIC_THRESHOLD,  avctx->mb_threshold);
> -codecctl_int(avctx, VP8E_SET_CQ_LEVEL,  ctx->crf);
> +if (ctx->crf >= 0)
> +codecctl_int(avctx, VP8E_SET_CQ_LEVEL,  ctx->crf);
>  if (ctx->max_intra_rate >= 0)
>  codecctl_int(avctx, VP8E_SET_MAX_INTRA_BITRATE_PCT, 
> ctx->max_intra_rate);
>
> @@ -775,7 +785,7 @@ static int vp8_encode(AVCodecContext *avctx, AVPacket 
> *pkt,
>   "by the bool decoder, meaning that partitions can 
> be decoded even " \
>   "though earlier partitions have been lost. Note 
> that intra predicition" \
>   " is still done over the partition boundary.",  
>  0, AV_OPT_TYPE_CONST, {.i64 = VPX_ERROR_RESILIENT_PARTITIONS}, 0, 0, VE, 
> "er"}, \
> -{ "crf",  "Select the quality for constant quality mode", 
> offsetof(VP8Context, crf), AV_OPT_TYPE_INT, {.i64 = 0}, 0, 63, VE }, \
> +{ "crf",  "Select the quality for constant quality mode", 
> offsetof(VP8Context, crf), AV_OPT_TYPE_INT, {.i64 = -1}, -1, 63, VE }, \
>
>  #define LEGACY_OPTIONS \
>  {"speed", "", offsetof(VP8Context, cpu_used), AV_OPT_TYPE_INT, {.i64 = 
> 1}, -16, 16, VE}, \
> --
> 2.1.0.rc2.206.gedb03e5
>
> ___
> 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] avformat/rtpdec_h261: sanity checks

[Michael Niedermayer]

On Tue, Aug 26, 2014 at 02:23:00PM +0200, Thomas Volkert wrote:
> From: ThomasVolkert 
> 
> ---
>  libavformat/rtpdec_h261.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

made commit message a bit more verbose

applied

thanks

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

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


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

Re: [FFmpeg-devel] [PATCH] Adds support for setting aq_mode in libvpx encoder

[James Almer]

On 25/08/14 9:17 PM, Deb Mukherjee wrote:
> Sets aq_mode in the [0, 3] range for the libvpx encode wrapper.
> 0: none
> 1: variance aq
> 2: complexity aq
> 3: cyclic refresh aq
> ---
>  doc/encoders.texi  | 5 -
>  libavcodec/libvpxenc.c | 9 +
>  2 files changed, 13 insertions(+), 1 deletion(-)
> 

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

[FFmpeg-devel] [PATCH] Add a license to the LESS file

[db0company]

---
 LICENSE.txt |   21 +
 src/less/style.less |6 --
 2 files changed, 25 insertions(+), 2 deletions(-)
 create mode 100644 LICENSE.txt

diff --git a/LICENSE.txt b/LICENSE.txt
new file mode 100644
index 000..c5983d2
--- /dev/null
+++ b/LICENSE.txt
@@ -0,0 +1,21 @@
+The MIT License (MIT)
+
+Copyright (c) 2014 Barbara Lepage
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.
diff --git a/src/less/style.less b/src/less/style.less
index 6a26684..5d6d03d 100644
--- a/src/less/style.less
+++ b/src/less/style.less
@@ -1,5 +1,7 @@
-// Author: db0 (db0comp...@gmail.com, http://db0.fr/)
-
+/*!
+ * Copyright 2014. Barbara Lepage (db0comp...@gmail.com, http://db0.fr/)
+ * Licensed under MIT (https://github.com/FFmpeg/web/blob/master/LICENSE.txt)
+ */
 // * //
 // COLORS
 
-- 
1.7.0.4

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

Re: [FFmpeg-devel] [PATCH] Add a license to the LESS file

[Andreas Cadhalpun]

On 26.08.2014 21:38, db0company wrote:

---
  LICENSE.txt |   21 +
  src/less/style.less |6 --
  2 files changed, 25 insertions(+), 2 deletions(-)
  create mode 100644 LICENSE.txt


Thanks.


diff --git a/LICENSE.txt b/LICENSE.txt
new file mode 100644
index 000..c5983d2
--- /dev/null
+++ b/LICENSE.txt
@@ -0,0 +1,21 @@
+The MIT License (MIT)
+
+Copyright (c) 2014 Barbara Lepage
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.
diff --git a/src/less/style.less b/src/less/style.less
index 6a26684..5d6d03d 100644
--- a/src/less/style.less
+++ b/src/less/style.less
@@ -1,5 +1,7 @@
-// Author: db0 (db0comp...@gmail.com, http://db0.fr/)
-
+/*!
+ * Copyright 2014. Barbara Lepage (db0comp...@gmail.com, http://db0.fr/)
+ * Licensed under MIT (https://github.com/FFmpeg/web/blob/master/LICENSE.txt)
+ */
  // * 
//
  // COLORS


A similar notice should be added to src/css_credit to comply with this 
license, when distributing the style.min.css.


Best regards,
Andreas

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

Re: [FFmpeg-devel] [PATCH] libavdevice/v4l2: fix of crash caused by assert

[Michael Niedermayer]

On Wed, Aug 13, 2014 at 07:04:01PM +0400, Dmitry Volyntsev wrote:
> From: Dmitry Volyntsev 
> 
> s->buffers_queued constantly decremented and not incremented
> in case of (s->frame_size > 0 && buf.bytesused != s->frame_size)
> condition (caught on long run capture of Logitech C310)

can you explain why this happens ? where do this misatching
bufs come from ?
why is droping them correct ?


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

Dictatorship naturally arises out of democracy, and the most aggravated
form of tyranny and slavery out of the most extreme liberty. -- Plato


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

Re: [FFmpeg-devel] [PATCH] Add a license to the LESS file

[Timothy Gu]

On Tue, Aug 26, 2014 at 12:38 PM, db0company  wrote:
> ---
>  LICENSE.txt |   21 +
>  src/less/style.less |6 --
>  2 files changed, 25 insertions(+), 2 deletions(-)
>  create mode 100644 LICENSE.txt
>
> diff --git a/LICENSE.txt b/LICENSE.txt
> new file mode 100644
> index 000..c5983d2
> --- /dev/null
> +++ b/LICENSE.txt
> @@ -0,0 +1,21 @@

> +The MIT License (MIT)
> +
> +Copyright (c) 2014 Barbara Lepage
> +
> +Permission is hereby granted, free of charge, to any person obtaining a copy
> +of this software and associated documentation files (the "Software"), to deal
> +in the Software without restriction, including without limitation the rights
> +to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
> +copies of the Software, and to permit persons to whom the Software is
> +furnished to do so, subject to the following conditions:
> +
> +The above copyright notice and this permission notice shall be included in 
> all
> +copies or substantial portions of the Software.
> +
> +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
> +AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> +LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
> +OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
> +SOFTWARE.

You should make it clear that only style.less is covered in this
license, not anything else.

[...]

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

[FFmpeg-devel] [PATCH] bktr: Fix Fabrice's name

[Timothy Gu]

Signed-off-by: Timothy Gu 
---
 libavdevice/bktr.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavdevice/bktr.c b/libavdevice/bktr.c
index d09d452..52d090c 100644
--- a/libavdevice/bktr.c
+++ b/libavdevice/bktr.c
@@ -3,7 +3,7 @@
  * Copyright (c) 2002 Steve O'Hara-Smith
  * based on
  *   Linux video grab interface
- *   Copyright (c) 2000,2001 Gerard Lantau
+ *   Copyright (c) 2000, 2001 Fabrice Bellard
  * and
  *   simple_grab.c Copyright (c) 1999 Roger Hardiman
  *
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Improved AC3 decoder level support (heavy drc, dialnorm)

[Michael Niedermayer]

On Tue, Aug 26, 2014 at 07:16:06PM -0400, Jean-Francois Thibert wrote:
> Added support for AC3 heavy dynamic range compression used
> to restrict the output range and added a setting to specify
> the output target level and use the dialog normalization
> field to apply it in the digital domain.

do you have a testcase/sample to test this ?

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

There will always be a question for which you do not know the correct answer.


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

Re: [FFmpeg-devel] [PATCH] avformat/mxfenc: dont warn about d10_channelcount being ignored if its not set

[Michael Niedermayer]

On Fri, Aug 22, 2014 at 10:58:41PM +0200, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer 
> ---
>  libavformat/mxfenc.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

applied

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

Breaking DRM is a little like attempting to break through a door even
though the window is wide open and the only thing in the house is a bunch
of things you dont want and which you would get tomorrow for free anyway


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

[FFmpeg-devel] [PATCH] lavf/mp3enc: don't abort if audio packets can't be buffered

[James Almer]

Instead skip the picture streams and flush the queued audio packets.
Should address ticket #3851.

Signed-off-by: James Almer 
---
This is more a workaround than a "fix" to the issue, with the intent of 
not aborting the entire muxing process just because a picture couldn't 
be written to the id3v2 tag.

 libavformat/mp3enc.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/libavformat/mp3enc.c b/libavformat/mp3enc.c
index c0270c2..7e6b2e1 100644
--- a/libavformat/mp3enc.c
+++ b/libavformat/mp3enc.c
@@ -421,8 +421,12 @@ static int mp3_write_packet(AVFormatContext *s, AVPacket 
*pkt)
 /* buffer audio packets until we get all the pictures */
 AVPacketList *pktl = av_mallocz(sizeof(*pktl));
 int ret;
-if (!pktl)
-return AVERROR(ENOMEM);
+if (!pktl) {
+av_log(s, AV_LOG_WARNING, "Not enough memory to buffer audio. 
Skipping picture streams\n");
+mp3->pics_to_write = 0;
+mp3_queue_flush(s);
+return mp3_write_audio_packet(s, pkt);
+}
 
 ret = av_copy_packet(&pktl->pkt, pkt);
 if (ret < 0) {
-- 
1.8.5.5

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

Re: [FFmpeg-devel] [PATCH] Improved AC3 decoder level support (heavy drc, dialnorm)

[Jean-Francois Thibert]

On Tue, Aug 26, 2014 at 7:40 PM, Michael Niedermayer  wrote:
> do you have a testcase/sample to test this ?
>
I don't have any specific sample but this can be tested with any
broadcast or most disc source using AC3 audio. I just tried with the
Broadway-5.1 clip from samples.mplayerhq.hu/A-codecs/AC3 and it
contains both types of DRC and can be decoded in multiple modes

./ffmpeg -heavy_compr 1 -target_level -20 -i Broadway-5.1.ac3 -acodec
pcm_s16le -ac 2 BroadwayHeavyDRC.wav

./ffmpeg -drc_scale 1 -target_level -31 -i Broadway-5.1.ac3 -acodec
pcm_s16le -ac 2 BroadwayLightDRC.wav

./ffmpeg -drc_scale 0 -target_level -31 -i Broadway-5.1.ac3 -acodec
pcm_s16le -ac 2 BroadwayNoDRC.wav
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] lavc/libwebpenc: use WebPMemoryWriterClear()

[James Almer]

WebPMemoryWriterClear() must be used instead of free() when libwebp ABI version 
is > 0x0202.

Signed-off-by: James Almer 
---
Untested. Latest stable libwebp release (0.4.1) is still 0x0202.

 libavcodec/libwebpenc.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/libavcodec/libwebpenc.c b/libavcodec/libwebpenc.c
index 5283da5..4f213bc 100644
--- a/libavcodec/libwebpenc.c
+++ b/libavcodec/libwebpenc.c
@@ -231,7 +231,11 @@ static int libwebp_encode_frame(AVCodecContext *avctx, 
AVPacket *pkt,
 *got_packet = 1;
 
 end:
+#if (WEBP_ENCODER_ABI_VERSION > 0x0202)
+WebPMemoryWriterClear(&mw);
+#else
 free(mw.mem); /* must use free() according to libwebp documentation */
+#endif
 WebPPictureFree(pic);
 av_freep(&pic);
 av_frame_free(&alt_frame);
-- 
1.8.5.5

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