Re: [FFmpeg-devel] [PATCH] avformat/concatdec: get bit_rate from internal format

[Nicolas George]

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 @@ static int open_file(AVFormatContext *avf, unsigned 
> fileno)
>  avformat_close_input(&cat->avf);
>  return ret;
>  }
> +avf->bit_rate = cat->avf->bit_rate;
>  cat->cur_file = file;
>  if (file->start_time == AV_NOPTS_VALUE)
>  file->start_time = !fileno ? 0 :

I do not think this would be correct. The different concatenated files may
not have the same bit rate, therefore we can not know the real value without
opening all of them and averaging. This version would just have the value
change at each opened file, which is not supposed to happen.

The documentation says: "0 if not available", this is exactly what happens
here.

Why do you think this is useful?

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] lavc/pcm_tablegen: slight speedup of table generation

[Clément Bœsch]

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 #4441 or #4085?
> >
> > Or ticket #4829 or a j2k issue?
> 
> Thanks a lot for taking the time to point these out. They have all
> been noted. Unfortunately, I have too many things on my list now. 4829
> may be what I tackle first; it may take a while though.
> 
> I hope the following is helpful.
> Generally, my strengths are in algorithmic/mathematical/numerical
> improvements. 

but not interested in merging pre-filter and RLB-filter in EBU R128 like I
pointed out? :(

More seriously, maybe try to write a filter? I'm thinking of the Eulerian
magnification filter¹², which I unfortunately haven't time to work on.

You may also enjoy studying motion interpolation for many applications.

Anyway, the point is, you have a very large range of possibilities to
enjoy yourself on the project wrt image processing.

[1]: http://people.csail.mit.edu/mrub/vidmag/
[2]: https://www.youtube.com/watch?v=ONZcjs1Pjmk

> I have a strong interest in security (both its
> "practical" and "theoretical" variants), but with nowhere near the
> same level of knowledge.
> 
> Clarifications: by algorithmic improvements, I do not usually count
> asm code, but make exceptions in some cases. In particular, I have
> minimal knowledge of assembly and minimal motivation in learning it.
> However, I may examine at some point cases where I am convinced that a
> compiler can't do the needful.
> By theoretical aspects of security, I refer to defensive programming,
> some forms of undefined behavior (e.g rint64_clip, many ubsan
> failures), and other such things such as those flagged by Coverity. By
> practical aspects of security, I refer to things like fuzzing crashes,
> other ubsan failures, and other things flagged by Coverity or found by
> audit.

Well, I have a challenging suggestion then... How about looking at
threading? Look for Helgrind (or DRD) on http://fate.ffmpeg.org. I know
many of the report are false positive... but are they? Do we have real
issues spotted here? You might want to study why we have so much of them,
if ints read/write really are actually atomic on all platforms, ... that
sort of stuff :)

-- 
Clément B.


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] lavc/pcm_tablegen: slight speedup of table generation

