Alright Michael, I'm currently rather ambivalent regarding whether 1 bpp in AVI
should be just black & white or any color. But the term "monochrome" has to
mean black & white after all. Windows Paint forces black & white when saving a
1 bpp BMP file, for example. So does several Mac programs whe
On 1/22/2016 7:25 PM, Michael Niedermayer wrote:
> On Thu, Jan 21, 2016 at 09:44:06PM +0300, foo86 wrote:
>> Updated version of the patch. I choose to split it into even smaller commits
>> to
>> make reviewing easier; you may prefer to squash it as needed.
>>
>> Changes since the first version:
>>
On 24.01.2016 22:57, Hendrik Leppkes wrote:
> While links are in theory a good idea, creating directory links on
> windows requires elevated privileges. Don't ask me why, I don't know,
> but that makes this unfortunately impractical.
> Copying files around between different physical media is not a
On 01/25/2016 02:15 AM, Mats Peterson wrote:
On 01/25/2016 02:01 AM, Mats Peterson wrote:
Monochrome doesn't mean black & white here, merely bi-level, as for PNG,
TIFF and QuickTime.
I don't know why they use the word "monochrome" whatsoever, since they
don't mention specifically what colors t
On 01/25/2016 02:01 AM, Mats Peterson wrote:
Monochrome doesn't mean black & white here, merely bi-level, as for PNG,
TIFF and QuickTime.
I don't know why they use the word "monochrome" whatsoever, since they
don't mention specifically what colors to use in the palette. I take it
they can be
On 01/25/2016 01:58 AM, Mats Peterson wrote:
And there is seldom documentation that EXPLICITLY says that 1-bit mode
is just black & white. Both PNG, TIFF, AVI and QuickTime can use any
color for the two indexes in 1-bit images or video.
Indices.
___
Hi,
On Sun, Jan 24, 2016 at 6:49 PM, Hendrik Leppkes
wrote:
> On Sat, Jan 23, 2016 at 4:55 PM, Ronald S. Bultje
> wrote:
> > Hi,
> >
> > On Sat, Jan 23, 2016 at 8:51 AM, Ronald S. Bultje
> > wrote:
> >
> >> Hi,
> >>
> >> On Sat, Jan 23, 2016 at 8:45 AM, Hendrik Leppkes
> >> wrote:
> >>
> >>>
On 01/25/2016 01:57 AM, Michael Niedermayer wrote:
do you have a link to these 1bpp palette docs ?
https://msdn.microsoft.com/en-us/library/windows/desktop/dd183376%28v=vs.85%29.aspx
Note the following regarding 1-bit mode:
"The bitmap is monochrome, and the bmiColors member of BITMAPINFO
con
On 01/25/2016 01:54 AM, Mats Peterson wrote:
Microsoft's player doesn't even play raw 1-bit video for some reason,
but that's not our problem, is it? All the documentation on Microsoft's
site on 1-bit video tells us that it's palettized and not simply black &
white. 1, 4, and 8 bit modes, all o
On Mon, Jan 25, 2016 at 01:54:22AM +0100, Mats Peterson wrote:
> On 01/25/2016 01:52 AM, Michael Niedermayer wrote:
> >On Mon, Jan 25, 2016 at 01:39:13AM +0100, Mats Peterson wrote:
> >>On 01/25/2016 01:31 AM, Mats Peterson wrote:
> >>>On 01/25/2016 01:30 AM, Mats Peterson wrote:
> >>>
> Well,
On 01/25/2016 01:54 AM, Mats Peterson wrote:
On 01/25/2016 01:52 AM, Michael Niedermayer wrote:
On Mon, Jan 25, 2016 at 01:39:13AM +0100, Mats Peterson wrote:
On 01/25/2016 01:31 AM, Mats Peterson wrote:
On 01/25/2016 01:30 AM, Mats Peterson wrote:
Well, this one is still incorrect, since it
On 01/25/2016 01:52 AM, Michael Niedermayer wrote:
On Mon, Jan 25, 2016 at 01:39:13AM +0100, Mats Peterson wrote:
On 01/25/2016 01:31 AM, Mats Peterson wrote:
On 01/25/2016 01:30 AM, Mats Peterson wrote:
Well, this one is still incorrect, since it doesn't cater for different
strides.
Mats
On Mon, Jan 25, 2016 at 01:39:13AM +0100, Mats Peterson wrote:
> On 01/25/2016 01:31 AM, Mats Peterson wrote:
> >On 01/25/2016 01:30 AM, Mats Peterson wrote:
> >
> >>Well, this one is still incorrect, since it doesn't cater for different
> >>strides.
> >>
> >>Mats
> >>
> >
> >I would like you to fo
On 01/25/2016 01:46 AM, Michael Niedermayer wrote:
dont fear, it was just applied locally, its not pushed to public
git
I didn't know. My heart was beating fast here :)
Mats
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/m
On 01/25/2016 01:45 AM, Michael Niedermayer wrote:-> can you post a
patchset with split changes ?
that is one bugfix -> one patch, one feature -> one patch
[...]
Have you seen my mail? And I don't find any logical way to split this,
since most of the changes are pretty atomic in my book. And
On Mon, Jan 25, 2016 at 01:41:08AM +0100, Mats Peterson wrote:
> On 01/25/2016 01:39 AM, Mats Peterson wrote:
> >On 01/25/2016 01:31 AM, Mats Peterson wrote:
> >>On 01/25/2016 01:30 AM, Mats Peterson wrote:
> >>
> >>>Well, this one is still incorrect, since it doesn't cater for different
> >>>strid
On Mon, Jan 25, 2016 at 01:30:01AM +0100, Mats Peterson wrote:
> On 01/25/2016 01:26 AM, Michael Niedermayer wrote:
> >On Wed, Jan 20, 2016 at 12:41:22PM +0100, Mats Peterson wrote:
> >>I don't know about this one, since it adds some calculations inside
> >>the loop, but it limits the line alignmen
On 01/25/2016 01:41 AM, Mats Peterson wrote:
On 01/25/2016 01:39 AM, Mats Peterson wrote:
On 01/25/2016 01:31 AM, Mats Peterson wrote:
On 01/25/2016 01:30 AM, Mats Peterson wrote:
Well, this one is still incorrect, since it doesn't cater for different
strides.
Mats
I would like you to foc
On 01/25/2016 01:39 AM, Mats Peterson wrote:
On 01/25/2016 01:31 AM, Mats Peterson wrote:
On 01/25/2016 01:30 AM, Mats Peterson wrote:
Well, this one is still incorrect, since it doesn't cater for different
strides.
Mats
I would like you to focus on version 5 that I've both mailed to you a
On 01/25/2016 01:31 AM, Mats Peterson wrote:
On 01/25/2016 01:30 AM, Mats Peterson wrote:
Well, this one is still incorrect, since it doesn't cater for different
strides.
Mats
I would like you to focus on version 5 that I've both mailed to you and
posted here.
Mats
And why did you omit
Decodes YUV 4:2:2 10-bit and RGB 12-bit files.
Older files with more subbands, skips, Bayer, alpha not supported.
Alpha requires addition of GBRAP12 pixel format.
---
libavcodec/Makefile | 1 +
libavcodec/allcodecs.c | 1 +
libavcodec/avcodec.h| 1 +
libavcodec/cfhd.c | 744 ++
On 01/25/2016 01:30 AM, Mats Peterson wrote:
Well, this one is still incorrect, since it doesn't cater for different
strides.
Mats
I would like you to focus on version 5 that I've both mailed to you and
posted here.
Mats
--
Mats Peterson
http://matsp888.no-ip.org/~mats/
_
On 01/25/2016 01:26 AM, Michael Niedermayer wrote:
On Wed, Jan 20, 2016 at 12:41:22PM +0100, Mats Peterson wrote:
I don't know about this one, since it adds some calculations inside
the loop, but it limits the line alignment to 16 bytes instead of 32
bytes as before. Less overhead.
Mats
--
Mat
On Mon, Jan 25, 2016 at 01:23:00AM +0100, Mats Peterson wrote:
> On 01/25/2016 01:14 AM, Michael Niedermayer wrote:
> >On Fri, Jan 22, 2016 at 03:44:30PM +0100, Mats Peterson wrote:
> >>You'll have to excuse me, Michael, but the changes I've made,
> >>including the line alignment changes, are depen
On 01/25/2016 01:23 AM, Mats Peterson wrote:
On 01/25/2016 01:14 AM, Michael Niedermayer wrote:
On Fri, Jan 22, 2016 at 03:44:30PM +0100, Mats Peterson wrote:
You'll have to excuse me, Michael, but the changes I've made,
including the line alignment changes, are dependent on each other,
and not
On Wed, Jan 20, 2016 at 12:41:22PM +0100, Mats Peterson wrote:
> I don't know about this one, since it adds some calculations inside
> the loop, but it limits the line alignment to 16 bytes instead of 32
> bytes as before. Less overhead.
>
> Mats
>
> --
> Mats Peterson
> http://matsp888.no-ip.or
On 01/25/2016 01:14 AM, Michael Niedermayer wrote:
On Fri, Jan 22, 2016 at 03:44:30PM +0100, Mats Peterson wrote:
You'll have to excuse me, Michael, but the changes I've made,
including the line alignment changes, are dependent on each other,
and not easy or very logical to split. Here's a new v
On Fri, Jan 22, 2016 at 03:44:30PM +0100, Mats Peterson wrote:
> You'll have to excuse me, Michael, but the changes I've made,
> including the line alignment changes, are dependent on each other,
> and not easy or very logical to split. Here's a new version that
> displays the Matrix video correctl
On Sat, Jan 23, 2016 at 3:52 PM, Andreas Cadhalpun
wrote:
> On 23.01.2016 15:10, Hendrik Leppkes wrote:
>> On Sat, Jan 23, 2016 at 2:45 PM, Ronald S. Bultje wrote:
>>> Both of you keep shouting from one side of the room to the other without
>>> trying to actually converge to a point that might so
On Sat, Jan 23, 2016 at 4:55 PM, Ronald S. Bultje wrote:
> Hi,
>
> On Sat, Jan 23, 2016 at 8:51 AM, Ronald S. Bultje
> wrote:
>
>> Hi,
>>
>> On Sat, Jan 23, 2016 at 8:45 AM, Hendrik Leppkes
>> wrote:
>>
>>> On Sat, Jan 23, 2016 at 2:38 PM, Ronald S. Bultje
>>> wrote:
>>> > Hi,
>>> >
>>> > On Sa
On Sun, Jan 24, 2016 at 10:22:45PM +0100, Clément Bœsch wrote:
> On Sun, Jan 24, 2016 at 10:09:49PM +0100, Michael Niedermayer wrote:
> [...]
> > fails to build:
> > make distclean ; ../configure --enable-pthreads --arch=x86_32
> > --target-os=linux --extra-cflags=-m32 --extra-ldflags=-m32
> >
On Sun, Jan 24, 2016 at 01:46:50PM -0800, Timothy Gu wrote:
> On Sun, Jan 24, 2016 at 10:21:14PM +0100, Andreas Cadhalpun wrote:
> >
> > That's not very reasonable.
> > Other changes also broke things that worked before.
> > For example before commit 94c20de one could build ffmpeg with x265 versio
On 1/24/2016 6:22 PM, Clément Bœsch wrote:
> On Sun, Jan 24, 2016 at 10:09:49PM +0100, Michael Niedermayer wrote:
> [...]
>> fails to build:
>> make distclean ; ../configure --enable-pthreads --arch=x86_32
>> --target-os=linux --extra-cflags=-m32 --extra-ldflags=-m32
>> --enable-cross-compile
On Sun, Jan 24, 2016 at 10:48 PM, Andreas Cadhalpun
wrote:
> On 24.01.2016 22:38, Michael Niedermayer wrote:
>> On Sun, Jan 24, 2016 at 10:21:14PM +0100, Andreas Cadhalpun wrote:
>>> The patch to use relative for DST_PATH should make FATE green again, as
>>> no MSVC FATE client I saw builds across
On Sun, Jan 24, 2016 at 06:40:53PM -0300, James Almer wrote:
> > If it's really necessary to continue supporting this fringe use case, one
> > could make configure create a link to the destination folder.
> > Unless links also don't work across drives.
>
> No idea about symlinks on Windows, but if
On 1/24/2016 6:41 PM, Hendrik Leppkes wrote:
> On Sun, Jan 24, 2016 at 9:53 PM, James Almer wrote:
>> Signed-off-by: James Almer
>> ---
>> This should make replacing the current dca decoder for foo86's easier,
>> without
>> having to disable/reenable the compilation of synth_filter files in betw
On 24.01.2016 22:38, Michael Niedermayer wrote:
> On Sun, Jan 24, 2016 at 10:21:14PM +0100, Andreas Cadhalpun wrote:
>> The patch to use relative for DST_PATH should make FATE green again, as
>> no MSVC FATE client I saw builds across drives.
>
> Please either fix fate and the cases that the devel
On Sun, Jan 24, 2016 at 10:21:14PM +0100, Andreas Cadhalpun wrote:
>
> That's not very reasonable.
> Other changes also broke things that worked before.
> For example before commit 94c20de one could build ffmpeg with x265 version
> X265_BUILD 17, and afterwards it requires at least X265_BUILD 57.
On Sun, Jan 24, 2016 at 9:53 PM, James Almer wrote:
> Signed-off-by: James Almer
> ---
> This should make replacing the current dca decoder for foo86's easier, without
> having to disable/reenable the compilation of synth_filter files in between
> removal/addition commits.
>
While it would make
On 1/24/2016 6:21 PM, Andreas Cadhalpun wrote:
> On 24.01.2016 21:40, Paul B Mahol wrote:
>> On 1/24/16, James Almer wrote:
>>> It is absolutely unacceptable to say "do something else" as a "workaround"
>>> to a breakage introduced by a new feature.
>>>
>>> Unless you can fix this for every usecas
On Sun, Jan 24, 2016 at 10:21:14PM +0100, Andreas Cadhalpun wrote:
> On 24.01.2016 21:40, Paul B Mahol wrote:
> > On 1/24/16, James Almer wrote:
> >> It is absolutely unacceptable to say "do something else" as a "workaround"
> >> to a breakage introduced by a new feature.
> >>
> >> Unless you can
+1
I doubt anyone will complain or notice.
On 24 January 2016 at 16:33, Kieran Kunhya wrote:
> The internal encoder is superior to libvo-aacenc.
> ---
> configure | 6 --
> doc/encoders.texi | 25 --
> doc/general.texi | 8 --
> libavcodec/Makefile
On 1/24/16, Derek Buitenhuis wrote:
> On 1/24/2016 4:33 PM, Kieran Kunhya wrote:
>> The internal encoder is superior to libvo-aacenc.
>> ---
>
> Just about everything is.
>
> +1 to removing.
+1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http:
On Sun, Jan 24, 2016 at 10:09:49PM +0100, Michael Niedermayer wrote:
[...]
> fails to build:
> make distclean ; ../configure --enable-pthreads --arch=x86_32
> --target-os=linux --extra-cflags=-m32 --extra-ldflags=-m32
> --enable-cross-compile && make -j12
> In file included from libavfilter/pt
On 24.01.2016 21:40, Paul B Mahol wrote:
> On 1/24/16, James Almer wrote:
>> It is absolutely unacceptable to say "do something else" as a "workaround"
>> to a breakage introduced by a new feature.
>>
>> Unless you can fix this for every usecase that was working before this
>> in the very short te
On Sun, Jan 24, 2016 at 01:58:29PM +0100, Clément Bœsch wrote:
> On Wed, Jan 20, 2016 at 09:15:15PM -0300, James Almer wrote:
> > On 1/20/2016 7:46 PM, Clément Bœsch wrote:
> > > diff --git a/libavutil/thread.h b/libavutil/thread.h
> > > index 32ddf40..42430fb 100644
> > > --- a/libavutil/thread.h
Signed-off-by: James Almer
---
This should make replacing the current dca decoder for foo86's easier, without
having to disable/reenable the compilation of synth_filter files in between
removal/addition commits.
aarch64 and arm changes untested.
configure
On Sun, Jan 24, 2016 at 04:03:30PM +0100, Vittorio Gambaletta (VittGam) wrote:
> Hi,
>
> On 24/01/2016 12:33:51 CET, Michael Niedermayer wrote:
> >On Sun, Jan 24, 2016 at 05:23:22AM +0100, Vittorio Gambaletta (VittGam)
> >wrote:
> >>This commit makes it possible to add optional metadata (such as
On 24 January 2016 at 19:53, Paul B Mahol wrote:
> Hi,
>
> patch attached.
>
LGTM
sr_code will be 12 in case the samplerate is below 255000 (so the header
will be +1 bytes long) and 14 (> 12 so the header will be +2 bytes long) if
it's above. The previous code assumed the first part in the brac
On 1/24/16, James Almer wrote:
> On 1/24/2016 5:20 PM, Andreas Cadhalpun wrote:
>> On 24.01.2016 21:14, Ronald S. Bultje wrote:
>>> On Sun, Jan 24, 2016 at 3:10 PM, Andreas Cadhalpun <
>>> andreas.cadhal...@googlemail.com> wrote:
>>>
On 24.01.2016 20:54, Hendrik Leppkes wrote:
> On Sun, J
On 1/24/2016 5:20 PM, Andreas Cadhalpun wrote:
> On 24.01.2016 21:14, Ronald S. Bultje wrote:
>> On Sun, Jan 24, 2016 at 3:10 PM, Andreas Cadhalpun <
>> andreas.cadhal...@googlemail.com> wrote:
>>
>>> On 24.01.2016 20:54, Hendrik Leppkes wrote:
On Sun, Jan 24, 2016 at 8:51 PM, Andreas Cadhalpu
Le quintidi 5 pluviôse, an CCXXIV, Andreas Cadhalpun a écrit :
> No. It would have prevented the issue with hls.
Reacting to known attacks by ad-hoc hole-plugging is no way of building
proper security.
> But it's usually only used with local files.
I do not know that. Do you?
> Why not?
Becaus
On 24.01.2016 21:14, Ronald S. Bultje wrote:
> On Sun, Jan 24, 2016 at 3:10 PM, Andreas Cadhalpun <
> andreas.cadhal...@googlemail.com> wrote:
>
>> On 24.01.2016 20:54, Hendrik Leppkes wrote:
>>> On Sun, Jan 24, 2016 at 8:51 PM, Andreas Cadhalpun
>>> wrote:
On 24.01.2016 20:40, Hendrik Leppk
Hi,
On Sun, Jan 24, 2016 at 09:10:53PM +0100, Andreas Cadhalpun wrote:
> When the build environment has so many limitations some things just
> don't work.
>
> Why is it necessary to do MSVC out-of-tree builds across different
> drives?
It's not, but it used to work, and it doesn't work now. Thus
On Sun, Jan 24, 2016 at 8:54 PM, Hendrik Leppkes wrote:
> Its just how it works. Relative paths can't switch drive in windows
> path, no matter how many ..'s you chain.
> Once you hit the root of a drive, .. just redirects to itself, just
> like a unix / would, except that you get one per drive in
Hi,
On Sun, Jan 24, 2016 at 3:10 PM, Andreas Cadhalpun <
andreas.cadhal...@googlemail.com> wrote:
> On 24.01.2016 20:54, Hendrik Leppkes wrote:
> > On Sun, Jan 24, 2016 at 8:51 PM, Andreas Cadhalpun
> > wrote:
> >> On 24.01.2016 20:40, Hendrik Leppkes wrote:
> >>> Unfortunately that doesn't work
On 24.01.2016 20:54, Hendrik Leppkes wrote:
> On Sun, Jan 24, 2016 at 8:51 PM, Andreas Cadhalpun
> wrote:
>> On 24.01.2016 20:40, Hendrik Leppkes wrote:
>>> Unfortunately that doesn't work when there is no common path, ie.
>>> sources on another drive (say D:) as my build directory (say C:)
>>
>>
On Sun, Jan 24, 2016 at 8:51 PM, Andreas Cadhalpun
wrote:
> On 24.01.2016 20:40, Hendrik Leppkes wrote:
>> On Sun, Jan 24, 2016 at 7:27 PM, Andreas Cadhalpun
>> wrote:
>>> On 24.01.2016 17:14, Henrik Gramner wrote:
>>> I have a hard time believing that there are environments, where one
>>> can't
Hi,
patch attached.
From c450396407c7fb6b4fbe32a3d5c095ee6fc98d96 Mon Sep 17 00:00:00 2001
From: Paul B Mahol
Date: Sun, 24 Jan 2016 20:47:49 +0100
Subject: [PATCH] avcodec/flacenc: fix calculation of bits required in case of
custom sample rate
Signed-off-by: Paul B Mahol
---
libavcodec/flace
On 24.01.2016 20:40, Hendrik Leppkes wrote:
> On Sun, Jan 24, 2016 at 7:27 PM, Andreas Cadhalpun
> wrote:
>> On 24.01.2016 17:14, Henrik Gramner wrote:
>> I have a hard time believing that there are environments, where one
>> can't use absolute paths...
>
> Its about the combination of msys and i
On Sun, Jan 24, 2016 at 7:27 PM, Andreas Cadhalpun
wrote:
> On 24.01.2016 17:14, Henrik Gramner wrote:
>> On Sun, Jan 24, 2016 at 5:02 PM, Hendrik Leppkes wrote:
>>> Windows doesn't particularly care which slash direction you give it,
>>> so no, that changes nothing. I'm not quite sure why it fai
On 24.01.2016 20:20, Nicolas George wrote:
> Le quintidi 5 pluviôse, an CCXXIV, Andreas Cadhalpun a écrit :
>> The idea is to classify protocols as local (file, concat) or remote (http,
>> tcp).
>
> I am sorry, but this is completely broken.
No. It would have prevented the issue with hls.
> Fir
Le quintidi 5 pluviôse, an CCXXIV, Andreas Cadhalpun a écrit :
> The idea is to classify protocols as local (file, concat) or remote (http,
> tcp).
I am sorry, but this is completely broken. First, concat is not local.
Second, local/remote is not a relevant distinction for security.
Any design m
On 24.01.2016 16:03, Michael Niedermayer wrote:
> On Sun, Jan 24, 2016 at 03:37:24PM +0100, Andreas Cadhalpun wrote:
>> On 24.01.2016 03:42, Michael Niedermayer wrote:
>>> From: Michael Niedermayer
>>> diff --git a/libavformat/avformat.h b/libavformat/avformat.h
>>> index 4964263..2fb9130 100644
>
On 24.01.2016 19:37, Nicolas George wrote:
> Le quintidi 5 pluviôse, an CCXXIV, Andreas Cadhalpun a écrit :
>> I can't reproduce this. The path is only included in the debugging
>> information.
>> And that happened even more before my change.
>
> I just built in-tree with:
>
> ./configure && nic
Le quintidi 5 pluviôse, an CCXXIV, Michael Niedermayer a écrit :
> the argument is added, not out of strict need, (there already is a
> AVDictionary that can be used) but to make it clear that the author
> set the whitelist correctly. Also it simplifies the code compared
> to using the AVDictionary
Le quintidi 5 pluviôse, an CCXXIV, Andreas Cadhalpun a écrit :
> I can't reproduce this. The path is only included in the debugging
> information.
> And that happened even more before my change.
I just built in-tree with:
./configure && nice make -j 8, and then I get:
/tmp/ff2 $ grep /tmp/ff2 f
On 24.01.2016 18:58, Nicolas George wrote:
> Le quintidi 5 pluviôse, an CCXXIV, Ronald S. Bultje a écrit :
>> I think Andreas' original patch removed that so in-tree and out-tree builds
>> are bit-exact (i.e. the pathnames to in-tree source files are identical
>> between the two build types).
>>
>>
On 24.01.2016 17:14, Henrik Gramner wrote:
> On Sun, Jan 24, 2016 at 5:02 PM, Hendrik Leppkes wrote:
>> Windows doesn't particularly care which slash direction you give it,
>> so no, that changes nothing. I'm not quite sure why it fails with the
>> include path this way, maybe some msys shenanigan
Le quintidi 5 pluviôse, an CCXXIV, Ronald S. Bultje a écrit :
> I think Andreas' original patch removed that so in-tree and out-tree builds
> are bit-exact (i.e. the pathnames to in-tree source files are identical
> between the two build types).
>
> I don't know if that's worth it. Andreas seems t
It's inferior to fdk-aac and has an arguably more problematic
license.
---
LICENSE.md | 2 +-
configure | 5 --
doc/general.texi| 6 +-
doc/platform.texi | 2 +-
libavcodec/Makefile | 1 -
libavcodec/allcodecs.c | 1 -
libavcodec/libaacplus
On Sun, Jan 24, 2016 at 10:14 PM, Ronald S. Bultje wrote:
> Hi,
>
> On Sun, Jan 24, 2016 at 11:14 AM, Henrik Gramner wrote:
>
>> On Sun, Jan 24, 2016 at 5:02 PM, Hendrik Leppkes
>> wrote:
>> > Windows doesn't particularly care which slash direction you give it,
>> > so no, that changes nothing.
Hi,
On Sun, Jan 24, 2016 at 12:24 PM, Ronald S. Bultje
wrote:
> Hi,
>
> On Sun, Jan 24, 2016 at 12:13 PM, Paul B Mahol wrote:
>
>> On 1/24/16, Ronald S. Bultje wrote:
>> > Hi,
>> >
>> > On Sun, Jan 24, 2016 at 12:02 PM, Paul B Mahol
>> wrote:
>> >
>> >> On 1/24/16, Paul B Mahol wrote:
>> >>
Hi,
On Sun, Jan 24, 2016 at 12:13 PM, Paul B Mahol wrote:
> On 1/24/16, Ronald S. Bultje wrote:
> > Hi,
> >
> > On Sun, Jan 24, 2016 at 12:02 PM, Paul B Mahol wrote:
> >
> >> On 1/24/16, Paul B Mahol wrote:
> >> > On 1/24/16, Ronald S. Bultje wrote:
> >> >> Hi,
> >> >>
> >> >> On Sun, Jan 24
On 1/24/2016 4:33 PM, Kieran Kunhya wrote:
> The internal encoder is superior to libvo-aacenc.
> ---
Just about everything is.
+1 to removing.
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On Sun, 24 Jan 2016 16:12:15 +
Mark Thompson wrote:
> On 24/01/16 14:52, wm4 wrote:
> > On Sun, 24 Jan 2016 14:20:54 +
> > Mark Thompson wrote:
> >
> > ...
> >
> +
> +new_frame = av_frame_alloc();
> +if(!new_frame)
> +return AVERROR(ENOMEM);
>
On 1/24/16, Ronald S. Bultje wrote:
> Hi,
>
> On Sun, Jan 24, 2016 at 12:02 PM, Paul B Mahol wrote:
>
>> On 1/24/16, Paul B Mahol wrote:
>> > On 1/24/16, Ronald S. Bultje wrote:
>> >> Hi,
>> >>
>> >> On Sun, Jan 24, 2016 at 11:41 AM, Paul B Mahol
>> wrote:
>> >>
>> >>> patch attached.
>> >>
>>
Hi,
On Sun, Jan 24, 2016 at 12:02 PM, Paul B Mahol wrote:
> On 1/24/16, Paul B Mahol wrote:
> > On 1/24/16, Ronald S. Bultje wrote:
> >> Hi,
> >>
> >> On Sun, Jan 24, 2016 at 11:41 AM, Paul B Mahol
> wrote:
> >>
> >>> patch attached.
> >>
> >>
> >> I think that's wrong. buf_end is buf_start+s
On 1/24/16, Paul B Mahol wrote:
> On 1/24/16, Ronald S. Bultje wrote:
>> Hi,
>>
>> On Sun, Jan 24, 2016 at 11:41 AM, Paul B Mahol wrote:
>>
>>> patch attached.
>>
>>
>> I think that's wrong. buf_end is buf_start+size, so if size=1, this
>> allows
>> writing up to and including buf_start[1], whic
On Sun, Jan 24, 2016 at 5:51 PM, Paul B Mahol wrote:
> On 1/24/16, Ronald S. Bultje wrote:
>> Hi,
>>
>> On Sun, Jan 24, 2016 at 11:41 AM, Paul B Mahol wrote:
>>
>>> patch attached.
>>
>>
>> I think that's wrong. buf_end is buf_start+size, so if size=1, this allows
>> writing up to and including
On 1/24/16, Ronald S. Bultje wrote:
> Hi,
>
> On Sun, Jan 24, 2016 at 11:41 AM, Paul B Mahol wrote:
>
>> patch attached.
>
>
> I think that's wrong. buf_end is buf_start+size, so if size=1, this allows
> writing up to and including buf_start[1], which overflows size=1.
Assert happens otherwise w
Hi,
On Thu, Jan 21, 2016 at 12:50 PM, Paul B Mahol wrote:
> On 1/21/16, Ronald S. Bultje wrote:
> > ---
> > libavfilter/drawutils.c | 4
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/libavfilter/drawutils.c b/libavfilter/drawutils.c
> > index 3257192..f9a5eb8 100644
> > --- a/l
Hi,
On Sun, Jan 24, 2016 at 11:41 AM, Paul B Mahol wrote:
> patch attached.
I think that's wrong. buf_end is buf_start+size, so if size=1, this allows
writing up to and including buf_start[1], which overflows size=1.
Ronald
___
ffmpeg-devel mailing
Hi,
On Sun, Jan 24, 2016 at 11:14 AM, Henrik Gramner wrote:
> On Sun, Jan 24, 2016 at 5:02 PM, Hendrik Leppkes
> wrote:
> > Windows doesn't particularly care which slash direction you give it,
> > so no, that changes nothing. I'm not quite sure why it fails with the
> > include path this way, m
Hi,
patch attached.
From cdbc09536a21400fd2df1cc7d00d806eae84572a Mon Sep 17 00:00:00 2001
From: Paul B Mahol
Date: Sun, 24 Jan 2016 17:39:39 +0100
Subject: [PATCH] avcodec/put_bits: fix off by one
Signed-off-by: Paul B Mahol
---
libavcodec/put_bits.h | 2 +-
1 file changed, 1 insertion(+), 1
The internal encoder is superior to libvo-aacenc.
---
configure | 6 --
doc/encoders.texi | 25 --
doc/general.texi | 8 --
libavcodec/Makefile | 1 -
libavcodec/allcodecs.c| 1 -
libavcodec/libvo-aacenc.c | 200 --
On Sun, Jan 24, 2016 at 5:02 PM, Hendrik Leppkes wrote:
> Windows doesn't particularly care which slash direction you give it,
> so no, that changes nothing. I'm not quite sure why it fails with the
> include path this way, maybe some msys shenanigans.
> For fun and giggles, I hard-coded the corre
On 24/01/16 14:52, wm4 wrote:
> On Sun, 24 Jan 2016 14:20:54 +
> Mark Thompson wrote:
>
> ...
>
+
+new_frame = av_frame_alloc();
+if(!new_frame)
+return AVERROR(ENOMEM);
+
+av_vaapi_surface_pool_get(&ctx->pool, new_frame);
+
+av
On Sun, Jan 24, 2016 at 4:56 PM, Andreas Cadhalpun
wrote:
> On 24.01.2016 16:29, Hendrik Leppkes wrote:
>> On Sun, Jan 24, 2016 at 3:45 PM, Andreas Cadhalpun
>> wrote:
>>>
>>> So here the correct path is passed to '-Fo'.
>>>
D:\Multimedia\ffmpeg\develop\libavdevice\alldevices.c : fatal error
On 24.01.2016 16:29, Hendrik Leppkes wrote:
> On Sun, Jan 24, 2016 at 3:45 PM, Andreas Cadhalpun
> wrote:
>>
>> So here the correct path is passed to '-Fo'.
>>
>>> D:\Multimedia\ffmpeg\develop\libavdevice\alldevices.c : fatal error
>>> C1083: Cannot open compiler generated file:
>>> 'D:\Multimedia
On Tue, Dec 01, 2015 at 09:46:04PM -0800, Timothy Gu wrote:
> CCFLAGS is equivalent to CPPFLAGS + CFLAGS.
> ---
> common.mak | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Set pushed (some with improved commit messages).
[...]
Timothy
___
ffm
On Sun, Jan 24, 2016 at 3:45 PM, Andreas Cadhalpun
wrote:
>
> So here the correct path is passed to '-Fo'.
>
>> D:\Multimedia\ffmpeg\develop\libavdevice\alldevices.c : fatal error
>> C1083: Cannot open compiler generated file:
>> 'D:\Multimedia\ffmpeg\develop\D:\Multimedia\BuildEnv\MSYS2\Multimedi
On Sun, Jan 24, 2016 at 04:03:40PM +0100, Michael Niedermayer wrote:
> On Sun, Jan 24, 2016 at 03:37:24PM +0100, Andreas Cadhalpun wrote:
> > On 24.01.2016 03:42, Michael Niedermayer wrote:
[...]
> > > if ((ret = av_opt_set_dict(*puc, options)) < 0)
> > > goto fail;
> > > +
> > > +
Hi,
On 24/01/2016 12:33:51 CET, Michael Niedermayer wrote:
On Sun, Jan 24, 2016 at 05:23:22AM +0100, Vittorio Gambaletta (VittGam) wrote:
This commit makes it possible to add optional metadata (such as
"service_provider") to an mpegts output stream composed by multiple programs
(mpts).
This
On Sun, Jan 24, 2016 at 03:37:24PM +0100, Andreas Cadhalpun wrote:
> On 24.01.2016 03:42, Michael Niedermayer wrote:
> > From: Michael Niedermayer
> >
> > TODO: Docs
> > TODO: version bump
> >
> > Note to maintainers: update tools
> >
> > Note, testing and checking for missing changes is needed
Hi Ronald,
On 24.01.2016 14:06, Ronald S. Bultje wrote:
> On Sun, Jan 24, 2016 at 6:52 AM, Andreas Cadhalpun <
> andreas.cadhal...@googlemail.com> wrote:
>
>> Thus I object to reverting this before the regression caused by 31741ae is
>> fixed.
>
>
> This is ridiculous, I (who didn't break it an
Hi,
On 24/01/2016 12:01:38 CET, Michael Niedermayer wrote:
On Sun, Jan 24, 2016 at 06:06:36AM +0100, Vittorio Gambaletta (VittGam) wrote:
Signed-off-by: Vittorio Gambaletta
---
libavformat/mpegtsenc.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/libav
On Sun, 24 Jan 2016 14:20:54 +
Mark Thompson wrote:
> ...
> >> +static int vaapi_get_buffer(AVCodecContext *s, AVFrame *frame, int flags)
> >> +{
> >> +InputStream *ist = s->opaque;
> >> +VAAPIDecoderContext *ctx = ist->hwaccel_ctx;
> >> +AVFrame *new_frame;
> >> +
> >> +av_as
On 24.01.2016 13:38, Hendrik Leppkes wrote:
> On Sun, Jan 24, 2016 at 12:52 PM, Andreas Cadhalpun
>> Thus I object to reverting this before the regression caused by 31741ae is
>> fixed.
>
> So you break building of git master, and you try to leverage this to
> get your own agenda forward? Serious
On Sun, 24 Jan 2016 13:44:47 +
Mark Thompson wrote:
> ...
> >> +
> >> +vas = vaSyncSurface(hw_ctx->display, surface->id);
> >
> > Is this strictly needed? (I don't know.)
>
> It's definitely needed in some cases - the hwaccel decoder does not call
> vaSyncSurface(), so we have to s
1 - 100 of 145 matches
Mail list logo
