Re: [FFmpeg-devel] [PATCH v2] avcodec/nvenc: Include NVENC SDK header

[Matt Oliver]

>
> When running ffmpeg on Debian (main), where these Nvidia blobs
> are not present and not needed (because nouveau is used as driver),
> no component of the operating system, major or not,
> has been distributed with Nvidia's blobs, so the system library
> exception does not apply.
>
> I'm not sure about the situation for Windows.
>

For reference Windows automatically supplies nvidia driver binaries and
keeps them upto date via Windows Update. These drivers are often not as
upto date as the ones supplied directly by nvidia but as far as the system
library debate goes they are still provided by the OS as standard.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Question about av_frame_is_writable

[Paul B Mahol]

On 12/12/15, Jean Delvare  wrote:
> Hi all,
>
> Can av_frame_is_writable() ever return 1, and if so, when?
>
> Context: I am testing corner cases of the delogo filter. To my
> surprise, even for a simple test case such as:
>
> $ ffmpeg -f lavfi -i "color=color=white:size=24x24" -frames:v 1 -vf
> "delogo=7:3:8:8" -f image2 debug.png
>
> av_frame_is_writable() returns 0, which disables direct mode of the
> delogo filter and forces the allocation of a new buffer. My
> understanding was that we were trying to avoid allocation and data copy
> as much as possible, for performance reasons, and with such a simple
> filter graph I can't see why we can't modify the video data in-place.
> Can someone enlighten me?

Non-refcounted frames are never writable. And color source is made of one single
frame which is cloned multiple times.
Use different input file perhaps?

>
> Thanks,
> --
> Jean Delvare
> SUSE L3 Support
> ___
> 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 v2] avcodec/nvenc: Include NVENC SDK header

[Philip Langdale]

On 2015-12-12 20:33, Nicolas George wrote:

Le duodi 22 frimaire, an CCXXIV, Philip Langdale a écrit :
it would be highly illogical to conclude that section 6/7 do not apply 
to
the original code itself and that we need to construct a separate 
entity

that does the combination for it to be licence compliant.


It would be fairly illogical to conclude that any clause in the 
license,
either GPL or LGPL, requires us to worry about the specifics of a file 
we do

not know anything about since it resides on the user's system.

We only have to worry about the files that were used to build the 
binary.


I actually completely agree with you, but I'm trying to make an 
incremental

argument. :-)

The source code that goes into the ffmpeg build is 100% (L)GPL 
compatible,

including the MIT licensed nvEncodeAPI.h. No one doubts that. This code
will dlopen nvenc.so (and the windows equivalent) on the system where it
is run. We do not know if that file exists or what licence that file
is under. It could be the nvidia binary, it could be some hypothetical
GPL reimplementation of the interface or it could rm -rf your 
filesystem.


So, to me, and to you, it seems clear that the combination with 
non(L)GPL
code cannot happen any earlier than when the library is actually 
dlopen'ed.


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

Re: [FFmpeg-devel] [PATCH v2] avcodec/nvenc: Include NVENC SDK header

[Nicolas George]

Le duodi 22 frimaire, an CCXXIV, Andreas Cadhalpun a écrit :
> I don't agree as I have already explained previously.

Fortunately, your arguments have no legal standing.

> Have a look at what some of the proprietary licenses require for distribution
> that has absolutely nothing to do with how the binary was built.

A lot of licenses have crazy and illegal clauses.

> For example, a license could allow distribution only under full moon,
> independently of when the binary was built.

Fortunately, the (L)GPL does not have such a crazy rule.

> Or, to take a more realistic example, the NVIDIA Software License [1] allows
> redistribution of it's software only if it is "designed exclusively for use
> on the Linux or FreeBSD operating systems". That's completely independent
> of where or how the binary was built.

Ditto.

The (L)GPL does not have a rule against distributing a binary that can load
a proprietary file. That would make ffmpeg all but useless, I hope you
realize that, because most of the licenses for the multimedia files
themselves are GPL-incompatible.

Regards,



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] avcodec/nvenc: Include NVENC SDK header

[Nicolas George]

Le duodi 22 frimaire, an CCXXIV, Andreas Cadhalpun a écrit :
> However, the (L)GPL has a rule that allows distribution of a
> binary only together with the complete corresponding source code,
> that also includes the source code of any dynamically loaded
> library needed at run-time.

No, it does not. Dynamically-loaded libraries are not part of the binary.

> Multimedia files are no library of executable code.

Define the difference.

Regards,

-- 
  Nicolas George


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

[FFmpeg-devel] End of the top-posting

[Mats Peterson]

I am happy to announce that I will now be using Alpine instead of the 
Yahoo website for posting to this mailing list, since the accepted policy 
here seems to be bottom-posting only.


Mats

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2] avcodec/nvenc: Include NVENC SDK header

[Nicolas George]

Le duodi 22 frimaire, an CCXXIV, Andreas Cadhalpun a écrit :
> Is in a previous mail.

I looked and did not see it.

> I'm not continuing this silly conversation.
> You can look up the meaning of words in a dictionary.

This has nothing silly. Having the code of a codec interpret the bitstream
of a multimedia file is exactly equivalent to having the processor microcode
or cabled logic interpret the machine language of a library.

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] End of the top-posting

[Mats Peterson]

On Sat, 12 Dec 2015, Nicolas George wrote:


Le duodi 22 frimaire, an CCXXIV, Mats Peterson a écrit :

Now, let's not split hairs. Be happy that I have stopped the top-posting
instead.

Not that I care a lot what you think.


It has not taken you a long time to show your true colors here too.

For the record, this was the guy who started insulting Carl Eugen on the
second or third comment of a trac ticket.

Since the patches are technically bad too, I will ignore these mails from
now on.

Regards,

--
 Nicolas George



The patches WERE technically bad, that's why I fixed them.

Mats

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2] avcodec/nvenc: Include NVENC SDK header

[Andreas Cadhalpun]

On 12.12.2015 13:27, Philip Langdale wrote:
> On 2015-12-12 19:26, Andreas Cadhalpun wrote:
>> Anyway, I think your idea about a license exception would be a good solution.
>> We could add a special exception to nvenc.c, allowing its use with Nvidia's
>> blobs, something like [1]:
>>
>>  In addition, as a special exception, the copyright holders give you
>>  permission to combine this code with free software programs or libraries
>>  that are released under the GNU LGPL and with code included in the standard
>>  release of the CUDA and NVENC libraries under the NVIDIA Software License
>>  (or modified versions of such code, with unchanged license).
>>  You may copy and distribute such a system following the terms of the GNU 
>> LGPL
>>  for this code and the licenses of the other code concerned.
>>
>>  Note that people who make modified versions of this code are not obligated
>>  to grant this special exception for their modified versions; it is their
>>  choice whether to do so. The GNU Lesser General Public License gives
>>  permission to release a modified version without this exception; this
>>  exception also makes it possible to release a modified version which carries
>>  forward this exception.
> 
> This is fair enough,

OK.

> but I want to close out the LGPL conversation. The FAQ
> specifically discusses GPLv2 and GPLv3 and not LGPL, and I'll claim that's 
> because
> it doesn't apply.

I'll claim that's because the text for the LGPL would be mostly duplicated.

> The fact that a third party can take LGPL ffmpeg and combine it
> with proprietary code in certain ways means that clearly we can do so as well.

No, because the LGPL allows this only for a "program that contains no 
derivative of
any portion of the Library". Otherwise anyone could just add proprietary code
to FFmpeg, distribute that and claim it is in accordance with the LGPL.

> it
> would be highly illogical to conclude that section 6/7 do not apply to the 
> original
> code itself and that we need to construct a separate entity that does the 
> combination
> for it to be licence compliant.

No, that's not illogical, that's the core component of the LGPL:
It ensures freedom of the library code, while allowing anyone to use the 
library.

Best regards,
Andreas

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

Re: [FFmpeg-devel] [PATCH v2] avcodec/nvenc: Include NVENC SDK header

[Andreas Cadhalpun]

On 12.12.2015 12:55, Nicolas George wrote:
> Le primidi 21 frimaire, an CCXXIV, Carl Eugen Hoyos a écrit :
>> I am glad we agree that there is no difference (license-wise) if 
>> a library is linked statically, dynamically or via dynamic 
>> loading;-)
> 
> You are, unfortunately, completely wrong. It makes all the difference in the
> world. Static linking is done under the distributor's responsibility while
> dynamic loading (pure dlopen()) happens under the recipient's sole
> responsibility. The only case where dlopen() would cause a license problem
> is if someone wanted to distribute a core dump of the resulting process.

I don't agree as I have already explained previously.

> There is a very simple rule of thumb to apply here: can we build the ffmpeg
> binary on a system without libnvenc.so? If the answer is yes, then there is
> no way the license of libnvenc.so could affect the distribution of the
> binary.

The distribution of the binary is only affected by it's license, not by
made-up rules of thumb. Thus you have to base your arguments on the former,
not the latter.

Have a look at what some of the proprietary licenses require for distribution
that has absolutely nothing to do with how the binary was built.
For example, a license could allow distribution only under full moon,
independently of when the binary was built.

Or, to take a more realistic example, the NVIDIA Software License [1] allows
redistribution of it's software only if it is "designed exclusively for use
on the Linux or FreeBSD operating systems". That's completely independent
of where or how the binary was built.

Best regards,
Andreas


1: http://www.nvidia.com/content/DriverDownload-March2009/licence.php?lang=us
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] End of the top-posting

[Nicolas George]

Le duodi 22 frimaire, an CCXXIV, Mats Peterson a écrit :
> Oh, such a lovely reply.

Too bad you did only take a very small part into account.

What did you not understand in "trimmed interleaved posting"?

Regards,

-- 
  Nicolas George


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

[FFmpeg-devel] Question about av_frame_is_writable

[Jean Delvare]

Hi all,

Can av_frame_is_writable() ever return 1, and if so, when?

Context: I am testing corner cases of the delogo filter. To my
surprise, even for a simple test case such as:

$ ffmpeg -f lavfi -i "color=color=white:size=24x24" -frames:v 1 -vf 
"delogo=7:3:8:8" -f image2 debug.png

av_frame_is_writable() returns 0, which disables direct mode of the
delogo filter and forces the allocation of a new buffer. My
understanding was that we were trying to avoid allocation and data copy
as much as possible, for performance reasons, and with such a simple
filter graph I can't see why we can't modify the video data in-place.
Can someone enlighten me?

Thanks,
-- 
Jean Delvare
SUSE L3 Support
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2] avcodec/nvenc: Include NVENC SDK header

[Andreas Cadhalpun]

On 12.12.2015 10:37, Matt Oliver wrote:
>>
>> When running ffmpeg on Debian (main), where these Nvidia blobs
>> are not present and not needed (because nouveau is used as driver),
>> no component of the operating system, major or not,
>> has been distributed with Nvidia's blobs, so the system library
>> exception does not apply.
>>
>> I'm not sure about the situation for Windows.
>>
> 
> For reference Windows automatically supplies nvidia driver binaries and
> keeps them upto date via Windows Update. These drivers are often not as
> upto date as the ones supplied directly by nvidia but as far as the system
> library debate goes they are still provided by the OS as standard.

Based on that one can probably argue that these are system libraries
on Windows.

Best regards,
Andreas

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

Re: [FFmpeg-devel] [PATCH 1/3] avcodec/aacsbr: Split the env_facs table

[Michael Niedermayer]