[Michael Niedermayer]

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 of some branches to speed up table generation slightly
> >> > (impact higher on mulaw than alaw). Tables are identical to before,
> >> > tested with FATE.
> >> >
> >> > Sample benchmark (Haswell, GNU/Linux+gcc):
> >> > old:
> >> >  313494 decicycles in build_alaw_table,4094 runs,  2 skips
> >> >  315959 decicycles in build_alaw_table,8190 runs,  2 skips
> >> >
> >> >  323599 decicycles in build_ulaw_table,4095 runs,  1 skips
> >> >  318849 decicycles in build_ulaw_table,8188 runs,  4 skips
> >> >
> >> > new:
> >> >  261902 decicycles in build_alaw_table,4096 runs,  0 skips
> >> >  266519 decicycles in build_alaw_table,8192 runs,  0 skips
> >> >
> >> >  209657 decicycles in build_ulaw_table,4096 runs,  0 skips
> >> >  232656 decicycles in build_ulaw_table,8192 runs,  0 skips
> >> >
> >> > Signed-off-by: Ganesh Ajjanagadde 
> >> > ---
> >> >  libavcodec/pcm_tablegen.h | 24 
> >> >  1 file changed, 12 insertions(+), 12 deletions(-)
> >> >
> >> > diff --git a/libavcodec/pcm_tablegen.h b/libavcodec/pcm_tablegen.h
> >> > index 1387210..7269977 100644
> >> > --- a/libavcodec/pcm_tablegen.h
> >> > +++ b/libavcodec/pcm_tablegen.h
> >> > @@ -87,21 +87,21 @@ static av_cold void build_xlaw_table(uint8_t 
> >> > *linear_to_xlaw,
> >> >  {
> >> >  int i, j, v, v1, v2;
> >> >
> >> > -j = 0;
> >> > -for(i=0;i<128;i++) {
> >> > -if (i != 127) {
> >> > -v1 = xlaw2linear(i ^ mask);
> >> > -v2 = xlaw2linear((i + 1) ^ mask);
> >> > -v = (v1 + v2 + 4) >> 3;
> >> > -} else {
> >> > -v = 8192;
> >> > -}
> >> > -for(;j >> > +j = 1;
> >> > +linear_to_xlaw[8192] = mask;
> >> > +for(i=0;i<127;i++) {
> >> > +v1 = xlaw2linear(i ^ mask);
> >> > +v2 = xlaw2linear((i + 1) ^ mask);
> >> > +v = (v1 + v2 + 4) >> 3;
> >> > +for(;j >> > +linear_to_xlaw[8192 - j] = (i ^ (mask ^ 0x80));
> >> >  linear_to_xlaw[8192 + j] = (i ^ mask);
> >> > -if (j > 0)
> >> > -linear_to_xlaw[8192 - j] = (i ^ (mask ^ 0x80));
> >> >  }
> >> >  }
> >> > +for(;j<8192;j++) {
> >> > +linear_to_xlaw[8192 - j] = (127 ^ (mask ^ 0x80));
> >> > +linear_to_xlaw[8192 + j] = (127 ^ mask);
> >> > +}
> >> >  linear_to_xlaw[0] = linear_to_xlaw[1];
> >>
> >> i think you can make the tables 8 times smaller
> >
> > forget this, i should have checked the whole table or looked when i
> > am awake ...
> 
> ha ha. By the way, both changes are needed to get this level of
> speedup, with only the j change which you acked, the speedup is much
> smaller. But then also note that the other parts of the patch also
> increase the binary size more.

hmm, ok if its needed to get the speedup then LGTM

thanks

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Concerning the gods, I have no means of knowing whether they exist or not
or of what sort they may be, because of the obscurity of the subject, and
the brevity of human life -- Protagoras


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/concatdec: get bit_rate from internal format

[Nicolas George]

> 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 concatenating: concatenating Theora and H.264 does not make any sense.

The bitrate, on the other hand, can vary from second to second, most streams
are VFR nowadays anyways.

> At least, do you mind if I introduce an option in concat file,
> or as an AVOption, to enable it manually?

If it is useful, but...:

> 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?

Regards,

-- 
  Nicolas George
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/concatdec: get bit_rate from internal format

[Zhang Rui]

>> 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 with bit_rate, for:
1. Calculate necessary download speed.
2. Adjust prefetch buffer size.
3. Show prefetched duration in progress bar.

I thought AVFormatContext.bit_rate is a convenient alias.
Is AVCodecContext.bit_rate more suitable for these purpose?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/3] vorbisdec: replace get_bits with get_bitsz where n can be 0

[Andreas Cadhalpun]

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
>> From 37170226888eb08fe1d98e31bed4a0a8199bd7e3 Mon Sep 17 00:00:00 2001
>> From: Andreas Cadhalpun 
>> Date: Sun, 3 Jan 2016 19:11:24 +0100
>> Subject: [PATCH] vorbisdec: reject rangebits 0 with non-0 partitions
>>
>> This causes non-unique elements in floor_setup->data.t1.list, which
>> makes the stream undecodable according to the specification.
>>
>> Signed-off-by: Andreas Cadhalpun 
>> ---
>>  libavcodec/vorbisdec.c | 5 +
>>  1 file changed, 5 insertions(+)
> 
> LGTM

Pushed.

Best regards,
Andreas

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 1/2] brstm: make sure an ADPC chunk was read for adpcm_thp

[Andreas Cadhalpun]

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 @@ static int read_packet(AVFormatContext *s, AVPacket *pkt)
 codec->codec_id == AV_CODEC_ID_ADPCM_THP_LE) {
 uint8_t *dst;
 
+if (!b->adpc) {
+av_log(s, AV_LOG_ERROR, "adpcm_thp requires ADPC chunk, but none 
was found.\n");
+return AVERROR_INVALIDDATA;
+}
+
 if (size > (INT_MAX - 32 - 4) ||
 (32 + 4 + size) > (INT_MAX / codec->channels) ||
 (32 + 4 + size) * codec->channels > INT_MAX - 8)
-- 
2.6.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 2/2] brstm: also allocate b->table in read_packet

[Andreas Cadhalpun]

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 100644
--- a/libavformat/brstm.c
+++ b/libavformat/brstm.c
@@ -392,6 +392,10 @@ static int read_packet(AVFormatContext *s, AVPacket *pkt)
 if (!b->adpc) {
 av_log(s, AV_LOG_ERROR, "adpcm_thp requires ADPC chunk, but none 
was found.\n");
 return AVERROR_INVALIDDATA;
+if (!b->table) {
+b->table = av_mallocz(32 * codec->channels);
+if (!b->table)
+return AVERROR(ENOMEM);
 }
 
 if (size > (INT_MAX - 32 - 4) ||
-- 
2.6.4

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] brstm: also allocate b->table in read_packet

[Paul B Mahol]

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/brstm.c b/libavformat/brstm.c
> index 6ec4d89..e9d64e4 100644
> --- a/libavformat/brstm.c
> +++ b/libavformat/brstm.c
> @@ -392,6 +392,10 @@ static int read_packet(AVFormatContext *s, AVPacket
> *pkt)
>  if (!b->adpc) {
>  av_log(s, AV_LOG_ERROR, "adpcm_thp requires ADPC chunk, but
> none was found.\n");
>  return AVERROR_INVALIDDATA;
> +if (!b->table) {
> +b->table = av_mallocz(32 * codec->channels);
> +if (!b->table)
> +return AVERROR(ENOMEM);
>  }
>
>  if (size > (INT_MAX - 32 - 4) ||
> --
> 2.6.4
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

whole set ok
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] brstm: also allocate b->table in read_packet

[Andreas Cadhalpun]

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 changed, 4 insertions(+)
>>
>> diff --git a/libavformat/brstm.c b/libavformat/brstm.c
>> index 6ec4d89..e9d64e4 100644
>> --- a/libavformat/brstm.c
>> +++ b/libavformat/brstm.c
>> @@ -392,6 +392,10 @@ static int read_packet(AVFormatContext *s, AVPacket
>> *pkt)
>>  if (!b->adpc) {
>>  av_log(s, AV_LOG_ERROR, "adpcm_thp requires ADPC chunk, but
>> none was found.\n");
>>  return AVERROR_INVALIDDATA;
>> +if (!b->table) {
>> +b->table = av_mallocz(32 * codec->channels);
>> +if (!b->table)
>> +return AVERROR(ENOMEM);
>>  }
>>
>>  if (size > (INT_MAX - 32 - 4) ||
>> --
>> 2.6.4
>>
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
> 
> whole set ok

That was fast! :)

Set pushed.

Best regards,
Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Adding frame side data about green metadata

[Nicolas Derouineau]

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 24 décembre 2015 11:31
À : FFmpeg development discussions and patches
Cc : vittorio.giov...@gmail.com; Michael Niedermayer; Carl Eugen Hoyos
Objet : Re: [FFmpeg-devel] [PATCH] Adding frame side data   about   green   
metadata

Please find here attached the updated patch with the suggested modifications.

Best regards,

Nicolas DEROUINEAU


De : ffmpeg-devel  de la part de Michael 
Niedermayer 
Envoyé : mercredi 23 décembre 2015 14:49
À : FFmpeg development discussions and patches
Objet : Re: [FFmpeg-devel] [PATCH] Adding frame side data about green   metadata

On Wed, Dec 23, 2015 at 12:43:48PM +, Nicolas Derouineau wrote:
> > Sorry if I missed something:
> > What is green metadata?
>
> Greenmetadata is a set of metrics specified in ISO/IEC 23001-11.
>
> They are used to predict the decoding complexity (in terms of cycles) of AVC 
> frames. It is useful to perform DVFS (ie: CPU frequency scaling) in order to 
> reduce decoder power consumption.
>
> By the way, I'm not sure the patch was correctly attached. I'm trying one 
> more time to attach it.
[...]

> index e69de29..7b383e7 100644
> --- a/libavutil/greenmetadata.h
> +++ b/libavutil/greenmetadata.h
> @@ -0,0 +1,38 @@
> +/*
> + * Copyright (c) 2015 Nicolas DEROUINEAU 
> + *
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 
> USA
> + */
> +
> +#ifndef AVUTIL_GREENMD_H
> +#define AVUTIL_GREENMD_H
> +
> +#include 

> +#include 

libavutil should not include stuff from libavcodec
also it would be "libavcodec/h264.h" not 


[...]

--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Breaking DRM is a little like attempting to break through a door even
though the window is wide open and the only thing in the house is a bunch
of things you dont want and which you would get tomorrow for free anyway
RnJvbSAwNGUzMzg0MGE1YTlmMTY0MTE1MjdmNjEyOWFiOWRjYWVlMmUzM2JhIE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBOaWNvbGFzIERFUk9VSU5FQVUgPG5pY29sYXMuZGVyb3VpbmVh
dUB2aXRlYy5jb20+CkRhdGU6IFRodSwgMjQgRGVjIDIwMTUgMTE6MTY6NTcgKzAxMDAKU3ViamVj
dDogW1BBVENIXSBBZGQgZnJhbWUgc2lkZSBkYXRhIHdoZW4gU0VJIGdyZWVuIG1ldGFkYXRhIGFy
ZSBkZXRlY3RlZAoKLS0tCiBsaWJhdmNvZGVjL2gyNjQuYyAgICAgfCAyMSArKysrKysrKysrKysr
KysrKysrKysKIGxpYmF2Y29kZWMvaDI2NC5oICAgICB8ICAxICsKIGxpYmF2Y29kZWMvaDI2NF9z
ZWkuYyB8ICAzICsrKwogbGliYXZ1dGlsL2ZyYW1lLmggICAgIHwgIDggKysrKysrKysKIDQgZmls
ZXMgY2hhbmdlZCwgMzMgaW5zZXJ0aW9ucygrKQoKZGlmZiAtLWdpdCBhL2xpYmF2Y29kZWMvaDI2
NC5jIGIvbGliYXZjb2RlYy9oMjY0LmMKaW5kZXggMDg5YTg2Zi4uZTkwYmNjMCAxMDA2NDQKLS0t
IGEvbGliYXZjb2RlYy9oMjY0LmMKKysrIGIvbGliYXZjb2RlYy9oMjY0LmMKQEAgLTg3OSw2ICs4
NzksMjcgQEAgc3RhdGljIHZvaWQgZGVjb2RlX3Bvc3Rpbml0KEgyNjRDb250ZXh0ICpoLCBpbnQg
c2V0dXBfZmluaXNoZWQpCiAgICAgICAgIH0KICAgICB9CiAKKyAgICBpZiAoaC0+c2VpX2dyZWVu
X21ldGFkYXRhX3ByZXNlbnQpIHsKKyAgICAgICAgQVZGcmFtZVNpZGVEYXRhICpHcmVlbm1kID0g
YXZfZnJhbWVfbmV3X3NpZGVfZGF0YShjdXItPmYsIEFWX0ZSQU1FX0RBVEFfR1JFRU5NRCwKKyAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzaXplb2Yo
R3JlZW5NZXRhRGF0YSkpOworICAgICAgICBpZiAoR3JlZW5tZCkgeworICAgICAgICAgICAgbWVt
c2V0KCh1aW50OF90KilHcmVlbm1kLT5kYXRhLCAwLCBzaXplb2YoR3JlZW5NZXRhRGF0YSkpOwor
ICAgICAgICAgICAgR3JlZW5tZC0+ZGF0YVswXSA9IGgtPnNlaV9ncmVlbl9tZXRhZGF0YS5ncmVl
bl9tZXRhZGF0YV90eXBlOworICAgICAgICAgICAgR3JlZW5tZC0+ZGF0YVsxXSA9IGgtPnNlaV9n
cmVlbl9tZXRhZGF0YS5wZXJpb2RfdHlwZTsKKyAgICAgICAgICAgIEdyZWVubWQtPmRhdGFbMl0g
PSAodWludDhfdCkoaC0+c2VpX2dyZWVuX21ldGFkYXRhLm51bV9zZWNvbmRzPj44KTsKKyAgICAg
ICAgICAgIEdyZWVubWQtPmRhdGFbM10gPSAodWludDhfdCkoaC0+c2VpX2dyZWVuX21ldGFkYXRh
Lm51bV9zZWNvbmRzJjB4RkYpOworICAgICAgICAgICAgR3JlZW5tZC0+ZGF0YVs0XSA9ICh1aW50
OF90KShoLT5zZWlfZ3JlZW5fbWV0YWRhdGEubnVtX3BpY3R1cmVzPj44KTsKKyAgICAgICAgICAg
IEdyZWVubWQtPmRhdGFbNV0gPSAodWludDhfdCkoaC0+c2VpX2dyZWVuX21ldGFkYXRhLm51bV9w
aWN0dXJlcyYweEZGKTsKKyAgICAgICAgICAgIEdyZWVubWQtPmRhdGFbNl0gPSBoLT5zZWlfZ3Jl
ZW5fbWV0YWRhdGEucGVyY2VudF9ub25femVyb19tYWNyb2Jsb2NrczsKKyAgICAgICAgICAgIEdy
ZWVubWQtPmRhdGFbN10gPSBoLT5z

[FFmpeg-devel] [PATCH 1/2] swscale/arm/yuv2rgb: fix typo

[Matthieu Bouron]

---
 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_\ifmt\()_to_\ofmt\()_neon_\precision\(), 
export=1
 
 ldr r7, [sp, #124] @ r7
 = linesizeV
 sub r7, r7, r0, lsr #1 @ r7
 = linesizeV - width / 2 (paddingV)
-add r10, r10, r7   @ srcU  
+= paddingV
+add r10, r10, r7   @ srcV  
+= paddingV
 .endif
 
 subsr1, r1, #2 @ 
height -= 2
-- 
2.6.4

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 2/2] swscale/arm/yuv2rgb: add ff_yuv422p_to_{argb, rgba, abgr, bgra}_neon_{16, 32}

[Matthieu Bouron]

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
index 1b50acd..ac1e4a9 100644
--- a/libswscale/arm/swscale_unscaled.c
+++ b/libswscale/arm/swscale_unscaled.c
@@ -69,8 +69,8 @@ static int rgbx_to_nv12_neon_16_wrapper(SwsContext *context, 
const uint8_t *src[
 c->yuv2rgb_v2g_coeff / ((precision) == 16 ? 1 << 7 : 1),   
 \
 c->yuv2rgb_u2b_coeff / ((precision) == 16 ? 1 << 7 : 1),   
 \
 
-#define DECLARE_FF_YUV420P_TO_RGBX_FUNCS(ofmt, precision)  
 \
-int ff_yuv420p_to_##ofmt##_neon_##precision(int w, int h,  
 \
+#define DECLARE_FF_YUVX_TO_RGBX_FUNCS(ifmt, ofmt, precision)   
 \
+int ff_##ifmt##_to_##ofmt##_neon_##precision(int w, int h, 
 \
  uint8_t *dst, int linesize,   
 \
  const uint8_t *srcY, int linesizeY,   
 \
  const uint8_t *srcU, int linesizeU,   
 \
@@ -79,12 +79,12 @@ int ff_yuv420p_to_##ofmt##_neon_##precision(int w, int h,
  int y_offset, 
 \
  int y_coeff); 
 \

 \
-static int yuv420p_to_##ofmt##_neon_wrapper_##precision(SwsContext *c, const 
uint8_t *src[],\
+static int ifmt##_to_##ofmt##_neon_wrapper_##precision(SwsContext *c, const 
uint8_t *src[], \
int srcStride[], int srcSliceY, int 
srcSliceH,   \
uint8_t *dst[], int dstStride[]) {  
 \
 const int16_t yuv2rgb_table[] = { YUV_TO_RGB_TABLE(precision) };   
 \

 \
-ff_yuv420p_to_##ofmt##_neon_##precision(c->srcW, srcSliceH,
 \
+ff_##ifmt##_to_##ofmt##_neon_##precision(c->srcW, srcSliceH,   
 \
  dst[0] + srcSliceY * dstStride[0], 
dstStride[0],   \
  src[0], srcStride[0], 
 \
  src[1], srcStride[1], 
 \
@@ -96,16 +96,17 @@ static int 
yuv420p_to_##ofmt##_neon_wrapper_##precision(SwsContext *c, const uin
 return 0;  
 \
 }  
 \
 
-#define DECLARE_FF_YUV420P_TO_ALL_RGBX_FUNCS(precision)
 \
-DECLARE_FF_YUV420P_TO_RGBX_FUNCS(argb, precision)  
 \
-DECLARE_FF_YUV420P_TO_RGBX_FUNCS(rgba, precision)  
 \
-DECLARE_FF_YUV420P_TO_RGBX_FUNCS(abgr, precision)  
 \
-DECLARE_FF_YUV420P_TO_RGBX_FUNCS(bgra, precision)  
 \
+#define DECLARE_FF_YUVX_TO_ALL_RGBX_FUNCS(yuvx, precision) 
 \
+DECLARE_FF_YUVX_TO_RGBX_FUNCS(yuvx, argb, precision)   
 \
+DECLARE_FF_YUVX_TO_RGBX_FUNCS(yuvx, rgba, precision)   
 \
+DECLARE_FF_YUVX_TO_RGBX_FUNCS(yuvx, abgr, precision)   
 \
+DECLARE_FF_YUVX_TO_RGBX_FUNCS(yuvx, bgra, precision)   
 \
 
-#define DECLARE_FF_YUV420P_TO_ALL_RGBX_ALL_PRECISION_FUNCS 
 \
-DECLARE_FF_YUV420P_TO_ALL_RGBX_FUNCS(16)   
 \
+#define DECLARE_FF_YUVX_TO_ALL_RGBX_ALL_PRECISION_FUNCS(yuvx)  
 \
+DECLARE_FF_YUVX_TO_ALL_RGBX_FUNCS(yuvx, 16)
 \
 
-DECLARE_FF_YUV420P_TO_ALL_RGBX_ALL_PRECISION_FUNCS
+DECLARE_FF_YUVX_TO_ALL_RGBX_ALL_PRECISION_FUNCS(yuv420p)
+DECLARE_FF_YUVX_TO_ALL_RGBX_ALL_PRECISION_FUNCS(yuv422p)
 
 #define DECLARE_FF_NVX_TO_RGBX_FUNCS(ifmt, ofmt, precision)
 \
 int ff_##ifmt##_to_##ofmt##_neon_##precision(int w, int h, 
 \
@@ -178,6 +179,7 @@ static void get_unscaled_swscale_neon(SwsContext *c) {
 SET_FF_NVX_TO_ALL_RGBX_FUNC(nv12, NV12, accurate_rnd);
 SET_FF_NVX_TO_ALL_RGBX_FUNC(nv21, NV21, accurate_rnd);
  

[FFmpeg-devel] [PATCH] Add frame side data when SEI green metadata are detected

[Nicolas DEROUINEAU]

---
 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/libavcodec/h264.c
@@ -879,6 +879,27 @@ static void decode_postinit(H264Context *h, int 
setup_finished)
 }
 }
 
+if (h->sei_green_metadata_present) {
+AVFrameSideData *Greenmd = av_frame_new_side_data(cur->f, 
AV_FRAME_DATA_GREENMD,
+sizeof(GreenMetaData));
+if (Greenmd) {
+memset((uint8_t*)Greenmd->data, 0, sizeof(GreenMetaData));
+Greenmd->data[0] = h->sei_green_metadata.green_metadata_type;
+Greenmd->data[1] = h->sei_green_metadata.period_type;
+Greenmd->data[2] = (uint8_t)(h->sei_green_metadata.num_seconds>>8);
+Greenmd->data[3] = 
(uint8_t)(h->sei_green_metadata.num_seconds&0xFF);
+Greenmd->data[4] = 
(uint8_t)(h->sei_green_metadata.num_pictures>>8);
+Greenmd->data[5] = 
(uint8_t)(h->sei_green_metadata.num_pictures&0xFF);
+Greenmd->data[6] = 
h->sei_green_metadata.percent_non_zero_macroblocks;
+Greenmd->data[7] = 
h->sei_green_metadata.percent_intra_coded_macroblocks;
+Greenmd->data[8] = h->sei_green_metadata.percent_six_tap_filtering;
+Greenmd->data[9] = 
h->sei_green_metadata.percent_alpha_point_deblocking_instance;
+Greenmd->data[10] = h->sei_green_metadata.xsd_metric_type;
+Greenmd->data[11] = 
(uint8_t)(h->sei_green_metadata.xsd_metric_value>>8);
+Greenmd->data[12] = 
(uint8_t)(h->sei_green_metadata.xsd_metric_value&0xFF);
+}
+}
+
 if (h->sei_reguserdata_afd_present) {
 AVFrameSideData *sd = av_frame_new_side_data(cur->f, AV_FRAME_DATA_AFD,
  sizeof(uint8_t));
diff --git a/libavcodec/h264.h b/libavcodec/h264.h
index 5d9aecd..51490d6 100644
--- a/libavcodec/h264.h
+++ b/libavcodec/h264.h
@@ -839,6 +839,7 @@ typedef struct H264Context {
 qpel_mc_func (*qpel_avg)[16];
 
 /*Green Metadata */
+int sei_green_metadata_present;
 GreenMetaData sei_green_metadata;
 
 } H264Context;
diff --git a/libavcodec/h264_sei.c b/libavcodec/h264_sei.c
index 0411b87..4a021b8 100644
--- a/libavcodec/h264_sei.c
+++ b/libavcodec/h264_sei.c
@@ -43,6 +43,7 @@ void ff_h264_reset_sei(H264Context *h)
 h->sei_frame_packing_present=  0;
 h->sei_display_orientation_present = 0;
 h->sei_reguserdata_afd_present  =  0;
+h->sei_green_metadata_present   =  0;
 
 h->a53_caption_size = 0;
 av_freep(&h->a53_caption);
@@ -363,6 +364,8 @@ static int decode_GreenMetadata(H264Context *h)
 if (h->avctx->debug & FF_DEBUG_GREEN_MD)
 av_log(h->avctx, AV_LOG_DEBUG,  "Green Metadata Info SEI 
message\n");
 
+h->sei_green_metadata_present = 1;
+
 h->sei_green_metadata.green_metadata_type=get_bits(&h->gb, 8);
 
 if (h->avctx->debug & FF_DEBUG_GREEN_MD)
diff --git a/libavutil/frame.h b/libavutil/frame.h
index 9c6061a..89a57ad 100644
--- a/libavutil/frame.h
+++ b/libavutil/frame.h
@@ -112,6 +112,14 @@ enum AVFrameSideDataType {
  * enum AVAudioServiceType defined in avcodec.h.
  */
 AV_FRAME_DATA_AUDIO_SERVICE_TYPE,
+
+
+/**
+ * This side data must be associated with a video frame and corresponds to
+ * struct GreenMDataType defined in avcodec.h. The green metadata 
specification
+ * is given in ISO/IEC 23001.
+ */
+AV_FRAME_DATA_GREENMD,
 };
 
 enum AVActiveFormatDescription {
-- 
1.9.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] swscale/arm/yuv2rgb: fix typo

[Michael Niedermayer]

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 responsible. -- Voltaire


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] lavc/pcm_tablegen: slight speedup of table generation

[Andreas Cadhalpun]

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.
> 
> Clarifications: by algorithmic improvements, I do not usually count
> asm code, but make exceptions in some cases. In particular, I have
> minimal knowledge of assembly and minimal motivation in learning it.
> However, I may examine at some point cases where I am convinced that a
> compiler can't do the needful.
> By theoretical aspects of security, I refer to defensive programming,
> some forms of undefined behavior (e.g rint64_clip, many ubsan
> failures), and other such things such as those flagged by Coverity. By
> practical aspects of security, I refer to things like fuzzing crashes,
> other ubsan failures, and other things flagged by Coverity or found by
> audit.

If you're interested in fixing some forms of undefined behavior (which?)
I can send you a couple of samples triggering them.
I have far too many of these to be able to fix them any time soon.

Best regards,
Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] Enable dash output to work when the output isn't a local file

[rhi]

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 +549,7 @@ static int write_manifest(AVFormatContext *s, int final)
 avio_printf(out, "\n");
 avio_flush(out);
 avio_close(out);
-return ff_rename(temp_filename, s->filename, s);
+return avpriv_io_move(temp_filename, s->filename);
 }
 
 static int dash_write_header(AVFormatContext *s)
@@ -856,7 +856,7 @@ static int dash_flush(AVFormatContext *s, int final, int 
stream)
 } else {
 ffurl_close(os->out);
 os->out = NULL;
-ret = ff_rename(temp_path, full_path, s);
+ret = avpriv_io_move(temp_path, full_path);
 if (ret < 0)
 break;
 }
-- 
2.4.3

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] alsdec: error out if channel number changes

[Andreas Cadhalpun]

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
--- a/libavcodec/alsdec.c
+++ b/libavcodec/alsdec.c
@@ -193,6 +193,7 @@ typedef struct ALSDecContext {
 ALSSpecificConfig sconf;
 GetBitContext gb;
 BswapDSPContext bdsp;
+int channels;
 const AVCRC *crc_table;
 uint32_t crc_org;   ///< CRC value of the original input data
 uint32_t crc;   ///< CRC value calculated from decoded data
@@ -1515,6 +1516,13 @@ static int decode_frame(AVCodecContext *avctx, void 
*data, int *got_frame_ptr,
 int invalid_frame, ret;
 unsigned int c, sample, ra_frame, bytes_read, shift;
 
+if (avctx->channels != ctx->channels) {
+av_log(avctx, AV_LOG_ERROR,
+   "Changing the number of channels from %d to %d requires 
re-initialization.\n",
+   ctx->channels, avctx->channels);
+return AVERROR_PATCHWELCOME;
+}
+
 if ((ret = init_get_bits8(&ctx->gb, buffer, buffer_size)) < 0)
 return ret;
 
@@ -1793,6 +1801,7 @@ static av_cold int decode_init(AVCodecContext *avctx)
 
 channel_size  = sconf->frame_length + sconf->max_order;
 
+ctx->channels = avctx->channels;
 ctx->prev_raw_samples = av_malloc_array(sconf->max_order, 
sizeof(*ctx->prev_raw_samples));
 ctx->raw_buffer   = av_mallocz_array(avctx->channels * channel_size, 
sizeof(*ctx->raw_buffer));
 ctx->raw_samples  = av_malloc_array(avctx->channels, 
sizeof(*ctx->raw_samples));
-- 
2.6.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] alsdec: error out if channel number changes

[Thilo Borgmann]

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.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [libav-devel] [PATCH] Cineform HD Decoder:

[Vittorio Giovara]

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;
> +
> +ff_cfhd_init_vlcs(s);
> +
> +avctx->pix_fmt = AV_PIX_FMT_YUV422P10;
> +avctx->bits_per_raw_sample = 16;
> +s->avctx   = avctx;
> +
> +return 0;

here could be return ff_cfhd_init_vlcs(s); (see below)

> +static av_cold int cfhd_close_decoder(AVCodecContext *avctx)
> +{
> +CFHDContext *s = avctx->priv_data;
> +
> +ff_free_vlc(&s->vlc_9);
> +ff_free_vlc(&s->vlc_18);
> +
> +return 0;
> +}

> +AVCodec ff_cfhd_decoder = {
> +.name   = "cfhdvideo",
> +.long_name  = NULL_IF_CONFIG_SMALL("cfhd video"),
> +.type   = AVMEDIA_TYPE_VIDEO,
> +.id = AV_CODEC_ID_CFHD,
> +.priv_data_size = sizeof(CFHDContext),
> +.init   = cfhd_init_decoder,
> +.close  = cfhd_close_decoder,
> +.decode = cfhd_decode,
> +.capabilities   = AV_CODEC_CAP_EXPERIMENTAL,

also DR1 I believe

> +};

> +av_cold int ff_cfhd_init_vlcs(CFHDContext *s)
> +{
> +init_vlc(&s->vlc_9, VLC_BITS, j, new_cfhd_vlc_len,
> + 1, 1, new_cfhd_vlc_bits, 4, 4, 0);

> +init_vlc(&s->vlc_18, VLC_BITS, j, new_cfhd_vlc_len,
> + 1, 1, new_cfhd_vlc_bits, 4, 4, 0);
> +assert(s->vlc_18.table_size == 4572);

my only suggestion here is that since this isn't using static vars you
should add FF_CODEC_CAP_INIT_THREADSAFE to the internal capabilities,
and since allocating memory you should check the init_vlc return
value, return it and add the proper FF_CODEC_CAP_INIT_CLEANUP to do
the cleanup work for you

if you feel like it you could use avpriv_report_missing_feature
instead of av_log where you return AVERROR_PATCHWELCOME
-- 
Vittorio
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] swscale/arm/yuv2rgb: add ff_yuv422p_to_{argb, rgba, abgr, bgra}_neon_{16, 32}

[Michael Niedermayer]

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(-)

tested with fate on qemu arm, no failures

thx

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

When you are offended at any man's fault, turn to yourself and study your
own failings. Then you will forget your anger. -- Epictetus


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] lavc/pcm_tablegen: slight speedup of table generation

[Ganesh Ajjanagadde]

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), but with nowhere near the
>> same level of knowledge.
>>
>> Clarifications: by algorithmic improvements, I do not usually count
>> asm code, but make exceptions in some cases. In particular, I have
>> minimal knowledge of assembly and minimal motivation in learning it.
>> However, I may examine at some point cases where I am convinced that a
>> compiler can't do the needful.
>> By theoretical aspects of security, I refer to defensive programming,
>> some forms of undefined behavior (e.g rint64_clip, many ubsan
>> failures), and other such things such as those flagged by Coverity. By
>> practical aspects of security, I refer to things like fuzzing crashes,
>> other ubsan failures, and other things flagged by Coverity or found by
>> audit.
>
> If you're interested in fixing some forms of undefined behavior (which?)
> I can send you a couple of samples triggering them.

Please do so.

> I have far too many of these to be able to fix them any time soon.
>
> Best regards,
> Andreas
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Enable dash output to work when the output isn't a local file

[Hendrik Leppkes]

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/libavformat/dashenc.c
> +++ b/libavformat/dashenc.c
> @@ -549,7 +549,7 @@ static int write_manifest(AVFormatContext *s, int final)
>  avio_printf(out, "\n");
>  avio_flush(out);
>  avio_close(out);
> -return ff_rename(temp_filename, s->filename, s);
> +return avpriv_io_move(temp_filename, s->filename);
>  }
>
>  static int dash_write_header(AVFormatContext *s)
> @@ -856,7 +856,7 @@ static int dash_flush(AVFormatContext *s, int final, int 
> stream)
>  } else {
>  ffurl_close(os->out);
>  os->out = NULL;
> -ret = ff_rename(temp_path, full_path, s);
> +ret = avpriv_io_move(temp_path, full_path);
>  if (ret < 0)
>  break;
>  }
> --

For unknown reasons, url_move(which avpriv_io_move uses) in the "file"
protocol depends on unistd.h, which is not available everywhere.
So commiting this without making sure file.url_move is available on
all systems where ff_rename works would introduce a regression.

- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] lavc/pcm_tablegen: slight speedup of table generation

