On 30/01/18 05:40, wm4 wrote:
> On Mon, 29 Jan 2018 23:01:18 +0000
> Mark Thompson <s...@jkqxz.net> wrote:
>
>> AVCodecContext.extra_hw_frames is added to the size of hardware frame
>> pools created by libavcodec for APIs which require fixed-size pools.
>> This allows the user to keep references to a greater number of frames
>> after decode, which may be necessary for some use-cases.
>>
>> It is also added to the initial_pool_size value returned by
>> avcodec_get_hw_frames_parameters() if a fixed-size pool is required.
>> ---
>> On 26/01/18 23:39, wm4 wrote:
>>> On Fri, 26 Jan 2018 23:30:48 +0000
>>> Mark Thompson <s...@jkqxz.net> wrote:
>>>
>>>> On 26/01/18 23:13, Mark Thompson wrote:
>>>>> AVFilterContext.extra_hw_frames functions identically to the field of
>>>>> the same name in AVCodecContext.
>>>>
>>>> Of course, that field doesn't actually exist before this patch now.
>>>> Updated to reflect that.
>>>>
>>>> Still, should the field be in AVCodecContext as well? (The
>>>> hw_frames_parameters API can do this for library users, but it isn't
>>>> usable in avconv.)
>>>
>>> Probably makes sense. How else would avconv control this? (Although in
>>> theory avconv could use the avcodec_get_hw_frames_parameters() API.)
>>>
>>> I assume actually this field would just be added to the frames context
>>> returned by avcodec_get_hw_frames_parameters(), since that is used
>>> internally by most hwaccels to allocate a frames context if
>>> hw_device_ctx is used.
>>
>> Yep, that sounds like a good way to do it.
>>
>> Here is new series with that change and some other minor fixups. (Not
>> tested on Windows yet.)
>>
>> Thanks,
>>
>> - Mark
>>
>>
>> doc/APIchanges | 3 +++
>> libavcodec/avcodec.h | 14 ++++++++++++++
>> libavcodec/options_table.h | 1 +
>> 3 files changed, 18 insertions(+)
>>
>> diff --git a/doc/APIchanges b/doc/APIchanges
>> index 0bde3a052..62c7a17e5 100644
>> --- a/doc/APIchanges
>> +++ b/doc/APIchanges
>> @@ -13,6 +13,9 @@ libavutil: 2017-03-23
>>
>> API changes, most recent first:
>>
>> +2018-xx-xx - xxxxxxx - lavc 58.x+1.0 - avcodec.h
>> + Add AVCodecContext.extra_hw_frames.
>> +
>> 2017-xx-xx - xxxxxxx - lavc 58.8.0 - avcodec.h
>> Add const to AVCodecContext.hwaccel.
>>
>> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
>> index 7eaa0c927..03a3d5bd6 100644
>> --- a/libavcodec/avcodec.h
>> +++ b/libavcodec/avcodec.h
>> @@ -2739,6 +2739,20 @@ typedef struct AVCodecContext {
>> * AVCodecContext.get_format callback)
>> */
>> int hwaccel_flags;
>> +
>> + /**
>> + * Video decoding only. Sets the number of extra hardware frames which
>> + * the decoder will allocate for use by the caller. This must be set
>> + * before avcodec_open2() is called.
>> + *
>> + * Some hardware decoders require all frames that they will use for
>> + * output to be defined in advance before decoding starts. For such
>> + * decoders, the hardware frame pool must therefore be of a fixed size.
>> + * The extra frames set here are on top of any number that the decoder
>> + * needs internally in order to operate normally (for example, frames
>> + * used as reference pictures).
>> + */
>> + int extra_hw_frames;
>> } AVCodecContext;
>>
>> /**
>> diff --git a/libavcodec/options_table.h b/libavcodec/options_table.h
>> index 925ef376f..4b0a8344d 100644
>> --- a/libavcodec/options_table.h
>> +++ b/libavcodec/options_table.h
>> @@ -419,6 +419,7 @@ static const AVOption avcodec_options[] = {
>> {"side_data_only_packets", NULL, OFFSET(side_data_only_packets),
>> AV_OPT_TYPE_INT, { .i64 = 1 }, 0, 1, A|V|E },
>> #endif
>> {"apply_cropping", NULL, OFFSET(apply_cropping), AV_OPT_TYPE_INT, { .i64 =
>> 1 }, 0, 1, V | D },
>> +{"extra_hw_frames", "Number of extra hardware frames to allocate for the
>> user", OFFSET(extra_hw_frames), AV_OPT_TYPE_INT, { .i64 = -1 }, -1, INT_MAX,
>> V|D },
>> {NULL},
>> };
>>
>
> Why not do this in generic code instead of every hwaccel backend?
Duh, yeah. Didn't think about that properly, will change :)
> Why not set this to the default of 4 ff_decode_get_hw_frames_ctx()
> implies?
I think we want to know whether the value is set or not. That's more visible
in lavfi where existing filters (especially libmfx) have a default value much
higher than they actually need, and I think it may want to apply to lavc as
well (if libmfx gets hw_device_ctx support and avconv_qsv goes away, say).
> Otherwise generally LGTM.
Thanks,
- Mark
_______________________________________________
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