On Fri, Dec 11, 2015 at 05:14:55PM +0100, Andreas Cadhalpun wrote:
> On 19.11.2015 14:17, Michael Niedermayer wrote:
> > From: Michael Niedermayer 
> > 
> > This also removes a #ifdef and special case for the fixed point case
> > 
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavcodec/aacsbr.c  |6 +++---
> >  libavcodec/aacsbr_fixed.c|6 +++---
> >  libavcodec/aacsbr_template.c |   42 
> > --
> >  3 files changed, 14 insertions(+), 40 deletions(-)
> 
> This looks good to me, because it makes the code shorter and easier to 
> understand.

applied

thanks

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

In a rich man's house there is no place to spit but his face.
-- Diogenes of Sinope


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] avcodec/nvenc: Include NVENC SDK header

[Andreas Cadhalpun]

On 12.12.2015 11:35, Hendrik Leppkes wrote:
> On Sat, Dec 12, 2015 at 11:25 AM, Andreas Cadhalpun
>  wrote:
>> On 12.12.2015 10:50, Hendrik Leppkes wrote:
>>> We should just add an exception into the license to explicitly allow
>>> using it with the NVIDIA CUDA library and be done with this debate for
>>> ever.
>>
>> That would be an option.
>>
>>> You know that Open-Source has failed when the project itself is
>>> arguing days and days for including a feature on license reasons that
>>> any closed-source app would just write, enable and offer to its users
>>> without a second thought.
>>
>> Please try to take a step back.
>> The "nvenc" feature is already included in FFmpeg, just not enabled by
>> default.
>>
> 
> And not enabled on any distribution, hence 99% of all users don't see
> it or get to use it.

You can't blame distributors for following our license.

Anyway, I think your idea about a license exception would be a good solution.
We could add a special exception to nvenc.c, allowing its use with Nvidia's
blobs, something like [1]:

 In addition, as a special exception, the copyright holders give you
 permission to combine this code with free software programs or libraries
 that are released under the GNU LGPL and with code included in the standard
 release of the CUDA and NVENC libraries under the NVIDIA Software License
 (or modified versions of such code, with unchanged license).
 You may copy and distribute such a system following the terms of the GNU LGPL
 for this code and the licenses of the other code concerned.

 Note that people who make modified versions of this code are not obligated
 to grant this special exception for their modified versions; it is their
 choice whether to do so. The GNU Lesser General Public License gives
 permission to release a modified version without this exception; this
 exception also makes it possible to release a modified version which carries
 forward this exception.

Best regards,
Andreas


1: https://www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleLibs
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2] avcodec/nvenc: Include NVENC SDK header

[Nicolas George]

Le primidi 21 frimaire, an CCXXIV, Carl Eugen Hoyos a écrit :
> I am glad we agree that there is no difference (license-wise) if 
> a library is linked statically, dynamically or via dynamic 
> loading;-)

You are, unfortunately, completely wrong. It makes all the difference in the
world. Static linking is done under the distributor's responsibility while
dynamic loading (pure dlopen()) happens under the recipient's sole
responsibility. The only case where dlopen() would cause a license problem
is if someone wanted to distribute a core dump of the resulting process.

There is a very simple rule of thumb to apply here: can we build the ffmpeg
binary on a system without libnvenc.so? If the answer is yes, then there is
no way the license of libnvenc.so could affect the distribution of the
binary.

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 v2] avcodec/nvenc: Include NVENC SDK header

[Philip Langdale]

On 2015-12-12 19:26, Andreas Cadhalpun wrote:

On 12.12.2015 11:35, Hendrik Leppkes wrote:

On Sat, Dec 12, 2015 at 11:25 AM, Andreas Cadhalpun
 wrote:

On 12.12.2015 10:50, Hendrik Leppkes wrote:

We should just add an exception into the license to explicitly allow
using it with the NVIDIA CUDA library and be done with this debate 
for

ever.


That would be an option.


You know that Open-Source has failed when the project itself is
arguing days and days for including a feature on license reasons 
that
any closed-source app would just write, enable and offer to its 
users

without a second thought.


Please try to take a step back.
The "nvenc" feature is already included in FFmpeg, just not enabled 
by

default.



And not enabled on any distribution, hence 99% of all users don't see
it or get to use it.


You can't blame distributors for following our license.

Anyway, I think your idea about a license exception would be a good 
solution.
We could add a special exception to nvenc.c, allowing its use with 
Nvidia's

blobs, something like [1]:

 In addition, as a special exception, the copyright holders give you
 permission to combine this code with free software programs or 
libraries
 that are released under the GNU LGPL and with code included in the 
standard
 release of the CUDA and NVENC libraries under the NVIDIA Software 
License

 (or modified versions of such code, with unchanged license).
 You may copy and distribute such a system following the terms of the 
GNU LGPL

 for this code and the licenses of the other code concerned.

 Note that people who make modified versions of this code are not 
obligated
 to grant this special exception for their modified versions; it is 
their

 choice whether to do so. The GNU Lesser General Public License gives
 permission to release a modified version without this exception; this
 exception also makes it possible to release a modified version which 
carries

 forward this exception.


This is fair enough, but I want to close out the LGPL conversation. The 
FAQ
specifically discusses GPLv2 and GPLv3 and not LGPL, and I'll claim 
that's because
it doesn't apply. The fact that a third party can take LGPL ffmpeg and 
combine it
with proprietary code in certain ways means that clearly we can do so as 
well. it
would be highly illogical to conclude that section 6/7 do not apply to 
the original
code itself and that we need to construct a separate entity that does 
the combination

for it to be licence compliant.

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

Re: [FFmpeg-devel] Question about av_frame_is_writable

[Jean Delvare]

Hi Paul,

On Sat, 12 Dec 2015 12:03:39 +, Paul B Mahol wrote:
> On 12/12/15, Jean Delvare  wrote:
> > Can av_frame_is_writable() ever return 1, and if so, when?
> >
> > Context: I am testing corner cases of the delogo filter. To my
> > surprise, even for a simple test case such as:
> >
> > $ ffmpeg -f lavfi -i "color=color=white:size=24x24" -frames:v 1 -vf
> > "delogo=7:3:8:8" -f image2 debug.png
> >
> > av_frame_is_writable() returns 0, which disables direct mode of the
> > delogo filter and forces the allocation of a new buffer. My
> > understanding was that we were trying to avoid allocation and data copy
> > as much as possible, for performance reasons, and with such a simple
> > filter graph I can't see why we can't modify the video data in-place.
> > Can someone enlighten me?
> 
> Non-refcounted frames are never writable. And color source is made of one 
> single
> frame which is cloned multiple times.
> Use different input file perhaps?

Thanks for the hint. That makes sense, and if I set the input to a
still picture instead then av_frame_is_writable() indeed returns 1.

However if I add replace "-frames:v 1" with "-loop 1 -frames:v 5",
av_frame_is_writable() still returns 1. I expected the input picture to
be cloned 4 times so it would no longer be writable, given your
explanation above.

Also if I change the input to a MPEG file, av_frame_is_writable()
returns 0 again.

So I still do not fully understand when frames are writable and when
not.

But 

-- 
Jean Delvare
SUSE L3 Support
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] End of the top-posting

[Mats Peterson]

On Sat, 12 Dec 2015, Nicolas George wrote:


Le duodi 22 frimaire, an CCXXIV, Mats Peterson a écrit :

I am happy to announce that I will now be using Alpine instead of the Yahoo


I must admit, I do not care very much what you do with your life. Would you
also tell us what you ate for breakfast?


website for posting to this mailing list, since the accepted policy here
seems to be bottom-posting only.


No. The preferred policy is trimmed interleaved posting. Untrimmed
interleaved posting is tolerated.


--
Mats Peterson


Your signature marker is invalid, it must contain a trailing space.

Regards,

--
 Nicolas George



Oh, such a lovely reply. Thanks for notifying me about the space though, I 
haven't been using mail or news in console for quite a while. Fixed.


--
Mats Peterson
http://matsp888.no-ip.org/~mats/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2] avcodec/nvenc: Include NVENC SDK header

[Nicolas George]

Le duodi 22 frimaire, an CCXXIV, Andreas Cadhalpun a écrit :
> It does.

[citation needed]

> Multimedia files can't be executed, only decoded.

Define the difference.

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] End of the top-posting

[Mats Peterson]

On Sat, 12 Dec 2015, Mats Peterson wrote:


On Sat, 12 Dec 2015, Nicolas George wrote:


Le duodi 22 frimaire, an CCXXIV, Mats Peterson a écrit :

Oh, such a lovely reply.


Too bad you did only take a very small part into account.

What did you not understand in "trimmed interleaved posting"?

Regards,

--
 Nicolas George



Now, let's not split hairs. Be happy that I have stopped the top-posting 
instead.


Mats

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel



Not that I care a lot what you think.

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2] avcodec/nvenc: Include NVENC SDK header

[Andreas Cadhalpun]

On 12.12.2015 10:50, Hendrik Leppkes wrote:
> On Sat, Dec 12, 2015 at 10:39 AM, Andreas Cadhalpun
>  wrote:
>> On 12.12.2015 01:46, Philip Langdale wrote:
>>> On 2015-12-12 00:03, Andreas Cadhalpun wrote:
 On 11.12.2015 09:41, Carl Eugen Hoyos wrote:
> My point is that so far several people have said that if nvenc
> is a system library there is no issue (and I fully agree). I
> didn't see a mail (and even less a patch with a commit message
> that says so) that claims nvenc is a system library (only that
> it "should" be one).

 So let's ask: Is someone here who claims that nvenc is a system
 library and can explain why?
>>>
>>> I'm not going to claim it's a system library.
>>
>> Interesting...
>>
>>> I'm, instead, going to
>>> ask why we're having this conversation about nvenc, when the qsx/mfx
>>> situation is exactly the same.
>>
>> We have this conversation, because someone sent a patch to enable it
>> by default, together with including the header and removing the
>> 'die_license_disabled nonfree nvenc' line.
>>
>>> The functionality is provided by a
>>> proprietary set of modules that are part of the intel driver on windows
>>> and a separate (almost undiscoverable) download on linux (actually,
>>> that's worse than nvenc where the functionality is shipped with the
>>> driver in both cases). The only structural difference is that ffmpeg
>>> links against a wrapper library for mfx and dlopens in the nvenc
>>> case, but because of your following statement, that cannot make any
>>> difference.
>>
>> Since this requires the mfx wrapper to link, it is not enabled by
>> default. As the license situation seems similar, it might be a good idea
>> to add a 'die_license_disabled nonfree libmfx' line. But these don't have
>> any effect on the legal situation anyway, they are just a help
>> for our users.
>>
> I am glad we agree that there is no difference (license-wise) if
> a library is linked statically, dynamically or via dynamic
> loading;-)

 There is that, at least. ;-)
>>>
>>> Oh, and do you know what's funny - I just realised that the primary ffmpeg
>>> code base is LGPL and not GPL, so this whole conversation is slighlty
>>> pointless.
>>
>> No, it's not, because the LGPL and GPL are very similar in terms of the
>> requirements about distributing object code of (L)GPL-ed source code.
>>
>>> Combining ffmpeg with proprietary libraries is covered under section 6 and
>>> section 7,
>>
>> These sections only cover "work that uses the Library" (defined in section 
>> 5),
>> not the Library itself.
>>
>>> so even if building the nvenc codec is considered to combine
>>> ffmpeg with nvenc in this sense, it would be acceptable. The key requirement
>>> is that the LGPL covered parts can be rebuilt and modified as desired, and
>>> that is certainly true.
>>>
>>> These sections are generally thought of as enabling a larger proprietary
>>> program to pull in an LGPL library, but the language is symmetric.
>>
>> No, see section 4:
>> "You may copy and distribute the Library (or a portion or derivative of it,
>> under Section 2) in object code or executable form under the terms of 
>> Sections
>> 1 and 2 above provided that you accompany it with the complete corresponding
>> machine-readable source code"
>>
>>> Note that I actually don't believe with have a GPL problem here,
>>
>> Why?
>>
>>> but as a step forward, if we can all agree that the nvenc codec is a valid
>>> part of an lgpl build of ffmpeg, that's a step forward.
>>
>> I don't agree with that interpretation, see above explanation.
>>
> 
> We should just add an exception into the license to explicitly allow
> using it with the NVIDIA CUDA library and be done with this debate for
> ever.

