Von meinem iPhone gesendet
> Am 20.08.2014 um 03:16 schrieb Michael Niedermayer :
>
>> On Wed, Aug 20, 2014 at 12:12:49AM +0200, Daniel Oberhoff wrote:
>> Hello,
>>
>> As a follow-up to my last patch I now factored out the floating point based
>> interpolation from transform.h/transform.c and
On 2014-08-20 01:25 +0200, Alexander Strasser wrote:
> Should fix CID1231988 (RESOURCE_LEAK)
>
> Signed-off-by: Alexander Strasser
> ---
>
> WARNING: Sorry, I only compile-tested so far.
>
> There is one remaining thing, I am not sure of:
> It looks like the variable feet could be uninitializ
~15% faster than sse2
Signed-off-by: James Almer
---
libavcodec/x86/hevc_res_add.asm | 15 +++
libavcodec/x86/hevcdsp.h| 4
libavcodec/x86/hevcdsp_init.c | 4
3 files changed, 19 insertions(+), 4 deletions(-)
diff --git a/libavcodec/x86/hevc_res_add.asm b/libav
On Tue, Aug 19, 2014 at 6:49 PM, Michael Niedermayer wrote:
> Fixes memleak
> Fixes CID1231989
>
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/hevc_ps.c |3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
Looks OK.
>
> diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
Fixes memleak
Fixes CID1231989
Signed-off-by: Michael Niedermayer
---
libavcodec/hevc_ps.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
index 163c5e4..2ccce5f 100644
--- a/libavcodec/hevc_ps.c
+++ b/libavcodec/hevc_ps.c
@@ -
On Wed, Aug 20, 2014 at 12:12:49AM +0200, Daniel Oberhoff wrote:
> Hello,
>
> As a follow-up to my last patch I now factored out the floating point based
> interpolation from transform.h/transform.c and applied it in the
> vf_lenscorrection filter I introduced in my last patch. What I did not do
On Tue, Aug 19, 2014 at 12:38 PM, Clément Bœsch wrote:
> On Mon, Aug 18, 2014 at 06:54:55AM +0700, Muhammad Faiz wrote:
> > This fontcolor option uses arithmetic expression, not color value,
> > so color names aren't available.
> > Thank's
> Can you suggest an alternative in the examples? (maybe
Hi,
On Mon, Aug 18, 2014 at 2:28 PM, James Almer wrote:
> On 18/08/14 5:01 AM, Pierre Edouard Lepere wrote:
> > Hi,
> > here's the new version of the patch. Sorry for the delay.
> > James, I have not done 8-bit AVX versions because it requires unpacks
> that are done differently in AVX.
>
> Aren
---
src/security |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/security b/src/security
index 1e0ecc7..8abf731 100644
--- a/src/security
+++ b/src/security
@@ -188,7 +188,7 @@ Fixes following vulnerabilities:
CVE-2014-5272, abc1fa7c5a1dca1345b9471b81cfcda00c56220d
---
src/index | 13 +
1 file changed, 13 insertions(+)
diff --git a/src/index b/src/index
index 40a8abf..f8224f1 100644
--- a/src/index
+++ b/src/index
@@ -36,6 +36,19 @@
News
+ August 20, 2014, FFmpeg 2.3.3, 2.2.7, 1.2.8
+
+We have made several new point releases
On Tue, Aug 19, 2014 at 4:20 PM, Lou Logan wrote:
> Signed-off-by: Lou Logan
> ---
> doc/ffmpeg.texi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
OK, of course.
[...]
Timothy
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ff
On Mon, Aug 18, 2014 at 03:28:02PM -0300, James Almer wrote:
> On 18/08/14 5:01 AM, Pierre Edouard Lepere wrote:
> > Hi,
> > here's the new version of the patch. Sorry for the delay.
> > James, I have not done 8-bit AVX versions because it requires unpacks that
> > are done differently in AVX.
>
Signed-off-by: Lou Logan
---
doc/ffmpeg.texi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
index 23ef668..69ffa87 100644
--- a/doc/ffmpeg.texi
+++ b/doc/ffmpeg.texi
@@ -339,7 +339,7 @@ ffmpeg -i in.avi -metadata title="my title" out.flv
T
Should fix CID1231988 (RESOURCE_LEAK)
Signed-off-by: Alexander Strasser
---
WARNING: Sorry, I only compile-tested so far.
There is one remaining thing, I am not sure of:
It looks like the variable feet could be uninitialized
at the point av_freep is called. I think it cannot, but
I had to fol
On Thu, 19 Jun 2014 10:06:48 -0800, Lou Logan wrote:
> On Wed, 18 Jun 2014 14:16:52 +0200, Carl Eugen Hoyos wrote:
>
> > diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
> > index 68fd12f..6f3c2c3 100644
> > --- a/doc/ffmpeg.texi
> > +++ b/doc/ffmpeg.texi
> > @@ -473,6 +473,9 @@ Set frame rate (Hz
Hello,
As a follow-up to my last patch I now factored out the floating point based
interpolation from transform.h/transform.c and applied it in the
vf_lenscorrection filter I introduced in my last patch. What I did not do is
also factor out fixed point based interpolation as used in vf_rotate a
On 19/08/14 6:35 PM, Michael Niedermayer wrote:
> On Tue, Aug 19, 2014 at 05:35:15PM -0300, James Almer wrote:
>> Signed-off-by: James Almer
>> ---
>> libavcodec/tiff.c | 17 +
>> 1 file changed, 9 insertions(+), 8 deletions(-)
>
> both patches should be ok
Pushed, thanks.
On Tue, Aug 19, 2014 at 05:35:15PM -0300, James Almer wrote:
> Signed-off-by: James Almer
> ---
> libavcodec/tiff.c | 17 +
> 1 file changed, 9 insertions(+), 8 deletions(-)
both patches should be ok
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0F
On Tue, Aug 19, 2014 at 11:54:26AM -0700, Jonathan Morley wrote:
> As of git: ea97859c8c218b83ab747a7eabcb88ca446f6751 line 1533 in
> libavcodec/adpcm.c contains:
>
> static const enum AVSampleFormat sample_fmts_s16p[] = { AV_SAMPLE_FMT_S16,
>
> I believe it should contain:
>
> static const enu
Signed-off-by: James Almer
---
libavcodec/tiff.c | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/libavcodec/tiff.c b/libavcodec/tiff.c
index 980aaf1..2bb7c90 100644
--- a/libavcodec/tiff.c
+++ b/libavcodec/tiff.c
@@ -333,9 +333,9 @@ static int tiff_uncompress
Signed-off-by: James Almer
---
libavcodec/tiff.c | 57 +++
1 file changed, 28 insertions(+), 29 deletions(-)
diff --git a/libavcodec/tiff.c b/libavcodec/tiff.c
index d5c03e8..980aaf1 100644
--- a/libavcodec/tiff.c
+++ b/libavcodec/tiff.c
@@ -28
On Tue, Aug 19, 2014 at 01:30:24AM +0200, Carl Eugen Hoyos wrote:
> Hi!
>
> Attached patch removes a request for samples of which we already
> have several that all work fine.
field_dominance can have 256 different values, do we have samples
for all ? do they even exist ?
is the st->codec->field_
As of git: ea97859c8c218b83ab747a7eabcb88ca446f6751 line 1533 in
libavcodec/adpcm.c contains:
static const enum AVSampleFormat sample_fmts_s16p[] = { AV_SAMPLE_FMT_S16,
I believe it should contain:
static const enum AVSampleFormat sample_fmts_s16p[] = { AV_SAMPLE_FMT_S16P,
Note the trailing "P
On Tue, Aug 19, 2014 at 01:39:33PM -0300, James Almer wrote:
> On 19/08/14 7:07 AM, Michael Niedermayer wrote:
> > is photometric guranteed to match the pix_fmt ?
> >
> > iam asking as i dont see that being ensured by the code but i might
> > be missing something
> > if they could mismatch, id assu
On Tue, Aug 19, 2014 at 02:50:39PM +0200, Moritz Barsnick wrote:
> Hi,
>
> I believe the h264_mp4toannexb message could be a bit more precise, and
> use the same wording as the aac_adtstoasc message.
>
> ("-bsf h264_mp4toannexb" used to give me warnings that it was ambiguous
> as to which stream
On 19.08.2014, at 15:46, Clément Bœsch wrote:
> On Tue, Aug 19, 2014 at 01:41:49PM +, Carl Eugen Hoyos wrote:
>> Clément Bœsch pkh.me> writes:
>>
>>> On Mon, Aug 18, 2014 at 11:39:26PM +, Carl Eugen Hoyos wrote:
Clément Bœsch pkh.me> writes:
> +{ AV_CODEC_ID_PCM_S24BE
On 19/08/14 7:07 AM, Michael Niedermayer wrote:
> is photometric guranteed to match the pix_fmt ?
>
> iam asking as i dont see that being ensured by the code but i might
> be missing something
> if they could mismatch, id assume it might crash
TIFF_PHOTOMETRIC_YCBCR seems to simply be a flag to si
Hi,
2014-08-19 16:20 GMT+02:00 Nicolas George :
> IMHO, the correct error depends on how sure you are that a buffer too small
> SHOULD not happen.
>
> If you are very sure, then av_assert0().
That would be it: I'm sure that, if the condition occurs and the
packet is written anyway, the file will
Hi,
I believe the h264_mp4toannexb message could be a bit more precise, and
use the same wording as the aac_adtstoasc message.
("-bsf h264_mp4toannexb" used to give me warnings that it was ambiguous
as to which stream to apply to, i.e. wanting to have the ":v"
specifier. But I can't reproduce tha
On Tue, Aug 19, 2014 at 02:50:37PM +0200, Paul B Mahol wrote:
> On 8/19/14, Christophe Gisquet wrote:
> > The allocation didn't account for headers, that can be easily 79 bytes.
> > As a result, buffers allocated for a few samples (e.g. 5 in the original
> > bug) could be undersized.
> >
> > Fixed
On Tue, Aug 19, 2014 at 02:50:58PM +0200, Paul B Mahol wrote:
> On 8/19/14, Christophe Gisquet wrote:
> > ---
> > libavcodec/wavpack.c | 4
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/libavcodec/wavpack.c b/libavcodec/wavpack.c
> > index 7c60f78..9f72ebe 100644
> > --- a/libavco
Le duodi 2 fructidor, an CCXXII, Christophe Gisquet a écrit :
> >> +return AVERROR_INVALIDDATA;
> > Shouldn't this be AVERROR_BUG?
> This was selected as a default, not knowing exactly what to put here.
> There's even a AVERROR_BUFFER_TOO_SMALL, but I though it would be used
> for user-prov
On Tue, Aug 19, 2014 at 07:44:53AM -0600, Roger Pack wrote:
> OK I was able to reproduce the problem.
> Patch looks good, see attached, FWIW.
> Thanks!
> -roger-
applied
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
In a rich man's house there is no p
Hi,
2014-08-19 16:06 GMT+02:00 Timothy Gu :
>> +return AVERROR_INVALIDDATA;
>
> Shouldn't this be AVERROR_BUG?
This was selected as a default, not knowing exactly what to put here.
There's even a AVERROR_BUFFER_TOO_SMALL, but I though it would be used
for user-provided buffers.
--
Chris
On Tue, Aug 19, 2014 at 5:26 AM, Christophe Gisquet
wrote:
> bytestream2_* will not cause buffer overflow, but on the other hand,
> it should be checked whether overflows have been prevented.
> ---
> libavcodec/wavpackenc.c | 5 +
> 1 file changed, 5 insertions(+)
[...]
> +return AVER
On Tue, Aug 19, 2014 at 01:41:49PM +, Carl Eugen Hoyos wrote:
> Clément Bœsch pkh.me> writes:
>
> > On Mon, Aug 18, 2014 at 11:39:26PM +, Carl Eugen Hoyos wrote:
> > > Clément Bœsch pkh.me> writes:
> > >
> > > > +{ AV_CODEC_ID_PCM_S24BE, MKTAG('n', 'i', '2', '4') },
> > > > BB
OK I was able to reproduce the problem.
Patch looks good, see attached, FWIW.
Thanks!
-roger-
On Sat, Aug 16, 2014 at 4:17 PM, Michael Niedermayer
wrote:
> On Fri, Aug 08, 2014 at 05:08:46PM +0800, hlszl1...@163.com wrote:
> > hi, all
> >
> > I'm using gdigrab feature on windows, and found that
Deti Fliegl fliegl.de> writes:
> Minor update to propagate field dominance.
At least a Changelog entry and a libavdevice version
bump are still missing, but consider waiting for a
real review.
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@f
Clément Bœsch pkh.me> writes:
> On Mon, Aug 18, 2014 at 11:39:26PM +, Carl Eugen Hoyos wrote:
> > Clément Bœsch pkh.me> writes:
> >
> > > +{ AV_CODEC_ID_PCM_S24BE, MKTAG('n', 'i', '2', '4') },
> > > BBC typo */
> > > +{ AV_CODEC_ID_PCM_S24LE, MKTAG('n', 'i', '2', '4') },
Hendrik Leppkes gmail.com> writes:
> Am 19.08.2014 01:34 schrieb "Carl Eugen Hoyos":
> >
> > Attached patch from Elemental increases the
> > maximum superframe size, I don't know if this
> > fixes any samples.
>
> It makes no sense to send random patches without
> either understanding the cod
James Almer gmail.com> writes:
> +static void unpack_yuv(TiffContext *s, AVFrame *p,
> + const uint8_t *src, int lnum)
> -static void unpack_yuv(TiffContext *s, AVFrame *p,
> - const uint8_t *src, int lnum)
If you want you could split the moving of th
On 8/19/14, Christophe Gisquet wrote:
> ---
> libavcodec/wavpack.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/libavcodec/wavpack.c b/libavcodec/wavpack.c
> index 7c60f78..9f72ebe 100644
> --- a/libavcodec/wavpack.c
> +++ b/libavcodec/wavpack.c
> @@ -253,6 +253,10 @@ static int w
On 8/19/14, Christophe Gisquet wrote:
> The allocation didn't account for headers, that can be easily 79 bytes.
> As a result, buffers allocated for a few samples (e.g. 5 in the original
> bug) could be undersized.
>
> Fixed ticket #2881.
> ---
> libavcodec/wavpackenc.c | 5 +++--
> 1 file change
On 8/19/14, Christophe Gisquet wrote:
> bytestream2_* will not cause buffer overflow, but on the other hand,
> it should be checked whether overflows have been prevented.
> ---
> libavcodec/wavpackenc.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/libavcodec/wavpackenc.c b/libavc
From: Clément Bœsch
---
libavfilter/avf_showwaves.c | 119 +++-
1 file changed, 74 insertions(+), 45 deletions(-)
diff --git a/libavfilter/avf_showwaves.c b/libavfilter/avf_showwaves.c
index e4911cc..1389e64 100644
--- a/libavfilter/avf_showwaves.c
+++ b/
From: Clément Bœsch
---
doc/filters.texi| 3 +++
libavfilter/avf_showwaves.c | 14 ++
2 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index 828f2b4..7939018 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -10830
From: Clément Bœsch
---
doc/filters.texi| 3 +++
libavfilter/avf_showwaves.c | 24 +++-
2 files changed, 22 insertions(+), 5 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index 0ca1d6f..828f2b4 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
The allocation didn't account for headers, that can be easily 79 bytes.
As a result, buffers allocated for a few samples (e.g. 5 in the original
bug) could be undersized.
Fixed ticket #2881.
---
libavcodec/wavpackenc.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/libav
The decoder is reporting CRC errors instead of the prime cause of
end-of-packet. This happens with current encoder when there are a few
samples and the output buffer is undersized because its size didn't
account for headers.
Christophe Gisquet (3):
wavpack: report if there is no bits left
wavp
bytestream2_* will not cause buffer overflow, but on the other hand,
it should be checked whether overflows have been prevented.
---
libavcodec/wavpackenc.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavcodec/wavpackenc.c b/libavcodec/wavpackenc.c
index 5b8973c..46c69a3 100644
---
---
libavcodec/wavpack.c | 4
1 file changed, 4 insertions(+)
diff --git a/libavcodec/wavpack.c b/libavcodec/wavpack.c
index 7c60f78..9f72ebe 100644
--- a/libavcodec/wavpack.c
+++ b/libavcodec/wavpack.c
@@ -253,6 +253,10 @@ static int wv_get_value(WavpackFrameContext *ctx,
GetBitContext *gb
On Tue, Aug 19, 2014 at 01:43:28PM +0200, Christophe Gisquet wrote:
> 2014-08-19 12:40 GMT+02:00 Michael Niedermayer :
> >> In the same fashion, shouldn't delta computation be updated to be:
> >> 200 + (ctx->pictures_per_frame * ctx->slices_per_picture + 1) * etc ?
> >
> > yes, locally changed
>
>
On Tue, Aug 19, 2014 at 01:42:44PM +0200, Christophe Gisquet wrote:
> Hi,
>
> 2014-08-19 12:31 GMT+02:00 Michael Niedermayer :
> > suggested commit message:
> > avcodec/proresenc_kostya: set initial max_slice_size based on
> > frame_size_upper_bound
> >
> > If the initial max_slice_size i
On Tue, Aug 19, 2014 at 09:35:33AM +0200, Christophe Gisquet wrote:
> Hi,
>
> 2014-08-18 22:35 GMT+02:00 Michael Niedermayer :
> > the "[PATCH 1/2] huffyuv: change statistics initialization"
> > patch has has been applied
>
> I thought your last "applied" message referred to the other patch in
>
On Fri, Jun 13, 2014 at 12:56:30AM +0200, Christophe Gisquet wrote:
> Hi,
>
> 2014-06-12 0:18 GMT+02:00 Michael Niedermayer :
> > i think adding a codec private option like
> > -non_deterministic 1
> > is safer than using the flags in terms of compatibility
> > it also would produce an error if th
2014-08-19 12:40 GMT+02:00 Michael Niedermayer :
>> In the same fashion, shouldn't delta computation be updated to be:
>> 200 + (ctx->pictures_per_frame * ctx->slices_per_picture + 1) * etc ?
>
> yes, locally changed
Good for me then.
--
Christophe
___
On 8/18/14, Moritz Mühlenhoff wrote:
> Andreas Cadhalpun schrieb:
>> Hi Thomas,
>>
>> On 18.08.2014 08:36, Thomas Goirand wrote:
>>> There's been a very well commented technical reason stated here: the
>>> release team don't want to deal with 2 of the same library that are
>>> doing (nearly) the
Hi,
2014-08-19 12:31 GMT+02:00 Michael Niedermayer :
> suggested commit message:
> avcodec/proresenc_kostya: set initial max_slice_size based on
> frame_size_upper_bound
>
> If the initial max_slice_size is 0 then reallocation is disabled for the
> first
> slice.
OK.
--
Christophe
On Tue, Aug 19, 2014 at 12:17:59AM -0600, Pavel Koshevoy wrote:
> Fixes ticket #3829
> ---
> libavfilter/af_atempo.c | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
applied
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
I have often repe
Minor update to propagate field dominance.
On 18.08.14 20:40, Deti Fliegl wrote:
> Rebased commits to have all changes in one patch. Hopefully it's
> complete now.
>
> Deti
>
> On 18.08.14 19:48, Deti Fliegl wrote:
>> On 18.08.14 19:23, Carl Eugen Hoyos wrote:
>>> Deti Fliegl fliegl.de> writes:
Hi,
On Tue, Aug 19, 2014 at 10:50:31AM +0200, Ondřej Surý wrote:
[...]
> From the security viewpoint, I would be also interested if ffmpeg
> has tests and what is current code coverage. That could help avoiding
> regressions when doing security updates.
>
> 1. There are also other tools: llvm/cla
On Tue, Aug 19, 2014 at 09:49:10AM +0200, Christophe Gisquet wrote:
> Hi,
>
> 2014-08-18 21:49 GMT+02:00 Michael Niedermayer :
> > +int max_slice_size = (ctx->frame_size_upper_bound - 200) /
> > (ctx->pictures_per_frame * ctx->slices_per_picture + 1);
>
> Regarding the reallocation check:
>
On Sat, Aug 16, 2014, at 17:29, Thomas Goirand wrote:
> On 08/15/2014 11:53 PM, The Wanderer wrote:
> > It's also something the Linux kernel is still doing, with apparent
> > success.
>
> Yes, the Linux kernel is a successful project. Does this mean using a
> list for reviewing patches is a good t
On Sat, Aug 16, 2014, at 20:59, Russ Allbery wrote:
> The problem, however, is that taking security seriously, while possibly
> necessary, is not sufficient. I'm glad that FFmpeg takes security
> seriously, but what FFmpeg needs is to *have fewer security bugs*.
JFTR the Coverity Scan results for
On Tue, Aug 19, 2014 at 09:40:03AM +0200, Christophe Gisquet wrote:
> Hi,
>
> 2014-08-18 21:49 GMT+02:00 Michael Niedermayer :
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavcodec/proresenc_kostya.c |3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/liba
On Tue, Aug 19, 2014 at 01:54:58AM -0300, James Almer wrote:
> Signed-off-by: James Almer
> ---
> Seems to work great with yuv deflate tiff images created with our tiff encoder
>
> libavcodec/tiff.c | 71
> +++
> 1 file changed, 35 insertions(
Hi,
2014-08-18 21:49 GMT+02:00 Michael Niedermayer :
> +int max_slice_size = (ctx->frame_size_upper_bound - 200) /
> (ctx->pictures_per_frame * ctx->slices_per_picture + 1);
Regarding the reallocation check:
pkt_size <= buf - orig_buf + 2 * max_slice_size
For last slice, pkt_size would be (N
Hi,
2014-08-18 21:49 GMT+02:00 Michael Niedermayer :
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/proresenc_kostya.c |3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/proresenc_kostya.c b/libavcodec/proresenc_kostya.c
> index 0f69767..1e40dcf 100
Hi,
2014-08-18 22:35 GMT+02:00 Michael Niedermayer :
> the "[PATCH 1/2] huffyuv: change statistics initialization"
> patch has has been applied
I thought your last "applied" message referred to the other patch in
this thread, so I'm probably the one confused here.
> is there some other patch ive
On 19/08/14 1:54 AM, James Almer wrote:
> Signed-off-by: James Almer
> ---
> Seems to work great with yuv deflate tiff images created with our tiff encoder
>
> libavcodec/tiff.c | 71
> +++
> 1 file changed, 35 insertions(+), 36 deletions(-)
>
On Mon, Aug 18, 2014 at 11:39:26PM +, Carl Eugen Hoyos wrote:
> Clément Bœsch pkh.me> writes:
>
> > +{ AV_CODEC_ID_PCM_S24BE, MKTAG('n', 'i', '2', '4') },
> > BBC typo */
> > +{ AV_CODEC_ID_PCM_S24LE, MKTAG('n', 'i', '2', '4') },
> > /* BBC typo */
>
> Doesn't this patch
71 matches
Mail list logo
