Re: [FFmpeg-devel] Issue with ogg page termination on full last page with even last segment size

2021-01-25 Thread Mark Harris
> > I am thinking that it should be safe to not mux any 0 sized packets in 
> > oggenc given that my understanding above is correct. Updated the patch to 
> > reflect that, let me know what you think.

Theora in Ogg uses zero-length packets to repeat the same video frame.

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avutil/mem: Fix invalid use of av_alloc_size

2018-11-25 Thread Mark Harris
On 2018-11-25 17:29, James Almer wrote:
> On 11/25/2018 10:01 PM, Michael Niedermayer wrote:
>> On Sat, Nov 24, 2018 at 01:02:02PM -0800, Mark Harris wrote:
>>> The alloc_size attribute is valid only on functions that return a
>>> pointer.  GCC 9 (not yet released) warns about invalid usage:
>>>
>>> ./libavutil/mem.h:342:1: warning: 'alloc_size' attribute ignored on a 
>>> function returning int' [-Wattributes]
>>>   342 | av_alloc_size(2, 3) int av_reallocp_array(void *ptr, size_t nmemb, 
>>> size_t size);
>>>   | ^
>>
>> Is the attribute also useless on all other compilers ?
> 
> The attribute is only used when __GNUC__ is defined, so it should for
> any such compiler (GCC and Clang).
> 
> https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html
> 

The Clang documentation does note a minor difference from GCC, but both
GCC and Clang agree that it applies to functions that return a pointer.
 The size is the number of bytes allocated at that pointer.  It doesn't
support an indirect reference to the allocated memory; if it did it
would likely need an additional parameter to indicate which argument was
the indirect reference.

https://clang.llvm.org/docs/AttributeReference.html#alloc-size

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


[FFmpeg-devel] [PATCH] avfilter/vf_chromashift: Fix mixed declaration and code

2018-11-24 Thread Mark Harris
---
 libavfilter/vf_chromashift.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libavfilter/vf_chromashift.c b/libavfilter/vf_chromashift.c
index 068c3c1b68..d073256b99 100644
--- a/libavfilter/vf_chromashift.c
+++ b/libavfilter/vf_chromashift.c
@@ -76,13 +76,14 @@ static int query_formats(AVFilterContext *ctx)
 AV_PIX_FMT_NONE
 };
 const enum AVPixelFormat *pix_fmts;
+AVFilterFormats *fmts_list;
 
 if (!strcmp(ctx->filter->name, "rgbashift"))
 pix_fmts = rgb_pix_fmts;
 else
 pix_fmts = yuv_pix_fmts;
 
-AVFilterFormats *fmts_list = ff_make_format_list(pix_fmts);
+fmts_list = ff_make_format_list(pix_fmts);
 if (!fmts_list)
 return AVERROR(ENOMEM);
 return ff_set_common_formats(ctx, fmts_list);
-- 
2.19.2

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


[FFmpeg-devel] [PATCH] avformat/vivo: Don't log null value

2018-11-24 Thread Mark Harris
---
 libavformat/vivo.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/vivo.c b/libavformat/vivo.c
index c9e9c37f37..9b9189f307 100644
--- a/libavformat/vivo.c
+++ b/libavformat/vivo.c
@@ -166,7 +166,7 @@ static int vivo_read_header(AVFormatContext *s)
 value = strchr(key, ':');
 if (!value) {
 av_log(s, AV_LOG_WARNING, "missing colon in key:value pair 
'%s'\n",
-   value);
+   key);
 continue;
 }
 
-- 
2.19.2

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


[FFmpeg-devel] [PATCH] avutil/mem: Fix invalid use of av_alloc_size

2018-11-24 Thread Mark Harris
The alloc_size attribute is valid only on functions that return a
pointer.  GCC 9 (not yet released) warns about invalid usage:

./libavutil/mem.h:342:1: warning: 'alloc_size' attribute ignored on a function 
returning int' [-Wattributes]
  342 | av_alloc_size(2, 3) int av_reallocp_array(void *ptr, size_t nmemb, 
size_t size);
  | ^
---
 libavutil/mem.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavutil/mem.h b/libavutil/mem.h
index 55ae573ac9..5fb1a02dd9 100644
--- a/libavutil/mem.h
+++ b/libavutil/mem.h
@@ -339,7 +339,7 @@ av_alloc_size(2, 3) void *av_realloc_array(void *ptr, 
size_t nmemb, size_t size)
  * @warning Unlike av_malloc(), the allocated memory is not guaranteed to be
  *  correctly aligned.
  */
