Nothing forbids them to be in any order the muxer desires.
Fixes demuxing heif samples generated by S1II.
Tested-by: Lynne <dev@lynne.ee>
Signed-off-by: James Almer <jamrial@gmail.com>
- Changes in mov_write_video_tag function to handle APV elementary stream
- Provided structure APVDecoderConfigurationRecord that specifies the decoder configuration information for APV video content
Co-Authored-by: James Almer <jamrial@gmail.com>
Signed-off-by: Dawid Kozinski <d.kozinski@samsung.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Requested by a user. Even with autovectorization enabled, the compiler
performs a quite poor job of optimizing this function, due to not being
able to take advantage of the pmaxub + pcmpeqb trick for counting the number
of pixels less than or equal-to a threshold.
blackdetect8_c: 4625.0 ( 1.00x)
blackdetect8_avx2: 155.1 (29.83x)
blackdetect16_c: 2529.4 ( 1.00x)
blackdetect16_avx2: 163.6 (15.46x)
Can't read alignment from packet, codecpar or decoded frame linesizes, so don't
set it. My test device redmi k60 produces images in 4624x3472, not 32 aligned
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
Nikon HEIFs from a camera or NX studio include a small jpeg thumbnail in addition to
the expected HEVC thumbnails; allowing jpegs allows all thumbnails to
have an associated stream for Nikon HEIF files.
With this, Nikon HEIFs can finally be decoded without failing and the
thumbnails can be extracted into their own files.
Signed-off-by: Eric Joyner <erj@erj.cc>
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: James Almer <jamrial@gmail.com>
Prevents ffmpeg/ffprobe from erroring out when reading an HEIF that
contains multiple hvcC thumbnails (e.g. from a Nikon Z6III camera).
Before, move_read_iref_thmb() would always override the stored
thmb_item_id in the MOVContext with each new read thumbnail, causing a
stream and item_id mismatch later in mov_parse_heif_items(), resulting
in the "HEIF thumbnail doesn't reference a stream" error message.
To solve this,
- Turn thmb_item_id into an array of IDs because multiple thumbnails can
exist
- Change check in mov_parse_heif_items() to compare against all stored
thumbnail IDs to see if any item missing a stream is in the list of
thumbnail IDs.
Signed-off-by: Eric Joyner <erj@erj.cc>
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: James Almer <jamrial@gmail.com>
We need to ensure rtp sets NONBLOCK since the dtls
handshake has potentially overriden the sockets mode.
Signed-off-by: Jack Lau <jacklau1222@qq.com>
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
This naive hist[p[x]]++ loop suffers badly when there are large regions of
identical values in the image, because of store-to-load forwarding delay.
Splitting up the histogram into four "parallel" histograms and processing
them one at a time speeds things up significantly, about 40% on my end.
Since psadbw only exists for 8-bits, we have to emulate it for 16-bit
inputs. The simplest sequence is to use a normal subtraction, which is safe
as long as the inputs do not exceed 32767 - so limit this implementation
to 15-bit inputs and below.
For 16-bit inputs, we could in theory instead use a pminw / pmaxw to ensure
the resulting difference does not overflow, but this is slower, and also
breaks the subsequent use of pmaddwd, so I opted to skip 16-bit SIMD for
now.
scene_sad10_c: 114175.6 ( 1.00x)
scene_sad10_avx2: 9617.7 (11.87x)
scene_sad10_avx512: 5208.8 (21.92x)
scene_sad12_c: 114537.8 ( 1.00x)
scene_sad12_avx2: 9614.0 (11.91x)
scene_sad12_avx512: 5186.3 (22.08x)
scene_sad14_c: 114113.9 ( 1.00x)
scene_sad14_avx2: 9612.9 (11.87x)
scene_sad14_avx512: 5186.0 (22.00x)
scene_sad15_c: 114108.9 ( 1.00x)
scene_sad15_avx2: 9612.3 (11.87x)
scene_sad15_avx512: 5186.4 (22.00x)
scene_sad16_c: 114136.0 ( 1.00x)
Trivial to add, but a lot faster (on my machine).
scene_sad8_c: 114476.4 ( 1.00x)
scene_sad8_sse2: 8644.3 (13.24x)
scene_sad8_avx2: 4520.1 (25.33x)
scene_sad8_avx512: 3153.0 (36.31x)
the SSL_shutdown in tls_close need call the url_bio_bwrite
so we should keep udp still alive
Signed-off-by: Jack Lau <jacklau1222@qq.com>
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
It's possible to call linker indirectly through driver like Clang. In
which cases linker args has to be prefixed with -Wl.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
This aligns declared function types in checkasm with real definition.
Fixes FATE: checkasm-{sw_rgb,sw_scale,sw_yuv2rgb,sw_yuv2yuv}
Fixes: runtime error: call to function <func> through pointer to incorrect function type
Fixes: c1a0e65763
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Skipping backwards (and even forwards) resets the EOF flag, and can thus
lead to infinite looping if the conditions are just right.
Fixes: Infinite loop
Fixes: 427538726/clusterfuzz-testcase-minimized-ffmpeg_dem_FLV_fuzzer-6582567304495104
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
Old Mingw-w64 releases provided by some distros seemingly don't have them, so
check for them and disable the dtls protocol if unavailable.
Signed-off-by: James Almer <jamrial@gmail.com>
If the image data is not at the start of the buffer allocation, such as
when the buffer has padding before the image data, this function maps too
much memory, since src_data + src_buf->size exceeds the buffer size.
Fix this by subtracting the difference between the buffer start and the
provided image data pointer from the size of the memory range to map.
An easy way to reproduce this issue is using the vf_pad filter, which
allocates image data buffers with a nonzero offset whenever padding is
requested before the start of the image data.
The issue is that:
float en[2];
...
tns->n_filt[w] = is8 ? 1 : order != TNS_MAX_ORDER ? 2 : 3;
for (g = 0; g < tns->n_filt[w]; g++) {
tns->direction[w][g] = slant != 2 ? slant : en[g] < en[!g];
When using the AAC Main profile, n_filt = 3, and slant is by
default 2 (normal long frames), g can go above 1.
en is the evolution of energy in the frequency domain for every
band at the given window. E.g. whether the energy is concentrated
at the top of each band, or the bottom.
For 2-pole filters, its straightforward.
For 3-pole filters, we need more than 2 measurements.
This commit properly implements support for 3-pole filters, by measuring
the band energy across three areas.
Do note that even xHE-AAC caps n_filt to 2, and only AAC Main allows
n_filt == 3.
Fixes https://trac.ffmpeg.org/ticket/11418
