On 15/12/2016 19:01, Luca Barbato wrote:
> The null demuxer does not have a backing AVIOContext.
> ---
> avconv.c | 23 ---
> 1 file changed, 12 insertions(+), 11 deletions(-)
>
> diff --git a/avconv.c b/avconv.c
> index 5c31332..fe60625 100644
> --- a/avconv.c
> +++ b/avconv.
On Tue, Dec 20, 2016 at 5:54 PM, Hendrik Leppkes wrote:
> On Tue, Dec 20, 2016 at 5:48 PM, Vittorio Giovara
>>
>> No, as I said I can compromise in simply moving "undefined" state to
>> value 2, so that if there is a remote case where this is useful it can
>> be still achieved. If that would be ok
On 20/12/2016 17:38, Diego Biurrun wrote:
> Literally the same Make variables are stored in a different place
> now: libfoo/libfoo.version instead of config.mak, so I don't expect
> any difference. I will of course let this run through Oracle at some
> point.
Just to be on the safe side, but yes,
On Tue, 20 Dec 2016 18:15:56 +0100
"Diego Biurrun" wrote:
> Previously, all link-time dependencies were added for all libraries,
> resulting in bogus link-time dependencies since not all dependencies
> are shared across libraries. Also, in some cases like libavutil, not
> all dependencies were ta
Previously, all link-time dependencies were added for all libraries,
resulting in bogus link-time dependencies since not all dependencies
are shared across libraries. Also, in some cases like libavutil, not
all dependencies were taken into account, resulting in some cases of
underlinking.
To addre
On Tue, Dec 20, 2016 at 5:48 PM, Vittorio Giovara
wrote:
> On Tue, Dec 20, 2016 at 5:14 PM, Hendrik Leppkes wrote:
>> On Tue, Dec 20, 2016 at 4:59 PM, Vittorio Giovara
>> wrote:
>>> On Tue, Dec 20, 2016 at 4:10 PM, wm4 wrote:
On Tue, 20 Dec 2016 12:29:20 +0100
Vittorio Giovara wrote:
On Tue, Dec 20, 2016 at 5:14 PM, Hendrik Leppkes wrote:
> On Tue, Dec 20, 2016 at 4:59 PM, Vittorio Giovara
> wrote:
>> On Tue, Dec 20, 2016 at 4:10 PM, wm4 wrote:
>>> On Tue, 20 Dec 2016 12:29:20 +0100
>>> Vittorio Giovara wrote:
>>>
>>> Also h264/hevc are not the only video codecs on the
On Tue, Dec 20, 2016 at 05:32:23PM +0100, Luca Barbato wrote:
> On 20/12/2016 17:12, Diego Biurrun wrote:
> > On Tue, Dec 20, 2016 at 05:00:24PM +0100, Luca Barbato wrote:
> >> On 20/12/2016 15:34, Diego Biurrun wrote:
> >>> This moves work from the configure to the Make stage where it can
> >>> be
On 20/12/2016 17:12, Diego Biurrun wrote:
> On Tue, Dec 20, 2016 at 05:00:24PM +0100, Luca Barbato wrote:
>> On 20/12/2016 15:34, Diego Biurrun wrote:
>>> This moves work from the configure to the Make stage where it can
>>> be parallelized and ensures that shared libraries are built with
>>> the r
On 20/12/2016 17:03, Vittorio Giovara wrote:
> On Tue, Dec 20, 2016 at 3:34 PM, Diego Biurrun wrote:
>> This unclutters the top-level directory and groups related files together.
>> ---
>>
>> I'm tempted to also move config.h and config.asm. For the former, it would
>> make the #include name less
On Tue, Dec 20, 2016 at 4:59 PM, Vittorio Giovara
wrote:
> On Tue, Dec 20, 2016 at 4:10 PM, wm4 wrote:
>> On Tue, 20 Dec 2016 12:29:20 +0100
>> Vittorio Giovara wrote:
>>
>>> >>> Also h264/hevc are not the only video codecs on the planet. Implicit
>>> >>> defaults in the data type is the wrong w
On Tue, Dec 20, 2016 at 05:03:27PM +0100, Vittorio Giovara wrote:
> On Tue, Dec 20, 2016 at 3:34 PM, Diego Biurrun wrote:
> > This unclutters the top-level directory and groups related files together.
> > ---
> >
> > I'm tempted to also move config.h and config.asm. For the former, it would
> > ma
On Tue, Dec 20, 2016 at 05:00:24PM +0100, Luca Barbato wrote:
> On 20/12/2016 15:34, Diego Biurrun wrote:
> > This moves work from the configure to the Make stage where it can
> > be parallelized and ensures that shared libraries are built with
> > the right version number in the filename.
> > ---
On 20/12/2016 15:34, Diego Biurrun wrote:
>
> I'm tempted to also move config.h and config.asm. For the former, it
> would make the #include name less generic, which would be a good
> thing.
would be a bit too annoying for many and open to be debated to death.
I'm fine with this less impacting c
On Tue, Dec 20, 2016 at 3:34 PM, Diego Biurrun wrote:
> This unclutters the top-level directory and groups related files together.
> ---
>
> I'm tempted to also move config.h and config.asm. For the former, it would
> make the #include name less generic, which would be a good thing.
>
> .gitignor
On 20/12/2016 15:34, Diego Biurrun wrote:
> This moves work from the configure to the Make stage where it can
> be parallelized and ensures that pkgconfig files are updated when
> library versions change.
>
> Bug-Id: 449
> ---
Possibly fine.
___
libav-
On 20/12/2016 15:34, Diego Biurrun wrote:
> This moves work from the configure to the Make stage where it can
> be parallelized and ensures that shared libraries are built with
> the right version number in the filename.
> ---
> Makefile| 2 +-
> build/common.mak| 2 +-
> build/l
On Tue, Dec 20, 2016 at 4:10 PM, wm4 wrote:
> On Tue, 20 Dec 2016 12:29:20 +0100
> Vittorio Giovara wrote:
>
>> >>> Also h264/hevc are not the only video codecs on the planet. Implicit
>> >>> defaults in the data type is the wrong way to go about this, it takes
>> >>> away any kind of flexibility
On Tue, Dec 20, 2016 at 3:09 PM, Anton Khirnov wrote:
> Quoting Vittorio Giovara (2016-12-20 12:29:20)
>> mm would you be okay with moving unspecified to 2 so that at least the
>> most common usecase can be mapped to a bool?
>
> I think the API should be designed in such a way that it is hard to u
On Fri, Dec 16, 2016 at 11:05:41AM +0100, Steve Lhomme wrote:
> --- a/Makefile
> +++ b/Makefile
> @@ -85,6 +85,7 @@ OBJS-avconv += avconv_opt.o
> avconv_filter.o
> OBJS-avconv-$(CONFIG_LIBMFX) += avconv_qsv.o
> OBJS-avconv-$(CONFIG_VAAPI) += avconv_vaapi.o
> OBJS-avconv-$(C
On Tue, 20 Dec 2016 16:04:47 +0100
Nicolas George wrote:
> Le decadi 30 frimaire, an CCXXV, wm4 a écrit :
> > Well, what do you want to work towards? I'd say either split the git
> > repo
>
> There is a lot of work before that:
>
> ~/tmp/git/libav $ git grep avpriv | wc -l
> 960
True.
> Can
Le decadi 30 frimaire, an CCXXV, wm4 a écrit :
> Well, what do you want to work towards? I'd say either split the git
> repo
There is a lot of work before that:
~/tmp/git/libav $ git grep avpriv | wc -l
960
Can somebody explain what the separation between libraries is good for
anyway?
I can see
On Tue, 20 Dec 2016 12:29:20 +0100
Vittorio Giovara wrote:
> >>> Also h264/hevc are not the only video codecs on the planet. Implicit
> >>> defaults in the data type is the wrong way to go about this, it takes
> >>> away any kind of flexibility for no real gain.
> >>
> >> What kind of flexibili
On Mon, 19 Dec 2016 13:04:38 +0100
Anton Khirnov wrote:
> Quoting Steve Lhomme (2016-12-16 11:05:40)
> > From: Steve Lhomme
> >
> > +ZeroMemory(&texDesc, sizeof(texDesc));
>
> Isn't this just memset(.., 0, ..)?
He should use "D3D11_TEXTURE2D_DESC texDesc = {0};" in the first place.
For
On Mon, 19 Dec 2016 12:57:23 +0100
Anton Khirnov wrote:
> Quoting Diego Biurrun (2016-12-06 23:15:48)
> > On Tue, Dec 06, 2016 at 04:23:09PM -0500, Vittorio Giovara wrote:
> > > On Tue, Dec 6, 2016 at 2:43 AM, Diego Biurrun wrote:
> > > > On Tue, Dec 06, 2016 at 12:27:22AM -0500, Vittorio Gi
On Fri, Dec 16, 2016 at 11:05:39AM +0100, Steve Lhomme wrote:
>
> avconv_dxva.h has to be included and misc. typedefs have to be set to use the
That file name has changed.
> --- /dev/null
> +++ b/avconv_directx_va_template.c
> @@ -0,0 +1,294 @@
> +
> +#ifndef AVCONV_DXVA_H
> +#define AVCONV_DXVA
This moves work from the configure to the Make stage where it can
be parallelized and ensures that pkgconfig files are updated when
library versions change.
Bug-Id: 449
---
Makefile| 3 +-
build/.gitignore| 1 +
build/library.mak | 7 +++--
build/pkgco
This unclutters the top-level directory and groups related files together.
---
I'm tempted to also move config.h and config.asm. For the former, it would
make the #include name less generic, which would be a good thing.
.gitignore | 3 ++-
Makefile
This moves work from the configure to the Make stage where it can
be parallelized and ensures that shared libraries are built with
the right version number in the filename.
---
Makefile| 2 +-
build/common.mak| 2 +-
build/library.mak | 5 +
build/libversion.sh | 15 ++
Howdy!
I finally put the finishing touches on a patch that I have had cooking
for a long time. I think it was Rémi that put me on to the fact that
we do less than we should when library version numbers change a long
time ago. I filed the issue away as Bugzilla #449 to be addressed on
some futu
Quoting Vittorio Giovara (2016-12-20 12:29:20)
> On Tue, Dec 20, 2016 at 12:22 PM, Hendrik Leppkes wrote:
> > On Tue, Dec 20, 2016 at 12:18 PM, Vittorio Giovara
> > wrote:
> >> On Tue, Dec 20, 2016 at 12:12 PM, Hendrik Leppkes
> >> wrote:
> >>> On Tue, Dec 20, 2016 at 12:07 PM, Vittorio Giovara
On Tue, Dec 20, 2016 at 12:22 PM, Hendrik Leppkes wrote:
> On Tue, Dec 20, 2016 at 12:18 PM, Vittorio Giovara
> wrote:
>> On Tue, Dec 20, 2016 at 12:12 PM, Hendrik Leppkes
>> wrote:
>>> On Tue, Dec 20, 2016 at 12:07 PM, Vittorio Giovara
>>> wrote:
On Tue, Dec 20, 2016 at 10:40 AM, Hendrik
On Tue, Dec 20, 2016 at 12:18 PM, Vittorio Giovara
wrote:
> On Tue, Dec 20, 2016 at 12:12 PM, Hendrik Leppkes wrote:
>> On Tue, Dec 20, 2016 at 12:07 PM, Vittorio Giovara
>> wrote:
>>> On Tue, Dec 20, 2016 at 10:40 AM, Hendrik Leppkes
>>> wrote:
On Tue, Dec 20, 2016 at 9:19 AM, Vittorio G
On Tue, Dec 20, 2016 at 12:12 PM, Hendrik Leppkes wrote:
> On Tue, Dec 20, 2016 at 12:07 PM, Vittorio Giovara
> wrote:
>> On Tue, Dec 20, 2016 at 10:40 AM, Hendrik Leppkes
>> wrote:
>>> On Tue, Dec 20, 2016 at 9:19 AM, Vittorio Giovara
>>> wrote:
This is the assumption that is made everyw
On Tue, Dec 20, 2016 at 12:07 PM, Vittorio Giovara
wrote:
> On Tue, Dec 20, 2016 at 10:40 AM, Hendrik Leppkes wrote:
>> On Tue, Dec 20, 2016 at 9:19 AM, Vittorio Giovara
>> wrote:
>>> This is the assumption that is made everywhere in the codebase
>>> and in several specifications too. The added
On Tue, Dec 20, 2016 at 10:40 AM, Hendrik Leppkes wrote:
> On Tue, Dec 20, 2016 at 9:19 AM, Vittorio Giovara
> wrote:
>> This is the assumption that is made everywhere in the codebase
>> and in several specifications too. The added benefit is that any
>> variable referencing range can now be simp
Quoting Hendrik Leppkes (2016-12-20 10:40:41)
> On Tue, Dec 20, 2016 at 9:19 AM, Vittorio Giovara
> wrote:
> > This is the assumption that is made everywhere in the codebase
> > and in several specifications too. The added benefit is that any
> > variable referencing range can now be simply consid
On Tue, Dec 20, 2016 at 9:19 AM, Vittorio Giovara
wrote:
> This is the assumption that is made everywhere in the codebase
> and in several specifications too. The added benefit is that any
> variable referencing range can now be simply considered a boolean.
>
> Signed-off-by: Vittorio Giovara
I
This is the assumption that is made everywhere in the codebase
and in several specifications too. The added benefit is that any
variable referencing range can now be simply considered a boolean.
Signed-off-by: Vittorio Giovara
---
This is the first patch I had in mind for the transition period af
39 matches
Mail list logo
