Re: [FFmpeg-devel] [mov] Bail when invalid sample data is present.

[Michael Niedermayer]

On Fri, Aug 25, 2017 at 11:59:51AM -0700, Dale Curtis wrote:
> On Fri, Aug 25, 2017 at 5:43 AM, Michael Niedermayer  > wrote:
> 
> >
> > This patch breaks:
> > http://samples.ffmpeg.org/mov/mp4/discont-frag.mp4
> >
> >
> Hmm, indeed it does. The reason is that we read the sample count from the
> stsz box and then read the trun box. I don't think this block of code has
> ever been correct in that case:
> 
> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavformat/mov.c;hb=HEAD#
> l4287
> 
> It shifts all the ctts entries incorrectly and even did so prior to my
> patch. I've uploaded a new version of my fix which simply deletes this
> block of code. It passes all the fate test cases and those we have in
> Chrome. Let me know if fails any of your private test cases.
> 
> - dale

>  mov.c |   25 +++--
>  1 file changed, 3 insertions(+), 22 deletions(-)
> 526e37d02ef1cc4ab1eed7d4f330ecc2b4bb5e8e  sample_count_fix_v3.patch
> From 049f885ee972b0efb6dcbf456025e56dd627b8b9 Mon Sep 17 00:00:00 2001
> From: Dale Curtis 
> Date: Mon, 31 Jul 2017 13:44:22 -0700
> Subject: [PATCH] [mov] Bail when invalid sample data is present.
> 
> ctts data in ffmpeg relies on the index entries array to be 1:1
> with samples... yet sc->sample_count can be read directly from
> the 'stsz' box and index entries are only generated if a chunk
> count has been read from 'stco' box.
> 
> Ensure that if sc->sample_count > 0, sc->chunk_count is too as
> a basic sanity check. Additionally we need to check that after
> the index is built we have the right number of entries, so we
> also check in mov_read_trun() that sc->sample_count ==
> st->nb_index_entries.
> ---
>  libavformat/mov.c | 25 +++--
>  1 file changed, 3 insertions(+), 22 deletions(-)

This changes the printed duration start time and bitrate for
MAV_0034.3G2
see
https://trac.ffmpeg.org/ticket/2757

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Into a blind darkness they enter who follow after the Ignorance,
they as if into a greater darkness enter who devote themselves
to the Knowledge alone. -- Isha Upanishad


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

Re: [FFmpeg-devel] [PATCH]lavc/put_bits: Remove usage of BITSTREAM_WRITER_LE.

[Ivan Kalvachev]

On 8/24/17, Carl Eugen Hoyos  wrote:
> 2017-08-23 0:56 GMT+02:00 Ivan Kalvachev :
>> On 8/22/17, Ronald S. Bultje  wrote:
>>> Hi,
>>>
>>> On Mon, Aug 21, 2017 at 11:16 AM, Carl Eugen Hoyos 
>>> wrote:
>>>
 Hi!

 Attached patch tries to slightly simplify and clean up the usage of
 put_bits* in libavcodec: put_bits_le() functions exist for the
 little-endian G.726 encoder, so the define makes less sense now.

 Fate passes here, please review, Carl Eugen
>>>
>>> I have to agree with Paul here, I can't say I'm a big fan of this...
>>
>> People,
>> As developers you are required
>> not only to give ultimate final verdicts,
>> but also give (nice technical) reasoning for them.
>>
>> Here is my list of pro and cons:
>>
>> - If it ain't broken, don't change it.
>
> No objection here - on the contrary, I wish this argument
> would count here more often...

Well, this too could be taken to an extreme.

>> + Bytesteam already uses explicit _le/be and it looks good.
>>
>> + Makes the code more clear. It is obvious that the given encoder
>> writes BE stream. Something that could easily be missed with the
>> single define.
>
>> - The type of bitstream however is not really important for the codec
>> working. Aka, there is no confusing, because no codec writes BE and LE
>> at the same time.(yet)
>
> Not at the same time but in the same encoder file (G.726).

It's at the same time...
since the endian-ness is decided at runtime.

There are two codecs g726le and g726, they execute same
code, with just few different conditions.

>> + Removes messy defines that obfuscate put_bits code, by separating
>> the big and little ending code.
>
>> - Duplicates put_bits.h code. It would probably make reworking harder,
>> as changes have to be synced in 2 places.
>
> I don't think this is correct (and not what the diffstats show afair) but
> it doesn't matter: I was under the impression this patch was a
> requirement after a previous commit, I am not particularly keen
> on it, see above.

Oh, there is already put_bits_le() that is always present
and put_bits() that could be le/be depending on the define.

Yeh, that needs a cleanup.

However it seems that the second g726 codecs is added by you
and that the introduction of put_bits_le duplication/unwinding
is also done by you, isn't it?

Maybe there is still more elegant way to do all that,
though I can't think of one now.

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

[FFmpeg-devel] [PATCH] avcodec/snowenc: fix setting motion_est option

[James Almer]

Remove usage of FF_MPV_COMMON_OPTS, and set SnowContext.motion_est directly.
Based on code from svq1enc.c

Signed-off-by: James Almer 
---
 libavcodec/snow.h| 3 ++-
 libavcodec/snowenc.c | 9 +
 2 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/libavcodec/snow.h b/libavcodec/snow.h
index f7ed1f82e7..41a3bef4de 100644
--- a/libavcodec/snow.h
+++ b/libavcodec/snow.h
@@ -32,10 +32,11 @@
 #include "rangecoder.h"
 #include "mathops.h"
 
-#define FF_MPV_OFFSET(x) (offsetof(MpegEncContext, x) + offsetof(SnowContext, 
m))
 #include "mpegvideo.h"
 #include "h264qpel.h"
 
+#define FF_ME_ITER 3
+
 #define MID_STATE 128
 
 #define MAX_PLANES 4
diff --git a/libavcodec/snowenc.c b/libavcodec/snowenc.c
index ca55914d9e..1cd7915cc3 100644
--- a/libavcodec/snowenc.c
+++ b/libavcodec/snowenc.c
@@ -33,8 +33,6 @@
 #include "mpegvideo.h"
 #include "h263.h"
 
-#define FF_ME_ITER 50
-
 static av_cold int encode_init(AVCodecContext *avctx)
 {
 SnowContext *s = avctx->priv_data;
@@ -1919,8 +1917,11 @@ static av_cold int encode_end(AVCodecContext *avctx)
 #define OFFSET(x) offsetof(SnowContext, x)
 #define VE AV_OPT_FLAG_VIDEO_PARAM | AV_OPT_FLAG_ENCODING_PARAM
 static const AVOption options[] = {
-FF_MPV_COMMON_OPTS
-{ "iter",   NULL, 0, AV_OPT_TYPE_CONST, { .i64 = FF_ME_ITER }, 0, 
0, FF_MPV_OPT_FLAGS, "motion_est" },
+{"motion_est", "motion estimation algorithm", OFFSET(motion_est), 
AV_OPT_TYPE_INT, {.i64 = FF_ME_EPZS }, FF_ME_ZERO, FF_ME_ITER, VE, "motion_est" 
},
+{ "zero", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = FF_ME_ZERO }, 0, 0, VE, 
"motion_est" },
+{ "epzs", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = FF_ME_EPZS }, 0, 0, VE, 
"motion_est" },
+{ "xone", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = FF_ME_XONE }, 0, 0, VE, 
"motion_est" },
+{ "iter", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = FF_ME_ITER }, 0, 0, VE, 
"motion_est" },
 { "memc_only",  "Only do ME/MC (I frames -> ref, P frame -> ME+MC).",  
 OFFSET(memc_only), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VE },
 { "no_bitstream",   "Skip final bitstream writeout.",
OFFSET(no_bitstream), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VE },
 { "intra_penalty",  "Penalty for intra blocks in block decission",  
OFFSET(intra_penalty), AV_OPT_TYPE_INT, { .i64 = 0 }, 0, INT_MAX, VE },
-- 
2.13.3

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

Re: [FFmpeg-devel] [PATCH] Use NULL_IF_CONFIG_SMALL for AVOption tables.

[Michael Niedermayer]

On Fri, Aug 25, 2017 at 04:20:28PM -0700, Dale Curtis wrote:
> Saves ~12kb of binary size and seems like a good use of
> CONFIG_SMALL. I've only converted some of the largest
> tables in this patch, there's way more to do if this is a
> reasonable direction.

[...]

> -{"dump_separator", "set information dump field separator", 
> OFFSET(dump_separator), AV_OPT_TYPE_STRING, {.str = ", "}, CHAR_MIN, 
> CHAR_MAX, D|E},
[...]
> +{"dump_separator", NULL_IF_CONFIG_SMALL("set information dump field 
> separator"), OFFSET(dump_separator), AV_OPT_TYPE_STRING, {.str = "), "}, 
> CHAR_MIN, CHAR_MAX, D|E},

the default value changes in this

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

It is dangerous to be right in matters on which the established authorities
are wrong. -- 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] Properly store sampling rate for FLAC in mp4

[Michael Niedermayer]

