Steven Liu [Mon, 3 Jul 2017 12:20:44 +0000 (20:20 +0800)]
avfomat/hlsenc: support fmp4 format in hls
add the fmp4 format into hlsenc
because the fmp4 format add into hls from version 7.
the spec link is:
https://tools.ietf.org/html/draft-pantos-http-live-streaming-20
and the describe on WWDC
https://developer.apple.com/videos/play/wwdc2017/515/
NVIDIA broke its own API when using VDPAU decoding. If you retrieve the
decoded YUV data, or if you map the surfaces with GL interop, the result
are interlacing artifacts. The only way to get non-broken data is by
using the vdpau video mixer to convert it to RGB. There is no way to
block the non-working operations in a reasonable way (a VdpVideoSurface
has to support all operations).
NVIDIA refuses to fix this issue (they "fixed" it by making it work with
the video mixer, but the rest is still broken). There is no sign of that
changing.
Do not use HEVC by default with the generic hwaccle API. Detect whether
it's the NVIDIA native implementation, and exit with an error. (The same
thing work with the MESA implementation.)
As an escape hatch and to allow applications to use the decoder if they
really want to (perhaps because they make sure to explicitly use the
video mixer), reuse AV_HWACCEL_FLAG_ALLOW_PROFILE_MISMATCH to disable
this check.
Once NVIDIA fixes the bug, working driver versions could be detected,
and it could be allowed again.
wm4 [Thu, 29 Jun 2017 13:36:55 +0000 (15:36 +0200)]
hevcdec: properly export some side data with frame threading
I noticed this with mastering display data. If frame threading is
enabled, this side data is exported only for some frames. It turns out
it's not properly propagated to the worker threads.
I didn't touch A53 captions, because that involves memory allocation and
freeing the data as side data is exported.
Micro bump so that API users can detect the bug fix.
avcodec/hevc_ps: Fix integer overflow with beta/tc offsets
Fixes: runtime error: signed integer overflow: 2113929216 * 2 cannot be represented in type 'int' Fixes: 2422/clusterfuzz-testcase-minimized-5242114713583616 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
avcodec/interplayvideo: Check ff_get_buffer() for failure
Fixes: runtime error: division by zero Fixes: 2408/clusterfuzz-testcase-minimized-5432734438653952 Fixes: 2415/clusterfuzz-testcase-minimized-4672827619803136 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
avcodec/cfhd: Fix invalid left shift of negative value
Fixes: runtime error: left shift of negative value -1 Fixes: 2395/clusterfuzz-testcase-minimized-6540529313513472 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
avcodec/vb: Check vertical GMC component before multiply
Fixes: runtime error: signed integer overflow: 8224 * 663584 cannot be represented in type 'int' Fixes: 2393/clusterfuzz-testcase-minimized-6128334993883136 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
hevc: Add support for alternative transfer characterics SEI
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.
avcodec/utvideodec: Factor multiply out of inner loop
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>
Clément Bœsch [Thu, 22 Jun 2017 09:04:26 +0000 (11:04 +0200)]
lavc/arm: fix lack of precision in ff_ps_stereo_interpolate_neon
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:
avcodec/hevcdec: do basic validity check on delta_chroma_weight and offset
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/ffmpeg Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Anton Khirnov [Thu, 22 Jun 2017 18:05:12 +0000 (20:05 +0200)]
hwframe: Allow hwaccel frame allocators to align surface sizes
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.
wm4 [Thu, 22 Jun 2017 12:52:56 +0000 (14:52 +0200)]
dxva: support DXGI_FORMAT_420_OPAQUE decoding
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.
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.
wm4 [Thu, 22 Jun 2017 12:52:53 +0000 (14:52 +0200)]
dxva: fix some warnings
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.
wm4 [Thu, 22 Jun 2017 12:52:52 +0000 (14:52 +0200)]
dxva: add declarative profile checks
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.
Martin Storsjö [Fri, 9 Jun 2017 09:05:00 +0000 (12:05 +0300)]
d3d11va: Link directly to dxgi.dll and d3d11.dll functions if LoadLibrary is unavailable
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.
wm4 [Wed, 7 Jun 2017 15:11:17 +0000 (17:11 +0200)]
dxva: add support for new dxva2 and d3d11 hwaccel APIs
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 f9e7a2f95a7194a8736cc1416a03a1a0155a3e9f.
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.
wm4 [Tue, 6 Jun 2017 16:51:10 +0000 (18:51 +0200)]
dxva: move d3d11 locking/unlocking to functions
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.
wm4 [Tue, 6 Jun 2017 16:51:09 +0000 (18:51 +0200)]
dxva: preparations for new hwaccel API
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.
wm4 [Tue, 6 Jun 2017 16:51:08 +0000 (18:51 +0200)]
lavc: set avctx->hwaccel before init
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.
wm4 [Tue, 6 Jun 2017 16:51:07 +0000 (18:51 +0200)]
lavu: add new D3D11 pixfmt and hwcontext
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.
James Almer [Mon, 26 Jun 2017 03:29:16 +0000 (00:29 -0300)]
x86inc: don't use read-only data sections on COFF targets
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>
This implements the 0x10 frame format for Interplay MVE movies. The
format is a variation on the 0x06 format with some changes. In addition
to the decoding map there's also a skip map. This skip map is used to
determine what 8x8 blocks can change in a particular frame.
This format expects to be able to copy an 8x8 block from before the last
time it was changed. This can be an arbitrary time in the past. In order
to implement this this decoder allocates two additional AVFrames where
actual decoding happens. At the end of a frame decoding changed blocks
are copied to a finished frame based on the skip map.
The skip map's encoding is a little convulted, I'll refer to the code
for details.
Values in the decoding map are the same as in format 0x06.
This implements the 0x06 frame format for Interplay MVE movies. The
format is relatively simple. The video data consists of two parts:
16 bits per 8x8 block movement data
a number of 8x8 blocks of pixel data
For each 8x8 block of pixel data the movement data is consulted. There
are 3 possible meanings of the movement data:
* zero : copy the 8x8 block from the pixel data
* negative : copy the 8x8 block from the previous frame from an offset
determined by the actual value of the entry -0xC000.
* positive : copy the 8x8 block from the current frame from an offset
determined by the actual value of the entry -0x4000
Decoding happens in two passes, in the fist pass only new pixeldata is
copied, during the second pass data is copied from the previous and
current frames.
The codec expects that the current frame being decoded to still has the
data from 2 frames ago on it when decoding starts.
Interplay MVE can contain up to three different frame formats. They
require different streams of information to render a frame. This patch
changes the IP packet format to prepare for the extra frame formats.
Interplay MVE movies have a SEND_BUFFER operation. Only after this
command does the current decoding buffer get displayed. This is required
for the other frame formats. They are fixed-size and can't always encode
a full frame worth of pixeldata.
This code prevents half-finished frames from being emitted.
Paul B Mahol [Mon, 26 Jun 2017 09:29:02 +0000 (11:29 +0200)]
avcodec/utvideodec: decode to GBR(A)P
This is actually internal utvideo format.
Allows to make use of SIMD for median prediction for rgb(a) formats,
thus speeding up decoding.
Simplifies code, eases further developement and maintenance.
avcodec/jpeg2000dwt: Fix integer overflows in sr_1d97_int()
Fixes: runtime error: signed integer overflow: 1157259380 + 1157259380 cannot be represented in type 'int' Fixes: 2365/clusterfuzz-testcase-minimized-6020421927305216 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
avcodec/jpeg2000dwt: Fix integer overflow in dwt_decode97_int()
Fixes: runtime error: signed integer overflow: -163654656 * 256 cannot be represented in type 'int' Fixes: 2367/clusterfuzz-testcase-minimized-4648678897745920 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
avcodec/wavpack: Fix integer overflow in wv_unpack_stereo()
Fixes: runtime error: signed integer overflow: 2080374785 + 2080374784 cannot be represented in type 'int' Fixes: 2351/clusterfuzz-testcase-minimized-5359403240783872 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: runtime error: signed integer overflow: -2147483648 - 1 cannot be represented in type 'int' Fixes: 2339/clusterfuzz-testcase-minimized-6663164320022528 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Jun Zhao [Wed, 14 Jun 2017 02:35:20 +0000 (10:35 +0800)]
lavc/golobm: Add set_ue_golomb_long to support up to 2^32 -2.
add set_ue_golomb_long to support up to 2^32-2.
Reviewed-by: Mark Thompson <sw@jkqxz.net> Reviewed-by: Michael Niedermayer <michael@niedermayer.cc> Signed-off-by: Jun Zhao <jun.zhao@intel.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Jun Zhao [Wed, 14 Jun 2017 02:22:10 +0000 (10:22 +0800)]
lavc/put_bits: Add put_bits64() to support up to 64 bits.
put_bits64() can write up to 64 bits into a bitstream.
Reviewed-by: Mark Thompson <sw@jkqxz.net> Reviewed-by: Michael Niedermayer <michael@niedermayer.cc> Signed-off-by: Jun Zhao <jun.zhao@intel.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
avcodec/hevcdec: check ff_init_cabac_decoder() for failure
Fixes: runtime error: left shift of 1965559808 by 4 places cannot be represented in type 'int' Fixes: 2333/clusterfuzz-testcase-minimized-5223935677300736 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Reviewed-by: Paul B Mahol <onemda@gmail.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
projects / ffmpeg / log