- 28 Jun, 2017 15 commits
-
-
Paul B Mahol authored
Signed-off-by: Paul B Mahol <onemda@gmail.com>
-
Paul B Mahol authored
Fixes #6499. 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
Fixes #6498. Signed-off-by: Paul B Mahol <onemda@gmail.com>
-
Vittorio Giovara authored
The use of this SEI is for backward compatibility in HLG HDR systems: older devices that cannot interpret the "arib-std-b67" transfer will get the compatible transfer (usually bt709 or bt2020) from the VUI, while newer devices that can interpret HDR will read the SEI and use its value instead. Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
-
Michael Niedermayer authored
0.5% faster loop Reviewed-by: Paul B Mahol <onemda@gmail.com> Reviewed-by: Steven Liu <lingjiujianke@gmail.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Michael Niedermayer authored
Reviewed-by: Paul B Mahol <onemda@gmail.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Michael Niedermayer authored
inner reader loop becomes 16% faster Reviewed-by: Paul B Mahol <onemda@gmail.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Michael Niedermayer authored
2.5% faster vlc decoding Reviewed-by: Paul B Mahol <onemda@gmail.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Michael Niedermayer authored
This is not needed when the buffer is large enough for the worst case of a line 2% faster vlc reading Reviewed-by: Paul B Mahol <onemda@gmail.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Clément Bœsch authored
-
Clément Bœsch authored
☭ tests/checkasm/checkasm --bench --test=aacpsdsp checkasm: using random seed 3318985180 MMX implied by specified flags MMX implied by specified flags NEON: - aacpsdsp.add_squares [OK] - aacpsdsp.mul_pair_single [OK] - aacpsdsp.hybrid_analysis [OK] - aacpsdsp.stereo_interpolate [OK] checkasm: all 5 tests passed nop: 10.0 ps_add_squares_c: 63221.2 ps_add_squares_neon: 22311.7 ps_hybrid_analysis_c: 2466.6 ps_hybrid_analysis_neon: 1521.9 ps_mul_pair_single_c: 68592.0 ps_mul_pair_single_neon: 17426.6 ps_stereo_interpolate_c: 72344.3 ps_stereo_interpolate_neon: 72308.8 ps_stereo_interpolate_ipdopd_c: 117415.2 ps_stereo_interpolate_ipdopd_neon: 113386.3
-
Clément Bœsch authored
-
Clément Bœsch authored
This includes various fixes and improvements from James Almer. Signed-off-by: James Almer <jamrial@gmail.com>
-
Clément Bœsch authored
The code originally pre-multiply by 2 the steps, causing the running sum of the h factors to drift away due to the lack of precision. It quickly causes an inaccuracy > 0.01. I tried diverse approaches such as multiply by 2.0 (instead of adding the value itself) without success. I'm unable to bench the impact of this change, feel free to compare. This commit fixes the incoming aacpsdsp tests. Following is an alternative simplified function (matching the incoming AArch64 code) that may be used: function ff_ps_stereo_interpolate_neon, export=1 vld1.32 {q0}, [r2] vld1.32 {q1}, [r3] ldr r12, [sp] vmov.f32 q8, q0 vmov.f32 q9, q1 vzip.32 q8, q0 vzip.32 q9, q1 1: vld1.32 {d4}, [r0,:64] vld1.32 {d6}, [r1,:64] vadd.f32 q8, q8, q9 vadd.f32 q0, q0, q1 vmov.f32 d5, d4 vmov.f32 d7, d6 vmul.f32 q2, q2, q8 vmla.f32 q2, q3, q0 vst1.32 {d4}, [r0,:64]! vst1.32 {d5}, [r1,:64]! subs r12, r12, #1 bgt 1b bx lr endfunc
-
- 27 Jun, 2017 25 commits
-
-
James Almer authored
-
Michael Niedermayer authored
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Hendrik Leppkes authored
-
Michael Niedermayer authored
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Michael Niedermayer authored
Fixes: runtime error: signed integer overflow: 2147483520 + 128 cannot be represented in type 'int' Fixes: 2385/clusterfuzz-testcase-minimized-6594333576790016 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegSigned-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Ilia Valiakhmetov authored
vp9_diag_downright_32x32_12bpp_c: 429.7 vp9_diag_downright_32x32_12bpp_sse2: 158.9 vp9_diag_downright_32x32_12bpp_ssse3: 144.6 vp9_diag_downright_32x32_12bpp_avx: 141.0 vp9_diag_downright_32x32_12bpp_avx2: 73.8 Almost 50% faster than avx implementation Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
-
James Almer authored
Process more pixels per loop. Reviewed-by: Paul B Mahol <onemda@gmail.com> Signed-off-by: James Almer <jamrial@gmail.com>
-
James Almer authored
Reviewed-by: Paul B Mahol <onemda@gmail.com> Signed-off-by: James Almer <jamrial@gmail.com>
-
Anton Khirnov authored
Hardware accelerated decoding generally uses AVHWFramesContext for pool allocation of hardware surfaces. These are setup to allocate surfaces aligned to hardware and hwaccel API requirements. Due to the architecture, av_hwframe_get_buffer() will return AVFrames with the dimensions set to the aligned sizes. This causes some decoders (like hevc) return these aligned size as final frame size, instead of cropping them to the video's actual dimensions. To make sure this doesn't happen, crop the frame to the size the decoder expects when ff_get_buffer() is called. Merges Libav commit 3fdf50f9. Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
-
wm4 authored
Helpful for debugging. Merges Libav commit 068eaa53. Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
-
wm4 authored
Basically copied from VLC (LGPL): http://git.videolan.org/?p=vlc.git;a=blob;f=modules/video_output/win32/direct3d11.c;h=e9fcb83dcabfe778f26e63d19f218caf06a7c3ae;hb=HEAD#l1482 http://git.videolan.org/?p=vlc.git;a=blob;f=modules/codec/avcodec/d3d11va.c;h=85e7d25caebc059a9770da2ef4bb8fe90816d76d;hb=HEAD#l599 Merges Libav commit cfc9e7c9. Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
-
wm4 authored
Some devices (some phones, apparently) will support only this opaque format. Of course this won't work with CLI, because copying data directly is not supported. Automatic frame allocation (setting AVCodecContext.hw_device_ctx) does not support this mode, even if it's the only supported mode. But since opaque surfaces are generally less useful, that's probably ok. Merges Libav commit 5030e385. Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
-
wm4 authored
Makes dealing with formats that can not be used for staging textures easier (DXGI_FORMAT_420_OPAQUE). It also saves memory if the staging texture is never needed, so this is a good thing. Merges Libav commit 98d73e41. Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
-
wm4 authored
It appears in this case, frames_ininit is called twice (once by av_hwframe_ctx_init(), and again by unreffing the frames ctx ref). Merges Libav commit 086321c6. Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
-
wm4 authored
Some existed since forever, some are new. The cast in get_surface() is silly, but unless we change the av_log function signature, or all callers of ff_dxva2_get_surface_index(), it's needed to remove the const warning. Merges Libav commit 752ddb45. Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
-
wm4 authored
Make supported codec profiles part of each dxva_modes entry. Every DXVA2 mode is representative for a codec with a subset of supported profiles, so reflecting that in dxva_modes seems appropriate. In practice, this will more strictly check MPEG2 profiles, will stop relying on the surface format checks for selecting the correct HEVC profile, and remove the verbose messages for mismatching H264/HEVC profiles. Instead of the latter, it will now print the more nebulous "No decoder device for codec found" verbose message. This also respects AV_HWACCEL_FLAG_ALLOW_PROFILE_MISMATCH. Move the Main10 HEVC entry before the normal one to make this work better. Originally inspired by VLC's code. Merges Libav commit 70e5e7c0. Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
-
Martin Storsjö authored
When targeting the UWP API subset, the LoadLibrary function is not available (and the fallback, LoadPackagedLibrary, can't be used to load system DLLs). In these cases, link directly to the functions in the DLLs instead of trying to load them dynamically at runtime. Merges Libav commit fd1ffa1f. Signed-off-by: Martin Storsjö <martin@martin.st>
-
wm4 authored
This also adds support to avconv (which is trivial due to the new hwaccel API being generic enough). The new decoder setup code in dxva2.c is significantly based on work by Steve Lhomme <robux4@gmail.com>, but with heavy changes/rewrites. Merges Libav commit f9e7a2f9. Also adds untested VP9 support. The check for DXVA2 COBJs is removed. Just update your MinGW to something newer than a 5 year old release. Signed-off-by: Diego Biurrun <diego@biurrun.de>
-
wm4 authored
I want to make it non-mandatory to set a mutex in the D3D11 device context, and replacing it with user callbacks seems like the best solution. This is preparation for it. Also makes the code slightly more readable. Merges Libav commit 831cfe10. Signed-off-by: Diego Biurrun <diego@biurrun.de>
-
wm4 authored
The actual hwaccel code will need to access an internal context instead of avctx->hwaccel_context, so add a new DXVA_CONTEXT() macro, that will dispatch between the "old" external and the new internal context. Also, the new API requires a new D3D11 pixfmt, so all places which check for the pixfmt need to be adjusted. Introduce a ff_dxva2_is_d3d11() function, which does the check. Merges Libav commit 4dec101a. Adds changes to vp9 over the Libav patch. Signed-off-by: Diego Biurrun <diego@biurrun.de>
-
wm4 authored
So a hwaccel can access avctx->hwaccel in init for whatever reason. This is for the new d3d hwaccel API. We could create separate entrypoints for each of the 3 hwaccel types (dxva2, d3d11va, new d3d11va), but this seems nicer. Merges Libav commit bd747b92. Signed-off-by: Diego Biurrun <diego@biurrun.de>
-
wm4 authored
To be used with the new d3d11 hwaccel decode API. With the new hwaccel API, we don't want surfaces to depend on the decoder (other than the required dimension and format). The old D3D11VA pixfmt uses ID3D11VideoDecoderOutputView pointers, which include the decoder configuration, and thus is incompatible with the new hwaccel API. This patch introduces AV_PIX_FMT_D3D11, which uses ID3D11Texture2D and an index. It's simpler and compatible with the new hwaccel API. The introduced hwcontext supports only the new pixfmt. Frame upload code untested. Significantly based on work by Steve Lhomme <robux4@gmail.com>, but with heavy changes/rewrites. Merges Libav commit fff90422. Signed-off-by: Diego Biurrun <diego@biurrun.de>
-
James Almer authored
Yasm: src/libavfilter/x86/af_volume.asm:24: warning: Standard COFF does not support read-only data sections src/libavfilter/x86/af_volume.asm:24: warning: Unrecognized qualifier `align' Nasm: src/libavfilter/x86/af_volume.asm:24: error: standard COFF does not support section alignment specification src/libavutil/x86/x86inc.asm:92: ... from macro `SECTION_RODATA' defined here Tested-by: Clément Bœsch <u@pkh.me> Signed-off-by: James Almer <jamrial@gmail.com>
-
Paul B Mahol authored
Signed-off-by: Paul B Mahol <onemda@gmail.com>
-
Hein-Pieter van Braam authored
Signed-off-by: Hein-Pieter van Braam <hp@tmm.cx>
-