On Fri, Aug 25, 2017 at 01:25:23PM +0200, Jean-Yves Avenard wrote:
> From 9baa7166fa96ed6beac9146c7e3b4dcf425a67d0 Mon Sep 17 00:00:00 2001
> From: Jean-Yves Avenard 
> Date: Fri, 25 Aug 2017 13:11:28 +0200
> Subject: [PATCH] Properly store sampling rate for FLAC in mp4
> 
> Fixes ticket #6609
> 
> Signed-off-by: Jean-Yves Avenard 
> ---
>  libavformat/movenc.c | 28 +---
>  1 file changed, 25 insertions(+), 3 deletions(-)
> 
> diff --git a/libavformat/movenc.c b/libavformat/movenc.c
> index 10b959ad02..aa4a9c962a 100644
> --- a/libavformat/movenc.c
> +++ b/libavformat/movenc.c
> @@ -1028,9 +1028,31 @@ static int mov_write_audio_tag(AVFormatContext
> *s, AVIOContext *pb, MOVMuxContex
>  avio_wb16(pb, 0); /* packet size (= 0) */

This patch is corrupted by line wraps / newlines

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Take away the freedom of one citizen and you will be jailed, take away
the freedom of all citizens and you will be congratulated by your peers
in Parliament.


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/hls: Fix DoS due to infinite loop

[Michael Niedermayer]

On Sat, Aug 26, 2017 at 06:49:00AM +0800, Steven Liu wrote:
> 2017-08-25 18:14 GMT+08:00 Michael Niedermayer :
> > Fixes: loop.m3u
> >
> > The default max iteration count of 1000 is arbitrary and ideas for a better 
> > solution are welcome
> >
> > Found-by: Xiaohei and Wangchu from Alibaba Security Team
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavformat/hls.c | 7 +++
> >  1 file changed, 7 insertions(+)
> >
> > diff --git a/libavformat/hls.c b/libavformat/hls.c
> > index 01731bd36b..0995345bbf 100644
> > --- a/libavformat/hls.c
> > +++ b/libavformat/hls.c
> > @@ -205,6 +205,7 @@ typedef struct HLSContext {
> >  AVDictionary *avio_opts;
> >  int strict_std_compliance;
> >  char *allowed_extensions;
> > +int max_reload;
> >  } HLSContext;
> >
> >  static int read_chomp_line(AVIOContext *s, char *buf, int maxlen)
> > @@ -1263,6 +1264,7 @@ static int read_data(void *opaque, uint8_t *buf, int 
> > buf_size)
> >  HLSContext *c = v->parent->priv_data;
> >  int ret, i;
> >  int just_opened = 0;
> > +int reload_count = 0;
> >
> >  restart:
> >  if (!v->needed)
> > @@ -1294,6 +1296,9 @@ restart:
> >  reload_interval = default_reload_interval(v);
> >
> >  reload:
> > +reload_count++;
> > +if (reload_count > c->max_reload)
> > +return AVERROR_EOF;
> >  if (!v->finished &&
> >  av_gettime_relative() - v->last_load_time >= reload_interval) {
> >  if ((ret = parse_playlist(c, v->url, v, NULL)) < 0) {
> > @@ -2150,6 +2155,8 @@ static const AVOption hls_options[] = {
> >  OFFSET(allowed_extensions), AV_OPT_TYPE_STRING,
> >  {.str = 
> > "3gp,aac,avi,flac,mkv,m3u8,m4a,m4s,m4v,mpg,mov,mp2,mp3,mp4,mpeg,mpegts,ogg,ogv,oga,ts,vob,wav"},
> >  INT_MIN, INT_MAX, FLAGS},
> > +{"max_reload", "Maximum number of times a insufficient list is 
> > attempted to be reloaded",
> > +OFFSET(max_reload), AV_OPT_TYPE_INT, {.i64 = 1000}, 0, INT_MAX, 
> > FLAGS},
> >  {NULL}
> >  };
> >
> > --
> > 2.14.1
> >
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> 
> should be ok,  and the demuxer option need a document.

posted patch with docs

thx

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

Rewriting code that is poorly written but fully understood is good.
Rewriting code that one doesnt understand is a sign that one is less smart
then the original author, trying to rewrite it will not make it better.


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

[FFmpeg-devel] [PATCH] avformat/hls: Fix DoS due to infinite loop

[Michael Niedermayer]

Fixes: loop.m3u

The default max iteration count of 1000 is arbitrary and ideas for a better 
solution are welcome

Found-by: Xiaohei and Wangchu from Alibaba Security Team
Signed-off-by: Michael Niedermayer 
---
 doc/demuxers.texi | 18 ++
 libavformat/hls.c |  7 +++
 2 files changed, 25 insertions(+)

diff --git a/doc/demuxers.texi b/doc/demuxers.texi
index 29a23d48b2..ba4bb51177 100644
--- a/doc/demuxers.texi
+++ b/doc/demuxers.texi
@@ -300,6 +300,24 @@ used to end the output video at the length of the shortest 
input file,
 which in this case is @file{input.mp4} as the GIF in this example loops
 infinitely.
 
+@section hls
+
+HLS demuxer
+
+It accepts the following options:
+
+@table @option
+@item live_start_index
+segment index to start live streams at (negative values are from the end).
+
+@item allowed_extensions
+',' seperated list of file extensions that hls is allowed to access.
+
+@item max_reload
+Maximum number of times a insufficient list is attempted to be reloaded.
+Default value is 1000.
+@end table
+
 @section image2
 
 Image file demuxer.
diff --git a/libavformat/hls.c b/libavformat/hls.c
index 01731bd36b..0995345bbf 100644
--- a/libavformat/hls.c
+++ b/libavformat/hls.c
@@ -205,6 +205,7 @@ typedef struct HLSContext {
 AVDictionary *avio_opts;
 int strict_std_compliance;
 char *allowed_extensions;
+int max_reload;
 } HLSContext;
 
 static int read_chomp_line(AVIOContext *s, char *buf, int maxlen)
@@ -1263,6 +1264,7 @@ static int read_data(void *opaque, uint8_t *buf, int 
buf_size)
 HLSContext *c = v->parent->priv_data;
 int ret, i;
 int just_opened = 0;
+int reload_count = 0;
 
 restart:
 if (!v->needed)
@@ -1294,6 +1296,9 @@ restart:
 reload_interval = default_reload_interval(v);
 
 reload:
+reload_count++;
+if (reload_count > c->max_reload)
+return AVERROR_EOF;
 if (!v->finished &&
 av_gettime_relative() - v->last_load_time >= reload_interval) {
 if ((ret = parse_playlist(c, v->url, v, NULL)) < 0) {
@@ -2150,6 +2155,8 @@ static const AVOption hls_options[] = {
 OFFSET(allowed_extensions), AV_OPT_TYPE_STRING,
 {.str = 
"3gp,aac,avi,flac,mkv,m3u8,m4a,m4s,m4v,mpg,mov,mp2,mp3,mp4,mpeg,mpegts,ogg,ogv,oga,ts,vob,wav"},
 INT_MIN, INT_MAX, FLAGS},
+{"max_reload", "Maximum number of times a insufficient list is attempted 
to be reloaded",
+OFFSET(max_reload), AV_OPT_TYPE_INT, {.i64 = 1000}, 0, INT_MAX, FLAGS},
 {NULL}
 };
 
-- 
2.14.1

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

Re: [FFmpeg-devel] [PATCH] ffmpeg options: Enable trailing ? for map_channel

[Kv Pham]

Thanks a lot Michael. (and for spotting the avfree I missed)

Le 25 août 2017 11:44 PM, "Michael Niedermayer"  a
écrit :

On Thu, Aug 24, 2017 at 11:10:49PM +0200, pkv.stream wrote:
> Thanks a lot Martin !!! all sorted out thanks to your kind help.
> I had run fate previously but obviously missed something; so re-run
> and it's ok.
>
> I created two tests per your advice testing for a third channel in a
> stereo file and then in a 2.1 file.
> Instead of CRC, I've used MD5 because the extant mapchan fate tests
> were using it.
>
> Updated patch in attachment.
>
> Michael: would that be OK or do you see other changes to make ?
>
>
>

>  doc/ffmpeg.texi |   13 +++-
>  ffmpeg_opt.c|   21
+---
>  tests/fate/ffmpeg.mak   |8 +++
>  tests/ref/fate/mapchan-2ch-extract-ch0-ch2-trailing |1
>  tests/ref/fate/mapchan-3ch-extract-ch0-ch2-trailing |1
>  5 files changed, 40 insertions(+), 4 deletions(-)
> 1d35047c00f25dc1391a541eb704a03a9c9198de  0001-ffmpeg-options-Enable-
trailing-for-map_channel.patch
> From 5c3b0fed39b713b19ed53b5704b1fce63b2742ad Mon Sep 17 00:00:00 2001
> From: pkviet 
> Date: Tue, 22 Aug 2017 11:30:45 +0200
> Subject: [PATCH] ffmpeg options: Enable trailing ? for map_channel
>
> The -map option allows for a trailing ? so that an error is not thrown if
> the input stream does not exist.
> This capability is extended to the map_channel option.
> This allows a ffmpeg command not to break if an input channel does not
> exist, which can be of use (for instance, scripts processing audio
> channels with sources having unset number of audio channels).

added missing av_free()
applied

thanks

[...]

--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data

___
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] avformat/hls: Fix DoS due to infinite loop

[Steven Liu]

2017-08-25 18:14 GMT+08:00 Michael Niedermayer :
> Fixes: loop.m3u
>
> The default max iteration count of 1000 is arbitrary and ideas for a better 
> solution are welcome
>
> Found-by: Xiaohei and Wangchu from Alibaba Security Team
> Signed-off-by: Michael Niedermayer 
> ---
>  libavformat/hls.c | 7 +++
>  1 file changed, 7 insertions(+)
>
> diff --git a/libavformat/hls.c b/libavformat/hls.c
> index 01731bd36b..0995345bbf 100644
> --- a/libavformat/hls.c
> +++ b/libavformat/hls.c
> @@ -205,6 +205,7 @@ typedef struct HLSContext {
>  AVDictionary *avio_opts;
>  int strict_std_compliance;
>  char *allowed_extensions;
> +int max_reload;
>  } HLSContext;
>
>  static int read_chomp_line(AVIOContext *s, char *buf, int maxlen)
> @@ -1263,6 +1264,7 @@ static int read_data(void *opaque, uint8_t *buf, int 
> buf_size)
>  HLSContext *c = v->parent->priv_data;
>  int ret, i;
>  int just_opened = 0;
> +int reload_count = 0;
>
>  restart:
>  if (!v->needed)
> @@ -1294,6 +1296,9 @@ restart:
>  reload_interval = default_reload_interval(v);
>
>  reload:
> +reload_count++;
> +if (reload_count > c->max_reload)
> +return AVERROR_EOF;
>  if (!v->finished &&
>  av_gettime_relative() - v->last_load_time >= reload_interval) {
>  if ((ret = parse_playlist(c, v->url, v, NULL)) < 0) {
> @@ -2150,6 +2155,8 @@ static const AVOption hls_options[] = {
>  OFFSET(allowed_extensions), AV_OPT_TYPE_STRING,
>  {.str = 
> "3gp,aac,avi,flac,mkv,m3u8,m4a,m4s,m4v,mpg,mov,mp2,mp3,mp4,mpeg,mpegts,ogg,ogv,oga,ts,vob,wav"},
>  INT_MIN, INT_MAX, FLAGS},
> +{"max_reload", "Maximum number of times a insufficient list is attempted 
> to be reloaded",
> +OFFSET(max_reload), AV_OPT_TYPE_INT, {.i64 = 1000}, 0, INT_MAX, 
> FLAGS},
>  {NULL}
>  };
>
> --
> 2.14.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


should be ok,  and the demuxer option need a document.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] ffmpeg options: Enable trailing ? for map_channel

[Michael Niedermayer]

On Thu, Aug 24, 2017 at 11:10:49PM +0200, pkv.stream wrote:
> Thanks a lot Martin !!! all sorted out thanks to your kind help.
> I had run fate previously but obviously missed something; so re-run
> and it's ok.
> 
> I created two tests per your advice testing for a third channel in a
> stereo file and then in a 2.1 file.
> Instead of CRC, I've used MD5 because the extant mapchan fate tests
> were using it.
> 
> Updated patch in attachment.
> 
> Michael: would that be OK or do you see other changes to make ?
> 
> 
> 

>  doc/ffmpeg.texi |   13 +++-
>  ffmpeg_opt.c|   21 
> +---
>  tests/fate/ffmpeg.mak   |8 +++
>  tests/ref/fate/mapchan-2ch-extract-ch0-ch2-trailing |1 
>  tests/ref/fate/mapchan-3ch-extract-ch0-ch2-trailing |1 
>  5 files changed, 40 insertions(+), 4 deletions(-)
> 1d35047c00f25dc1391a541eb704a03a9c9198de  
> 0001-ffmpeg-options-Enable-trailing-for-map_channel.patch
> From 5c3b0fed39b713b19ed53b5704b1fce63b2742ad Mon Sep 17 00:00:00 2001
> From: pkviet 
> Date: Tue, 22 Aug 2017 11:30:45 +0200
> Subject: [PATCH] ffmpeg options: Enable trailing ? for map_channel
> 
> The -map option allows for a trailing ? so that an error is not thrown if
> the input stream does not exist.
> This capability is extended to the map_channel option.
> This allows a ffmpeg command not to break if an input channel does not
> exist, which can be of use (for instance, scripts processing audio
> channels with sources having unset number of audio channels).

added missing av_free()
applied

thanks

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data


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

Re: [FFmpeg-devel] [mov] Bail when invalid sample data is present.

[Dale Curtis]

On Fri, Aug 25, 2017 at 5:43 AM, Michael Niedermayer  wrote:

>
> This patch breaks:
> http://samples.ffmpeg.org/mov/mp4/discont-frag.mp4
>
>
Hmm, indeed it does. The reason is that we read the sample count from the
stsz box and then read the trun box. I don't think this block of code has
ever been correct in that case:

http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavformat/mov.c;hb=HEAD#
l4287

It shifts all the ctts entries incorrectly and even did so prior to my
patch. I've uploaded a new version of my fix which simply deletes this
block of code. It passes all the fate test cases and those we have in
Chrome. Let me know if fails any of your private test cases.

- dale
From 049f885ee972b0efb6dcbf456025e56dd627b8b9 Mon Sep 17 00:00:00 2001
From: Dale Curtis 
Date: Mon, 31 Jul 2017 13:44:22 -0700
Subject: [PATCH] [mov] Bail when invalid sample data is present.

ctts data in ffmpeg relies on the index entries array to be 1:1
with samples... yet sc->sample_count can be read directly from
the 'stsz' box and index entries are only generated if a chunk
count has been read from 'stco' box.

Ensure that if sc->sample_count > 0, sc->chunk_count is too as
a basic sanity check. Additionally we need to check that after
the index is built we have the right number of entries, so we
also check in mov_read_trun() that sc->sample_count ==
st->nb_index_entries.
---
 libavformat/mov.c | 25 +++--
 1 file changed, 3 insertions(+), 22 deletions(-)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index 876f48d912..f8bcba4cd1 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -3755,8 +3755,9 @@ static int mov_read_trak(MOVContext *c, AVIOContext *pb, MOVAtom atom)
 c->trak_index = -1;
 
 /* sanity checks */
-if (sc->chunk_count && (!sc->stts_count || !sc->stsc_count ||
-(!sc->sample_size && !sc->sample_count))) {
+if ((sc->chunk_count && (!sc->stts_count || !sc->stsc_count ||
+(!sc->sample_size && !sc->sample_count))) ||
+(!sc->chunk_count && sc->sample_count)) {
 av_log(c->fc, AV_LOG_ERROR, "stream %d, missing mandatory atoms, broken header\n",
st->index);
 return 0;
@@ -4284,26 +4285,6 @@ static int mov_read_trun(MOVContext *c, AVIOContext *pb, MOVAtom atom)
 entries = avio_rb32(pb);
 av_log(c->fc, AV_LOG_TRACE, "flags 0x%x entries %u\n", flags, entries);
 
-/* Always assume the presence of composition time offsets.
- * Without this assumption, for instance, we cannot deal with a track in fragmented movies that meet the following.
- *  1) in the initial movie, there are no samples.
- *  2) in the first movie fragment, there is only one sample without composition time offset.
- *  3) in the subsequent movie fragments, there are samples with composition time offset. */
-if (!sc->ctts_count && sc->sample_count)
-{
-/* Complement ctts table if moov atom doesn't have ctts atom. */
-ctts_data = av_fast_realloc(NULL, >ctts_allocated_size, sizeof(*sc->ctts_data) * sc->sample_count);
-if (!ctts_data)
-return AVERROR(ENOMEM);
-/* Don't use a count greater than 1 here since it will leave a gap in
- * the ctts index which the code below relies on being sequential. */
-sc->ctts_data = ctts_data;
-for (i = 0; i < sc->sample_count; i++) {
-sc->ctts_data[sc->ctts_count].count = 1;
-sc->ctts_data[sc->ctts_count].duration = 0;
-sc->ctts_count++;
-}
-}
 if ((uint64_t)entries+sc->ctts_count >= UINT_MAX/sizeof(*sc->ctts_data))
 return AVERROR_INVALIDDATA;
 if (flags & MOV_TRUN_DATA_OFFSET)data_offset= avio_rb32(pb);
-- 
2.14.1.342.g6490525c54-goog

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

Re: [FFmpeg-devel] [PATCHv6 1/4] Move lavd/v4l2-common.* to lavc

[Paul B Mahol]

On 8/25/17, Jorge Ramirez  wrote:
> On 08/25/2017 02:50 PM, Paul B Mahol wrote:
>> On 8/25/17, Jorge Ramirez-Ortiz  wrote:
>>> From: Alexis Ballier 
>>>
>>> In preparation to support the integation of the V4L2 API for encoding
>>> and decoding, move v4l2 related files to libavcodec.
>>>
>>> v4l2-common was renamed to v4l2_fmt for clarity (v4l2-common.h belongs
>>> to the V4L2 API)
>>>
>>> Signed-off-by: Alexis Ballier 
>>> Reviewed-by: Jorge Ramirez-Ortiz 
>>> ---
>>>   configure |   6 ++-
>>>   libavcodec/Makefile   |   1 +
>>>   libavcodec/v4l2_fmt.c | 105
>>> ++
>>>   libavcodec/v4l2_fmt.h |  57 +
>>>   libavdevice/Makefile  |   6 +--
>>>   libavdevice/v4l2-common.c | 105
>>> --
>>>   libavdevice/v4l2-common.h |  61 ---
>>>   libavdevice/v4l2.c|  40 --
>>>   libavdevice/v4l2enc.c |  12 +-
>>>   9 files changed, 206 insertions(+), 187 deletions(-)
>>>   create mode 100644 libavcodec/v4l2_fmt.c
>>>   create mode 100644 libavcodec/v4l2_fmt.h
>>>   delete mode 100644 libavdevice/v4l2-common.c
>>>   delete mode 100644 libavdevice/v4l2-common.h
>>>
>> Does lavd stuff now depends on lavc?
>
> um yes, v4l2 in/out devices (lavd) do use a common file now present in
> lavc (ie: v4l2_fmt.c).
>
> see libavcodec/Makefile:
>
> OBJS-$(CONFIG_V4L2)+= v4l2_fmt.o
> OBJS-$(CONFIG_V4L2_M2M)+= v4l2_m2m.o v4l2_buffers.o
>
> also note that the common file doesn't depend on the new V4L2_M2M
> decoders/encoders being available (only on V4L2)

Than relevant devices in lavd should be marked to depend on lavc.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCHv6 1/4] Move lavd/v4l2-common.* to lavc

[Jorge Ramirez]

On 08/25/2017 02:50 PM, Paul B Mahol wrote:

On 8/25/17, Jorge Ramirez-Ortiz  wrote:

From: Alexis Ballier 

In preparation to support the integation of the V4L2 API for encoding
and decoding, move v4l2 related files to libavcodec.

v4l2-common was renamed to v4l2_fmt for clarity (v4l2-common.h belongs
to the V4L2 API)

Signed-off-by: Alexis Ballier 
Reviewed-by: Jorge Ramirez-Ortiz 
---
  configure |   6 ++-
  libavcodec/Makefile   |   1 +
  libavcodec/v4l2_fmt.c | 105
++
  libavcodec/v4l2_fmt.h |  57 +
  libavdevice/Makefile  |   6 +--
  libavdevice/v4l2-common.c | 105
--
  libavdevice/v4l2-common.h |  61 ---
  libavdevice/v4l2.c|  40 --
  libavdevice/v4l2enc.c |  12 +-
  9 files changed, 206 insertions(+), 187 deletions(-)
  create mode 100644 libavcodec/v4l2_fmt.c
  create mode 100644 libavcodec/v4l2_fmt.h
  delete mode 100644 libavdevice/v4l2-common.c
  delete mode 100644 libavdevice/v4l2-common.h


Does lavd stuff now depends on lavc?


um yes, v4l2 in/out devices (lavd) do use a common file now present in 
lavc (ie: v4l2_fmt.c).


see libavcodec/Makefile:

OBJS-$(CONFIG_V4L2)+= v4l2_fmt.o
OBJS-$(CONFIG_V4L2_M2M)+= v4l2_m2m.o v4l2_buffers.o

also note that the common file doesn't depend on the new V4L2_M2M 
decoders/encoders being available (only on V4L2)





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

Re: [FFmpeg-devel] [PATCH] avcodec/dvbsubdec: Check for duplicate regions in dvbsub_parse_page_segment()

[Michael Niedermayer]

On Tue, Aug 22, 2017 at 03:56:41AM +0200, Michael Niedermayer wrote:
> Fixes: OOM
> Fixes: 3051/clusterfuzz-testcase-minimized-5745818336231424
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/dvbsubdec.c | 9 +
>  1 file changed, 9 insertions(+)

applied


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

Many things microsoft did are stupid, but not doing something just because
microsoft did it is even more stupid. If everything ms did were stupid they
would be bankrupt already.


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

[FFmpeg-devel] [PATCH] libavformat/mov: Always use av_realloc() for AVCodecParameters.extradata

[John Rummell]

Chromium uses tcmalloc which doesn't like mixing calls to posix_memalign()
and realloc(). This change updates mov.c to only use av_realloc() when
allocating memory for AVCodecParameters.extradata.
---
 libavformat/mov.c | 21 -
 1 file changed, 12 insertions(+), 9 deletions(-)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index 876f48d912..6e226c8ce4 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -1652,9 +1652,10 @@ static int mov_read_wave(MOVContext *c, AVIOContext
*pb, MOVAtom atom)
 atom.size += 8;
 } else if (!st->codecpar->extradata_size) {
 #define ALAC_EXTRADATA_SIZE 36
-st->codecpar->extradata = av_mallocz(ALAC_EXTRADATA_SIZE +
AV_INPUT_BUFFER_PADDING_SIZE);
-if (!st->codecpar->extradata)
-return AVERROR(ENOMEM);
+uint64_t size = ALAC_EXTRADATA_SIZE +
AV_INPUT_BUFFER_PADDING_SIZE;
+if ((ret = av_reallocp(>codecpar->extradata, size)) <
0)
+return ret;
+memset(st->codecpar->extradata, 0, size);
 st->codecpar->extradata_size = ALAC_EXTRADATA_SIZE;
 AV_WB32(st->codecpar->extradata, ALAC_EXTRADATA_SIZE);
 AV_WB32(st->codecpar->extradata + 4,
MKTAG('a','l','a','c'));
@@ -2054,6 +2055,8 @@ static int mov_rewrite_dvd_sub_extradata(AVStream *st)
 char buf[256] = {0};
 uint8_t *src = st->codecpar->extradata;
 int i;
+uint64_t size;
+int ret;

 if (st->codecpar->extradata_size != 64)
 return 0;
@@ -2075,9 +2078,9 @@ static int mov_rewrite_dvd_sub_extradata(AVStream *st)

 av_freep(>codecpar->extradata);
 st->codecpar->extradata_size = 0;
-st->codecpar->extradata = av_mallocz(strlen(buf) +
AV_INPUT_BUFFER_PADDING_SIZE);
-if (!st->codecpar->extradata)
-return AVERROR(ENOMEM);
+size = strlen(buf) + AV_INPUT_BUFFER_PADDING_SIZE;
+if ((ret = av_reallocp(>codecpar->extradata, size)) < 0)
+return ret;
 st->codecpar->extradata_size = strlen(buf);
 memcpy(st->codecpar->extradata, buf, st->codecpar->extradata_size);

@@ -2392,9 +2395,9 @@ static int mov_read_stsd(MOVContext *c, AVIOContext
*pb, MOVAtom atom)
 av_freep(>codecpar->extradata);
 st->codecpar->extradata_size = sc->extradata_size[0];
 if (sc->extradata_size[0]) {
-st->codecpar->extradata = av_mallocz(sc->extradata_size[0] +
AV_INPUT_BUFFER_PADDING_SIZE);
-if (!st->codecpar->extradata)
-return AVERROR(ENOMEM);
+uint64_t size = sc->extradata_size[0] +
AV_INPUT_BUFFER_PADDING_SIZE;
+if ((ret = av_reallocp(>codecpar->extradata, size)) < 0)
+return ret;
 memcpy(st->codecpar->extradata, sc->extradata[0],
sc->extradata_size[0]);
 }

-- 
2.14.1.342.g6490525c54-goog
From 1e34019d625d4b33a1767af70bc6c7e2c6b42a7f Mon Sep 17 00:00:00 2001
From: John Rummell 
Date: Wed, 21 Jun 2017 14:39:20 -0700
Subject: [PATCH] libavformat/mov: Always use av_realloc() for
 AVCodecParameters.extradata

Chromium uses tcmalloc which doesn't like mixing calls to posix_memalign()
and realloc(). This change updates mov.c to only use av_realloc() when
allocating memory for AVCodecParameters.extradata.
---
 libavformat/mov.c | 21 -
 1 file changed, 12 insertions(+), 9 deletions(-)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index 876f48d912..6e226c8ce4 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -1652,9 +1652,10 @@ static int mov_read_wave(MOVContext *c, AVIOContext *pb, MOVAtom atom)
 atom.size += 8;
 } else if (!st->codecpar->extradata_size) {
 #define ALAC_EXTRADATA_SIZE 36
-st->codecpar->extradata = av_mallocz(ALAC_EXTRADATA_SIZE + AV_INPUT_BUFFER_PADDING_SIZE);
-if (!st->codecpar->extradata)
-return AVERROR(ENOMEM);
+uint64_t size = ALAC_EXTRADATA_SIZE + AV_INPUT_BUFFER_PADDING_SIZE;
+if ((ret = av_reallocp(>codecpar->extradata, size)) < 0)
+return ret;
+memset(st->codecpar->extradata, 0, size);
 st->codecpar->extradata_size = ALAC_EXTRADATA_SIZE;
 AV_WB32(st->codecpar->extradata, ALAC_EXTRADATA_SIZE);
 AV_WB32(st->codecpar->extradata + 4, MKTAG('a','l','a','c'));
@@ -2054,6 +2055,8 @@ static int mov_rewrite_dvd_sub_extradata(AVStream *st)
 char buf[256] = {0};
 uint8_t *src = st->codecpar->extradata;
 int i;
+uint64_t size;
+int ret;
 
 if (st->codecpar->extradata_size != 64)
 return 0;
@@ -2075,9 +2078,9 @@ static int mov_rewrite_dvd_sub_extradata(AVStream *st)
 
 av_freep(>codecpar->extradata);
 st->codecpar->extradata_size = 0;
-st->codecpar->extradata = av_mallocz(strlen(buf) + AV_INPUT_BUFFER_PADDING_SIZE);
-if (!st->codecpar->extradata)
-return AVERROR(ENOMEM);
+size = 

Re: [FFmpeg-devel] [mov] Fix trampling of ctts during seeks when sidx support is enabled.

[Michael Niedermayer]

On Thu, Aug 24, 2017 at 05:06:16PM -0700, Dale Curtis wrote:
> On Thu, Aug 24, 2017 at 2:27 AM, Michael Niedermayer  > wrote:
> 
> >
> > can the insertions be done in groups instead of one at a time ?
> > so that it basically merges 2 lists (O(n)) instead of inserting
> > one at a time O(n^2)
> > ?
> > This would significantly improve the worst case while not needing
> > to change the data structures
> > (of course iam not against changing the data structures if someone wants
> > to do the work)
> >
> 
> Unfortunately this is hard / impossible to do if I understand what you're
> asking for correctly. Here's my response to the same suggestion from Rodger
> above: "We could speculatively move all entries based on the first insert
> and total entries count, but their are several conditionals in
> av_add_index_entry() which may cause a bail out and such failure would be
> unrecoverable (maybe painfully?) if we moved everything ahead of time."

hmm

maybe i misunderstand but assuming we insert a block of dummy blank
entries (without breaking monotonicity) and keep a pointer to that
block

then add entries with a av_add_index_entry()
and in case of failure remove the blank entries

this would result in the same as now and seems relativly simple
it would not need memmove and in general would not need a log n
search if each falls on the first spot of the block

or am i missing something ?





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

When the tyrant has disposed of foreign enemies by conquest or treaty, and
there is nothing more to fear from them, then he is always stirring up
some war or other, in order that the people may require a leader. -- Plato


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

Re: [FFmpeg-devel] [PATCH] avcodec: make the avcodec_get_chroma_sub_sample deprecation effective

[Michael Niedermayer]

On Fri, Aug 25, 2017 at 12:09:53PM -0300, James Almer wrote:
> ---
>  libavcodec/avcodec.h | 16 
>  libavcodec/version.h |  6 +++---
>  2 files changed, 7 insertions(+), 15 deletions(-)
> 
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index c594993766..65092a 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -5665,22 +5665,14 @@ int av_picture_pad(AVPicture *dst, const AVPicture 
> *src, int height, int width,
>   * @{
>   */
>  
> +#if FF_API_GETCHROMA
>  /**
> - * Utility function to access log2_chroma_w log2_chroma_h from
> - * the pixel format AVPixFmtDescriptor.
> - *
> - * This function asserts that pix_fmt is valid. See 
> av_pix_fmt_get_chroma_sub_sample
> - * for one that returns a failure code and continues in case of invalid
> - * pix_fmts.
> - *
> - * @param[in]  pix_fmt the pixel format
> - * @param[out] h_shift store log2_chroma_w
> - * @param[out] v_shift store log2_chroma_h
> - *
> - * @see av_pix_fmt_get_chroma_sub_sample
> + * @deprecated Use av_pix_fmt_get_chroma_sub_sample
>   */
>  
> +attribute_deprecated
>  void avcodec_get_chroma_sub_sample(enum AVPixelFormat pix_fmt, int *h_shift, 
> int *v_shift);
> +#endif

As avcodec_get_chroma_sub_sample() is inherently safe while
av_pix_fmt_get_chroma_sub_sample() is not

please make sure every use of av_pix_fmt_get_chroma_sub_sample() has
its return code checked. Either through code review or through adding
an explicit check.
avcodec_get_chroma_sub_sample() cannot fail so it didnt need that.
av_pix_fmt_get_chroma_sub_sample() can fail so its needed to check it
for failure.

Given above, i would favor the API that internally checks and doesnt
require an external check.

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Dictatorship naturally arises out of democracy, and the most aggravated
form of tyranny and slavery out of the most extreme liberty. -- Plato


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

Re: [FFmpeg-devel] [PATCH 6/6] avformat/hls: Fix DoS due to infinite loop

[Michael Niedermayer]

On Fri, Aug 25, 2017 at 01:03:35PM +0200, wm4 wrote:
> On Fri, 25 Aug 2017 11:59:54 +0200
> Michael Niedermayer  wrote:
> 
> > On Fri, Aug 25, 2017 at 10:08:23AM +0200, wm4 wrote:
> > > On Fri, 25 Aug 2017 01:15:32 +0200
> > > Michael Niedermayer  wrote:
> > >   
> > > > Fixes: loop.m3u
> > > > 
> > > > The max iteration count of 1 is arbitrary and ideas for a better 
> > > > solution are welcome
> > > > 
> > > > Found-by: Xiaohei and Wangchu from Alibaba Security Team
> > > > Signed-off-by: Michael Niedermayer 
> > > > ---
> > > >  libavformat/hls.c | 4 
> > > >  1 file changed, 4 insertions(+)
> > > > 
> > > > diff --git a/libavformat/hls.c b/libavformat/hls.c
> > > > index 01731bd36b..26f4ebd965 100644
> > > > --- a/libavformat/hls.c
> > > > +++ b/libavformat/hls.c
> > > > @@ -1263,6 +1263,7 @@ static int read_data(void *opaque, uint8_t *buf, 
> > > > int buf_size)
> > > >  HLSContext *c = v->parent->priv_data;
> > > >  int ret, i;
> > > >  int just_opened = 0;
> > > > +int reload_count = 0;
> > > >  
> > > >  restart:
> > > >  if (!v->needed)
> > > > @@ -1294,6 +1295,9 @@ restart:
> > > >  reload_interval = default_reload_interval(v);
> > > >  
> > > >  reload:
> > > > +reload_count++;
> > > > +if (reload_count > 1)
> > > > +return AVERROR_EOF;
> > > >  if (!v->finished &&
> > > >  av_gettime_relative() - v->last_load_time >= 
> > > > reload_interval) {
> > > >  if ((ret = parse_playlist(c, v->url, v, NULL)) < 0) {  
> > > 
> > > Why 1000?  
> > 
> > Please read the commit message at the top of the mail you reply to,
> > that is explained in it
> > 
> > 
> > > 
> > > This patch is unnecessary. The interrupt callback can break out of this
> > > loop anyway on user request. Or is this patch again intended for
> > > transcode servers with hilariously insecure amateurish configuration,
> > > like most of these patches seem to be?  
> > 
> > Do you object to this issue being fixed ?
> 

> I content that there is an issue. It was found by a fuzzer, and has no
> security implications.

I belive you should CC the security researchers who found
the issue.
Also to repeat, my oppinion is that this is a security issue and
requires a fix.


> 
> > In which case i will of course respect your veto and leave the issue
> > open.
> > Otherwise i will here note that i disagree with your oppinion.
> > 
> > And will resubmit a patch with the changes requested by the maintainer
> 
> A user option is even worse, because it creates API for a thing that
> doesn't matter.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

"Nothing to hide" only works if the folks in power share the values of
you and everyone you know entirely and always will -- Tom Scott



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

Re: [FFmpeg-devel] [PATCH] opus_pvq_search.asm: Handle zero vector input differently.

[Rostislav Pehlivanov]

On 25 August 2017 at 16:38, Ivan Kalvachev  wrote:

> Instead of returning all zeroes as result and Syy=1.0,
> place all the K pulses in the first element y[0]
> and return Syy=K*K.
>
> This is how the original opus function handles the case.
> This is how the existing pvq_search_c handles the case.
>
> Also, according to Rostislav, the encoded all zeros vector
> would be decoded as such y[0]=K vector, before dequantization.
> So it is better to do that explicitly and calculate
> the proper gain in the encoder.
> --
>
> I must point out that ppp_pvq_search_c() does generate
> y[0]=-K vector, not +K.
> This is because FFSIGN(0.0) returns -1.
> I do consider this bug, however I'm not quite sure what
> is the best way to handle it.
>
>
I don't think its a bug, celt_cwrsi() also has the same behavior (and
doesn't use FFSIGN) so FF_SIGN returning -1 in the encoder matches what
celt_cwrsi() would see.
Could you send a V2 which outputs a -K in y[0] instead?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Offer paid job to maintain ffserver: seeking interested developers

[James Almer]

On 8/25/2017 12:43 PM, wm4 wrote:
> On Fri, 25 Aug 2017 12:09:24 -0300
> Rodrigo Severo  wrote:
> 
>> Hi,
>>
>>
>> I'm resending this email, now with a proper subject line, as per Ivan
>> Kalvachev suggestion.
>>
>> My company does some video recording and internal streaming.
>>
>> Our current solution (on Ubuntu 16.10 servers) uses ffmpeg and
>> ffserver (versions 3.0.7). It works great.
>>
>> Unfortunately, on Ubuntu 17.04, it stopped working. I believe the
>> problems I'm facing are related to the deprecation of ffserver. On
>> Ubuntu 17.04 the ffmpeg/ffserver available is version 3.2.4.
>>
>> I would like to know if there is any developer(s) interested in
>> assuming a paid job to maintain ffserver making it compatible with
>> present and future ffmpeg versions (most important part) and
>> eventually implementing new features.
>>
>> Are any of you interested?
>>
>> Please contact me privately if interested so we can further detail
>> what should be done.
>>
> 
> You should add "re-add ffserver" to the job description, because it's
> going to be removed soon.

Removed then re added to the tree doesn't change anything as far as the
job offer goes. He wants someone to develop ffserver or something like it.

If someone fixes the internal API usage in ffserver right now, then
that's ok and it will not be removed during the next bump.
If nobody fixes the internal API usage on time, then that's ok as well.
ffserver will be removed, then it or a brand new program that properly
uses the public API can be (re)added at a latter date.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Offer paid job to maintain ffserver: seeking interested developers

[wm4]

On Fri, 25 Aug 2017 12:09:24 -0300
Rodrigo Severo  wrote:

> Hi,
> 
> 
> I'm resending this email, now with a proper subject line, as per Ivan
> Kalvachev suggestion.
> 
> My company does some video recording and internal streaming.
> 
> Our current solution (on Ubuntu 16.10 servers) uses ffmpeg and
> ffserver (versions 3.0.7). It works great.
> 
> Unfortunately, on Ubuntu 17.04, it stopped working. I believe the
> problems I'm facing are related to the deprecation of ffserver. On
> Ubuntu 17.04 the ffmpeg/ffserver available is version 3.2.4.
> 
> I would like to know if there is any developer(s) interested in
> assuming a paid job to maintain ffserver making it compatible with
> present and future ffmpeg versions (most important part) and
> eventually implementing new features.
> 
> Are any of you interested?
> 
> Please contact me privately if interested so we can further detail
> what should be done.
> 

You should add "re-add ffserver" to the job description, because it's
going to be removed soon.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] opus_pvq_search.asm: Handle zero vector input differently.

[Ivan Kalvachev]

Instead of returning all zeroes as result and Syy=1.0,
place all the K pulses in the first element y[0]
and return Syy=K*K.

This is how the original opus function handles the case.
This is how the existing pvq_search_c handles the case.

Also, according to Rostislav, the encoded all zeros vector
would be decoded as such y[0]=K vector, before dequantization.
So it is better to do that explicitly and calculate
the proper gain in the encoder.
--

I must point out that ppp_pvq_search_c() does generate
y[0]=-K vector, not +K.
This is because FFSIGN(0.0) returns -1.
I do consider this bug, however I'm not quite sure what
is the best way to handle it.

1. Fix localy
#undef FFSIGN
#define FFSIGN(a) ((a) >= 0 ? 1 : -1)

2. Use different name for that macro
#define OPUS_SIGN(a) ...

3. Fix by special case in ppp_pvq_search_c():
if( !(res > 0.0) ) { y[0]=K; for(i=1;i
Date: Fri, 25 Aug 2017 17:14:28 +0300
Subject: [PATCH] opus_pvq_search.asm: Handle zero vector input differently.

Instead of returning all zeroes as result and Syy=1.0,
place all the K pulses in the first element y[0]
and return Syy=K*K.

This is how the original opus function handles the case.
This is how the existing pvq_search_c handles the case.

Also, according to Rostislav, the encoded all zeros vector
would be decoded as such y[0]=K vector, before dequantization.
So it is better to do that explicitly and calculate
the proper gain in the encoder.

Signed-off-by: Ivan Kalvachev 
---
 libavcodec/x86/opus_pvq_search.asm | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/libavcodec/x86/opus_pvq_search.asm b/libavcodec/x86/opus_pvq_search.asm
index 5c1e6d6174..adf3e6f87c 100644
--- a/libavcodec/x86/opus_pvq_search.asm
+++ b/libavcodec/x86/opus_pvq_search.asm
@@ -252,9 +252,9 @@ align 16
 
 xorps  m0, m0
 comissxm0, xm1  ;
+cvtsi2ss  xm0, dword Kd ; m0 = K
 jz   %%zero_input   ; if (Sx==0) goto zero_input
 
-cvtsi2ss  xm0, dword Kd ; m0 = K
 %if USE_APPROXIMATION == 1
 rcpss xm1, xm1  ; m1 = approx(1/Sx)
 mulss xm0, xm1  ; m0 = K*(1/Sx)
@@ -355,7 +355,8 @@ align 16
 RET
 
 align 16
-%%zero_input:
+%%zero_input:   ; expected m0 = K
+mulss xm6, xm0, xm0 ; Syy_norm = K*K
 lea   r4d, [Nd - mmsize]
 xorps  m0, m0
 %%zero_loop:
@@ -363,7 +364,7 @@ align 16
 sub   r4d, mmsize
 jnc  %%zero_loop
 
-movaps m6, [const_float_1]
+mov   [outYq], Kd
 jmp  %%return
 %endmacro
 
-- 
2.14.1

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

Re: [FFmpeg-devel] [PATCHv6 4/4] libavcodec: v4l2: add support for v4l2 mem2mem codecs

[wm4]

That looks generally OK. Is there any chance a hwaccel approach would
be possible instead? If I've learned anything about hardware decoding,
then that hwaccel is vastly superior to vendor-implemented full stream
decoders.

I don't think I like the attempt of sharing the v4l helper functions
between libavdevice and libavcodec, but I can't tell how much it helps.

On Fri, 25 Aug 2017 13:22:48 +0200
Jorge Ramirez-Ortiz  wrote:


> +#define WIDTH(__ctx, __fmt) \
> +(V4L2_TYPE_IS_MULTIPLANAR((__ctx)->type) ? __fmt.fmt.pix_mp.width : 
> __fmt.fmt.pix.width)
> +
> +#define HEIGHT(__ctx, __fmt) \
> +(V4L2_TYPE_IS_MULTIPLANAR((__ctx)->type) ? __fmt.fmt.pix_mp.height : 
> __fmt.fmt.pix.height)

These names are a bit generic. Also, identifiers starting with __ are
always implementation reserved (i.e. using them undefined behavior).
You're forgetting to quote the __fmt macro parameter too.

> +static inline void set_pts(V4L2Buffer *out, int64_t pts)
> +{
> +if (pts == AV_NOPTS_VALUE) {
> +/* invalid timestamp: not sure how to handle this case */
> +out->timestamp.tv_sec  = 0;
> +out->timestamp.tv_usec = 0;
> +} else {
> +AVRational v4l2_timebase = { 1, 100 };
> +int64_t v4l2_pts = av_rescale_q(pts, out->context->time_base, 
> v4l2_timebase);
> +out->timestamp.tv_sec  = v4l2_pts / INT64_C(100);
> +out->timestamp.tv_usec = v4l2_pts % INT64_C(100);
> +}
> +}

Why does it require a fixed timebase? A decoder shouldn't even look at
the timestamps, it should only pass them though. Also, not using DTS
will make it a nightmare to support containers like avi.

I suspect the decoder tries to "fix" timestamps, or maybe even does
something particularly bad like reordering frames by timestamps. This
is NOT something that should be in a kernel API.

(FFmpeg native decoders _and_ hwaccels pass through both PTS and DTS,
and don't touch their values.)

> +static void free_v4l2buf_cb(void *opaque, uint8_t *unused)
> +{
> +V4L2Buffer* avbuf = opaque;
> +
> +if (V4L2BUF_IN_DRIVER == avbuf->status)
> +return;
> +
> +if (V4L2_TYPE_IS_OUTPUT(avbuf->context->type))
> +avbuf->status = V4L2BUF_AVAILABLE;
> +else
> +   avbuf->context->ops.enqueue(avbuf);
> +}

> +static inline int buffer_ops_v4l2buf_to_bufref(V4L2Buffer *in, int plane, 
> AVBufferRef **buf)
> +{
> +if (plane >= in->num_planes)
> +return AVERROR(EINVAL);
> +
> +/* even though most encoders return 0 in data_offset encoding vp8 does 
> require this value*/
> +*buf = av_buffer_create((char *)in->plane_info[plane].mm_addr + 
> in->planes[plane].data_offset,
> +in->plane_info[plane].lengths, free_v4l2buf_cb, 
> in, 0);
> +if (!*buf)
> +return AVERROR(ENOMEM);
> +
> +in->status = V4L2BUF_RET_USER;
> +
> +return 0;
> +}

This looks like it would trigger massive UB if you keep a frame after
the decoder is closed.  This should not happen, an AVBufferRef must
stay valid forever. At least it looks like it assumes that the decoder
is somehow still around, without unreffing it, which hints towards that
this is done incorrectly.

> +static int buffer_ops_v4l2buf_to_avframe(AVFrame *frame, V4L2Buffer *avbuf)
> +{
> +int i, ret;
> +
> +av_frame_unref(frame);
> +
> +/* 1. get references to the actual data */
> +for (i = 0; i < avbuf->num_planes; i++) {
> +ret = avbuf->ops.buf_to_bufref(avbuf, i, >buf[i]);
> +if (ret)
> +return ret;
> +
> +frame->linesize[i] = avbuf->bytesperline[i];
> +frame->data[i] = frame->buf[i]->data;
> +}
> +
> +/* 1.1 fixup special cases */
> +switch (avbuf->context->av_pix_fmt) {
> +case AV_PIX_FMT_NV12:
> +if (avbuf->num_planes > 1)
> +break;
> +frame->linesize[1] = avbuf->bytesperline[0];
> +frame->data[1] = frame->buf[0]->data + avbuf->bytesperline[0] * 
> avbuf->context->format.fmt.pix_mp.height;
> +break;
> +default:
> +break;
> +}
> +
> +/* 2. get frame information */
> +frame->key_frame = !!(avbuf->buf.flags & V4L2_BUF_FLAG_KEYFRAME);
> +frame->format = avbuf->context->av_pix_fmt;
> +
> +/* these values are updated also during re-init in process_video_event */
> +frame->height = avbuf->context->height;
> +frame->width = avbuf->context->width;
> +frame->pts = get_pts(avbuf);
> +
> +/* 3. report errors upstream */
> +if (avbuf->buf.flags & V4L2_BUF_FLAG_ERROR) {
> +av_log(avbuf->context->log_ctx, AV_LOG_ERROR, "%s: driver decode 
> error\n", avbuf->context->name);
> +frame->decode_error_flags |= FF_DECODE_ERROR_INVALID_BITSTREAM;
> +}
> +
> +return 0;
> +}

This function seems to lack setting typically required metadata like
colorspace.

> +static int buffer_ops_v4l2buf_to_avpkt(AVPacket *pkt, V4L2Buffer *avbuf)
> +{
> +int ret;
> +
> +

Re: [FFmpeg-devel] [PATCH] avcodec: make the avcodec_get_chroma_sub_sample deprecation effective

[James Almer]

On 8/25/2017 12:16 PM, Ronald S. Bultje wrote:
> Hi,
> 
> On Fri, Aug 25, 2017 at 11:09 AM, James Almer  wrote:
> 
>> ---
>>  libavcodec/avcodec.h | 16 
>>  libavcodec/version.h |  6 +++---
>>  2 files changed, 7 insertions(+), 15 deletions(-)
> 
> 
> Thanks :)
> 
> Ronald

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

Re: [FFmpeg-devel] (no subject)

[Rodrigo Severo]

2017-08-25 11:58 GMT-03:00 Ivan Kalvachev :
> On 8/22/17, Rodrigo Severo  wrote:
>>
>> I would like to know if there is any developer(s) interested in
>> assuming a paid job to maintain ffserver making it compatible with
>> present and future ffmpeg versions (most important part) and
>> eventually implementing new features.
>
>
> Would you please resend your offer with properly filled email subject.
> Something like "offer paid job to maintain ffserver".
>
> It's quite easy to miss email with "no subject", especially with all
> the spam around.
>
> I also would like ffserver to be maintained.
> Unfortunately streaming, format handling etc
> are not my area of expertise.


Sure. You are right.


Thanks for the suggestion,

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

Re: [FFmpeg-devel] [PATCH] avcodec: make the avcodec_get_chroma_sub_sample deprecation effective

[Ronald S. Bultje]

Hi,

On Fri, Aug 25, 2017 at 11:09 AM, James Almer  wrote:

> ---
>  libavcodec/avcodec.h | 16 
>  libavcodec/version.h |  6 +++---
>  2 files changed, 7 insertions(+), 15 deletions(-)


Thanks :)

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

[FFmpeg-devel] Offer paid job to maintain ffserver: seeking interested developers

[Rodrigo Severo]

Hi,


I'm resending this email, now with a proper subject line, as per Ivan
Kalvachev suggestion.

My company does some video recording and internal streaming.

Our current solution (on Ubuntu 16.10 servers) uses ffmpeg and
ffserver (versions 3.0.7). It works great.

Unfortunately, on Ubuntu 17.04, it stopped working. I believe the
problems I'm facing are related to the deprecation of ffserver. On
Ubuntu 17.04 the ffmpeg/ffserver available is version 3.2.4.

I would like to know if there is any developer(s) interested in
assuming a paid job to maintain ffserver making it compatible with
present and future ffmpeg versions (most important part) and
eventually implementing new features.

Are any of you interested?

Please contact me privately if interested so we can further detail
what should be done.


Regards,

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

Re: [FFmpeg-devel] [PATCH] avcodec/imgconvert: remove deprecation guards for a function that's not declared as such

[James Almer]

On 8/25/2017 11:39 AM, Ronald S. Bultje wrote:
> Hi,
> 
> On Fri, Aug 25, 2017 at 10:04 AM, James Almer  wrote:
> 
>> On 8/25/2017 8:10 AM, Ronald S. Bultje wrote:
>>> Hi,
>>>
>>> On Thu, Aug 24, 2017 at 7:43 PM, James Almer  wrote:
>>>
 Signed-off-by: James Almer 
 ---
 The deprecation seems to have been imported from libav but never made
 effective.
>>>
>>>
>>> Hm, but do we really want this function? Shouldn't all users be ported to
>>> the function this wraps?
>>
>> I don't know. The Doxy even acknowledges there's an alternative but
>> mentions its use case is apparently different, which is probably why
>> the deprecation wasn't made effective.
>>
> 
> We should all acknowledge fully that there is a use case for
> memcpy_inverted(source, destination, size), yet libc does not define it. I
> don't know why. It's silly. I feel libc is being racist.
> 
> Silliness aside, let's not have multiple APIs that do the same thing.
> 
> If the function really needs to go, then the deprecated attribute should
>> be added to the header. And from that point the ~2 years deprecation
>> period starts.
> 
> 
> Sure, operationally I don't really care, as long as the end product is that
> it goes away.

Ok, patch dropped and a new one sent that effectively deprecates the
function.

> 
> Fork nastiness aside, I feel that one thing Libav does have a much better
> handle on than us is API cleanliness.
> 
> 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

[FFmpeg-devel] [PATCH] avcodec: make the avcodec_get_chroma_sub_sample deprecation effective

[James Almer]

---
 libavcodec/avcodec.h | 16 
 libavcodec/version.h |  6 +++---
 2 files changed, 7 insertions(+), 15 deletions(-)

diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index c594993766..65092a 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -5665,22 +5665,14 @@ int av_picture_pad(AVPicture *dst, const AVPicture 
*src, int height, int width,
  * @{
  */
 
+#if FF_API_GETCHROMA
 /**
- * Utility function to access log2_chroma_w log2_chroma_h from
- * the pixel format AVPixFmtDescriptor.
- *
- * This function asserts that pix_fmt is valid. See 
av_pix_fmt_get_chroma_sub_sample
- * for one that returns a failure code and continues in case of invalid
- * pix_fmts.
- *
- * @param[in]  pix_fmt the pixel format
- * @param[out] h_shift store log2_chroma_w
- * @param[out] v_shift store log2_chroma_h
- *
- * @see av_pix_fmt_get_chroma_sub_sample
+ * @deprecated Use av_pix_fmt_get_chroma_sub_sample
  */
 
+attribute_deprecated
 void avcodec_get_chroma_sub_sample(enum AVPixelFormat pix_fmt, int *h_shift, 
int *v_shift);
+#endif
 
 /**
  * Return a value representing the fourCC code associated to the
diff --git a/libavcodec/version.h b/libavcodec/version.h
index 7473000579..48e57bd86b 100644
--- a/libavcodec/version.h
+++ b/libavcodec/version.h
@@ -60,9 +60,6 @@
 #ifndef FF_API_AVCODEC_RESAMPLE
 #define FF_API_AVCODEC_RESAMPLE  FF_API_AUDIO_CONVERT
 #endif
-#ifndef FF_API_GETCHROMA
-#define FF_API_GETCHROMA (LIBAVCODEC_VERSION_MAJOR < 58)
-#endif
 #ifndef FF_API_MISSING_SAMPLE
 #define FF_API_MISSING_SAMPLE(LIBAVCODEC_VERSION_MAJOR < 58)
 #endif
@@ -238,6 +235,9 @@
 #ifndef FF_API_TAG_STRING
 #define FF_API_TAG_STRING(LIBAVCODEC_VERSION_MAJOR < 59)
 #endif
+#ifndef FF_API_GETCHROMA
+#define FF_API_GETCHROMA (LIBAVCODEC_VERSION_MAJOR < 59)
+#endif
 
 
 #endif /* AVCODEC_VERSION_H */
-- 
2.13.3

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

Re: [FFmpeg-devel] (no subject)

[Ivan Kalvachev]

On 8/22/17, Rodrigo Severo  wrote:
> Hi,
>
>
> My company does some video recording and internal streaming.
>
> Our current solution (on Ubuntu 16.10 servers) uses ffmpeg and
> ffserver (versions 3.0.7). It works great.
>
> Unfortunately, on Ubuntu 17.04, it stopped working. I believe the
> problems I'm facing are related to the deprecation of ffserver. On
> Ubuntu 17.04 the ffmpeg/ffserver available is version 3.2.4.
>
> I would like to know if there is any developer(s) interested in
> assuming a paid job to maintain ffserver making it compatible with
> present and future ffmpeg versions (most important part) and
> eventually implementing new features.
>
> Are any of you interested?
>
> Please contact me privately if interested so we can further detail
> what should be done.
>
>
> Regards,
>
> Rodrigo Severo

Would you please resend your offer with properly filled email subject.
Something like "offer paid job to maintain ffserver".

It's quite easy to miss email with "no subject", especially with all
the spam around.

I also would like ffserver to be maintained.
Unfortunately streaming, format handling etc
are not my area of expertise.

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

Re: [FFmpeg-devel] [PATCH] avcodec/imgconvert: remove deprecation guards for a function that's not declared as such

[Ronald S. Bultje]

Hi,

On Fri, Aug 25, 2017 at 10:04 AM, James Almer  wrote:

> On 8/25/2017 8:10 AM, Ronald S. Bultje wrote:
> > Hi,
> >
> > On Thu, Aug 24, 2017 at 7:43 PM, James Almer  wrote:
> >
> >> Signed-off-by: James Almer 
> >> ---
> >> The deprecation seems to have been imported from libav but never made
> >> effective.
> >
> >
> > Hm, but do we really want this function? Shouldn't all users be ported to
> > the function this wraps?
>
> I don't know. The Doxy even acknowledges there's an alternative but
> mentions its use case is apparently different, which is probably why
> the deprecation wasn't made effective.
>

We should all acknowledge fully that there is a use case for
memcpy_inverted(source, destination, size), yet libc does not define it. I
don't know why. It's silly. I feel libc is being racist.

Silliness aside, let's not have multiple APIs that do the same thing.

If the function really needs to go, then the deprecated attribute should
> be added to the header. And from that point the ~2 years deprecation
> period starts.


Sure, operationally I don't really care, as long as the end product is that
it goes away.

Fork nastiness aside, I feel that one thing Libav does have a much better
handle on than us is API cleanliness.

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

Re: [FFmpeg-devel] [PATCH] avcodec/imgconvert: remove deprecation guards for a function that's not declared as such

[James Almer]

On 8/25/2017 8:10 AM, Ronald S. Bultje wrote:
> Hi,
> 
> On Thu, Aug 24, 2017 at 7:43 PM, James Almer  wrote:
> 
>> Signed-off-by: James Almer 
>> ---
>> The deprecation seems to have been imported from libav but never made
>> effective.
> 
> 
> Hm, but do we really want this function? Shouldn't all users be ported to
> the function this wraps?

I don't know. The Doxy even acknowledges there's an alternative but
mentions its use case is apparently different, which is probably why
the deprecation wasn't made effective.

If the function really needs to go, then the deprecated attribute should
be added to the header. And from that point the ~2 years deprecation
period starts.

> 
> 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 v2] mjpeg: Add support for ICC side data

[Derek Buitenhuis]

On 8/25/2017 1:37 AM, Michael Niedermayer wrote:
> should be ok

Pushed, with an extra check added for duplicate sequence numbers.

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

Re: [FFmpeg-devel] [PATCHv6 1/4] Move lavd/v4l2-common.* to lavc

[Paul B Mahol]

On 8/25/17, Jorge Ramirez-Ortiz  wrote:
> From: Alexis Ballier 
>
> In preparation to support the integation of the V4L2 API for encoding
> and decoding, move v4l2 related files to libavcodec.
>
> v4l2-common was renamed to v4l2_fmt for clarity (v4l2-common.h belongs
> to the V4L2 API)
>
> Signed-off-by: Alexis Ballier 
> Reviewed-by: Jorge Ramirez-Ortiz 
> ---
>  configure |   6 ++-
>  libavcodec/Makefile   |   1 +
>  libavcodec/v4l2_fmt.c | 105
> ++
>  libavcodec/v4l2_fmt.h |  57 +
>  libavdevice/Makefile  |   6 +--
>  libavdevice/v4l2-common.c | 105
> --
>  libavdevice/v4l2-common.h |  61 ---
>  libavdevice/v4l2.c|  40 --
>  libavdevice/v4l2enc.c |  12 +-
>  9 files changed, 206 insertions(+), 187 deletions(-)
>  create mode 100644 libavcodec/v4l2_fmt.c
>  create mode 100644 libavcodec/v4l2_fmt.h
>  delete mode 100644 libavdevice/v4l2-common.c
>  delete mode 100644 libavdevice/v4l2-common.h
>

Does lavd stuff now depends on lavc?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [mov] Bail when invalid sample data is present.

[Michael Niedermayer]

On Mon, Jul 31, 2017 at 04:42:20PM -0700, Dale Curtis wrote:
> I'm not convinced my original patch catches all cases. So here's an updated
> one which explicitly verifies the contract.
> 
> - dale
> 
> On Mon, Jul 31, 2017 at 2:40 PM, Dale Curtis 
> wrote:
> 
> > [mov] Bail when invalid sample data is present.
> >
> > ctts data in ffmpeg relies on the index entries array to be 1:1
> > with samples... yet sc->sample_count can be read directly from
> > the 'stsz' box and index entries are only generated if a chunk
> > count has been read from 'stco' box.
> >
> > Ensure that if sc->sample_count > 0, sc->chunk_count is too.
> >
> > This should be applied on top of the ctts fixes in my previous patch.
> >
> >

>  mov.c |8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> b9e9d387abfa321d17f117833f0b4a6f04ab6feb  sample_count_fix_v2.patch
> From 51571dd294350f2ef367fd9391ed4c1e94387947 Mon Sep 17 00:00:00 2001
> From: Dale Curtis 
> Date: Mon, 31 Jul 2017 13:44:22 -0700
> Subject: [PATCH] [mov] Bail when invalid sample data is present.
> 
> ctts data in ffmpeg relies on the index entries array to be 1:1
> with samples... yet sc->sample_count can be read directly from
> the 'stsz' box and index entries are only generated if a chunk
> count has been read from 'stco' box.
> 
> Ensure that if sc->sample_count > 0, sc->chunk_count is too as
> a basic sanity check. Additionally we need to check that after
> the index is built we have the right number of entries, so we
> also check in mov_read_trun() that sc->sample_count ==
> st->nb_index_entries.
> ---
>  libavformat/mov.c | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)

This patch breaks:
http://samples.ffmpeg.org/mov/mp4/discont-frag.mp4

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In a rich man's house there is no place to spit but his face.
-- Diogenes of Sinope


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

[FFmpeg-devel] [PATCHv6 2/4] libavcodec: v4l2: add pack_flags to the conversion tables

[Jorge Ramirez-Ortiz]

From: Alexis Ballier 

Extend the mapping function to use the v4l2 conversion tables.

Reviewed-by: Jorge Ramirez 
Tested-by: Jorge Ramirez 
---
 libavcodec/v4l2_fmt.c | 63 ++-
 libavcodec/v4l2_fmt.h | 17 +-
 libavdevice/v4l2.c|  2 +-
 libavdevice/v4l2enc.c |  2 +-
 4 files changed, 45 insertions(+), 39 deletions(-)

diff --git a/libavcodec/v4l2_fmt.c b/libavcodec/v4l2_fmt.c
index 322f595..855cc64 100644
--- a/libavcodec/v4l2_fmt.c
+++ b/libavcodec/v4l2_fmt.c
@@ -19,49 +19,49 @@
 #include "v4l2_fmt.h"
 
 const struct v4l_fmt_map avpriv_v4l_fmt_conversion_table[] = {
-//ff_fmt  codec_id  v4l2_fmt
-{ AV_PIX_FMT_YUV420P, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_YUV420  },
-{ AV_PIX_FMT_YUV420P, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_YVU420  },
-{ AV_PIX_FMT_YUV422P, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_YUV422P },
-{ AV_PIX_FMT_YUYV422, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_YUYV},
-{ AV_PIX_FMT_UYVY422, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_UYVY},
-{ AV_PIX_FMT_YUV411P, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_YUV411P },
-{ AV_PIX_FMT_YUV410P, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_YUV410  },
-{ AV_PIX_FMT_YUV410P, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_YVU410  },
-{ AV_PIX_FMT_RGB555LE,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_RGB555  },
-{ AV_PIX_FMT_RGB555BE,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_RGB555X },
-{ AV_PIX_FMT_RGB565LE,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_RGB565  },
-{ AV_PIX_FMT_RGB565BE,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_RGB565X },
-{ AV_PIX_FMT_BGR24,   AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_BGR24   },
-{ AV_PIX_FMT_RGB24,   AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_RGB24   },
-{ AV_PIX_FMT_BGR0,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_BGR32   },
-{ AV_PIX_FMT_0RGB,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_RGB32   },
-{ AV_PIX_FMT_GRAY8,   AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_GREY},
+/* ff_fmt  codec_id  v4l2_fmt  
pack_flags */
+{ AV_PIX_FMT_YUV420P, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_YUV420 , 
FF_V4L_PACK_AVPACKET },
+{ AV_PIX_FMT_YUV420P, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_YVU420 , 
FF_V4L_PACK_AVPACKET },
+{ AV_PIX_FMT_YUV422P, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_YUV422P, 
FF_V4L_PACK_AVPACKET },
+{ AV_PIX_FMT_YUYV422, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_YUYV   , 
FF_V4L_PACK_AVPACKET | FF_V4L_PACK_AVFRAME },
+{ AV_PIX_FMT_UYVY422, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_UYVY   , 
FF_V4L_PACK_AVPACKET | FF_V4L_PACK_AVFRAME },
+{ AV_PIX_FMT_YUV411P, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_YUV411P, 
FF_V4L_PACK_AVPACKET },
+{ AV_PIX_FMT_YUV410P, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_YUV410 , 
FF_V4L_PACK_AVPACKET },
+{ AV_PIX_FMT_YUV410P, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_YVU410 , 
FF_V4L_PACK_AVPACKET },
+{ AV_PIX_FMT_RGB555LE,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_RGB555 , 
FF_V4L_PACK_AVPACKET | FF_V4L_PACK_AVFRAME },
+{ AV_PIX_FMT_RGB555BE,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_RGB555X, 
FF_V4L_PACK_AVPACKET | FF_V4L_PACK_AVFRAME },
+{ AV_PIX_FMT_RGB565LE,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_RGB565 , 
FF_V4L_PACK_AVPACKET | FF_V4L_PACK_AVFRAME },
+{ AV_PIX_FMT_RGB565BE,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_RGB565X, 
FF_V4L_PACK_AVPACKET | FF_V4L_PACK_AVFRAME },
+{ AV_PIX_FMT_BGR24,   AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_BGR24  , 
FF_V4L_PACK_AVPACKET | FF_V4L_PACK_AVFRAME },
+{ AV_PIX_FMT_RGB24,   AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_RGB24  , 
FF_V4L_PACK_AVPACKET | FF_V4L_PACK_AVFRAME },
+{ AV_PIX_FMT_BGR0,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_BGR32  , 
FF_V4L_PACK_AVPACKET | FF_V4L_PACK_AVFRAME },
+{ AV_PIX_FMT_0RGB,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_RGB32  , 
FF_V4L_PACK_AVPACKET | FF_V4L_PACK_AVFRAME },
+{ AV_PIX_FMT_GRAY8,   AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_GREY   , 
FF_V4L_PACK_AVPACKET | FF_V4L_PACK_AVFRAME },
 #ifdef V4L2_PIX_FMT_Y16
-{ AV_PIX_FMT_GRAY16LE,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_Y16 },
+{ AV_PIX_FMT_GRAY16LE,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_Y16, 
FF_V4L_PACK_AVPACKET | FF_V4L_PACK_AVFRAME },
 #endif
-{ AV_PIX_FMT_NV12,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_NV12},
-{ AV_PIX_FMT_NONE,AV_CODEC_ID_MJPEG,V4L2_PIX_FMT_MJPEG   },
-{ AV_PIX_FMT_NONE,AV_CODEC_ID_MJPEG,V4L2_PIX_FMT_JPEG},
+{ AV_PIX_FMT_NV12,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_NV12   , 
FF_V4L_PACK_AVPACKET },
+{ AV_PIX_FMT_NONE,AV_CODEC_ID_MJPEG,V4L2_PIX_FMT_MJPEG  , 
FF_V4L_PACK_AVPACKET },
+{ AV_PIX_FMT_NONE,AV_CODEC_ID_MJPEG,V4L2_PIX_FMT_JPEG   , 
FF_V4L_PACK_AVPACKET },
 #ifdef V4L2_PIX_FMT_H264
-{ AV_PIX_FMT_NONE,AV_CODEC_ID_H264, V4L2_PIX_FMT_H264},
+{ AV_PIX_FMT_NONE,AV_CODEC_ID_H264, V4L2_PIX_FMT_H264   , 
FF_V4L_PACK_AVPACKET 

[FFmpeg-devel] [PATCH] Properly store sampling rate for FLAC in mp4

[Jean-Yves Avenard]

From 9baa7166fa96ed6beac9146c7e3b4dcf425a67d0 Mon Sep 17 00:00:00 2001
From: Jean-Yves Avenard 
Date: Fri, 25 Aug 2017 13:11:28 +0200
Subject: [PATCH] Properly store sampling rate for FLAC in mp4

Fixes ticket #6609

Signed-off-by: Jean-Yves Avenard 
---
 libavformat/movenc.c | 28 +---
 1 file changed, 25 insertions(+), 3 deletions(-)

diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 10b959ad02..aa4a9c962a 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -1028,9 +1028,31 @@ static int mov_write_audio_tag(AVFormatContext
*s, AVIOContext *pb, MOVMuxContex
 avio_wb16(pb, 0); /* packet size (= 0) */
 if (track->par->codec_id == AV_CODEC_ID_OPUS)
 avio_wb16(pb, 48000);
-else
-avio_wb16(pb, track->par->sample_rate <= UINT16_MAX ?
-  track->par->sample_rate : 0);
+else {
+uint32_t rate;
+if (track->par->codec_id == AV_CODEC_ID_FLAC) {
+/* When the bitstream's native sample rate is greater
+ than the maximum expressible value of 65535 Hz,
+ the samplerate field shall hold the greatest
+ expressible regular division of that rate. I.e.
+ the samplerate field shall hold 48000.0 for
+ native sample rates of 96 and 192 kHz. In the
+ case of unusual sample rates which do not have
+ an expressible regular division, the maximum value
+ of 65535.0 Hz should be used. */
+rate = track->par->sample_rate;
+while (rate > UINT16_MAX && (rate & 1) == 0) {
+rate = rate >> 1;
+}
+if (rate > UINT16_MAX) {
+rate = UINT16_MAX;
+}
+} else {
+rate = track->par->sample_rate <= UINT16_MAX ?
+   track->par->sample_rate : 0;
+}
+avio_wb16(pb, rate);
+}
 avio_wb16(pb, 0); /* Reserved */
 }

-- 
2.11.0 (Apple Git-81)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCHv6 4/4] libavcodec: v4l2: add support for v4l2 mem2mem codecs

[Jorge Ramirez-Ortiz]

This patchset enhances Alexis Ballier's original patch and validates
it using Qualcomm's Venus hardware (driver recently landed upstream
[1]).

This has been tested on Qualcomm's DragonBoard 410c and 820c
Configure/make scripts have been validated on Ubuntu 10.04 and
16.04.

Tested decoders:
   - h264
   - mpeg4
   - vp8
   - vp9
   - hevc

Tested encoders:
- h264
- h263
- mpeg4

Tested transcoding (concurrent encoding/decoding)

Some of the changes introduced:
- v4l2: code cleanup and abstractions added
- v4l2: follow the new encode/decode api.
- v4l2: fix display size for NV12 output pool.
- v4l2: handle EOS.
- v4l2: vp8 and mpeg4 decoding and encoding.
- v4l2: hevc and vp9 support.
- v4l2: generate EOF on dequeue errors.
- v4l2: h264_mp4toannexb filtering.
- v4l2: fixed make install and fate issues.
- v4l2: codecs enabled/disabled depending on pixfmt defined
- v4l2: pass timebase/framerate to the context
- v4l2: runtime decoder reconfiguration.

[1] https://lwn.net/Articles/697956/

Reviewed-by: Jorge Ramirez 
Reviewed-by: Alexis Ballier 
Tested-by: Jorge Ramirez 
---
 Changelog |   1 +
 configure |  30 +-
 libavcodec/Makefile   |  18 +-
 libavcodec/allcodecs.c|   9 +
 libavcodec/v4l2_buffers.c | 741 ++
 libavcodec/v4l2_buffers.h | 259 +++
 libavcodec/v4l2_fmt.c |   9 +-
 libavcodec/v4l2_m2m.c | 428 
 libavcodec/v4l2_m2m.h |  59 
 libavcodec/v4l2_m2m_avcodec.h |  32 ++
 libavcodec/v4l2_m2m_dec.c | 252 ++
 libavcodec/v4l2_m2m_enc.c | 288 
 12 files changed, 2119 insertions(+), 7 deletions(-)
 create mode 100644 libavcodec/v4l2_buffers.c
 create mode 100644 libavcodec/v4l2_buffers.h
 create mode 100644 libavcodec/v4l2_m2m.c
 create mode 100644 libavcodec/v4l2_m2m.h
 create mode 100644 libavcodec/v4l2_m2m_avcodec.h
 create mode 100644 libavcodec/v4l2_m2m_dec.c
 create mode 100644 libavcodec/v4l2_m2m_enc.c

diff --git a/Changelog b/Changelog
index f5dc1da..9156568 100644
--- a/Changelog
+++ b/Changelog
@@ -34,6 +34,7 @@ version :
 - floodfill video filter
 - pseudocolor video filter
 - raw G.726 demuxer, left- and right-justified
+- V4L2 mem2mem HW accelerated codecs support
 
 version 3.3:
 - CrystalHD decoder moved to new decode API
diff --git a/configure b/configure
index e048b02..7a8c0e6 100755
--- a/configure
+++ b/configure
@@ -149,6 +149,7 @@ Component options:
   --disable-pixelutils disable pixel utils in libavutil
 
 Individual component options:
+  --disable-v4l2_m2m   disable V4L2 mem2mem code [autodetect]
   --disable-everything disable all components listed below
   --disable-encoder=NAME   disable encoder NAME
   --enable-encoder=NAMEenable encoder NAME
@@ -1432,6 +1433,7 @@ AVCODEC_COMPONENTS="
 
 AVDEVICE_COMPONENTS="
 indevs
+v4l2_m2m
 outdevs
 "
 AVFILTER_COMPONENTS="
@@ -2271,6 +2273,7 @@ map 'eval ${v}_inline_deps=inline_asm' $ARCH_EXT_LIST_ARM
 loongson2_deps="mips"
 loongson3_deps="mips"
 v4l2_deps_any="linux_videodev2_h sys_videoio_h"
+v4l2_m2m_select="v4l2"
 mipsfpu_deps="mips"
 mipsdsp_deps="mips"
 mipsdspr2_deps="mips"
@@ -2743,6 +2746,8 @@ nvenc_deps="cuda"
 nvenc_deps_any="dlopen LoadLibrary"
 nvenc_encoder_deps="nvenc"
 
+h263_v4l2m2m_decoder_deps="v4l2_m2m h263_v4l2_m2m"
+h263_v4l2m2m_encoder_deps="v4l2_m2m h263_v4l2_m2m"
 h264_crystalhd_decoder_select="crystalhd h264_mp4toannexb_bsf h264_parser"
 h264_cuvid_decoder_deps="cuda cuvid"
 h264_cuvid_decoder_select="h264_mp4toannexb_bsf"
@@ -2761,6 +2766,8 @@ h264_vda_decoder_deps="vda"
 h264_vda_decoder_select="h264_decoder"
 h264_vdpau_decoder_deps="vdpau"
 h264_vdpau_decoder_select="h264_decoder"
+h264_v4l2m2m_decoder_deps="v4l2_m2m h264_v4l2_m2m"
+h264_v4l2m2m_encoder_deps="v4l2_m2m h264_v4l2_m2m"
 hevc_cuvid_decoder_deps="cuda cuvid"
 hevc_cuvid_decoder_select="hevc_mp4toannexb_bsf"
 hevc_mediacodec_decoder_deps="mediacodec"
@@ -2772,12 +2779,15 @@ hevc_qsv_encoder_deps="libmfx"
 hevc_qsv_encoder_select="hevcparse qsvenc"
 hevc_vaapi_encoder_deps="VAEncPictureParameterBufferHEVC"
 hevc_vaapi_encoder_select="vaapi_encode golomb"
+hevc_v4l2m2m_decoder_deps="v4l2_m2m hevc_v4l2_m2m"
+hevc_v4l2m2m_encoder_deps="v4l2_m2m hevc_v4l2_m2m"
 mjpeg_cuvid_decoder_deps="cuda cuvid"
 mjpeg_vaapi_encoder_deps="VAEncPictureParameterBufferJPEG"
 mjpeg_vaapi_encoder_select="vaapi_encode jpegtables"
 mpeg1_cuvid_decoder_deps="cuda cuvid"
 mpeg1_vdpau_decoder_deps="vdpau"
 mpeg1_vdpau_decoder_select="mpeg1video_decoder"
+mpeg1_v4l2m2m_decoder_deps="v4l2_m2m mpeg1_v4l2_m2m"
 

[FFmpeg-devel] [PATCHv6 3/4] libavcodec: v4l2: add codec formats

[Jorge Ramirez-Ortiz]

In addition, enable the multi planar raw formats.

Reviewed-by: Jorge Ramirez 
Tested-by: Jorge Ramirez 
---
 libavcodec/v4l2_fmt.c | 38 +-
 1 file changed, 37 insertions(+), 1 deletion(-)

diff --git a/libavcodec/v4l2_fmt.c b/libavcodec/v4l2_fmt.c
index 855cc64..2cda6b2 100644
--- a/libavcodec/v4l2_fmt.c
+++ b/libavcodec/v4l2_fmt.c
@@ -58,7 +58,43 @@ const struct v4l_fmt_map avpriv_v4l_fmt_conversion_table[] = 
{
 { AV_PIX_FMT_BAYER_GRBG8, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_SGRBG8 , 
FF_V4L_PACK_AVPACKET | FF_V4L_PACK_AVFRAME },
 { AV_PIX_FMT_BAYER_RGGB8, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_SRGGB8 , 
FF_V4L_PACK_AVPACKET | FF_V4L_PACK_AVFRAME },
 #endif
-{ AV_PIX_FMT_NONE,AV_CODEC_ID_NONE, 0},
+#ifdef V4L2_PIX_FMT_NV12M
+{ AV_PIX_FMT_NV12,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_NV12M  , 
FF_V4L_PACK_AVFRAME  },
+#endif
+#ifdef V4L2_PIX_FMT_NV21M
+{ AV_PIX_FMT_NV21,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_NV21M  , 
FF_V4L_PACK_AVFRAME  },
+#endif
+#ifdef V4L2_PIX_FMT_YUV420M
+{ AV_PIX_FMT_YUV420P, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_YUV420M, 
FF_V4L_PACK_AVFRAME  },
+#endif
+#ifdef V4L2_PIX_FMT_NV16M
+{ AV_PIX_FMT_NV16,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_NV16M  , 
FF_V4L_PACK_AVFRAME  },
+#endif
+#ifdef V4L2_PIX_FMT_DV
+{ AV_PIX_FMT_NONE,AV_CODEC_ID_DVVIDEO,  V4L2_PIX_FMT_DV , 
FF_V4L_PACK_AVPACKET },
+#endif
+#ifdef V4L2_PIX_FMT_H263
+{ AV_PIX_FMT_NONE,AV_CODEC_ID_H263, V4L2_PIX_FMT_H263   , 
FF_V4L_PACK_AVPACKET },
+#endif
+#ifdef V4L2_PIX_FMT_MPEG1
+{ AV_PIX_FMT_NONE,AV_CODEC_ID_MPEG1VIDEO, V4L2_PIX_FMT_MPEG1, 
FF_V4L_PACK_AVPACKET },
+#endif
+#ifdef V4L2_PIX_FMT_MPEG2
+{ AV_PIX_FMT_NONE,AV_CODEC_ID_MPEG2VIDEO, V4L2_PIX_FMT_MPEG2, 
FF_V4L_PACK_AVPACKET },
+#endif
+#ifdef V4L2_PIX_FMT_VC1_ANNEX_G
+{ AV_PIX_FMT_NONE,AV_CODEC_ID_VC1,  V4L2_PIX_FMT_VC1_ANNEX_G, 
FF_V4L_PACK_AVPACKET },
+#endif
+#ifdef V4L2_PIX_FMT_VP8
+{ AV_PIX_FMT_NONE,AV_CODEC_ID_VP8,  V4L2_PIX_FMT_VP8, 
FF_V4L_PACK_AVPACKET },
+#endif
+#ifdef V4L2_PIX_FMT_HEVC
+{ AV_PIX_FMT_NONE,AV_CODEC_ID_HEVC, V4L2_PIX_FMT_HEVC, 
FF_V4L_PACK_AVPACKET},
+#endif
+#ifdef V4L2_PIX_FMT_VP9
+{ AV_PIX_FMT_NONE,AV_CODEC_ID_VP9,  V4L2_PIX_FMT_VP9, 
FF_V4L_PACK_AVPACKET },
+#endif
+{ AV_PIX_FMT_NONE,AV_CODEC_ID_NONE, 0   , 
FF_V4L_PACK_AVPACKET | FF_V4L_PACK_AVFRAME },
 };
 
 uint32_t avpriv_v4l_fmt_ff2v4l(enum AVPixelFormat pix_fmt, enum AVCodecID 
codec_id, int pack_flags)
-- 
2.7.4

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

Re: [FFmpeg-devel] [PATCH] Properly store sampling rate for FLAC in mp4

[Jean-Yves Avenard]

Note that that it's also not correct for other codecs when the
sampling rate is greater than 65536. Right now it stores 0.
If in quicktime mode, it could use a SoundDescription v2 box, but in
mp4 that doesn't exist.

Per ISO 14496-12 , it should be using a AudioSampleEntryV1 along a
SamplingRateBox ('srat') which uses a 32 bits unsigned integer.
There's no handling of that in the current ffmpeg.

If time permit I will submit something for this.

Rgds
JY


On 25 August 2017 at 13:25, Jean-Yves Avenard  wrote:
> From 9baa7166fa96ed6beac9146c7e3b4dcf425a67d0 Mon Sep 17 00:00:00 2001
> From: Jean-Yves Avenard 
> Date: Fri, 25 Aug 2017 13:11:28 +0200
> Subject: [PATCH] Properly store sampling rate for FLAC in mp4
>
> Fixes ticket #6609
>
> Signed-off-by: Jean-Yves Avenard 
> ---
>  libavformat/movenc.c | 28 +---
>  1 file changed, 25 insertions(+), 3 deletions(-)
>
> diff --git a/libavformat/movenc.c b/libavformat/movenc.c
> index 10b959ad02..aa4a9c962a 100644
> --- a/libavformat/movenc.c
> +++ b/libavformat/movenc.c
> @@ -1028,9 +1028,31 @@ static int mov_write_audio_tag(AVFormatContext
> *s, AVIOContext *pb, MOVMuxContex
>  avio_wb16(pb, 0); /* packet size (= 0) */
>  if (track->par->codec_id == AV_CODEC_ID_OPUS)
>  avio_wb16(pb, 48000);
> -else
> -avio_wb16(pb, track->par->sample_rate <= UINT16_MAX ?
> -  track->par->sample_rate : 0);
> +else {
> +uint32_t rate;
> +if (track->par->codec_id == AV_CODEC_ID_FLAC) {
> +/* When the bitstream's native sample rate is greater
> + than the maximum expressible value of 65535 Hz,
> + the samplerate field shall hold the greatest
> + expressible regular division of that rate. I.e.
> + the samplerate field shall hold 48000.0 for
> + native sample rates of 96 and 192 kHz. In the
> + case of unusual sample rates which do not have
> + an expressible regular division, the maximum value
> + of 65535.0 Hz should be used. */
> +rate = track->par->sample_rate;
> +while (rate > UINT16_MAX && (rate & 1) == 0) {
> +rate = rate >> 1;
> +}
> +if (rate > UINT16_MAX) {
> +rate = UINT16_MAX;
> +}
> +} else {
> +rate = track->par->sample_rate <= UINT16_MAX ?
> +   track->par->sample_rate : 0;
> +}
> +avio_wb16(pb, rate);
> +}
>  avio_wb16(pb, 0); /* Reserved */
>  }
>
> --
> 2.11.0 (Apple Git-81)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCHv6 1/4] Move lavd/v4l2-common.* to lavc

[Jorge Ramirez-Ortiz]

From: Alexis Ballier 

In preparation to support the integation of the V4L2 API for encoding
and decoding, move v4l2 related files to libavcodec.

v4l2-common was renamed to v4l2_fmt for clarity (v4l2-common.h belongs
to the V4L2 API)

Signed-off-by: Alexis Ballier 
Reviewed-by: Jorge Ramirez-Ortiz 
---
 configure |   6 ++-
 libavcodec/Makefile   |   1 +
 libavcodec/v4l2_fmt.c | 105 ++
 libavcodec/v4l2_fmt.h |  57 +
 libavdevice/Makefile  |   6 +--
 libavdevice/v4l2-common.c | 105 --
 libavdevice/v4l2-common.h |  61 ---
 libavdevice/v4l2.c|  40 --
 libavdevice/v4l2enc.c |  12 +-
 9 files changed, 206 insertions(+), 187 deletions(-)
 create mode 100644 libavcodec/v4l2_fmt.c
 create mode 100644 libavcodec/v4l2_fmt.h
 delete mode 100644 libavdevice/v4l2-common.c
 delete mode 100644 libavdevice/v4l2-common.h

diff --git a/configure b/configure
index 7201941..e048b02 100755
--- a/configure
+++ b/configure
@@ -1671,6 +1671,7 @@ SUBSYSTEM_LIST="
 pixelutils
 network
 rdft
+v4l2
 "
 
 # COMPONENT_LIST needs to come last to ensure correct dependency checking
@@ -2269,6 +2270,7 @@ map 'eval ${v}_inline_deps=inline_asm' $ARCH_EXT_LIST_ARM
 
 loongson2_deps="mips"
 loongson3_deps="mips"
+v4l2_deps_any="linux_videodev2_h sys_videoio_h"
 mipsfpu_deps="mips"
 mipsdsp_deps="mips"
 mipsdspr2_deps="mips"
@@ -3042,8 +3044,8 @@ sdl2_outdev_deps="sdl2"
 sndio_indev_deps="sndio"
 sndio_outdev_deps="sndio"
 v4l_indev_deps="linux_videodev_h"
-v4l2_indev_deps_any="linux_videodev2_h sys_videoio_h"
-v4l2_outdev_deps_any="linux_videodev2_h sys_videoio_h"
+v4l2_indev_select="v4l2"
+v4l2_outdev_select="v4l2"
 vfwcap_indev_deps="vfw32 vfwcap_defines"
 xcbgrab_indev_deps="libxcb"
 xv_outdev_deps="X11_extensions_Xvlib_h XvGetPortAttribute"
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 982d7f5..153247f 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -101,6 +101,7 @@ OBJS-$(CONFIG_LZF) += lzf.o
 OBJS-$(CONFIG_MDCT)+= mdct_fixed.o mdct_float.o 
mdct_fixed_32.o
 OBJS-$(CONFIG_ME_CMP)  += me_cmp.o
 OBJS-$(CONFIG_MEDIACODEC)  += mediacodecdec_common.o 
mediacodec_surface.o mediacodec_wrapper.o mediacodec_sw_buffer.o
+OBJS-$(CONFIG_V4L2)+= v4l2_fmt.o
 OBJS-$(CONFIG_MPEG_ER) += mpeg_er.o
 OBJS-$(CONFIG_MPEGAUDIO)   += mpegaudio.o
 OBJS-$(CONFIG_MPEGAUDIODSP)+= mpegaudiodsp.o\
diff --git a/libavcodec/v4l2_fmt.c b/libavcodec/v4l2_fmt.c
new file mode 100644
index 000..322f595
--- /dev/null
+++ b/libavcodec/v4l2_fmt.c
@@ -0,0 +1,105 @@
+/*
+ * 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 "v4l2_fmt.h"
+
+const struct v4l_fmt_map avpriv_v4l_fmt_conversion_table[] = {
+//ff_fmt  codec_id  v4l2_fmt
+{ AV_PIX_FMT_YUV420P, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_YUV420  },
+{ AV_PIX_FMT_YUV420P, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_YVU420  },
+{ AV_PIX_FMT_YUV422P, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_YUV422P },
+{ AV_PIX_FMT_YUYV422, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_YUYV},
+{ AV_PIX_FMT_UYVY422, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_UYVY},
+{ AV_PIX_FMT_YUV411P, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_YUV411P },
+{ AV_PIX_FMT_YUV410P, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_YUV410  },
+{ AV_PIX_FMT_YUV410P, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_YVU410  },
+{ AV_PIX_FMT_RGB555LE,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_RGB555  },
+{ AV_PIX_FMT_RGB555BE,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_RGB555X },
+{ AV_PIX_FMT_RGB565LE,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_RGB565  },
+{ AV_PIX_FMT_RGB565BE,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_RGB565X },
+{ AV_PIX_FMT_BGR24,   AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_BGR24   },
+{ AV_PIX_FMT_RGB24,   AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_RGB24   },
+{ AV_PIX_FMT_BGR0,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_BGR32   },
+{ AV_PIX_FMT_0RGB,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_RGB32   },

[FFmpeg-devel] V4L2 M2M version 6

[Jorge Ramirez-Ortiz]

This patch-set adds support for dynamically reconfiguring the video stream.

The set was rebased on top of [1].

The fate suite was run successfully and the encoders/decoders have
been tested (including a fix for vp8 encoding).  Simultaneous
encoding/decoding was also validated and the build system checked on
ubuntu 10.04 and following versions. 

Because I didnt receive any comments on v5 - submited some weeks ago -
and _not_ because I am trying to rush things, I'd appreciate some
clarification on what the next steps would be to get the set merge
upstream.

looking forward to feedback and comments.

TIA

[1] commit 3ddd10290afb88ffbb25d15863076002cfca4827
Author: Muhammad Faiz 
Date:   Fri Aug 25 17:36:04 2017 +0700
avfilter/af_firequalizer: fix minval on cepstrum calculation
The impulse response is scaled with 2/rdft_len.
Signed-off-by: Muhammad Faiz 




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

Re: [FFmpeg-devel] [PATCH] avcodec/imgconvert: remove deprecation guards for a function that's not declared as such

[Ronald S. Bultje]

Hi,

On Thu, Aug 24, 2017 at 7:43 PM, James Almer  wrote:

> Signed-off-by: James Almer 
> ---
> The deprecation seems to have been imported from libav but never made
> effective.


Hm, but do we really want this function? Shouldn't all users be ported to
the function this wraps?

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

Re: [FFmpeg-devel] [PATCH] avcodec/imgconvert: remove deprecation guards for a function that's not declared as such

[wm4]

On Fri, 25 Aug 2017 10:15:05 +0200
Paul B Mahol  wrote:

> On 8/25/17, wm4  wrote:
> > On Thu, 24 Aug 2017 20:43:11 -0300
> > James Almer  wrote:
> >  
> >> Signed-off-by: James Almer 
> >> ---
> >> The deprecation seems to have been imported from libav but never made
> >> effective.
> >>
> >>  libavcodec/imgconvert.c | 2 --
> >>  libavcodec/version.h| 3 ---
> >>  2 files changed, 5 deletions(-)
> >>
> >> diff --git a/libavcodec/imgconvert.c b/libavcodec/imgconvert.c
> >> index 1547f18966..a349e2a083 100644
> >> --- a/libavcodec/imgconvert.c
> >> +++ b/libavcodec/imgconvert.c
> >> @@ -34,7 +34,6 @@
> >>  #include "libavutil/internal.h"
> >>  #include "libavutil/imgutils.h"
> >>
> >> -#if FF_API_GETCHROMA
> >>  void avcodec_get_chroma_sub_sample(enum AVPixelFormat pix_fmt, int
> >> *h_shift, int *v_shift)
> >>  {
> >>  const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(pix_fmt);
> >> @@ -42,7 +41,6 @@ void avcodec_get_chroma_sub_sample(enum AVPixelFormat
> >> pix_fmt, int *h_shift, int
> >>  *h_shift = desc->log2_chroma_w;
> >>  *v_shift = desc->log2_chroma_h;
> >>  }
> >> -#endif
> >>
> >>  int avcodec_get_pix_fmt_loss(enum AVPixelFormat dst_pix_fmt,
> >>   enum AVPixelFormat src_pix_fmt,
> >> diff --git a/libavcodec/version.h b/libavcodec/version.h
> >> index 7473000579..f41b9caa2d 100644
> >> --- a/libavcodec/version.h
> >> +++ b/libavcodec/version.h
> >> @@ -60,9 +60,6 @@
> >>  #ifndef FF_API_AVCODEC_RESAMPLE
> >>  #define FF_API_AVCODEC_RESAMPLE  FF_API_AUDIO_CONVERT
> >>  #endif
> >> -#ifndef FF_API_GETCHROMA
> >> -#define FF_API_GETCHROMA (LIBAVCODEC_VERSION_MAJOR < 58)
> >> -#endif
> >>  #ifndef FF_API_MISSING_SAMPLE
> >>  #define FF_API_MISSING_SAMPLE(LIBAVCODEC_VERSION_MAJOR < 58)
> >>  #endif  
> >
> > I don't agree with this.  
> 
> Why?

The function should be removed.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 6/6] avformat/hls: Fix DoS due to infinite loop

[wm4]

On Fri, 25 Aug 2017 11:59:54 +0200
Michael Niedermayer  wrote:

> On Fri, Aug 25, 2017 at 10:08:23AM +0200, wm4 wrote:
> > On Fri, 25 Aug 2017 01:15:32 +0200
> > Michael Niedermayer  wrote:
> >   
> > > Fixes: loop.m3u
> > > 
> > > The max iteration count of 1 is arbitrary and ideas for a better 
> > > solution are welcome
> > > 
> > > Found-by: Xiaohei and Wangchu from Alibaba Security Team
> > > Signed-off-by: Michael Niedermayer 
> > > ---
> > >  libavformat/hls.c | 4 
> > >  1 file changed, 4 insertions(+)
> > > 
> > > diff --git a/libavformat/hls.c b/libavformat/hls.c
> > > index 01731bd36b..26f4ebd965 100644
> > > --- a/libavformat/hls.c
> > > +++ b/libavformat/hls.c
> > > @@ -1263,6 +1263,7 @@ static int read_data(void *opaque, uint8_t *buf, 
> > > int buf_size)
> > >  HLSContext *c = v->parent->priv_data;
> > >  int ret, i;
> > >  int just_opened = 0;
> > > +int reload_count = 0;
> > >  
> > >  restart:
> > >  if (!v->needed)
> > > @@ -1294,6 +1295,9 @@ restart:
> > >  reload_interval = default_reload_interval(v);
> > >  
> > >  reload:
> > > +reload_count++;
> > > +if (reload_count > 1)
> > > +return AVERROR_EOF;
> > >  if (!v->finished &&
> > >  av_gettime_relative() - v->last_load_time >= 
> > > reload_interval) {
> > >  if ((ret = parse_playlist(c, v->url, v, NULL)) < 0) {  
> > 
> > Why 1000?  
> 
> Please read the commit message at the top of the mail you reply to,
> that is explained in it
> 
> 
> > 
> > This patch is unnecessary. The interrupt callback can break out of this
> > loop anyway on user request. Or is this patch again intended for
> > transcode servers with hilariously insecure amateurish configuration,
> > like most of these patches seem to be?  
> 
> Do you object to this issue being fixed ?

I content that there is an issue. It was found by a fuzzer, and has no
security implications.

> In which case i will of course respect your veto and leave the issue
> open.
> Otherwise i will here note that i disagree with your oppinion.
> 
> And will resubmit a patch with the changes requested by the maintainer

A user option is even worse, because it creates API for a thing that
doesn't matter.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avformat/asfdec: Fix DoS due to lack of eof check

[Michael Niedermayer]

From: "wangchu@alibaba-inc.com" 

Fixes: loop.asf

Found-by: Xiaohei and Wangchu from Alibaba Security Team
Signed-off-by: Michael Niedermayer 
---
 libavformat/asfdec_f.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/libavformat/asfdec_f.c b/libavformat/asfdec_f.c
index be09a92bd1..f3acbae280 100644
--- a/libavformat/asfdec_f.c
+++ b/libavformat/asfdec_f.c
@@ -749,13 +749,15 @@ static int asf_read_marker(AVFormatContext *s, int64_t 
size)
 count = avio_rl32(pb);// markers count
 avio_rl16(pb);// reserved 2 bytes
 name_len = avio_rl16(pb); // name length
-for (i = 0; i < name_len; i++)
-avio_r8(pb); // skip the name
+avio_skip(pb, name_len);
 
 for (i = 0; i < count; i++) {
 int64_t pres_time;
 int name_len;
 
+if (avio_feof(pb))
+return AVERROR_INVALIDDATA;
+
 avio_rl64(pb); // offset, 8 bytes
 pres_time = avio_rl64(pb); // presentation time
 pres_time -= asf->hdr.preroll * 1;
-- 
2.14.1

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

Re: [FFmpeg-devel] [PATCH 5/6] avformat/asfdec: Fix DoS due to lack of eof check

[Michael Niedermayer]

On Fri, Aug 25, 2017 at 08:52:22AM +0200, Paul B Mahol wrote:
> On 8/25/17, Michael Niedermayer  wrote:
> > From: ** and *(**) 
> >
> > Fixes: loop.asf
> >
> > Found-by: Xiaohei and Wangchu from Alibaba Security Team
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavformat/asfdec_f.c | 9 -
> >  1 file changed, 8 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavformat/asfdec_f.c b/libavformat/asfdec_f.c
> > index be09a92bd1..00dd5ec41d 100644
> > --- a/libavformat/asfdec_f.c
> > +++ b/libavformat/asfdec_f.c
> > @@ -749,13 +749,20 @@ static int asf_read_marker(AVFormatContext *s, int64_t
> > size)
> >  count = avio_rl32(pb);// markers count
> >  avio_rl16(pb);// reserved 2 bytes
> >  name_len = avio_rl16(pb); // name length
> > -for (i = 0; i < name_len; i++)
> > +for (i = 0; i < name_len; i++) {
> > +if (avio_feof(pb))
> > +return AVERROR_INVALIDDATA;
> >  avio_r8(pb); // skip the name
> 
> This is very slow way to skip something.

yes, you are correct, i will fix that and resubmit

thx

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

If you think the mosad wants you dead since a long time then you are either
wrong or dead since a long time.


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

Re: [FFmpeg-devel] [PATCH 6/6] avformat/hls: Fix DoS due to infinite loop

[Michael Niedermayer]

On Fri, Aug 25, 2017 at 08:23:32AM +0800, Steven Liu wrote:
> 2017-08-25 7:15 GMT+08:00 Michael Niedermayer :
> > Fixes: loop.m3u
> >
> > The max iteration count of 1 is arbitrary and ideas for a better 
> > solution are welcome
> Why not give a option to user for set the reload_count and limit from 1 - 
> 1?

patch submitted

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

[FFmpeg-devel] [PATCH] avformat/hls: Fix DoS due to infinite loop

[Michael Niedermayer]

Fixes: loop.m3u

The default max iteration count of 1000 is arbitrary and ideas for a better 
solution are welcome

Found-by: Xiaohei and Wangchu from Alibaba Security Team
Signed-off-by: Michael Niedermayer 
---
 libavformat/hls.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/libavformat/hls.c b/libavformat/hls.c
index 01731bd36b..0995345bbf 100644
--- a/libavformat/hls.c
+++ b/libavformat/hls.c
@@ -205,6 +205,7 @@ typedef struct HLSContext {
 AVDictionary *avio_opts;
 int strict_std_compliance;
 char *allowed_extensions;
+int max_reload;
 } HLSContext;
 
 static int read_chomp_line(AVIOContext *s, char *buf, int maxlen)
@@ -1263,6 +1264,7 @@ static int read_data(void *opaque, uint8_t *buf, int 
buf_size)
 HLSContext *c = v->parent->priv_data;
 int ret, i;
 int just_opened = 0;
+int reload_count = 0;
 
 restart:
 if (!v->needed)
@@ -1294,6 +1296,9 @@ restart:
 reload_interval = default_reload_interval(v);
 
 reload:
+reload_count++;
+if (reload_count > c->max_reload)
+return AVERROR_EOF;
 if (!v->finished &&
 av_gettime_relative() - v->last_load_time >= reload_interval) {
 if ((ret = parse_playlist(c, v->url, v, NULL)) < 0) {
@@ -2150,6 +2155,8 @@ static const AVOption hls_options[] = {
 OFFSET(allowed_extensions), AV_OPT_TYPE_STRING,
 {.str = 
"3gp,aac,avi,flac,mkv,m3u8,m4a,m4s,m4v,mpg,mov,mp2,mp3,mp4,mpeg,mpegts,ogg,ogv,oga,ts,vob,wav"},
 INT_MIN, INT_MAX, FLAGS},
+{"max_reload", "Maximum number of times a insufficient list is attempted 
to be reloaded",
+OFFSET(max_reload), AV_OPT_TYPE_INT, {.i64 = 1000}, 0, INT_MAX, FLAGS},
 {NULL}
 };
 
-- 
2.14.1

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

Re: [FFmpeg-devel] [PATCH 6/6] avformat/hls: Fix DoS due to infinite loop

[Michael Niedermayer]

On Fri, Aug 25, 2017 at 10:08:23AM +0200, wm4 wrote:
> On Fri, 25 Aug 2017 01:15:32 +0200
> Michael Niedermayer  wrote:
> 
> > Fixes: loop.m3u
> > 
> > The max iteration count of 1 is arbitrary and ideas for a better 
> > solution are welcome
> > 
> > Found-by: Xiaohei and Wangchu from Alibaba Security Team
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavformat/hls.c | 4 
> >  1 file changed, 4 insertions(+)
> > 
> > diff --git a/libavformat/hls.c b/libavformat/hls.c
> > index 01731bd36b..26f4ebd965 100644
> > --- a/libavformat/hls.c
> > +++ b/libavformat/hls.c
> > @@ -1263,6 +1263,7 @@ static int read_data(void *opaque, uint8_t *buf, int 
> > buf_size)
> >  HLSContext *c = v->parent->priv_data;
> >  int ret, i;
> >  int just_opened = 0;
> > +int reload_count = 0;
> >  
> >  restart:
> >  if (!v->needed)
> > @@ -1294,6 +1295,9 @@ restart:
> >  reload_interval = default_reload_interval(v);
> >  
> >  reload:
> > +reload_count++;
> > +if (reload_count > 1)
> > +return AVERROR_EOF;
> >  if (!v->finished &&
> >  av_gettime_relative() - v->last_load_time >= reload_interval) {
> >  if ((ret = parse_playlist(c, v->url, v, NULL)) < 0) {
> 
> Why 1000?

Please read the commit message at the top of the mail you reply to,
that is explained in it


> 
> This patch is unnecessary. The interrupt callback can break out of this
> loop anyway on user request. Or is this patch again intended for
> transcode servers with hilariously insecure amateurish configuration,
> like most of these patches seem to be?

Do you object to this issue being fixed ?
In which case i will of course respect your veto and leave the issue
open.
Otherwise i will here note that i disagree with your oppinion.

And will resubmit a patch with the changes requested by the maintainer

Thanks

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I do not agree with what you have to say, but I'll defend to the death your
right to say it. -- 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] avcodec/imgconvert: remove deprecation guards for a function that's not declared as such

[Paul B Mahol]

On 8/25/17, wm4  wrote:
> On Thu, 24 Aug 2017 20:43:11 -0300
> James Almer  wrote:
>
>> Signed-off-by: James Almer 
>> ---
>> The deprecation seems to have been imported from libav but never made
>> effective.
>>
>>  libavcodec/imgconvert.c | 2 --
>>  libavcodec/version.h| 3 ---
>>  2 files changed, 5 deletions(-)
>>
>> diff --git a/libavcodec/imgconvert.c b/libavcodec/imgconvert.c
>> index 1547f18966..a349e2a083 100644
>> --- a/libavcodec/imgconvert.c
>> +++ b/libavcodec/imgconvert.c
>> @@ -34,7 +34,6 @@
>>  #include "libavutil/internal.h"
>>  #include "libavutil/imgutils.h"
>>
>> -#if FF_API_GETCHROMA
>>  void avcodec_get_chroma_sub_sample(enum AVPixelFormat pix_fmt, int
>> *h_shift, int *v_shift)
>>  {
>>  const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(pix_fmt);
>> @@ -42,7 +41,6 @@ void avcodec_get_chroma_sub_sample(enum AVPixelFormat
>> pix_fmt, int *h_shift, int
>>  *h_shift = desc->log2_chroma_w;
>>  *v_shift = desc->log2_chroma_h;
>>  }
>> -#endif
>>
>>  int avcodec_get_pix_fmt_loss(enum AVPixelFormat dst_pix_fmt,
>>   enum AVPixelFormat src_pix_fmt,
>> diff --git a/libavcodec/version.h b/libavcodec/version.h
>> index 7473000579..f41b9caa2d 100644
>> --- a/libavcodec/version.h
>> +++ b/libavcodec/version.h
>> @@ -60,9 +60,6 @@
>>  #ifndef FF_API_AVCODEC_RESAMPLE
>>  #define FF_API_AVCODEC_RESAMPLE  FF_API_AUDIO_CONVERT
>>  #endif
>> -#ifndef FF_API_GETCHROMA
>> -#define FF_API_GETCHROMA (LIBAVCODEC_VERSION_MAJOR < 58)
>> -#endif
>>  #ifndef FF_API_MISSING_SAMPLE
>>  #define FF_API_MISSING_SAMPLE(LIBAVCODEC_VERSION_MAJOR < 58)
>>  #endif
>
> I don't agree with this.

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

Re: [FFmpeg-devel] [PATCH 6/6] avformat/hls: Fix DoS due to infinite loop

[wm4]

On Fri, 25 Aug 2017 01:15:32 +0200
Michael Niedermayer  wrote:

> Fixes: loop.m3u
> 
> The max iteration count of 1 is arbitrary and ideas for a better solution 
> are welcome
> 
> Found-by: Xiaohei and Wangchu from Alibaba Security Team
> Signed-off-by: Michael Niedermayer 
> ---
>  libavformat/hls.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/libavformat/hls.c b/libavformat/hls.c
> index 01731bd36b..26f4ebd965 100644
> --- a/libavformat/hls.c
> +++ b/libavformat/hls.c
> @@ -1263,6 +1263,7 @@ static int read_data(void *opaque, uint8_t *buf, int 
> buf_size)
>  HLSContext *c = v->parent->priv_data;
>  int ret, i;
>  int just_opened = 0;
> +int reload_count = 0;
>  
>  restart:
>  if (!v->needed)
> @@ -1294,6 +1295,9 @@ restart:
>  reload_interval = default_reload_interval(v);
>  
>  reload:
> +reload_count++;
> +if (reload_count > 1)
> +return AVERROR_EOF;
>  if (!v->finished &&
>  av_gettime_relative() - v->last_load_time >= reload_interval) {
>  if ((ret = parse_playlist(c, v->url, v, NULL)) < 0) {

Why 1000?

This patch is unnecessary. The interrupt callback can break out of this
loop anyway on user request. Or is this patch again intended for
transcode servers with hilariously insecure amateurish configuration,
like most of these patches seem to be?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Autotools full recompilation

[wm4]

On Fri, 25 Aug 2017 02:19:00 +0300
Yan  wrote:

> And after each time the whole project got recompiled. I guess you cook
> autotools wrong. (Personally I hate this build system cause it's ugly
> and slw)

As it was mentioned, FFmpeg doesn't use autotools, just
somewhat similar conventions. A full recompile is usually triggered only
if config.h changes (in which case you really can't avoid it). What
build system would you suggest instead?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/imgconvert: remove deprecation guards for a function that's not declared as such

[wm4]

On Thu, 24 Aug 2017 20:43:11 -0300
James Almer  wrote:

> Signed-off-by: James Almer 
> ---
> The deprecation seems to have been imported from libav but never made 
> effective.
> 
>  libavcodec/imgconvert.c | 2 --
>  libavcodec/version.h| 3 ---
>  2 files changed, 5 deletions(-)
> 
> diff --git a/libavcodec/imgconvert.c b/libavcodec/imgconvert.c
> index 1547f18966..a349e2a083 100644
> --- a/libavcodec/imgconvert.c
> +++ b/libavcodec/imgconvert.c
> @@ -34,7 +34,6 @@
>  #include "libavutil/internal.h"
>  #include "libavutil/imgutils.h"
>  
> -#if FF_API_GETCHROMA
>  void avcodec_get_chroma_sub_sample(enum AVPixelFormat pix_fmt, int *h_shift, 
> int *v_shift)
>  {
>  const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(pix_fmt);
> @@ -42,7 +41,6 @@ void avcodec_get_chroma_sub_sample(enum AVPixelFormat 
> pix_fmt, int *h_shift, int
>  *h_shift = desc->log2_chroma_w;
>  *v_shift = desc->log2_chroma_h;
>  }
> -#endif
>  
>  int avcodec_get_pix_fmt_loss(enum AVPixelFormat dst_pix_fmt,
>   enum AVPixelFormat src_pix_fmt,
> diff --git a/libavcodec/version.h b/libavcodec/version.h
> index 7473000579..f41b9caa2d 100644
> --- a/libavcodec/version.h
> +++ b/libavcodec/version.h
> @@ -60,9 +60,6 @@
>  #ifndef FF_API_AVCODEC_RESAMPLE
>  #define FF_API_AVCODEC_RESAMPLE  FF_API_AUDIO_CONVERT
>  #endif
> -#ifndef FF_API_GETCHROMA
> -#define FF_API_GETCHROMA (LIBAVCODEC_VERSION_MAJOR < 58)
> -#endif
>  #ifndef FF_API_MISSING_SAMPLE
>  #define FF_API_MISSING_SAMPLE(LIBAVCODEC_VERSION_MAJOR < 58)
>  #endif

I don't agree with this.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] lavc/vaapi_encode_h265: Enable VBR mode

[Jun Zhao]

From 483204cf7c25077d556c86b9e70f591fc2c0d4a3 Mon Sep 17 00:00:00 2001
From: Jun Zhao 
Date: Fri, 25 Aug 2017 03:50:37 -0400
Subject: [PATCH] lavc/vaapi_encode_h265: Enable VBR mode

Follow vaapi_h264 style, enable the VBR mode.

Signed-off-by: Jun Zhao 
---
 libavcodec/vaapi_encode_h265.c | 15 ++-
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/libavcodec/vaapi_encode_h265.c b/libavcodec/vaapi_encode_h265.c
index cf6b9388d1..971458db87 100644
--- a/libavcodec/vaapi_encode_h265.c
+++ b/libavcodec/vaapi_encode_h265.c
@@ -1185,13 +1185,15 @@ static av_cold int 
vaapi_encode_h265_configure(AVCodecContext *avctx)
"%d / %d / %d for IDR- / P- / B-frames.\n",
priv->fixed_qp_idr, priv->fixed_qp_p, priv->fixed_qp_b);
 
-} else if (ctx->va_rc_mode == VA_RC_CBR) {
+} else if (ctx->va_rc_mode == VA_RC_CBR ||
+   ctx->va_rc_mode == VA_RC_VBR) {
 // These still need to be  set for pic_init_qp/slice_qp_delta.
 priv->fixed_qp_idr = 30;
 priv->fixed_qp_p   = 30;
 priv->fixed_qp_b   = 30;
 
-av_log(avctx, AV_LOG_DEBUG, "Using constant-bitrate = %"PRId64" 
bps.\n",
+av_log(avctx, AV_LOG_DEBUG, "Using %s-bitrate = %"PRId64" bps.\n",
+   ctx->va_rc_mode == VA_RC_CBR ? "constant" : "variable",
avctx->bit_rate);
 
 } else {
@@ -1251,9 +1253,12 @@ static av_cold int vaapi_encode_h265_init(AVCodecContext 
*avctx)
 }
 ctx->va_entrypoint = VAEntrypointEncSlice;
 
-if (avctx->bit_rate > 0)
-ctx->va_rc_mode = VA_RC_CBR;
-else
+if (avctx->bit_rate > 0) {
+if (avctx->rc_max_rate == avctx->bit_rate)
+ctx->va_rc_mode = VA_RC_CBR;
+else
+ctx->va_rc_mode = VA_RC_VBR;
+} else
 ctx->va_rc_mode = VA_RC_CQP;
 
 ctx->va_packed_headers =
-- 
2.11.0

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

Re: [FFmpeg-devel] [PATCH 5/6] avformat/asfdec: Fix DoS due to lack of eof check

[Paul B Mahol]

On 8/25/17, Michael Niedermayer  wrote:
> From: ** and *(**) 
>
> Fixes: loop.asf
>
> Found-by: Xiaohei and Wangchu from Alibaba Security Team
> Signed-off-by: Michael Niedermayer 
> ---
>  libavformat/asfdec_f.c | 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/libavformat/asfdec_f.c b/libavformat/asfdec_f.c
> index be09a92bd1..00dd5ec41d 100644
> --- a/libavformat/asfdec_f.c
> +++ b/libavformat/asfdec_f.c
> @@ -749,13 +749,20 @@ static int asf_read_marker(AVFormatContext *s, int64_t
> size)
>  count = avio_rl32(pb);// markers count
>  avio_rl16(pb);// reserved 2 bytes
>  name_len = avio_rl16(pb); // name length
> -for (i = 0; i < name_len; i++)
> +for (i = 0; i < name_len; i++) {
> +if (avio_feof(pb))
> +return AVERROR_INVALIDDATA;
>  avio_r8(pb); // skip the name

This is very slow way to skip something.

> +}
> +
>
>  for (i = 0; i < count; i++) {
>  int64_t pres_time;
>  int name_len;
>
> +if (avio_feof(pb))
> +return AVERROR_INVALIDDATA;
> +
>  avio_rl64(pb); // offset, 8 bytes
>  pres_time = avio_rl64(pb); // presentation time
>  pres_time -= asf->hdr.preroll * 1;
> --
> 2.14.1
>
> ___
> 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] avcodec/imgconvert: remove deprecation guards for a function that's not declared as such

[Paul B Mahol]

On 8/25/17, James Almer  wrote:
> Signed-off-by: James Almer 
> ---
> The deprecation seems to have been imported from libav but never made
> effective.
>
>  libavcodec/imgconvert.c | 2 --
>  libavcodec/version.h| 3 ---
>  2 files changed, 5 deletions(-)
>

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