That would be an option.

> You know that Open-Source has failed when the project itself is
> arguing days and days for including a feature on license reasons that
> any closed-source app would just write, enable and offer to its users
> without a second thought.

Please try to take a step back.
The "nvenc" feature is already included in FFmpeg, just not enabled by
default.

Best regards,
Andreas

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

Re: [FFmpeg-devel] End of the top-posting

[Mats Peterson]

On Sat, 12 Dec 2015, Nicolas George wrote:


Le duodi 22 frimaire, an CCXXIV, Mats Peterson a écrit :

Oh, such a lovely reply.


Too bad you did only take a very small part into account.

What did you not understand in "trimmed interleaved posting"?

Regards,

--
 Nicolas George



Now, let's not split hairs. Be happy that I have stopped the top-posting 
instead.


Mats

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2] avcodec/nvenc: Include NVENC SDK header

[Andreas Cadhalpun]

On 12.12.2015 14:42, Nicolas George wrote:
> Le duodi 22 frimaire, an CCXXIV, Andreas Cadhalpun a écrit :
>> It does.
> 
> [citation needed]

Is in a previous mail.

>> Multimedia files can't be executed, only decoded.
> 
> Define the difference.

I'm not continuing this silly conversation.
You can look up the meaning of words in a dictionary.

Best regards,
Andreas

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

Re: [FFmpeg-devel] [PATCH v2] avcodec/nvenc: Include NVENC SDK header

[Andreas Cadhalpun]

On 12.12.2015 01:46, Philip Langdale wrote:
> On 2015-12-12 00:03, Andreas Cadhalpun wrote:
>> On 11.12.2015 09:41, Carl Eugen Hoyos wrote:
>>> My point is that so far several people have said that if nvenc
>>> is a system library there is no issue (and I fully agree). I
>>> didn't see a mail (and even less a patch with a commit message
>>> that says so) that claims nvenc is a system library (only that
>>> it "should" be one).
>>
>> So let's ask: Is someone here who claims that nvenc is a system
>> library and can explain why?
> 
> I'm not going to claim it's a system library.

Interesting...

> I'm, instead, going to
> ask why we're having this conversation about nvenc, when the qsx/mfx
> situation is exactly the same.

We have this conversation, because someone sent a patch to enable it
by default, together with including the header and removing the
'die_license_disabled nonfree nvenc' line.

> The functionality is provided by a
> proprietary set of modules that are part of the intel driver on windows
> and a separate (almost undiscoverable) download on linux (actually,
> that's worse than nvenc where the functionality is shipped with the
> driver in both cases). The only structural difference is that ffmpeg
> links against a wrapper library for mfx and dlopens in the nvenc
> case, but because of your following statement, that cannot make any
> difference.

Since this requires the mfx wrapper to link, it is not enabled by
default. As the license situation seems similar, it might be a good idea
to add a 'die_license_disabled nonfree libmfx' line. But these don't have
any effect on the legal situation anyway, they are just a help
for our users.

>>> I am glad we agree that there is no difference (license-wise) if
>>> a library is linked statically, dynamically or via dynamic
>>> loading;-)
>>
>> There is that, at least. ;-)
> 
> Oh, and do you know what's funny - I just realised that the primary ffmpeg
> code base is LGPL and not GPL, so this whole conversation is slighlty
> pointless.

No, it's not, because the LGPL and GPL are very similar in terms of the
requirements about distributing object code of (L)GPL-ed source code.

> Combining ffmpeg with proprietary libraries is covered under section 6 and
> section 7,

These sections only cover "work that uses the Library" (defined in section 5),
not the Library itself.

> so even if building the nvenc codec is considered to combine
> ffmpeg with nvenc in this sense, it would be acceptable. The key requirement
> is that the LGPL covered parts can be rebuilt and modified as desired, and
> that is certainly true.
> 
> These sections are generally thought of as enabling a larger proprietary
> program to pull in an LGPL library, but the language is symmetric.

No, see section 4:
"You may copy and distribute the Library (or a portion or derivative of it,
under Section 2) in object code or executable form under the terms of Sections
1 and 2 above provided that you accompany it with the complete corresponding
machine-readable source code"

> Note that I actually don't believe with have a GPL problem here,

Why?

> but as a step forward, if we can all agree that the nvenc codec is a valid
> part of an lgpl build of ffmpeg, that's a step forward.

I don't agree with that interpretation, see above explanation.

Best regards,
Andreas

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

Re: [FFmpeg-devel] [PATCH v2] avcodec/nvenc: Include NVENC SDK header

[Hendrik Leppkes]

On Sat, Dec 12, 2015 at 10:39 AM, Andreas Cadhalpun
 wrote:
> On 12.12.2015 01:46, Philip Langdale wrote:
>> On 2015-12-12 00:03, Andreas Cadhalpun wrote:
>>> On 11.12.2015 09:41, Carl Eugen Hoyos wrote:
 My point is that so far several people have said that if nvenc
 is a system library there is no issue (and I fully agree). I
 didn't see a mail (and even less a patch with a commit message
 that says so) that claims nvenc is a system library (only that
 it "should" be one).
>>>
>>> So let's ask: Is someone here who claims that nvenc is a system
>>> library and can explain why?
>>
>> I'm not going to claim it's a system library.
>
> Interesting...
>
>> I'm, instead, going to
>> ask why we're having this conversation about nvenc, when the qsx/mfx
>> situation is exactly the same.
>
> We have this conversation, because someone sent a patch to enable it
> by default, together with including the header and removing the
> 'die_license_disabled nonfree nvenc' line.
>
>> The functionality is provided by a
>> proprietary set of modules that are part of the intel driver on windows
>> and a separate (almost undiscoverable) download on linux (actually,
>> that's worse than nvenc where the functionality is shipped with the
>> driver in both cases). The only structural difference is that ffmpeg
>> links against a wrapper library for mfx and dlopens in the nvenc
>> case, but because of your following statement, that cannot make any
>> difference.
>
> Since this requires the mfx wrapper to link, it is not enabled by
> default. As the license situation seems similar, it might be a good idea
> to add a 'die_license_disabled nonfree libmfx' line. But these don't have
> any effect on the legal situation anyway, they are just a help
> for our users.
>
 I am glad we agree that there is no difference (license-wise) if
 a library is linked statically, dynamically or via dynamic
 loading;-)
>>>
>>> There is that, at least. ;-)
>>
>> Oh, and do you know what's funny - I just realised that the primary ffmpeg
>> code base is LGPL and not GPL, so this whole conversation is slighlty
>> pointless.
>
> No, it's not, because the LGPL and GPL are very similar in terms of the
> requirements about distributing object code of (L)GPL-ed source code.
>
>> Combining ffmpeg with proprietary libraries is covered under section 6 and
>> section 7,
>
> These sections only cover "work that uses the Library" (defined in section 5),
> not the Library itself.
>
>> so even if building the nvenc codec is considered to combine
>> ffmpeg with nvenc in this sense, it would be acceptable. The key requirement
>> is that the LGPL covered parts can be rebuilt and modified as desired, and
>> that is certainly true.
>>
>> These sections are generally thought of as enabling a larger proprietary
>> program to pull in an LGPL library, but the language is symmetric.
>
> No, see section 4:
> "You may copy and distribute the Library (or a portion or derivative of it,
> under Section 2) in object code or executable form under the terms of Sections
> 1 and 2 above provided that you accompany it with the complete corresponding
> machine-readable source code"
>
>> Note that I actually don't believe with have a GPL problem here,
>
> Why?
>
>> but as a step forward, if we can all agree that the nvenc codec is a valid
>> part of an lgpl build of ffmpeg, that's a step forward.
>
> I don't agree with that interpretation, see above explanation.
>

We should just add an exception into the license to explicitly allow
using it with the NVIDIA CUDA library and be done with this debate for
ever.
You know that Open-Source has failed when the project itself is
arguing days and days for including a feature on license reasons that
any closed-source app would just write, enable and offer to its users
without a second thought.

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

Re: [FFmpeg-devel] [PATCH] matroskadec.c: Handle palettized QuickTime video properly

[Michael Niedermayer]

On Fri, Dec 11, 2015 at 11:32:13AM +, Mats Peterson wrote:
> OK, here is an improved version of my previous patch of matroskadec.c that 
> manages the palette itself without calling code in mov.c. I have borrowed 
> some code from it, though, and I'm including qtpalette.h. One thing I don't 
> understand is why the minimum private data size for V_QUICKTIME has been the 
> mysterioius value 21 so far, since 86 is the minimum size for a video sample 
> description without a palette. So I changed that. As I said before, I have 
> also changed the minimum private data size for A_QUICKTIME from 86 to 36, 
> since 36 is the size of a version 0 sound sample description.
> Mats -- 
> Mats Peterson
> http://matsp888.no-ip.org/~mats/

>  matroskadec.c |   94 
> ++
>  1 file changed, 89 insertions(+), 5 deletions(-)
> 6d1e32a75c7d8de7dfb02756a135ad7855c49b90  matroskadec.c.diff
> --- matroskadec.c.orig2015-12-08 11:01:40.640478749 +0100
> +++ matroskadec.c 2015-12-11 12:00:13.0 +0100

this breaks demuxing of the video stream from
output-ffmpeg-20140109-git-c0a33c4.mkv
(google should find a url for this)


