- 09 Oct, 2015 18 commits
-
-
赵宇龙 authored
the pps offset is used to locate pps in the spspps_buf; however, the current calc method is wrong because it is the offset of the original avctx->extradata; when there is only one sps in the avcc; the value is correct by coincidence, however, it will fail in avcc with multi sps Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Michael Niedermayer authored
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Ganesh Ajjanagadde authored
This fixes a warning observed on Clang 3.7: "warning: attribute 'deprecated' is ignored, place it after "struct" to apply attribute to type declaration [-Wignored-attributes]" and thus enables deprecation warning for the relevant struct. Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com> Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
-
Ganesh Ajjanagadde authored
This should fix the first undefined behavior reported in: https://trac.ffmpeg.org/ticket/4727. I can't reproduce the runtime behavior reported in the ticket, hence I can't confirm that this actually fixes the exact issue reported in the ticket. Regardless, I can confirm that this is a genuine issue, and that negative shifts can (and do) occur, fixed by this. Tested with FATE. Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Christophe Gisquet authored
Currently only 2 profiles are evaluated because they are the only 2 with distributed test sequences. - CID 1260: YUV 4:2:2 10 bits with block-adaptive interlace coding, from ticket 4876; - CID 1270: YUV 4:4:4 10 bits (HR), 1920x839, from ticket 4581. They were generated from the ticket sequences by running the following kind of command-line; ffmpeg -i $INPUT -an -sn -vcodec copy -vframes 1 -y $OUTPUT.mov Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Andreas Cadhalpun authored
Reviewed-by: Lou Logan <lou@lrcd.com> Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
-
Paul B Mahol authored
Signed-off-by: Paul B Mahol <onemda@gmail.com>
-
Ganesh Ajjanagadde authored
On lines 1633,1634 FFABS(pts) is performed. However, if av_stream_get_end_pts returns AV_NOPTS_VALUE always, pts remains stuck at INT64_MIN, leading to undefined behavior on FFABS. One could conceive of a solution using FFNABS. However, such a solution has to deal with the implementation defined rounding of integer division with at least one negative operand in ANSI C89. C99 forces truncation to zero, but I am not sure that all of our platforms compile with full C99 support, and in particular whether we can safely assume a fixed rounding behavior across all platforms. This solution is simple, and I doubt changing INT64_MIN to INT64_MIN + 1 has any practical loss - if it is stuck at its initial value, the stream is messed up anyway. Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Carl Eugen Hoyos authored
RFC 2435 suggests that mjpeg over rtp uses both two tables.
-
Ganesh Ajjanagadde authored
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com> Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
-
Christophe Gisquet authored
When trying to build the binary dct-test under MSYS2/Win64, the makefile rule does not have the SUBDIR in the target for its object file. Consequently, modifications to various include files (e.g. C ones) do not trigger a recompilation. When tracing the dependency generating, the dependency generation has this strange content (linebreak inserted): sed -e "/^#.*/d" -e "s,^[[:space:]]*dct\\.o,libavcodec/dct.o," \ > libavcodec/dct-test.d For some reason, the $(*F) has weird content. It looks simpler to use $(@F) instead of $(*F)\\.o, although this was tested on one single version of make. Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Paul B Mahol authored
Signed-off-by: Paul B Mahol <onemda@gmail.com>
-
Rodger Combs authored
-
Rodger Combs authored
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Rodger Combs authored
-
Clément Bœsch authored
-
Clément Bœsch authored
Fixes regression since 7218352e: WebVTT files were matching the SRT probing.
-
Rodger Combs authored
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
- 08 Oct, 2015 7 commits
-
-
wm4 authored
-
Ganesh Ajjanagadde authored
Change to https for FFmpeg websites. Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Justin Greer authored
Fixes #4919
-
Ganesh Ajjanagadde authored
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
-
Ganesh Ajjanagadde authored
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
-
Stefano Sabatini authored
tests: update fate-filter-delogo test reference after commit 8bc708fc
-
Jean Delvare authored
The original interpolation algorithm behaved poorly on the borders and did not even guarantee continuity at the borders. For this reason, a second interpolation/blending pass was required on the borders to make them seamless. However, since the interpolation algorithm was improved in June 2013, the border issues no longer exist. The new algorithm does guarantee continuity at the borders, making the second pass useless. A larger band always increases the cumulated interpolation error. In most cases it also increases the average interpolation error, even though the samples in the band are only partially interpolated. For this reason I would like to get rid of the "band" parameter. As a first step, let's change its default value from 4 to 1 and document it as deprecated. I have benchmarked this change on a combination of input sources and realistic logo areas. Lowering the band value from 4 to 1 resulted in 8 to 39 % less interpolation error per frame (or 1 to 34 % less interpolation error per luma sample.) Signed-off-by: Jean Delvare <jdelvare@suse.de> Signed-off-by: Stefano Sabatini <stefasab@gmail.com>
-
- 07 Oct, 2015 15 commits
-
-
Christophe Gisquet authored
The MBAFF handling recently introduced on the decoder side shows that the encoder does not support it correctly. Therefore, make the related profile experimental. Furthermore, current encoder logic treats it as unable to encode as progressive, which isn't the case. Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Christophe Gisquet authored
MBAFF-like handling of interlaced content in CID 1260 is different from the other CIDs, and in particular doesn't use the same syntax. Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Paul B Mahol authored
Signed-off-by: Paul B Mahol <onemda@gmail.com>
-
Christophe Gisquet authored
Profiles 1256 & 1270 (currently) signal at the frame header and MB levels the colorspace used, either RGB or YUV. While a MB-level varying colorspace is not supported, whether it is constant can be tracked so as to determine the exact colorspace. This requires having bitdepth and the ACT and 4:4:4 flags, in turn needing the CID. Because setting those before having validated enough things may result in invalid/unset DSP fucntions, setting the bitdepth in the context is delayed. It is not tested against a true RGB sequence, though. Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
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>
-
Nicolas George authored
-
Nicolas George authored
-
Nicolas George authored
-
Nicolas George authored
-
Nicolas George authored
-
Nicolas George authored
-
Nicolas George authored
-
Nicolas George authored
-