On 06/09/17 20:52, wm4 wrote:
> On Wed, 6 Sep 2017 20:18:19 +0100
> Mark Thompson <s...@jkqxz.net> wrote:
>
>> On 06/09/17 19:14, wm4 wrote:
>>> On Wed, 6 Sep 2017 18:55:46 +0100
>>> Mark Thompson <s...@jkqxz.net> wrote:
>>>
>>>> On 06/09/17 17:29, wm4 wrote:
>>>>> On Wed, 6 Sep 2017 16:53:04 +0100
>>>>> Mark Thompson <s...@jkqxz.net> wrote:
>>>>>
>>>>>> On 06/09/17 15:37, wm4 wrote:
>>>>>>> On Tue, 5 Sep 2017 23:59:31 +0100
>>>>>>> Mark Thompson <s...@jkqxz.net> wrote:
>>>>>>>
>>>>>>>> ---
>>>>>>>> doc/APIchanges | 3 +++
>>>>>>>> libavcodec/avcodec.h | 23 +++++++++++++++++++++++
>>>>>>>> 2 files changed, 26 insertions(+)
>>>>>>>>
>>>>>>>> diff --git a/doc/APIchanges b/doc/APIchanges
>>>>>>>> index 6f70f3c96..f21dc4db0 100644
>>>>>>>> --- a/doc/APIchanges
>>>>>>>> +++ b/doc/APIchanges
>>>>>>>> @@ -14,6 +14,9 @@ libavutil: 2017-03-23
>>>>>>>> API changes, most recent first:
>>>>>>>>
>>>>>>>> 2017-xx-xx - xxxxxxx - lavc 58.x+1.0 - avcodec.h
>>>>>>>> + Add AVCodecHWConfig and AVCodec.hw_configs.
>>>>>>>> +
>>>>>>>> +2017-xx-xx - xxxxxxx - lavc 58.x+1.0 - avcodec.h
>>>>>>>> Add AV_HWACCEL_FLAG_REUSE_CONTEXT.
>>>>>>>>
>>>>>>>> 2017-xx-xx - xxxxxxx - lavfi 7.x+1.0 - avfilter.h
>>>>>>>> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
>>>>>>>> index 89e432d16..4f6b76203 100644
>>>>>>>> --- a/libavcodec/avcodec.h
>>>>>>>> +++ b/libavcodec/avcodec.h
>>>>>>>> @@ -35,6 +35,7 @@
>>>>>>>> #include "libavutil/cpu.h"
>>>>>>>> #include "libavutil/dict.h"
>>>>>>>> #include "libavutil/frame.h"
>>>>>>>> +#include "libavutil/hwcontext.h"
>>>>>>>> #include "libavutil/log.h"
>>>>>>>> #include "libavutil/pixfmt.h"
>>>>>>>> #include "libavutil/rational.h"
>>>>>>>> @@ -2773,6 +2774,19 @@ typedef struct AVProfile {
>>>>>>>> const char *name; ///< short name for the profile
>>>>>>>> } AVProfile;
>>>>>>>>
>>>>>>>> +typedef struct AVCodecHWConfig {
>>>>>>>> + /**
>>>>>>>> + * A device type which can be supplied to the codec.
>>>>>>>> + */
>>>>>>>> + enum AVHWDeviceType device_type;
>>>>>>>> + /**
>>>>>>>> + * The matching hardware pixel format which the codec can produce.
>>>>>>>> + *
>>>>>>>> + * Set to AV_PIX_FMT_NONE if no hardware pixel format is
>>>>>>>> available.
>>>>>>>> + */
>>>>>>>> + enum AVPixelFormat pix_fmt;
>>>>>>>> +} AVCodecHWConfig;
>>>>>>>> +
>>>>>>>> typedef struct AVCodecDefault AVCodecDefault;
>>>>>>>>
>>>>>>>> struct AVSubtitle;
>>>>>>>> @@ -2808,6 +2822,15 @@ typedef struct AVCodec {
>>>>>>>> const AVClass *priv_class; ///< AVClass for the
>>>>>>>> private context
>>>>>>>> const AVProfile *profiles; ///< array of recognized
>>>>>>>> profiles, or NULL if unknown, array is terminated by
>>>>>>>> {FF_PROFILE_UNKNOWN}
>>>>>>>>
>>>>>>>> + /**
>>>>>>>> + * Array of hardware configurations supported by the codec, or
>>>>>>>> NULL
>>>>>>>> + * if no hardware supported.
>>>>>>>> + *
>>>>>>>> + * The array is terminated by a configuration with a device_type
>>>>>>>> of
>>>>>>>> + * AV_HW_DEVICE_TYPE_NONE.
>>>>>>>> + */
>>>>>>>> + const AVCodecHWConfig *hw_configs;
>>>>>>>> +
>>>>>>>> /*****************************************************************
>>>>>>>> * No fields below this line are part of the public API. They
>>>>>>>> * may not be used outside of libavcodec and can be changed and
>>>>>>>>
>>>>>>>
>>>>>>> What if a decoder provides hardware decoding, but has no associated
>>>>>>> AVHWDeviceType? (Such as mmal.)
>>>>>>
>>>>>> They are in the pix_fmts list. What other information do you want?
>>>>>
>>>>> They don't necessarily output a hw format. For example, crystalhd
>>>>> (ffmpeg only) doesn't. It would also not be very uniform.
>>>>
>>>> If it doesn't require any additional setup and it outputs software frames
>>>> then it's indistinguishable from a normal software decoder; therefore,
>>>> treat it as such.
>>>>
>>>> MMAL is harder - I'm only treating the real hwaccels here because they now
>>>> have a consistent form we can make use of.
>>>>
>>>> I haven't really thought about this properly, but how about something like:
>>>>
>>>> enum AVCodecHWConfigMethod {
>>>> AV_CODEC_HW_CONFIG_METHOD_HW_DEVICE = 1,
>>>> AV_CODEC_HW_CONFIG_METHOD_HW_FRAMES = 2,
>>>> AV_CODEC_HW_CONFIG_METHOD_LEGACY_SHIT = 4,
>>>> AV_CODEC_HW_CONFIG_METHOD_MAGIC = 8,
>>>> };
>>>>
>>>> struct AVCodecHWConfig {
>>>> int methods;
>>>> enum AVHWDeviceType device_type;
>>>> enum AVPixelFormat pix_fmt;
>>>> };
>>>>
>>>> Then you would label MMAL as MAGIC, because it can just output the MMAL
>>>> frames without additional setup. VAAPI/VDPAU would be HW_DEVICE |
>>>> HW_FRAMES | LEGACY_SHIT. QSV would be HW_FRAMES | LEGACY_SHIT.
>>>
>>> That sounds OK too. Maybe we should include the information whether it's
>>> a hwaccel, i.e. something that has an actual software decoder under the
>>> hood, and that dynamic fallback/resuming HW decoding is supported?
>>
>> I was thinking that was implied by not-MAGIC, but it isn't. Yeah, that flag
>> would help. Does it actually need to be externally-visible, though?
>
> I think being explicit about it would potentially be less confusing to
> API users.
Ok, easy enough.
>>> What is LEGACY_SHIT exactly?
>>
>> "This has some arcane rules that can't be expressed here, go read the code"
>> - the old hwaccels where you have to put structure X in hwaccel_context and
>> call special function Y before you do anything.
>
> Sounds fine.
>
>>>> Is there then sufficient information for ff_get_format() to look at this
>>>> list to decide on whether it needs an AVHWAccel, and therefore eliminate
>>>> dummy hwaccels?
>>>
>>> I suspect it is. I wonder why this check is even being done at all.
>>
>> With the needs_hwaccel flag then yes.
>
> I mean, for normal hwaccel, it uses that to find the AVHWAccel.
Well, I think find by codec+pixfmt is actually fine once we know whether to
look for one or not (and removed all of the fake ones).
_______________________________________________
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
