From: Clément Bœsch
---
libavutil/threadmessage.c | 37 ++---
libavutil/threadmessage.h | 21 ++---
2 files changed, 52 insertions(+), 6 deletions(-)
diff --git a/libavutil/threadmessage.c b/libavutil/threadmessage.c
index
On Wed, Dec 2, 2015 at 10:37 AM, Claudio Freire wrote:
> So, here comes the discussion again.
>
> This time, the AAC encoder is in good shape. It's not perfect. I have
> a list of known bugs to address that still has some issues, but I'm
> not really certain whether they
From: Clément Bœsch
Fix a dead lock under certain conditions. Let's assume we have a queue of 1
message max, 2 senders, and 1 receiver.
Scenario (real record obtained with debug added):
[...]
SENDER #0: acquired lock
SENDER #0: queue is full, wait
SENDER
On 11/30/15 10:35 AM, Alexander Agranovsky wrote:
On 11/30/15 10:24 AM, Nicolas George wrote:
Le decadi 10 frimaire, an CCXXIV, Alexander Agranovsky a écrit :
Without getting into a religious debate
This is the reason I gave practical argument.
As pointed later in the thread, lu is used
Improvements & changes regarding last iteration:
[PATCH 1/3] avutil/threadmessage: add av_thread_message_flush()
- the flushing function can be set through a dedicated function instead of a
new constructor prototype
- the flush function is now fixed regarding messages larger than a pointer...
sorry wrong patchset.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On Wed, Dec 02, 2015 at 03:13:33PM +0100, Nicolas George wrote:
> Le duodi 12 frimaire, an CCXXIV, Clement Boesch a écrit :
> > because concurrent read/write accesses on the fifo needs to be locked?
>
> No, of course not.
I was talking about the fifo itself, not the threadmessage API.
>
> > I
Le duodi 12 frimaire, an CCXXIV, Ganesh Ajjanagadde a écrit :
> He mentioned AAC due to some user's
> complaints about quality on certain files. This was likely referring
> to the decoder and not encoder.
I remember it about the MP3 decoder compared to libmp3, not
On Wed, Dec 02, 2015 at 05:09:23PM +0100, Nicolas George wrote:
> Le duodi 12 frimaire, an CCXXIV, Clement Boesch a écrit :
> > What would be the difference? both av_fifo_generic_peek and
> > av_fifo_generic_peek_at require a copy of the element in a destination
> > buffer, unless I'm missing
On Wed, Dec 2, 2015 at 4:42 PM, Clément Bœsch wrote:
> On Wed, Dec 02, 2015 at 12:37:00PM -0300, Claudio Freire wrote:
>> So, here comes the discussion again.
>>
>> This time, the AAC encoder is in good shape. It's not perfect. I have
>> a list of known bugs to address that still has
Le duodi 12 frimaire, an CCXXIV, Clement Boesch a écrit :
> From: Clément Bœsch
>
> ---
> libavutil/threadmessage.c | 32
> libavutil/threadmessage.h | 12
> 2 files changed, 44 insertions(+)
>
> diff --git
Le duodi 12 frimaire, an CCXXIV, Clement Boesch a écrit :
> What would be the difference? both av_fifo_generic_peek and
> av_fifo_generic_peek_at require a copy of the element in a destination
> buffer, unless I'm missing something.
As I see it, av_fifo_generic_peek() does NOT require a copy if a
From: Clément Bœsch
---
tests/api/Makefile | 1 +
tests/api/api-threadmessage-test.c | 202 +
tests/fate/api.mak | 6 ++
3 files changed, 209 insertions(+)
create mode 100644
GIT: [PATCH 1/3] avutil/threadmessage: add av_thread_message_flush()
GIT: [PATCH 2/3] fate/api: test threadmessage
GIT: [PATCH 3/3] avutil/threadmessage: fix condition broadcasting
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
From: Clément Bœsch
Fix a dead lock under certain conditions. Let's assume we have a queue of 1
message max, 2 senders, and 1 receiver.
Scenario (real record obtained with debug added):
[...]
SENDER #0: acquired lock
SENDER #0: queue is full, wait
SENDER
Le duodi 12 frimaire, an CCXXIV, Clement Boesch a écrit :
> - the flushing function can be set through a dedicated function instead of a
> new constructor prototype
If I read the patch correctly, you seem to have fumbled your rebasing. The
deprecation is still there and the setter function is
On Wed, Dec 02, 2015 at 12:37:00PM -0300, Claudio Freire wrote:
> So, here comes the discussion again.
>
> This time, the AAC encoder is in good shape. It's not perfect. I have
> a list of known bugs to address that still has some issues, but I'm
> not really certain whether they should block the
Le duodi 12 frimaire, an CCXXIV, Clement Boesch a écrit :
> - there is a large queue of packets, almost filled
> - there is one fast sender filling the queue (the demuxer)
> - there is a bunch of slow readers reading from the queue (the decoders)
> - the sender "receives" a seek event from the
Dear Andreas Cadhalpun,
On 20/11/15 20:10, Andreas Cadhalpun wrote:
> On 18.11.2015 12:13, Vicente Olivert Riera wrote:
>> There is no point to have a "generic" core when we can catch all
>> unsupported cores with the "*" option, so remove it.
>>
>> Signed-off-by: Vicente Olivert Riera
On Wed, 2 Dec 2015 09:28:40 -0500
Alexander Agranovsky wrote:
> Hi guys -- where do we stand with this? Are there any additional comments?
>
> - A.
Looks fine now. The trim_right() still looks a bit awkward IMHO, but it
should be correct (whoever really cares can send a
On Wed, Dec 02, 2015 at 09:52:02AM +0100, Hendrik Leppkes wrote:
> ---
> libavcodec/cbrt_tablegen_template.c | 2 +-
> libavcodec/mpegaudio_tablegen.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
should be ok (ugly though that the order matters)
[...]
--
Michael GnuPG
On Wed, Dec 02, 2015 at 04:01:40PM +0100, Nicolas George wrote:
> Le duodi 12 frimaire, an CCXXIV, Clement Boesch a écrit :
> > - the flushing function can be set through a dedicated function instead of a
> > new constructor prototype
>
> If I read the patch correctly, you seem to have fumbled
So, here comes the discussion again.
This time, the AAC encoder is in good shape. It's not perfect. I have
a list of known bugs to address that still has some issues, but I'm
not really certain whether they should block the flag's removal.
The bugs will be addressed in time, but maybe the
On Wed, Dec 02, 2015 at 04:59:15PM +0100, Nicolas George wrote:
[...]
> > +av_fifo_generic_peek_at(mq->fifo, mq->tmp_msg, off,
> > mq->elsize, NULL);
> > +mq->free_func(mq->tmp_msg);
>
> Could this use av_fifo_generic_peek() to avoid the ugly extra allocation?
>
What
On 02.12.2015 15:54, Vicente Olivert Riera wrote:
> On 20/11/15 20:10, Andreas Cadhalpun wrote:
>> If the cpu is not explicitly set via configure options, it is set to generic.
>> Removing this generic case here, will force-disable all mips optimizations,
>> even if they were explicitly enabled
On 25.11.2015 11:56, Tobias Rapp wrote:
> Subject: [PATCH] Makefile: add cleanup of pkg-config files created by
> configure to distclean
>
> ---
> Makefile | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Makefile b/Makefile
> index 306f060..58f1a3a 100644
> --- a/Makefile
> +++
On 29.11.2015 17:21, Nicolas George wrote:
> Applications are not supposed to mess with links,
> they should close the sinks.
> Furthermore, this function does not distinguish what end
> of the link caused the close and does not have a timestamp.
>
> Signed-off-by: Nicolas George
On Wed, Dec 2, 2015 at 2:16 AM wm4 wrote:
> On Wed, 02 Dec 2015 00:32:46 +
> Aaron Colwell wrote:
>
> > On Mon, Nov 30, 2015 at 4:35 PM wm4 wrote:
> >
> > >
> > > I tried your patch, and it actually makes it work better
On 25.11.2015 02:30, Timothy Gu wrote:
> On Wed, Nov 25, 2015 at 12:35:03AM +0100, Andreas Cadhalpun wrote:
>> They are not very helpful and feel out-of-place.
>>
>> Suggested-by: Timothy Gu
>> Signed-off-by: Andreas Cadhalpun
>> ---
>>
On Wed, Dec 2, 2015 at 12:50 PM, Hendrik Leppkes wrote:
> On Wed, Dec 2, 2015 at 4:42 PM, Clément Bœsch wrote:
>> On Wed, Dec 02, 2015 at 12:37:00PM -0300, Claudio Freire wrote:
>>> So, here comes the discussion again.
>>>
>>> This time, the AAC encoder is in
Hi,
According to Microsoft's specs [1] (and after experiencing issues with the
Unified Streaming Platform [2] server), content encoded with HE-AAC audio
should use the AACH FourCC, but the value AACL is hardcoded in the manifest
generation code. So I created the attached patch to fix this. It
Dana 2. 12. 2015. 16:54 osoba "Nicolas George" napisala
je:
>
> Le duodi 12 frimaire, an CCXXIV, Ganesh Ajjanagadde a écrit :
> > He mentioned AAC due to some user's
> > complaints about quality on certain files. This was likely referring
> > to the
If the chroma components are subsampled, smaller buffers are allocated
for them. In that case the maximal block_offset for the chroma
components is not as large as for the luma component.
This fixes out of bounds writes causing segmentation faults or memory
corruption.
Signed-off-by: Andreas
On 25.11.2015 01:26, Andreas Cadhalpun wrote:
> Subject: [PATCH] git-howto: mention how to clone ffmpeg-web
>
> Signed-off-by: Andreas Cadhalpun
> ---
> doc/git-howto.texi | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git
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(-)
does this fix any case or just simplifies common.mak ?
[...]
--
Michael GnuPG fingerprint:
On Wed, Dec 2, 2015 at 4:14 PM, Rostislav Pehlivanov
wrote:
> This commit removes the experimental flag from the native AAC Encoder
> and thus makes it the default.
>
> After a lot of work, done by myself and Claudio Freire, the quality of
> this encoder rivals and surpasses
On 19.11.2015 01:02, Andreas Cadhalpun wrote:
> If the input contains too many too large values, the imdct can overflow.
> Even if it didn't, the output would be larger than the valid range of 29
> bits.
>
> Note that this is a very delicate limit: Allowing values up to 1<<25
> does not prevent
On 19.11.2015 01:01, Andreas Cadhalpun wrote:
> Subject: [PATCH] sbrdsp_fixed: assert that input values for sbr_sum_square_c
> are valid
>
> Larger values can cause overflows, leading to this function returning a
> negative value.
>
> Signed-off-by: Andreas Cadhalpun
Hi,
On Tue, Dec 1, 2015 at 1:21 PM, Ronald S. Bultje wrote:
> Hi,
>
> On Tue, Dec 1, 2015 at 12:34 PM, Hendrik Leppkes
> wrote:
>
>> On Tue, Dec 1, 2015 at 6:24 PM, Ronald S. Bultje
>> wrote:
>> > Fixes mozilla bug 1229128.
>> > ---
On Tue, Dec 01, 2015 at 01:50:13PM +0100, Michael Niedermayer wrote:
> From: Michael Niedermayer
>
> Fixes integer overflow
> Fixes: mozilla bug 1229167
>
> Found-by: Tyson Smith
> Signed-off-by: Michael Niedermayer
> ---
>
This commit removes the experimental flag from the native AAC Encoder
and thus makes it the default.
After a lot of work, done by myself and Claudio Freire, the quality of
this encoder rivals and surpasses libfdk_aac in some situations. The
encoder had instability issues earlier which prevented
This commit marks any coders beside twoloop as experimental and gives
out a warning that some of they might be silently removed in the future.
Users are highly encouraged to use the twoloop coder, which is the
default.
---
libavcodec/aacenc.c | 2 ++
1 file changed, 2 insertions(+)
diff --git
On 08.11.2015 22:04, Andreas Cadhalpun wrote:
> This fixes a SIGFPE crash in the aac_fixed decoder.
>
> Signed-off-by: Andreas Cadhalpun
> ---
> libavcodec/aacsbr_template.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git
On Wed, 2 Dec 2015 02:23:15 +0100
Michael Niedermayer wrote:
> On Tue, Dec 01, 2015 at 10:47:53AM -0800, Chris Cunningham wrote:
> > Thanks wm4, next patch will fix that declaration.
> >
> > Michael, any concerns?
>
> iam fine with the patch
>
>
> >
> > On Mon, Nov 30,
On 12/2/15, Hendrik Leppkes wrote:
> ---
> libavutil/tablegen.h | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/libavutil/tablegen.h b/libavutil/tablegen.h
> index f81b46b..02acdd6 100644
> --- a/libavutil/tablegen.h
> +++ b/libavutil/tablegen.h
> @@ -24,6 +24,8
---
libavutil/tablegen.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavutil/tablegen.h b/libavutil/tablegen.h
index f81b46b..02acdd6 100644
--- a/libavutil/tablegen.h
+++ b/libavutil/tablegen.h
@@ -24,6 +24,8 @@
#ifndef AVUTIL_TABLEGEN_H
#define AVUTIL_TABLEGEN_H
+#include
+
//
---
libavcodec/cbrt_tablegen_template.c | 2 +-
libavcodec/mpegaudio_tablegen.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/cbrt_tablegen_template.c
b/libavcodec/cbrt_tablegen_template.c
index 1d71d34..7dcab91 100644
---
Including these headers is not needed and breaks building on Windows as it
tries to activate the full compat tools, which are not needed for host
tools.
---
libavcodec/aacsbr_fixed_tablegen.c | 3 ---
libavcodec/aacsbr_tablegen.c| 3 ---
libavcodec/aacsbr_tablegen_common.h | 3 ++-
3
If size is zero, avio_get_str fails, leaving the buffer uninitialized.
This causes invalid reads in av_set_options_string.
Signed-off-by: Andreas Cadhalpun
---
libavformat/ffmdec.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
On Wed, Dec 2, 2015 at 4:47 PM, Rostislav Pehlivanov
wrote:
> This commit marks any coders beside twoloop as experimental and gives
> out a warning that some of they might be silently removed in the future.
>
> Users are highly encouraged to use the twoloop coder, which is
On Wed, 2 Dec 2015 09:28:40 -0500
Alexander Agranovsky wrote:
> Hi guys -- where do we stand with this? Are there any additional comments?
>
> - A.
Pushed both patches.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
Otherwise the ffm demuxer can return the same packets endlessly, if
there is no server attached.
---
I haven't tested ffserver, but since it sets server_attached, it
should still work as previously.
---
libavformat/ffmdec.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git
On Wed, Dec 2, 2015 at 10:04 PM, Claudio Freire wrote:
> On Wed, Dec 2, 2015 at 4:47 PM, Rostislav Pehlivanov
> wrote:
>> This commit marks any coders beside twoloop as experimental and gives
>> out a warning that some of they might be silently
On Wed, Dec 2, 2015 at 12:51 PM, Ganesh Ajjanagadde wrote:
> On Wed, Dec 2, 2015 at 10:37 AM, Claudio Freire
> wrote:
>> So, here comes the discussion again.
>>
>> This time, the AAC encoder is in good shape. It's not perfect. I have
>> a list of known
Le tridi 13 frimaire, an CCXXIV, Ganesh Ajjanagadde a écrit :
> There was no reason AFAIK for making AV_CRC_24_IEEE 12.
The reason was to leave room for the fork to add its own new constants
without causing ABI incompatibilities.
Regards,
--
Nicolas George
signature.asc
Description:
On Tue, Dec 1, 2015 at 8:38 PM, James Almer wrote:
> On 12/1/2015 10:35 PM, Ganesh Ajjanagadde wrote:
>> On Tue, Dec 1, 2015 at 8:08 PM, James Almer wrote:
>>> On 12/1/2015 9:53 PM, Ganesh Ajjanagadde wrote:
There was no reason AFAIK for making
On Tue, Dec 1, 2015 at 9:11 PM, Michael Niedermayer wrote:
> On Tue, Dec 01, 2015 at 07:27:50PM -0500, Ganesh Ajjanagadde wrote:
>> lrint is faster, and is more consistent across the codebase.
>>
>> Signed-off-by: Ganesh Ajjanagadde
>> ---
>>
On Tue, Dec 1, 2015 at 9:10 PM, Michael Niedermayer wrote:
> On Tue, Dec 01, 2015 at 07:27:51PM -0500, Ganesh Ajjanagadde wrote:
>> Signed-off-by: Ganesh Ajjanagadde
>> ---
>> libavfilter/vf_perspective.c | 10 +-
>> 1 file changed, 5
On Wed, Dec 2, 2015 at 7:39 AM, Paul B Mahol wrote:
> On 12/2/15, Ganesh Ajjanagadde wrote:
>> On Wed, Dec 2, 2015 at 1:18 AM, Paul B Mahol wrote:
>>> On 12/2/15, Ganesh Ajjanagadde wrote:
Signed-off-by:
On Wed, Dec 02, 2015 at 08:03:33PM +0100, Michael Niedermayer wrote:
> 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(-)
>
> does this fix any case or just
On Wed, 02 Dec 2015 00:32:46 +
Aaron Colwell wrote:
> On Mon, Nov 30, 2015 at 4:35 PM wm4 wrote:
>
> >
> > I tried your patch, and it actually makes it work better (looks correct
> > with the patch). The patch itself also LGTM.
> >
> >
> Ok.
On Tue, Dec 1, 2015 at 11:12 PM, Claudio Freire wrote:
> On Tue, Dec 1, 2015 at 10:47 PM, Michael Niedermayer wrote:
>>> libavcodec/aaccoder.c | 60 --
>>> libavcodec/aaccoder_twoloop.h | 136
>>>
On 12/2/15, Paul B Mahol wrote:
> On 12/2/15, Ganesh Ajjanagadde wrote:
>> Signed-off-by: Ganesh Ajjanagadde
>> ---
>> libavfilter/af_stereotools.c | 8
>> 1 file changed, 4 insertions(+), 4 deletions(-)
>>
>> diff
On Tue, 1 Dec 2015 10:54:38 -0800
chcunning...@chromium.org wrote:
> From: Chris Cunningham
>
> "Fast seek" uses linear interpolation to find the position of the
> requested seek time. For CBR this is more direct than using the
> mp3 TOC and bypassing the TOC avoids
On Tue, Dec 01, 2015 at 06:49:29PM +0100, Nicolas George wrote:
> Le primidi 11 frimaire, an CCXXIV, Clement Boesch a écrit :
> > Ah. Well then the user can not do it himself since he has no way of
> > acquiring the queue lock (AVThreadMessageQueue is opaque)
>
> Yes, but why does it matter, if
On Wed, Dec 2, 2015 at 2:29 AM, Michael Niedermayer wrote:
> On Tue, Dec 01, 2015 at 08:04:22PM +0100, Hendrik Leppkes wrote:
>> On Mon, Nov 30, 2015 at 10:50 PM, Hendrik Leppkes
>> wrote:
>> > ---
>> > I'm not quite sure if this fix is 100% correct, but
On Wed, Dec 2, 2015 at 1:18 AM, Paul B Mahol wrote:
> On 12/2/15, Ganesh Ajjanagadde wrote:
>> Signed-off-by: Ganesh Ajjanagadde
>> ---
>> libavfilter/af_flanger.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>>
On Wed, Dec 2, 2015 at 6:03 AM, Paul B Mahol wrote:
> On 12/2/15, Paul B Mahol wrote:
>> On 12/2/15, Ganesh Ajjanagadde wrote:
>>> Signed-off-by: Ganesh Ajjanagadde
>>> ---
>>> libavfilter/af_stereotools.c | 8
On 12/2/15, Ganesh Ajjanagadde wrote:
> On Wed, Dec 2, 2015 at 1:18 AM, Paul B Mahol wrote:
>> On 12/2/15, Ganesh Ajjanagadde wrote:
>>> Signed-off-by: Ganesh Ajjanagadde
>>> ---
>>>
Le duodi 12 frimaire, an CCXXIV, Clement Boesch a écrit :
> because concurrent read/write accesses on the fifo needs to be locked?
No, of course not.
> I don't understand...
*I* do not understand what you need, what you want to do with this API. To
discard all elements, just read them until
70 matches
Mail list logo