| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Signed-off-by: Andreas Rheinhardt <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The behavior of the ffio_*_checksum feature is not well defined
when using avio_skip(). The code in oggdec.c relied on the skipped
data (four bytes) to be checksummed, which is mostly true
because short_seek_threshold is 32768 by default, so that
avio_seek() will normally read data instead of calling the
underlying seek function. Yet this has two problems:
a) It relies on implementation details of avio_seek().
b) There is an exception, namely if the AVIO_FLAG_DIRECT is set.
In this case the underlying seek function (if set) is always
called and the data is skipped, leading to CRC errors.
So don't skip the data.
Signed-off-by: Andreas Rheinhardt <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Otherwise it might be > buf_ptr in which case ffio_get_checksum()
could segfault (s->buf_ptr - s->checksum_ptr would be negative
which would be converted to something very big when converted
to unsigned for the update_checksum callback).
Fixes ticket #11233.
Reported-by: Du4t
Signed-off-by: Andreas Rheinhardt <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes an issue uncovered since 0ce413af9cc8040095a6b714600d6a8dceaca514
where flags were properly separated but without the objcflags_filter
being initialized, if add_objcflags is called early as part of
add_allcflags, it would lead to the append() function using an empty
filter and trying to call the flag instead, leading to errors like:
./configure: line 976: -fsanitize=address: command not found
./configure: line 976: -fno-omit-frame-pointer: command not found
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add a new flag to the vf_colorspace filter which provides the user an
option to clamp the linear and delinear transfer characteristics LUT
values to the [0, 1] represented range. This helps constrain the
potential value range when converting between colorspaces.
Certain colors when going through the conversion can result in out of
gamut colors after the rotation. The colorspace filter allows that with
the extended range. The added clamping just keeps the colors within the
[0, 1) range rather than using that extended range. I'm not enough of a
color scientist to say which is correct, but there are certain
situations where we would prefer to keep the colors in gamut.
The example I have is:
A solid color image of 8-bit YUV: Y=157, U=164, V=98.
Specify the input as:
Input range: MPEG
In color matrix: BT470BG
In color primaries: BT470M
In color transfer characteristics: Gamma 28
Output as:
Out color range: JPEG
Out color matrix: BT.709
Out color primaries: BT.709
Out color transfer characteristics: BT.709
During the calculation you get:
Input YUV: y=157, u=164, v-98
Post-yuv2rgb BT.470BG: r=0.456055, g=0.684152, b=0.928606
Post-apply gamma28 linear LUT: r=0.110979, g=0.345494, b=0.812709
Post-color rotation BT.470M to BT.709: r=-0.04161, g=0.384626, b=0.852400
Post-apply Rec.709 delinear LUT: r=-0.16382, g=0.615932, b=0.923793
Post-rgb2yuv Rec.709 matrix: y=120, u=190, v=25
Where with this change, the delinear LUT output would be clamped to 0,
so the result would be:
r=0.000000, g=0.612390, b=0.918807 and a final output of
y=129, u=185, v=46
As for the long and av_clip64, this was just because lrint returned a
long, so I left it as that and then used av_clip64 to the [0,1) range to
avoid overflow. But re-reading, it looks like av_clip_int16 would
downcast that long to int anyway so the possibility of overflow already
existed there. I've put it back to int just to match the existing
behavior.
|
|
|
|
|
|
|
|
| |
It was mistakenly removed in 0ce413af9cc8040095a6b714600d6a8dceaca514.
This matches how the Makefiles actually compile ObjC code, and
unlike C++, this seems to actually be benign and various existing
setups rely on that behaviour.
|
| |
|
|
|
|
|
|
|
|
| |
This was missed in 0ce413af9cc8040095a6b714600d6a8dceaca514.
This fixes proper detection of Objective C APIs (that are missing)
if targeting older macOS versions, such as the check for
AVCaptureSession.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Refer to RFC 4585 4.2,
Add SDP "a=rtcp-fb" so the peer can request rtx
through sending NACKs.
Add basic parsing for NACK packet.
Decrypt into a newly allocated buffer (do not
overwrite whip->buf) so multiple NACKs in a
bundled packet can be parsed in a loop while
keeping whip->buf available for sending rtx
Broken or wrong NACk are logged and skipped.
Signed-off-by: Jack Lau <[email protected]>
|
|
|
|
|
|
|
|
| |
Combining C++ with our w32pthreads does not work out.
The C++ standard lib headers might include pthread.h, which will then
define clashing types with our w32pthread header.
To solve this, switch to using C++ native std::thread.
|
| |
|
| |
|
|
|
|
| |
Signed-off-by: Zhao Zhili <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The strategy to count free slots isn't reliable. The value of
INPUT_MAX_PACKETS is a hardcoded value, and MPP_DEC_GET_STREAM_COUNT
doesn't always work as expected. When freeslots is nonzero, the mpp
decoder still returns MPP_ERR_BUFFER_FULL. Before this patch, all
packets are dropped once went into MPP_ERR_BUFFER_FULL state.
Don't drop packet and return error in MPP_ERR_BUFFER_FULL state.
Receive frame to allow the decoder's state machine to resume.
Signed-off-by: Zhao Zhili <[email protected]>
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
MinGWs ANSI stdio is quite slow, and when using UCRT, its extra features
are not needed.
The only troublesome part with ucrt printf is that is disagrees about
the size of "long double", but FFmpeg does not use that anywhere, let
alone prints it.
|
| |
|
|
|
|
|
|
|
|
| |
Right now, CFLAGS like -std=c17 leak onto the C++ compilers commandline,
leading to tons of warnings and even some errors.
Undefining __STRICT_ANSI__ causes strong warnings from the stdlib
headers. So only set it for C.
|
| |
|
|
|
|
| |
Signed-off-by: Andreas Rheinhardt <[email protected]>
|
|
|
|
| |
Signed-off-by: Andreas Rheinhardt <[email protected]>
|
|
|
|
|
| |
Needed some minor semantical changes to the shell wrapper, since
pre-commit expects it to exit with an error when applying fixes.
|
|
|
|
|
|
|
| |
Alternatively, this could be a separate job, potentially keyed
to only run on PRs that touch files matching */aarch64/*. But
as this runs very quickly, it's probably less clutter to just
bundle it here.
|
|
|
|
|
|
|
|
| |
The same also applies for arm assembly, but there are more known
deviations within that.
Add a script which checks all files, except for a few known files
that deviate, for various reasons.
|
|
|
|
| |
Signed-off-by: Andreas Rheinhardt <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, any nonnegative return value from an init function
is just treated as success and otherwise ignored; while it is
not explicitly forbidden to return something else than 0 (there
is no documentation whatsoever), the assumption is that
they return zero on success. So change dvdsubdec.c accordingly.
Also change dvdsub_parse_extradata() to return zero on success.
Signed-off-by: Andreas Rheinhardt <[email protected]>
|
|
|
|
| |
Signed-off-by: Andreas Rheinhardt <[email protected]>
|
|
|
|
|
|
| |
It is UB.
Signed-off-by: Andreas Rheinhardt <[email protected]>
|
|
|
|
| |
Signed-off-by: Kacper Michajłow <[email protected]>
|
|
|
|
|
|
|
| |
to avoid pointer casting and UB of calling function with different
pointer type.
Signed-off-by: Kacper Michajłow <[email protected]>
|
|
|
|
|
| |
Reviewed-by: Niklas Haas <[email protected]>
Signed-off-by: Andreas Rheinhardt <[email protected]>
|
|
|
|
|
| |
Reviewed-by: Niklas Haas <[email protected]>
Signed-off-by: Andreas Rheinhardt <[email protected]>
|
|
|
|
|
| |
Reviewed-by: Peter Ross <[email protected]>
Signed-off-by: Andreas Rheinhardt <[email protected]>
|
|
|
|
|
| |
Reviewed-by: Peter Ross <[email protected]>
Signed-off-by: Andreas Rheinhardt <[email protected]>
|
|
|
|
|
| |
Reviewed-by: Peter Ross <[email protected]>
Signed-off-by: Andreas Rheinhardt <[email protected]>
|
|
|
|
|
| |
Reviewed-by: Peter Ross <[email protected]>
Signed-off-by: Andreas Rheinhardt <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
Since ae448e00afb43d7f72dfa9c82a4c45994e4fea6a the various
tableinit functions are not compiled unconditionally any more,
so that pcm_tablegen.c (which creates the hardcoded tables)
needs to be updated.
Reviewed-by: James Almer <[email protected]>
Signed-off-by: Andreas Rheinhardt <[email protected]>
|
|
|
|
|
|
|
| |
Forgotten in 9141fe9653dc078d81bff8308ffdd2aaaf35495c.
Reviewed-by: Peter Ross <[email protected]>
Signed-off-by: Andreas Rheinhardt <[email protected]>
|
|
|
|
| |
Signed-off-by: James Almer <[email protected]>
|
|
|
|
|
|
|
|
|
| |
Wrongly removed in fe73b84879a560d69affca88ce21e61108e7c38d, it's required for
calls with a payload smaller than a full block.
Fixes issue #20474.
Signed-off-by: James Almer <[email protected]>
|
|
|
|
|
|
| |
VideoToolbox doesn't support automatic bitrate in low delay mode.
Check bitrate and show error message so user knows what's going
wrong.
|
|
|
|
|
|
|
| |
It is supported only for H.264 on Intel Macs, but it can be used with
both H.264 and HEVC on Apple Silicon.
Signed-off-by: Cameron Gutman <[email protected]>
|
|
|
|
| |
Signed-off-by: Tong Wu <[email protected]>
|
|
|
|
| |
Should fix #11240
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Macbook Air (M2):
vvc_alf_classify_8x8_8_c: 2.6 ( 1.00x)
vvc_alf_classify_8x8_8_neon: 1.0 ( 2.47x)
vvc_alf_classify_8x8_10_c: 2.7 ( 1.00x)
vvc_alf_classify_8x8_10_neon: 0.9 ( 2.98x)
vvc_alf_classify_8x8_12_c: 2.7 ( 1.00x)
vvc_alf_classify_8x8_12_neon: 0.9 ( 2.97x)
vvc_alf_classify_16x16_8_c: 7.3 ( 1.00x)
vvc_alf_classify_16x16_8_neon: 3.4 ( 2.12x)
vvc_alf_classify_16x16_10_c: 4.3 ( 1.00x)
vvc_alf_classify_16x16_10_neon: 2.9 ( 1.47x)
vvc_alf_classify_16x16_12_c: 4.3 ( 1.00x)
vvc_alf_classify_16x16_12_neon: 3.0 ( 1.44x)
vvc_alf_classify_32x32_8_c: 13.7 ( 1.00x)
vvc_alf_classify_32x32_8_neon: 10.7 ( 1.29x)
vvc_alf_classify_32x32_10_c: 12.3 ( 1.00x)
vvc_alf_classify_32x32_10_neon: 8.7 ( 1.42x)
vvc_alf_classify_32x32_12_c: 12.2 ( 1.00x)
vvc_alf_classify_32x32_12_neon: 8.7 ( 1.40x)
vvc_alf_classify_64x64_8_c: 45.8 ( 1.00x)
vvc_alf_classify_64x64_8_neon: 37.1 ( 1.23x)
vvc_alf_classify_64x64_10_c: 41.3 ( 1.00x)
vvc_alf_classify_64x64_10_neon: 32.8 ( 1.26x)
vvc_alf_classify_64x64_12_c: 41.4 ( 1.00x)
vvc_alf_classify_64x64_12_neon: 32.4 ( 1.28x)
vvc_alf_classify_128x128_8_c: 163.7 ( 1.00x)
vvc_alf_classify_128x128_8_neon: 138.3 ( 1.18x)
vvc_alf_classify_128x128_10_c: 149.1 ( 1.00x)
vvc_alf_classify_128x128_10_neon: 120.3 ( 1.24x)
vvc_alf_classify_128x128_12_c: 148.7 ( 1.00x)
vvc_alf_classify_128x128_12_neon: 119.4 ( 1.25x)
RPi4 (Cortex-A72):
vvc_alf_classify_8x8_8_c: 1251.6 ( 1.00x)
vvc_alf_classify_8x8_8_neon: 700.7 ( 1.79x)
vvc_alf_classify_8x8_10_c: 1141.9 ( 1.00x)
vvc_alf_classify_8x8_10_neon: 659.7 ( 1.73x)
vvc_alf_classify_8x8_12_c: 1075.8 ( 1.00x)
vvc_alf_classify_8x8_12_neon: 658.7 ( 1.63x)
vvc_alf_classify_16x16_8_c: 3574.1 ( 1.00x)
vvc_alf_classify_16x16_8_neon: 1849.8 ( 1.93x)
vvc_alf_classify_16x16_10_c: 3270.0 ( 1.00x)
vvc_alf_classify_16x16_10_neon: 1786.1 ( 1.83x)
vvc_alf_classify_16x16_12_c: 3271.7 ( 1.00x)
vvc_alf_classify_16x16_12_neon: 1785.5 ( 1.83x)
vvc_alf_classify_32x32_8_c: 12451.9 ( 1.00x)
vvc_alf_classify_32x32_8_neon: 5984.3 ( 2.08x)
vvc_alf_classify_32x32_10_c: 11428.9 ( 1.00x)
vvc_alf_classify_32x32_10_neon: 5756.3 ( 1.99x)
vvc_alf_classify_32x32_12_c: 11252.8 ( 1.00x)
vvc_alf_classify_32x32_12_neon: 5755.7 ( 1.96x)
vvc_alf_classify_64x64_8_c: 47625.5 ( 1.00x)
vvc_alf_classify_64x64_8_neon: 21071.9 ( 2.26x)
vvc_alf_classify_64x64_10_c: 44576.3 ( 1.00x)
vvc_alf_classify_64x64_10_neon: 21544.7 ( 2.07x)
vvc_alf_classify_64x64_12_c: 44600.5 ( 1.00x)
vvc_alf_classify_64x64_12_neon: 21491.2 ( 2.08x)
vvc_alf_classify_128x128_8_c: 192143.3 ( 1.00x)
vvc_alf_classify_128x128_8_neon: 82387.6 ( 2.33x)
vvc_alf_classify_128x128_10_c: 177583.1 ( 1.00x)
vvc_alf_classify_128x128_10_neon: 81628.8 ( 2.18x)
vvc_alf_classify_128x128_12_c: 177582.2 ( 1.00x)
vvc_alf_classify_128x128_12_neon: 81625.1 ( 2.18x)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before and after:
A53:
apply_bdof_8_8x16_neon: 3320.5 ( 4.02x)
apply_bdof_10_8x16_neon: 3317.8 ( 3.90x)
apply_bdof_12_8x16_neon: 3303.6 ( 3.91x)
apply_bdof_8_8x16_neon: 3168.1 ( 4.23x)
apply_bdof_10_8x16_neon: 3127.8 ( 4.13x)
apply_bdof_12_8x16_neon: 3119.3 ( 4.18x)
A72:
apply_bdof_8_8x16_neon: 1827.4 ( 5.02x)
apply_bdof_10_8x16_neon: 1838.5 ( 4.89x)
apply_bdof_12_8x16_neon: 1841.1 ( 4.83x)
apply_bdof_8_8x16_neon: 1691.6 ( 5.46x)
apply_bdof_10_8x16_neon: 1695.9 ( 5.23x)
apply_bdof_12_8x16_neon: 1695.4 ( 5.29x)
A78
apply_bdof_8_8x16_neon: 648.9 ( 7.43x)
apply_bdof_10_8x16_neon: 646.1 ( 7.04x)
apply_bdof_12_8x16_neon: 643.8 ( 7.04x)
apply_bdof_8_8x16_neon: 603.2 ( 7.97x)
apply_bdof_10_8x16_neon: 604.1 ( 7.52x)
apply_bdof_12_8x16_neon: 604.5 ( 7.52x)
|
|
|
|
|
|
| |
This is a newly added field, so there's no point to try and keep backwards
compatibility with an older API - newer clients should just use the new
fields.
|
|
|
|
| |
Signed-off-by: averne <[email protected]>
|