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