[Ganesh Ajjanagadde]

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 told me what is interesting
>> >>
>> >> Did you look at tickets #4441 or #4085?
>> >
>> > Or ticket #4829 or a j2k issue?
>>
>> Thanks a lot for taking the time to point these out. They have all
>> been noted. Unfortunately, I have too many things on my list now. 4829
>> may be what I tackle first; it may take a while though.
>>
>> I hope the following is helpful.
>> Generally, my strengths are in algorithmic/mathematical/numerical
>> improvements.
>
> but not interested in merging pre-filter and RLB-filter in EBU R128 like I
> pointed out? :(

That was a long time back, completely forgotten and never noted down
explicitly. Thanks for reminding me :).

>
> More seriously, maybe try to write a filter? I'm thinking of the Eulerian
> magnification filter¹², which I unfortunately haven't time to work on.

I recall seeing this at MIT a year back, noted. Thanks.

>
> You may also enjoy studying motion interpolation for many applications.
>
> Anyway, the point is, you have a very large range of possibilities to
> enjoy yourself on the project wrt image processing.
>
> [1]: http://people.csail.mit.edu/mrub/vidmag/
> [2]: https://www.youtube.com/watch?v=ONZcjs1Pjmk
>
>> I have a strong interest in security (both its
>> "practical" and "theoretical" variants), but with nowhere near the
>> same level of knowledge.
>>
>> Clarifications: by algorithmic improvements, I do not usually count
>> asm code, but make exceptions in some cases. In particular, I have
>> minimal knowledge of assembly and minimal motivation in learning it.
>> However, I may examine at some point cases where I am convinced that a
>> compiler can't do the needful.
>> By theoretical aspects of security, I refer to defensive programming,
>> some forms of undefined behavior (e.g rint64_clip, many ubsan
>> failures), and other such things such as those flagged by Coverity. By
>> practical aspects of security, I refer to things like fuzzing crashes,
>> other ubsan failures, and other things flagged by Coverity or found by
>> audit.
>
> Well, I have a challenging suggestion then... How about looking at
> threading? Look for Helgrind (or DRD) on http://fate.ffmpeg.org. I know
> many of the report are false positive... but are they? Do we have real
> issues spotted here? You might want to study why we have so much of them,
> if ints read/write really are actually atomic on all platforms, ... that
> sort of stuff :)

Ah, threading - this was always a pain, and I deliberately did not
study it as well as I should have during my undergrad years. This will
unfortunately go very down in my list, as I need to study it and find
the necessary time.

@all: thanks very much for suggestions.

>
> --
> Clément B.
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Cineform HD Decoder:

[Michael Niedermayer]

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 +
>  libavcodec/cfhd.c   | 567 
> 
>  libavcodec/cfhd.h   |  97 +
>  libavcodec/cfhddata.c   | 466 +++
>  libavcodec/codec_desc.c |   6 +

>  libavformat/riff.c  |   1 +

ideally the avformat change should be a seperate commit


>  8 files changed, 1140 insertions(+)
>  create mode 100644 libavcodec/cfhd.c
>  create mode 100644 libavcodec/cfhd.h
>  create mode 100644 libavcodec/cfhddata.c
> 
> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> index a18ca5b..9db88d7 100644
> --- a/libavcodec/Makefile
> +++ b/libavcodec/Makefile
> @@ -212,6 +212,7 @@ OBJS-$(CONFIG_CDGRAPHICS_DECODER)  += cdgraphics.o
>  OBJS-$(CONFIG_CDXL_DECODER)+= cdxl.o
>  OBJS-$(CONFIG_CINEPAK_DECODER) += cinepak.o
>  OBJS-$(CONFIG_CINEPAK_ENCODER) += cinepakenc.o elbg.o
> +OBJS-$(CONFIG_CFHD_DECODER)+= cfhd.o cfhddata.o
>  OBJS-$(CONFIG_CLJR_DECODER)+= cljrdec.o
>  OBJS-$(CONFIG_CLJR_ENCODER)+= cljrenc.o
>  OBJS-$(CONFIG_CLLC_DECODER)+= cllc.o canopus.o
> diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
> index 4eeb6f3..ca6e4c2 100644
> --- a/libavcodec/allcodecs.c
> +++ b/libavcodec/allcodecs.c
> @@ -147,6 +147,7 @@ void avcodec_register_all(void)
>  REGISTER_DECODER(CAVS,  cavs);
>  REGISTER_DECODER(CDGRAPHICS,cdgraphics);
>  REGISTER_DECODER(CDXL,  cdxl);
> +REGISTER_DECODER(CFHD,  cfhd);
>  REGISTER_ENCDEC (CINEPAK,   cinepak);
>  REGISTER_ENCDEC (CLJR,  cljr);
>  REGISTER_DECODER(CLLC,  cllc);
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index f365775..b958a6c 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -315,6 +315,7 @@ enum AVCodecID {
>  AV_CODEC_ID_SMVJPEG,
>  AV_CODEC_ID_APNG,
>  AV_CODEC_ID_DAALA,
> +AV_CODEC_ID_CFHD,
>  
>  /* various PCM "codecs" */
>  AV_CODEC_ID_FIRST_AUDIO = 0x1, ///< A dummy id pointing at the 
> start of audio codecs
> diff --git a/libavcodec/cfhd.c b/libavcodec/cfhd.c
> new file mode 100644
> index 000..0f1bcd3
> --- /dev/null
> +++ b/libavcodec/cfhd.c
> @@ -0,0 +1,567 @@
> +/*
> + * Copyright (c) 2015 Kieran Kunhya
> + *
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 
> USA
> + */
> +
> +/**
> + * @file
> + * CFHD Video Decoder
> + */
> +
> +#include "avcodec.h"
> +#include "bswapdsp.h"
> +#include "internal.h"
> +#include "cfhd.h"
> +#include "libavutil/avassert.h"
> +#include "libavutil/buffer.h"
> +#include "libavutil/common.h"
> +#include "libavutil/intreadwrite.h"
> +#include "libavutil/imgutils.h"
> +#include "libavutil/opt.h"
> +
> +static av_cold int cfhd_init_decoder(AVCodecContext *avctx)
> +{
> +CFHDContext *s = avctx->priv_data;
> +
> +ff_cfhd_init_vlcs(s);
> +
> +avctx->pix_fmt = AV_PIX_FMT_YUV422P10;
> +avctx->bits_per_raw_sample = 16;
> +s->avctx   = avctx;
> +
> +return 0;
> +}
> +
> +static void init_plane_defaults(CFHDContext *s)
> +{
> +s->subband_num= 0;
> +s->level  = 0;
> +s->subband_num_actual = 0;
> +}
> +
> +static void init_frame_defaults(CFHDContext *s)
> +{
> +s->bpc   = 10;
> +s->channel_cnt   = 4;
> +s->subband_cnt   = 10;
> +s->channel_num   = 0;
> +s->lowpass_precision = 16;
> +s->quantisation  = 1;
> +s->wavelet_depth = 3;
> +s->pshift= 1;
> +s->codebook  = 0;
> +init_plane_defaults(s);
> +}
> +
> +static inline int dequant_and_decompand(int level, int quantisation)
> +{
> +int abslevel = abs(level);
> +return (abslevel + ((768 * abslevel * abslevel * abslevel) / (255 * 255 
> * 255))) * FFSIGN(level) * quantisation;
> +}
> +
> +static inline void filter(int16_t *output, int out_stride, int

Re: [FFmpeg-devel] [PATCH] Enable dash output to work when the output isn't a local file

[Ganesh Ajjanagadde]

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/libavformat/dashenc.c
>> index 4509ee4..378c4e4 100644
>> --- a/libavformat/dashenc.c
>> +++ b/libavformat/dashenc.c
>> @@ -549,7 +549,7 @@ static int write_manifest(AVFormatContext *s, int final)
>>  avio_printf(out, "\n");
>>  avio_flush(out);
>>  avio_close(out);
>> -return ff_rename(temp_filename, s->filename, s);
>> +return avpriv_io_move(temp_filename, s->filename);
>>  }
>>
>>  static int dash_write_header(AVFormatContext *s)
>> @@ -856,7 +856,7 @@ static int dash_flush(AVFormatContext *s, int final, int 
>> stream)
>>  } else {
>>  ffurl_close(os->out);
>>  os->out = NULL;
>> -ret = ff_rename(temp_path, full_path, s);
>> +ret = avpriv_io_move(temp_path, full_path);
>>  if (ret < 0)
>>  break;
>>  }
>> --
>
> For unknown reasons, url_move(which avpriv_io_move uses) in the "file"
> protocol depends on unistd.h, which is not available everywhere.

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:
http://en.cppreference.com/w/c/io/rename.
As the code is recent, dating to this year's gsoc, 824a82d1b8, it may
not be too surprising that this was not addressed yet.

> So commiting this without making sure file.url_move is available on
> all systems where ff_rename works would introduce a regression.
>
> - Hendrik
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Enable dash output to work when the output isn't a local file

[Derek Buitenhuis]

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:
> http://en.cppreference.com/w/c/io/rename.
> As the code is recent, dating to this year's gsoc, 824a82d1b8, it may
> not be too surprising that this was not addressed yet.

I know rename is not atomic on Windows, if that matters.

- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavf/decimate: Fix total difference for the first frame

[Carl Eugen Hoyos]

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 nobody objects.

Carl Eugen

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Adding frame side data about green metadata

[wm4]

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?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] alsdec: error out if channel number changes

[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?

- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavf/decimate: Fix total difference for the first frame

[Derek Buitenhuis]

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] <@ubitux> i need to look more closely, it's been a long time
[17:31] <@ubitux> i need to "sync" it with upstream since a long time
[17:31] <@ubitux> i'll check tonight (in ~3h probably)

- Derek

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] swscale/arm/yuv2rgb: fix typo

[Matthieu Bouron]

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.

[...]
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] swscale/arm/yuv2rgb: add ff_yuv422p_to_{argb, rgba, abgr, bgra}_neon_{16, 32}

[Matthieu Bouron]

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 
> > ---
> >  2 files changed, 101 insertions(+), 18 deletions(-)
> 
> tested with fate on qemu arm, no failures

Pushed, thanks.

[...]
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Enable dash output to work when the output isn't a local file

[Ganesh Ajjanagadde]

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 details specified in
>> POSIX, but rename itself is standard C:
>> http://en.cppreference.com/w/c/io/rename.
>> As the code is recent, dating to this year's gsoc, 824a82d1b8, it may
>> not be too surprising that this was not addressed yet.
>
> I know rename is not atomic on Windows, if that matters.

