On Sat, May 10, 2025 at 9:05 AM Paul B Mahol <onemda@gmail.com> wrote:
>
>
>
> On Fri, May 9, 2025 at 11:38 PM Andrew Randrianasulu <randrianasulu@gmail.com> wrote:
>>
>> I was looking at why our application (cinelerra-gg) crashed at trying to use libplacebo
>>
>> I found that libplacebo defines itself
>>
>> https://ffmpeg.org/doxygen/7.0/vf__libplacebo_8c.html
>>
>> as
>>
>> .flags = AVFILTER_FLAG_HWDEVICE | AVFILTER_FLAG_DYNAMIC_INPUTS,
>>
>> so only output pad is defined, as far as I can see:
>>
>> static const AVFilterPad libplacebo_outputs[] = {
>> {
>> .name = "default",
>> .type = AVMEDIA_TYPE_VIDEO,
>> .config_props = &libplacebo_config_output,
>> },
>> };
>>
>>
>>
>> then when our code calls
>>
>> avfilter_pad_get_type()
>
>
> You need to call it only after filtergraph have been configured, not before because in such cases number of output pads may be 0 before configuration.
> In any case you need to check current number of input pads and output pads for each filter before trying to access them.
>
Thanks. Attached patch makes this crash go away, just 32-bit cingg
can't cope with 4k frames filtering en-masse :)
Andrea, can you test attached patch + this opts file put alongside
test 4k HDR video decodable by hardware?
Aw, tried to reduce resolution to very barest minimum allowed by hevc encoder (228*128!) and while libplacebo works (sloowly!) with software decoder, it does not produce good frames with Vulkan hw decoder (even if I seen in nvtop hw decoder really runs sometimes at close to 100%).
So, something confuses libplacebo greatly if used like this.
I also tried *_vulkan filters on input, hoping they will also pick up hw vulkan decoding device but apparently no?