[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The worst form of inequality is to try to make unequal things equal.
-- Aristotle


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

Re: [FFmpeg-devel] [PATCH RFC] avfilter/vf_delogo: Use AVPixFmtDescriptor.nb_components

[Paul B Mahol]

On 12/10/15, Jean Delvare  wrote:
> Relying on AVPixFmtDescriptor.nb_components is cleaner and faster than
> checking data and linesize for every possible plane.
>
> Signed-off-by: Jean Delvare 
> ---
> I see that most filters use AVPixFmtDescriptor.nb_components while
> others still check data and linesize. Am I correct assuming that the
> former is faster and preferred?
>
>  libavfilter/vf_delogo.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- ffmpeg.orig/libavfilter/vf_delogo.c   2015-12-10 13:06:16.212908502 
> +0100
> +++ ffmpeg/libavfilter/vf_delogo.c2015-12-10 13:07:04.877966120 +0100
> @@ -256,7 +256,7 @@ static int filter_frame(AVFilterLink *in
>  if (!sar.num)
>  sar.num = sar.den = 1;
>
> -for (plane = 0; plane < 4 && in->data[plane] && in->linesize[plane];
> plane++) {
> +for (plane = 0; plane < desc->nb_components; plane++) {
>  int hsub = plane == 1 || plane == 2 ? hsub0 : 0;
>  int vsub = plane == 1 || plane == 2 ? vsub0 : 0;
>
>
>
> --
> Jean Delvare
> SUSE L3 Support
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

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

Re: [FFmpeg-devel] [PATCH v2] avcodec/nvenc: Include NVENC SDK header

[Nicolas George]

Le duodi 22 frimaire, an CCXXIV, Philip Langdale a écrit :
> it would be highly illogical to conclude that section 6/7 do not apply to
> the original code itself and that we need to construct a separate entity
> that does the combination for it to be licence compliant.

It would be fairly illogical to conclude that any clause in the license,
either GPL or LGPL, requires us to worry about the specifics of a file we do
not know anything about since it resides on the user's system.

We only have to worry about the files that were used to build the binary.

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 v2] avcodec/nvenc: Include NVENC SDK header

[Andreas Cadhalpun]

On 12.12.2015 14:29, Nicolas George wrote:
> Le duodi 22 frimaire, an CCXXIV, Andreas Cadhalpun a écrit :
>> However, the (L)GPL has a rule that allows distribution of a
>> binary only together with the complete corresponding source code,
>> that also includes the source code of any dynamically loaded
>> library needed at run-time.
> 
> No, it does not.

It does.

> Dynamically-loaded libraries are not part of the binary.

I haven't claimed that.

>> Multimedia files are no library of executable code.
> 
> Define the difference.

You're arguments are getting silly.
Multimedia files can't be executed, only decoded.
Try to convince any judge otherwise.

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

Re: [FFmpeg-devel] [PATCH v2] avcodec/nvenc: Include NVENC SDK header

[Hendrik Leppkes]

On Sat, Dec 12, 2015 at 11:25 AM, Andreas Cadhalpun
 wrote:
> On 12.12.2015 10:50, Hendrik Leppkes wrote:
>> On Sat, Dec 12, 2015 at 10:39 AM, Andreas Cadhalpun
>>  wrote:
>>> On 12.12.2015 01:46, Philip Langdale wrote:
 On 2015-12-12 00:03, Andreas Cadhalpun wrote:
> On 11.12.2015 09:41, Carl Eugen Hoyos wrote:
>> My point is that so far several people have said that if nvenc
>> is a system library there is no issue (and I fully agree). I
>> didn't see a mail (and even less a patch with a commit message
>> that says so) that claims nvenc is a system library (only that
>> it "should" be one).
>
> So let's ask: Is someone here who claims that nvenc is a system
> library and can explain why?

 I'm not going to claim it's a system library.
>>>
>>> Interesting...
>>>
 I'm, instead, going to
 ask why we're having this conversation about nvenc, when the qsx/mfx
 situation is exactly the same.
>>>
>>> We have this conversation, because someone sent a patch to enable it
>>> by default, together with including the header and removing the
>>> 'die_license_disabled nonfree nvenc' line.
>>>
 The functionality is provided by a
 proprietary set of modules that are part of the intel driver on windows
 and a separate (almost undiscoverable) download on linux (actually,
 that's worse than nvenc where the functionality is shipped with the
 driver in both cases). The only structural difference is that ffmpeg
 links against a wrapper library for mfx and dlopens in the nvenc
 case, but because of your following statement, that cannot make any
 difference.
>>>
>>> Since this requires the mfx wrapper to link, it is not enabled by
>>> default. As the license situation seems similar, it might be a good idea
>>> to add a 'die_license_disabled nonfree libmfx' line. But these don't have
>>> any effect on the legal situation anyway, they are just a help
>>> for our users.
>>>
>> I am glad we agree that there is no difference (license-wise) if
>> a library is linked statically, dynamically or via dynamic
>> loading;-)
>
> There is that, at least. ;-)

 Oh, and do you know what's funny - I just realised that the primary ffmpeg
 code base is LGPL and not GPL, so this whole conversation is slighlty
 pointless.
>>>
>>> No, it's not, because the LGPL and GPL are very similar in terms of the
>>> requirements about distributing object code of (L)GPL-ed source code.
>>>
 Combining ffmpeg with proprietary libraries is covered under section 6 and
 section 7,
>>>
>>> These sections only cover "work that uses the Library" (defined in section 
>>> 5),
>>> not the Library itself.
>>>
 so even if building the nvenc codec is considered to combine
 ffmpeg with nvenc in this sense, it would be acceptable. The key 
 requirement
 is that the LGPL covered parts can be rebuilt and modified as desired, and
 that is certainly true.

 These sections are generally thought of as enabling a larger proprietary
 program to pull in an LGPL library, but the language is symmetric.
>>>
>>> No, see section 4:
>>> "You may copy and distribute the Library (or a portion or derivative of it,
>>> under Section 2) in object code or executable form under the terms of 
>>> Sections
>>> 1 and 2 above provided that you accompany it with the complete corresponding
>>> machine-readable source code"
>>>
 Note that I actually don't believe with have a GPL problem here,
>>>
>>> Why?
>>>
 but as a step forward, if we can all agree that the nvenc codec is a valid
 part of an lgpl build of ffmpeg, that's a step forward.
>>>
>>> I don't agree with that interpretation, see above explanation.
>>>
>>
>> We should just add an exception into the license to explicitly allow
>> using it with the NVIDIA CUDA library and be done with this debate for
>> ever.
>
> That would be an option.
>
>> You know that Open-Source has failed when the project itself is
>> arguing days and days for including a feature on license reasons that
>> any closed-source app would just write, enable and offer to its users
>> without a second thought.
>
> Please try to take a step back.
> The "nvenc" feature is already included in FFmpeg, just not enabled by
> default.
>

And not enabled on any distribution, hence 99% of all users don't see
it or get to use it.

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

Re: [FFmpeg-devel] [PATCH] matroskadec.c: Handle palettized QuickTime video properly

[Mats Peterson]

21 is one odd number, to start with. It will make the privata end in the middle 
of the vendor fourcc, which is often 'appl'.


Mats

 -- 
Mats Peterson
http://matsp888.no-ip.org/~mats/


- Original Message -
From: Mats Peterson 
To: FFmpeg development discussions and patches 
Sent: Saturday, December 12, 2015 12:17 PM
Subject: Re: [FFmpeg-devel] [PATCH] matroskadec.c: Handle   palettized  
QuickTime video properly

Obviously that private data is cropped in some way then, since the minimum size 
of a video sample description in QuickTime video is 86 bytes.


Mats

-- 
Mats Peterson
http://matsp888.no-ip.org/~mats/


- Original Message -
From: Michael Niedermayer 
To: FFmpeg development discussions and patches 
Sent: Saturday, December 12, 2015 11:58 AM
Subject: Re: [FFmpeg-devel] [PATCH] matroskadec.c: Handle palettized
QuickTime video properly

On Fri, Dec 11, 2015 at 11:32:13AM +, Mats Peterson wrote:



> OK, here is an improved version of my previous patch of matroskadec.c that 
> manages the palette itself without calling code in mov.c. I have borrowed 
> some code from it, though, and I'm including qtpalette.h. One thing I don't 
> understand is why the minimum private data size for V_QUICKTIME has been the 
> mysterioius value 21 so far, since 86 is the minimum size for a video sample 
> description without a palette. So I changed that. As I said before, I have 
> also changed the minimum private data size for A_QUICKTIME from 86 to 36, 
> since 36 is the size of a version 0 sound sample description.
> Mats -- 
> Mats Peterson
> http://matsp888.no-ip.org/~mats/

>  matroskadec.c |   94 
> ++
>  1 file changed, 89 insertions(+), 5 deletions(-)
> 6d1e32a75c7d8de7dfb02756a135ad7855c49b90  matroskadec.c.diff
> --- matroskadec.c.orig2015-12-08 11:01:40.640478749 +0100
> +++ matroskadec.c2015-12-11 12:00:13.0 +0100

this breaks demuxing of the video stream from
output-ffmpeg-20140109-git-c0a33c4.mkv
(google should find a url for this)


[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The worst form of inequality is to try to make unequal things equal.
-- Aristotle

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



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

Re: [FFmpeg-devel] [PATCH] matroskadec.c: Handle palettized QuickTime video properly

[Mats Peterson]

Sorry for my typos. "Privata" really means "private data" ;)

 
Mats
-- 
Mats Peterson
http://matsp888.no-ip.org/~mats/


- Original Message -
From: Mats Peterson 
To: FFmpeg development discussions and patches 
Sent: Saturday, December 12, 2015 12:22 PM
Subject: Re: [FFmpeg-devel] [PATCH] matroskadec.c:  Handle  palettized  
QuickTime video properly

21 is one odd number, to start with. It will make the privata end in the middle 
of the vendor fourcc, which is often 'appl'.


Mats

-- 
Mats Peterson
http://matsp888.no-ip.org/~mats/


- Original Message -
From: Mats Peterson 
To: FFmpeg development discussions and patches 
Sent: Saturday, December 12, 2015 12:17 PM
Subject: Re: [FFmpeg-devel] [PATCH] matroskadec.c: Handlepalettized
QuickTime video properly

Obviously that private data is cropped in some way then, since the minimum size 
of a video sample description in QuickTime video is 86 bytes.


Mats

-- 
Mats Peterson
http://matsp888.no-ip.org/~mats/


- Original Message -
From: Michael Niedermayer 
To: FFmpeg development discussions and patches 
Sent: Saturday, December 12, 2015 11:58 AM
Subject: Re: [FFmpeg-devel] [PATCH] matroskadec.c: Handle palettized
QuickTime video properly

On Fri, Dec 11, 2015 at 11:32:13AM +, Mats Peterson wrote:



> OK, here is an improved version of my previous patch of matroskadec.c that 
> manages the palette itself without calling code in mov.c. I have borrowed 
> some code from it, though, and I'm including qtpalette.h. One thing I don't 
> understand is why the minimum private data size for V_QUICKTIME has been the 
> mysterioius value 21 so far, since 86 is the minimum size for a video sample 
> description without a palette. So I changed that. As I said before, I have 
> also changed the minimum private data size for A_QUICKTIME from 86 to 36, 
> since 36 is the size of a version 0 sound sample description.
> Mats -- 
> Mats Peterson
> http://matsp888.no-ip.org/~mats/

>  matroskadec.c |   94 
> ++
>  1 file changed, 89 insertions(+), 5 deletions(-)
> 6d1e32a75c7d8de7dfb02756a135ad7855c49b90  matroskadec.c.diff
> --- matroskadec.c.orig2015-12-08 11:01:40.640478749 +0100
> +++ matroskadec.c2015-12-11 12:00:13.0 +0100

this breaks demuxing of the video stream from
output-ffmpeg-20140109-git-c0a33c4.mkv
(google should find a url for this)


[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The worst form of inequality is to try to make unequal things equal.
-- Aristotle

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






___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel 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 v2] avcodec/nvenc: Include NVENC SDK header

[Andreas Cadhalpun]

On 12.12.2015 14:03, Nicolas George wrote:
> Le duodi 22 frimaire, an CCXXIV, Andreas Cadhalpun a écrit :
>> I don't agree as I have already explained previously.
> 
> Fortunately, your arguments have no legal standing.

Neither have yours.

> The (L)GPL does not have a rule against distributing a binary that can load
> a proprietary file.

However, the (L)GPL has a rule that allows distribution of a
binary only together with the complete corresponding source code,
that also includes the source code of any dynamically loaded
library needed at run-time.

> That would make ffmpeg all but useless, I hope you
> realize that, because most of the licenses for the multimedia files
> themselves are GPL-incompatible.

Multimedia files are no library of executable code.

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

Re: [FFmpeg-devel] End of the top-posting

[Nicolas George]

Le duodi 22 frimaire, an CCXXIV, Mats Peterson a écrit :
> I am happy to announce that I will now be using Alpine instead of the Yahoo

I must admit, I do not care very much what you do with your life. Would you
also tell us what you ate for breakfast?

> website for posting to this mailing list, since the accepted policy here
> seems to be bottom-posting only.

No. The preferred policy is trimmed interleaved posting. Untrimmed
interleaved posting is tolerated.

> --
> Mats Peterson

Your signature marker is invalid, it must contain a trailing space.

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] End of the top-posting

[Nicolas George]

Le duodi 22 frimaire, an CCXXIV, Mats Peterson a écrit :
> >Now, let's not split hairs. Be happy that I have stopped the top-posting
> >instead.
> Not that I care a lot what you think.

It has not taken you a long time to show your true colors here too.

