- 31 Oct, 2015 6 commits
-
-
Matt Oliver authored
Signed-off-by: Matt Oliver <protogonoi@gmail.com>
-
Ganesh Ajjanagadde authored
This simplifies and cleans up the code. Furthermore, it is much faster due to absence of the slow log computation. Reviewed-by: Michael Niedermayer <michael@niedermayer.cc> Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
-
Michael Niedermayer authored
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Michael Niedermayer authored
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Michael Niedermayer authored
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Michael Niedermayer authored
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
- 30 Oct, 2015 12 commits
-
-
Michael Niedermayer authored
Should fix build on x86_32-msvc2012 The alternative of emulating fmin/fmax* turns out to be non trivial Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Muhammad Faiz authored
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Marton Balint authored
ffprobe.xsd already contains the tag element. Reviewed-by: Stefano Sabatini <stefasab@gmail.com> Signed-off-by: Marton Balint <cus@passwd.hu>
-
Ganesh Ajjanagadde authored
ISO C restricts enumerator values to the range of int. Thus (for instance) 0x80000000 unfortunately does not work, and throws a warning with -Wpedantic on clang 3.7. This fixes it by using alternative expressions that result in identical values but do not have this issue. Tested with FATE. Reviewed-by: Ronald S. Bultje <rsbultje@gmail.com> Reviewed-by: Michael Niedermayer <michael@niedermayer.cc> Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
-
Ganesh Ajjanagadde authored
Current code is fine, this just adds robustness. Reviewed-by: Michael Niedermayer <michael@niedermayer.cc> Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
-
Ganesh Ajjanagadde authored
av_gcd is now always defined regardless of input. This documents this change in the "documented API". Two benefits (closely related): 1. The function is robust, and there is no need to worry about INT64_MIN, etc. 2. Clients of av_gcd, like av_reduce, can now be made fully correct. Currently, av_reduce can trigger undefined behavior if e.g num is INT64_MIN due to integer overflow in the FFABS. Furthermore, this undefined behavior is completely undocumented, and could be a fuzzer's paradise. The FFABS was needed in the past as av_gcd was undefined for negative inputs. In order to make av_reduce robust, it is essential to guarantee that av_gcd works for all int64_t. Reviewed-by: Michael Niedermayer <michael@niedermayer.cc> Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
-
Nicolas George authored
Fix a segfault when no encoder is found for a default codec with a complex filter graph.
-
Steven Robertson authored
Signed-off-by: Steven Robertson <steven@strobe.cc> Reviewed-by: Paul B Mahol <onemda@gmail.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Michael Niedermayer authored
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Michael Niedermayer authored
Fixes regression with iJi.ogv Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Carl Eugen Hoyos authored
QT ignores the value written in the frame header. Issue reported by forum user Koracas.
-
Carl Eugen Hoyos authored
-
- 29 Oct, 2015 22 commits
-
-
Ganesh Ajjanagadde authored
This ensures that no undefined behavior is invoked, while retaining identical return values in all cases and at no loss of performance (identical asm on clang and gcc). Essentially, this patch exchanges undefined behavior with implementation defined behavior, a strict improvement. Rationale: 1. The ideal solution is to have the return type a uint64_t. This unfortunately requires an API change. 2. The only pathological behavior happens if both arguments are INT64_MIN, to the best of my knowledge. In such a case, the implementation defined behavior is invoked in the sense that UINT64_MAX is interpreted as INT64_MIN, which any reasonable implementation will do. In any case, any usage where both arguments are INT64_MIN is a fuzzer anyway. 3. Alternatives of checking, etc require branching and lose performance for no concrete gain - no client cares about av_gcd's actual value when both args are INT64_MIN. Even if it did, on sane platforms (e.g all the ones FFmpeg cares about), it produces a correct gcd, namely INT64_MIN. Reviewed-by: Michael Niedermayer <michael@niedermayer.cc> Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
-
Ganesh Ajjanagadde authored
This is likely more precise and conveys the intent better. Reviewed-by: Paul B Mahol <onemda@gmail.com> Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
-
Ganesh Ajjanagadde authored
This is more concise and conveys the intent better. Furthermore, it is likely more precise as well due to lack of floating point division. Reviewed-by: Michael Niedermayer <michael@niedermayer.cc> Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
-
Ganesh Ajjanagadde authored
This is likely more precise and conveys the intent better. Reviewed-by: Michael Niedermayer <michael@niedermayer.cc> Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
-
Ganesh Ajjanagadde authored
This is likely more precise and conveys the intent better. Reviewed-by: Michael Niedermayer <michael@niedermayer.cc> Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
-
Ganesh Ajjanagadde authored
This is likely more precise and conveys the intent better. Reviewed-by: Michael Niedermayer <michael@niedermayer.cc> Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
-
Andreas Cadhalpun authored
It is an internal swscale function and thus should not be exported. Reviewed-by: Michael Niedermayer <michael@niedermayer.cc> Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
-
Andreas Cadhalpun authored
It is an internal swscale symbol and thus should not be exported. Reviewed-by: Michael Niedermayer <michael@niedermayer.cc> Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
-
Andreas Cadhalpun authored
They are not in public headers and not used outside of libavformat. Reviewed-by: Hendrik Leppkes <h.leppkes@gmail.com> Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
-
Ganesh Ajjanagadde authored
This is likely more precise and conveys the intent better. Reviewed-by: Michael Niedermayer <michael@niedermayer.cc> Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
-
Ganesh Ajjanagadde authored
This is likely more precise and conveys the intent better. Reviewed-by: Michael Niedermayer <michael@niedermayer.cc> Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
-
Ganesh Ajjanagadde authored
This is likely more precise and conveys the intent better. Reviewed-by: Michael Niedermayer <michael@niedermayer.cc> Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
-
Ganesh Ajjanagadde authored
This is likely more precise and conveys the intent better. The expression has also been accordingly simplified. Reviewed-by: Michael Niedermayer <michael@niedermayer.cc> Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
-
Paul B Mahol authored
Signed-off-by: Paul B Mahol <onemda@gmail.com>
-
Paul B Mahol authored
Signed-off-by: Paul B Mahol <onemda@gmail.com>
-
Paul B Mahol authored
Signed-off-by: Paul B Mahol <onemda@gmail.com>
-
Paul B Mahol authored
Signed-off-by: Paul B Mahol <onemda@gmail.com>
-
Paul B Mahol authored
Signed-off-by: Paul B Mahol <onemda@gmail.com>
-
Kyle Swanson authored
Signed-off-by: Kyle Swanson <k@ylo.ph> Reviewed-by: Paul B Mahol <onemda@gmail.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Kyle Swanson authored
Signed-off-by: Kyle Swanson <k@ylo.ph> Reviewed-by: Nicolas George <george@nsup.org> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Hendrik Leppkes authored
* commit '8edaf625': libopenh264enc: Count and warn about the number of skipped frames Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
-
Hendrik Leppkes authored
* commit '9e14a992': libopenh264enc: Add an option for controlling the frame skipping Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
-