On 02/02/17 07:00, wm4 wrote:
> On Wed, 1 Feb 2017 21:32:21 +0000
> Mark Thompson <s...@jkqxz.net> wrote:
>
>> For use by codec implementations which can allocate frames internally.
>> ---
>> Now with explicit prohibition on the user reading either field.
>>
>>
>> doc/APIchanges | 3 +++
>> libavcodec/avcodec.h | 23 ++++++++++++++++++++++-
>> libavcodec/decode.c | 1 +
>> libavcodec/utils.c | 1 +
>> libavcodec/version.h | 2 +-
>> 5 files changed, 28 insertions(+), 2 deletions(-)
>>
>> diff --git a/doc/APIchanges b/doc/APIchanges
>> index c161618d9..694058574 100644
>> --- a/doc/APIchanges
>> +++ b/doc/APIchanges
>> @@ -13,6 +13,9 @@ libavutil: 2015-08-28
>>
>> API changes, most recent first:
>>
>> +2017-xx-xx - xxxxxxx - lavc 57.34.0 - avcodec.h
>> + Add AVCodecContext.hw_device_ctx.
>> +
>> 2017-02-01 - xxxxxxx - lavc - avcodec.h
>> Deprecate AVCodecContext.refcounted_frames. This was useful for deprecated
>> API only (avcodec_decode_video2/avcodec_decode_audio4). The new decode
>> APIs
>> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
>> index 8d8fa594a..5c3ce59b1 100644
>> --- a/libavcodec/avcodec.h
>> +++ b/libavcodec/avcodec.h
>> @@ -3093,7 +3093,8 @@ typedef struct AVCodecContext {
>> /**
>> * A reference to the AVHWFramesContext describing the input (for
>> encoding)
>> * or output (decoding) frames. The reference is set by the caller and
>> - * afterwards owned (and freed) by libavcodec.
>> + * afterwards owned (and freed) by libavcodec - it should never be read
>> by
>> + * the caller after being set.
>> *
>> * - decoding: This field should be set by the caller from the
>> get_format()
>> * callback. The previous reference (if any) will always be
>> @@ -3139,6 +3140,26 @@ typedef struct AVCodecContext {
>> * (with the display dimensions being determined by the crop_* fields).
>> */
>> int apply_cropping;
>> +
>> + /**
>> + * A reference to the AVHWDeviceContext describing the device which will
>> + * be used by a hardware encoder/decoder. The reference is set by the
>> + * caller and afterwards owned (and freed) by libavcodec - it should
>> never
>> + * be read by the caller after being set.
>> + *
>> + * This should only be used if either the codec device does not require
>> + * hardware frames or any that are used are allocated internally by
>> + * libavcodec. If the user wishes to supply any of the frames used as
>> + * encoder input or decoder output then hw_frames_ctx should be used
>> + * instead.
>> + *
>> + * - decoding: This field should be set by the caller from the
>> get_format()
>> + * callback. The previous reference (if any) will always be
>> + * unreffed by libavcodec before the get_format() call.
>> + *
>> + * - encoding: This field should be set before avcodec_open2() is
>> called.
>> + */
>> + AVBufferRef *hw_device_ctx;
>
> I'm getting confused about what we want here. Wouldn't it be better to:
> - make this field freely accessible, except read-only after
> avcodec_open2() is called
> - do not allow get_format to change the device, and require the user to
> hw_frames_ctx instead
Hmm. I'm being inappropriately influenced by the design of avconv, where for
hwaccels it's easier to set the device in get_format(). Yes, this definition
makes more sense; changing the device is only going to happen in insane cases.
> We have 2 use cases for this field:
> - wrappers for "full" decoders - these generally can't change the
> device, or it's not a use-case for which we need to make their
> implementations more complex
Urgh, I didn't mean to remove the before-open2 case completely.
I think I agree with the change to only support one reference at the beginning
- supporting both an initial reference and changes in get_format() requires
somewhat more tricky logic in the decoder managing the references for no
obvious gain. New patch soon...
> - hwaccels - for these we provide the API for convenience, and
> complexer interactions can be implemented by setting hw_frames_ctx
> manually
Yeah.
> For the hwaccel case, we could in particular provide an API which
> returns codec- or profile-specific parameters like surface format and
> surface count, which would make changing to hw_frames_ctx rather
> unproblematic for a user.
I do think this API would be useful, but also mostly orthogonal to the use here.
_______________________________________________
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
