On Sat, 12 May 2012, Luca Barbato wrote:
On 12/05/12 15:47, Martin Storsjö wrote:
On Sat, 12 May 2012, Luca Barbato wrote:
On 12/05/12 12:35, Martin Storsjö wrote:
Is this "type => 'foo', text => 'bar'" structure standardized anywhere
or used by any other existing application?
What about
On Sat, May 12, 2012 at 06:12:35PM +0200, Anton Khirnov wrote:
> ---
> libavfilter/avfiltergraph.c | 120
> +--
> 1 file changed, 60 insertions(+), 60 deletions(-)
OK
Diego
___
libav-devel mailing list
libav-de
On Sat, May 12, 2012 at 06:12:36PM +0200, Anton Khirnov wrote:
> Most of the code will be shared for both audio and video version.
> ---
> libavfilter/Makefile |2 +-
> libavfilter/{vsrc_buffer.c => buffersrc.c} |0
> 2 files changed, 1 insertion(+), 1 deletion(-)
>
On Sat, May 12, 2012 at 08:54:38PM +0200, Robert Nagy wrote:
> The previous update to PATCH 1/2 broke PATCH 2/2, this one should be ok.
>
> --- a/libavfilter/vf_yadif.c
> +++ b/libavfilter/vf_yadif.c
> @@ -218,14 +218,16 @@ static void return_frame(AVFilterContext *ctx, int
> is_second)
> fi
On Sat, May 12, 2012 at 07:52:02PM +0200, Robert Nagy wrote:
>
> --- a/libavfilter/vf_yadif.c
> +++ b/libavfilter/vf_yadif.c
> @@ -293,10 +293,19 @@ static int request_frame(AVFilterLink *link)
>
> do {
> -int ret;
> -
> -if ((ret = avfilter_request_frame(link->src->inputs[0
On Sat, May 12, 2012 at 07:56:27AM -0700, Luca Barbato wrote:
> On 12/05/12 07:41, Diego Biurrun wrote:
> > On Tue, May 08, 2012 at 09:40:36PM +0200, Diego Biurrun wrote:
> >> On Tue, Dec 13, 2011 at 12:32:19AM +0100, Diego Biurrun wrote:
> >>> ---
> >>> Makefile |4 +++-
> >>> doc/d
So who is coming?
I expect to be there from start to finish. Janne will be away from
Friday noon, Mans Saturday noon.
Do we have posters or so to decorate the booth? We'll need a small
switch and a few network cables; Club Mate can be bought locally.
I'll suggest that we try our sample fixing
Vitor Sessak writes:
> On 05/12/2012 02:17 PM, Mans Rullgard wrote:
>> The codecs in this file are tested elsewhere. The container differs
>> from psx-str-demux in that it has a RIFF header, which the new name
>> reflects.
>
> This test is AFAIK the only one who tests the decode_dc() path in the
Diego Biurrun writes:
> On Fri, May 11, 2012 at 06:35:32PM +0100, Mans Rullgard wrote:
>> These two files use the same audio codec so only one test for
>> this is needed.
>>
>> Signed-off-by: Mans Rullgard
>> ---
>> tests/fate/demux.mak |6 --
>> tests/fate/dpcm.mak
On Sun, May 13, 2012 at 04:46:50PM +0100, Måns Rullgård wrote:
> Diego Biurrun writes:
>
> > On Fri, May 11, 2012 at 06:35:32PM +0100, Mans Rullgard wrote:
> >> These two files use the same audio codec so only one test for
> >> this is needed.
> >>
> >> Signed-off-by: Mans Rullgard
> >> ---
> >
On 08/05/12 21:46, Anton Khirnov wrote:
> This is easier to parse with automated tools.
> ---
> avprobe.c|6 +-
> tests/fate/probe.mak |8
> 2 files changed, 9 insertions(+), 5 deletions(-)
>
Ok.
--
Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero
__
On 12/05/2012 8:17 AM, Mans Rullgard wrote:
> The codec (adpcm-ima-ws) is tested elsewhere. Using framecrc output
> provides more information than a single md5 if something goes wrong.
>
> Signed-off-by: Mans Rullgard
> ---
Makes sense, looks good.
- Derek
_
On 12/05/12 09:12, Anton Khirnov wrote:
> ---
> libavfilter/avfilter.h | 16 +++
> libavfilter/formats.c | 280
> +++-
> libavfilter/formats.h | 78 ++
> 3 files changed, 299 insertions(+), 75 deletions(-)
> create mode 100644 libavf
0001-yadif-Improve-pts-accuracy.patch
Description: Binary data
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
0002-yadif-Flush-filter-on-eof.patch
Description: Binary data
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
On 12/05/12 09:12, Anton Khirnov wrote:
> ---
> libavfilter/af_resample.c | 11 ++
> libavfilter/avfilter.c | 21 +++-
> libavfilter/avfiltergraph.c | 255
> +--
> libavfilter/defaults.c | 72 +++-
> 4 files changed, 292 insertion
On 12/05/12 09:12, Anton Khirnov wrote:
> ---
> libavfilter/buffersrc.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavfilter/buffersrc.c b/libavfilter/buffersrc.c
> index 1ace368..c7284c1 100644
> --- a/libavfilter/buffersrc.c
> +++ b/libavfilter/buffersrc.c
> @
On 12/05/12 09:12, Anton Khirnov wrote:
> It's the same as av_vsrc_buffer_add_frame(), except it doesn't take pts
> or pixel_aspect parameters. Those are read from AVFrame.
>
> Deprecate av_vsrc_buffer_add_frame().
> ---
> avconv.c|3 +--
> libavfilter/buffersrc.c | 20 +
On 12/05/12 09:12, Anton Khirnov wrote:
> ---
> doc/filters.texi | 27 ++
> libavfilter/allfilters.c |4 +
> libavfilter/buffersrc.c | 211
> +-
> 3 files changed, 222 insertions(+), 20 deletions(-)
>
Ok
--
Luca Barbato
Gentoo/
On 12/05/12 09:12, Anton Khirnov wrote:
> ---
> doc/filters.texi |7
> libavfilter/allfilters.c |4 ++
> libavfilter/buffersink.c | 102
> --
> libavfilter/buffersink.h | 21 +-
> 4 files changed, 129 insertions(+), 5 del
On 12/05/12 09:12, Anton Khirnov wrote:
> Based on a patch by Mina Nagy Zaki
> ---
> doc/filters.texi | 26
> libavfilter/Makefile |1 +
> libavfilter/af_aformat.c | 148
> ++
> libavfilter/allfilters.c |1 +
> 4 files c
On 12/05/12 09:12, Anton Khirnov wrote:
> ---
> doc/filters.texi | 19
> libavfilter/Makefile |2 +
> libavfilter/af_asyncts.c | 237
> ++
> libavfilter/allfilters.c |1 +
> 4 files changed, 259 insertions(+)
> create mode 1
On 12/05/12 09:12, Anton Khirnov wrote:
> The FATE changes are all off-by-one due to different rounding being used
> (lrintf vs av_rescale_q).
> ---
> avconv.c | 806
> -
> doc/avconv.texi |5 +
> tests/ref/fate/amv| 20
On 12/05/12 09:12, Anton Khirnov wrote:
> Deprecate -async.
> ---
> avconv.c| 27 +++
> doc/avconv.texi |1 +
> 2 files changed, 28 insertions(+)
I'm a little undecided on deprecating now.
lu
--
Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero
__
Il 12/05/2012 01:15, Vitor Sessak ha scritto:
>
> Here is a version with 128-bit regs (again, completely untested).
The patch seems to require a new series that factors "x86: use more
standard construct for setting ASM funcitons in FFT code" into it.
Probably you should resend the series.
If you
On 05/13/2012 11:40 PM, Diego Elio Pettenò wrote:
Il 12/05/2012 01:15, Vitor Sessak ha scritto:
Here is a version with 128-bit regs (again, completely untested).
The patch seems to require a new series that factors "x86: use more
standard construct for setting ASM funcitons in FFT code" into
On 13/05/12 22:19, Vitor Sessak wrote:
> On 05/13/2012 11:40 PM, Diego Elio Pettenò wrote:
>> Il 12/05/2012 01:15, Vitor Sessak ha scritto:
>>>
>>> Here is a version with 128-bit regs (again, completely untested).
>>
>> The patch seems to require a new series that factors "x86: use more
>> standard
27 matches
Mail list logo
