On 31/03/17 20:12, Anton Khirnov wrote:
> Quoting Mark Thompson (2017-03-05 00:57:39)
>> Some frames contexts are not usable without additional format-specific
>> state in hwctx. This adds new functions map_frames_from and
>> map_frames_to to set this up appropriately when deriving a frames
>> context which will require it to be set.
>> ---
>> libavutil/hwcontext.c | 9 ++++++++-
>> libavutil/hwcontext_internal.h | 5 +++++
>> 2 files changed, 13 insertions(+), 1 deletion(-)
>
> This patch confuses me. Are those functions actually implemented
> anywhere in the set. I'd expect it to be right before the patch that
> makes use of it.
It's used in 18. I'll rearrange.
>>
>> diff --git a/libavutil/hwcontext.c b/libavutil/hwcontext.c
>> index 8195a7245..4a47e258a 100644
>> --- a/libavutil/hwcontext.c
>> +++ b/libavutil/hwcontext.c
>> @@ -820,7 +820,14 @@ int av_hwframe_ctx_create_derived(AVBufferRef
>> **derived_frame_ctx,
>> goto fail;
>> }
>>
>> - ret = av_hwframe_ctx_init(dst_ref);
>> + ret = AVERROR(ENOSYS);
>> + if (src->internal->hw_type->map_frames_from)
>> + ret = src->internal->hw_type->map_frames_from(dst, src, flags);
>> + if (ret == AVERROR(ENOSYS) &&
>> + dst->internal->hw_type->map_frames_to)
>> + ret = dst->internal->hw_type->map_frames_to(dst, src, flags);
>> + if (ret == AVERROR(ENOSYS))
>> + ret = 0;
>> if (ret)
>> goto fail;
>>
>> diff --git a/libavutil/hwcontext_internal.h b/libavutil/hwcontext_internal.h
>> index 66f54142e..125517215 100644
>> --- a/libavutil/hwcontext_internal.h
>> +++ b/libavutil/hwcontext_internal.h
>> @@ -92,6 +92,11 @@ typedef struct HWContextType {
>> const AVFrame *src, int flags);
>> int (*map_from)(AVHWFramesContext *ctx, AVFrame *dst,
>> const AVFrame *src, int flags);
>> + int (*map_frames_to)(AVHWFramesContext *dst_ctx,
>> + AVHWFramesContext *src_ctx, int
>> flags);
>> + int (*map_frames_from)(AVHWFramesContext *dst_ctx,
>> + AVHWFramesContext *src_ctx, int
>> flags);
>
> Wouldn't derive_frames_foo be more appropriate?
Hmm, yes. (Though derive_frames_to sounds a bit odd, it would certainly be
less confusing.)
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
