ffmpeg CLI pixel format selection for filtering currently special-cases
MJPEG encoding, where it will restrict the supported list of pixel
formats depending on the value of the -strict option. In order to get
that value it will apply it from the options dict into the encoder
context, which is a highly invasive action even now, and would become a
race once encoding is moved to its own thread.
The ugliness of this code can be much reduced by moving the special
handling of MJPEG into ofilter_bind_ost(), which is called from encoder
init and is thus synchronized with it. There is also no need to write
anything to the encoder context, we can evaluate the option into our
stack variable.
There is also no need to access AVCodec at all during pixel format
selection, as the pixel formats array is already stored in
OutputFilterPriv.
When -pix_fmt designates a BE/LE pixel format, it gets translated into
the native one by av_get_pix_fmt(). This may not always be the best
choice, as the encoder might only support one endianness. In such a
case, explicitly choose the endianness supported by the encoder.
While this is currently redundant with choose_pixel_fmt() in
ffmpeg_filter.c, the latter code will be deprecated in following commits.
AVISYNTH_INTERFACE_VERSION 10 fell in-between the releases of
3.7.2 and 3.7.3, and is required to be able to read the channel
layout information.
Signed-off-by: Stephen Hutchinson <qyot27@gmail.com>
This cannot beat the Zbb implementation, and it is unlikely that a real
meaningful CPU design would support V and not Zbb. The best loop rewrite
that I could come up with (4 shifts, 2 ands, 3 ors) is still ~40% slower
than Zbb.
A proper faster vector implementation should be feasible with the
cryptographic vector extensions, but that is a story for another time.
The code was blindly assuming that Zbb or V implied Zba. While the
earlier is practically always true, the later broke some QEMU setups,
as V was introduced earlier than Zba.
I cannot find the spec, but according to the original commit
d4fdba0df7, it's CAVS. e571305a71 changed it to AVS by
accident. Ten years on, nothing happened. We still have the
sample [1], however, since there is no cavs_mp4tofoobar bsf, the
cavs decoder doesn't work. I don't know if there is any use case.
[1] https://samples.ffmpeg.org/AVS/AVSFileFormat/AVSFileFormat.mp4
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
Even though they have the same size, and typically the same alignment,
uint32_t and float are under no circumstances compatible types in C.
The casts from float * to uint32_t * are invalid here. Insofar as the
resulting pointers are dereferenced, this is undefined behaviour.
This patch uses av_float2int() / av_int2float() instead.
Except for add_squares, telling the compiler that the output vector(s)
cannot alias helps quite a bit (cycles on SiFive U74-MC):
ps_add_squares_c: 98277.7
ps_add_squares_r: 98320.2
ps_hybrid_analysis_c: 3731.2
ps_hybrid_analysis_r: 2495.7
ps_hybrid_analysis_ileave_c: 20478.0
ps_hybrid_analysis_ileave_r: 16092.2
ps_hybrid_synthesis_deint_c: 19051.5
ps_hybrid_synthesis_deint_r: 15420.0
ps_mul_pair_single_c: 122941.2
ps_mul_pair_single_r: 91035.0
Encoders (usually) have no business modifying frame->data
(which need not be writable), so they should use the appropriate
pointers.
Reviewed-by: Tomas Härdin <git@haerdin.se>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Also allocate the AVFrame during init and use av_frame_replace()
to replace it later.
Reviewed-by: Tomas Härdin <git@haerdin.se>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
A private class for an encoder without options is useless.
Reviewed-by: Tomas Härdin <git@haerdin.se>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
