On Tue, 12 Apr 2011, Ronald S. Bultje wrote:
> Hi,
>
> On Tue, Apr 12, 2011 at 4:08 AM, Martin Storsjö wrote:
> > This should hopefully fix roundup issue 2586.
> >
> > This commit only implements it in the demuxer, not in the
> > protocol handler. If desired, some of the code could be
> > refact
On 04/12/2011 11:03 PM, Ronald S. Bultje wrote:
> This one can use a lot more cleanup.
I know and stated on the commit message =)
> Big ones: in x86/swscale_template.c, there's a bunch of #if
> COMPILE_TEMPLATE_MMX. They are unnecessary, all of 3dnow/mmx/mmx2 set
> COMPILE_TEMPLATE_MMX, and thus
On Tue, 12 Apr 2011, Ronald S. Bultje wrote:
> On Tue, Apr 12, 2011 at 3:44 AM, Martin Storsjö wrote:
> > ---
> > libavcodec/libvo-aacenc.c | 18 ++
> > 1 files changed, 10 insertions(+), 8 deletions(-)
> >
> > diff --git a/libavcodec/libvo-aacenc.c b/libavcodec/libvo-aacenc.c
On 04/12/2011 11:32 PM, Ronald S. Bultje wrote:
> Hi,
>
> On Sun, Apr 10, 2011 at 2:04 PM, Luca Barbato wrote:
>> Refer to the current submission policy and refer to FATE in the
>> Regression Test section.
>> ---
>> doc/developer.texi | 221
>> ++
On 04/12/2011 11:26 PM, Alexander Strange wrote:
>
> On Apr 11, 2011, at 5:07 AM, Luca Barbato wrote:
>
>> This unbreak darwin.
>
> When was it broken?
Apparently having the pointers on a separate file upsets it. this patch
and the one causing the issue got dropped in the new patchset.
lu
--
On Tue, 12 Apr 2011, Ronald S. Bultje wrote:
> On Tue, Apr 12, 2011 at 3:57 AM, Martin Storsjö wrote:
> > This code could be executed if the demuxer reads more than one
> > segment before returning from av_open_input_stream.
> > ---
> > libavformat/applehttp.c | 11 +++
> > 1 files cha
On Sun, Apr 10, 2011 at 07:42:46AM -0400, Ronald S. Bultje wrote:
> Hi,
>
> On Sun, Apr 10, 2011 at 4:09 AM, Anton Khirnov wrote:
> > On Sat, Apr 09, 2011 at 08:42:10AM -0400, Ronald S. Bultje wrote:
> >> Hi,
> >>
> >> On Sat, Apr 9, 2011 at 7:50 AM, Reinhard Tartler
> >> wrote:
> >> > From: Ge
On Sat, Apr 09, 2011 at 09:59:37PM -0400, Ronald S. Bultje wrote:
> Hi,
>
> On Sat, Apr 9, 2011 at 7:49 AM, Reinhard Tartler wrote:
> > From: Stefano Sabatini
> >
> > ---
> > doc/filters.texi | 3 +--
> > 1 files changed, 1 insertions(+), 2 deletions(-)
>
> Here also, please squash with 7.
From: Stefano Sabatini
With the following additions:
* support to anti-aliased glyph rendering
* support to UTF-8 text and Unicode chars rendering
* support for RGB packed formats
* fix minor errors and typos in the filter description
* extend/clarify examples in the filter description
Signed-of
On Mon, Apr 04, 2011 at 10:01:43AM -0700, Alex Converse wrote:
> On Tue, Mar 22, 2011 at 10:31 PM, Anton Khirnov wrote:
> > From: Michael Niedermayer
> >
> > ---
> > libavfilter/vf_yadif.c | 4 ++--
> > 1 files changed, 2 insertions(+), 2 deletions(-)
> >
>
> OK
Do you know what it's needed
On Tue, Apr 12, 2011 at 04:00:34PM -0400, Ronald S. Bultje wrote:
> Hi,
>
> On Tue, Apr 12, 2011 at 3:36 PM, Anton Khirnov wrote:
> > On Tue, Apr 12, 2011 at 07:34:59PM +0200, Stefano Sabatini wrote:
> >> On date Tuesday 2011-04-12 10:23:54 +0200, Anton Khirnov wrote:
> >> > From: Stefano Sabatin
Hi, I'm newbie here.
No Unicode API in FFmpeg make me very sad (this is important only for
Windows applications).
I partially investigate the current i/o and found that creating Unicode
versions for major functions cause to create the tons of another stuff.
But I found another 'stupid' way - I def
On Wed, Apr 13, 2011 at 01:33:47AM +0200, Alberto Delmás wrote:
> In the current code, the display extension info (if present) is used
> to set avctx->width and height. These in turn determine the size of
> the allocated picture buffer, so if they're too small the decoder will
> write past its end.
Hi,
On Mon, Apr 4, 2011 at 11:35 AM, Justin Ruggles
wrote:
> On 04/04/2011 11:30 AM, Ronald S. Bultje wrote:
>> On Mon, Apr 4, 2011 at 3:21 PM, Justin Ruggles
>> wrote:
>>> On 04/02/2011 01:19 PM, Anton Khirnov wrote:
+#if FF_API_FLAC_GLOBAL_OPTS
/**
* Determines which
Hi Martin,
On Tue, Apr 12, 2011 at 3:57 AM, Martin Storsjö wrote:
> This code could be executed if the demuxer reads more than one
> segment before returning from av_open_input_stream.
> ---
> libavformat/applehttp.c | 11 +++
> 1 files changed, 7 insertions(+), 4 deletions(-)
Is this
Hi,
On Sat, Apr 9, 2011 at 11:14 PM, Luca Barbato wrote:
> Today I planned to add to av_log() some optional features in order to
> track file, line and function.
>
> I noticed some strange code introduced with this commit[1]
>
> if(avc && avc->version >= (50<<16 | 15<<8 | 2) &&
> avc->log_level_o
Hi,
On Tue, Apr 12, 2011 at 3:44 AM, Luca Barbato wrote:
> On 04/09/2011 03:59 PM, Kostya Shishkov wrote:
>> This implementation should work fine with multiple side information types
>> present.
>
>> + uint8_t **side_data;
>> + int *side_data_sizes;
>> + int *side_data_types;
>
Hi,
On Tue, Apr 12, 2011 at 3:44 AM, Martin Storsjö wrote:
> ---
> libavcodec/libvo-aacenc.c | 18 ++
> 1 files changed, 10 insertions(+), 8 deletions(-)
>
> diff --git a/libavcodec/libvo-aacenc.c b/libavcodec/libvo-aacenc.c
> index 3c7dde7..7c1738d 100644
> --- a/libavcodec/li
Hi,
On Tue, Apr 12, 2011 at 4:08 AM, Martin Storsjö wrote:
> This should hopefully fix roundup issue 2586.
>
> This commit only implements it in the demuxer, not in the
> protocol handler. If desired, some of the code could be
> refactored to be shared by both implementations.
>
> Is there any us
Hi,
On Tue, Apr 12, 2011 at 7:33 PM, Alberto Delmás wrote:
> In the current code, the display extension info (if present) is used
> to set avctx->width and height. These in turn determine the size of
> the allocated picture buffer, so if they're too small the decoder will
> write past its end.
>
Hi,
On Tue, Apr 12, 2011 at 7:38 PM, Alberto Delmás wrote:
> This prevents crashes on malloc failures and the like, and helps catch
> other problems earlier.
Looks OK, queued locally.
Ronald
___
libav-devel mailing list
libav-devel@libav.org
https://l
Hi,
On Tue, Apr 12, 2011 at 5:58 PM, Martin Storsjö wrote:
> ---
> libavcodec/libopencore-amr.c | 18 --
> libavcodec/libvo-amrwbenc.c | 17 ++---
> 2 files changed, 14 insertions(+), 21 deletions(-)
[..]
> -static const char nb_bitrate_unsupported[] =
> - "bi
Hi,
On Tue, Apr 12, 2011 at 5:58 PM, Martin Storsjö wrote:
> The bitrate modes are equal to the array indices.
> ---
> libavcodec/libvo-amrwbenc.c | 20
> 1 files changed, 4 insertions(+), 16 deletions(-)
OK.
Ronald
___
libav-d
Hi,
On Tue, Apr 12, 2011 at 5:58 PM, Martin Storsjö wrote:
> ---
> libavcodec/libopencore-amr.c | 20
> 1 files changed, 8 insertions(+), 12 deletions(-)
OK.
Ronald
___
libav-devel mailing list
libav-devel@libav.org
https://lis
Hi,
On Tue, Apr 12, 2011 at 5:58 PM, Martin Storsjö wrote:
> ---
> libavcodec/libopencore-amr.c | 8 +++-
> 1 files changed, 3 insertions(+), 5 deletions(-)
OK.
Ronald
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/
Hi,
On Tue, Apr 12, 2011 at 5:58 PM, Martin Storsjö wrote:
> ---
> libavcodec/libopencore-amr.c | 26 +-
> libavcodec/libvo-amrwbenc.c | 6 +++---
> 2 files changed, 16 insertions(+), 16 deletions(-)
OK.
Ronald
___
libav
Hi,
On Tue, Apr 12, 2011 at 5:58 PM, Martin Storsjö wrote:
> ---
> libavcodec/libopencore-amr.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/libavcodec/libopencore-amr.c b/libavcodec/libopencore-amr.c
> index 8a8c18b..c04cf99 100644
> --- a/libavcodec/libopencor
Hi,
On Tue, Apr 12, 2011 at 5:58 PM, Martin Storsjö wrote:
> ---
> libavcodec/libopencore-amr.c | 16
> libavcodec/libvo-amrwbenc.c | 8
> 2 files changed, 12 insertions(+), 12 deletions(-)
All OK.
> if (avctx->sample_rate != 8000) {
> av_log(avctx,
This prevents crashes on malloc failures and the like, and helps catch
other problems earlier.
From 5bf887f41173f0e94bf61d663d9545ff16c4b753 Mon Sep 17 00:00:00 2001
From: Alberto Delmas
Date: Mon, 12 Apr 2010 23:16:12 +0200
Subject: [PATCH] Check for successful h263 init in msmpeg4 init
---
lib
Hi,
On Tue, Apr 12, 2011 at 5:58 PM, Martin Storsjö wrote:
> ---
> libavcodec/libopencore-amr.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/libavcodec/libopencore-amr.c b/libavcodec/libopencore-amr.c
> index 13594fa..e6958c9 100644
> --- a/libavcodec/libopencor
Hi,
On Tue, Apr 12, 2011 at 5:58 PM, Martin Storsjö wrote:
> ---
> libavcodec/libopencore-amr.c | 5 -
> 1 files changed, 0 insertions(+), 5 deletions(-)
>
> diff --git a/libavcodec/libopencore-amr.c b/libavcodec/libopencore-amr.c
> index 0e467a6..13594fa 100644
> --- a/libavcodec/libopen
Hi,
On Tue, Apr 12, 2011 at 5:58 PM, Martin Storsjö wrote:
> ---
> libavcodec/libopencore-amr.c | 15 ---
> 1 files changed, 0 insertions(+), 15 deletions(-)
[..]
> diff --git a/libavcodec/libopencore-amr.c b/libavcodec/libopencore-amr.c
[..]
> - /* av_log(NULL, AV_LOG_DEBUG, "a
Hi,
On Tue, Apr 12, 2011 at 5:58 PM, Martin Storsjö wrote:
> ---
> libavcodec/libopencore-amr.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/libavcodec/libopencore-amr.c b/libavcodec/libopencore-amr.c
> index c11c924..52dfe10 100644
> --- a/libavcodec/libopencor
Hi,
On Tue, Apr 12, 2011 at 5:58 PM, Martin Storsjö wrote:
> This parts are heritage from the encoder part from the old
> libamr code removed in SVN rev 19365.
> ---
> libavcodec/libopencore-amr.c | 11 ---
> 1 files changed, 0 insertions(+), 11 deletions(-)
OK.
(Although in a way it
In the current code, the display extension info (if present) is used
to set avctx->width and height. These in turn determine the size of
the allocated picture buffer, so if they're too small the decoder will
write past its end.
I've uploaded a sample illustrating the issue to incoming/VC1_DEI_cras
Hi,
On Tue, Apr 12, 2011 at 9:56 AM, Luca Barbato wrote:
> On 4/12/11 3:20 PM, Ronald S. Bultje wrote:
>> This allows for more reproducible results when using multi-threading.
>
> Fine for me.
Pushed.
Ronald
___
libav-devel mailing list
libav-devel@li
---
libavcodec/libopencore-amr.c | 18 --
libavcodec/libvo-amrwbenc.c | 17 ++---
2 files changed, 14 insertions(+), 21 deletions(-)
diff --git a/libavcodec/libopencore-amr.c b/libavcodec/libopencore-amr.c
index e3708f1..9575916 100644
--- a/libavcodec/libopencore
The bitrate modes are equal to the array indices.
---
libavcodec/libvo-amrwbenc.c | 20
1 files changed, 4 insertions(+), 16 deletions(-)
diff --git a/libavcodec/libvo-amrwbenc.c b/libavcodec/libvo-amrwbenc.c
index cfd1bac..e55fdc6 100644
--- a/libavcodec/libvo-amrwbenc.c
+
---
libavcodec/libopencore-amr.c | 20
1 files changed, 8 insertions(+), 12 deletions(-)
diff --git a/libavcodec/libopencore-amr.c b/libavcodec/libopencore-amr.c
index a5c9269..e3708f1 100644
--- a/libavcodec/libopencore-amr.c
+++ b/libavcodec/libopencore-amr.c
@@ -53,14 +5
---
libavcodec/libopencore-amr.c | 26 +-
libavcodec/libvo-amrwbenc.c |6 +++---
2 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/libavcodec/libopencore-amr.c b/libavcodec/libopencore-amr.c
index 8cee785..a5c9269 100644
--- a/libavcodec/libopencore-am
---
libavcodec/libopencore-amr.c |8 +++-
1 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/libavcodec/libopencore-amr.c b/libavcodec/libopencore-amr.c
index c04cf99..8cee785 100644
--- a/libavcodec/libopencore-amr.c
+++ b/libavcodec/libopencore-amr.c
@@ -110,7 +110,6 @@ stati
---
libavcodec/libopencore-amr.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/libavcodec/libopencore-amr.c b/libavcodec/libopencore-amr.c
index 8a8c18b..c04cf99 100644
--- a/libavcodec/libopencore-amr.c
+++ b/libavcodec/libopencore-amr.c
@@ -53,7 +53,7 @@ typedef struc
---
libavcodec/libopencore-amr.c | 16
libavcodec/libvo-amrwbenc.c |8
2 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/libavcodec/libopencore-amr.c b/libavcodec/libopencore-amr.c
index e6958c9..8a8c18b 100644
--- a/libavcodec/libopencore-amr.c
+++
---
libavcodec/libopencore-amr.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/libavcodec/libopencore-amr.c b/libavcodec/libopencore-amr.c
index 13594fa..e6958c9 100644
--- a/libavcodec/libopencore-amr.c
+++ b/libavcodec/libopencore-amr.c
@@ -82,7 +82,7 @@ static av_col
---
libavcodec/libopencore-amr.c |5 -
1 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/libavcodec/libopencore-amr.c b/libavcodec/libopencore-amr.c
index 0e467a6..13594fa 100644
--- a/libavcodec/libopencore-amr.c
+++ b/libavcodec/libopencore-amr.c
@@ -219,11 +219,6 @@ AVCodec
---
libavcodec/libopencore-amr.c | 15 ---
1 files changed, 0 insertions(+), 15 deletions(-)
diff --git a/libavcodec/libopencore-amr.c b/libavcodec/libopencore-amr.c
index 52dfe10..0e467a6 100644
--- a/libavcodec/libopencore-amr.c
+++ b/libavcodec/libopencore-amr.c
@@ -71,7 +71,6 @@
---
libavcodec/libopencore-amr.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/libavcodec/libopencore-amr.c b/libavcodec/libopencore-amr.c
index c11c924..52dfe10 100644
--- a/libavcodec/libopencore-amr.c
+++ b/libavcodec/libopencore-amr.c
@@ -73,7 +73,7 @@ static int ge
This parts are heritage from the encoder part from the old
libamr code removed in SVN rev 19365.
---
libavcodec/libopencore-amr.c | 11 ---
1 files changed, 0 insertions(+), 11 deletions(-)
diff --git a/libavcodec/libopencore-amr.c b/libavcodec/libopencore-amr.c
index a7abe26..c11c924 1
On Mon, Mar 28, 2011 at 6:02 PM, Justin Ruggles
wrote:
> On 03/28/2011 06:14 PM, Alex Converse wrote:
>
>> On Mon, Mar 28, 2011 at 2:37 PM, Justin Ruggles
>> wrote:
>>> On 03/28/2011 05:27 PM, Alex Converse wrote:
>>>
On Mon, Mar 28, 2011 at 2:19 PM, Justin Ruggles
wrote:
> On 03/2
Hi,
On Sun, Apr 10, 2011 at 2:04 PM, Luca Barbato wrote:
> Refer to the current submission policy and refer to FATE in the
> Regression Test section.
> ---
> doc/developer.texi | 221
> ++--
> 1 files changed, 93 insertions(+), 128 deletions(-)
On Apr 11, 2011, at 5:26 AM, Kostya wrote:
> On Mon, Apr 11, 2011 at 11:07:39AM +0200, Luca Barbato wrote:
>> With this commit we should have all the arch specific code moved away.
>> Init pattern now:
>> - generic C init first
>> - arch specific init later overwriting
>>
>> In future the arch s
On Apr 11, 2011, at 5:07 AM, Luca Barbato wrote:
> This unbreak darwin.
When was it broken?
> ---
> libswscale/Makefile|2 +-
> libswscale/rgb2rgb.c | 65 ++
> libswscale/swscale_functions.c | 67 ---
Hi,
On Tue, Apr 12, 2011 at 5:13 PM, Justin Ruggles
wrote:
> On 04/12/2011 02:41 PM, Max Horn wrote:
>> @@ -510,6 +510,8 @@ void ff_get_wav_header(AVIOContext *pb, AVCodecContext
>> *codec, int size)
>> codec->extradata_size = cbSize;
>> if (cbSize > 0) {
>> codec-
On 04/12/2011 02:41 PM, Max Horn wrote:
> @@ -510,6 +510,8 @@ void ff_get_wav_header(AVIOContext *pb, AVCodecContext
> *codec, int size)
> codec->extradata_size = cbSize;
> if (cbSize > 0) {
> codec->extradata = av_mallocz(codec->extradata_size +
> FF_INPUT_BUFFER_
Hi,
On Mon, Apr 11, 2011 at 4:01 PM, Luca Barbato wrote:
> From: Josh Allmann
>
> Simplify the fallthrough case when no accelerated functions
> can be initialized.
> ---
> libswscale/swscale.c | 9 ++---
> 1 files changed, 2 insertions(+), 7 deletions(-)
OK, but as said in my previous p
Hi,
On Mon, Apr 11, 2011 at 4:01 PM, Luca Barbato wrote:
> From: Josh Allmann
>
> Move x86-specific constants out of swscale.c
> ---
> libswscale/swscale.c | 57
> -
> libswscale/x86/swscale_template.c | 54 ++
Hi,
On Mon, Apr 11, 2011 at 4:01 PM, Luca Barbato wrote:
> The swscale_template is split among ppc and x86, lots of code is
> still duplicated and should be removed later.
>
> Again uniform the init system to be more similar to the dsputil one
>
> Unset h*scale_fast in the x86 init in order to ma
Hi,
minor comments only. Please fix and apply directly afterwards, this is
a massive and useful patch and I want to get it out of the way.
On Mon, Apr 11, 2011 at 4:01 PM, Luca Barbato wrote:
> @@ -199,20 +116,14 @@ DECLARE_ASM_CONST(8, uint64_t, blue_15mask) =
> 0x001f001fULL;
> 32-b
Hi,
On Tue, Apr 12, 2011 at 3:36 PM, Anton Khirnov wrote:
> On Tue, Apr 12, 2011 at 07:34:59PM +0200, Stefano Sabatini wrote:
>> On date Tuesday 2011-04-12 10:23:54 +0200, Anton Khirnov wrote:
>> > From: Stefano Sabatini
>> >
>> > The new function is more flexible than url_exist(), as it allows
On Tue, Apr 12, 2011 at 07:34:59PM +0200, Stefano Sabatini wrote:
> On date Tuesday 2011-04-12 10:23:54 +0200, Anton Khirnov wrote:
> > From: Stefano Sabatini
> >
> > The new function is more flexible than url_exist(), as it allows to
> > specify which access flags to check, and does not require
Am 12.04.2011 um 18:30 schrieb Justin Ruggles:
> On 04/12/2011 11:48 AM, Max Horn wrote:
>
>> diff --git a/libavformat/wtv.c b/libavformat/wtv.c
>> index 8260fe1..524d222 100644
>> --- a/libavformat/wtv.c
>> +++ b/libavformat/wtv.c
>> @@ -675,7 +675,9 @@ static AVStream * parse_media_type(AVForm
On date Tuesday 2011-04-12 10:23:54 +0200, Anton Khirnov wrote:
> From: Stefano Sabatini
>
> The new function is more flexible than url_exist(), as it allows to
> specify which access flags to check, and does not require an explicit
> open of the checked resource.
>
> Signed-off-by: Anton Khirno
Hi,
My comments are below to your questions.
-Manjunath H Siddaiah
-Original Message-
From: libav-devel-boun...@libav.org [mailto:libav-devel-boun...@libav.org] On
Behalf Of Luca Barbato
Sent: Tuesday, April 12, 2011 3:34 AM
To: libav-devel@libav.org
Subject: Re: [libav-devel] [PATCH] RT
On 04/12/2011 11:48 AM, Max Horn wrote:
> diff --git a/libavformat/wtv.c b/libavformat/wtv.c
> index 8260fe1..524d222 100644
> --- a/libavformat/wtv.c
> +++ b/libavformat/wtv.c
> @@ -675,7 +675,9 @@ static AVStream * parse_media_type(AVFormatContext *s,
> AVStream *st, int sid,
> if (!st
The attached patch handles malloc failures in ff_get_wav_header.
ff_get_wav_header is reading data from a WAVE file and then uses it (without
validation) to malloc a buffer. It then proceeded to read data into the buffer,
without verifying that the allocation succeeded.
To address this, I chang
On 4/12/11 5:30 PM, Max Horn wrote:
It's just that it feels a bit unfair to be upheld to standards that seem a much
higher than what a lot of the existing code meets...
Polishing is something we are trying to do little by little (or when
something is spotted). We try not to add more of such f
Am 12.04.2011 um 16:51 schrieb Kostya:
> On Tue, Apr 12, 2011 at 04:34:19PM +0200, Max Horn wrote:
>> Hi again!
>>
>> Am 12.04.2011 um 15:59 schrieb Kostya:
>>
>>> On Tue, Apr 12, 2011 at 03:35:04PM +0200, Max Horn wrote:
>
[...]
>> I guess this means I should report similar and worse things
On Tue, Apr 12, 2011 at 04:34:19PM +0200, Max Horn wrote:
> Hi again!
>
> Am 12.04.2011 um 15:59 schrieb Kostya:
>
> > On Tue, Apr 12, 2011 at 03:35:04PM +0200, Max Horn wrote:
> >>
>
> [...]
>
> >>
> >> +/* parse fmt header */
> >> +tag = avio_rl32(pb);
> >> +if (tag != MKTAG('f'
On Tue, 12 Apr 2011, Luca Barbato wrote:
> On 4/12/11 4:06 PM, Martin Storsjö wrote:
> > On Tue, 12 Apr 2011, Luca Barbato wrote:
> >
> > > On 4/12/11 3:47 PM, Martin Storsjö wrote:
> > > > Stop the avio input at a point where amf_parse_object can
> > > > continue parsing the end of the object se
Hi again!
Am 12.04.2011 um 15:59 schrieb Kostya:
> On Tue, Apr 12, 2011 at 03:35:04PM +0200, Max Horn wrote:
>>
[...]
>>
>> +/* parse fmt header */
>> +tag = avio_rl32(pb);
>> +if (tag != MKTAG('f', 'm', 't', ' '))
>> +return -1;
>> +size = avio_rl32(pb);
>> +if (s
On 4/12/11 4:06 PM, Martin Storsjö wrote:
On Tue, 12 Apr 2011, Luca Barbato wrote:
On 4/12/11 3:47 PM, Martin Storsjö wrote:
Stop the avio input at a point where amf_parse_object can
continue parsing the end of the object seamlessly, when all
data is available.
If unsupported data is encounte
On Tue, 12 Apr 2011, Luca Barbato wrote:
> On 4/12/11 3:47 PM, Martin Storsjö wrote:
> > Stop the avio input at a point where amf_parse_object can
> > continue parsing the end of the object seamlessly, when all
> > data is available.
> >
> > If unsupported data is encountered within the keyframes
On Tue, Apr 12, 2011 at 03:35:04PM +0200, Max Horn wrote:
> Hi Kostya,
>
> thanks for your feedback. Attached is a revised patch, in which I hopefully
> addressed all issues you pointed out. If I forgot something / introduced new
> badness, please let me know.
>
> Cheers,
> Max
> From 861668cd
On 4/12/11 3:20 PM, Ronald S. Bultje wrote:
This allows for more reproducible results when using multi-threading.
Fine for me.
lu
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
On 4/12/11 3:47 PM, Martin Storsjö wrote:
Stop the avio input at a point where amf_parse_object can
continue parsing the end of the object seamlessly, when all
data is available.
If unsupported data is encountered within the keyframes object,
try seeking to the start of the keyframes object - if
Stop the avio input at a point where amf_parse_object can
continue parsing the end of the object seamlessly, when all
data is available.
If unsupported data is encountered within the keyframes object,
try seeking to the start of the keyframes object - if the seek
back was successful, the caller ca
Hi
On Tue, Apr 12, 2011 at 4:49 AM, Luca Barbato wrote:
> On 04/12/2011 10:23 AM, Anton Khirnov wrote:
>> It seems their replacements won't be ready anytime soon.
>> ---
>> libavformat/asfdec.c | 2 +-
>> libavformat/avio.h | 27 +++
>> libavformat/av
Hi Kostya,
thanks for your feedback. Attached is a revised patch, in which I hopefully
addressed all issues you pointed out. If I forgot something / introduced new
badness, please let me know.
Cheers,
Max
0001-add-xWMA-demuxer.patch
Description: Binary data
___
On Tue, 12 Apr 2011, Luca Barbato wrote:
> On 4/12/11 2:13 PM, Martin Storsjö wrote:
> > As I said in the other thread, if you return from parse_keyframes_index
> > without seeking - like you propose, you need to parse in exactly the same
> > way as what amf_parse_object does.
>
> An amf object i
On 4/12/11 2:13 PM, Martin Storsjö wrote:
As I said in the other thread, if you return from parse_keyframes_index
without seeking - like you propose, you need to parse in exactly the same
way as what amf_parse_object does.
An amf object is just a null terminated list of tuples {string, object}
On Tue, 12 Apr 2011, Luca Barbato wrote:
> On 4/12/11 12:59 PM, Martin Storsjö wrote:
> > On Tue, 12 Apr 2011, Anton Khirnov wrote:
> >
> > > On Tue, Apr 12, 2011 at 12:43:23PM +0300, Martin Storsjö wrote:
> > > > From: Michael Niedermayer
> > > >
> > > > Reading the index currently requires see
On Tue, Apr 12, 2011 at 01:32:26PM +0200, Max Horn wrote:
> Hi there!
>
> I originally sent this patch to ffmpeg-devel, but DonDiego on #libav-devel
> asked me to re-send it also here, which I am doing hereby. Below is my
> original email; since then, I revised the patch to include seeking suppo
On 4/12/11 12:59 PM, Martin Storsjö wrote:
On Tue, 12 Apr 2011, Anton Khirnov wrote:
On Tue, Apr 12, 2011 at 12:43:23PM +0300, Martin Storsjö wrote:
From: Michael Niedermayer
Reading the index currently requires seeking.
---
libavformat/flvdec.c |2 +-
1 files changed, 1 insertions(+),
Hi there!
I originally sent this patch to ffmpeg-devel, but DonDiego on #libav-devel
asked me to re-send it also here, which I am doing hereby. Below is my original
email; since then, I revised the patch to include seeking support, so that part
of it is outdated.
The patch, however, is against
On 4/12/11 12:57 PM, Martin Storsjö wrote:
On Tue, 12 Apr 2011, Luca Barbato wrote:
On 04/12/2011 12:04 PM, Anton Khirnov wrote:
On Tue, Apr 12, 2011 at 12:43:23PM +0300, Martin Storsjö wrote:
From: Michael Niedermayer
Reading the index currently requires seeking.
---
libavformat/flvdec.c
On Tue, 12 Apr 2011, Anton Khirnov wrote:
> On Tue, Apr 12, 2011 at 12:43:23PM +0300, Martin Storsjö wrote:
> > From: Michael Niedermayer
> >
> > Reading the index currently requires seeking.
> > ---
> > libavformat/flvdec.c |2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
>
On Tue, 12 Apr 2011, Luca Barbato wrote:
> On 04/12/2011 12:04 PM, Anton Khirnov wrote:
> > On Tue, Apr 12, 2011 at 12:43:23PM +0300, Martin Storsjö wrote:
> >> From: Michael Niedermayer
> >>
> >> Reading the index currently requires seeking.
> >> ---
> >> libavformat/flvdec.c |2 +-
> >> 1
On Mon, Apr 11, 2011 at 10:01:10PM +0200, Luca Barbato wrote:
> From: Josh Allmann
>
> Simplify the fallthrough case when no accelerated functions
> can be initialized.
OK
Diego
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.or
On 04/12/2011 12:04 PM, Anton Khirnov wrote:
> On Tue, Apr 12, 2011 at 12:43:23PM +0300, Martin Storsjö wrote:
>> From: Michael Niedermayer
>>
>> Reading the index currently requires seeking.
>> ---
>> libavformat/flvdec.c |2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff
On Tue, Apr 12, 2011 at 12:43:23PM +0300, Martin Storsjö wrote:
> From: Michael Niedermayer
>
> Reading the index currently requires seeking.
> ---
> libavformat/flvdec.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
>
On Tue, 12 Apr 2011, Diego Biurrun wrote:
> On Tue, Apr 12, 2011 at 12:37:10PM +0300, Martin Storsjö wrote:
> > [...]
>
> OK
Queued
// Martin___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
This can later be extended to support other AES bit sizes,
encryption, other crypto algorithms, reading the key from a URL, etc.
In order to use it, the key and initialization vector has to be
passed via AVOptions. Since such options can't be passed to
protocols from the command line, the protocol
On Tue, 12 Apr 2011, Diego Biurrun wrote:
> On Tue, Apr 12, 2011 at 11:08:13AM +0300, Martin Storsjö wrote:
> > This can later be extended to support other AES bit sizes,
> > encryption, other crypto algorithms, reading the key from a URL, etc.
> >
> > --- /dev/null
> > +++ b/libavformat/crypto.c
On Tue, Apr 12, 2011 at 12:37:10PM +0300, Martin Storsjö wrote:
> [...]
OK
Diego
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
On Mon, Apr 11, 2011 at 10:01:09PM +0200, Luca Barbato wrote:
>
> --- a/libswscale/swscale.c
> +++ b/libswscale/swscale.c
> @@ -121,63 +121,6 @@ add BGR4 output support
>
> -const DECLARE_ALIGNED(8, uint64_t, ff_dither4)[2] = {
> -0x0103010301030103LL,
> -0x0200020002000200LL,};
On Mon, Apr 11, 2011 at 10:01:06PM +0200, Luca Barbato wrote:
> It is used only for x86 so it will be moved once the code is moved in
> the arch dir
swscale: factorize FAST_BGR2YV12 definition
It is used only for x86 so it will eventually be moved with that code into
the arch directory.
I
Martin Storsjö wrote:
An approach which doesn't require seekability would be to hook in this
parsing along the normal recursive amf parsing. That would distribute all
of the keyframe index parsing all over the place, though. (I didn't follow
this patchset closely in the beginning, but wasn't tha
From: Michael Niedermayer
Reading the index currently requires seeking.
---
libavformat/flvdec.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
index 62d25c8..1a827fd 100644
--- a/libavformat/flvdec.c
+++ b/libavformat/flvdec
On Tue, 12 Apr 2011, Diego Biurrun wrote:
> On Tue, Apr 12, 2011 at 10:44:26AM +0300, Martin Storsjö wrote:
> > [...]
>
> OK
Pushed this one
// Martin___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-dev
On Tue, Apr 12, 2011 at 11:08:13AM +0300, Martin Storsjö wrote:
> This can later be extended to support other AES bit sizes,
> encryption, other crypto algorithms, reading the key from a URL, etc.
>
> --- /dev/null
> +++ b/libavformat/crypto.c
> @@ -0,0 +1,170 @@
> +/*
> + * Decryption protocol ha
1 - 100 of 132 matches
Mail list logo
