Re: [FFmpeg-devel] lurking bugs in the mmx-related assembler code (?)

[compn]

On Sun, 2 Oct 2016 08:29:22 -0400
"Ronald S. Bultje"  wrote:

> I also think we could contact musl developers and see what's going on
> there. We certainly shouldn't blindly fix this bug by adding an emms
> in a random place, to me that's like opening pandora's box.

on irc i pointed dalias to this thread.

or you can just ask on #musl in freenode.

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

Re: [FFmpeg-devel] lurking bugs in the mmx-related assembler code (?)

[compn]

On Sun, 2 Oct 2016 23:16:02 +0200
u-h...@aetey.se wrote:

> > looking at the code? Seriously?)
> 
> Yes, I am serious.

vp3 is a decoder written 10+ years ago by a dev who is no longer
active in ffmpeg.

we have many decoders and encoders (and other code) in ffmpeg that have
not been audited (to my knowledge).

i know this isnt an excuse for not looking at the code. just letting
you know the history.

> Frankly, your tone looks unpleasant.
> It is a friendly information to make you aware. I guess you were not.

please dont think carl's tone is unpleasant, maybe he is just
incredulous.

carl has tested and verified thousands of bugs for ffmpeg. carl also
fixes some of them. carl i think was confused by your comment, because
carl would like to reproduce the bug. reproducing the bug with an easy
command line, on a dev computer usually makes the bug finding and fixing
quicker.

> To give you an example of successful code auditing, the corresponding
> UB-problem in libtheora was properly fixed without anybody at Xiph
> having to install musl.
> That's why I still believe that auditing the code is more useful than
> hunting once again the hard-to-pinpoint symptoms of the already known
> cause.

do you have any suggestions for how the ffmpeg project could do
successful code audits?

we have static code analyzers like coverity running on ffmpeg. there
has also been a lot of fuzz testing done. i'm sure some of the more
popular decoders like h264 have had code audits done in private.

i really dont see much enthusiasm for line by line code auditing within
ffmpeg. in fact, i'd say people would rather re-write an entirely new
piece of code than try to clean up the old code. this isnt a knock on
anyone or any piece of code, just my observation.

feel free to tell me that i am wrong.

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

Re: [FFmpeg-devel] [PATCH]doc/platform: Mention musl where x86_32 is not supported

[Carl Eugen Hoyos]

2016-10-03 2:57 GMT+02:00 wm4 :

>> +Do not compile FFmpeg with musl on x86_32, random
>> crashes have to be expected.

> You could mention that this is due to FFmpeg violating the
> ABI (apparently).

New patch attached.

Carl Eugen
From 008248a202e9eb6c1f946467a6fd45825a82a92a Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Mon, 3 Oct 2016 03:50:29 +0200
Subject: [PATCH] doc/platform: Mention musl where x86_32 is not supported.

---
 doc/platform.texi |8 
 1 file changed, 8 insertions(+)