-av_alloc_size(2, 3) int av_reallocp_array(void *ptr, size_t nmemb, size_t 
size);
+int av_reallocp_array(void *ptr, size_t nmemb, size_t size);
 
 /**
  * Reallocate the given buffer if it is not large enough, otherwise do nothing.
-- 
2.19.2

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


[FFmpeg-devel] [PATCH] avfilter/vf_fade: fix start/duration max value

2018-11-11 Thread Mark Harris
A fade out (usually at the end of a video) can easily start beyond
INT32_MAX (about 36 minutes).  Regression since d40dc64173.
---
 libavfilter/vf_fade.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/libavfilter/vf_fade.c b/libavfilter/vf_fade.c
index c30c41db0d..17eca109b6 100644
--- a/libavfilter/vf_fade.c
+++ b/libavfilter/vf_fade.c
@@ -386,13 +386,13 @@ static const AVOption fade_options[] = {
 OFFSET(nb_frames),   
AV_OPT_TYPE_INT, { .i64 = 25 }, 0, INT_MAX, FLAGS },
 { "alpha",   "fade alpha if it is available on the input", 
OFFSET(alpha),   AV_OPT_TYPE_BOOL, {.i64 = 0}, 0,   1, FLAGS },
 { "start_time",  "Number of seconds of the beginning of the effect.",
-OFFSET(start_time),  
AV_OPT_TYPE_DURATION, {.i64 = 0. }, 0, INT32_MAX, FLAGS },
+OFFSET(start_time),  
AV_OPT_TYPE_DURATION, {.i64 = 0. }, 0, INT64_MAX, FLAGS },
 { "st",  "Number of seconds of the beginning of the effect.",
-OFFSET(start_time),  
AV_OPT_TYPE_DURATION, {.i64 = 0. }, 0, INT32_MAX, FLAGS },
+OFFSET(start_time),  
AV_OPT_TYPE_DURATION, {.i64 = 0. }, 0, INT64_MAX, FLAGS },
 { "duration","Duration of the effect in seconds.",
-OFFSET(duration),
AV_OPT_TYPE_DURATION, {.i64 = 0. }, 0, INT32_MAX, FLAGS },
+OFFSET(duration),
AV_OPT_TYPE_DURATION, {.i64 = 0. }, 0, INT64_MAX, FLAGS },
 { "d",   "Duration of the effect in seconds.",
-OFFSET(duration),
AV_OPT_TYPE_DURATION, {.i64 = 0. }, 0, INT32_MAX, FLAGS },
+OFFSET(duration),
AV_OPT_TYPE_DURATION, {.i64 = 0. }, 0, INT64_MAX, FLAGS },
 { "color",   "set color",   OFFSET(color_rgba),  
AV_OPT_TYPE_COLOR,{.str = "black"}, CHAR_MIN, CHAR_MAX, FLAGS },
 { "c",   "set color",   OFFSET(color_rgba),  
AV_OPT_TYPE_COLOR,{.str = "black"}, CHAR_MIN, CHAR_MAX, FLAGS },
 { NULL }
-- 
2.19.1

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


Re: [FFmpeg-devel] [RFC] libfdk_aac license

2018-05-31 Thread Mark Harris
>> "The Fraunhofer AAC library is licensed under a license incompatible to

s/to/with/

>>   the GPL. Therefore, for GPL builds, you have to pass
>>   @code{--enable-nonfree} to configure to use it. To the best of our
>>   knowledge, it is compatible with the LGPL" ?

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


[FFmpeg-devel] [PATCH] avformat/wavdec: Eliminate goto for clang -O0 DCE

2016-12-15 Thread Mark Harris
Clang is not able to eliminate the reference to ff_spdif_probe() when
there is a goto target in the same block and optimization is disabled.

This fixes the following build failure on OS X:
  ./configure --disable-everything --disable-doc \
--enable-decoder=pcm_s16le --enable-demuxer=wav \
--enable-protocol=file --disable-optimizations --cc=clang
  make
  ...
  Undefined symbols for architecture x86_64:
"_ff_spdif_probe", referenced from:
_set_spdif in libavformat.a(wavdec.o)
  ld: symbol(s) not found for architecture x86_64
---
 libavformat/wavdec.c | 38 +-
 1 file changed, 17 insertions(+), 21 deletions(-)

diff --git a/libavformat/wavdec.c b/libavformat/wavdec.c
index 7176cd6f2d..ae42a6167f 100644
--- a/libavformat/wavdec.c
+++ b/libavformat/wavdec.c
@@ -64,34 +64,30 @@ static void set_spdif(AVFormatContext *s, WAVDemuxContext 
*wav)
 {
 if (CONFIG_SPDIF_DEMUXER && s->streams[0]->codecpar->codec_tag == 1) {
 enum AVCodecID codec;
-uint8_t *buf = NULL;
 int len = 1<<16;
 int ret = ffio_ensure_seekback(s->pb, len);
-int64_t pos = avio_tell(s->pb);
 
-if (ret < 0)
-goto end;
-
-buf = av_malloc(len);
-if (!buf) {
-ret = AVERROR(ENOMEM);
-goto end;
+if (ret >= 0) {
+uint8_t *buf = av_malloc(len);
+if (!buf) {
+ret = AVERROR(ENOMEM);
+} else {
+int64_t pos = avio_tell(s->pb);
+len = ret = avio_read(s->pb, buf, len);
+if (len >= 0) {
+ret = ff_spdif_probe(buf, len, );
+if (ret > AVPROBE_SCORE_EXTENSION) {
+s->streams[0]->codecpar->codec_id = codec;
+wav->spdif = 1;
+}
+}
+avio_seek(s->pb, pos, SEEK_SET);
+av_free(buf);
+}
 }
 
-len = ret = avio_read(s->pb, buf, len);
-if (ret < 0)
-goto end;
-
-ret = ff_spdif_probe(buf, len, );
-if (ret > AVPROBE_SCORE_EXTENSION) {
-s->streams[0]->codecpar->codec_id = codec;
-wav->spdif = 1;
-}
-end:
-avio_seek(s->pb, pos, SEEK_SET);
 if (ret < 0)
 av_log(s, AV_LOG_WARNING, "Cannot check for SPDIF\n");
-av_free(buf);
 }
 }
 
-- 
2.11.0

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


Re: [FFmpeg-devel] [PATCH] vc2enc: do not print lavc version when the bitexact flag is enabled

2016-05-03 Thread Mark Harris
> -const char aux_data[] = LIBAVCODEC_IDENT;
> +const char *aux_data = avctx->flags & AV_CODEC_FLAG_BITEXACT ?
> +   NULL : LIBAVCODEC_IDENT;
>  const int aux_data_size = sizeof(aux_data);
>  const int header_size = 100 + aux_data_size;
>  int64_t max_frame_bytes, r_bitrate = avctx->bit_rate >> (s->interlaced);

sizeof(aux_data) is no longer the string length or the correct
aux_data_size, since aux_data was changed to a pointer.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH v10] VideoToolbox H.264 Encoder

2016-03-05 Thread Mark Harris
> iam not sure zthis is still an issue as the last build is a few days
> ago so maybe this is alread fixed but, theres a build failure on:
> http://fatebeta.ffmpeg.org/log/x86_64-darwin-gcc-4.8/20160303011009/compile

This was fixed by ecba35bbe305c022d59da2d7bf066e3325693c26.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [PATCH] avformat/dump: Fix context/level for payload dump

2016-03-05 Thread Mark Harris
Use the context and level specified to av_pkt_dump_log2(),
instead of panic level (0), for dumping packet payload.
---
 libavformat/dump.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/dump.c b/libavformat/dump.c
index 9e7c12b..86bb82d 100644
--- a/libavformat/dump.c
+++ b/libavformat/dump.c
@@ -101,7 +101,7 @@ static void pkt_dump_internal(void *avcl, FILE *f, int 
level, const AVPacket *pk
 HEXDUMP_PRINT("\n");
 HEXDUMP_PRINT("  size=%d\n", pkt->size);
 if (dump_payload)
-av_hex_dump(f, pkt->data, pkt->size);
+hex_dump_internal(avcl, f, level, pkt->data, pkt->size);
 }
 
 void av_pkt_dump2(FILE *f, const AVPacket *pkt, int dump_payload, const 
AVStream *st)
-- 
2.7.2

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


Re: [FFmpeg-devel] [PATCH] videotoolboxenc: Fix compile failure on OS X 10.10

2016-03-02 Thread Mark Harris
> ---
>  libavcodec/videotoolboxenc.c | 8 
>  1 file changed, 8 insertions(+)
>
> diff --git a/libavcodec/videotoolboxenc.c b/libavcodec/videotoolboxenc.c
> index bbecb24..342c83c 100644
> --- a/libavcodec/videotoolboxenc.c
> +++ b/libavcodec/videotoolboxenc.c
> @@ -32,6 +32,14 @@
>  #include "internal.h"
>  #include 
>
> +#ifndef CM_NULLABLE
> +#define CM_NULLABLE
> +#endif
> +
> +#ifndef CV_NULLABLE
> +#define CV_NULLABLE
> +#endif
> +
>  typedef enum VT_H264Profile {
>  H264_PROF_AUTO,
>  H264_PROF_BASELINE,
> --
> 2.7.2

Never mind; use Rodger's patch instead.

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


[FFmpeg-devel] [PATCH] videotoolboxenc: Fix compile failure on OS X 10.10

2016-03-02 Thread Mark Harris
---
 libavcodec/videotoolboxenc.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/libavcodec/videotoolboxenc.c b/libavcodec/videotoolboxenc.c
index bbecb24..342c83c 100644
--- a/libavcodec/videotoolboxenc.c
+++ b/libavcodec/videotoolboxenc.c
@@ -32,6 +32,14 @@
 #include "internal.h"
 #include 
 
+#ifndef CM_NULLABLE
+#define CM_NULLABLE
+#endif
+
+#ifndef CV_NULLABLE
+#define CV_NULLABLE
+#endif
+
 typedef enum VT_H264Profile {
 H264_PROF_AUTO,
 H264_PROF_BASELINE,
-- 
2.7.2

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


[FFmpeg-devel] [PATCH] sdp: fix opus sprop-stereo fmtp syntax

2016-02-29 Thread Mark Harris
---
 libavformat/sdp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/sdp.c b/libavformat/sdp.c
index 2ab37a8..368402b 100644
--- a/libavformat/sdp.c
+++ b/libavformat/sdp.c
@@ -706,7 +706,7 @@ static char *sdp_write_media_attributes(char *buff, int 
size, AVCodecContext *c,
 av_strlcatf(buff, size, "a=rtpmap:%d opus/48000/2\r\n",
  payload_type);
 if (c->channels == 2) {
-av_strlcatf(buff, size, "a=fmtp:%d sprop-stereo:1\r\n",
+av_strlcatf(buff, size, "a=fmtp:%d sprop-stereo=1\r\n",
  payload_type);
 }
 break;
-- 
2.7.2

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


Re: [FFmpeg-devel] [PATCH 1/2] avformat/icodec: ico probe with unknown data

2016-02-16 Thread Mark Harris
>> Header:  OK, 2 frames
>> Frame 0: Unknown (offset points beyond end of probe buffer)
>> Frame 1: Invalid
>> Previously this example had a score of 25, even though the score would
>> be 1 if the unknown frame was known to be valid or 0 if it was known
>> to be invalid.  For this example the score is now 1.
>
> If the header is ok and the offset points beyond the end
> of the probe buffer, the score was always 25 (before I
> extended the check). Why should this be changed?
> 25 is not very high after checking ~40 bit.

If you think that 25 is better when there is 1 unknown frame and 1
invalid frame, I don't see an issue with that.  However in that case,
when the unknown frame is known to be valid it should have a score
that is at least the same value.  It doesn't make sense for the score
with an unknown value to be higher than the highest score that could
possibly be produced if the unknown value was known.

For this patch I just wanted to keep the behavior exactly the same in
the common case where all of the data is in the buffer.

For the case of unknown data, the existing code can do strange things.
For example if the probe buffer ends in the middle of a size or offset
field then it can end up reading a partial value, which can cause it
to check bytes at the wrong offset or produce false positives or false
negatives.  There were also inconsistencies if there was a mixture of
unknown and invalid data.  It seemed only logical that with unknown
data the score should never be higher than what it would be if the
data was known to be valid, and never be lower than what it would be
if the data was known to be invalid.  So I preserved the existing
behavior for the cases of known data, and adjusted the behavior for
unknown data so that the scores would be within these constraints and
so that there was no reliance on the zero padding.

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


[FFmpeg-devel] [PATCH 1/2] avformat/icodec: ico probe with unknown data

2016-02-15 Thread Mark Harris
Fix cases where unknown data (data beyond p->buf_size) could produce a
higher ico probe score than if the unknown data was known and valid.
For example:
Header:  OK, 2 frames
Frame 0: Unknown (offset points beyond end of probe buffer)
Frame 1: Invalid
Previously this example had a score of 25, even though the score would
be 1 if the unknown frame was known to be valid or 0 if it was known
to be invalid.  For this example the score is now 1.
---
 libavformat/icodec.c | 16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/libavformat/icodec.c b/libavformat/icodec.c
index 6ddb901..b247cb2 100644
--- a/libavformat/icodec.c
+++ b/libavformat/icodec.c
@@ -45,11 +45,14 @@ typedef struct {
 
 static int probe(AVProbeData *p)
 {
-unsigned i, frames = AV_RL16(p->buf + 4);
+unsigned i, frames, checked = 0;
 
-if (AV_RL16(p->buf) || AV_RL16(p->buf + 2) != 1 || !frames)
+if (p->buf_size < 22 || AV_RL16(p->buf) || AV_RL16(p->buf + 2) != 1)
 return 0;
-for (i = 0; i < frames; i++) {
+frames = AV_RL16(p->buf + 4);
+if (!frames)
+return 0;
+for (i = 0; i < frames && i * 16 + 22 <= p->buf_size; i++) {
 unsigned offset;
 if (AV_RL16(p->buf + 10 + i * 16) & ~1)
 return FFMIN(i, AVPROBE_SCORE_MAX / 4);
@@ -61,13 +64,14 @@ static int probe(AVProbeData *p)
 if (offset < 22)
 return FFMIN(i, AVPROBE_SCORE_MAX / 4);
 if (offset + 8 > p->buf_size)
-return AVPROBE_SCORE_MAX / 4 + FFMIN(i, 1);
+continue;
 if (p->buf[offset] != 40 && AV_RB64(p->buf + offset) != PNGSIG)
 return FFMIN(i, AVPROBE_SCORE_MAX / 4);
-if (i * 16 + 6 > p->buf_size)
-return AVPROBE_SCORE_MAX / 4 + FFMIN(i, 1);
+checked++;
 }
 
+if (checked < frames)
+return AVPROBE_SCORE_MAX / 4 + FFMIN(checked, 1);
 return AVPROBE_SCORE_MAX / 2 + 1;
 }
 
-- 
2.7.1

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


[FFmpeg-devel] [PATCH 2/2] avformat/icodec: Fix crash probing fuzzed file

2016-02-15 Thread Mark Harris
Avoid invalid memory read/crash when frame offset >= 0xfff8.
Base64-encoded example: AAABADAwMDAwMAAAMAAwMDAw/P///w==
(The previous commit verifies that p->buf_size >= 22.)
---
 libavformat/icodec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/icodec.c b/libavformat/icodec.c
index b247cb2..17acfb4 100644
--- a/libavformat/icodec.c
+++ b/libavformat/icodec.c
@@ -63,7 +63,7 @@ static int probe(AVProbeData *p)
 offset = AV_RL32(p->buf + 18 + i * 16);
 if (offset < 22)
 return FFMIN(i, AVPROBE_SCORE_MAX / 4);
-if (offset + 8 > p->buf_size)
+if (offset > p->buf_size - 8)
 continue;
 if (p->buf[offset] != 40 && AV_RB64(p->buf + offset) != PNGSIG)
 return FFMIN(i, AVPROBE_SCORE_MAX / 4);
-- 
2.7.1

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


Re: [FFmpeg-devel] [PATCH] avformat/icodec: Fix crash probing fuzzed file

2016-02-15 Thread Mark Harris
On Mon, Feb 15, 2016 at 11:02 AM, Michael Niedermayer
<mich...@niedermayer.cc> wrote:
> On Mon, Feb 15, 2016 at 09:57:51AM -0800, Mark Harris wrote:
>> Avoid invalid memory read/crash when ico offset >= 0xfff8.
>> Base64-encoded example: AAABADAwMDAwMAAAMAAwMDAw/P///w==
>> ---
>>  libavformat/icodec.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/libavformat/icodec.c b/libavformat/icodec.c
>> index 6ddb901..8f84337 100644
>> --- a/libavformat/icodec.c
>> +++ b/libavformat/icodec.c
>> @@ -60,7 +60,7 @@ static int probe(AVProbeData *p)
>>  offset = AV_RL32(p->buf + 18 + i * 16);
>>  if (offset < 22)
>>  return FFMIN(i, AVPROBE_SCORE_MAX / 4);
>> -if (offset + 8 > p->buf_size)
>> +if (offset > p->buf_size - 8)
>
> buf_size - 8 can underflow or more precissely is not guranteed to be
> representable as unsigned while the compare is using unsigned
>

If p->buf_size was less than 8, would it not have returned before
this?  AV_RL32(p->buf + 14) would be 0 and offset = AV_RL32(p->buf +
18) would be 0, due to the zero padding of the probe buffer.

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


[FFmpeg-devel] [PATCH] avformat/icodec: Fix crash probing fuzzed file

2016-02-15 Thread Mark Harris
Avoid invalid memory read/crash when ico offset >= 0xfff8.
Base64-encoded example: AAABADAwMDAwMAAAMAAwMDAw/P///w==
---
 libavformat/icodec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/icodec.c b/libavformat/icodec.c
index 6ddb901..8f84337 100644
--- a/libavformat/icodec.c
+++ b/libavformat/icodec.c
@@ -60,7 +60,7 @@ static int probe(AVProbeData *p)
 offset = AV_RL32(p->buf + 18 + i * 16);
 if (offset < 22)
 return FFMIN(i, AVPROBE_SCORE_MAX / 4);
-if (offset + 8 > p->buf_size)
+if (offset > p->buf_size - 8)
 return AVPROBE_SCORE_MAX / 4 + FFMIN(i, 1);
 if (p->buf[offset] != 40 && AV_RB64(p->buf + offset) != PNGSIG)
 return FFMIN(i, AVPROBE_SCORE_MAX / 4);
-- 
2.7.1

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


[FFmpeg-devel] [PATCH] avcodec: Use get_ue_golomb_long() when needed

2015-12-28 Thread Mark Harris
get_ue_golomb() cannot decode values larger than 8190 (the maximum
value that can be golomb encoded in 25 bits) and produces the error
"Invalid UE golomb code" if a larger value is encountered.  Use
get_ue_golomb_long() instead (which supports 63 bits, up to 4294967294)
when valid h264/hevc values can exceed 8190.

This updates decoding of the following values:   (maximum)
  first_mb_in_slice36863* for level 5.2
  abs_diff_pic_num_minus1 131071
  difference_of_pic_nums_minus1   131071
  idr_pic_id   65535
  recovery_frame_cnt   65535
  frame_packing_arrangement_id4294967294
  frame_packing_arrangement_repetition_period  16384
  display_orientation_repetition_period16384

An alternative would be to modify get_ue_golomb() to handle encoded
values of up to 49 bits as was done for get_se_golomb() in a92816c.
In that case get_ue_golomb() could continue to be used for all of
these except frame_packing_arrangement_id.
---
 libavcodec/golomb.h  |  2 +-
 libavcodec/h264.c|  2 +-
 libavcodec/h264_parser.c |  6 +++---
 libavcodec/h264_refs.c   |  4 ++--
 libavcodec/h264_sei.c| 10 +-
 libavcodec/h264_slice.c  |  2 +-
 libavcodec/hevc_sei.c|  2 +-
 7 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/libavcodec/golomb.h b/libavcodec/golomb.h
index 5136a04..d4df0b3 100644
--- a/libavcodec/golomb.h
+++ b/libavcodec/golomb.h
@@ -48,7 +48,7 @@ extern const  int8_t ff_interleaved_se_golomb_vlc_code[256];
 extern const uint8_t ff_interleaved_dirac_golomb_vlc_code[256];
 
 /**
- * read unsigned exp golomb code.
+ * Read an unsigned Exp-Golomb code in the range 0 to 8190.
  */
 static inline int get_ue_golomb(GetBitContext *gb)
 {
diff --git a/libavcodec/h264.c b/libavcodec/h264.c
index 089a86f..139011b 100644
--- a/libavcodec/h264.c
+++ b/libavcodec/h264.c
@@ -1365,7 +1365,7 @@ static int get_last_needed_nal(H264Context *h, const 
uint8_t *buf, int buf_size)
 case NAL_IDR_SLICE:
 case NAL_SLICE:
 init_get_bits(, ptr, bit_length);
-if (!get_ue_golomb() ||
+if (!get_ue_golomb_long() ||  // first_mb_in_slice
 !first_slice ||
 first_slice != h->nal_unit_type)
 nals_needed = nal_index;
diff --git a/libavcodec/h264_parser.c b/libavcodec/h264_parser.c
index 19d1aa3..12d6397 100644
--- a/libavcodec/h264_parser.c
+++ b/libavcodec/h264_parser.c
@@ -152,7 +152,7 @@ static int scan_mmco_reset(AVCodecParserContext *s)
 unsigned int reordering_of_pic_nums_idc = 
get_ue_golomb_31(>gb);
 
 if (reordering_of_pic_nums_idc < 3)
-get_ue_golomb(>gb);
+get_ue_golomb_long(>gb);
 else if (reordering_of_pic_nums_idc > 3) {
 av_log(h->avctx, AV_LOG_ERROR,
"illegal reordering_of_pic_nums_idc %d\n",
@@ -191,7 +191,7 @@ static int scan_mmco_reset(AVCodecParserContext *s)
 return 1;
 
 if (opcode == MMCO_SHORT2UNUSED || opcode == MMCO_SHORT2LONG)
-get_ue_golomb(>gb);
+get_ue_golomb_long(>gb); // difference_of_pic_nums_minus1
 if (opcode == MMCO_SHORT2LONG || opcode == MMCO_LONG2UNUSED ||
 opcode == MMCO_LONG || opcode == MMCO_SET_MAX_LONG)
 get_ue_golomb_31(>gb);
@@ -373,7 +373,7 @@ static inline int parse_nal_units(AVCodecParserContext *s,
 }
 
 if (h->nal_unit_type == NAL_IDR_SLICE)
-get_ue_golomb(>gb); /* idr_pic_id */
+get_ue_golomb_long(>gb); /* idr_pic_id */
 if (h->sps.poc_type == 0) {
 h->poc_lsb = get_bits(>gb, h->sps.log2_max_poc_lsb);
 
diff --git a/libavcodec/h264_refs.c b/libavcodec/h264_refs.c
index fbdcbd6..52fedc1 100644
--- a/libavcodec/h264_refs.c
+++ b/libavcodec/h264_refs.c
@@ -266,7 +266,7 @@ int ff_h264_decode_ref_pic_list_reordering(H264Context *h, 
H264SliceContext *sl)
 switch (modification_of_pic_nums_idc) {
 case 0:
 case 1: {
-const unsigned int abs_diff_pic_num = 
get_ue_golomb(>gb) + 1;
+const unsigned int abs_diff_pic_num = 
get_ue_golomb_long(>gb) + 1;
 int frame_num;
 
 if (abs_diff_pic_num > h->max_pic_num) {
@@ -843,7 +843,7 @@ int ff_h264_decode_ref_pic_marking(H264Context *h, 
GetBitContext *gb,
 mmco[i].opcode = opcode;
 if (opcode == MMCO_SHORT2UNUSED || opcode == MMCO_SHORT2LONG) {
 mmco[i].short_pic_num =
-(h->curr_pic_num - get_ue_golomb(gb) - 1) &
+(h->curr_pic_num - get_ue_golomb_long(gb) - 1) &
 (h->max_pic_num 

Re: [FFmpeg-devel] [PATCH] ffserver: fix incorrect strlcpy usage

2015-11-06 Thread Mark Harris
On Fri, Nov 6, 2015 at 12:49 PM, Ganesh Ajjanagadde
 wrote:
> Somewhat ironic that this "safe" interface is actually being used
> unsafely here. This fixes the usage preventing potential null pointer
> dereference, where the old code was doubly broken: ctime can return
> NULL, and ctime can return an arbitrarily long buffer.
>
> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  ffserver.c | 9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/ffserver.c b/ffserver.c
> index 526cbfc..108523e 100644
> --- a/ffserver.c
> +++ b/ffserver.c
> @@ -305,15 +305,18 @@ static void ffm_set_write_index(AVFormatContext *s, 
> int64_t pos,
>  ffm->file_size = file_size;
>  }
>
> -static char *ctime1(char *buf2, int buf_size)
> +static char *ctime1(char *buf2, size_t buf_size)
>  {
>  time_t ti;
>  char *p;
>
>  ti = time(NULL);
>  p = ctime();
> -av_strlcpy(buf2, p, buf_size);
> -p = buf2 + strlen(p) - 1;
> +if (!p) {
> +*buf2 = '\0';
> +return buf2;
> +}
> +p = buf2 + av_strlcpy(buf2, p, buf_size) - 1;
>  if (*p == '\n')
>  *p = '\0';
>  return buf2;

Ironically, this still doesn't handle a string that is too long for
the buffer.  "safe" indeed!  strlcpy (and av_strlcpy) returns the
length of the source, not the destination, so this will still access
and possibly write to memory beyond the end of buf2 when the string is
truncated.

It will also still access and possibly write to one byte before the
beginning of the buffer if the string is an empty string, although
that "should not happen".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH 06/11] avfilter/af_volumedetect: use log10 instead of hardcoded constant

2015-10-31 Thread Mark Harris
On Wed, Oct 28, 2015 at 9:20 PM, Ganesh Ajjanagadde
 wrote:
> This is likely more precise and conveys the intent better.
>
> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  libavfilter/af_volumedetect.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavfilter/af_volumedetect.c b/libavfilter/af_volumedetect.c
> index 01f24ba..ad5fef3 100644
> --- a/libavfilter/af_volumedetect.c
> +++ b/libavfilter/af_volumedetect.c
> @@ -78,7 +78,7 @@ static inline double logdb(uint64_t v)
>  double d = v / (double)(0x8000 * 0x8000);
>  if (!v)
>  return MAX_DB;
> -return log(d) * -4.3429448190325182765112891891660508229; /* -10/log(10) 
> */
> +return log10(d) * 10;

Wouldn't this reverse the sign of the result?

>  }
>
>  static void print_stats(AVFilterContext *ctx)
> --
> 2.6.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] lavfi: add realtime filter.

2015-10-25 Thread Mark Harris
> +static int filter_frame(AVFilterLink *inlink, AVFrame *frame)
> +{
> +AVFilterContext *ctx = inlink->dst;
> +RealtimeContext *s = ctx->priv;
> +
> +if (frame->pts != AV_NOPTS_VALUE) {
> +int64_t pts = av_rescale_q(frame->pts, inlink->time_base, 
> AV_TIME_BASE_Q);
> +int64_t now = av_gettime_relative();
> +int64_t sleep = pts - now + s->delta;
> +if (!s->inited) {
> +s->inited = 1;
> +sleep = 0;
> +s->delta = now - pts;
> +}
> +if (sleep > s->limit || sleep < -s->limit) {
> +av_log(ctx, AV_LOG_WARNING,
> +   "time discontinuity detected: %"PRIi64" us, resetting\n",
> +   sleep);

Won't this also be shown when there is no discontinuity but it isn't
able to keep up with realtime (e.g. due to a very high frame rate)?
The message is misleading in that situation.

> +sleep = 0;
> +s->delta = now - pts;
> +}
> +if (sleep > 0) {
> +av_log(ctx, AV_LOG_DEBUG, "sleeping %"PRIi64" us\n", sleep);
> +av_usleep(sleep);
> +}
> +}
> +return ff_filter_frame(inlink->dst->outputs[0], frame);
> +}
> +
> +#define OFFSET(x) offsetof(RealtimeContext, x)
> +#define FLAGS AV_OPT_FLAG_VIDEO_PARAM | AV_OPT_FLAG_AUDIO_PARAM | 
> AV_OPT_FLAG_FILTERING_PARAM
> +static const AVOption options[] = {
> +{ "limit", "sleep time limit", OFFSET(limit), AV_OPT_TYPE_DURATION, { 
> .i64 = 200 }, 0, INT64_MAX, FLAGS },
> +{ NULL }
> +};

The argument to av_usleep() is an unsigned int.  Should the maximum
limit be UINT_MAX rather than INT64_MAX?  Alternatively it could call
av_usleep() in a loop if the value is too large for one call.

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


Re: [FFmpeg-devel] [PATCH] all: simplify qsort comparators, and add const-correctness

2015-10-24 Thread Mark Harris
>>
>>  static int compare_int64(const void *a, const void *b)
>>  {
>> -int64_t va = *(int64_t *)a, vb = *(int64_t *)b;
>> -return va < vb ? -1 : va > vb ? +1 : 0;
>> +return *(const int64_t *)a - *(const int64_t *)b;
>>  }
>>
>
> What if the result doesn't fit in int? The input is not int.

Even for int this transformation is not valid assuming that the full
range of int is possible.  For example if *a = INT_MAX and *b = -1
then *a - *b = INT_MAX+1 which is negative when cast to an int.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] forcing ints to be 64 bits, possible new FATE client idea

2015-10-20 Thread Mark Harris
On Tue, Oct 20, 2015 at 7:08 PM, Ganesh Ajjanagadde  wrote:
> Hi all,
>
> It is known that there exist at least certain parts of the codebase
> that do not work correctly if ints are 64 bits. One of them I noticed
> was in avutil/intmath.h: ff_ctz_c does not compute the right thing if
> int is 64 bits. This is true both before and after the De-Bruijn
> optimization.
>
> A more interesting (and serious) question is whether FATE is broken if
> int's are 64 bits. I did some digging, and found the following from
> "The Definitive Guide to GCC" - On GCC prior to 4.x, there was a flag
> -mint64, documented as follows (see e.g
> https://gcc.gnu.org/onlinedocs/gcc-3.4.6/gcc.pdf):
> "Force int and long types to be 64 bits wide. See -mlong32 for an
> explanation of the default and the way that the pointer size is
> determined".
>
> This should be helpful in setting up a FATE client to test (and
> possibly fix) bad code that assumed int = 32 bits. I myself can't
> easily run such an outdated GCC, but I noticed a bunch of clients
> running GCC < 4.0 where this may be set up.

This option was only valid on MIPS targets, not on x86_64 or other
common platforms.  It produced code that was incompatible with the
ABI, which made it not very useful if you want to link with system
libraries.  It was therefore removed.

Although it would be possible to modify gcc to add a new x86_64 target
where int is 64 bits, you would probably have the same ABI issues
because libc and other system libraries would be assuming a 32-bit
int.

>
> Regards,
> Ganesh
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCHv2] avformat/movenc: suppress -Wstrict-overflow warnings

2015-10-17 Thread Mark Harris
> -if (cluster_idx >= track->entry)
> +/* GCC 5.2 wants to "optimize" cluster_idx >= track->entry to the below
> + * expression. We actually mean cluster_idx >= track->entry. */
> +if (cluster_idx - track->entry >= 0)
>  return 0;

On Sat, Oct 17, 2015 at 11:04 AM, Ganesh Ajjanagadde  wrote:
> Yes, it is really a questions of where on the ROC curve you want to
> land, and as such has no technical solution. Since there seems to be
> almost universal consensus against my proposal in this case, consider
> the patch dropped. I may return to it in a few years :).

Just a suggestion but I think the key thing to avoid in future patches
is changing an obviously correct check to something else that has the
potential to introduce new undefined behavior or subtle bugs.

For example the original check here is the obvious check to ensure
that access to the cluster array cannot occur at or beyond index
track->entry.  The proposed replacement cannot ensure that because the
arithmetic has the potential to overflow and produce the wrong result,
even without any compiler optimizations that eliminate the check.  So
this is simply replacing a potential for undefined behavior that is
impossible (provable by looking only at this source file) but gcc (and
not clang) falsely warn about, with a potential for new undefined
behavior that gcc doesn't warn about even though it cannot be ruled
out, at least not without analyzing other source files.

As an example, suppose it was possible for some other source file to
set track->entry to INT_MIN.  Previously the comparison would be true
and it would safely return 0, but with the proposed change it would
result in undefined behavior and may attempt to access entries in the
cluster array that do not exist.

This is different than quieting a warning by unnecessarily
initializing a local variable to 0, because changing a local variable
from uninitialized to initialized does not introduce any new undefined
behavior.

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


Re: [FFmpeg-devel] [PATCH] avformat/aiffdec: avoid double and ldexp()

2015-06-07 Thread Mark Harris
 -sample_rate = ldexp(val, exp - 16383 - 63);
 +if (exp = 0)
 +sample_rate = val  exp;
 +else
 +sample_rate = (val + (1(-exp/2)))  -exp;

To round the value it should probably be something like:
sample_rate = (val + ((uint64_t)1(-exp-1)))  -exp;

To avoid possible undefined behavior it would also need to check that
exp is within range.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] doc/filters.texi: remove incorrect duration syntax

2014-09-04 Thread Mark Harris
Stefano Sabatini wrote:
 What about:

 Specify time for starting to apply the fade effect. Default is 0.
 The value must be specified as a time duration, see
 @ref{date syntax,,the Date section in the ffmpeg-utils(1) 
 manual,ffmpeg-utils}.

 Same below.

Ok, I am sending a new patch, replacing this one, to make all of the
time duration references consistent.

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


[FFmpeg-devel] [PATCH] doc/filters.texi: fix time duration references

2014-09-04 Thread Mark Harris
Make time duration references consistent, using @ref links, and
eliminate incorrect syntax [-]HH[:MM[:SS[.m...]]].
---
 doc/filters.texi | 68 
 1 file changed, 29 insertions(+), 39 deletions(-)

diff --git a/doc/filters.texi b/doc/filters.texi
index 4ae5b4f..d13278e 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -517,27 +517,21 @@ volume as the input audio, at the end of the fade-out 
transition
 the output audio will be silence. Default is 44100.
 
 @item start_time, st
-Specify time for starting to apply the fade effect. Default is 0.
-The accepted syntax is:
-@example
-[-]HH[:MM[:SS[.m...]]]
-[-]S+[.m...]
-@end example
-See also the function @code{av_parse_time()}.
-If set this option is used instead of @var{start_sample} one.
+Specify the start time of the fade effect. Default is 0.
+The value must be specified as a time duration; see
+@ref{time duration syntax,,the Time duration section in the ffmpeg-utils(1) 
manual,ffmpeg-utils}
+for the accepted syntax.
+If set this option is used instead of @var{start_sample}.
 
 @item duration, d
-Specify the duration for which the fade effect has to last. Default is 0.
-The accepted syntax is:
-@example
-[-]HH[:MM[:SS[.m...]]]
-[-]S+[.m...]
-@end example
-See also the function @code{av_parse_time()}.
+Specify the duration of the fade effect. See
+@ref{time duration syntax,,the Time duration section in the ffmpeg-utils(1) 
manual,ffmpeg-utils}
+for the accepted syntax.
 At the end of the fade-in effect the output audio will have the same
 volume as the input audio, at the end of the fade-out transition
 the output audio will be silence.
-If set this option is used instead of @var{nb_samples} one.
+By default the duration is determined by @var{nb_samples}.
+If set this option is used instead of @var{nb_samples}.
 
 @item curve
 Set curve for fade transition.
@@ -1120,9 +1114,9 @@ The number of the first sample that should be output.
 The number of the first sample that should be dropped.
 @end table
 
-@option{start}, @option{end}, @option{duration} are expressed as time
-duration specifications, check the Time duration section in the
-ffmpeg-utils manual.
+@option{start}, @option{end}, and @option{duration} are expressed as time
+duration specifications; see
+@ref{time duration syntax,,the Time duration section in the ffmpeg-utils(1) 
manual,ffmpeg-utils}.
 
 Note that the first two sets of the start/end options and the @option{duration}
 option look at the frame timestamp, while the _sample options simply count the
@@ -1637,9 +1631,9 @@ Set the number of samples per channel per each output 
frame, default
 is 1024. Only used if plugin have zero inputs.
 
 @item duration, d
-Set the minimum duration of the sourced audio. See the function
-@code{av_parse_time()} for the accepted format, also check the Time duration
-section in the ffmpeg-utils manual.
+Set the minimum duration of the sourced audio. See
+@ref{time duration syntax,,the Time duration section in the ffmpeg-utils(1) 
manual,ffmpeg-utils}
+for the accepted syntax.
 Note that the resulting duration may be greater than the specified duration,
 as the generated audio is always cut at the end of a complete frame.
 If not specified, or the expressed duration is negative, the audio is
@@ -2189,8 +2183,9 @@ Set the channel layout. The number of channels in the 
specified layout
 must be equal to the number of specified expressions.
 
 @item duration, d
-Set the minimum duration of the sourced audio. See the function
-@code{av_parse_time()} for the accepted format.
+Set the minimum duration of the sourced audio. See
+@ref{time duration syntax,,the Time duration section in the ffmpeg-utils(1) 
manual,ffmpeg-utils}
+for the accepted syntax.
 Note that the resulting duration may be greater than the specified
 duration, as the generated audio is always cut at the end of a
 complete frame.
@@ -8546,9 +8541,10 @@ The number of the first frame that should be passed to 
the output.
 The number of the first frame that should be dropped.
 @end table
 
-@option{start}, @option{end}, @option{duration} are expressed as time
-duration specifications, check the Time duration section in the
-ffmpeg-utils manual.
+@option{start}, @option{end}, and @option{duration} are expressed as time
+duration specifications; see
+@ref{time duration syntax,,the Time duration section in the ffmpeg-utils(1) 
manual,ffmpeg-utils}
+for the accepted syntax.
 
 Note that the first two sets of the start/end options and the @option{duration}
 option look at the frame timestamp, while the _frame variants simply count the
@@ -9459,12 +9455,9 @@ number or a valid video frame rate abbreviation. The 
default value is
 25.
 
 @item duration, d
-Set the video duration of the sourced video. The accepted syntax is:
-@example
-[-]HH:MM:SS[.m...]
-[-]S+[.m...]
-@end example
-See also the function @code{av_parse_time()}.
+Set the duration of the sourced video. See
+@ref{time duration syntax,,the 

[FFmpeg-devel] [PATCH] doc/filters.texi: fix filter name in examples

2014-09-01 Thread Mark Harris
---
 doc/filters.texi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/doc/filters.texi b/doc/filters.texi
index cca15fc..4ae5b4f 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -491,7 +491,7 @@ aeval=val(ch)/2:c=same
 @item
 Invert phase of the second channel:
 @example
-eval=val(0)|-val(1)
+aeval=val(0)|-val(1)
 @end example
 @end itemize
 
@@ -9492,7 +9492,7 @@ Default value is all, which will cycle through the list 
of all tests.
 
 Some examples:
 @example
-testsrc=t=dc_luma
+mptestsrc=t=dc_luma
 @end example
 
 will generate a dc_luma test pattern.
-- 
2.1.0

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