The motion estimation code only uses block_index[0..3],
so only initialize that (just like estimate_motion_thread()
in mpegvideo_enc.c).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is not really needed, as none of the buffers allocated
in ff_mpv_common_init() are used lateron; in fact, ff_mpv_common_init()
is called with MpegEncContext.width and height equal to zero
(as well as encoding equal to zero, so that the error resilience
parts are initialized...), so that all the buffers are too small
anyway.
The call to ff_mpv_common_init() has been added in commit
f6774f905f in order to allocate
{current,last,new}_picture.f (an AVFrame). Yet this is unnecessary
since 7814dd77aa.
The only task that ff_mpv_common_init() does that may be used
is initializing the HpelDSPContext embedded in the MpegEncContext.
In fact, it was not initialized before
f6774f905f and not initializing
it passes FATE, yet I can't prove that it is indeed unnecessary.
Therefore it is still initialized and used instead of
SVQ1EncContext.hdsp.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Forgotten in 65015003f5c4b83a8202abfa7420ccf37cde6ce3;
after said commit, freeing scratchbuf on error in svq1_encode_frame()
could lead to segfaults lateron, because the buffer will not
be allocated again.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Given that the MPEG-1/2 decoders unquantize the blocks
on their own, block_last_index is only used to signal
to ff_mpv_reconstruct_mb() whether a block is skipped
or not; but this is only checked for inter macroblocks,
so it is unnecessary to set block_last_index for intra
macroblocks.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Overriding the number of coefficients is only necessary if
ac_pred is in used, not for h263_aic alone (for which only
the DC coefficient is predicted) as it is done here.
And since d50635cd24
the H.263 unquantize-intra functions override the number of
coefficients in case of ac_pred, so we don't have to do this here.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The version ident is printed on stdout for link.exe and redirecting
stdout to /dev/null will cause the output of link.exe to be paged.
This caused configure to hang for some configurations and by
extension some FATE clients. You might want to check if you run
affected configurations automated in FATE clients or similar setups.
Fixes: 45a30e0361
Signed-off-by: Martin Storsjö <martin@martin.st>
This should prevent the possibility of audio data accumulating.
The commit also cleans up and simplifies the code a bit so all frame producers
(filter_frame(), flush_frame()) functions follow similar logic as
ff_inlink_consume_frame() for the return code.
Signed-off-by: Marton Balint <cus@passwd.hu>
Easier to read, less convoluted, and ~30% faster. Most importantly, this
avoids repeating the redundant recalculation of the true peak on every
single sample, by moving the FIND_PEAK() loop out of the main loop. (Note
that FIND_PEAK() does not depend on the current sample index at all, so
there is no reason for it to ever be recomputed here)
Processes two channels in parallel, using 128-bit XMM registers.
In theory, we could go up to YMM registers to process 4 channels, but this is
not a gain except for relatively high channel counts (e.g. 7.1), and also
complicates the sample load/store operations considerably.
I decided to only add an AVX variant, since the C code is not substantially
slower enough to justify a separate function just for ancient CPUs.
Instead of having a planar array for each channel, use a single packed array.
This will help processing multiple channels in parallel, as we can directly
load all channels' data in a single load instruction.
Also improves memory locality of data, as the loop order is:
for (samples) {
for (channels) {
process sample
}
}
This patch doesn't effect WHIP usage via command, as WHIP always
needs to be explicitly specified
Signed-off-by: Jack Lau <jacklau1222@qq.com>
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
api doc: https://docs.openssl.org/1.0.2/man3/BIO_s_mem
In higher versions (openssl 1.0.2 and higher),
the function signature is BIO *BIO_new_mem_buf(const void *buf, int len),
so passing a const string doesn't cause an warnings.
However, in lower versions of OpenSSL,
the function signature becomes BIO *BIO_new_mem_buf(void *buf, int len),
which leads to warnings.
OpenSSL guarantees that it will not modify the string,
so it's safe to cast the pem_str to (void *) to avoid this warning.
Signed-off-by: Jack Lau <jacklau1222@qq.com>
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
This was requested by users of `vf_libplacebo`, to mirror the existing
option on the other `vf_scale_*` family of filters. While we have
`vf_normalize`, it was not as useful in the event that the content
stretching was actually desired.
Bridges an important usability gap between `vf_scale` and `vf_libplacebo`
that made mixing and matching the filters needlessly difficult.
This aligns the behavior of vf_libplacebo with other filters in the
vf_scale family, that forward any change in the SAR as a result of
changing the output resolution to the output frame / link, and updates
the ff_scale_adjust_dimensions() call to continue working as intended.
The new behavior reflects the documentation of vf_libplacebo, which
described this behavior despite that not being the way the filter worked
up to this point.
As an aside, also fixes a bug where the AVFrame SAR was inconsistent
with the AVFilterLink SAR when the s->nb_inputs > 1 condition was met.
Under normal circumstances, this change does not affect anything, as the vast
majority of filters either support only vulkan or only software formats.
However, when a filter supports both (such as vf_libplacebo itself, and
possibly vf_scale in the future), linking together two such filter instances
without an explicit format will default matching the input format, resulting
in a redundant round trip through host RAM.
This change bumps up AV_PIX_FMT_VULKAN to the first entry in the format list,
ensuring that it gets preferred whenever possible.
When running plain "cl", to get the MSVC version, it prints the
version header on stderr, while the usage instructions are printed
on stdout. Usually, the version on stderr gets flushed first,
so "head -n1" gets the line it expects, but some times (in particular
when running MSVC wrapped in wine), it can get the usage line
first.
Redirect stdout to /dev/null, so we only grab the version among
the lines printed to stderr. This should make the version number
grabbing more robust.
At least all relevant versions of MSVC seem to print this specifically
to stderr, not stdout (so we don't risk to miss it); checked down
to MSVC 2010.
Signed-off-by: Martin Storsjö <martin@martin.st>
