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.
--
Anton Khirnov
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