For the record, this was the guy who started insulting Carl Eugen on the
second or third comment of a trac ticket.

Since the patches are technically bad too, I will ignore these mails from
now on.

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 RFC] avfilter/vf_delogo: Use AVPixFmtDescriptor.nb_components

[Michael Niedermayer]

On Sat, Dec 12, 2015 at 12:07:25PM +, Paul B Mahol wrote:
> On 12/10/15, Jean Delvare  wrote:
> > Relying on AVPixFmtDescriptor.nb_components is cleaner and faster than
> > checking data and linesize for every possible plane.
> >
> > Signed-off-by: Jean Delvare 
> > ---
> > I see that most filters use AVPixFmtDescriptor.nb_components while
> > others still check data and linesize. Am I correct assuming that the
> > former is faster and preferred?
> >
> >  libavfilter/vf_delogo.c |2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > --- ffmpeg.orig/libavfilter/vf_delogo.c 2015-12-10 13:06:16.212908502 
> > +0100
> > +++ ffmpeg/libavfilter/vf_delogo.c  2015-12-10 13:07:04.877966120 +0100
> > @@ -256,7 +256,7 @@ static int filter_frame(AVFilterLink *in
> >  if (!sar.num)
> >  sar.num = sar.den = 1;
> >
> > -for (plane = 0; plane < 4 && in->data[plane] && in->linesize[plane];
> > plane++) {
> > +for (plane = 0; plane < desc->nb_components; plane++) {
> >  int hsub = plane == 1 || plane == 2 ? hsub0 : 0;
> >  int vsub = plane == 1 || plane == 2 ? vsub0 : 0;
> >
> >
> >
> > --
> > Jean Delvare
> > SUSE L3 Support
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> 
> lgtm

applied

thx

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

No snowflake in an avalanche ever feels responsible. -- 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]lavf/matroskadec: Set codec_tag also for audio codecs

[Carl Eugen Hoyos]

On Friday 11 December 2015 05:04:21 pm Michael Niedermayer wrote:
> >  matroskadec.c |2 ++
> >  1 file changed, 2 insertions(+)
> > 77e6700373ba86f49886c58ef28a9ffbd9b7e001  patchmkvaudiofourcc.diff
> > diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
> > index aad567a..b77e7e8 100644
> > --- a/libavformat/matroskadec.c
> > +++ b/libavformat/matroskadec.c
>
> probably ok

Patch applied.

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

Re: [FFmpeg-devel] [PATCH 2/3] avcodec/aacsbr: Add comment about possibly optimization in sbr_dequant()

[Michael Niedermayer]

On Fri, Dec 11, 2015 at 12:09:57PM -0500, Ganesh Ajjanagadde wrote:
> On Fri, Dec 11, 2015 at 11:36 AM, Andreas Cadhalpun
>  wrote:
> > On 11.12.2015 17:21, Ganesh Ajjanagadde wrote:
> >> On Fri, Dec 11, 2015 at 11:16 AM, Andreas Cadhalpun
> >>  wrote:
> >>> On 19.11.2015 14:17, Michael Niedermayer wrote:
>  From: Michael Niedermayer 
> 
>  Signed-off-by: Michael Niedermayer 
>  ---
>   libavcodec/aacsbr.c |1 +
>   1 file changed, 1 insertion(+)
> 
>  diff --git a/libavcodec/aacsbr.c b/libavcodec/aacsbr.c
>  index d1e3a91..e014646 100644
>  --- a/libavcodec/aacsbr.c
>  +++ b/libavcodec/aacsbr.c
>  @@ -73,6 +73,7 @@ static void sbr_dequant(SpectralBandReplication *sbr, 
>  int id_aac)
>   {
>   int k, e;
>   int ch;
>  +//TODO: Replace exp2f(0.5*x) by a LUT, the inputs are all integer 
>  and have a small range
> 
>   if (id_aac == TYPE_CPE && sbr->bs_coupling) {
>   float alpha  = sbr->data[0].bs_amp_res ?  1.0f :  0.5f;
> 
> >>>
> >>> This shouldn't hurt, with or without the clarification requested by 
> >>> Ganesh.
> >>
> >> I am doing related work cleaning up and optimizing usages of slow libm
> >> functions such as pow and exp2. Do you know the exact possible range
> >> of the inputs x, and if so, can it be added to the comment? That will
> >> be very helpful for me to come up with a patch. Thanks.
> >
> > The exp2f expressions are:
> > exp2f(sbr->data[0].env_facs_q[e][k] * alpha + 7.0f);
> > exp2f((pan_offset - sbr->data[1].env_facs_q[e][k]) * alpha);
> > exp2f(NOISE_FLOOR_OFFSET - sbr->data[0].noise_facs_q[e][k] + 1);
> > exp2f(12 - sbr->data[1].noise_facs_q[e][k]);
> > exp2f(alpha * sbr->data[ch].env_facs_q[e][k] + 6.0f);
> > exp2f(NOISE_FLOOR_OFFSET - sbr->data[ch].noise_facs_q[e][k]);
> >
> > Here alpha is 1 or 0.5, pan_offset 12 or 24 and NOISE_FLOOR_OFFSET is 6.
> > After patch 3 of this series, env_facs_q is in the range from 0 to 127 and
> > noise_facs_q is already limited to the range from 0 to 30.
> >
> > So x should always be in the range -300..300, or so.
> 
> Very good, thanks a lot.
> 
> Based on the above range, my idea is to not even use a LUT, but use
> something like exp2fi followed by multiplication by M_SQRT2 depending
> on even or odd.

conditional operations can due to branch misprediction be potentially
rather slow

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

Many that live deserve death. And some that die deserve life. Can you give
it to them? Then do not be too eager to deal out death in judgement. For
even the very wise cannot see all ends. -- Gandalf


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

Re: [FFmpeg-devel] End of the top-posting

[Ganesh Ajjanagadde]

On Sat, Dec 12, 2015 at 10:19 AM, Mats Peterson
 wrote:
[...]
> Even with the first patch, there isn't a lot to be technically bad about,
> since it concerns something as simple as putting the palette in extradata.
> Calling a function in mov.c could perhaps be viewed as being remotely
> technically bad, but that's fixed long ago. You just seem to like to bitch.
> I have excused myself for my initial behaviour at the bug tracker, but if
> you like dig around in old sh*t, please go ahead. But you won't get any
> sympathy from me.

Please refrain from such language ("bitch", "sh*t"). It is not good
for ffmpeg-devel, and moreover such extreme language has a tendency of
resulting in needless escalation.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] End of the top-posting

[Mats Peterson]

On Sat, 12 Dec 2015, Ganesh Ajjanagadde wrote:


On Sat, Dec 12, 2015 at 10:19 AM, Mats Peterson
 wrote:
[...]

Even with the first patch, there isn't a lot to be technically bad about,
since it concerns something as simple as putting the palette in extradata.
Calling a function in mov.c could perhaps be viewed as being remotely
technically bad, but that's fixed long ago. You just seem to like to bitch.
I have excused myself for my initial behaviour at the bug tracker, but if
you like dig around in old sh*t, please go ahead. But you won't get any
sympathy from me.


Please refrain from such language ("bitch", "sh*t"). It is not good
for ffmpeg-devel, and moreover such extreme language has a tendency of
resulting in needless escalation.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


No problem. He shouldn't tell me that the patch is technically bad, 
anyway, and then ignore me. That's utterly childish behaviour.


Mats

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] End of the top-posting

[Mats Peterson]

On Sat, 12 Dec 2015, Nicolas George wrote:


Since the patches are technically bad too, I will ignore these mails from
now on.

Regards,

--
 Nicolas George



Even with the first patch, there isn't a lot to be technically bad 
about, since it concerns something as simple as putting the palette in 
extradata. Calling a function in mov.c could perhaps be viewed as being 
remotely technically bad, but that's fixed long ago. You just seem to like 
to bitch. I have excused myself for my initial behaviour at the bug 
tracker, but if you like dig around in old sh*t, please go ahead. But you 
won't get any sympathy from me.


Mats

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] lavu/error: add missing error messages for errors supported on all platforms

[Michael Niedermayer]

On Wed, Dec 09, 2015 at 10:12:52PM +0100, Marton Balint wrote:
> We need these if we have no strerror_r.
> 
> Descriptions are taken from doc/errno.txt except for ENOMEM.
> 
> Signed-off-by: Marton Balint 
> ---
>  libavutil/error.c | 37 +
>  1 file changed, 37 insertions(+)

LGTM

thx

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

When you are offended at any man's fault, turn to yourself and study your
own failings. Then you will forget your anger. -- Epictetus


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] avcodec/aacsbr_template: Add Check to read_sbr_envelope()

[Michael Niedermayer]

On Fri, Dec 11, 2015 at 05:23:58PM +0100, Andreas Cadhalpun wrote:
> On 19.11.2015 14:17, Michael Niedermayer wrote:
> > From: Michael Niedermayer 
> > 
> > The limit is a conservative guess, the spec does not seem to specify a limit
> > 
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavcodec/aacsbr_template.c |   41 
> > +
> >  1 file changed, 33 insertions(+), 8 deletions(-)
> 
> This fixes the remaining crash problem in the aac_fixed decoder, which is 
> caused
> by underflow of sbr->gain[e][m] in sbr_gain_calc.
> (That is the same problem as was caused by calling sbr_dequant twice,
> just with a different cause.)
> 
> Therefore this patch looks good to me. Thanks!

applied

thanks

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

Those who are best at talking, realize last or never when they are wrong.


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

Re: [FFmpeg-devel] [PATCH] lavf/mov: add support for sidx fragment indexes

[Dan Sanders]

I took a look at the structure of this file, and the encoding appears to be
correct. The frame order in the moof boxes matches the H.264 stream, and
the durations of the moof boxes match with the sidx.

Some notes to help with analysis: There are no per-frame durations
specified, every frame is exactly 3000 time units long (=1s/30). The first
frame PTS is 3000, but there is an edit list to shift that to movie time 0.
The fragments contain 152 frames each, and the base times of the fragments
reflect that correctly.

On Fri, Dec 11, 2015 at 2:39 PM Dale Curtis  wrote:

> This patch seems to be causing some issues with some h264 video-only
> content. Attempting to play the following in ffplay with "-v debug -drp 1"
> (disables pts/dts fixups and purely uses pts) will cause jerky playback
> after seeking around a few times due to dropped out of order frames. These
> are shown in the log as "invalid dts/pts combination..." Skipping sidx
> parsing for this file yields smooth playback. I haven't figured out yet if
> this is bad encoding or something is wrong with the patch, but FYI.
>
> http://storage.googleapis.com/dalecurtis-shared/buck480p30_na.mp4
>
> - dale
>
> On Tue, Oct 6, 2015 at 9:18 AM, Michael Niedermayer <
> mich...@niedermayer.cc> wrote:
>
>> On Tue, Oct 06, 2015 at 03:50:23AM -0500, Rodger Combs wrote:
>> > Fixes trac #3842
>> > ---
>> >  libavformat/isom.h |   2 +
>> >  libavformat/mov.c  | 245
>> -
>> >  2 files changed, 208 insertions(+), 39 deletions(-)
>>
>> i think this should be applied unless someone has more comments
>>
>> [...]
>
>
>> --
>> 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.
>>
>> ___
>> 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] End of the top-posting

[Mats Peterson]

On Sat, 12 Dec 2015, Mats Peterson wrote:


On Sat, 12 Dec 2015, Nicolas George wrote:


Le duodi 22 frimaire, an CCXXIV, Mats Peterson a écrit :

Now, let's not split hairs. Be happy that I have stopped the top-posting
instead.

Not that I care a lot what you think.


It has not taken you a long time to show your true colors here too.

