Xiang, Haihao:
> On Fri, 2021-12-24 at 03:20 +0100, Andreas Rheinhardt wrote:
>> Xiang, Haihao:
>>> On Fri, 2021-09-24 at 18:37 +0200, Andreas Rheinhardt wrote:
>>>> Signed-off-by: Andreas Rheinhardt <andreas.rheinha...@outlook.com>
>>>> ---
>>>> libavcodec/tests/avcodec.c | 38 ++++++++++++++++++++++++++++++++++++++
>>>> 1 file changed, 38 insertions(+)
>>>>
>>>> diff --git a/libavcodec/tests/avcodec.c b/libavcodec/tests/avcodec.c
>>>> index 5512ae99f7..e26315c368 100644
>>>> --- a/libavcodec/tests/avcodec.c
>>>> +++ b/libavcodec/tests/avcodec.c
>>>> @@ -19,6 +19,7 @@
>>>> #include "libavutil/opt.h"
>>>> #include "libavcodec/codec.h"
>>>> #include "libavcodec/codec_desc.h"
>>>> +#include "libavcodec/internal.h"
>>>>
>>>> static const char *get_type_string(enum AVMediaType type)
>>>> {
>>>> @@ -78,11 +79,26 @@ int main(void){
>>>> if (codec->channel_layouts || codec->sample_fmts ||
>>>> codec->supported_samplerates)
>>>> ERR("Non-audio codec %s has audio-only fields set\n");
>>>> + if (codec->capabilities & (AV_CODEC_CAP_SMALL_LAST_FRAME |
>>>> + AV_CODEC_CAP_CHANNEL_CONF |
>>>> + AV_CODEC_CAP_VARIABLE_FRAME_SIZE))
>>>> + ERR("Non-audio codec %s has audio-only capabilities
>>>> set\n");
>>>> }
>>>> if (codec->type != AVMEDIA_TYPE_VIDEO) {
>>>> if (codec->pix_fmts || codec->supported_framerates)
>>>> ERR("Non-video codec %s has audio-only fields set\n");
>>>> + if (codec->caps_internal & FF_CODEC_CAP_EXPORTS_CROPPING)
>>>> + ERR("Non-video codec %s exports cropping\n");
>>>> }
>>>> + if (codec->caps_internal & FF_CODEC_CAP_SLICE_THREAD_HAS_MF &&
>>>> + !(codec->capabilities & AV_CODEC_CAP_SLICE_THREADS))
>>>> + ERR("Codec %s wants mainfunction despite not being "
>>>> + "slice-threading capable");
>>>> + if (codec->caps_internal & FF_CODEC_CAP_AUTO_THREADS &&
>>>> + !(codec->capabilities & (AV_CODEC_CAP_FRAME_THREADS |
>>>> + AV_CODEC_CAP_SLICE_THREADS |
>>>> + AV_CODEC_CAP_OTHER_THREADS)))
>>>> + ERR("Codec %s has private-only threading support\n");
>>>>
>>>> is_decoder = av_codec_is_decoder(codec);
>>>> is_encoder = av_codec_is_encoder(codec);
>>>> @@ -103,6 +119,19 @@ int main(void){
>>>> ret = 1;
>>>> }
>>>> }
>>>> + if (codec->caps_internal & (FF_CODEC_CAP_ALLOCATE_PROGRESS |
>>>> + FF_CODEC_CAP_SETS_PKT_DTS |
>>>> + FF_CODEC_CAP_SKIP_FRAME_FILL_PARA
>>>> M |
>>>> + FF_CODEC_CAP_EXPORTS_CROPPING |
>>>> + FF_CODEC_CAP_SETS_FRAME_PROPS) ||
>>>> + codec->capabilities & (AV_CODEC_CAP_AVOID_PROBING |
>>>> + AV_CODEC_CAP_CHANNEL_CONF |
>>>> + AV_CODEC_CAP_DRAW_HORIZ_BAND |
>>>> + AV_CODEC_CAP_SUBFRAMES))
>>>> + ERR("Encoder %s has decoder-only capabilities set\n");
>>>> + if (codec->capabilities & AV_CODEC_CAP_FRAME_THREADS &&
>>>> + codec->capabilities & AV_CODEC_CAP_ENCODER_FLUSH)
>>>> + ERR("Frame-threaded encoder %s claims to support
>>>> flushing\n");
>>>
>>> I didn't see such requirement in codec.h and wonder why the two flags can't
>>> coexist, could you please provide a little more explanation ?
>>>
>>
>> The only reason for this is that it is not implemented to flush an
>> encoder that uses frame threads.
>> (Do you have any specific encoder in mind?)
>
> Thanks for the answer.
>
> ( There is a patch (
> https://patchwork.ffmpeg.org/project/ffmpeg/patch/1564549538-25724-1-git-send-email-linjie...@intel.com/
> ) to support variable resolution encode, and the revised version (
> https://github.com/intel-media-ci/cartwheel-ffmpeg/blob/master/patches/0011-fftools-ffmpeg-support-variable-resolution-encode.patch
> , which is not sent to ML yet) added AV_CODEC_CAP_ENCODER_FLUSH to
> ff_rawvideo_encoder, and recently AV_CODEC_CAP_FRAME_THREADS was added to
> ff_rawvideo_encoder in FFmpeg, so this error was triggered in testing)
>
> BRs
> Haihao
>
1. AV_CODEC_CAP_ENCODER_FLUSH has actually been added for encoders for
which closing and reopening is prohibitively expensive; the rawvideo
encoder is the exact opposite of this.
2. The unimplemented frame-threaded part of flushing an encoder is
roughly as follows: Wait until all the worker threads have finished
encoding what they have and discard the result.
3. I don't know whether it is desired to update the values set during
init based upon the new parameters. If so, the update_thread_context
would need to be repurposed, but this is probably more complicated than
simply adding flushing to frame threaded encoders.
- Andreas
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
