Despite '417792' being reported in the binary decoder, the buffer at
encoding time needs to be bigger to avoid running out of space due to
interlace handling.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
This was copied from the decoder, but is unneeded for the encoder.
tns_max_bands is unused and set to zero which zeroed out start, end
and size and thus no filter was actually applied.
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
Since the coefficients are stepped up to order + 1 it was possible
that it went over TNS_MAX_ORDER. Also just return in case the only
coefficient is less than the threshold.
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
The encoder-side filter isn't that important. The PSNR
shouldn't change so the FATE test should still be fine.
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
The order should never go above TNS_MAX_ORDER (and thus cause
the context to be reinitialized) but this is just in case.
Also fix a comparison, since the coefficients are zero-indexed.
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
It also made no sense to actually make the filter span the entire
window including the first band of the next window.
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
Pulses are already on the way so expect to see the list
gone in the close future.
TNS is already of sufficiently high quality to be enabled
by default (but isn't yet, so you too can help by testing!).
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
This commit abandons the way the specifications state to
quantize the coefficients, makes use of the new LPC float
functions and is much better.
The original way of converting non-normalized float samples
to int32_t which out LPC system expects was wrong and it was
wrong to assume the coefficients that are generated are also
valid. It was essentially a full garbage-in, garbage-out
system and it definitely shows when looking at spectrals
and listening. The high frequencies were very overattenuated.
The new LPC function performs the analysis directly.
The specifications state to quantize the coefficients into
four bit index values using an asin() function which of course
had to have ugly ternary operators because the function turns
negative if the coefficients are negative which when encoding
causes invalid bitstream to get generated.
This deviates from this by using the direct TNS tables, which
are fairly small since you only have 4 bits at most for index
values. The LPC values are directly quantized against the tables
and are then used to perform filtering after the requantization,
which simply fetches the array values.
The end result is that TNS works much better now and doesn't
attenuate anything but the actual signal, e.g. TNS removes
quantization errors and does it's job correctly now.
It might be enabled by default soon since it doesn't hurt and
helps reduce nastyness at low bitrates.
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
This commit removes the array which was made redundant with
the last commit. The current prediction system gets the
quantization error directly (and without the single-frame delay)
in the search_for_pred function.
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
This commit completely alters the algorithm of prediction.
The original commit which introduced prediction was completely
incorrect to even remotely care about what the actual coefficients
contain or whether any options were enabled. Not my actual fault.
This commit treats prediction the way the decoder does and expects
to do: like lossy encryption. Everything related to prediction now
happens at the very end but just before quantization and encoding
of coefficients. On the decoder side, prediction happens before
anything has had a chance to even access the coefficients.
Also the original implementation had problems because it actually
touched the band_type of special bands which already had their
scalefactor indices marked and it's a wonder the asserion wasn't
triggered when transmitting those.
Overall, this now drastically increases audio quality and you should
think about enabling it if you don't plan on playing anything encoded
on really old low power ultra-embedded devices since they might not
support decoding of prediction or AAC-Main. Though the specifications
were written ages ago and as times change so do the FLOPS.
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
This was missed when the original commits were done. FF_PROFILE_UNKNOWN
is what's in avctx->profile when no audio profile is specified.
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
This commit simply duplicates the functionality of ff_lpc_calc_coefs()
for the case of a Levinson-Durbin LPC with the only difference being
that floating point samples are accepted and the resulting coefficients
are raw and unquantized.
The motivation behind doing this is the fact that the AAC encoder
requires LPC in TNS and LTP and converting non-normalized floating
point coefficients to int32_t using SWR and again back for the LPC
coefficients was very impractical.
The current LPC interfaces were designed for int32_t in mind possibly
because FLAC and ALAC use this type for most internal operations.
The mathematics in case of floats remains of course identical.
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
This commit simply moves the TNS tables to a more appropriate
aactab.h since then they can be accessed by both the decoder
and encoder.
The encoder _shouldn't_ normally need the tables since the
specs describe a specific quantization process, but the exact
reason for this can be seen in the TNS commit following.
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
At least for vdpau, the hwaccel init code tries to check the video
profile and ensure that there is a matching vdpau profile available.
If it can't find a match, it will fail to initialise.
In the case of wmv3/vc1, I observed initialisation to fail all the
time. It turns out that this is due to the hwaccel being initialised
very early in the codec init, before the profile has been extracted
and set.
Conceptually, it's a simple fix to reorder the init code, but it gets
messy really fast because ff_get_format(), which is what implicitly
trigger hwaccel init, is called multiple times through various shared
init calls from h263, etc. It's incredibly hard to prove to my own
satisfaction that it's safe to move the vc1 specific init code
ahead of this generic code, but all the vc1 fate tests pass, and I've
visually inspected a couple of samples and things seem correct.
Signed-off-by: Philip Langdale <philipl@overt.org>
The amv one probably looks suspicious, but since it's an intra-only
codec, I couldn't possibly imagine what it would use the edge for,
and the vsynth fate result doesn't change, so it's probably OK.
The current algorithm is just "try all the combinations, and pick the best".
It's not very fast either, probably due to a lot of copying, but will do for
an initial implementation.
Signed-off-by: Donny Yang <work@kota.moe>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Assert on `avctx->codec->encode2` to avoid a SEGFAULT on the subsequent
function call.
avcodec_encode_video2() uses a similar assertion.
Calling the wrong function on a stream is a serious inconsistency
which could at other places be potentially dangerous and exploitable,
it is thus safer to stop execution and not continue with such
inconsistency after returning an error.
Commit-message-extended-by commiter
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Use a comment to list the reused tables, since it's more flexible than a
table name to keep information like this. The list will expand in later
commits.
* commit '167ea1fbf15ecefa30729f9b8d091ed431bf43bd':
xavs: Do not try to set the bitrate tolerance without a bitrate
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit 'f9ab4fe1f7c1e9d410ca5ee2c9ff8d2892aad068':
h264: Discard currently unsupported registered sei
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
Including libavutil/internal.h breaks compilation of doc/print_options.c
with MSVC due to linking avpriv_strtod/avpriv_snprintf.
This reverts part of commit 095347f.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Fixes -Wunused-function warnings when compiling with --disable-yasm on x86.
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This commit removes the last thing a Windows environment can
complain about the AAC encoder code. Leftover from an old revision.
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
Thanks to @nevcairiel for pointing this one out.
Another thing which stopped msvc from compiling.
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
When the encoder is ran without specifying -profile:a
the default avctx->profile value is -99 (FF_PROFILE_UKNOWN),
which used to be treated as AAC-LC.
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
Hotfix to deal with msvc. Sane compilers lack POSIX ffs().
It only saves a single bit or so and isn't worth it that much.
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
This commit finalizes AAC-Main profile encoding support
by implementing all mandatory and optional tools available
in the specifications and current decoders.
The AAC-Main profile reqires that prediction support be
present (although decoders don't require it to be enabled)
for an encoder to be deemed capable of AAC-Main encoding,
as well as TNS, PNS and IS, all of which were implemented
with previous commits or earlier of this year.
Users are encouraged to test the new functionality using either
-profile:a aac_main or -aac_pred 1, the former of which will enable
the prediction option by default and the latter will change the
profile to AAC-Main. No other options shall be changed by enabling
either, it's currently up to the users to decide what's best.
The current implementation works best using M/S and/or IS,
so users are also welcome to enable both options and any
other options (TNS, PNS) for maximum quality.
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
This commit implements temporal noise shaping support in the
encoder, along with an -aac_tns option to toggle it on or off
(off by default for now). TNS will increase audio quality
and reduce quantization noise by applying a multitap FIR filter
across allowed coefficients and transmit side information to the
decoder so it could create an inverse filter.
Users are encouraged to test the new functionality by enabling
-aac_tns 1 during encoding.
No major bugs are observable at this time so after a while if no
new problems appear and if the current implementation is deemed
of high enough quality and stability it will be enabled by default,
possibly at the same time the encoder has its experimental flag
removed and becomes the standard aac encoder in ffmpeg.
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
This commit permits for the use of the Main profile
in encoding. The functionality of that profile will
be added in the commits following. By itself, this
commit does not alter anything.
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
This commit moves the intensity stereo implementation
out from aaccoder and into a separate file. This was
possible using the previous commits.
This commit also drastically improves the IS implementation
by making it phase invariant e.g. it will always choose the
best possible phase regardless of whether M/S coding is on
or most of the coefficients have identical phases.
This also increases the quality and reduces any distortions
introduced by enablind intensity stereo.
Users are encouraged to test it out using the -aac_is 1
parameter as it has always been.
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
This commit updates the function definitions in the aaccoder_mips.c
file. This was broken around a month or so ago with the addition
of the rounding argument.
The previous commit in this series also introduced a separate array
to put the quantization error in, this also needed to be updated,
albeit non-functional, in the MIPS optimized aaccoder file.
Credits for the rounding goes to Claudio Freire.
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
This commit moves the quantizer to a separate header file.
This allows the quantizer to be used from a separate files outside
of aaccoder without having to put another function pointer and will
result in a slight speedup as the compiler can do more optimizations.
This is required for commits following.
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
This commit only creates and initializes an LTP
context which is needed for upcoming commits (TNS).
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
This commit simply populates the table pointer which is needed
for upcoming commits (TNS, prediction, etc.). Copied from
the decoder.
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
This commit moves the resetting of special bands (above RESERVED_BT)
to the main frame encoding function rather than the way it was done
previously in their corresponding search_for_... functions.
The reason why special bands need to be reset is that while normal
bands get chosen for every frame by the coder (twoloop by default)
the coders do not touch any special sfbs and will therefore
make them persist throughout the file.
If we zero them out any bands left unmarked will be chosen by
the second part of the coder (the trellis function in aaccoder.c).
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
This commit only changes the coding style to a saner way
of accessing coefficients (makes more sense to get the
memory address of a coefficients and start from there
rather than adding arbitrary numbers to offset a pointer).
Some compilers might detect an out of bounds access easier.
Also the way M/S and IS coefficients are calculated has been
changed, but should still have the same result (with the exception
that IS now applies from the normal coefficients rather than the
pristine ones, this is needed for upcoming commits).
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
Fixes a -Wunused-variable while compiling with --disable-yasm on x86
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
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>
2nd channel makes sense only for CPE type.
Skip 2nd channel in preparation for resampler (in spectral_to _sample())
depending on block type.
Fixes fate failure with clang ftrapv.
Signed-off-by: Nedeljko Babic <nedeljko.babic@imgtec.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This makes it possible to remove more coded_frame usage without breaking the
publically visible coded_frame
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* commit 'd75b55635a02444c2f188c26e431a1cec992babe':
dxva2/d3d11va: Set _WIN32_WINNT to 0x0602 instead of 0x0600
Merged-by: Michael Niedermayer <michael@niedermayer.cc>
This commit replaces the 1 microsecond delay by 500 microsecond for the
case when the MFX library does return MFX_WRN_DEVICE_BUSY status.
In general this warning never appears for simple encoding or
transcoding session because the GPU is so fast so it almost always is not busy and
any delay value just does not executes.
But for heavy transcoding tasks for example, when several QSV sessions
are running simultaneously then using a 1-microsecond delay may
result in 1000 iterations per each frame.
So here possible a paradoxical case when GPU loading also loads CPU by dummy tasks.
Official MFX/QSV samples by Intel are using 1 millisecond (i.e. 1000
microseconds) everywhere where MFX_WRN_DEVICE_BUSY does appear.
So 500us is a much more optimal value than 1us.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
There was fixed number of loops (2048) in preparation for resampler, so
when number of samples is smaller than this, there would be an overflow on
ret_buf.
For some reason this behavior popped out only under valgrind with
--disable-memory-poisoning option.
This is now fixed and number of loops depends on actual number of samples.
Signed-off-by: Nedeljko Babic <nedeljko.babic@rt-rk.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
If _WIN32_WINNT is unset, we force it to a new enough value to
make sure the necessary definitions are visible.
When targeting Windows Phone or Windows RT, _WIN32_WINNT should
be at least 0x0602 - otherwise the windows headers themselves
can cause errors (which technically are bugs in the headers).
Raising this value here shouldn't hurt; the alternative would
be to not touch it at all if WINAPI_FAMILY is set to phone/app,
or to force setting it to 0x0602 in configure if unset (for phone/app).
Signed-off-by: Martin Storsjö <martin@martin.st>
* commit '3ee217853a6741b829a2683f49c590618891b1ab':
Support the Hap chunked frame format
Conflicts:
libavcodec/hap.h
libavcodec/hapdec.c
libavcodec/version.h
See: c7e6443441
Merged-by: Michael Niedermayer <michael@niedermayer.cc>
* commit '43dd004747fa697396b47d034a80e069facbea09':
hap: Move some per-stream setup into decoder init rather than per-frame
Conflicts:
libavcodec/hapdec.c
See: 6074956fa1
Merged-by: Michael Niedermayer <michael@niedermayer.cc>
When skip_frame is set to _NONKEY the decoder skips everything except intra
slices, which breaks frames that consist of an intra field together with any
other field type; half the frame becomes garbage. This patch fixes the issue by
letting non-intra slices through if they're part of a keyframe.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
This change will reject frames with a texture type which does not match
the stream description.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
This option is extremely codec specific and only a few codecs employ it.
Move it to codec private options instead: mpegenc family supports only 3
values, xavs and x264 use 5, and xvid has a different metric entirely.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
it is not optimal when the buffer size is well known at allocation time
This avoids a memcpy()
about 1% faster
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This parameter can be used to inform the allocation code about how much
downsizing might occur, and can be used to optimize how to allocate the
packet
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Avoid clipping due to quantization noise to produce audible
artifacts, by detecting near-clipping signals and both attenuating
them a little and encoding escape-encoded bands (usually the
loudest) rounding towards zero instead of nearest, which tends to
decrease overall energy and thus clipping.
Currently fate tests measure numerical error so this change makes
tests using asynth (which are near clipping) report higher error
not less, because of window attenuation. Yet, they sound better,
not worse (albeit subtle, other samples aren't subtle at all).
Only measuring psychoacoustically weighted error would make for
a representative test, so that will be left for a future patch.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* commit '9b4b96c0dee90d260891ec765b28f6ca15594340':
force WINAPI_FAMILY to WINAPI_FAMILY_DESKTOP_APP to be able to use dxva.h
Conflicts:
libavcodec/dxva2_internal.h
See: c5327df838
Merged-by: Michael Niedermayer <michael@niedermayer.cc>
The struct definitions in dxva.h, which are necessary in order to
actually use d3d11va, are hidden when WINAPI_FAMILY targets Windows Phone
or WindowsRT.
Building with WINAPI_FAMILY=WINAPI_FAMILY_DESKTOP_APP is disallowed
when targeting ARM. ("Compiling Desktop applications for the ARM
platform is not supported.") So we set _CRT_BUILD_DESKTOP_APP to 0
to tell the runtime not to detect some issues with this mismatching.
The same tweaks to detect if the API is available is done in dxva2_internal.h
when compiling each DXVA2/D3D11VA decoders.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The struct definitions in dxva.h, which are necessary in order to
actually use d3d11va, are hidden when WINAPI_FAMILY targets Windows Phone
or WindowsRT.
Building with WINAPI_FAMILY=WINAPI_FAMILY_DESKTOP_APP is disallowed
when targeting ARM. ("Compiling Desktop applications for the ARM
platform is not supported.") So we set _CRT_BUILD_DESKTOP_APP to 0
to tell the runtime not to detect some issues with this mismatching.
The same tweaks to detect if the API is available is done in dxva2_internal.h
when compiling each DXVA2/D3D11VA decoders.
Signed-off-by: Martin Storsjö <martin@martin.st>
Add support for fontsize in style records. The patch uses reset to
directly change back to default style instead of using closing tags,
since we are not handling the default styles right now.
Signed-off-by: Niklesh <niklesh.lalwani@iitb.ac.in>
This also switches to using a separate AVCodecContext for the inner mjpeg decoder
which is cleaner and avoids fields from being overwritten with wrong values
Fixes Ticket162
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes displaying subtitles before any CLUT has been received
Fixes Ticket153
This will of course not display these initial subtitles in the correct
color (as that is not known at that point) but they should look clean
and not corrupted
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Silences warnings when using -Wshift-overflow (GCC 6+)
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>
* commit 'bf52f773913cf74bdf0d2c8c2cb4473fa1b7801e':
lavc: add Intel libmfx-based MPEG2 decoder.
Conflicts:
configure
libavcodec/qsvdec_mpeg2.c
Some cosmetics merged, rest is related to the removed parser code and
thus not merged
Merged-by: Michael Niedermayer <michael@niedermayer.cc>
* commit '22522d9c2c69624fe4d81d61ee65a56610f22f1d':
qsvdec: fix a memleak of async_fifo
Conflicts:
libavcodec/qsvdec.c
Merged-by: Michael Niedermayer <michael@niedermayer.cc>
* commit 'aa9d15d89bb4ee8a31607d3db1b8c5334eb88d2d':
qsvdec: avoid an infinite loop with no consumed data and no output
Conflicts:
libavcodec/qsvdec.c
Merged-by: Michael Niedermayer <michael@niedermayer.cc>
This is triggerable with the HEVC decoder. It is unclear yet whether the
bug is in the calling code or the MSDK, but it seems better to check for
this in any case.
A bug was introduced in 977105407c whereby when
frame height wasn't divisible by the number of threads, pixels would be omitted
from the bottom rows during decode.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
A bug was introduced in 6b2b26e7af whereby when
frame height wasn't divisible by the number of threads, pixels would be omitted
from the bottom rows during decode.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