For the record, this was the guy who started insulting Carl Eugen on the
second or third comment of a trac ticket.

Since the patches are technically bad too, I will ignore these mails from
now on.

Regards,

--
 Nicolas George



The patches WERE technically bad, that's why I fixed them.

Mats



You could always try and do it better yourself. And I'm talking about the 
SECOND patch posted here, not the hack that calls a function in mov.c.


Mats

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/3] avcodec/aacsbr: Add comment about possibly optimization in sbr_dequant()

[Ganesh Ajjanagadde]

On Sat, Dec 12, 2015 at 12:58 PM, Michael Niedermayer  wrote:
> On Fri, Dec 11, 2015 at 12:09:57PM -0500, Ganesh Ajjanagadde wrote:
>> On Fri, Dec 11, 2015 at 11:36 AM, Andreas Cadhalpun
>>  wrote:
>> > On 11.12.2015 17:21, Ganesh Ajjanagadde wrote:
>> >> On Fri, Dec 11, 2015 at 11:16 AM, Andreas Cadhalpun
>> >>  wrote:
>> >>> On 19.11.2015 14:17, Michael Niedermayer wrote:
>>  From: Michael Niedermayer 
>> 
>>  Signed-off-by: Michael Niedermayer 
>>  ---
>>   libavcodec/aacsbr.c |1 +
>>   1 file changed, 1 insertion(+)
>> 
>>  diff --git a/libavcodec/aacsbr.c b/libavcodec/aacsbr.c
>>  index d1e3a91..e014646 100644
>>  --- a/libavcodec/aacsbr.c
>>  +++ b/libavcodec/aacsbr.c
>>  @@ -73,6 +73,7 @@ static void sbr_dequant(SpectralBandReplication *sbr, 
>>  int id_aac)
>>   {
>>   int k, e;
>>   int ch;
>>  +//TODO: Replace exp2f(0.5*x) by a LUT, the inputs are all integer 
>>  and have a small range
>> 
>>   if (id_aac == TYPE_CPE && sbr->bs_coupling) {
>>   float alpha  = sbr->data[0].bs_amp_res ?  1.0f :  0.5f;
>> 
>> >>>
>> >>> This shouldn't hurt, with or without the clarification requested by 
>> >>> Ganesh.
>> >>
>> >> I am doing related work cleaning up and optimizing usages of slow libm
>> >> functions such as pow and exp2. Do you know the exact possible range
>> >> of the inputs x, and if so, can it be added to the comment? That will
>> >> be very helpful for me to come up with a patch. Thanks.
>> >
>> > The exp2f expressions are:
>> > exp2f(sbr->data[0].env_facs_q[e][k] * alpha + 7.0f);
>> > exp2f((pan_offset - sbr->data[1].env_facs_q[e][k]) * alpha);
>> > exp2f(NOISE_FLOOR_OFFSET - sbr->data[0].noise_facs_q[e][k] + 1);
>> > exp2f(12 - sbr->data[1].noise_facs_q[e][k]);
>> > exp2f(alpha * sbr->data[ch].env_facs_q[e][k] + 6.0f);
>> > exp2f(NOISE_FLOOR_OFFSET - sbr->data[ch].noise_facs_q[e][k]);
>> >
>> > Here alpha is 1 or 0.5, pan_offset 12 or 24 and NOISE_FLOOR_OFFSET is 6.
>> > After patch 3 of this series, env_facs_q is in the range from 0 to 127 and
>> > noise_facs_q is already limited to the range from 0 to 30.
>> >
>> > So x should always be in the range -300..300, or so.
>>
>> Very good, thanks a lot.
>>
>> Based on the above range, my idea is to not even use a LUT, but use
>> something like exp2fi followed by multiplication by M_SQRT2 depending
>> on even or odd.
>
> conditional operations can due to branch misprediction be potentially
> rather slow

I think it will still be far faster than exp2f, and in the absence of
hard numbers, I view this a far better approach than a large (~300
element) lut. Of course, the proof and extent of this will need to
wait for actual benches.

>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Many that live deserve death. And some that die deserve life. Can you give
> it to them? Then do not be too eager to deal out death in judgement. For
> even the very wise cannot see all ends. -- Gandalf
>
> ___
> 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/3] avcodec/aacsbr: Add comment about possibly optimization in sbr_dequant()

[Michael Niedermayer]

On Sat, Dec 12, 2015 at 01:08:01PM -0500, Ganesh Ajjanagadde wrote:
> On Sat, Dec 12, 2015 at 12:58 PM, Michael Niedermayer  
> wrote:
> > On Fri, Dec 11, 2015 at 12:09:57PM -0500, Ganesh Ajjanagadde wrote:
> >> On Fri, Dec 11, 2015 at 11:36 AM, Andreas Cadhalpun
> >>  wrote:
> >> > On 11.12.2015 17:21, Ganesh Ajjanagadde wrote:
> >> >> On Fri, Dec 11, 2015 at 11:16 AM, Andreas Cadhalpun
> >> >>  wrote:
> >> >>> On 19.11.2015 14:17, Michael Niedermayer wrote:
> >>  From: Michael Niedermayer 
> >> 
> >>  Signed-off-by: Michael Niedermayer 
> >>  ---
> >>   libavcodec/aacsbr.c |1 +
> >>   1 file changed, 1 insertion(+)
> >> 
> >>  diff --git a/libavcodec/aacsbr.c b/libavcodec/aacsbr.c
> >>  index d1e3a91..e014646 100644
> >>  --- a/libavcodec/aacsbr.c
> >>  +++ b/libavcodec/aacsbr.c
> >>  @@ -73,6 +73,7 @@ static void sbr_dequant(SpectralBandReplication 
> >>  *sbr, int id_aac)
> >>   {
> >>   int k, e;
> >>   int ch;
> >>  +//TODO: Replace exp2f(0.5*x) by a LUT, the inputs are all 
> >>  integer and have a small range
> >> 
> >>   if (id_aac == TYPE_CPE && sbr->bs_coupling) {
> >>   float alpha  = sbr->data[0].bs_amp_res ?  1.0f :  0.5f;
> >> 
> >> >>>
> >> >>> This shouldn't hurt, with or without the clarification requested by 
> >> >>> Ganesh.
> >> >>
> >> >> I am doing related work cleaning up and optimizing usages of slow libm
> >> >> functions such as pow and exp2. Do you know the exact possible range
> >> >> of the inputs x, and if so, can it be added to the comment? That will
> >> >> be very helpful for me to come up with a patch. Thanks.
> >> >
> >> > The exp2f expressions are:
> >> > exp2f(sbr->data[0].env_facs_q[e][k] * alpha + 7.0f);
> >> > exp2f((pan_offset - sbr->data[1].env_facs_q[e][k]) * alpha);
> >> > exp2f(NOISE_FLOOR_OFFSET - sbr->data[0].noise_facs_q[e][k] + 1);
> >> > exp2f(12 - sbr->data[1].noise_facs_q[e][k]);
> >> > exp2f(alpha * sbr->data[ch].env_facs_q[e][k] + 6.0f);
> >> > exp2f(NOISE_FLOOR_OFFSET - sbr->data[ch].noise_facs_q[e][k]);
> >> >
> >> > Here alpha is 1 or 0.5, pan_offset 12 or 24 and NOISE_FLOOR_OFFSET is 6.
> >> > After patch 3 of this series, env_facs_q is in the range from 0 to 127 
> >> > and
> >> > noise_facs_q is already limited to the range from 0 to 30.
> >> >
> >> > So x should always be in the range -300..300, or so.
> >>
> >> Very good, thanks a lot.
> >>
> >> Based on the above range, my idea is to not even use a LUT, but use
> >> something like exp2fi followed by multiplication by M_SQRT2 depending
> >> on even or odd.
> >
> > conditional operations can due to branch misprediction be potentially
> > rather slow
> 
> I think it will still be far faster than exp2f, and in the absence of
> hard numbers, I view this a far better approach than a large (~300
> element) lut. Of course, the proof and extent of this will need to
> wait for actual benches.

alternatively one could do a
if (x+A < (unsigned)B)
LUT[x+A]
else
exp2whatever(x)

the range in practice should be much smaller than +-300

also the LUT can possibly be shared between codecs

or that code could be in a exp_sqrt2i() or something

just some random ideas...

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

Complexity theory is the science of finding the exact solution to an
approximation. Benchmarking OTOH is finding an approximation of the exact


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

Re: [FFmpeg-devel] [PATCH] avcodec/golomb: Mask shift amount before use in get_ue_golomb()

[Michael Niedermayer]

On Fri, Dec 11, 2015 at 04:24:43PM -0500, Ganesh Ajjanagadde wrote:
> On Fri, Dec 11, 2015 at 4:14 PM, Andreas Cadhalpun
>  wrote:
> > On 07.12.2015 00:27, Ganesh Ajjanagadde wrote:
> >> On Sun, Dec 6, 2015 at 6:12 PM, Andreas Cadhalpun
> >>  wrote:
> >>> On 06.12.2015 22:48, Michael Niedermayer wrote:
>  my concern is more on h264 (CAVLC) and hevc speed
> >>>
> >>> I tested with 444_8bit_cavlc.h264 added 100 together with the concat 
> >>> demuxer,
> >>> and couldn't see a measurable speed difference caused by this error check.
> >>
> >> Ok, so here is my understanding of the situation.
> >> I think both of you are right, but have different perspectives on this.
> >> So in practice a log < 7 may be usually predicted correctly, and the
> >> compiler in all likelihood will continue to inline the function. Thus,
> >> excepting the first run, there should not be an issue, and maybe the
> >> compiler even feeds in the "likely" information for the first run
> >> also.
> >>
> >> Nevertheless, I also understand Michael's perspective: h264 is
> >> arguably one of the most important codecs as supplied by FFmpeg. Even
> >> a 0.01% speedloss in some place should be done with extreme caution,
> >> since over time these may accumulate to something more sizable, say
> >> 0.5%. There should be a very good justification for it, and thus
> >> Michael spends effort trying to ensure that the security issue is
> >> fixed at identical asm.
> >
> > I wouldn't call this a security issue, it's just undefined behavior.
> 
> Meant really from a theoretical perspective, since undefined means
> anything can happen. Of course, in practice a distinction may be
> drawn. But then again, I consider even these worthy of backport.

btw, if you feel something should be backported, dont hesitate to
push cherry picked commits to the release branches
(with cherry-pick -x)
if you are unsure if somethig should be cherry picked, dont hesitate
to ask


[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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

Re: [FFmpeg-devel] [PATCH] avcodec/golomb: Mask shift amount before use in get_ue_golomb()

[Ganesh Ajjanagadde]

On Sat, Dec 12, 2015 at 1:13 PM, Michael Niedermayer  wrote:

[...]

> btw, if you feel something should be backported, dont hesitate to
> push cherry picked commits to the release branches
> (with cherry-pick -x)
> if you are unsure if somethig should be cherry picked, dont hesitate
> to ask

Personally, I only use master and the distro I mainly care about
(Arch) is on the latest stable release, so the importance of backports
for me is low. I also view FFmpeg as something for which it is best to
be on master due to its nature, so philosophically as well I have
little interest in backports.

However, if it reduces work for you, or others who backport, please
tell me whenever you review whether something I fixed should be
backported, and which release branch to push to. I just feel that
these are best done by those who have higher interest in it - after
all, work is best done by those who are motivated to do it.

Alternatively, we can just continue with the status quo from my end: I
work on master, release and backport business handled by others.

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

Re: [FFmpeg-devel] [PATCH] matroskadec.c: Handle palettized QuickTime video properly

[Michael Niedermayer]

On Sat, Dec 12, 2015 at 11:17:00AM +, Mats Peterson wrote:
> Obviously that private data is cropped in some way then, since the minimum 
> size of a video sample description in QuickTime video is 86 bytes.

FFmpeg tries to support all kind of odd and broken files, so even if
the file is invalid, continuing to support it would be better

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

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


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

Re: [FFmpeg-devel] [PATCH v3 06/14] mips: i6400 core does have an FPU, so not disable it

[Michael Niedermayer]

On Thu, Dec 03, 2015 at 01:22:21PM +, Vicente Olivert Riera wrote:
> Signed-off-by: Vicente Olivert Riera 
> ---
> Changes v2 -> v3:
>  - Nothing.
> 
> Changes v1 -> v2:
>  - Fix a grammar mistake in the commit log. Change "do has" by "does
>have". Thanks to Moritz Barsnick:
>https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2015-November/183437.html
> 
> configure | 1 -
>  1 file changed, 1 deletion(-)

applied

thanks

[...]
-- 
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] [PATCH v3 04/14] mips: remove --mips64r6 configure option

[Michael Niedermayer]

On Thu, Dec 03, 2015 at 01:22:19PM +, Vicente Olivert Riera wrote:
> Having a configure option with the same name as a MIPS ISA is confusing,
> so better to remove it. This option was being used to add some
> optimizations to a specific core (i6400). We will add the optimizations
> just when the i6400 core has been detected, in a later patch.
> 
> Signed-off-by: Vicente Olivert Riera 
> ---
> Changes v2 -> v3:
>  - Document it in the Changelog.
> 
> Changes v1 -> v2:
>  - Nothing.
> 
>  Changelog | 1 +
>  configure | 9 -
>  2 files changed, 1 insertion(+), 9 deletions(-)

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 v3 05/14] mips: add i6400 core optimizations

[Michael Niedermayer]

On Thu, Dec 03, 2015 at 01:22:20PM +, Vicente Olivert Riera wrote:
> Signed-off-by: Vicente Olivert Riera 
> ---
> Changes v2 -> v3:
>  - Nothing.
> 
> Changes v1 -> v2:
>  - Nothing.
> 
>  configure | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)

applied

thanks

[...]
-- 
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] mpegtsenc cbr mode pcr accuracy

