Re: [FFmpeg-devel] [PATCH 1/2] avutil/file_open: Fix build error with wasi
> From: Zhao Zhili
>
> Don't assume tempnam is available when !HAVE_MKSTEMP. Check tempnam
> explicitly in configure.
>
> Signed-off-by: Zhao Zhili
> ---
> configure | 2 ++
> libavutil/file_open.c | 2 +-
> 2 files changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/configure b/configure
> index 7685c95fbb..bd3c1d4838 100755
> --- a/configure
> +++ b/configure
> @@ -2413,6 +2413,7 @@ SYSTEM_FUNCS="
> sysconf
> sysctl
> sysctlbyname
> +tempnam
> usleep
> UTGetOSTypeFromString
> VirtualAlloc
> @@ -6548,6 +6549,7 @@ check_struct "sys/stat.h" "struct stat" st_mtim.tv_nsec
> -D_BSD_SOURCE
> check_func strerror_r
> check_func sysconf
> check_func sysctl
> +check_func tempnam
> check_func usleep
>
> check_func_headers conio.h kbhit
> diff --git a/libavutil/file_open.c b/libavutil/file_open.c
> index 24ef33e3da..eef6d83706 100644
> --- a/libavutil/file_open.c
> +++ b/libavutil/file_open.c
> @@ -112,7 +112,7 @@ int avpriv_tempfile(const char *prefix, char **filename,
> int log_offset, void *l
> {
> FileLogContext file_log_ctx = { &file_log_ctx_class, log_offset, log_ctx
> };
> int fd = -1;
> -#if !HAVE_MKSTEMP
> +#if HAVE_TEMPNAM
If neither HAVE_TEMPNAM nor HAVE_MKSTEMP are defined, this will get
the file name from an uninitialized buffer. If both are defined it
will not compile because len will be undefined.
- Mark
> void *ptr= tempnam(NULL, prefix);
> if(!ptr)
> ptr= tempnam(".", prefix);
> --
> 2.42.0
___
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] Issue with ogg page termination on full last page with even last segment size
> > 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
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
--- 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
---
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
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
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
>> "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
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, &codec);
+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, &codec);
-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] libopusenc: Add channel mapping family argument
On Tue, Jun 14, 2016 at 6:49 PM, Michael Graczyk
wrote:
> +@item mapping_family (@emph{mapping_family})
> +Set channel mapping family to be used by the encoder. The default is -1
> +(determine channel mapping and layout from channel count). Other values
> include
> +0 for stereo, 1 for surround sound, and 255 for independent streams with an
> +unspecified channel layout.
This implies that -mapping_family -1 (the default) is the same as some
other -mapping_family 0..255, determined by the input, but it is not.
For example even though 6 input channels will by default cause mapping
family 1 and a 5.1 surround layout to be written, it is required to
explicitly specify -mapping_family 1 to actually enable surround
masking and the special processing of the LFE channel. It is not
clear why surround masking and LFE processing are not enabled when the
family is defaulted to 1 rather than set to 1 explicitly, but if there
is an intentional difference then this should be clarified in the
documentation. -mapping_family -1 also imposes a limit on the number
of channels that is not present with -mapping_family 255.
> -.channel_layouts = ff_vorbis_channel_layouts,
This removes the restrictions on input channel layouts, allowing any
channel layout to be accepted. However, the code does not appear to
check the channel_layout, it only looks at the number of channels as
before. That means, for example, that it will no longer produce any
error for a 6.0 layout or a hexagonal layout, but the code still
assumes that 6 channels have a 5.1 layout and will write it as such by
default, without even a warning.
If the layout is not supported it should not be silently reinterpreted
as a completely different layout. See libvorbis_setup() for an
example of code that checks for a supported layout.
> if (channels > 2) {
> -bytestream_put_byte(&p, channels <= 8 ? 1 : 255);
> +bytestream_put_byte(&p, mapping_family);
When channels <= 2, the mapping family will still be 0 even if
-mapping_family 255 was explicitly specified.
> +/* Channels must be reordered to match opus mapping. */
> +opus->encoder_channel_map =
> ff_vorbis_channel_layout_offsets[avctx->channels - 1];
It looks like this is only intended to be used for mapping family 1,
with a channel count between 1 and 8, when the input layout is the one
that is supported by mapping family 1 for that channel count. However
there are no such checks.
If there are more than 8 channels it appears that it will read beyond
the end of the array. If the input does not have a family 1 layout
and mapping family 255 was specified, it will still remap the channels
as if they had a family 1 layout.
- Mark
___
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
> -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
> 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
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
> ---
> 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
---
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
---
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
>> 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
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
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
On Mon, Feb 15, 2016 at 11:02 AM, Michael Niedermayer 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
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
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(&gb, ptr, bit_length);
-if (!get_ue_golomb(&gb) ||
+if (!get_ue_golomb_long(&gb) || // 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(&sl->gb);
if (reordering_of_pic_nums_idc < 3)
-get_ue_golomb(&sl->gb);
+get_ue_golomb_long(&sl->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(&sl->gb);
+get_ue_golomb_long(&sl->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(&sl->gb);
@@ -373,7 +373,7 @@ static inline int parse_nal_units(AVCodecParserContext *s,
}
if (h->nal_unit_type == NAL_IDR_SLICE)
-get_ue_golomb(&sl->gb); /* idr_pic_id */
+get_ue_golomb_long(&sl->gb); /* idr_pic_id */
if (h->sps.poc_type == 0) {
h->poc_lsb = get_bits(&sl->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(&sl->gb) + 1;
+const unsigned int abs_diff_pic_num =
get_ue_golomb_long(&sl->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)
Re: [FFmpeg-devel] [PATCH] ffserver: fix incorrect strlcpy usage
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(&ti);
> -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
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.
> +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
>>
>> 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
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
> -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()
> -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
[FFmpeg-devel] [PATCH] doc/filters.texi: fix time duration references
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 synta
Re: [FFmpeg-devel] [PATCH] doc/filters.texi: remove incorrect duration syntax
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: remove incorrect duration syntax
The actual duration syntax with optional hours can be found in the
ffmpeg-utils doc, but mention only seconds for filter options because
":" is an option separator (at least on the command line).
---
doc/filters.texi | 36
1 file changed, 8 insertions(+), 28 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index 4ae5b4f..afac010 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -517,27 +517,17 @@ 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, in seconds.
+By default the start is determined by @var{start_sample}.
+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, in seconds.
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.
@@ -9459,12 +9449,7 @@ 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, in seconds.
If not specified, or the expressed duration is negative, the video is
supposed to be generated forever.
@@ -9726,12 +9711,7 @@ number or a valid video frame rate abbreviation. The
default value is
Set the sample aspect ratio of the sourced video.
@item duration, d
-Set the video duration of the sourced video. The accepted syntax is:
-@example
-[-]HH[:MM[:SS[.m...]]]
-[-]S+[.m...]
-@end example
-Also see the the @code{av_parse_time()} function.
+Set the duration of the sourced video, in seconds.
If not specified, or the expressed duration is negative, the video is
supposed to be generated forever.
--
2.1.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] tools/normalize.py: both input and output file names are required
--- tools/normalize.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/normalize.py b/tools/normalize.py index e015913..7d87c5e 100755 --- a/tools/normalize.py +++ b/tools/normalize.py @@ -2,7 +2,7 @@ import sys, subprocess -if len(sys.argv) > 1: +if len(sys.argv) > 2: ifile = sys.argv[1] encopt = sys.argv[2:-1] ofile = sys.argv[-1] -- 2.1.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] doc/filters.texi: fix filter name in examples
--- 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