Nothing in the docs for url_move requires that the callback be atomic,
though it is indeed a very useful property here.

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
https://stackoverflow.com/questions/167414/is-an-atomic-file-rename-with-overwrite-possible-on-windows#,
where there seems to be a lack of clarity, and perhaps make a better
effort at an atomic rename operation for Windows.

>
> - Derek
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] alsdec: error out if channel number changes

[Andreas Cadhalpun]

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 trigger this problem when
using ffmpeg, it only happens with the simple program I use for fuzz testing.

I tracked down the difference:
My simple program tries to test a specific codec given on the command line
(like the '-c' option of ffmpeg). So it iterates over all streams and
uses the stream with a matching codec. However, if none is found it forces
the codec given on the command line for the first stream.

The difference to ffmpeg is that the latter calls avformat_find_stream_info
after forcing the codec, while my simple program did that beforehand.

Apparently the API isn't compatible with that as it now used the ac3 parser
together with the als decoder, which didn't work out well...

I find this a bit strange since avformat_find_stream_info could even find
new streams, whose codecs can't be changed, it seems.
Better documentation of this would be good.

On 04.01.2016 18:31, Derek Buitenhuis wrote:
> 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?

Probably, but that wouldn't have mattered for preventing out-of-bounds reads.

Anyway, consider this patch dropped.

Best regards,
Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/concatdec: get bit_rate from internal format