[Michael Niedermayer]

On Sat, Nov 28, 2015 at 09:03:20AM +0200, Timo Teras wrote:
> Hi,
> 
> While the pcr is accuracte, I was measuring the cbr pcr frequence with
> opencaster suite's tspcmeasure tool, and it says that the frequency is
> not that accurate. With default options (just muxrate specified) the
> pcr should appear every 20ms. But it appears every 19-22.5ms (also
> there some appearances with 1-18ms but those are probably the extra pcr
> announces for key frames).
> 
> While in practice this is not too bad for me, I wondered how it should
> be generated instead.
> 
> Seems that the period is calculated in mpegts_write_header():
>   pcr_packet_period = mux_rate * pcr_period / (TS_PACKET_SIZE * 8 * 1000)
> 
> Which is the packet period over the whole mpeg ts stream. But the count
> is actually incremented like mpegts_write_pes():
> while (payload_size > 0) {
> retransmit_si_info(s, force_pat, dts);
> force_pat = 0;
> write_pcr = 0;
> if (ts_st->pid == ts_st->service->pcr_pid) {
> if (ts->mux_rate > 1 || is_start) // VBR pcr period is based on 
> frames
> ts_st->service->pcr_packet_count++;
> 
> The problem seems to be that only packets for pcr_pid are counted in
> the pcr period. That's why the gap goes >20ms when there's other
> streams muxed (usually audio) and depends on the other PES' bandwidth.
> Same is true for sdt and pat - they drift very slightly, because they
> don't count each other's packets.
> 
> I was wondering how to fix this. Would it be best to remove all
> {sdt,pat,pcr}_packet_count variables, and replace it with single
> packet_count counter that is incremented everytime a packet is sent
> (in the four functions section_write_packet(),
> mpegts_insert_null_packet(), mpegts_insert_pcr_only(),
> mpegts_write_pes()) and then calculate just the next packet count when
> to trigger resend. packet_count + {sdt,pat,pcr}_packet_period.

wouldnt packet_count overflow? (can be worked around of course just
want to make sure i understand what you suggest)


> 
> Another problem case is the inserting of null/pcr-only packets. If it's
> a non-pcr stream PES packet triggering the stuffing, it should still
> stuff pcr to the pcr_pid - not the pid of the stream triggering the
> stuffing. Basically the strategy in cbr mode should be:
>  1) Check / send SDT/PAT as currently
>  2) Check if PCR needs to be sent
>  3) If filler packets needed: a) send pcr on pcr_pid, OR b) send null
>  4) If PCR send needed but ES PID != pcr pid: send PCR only on pcr_pid
>  5) Proceed with sending ES on ES PID as regular
> 
> Does this reasoning / approach make sense?

yes


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

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The misfortune of the wise is better than the prosperity of the fool.
-- Epicurus


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/mov: Enable parser for mp3s by old HandBrake

[Michael Niedermayer]

On Thu, Dec 10, 2015 at 01:42:52PM +0100, Michael Niedermayer wrote:
> On Thu, Dec 10, 2015 at 10:37:42AM +0100, Moritz Barsnick wrote:
> > On Wed, Dec 09, 2015 at 22:24:08 +0100, Michael Niedermayer wrote:
> > > +if (sscanf(str, "HandBrake %d.%d.%d", , , 
> > > ) == 3) {
> > > +c->handbrake_version = 100*major + 1000*minor + 
> > > micro;
> > [...]
> > > +if (mov->handbrake_version &&
> > > +mov->handbrake_version <= 100*0 + 1000*10 + 0 &&
> > 
> > Really hard to read for all the '1's and '0'. You're checking for "<=
> > 0.10.0"? Perhaps better to clearly document that.
> 
> comment added
> 
> 
> > 
> > So starting with 0.10.1, behavior is different?
> 
> we have a file from 0.10.0 which is affected, i do not know if
> later versions are affected, if somone knows or someone submits
> files from later versions which are affected then this can be
> updated

applied

thanks

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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

Re: [FFmpeg-devel] [PATCH] avformat/mxfenc: Fix integer overflow in length computation

[Michael Niedermayer]

On Wed, Dec 09, 2015 at 06:13:25PM +0100, Michael Niedermayer wrote:
> From: Michael Niedermayer 
> 
> Fixes: CID1341577
> 
> Signed-off-by: Michael Niedermayer 
> ---
>  libavformat/mxfenc.c |4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

applied

[...]
-- 
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] matroskadec.c: Handle palettized QuickTime video properly

[Mats Peterson]

On Sat, 12 Dec 2015, Paul B Mahol wrote:


On 12/12/15, Mats Peterson  wrote:

On Sat, 12 Dec 2015, Michael Niedermayer wrote:


On Sat, Dec 12, 2015 at 11:17:00AM +, Mats Peterson wrote:

Obviously that private data is cropped in some way then, since the
minimum size of a video sample description in QuickTime video is 86
bytes.


FFmpeg tries to support all kind of odd and broken files, so even if
the file is invalid, continuing to support it would be better



Personally I don't see why it should support broken files, but your
mileage may vary, of course. So just keep the value 21 then.


Have you provided file that doesn't work?





I got a sample Matroska file from Michael Niedermayer with V_QUICKTIME 
video and with a private data of only 21 bytes, when it should be at least 
86 bytes, which is the minimum size for a video sample description in 
QuickTime.


Mats

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] matroskadec.c: Handle palettized QuickTime video properly

[Paul B Mahol]

On 12/12/15, Mats Peterson  wrote:
> On Sat, 12 Dec 2015, Michael Niedermayer wrote:
>
>> On Sat, Dec 12, 2015 at 11:17:00AM +, Mats Peterson wrote:
>>> Obviously that private data is cropped in some way then, since the
>>> minimum size of a video sample description in QuickTime video is 86
>>> bytes.
>>
>> FFmpeg tries to support all kind of odd and broken files, so even if
>> the file is invalid, continuing to support it would be better
>>
>
> Personally I don't see why it should support broken files, but your
> mileage may vary, of course. So just keep the value 21 then.

Have you provided file that doesn't work?

>
> Mats
>
>
> --
> Mats Peterson
> http://matsp888.no-ip.org/~mats/
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] lavu: add AVVideoFramePool

[Michael Niedermayer]

On Fri, Dec 11, 2015 at 07:35:08PM +0100, Matthieu Bouron wrote:
> On Fri, Dec 11, 2015 at 7:07 PM, Michael Niedermayer 
> wrote:
> 
> > On Fri, Dec 11, 2015 at 01:32:46PM +0100, Matthieu Bouron wrote:
> > > From: Matthieu Bouron 
> > >
> > > ---
> > >  libavutil/frame.c  | 153
> > +
> > >  libavutil/frame.h  |  56 +
> > >  libavutil/frame_internal.h |  37 +++
> > >  3 files changed, 246 insertions(+)
> > >  create mode 100644 libavutil/frame_internal.h
> >
> >
> > make distclean ; ./configure --enable-shared --cc=clang && make -j12
> >
> > in file included from libavutil/frame.c:26:
> > libavutil/frame_internal.h:35:3: error: redefinition of typedef
> > 'AVVideoFramePool' is invalid in C [-Wtypedef-redefinition]
> > } AVVideoFramePool;
> >   ^
> > libavutil/frame.h:718:33: note: previous definition is here
> > typedef struct AVVideoFramePool AVVideoFramePool;
> > ^
> > 1 error generated.
> > make: *** [libavutil/frame.o] Error 1
> > make: *** Waiting for unfinished jobs
> >
> >
> Fixed, new patch attached.
> 
> Thanks.
> 
> [...]

>  frame.c  |  153 
> +++
>  frame.h  |   56 
>  frame_internal.h |   37 +
>  3 files changed, 246 insertions(+)
> bf36a47628ee66ed76ab19dd412b97c88cb639bd  0001-lavu-add-AVVideoFramePool.patch
> From 1d8bd643699f78cea70e647cc584b012d9d77df1 Mon Sep 17 00:00:00 2001
> From: Matthieu Bouron 
> Date: Fri, 11 Dec 2015 09:55:27 +0100
> Subject: [PATCH 1/2] lavu: add AVVideoFramePool

seems fine to me

thanks

[...]

-- 
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] matroskadec.c: Handle palettized QuickTime video properly

[Mats Peterson]

On Sat, 12 Dec 2015, Michael Niedermayer wrote:


On Sat, Dec 12, 2015 at 11:17:00AM +, Mats Peterson wrote:

Obviously that private data is cropped in some way then, since the minimum size 
of a video sample description in QuickTime video is 86 bytes.


FFmpeg tries to support all kind of odd and broken files, so even if
the file is invalid, continuing to support it would be better



Personally I don't see why it should support broken files, but your 
mileage may vary, of course. So just keep the value 21 then.


Mats


--
Mats Peterson
http://matsp888.no-ip.org/~mats/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Memory leaks in libavformat/segment.c

[Michael Niedermayer]

