The only thing besides the hwaccel that this function uses from
AVCodecHWConfigInternal is the pixel format, which should always match
the hwaccel one.

Will be useful in following commits.

A non-limiting stream could mistakenly end up being the queue head,
which would then produce incorrect synchronization, seen e.g. in
fate-matroska-flac-extradata-update for certain number of frame threads
(e.g. 5).

Found-By: James Almer

Allows simplifying the log message.

This allows to avoid access to the underlying AVStream in many places.

It is purely internal to decoding.

It is purely internal to decoding.

Move InputStream.decoded_frame to it.

Analogous to what has been previously done for all the other major
components.

No useful information can be printed for them.

Fixes spurious new-stream warnings for unused streams after
9429624a

If the transcoding process never got to reading any packets from this
input then printing stats is just pointless noise.

Checking whether the user requested an unsupported conversion between
text and bitmap subtitles can be done immediately when creating the
output stream.

It should be the same as the one that can be extracted from the filter
and does not require access to outside data.

This function is entangled with encoder setup, so it is more encoding
code rather than ffmpeg_hw code. This will allow making more encoder
state private in the future.

This function is entangled with decoder setup, so it is more decoding
code rather than ffmpeg_hw code. This will allow making more decoder
state private in the future.

'any' stop mode is now correctly implemented for end trimming and is of limited usage.
Extend examples and other documentation of this filter.

No point to call filter_start on samples that will pass them unchanged
once initial trimming stopped.

As the comment in the code mentions, EAGAIN is not an expected value here
because we call avcodec_receive_frame() until all frames have been returned.
avcodec_send_packet() returning EAGAIN means a packet is still buffered, which
hints that the underlying decoder is buggy and not fetching packets as it
should.

An example of this behavior was in the libdav1d wrapper before f2096142,
where feeding it split frames (or individual OBUs) would result in the CLI
eventually printing the confusing "Error submitting packet to decoder: Resource
temporarily unavailable" error message, and just keep going until EOF without
returning new frames.
Signed-off-by: James Almer <jamrial@gmail.com>

The implementation was not working correctly.

Rename old peak detector to more correct name one.

Do full rewrite, new code is much faster for typical filter usages.
Also previous code was hard to follow and basically very-hard to maintain.

This patch supports the use of the "checkasm --bench" testing feature
on loongarch platform.

Change-Id: I42790388d057c9ade0dfa38a19d9c1fd44ca0bc3
Reviewed-by: Shiyou Yin <yinshiyou-hf@loongson.cn>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

yuv420_rgb24_lsx
yuv420_bgr24_lsx
yuv420_rgba32_lsx
yuv420_argb32_lsx
yuv420_bgra32_lsx
yuv420_abgr32_lsx
./configure --disable-lasx
ffmpeg -i ~/media/1_h264_1080p_30fps_3Mbps.mp4 -f rawvideo
-pix_fmt rgb24 -y /dev/null -an
before: 184fps
after:  207fps
Reviewed-by: Shiyou Yin <yinshiyou-hf@loongson.cn>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

./configure --disable-lasx
ffmpeg -i ~/media/1_h264_1080p_30fps_3Mbps.mp4 -f rawvideo -s 640x480
-pix_fmt bgra -y /dev/null -an
before: 91fps
after:  160fps
Reviewed-by: Shiyou Yin <yinshiyou-hf@loongson.cn>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

./configure --disable-lasx
ffmpeg -i 1_h264_1080p_30fps_3Mbps.mp4 -f rawvideo -y /dev/null -an
before: 214fps
after:  274fps
Reviewed-by: Shiyou Yin <yinshiyou-hf@loongson.cn>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

./configure --disable-lasx
ffmpeg -i 1_h264_1080p_30fps_3Mbps.mp4 -f rawvideo -y /dev/null -an
before: 199fps
after:  214fps
Reviewed-by: Shiyou Yin <yinshiyou-hf@loongson.cn>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>