Sorry for delaying my reply.
Zhang Rui:
> ---
> libavformat/concatdec.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/libavformat/concatdec.c b/libavformat/concatdec.c
> index d21805f..4c7217c 100644
> --- a/libavformat/concatdec.c
> +++ b/libavformat/concatdec.c
> @@ -310,6 +310,7 @@
On Sun, Jan 03, 2016 at 09:49:33PM -0800, Ganesh Ajjanagadde wrote:
> On Sun, Jan 3, 2016 at 1:30 PM, Carl Eugen Hoyos wrote:
> > Carl Eugen Hoyos ag.or.at> writes:
> >
> >> Ganesh Ajjanagadde mit.edu> writes:
> >>
> >> > No one has told me what is interesting
> >>
> >> Did you look at tickets #
On Sun, Jan 03, 2016 at 09:11:28PM -0800, Ganesh Ajjanagadde wrote:
> On Sun, Jan 3, 2016 at 7:32 PM, Michael Niedermayer
> wrote:
> > On Mon, Jan 04, 2016 at 04:04:02AM +0100, Michael Niedermayer wrote:
> >> On Wed, Dec 30, 2015 at 08:34:55PM -0800, Ganesh Ajjanagadde wrote:
> >> > This gets rid
> When concatenated files are streamed via HTTP,
> opening all of them is not a good idea.
Exactly.
> If we've known that all files share same codec parameters,
> maybe first file's bit_rate would be the best guess.
Not at all. Having the same codec parameters, to some extent, is necessary
for c
>> av_dump_format() could show something better than 0.
>
> Yes, but what would be the point? How is it actually useful to know the
> average bitrate of a concatenated stream?
Actually, I use custom IO in my own application to prefetch data via HTTP.
I'm trying to calculate duration from bytes wit
On 04.01.2016 02:31, Michael Niedermayer wrote:
> On Sun, Jan 03, 2016 at 11:44:02PM +0100, Andreas Cadhalpun wrote:
>> vorbisdec.c |5 +
>> 1 file changed, 5 insertions(+)
>> cb124c1de2cdbe783b2217af90f082cbc6e0a29f
>> 0001-vorbisdec-reject-rangebits-0-with-non-0-partitions.patch
>> Fro
This fixes NULL pointer dereferencing.
Signed-off-by: Andreas Cadhalpun
---
libavformat/brstm.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavformat/brstm.c b/libavformat/brstm.c
index bbdbcef..6ec4d89 100644
--- a/libavformat/brstm.c
+++ b/libavformat/brstm.c
@@ -389,6 +389,11 @
This fixes NULL pointer dereferencing if the codec is forced to
adpcm_thp even though a different one was detected.
Signed-off-by: Andreas Cadhalpun
---
libavformat/brstm.c | 4
1 file changed, 4 insertions(+)
diff --git a/libavformat/brstm.c b/libavformat/brstm.c
index 6ec4d89..e9d64e4 10
On 1/4/16, Andreas Cadhalpun wrote:
> This fixes NULL pointer dereferencing if the codec is forced to
> adpcm_thp even though a different one was detected.
>
> Signed-off-by: Andreas Cadhalpun
> ---
> libavformat/brstm.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/libavformat/br
On 04.01.2016 13:15, Paul B Mahol wrote:
> On 1/4/16, Andreas Cadhalpun wrote:
>> This fixes NULL pointer dereferencing if the codec is forced to
>> adpcm_thp even though a different one was detected.
>>
>> Signed-off-by: Andreas Cadhalpun
>> ---
>> libavformat/brstm.c | 4
>> 1 file change
Same patch encoded as base64. I hope this time it won't get trashed.
Nicolas DEROUINEAU
Research Engineer
VITEC
T. +33 1 46 73 06 06
E. nicolas.derouin...@vitec.com
W. www.vitec.com
De : ffmpeg-devel de la part de Nicolas
Derouineau
Envoyé : jeudi 2
---
libswscale/arm/yuv2rgb_neon.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libswscale/arm/yuv2rgb_neon.S b/libswscale/arm/yuv2rgb_neon.S
index dd00246..d497dd4 100644
--- a/libswscale/arm/yuv2rgb_neon.S
+++ b/libswscale/arm/yuv2rgb_neon.S
@@ -299,7 +299,7 @@ function ff_
From: Matthieu Bouron
---
libswscale/arm/swscale_unscaled.c | 26 ++-
libswscale/arm/yuv2rgb_neon.S | 93 ---
2 files changed, 101 insertions(+), 18 deletions(-)
diff --git a/libswscale/arm/swscale_unscaled.c
b/libswscale/arm/swscale_unscaled.c
i
---
libavcodec/h264.c | 21 +
libavcodec/h264.h | 1 +
libavcodec/h264_sei.c | 3 +++
libavutil/frame.h | 8
4 files changed, 33 insertions(+)
diff --git a/libavcodec/h264.c b/libavcodec/h264.c
index 089a86f..e90bcc0 100644
--- a/libavcodec/h264.c
+++ b
On Mon, Jan 04, 2016 at 02:33:46PM +0100, Matthieu Bouron wrote:
> ---
> libswscale/arm/yuv2rgb_neon.S | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
LGTM
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
No snowflake in an avalanche ever feels resp
Hi Ganesh,
On 04.01.2016 06:49, Ganesh Ajjanagadde wrote:
> Generally, my strengths are in algorithmic/mathematical/numerical
> improvements. I have a strong interest in security (both its
> "practical" and "theoretical" variants), but with nowhere near the
> same level of knowledge.
>
> Clarific
From: Raymond Hilseth
Signed-off-by: Raymond Hilseth
---
libavformat/dashenc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 4509ee4..378c4e4 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -549,7 +5
Supporting this would require re-initialization to change buffer sizes.
This fixes out of bounds reads.
Signed-off-by: Andreas Cadhalpun
---
libavcodec/alsdec.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/libavcodec/alsdec.c b/libavcodec/alsdec.c
index ebd364e..5efa0cc 100644
-
Am 04.01.16 um 16:18 schrieb Andreas Cadhalpun:
> Supporting this would require re-initialization to change buffer sizes.
>
> This fixes out of bounds reads.
Can you upload a sample for this?
-Thilo
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.or
On Mon, Jan 4, 2016 at 1:04 AM, Kieran Kunhya wrote:
> Decodes YUV422P10 samples in AVI and MOV (Gopro Studio)
> Older files with more subbands, skips, Bayer not supported
> ---
> +static av_cold int cfhd_init_decoder(AVCodecContext *avctx)
> +{
> +CFHDContext *s = avctx->priv_data;
> +
> +
On Mon, Jan 04, 2016 at 02:33:47PM +0100, Matthieu Bouron wrote:
> From: Matthieu Bouron
>
> ---
> libswscale/arm/swscale_unscaled.c | 26 ++-
> libswscale/arm/yuv2rgb_neon.S | 93
> ---
> 2 files changed, 101 insertions(+), 18 deletions(-)
teste
On Mon, Jan 4, 2016 at 6:13 AM, Andreas Cadhalpun
wrote:
> Hi Ganesh,
>
> On 04.01.2016 06:49, Ganesh Ajjanagadde wrote:
>> Generally, my strengths are in algorithmic/mathematical/numerical
>> improvements. I have a strong interest in security (both its
>> "practical" and "theoretical" variants),
On Mon, Jan 4, 2016 at 3:58 PM, wrote:
> From: Raymond Hilseth
>
> Signed-off-by: Raymond Hilseth
> ---
> libavformat/dashenc.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
> index 4509ee4..378c4e4 100644
> --- a/lib
On Mon, Jan 4, 2016 at 1:29 AM, Clément Bœsch wrote:
> On Sun, Jan 03, 2016 at 09:49:33PM -0800, Ganesh Ajjanagadde wrote:
>> On Sun, Jan 3, 2016 at 1:30 PM, Carl Eugen Hoyos wrote:
>> > Carl Eugen Hoyos ag.or.at> writes:
>> >
>> >> Ganesh Ajjanagadde mit.edu> writes:
>> >>
>> >> > No one has t
On Mon, Jan 04, 2016 at 12:04:08AM +, Kieran Kunhya wrote:
> Decodes YUV422P10 samples in AVI and MOV (Gopro Studio)
> Older files with more subbands, skips, Bayer not supported
> ---
> libavcodec/Makefile | 1 +
> libavcodec/allcodecs.c | 1 +
> libavcodec/avcodec.h| 1 +
> lib
On Mon, Jan 4, 2016 at 8:36 AM, Hendrik Leppkes wrote:
> On Mon, Jan 4, 2016 at 3:58 PM, wrote:
>> From: Raymond Hilseth
>>
>> Signed-off-by: Raymond Hilseth
>> ---
>> libavformat/dashenc.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/libavformat/dashenc.c b
On 1/4/2016 4:46 PM, Ganesh Ajjanagadde wrote:
> Yes, this is strange. url_move points to file_move, and the only
> system functionality it relies on is rename, available in stdio.h. The
> semantics vary from system to system, with some details specified in
> POSIX, but rename itself is standard C:
Derek Buitenhuis gmail.com> writes:
> > -dm->queue[dm->fid].totdiff = INT64_MAX;
> > +dm->queue[dm->fid].totdiff = dm->scthresh;
>
> Upstream uses +1 here, but I'm not sure why
I wish I would understand;-(
Since this fixes a reported issue here, I will
commit my patch if nob
On Mon, 4 Jan 2016 13:33:02 +
Nicolas Derouineau wrote:
> Same patch encoded as base64. I hope this time it won't get trashed.
>
Well, now most likely nobody can comfortably read it.
Does your mail client not allow to simply attach text files?
__
On 1/4/2016 3:18 PM, Andreas Cadhalpun wrote:
> Supporting this would require re-initialization to change buffer sizes.
I may be mistaken, but don't we already support some codecs which do
this, properly?
- Derek
___
ffmpeg-devel mailing list
ffmpeg-dev
On 1/4/2016 5:17 PM, Carl Eugen Hoyos wrote:
> I wish I would understand;-(
>
> Since this fixes a reported issue here, I will
> commit my patch if nobody objects.
[17:30] * Daemon404 pokes ubitux
[17:30] <@ubitux> yup?
[17:30] <@Daemon404> do you have a comment on carl's decimate change
[17:31
On Mon, Jan 04, 2016 at 03:12:13PM +0100, Michael Niedermayer wrote:
> On Mon, Jan 04, 2016 at 02:33:46PM +0100, Matthieu Bouron wrote:
> > ---
> > libswscale/arm/yuv2rgb_neon.S | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
>
> LGTM
Pushed, thanks.
[...]
On Mon, Jan 04, 2016 at 05:07:50PM +0100, Michael Niedermayer wrote:
> On Mon, Jan 04, 2016 at 02:33:47PM +0100, Matthieu Bouron wrote:
> > From: Matthieu Bouron
> >
> > ---
> > libswscale/arm/swscale_unscaled.c | 26 ++-
> > libswscale/arm/yuv2rgb_neon.S | 93
> > ++
On Mon, Jan 4, 2016 at 9:12 AM, Derek Buitenhuis
wrote:
> On 1/4/2016 4:46 PM, Ganesh Ajjanagadde wrote:
>> Yes, this is strange. url_move points to file_move, and the only
>> system functionality it relies on is rename, available in stdio.h. The
>> semantics vary from system to system, with some
On 04.01.2016 16:29, Thilo Borgmann wrote:
> Am 04.01.16 um 16:18 schrieb Andreas Cadhalpun:
>> Supporting this would require re-initialization to change buffer sizes.
>>
>> This fixes out of bounds reads.
>
> Can you upload a sample for this?
Unfortunately (or fortunately?) the sample doesn't tr
Le quintidi 15 nivôse, an CCXXIV, Zhang Rui a écrit :
> Actually, I use custom IO in my own application to prefetch data via HTTP.
> I'm trying to calculate duration from bytes with bit_rate, for:
> 1. Calculate necessary download speed.
> 2. Adjust prefetch buffer size.
> 3. Show prefetched durati
Carl Eugen Hoyos ag.or.at> writes:
> -dm->queue[dm->fid].totdiff = INT64_MAX;
> +dm->queue[dm->fid].totdiff = dm->scthresh;
This is not correct, I will try to find the actual issue.
Sorry, Carl Eugen
___
ffmpeg-devel mailing
On Mon, Jan 04, 2016 at 02:50:44PM +0100, Nicolas DEROUINEAU wrote:
> ---
> libavcodec/h264.c | 21 +
> libavcodec/h264.h | 1 +
> libavcodec/h264_sei.c | 3 +++
> libavutil/frame.h | 8
this should be in a seperate patch and libavutil/version.h should
Ping! I could not find any other fields for version other than the
IMAGE_ABI_VERSION , CODEC_ABI_VERSION, DECODER_ABI_VERSION which remain
unchanged .
On Wed, Dec 30, 2015 at 2:21 PM, Ronald S. Bultje
wrote:
> Hi,
>
> On Wed, Dec 30, 2015 at 3:46 PM, Sasi Inguva wrote:
>
> > VPX_IMAGE_ABI_VERSI
Hi,
On Mon, Jan 4, 2016 at 1:48 PM, Sasi Inguva wrote:
> Ping! I could not find any other fields for version other than the
> IMAGE_ABI_VERSION , CODEC_ABI_VERSION, DECODER_ABI_VERSION which remain
> unchanged .
So, add a version check? Or check for the existence of the appropriate
color range
On 1/4/2016 6:05 PM, Ganesh Ajjanagadde wrote:
> Personally, I think it should be ok to use rename here for now,
> especially since even projects like Python had trouble with this
> aspect: https://bugs.python.org/issue8828. Someone with greater
> Windows expertise can then examine the validity of
On 04.01.2016 20:10, Derek Buitenhuis wrote:
On 1/4/2016 6:05 PM, Ganesh Ajjanagadde wrote:
Personally, I think it should be ok to use rename here for now,
especially since even projects like Python had trouble with this
aspect: https://bugs.python.org/issue8828. Someone with greater
Windows exp
Would it be a lot easier and correct if I just update the IMAGE_ABI_VERSION
to 4 in libvpx HEAD and check here in the decoder IMAGE_ABI_VERSION > 3 ?
On Mon, Jan 4, 2016 at 11:03 AM, Ronald S. Bultje
wrote:
> Hi,
>
> On Mon, Jan 4, 2016 at 1:48 PM, Sasi Inguva wrote:
>
> > Ping! I could not fi
On Mon, Jan 04, 2016 at 05:32:32PM +, Derek Buitenhuis wrote:
> On 1/4/2016 5:17 PM, Carl Eugen Hoyos wrote:
> > I wish I would understand;-(
> >
> > Since this fixes a reported issue here, I will
> > commit my patch if nobody objects.
>
> [17:30] * Daemon404 pokes ubitux
> [17:30] <@ubitux
Am 04.01.16 um 18:31 schrieb Derek Buitenhuis:
> On 1/4/2016 3:18 PM, Andreas Cadhalpun wrote:
>> Supporting this would require re-initialization to change buffer sizes.
>
> I may be mistaken, but don't we already support some codecs which do
> this, properly?
I'm quite sure that changing the num
Hi Sasi,
On Mon, Jan 4, 2016 at 3:01 PM, Sasi Inguva wrote:
> Would it be a lot easier and correct if I just update the IMAGE_ABI_VERSION
> to 4 in libvpx HEAD and check here in the decoder IMAGE_ABI_VERSION > 3 ?
Sure, that's fine also.
Ronald
___
On 1/4/2016 7:54 PM, Hendrik Leppkes wrote:
> rename is used unconditionally in ff_rename as far as I can tell, so it
> would probably be OK to remove the unistd.h check in file.c for rename?
I would git blame and ask the author if possible first.
- Derek
On 04.01.2016 21:18, Thilo Borgmann wrote:
> Am 04.01.16 um 18:31 schrieb Derek Buitenhuis:
>> On 1/4/2016 3:18 PM, Andreas Cadhalpun wrote:
>>> Supporting this would require re-initialization to change buffer sizes.
>>
>> I may be mistaken, but don't we already support some codecs which do
>> this
On 1/4/2016 5:01 PM, Sasi Inguva wrote:
> Would it be a lot easier and correct if I just update the IMAGE_ABI_VERSION
> to 4 in libvpx HEAD and check here in the decoder IMAGE_ABI_VERSION > 3 ?
Yes, bumping any of the defines would probably be best. It will not apply
to libvpxdec 1.5.0, though,
On 1/4/2016 8:18 PM, Thilo Borgmann wrote:
> I'm quite sure that changing the number of channels is invalid for ALS
> so there is no sense in implementing it.
Ah, OK.
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailma
Clément Bœsch pkh.me> writes:
> +if (cyclestart == 0) {
> +vdm->vmi[0].maxbdiff = vdm->vmi[1].maxbdiff;
> +vdm->vmi[0].totdiff = vdm->scthresh + 1;
> +}
> +
> I suggest to "cherry-pick" this if it works.
Nicolas has already found a very similar solution
that only differ
On Mon, Jan 04, 2016 at 08:53:24PM +, Carl Eugen Hoyos wrote:
> Clément Bœsch pkh.me> writes:
>
> > +if (cyclestart == 0) {
> > +vdm->vmi[0].maxbdiff = vdm->vmi[1].maxbdiff;
> > +vdm->vmi[0].totdiff = vdm->scthresh + 1;
> > +}
> > +
>
> > I suggest to "cherry-pick" th
In many older QuickTime files, the audio format, or "fourcc", is
0x (AV_CODEC_ID_NONE). The QuickTime File Format Specification
states the following regarding this situation:
"This format descriptor should not be used, but may be found in some
files. Samples are assumed to be stored in ei
In many older QuickTime files, the audio format, or "fourcc", is
0x (AV_CODEC_ID_NONE). The QuickTime File Format Specification
states the following regarding this situation:
"This format descriptor should not be used, but may be found in some
files. Samples are assumed to be stored in ei
On Mon, Jan 4, 2016 at 10:17 PM, Mats Peterson
wrote:
> In many older QuickTime files, the audio format, or "fourcc", is
> 0x (AV_CODEC_ID_NONE). The QuickTime File Format Specification
> states the following regarding this situation:
>
> "This format descriptor should not be used, but may
On 01/04/2016 10:34 PM, Hendrik Leppkes wrote:
On Mon, Jan 4, 2016 at 10:17 PM, Mats Peterson
wrote:
In many older QuickTime files, the audio format, or "fourcc", is
0x (AV_CODEC_ID_NONE). The QuickTime File Format Specification
states the following regarding this situation:
"This form
In many older QuickTime files, the audio format, or "fourcc", is
0x (AV_CODEC_ID_NONE). The QuickTime File Format Specification
states the following regarding this situation:
"This format descriptor should not be used, but may be found in some
files. Samples are assumed to be stored in ei
Otherwise this can have some surprising effects (crashes), so let's
better not allow it.
Signed-off-by: Andreas Cadhalpun
---
libavcodec/parser.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/libavcodec/parser.c b/libavcodec/parser.c
index 2809158..1f38edb 100644
--- a/libavco
On Mon, Jan 4, 2016 at 3:44 PM, Andreas Cadhalpun
wrote:
> Otherwise this can have some surprising effects (crashes), so let's
> better not allow it.
>
> Signed-off-by: Andreas Cadhalpun
> ---
> libavcodec/parser.c | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/libavcodec/
On 05.01.2016 00:51, Ganesh Ajjanagadde wrote:
> On Mon, Jan 4, 2016 at 3:44 PM, Andreas Cadhalpun
> wrote:
>> Otherwise this can have some surprising effects (crashes), so let's
>> better not allow it.
>>
>> Signed-off-by: Andreas Cadhalpun
>> ---
>> libavcodec/parser.c | 11 +++
>> 1 f
On Mon, Jan 4, 2016 at 4:05 PM, Andreas Cadhalpun
wrote:
> On 05.01.2016 00:51, Ganesh Ajjanagadde wrote:
>> On Mon, Jan 4, 2016 at 3:44 PM, Andreas Cadhalpun
>> wrote:
>>> Otherwise this can have some surprising effects (crashes), so let's
>>> better not allow it.
>>>
>>> Signed-off-by: Andreas
>This can still overflow to -256 causing the following line to crash.
>A first step towards fixing this would be to replace '2*(*ex) >> 8'
>with '*ex >> 7'. That has the same result whenever the first expression
>is not undefined and should be faster, as well. ;)
>This prevents most of these crashe
On Mon, Jan 4, 2016 at 2:45 AM, Michael Niedermayer
wrote:
> On Sun, Jan 03, 2016 at 09:11:28PM -0800, Ganesh Ajjanagadde wrote:
>> On Sun, Jan 3, 2016 at 7:32 PM, Michael Niedermayer
>> wrote:
>> > On Mon, Jan 04, 2016 at 04:04:02AM +0100, Michael Niedermayer wrote:
>> >> On Wed, Dec 30, 2015 at
On Wed, Dec 30, 2015 at 8:34 PM, Ganesh Ajjanagadde
wrote:
> Previous commit has sped up pcm_tablegen slightly, and table generation
> of the alaw and mulaw tables is ~ 20k cycles. Thus, these tables can
> always be generated at runtime.
>
> Tested with/without --enable-hardcoded-tables.
>
> Signe
On Sat, Jan 2, 2016 at 7:59 AM, Ganesh Ajjanagadde wrote:
> On Sat, Jan 2, 2016 at 6:24 AM, Michael Niedermayer
> wrote:
>> On Fri, Jan 01, 2016 at 05:55:31PM -0800, Ganesh Ajjanagadde wrote:
>>> On Wed, Dec 30, 2015 at 1:01 AM, Hendrik Leppkes
>>> wrote:
>>> > On Wed, Dec 30, 2015 at 4:39 AM,
ffio_ensure_seekback can fail due to e.g ENOMEM. This return value is
checked here and a diagnostic is logged.
All usage of ffio_ensure_seekback in the codebase now has the return value
checked.
Reviewed-by: wm4
Reviewed-by: Ronald S. Bultje
Reviewed-by: Michael Niedermayer
Signed-off-by: Gan
This exploits an approach based on the sieve of Eratosthenes, a popular
method for generating prime numbers.
Tables are identical to previous ones.
Tested with FATE with/without --enable-hardcoded-tables.
Sample benchmark (Haswell, GNU/Linux+gcc):
prev:
7860100 decicycles in cbrt_tableinit,
This is faster; precision assured as result is a float.
Signed-off-by: Ganesh Ajjanagadde
---
libavfilter/avf_showspectrum.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavfilter/avf_showspectrum.c b/libavfilter/avf_showspectrum.c
index accd8c7..cff98ff 100644
--- a/lib
2016-01-05 2:12 GMT+08:00 Nicolas George :
> Le quintidi 15 nivôse, an CCXXIV, Zhang Rui a écrit :
>> Actually, I use custom IO in my own application to prefetch data via HTTP.
>> I'm trying to calculate duration from bytes with bit_rate, for:
>> 1. Calculate necessary download speed.
>> 2. Adjust
sqrt is faster, and is sometimes more accurate depending on the libm.
Signed-off-by: Ganesh Ajjanagadde
---
libavfilter/af_compensationdelay.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavfilter/af_compensationdelay.c
b/libavfilter/af_compensationdelay.c
index 33ee7e
avio_closep is not guaranteed to succeed, and its return value can
contain information regarding failure of preceding writes and silent
loss of data (man 2 close, man fclose). Users should know when the
progress was not successfully logged, and so a diagnostic is printed
here.
The reason only one
From: Aman Gupta
---
libavcodec/ccaption_dec.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/libavcodec/ccaption_dec.c b/libavcodec/ccaption_dec.c
index 9f67caa..4e478e0 100644
--- a/libavcodec/ccaption_dec.c
+++ b/libavcodec/ccaption_dec.c
@@ -21,7 +21,6 @@
#include "avcodec.h"
#includ
From: Aman Gupta
---
libavcodec/ccaption_dec.c | 98 ++-
1 file changed, 45 insertions(+), 53 deletions(-)
diff --git a/libavcodec/ccaption_dec.c b/libavcodec/ccaption_dec.c
index 4e478e0..96f0ccf 100644
--- a/libavcodec/ccaption_dec.c
+++ b/libavcode
From: Aman Gupta
---
libavcodec/ccaption_dec.c | 92 +++
1 file changed, 53 insertions(+), 39 deletions(-)
diff --git a/libavcodec/ccaption_dec.c b/libavcodec/ccaption_dec.c
index 96f0ccf..788e96a 100644
--- a/libavcodec/ccaption_dec.c
+++ b/libavcode
Simplified the patch somewhat. Description follows:
In many older QuickTime files, the audio format, or "fourcc", is
0x (AV_CODEC_ID_NONE). The QuickTime File Format Specification
states the following regarding this situation:
"This format descriptor should not be used, but may be found
On Mon, Jan 4, 2016 at 9:45 PM, Mats Peterson
wrote:
> Simplified the patch somewhat. Description follows:
>
> In many older QuickTime files, the audio format, or "fourcc", is
> 0x (AV_CODEC_ID_NONE). The QuickTime File Format Specification
> states the following regarding this situation:
On 01/05/2016 07:05 AM, Ganesh Ajjanagadde wrote:
On Mon, Jan 4, 2016 at 9:45 PM, Mats Peterson
wrote:
Simplified the patch somewhat. Description follows:
In many older QuickTime files, the audio format, or "fourcc", is
0x (AV_CODEC_ID_NONE). The QuickTime File Format Specification
sta
On Mon, Jan 4, 2016 at 10:09 PM, Mats Peterson
wrote:
> On 01/05/2016 07:05 AM, Ganesh Ajjanagadde wrote:
>>
>> On Mon, Jan 4, 2016 at 9:45 PM, Mats Peterson
>> wrote:
>>>
>>> Simplified the patch somewhat. Description follows:
>>>
>>> In many older QuickTime files, the audio format, or "fourcc",
On 01/05/2016 07:16 AM, Ganesh Ajjanagadde wrote:
Sorry, my gmail webmail does not seem to handle this correctly.
Ah, OK!
Mats
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On Sun, Jan 03, 2016 at 01:37:18PM -0500, Derek Buitenhuis wrote:
> It serves absolutely no purpose other than to confuse potentional
> Android developers about how to use hardware acceleration properly
> on the the platform. Both stagefright itself, and MediaCodec, have
> avcodec backends already,
80 matches
Mail list logo