[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 prefetch buffer size.
> 3. Show prefetched duration in progress bar.
> 
> I thought AVFormatContext.bit_rate is a convenient alias.
> Is AVCodecContext.bit_rate more suitable for these purpose?

I see. At first glance it makes sense, but I do not think you are on the
right track, for two reasons.

First, you will have trouble using custom I/O with the concat demuxer, it is
not really meant for programmatic use. All it does is read packets from the
underlying demuxers and adjust timestamps: in an application, you can easily
do the same directly with more control. Then you have access to the
properties of each file, including bit_rate.

Second, the bit_rate is only an average. With VFR content, you would end up
buffering way more than necessary for still scenes (not really a problem if
memory is cheap), and then under-run very fast as soon as there is water or
foliage visible.

To handle VFR content, you need to adjust dynamically. IMHO, the best way of
doing that is to buffer packets after the demuxer, not octets before it.
Demuxing is fast, and the memory use is roughly the same, mostly the
payload, so it does not change anything. But if you buffer after the
demuxer, you have access to the timestamps of the packets: you can decide
you want to buffer 20 seconds of movie, you just have to demux until the
timestamp is right, you do not need to estimate how many octets it makes.

Hope this helps.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavf/decimate: Fix total difference for the first frame

[Carl Eugen Hoyos]

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 list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Add frame side data when SEI green metadata are detected

[Michael Niedermayer]

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 have
its minor version bumped


>  4 files changed, 33 insertions(+)
> 
> diff --git a/libavcodec/h264.c b/libavcodec/h264.c
> index 089a86f..e90bcc0 100644
> --- a/libavcodec/h264.c
> +++ b/libavcodec/h264.c
> @@ -879,6 +879,27 @@ static void decode_postinit(H264Context *h, int 
> setup_finished)
>  }
>  }
>  
> +if (h->sei_green_metadata_present) {
> +AVFrameSideData *Greenmd = av_frame_new_side_data(cur->f, 
> AV_FRAME_DATA_GREENMD,
> +sizeof(GreenMetaData));
> +if (Greenmd) {
> +memset((uint8_t*)Greenmd->data, 0, sizeof(GreenMetaData));
> +Greenmd->data[0] = h->sei_green_metadata.green_metadata_type;
> +Greenmd->data[1] = h->sei_green_metadata.period_type;
> +Greenmd->data[2] = 
> (uint8_t)(h->sei_green_metadata.num_seconds>>8);
> +Greenmd->data[3] = 
> (uint8_t)(h->sei_green_metadata.num_seconds&0xFF);
> +Greenmd->data[4] = 
> (uint8_t)(h->sei_green_metadata.num_pictures>>8);
> +Greenmd->data[5] = 
> (uint8_t)(h->sei_green_metadata.num_pictures&0xFF);
> +Greenmd->data[6] = 
> h->sei_green_metadata.percent_non_zero_macroblocks;
> +Greenmd->data[7] = 
> h->sei_green_metadata.percent_intra_coded_macroblocks;
> +Greenmd->data[8] = 
> h->sei_green_metadata.percent_six_tap_filtering;
> +Greenmd->data[9] = 
> h->sei_green_metadata.percent_alpha_point_deblocking_instance;
> +Greenmd->data[10] = h->sei_green_metadata.xsd_metric_type;
> +Greenmd->data[11] = 
> (uint8_t)(h->sei_green_metadata.xsd_metric_value>>8);
> +Greenmd->data[12] = 
> (uint8_t)(h->sei_green_metadata.xsd_metric_value&0xFF);
> +}
> +}
> +
>  if (h->sei_reguserdata_afd_present) {
>  AVFrameSideData *sd = av_frame_new_side_data(cur->f, 
> AV_FRAME_DATA_AFD,
>   sizeof(uint8_t));
> diff --git a/libavcodec/h264.h b/libavcodec/h264.h
> index 5d9aecd..51490d6 100644
> --- a/libavcodec/h264.h
> +++ b/libavcodec/h264.h
> @@ -839,6 +839,7 @@ typedef struct H264Context {
>  qpel_mc_func (*qpel_avg)[16];
>  
>  /*Green Metadata */
> +int sei_green_metadata_present;
>  GreenMetaData sei_green_metadata;
>  
>  } H264Context;
> diff --git a/libavcodec/h264_sei.c b/libavcodec/h264_sei.c
> index 0411b87..4a021b8 100644
> --- a/libavcodec/h264_sei.c
> +++ b/libavcodec/h264_sei.c
> @@ -43,6 +43,7 @@ void ff_h264_reset_sei(H264Context *h)
>  h->sei_frame_packing_present=  0;
>  h->sei_display_orientation_present = 0;
>  h->sei_reguserdata_afd_present  =  0;
> +h->sei_green_metadata_present   =  0;
>  
>  h->a53_caption_size = 0;
>  av_freep(&h->a53_caption);
> @@ -363,6 +364,8 @@ static int decode_GreenMetadata(H264Context *h)
>  if (h->avctx->debug & FF_DEBUG_GREEN_MD)
>  av_log(h->avctx, AV_LOG_DEBUG,  "Green Metadata Info SEI 
> message\n");
>  
> +h->sei_green_metadata_present = 1;
> +
>  h->sei_green_metadata.green_metadata_type=get_bits(&h->gb, 8);
>  
>  if (h->avctx->debug & FF_DEBUG_GREEN_MD)


> diff --git a/libavutil/frame.h b/libavutil/frame.h
> index 9c6061a..89a57ad 100644
> --- a/libavutil/frame.h
> +++ b/libavutil/frame.h
> @@ -112,6 +112,14 @@ enum AVFrameSideDataType {
>   * enum AVAudioServiceType defined in avcodec.h.
>   */
>  AV_FRAME_DATA_AUDIO_SERVICE_TYPE,
> +
> +
> +/**
> + * This side data must be associated with a video frame and corresponds 
> to
> + * struct GreenMDataType defined in avcodec.h. The green metadata 
> specification
> + * is given in ISO/IEC 23001.

GreenMDataType does not exist
GreenMetaData is defined in h264.h, which is an internal header
while AVFrameSideDataType is external. public API should not refer to
internal/private headers
also the struct, as currently defined is platform specific. Theres no
gurantee that a compiler doesnt add padding betwen the elements. Also
the code initializing it only matches the platform dependant struct
on little endian


[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I am the wisest man alive, for I know one thing, and that is that I know
nothing. -- Socrates


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libvpx: Support setting color range for vp9.

[Sasi Inguva]

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_VERSION was not changed when the color_range enum was
> > introduced so I am afraid I would have to drop libvpxdec changes.
>
>
> It should work in 1.5.0, no? So can't you do a version check?
>
> Ronald
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libvpx: Support setting color range for vp9.

[Ronald S. Bultje]

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 field in this struct in our configure script.

Ronald
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Enable dash output to work when the output isn't a local file

[Derek Buitenhuis]

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
> https://stackoverflow.com/questions/167414/is-an-atomic-file-rename-with-overwrite-possible-on-windows#,
> where there seems to be a lack of clarity, and perhaps make a better
> effort at an atomic rename operation for Windows.

Windows API can lock files from read/write by other procs, which may "emulated"
it... kinda. Probably a bad idea.

- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Enable dash output to work when the output isn't a local file

[Hendrik Leppkes]

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 expertise can then examine the validity of
https://stackoverflow.com/questions/167414/is-an-atomic-file-rename-with-overwrite-possible-on-windows#,
where there seems to be a lack of clarity, and perhaps make a better
effort at an atomic rename operation for Windows.


Windows API can lock files from read/write by other procs, which may "emulated"
it... kinda. Probably a bad idea.



We don't really need to discuss this now though, the overall point is 
that it uses rename now through ff_rename, and the new call should also 
use rename on all the same systems.


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?



--
Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libvpx: Support setting color range for vp9.

[Sasi Inguva]

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 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 field in this struct in our configure script.
>
> Ronald
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavf/decimate: Fix total difference for the first frame

[Clément Bœsch]

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> yup?
> [17:30] <@Daemon404> do you have a comment on carl's decimate change
> [17:31] <@ubitux> i need to look more closely, it's been a long time
> [17:31] <@ubitux> i need to "sync" it with upstream since a long time
> [17:31] <@ubitux> i'll check tonight (in ~3h probably)
> 

commit e004c18ced0cd1c9b0d3680835b8ec474c539217
Author: cantabile 
Date:   Mon May 19 00:03:17 2014 +0300

VDecimate: Fix decimation of the first cycle

The first frame's metrics are always zero, thus the first frame is
always considered a duplicate, which means it's always dropped. Avoid
this by copying the second frame's maximum block difference.

Also make the first frame's total difference just a bit higher than the
scene change threshold, so it's always considered a scene change. This
way the first frame will be dropped when there are no duplicates and no
other scene changes in the cycle.

diff --git a/src/filters/vivtc/vivtc.c b/src/filters/vivtc/vivtc.c
index b0eba1d..abfa900 100644
--- a/src/filters/vivtc/vivtc.c
+++ b/src/filters/vivtc/vivtc.c
@@ -1252,6 +1252,12 @@ static const VSFrameRef *VS_CC vdecimateGetFrame(int n, 
int activationReason, vo
 vsapi->freeFrame(cur);
 }
 
+// The first frame's metrics are always 0, thus it's always 
considered a duplicate.
+if (cyclestart == 0) {
+vdm->vmi[0].maxbdiff = vdm->vmi[1].maxbdiff;
+vdm->vmi[0].totdiff = vdm->scthresh + 1;
+}
+
 if (*drop < 0)
 *drop = findDropFrame(&vdm->vmi[cyclestart], cycleend - 
cyclestart, vdm->scthresh, vdm->dupthresh);
 }

I suggest to "cherry-pick" this if it works.

Regards,

-- 
Clément B.


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] alsdec: error out if channel number changes

[Thilo Borgmann]

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 number of channels is invalid for ALS
so there is no sense in implementing it.

However, we should should add a fix for out-of-bound reads. An updated
patch giving a proper error would do, I think.

-Thilo


___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libvpx: Support setting color range for vp9.

[Ronald S. Bultje]

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
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Enable dash output to work when the output isn't a local file

[Derek Buitenhuis]

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
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] alsdec: error out if channel number changes

[Andreas Cadhalpun]

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, properly?
> 
> I'm quite sure that changing the number of channels is invalid for ALS
> so there is no sense in implementing it.

OK.

> However, we should should add a fix for out-of-bound reads. An updated
> patch giving a proper error would do, I think.

I'm not sure that would have much use as this only happens if the API
isn't used as intended (ac3 parser with als decoder).

It might be better to check that parsers are used with matching decoders,
if such a check can be implemented.

Best regards,
Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libvpx: Support setting color range for vp9.

[James Almer]

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, but i guess it's better than bloating configure
with checks for specific struct members.

> 
> 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 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 field in this struct in our configure script.
> 
> Ronald
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org 
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> 

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] alsdec: error out if channel number changes

[Derek Buitenhuis]

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/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavf/decimate: Fix total difference for the first frame

[Carl Eugen Hoyos]

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 differs in rare cases (although the change 
should be ported) and not for the file in question.
Sorry to say this but I wonder how the filter ever 
passed any test without this (or a similar) change.

The OP of ticket #4990 claims that for his sample 
the first frames are correctly handled with avisynth.
(I have no idea how to test this.)

When looking at the frames visually, I can very, very 
easily distinguish between the four duplicates of the 
20 frames and the other frames and I do not see any 
difference between the duplicates. FFmpeg's decimate 
filter does not detect any of the duplicates and 
therefore drops the first frame because it is a scene 
change, the other three duplicates are correctly 
dropped because they are "lowest" by a large margin 
but are not detected as duplicates.

It works if blockx and blocky are set to 128 but I 
wonder why this should be necessary and why it isn't 
necessary for avisynth (if this is true).

Perhaps somebody can test the fieldmatched.avi file in 
http://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket4990/ 
with the Virtualdub filter to see if it really works 
correctly for the first frames and ideally add debug 
output to see its maxbdiff and dupthresh values.

Thank you, Carl Eugen

duppos: -1 lowest: 4, dm->queue[lowest].maxbdiff: , dm->dupthresh: 2872
Last message repeated 11 times
[Parsed_decimate_0 @ 0x362b160] 1/5 frame drop:
[Parsed_decimate_0 @ 0x362b160]   #1: totdiff=7fff
maxbdiff=7fff sc [DROP]
[Parsed_decimate_0 @ 0x362b160]   #2: totdiff=00ca660c maxbdiff=000130d8
[Parsed_decimate_0 @ 0x362b160]   #3: totdiff=015715f3 maxbdiff=00022e12
[Parsed_decimate_0 @ 0x362b160]   #4: totdiff=00c6e459 maxbdiff=0001df5b
[Parsed_decimate_0 @ 0x362b160]   #5: totdiff=000d4fce maxbdiff=0d05 lowest
duppos: -1 lowest: 4, dm->queue[lowest].maxbdiff: 3947, dm->dupthresh: 2872
[Parsed_decimate_0 @ 0x362b160] 1/5 frame drop:
[Parsed_decimate_0 @ 0x362b160]   #1: totdiff=0093eda5 maxbdiff=0001b481
[Parsed_decimate_0 @ 0x362b160]   #2: totdiff=0089d968 maxbdiff=00019ebc
[Parsed_decimate_0 @ 0x362b160]   #3: totdiff=0080a999 maxbdiff=00017223
[Parsed_decimate_0 @ 0x362b160]   #4: totdiff=007c98d0 maxbdiff=00018261
[Parsed_decimate_0 @ 0x362b160]   #5: totdiff=00099bf0 maxbdiff=0f6b
lowest [DROP]
duppos: -1 lowest: 4, dm->queue[lowest].maxbdiff: 7578, dm->dupthresh: 2872
[Parsed_decimate_0 @ 0x362b160] 1/5 frame drop:
[Parsed_decimate_0 @ 0x362b160]   #1: totdiff=0079855c maxbdiff=0001ab54
[Parsed_decimate_0 @ 0x362b160]   #2: totdiff=008401c0 maxbdiff=0001bf8e
[Parsed_decimate_0 @ 0x362b160]   #3: totdiff=007db8bb maxbdiff=0001ade7
[Parsed_decimate_0 @ 0x362b160]   #4: totdiff=007f553c maxbdiff=0001806d
[Parsed_decimate_0 @ 0x362b160]   #5: totdiff=0010b14d maxbdiff=1d9a
lowest [DROP]
duppos: -1 lowest: 4, dm->queue[lowest].maxbdiff: 5389, dm->dupthresh: 2872
[Parsed_decimate_0 @ 0x362b160] 1/5 frame drop:
[Parsed_decimate_0 @ 0x362b160]   #1: totdiff=007b5d19 maxbdiff=0001691f
[Parsed_decimate_0 @ 0x362b160]   #2: totdiff=0076c12d maxbdiff=00012a61
[Parsed_decimate_0 @ 0x362b160]   #3: totdiff=006cc5ab maxbdiff=00014404
[Parsed_decimate_0 @ 0x362b160]   #4: totdiff=005b2dca maxbdiff=e7ce
[Parsed_decimate_0 @ 0x362b160]   #5: totdiff=000fe7bc maxbdiff=150d
lowest [DROP]

Note the missing "dup" for the "lowest" frames.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavf/decimate: Fix total difference for the first frame

[Clément Bœsch]

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" this if it works.
> 
> Nicolas has already found a very similar solution 
> that only differs in rare cases (although the change 
> should be ported) and not for the file in question.
> Sorry to say this but I wonder how the filter ever 
> passed any test without this (or a similar) change.
> 

I must confess that my initial testing was very light (it did match the
behaviour I was trying to copy with the sample I was using though), but I
remember saying that I was waiting for more testing from users since it
was supposedly a very much requested feature. Unfortunately, the issues
were raised very late, at a time when I didn't actually have much time to
look into this (like right now).

BTW, the main reason I pasted the commit was because of the explanation
for the "+1" you seemed to be wondering about.

> The OP of ticket #4990 claims that for his sample 
> the first frames are correctly handled with avisynth.
> (I have no idea how to test this.)
> 

You can maybe test with Vapoursynth (works on Linux). It was IMO a real
pain to use years ago, and documentation was severely lacking
(understandable because of the ambition of the project), but it might be
simpler nowadays.

[...]

-- 
Clément B.


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] lavf/matroskadec: A_QUICKTIME and AV_CODEC_ID_NONE

[Mats Peterson]

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 either 'raw ' or 'twos'
format, depending on the sample size field in the sound description."

MPlayer handles this logic by itself, but FFmpeg/FFplay currently does
not.

I have also removed some superfluous checks for the format/fourcc at the
very start of the private data for A_QUICKTIME and V_QUICKTIME. This
shouldn't happen, since the private data always starts with the sample
description size, *then* the format/fourcc, in a Matroska file.

Mats

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From 2783742601db6bb19d8571f013a5ec6902201e83 Mon Sep 17 00:00:00 2001
From: Mats Peterson 
Date: Mon, 4 Jan 2016 21:38:34 +0100
Subject: [PATCH] lavf/matroskadec: A_QUICKTIME and AV_CODEC_ID_NONE

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 either 'raw ' or 'twos'
format, depending on the sample size field in the sound description."

MPlayer handles this logic by itself, but FFmpeg/FFplay currently does
not.

I have also removed some superfluous checks for the format/fourcc at the
very start of the private data for A_QUICKTIME and V_QUICKTIME. This
shouldn't happen, since the private data always starts with the sample
description size, *then* the format/fourcc, in a Matroska file.

Mats

---
 libavformat/matroskadec.c |   15 ---
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index 9de7cfb..aaac620 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -1865,19 +1865,20 @@ static int matroska_parse_tracks(AVFormatContext *s)
&& (track->codec_priv.data)) {
 fourcc = AV_RL32(track->codec_priv.data + 4);
 codec_id = ff_codec_get_id(ff_codec_movaudio_tags, fourcc);
-if (ff_codec_get_id(ff_codec_movaudio_tags, AV_RL32(track->codec_priv.data))) {
-fourcc = AV_RL32(track->codec_priv.data);
-codec_id = ff_codec_get_id(ff_codec_movaudio_tags, fourcc);
+if (codec_id == AV_CODEC_ID_NONE) {
+if (track->audio.bitdepth == 8) {
+fourcc = MKTAG('r','a','w',' ');
+codec_id = ff_codec_get_id(ff_codec_movaudio_tags, fourcc);
+} else if (track->audio.bitdepth == 16) {
+fourcc = MKTAG('t','w','o','s');
+codec_id = ff_codec_get_id(ff_codec_movaudio_tags, fourcc);
+}
 }
 } else if (!strcmp(track->codec_id, "V_QUICKTIME") &&
(track->codec_priv.size >= 21)  &&
(track->codec_priv.data)) {
 fourcc   = AV_RL32(track->codec_priv.data + 4);
 codec_id = ff_codec_get_id(ff_codec_movvideo_tags, fourcc);
-if (ff_codec_get_id(ff_codec_movvideo_tags, AV_RL32(track->codec_priv.data))) {
-fourcc   = AV_RL32(track->codec_priv.data);
-codec_id = ff_codec_get_id(ff_codec_movvideo_tags, fourcc);
-}
 if (codec_id == AV_CODEC_ID_NONE && AV_RL32(track->codec_priv.data+4) == AV_RL32("SMI "))
 codec_id = AV_CODEC_ID_SVQ3;
 if (codec_id == AV_CODEC_ID_NONE) {
-- 
1.7.10.4

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] lavf/mov: Audio and AV_CODEC_ID_NONE

[Mats Peterson]

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 either 'raw ' or 'twos'
format, depending on the sample size field in the sound description."

MPlayer handles this logic by itself, but FFmpeg/FFplay currently does
not.

Mats

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From 861ecae89d3a33ae9dffa34494569fb9994071ff Mon Sep 17 00:00:00 2001
From: Mats Peterson 
Date: Mon, 4 Jan 2016 21:40:25 +0100
Subject: [PATCH] lavf/mov: Audio and AV_CODEC_ID_NONE

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 either 'raw ' or 'twos'
format, depending on the sample size field in the sound description."

MPlayer handles this logic by itself, but FFmpeg/FFplay currently does
not.

Mats

---
 libavformat/mov.c |   11 +++
 1 file changed, 11 insertions(+)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index 78081ce..f3ed85e 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -1899,6 +1899,17 @@ static void mov_parse_stsd_audio(MOVContext *c, AVIOContext *pb,
 sc->samples_per_frame = 160;
 sc->bytes_per_frame   = 33;
 break;
+case AV_CODEC_ID_NONE:
+if (st->codec->bits_per_coded_sample == 8) {
+st->codec->codec_tag = MKTAG('r','a','w',' ');
+st->codec->codec_id = ff_codec_get_id(ff_codec_movaudio_tags,
+st->codec->codec_tag);
+} else if (st->codec->bits_per_coded_sample == 16) {
+st->codec->codec_tag = MKTAG('t','w','o','s');
+st->codec->codec_id = ff_codec_get_id(ff_codec_movaudio_tags,
+st->codec->codec_tag);
+}
+break;
 default:
 break;
 }
-- 
1.7.10.4

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavf/matroskadec: A_QUICKTIME and AV_CODEC_ID_NONE

[Hendrik Leppkes]

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 be found in some
> files. Samples are assumed to be stored in either 'raw ' or 'twos'
> format, depending on the sample size field in the sound description."
>
> MPlayer handles this logic by itself, but FFmpeg/FFplay currently does
> not.
>
> I have also removed some superfluous checks for the format/fourcc at the
> very start of the private data for A_QUICKTIME and V_QUICKTIME. This
> shouldn't happen, since the private data always starts with the sample
> description size, *then* the format/fourcc, in a Matroska file.
>

Don't remove any existing checks, they usually get added based on actual files.
"Should not" does not mean "does not".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavf/matroskadec: A_QUICKTIME and AV_CODEC_ID_NONE

[Mats Peterson]

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 format descriptor should not be used, but may be found in some
files. Samples are assumed to be stored in either 'raw ' or 'twos'
format, depending on the sample size field in the sound description."

MPlayer handles this logic by itself, but FFmpeg/FFplay currently does
not.

I have also removed some superfluous checks for the format/fourcc at the
very start of the private data for A_QUICKTIME and V_QUICKTIME. This
shouldn't happen, since the private data always starts with the sample
description size, *then* the format/fourcc, in a Matroska file.



Don't remove any existing checks, they usually get added based on actual files.
"Should not" does not mean "does not".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel



Well, I almost expected that answer, Hendrik. Thanks. But a file with 
the fourcc at the very start will break things later on. Hopefully these 
files are very few ;)


Mats

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH v2] lavf/matroskadec: A_QUICKTIME and AV_CODEC_ID_NONE

[Mats Peterson]

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 either 'raw ' or 'twos'
format, depending on the sample size field in the sound description."

MPlayer handles this logic by itself, but FFmpeg/FFplay currently does
not.

Mats

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From 35c846a8d2a1bd1d90a0bfc71ec2f9d47227f625 Mon Sep 17 00:00:00 2001
From: Mats Peterson 
Date: Mon, 4 Jan 2016 22:47:25 +0100
Subject: [PATCH v2] lavf/matroskadec: A_QUICKTIME and AV_CODEC_ID_NONE

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 either 'raw ' or 'twos'
format, depending on the sample size field in the sound description."

MPlayer handles this logic by itself, but FFmpeg/FFplay currently does
not.

Mats

---
 libavformat/matroskadec.c |9 +
 1 file changed, 9 insertions(+)

diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index 9de7cfb..440c9f9 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -1869,6 +1869,15 @@ static int matroska_parse_tracks(AVFormatContext *s)
 fourcc = AV_RL32(track->codec_priv.data);
 codec_id = ff_codec_get_id(ff_codec_movaudio_tags, fourcc);
 }
+if (codec_id == AV_CODEC_ID_NONE) {
+if (track->audio.bitdepth == 8) {
+fourcc = MKTAG('r','a','w',' ');
+codec_id = ff_codec_get_id(ff_codec_movaudio_tags, fourcc);
+} else if (track->audio.bitdepth == 16) {
+fourcc = MKTAG('t','w','o','s');
+codec_id = ff_codec_get_id(ff_codec_movaudio_tags, fourcc);
+}
+}
 } else if (!strcmp(track->codec_id, "V_QUICKTIME") &&
(track->codec_priv.size >= 21)  &&
(track->codec_priv.data)) {
-- 
1.7.10.4

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] parser: error out if the codec doesn't match

[Andreas Cadhalpun]

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/libavcodec/parser.c
+++ b/libavcodec/parser.c
@@ -141,6 +141,17 @@ int av_parser_parse2(AVCodecParserContext *s, 
AVCodecContext *avctx,
 int index, i;
 uint8_t dummy_buf[AV_INPUT_BUFFER_PADDING_SIZE];
 
+if (avctx->codec_id != s->parser->codec_ids[0] &&
+avctx->codec_id != s->parser->codec_ids[1] &&
+avctx->codec_id != s->parser->codec_ids[2] &&
+avctx->codec_id != s->parser->codec_ids[3] &&
+avctx->codec_id != s->parser->codec_ids[4]) {
+av_log(avctx, AV_LOG_ERROR,
+   "The parser doesn't match the codec %s.\n",
+   avcodec_get_name(avctx->codec_id));
+return buf_size;
+}
+
 if (!(s->flags & PARSER_FLAG_FETCHED_OFFSET)) {
 s->next_frame_offset =
 s->cur_offset= pos;
-- 
2.6.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] parser: error out if the codec doesn't match

[Ganesh Ajjanagadde]

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/parser.c b/libavcodec/parser.c
> index 2809158..1f38edb 100644
> --- a/libavcodec/parser.c
> +++ b/libavcodec/parser.c
> @@ -141,6 +141,17 @@ int av_parser_parse2(AVCodecParserContext *s, 
> AVCodecContext *avctx,
>  int index, i;
>  uint8_t dummy_buf[AV_INPUT_BUFFER_PADDING_SIZE];
>
> +if (avctx->codec_id != s->parser->codec_ids[0] &&
> +avctx->codec_id != s->parser->codec_ids[1] &&
> +avctx->codec_id != s->parser->codec_ids[2] &&
> +avctx->codec_id != s->parser->codec_ids[3] &&
> +avctx->codec_id != s->parser->codec_ids[4]) {

Can't you use FFARRAY_ELEMS on codec_ids to make this more generic? No
opinion on the change itself.

> +av_log(avctx, AV_LOG_ERROR,
> +   "The parser doesn't match the codec %s.\n",
> +   avcodec_get_name(avctx->codec_id));
> +return buf_size;
> +}
> +
>  if (!(s->flags & PARSER_FLAG_FETCHED_OFFSET)) {
>  s->next_frame_offset =
>  s->cur_offset= pos;
> --
> 2.6.4
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] parser: error out if the codec doesn't match

[Andreas Cadhalpun]

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 file changed, 11 insertions(+)
>>
>> diff --git a/libavcodec/parser.c b/libavcodec/parser.c
>> index 2809158..1f38edb 100644
>> --- a/libavcodec/parser.c
>> +++ b/libavcodec/parser.c
>> @@ -141,6 +141,17 @@ int av_parser_parse2(AVCodecParserContext *s, 
>> AVCodecContext *avctx,
>>  int index, i;
>>  uint8_t dummy_buf[AV_INPUT_BUFFER_PADDING_SIZE];
>>
>> +if (avctx->codec_id != s->parser->codec_ids[0] &&
>> +avctx->codec_id != s->parser->codec_ids[1] &&
>> +avctx->codec_id != s->parser->codec_ids[2] &&
>> +avctx->codec_id != s->parser->codec_ids[3] &&
>> +avctx->codec_id != s->parser->codec_ids[4]) {
> 
> Can't you use FFARRAY_ELEMS on codec_ids to make this more generic? No
> opinion on the change itself.

I don't think that would improve readability.
Also codec_ids is already used that way in av_parser_init.

Anyway, the array length can't easily change as it's public API.

Best regards,
Andreas

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] parser: error out if the codec doesn't match

[Ganesh Ajjanagadde]

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 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/libavcodec/parser.c
>>> +++ b/libavcodec/parser.c
>>> @@ -141,6 +141,17 @@ int av_parser_parse2(AVCodecParserContext *s, 
>>> AVCodecContext *avctx,
>>>  int index, i;
>>>  uint8_t dummy_buf[AV_INPUT_BUFFER_PADDING_SIZE];
>>>
>>> +if (avctx->codec_id != s->parser->codec_ids[0] &&
>>> +avctx->codec_id != s->parser->codec_ids[1] &&
>>> +avctx->codec_id != s->parser->codec_ids[2] &&
>>> +avctx->codec_id != s->parser->codec_ids[3] &&
>>> +avctx->codec_id != s->parser->codec_ids[4]) {
>>
>> Can't you use FFARRAY_ELEMS on codec_ids to make this more generic? No
>> opinion on the change itself.
>
> I don't think that would improve readability.
> Also codec_ids is already used that way in av_parser_init.
>
> Anyway, the array length can't easily change as it's public API.

This is a good point, comment withdrawn.

>
> Best regards,
> Andreas
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [RFC v5] libavcodec: add a native Daala decoder

[Rostislav Pehlivanov]

>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 crashes, but a few remain, because *ex
>can already be negative here due to a previous overflow.
Thanks for the feedback and the suggestion. I've fixed that as well as some
more bugs in the entropy decoding system. I've also switched to using
uint64_t for ent_win and uint32_t for ent_rng. This should hopefully make
the decoder more robust. There was no performance penalty (although a
comment in libdaala's code mentions performance gains with "fast 64 bit
arithmetic").

>To avoid this problem, this line could be replaced with:
>*ex += (qg << 14) - (*ex >> 2);
Unfortunately that changes the result of the expectation value and causes
the decoder to go out of sync. I doubt that qg can overflow however, the
quantized gain values are usually far from INT_MAX/2;

>The width, height and pixel format can change in the middle of a stream,
>which currently causes segmentation faults due to out of bounds
>reads/writes.
I've written a new function which reinits the context and/or buffers in
case any of those change from frame to frame. It uses realloc so it should
be reasonably fast. Also I was able to remove the ugly 2D arrays and
replaced them with just a 1D array + a stride. This fixes some crashes when
reading the dering data.

You can see the changes on my repo: https://github.com/atomnuker/FFmpeg

Best regards,
Rostislav

On 3 January 2016 at 19:27, Andreas Cadhalpun <
andreas.cadhal...@googlemail.com> wrote:

> On 02.01.2016 18:56, Rostislav Pehlivanov wrote:
> > --- /dev/null
> > +++ b/libavcodec/daala_entropy.h
> > @@ -0,0 +1,464 @@
> [...]
> > +/* Expectation value is in Q16 */
> > +static inline int daalaent_decode_generic(DaalaEntropy *e, DaalaCDF *c,
> int *ex,
> > +  int max, int integrate)
> > +{
> > +int rval, lsb = 0, log_ex = daalaent_log_ex(*ex);
> > +const int shift = FFMAX(0, (log_ex - 5) >> 1);
> > +const int id = FFMIN(DAALAENT_MODEL_TAB - 1, log_ex);
> > +const int ms = (max + (1 << shift >> 1)) >> shift;
> > +int xs = (max == -1) ? 16 : FFMIN(ms + 1, 16);
> > +ent_rng *cdf = &c->cdf[id*c->y];
> > +if (!max)
> > +return 0;
> > +if ((xs = daalaent_decode_cdf(e, cdf, xs, 0, CDF_UNSCALED)) == 15) {
> > +int g = ((2*(*ex) >> 8) + (1 << shift >> 1)) >> shift;
>
> 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 crashes, but a few remain, because *ex
> can already be negative here due to a previous overflow.
>
> > +ent_win decay = FFMAX(2, FFMIN(254, 256*g/(g + 256)));
> > +xs += daalaent_decode_laplace(e, decay, (max == -1) ? -1 : ms -
> 15);
> > +}
> > +if (shift) {
> > +if (shift > !xs)
> > +lsb = daalaent_decode_bits(e, shift - !xs);
> > +lsb -= !!xs << (shift - 1);
> > +}
> > +rval = (xs << shift) + lsb;
> > +daalaent_exp_model_update(c, ex, rval, xs, id, integrate);
> > +return rval;
> > +}
>
> > --- /dev/null
> > +++ b/libavcodec/daala_pvq.h
> > @@ -0,0 +1,491 @@
> [...]
> > +static void daalapvq_decode_vector(DaalaEntropy *e, DaalaPVQ *pvq,
> > +   dctcoef *out, dctcoef *ref, const
> double beta,
> > +   uint8_t key_frame, int p, uint8_t
> *skip_rest,
> > +   uint8_t has_err, int band_idx,
> > +   int qm_off, enum DaalaBsize bsize)
> > +{
> > +int i, k;
> > +int qg = 0, skip = 0, itheta = (!!key_frame), has_ref = !key_frame;
> > +double qcg, gain, theta = 0.0f, gr = 0.0f, gain_off = 0.0f;
> > +dctcoef tmp[DAALAPVQ_MAX_PART_SIZE] = {0};
> > +
> > +const int robust = has_err || key_frame;
> > +const int band_len = pvq->size[band_idx];
> > +const int16_t *qmatrix = &pvq->qmatrix[qm_off];
> > +const int16_t *qmatrix_inv = &pvq->qmatrix_inv[qm_off];
> > +
> > +if (!skip_rest[(band_idx + 2) % 3]) {
> > +int iloc = (!!p)*DAALA_NBSIZES*DAALAPVQ_PARTITIONS_MAX +
> bsize*DAALAPVQ_PARTITIONS_MAX + band_idx;
> > +i = daalaent_decode_cdf_adapt(e, &pvq->pvqtheta_gain_cdf, iloc,
> 8 + 7*pvq->skip[band_idx]);
> > +if (!key_frame && i >= 10)
> > +i++;
> > +if (key_frame && i >= 8)
> > +i++;
> > +if (i >= 8) {
> > +i -= 8;
> > +skip_rest[0] = skip_rest[1] = skip_rest[2] = 1;
> > +}
> > +qg = i & 1;
> > +itheta = (i >> 1) - 1;
> > +has_ref =

Re: [FFmpeg-devel] [PATCH 1/2] lavc/pcm_tablegen: slight speedup of table generation

[Ganesh Ajjanagadde]

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 08:34:55PM -0800, Ganesh Ajjanagadde wrote:
>> >> > This gets rid of some branches to speed up table generation slightly
>> >> > (impact higher on mulaw than alaw). Tables are identical to before,
>> >> > tested with FATE.
>> >> >
>> >> > Sample benchmark (Haswell, GNU/Linux+gcc):
>> >> > old:
>> >> >  313494 decicycles in build_alaw_table,4094 runs,  2 skips
>> >> >  315959 decicycles in build_alaw_table,8190 runs,  2 skips
>> >> >
>> >> >  323599 decicycles in build_ulaw_table,4095 runs,  1 skips
>> >> >  318849 decicycles in build_ulaw_table,8188 runs,  4 skips
>> >> >
>> >> > new:
>> >> >  261902 decicycles in build_alaw_table,4096 runs,  0 skips
>> >> >  266519 decicycles in build_alaw_table,8192 runs,  0 skips
>> >> >
>> >> >  209657 decicycles in build_ulaw_table,4096 runs,  0 skips
>> >> >  232656 decicycles in build_ulaw_table,8192 runs,  0 skips
>> >> >
>> >> > Signed-off-by: Ganesh Ajjanagadde 
>> >> > ---
>> >> >  libavcodec/pcm_tablegen.h | 24 
>> >> >  1 file changed, 12 insertions(+), 12 deletions(-)
>> >> >
>> >> > diff --git a/libavcodec/pcm_tablegen.h b/libavcodec/pcm_tablegen.h
>> >> > index 1387210..7269977 100644
>> >> > --- a/libavcodec/pcm_tablegen.h
>> >> > +++ b/libavcodec/pcm_tablegen.h
>> >> > @@ -87,21 +87,21 @@ static av_cold void build_xlaw_table(uint8_t 
>> >> > *linear_to_xlaw,
>> >> >  {
>> >> >  int i, j, v, v1, v2;
>> >> >
>> >> > -j = 0;
>> >> > -for(i=0;i<128;i++) {
>> >> > -if (i != 127) {
>> >> > -v1 = xlaw2linear(i ^ mask);
>> >> > -v2 = xlaw2linear((i + 1) ^ mask);
>> >> > -v = (v1 + v2 + 4) >> 3;
>> >> > -} else {
>> >> > -v = 8192;
>> >> > -}
>> >> > -for(;j> >> > +j = 1;
>> >> > +linear_to_xlaw[8192] = mask;
>> >> > +for(i=0;i<127;i++) {
>> >> > +v1 = xlaw2linear(i ^ mask);
>> >> > +v2 = xlaw2linear((i + 1) ^ mask);
>> >> > +v = (v1 + v2 + 4) >> 3;
>> >> > +for(;j> >> > +linear_to_xlaw[8192 - j] = (i ^ (mask ^ 0x80));
>> >> >  linear_to_xlaw[8192 + j] = (i ^ mask);
>> >> > -if (j > 0)
>> >> > -linear_to_xlaw[8192 - j] = (i ^ (mask ^ 0x80));
>> >> >  }
>> >> >  }
>> >> > +for(;j<8192;j++) {
>> >> > +linear_to_xlaw[8192 - j] = (127 ^ (mask ^ 0x80));
>> >> > +linear_to_xlaw[8192 + j] = (127 ^ mask);
>> >> > +}
>> >> >  linear_to_xlaw[0] = linear_to_xlaw[1];
>> >>
>> >> i think you can make the tables 8 times smaller
>> >
>> > forget this, i should have checked the whole table or looked when i
>> > am awake ...
>>
>> ha ha. By the way, both changes are needed to get this level of
>> speedup, with only the j change which you acked, the speedup is much
>> smaller. But then also note that the other parts of the patch also
>> increase the binary size more.
>
> hmm, ok if its needed to get the speedup then LGTM
>
> thanks

pushed, thanks

>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Concerning the gods, I have no means of knowing whether they exist or not
> or of what sort they may be, because of the obscurity of the subject, and
> the brevity of human life -- Protagoras
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] lavc/pcm_tablegen: always generate tables at runtime.

[Ganesh Ajjanagadde]

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.
>
> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  libavcodec/Makefile   |  4 +---
>  libavcodec/pcm_tablegen.c | 39 ---
>  libavcodec/pcm_tablegen.h |  6 --
>  3 files changed, 1 insertion(+), 48 deletions(-)
>  delete mode 100644 libavcodec/pcm_tablegen.c
>
> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> index 0717d0a..568bc8a 100644
> --- a/libavcodec/Makefile
> +++ b/libavcodec/Makefile
> @@ -978,7 +978,6 @@ HOSTPROGS = aacps_tablegen
>   \
>  dv_tablegen \
>  motionpixels_tablegen   \
>  mpegaudio_tablegen  \
> -pcm_tablegen\
>  qdm2_tablegen   \
>  sinewin_tablegen\
>  sinewin_fixed_tablegen  \
> @@ -1003,7 +1002,7 @@ endif
>  GEN_HEADERS = cbrt_tables.h cbrt_fixed_tables.h aacps_tables.h 
> aacps_fixed_tables.h \
>dv_tables.h \
>sinewin_tables.h sinewin_fixed_tables.h mpegaudio_tables.h 
> motionpixels_tables.h \
> -  pcm_tables.h qdm2_tables.h
> +  qdm2_tables.h
>  GEN_HEADERS := $(addprefix $(SUBDIR), $(GEN_HEADERS))
>
>  $(GEN_HEADERS): $(SUBDIR)%_tables.h: $(SUBDIR)%_tablegen$(HOSTEXESUF)
> @@ -1021,6 +1020,5 @@ $(SUBDIR)sinewin_fixed.o: 
> $(SUBDIR)sinewin_fixed_tables.h
>  $(SUBDIR)mpegaudiodec_fixed.o: $(SUBDIR)mpegaudio_tables.h
>  $(SUBDIR)mpegaudiodec_float.o: $(SUBDIR)mpegaudio_tables.h
>  $(SUBDIR)motionpixels.o: $(SUBDIR)motionpixels_tables.h
> -$(SUBDIR)pcm.o: $(SUBDIR)pcm_tables.h
>  $(SUBDIR)qdm2.o: $(SUBDIR)qdm2_tables.h
>  endif
> diff --git a/libavcodec/pcm_tablegen.c b/libavcodec/pcm_tablegen.c
> deleted file mode 100644
> index bf8e7fb..000
> --- a/libavcodec/pcm_tablegen.c
> +++ /dev/null
> @@ -1,39 +0,0 @@
> -/*
> - * Generate a header file for hardcoded PCM tables
> - *
> - * Copyright (c) 2010 Reimar Döffinger 
> - *
> - * This file is part of FFmpeg.
> - *
> - * FFmpeg is free software; you can redistribute it and/or
> - * modify it under the terms of the GNU Lesser General Public
> - * License as published by the Free Software Foundation; either
> - * version 2.1 of the License, or (at your option) any later version.
> - *
> - * FFmpeg is distributed in the hope that it will be useful,
> - * but WITHOUT ANY WARRANTY; without even the implied warranty of
> - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> - * Lesser General Public License for more details.
> - *
> - * You should have received a copy of the GNU Lesser General Public
> - * License along with FFmpeg; if not, write to the Free Software
> - * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 
> USA
> - */
> -
> -#include 
> -#define CONFIG_HARDCODED_TABLES 0
> -#include "pcm_tablegen.h"
> -#include "tableprint.h"
> -
> -int main(void)
> -{
> -pcm_alaw_tableinit();
> -pcm_ulaw_tableinit();
> -
> -write_fileheader();
> -
> -WRITE_ARRAY("static const", uint8_t, linear_to_alaw);
> -WRITE_ARRAY("static const", uint8_t, linear_to_ulaw);
> -
> -return 0;
> -}
> diff --git a/libavcodec/pcm_tablegen.h b/libavcodec/pcm_tablegen.h
> index 7269977..d73a14e 100644
> --- a/libavcodec/pcm_tablegen.h
> +++ b/libavcodec/pcm_tablegen.h
> @@ -72,11 +72,6 @@ static av_cold int ulaw2linear(unsigned char u_val)
>  return (u_val & SIGN_BIT) ? (BIAS - t) : (t - BIAS);
>  }
>
> -#if CONFIG_HARDCODED_TABLES
> -#define pcm_alaw_tableinit()
> -#define pcm_ulaw_tableinit()
> -#include "libavcodec/pcm_tables.h"
> -#else
>  /* 16384 entries per table */
>  static uint8_t linear_to_alaw[16384];
>  static uint8_t linear_to_ulaw[16384];
> @@ -114,6 +109,5 @@ static void pcm_ulaw_tableinit(void)
>  {
>  build_xlaw_table(linear_to_ulaw, ulaw2linear, 0xff);
>  }
> -#endif /* CONFIG_HARDCODED_TABLES */
>
>  #endif /* AVCODEC_PCM_TABLEGEN_H */
> --
> 2.6.4
>

dropped, some have reservations about this.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] ffmpeg: replace log2 by faster variant

[Ganesh Ajjanagadde]

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, Ganesh Ajjanagadde
>>> >  wrote:
>>> >> The log is anyway rounded to an integer, so one may use an frexp
>>> >> based approach. Note that this may be made frexpf; if arguments are less 
>>> >> than
>>> >> 2^24 there is no loss. Kept as double precision for simplicity; 2^32 is
>>> >> exactly representable as a double.
>>> >>
>>> >> Signed-off-by: Ganesh Ajjanagadde 
>>> >> ---
>>> >>  ffmpeg.c | 13 -
>>> >>  1 file changed, 12 insertions(+), 1 deletion(-)
>>> >>
>>> >> diff --git a/ffmpeg.c b/ffmpeg.c
>>> >> index 6d01987..ee72f91 100644
>>> >> --- a/ffmpeg.c
>>> >> +++ b/ffmpeg.c
>>> >> @@ -1486,6 +1486,17 @@ static void print_final_stats(int64_t total_size)
>>> >>  }
>>> >>  }
>>> >>
>>> >> +static inline int log2i(double d)
>>> >> +{
>>> >> +int exp;
>>> >> +double mant;
>>> >> +
>>> >> +mant = frexp(d, &exp);
>>> >> +if (mant >= M_SQRT1_2)
>>> >> +return exp;
>>> >> +return exp-1;
>>> >> +}
>>> >> +
>>> >>  static void print_report(int is_last_report, int64_t timer_start, 
>>> >> int64_t cur_time)
>>> >>  {
>>> >>  char buf[1024];
>>> >> @@ -1559,7 +1570,7 @@ static void print_report(int is_last_report, 
>>> >> int64_t timer_start, int64_t cur_ti
>>> >>  if (qp >= 0 && qp < FF_ARRAY_ELEMS(qp_histogram))
>>> >>  qp_histogram[qp]++;
>>> >>  for (j = 0; j < 32; j++)
>>> >> -snprintf(buf + strlen(buf), sizeof(buf) - 
>>> >> strlen(buf), "%X", (int)lrintf(log2(qp_histogram[j] + 1)));
>>> >> +snprintf(buf + strlen(buf), sizeof(buf) - 
>>> >> strlen(buf), "%X", log2i(qp_histogram[j] + 1));
>>> >>  }
>>> >>
>>> >>  if ((enc->flags & AV_CODEC_FLAG_PSNR) && (ost->pict_type != 
>>> >> AV_PICTURE_TYPE_NONE || is_last_report)) {
>>> >> --
>>> >> 2.6.4
>>> >
>>> > This isn't exactly a performance critical area, and defining a custom
>>> > function just for this seems somewhat like over-optimization.
>>> > Just my opinion, of course, I'll leave the decision up to the
>>> > maintainers of ffmpeg.c
>>>
>>> Ping: based on the above, final decision left to you, Michael.
>>
>> maybe av_log2() could be used, so as to avoid any increase in
>> complexity
>
> Not really, or at least not without additional code. The lrint rounds
> the log; av_log2 either returns the log of the next higher power of 2,
> or the one before it. Thus they are quite different things. I don't
> know if this is wrong or not; I created this to preserve identical
> behavior.

@Michael: final thoughts?

>
>>
>> [...]
>> --
>> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>>
>> The greatest way to live with honor in this world is to be what we pretend
>> to be. -- Socrates
>>
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCHv2] avformat/mp3dec, rmdec: check return value of ffio_ensure_seekback

[Ganesh Ajjanagadde]

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: Ganesh Ajjanagadde 
---
 libavformat/mp3dec.c | 13 +++--
 libavformat/rmdec.c  |  3 ++-
 2 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/libavformat/mp3dec.c b/libavformat/mp3dec.c
index c76b21e..57ebcc8 100644
--- a/libavformat/mp3dec.c
+++ b/libavformat/mp3dec.c
@@ -372,11 +372,19 @@ static int mp3_read_header(AVFormatContext *s)
 uint32_t header, header2;
 int frame_size;
 if (!(i&1023))
-ffio_ensure_seekback(s->pb, i + 1024 + 4);
+if ((ret = ffio_ensure_seekback(s->pb, i + 1024 + 4)) < 0) {
+av_log(s, AV_LOG_WARNING,
+   "initial junk detection and skipping impossible due to: 
%s\n", av_err2str(ret));
+goto skip_fail;
+}
 frame_size = check(s->pb, off + i, &header);
 if (frame_size > 0) {
 avio_seek(s->pb, off, SEEK_SET);
-ffio_ensure_seekback(s->pb, i + 1024 + frame_size + 4);
+if ((ret = ffio_ensure_seekback(s->pb, i + 1024 + frame_size + 4)) 
< 0) {
+av_log(s, AV_LOG_WARNING,
+   "initial junk detection and skipping impossible due to: 
%s\n", av_err2str(ret));
+goto skip_fail;
+}
 if (check(s->pb, off + i + frame_size, &header2) >= 0 &&
 (header & SAME_HEADER_MASK) == (header2 & SAME_HEADER_MASK))
 {
@@ -387,6 +395,7 @@ static int mp3_read_header(AVFormatContext *s)
 }
 avio_seek(s->pb, off, SEEK_SET);
 }
+skip_fail:
 
 // the seek index is relative to the end of the xing vbr headers
 for (i = 0; i < st->nb_index_entries; i++)
diff --git a/libavformat/rmdec.c b/libavformat/rmdec.c
index 4e46a3d..470e227 100644
--- a/libavformat/rmdec.c
+++ b/libavformat/rmdec.c
@@ -618,7 +618,8 @@ static int rm_read_header(AVFormatContext *s)
 size = avio_rb32(pb);
 codec_pos = avio_tell(pb);
 
-ffio_ensure_seekback(pb, 4);
+if ((ret = ffio_ensure_seekback(pb, 4)) < 0)
+av_log(s, AV_LOG_WARNING, "seeking back impossible due to: 
%s\n", av_err2str(ret));
 v = avio_rb32(pb);
 if (v == MKBETAG('M', 'L', 'T', 'I')) {
 ret = rm_read_multi(s, s->pb, st, mime);
-- 
2.6.4

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCHv2] lavc/cbrt_tablegen: speed up tablegen

[Ganesh Ajjanagadde]

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,   1 runs,  0 skips
490 decicycles in cbrt_tableinit,   2 runs,  0 skips
[...]
7582339 decicycles in cbrt_tableinit, 256 runs,  0 skips
7563556 decicycles in cbrt_tableinit, 512 runs,  0 skips

new:
2099480 decicycles in cbrt_tableinit,   1 runs,  0 skips
2044470 decicycles in cbrt_tableinit,   2 runs,  0 skips
[...]
1796544 decicycles in cbrt_tableinit, 256 runs,  0 skips
1791631 decicycles in cbrt_tableinit, 512 runs,  0 skips

Both small and large run count given as this is called once so small run
count may give a better picture, small numbers are fairly consistent,
and there is a consistent downward trend from small to large runs,
at which point it stabilizes to a new value.

Signed-off-by: Ganesh Ajjanagadde 
---
 libavcodec/aacdec_fixed.c   |  4 +--
 libavcodec/aacdec_template.c|  2 +-
 libavcodec/cbrt_tablegen.h  | 53 ++---
 libavcodec/cbrt_tablegen_template.c | 12 -
 4 files changed, 51 insertions(+), 20 deletions(-)

diff --git a/libavcodec/aacdec_fixed.c b/libavcodec/aacdec_fixed.c
index 396a874..f7b882b 100644
--- a/libavcodec/aacdec_fixed.c
+++ b/libavcodec/aacdec_fixed.c
@@ -155,9 +155,9 @@ static void vector_pow43(int *coefs, int len)
 for (i=0; i
 #include 
 #include "libavutil/attributes.h"
+#include "libavutil/intfloat.h"
 #include "libavcodec/aac_defines.h"
 
-#if USE_FIXED
-#define CBRT(x) lrint((x).f * 8192)
-#else
-#define CBRT(x) x.i
-#endif
-
+union ff_int32float64 {
+uint32_t i;
+double   f;
+};
 #if CONFIG_HARDCODED_TABLES
 #if USE_FIXED
 #define cbrt_tableinit_fixed()
@@ -43,20 +42,42 @@
 #include "libavcodec/cbrt_tables.h"
 #endif
 #else
-static uint32_t cbrt_tab[1 << 13];
+static union ff_int32float64 cbrt_tab[1 << 13];
 
 static av_cold void AAC_RENAME(cbrt_tableinit)(void)
 {
-if (!cbrt_tab[(1<<13) - 1]) {
-int i;
-for (i = 0; i < 1<<13; i++) {
-union {
-float f;
-uint32_t i;
-} f;
-f.f = cbrt(i) * i;
-cbrt_tab[i] = CBRT(f);
+int i, j, k;
+double cbrt_val;
+
+if (!cbrt_tab[(1<<13) - 1].i) {
+cbrt_tab[0].f = 0;
+for (i = 1; i < 1<<13; i++)
+cbrt_tab[i].f = 1;
+
+/* have to worry about non-squarefree numbers */
+for (i = 2; i < 90; i++) {
+if (cbrt_tab[i].f == 1) {
+cbrt_val = i * cbrt(i);
+for (k = i; k < (1<<13); k*= i)
+for (j = k; j < (1<<13); j+=k)
+cbrt_tab[j].f *= cbrt_val;
+}
 }
+
+for (i = 91; i <= 8191; i+=2) {
+if (cbrt_tab[i].f == 1) {
+cbrt_val = i * cbrt(i);
+for (j = i; j < (1<<13); j+=i)
+cbrt_tab[j].f *= cbrt_val;
+}
+}
+#if USE_FIXED
+for (i = 0; i < 1<<13; i++)
+cbrt_tab[i].i = lrint(cbrt_tab[i].f * 8192);
+#else
+for (i = 0; i < 1<<13; i++)
+cbrt_tab[i].i = av_float2int((float)cbrt_tab[i].f);
+#endif
 }
 }
 #endif /* CONFIG_HARDCODED_TABLES */
diff --git a/libavcodec/cbrt_tablegen_template.c 
b/libavcodec/cbrt_tablegen_template.c
index 7dcab91..5abcaba 100644
--- a/libavcodec/cbrt_tablegen_template.c
+++ b/libavcodec/cbrt_tablegen_template.c
@@ -28,11 +28,21 @@
 
 int main(void)
 {
+const int array_size = FF_ARRAY_ELEMS(cbrt_tab);
+int i;
 AAC_RENAME(cbrt_tableinit)();
 
 write_fileheader();
 
-WRITE_ARRAY("static const", uint32_t, cbrt_tab);
+printf("static const union ff_int32float64 cbrt_tab[%d] = {\n", 
array_size);
+printf("   ");
+for (i = 0; i < array_size - 1; i++) {
+printf(" {.i = 0x%08"PRIx32"},", cbrt_tab[i].i);
+if ((i & 7) == 7)
+printf("\n   ");
+}
+printf(" {.i = 0x%08"PRIx32"}\n", cbrt_tab[i].i);
+printf("};\n");
 
 return 0;
 }
-- 
2.6.4

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] lavfi/avf_showspectrum: replace pow(x, 0.25) by sqrt(sqrt(x))

[Ganesh Ajjanagadde]

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/libavfilter/avf_showspectrum.c
+++ b/libavfilter/avf_showspectrum.c
@@ -578,7 +578,7 @@ static int plot_spectrum_column(AVFilterLink *inlink, 
AVFrame *insamples)
 a = cbrt(a);
 break;
 case FOURTHRT:
-a = pow(a, 0.25);
+a = sqrt(sqrt(a));
 break;
 case FIFTHRT:
 a = pow(a, 0.20);
-- 
2.6.4

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/concatdec: get bit_rate from internal format

[Zhang Rui]

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 prefetch buffer size.
>> 3. Show prefetched duration in progress bar.
>>
>> I thought AVFormatContext.bit_rate is a convenient alias.
>> Is AVCodecContext.bit_rate more suitable for these purpose?
>
> I see. At first glance it makes sense, but I do not think you are on the
> right track, for two reasons.
>
> First, you will have trouble using custom I/O with the concat demuxer, it is
> not really meant for programmatic use. All it does is read packets from the
> underlying demuxers and adjust timestamps: in an application, you can easily
> do the same directly with more control. Then you have access to the
> properties of each file, including bit_rate.
>
> Second, the bit_rate is only an average. With VFR content, you would end up
> buffering way more than necessary for still scenes (not really a problem if
> memory is cheap), and then under-run very fast as soon as there is water or
> foliage visible.
>
> To handle VFR content, you need to adjust dynamically. IMHO, the best way of
> doing that is to buffer packets after the demuxer, not octets before it.
> Demuxing is fast, and the memory use is roughly the same, mostly the
> payload, so it does not change anything. But if you buffer after the
> demuxer, you have access to the timestamps of the packets: you can decide
> you want to buffer 20 seconds of movie, you just have to demux until the
> timestamp is right, you do not need to estimate how many octets it makes.
>
> Hope this helps.

Got it.
Thanks for your patient reply.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] lavfi/af_compensationdelay: replace pow(x, 0.5) by sqrt(x)

[Ganesh Ajjanagadde]

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 33ee7e4..d5a3484 100644
--- a/libavfilter/af_compensationdelay.c
+++ b/libavfilter/af_compensationdelay.c
@@ -57,7 +57,7 @@ AVFILTER_DEFINE_CLASS(compensationdelay);
 // The maximum distance for options
 #define COMP_DELAY_MAX_DISTANCE(100.0 * 100.0 + 100.0 * 1.0 + 1.0)
 // The actual speed of sound in normal conditions
-#define COMP_DELAY_SOUND_SPEED_KM_H(temp)  1.85325 * (643.95 * pow(((temp + 
273.15) / 273.15), 0.5))
+#define COMP_DELAY_SOUND_SPEED_KM_H(temp)  1.85325 * (643.95 * sqrt(((temp + 
273.15) / 273.15)))
 #define COMP_DELAY_SOUND_SPEED_CM_S(temp)  (COMP_DELAY_SOUND_SPEED_KM_H(temp) 
* (1000.0 * 100.0) /* cm/km */ / (60.0 * 60.0) /* s/h */)
 #define COMP_DELAY_SOUND_FRONT_DELAY(temp) (1.0 / 
