> 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
> > 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
_
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
---
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 in
---
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)
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,
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..17eca
>> "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
__
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 \
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
> -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_fra
> 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.
_
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
> ---
> 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 @@
> #inclu
---
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"
#i
---
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, AVCodecCo
>> 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 examp
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
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/libav
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==
>> ---
>> lib
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/libav
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
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
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
> +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);
> +
>>
>> 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
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 b
> -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 Aj
> -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 a
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
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, repla
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 de
---
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) >
---
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:
@exam
34 matches
Mail list logo
