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 it works here.
>> >
>> > The problem is t
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, 2015 at 2:51 PM, wm4
---
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
--- a/libavcodec/cbrt_tablegen_templat
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 file
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 @@
> #ifndef AVUTIL_TA
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 problems with TOC precision.
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. Great. Thanks for the review. What do I need to
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
>>> --
>>> libavcodec/aacenc.c
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 th
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 --git a/libavfilter/af_stereotools.c b/libavfilter/af_stereotools.c
>>
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(-)
>>
>> diff --git a/libavfilter/af_flanger.c b/libavfilter/af_flanger.c
>>
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
>>> 1 file changed, 4 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/l
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
>>> ---
>>> libavfilter/af_flanger.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/libavfi
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 ther
On Monday 30 November 2015 10:57:32 pm Michael Niedermayer wrote:
> On Mon, Nov 30, 2015 at 01:18:21AM +0100, Carl Eugen Hoyos wrote:
> > On Saturday 28 November 2015 02:32:37 am Carl Eugen Hoyos wrote:
> > > Hi!
> > >
> > > Jpeg over rtp requires standard huffman tables, but the test I
> > > imple
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 fing
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
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 d
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
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...
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 b7fcbe2..87ce8dc 100644
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 tests/api/api-threadmessage-test.c
diff --git a
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 #1: acquired lock
SEN
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
>> ---
>>
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
http://ffmpeg.org/ma
From: Clément Bœsch
---
libavutil/threadmessage.c | 32
libavutil/threadmessage.h | 12
2 files changed, 44 insertions(+)
diff --git a/libavutil/threadmessage.c b/libavutil/threadmessage.c
index b7fcbe2..66b5fc6 100644
--- a/libavutil/threadmessage.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
sorry wrong patchset.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
From: Clément Bœsch
---
tests/api/Makefile | 1 +
tests/api/api-threadmessage-test.c | 263 +
tests/fate/api.mak | 6 +
3 files changed, 270 insertions(+)
create mode 100644 tests/api/api-threadmessage-test.c
diff --git a/
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 y
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 no
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 #1: acquired lock
SEN
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 follow-up patch to
chang
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 encoder
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
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 some issues,
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 should block the flag's re
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 a/libavutil/threadmessage.c b/libavutil/th
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 AAC
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 wou
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
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 somet
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 wit
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 decoder and not en
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 pass
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
>> ---
>> src/download | 6 +-
>> 1 file changed, 1 insertion(+),
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 (looks correct
> > > with the patch). The patch itself also LGTM.
> > >
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 good shape. It's not perfect. I have
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
> +++ b/Makef
> On Nov 19, 2015, at 6:31 PM, Michael Niedermayer wrote:
>
>> On Wed, Nov 18, 2015 at 09:22:57PM -0800, Michael Bradshaw wrote:
>> On Wed, Nov 18, 2015 at 8:00 AM, Michael Niedermayer >> wrote:
>>
On Tue, Nov 17, 2015 at 07:27:55AM -0800, Michael Bradshaw wrote:
Hi,
Attach
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
> ---
> libavfi
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: 9FF2128B147EF6730BA
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 it
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 libfdk_aac in some sit
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 a/doc/git-howto.texi b/doc/git-howto.texi
> index b
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 a/
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 a/libavcodec/aacsbr_template.c b/libavcodec/aa
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
> ---
> libavcodec/sbrdsp_
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 in
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.
>> > ---
>> > libavcodec/vp9.c | 43 ++---
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
> ---
> libavutil/mathematics.c | 13 ++---
> 1 file changed, 10 ins
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 Cadh
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 the
> default.
> ---
>
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
http://ffmpeg.org/mailman/l
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 a/libavformat/ffmdec.c b/libavformat/ffmdec.c
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 a/
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 removed in the future.
>>
>> Users are highly encour
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: Ganesh Ajjanagadde
---
libavfilter/af_flanger.c | 2 +-
1 file change
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
>> ---
>> libavfilter/vsrc_mptestsrc.c | 2 +-
>> 1 file change
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 insertions(+), 5 deletions(-)
>
> should be ok
pushe
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 AV_CRC_24_IEEE 12. This simply
resulted in
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 si
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 bugs to address that still has some issues,
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: Digital
75 matches
Mail list logo