COMP_DELAY_SOUND_SPEED_CM_S(temp))
 // The maximum delay may be reached by this filter
-- 
2.6.4

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] ffmpeg: check return value of avio_closep for progress report

[Ganesh Ajjanagadde]

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 of these is changed in the patch is to get feedback:
a quick glance shows a large number of unchecked avio_close operations.
It may be tedious to check all of them, and relative importance varies
across instances. This was one which I feel is important.

Signed-off-by: Ganesh Ajjanagadde 
---
 ffmpeg.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/ffmpeg.c b/ffmpeg.c
index ee72f91..81f3697 100644
--- a/ffmpeg.c
+++ b/ffmpeg.c
@@ -1512,6 +1512,7 @@ static void print_report(int is_last_report, int64_t 
timer_start, int64_t cur_ti
 static int64_t last_time = -1;
 static int qp_histogram[52];
 int hours, mins, secs, us;
+int ret;
 float t;
 
 if (!print_stats && !is_last_report && !progress_avio)
@@ -1678,7 +1679,9 @@ static void print_report(int is_last_report, int64_t 
timer_start, int64_t cur_ti
 avio_flush(progress_avio);
 av_bprint_finalize(&buf_script, NULL);
 if (is_last_report) {
-avio_closep(&progress_avio);
+if ((ret = avio_closep(&progress_avio)) < 0)
+av_log(NULL, AV_LOG_ERROR,
+   "not possible to close progress log, loss of 
information possible: %s\n", av_err2str(ret));
 }
 }
 
-- 
2.6.4

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 1/3] libavcodec/ccaption_dec: remove unnecessary include

[Aman Gupta]

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"
 #include "ass.h"
-#include "libavutil/internal.h"
 #include "libavutil/opt.h"
 
 #define SCREEN_ROWS 15
-- 
2.5.3

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 2/3] libavcodec/ccaption_dec: clean up and standardize white space

