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.
> > 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.
_______________________________________________
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