diff --git a/doc/platform.texi b/doc/platform.texi
index 21b135f..5c252ac 100644
--- a/doc/platform.texi
+++ b/doc/platform.texi
@@ -77,6 +77,14 @@ optimized assembly functions. @uref{http://www.finkproject.org/, Fink},
 @uref{https://mxcl.github.com/homebrew/, Homebrew}
 or @uref{http://www.macports.org, MacPorts} can easily provide it.
 
+@section musl
+
+Compilation with @uref{http://www.musl-libc.org/, musl} on x86-64 is supposed
+to work out-of-the-box.
+Do not compile FFmpeg with musl on x86_32 with assembler optimizations, random
+crashes have to be expected because FFmpeg does not always clear the fpu state
+as required by POSIX.
+
 
 @chapter DOS
 
-- 
1.7.10.4

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

Re: [FFmpeg-devel] [PATCH]doc/platform: Mention musl where x86_32 is not supported

[wm4]

On Mon, 3 Oct 2016 01:51:25 +0200
Carl Eugen Hoyos  wrote:

> From 35bf44b909658864c9e8cca8dbc855dbde1e1ef5 Mon Sep 17 00:00:00 2001
> From: Carl Eugen Hoyos 
> Date: Mon, 3 Oct 2016 01:41:37 +0200
> Subject: [PATCH] doc/platform: Mention musl where x86_32 is not supported.
> 
> ---
>  doc/platform.texi |6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/doc/platform.texi b/doc/platform.texi
> index 21b135f..3404407 100644
> --- a/doc/platform.texi
> +++ b/doc/platform.texi
> @@ -77,6 +77,12 @@ optimized assembly functions. 
> @uref{http://www.finkproject.org/, Fink},
>  @uref{https://mxcl.github.com/homebrew/, Homebrew}
>  or @uref{http://www.macports.org, MacPorts} can easily provide it.
>  
> +@section musl
> +
> +Compilation with @uref{http://www.musl-libc.org/, musl} on x86-64 is supposed
> +to work out-of-the-box.
> +Do not compile FFmpeg with musl on x86_32, random crashes have to be 
> expected.
> +
>  
>  @chapter DOS
>  

You could mention that this is due to FFmpeg violating the ABI
(apparently).
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]doc/platform: Mention musl where x86_32 is not supported

[Josh de Kock]

On 03/10/2016 01:44, Ronald S. Bultje wrote:

Hi,

On Sun, Oct 2, 2016 at 8:42 PM, Carl Eugen Hoyos  wrote:


2016-10-03 2:36 GMT+02:00 Ronald S. Bultje :

Hi,

On Sun, Oct 2, 2016 at 7:51 PM, Carl Eugen Hoyos 

wrote:



Attached patch adds a musl section to doc/platform.


This is counter-productive...


Sorry, I just wanted to be productive wrt a bug (actually
bugs) that we will not be able to fix quickly.



Have we reported it upstream? That seems to be the least we can do.



Not sure it's worth reporting upstream, we're at fault here. The SysV 
calling convention ABI explicitly states: 'If the function does not 
return a floating-point value, then this register must be empty. This 
register must be empty before entry to a function.' (in regards to the 
floating point registers).


See: http://sco.com/developers/devspecs/abi386-4.pdf pages 37-38

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

Re: [FFmpeg-devel] [PATCH]doc/platform: Mention musl where x86_32 is not supported

[Ronald S. Bultje]

Hi,

On Sun, Oct 2, 2016 at 8:42 PM, Carl Eugen Hoyos  wrote:

> 2016-10-03 2:36 GMT+02:00 Ronald S. Bultje :
> > Hi,
> >
> > On Sun, Oct 2, 2016 at 7:51 PM, Carl Eugen Hoyos 
> wrote:
> >
> >> Attached patch adds a musl section to doc/platform.
> >
> > This is counter-productive...
>
> Sorry, I just wanted to be productive wrt a bug (actually
> bugs) that we will not be able to fix quickly.


Have we reported it upstream? That seems to be the least we can do.

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

Re: [FFmpeg-devel] [PATCH]doc/platform: Mention musl where x86_32 is not supported

[Carl Eugen Hoyos]

2016-10-03 2:36 GMT+02:00 Ronald S. Bultje :
> Hi,
>
> On Sun, Oct 2, 2016 at 7:51 PM, Carl Eugen Hoyos  wrote:
>
>> Attached patch adds a musl section to doc/platform.
>
> This is counter-productive...

Sorry, I just wanted to be productive wrt a bug (actually
bugs) that we will not be able to fix quickly.

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

Re: [FFmpeg-devel] [PATCH]doc/platform: Mention musl where x86_32 is not supported

[Ronald S. Bultje]

Hi,

On Sun, Oct 2, 2016 at 7:51 PM, Carl Eugen Hoyos  wrote:

> Hi!
>
> Attached patch adds a musl section to doc/platform.


This is counter-productive... Let's work with the musl-devs and fix their
libc-alternative?

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

[FFmpeg-devel] [PATCH]doc/platform: Mention musl where x86_32 is not supported

[Carl Eugen Hoyos]

Hi!

Attached patch adds a musl section to doc/platform.

Please comment, Carl Eugen
From 35bf44b909658864c9e8cca8dbc855dbde1e1ef5 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Mon, 3 Oct 2016 01:41:37 +0200
Subject: [PATCH] doc/platform: Mention musl where x86_32 is not supported.

---
 doc/platform.texi |6 ++
 1 file changed, 6 insertions(+)

diff --git a/doc/platform.texi b/doc/platform.texi
index 21b135f..3404407 100644
--- a/doc/platform.texi
+++ b/doc/platform.texi
@@ -77,6 +77,12 @@ optimized assembly functions. 
@uref{http://www.finkproject.org/, Fink},
 @uref{https://mxcl.github.com/homebrew/, Homebrew}
 or @uref{http://www.macports.org, MacPorts} can easily provide it.
 
+@section musl
+
+Compilation with @uref{http://www.musl-libc.org/, musl} on x86-64 is supposed
+to work out-of-the-box.
+Do not compile FFmpeg with musl on x86_32, random crashes have to be expected.
+
 
 @chapter DOS
 
-- 
1.7.10.4

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

Re: [FFmpeg-devel] [PATCH] fate: Add PSP test

[Michael Niedermayer]

On Sat, Oct 01, 2016 at 04:36:54PM -0300, James Almer wrote:
> On 10/1/2016 4:24 PM, Michael Niedermayer wrote:
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  tests/fate/ffmpeg.mak |   4 +
> >  tests/ref/fate/psp| 287 
> > ++
> >  2 files changed, 291 insertions(+)
> >  create mode 100644 tests/ref/fate/psp
> > 
> > diff --git a/tests/fate/ffmpeg.mak b/tests/fate/ffmpeg.mak
> > index eb90090..a0d9f9b 100644
> > --- a/tests/fate/ffmpeg.mak
> > +++ b/tests/fate/ffmpeg.mak
> > @@ -105,5 +105,9 @@ fate-ffmpeg-bsf-remove-e: 
> > $(TARGET_SAMPLES)/mpeg2/matrixbench_mpeg2.lq1.mpg
> >  fate-ffmpeg-bsf-remove-e: CMD = transcode "mpeg" 
> > $(TARGET_SAMPLES)/mpeg2/matrixbench_mpeg2.lq1.mpg\
> >avi "-vbsf remove_extra=e" "-codec copy"
> >  
> > +FATE_SAMPLES_FFMPEG-$(call ALLYES, MOV_DEMUXER MOV_MUXER) += fate-psp
> 
> fate-copy-psp or fate-remux-psp would be a better name, i think.
> Also, add it to FATE_STREAMCOPY earlier in the file instead.

changed
applied

thx

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

Into a blind darkness they enter who follow after the Ignorance,
they as if into a greater darkness enter who devote themselves
to the Knowledge alone. -- Isha Upanishad


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

Re: [FFmpeg-devel] [PATCH 3/3] avformat/hlsenc: support multi level path in m3u8 with filename

[Steven Liu]

will push aftet 24 hours
Steven Liu 于2016年9月26日 周一下午4:05写道：

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

Re: [FFmpeg-devel] [PATCH v2] doc/t2h: use container

[Josh de Kock]

On 03/10/2016 00:07, Timothy Gu wrote:

On Sun, Oct 02, 2016 at 02:53:22PM +0100, Josh de Kock wrote:

Full width text is really difficult to read, this makes it more
more legible on larger (widescreen) screens. It also means we aren't
inventing our own container instead of using the bootstrap one.

Signed-off-by: Josh de Kock 
---
 doc/t2h.init | 2 +-
 doc/t2h.pm   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)


LGTM.



Thanks, applied.

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

Re: [FFmpeg-devel] [PATCH 1/3] avformat/matroska: write FlagInterlaced element in WebM

[James Almer]

On 9/27/2016 3:03 PM, James Almer wrote:
> It's listed as supported in both https://www.webmproject.org/docs/container/
> and https://matroska.org/technical/specs/index.html
> 
> Signed-off-by: James Almer 
> ---
>  libavformat/matroskaenc.c | 41 +
>  1 file changed, 21 insertions(+), 20 deletions(-)

Ping.

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

Re: [FFmpeg-devel] [PATCH 1/2] avformat/matroskaenc: don't write an empty Colour master element

[James Almer]

On 9/27/2016 8:49 PM, James Almer wrote:
> Signed-off-by: James Almer 
> ---
>  libavformat/matroskaenc.c | 53 
> ++-
>  1 file changed, 34 insertions(+), 19 deletions(-)

Ping for patchset.

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

Re: [FFmpeg-devel] [PATCH v2] doc/t2h: use container

[Timothy Gu]

On Sun, Oct 02, 2016 at 02:53:22PM +0100, Josh de Kock wrote:
> Full width text is really difficult to read, this makes it more
> more legible on larger (widescreen) screens. It also means we aren't
> inventing our own container instead of using the bootstrap one.
> 
> Signed-off-by: Josh de Kock 
> ---
>  doc/t2h.init | 2 +-
>  doc/t2h.pm   | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)

LGTM.

[...]

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

Re: [FFmpeg-devel] [PATCH v2 1/2] doc/developer: reword some of the policies

[Michael Niedermayer]

On Sun, Oct 02, 2016 at 11:16:49PM +0100, Josh de Kock wrote:
> 
> 
> On 02/10/2016 22:47, Michael Niedermayer wrote:
> >On Sun, Oct 02, 2016 at 01:51:41AM +0100, Josh de Kock wrote:
> >>Explicitly state that FATE should pass, and code should work
> >>for all reviewers who tested.
[...]
> >>-@item
> >>-Do not commit unrelated changes together, split them into self-contained
> >>-pieces. Also do not forget that if part B depends on part A, but A does not
> >>-depend on B, then A can and should be committed first and separate from B.
> >>-Keeping changes well split into self-contained parts makes reviewing and
> >>-understanding them on the commit log mailing list easier. This also helps
> >>-in case of debugging later on.
> >>+@item Testing must be adequate but not excessive.
> >>+If it works for you, others, and passes FATE then it should be OK to commit
> >>+it, provided it fits the other committing criteria. You should not worry 
> >>about
> >>+over-testing things. If your code has problems (portability, triggers
> >>+compiler bugs, unusual environment etc) they will be reported and 
> >>eventually
> >>+fixed.
> >>+
> >>+@item Do not commit unrelated changes together.
> >>+They should be split them into self-contained pieces. Also do not forget
> >>+that if part B depends on part A, but A does not depend on B, then A can
> >>+and should be committed first and separate from B. Keeping changes well
> >>+split into self-contained parts makes reviewing and understanding them on
> >>+the commit log mailing list easier. This also helps in case of debugging
> >>+later on.
> >> Also if you have doubts about splitting or not splitting, do not hesitate 
> >> to
> >> ask/discuss it on the developer mailing list.
> >>
> >
> >>-@item
> >>+@item API/ABI breakages and changes should be discussed before they are 
> >>made.
> >
> >I dont think this should list "breakages"
> >"breakages" are a subset of "changes"
> >and except in exteemly rare cases "breakages" should not happen
> >intentionally
> >
> 
> That makes sense, I'll push a couple days with `s/breakages and //`
> if there are no further comments.

not sure this fits in the patchset but
maybe "deprecation" should be added as deprecation implies future
change. Such change of course needs to be discussed. Discussing it
at the time of deprecation is better than after.

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

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


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

Re: [FFmpeg-devel] lurking bugs in the mmx-related assembler code (?)

[Ronald S. Bultje]

Hi,

On Sun, Oct 2, 2016 at 6:41 PM, Carl Eugen Hoyos  wrote:

> 2016-10-02 14:29 GMT+02:00 Ronald S. Bultje :
> > I also think we could contact musl developers and see what's
> > going on there.
>
> I suspect I found the responsible code:
> http://git.musl-libc.org/cgit/musl/tree/src/malloc/malloc.c#n114


So it's like a hashing function? (Basically.)

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

Re: [FFmpeg-devel] lurking bugs in the mmx-related assembler code (?)

[Carl Eugen Hoyos]

2016-10-02 14:29 GMT+02:00 Ronald S. Bultje :
> I also think we could contact musl developers and see what's
> going on there.

I suspect I found the responsible code:
http://git.musl-libc.org/cgit/musl/tree/src/malloc/malloc.c#n114

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

Re: [FFmpeg-devel] [PATCH v2 1/2] doc/developer: reword some of the policies

[Josh de Kock]

On 02/10/2016 22:47, Michael Niedermayer wrote:

On Sun, Oct 02, 2016 at 01:51:41AM +0100, Josh de Kock wrote:

Explicitly state that FATE should pass, and code should work
for all reviewers who tested.

Signed-off-by: Josh de Kock 
---
 doc/developer.texi | 91 ++
 1 file changed, 44 insertions(+), 47 deletions(-)

diff --git a/doc/developer.texi b/doc/developer.texi
index 4d3a7ae..0075a27 100644
--- a/doc/developer.texi
+++ b/doc/developer.texi
@@ -247,7 +247,7 @@ For Emacs, add these roughly equivalent lines to your 
@file{.emacs.d/init.el}:
 @section Development Policy

 @enumerate
-@item
+@item Licenses for patches must be compatible with FFmpeg.
 Contributions should be licensed under the
 @uref{http://www.gnu.org/licenses/lgpl-2.1.html, LGPL 2.1},
 including an "or any later version" clause, or, if you prefer



@@ -260,15 +260,15 @@ preferred.
 If you add a new file, give it a proper license header. Do not copy and
 paste it from a random place, use an existing file as template.

-@item
-You must not commit code which breaks FFmpeg! (Meaning unfinished but
-enabled code which breaks compilation or compiles but does not work or
-breaks the regression tests)
-You can commit unfinished stuff (for testing etc), but it must be disabled
-(#ifdef etc) by default so it does not interfere with other developers'
-work.
+@item You must not commit code which breaks FFmpeg!
+This means unfinished code which is enabled and breaks compilation,
+or compiles but does not work/breaks the regression tests. Code which
+is unfinished but disabled may be permitted under-circumstances, like
+missing samples or an implementation with a small subset of features.
+Always check the mailing list for any reviewers with issues and test
+FATE before you push.


"You can" and "may be permitted under-circumstances" has rather
different meaning. Also the later is bad in a text like this
as its ambigous ...




-@item
+@item Keep the main commit message short with an extended description below.
 The commit message should have a short first line in the form of
 a @samp{topic: short description} as a header, separated by a newline
 from the body consisting of an explanation of why the change is necessary.
@@ -276,30 +276,29 @@ If the commit fixes a known bug on the bug tracker, the 
commit message
 should include its bug ID. Referring to the issue on the bug tracker does
 not exempt you from writing an excerpt of the bug in the commit message.

-@item
-You do not have to over-test things. If it works for you, and you think it
-should work for others, then commit. If your code has problems
-(portability, triggers compiler bugs, unusual environment etc) they will be
-reported and eventually fixed.
-
-@item
-Do not commit unrelated changes together, split them into self-contained
-pieces. Also do not forget that if part B depends on part A, but A does not
-depend on B, then A can and should be committed first and separate from B.
-Keeping changes well split into self-contained parts makes reviewing and
-understanding them on the commit log mailing list easier. This also helps
-in case of debugging later on.
+@item Testing must be adequate but not excessive.
+If it works for you, others, and passes FATE then it should be OK to commit
+it, provided it fits the other committing criteria. You should not worry about
+over-testing things. If your code has problems (portability, triggers
+compiler bugs, unusual environment etc) they will be reported and eventually
+fixed.
+
+@item Do not commit unrelated changes together.
+They should be split them into self-contained pieces. Also do not forget
+that if part B depends on part A, but A does not depend on B, then A can
+and should be committed first and separate from B. Keeping changes well
+split into self-contained parts makes reviewing and understanding them on
+the commit log mailing list easier. This also helps in case of debugging
+later on.
 Also if you have doubts about splitting or not splitting, do not hesitate to
 ask/discuss it on the developer mailing list.




-@item
+@item API/ABI breakages and changes should be discussed before they are made.


I dont think this should list "breakages"
"breakages" are a subset of "changes"
and except in exteemly rare cases "breakages" should not happen
intentionally



That makes sense, I'll push a couple days with `s/breakages and //` if 
there are no further comments.


Thanks for the review.

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

Re: [FFmpeg-devel] lurking bugs in the mmx-related assembler code (?)

[Ronald S. Bultje]

Hi,

On Sun, Oct 2, 2016 at 4:24 PM, Carl Eugen Hoyos  wrote:

> 2016-10-02 16:01 GMT+02:00 Carl Eugen Hoyos :
>
> > PS: There are several unrelated build issues.
>
> The build issues were just seen here because I
> had to add "-melf_i386" to the musl spec file.
> After adding it, building works perfectly smooth.
>
> I tested with --enable-debug for musl and still get
> no backtrace, valgrind cannot help.
>
> No issue on x86_64: The musl spec file works
> fine and fate passes with asm optimizations.


Floating point operations on x86-64 (which is by definition >= SSE2) are
typically done using scalar SSE instructions, not using x87. Therefore, if
you don't clean up the floating point state, things will usually still work
fine. On x86-32, you can't do this because you can't be sure that the CPU
supports SSE.

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

Re: [FFmpeg-devel] [PATCH v2 1/2] doc/developer: reword some of the policies

[Michael Niedermayer]

On Sun, Oct 02, 2016 at 01:51:41AM +0100, Josh de Kock wrote:
> Explicitly state that FATE should pass, and code should work
> for all reviewers who tested.
> 
> Signed-off-by: Josh de Kock 
> ---
>  doc/developer.texi | 91 
> ++
>  1 file changed, 44 insertions(+), 47 deletions(-)
> 
> diff --git a/doc/developer.texi b/doc/developer.texi
> index 4d3a7ae..0075a27 100644
> --- a/doc/developer.texi
> +++ b/doc/developer.texi
> @@ -247,7 +247,7 @@ For Emacs, add these roughly equivalent lines to your 
> @file{.emacs.d/init.el}:
>  @section Development Policy
>  
>  @enumerate
> -@item
> +@item Licenses for patches must be compatible with FFmpeg.
>  Contributions should be licensed under the
>  @uref{http://www.gnu.org/licenses/lgpl-2.1.html, LGPL 2.1},
>  including an "or any later version" clause, or, if you prefer

> @@ -260,15 +260,15 @@ preferred.
>  If you add a new file, give it a proper license header. Do not copy and
>  paste it from a random place, use an existing file as template.
>  
> -@item
> -You must not commit code which breaks FFmpeg! (Meaning unfinished but
> -enabled code which breaks compilation or compiles but does not work or
> -breaks the regression tests)
> -You can commit unfinished stuff (for testing etc), but it must be disabled
> -(#ifdef etc) by default so it does not interfere with other developers'
> -work.
> +@item You must not commit code which breaks FFmpeg!
> +This means unfinished code which is enabled and breaks compilation,
> +or compiles but does not work/breaks the regression tests. Code which
> +is unfinished but disabled may be permitted under-circumstances, like
> +missing samples or an implementation with a small subset of features.
> +Always check the mailing list for any reviewers with issues and test
> +FATE before you push.

"You can" and "may be permitted under-circumstances" has rather
different meaning. Also the later is bad in a text like this
as its ambigous ...


>  
> -@item
> +@item Keep the main commit message short with an extended description below.
>  The commit message should have a short first line in the form of
>  a @samp{topic: short description} as a header, separated by a newline
>  from the body consisting of an explanation of why the change is necessary.
> @@ -276,30 +276,29 @@ If the commit fixes a known bug on the bug tracker, the 
> commit message
>  should include its bug ID. Referring to the issue on the bug tracker does
>  not exempt you from writing an excerpt of the bug in the commit message.
>  
> -@item
> -You do not have to over-test things. If it works for you, and you think it
> -should work for others, then commit. If your code has problems
> -(portability, triggers compiler bugs, unusual environment etc) they will be
> -reported and eventually fixed.
> -
> -@item
> -Do not commit unrelated changes together, split them into self-contained
> -pieces. Also do not forget that if part B depends on part A, but A does not
> -depend on B, then A can and should be committed first and separate from B.
> -Keeping changes well split into self-contained parts makes reviewing and
> -understanding them on the commit log mailing list easier. This also helps
> -in case of debugging later on.
> +@item Testing must be adequate but not excessive.
> +If it works for you, others, and passes FATE then it should be OK to commit
> +it, provided it fits the other committing criteria. You should not worry 
> about
> +over-testing things. If your code has problems (portability, triggers
> +compiler bugs, unusual environment etc) they will be reported and eventually
> +fixed.
> +
> +@item Do not commit unrelated changes together.
> +They should be split them into self-contained pieces. Also do not forget
> +that if part B depends on part A, but A does not depend on B, then A can
> +and should be committed first and separate from B. Keeping changes well
> +split into self-contained parts makes reviewing and understanding them on
> +the commit log mailing list easier. This also helps in case of debugging
> +later on.
>  Also if you have doubts about splitting or not splitting, do not hesitate to
>  ask/discuss it on the developer mailing list.
>  

> -@item
> +@item API/ABI breakages and changes should be discussed before they are made.

I dont think this should list "breakages"
"breakages" are a subset of "changes"
and except in exteemly rare cases "breakages" should not happen
intentionally


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

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


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

Re: [FFmpeg-devel] [PATCH v2 1/2] doc/developer: reword some of the policies

[James Almer]

On 10/1/2016 9:51 PM, Josh de Kock wrote:
> Explicitly state that FATE should pass, and code should work
> for all reviewers who tested.
> 
> Signed-off-by: Josh de Kock 
> ---
>  doc/developer.texi | 91 
> ++
>  1 file changed, 44 insertions(+), 47 deletions(-)
> 
> diff --git a/doc/developer.texi b/doc/developer.texi
> index 4d3a7ae..0075a27 100644
> --- a/doc/developer.texi
> +++ b/doc/developer.texi
> @@ -247,7 +247,7 @@ For Emacs, add these roughly equivalent lines to your 
> @file{.emacs.d/init.el}:
>  @section Development Policy
>  
>  @enumerate
> -@item
> +@item Licenses for patches must be compatible with FFmpeg.
>  Contributions should be licensed under the
>  @uref{http://www.gnu.org/licenses/lgpl-2.1.html, LGPL 2.1},
>  including an "or any later version" clause, or, if you prefer
> @@ -260,15 +260,15 @@ preferred.
>  If you add a new file, give it a proper license header. Do not copy and
>  paste it from a random place, use an existing file as template.
>  
> -@item
> -You must not commit code which breaks FFmpeg! (Meaning unfinished but
> -enabled code which breaks compilation or compiles but does not work or
> -breaks the regression tests)
> -You can commit unfinished stuff (for testing etc), but it must be disabled
> -(#ifdef etc) by default so it does not interfere with other developers'
> -work.
> +@item You must not commit code which breaks FFmpeg!
> +This means unfinished code which is enabled and breaks compilation,
> +or compiles but does not work/breaks the regression tests. Code which
> +is unfinished but disabled may be permitted under-circumstances, like
> +missing samples or an implementation with a small subset of features.
> +Always check the mailing list for any reviewers with issues and test
> +FATE before you push.
>  
> -@item
> +@item Keep the main commit message short with an extended description below.
>  The commit message should have a short first line in the form of
>  a @samp{topic: short description} as a header, separated by a newline
>  from the body consisting of an explanation of why the change is necessary.
> @@ -276,30 +276,29 @@ If the commit fixes a known bug on the bug tracker, the 
> commit message
>  should include its bug ID. Referring to the issue on the bug tracker does
>  not exempt you from writing an excerpt of the bug in the commit message.
>  
> -@item
> -You do not have to over-test things. If it works for you, and you think it
> -should work for others, then commit. If your code has problems
> -(portability, triggers compiler bugs, unusual environment etc) they will be
> -reported and eventually fixed.
> -
> -@item
> -Do not commit unrelated changes together, split them into self-contained
> -pieces. Also do not forget that if part B depends on part A, but A does not
> -depend on B, then A can and should be committed first and separate from B.
> -Keeping changes well split into self-contained parts makes reviewing and
> -understanding them on the commit log mailing list easier. This also helps
> -in case of debugging later on.
> +@item Testing must be adequate but not excessive.
> +If it works for you, others, and passes FATE then it should be OK to commit
> +it, provided it fits the other committing criteria. You should not worry 
> about
> +over-testing things. If your code has problems (portability, triggers
> +compiler bugs, unusual environment etc) they will be reported and eventually
> +fixed.
> +
> +@item Do not commit unrelated changes together.
> +They should be split them into self-contained pieces. Also do not forget
> +that if part B depends on part A, but A does not depend on B, then A can
> +and should be committed first and separate from B. Keeping changes well
> +split into self-contained parts makes reviewing and understanding them on
> +the commit log mailing list easier. This also helps in case of debugging
> +later on.
>  Also if you have doubts about splitting or not splitting, do not hesitate to
>  ask/discuss it on the developer mailing list.
>  
> -@item
> +@item API/ABI breakages and changes should be discussed before they are made.
>  Do not change behavior of the programs (renaming options etc) or public
>  API or ABI without first discussing it on the ffmpeg-devel mailing list.
> -Do not remove functionality from the code. Just improve!
> -
> -Note: Redundant code can be removed.
> +Do not remove widely used functionality or features (redundant code can be 
> removed).
>  
> -@item
> +@item Ask before you change the build system (configure, etc).
>  Do not commit changes to the build system (Makefiles, configure script)
>  which change behavior, defaults etc, without asking first. The same
>  applies to compiler warning fixes, trivial looking fixes and to code
> @@ -308,7 +307,7 @@ the way we do. Send your changes as patches to the 
> ffmpeg-devel mailing
>  list, and if the code maintainers say OK, you may commit. This does not
>  apply to files 

Re: [FFmpeg-devel] [PATCH 3/3] avcodec/cuvid: set best_effort_timestamp instead of frame pts

[Hendrik Leppkes]

On Sun, Oct 2, 2016 at 11:08 PM, Timo Rothenpieler
 wrote:
> ---
>  libavcodec/cuvid.c | 16 
>  1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/libavcodec/cuvid.c b/libavcodec/cuvid.c
> index e9a1dd7..5ceb94e 100644
> --- a/libavcodec/cuvid.c
> +++ b/libavcodec/cuvid.c
> @@ -451,25 +451,25 @@ static int cuvid_output_frame(AVCodecContext *avctx, 
> AVFrame *frame)
>  frame->width = avctx->width;
>  frame->height = avctx->height;
>  if (avctx->pkt_timebase.num && avctx->pkt_timebase.den)
> -frame->pts = av_rescale_q(parsed_frame.dispinfo.timestamp, 
> (AVRational){1, 1000}, avctx->pkt_timebase);
> +frame->pkt_pts = av_rescale_q(parsed_frame.dispinfo.timestamp, 
> (AVRational){1, 1000}, avctx->pkt_timebase);
>  else
> -frame->pts = parsed_frame.dispinfo.timestamp;
> +frame->pkt_pts = parsed_frame.dispinfo.timestamp;
>
>  if (parsed_frame.second_field) {
>  if (ctx->prev_pts == INT64_MIN) {
> -ctx->prev_pts = frame->pts;
> -frame->pts += (avctx->pkt_timebase.den * 
> avctx->framerate.den) / (avctx->pkt_timebase.num * avctx->framerate.num);
> +ctx->prev_pts = frame->pkt_pts;
> +frame->pkt_pts += (avctx->pkt_timebase.den * 
> avctx->framerate.den) / (avctx->pkt_timebase.num * avctx->framerate.num);
>  } else {
> -int pts_diff = (frame->pts - ctx->prev_pts) / 2;
> -ctx->prev_pts = frame->pts;
> -frame->pts += pts_diff;
> +int pts_diff = (frame->pkt_pts - ctx->prev_pts) / 2;
> +ctx->prev_pts = frame->pkt_pts;
> +frame->pkt_pts += pts_diff;
>  }
>  }
>
>  /* CUVIDs opaque reordering breaks the internal pkt logic.
>   * So set pkt_pts and clear all the other pkt_ fields.
>   */
> -frame->pkt_pts = frame->pts;
> +av_frame_set_best_effort_timestamp(frame, frame->pkt_pts);
>  av_frame_set_pkt_pos(frame, -1);
>  av_frame_set_pkt_duration(frame, 0);
>  av_frame_set_pkt_size(frame, -1);
> --
> 2.10.0
>

Please just leave the pts stuff as-is, or we'll have to undo these
changes right in the next merge again, which deprecates pkt_pts and
favors using AVFrame.pts for decoding as well (less redundant fields).
Setting both for the time being should not have any negative effects.

Settings best effort in addition seems slightly weird, do any other
decoders actually set that by themself?

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

Re: [FFmpeg-devel] lurking bugs in the mmx-related assembler code (?)

[u-h8zb]

Hello Carl Eugen,

On Sun, Oct 02, 2016 at 04:01:21PM +0200, Carl Eugen Hoyos wrote:
> > I do not expect that the ffmpeg developers take the trouble
> > to install an extra build environment with a different libc,
> 
> (If I could just understand this sentence: Is it meant as
> an insult? How do you expect the issue to be fixed? By
> looking at the code? Seriously?)

It is unfortunate if you took this as an insult, it was not.

> looking at the code? Seriously?)

Yes, I am serious.

Frankly, your tone looks unpleasant.
It is a friendly information to make you aware. I guess you were not.

To give you an example of successful code auditing, the corresponding
UB-problem in libtheora was properly fixed without anybody at Xiph having
to install musl.

With all respect to your prefered workflow, it is not the only
possible one and in certain situations may be not the most optimal.

> I can confirm that there is an issue with current musl,

This confirmation is certainly valuable per se.

On the other hand, the underlying problem is not the interaction
with musl, but the reliance of the ffmpeg code on certain UBs.

That's why I still believe that auditing the code is more useful than
hunting once again the hard-to-pinpoint symptoms of the already known
cause.

For the sake of clarity: I do not mean any part of this message
as an insult. It is great that you care about ffmpeg, so do I.

Best regards,
Rune

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

[FFmpeg-devel] [PATCH 2/3] MAINTAINERS: add myself for hwcontext_cuda

[Timo Rothenpieler]

---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index d1e487a..3570253 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -78,6 +78,7 @@ Other:
   eval.c, eval.hMichael Niedermayer
   float_dsp Loren Merritt
   hash  Reimar Doeffinger
+  hwcontext_cuda*   Timo Rothenpieler
   intfloat* Michael Niedermayer
   integer.c, integer.h  Michael Niedermayer
   lzo   Reimar Doeffinger
-- 
2.10.0

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

[FFmpeg-devel] [PATCH 3/3] avcodec/cuvid: set best_effort_timestamp instead of frame pts

[Timo Rothenpieler]

---
 libavcodec/cuvid.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/libavcodec/cuvid.c b/libavcodec/cuvid.c
index e9a1dd7..5ceb94e 100644
--- a/libavcodec/cuvid.c
+++ b/libavcodec/cuvid.c
@@ -451,25 +451,25 @@ static int cuvid_output_frame(AVCodecContext *avctx, 
AVFrame *frame)
 frame->width = avctx->width;
 frame->height = avctx->height;
 if (avctx->pkt_timebase.num && avctx->pkt_timebase.den)
-frame->pts = av_rescale_q(parsed_frame.dispinfo.timestamp, 
(AVRational){1, 1000}, avctx->pkt_timebase);
+frame->pkt_pts = av_rescale_q(parsed_frame.dispinfo.timestamp, 
(AVRational){1, 1000}, avctx->pkt_timebase);
 else
-frame->pts = parsed_frame.dispinfo.timestamp;
+frame->pkt_pts = parsed_frame.dispinfo.timestamp;
 
 if (parsed_frame.second_field) {
 if (ctx->prev_pts == INT64_MIN) {
-ctx->prev_pts = frame->pts;
-frame->pts += (avctx->pkt_timebase.den * avctx->framerate.den) 
/ (avctx->pkt_timebase.num * avctx->framerate.num);
+ctx->prev_pts = frame->pkt_pts;
+frame->pkt_pts += (avctx->pkt_timebase.den * 
avctx->framerate.den) / (avctx->pkt_timebase.num * avctx->framerate.num);
 } else {
-int pts_diff = (frame->pts - ctx->prev_pts) / 2;
-ctx->prev_pts = frame->pts;
-frame->pts += pts_diff;
+int pts_diff = (frame->pkt_pts - ctx->prev_pts) / 2;
+ctx->prev_pts = frame->pkt_pts;
+frame->pkt_pts += pts_diff;
 }
 }
 
 /* CUVIDs opaque reordering breaks the internal pkt logic.
  * So set pkt_pts and clear all the other pkt_ fields.
  */
-frame->pkt_pts = frame->pts;
+av_frame_set_best_effort_timestamp(frame, frame->pkt_pts);
 av_frame_set_pkt_pos(frame, -1);
 av_frame_set_pkt_duration(frame, 0);
 av_frame_set_pkt_size(frame, -1);
-- 
2.10.0

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

[FFmpeg-devel] [PATCH 1/3] avutil/hwcontext_cuda: align allocated frames

[Timo Rothenpieler]

---
 libavutil/hwcontext_cuda.c | 35 ---
 1 file changed, 20 insertions(+), 15 deletions(-)

diff --git a/libavutil/hwcontext_cuda.c b/libavutil/hwcontext_cuda.c
index 40d2971..e1dcab0 100644
--- a/libavutil/hwcontext_cuda.c
+++ b/libavutil/hwcontext_cuda.c
@@ -25,6 +25,8 @@
 #include "pixdesc.h"
 #include "pixfmt.h"
 
+#define CUDA_FRAME_ALIGNMENT 256
+
 typedef struct CUDAFramesContext {
 int shift_width, shift_height;
 } CUDAFramesContext;
@@ -83,6 +85,7 @@ fail:
 static int cuda_frames_init(AVHWFramesContext *ctx)
 {
 CUDAFramesContext *priv = ctx->internal->priv;
+int aligned_width = FFALIGN(ctx->width, CUDA_FRAME_ALIGNMENT);
 int i;
 
 for (i = 0; i < FF_ARRAY_ELEMS(supported_formats); i++) {
@@ -103,10 +106,10 @@ static int cuda_frames_init(AVHWFramesContext *ctx)
 switch (ctx->sw_format) {
 case AV_PIX_FMT_NV12:
 case AV_PIX_FMT_YUV420P:
-size = ctx->width * ctx->height * 3 / 2;
+size = aligned_width * ctx->height * 3 / 2;
 break;
 case AV_PIX_FMT_YUV444P:
-size = ctx->width * ctx->height * 3;
+size = aligned_width * ctx->height * 3;
 break;
 }
 
@@ -120,6 +123,8 @@ static int cuda_frames_init(AVHWFramesContext *ctx)
 
 static int cuda_get_buffer(AVHWFramesContext *ctx, AVFrame *frame)
 {
+int aligned_width = FFALIGN(ctx->width, CUDA_FRAME_ALIGNMENT);
+
 frame->buf[0] = av_buffer_pool_get(ctx->pool);
 if (!frame->buf[0])
 return AVERROR(ENOMEM);
@@ -127,25 +132,25 @@ static int cuda_get_buffer(AVHWFramesContext *ctx, 
AVFrame *frame)
 switch (ctx->sw_format) {
 case AV_PIX_FMT_NV12:
 frame->data[0] = frame->buf[0]->data;
-frame->data[1] = frame->data[0] + ctx->width * ctx->height;
-frame->linesize[0] = ctx->width;
-frame->linesize[1] = ctx->width;
+frame->data[1] = frame->data[0] + aligned_width * ctx->height;
+frame->linesize[0] = aligned_width;
+frame->linesize[1] = aligned_width;
 break;
 case AV_PIX_FMT_YUV420P:
 frame->data[0] = frame->buf[0]->data;
-frame->data[2] = frame->data[0] + ctx->width * ctx->height;
-frame->data[1] = frame->data[2] + ctx->width * ctx->height / 4;
-frame->linesize[0] = ctx->width;
-frame->linesize[1] = ctx->width / 2;
-frame->linesize[2] = ctx->width / 2;
+frame->data[2] = frame->data[0] + aligned_width * ctx->height;
+frame->data[1] = frame->data[2] + aligned_width * ctx->height / 4;
+frame->linesize[0] = aligned_width;
+frame->linesize[1] = aligned_width / 2;
+frame->linesize[2] = aligned_width / 2;
 break;
 case AV_PIX_FMT_YUV444P:
 frame->data[0] = frame->buf[0]->data;
-frame->data[1] = frame->data[0] + ctx->width * ctx->height;
-frame->data[2] = frame->data[1] + ctx->width * ctx->height;
-frame->linesize[0] = ctx->width;
-frame->linesize[1] = ctx->width;
-frame->linesize[2] = ctx->width;
+frame->data[1] = frame->data[0] + aligned_width * ctx->height;
+frame->data[2] = frame->data[1] + aligned_width * ctx->height;
+frame->linesize[0] = aligned_width;
+frame->linesize[1] = aligned_width;
+frame->linesize[2] = aligned_width;
 break;
 default:
 av_frame_unref(frame);
-- 
2.10.0

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

Re: [FFmpeg-devel] [RFC]lavu/x86/pixelutils: Call emms before returning.

[Michael Niedermayer]

On Sun, Oct 02, 2016 at 10:53:17PM +0200, Carl Eugen Hoyos wrote:
> Hi!
> 
> The functions in libavutil/x86/pixelutils.asm are exported 
> to the library users if I understand the code correctly.
> I suspect it can be expected that the MMX state is reset 
> after returning.
> 
> Fixes the pixelutils fate test with musl on x86-32.
> 
> Please comment, Carl Eugen

>  pixelutils.asm |5 +
>  1 file changed, 5 insertions(+)
> a7b729f55ec6170b1c4b1959a4be7530926368ce  
> 0001-lavu-x86-pixelutils-Call-emms-before-returning.patch
> From f16831e6dc0f36c8f290d927bf51142c64fe8afc Mon Sep 17 00:00:00 2001
> From: Carl Eugen Hoyos 
> Date: Sun, 2 Oct 2016 22:45:51 +0200
> Subject: [PATCH] lavu/x86/pixelutils: Call emms before returning.
> 
> The functions are exported and the library user can
> expect that the MMX state is reset after returning.
> ---
>  libavutil/x86/pixelutils.asm |5 +
>  1 file changed, 5 insertions(+)

I think the performance impact of this on some CPUs is too large
to call this at a 8x8 and 16x16 granularity

[...]

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

Re: [FFmpeg-devel] [RFC]lavu/x86/pixelutils: Call emms before returning.

[Hendrik Leppkes]

On Sun, Oct 2, 2016 at 10:53 PM, Carl Eugen Hoyos  wrote:
> Hi!
>
> The functions in libavutil/x86/pixelutils.asm are exported
> to the library users if I understand the code correctly.
> I suspect it can be expected that the MMX state is reset
> after returning.
>
> Fixes the pixelutils fate test with musl on x86-32.
>
> Please comment, Carl Eugen
>

These functions are called in tight loops, and emms is then called in
the user-code after the loop. Calling emms inside the DSP function
would result in a performance degredation.

If a test doesn't call emms after using it, then that should be fixed.
And the docs should perhaps be amended to make note of that. Many DSP
functions work like that, to allow using them in tight loops without
the overhead.

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

[FFmpeg-devel] [RFC]lavu/x86/pixelutils: Call emms before returning.

[Carl Eugen Hoyos]

Hi!

The functions in libavutil/x86/pixelutils.asm are exported 
to the library users if I understand the code correctly.
I suspect it can be expected that the MMX state is reset 
after returning.

Fixes the pixelutils fate test with musl on x86-32.

Please comment, Carl Eugen
From f16831e6dc0f36c8f290d927bf51142c64fe8afc Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Sun, 2 Oct 2016 22:45:51 +0200
Subject: [PATCH] lavu/x86/pixelutils: Call emms before returning.

The functions are exported and the library user can
expect that the MMX state is reset after returning.
---
 libavutil/x86/pixelutils.asm |5 +
 1 file changed, 5 insertions(+)

diff --git a/libavutil/x86/pixelutils.asm b/libavutil/x86/pixelutils.asm
index 7af3007..092eb6e 100644
--- a/libavutil/x86/pixelutils.asm
+++ b/libavutil/x86/pixelutils.asm
@@ -61,6 +61,7 @@ cglobal pixelutils_sad_8x8, 4,4,0, src1, stride1, src2, 
stride2
 paddw   m6, m0
 movdeax, m6
 movzx   eax, ax
+emms
 RET
 
 
;---
@@ -81,6 +82,7 @@ cglobal pixelutils_sad_8x8, 4,4,0, src1, stride1, src2, 
stride2
 lea src2q, [src2q + 2*stride2q]
 %endrep
 movdeax, m2
+emms
 RET
 
 
;---
@@ -101,6 +103,7 @@ cglobal pixelutils_sad_16x16, 4,4,0, src1, stride1, src2, 
stride2
 add src2q, stride2q
 %endrep
 movdeax, m2
+emms
 RET
 
 
;---
@@ -131,6 +134,7 @@ cglobal pixelutils_sad_16x16, 4,4,5, src1, stride1, src2, 
stride2
 movhlps m0, m4
 paddw   m4, m0
 movdeax, m4
+emms
 RET
 
 
;---
@@ -158,6 +162,7 @@ cglobal pixelutils_sad_%1_16x16, 4,4,3, src1, stride1, 
src2, stride2
 movhlps m0, m2
 paddw   m2, m0
 movdeax, m2
+emms
 RET
 %endmacro
 
-- 
1.7.10.4

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

Re: [FFmpeg-devel] lurking bugs in the mmx-related assembler code (?)

[Carl Eugen Hoyos]

2016-10-02 16:01 GMT+02:00 Carl Eugen Hoyos :

> PS: There are several unrelated build issues.

The build issues were just seen here because I
had to add "-melf_i386" to the musl spec file.
After adding it, building works perfectly smooth.

I tested with --enable-debug for musl and still get
no backtrace, valgrind cannot help.

No issue on x86_64: The musl spec file works
fine and fate passes with asm optimizations.

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

[FFmpeg-devel] [PATCH 2/2] libavcodec/ivi_dsp.c: fix warning due to misleading indentation

[Adriano Pallavicino]

From ca69f377f019dc72e7f34020634b57e1e9c6a8d2 Mon Sep 17 00:00:00 2001
From: Adriano Pallavicino 
Date: Sun, 2 Oct 2016 20:42:44 +0200
Subject: [PATCH] Fix warning due to misleading indendation in ivi_dsp.c line
 592
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

libavcodec/ivi_dsp.c: In function ‘ff_ivi_inverse_slant_4x4’:
libavcodec/ivi_dsp.c:592:11: warning: this ‘else’ clause does not guard... [-Wmisleading-indentation]
 } else
   ^~~~
libavcodec/ivi_dsp.c:595:13: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the ‘else’
 src++;

Changes to be committed:
	modified:   libavcodec/ivi_dsp.c

Signed-off-by: Adriano Pallavicino 
---
 libavcodec/ivi_dsp.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavcodec/ivi_dsp.c b/libavcodec/ivi_dsp.c
index 99a7ad5..5211269 100644
--- a/libavcodec/ivi_dsp.c
+++ b/libavcodec/ivi_dsp.c
@@ -592,8 +592,8 @@ void ff_ivi_inverse_slant_4x4(const int32_t *in, int16_t *out, uint32_t pitch, c
 } else
 dst[0] = dst[4] = dst[8] = dst[12] = 0;
 
-src++;
-dst++;
+src++;
+dst++;
 }
 #undef COMPENSATE
 
-- 
2.7.4

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

Re: [FFmpeg-devel] [PATCH] libavfilter/vf_paletteuse.c: fix warning due to misleading indentation

[Clément Bœsch]

On Sun, Oct 02, 2016 at 05:58:30PM +0200, Adriano Pallavicino wrote:
> 

> From 93fe2a96d71ac219915ade0a9247e1ae4b931a27 Mon Sep 17 00:00:00 2001
> From: Adriano Pallavicino 
> Date: Sun, 2 Oct 2016 17:52:12 +0200
> Subject: [PATCH] =?UTF-8?q?Fix=20warning:=20this=20=E2=80=98if=E2=80=99=20?=
>  =?UTF-8?q?clause=20does=20not=20guard...=20[-Wmisleading-indentation]?=
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
> 
>  Please enter the commit message for your changes. Lines starting
>  with '#' will be ignored, and an empty message aborts the commit.
>  On branch fix_if_clause
>  Changes to be committed:
>   modified:   libavfilter/vf_paletteuse.c
> ---
>  libavfilter/vf_paletteuse.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavfilter/vf_paletteuse.c b/libavfilter/vf_paletteuse.c
> index e063ff7..75d80d6 100644
> --- a/libavfilter/vf_paletteuse.c
> +++ b/libavfilter/vf_paletteuse.c
> @@ -444,7 +444,7 @@ static av_always_inline int set_frame(PaletteUseContext 
> *s, AVFrame *out, AVFram
>  if (down) {
>  if (left2)  src[  src_linesize + x - 2] = 
> dither_color(src[  src_linesize + x - 2], er, eg, eb, 1, 4);
>  if (left)   src[  src_linesize + x - 1] = 
> dither_color(src[  src_linesize + x - 1], er, eg, eb, 2, 4);
> -src[  src_linesize + x] = 
> dither_color(src[  src_linesize + x], er, eg, eb, 3, 4);
> +src[  src_linesize + x] = dither_color(src[  
> src_linesize + x], er, eg, eb, 3, 4);

At least remove on that line the spaces used for vertical alignment which
isn't relevant anymore after. It's goddamn ugly otherwise.

>  if (right)  src[  src_linesize + x + 1] = 
> dither_color(src[  src_linesize + x + 1], er, eg, eb, 2, 4);
>  if (right2) src[  src_linesize + x + 2] = 
> dither_color(src[  src_linesize + x + 2], er, eg, eb, 1, 4);
>  }

-- 
Clément B.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavformat/bink.c: fix warning due to misleading indentation

[Josh de Kock]

Hi Adriano,

We appreciate the patches, but is it possible you could maybe collate 
your cosmetic patches and send them as a larger set?


This patch LGTM though, will push tomorrow if no further comments.

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

[FFmpeg-devel] [PATCH 1/2] libavcodec/ivi_dsp.c: fix warning due to misleading indentation

[Adriano Pallavicino]

From 0a13315b4dd55ceb6da28fbbafa7d80b81d94794 Mon Sep 17 00:00:00 2001
From: Adriano Pallavicino 
Date: Sun, 2 Oct 2016 20:27:23 +0200
Subject: [PATCH] Fix warning misleading indentation ivi_dsp.c line 552
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

libavcodec/ivi_dsp.c:552:11: warning: this ‘else’ clause does not guard... [-Wmisleading-indentation]
 } else
   ^~~~
libavcodec/ivi_dsp.c:555:13: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the ‘else’
 src++;

 Changes to be committed:
	modified:   libavcodec/ivi_dsp.c

Signed-off-by: Adriano Pallavicino 
---
 libavcodec/ivi_dsp.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavcodec/ivi_dsp.c b/libavcodec/ivi_dsp.c
index bc9de1a..99a7ad5 100644
--- a/libavcodec/ivi_dsp.c
+++ b/libavcodec/ivi_dsp.c
@@ -552,8 +552,8 @@ void ff_ivi_inverse_slant_8x8(const int32_t *in, int16_t *out, uint32_t pitch, c
 } else
 dst[0] = dst[8] = dst[16] = dst[24] = dst[32] = dst[40] = dst[48] = dst[56] = 0;
 
-src++;
-dst++;
+src++;
+dst++;
 }
 #undef COMPENSATE
 
-- 
2.7.4

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

Re: [FFmpeg-devel] [PATCH 2/2] MAINTAINERS: add myself for hwcontext_cuda

[Michael Niedermayer]

On Sun, Oct 02, 2016 at 06:58:13PM +0200, Timo Rothenpieler wrote:
> ---
>  MAINTAINERS | 1 +
>  1 file changed, 1 insertion(+)

LGTM

thx

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

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


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

Re: [FFmpeg-devel] [PATCH 1/2] avutil/hwcontext_cuda: align allocated frames

[Philip Langdale]

On Sun,  2 Oct 2016 18:58:12 +0200
Timo Rothenpieler  wrote:

> ---
>  libavutil/hwcontext_cuda.c | 43
> --- 1 file changed, 28
> insertions(+), 15 deletions(-)
> 
> diff --git a/libavutil/hwcontext_cuda.c b/libavutil/hwcontext_cuda.c
> index 40d2971..706d195 100644
> --- a/libavutil/hwcontext_cuda.c
> +++ b/libavutil/hwcontext_cuda.c
> @@ -16,6 +16,8 @@
>   * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
> 02110-1301 USA */
>  
> +#include "libavutil/intmath.h"
> +
>  #include "buffer.h"
>  #include "common.h"
>  #include "hwcontext.h"
> @@ -35,6 +37,14 @@ static const enum AVPixelFormat
> supported_formats[] = { AV_PIX_FMT_YUV444P,
>  };
>  
> +static unsigned int next_pow2(unsigned int a)
> +{
> +if (a <= 1)
> +return 1;
> +a = 1 << (sizeof(a) * 8 - ff_clz(a - 1));
> +return FFALIGN(a, 256);
> +}
> +
>  static void cuda_buffer_free(void *opaque, uint8_t *data)
>  {
>  AVHWFramesContext *ctx = opaque;
> @@ -83,6 +93,7 @@ fail:
>  static int cuda_frames_init(AVHWFramesContext *ctx)
>  {
>  CUDAFramesContext *priv = ctx->internal->priv;
> +int aligned_width = next_pow2(ctx->width);
>  int i;
>  
>  for (i = 0; i < FF_ARRAY_ELEMS(supported_formats); i++) {
> @@ -103,10 +114,10 @@ static int cuda_frames_init(AVHWFramesContext
> *ctx) switch (ctx->sw_format) {
>  case AV_PIX_FMT_NV12:
>  case AV_PIX_FMT_YUV420P:
> -size = ctx->width * ctx->height * 3 / 2;
> +size = aligned_width * ctx->height * 3 / 2;
>  break;
>  case AV_PIX_FMT_YUV444P:
> -size = ctx->width * ctx->height * 3;
> +size = aligned_width * ctx->height * 3;
>  break;
>  }
>  
> @@ -120,6 +131,8 @@ static int cuda_frames_init(AVHWFramesContext
> *ctx) 
>  static int cuda_get_buffer(AVHWFramesContext *ctx, AVFrame *frame)
>  {
> +int aligned_width = next_pow2(ctx->width);
> +
>  frame->buf[0] = av_buffer_pool_get(ctx->pool);
>  if (!frame->buf[0])
>  return AVERROR(ENOMEM);
> @@ -127,25 +140,25 @@ static int cuda_get_buffer(AVHWFramesContext
> *ctx, AVFrame *frame) switch (ctx->sw_format) {
>  case AV_PIX_FMT_NV12:
>  frame->data[0] = frame->buf[0]->data;
> -frame->data[1] = frame->data[0] + ctx->width *
> ctx->height;
> -frame->linesize[0] = ctx->width;
> -frame->linesize[1] = ctx->width;
> +frame->data[1] = frame->data[0] + aligned_width *
> ctx->height;
> +frame->linesize[0] = aligned_width;
> +frame->linesize[1] = aligned_width;
>  break;
>  case AV_PIX_FMT_YUV420P:
>  frame->data[0] = frame->buf[0]->data;
> -frame->data[2] = frame->data[0] + ctx->width *
> ctx->height;
> -frame->data[1] = frame->data[2] + ctx->width *
> ctx->height / 4;
> -frame->linesize[0] = ctx->width;
> -frame->linesize[1] = ctx->width / 2;
> -frame->linesize[2] = ctx->width / 2;
> +frame->data[2] = frame->data[0] + aligned_width *
> ctx->height;
> +frame->data[1] = frame->data[2] + aligned_width *
> ctx->height / 4;
> +frame->linesize[0] = aligned_width;
> +frame->linesize[1] = aligned_width / 2;
> +frame->linesize[2] = aligned_width / 2;
>  break;
>  case AV_PIX_FMT_YUV444P:
>  frame->data[0] = frame->buf[0]->data;
> -frame->data[1] = frame->data[0] + ctx->width *
> ctx->height;
> -frame->data[2] = frame->data[1] + ctx->width *
> ctx->height;
> -frame->linesize[0] = ctx->width;
> -frame->linesize[1] = ctx->width;
> -frame->linesize[2] = ctx->width;
> +frame->data[1] = frame->data[0] + aligned_width *
> ctx->height;
> +frame->data[2] = frame->data[1] + aligned_width *
> ctx->height;
> +frame->linesize[0] = aligned_width;
> +frame->linesize[1] = aligned_width;
> +frame->linesize[2] = aligned_width;
>  break;
>  default:
>  av_frame_unref(frame);

Looks good to me (and I tried it out).


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

Re: [FFmpeg-devel] [PATCH 2/2] MAINTAINERS: add myself for hwcontext_cuda

[Philip Langdale]

On Sun,  2 Oct 2016 18:58:13 +0200
Timo Rothenpieler  wrote:

> ---
>  MAINTAINERS | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index d1e487a..3570253 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -78,6 +78,7 @@ Other:
>eval.c, eval.hMichael Niedermayer
>float_dsp Loren Merritt
>hash  Reimar Doeffinger
> +  hwcontext_cuda*   Timo Rothenpieler
>intfloat* Michael Niedermayer
>integer.c, integer.h  Michael Niedermayer
>lzo   Reimar Doeffinger

Ship it


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

[FFmpeg-devel] [PATCH] added possibility to set first to ninth audio language for RIFF taged files (e.g. avi files)

[Florian Diemer]

---
Sorry but the first patch was improperly formatted.


According to this page 
(http://www.sno.phy.queensu.ca/~phil/exiftool/TagNames/RIFF.html#Info) it is 
possible
to add language information ("IAS1" (first language) to "IAS9" (ninth 
language)) to RIFF tagged files (as RIFF Info Tags).
Programs such as VLC media player or MediaInfo can properly read and display 
this information. Allowing to set this tags
with the -metadata option while encoding, would simplify the process.
---
 libavformat/riffenc.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libavformat/riffenc.c b/libavformat/riffenc.c
index 36e6ac7..4b25c06 100644
--- a/libavformat/riffenc.c
+++ b/libavformat/riffenc.c
@@ -304,7 +304,8 @@ void ff_riff_write_info_tag(AVIOContext *pb, const char 
*tag, const char *str)
 }
 
 static const char riff_tags[][5] = {
-"IARL", "IART", "ICMS", "ICMT", "ICOP", "ICRD", "ICRP", "IDIM", "IDPI",
+"IARL", "IART", "IAS1", "IAS2", "IAS3", "IAS4", "IAS5", "IAS6", "IAS7",
+"IAS8", "IAS9", "ICMS", "ICMT", "ICOP", "ICRD", "ICRP", "IDIM", "IDPI",
 "IENG", "IGNR", "IKEY", "ILGT", "ILNG", "IMED", "INAM", "IPLT", "IPRD",
 "IPRT", "ITRK", "ISBJ", "ISFT", "ISHP", "ISMP", "ISRC", "ISRF", "ITCH",
 { 0 }
-- 
2.10.0.windows.1

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

[FFmpeg-devel] [PATCH 2/2] MAINTAINERS: add myself for hwcontext_cuda

[Timo Rothenpieler]

---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index d1e487a..3570253 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -78,6 +78,7 @@ Other:
   eval.c, eval.hMichael Niedermayer
   float_dsp Loren Merritt
   hash  Reimar Doeffinger
+  hwcontext_cuda*   Timo Rothenpieler
   intfloat* Michael Niedermayer
   integer.c, integer.h  Michael Niedermayer
   lzo   Reimar Doeffinger
-- 
2.10.0

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

[FFmpeg-devel] [PATCH 1/2] avutil/hwcontext_cuda: align allocated frames

[Timo Rothenpieler]

---
 libavutil/hwcontext_cuda.c | 43 ---
 1 file changed, 28 insertions(+), 15 deletions(-)

diff --git a/libavutil/hwcontext_cuda.c b/libavutil/hwcontext_cuda.c
index 40d2971..706d195 100644
--- a/libavutil/hwcontext_cuda.c
+++ b/libavutil/hwcontext_cuda.c
@@ -16,6 +16,8 @@
  * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
  */
 
+#include "libavutil/intmath.h"
+
 #include "buffer.h"
 #include "common.h"
 #include "hwcontext.h"
@@ -35,6 +37,14 @@ static const enum AVPixelFormat supported_formats[] = {
 AV_PIX_FMT_YUV444P,
 };
 
+static unsigned int next_pow2(unsigned int a)
+{
+if (a <= 1)
+return 1;
+a = 1 << (sizeof(a) * 8 - ff_clz(a - 1));
+return FFALIGN(a, 256);
+}
+
 static void cuda_buffer_free(void *opaque, uint8_t *data)
 {
 AVHWFramesContext *ctx = opaque;
@@ -83,6 +93,7 @@ fail:
 static int cuda_frames_init(AVHWFramesContext *ctx)
 {
 CUDAFramesContext *priv = ctx->internal->priv;
+int aligned_width = next_pow2(ctx->width);
 int i;
 
 for (i = 0; i < FF_ARRAY_ELEMS(supported_formats); i++) {
@@ -103,10 +114,10 @@ static int cuda_frames_init(AVHWFramesContext *ctx)
 switch (ctx->sw_format) {
 case AV_PIX_FMT_NV12:
 case AV_PIX_FMT_YUV420P:
-size = ctx->width * ctx->height * 3 / 2;
+size = aligned_width * ctx->height * 3 / 2;
 break;
 case AV_PIX_FMT_YUV444P:
-size = ctx->width * ctx->height * 3;
+size = aligned_width * ctx->height * 3;
 break;
 }
 
@@ -120,6 +131,8 @@ static int cuda_frames_init(AVHWFramesContext *ctx)
 
 static int cuda_get_buffer(AVHWFramesContext *ctx, AVFrame *frame)
 {
+int aligned_width = next_pow2(ctx->width);
+
 frame->buf[0] = av_buffer_pool_get(ctx->pool);
 if (!frame->buf[0])
 return AVERROR(ENOMEM);
@@ -127,25 +140,25 @@ static int cuda_get_buffer(AVHWFramesContext *ctx, 
AVFrame *frame)
 switch (ctx->sw_format) {
 case AV_PIX_FMT_NV12:
 frame->data[0] = frame->buf[0]->data;
-frame->data[1] = frame->data[0] + ctx->width * ctx->height;
-frame->linesize[0] = ctx->width;
-frame->linesize[1] = ctx->width;
+frame->data[1] = frame->data[0] + aligned_width * ctx->height;
+frame->linesize[0] = aligned_width;
+frame->linesize[1] = aligned_width;
 break;
 case AV_PIX_FMT_YUV420P:
 frame->data[0] = frame->buf[0]->data;
-frame->data[2] = frame->data[0] + ctx->width * ctx->height;
-frame->data[1] = frame->data[2] + ctx->width * ctx->height / 4;
-frame->linesize[0] = ctx->width;
-frame->linesize[1] = ctx->width / 2;
-frame->linesize[2] = ctx->width / 2;
+frame->data[2] = frame->data[0] + aligned_width * ctx->height;
+frame->data[1] = frame->data[2] + aligned_width * ctx->height / 4;
+frame->linesize[0] = aligned_width;
+frame->linesize[1] = aligned_width / 2;
+frame->linesize[2] = aligned_width / 2;
 break;
 case AV_PIX_FMT_YUV444P:
 frame->data[0] = frame->buf[0]->data;
-frame->data[1] = frame->data[0] + ctx->width * ctx->height;
-frame->data[2] = frame->data[1] + ctx->width * ctx->height;
-frame->linesize[0] = ctx->width;
-frame->linesize[1] = ctx->width;
-frame->linesize[2] = ctx->width;
+frame->data[1] = frame->data[0] + aligned_width * ctx->height;
+frame->data[2] = frame->data[1] + aligned_width * ctx->height;
+frame->linesize[0] = aligned_width;
+frame->linesize[1] = aligned_width;
+frame->linesize[2] = aligned_width;
 break;
 default:
 av_frame_unref(frame);
-- 
2.10.0

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

[FFmpeg-devel] [PATCH] lavc: set best effort timestamp if unset when using new decode API

[wm4]

Some API users (in particular ffmpeg.c) check the best effort timestamp
only.
---
Still undecided if this is the right approach.
---
 libavcodec/utils.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index ef3da65..1875a69 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -2867,7 +2867,12 @@ int attribute_align_arg 
avcodec_receive_frame(AVCodecContext *avctx, AVFrame *fr
 if (avctx->codec->receive_frame) {
 if (avctx->internal->draining && !(avctx->codec->capabilities & 
AV_CODEC_CAP_DELAY))
 return AVERROR_EOF;
-return avctx->codec->receive_frame(avctx, frame);
+ret = avctx->codec->receive_frame(avctx, frame);
+if (ret >= 0) {
+if (av_frame_get_best_effort_timestamp(frame) == AV_NOPTS_VALUE)
+av_frame_set_best_effort_timestamp(frame, frame->pkt_pts);
+}
+return ret;
 }
 
 // Emulation via old API.
-- 
2.9.3

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

Re: [FFmpeg-devel] [PATCH] ffmpeg: remove unused and errorneous AVFrame timestamp check

[wm4]

On Sat,  1 Oct 2016 16:15:45 +0200
Hendrik Leppkes  wrote:

> Decoders have previously not used AVFrame.pts, and with the upcoming
> deprecation of pkt_pts (in favor of pts), this would lead to an errorneous
> interpration of timestamps.
> ---
>  ffmpeg.c | 7 +--
>  1 file changed, 1 insertion(+), 6 deletions(-)
> 
> diff --git a/ffmpeg.c b/ffmpeg.c
> index 9a8e65a..cdbf3d4 100644
> --- a/ffmpeg.c
> +++ b/ffmpeg.c
> @@ -2058,12 +2058,7 @@ static int decode_audio(InputStream *ist, AVPacket 
> *pkt, int *got_output)
>  }
>  }
>  
> -/* if the decoder provides a pts, use it instead of the last packet pts.
> -   the decoder could be delaying output by a packet or more. */
> -if (decoded_frame->pts != AV_NOPTS_VALUE) {
> -ist->dts = ist->next_dts = ist->pts = ist->next_pts = 
> av_rescale_q(decoded_frame->pts, avctx->time_base, AV_TIME_BASE_Q);
> -decoded_frame_tb   = avctx->time_base;
> -} else if (decoded_frame->pkt_pts != AV_NOPTS_VALUE) {
> +if (decoded_frame->pkt_pts != AV_NOPTS_VALUE) {
>  decoded_frame->pts = decoded_frame->pkt_pts;
>  decoded_frame_tb   = ist->st->time_base;
>  } else if (pkt->pts != AV_NOPTS_VALUE) {

Seems fine to me. No decoder should ever have set the pts field
before. (Forgot to reply earlier.)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] libavformat/bink.c: fix warning due to misleading indentation

[Adriano Pallavicino]

From 78821da34356c1700695f19923e4e8b130b96963 Mon Sep 17 00:00:00 2001
From: Adriano Pallavicino 
Date: Sun, 2 Oct 2016 18:16:21 +0200
Subject: [PATCH] Fix warning: [-Wmisleading-indentation] bink.c
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

This is output of gcc:

libavformat/bink.c:68:9: warning: this ‘if’ clause does not guard... [-Wmisleading-indentation]
 if (((b[0] == 'B' && b[1] == 'I' && b[2] == 'K' &&
 ^~
libavformat/bink.c:77:13: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the ‘if’
 b += SMUSH_BLOCK_SIZE;

 Changes to be committed:
	modified:   libavformat/bink.c

Signed-off-by: Adriano Pallavicino 
---
 libavformat/bink.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/bink.c b/libavformat/bink.c
index c214eb3..e6f0cb7 100644
--- a/libavformat/bink.c
+++ b/libavformat/bink.c
@@ -74,7 +74,7 @@ static int probe(AVProbeData *p)
 AV_RL32(b+24) > 0 && AV_RL32(b+24) <= BINK_MAX_HEIGHT &&
 AV_RL32(b+28) > 0 && AV_RL32(b+32) > 0)  // fps num,den
 return AVPROBE_SCORE_MAX;
-b += SMUSH_BLOCK_SIZE;
+b += SMUSH_BLOCK_SIZE;
 } while (smush && b < p->buf + p->buf_size - 32);
 return 0;
 }
-- 
2.7.4

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

Re: [FFmpeg-devel] [PATCH] ffmpeg: remove unused and errorneous AVFrame timestamp check

[Hendrik Leppkes]

On Sat, Oct 1, 2016 at 4:15 PM, Hendrik Leppkes  wrote:
> Decoders have previously not used AVFrame.pts, and with the upcoming
> deprecation of pkt_pts (in favor of pts), this would lead to an errorneous
> interpration of timestamps.
> ---
>  ffmpeg.c | 7 +--
>  1 file changed, 1 insertion(+), 6 deletions(-)
>
> diff --git a/ffmpeg.c b/ffmpeg.c
> index 9a8e65a..cdbf3d4 100644
> --- a/ffmpeg.c
> +++ b/ffmpeg.c
> @@ -2058,12 +2058,7 @@ static int decode_audio(InputStream *ist, AVPacket 
> *pkt, int *got_output)
>  }
>  }
>
> -/* if the decoder provides a pts, use it instead of the last packet pts.
> -   the decoder could be delaying output by a packet or more. */
> -if (decoded_frame->pts != AV_NOPTS_VALUE) {
> -ist->dts = ist->next_dts = ist->pts = ist->next_pts = 
> av_rescale_q(decoded_frame->pts, avctx->time_base, AV_TIME_BASE_Q);
> -decoded_frame_tb   = avctx->time_base;
> -} else if (decoded_frame->pkt_pts != AV_NOPTS_VALUE) {
> +if (decoded_frame->pkt_pts != AV_NOPTS_VALUE) {
>  decoded_frame->pts = decoded_frame->pkt_pts;
>  decoded_frame_tb   = ist->st->time_base;
>  } else if (pkt->pts != AV_NOPTS_VALUE) {
> --

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

Re: [FFmpeg-devel] [PATCH] libavcodec/qdm2.c: fix warning due to misleading indentation

[Adriano Pallavicino]

You are welcome

2016-09-28 13:54 GMT+02:00 Josh de Kock :

> On 27/09/2016 23:11, Josh de Kock wrote:
>
>> On 27/09/2016 20:47, Adriano Pallavicino wrote:
>>
>>> Sure
>>>
>>> Adriano
>>>
>>>
>> This patch looks good to me, just going to give it a little time for
>> others to comment.
>>
>> Thanks, applied.
>
>
> --
> Josh
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] avformat/tee: Add FATE tests for tee

[Jan Sebechlebsky]

On 09/29/2016 12:49 AM, sebechlebsky...@gmail.com wrote:


From: Jan Sebechlebsky 

This commit also adds new diff option for fate tests allowing do compare
multiple tuples of files.

Signed-off-by: Jan Sebechlebsky 
---
  tests/Makefile|  1 +
  tests/fate-run.sh |  7 
  tests/fate/tee-muxer.mak  | 22 ++
  tests/ref/fate/tee-muxer-h264 |  2 +
  tests/ref/fate/tee-muxer-h264-audio   | 30 +
  tests/ref/fate/tee-muxer-h264-copy| 47 +
  tests/ref/fate/tee-muxer-ignorefail   | 79 +++
  tests/ref/fate/tee-muxer-tstsrc   |  2 +
  tests/ref/fate/tee-muxer-tstsrc-audio | 49 ++
  9 files changed, 239 insertions(+)
  create mode 100644 tests/fate/tee-muxer.mak
  create mode 100644 tests/ref/fate/tee-muxer-h264
  create mode 100644 tests/ref/fate/tee-muxer-h264-audio
  create mode 100644 tests/ref/fate/tee-muxer-h264-copy
  create mode 100644 tests/ref/fate/tee-muxer-ignorefail
  create mode 100644 tests/ref/fate/tee-muxer-tstsrc
  create mode 100644 tests/ref/fate/tee-muxer-tstsrc-audio

[...]

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

[FFmpeg-devel] [PATCH] libavfilter/vf_paletteuse.c: fix warning due to misleading indentation

[Adriano Pallavicino]

From 93fe2a96d71ac219915ade0a9247e1ae4b931a27 Mon Sep 17 00:00:00 2001
From: Adriano Pallavicino 
Date: Sun, 2 Oct 2016 17:52:12 +0200
Subject: [PATCH] =?UTF-8?q?Fix=20warning:=20this=20=E2=80=98if=E2=80=99=20?=
 =?UTF-8?q?clause=20does=20not=20guard...=20[-Wmisleading-indentation]?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

 Please enter the commit message for your changes. Lines starting
 with '#' will be ignored, and an empty message aborts the commit.
 On branch fix_if_clause
 Changes to be committed:
	modified:   libavfilter/vf_paletteuse.c
---
 libavfilter/vf_paletteuse.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavfilter/vf_paletteuse.c b/libavfilter/vf_paletteuse.c
index e063ff7..75d80d6 100644
--- a/libavfilter/vf_paletteuse.c
+++ b/libavfilter/vf_paletteuse.c
@@ -444,7 +444,7 @@ static av_always_inline int set_frame(PaletteUseContext *s, AVFrame *out, AVFram
 if (down) {
 if (left2)  src[  src_linesize + x - 2] = dither_color(src[  src_linesize + x - 2], er, eg, eb, 1, 4);
 if (left)   src[  src_linesize + x - 1] = dither_color(src[  src_linesize + x - 1], er, eg, eb, 2, 4);
-src[  src_linesize + x] = dither_color(src[  src_linesize + x], er, eg, eb, 3, 4);
+src[  src_linesize + x] = dither_color(src[  src_linesize + x], er, eg, eb, 3, 4);
 if (right)  src[  src_linesize + x + 1] = dither_color(src[  src_linesize + x + 1], er, eg, eb, 2, 4);
 if (right2) src[  src_linesize + x + 2] = dither_color(src[  src_linesize + x + 2], er, eg, eb, 1, 4);
 }
-- 
2.7.4

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

Re: [FFmpeg-devel] [PATCH] configure: define posix source on cygwin

[Timo Rothenpieler]

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

[FFmpeg-devel] [PATCH] added possibility to set first to ninth audio language for RIFF taged files (e.g. avi files)

[floriandiemer]

---
According to this page 
(http://www.sno.phy.queensu.ca/~phil/exiftool/TagNames/RIFF.html#Info) 
it is possible
to add language information ("IAS1" (first language) to "IAS9" (ninth 
language)) to RIFF tagged files (as RIFF Info Tags).
Programs such as VLC media player or MediaInfo can properly read and 
display this information. Allowing to set this tags

with the -metadata option while encoding, would simplify the process.
---
libavformat/riffenc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libavformat/riffenc.c b/libavformat/riffenc.c
index 36e6ac7..4b25c06 100644
--- a/libavformat/riffenc.c
+++ b/libavformat/riffenc.c
@@ -304,7 +304,8 @@ void ff_riff_write_info_tag(AVIOContext *pb, const 
char *tag, const char *str)

}

static const char riff_tags[][5] = {
- "IARL", "IART", "ICMS", "ICMT", "ICOP", "ICRD", "ICRP", "IDIM", "IDPI",
+ "IARL", "IART", "IAS1", "IAS2", "IAS3", "IAS4", "IAS5", "IAS6", "IAS7",
+ "IAS8", "IAS9", "ICMS", "ICMT", "ICOP", "ICRD", "ICRP", "IDIM", "IDPI",
"IENG", "IGNR", "IKEY", "ILGT", "ILNG", "IMED", "INAM", "IPLT", "IPRD",
"IPRT", "ITRK", "ISBJ", "ISFT", "ISHP", "ISMP", "ISRC", "ISRF", "ITCH",
{ 0 }
--
2.10.0.windows.1

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

Re: [FFmpeg-devel] [PATCH 1/2] ffplay: use decoder avctx for decoded subtitle width/height

[Marton Balint]

On Sat, 1 Oct 2016, Josh de Kock wrote:


On 01/10/2016 17:17, Marton Balint wrote:

Fixes ticket #5873.

Signed-off-by: Marton Balint 
---
 ffplay.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/ffplay.c b/ffplay.c
index e64909a..a7a6785 100644
--- a/ffplay.c
+++ b/ffplay.c
@@ -2224,7 +2224,6 @@ static int video_thread(void *arg)
 static int subtitle_thread(void *arg)
 {
 VideoState *is = arg;
-AVCodecParameters *codecpar = is->subtitle_st->codecpar;
 Frame *sp;
 int got_subtitle;
 double pts;
@@ -2243,8 +2242,8 @@ static int subtitle_thread(void *arg)
 pts = sp->sub.pts / (double)AV_TIME_BASE;
 sp->pts = pts;
 sp->serial = is->subdec.pkt_serial;
-sp->width = codecpar->width;
-sp->height = codecpar->height;
+sp->width = is->subdec.avctx->width;
+sp->height = is->subdec.avctx->height;
 sp->uploaded = 0;

 /* now we can update the picture count */



Feels backwards to go to a avctx from codecpar, but if it fixes 5873 
then it's fine, it can always be changed back again in the future--so LGTM.




Pushed both patches, thanks.

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

Re: [FFmpeg-devel] lurking bugs in the mmx-related assembler code (?)

[Carl Eugen Hoyos]

2016-10-02 9:27 GMT+02:00  :

> I do not expect that the ffmpeg developers take the trouble
> to install an extra build environment with a different libc,

(If I could just understand this sentence: Is it meant as
an insult? How do you expect the issue to be fixed? By
looking at the code? Seriously?)

I can confirm that there is an issue with current musl,
it is (for example) reproducible by calling
libavutil/tests/pixelutils which crashes every time and I
can confirm that adding an emms() call to av_free()
fixes the issue.

Carl Eugen

PS: There are several unrelated build issues. Either
they only happen here (which I consider unlikely) or
there is an - unknown - reason why the OP decided
not to tell us about those.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH v2] doc/t2h: use container

[Josh de Kock]

Full width text is really difficult to read, this makes it more
more legible on larger (widescreen) screens. It also means we aren't
inventing our own container instead of using the bootstrap one.

Signed-off-by: Josh de Kock 
---
 doc/t2h.init | 2 +-
 doc/t2h.pm   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/doc/t2h.init b/doc/t2h.init
index c41be2e..a01a971 100644
--- a/doc/t2h.init
+++ b/doc/t2h.init
@@ -22,7 +22,7 @@ EOT
 my $TEMPLATE_HEADER2 = $ENV{"FFMPEG_HEADER2"} || <

Re: [FFmpeg-devel] [PATCH] doc/t2h: add max-width to css.

[Nicolas George]

Le primidi 11 vendémiaire, an CCXXV, Josh de Kock a écrit :
> Not really.

Absolutely.

> The containers should not change size depending on the font size.

The issue at hand is not about "containers" or whatever, it is about the
max-width property, in order, quoting yourself, to make things "more legible
on larger (widescreen) screens".

The problem with long lines and readability is that the eye loses alignment
when scanning the text, especially when going from the end of a ling to the
beginning of the next.

This is caused by the length of the line in terms of words and characters,
not by its number of pixels nor its size in physical units.

Can you tell how many characters fit in 960 pixels? Definitely not, since it
depends on users settings that you have no control over. Therefore, using
pixels for max-width is wrong. Furthermore, designs that do not respect
these user settings or misbehave when they have a non-default value are
incorrect.

>   It results
> in really ugly, fairly undefined behavior. I made an example to illustrate
> this: https://codepen.io/anon/pen/ozGqEj

Relying on WYSIWYG tools for web design usually result in bogus stylesheets
that look nice on your particular settings and misbehave badly with unusual
settings.

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] doc/t2h: add max-width to css.

[Nicolas George]

Le primidi 11 vendémiaire, an CCXXV, Josh de Kock a écrit :
> Using max-width: 960px is common practice,

Yet still bad practice.

>and since pixels are generally
> not 1:1 but scaled with regards to DPI, rather than text-size it results in
> a more constant layout across environments.

Indeed: most web designers are idiots, they used pixels all over the place,
forcing browsers authors to step in and work around their bad design. As a
consequence, the few web designers who are not idiots and have a good reason
to use pixels at some place have a hard time.

And it does not address the problem of user-mandated font sizes.

CSS did include from the start a mechanism to make design independent from
the resolution and font size: expressing length in ems. It still works,
still better than the workaround.

Since you are not an idiot, you will use it.

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] lurking bugs in the mmx-related assembler code (?)

[Ronald S. Bultje]

Hi,

On Sun, Oct 2, 2016 at 2:17 AM,  wrote:

> Hello Henrik,
>
> On Sun, Oct 02, 2016 at 01:18:29AM +0200, Henrik Gramner wrote:
> > Ensuring that emms is issued before every single libc function call is
> > likely problematic.
> >
> > What if we simply document the requirement that C standard library
> > functions are assumed to not modify the x87 FPU state unless
> > specifically designated to handle floating-point numbers?
>
> Is it remarkably expensive to reset the FPU state?


Yes.


> (I am unsure
> also how much of the assembler code depends on clobbering it?)
> If yes, then such documentation would be a reasonable approach.


I would advocate for this approach.

I also think we could contact musl developers and see what's going on
there. We certainly shouldn't blindly fix this bug by adding an emms in a
random place, to me that's like opening pandora's box.

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

Re: [FFmpeg-devel] lurking bugs in the mmx-related assembler code (?)

[wm4]

On Sun, 2 Oct 2016 02:25:30 +0200
Michael Niedermayer  wrote:

> On Sun, Oct 02, 2016 at 01:18:29AM +0200, Henrik Gramner wrote:
> > Ensuring that emms is issued before every single libc function call is
> > likely problematic.  
> 
> maybe, maybe not, iam not sure but
> calling emms between init/de/reinint and optimized inner loops should
> be doable, we generally shouldnt be doing malloc in highly optimized
> loops as factorizing allocation out and reusing buffers is likely
> a better choice

+1 for not leaving the C environment and the FPU in a broken state.

> beyond malloc() what else is there ?
> 
> string functions ?
> these are in fact not unlikely to use SIMD of some sort
> same for memcpy/move()
> 
> also there are callbacks like av_log() we should document any
> requirements that apply to them or ensure no such requirements exist
> 
> exact backtraces of where issues occur would be interesting to better
> understand how much code is affected by this
> 
> 
> > 
> > What if we simply document the requirement that C standard library
> > functions are assumed to not modify the x87 FPU state unless
> > specifically designated to handle floating-point numbers?  
> 
> thats like saying that we require undefined behavior to be defined
> in a specific way. We can do this but thats like saying we support
> only a subset of POSIX platforms and that subset could shrink at
> any time if implementations change
> 
> I think our first choice should be to comply to specs where its
> needed in practice and doable.
> when its not useful in practice and a total unreadable mess if done
> i would tend suggest to ignore specs. 
> 
> If all else fails we could add a emms call behind #if in
> av_malloc() and detect affected libcs but thats IMHO a ugly hack
> but better than declaring "non support"
> 

Yes, that would be a very ugly hack that should be avoided.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] lurking bugs in the mmx-related assembler code (?)

[u-h8zb]

Thanks Michael,

On Sun, Oct 02, 2016 at 02:25:30AM +0200, Michael Niedermayer wrote:
> beyond malloc() what else is there ?
> 
> string functions ?
> these are in fact not unlikely to use SIMD of some sort
> same for memcpy/move()
> 
> also there are callbacks like av_log() we should document any
> requirements that apply to them or ensure no such requirements exist
> 
> exact backtraces of where issues occur would be interesting to better
> understand how much code is affected by this

Regarding backtraces of the ill effects, I made an effort when I earlier
hit the same issue with libtheora (the fpu corruption seemed to affect
consistency in picking malloc buckets). The noticeable problems happened
with a delay, eventually causing accesses to quite random places in the
address space, often without any troubles for a while. Hideous and out
of the application code, it is the libc which must be carefully traced.

As for how much of ffmpeg code is affected, I can't tell.
The vp3/theora decoder is certainly in this group but there may be more.
The exact place where the corruption happens is hard to point out,
this depends too much on the particular situation.

> > What if we simply document the requirement that C standard library
> > functions are assumed to not modify the x87 FPU state unless
> > specifically designated to handle floating-point numbers?
> 
> thats like saying that we require undefined behavior to be defined
> in a specific way. We can do this but thats like saying we support
> only a subset of POSIX platforms and that subset could shrink at
> any time if implementations change

Exactly.

> If all else fails we could add a emms call behind #if in
> av_malloc() and detect affected libcs but thats IMHO a ugly hack
> but better than declaring "non support"

This would help to somewhat boost performance on those libraries and
versions which e.g. are known not to touch fpu, but I wonder if this
gain is worth the trouble.

Thanks again.

I hope you find a reasonable solution, without undue complication of
the code and preserving the performance.

Regards,
Rune

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

[FFmpeg-devel] [PATCH 2/5] af_hdcd: support s16p (WavPack) directly

[Burt P]

The buffer is already being copied anyway, so interlace the planar
format during the copy and remove one use of auto-convert.

Signed-off-by: Burt P 
---
 libavfilter/af_hdcd.c | 15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/libavfilter/af_hdcd.c b/libavfilter/af_hdcd.c
index a9f2f93..90b6b64 100644
--- a/libavfilter/af_hdcd.c
+++ b/libavfilter/af_hdcd.c
@@ -1665,10 +1665,18 @@ static int filter_frame(AVFilterLink *inlink, AVFrame 
*in)
 }
 out->format = outlink->format; // is this needed?
 
-in_data  = (int16_t*)in->data[0];
 out_data = (int32_t*)out->data[0];
-for (c = n = 0; n < in->nb_samples * in->channels; n++)
-out_data[n] = in_data[n];
+if (inlink->format == AV_SAMPLE_FMT_S16P) {
+for (n = 0; n < in->nb_samples; n++)
+for (c = 0; c < in->channels; c++) {
+in_data = (int16_t*)in->extended_data[c];
+out_data[(n * in->channels) + c] = in_data[n];
+}
+} else {
+in_data  = (int16_t*)in->data[0];
+for (n = 0; n < in->nb_samples * in->channels; n++)
+out_data[n] = in_data[n];
+}
 
 if (s->process_stereo) {
 hdcd_detect_start(>detect);
@@ -1707,6 +1715,7 @@ static int query_formats(AVFilterContext *ctx)
 
 static const enum AVSampleFormat sample_fmts_in[] = {
 AV_SAMPLE_FMT_S16,
+AV_SAMPLE_FMT_S16P,
 AV_SAMPLE_FMT_NONE
 };
 static const enum AVSampleFormat sample_fmts_out[] = {
-- 
2.7.4

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

[FFmpeg-devel] Alternate HDCD format/rate support

[Burt P]

According to the Users' Manual, the PM Model Two would encode 
HDCD in any CD or DVD-Audio sampler rates, and at 16, 20, or 
24-bit output. While HDCD was (afaik) only published on CD, and
therefor 16-bit@44100Hz, audio may exist in any other other formats
supported by the encoding equipment, so I've made an effort support them.

At the end of this set, auto-convert is disabled, as now the filter will
handle any format that might ligitimately have HDCD encoding. This was
requested by Nicolas George in an earlier conversation referenced in the
last patch's commit message.

Thanks for comments.
---
Burt


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

[FFmpeg-devel] [PATCH 1/5] af_hdcd: allow all HDCD sample rates

[Burt P]

The PM Model Two could output HDCD-encoded audio in CD and all
DVD-Audio sample rates. (44100, 48000, 88200, 96000, 176400, and
192000 Hz)

Signed-off-by: Burt P 
---
 libavfilter/af_hdcd.c | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/libavfilter/af_hdcd.c b/libavfilter/af_hdcd.c
index 40dba3c..a9f2f93 100644
--- a/libavfilter/af_hdcd.c
+++ b/libavfilter/af_hdcd.c
@@ -1693,9 +1693,14 @@ static int filter_frame(AVFilterLink *inlink, AVFrame 
*in)
 
 static int query_formats(AVFilterContext *ctx)
 {
+static const int sample_rates[] = {
+44100, 48000,
+88200, 96000,
+176400, 192000,
+-1
+};
 AVFilterFormats *in_formats;
 AVFilterFormats *out_formats;
-AVFilterFormats *sample_rates = NULL;
 AVFilterChannelLayouts *layouts = NULL;
 AVFilterLink *inlink  = ctx->inputs[0];
 AVFilterLink *outlink = ctx->outputs[0];
@@ -1730,11 +1735,8 @@ static int query_formats(AVFilterContext *ctx)
 if (ret < 0)
 return ret;
 
-ret = ff_add_format(_rates, 44100);
-if (ret < 0)
-return AVERROR(ENOMEM);
-
-return ff_set_common_samplerates(ctx, sample_rates);
+return
+ff_set_common_samplerates(ctx, ff_make_format_list(sample_rates) );
 }
 
 static av_cold void uninit(AVFilterContext *ctx)
-- 
2.7.4

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

Re: [FFmpeg-devel] lurking bugs in the mmx-related assembler code (?)

[u-h8zb]

Hello Carl Eugen,

On Sun, Oct 02, 2016 at 03:05:13AM +0200, Carl Eugen Hoyos wrote:
> 2016-10-01 19:48 GMT+02:00  :
> > I do not expect the ffmpeg developers to try to reproduce this.
> 
> (Would you mind explaining this sentence to me? I
> do not understand it.)

I do not expect that the ffmpeg developers take the trouble
to install an extra build environment with a different libc,
just to confirm a fact which is pretty evident when looking
at the code.

> > I expect somebody to look at the code (beginning with the
> > MMX assembler in the vp3 decoder), which is a lower
> > threshold than building a new libc.
> 
> Either you know a lot of things that nobody on this list
> knows or you have very little clue about FFmpeg
> development.

It is safe to assume that the knowledge varies a lot :)
and indeed it has been quite some time since i added code
to ffmpeg.

But discussing personal qualities is not the topic of this thread.

> The expected route if trac is down (but also if
> you don't want to use it) is to send an email to
> the user mailing list.

This discussion is about ffmpeg internal details, not about its usage,
so why go to the wrong forum?

> >  ffmpeg -i test.640x480.19seconds.theora.ogg
> > -c:v libtheora -y test.out.ogg
> 
> Missing console output and backtrace, please do
> not use external libraries unless they are necessary
> to reproduce the issue.

I am aware of the general rules and why/when they make sense.

Is there anybody on this lilst who builds ffmpeg against musl?
If there were, the problem would be noticed and hopefully fixed.
If there is none, nobody here will be able to make sense of my console output.

I am contributing the result of the analysis:

 the assumptions in the mmx-related assembler code in ffmpeg are
 not fulfilled in a real world scenario and they do not conform
 to what standards say

You do not have to reproduce my builds to confirm or deny this. Some
replies have apparently confirmed the situation.

The rest is up to the maintainers of that code.

Regards,
Rune

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

Re: [FFmpeg-devel] lurking bugs in the mmx-related assembler code (?)

[u-h8zb]

On Sat, Oct 01, 2016 at 06:25:29PM -0400, Ronald S. Bultje wrote:
> > We are not talking about what you and me "would like inside a standard
> > library" but whether we can rely on the specified interfaces. The
> > malloc() interface was apparently misunderstood as a promise to never
> > do float. There is no such promise.
> 
> Can malloc call sleep() then?

 "Can malloc do XXX?"
If the standard (as of https://en.wikipedia.org/wiki/C_standard_library)
does not prohibit this, then certainly yes.

You do not have any time guarantees on malloc(), if this is
what you meant.

Other implementation details aside, a call to a general purpose malloc()
on a Unix-like system regularly results in a system call and then
your process can pretty well be put to sleep for unspecified time,
by the kernel.

Regards,
Rune

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