Invalid buffer ids are defined by VA_INVALID_ID. Use that through out
vaapi_*.c support files now that we have private data initialized and
managed by libavcodec. Previously, the only requirement for the public
vaapi_context struct was to be zero-initialized.
This fixes support for 3rdparty VA drivers that strictly conform to
the API whereby an invalid buffer id is VA_INVALID_ID and the first
valid buffer id can actually be zero.
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Move libavcodec managed objects from the public struct vaapi_context
to a new privately owned FFVAContext. This is done so that to clean up
and streamline the public structure, but also to prepare for new codec
support, thus requiring new internal data to be added in there.
The AVCodecContext.hwaccel_context, that holds the public vaapi_context,
shall no longer be accessed from within vaapi_*.c codec support files.
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Deprecate older VA pixel formats (MOCO, IDCT) as it is now very unlikely
to ever be useful in the future. Only keep plain AV_PIX_FMT_VAAPI format
that is aliased to the older VLD variant.
This is an API change.
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Currently, when forcing an I frame, via API, or via the ffmpeg cli,
using -force_key_frames, we still let x264 decide what sort of
keyframe to user. In some cases, it is useful to be able to force
an IDR frame, e.g. for cutting streams.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
* commit '7bf9647264308d2df74b2b50669f2d02a7ecc90b':
vp7: bound checking in vp7_decode_frame_header
Only partially merged, see 46f72ea507
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit 'f34b152eb7b7e8d2aee57c710a072cf74173fbe1':
libfdk-aacdec: Clean up properly if the init fails
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit '87de6ddb7b7674e329d5c96677bd8685bc7f7855':
libfdk-aacdec: Bump the max number of channels to 8
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
The h264 decoder reports 4.1 as its maximum level, but it will decode
5.1 4K video just fine. In practice, the published level limits in
vdpau do not communicate anything that's actually useful.
Previously most of the error paths leaked.
Also add FF_CODEC_CAP_INIT_THREADSAFE while adding caps_internal;
this decoder wrapper doesn't have any static data that is initialized.
Signed-off-by: Martin Storsjö <martin@martin.st>
For ADTS streams, the output format (number of channels, frame size)
can change at any point (with the latest version of fdk-aac, the decoder
seems to change format after a handful of frames, not outputting the
right format immediately, for cases that worked fine with the earlier
version of the lib).
Previously, the decoder decoded straight into the output frame once the
number of channels and frame size was known. This obviously does not
work if the number of channels or frame size changes.
The alternative would be to allocate the AVFrame with the maximum number
of channels and frame size, and change them afterward decoding into it,
but that may cause confusion to users e.g. of the get_buffer callback.
This solution should be more robust.
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>
In the latest version of fdk-aac, the decoder can output up to 8
channels; take this into account when preallocating buffers that
need to fit the output from any packet.
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>
The value of wrap_flag in the Text Wrap Box specifies if the text is to
be wrapped or not. Uses 'end of line wrap' amongst the wrap styles
supported by ASS if the text is to be wrapped, i.e; fill as much text
in a line as possible, then break to next line.
The 3GPP spec has no provision for smart wrapping.
Signed-off-by: Niklesh <niklesh.lalwani@iitb.ac.in>
As suggested, posting the combined patch with the fate changes.
The patch sets the default style in ASS from the default style
information present in the movtext header.
Signed-off-by: Niklesh <niklesh.lalwani@iitb.ac.in>
A parser should never be called with a mismatching codec
Found-by: Ganesh Ajjanagadde <gajjanag@mit.edu>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The table is used in libavutil/eval.c.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Don't try to do a blocking wait for MMAL output if we haven't even sent
a single real packet, but only flush packets. Obviously we can't expect
to get anything back.
Additionally, don't send a flush packet to MMAL in the same case. It
appears the MMAL decoder will sometimes hang in mmal_vc_port_disable()
(called from ffmmal_close_decoder()), waiting for a reply from the GPU
which never arrives. Either MMAL disallows sending flush packets without
preceding real data, or it's a MMAL bug.
I can't come up with a nice way to handle this. It's hard to keep the
lock-stepped input/output in this case. You can't predict whether the
MMAL decoder will output a picture (because it's asynchronous), so
you have to assume in general that any packet could produce 0 or 1
frames. You can't continue to write input packets to the decoder,
because then you might get too many output frames, which you can't
get rid of because the lavc decoding API does not allow the decoder
to return an output frame without consuming an input frame (except
when flushing).
The ideal fix is a M:N decoding API (preferably asynchronous), which
would make this code potentially much cleaner. For now, this hack
will do.
The .text section is already 16-byte aligned by default on all supported
platforms so `SECTION_TEXT` isn't any different from `SECTION .text`.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Change ALLOC_STACK to always align the stack before allocating stack space for
consistency. Previously alignment would occur either before or after allocating
stack space depending on whether manual alignment was required or not.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
As well as tables littered everywhere, functions were spread
out all across the encoder's files. This moves them to a single
place where they can be used by either the encoder's main files
or additional encoder files. Additionally, it changes the type
of some to 'inline' to enable us to simply put them in a header
file and possibly gain some speed due to compiler optimizations.
Signed-off-by: Claudio Freire <klaussfreire@gmail.com>
* commit '1542ec96389f32e5081c6c607e4b6f5e257ccdf2':
cosmetics: Drop spurious spaces from if clauses
Conflicts:
libavcodec/vc1_block.c
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit '0f562f5b833d603e04123d198c59f8b2b5eb43e4':
h264: Do not print an error when the buffer has to be refilled
Conflicts:
libavcodec/h264.c
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
The commit broke sub-movtext and sub-subripenc
fate output differs between mips ad x86 so updating fate ref is not
possible
This reverts commit d670848d4c.
* commit '9469370fb32679352e66826daf77bdd2e6f067b5':
h264: Use AVERROR return codes instead of -1
Only partially merged, as the first hunk is not correct and would result
in endless log spam.
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
This commit moves any tables specific to the encoder from aacenc
and aaccoder to a separate file called 'aacenctab.c/.h'.
This was done as a clean up attempt as the encoder was filled with
tables pasted in between functions which made it confusing to follow
and track where each table and definition had been used.
This commit solves this by simply exporting the smaller tables out to
the aacenctab.h while the larger ones are compiled using aacenctab.c
and are referenced from the header file.
Signed-off-by: Claudio Freire <klaussfreire@gmail.com>
At least the new videotoolbox decoder does not actually set a frame if
end_frame fails. This causes the API to return success and signals that
a picture was decoded, even though AVFrame->data[0] is NULL.
Fix this by propagating end_frame errors.
Avoid duplicating the literal numeric values
Reviewed-by: "Ronald S. Bultje" <rsbultje@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Change ALLOC_STACK to always align the stack before allocating stack space for
consistency. Previously alignment would occur either before or after allocating
stack space depending on whether manual alignment was required or not.
This is the same fix that Hendrik made to dxva2_hevc. It should be
equally required here, although I don't see any visual difference.
Nevertheless, best to stay consistent.
The latest nvidia 355.06 drivers fixes the interleaving bug when
video surfaces are rendered. It still seems to be broken for
read-back with getBits but that's sufficiently uninteresting that
I don't think we need to wait for it to remove the flag.
Only two functions that use xop multiply-accumulate instructions where the
first operand is the same as the fourth actually took advantage of the macros.
This further reduces differences with x264's x86inc.
Reviewed-by: Ronald S. Bultje <rsbultje@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
ucNumDeltaPocsOfRefRpsIdx needs to contain the flat value from the SPS RPS,
and not the final computed value from the slice header RPS, as this calculation
is done internally by the driver again.
Sample-Id: http://trailers.divx.com/hevc/Sintel_4k_27qp_24fps_1aud_9subs.mkvi
* commit '979cb55103fa8e8274806e496901203742c686d1':
hevc: Split the sei parsing in 3 functions
Conflicts:
libavcodec/hevc_sei.c
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit '043f46f5741e1a5caedf55d788e1a72aae3b7605':
hevc: Use switch instead of if-nests in decode_nal_sei_message
Conflicts:
libavcodec/hevc_sei.c
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit '2cd841c0776535be56e4db67485fdd9509c9b9f4':
hevc: Use a proper enum for the SEI values
Conflicts:
libavcodec/hevc_sei.c
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
There is an SSE2 implementation so the SSE version is never used. The "SSE"
version also happens to contain SSE2 instructions on x86-64.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
This commit adds a short description to the aac_coder option of the
AAC encoder in order to be consistent with the other options.
Generally, right now, the 'FAAC' method works fine with speech and
low broadband spectrum audio. 'Fast' is just as the name suggests.
'ANMR' still needs work and 'Twoloop', the default, works well with
every type of audio.
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
Extract two methods from decode_registered_user_data in order to improve
code readability. Also make the constant holding the allocation size a
64-bit unsigned integer so that the size comparison against INT_MAX makes
sense.
Bug-Id: CID1312090
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
This commit removes a redundant argument from the functions in aaccoder.
The argument lambda was redundant as it was just a copy of s->lambda,
to which all functions have access to anyway. This cleans up the function
pointers a bit which is helpful as there are a lot of other search_for_*
functions under development and with them populated it gets messy.
Reviewed-by: Claudio Freire <klaussfreire@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
All DSD codes have 1 bit per sample.
https://en.wikipedia.org/wiki/Direct_Stream_Digital
Signed-off-by: Ihar A. Tumashyk <itumashyk@gmail.com>
Reviewed-by: Ganesh Ajjanagadde <gajjanag@mit.edu>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Needed for old compilers like GCC 4.2
Tested by trac user brad. Fixes ticket #4745
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>