On Tue, Dec 08, 2015 at 07:29:13PM +0800, Lvqier wrote:
> On 12/8/15 7:05 PM, Hendrik Leppkes wrote:
> >On Tue, Dec 8, 2015 at 11:46 AM, Lvqier  wrote:
> >>On 12/8/15 6:26 PM, Hendrik Leppkes wrote:
> >>>On Tue, Dec 8, 2015 at 11:19 AM, Lvqier  wrote:
> Hi Hendrik,
> 
>   The attached is another patch which uses av_reallocp to fix this
> issue.
> 
> >>>Thanks, that looks almost good. But you should check for a negative
> >>>return value, as all errors are negative.
> >>Do you mean that the set_segment_filename function should return the value
> >>which returns from av_reallocp instead of AVERROR(ENOMEM) when it fails?
> >That would be an option too, but right now you just do
> >if(av_reallop(..)), at the least this should be if (av_reallocp(...) <
> >0)
> >
> >or even better:
> >ret = av_reallocp(...);
> >if (ret < 0)
> > return ret;
> Thank you, I will follow your advice. Please help review this
> version. I have studied some code where av_reallocp is used before
> sending it out.
> >
> >- Hendrik
> >___
> >ffmpeg-devel mailing list
> >ffmpeg-devel@ffmpeg.org
> >http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> -- 
> /Best Regards,
> lvqier - lvq...@gmail.com 
> /
> 
> **
> 青春如烟，唱一首笑忘歌
> 

>  segment.c |6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 1937242a893d87f41f4a8feed2e176ce705987b1  patch_v4.diff
> diff --git a/libavformat/segment.c b/libavformat/segment.c

applied

thanks


[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The misfortune of the wise is better than the prosperity of the fool.
-- Epicurus


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

Re: [FFmpeg-devel] [PATCH 2/3] avcodec/aacsbr: Add comment about possibly optimization in sbr_dequant()

[Ganesh Ajjanagadde]

On Sat, Dec 12, 2015 at 1:17 PM, Michael Niedermayer  wrote:
[...]

>> >> >
>> >> > The exp2f expressions are:
>> >> > exp2f(sbr->data[0].env_facs_q[e][k] * alpha + 7.0f);
>> >> > exp2f((pan_offset - sbr->data[1].env_facs_q[e][k]) * alpha);
>> >> > exp2f(NOISE_FLOOR_OFFSET - sbr->data[0].noise_facs_q[e][k] + 1);
>> >> > exp2f(12 - sbr->data[1].noise_facs_q[e][k]);
>> >> > exp2f(alpha * sbr->data[ch].env_facs_q[e][k] + 6.0f);
>> >> > exp2f(NOISE_FLOOR_OFFSET - sbr->data[ch].noise_facs_q[e][k]);
>> >> >
>> >> > Here alpha is 1 or 0.5, pan_offset 12 or 24 and NOISE_FLOOR_OFFSET is 6.
>> >> > After patch 3 of this series, env_facs_q is in the range from 0 to 127 
>> >> > and
>> >> > noise_facs_q is already limited to the range from 0 to 30.
>> >> >
>> >> > So x should always be in the range -300..300, or so.
>> >>
>> >> Very good, thanks a lot.
>> >>
>> >> Based on the above range, my idea is to not even use a LUT, but use
>> >> something like exp2fi followed by multiplication by M_SQRT2 depending
>> >> on even or odd.
>> >
>> > conditional operations can due to branch misprediction be potentially
>> > rather slow
>>
>> I think it will still be far faster than exp2f, and in the absence of
>> hard numbers, I view this a far better approach than a large (~300
>> element) lut. Of course, the proof and extent of this will need to
>> wait for actual benches.
>
> alternatively one could do a
> if (x+A < (unsigned)B)
> LUT[x+A]
> else
> exp2whatever(x)
>
> the range in practice should be much smaller than +-300

That still uses a branch, so unless for whatever reason the numbers
tend to concentrate in an interval (which you believe but I am
agnostic about since I don't know AAC), this is code complexity for
little gain. Furthermore, that B then becomes a "voodoo" constant, and
performance may vary across files depending on the degree of
concentration of the inputs. I personally don't like such things
unless they are very well justified after all other easy, uniform
methods of optimization are exhausted.

>
> also the LUT can possibly be shared between codecs

This is something for which there is plenty of low hanging fruit
across FFmpeg. The best example I know of is the sin/cos tables used
across dct, fft, and other areas: a lot of them can be derived from
sin(2*pi*i/65536) for 0 <= i <= 65536/4, and cheap runtime derivation
via indexing and symmetry exploitation (eg 16*i, 32*i, flip the sign).
I will work on this only after other things are sorted out; so in the
meantime it is up for grabs.

Complications come from threading issues for the case of dynamic init,
since one needs to place a lock of some sort to avoid write
contention. And --enable-hardcoded-tables does not help at all, as it
distracts from the key issues since one needs to reason about both
cases.

Unfortunately, the question of static vs dynamic tables is something
that can easily get bikeshedded to death. I am trying to do
improvements to the default dynamic initialization to help resolve
such things, see e.g the aac_tablegen work. My goal is to first
improve the runtime generation code, and once it is done, ask the ML
for decisions on this when the answer is relatively clear cut.

I might be too optimistic here regarding removal of
--enable-hardcoded-tables entirely via hard decisions in respective
usages of static vs runtime across the codebase. This is beacuse
things like mpegaudio_tablegen are hard to do on the order of 10^5 or
below cycles at runtime, leading to ambiguity and stalemating the
removal of hardcoded tables hackery.

>
> or that code could be in a exp_sqrt2i() or something

Maybe, I just thought by keeping common code, one avoids essentially
duplicate functions and it possibly keeps binary size smaller. This of
course depends on the linker, header vs source implementation, etc and
is a minor consideration.

>
> just some random ideas...

Thanks for the ideas. I had thought about most of these things before
settling on the idea proposed above. In any case, the goal should be
solid incremental improvement: last mile tweaks to get rid of some
branch penalties, optimize for common inputs, or other things can
always be done later, and should not bog down work now.

>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Complexity theory is the science of finding the exact solution to an
> approximation. Benchmarking OTOH is finding an approximation of the exact
>
> ___
> 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 v4] Added VideoToolbox H.264 encoder.

[Richard Kern]

On Nov 28, 2015, at 5:23 PM, Richard Kern  wrote:
> 
> On Nov 28, 2015, at 5:07 PM, Timothy Gu  wrote:
>> 
>> On Sat, Nov 28, 2015 at 02:06:07PM -0500, Rick Kern wrote:
>>> vtenc.c was updated to match the coding style of the project.
>>> 
>>> I used several other files to get a feel for the project's coding
>>> style. Is there documentation for this?
>> 
>> Yes: https://ffmpeg.org/developer.html#Coding-Rules-1
>> 
>> Timothy
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> Got it - I didn’t realize ‘indent’ was a source code formatter.

Ping - can this be pushed, or does anyone else want to review?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] mpegtsenc: signalling of AC-3 and E-AC-3 according to ATSC/DVB

[Stefan Pöschel]

[sorry, used wrong sender previously]


Hi,

within the MPEG-TS muxer, the signalling of AC-3 is done according to
System A (ATSC) while in contrast E-AC-3 is signalled according to
System B (DVB).
To fix this inconsistency, E-AC-3 should IMO be signalled according to
System A, too. Furthermore a flag for the mpegts_flags param should be
added to optionally switch the behaviour (regarding both codecs) to
System B conformity.

IMO it makes more sense to change the E-AC-3 behaviour to ATSC instead
of the AC-3 behaviour to DVB, as the AC-3 behaviour is older (E-AC-3 is
present in FFmpeg code since 2011).

If there are no objections against my proposal, I would write and post a
regarding patch.

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

Re: [FFmpeg-devel] [PATCH 2/3] avcodec/aacsbr: Add comment about possibly optimization in sbr_dequant()

[Michael Niedermayer]

On Sat, Dec 12, 2015 at 05:24:34PM -0500, Ganesh Ajjanagadde wrote:
> On Sat, Dec 12, 2015 at 1:17 PM, Michael Niedermayer  wrote:
> [...]
> 
> >> >> >
> >> >> > The exp2f expressions are:
> >> >> > exp2f(sbr->data[0].env_facs_q[e][k] * alpha + 7.0f);
> >> >> > exp2f((pan_offset - sbr->data[1].env_facs_q[e][k]) * alpha);
> >> >> > exp2f(NOISE_FLOOR_OFFSET - sbr->data[0].noise_facs_q[e][k] + 1);
> >> >> > exp2f(12 - sbr->data[1].noise_facs_q[e][k]);
> >> >> > exp2f(alpha * sbr->data[ch].env_facs_q[e][k] + 6.0f);
> >> >> > exp2f(NOISE_FLOOR_OFFSET - sbr->data[ch].noise_facs_q[e][k]);
> >> >> >
> >> >> > Here alpha is 1 or 0.5, pan_offset 12 or 24 and NOISE_FLOOR_OFFSET is 
> >> >> > 6.
> >> >> > After patch 3 of this series, env_facs_q is in the range from 0 to 
> >> >> > 127 and
> >> >> > noise_facs_q is already limited to the range from 0 to 30.
> >> >> >
> >> >> > So x should always be in the range -300..300, or so.
> >> >>
> >> >> Very good, thanks a lot.
> >> >>
> >> >> Based on the above range, my idea is to not even use a LUT, but use
> >> >> something like exp2fi followed by multiplication by M_SQRT2 depending
> >> >> on even or odd.
> >> >
> >> > conditional operations can due to branch misprediction be potentially
> >> > rather slow
> >>
> >> I think it will still be far faster than exp2f, and in the absence of
> >> hard numbers, I view this a far better approach than a large (~300
> >> element) lut. Of course, the proof and extent of this will need to
> >> wait for actual benches.
> >
> > alternatively one could do a
> > if (x+A < (unsigned)B)
> > LUT[x+A]
> > else
> > exp2whatever(x)
> >
> > the range in practice should be much smaller than +-300
> 
> That still uses a branch, so unless for whatever reason the numbers
> tend to concentrate in an interval (which you believe but I am
> agnostic about since I don't know AAC), this is code complexity for

theres an easy way to find out, just print the numbers and use
sort -n | uniq -c
i didnt try but i expect most of the range to have 0 hits


> little gain. Furthermore, that B then becomes a "voodoo" constant, and
> performance may vary across files depending on the degree of
> concentration of the inputs. I personally don't like such things
> unless they are very well justified after all other easy, uniform
> methods of optimization are exhausted.
> 
> >
> > also the LUT can possibly be shared between codecs
> 
> This is something for which there is plenty of low hanging fruit
> across FFmpeg. The best example I know of is the sin/cos tables used
> across dct, fft, and other areas: a lot of them can be derived from
> sin(2*pi*i/65536) for 0 <= i <= 65536/4, and cheap runtime derivation
> via indexing and symmetry exploitation (eg 16*i, 32*i, flip the sign).
> I will work on this only after other things are sorted out; so in the
> meantime it is up for grabs.
> 
> Complications come from threading issues for the case of dynamic init,
> since one needs to place a lock of some sort to avoid write
> contention. And --enable-hardcoded-tables does not help at all, as it
> distracts from the key issues since one needs to reason about both
> cases.

you do not "need" a lock

the most standard way to add a table is to type the numbers of its
entries in the a source file and commit that.
if the table is to be generated at build time then some complexity is
added to do that with a generator run at build time
if it is build at runtime then it no longer can be shared between
processes and needs to be written to disk in case it is paged out
a "hardcoded" table resides in read only memory and on page out
is discarded, the kernel can read it directly from the excutable
again when it gets accessed again.
and one can support both runtime and buildtime tables, so the user
can choose
a manually hardcoded table without generator is harder to update
though and it and the build generated ones result in larger object and
excutable files


> 
> Unfortunately, the question of static vs dynamic tables is something
> that can easily get bikeshedded to death. I am trying to do

yes, everyone has a different use case in mind and a different variant
is optimal for each.
In the end there is not a big difference between them i think,
especially not for small tables. For big tables there could be more
significant disadvantages in each solution relative to what is optimal
for each others use case

anyway, you could try exp2whatever(x>>1) * tab[x&1]
or something
that may be faster IFF the compiler builds the  if(x&1) into bad
code and if the values actually fluctuate enough

[...]

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