Quoting Mark Thompson (2016-02-28 23:13:37)
> On 28/02/16 21:19, Anton Khirnov wrote:
> > Quoting Anton Khirnov (2016-02-28 14:20:25)
> >> Quoting Mark Thompson (2016-02-27 19:15:34)
> >>> On 27/02/16 09:11, Anton Khirnov wrote:
> >>>> Quoting Mark Thompson (2016-02-26 00:48:11)
> >>>>> +static int hwdownload_config_input(AVFilterLink *inlink)
> >>>>> +{
> >>>>> + AVFilterContext *avctx = inlink->dst;
> >>>>> + HWDownloadContext *ctx = avctx->priv;
> >>>>> +
> >>>>> + av_buffer_unref(&ctx->hwframes_ref);
> >>>>> +
> >>>>> + if (!inlink->hw_frames_ctx) {
> >>>>> + // We allow success here in order to allow dynamic
> >>>>> reconfiguration
> >>>>> + // to do the right thing after one step. filter_frame must not
> >>>>> + // be called in this state, however.
> >>>>> + return 0;
> >>>>> + }
> >>>>> +
> >>>>> + ctx->hwframes_ref = av_buffer_ref(inlink->hw_frames_ctx);
> >>>>> + if (!ctx->hwframes_ref)
> >>>>> + return AVERROR(ENOMEM);
> >>>>> +
> >>>>> + ctx->hwframes = (AVHWFramesContext*)ctx->hwframes_ref->data;
> >>>>> +
> >>>>> + return 0;
> >>>>> +}
> >>>>
> >>>> It's not clear to me why this is needed. There is no dynamic
> >>>> reconfiguration in lavfi currently. So unless I'm missing something, you
> >>>> can just have config_output which reads the hw_frames_ctx from the input
> >>>> link.
> >>>>
> >>>> You also need to ensure that hw_frames_ctx is unset on the output link.
> >>>> For that you will probably need to modify the generic bit that copies it
> >>>> in avfilter.c, either by moving it before the config_props() call and
> >>>> then unsetting it here, or by only setting it for hwaccel formats.
> >>>
> >>> It was to handle the nasty reinit case you get with a hwaccel decoder
> >>> which sets everything up with it's software output format (probably
> >>> YUV420P), then only sets up the hwaccel format once actually running.
> >>>
> >>> Maybe it's not directly needed here, but the typically-late setting of
> >>> hw_frames_ctx made it seem like a sensible thing to allow.
> >>
> >> Ah, now I'm starting to see what the problem is. It's that avconv starts
> >> out thinking that the pixel format is sw, but only later discovers it's
> >> actually hw. And because of that the initial filter graph setup fails.
> >> Is that correct?
> >>
> >> If so, then I'd first look into making avconv behave in a more
> >> reasonable way before adding workarounds into the libs.
> >> I'll check if something can be done about this without too much work.
> >>
> >
> > A random idea -- when -hwaccel vaapi is specified for a stream, we could
> > have avconv always assume the pixfmt will be hwaccel and create the
> > device preemptively. That way it won't need to create those dummy sw
> > graphs.
> >
>
> Software fallback problems are going to be rather nasty (hardware not
> supporting some feature in one of the input streams), turning it into
> exactly the same graph reinit case in the opposite direction. (Though
> maybe it's less of a problem that way round.)
>
> That usefully prompts me into thinking about the fact that the
> software fallback isn't going to give you output in a hardware
> surface: "avconv -hwaccel vaapi -hwaccel_output_format vaapi -i ...
> -vf scale_vaapi,hwdownload ..." is going to fail on those with the
> current setup. Hence I think hwupload should become hwpossiblyupload
> (accepting the hardware format as input and passing it through with no
> change) to handle that case.
>
> Given that, not sure it's worth it? If we just say that you have to
> put a hwupload immediately after every decoder with hardware output in
> your graph (or maybe we add it automagically if that can be done in a
> nonsurprising way) then most of the configuration problem goes away.
Well, I think it's pretty clear that TheRightLongTermSolution(tm) is
extending (or possibly entirely redesigning) lavfi format negotiation to
support hwaccel formats (and ideally also fix other issues in it at the
same time). Any temporary solution we come up with right now is bound to
be suboptimal.
In light of that, I'd say that it's better to add the least possible
amount of new public API to lavfi and make avconv do the work.
Or in other words, hacks in avconv are preferable to hacks in the
libraries, because the former are easier to get rid of later.
--
Anton Khirnov
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