[Aman Gupta]

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/libavcodec/ccaption_dec.c
@@ -145,10 +145,9 @@ struct Screen {
  * for setting row 1  use row | (1 << 0)
  * for setting row 15 use row | (1 << 14)
  */
-int16_t  row_used;
+int16_t row_used;
 };
 
-
 typedef struct CCaptionSubContext {
 AVClass *class;
 struct Screen screen[2];
@@ -168,7 +167,7 @@ typedef struct CCaptionSubContext {
 char prev_cmd[2];
 /* buffer to store pkt data */
 AVBufferRef *pktbuf;
-}CCaptionSubContext;
+} CCaptionSubContext;
 
 
 static av_cold int init_decoder(AVCodecContext *avctx)
@@ -181,12 +180,12 @@ static av_cold int init_decoder(AVCodecContext *avctx)
 ctx->mode = CCMODE_ROLLUP_2;
 ctx->rollup = 2;
 ret = ff_ass_subtitle_header_default(avctx);
-if(ret < 0) {
+if (ret < 0) {
 return ret;
 }
 /* allocate pkt buffer */
 ctx->pktbuf = av_buffer_alloc(128);
-if( !ctx->pktbuf) {
+if (!ctx->pktbuf) {
 ret = AVERROR(ENOMEM);
 }
 return ret;
@@ -195,7 +194,7 @@ static av_cold int init_decoder(AVCodecContext *avctx)
 static av_cold int close_decoder(AVCodecContext *avctx)
 {
 CCaptionSubContext *ctx = avctx->priv_data;
-av_bprint_finalize( &ctx->buffer, NULL);
+av_bprint_finalize(&ctx->buffer, NULL);
 av_buffer_unref(&ctx->pktbuf);
 return 0;
 }
@@ -203,14 +202,14 @@ static av_cold int close_decoder(AVCodecContext *avctx)
 /**
  * @param ctx closed caption context just to print log
  */
-static int write_char (CCaptionSubContext *ctx, char *row,uint8_t col, char ch)
+static int write_char(CCaptionSubContext *ctx, char *row, uint8_t col, char ch)
 {
-if(col < SCREEN_COLUMNS) {
+if (col < SCREEN_COLUMNS) {
 row[col] = ch;
 return 0;
 }
 /* We have extra space at end only for null character */
-else if ( col == SCREEN_COLUMNS && ch == 0) {
+else if (col == SCREEN_COLUMNS && ch == 0) {
 row[col] = ch;
 return 0;
 }
@@ -227,7 +226,7 @@ static int write_char (CCaptionSubContext *ctx, char 
*row,uint8_t col, char ch)
  * If the second byte doesn't pass parity, it returns INVALIDDATA
  * user can ignore the whole pair and pass the other pair.
  */
-static int validate_cc_data_pair (uint8_t *cc_data_pair)
+static int validate_cc_data_pair(uint8_t *cc_data_pair)
 {
 uint8_t cc_valid = (*cc_data_pair & 4) >>2;
 uint8_t cc_type = *cc_data_pair & 3;
@@ -246,21 +245,19 @@ static int validate_cc_data_pair (uint8_t *cc_data_pair)
 }
 
 //Skip non-data
-if( (cc_data_pair[0] == 0xFA || cc_data_pair[0] == 0xFC || cc_data_pair[0] 
== 0xFD )
+if ((cc_data_pair[0] == 0xFA || cc_data_pair[0] == 0xFC || cc_data_pair[0] 
== 0xFD)
  && (cc_data_pair[1] & 0x7F) == 0 && (cc_data_pair[2] & 0x7F) == 0)
 return AVERROR_PATCHWELCOME;
 
 //skip 708 data
-if(cc_type == 3 || cc_type == 2 )
+if (cc_type == 3 || cc_type == 2)
 return AVERROR_PATCHWELCOME;
 
 /* remove parity bit */
 cc_data_pair[1] &= 0x7F;
 cc_data_pair[2] &= 0x7F;
 
-
 return 0;
-
 }
 
 static struct Screen *get_writing_screen(CCaptionSubContext *ctx)
@@ -286,7 +283,7 @@ static void roll_up(CCaptionSubContext *ctx)
 struct Screen *screen;
 int i, keep_lines;
 
-if(ctx->mode == CCMODE_TEXT)
+if (ctx->mode == CCMODE_TEXT)
 return;
 
 screen = get_writing_screen(ctx);
@@ -296,22 +293,21 @@ static void roll_up(CCaptionSubContext *ctx)
  */
 keep_lines = FFMIN(ctx->cursor_row + 1, ctx->rollup);
 
-for( i = 0; i < ctx->cursor_row - keep_lines; i++ )
+for (i = 0; i < ctx->cursor_row - keep_lines; i++)
 UNSET_FLAG(screen->row_used, i);
 
 
-for( i = 0; i < keep_lines && screen->row_used; i++ ) {
+for (i = 0; i < keep_lines && screen->row_used; i++) {
 const int i_row = ctx->cursor_row - keep_lines + i + 1;
 
-memcpy( screen->characters[i_row], screen->characters[i_row+1], 
SCREEN_COLUMNS );
-memcpy( screen->colors[i_row], screen->colors[i_row+1], 
SCREEN_COLUMNS);
-memcpy( screen->fonts[i_row], screen->fonts[i_row+1], SCREEN_COLUMNS);
-if(CHECK_FLAG(screen->row_used, i_row + 1))
+memcpy(screen->characters[i_row], screen->characters[i_row+1], 
SCREEN_COLUMNS);
+memcpy(screen->colors[i_row], screen->colors[i_row+1], SCREEN_COLUMNS);
+memcpy(screen->fonts[i_row], screen->fonts[i_row+1], SCREEN_COLUMNS);
+if (CHECK_FLAG(screen->row_used, i_row + 1))
 SET_FLAG(screen->row_used, i_row);
 
 }
 UNSET_FLAG(screen->row_used, ctx->cursor_row);
-
 }
 
 static int reap_screen(CCaptionSubContext *ctx, int64_t pts)
@@ -321,9 +317,9 @@ static int reap_screen(CCaptionSubContext *ctx, int

[FFmpeg-devel] [PATCH 3/3] libavcodec/ccaption_dec: rewrite packet handler as case statement; remove COR3 macro

[Aman Gupta]

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/libavcodec/ccaption_dec.c
@@ -453,54 +453,69 @@ static void handle_char(CCaptionSubContext *ctx, char hi, 
char lo, int64_t pts)
 static int process_cc608(CCaptionSubContext *ctx, int64_t pts, uint8_t hi, 
uint8_t lo)
 {
 int ret = 0;
-#define COR3(var, with1, with2, with3)  ( (var) == (with1) ||  (var) == 
(with2) || (var) == (with3) )
 if (hi == ctx->prev_cmd[0] && lo == ctx->prev_cmd[1]) {
-/* ignore redundant command */
+/* ignore redundant command */
 } else if ( (hi == 0x10 && (lo >= 0x40 || lo <= 0x5f)) ||
   ( (hi >= 0x11 && hi <= 0x17) && (lo >= 0x40 && lo <= 0x7f) ) ) {
 handle_pac(ctx, hi, lo);
 } else if ( ( hi == 0x11 && lo >= 0x20 && lo <= 0x2f ) ||
 ( hi == 0x17 && lo >= 0x2e && lo <= 0x2f) ) {
 handle_textattr(ctx, hi, lo);
-} else if ( COR3(hi, 0x14, 0x15, 0x1C) && lo == 0x20 ) {
-/* resume caption loading */
-ctx->mode = CCMODE_POPON;
-} else if ( COR3(hi, 0x14, 0x15, 0x1C) && lo == 0x24 ) {
-handle_delete_end_of_row(ctx, hi, lo);
-} else if ( COR3(hi, 0x14, 0x15, 0x1C) && lo == 0x25 ) {
-ctx->rollup = 2;
-ctx->mode = CCMODE_ROLLUP_2;
-} else if ( COR3(hi, 0x14, 0x15, 0x1C) && lo == 0x26 ) {
-ctx->rollup = 3;
-ctx->mode = CCMODE_ROLLUP_3;
-} else if ( COR3(hi, 0x14, 0x15, 0x1C) && lo == 0x27 ) {
-ctx->rollup = 4;
-ctx->mode = CCMODE_ROLLUP_4;
-} else if ( COR3(hi, 0x14, 0x15, 0x1C) && lo == 0x29 ) {
-/* resume direct captioning */
-ctx->mode = CCMODE_PAINTON;
-} else if ( COR3(hi, 0x14, 0x15, 0x1C) && lo == 0x2B ) {
-/* resume text display */
-ctx->mode = CCMODE_TEXT;
-} else if ( COR3(hi, 0x14, 0x15, 0x1C) && lo == 0x2C ) {
-/* erase display memory */
-ret = handle_edm(ctx, pts);
-} else if ( COR3(hi, 0x14, 0x15, 0x1C) && lo == 0x2D ) {
-/* carriage return */
-ff_dlog(ctx, "carriage return\n");
-reap_screen(ctx, pts);
-roll_up(ctx);
-ctx->screen_changed = 1;
-ctx->cursor_column = 0;
-} else if ( COR3(hi, 0x14, 0x15, 0x1C) && lo == 0x2F ) {
-/* end of caption */
-ff_dlog(ctx, "handle_eoc\n");
-ret = handle_eoc(ctx, pts);
+} else if (hi == 0x14 || hi == 0x15 || hi == 0x1c) {
+switch (lo) {
+case 0x20:
+/* resume caption loading */
+ctx->mode = CCMODE_POPON;
+break;
+case 0x24:
+handle_delete_end_of_row(ctx, hi, lo);
+break;
+case 0x25:
+ctx->rollup = 2;
+ctx->mode = CCMODE_ROLLUP_2;
+break;
+case 0x26:
+ctx->rollup = 3;
+ctx->mode = CCMODE_ROLLUP_3;
+break;
+case 0x27:
+ctx->rollup = 4;
+ctx->mode = CCMODE_ROLLUP_4;
+break;
+case 0x29:
+/* resume direct captioning */
+ctx->mode = CCMODE_PAINTON;
+break;
+case 0x2b:
+/* resume text display */
+ctx->mode = CCMODE_TEXT;
+break;
+case 0x2c:
+/* erase display memory */
+ret = handle_edm(ctx, pts);
+break;
+case 0x2d:
+/* carriage return */
+ff_dlog(ctx, "carriage return\n");
+reap_screen(ctx, pts);
+roll_up(ctx);
+ctx->screen_changed = 1;
+ctx->cursor_column = 0;
+break;
+case 0x2f:
+/* end of caption */
+ff_dlog(ctx, "handle_eoc\n");
+ret = handle_eoc(ctx, pts);
+break;
+default:
+ff_dlog(ctx, "Unknown command 0x%hhx 0x%hhx\n", hi, lo);
+break;
+}
 } else if (hi>=0x20) {
-/* Standard characters (always in pairs) */
+/* Standard characters (always in pairs) */
 handle_char(ctx, hi, lo, pts);
 } else {
-/* Ignoring all other non data code */
+/* Ignoring all other non data code */
 ff_dlog(ctx, "Unknown command 0x%hhx 0x%hhx\n", hi, lo);
 }
 
@@ -508,7 +523,6 @@ static int process_cc608(CCaptionSubContext *ctx, int64_t 
pts, uint8_t hi, uint8
 ctx->prev_cmd[0] = hi;
 ctx->prev_cmd[1] = lo;
 
-#undef COR3
 return ret;
 }
 
-- 
2.5.3

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH v2] lavf/mov: Audio and AV_CODEC_ID_NONE

[Mats Peterson]

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 in some
files. Samples are assumed to be stored in either 'raw ' or 'twos'
format, depending on the sample size field in the sound description."

MPlayer handles this logic by itself, but FFmpeg/FFplay currently does
not.

Mats

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From 60e5a75c192e867d039933cf1d06595f90a5da98 Mon Sep 17 00:00:00 2001
From: Mats Peterson 
Date: Tue, 5 Jan 2016 06:24:23 +0100
Subject: [PATCH v2] lavf/mov: Audio and AV_CODEC_ID_NONE

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 in some
files. Samples are assumed to be stored in either 'raw ' or 'twos'
format, depending on the sample size field in the sound description."

MPlayer handles this logic by itself, but FFmpeg/FFplay currently does
not.

Mats

---
 libavformat/mov.c |6 ++
 1 file changed, 6 insertions(+)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index 78081ce..3232cac 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -1882,6 +1882,12 @@ static void mov_parse_stsd_audio(MOVContext *c, AVIOContext *pb,
 st->codec->codec_id == AV_CODEC_ID_PCM_S16BE ?
 AV_CODEC_ID_PCM_S32BE : AV_CODEC_ID_PCM_S32LE;
 break;
+case AV_CODEC_ID_NONE:
+if (st->codec->bits_per_coded_sample == 8)
+st->codec->codec_id = mov_codec_id(st, MKTAG('r','a','w',' '));
+else if (st->codec->bits_per_coded_sample == 16)
+st->codec->codec_id = mov_codec_id(st, MKTAG('t','w','o','s'));
+break;
 /* set values for old format before stsd version 1 appeared */
 case AV_CODEC_ID_MACE3:
 sc->samples_per_frame = 6;
-- 
1.7.10.4

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2] lavf/mov: Audio and AV_CODEC_ID_NONE

[Ganesh Ajjanagadde]

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:
>
> "This format descriptor should not be used, but may be found in some
> files. Samples are assumed to be stored in either 'raw ' or 'twos'
> format, depending on the sample size field in the sound description."
>
> MPlayer handles this logic by itself, but FFmpeg/FFplay currently does
> not.
>
> Mats
>
> --
> Mats Peterson
> http://matsp888.no-ip.org/~mats/
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

One tip for you that is very helpful for reviewers: suffix [PATCH] by
a version, like [PATCHv2], [PATCHv3], etc. It helps them in keeping
track of the proposal. Thanks.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2] lavf/mov: Audio and AV_CODEC_ID_NONE

[Mats Peterson]

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
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 either 'raw ' or 'twos'
format, depending on the sample size field in the sound description."

MPlayer handles this logic by itself, but FFmpeg/FFplay currently does
not.

Mats

--
Mats Peterson
http://matsp888.no-ip.org/~mats/

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel



One tip for you that is very helpful for reviewers: suffix [PATCH] by
a version, like [PATCHv2], [PATCHv3], etc. It helps them in keeping
track of the proposal. Thanks.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel



Already done. Look at the subject.

Mats

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2] lavf/mov: Audio and AV_CODEC_ID_NONE

[Ganesh Ajjanagadde]

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", 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 either 'raw ' or 'twos'
>>> format, depending on the sample size field in the sound description."
>>>
>>> MPlayer handles this logic by itself, but FFmpeg/FFplay currently does
>>> not.
>>>
>>> Mats
>>>
>>> --
>>> Mats Peterson
>>> http://matsp888.no-ip.org/~mats/
>>>
>>> ___
>>> ffmpeg-devel mailing list
>>> ffmpeg-devel@ffmpeg.org
>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>>
>>
>> One tip for you that is very helpful for reviewers: suffix [PATCH] by
>> a version, like [PATCHv2], [PATCHv3], etc. It helps them in keeping
>> track of the proposal. Thanks.
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
>
> Already done. Look at the subject.

Sorry, my gmail webmail does not seem to handle this correctly.

>
>
> Mats
>
> --
> Mats Peterson
> http://matsp888.no-ip.org/~mats/
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2] lavf/mov: Audio and AV_CODEC_ID_NONE

[Mats Peterson]

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

Re: [FFmpeg-devel] [PATCH] avcodec: Remove libstagefright

[Matthieu Bouron]

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, and this is the correct way to use it.
> MediaCodec as a proper JNI API.

MediaCodec is the current way to go on Android either via JNI or using its
C API that has been introduced in Android 5. I'm not sure if there is
already an avcodec backend for it as I'm currently working on one based on
the C API (h264 decoding is working, the flush command still need to be
implemented; some patch can be expected at the end of the month).

>
> Furthermore, stagefright support in avcodec needs a series of
> magic incantations and version-specific stuff, such that
> using it actually provides downsides compared just using the actual
> Android frameworks properly, in that it is a lot more work and confusion
> to get it even running. It also leads to a lot of misinformation, like
> these sorts of comments (in [1]) that are absolutely incorrect.

+1 for removal (but I'm not an user of this backend).

Matthieu

[...]
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel