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_query_formats(AVFilterContext *avctx)
> > >> +{
> > >> + if (avctx->inputs[0]) {
> > >> + ff_formats_ref(ff_all_formats(AVMEDIA_TYPE_VIDEO),
> > >> + &avctx->inputs[0]->out_formats);
> > >> + }
> > >> + if (avctx->outputs[0]) {
> > >> + ff_formats_ref(ff_all_formats(AVMEDIA_TYPE_VIDEO),
> > >> + &avctx->outputs[0]->in_formats);
> > >> + }
> > >
> > > The checks are redundant, the inputs and output are guaranteed to be
> > > there. Also, this makes lavfi think this filter can convert from any
> > > format to any other format. Granted, we don't have and are not adding
> > > proper hwaccel format negotiation yet, but perhaps you could at least
> > > limit the input formats to hwaccel ones.
> >
> > The checks came from copying vf_scale - I assumed there was some case
> > where it might query only inputs or outputs. I'll remove them from
> > all the other filters too.
> >
> > Should the sets be made by running through all formats with
> > av_pix_fmt_desc_next() and splitting them into two lists depending on
> > AV_PIX_FMT_FLAG_HWACCEL, then?
>
> Yes, that's probably the most straightforward way.
>
> >
> > >> +
> > >> + return 0;
> > >> +}
> > >> +
> > >> +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.
--
Anton Khirnov
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
