do we really need this handling here?

yes, throw exception on upper level to invoke dtor to free mfx_handle

but if the above code throws already, the upper level dtor will be called anyway - the question is whether we need the catch block.

why not just use delegating constructor to be sure that destructor will be always called if exception happens in this delegating constructor?
https://en.cppreference.com/w/cpp/language/throw

@AsyaPronina
'delegating ctor' - it used as well.
@dmatveev
The question is to print out WARN about with all summarized information about failure

But it is possible to get rid of duplicating the error message in exception rethrowing but only in case if WARN severity is always ON

Catching your own exceptions only makes debugging harder not easier - you wan't get into the place where the original exception has been thrown.

Please remove this handling and if you want some better reporting, produce logs such that when an exception is thrown, the context is clear for the reader.

Why?

two step logic:
user passed MAJOR & not-MAJOR (optional) params to create as VPL source.
VPL source inside chose several available implementations (by MAJOR params such as ACCEL type, codec and so on) in generic case. So we can got several impls inside. It is possible to select the first one of them but it also possible to introduce not-MAJOR/optional/preferrable params which allow to select preferrable implementation from availavle implementations which provide MAJOR params match already.
Amid optional params VPL version may be present ( in case of use have multiple versions).

So at first step:

1. we request VPL available Implementations using MAJOR params only
2. we printout available implementations ALL params in std::string
3. serialize string into CFG not-major params
4. use max intersection of requested not-major params from user & seriaziled implemnetation params to find the better match

If no not-major params passed then the first VPL implementation would chosen

So at first step:
we request VPL available Implementations using MAJOR params only
we printout available implementations ALL params in std::string
serialize string into CFG not-major params
use max intersection of requested not-major params from user & seriaziled implemnetation params to find the better match

This behavior sounds complicated, is this what we really have to do here? Is there a way to be a thinner wrapper over this VPL stuff?

If optional params from multiple implementation create equal max intersections with user ones, first one will be used?

@dmatveev

This behavior sounds complicated, is this what we really have to do here? Is there a way to be a thinner wrapper over this VPL stuff?

If it looks complicated: it is fully possible just use default CfgParams creation (with major by default) without any concern about optional params and fine-grained tuning

Optional params implementation is stick on already written code: parse in/from string and mfxVariant - (only operator less introduced) and comes with cheap implementation cost and functional for fine-grained tuning

@AsyaPronina

If optional params from multiple implementation create equal max intersections with user ones, first one will be used?

After set major params: vpl dispatcher then draw several implementations which matches requested CfgParams.
For example, if you choose HEVC encoding, then VPL dispatcher returns all implementations which support HEVC encoding: CPU,GPU, FPGA(?) and so on.
So current function just serialize each collected VPL implementation descriptions into string for two purposes:

• to print out this setting in LOG
• to deserialize it back into CfgParams

The latter deserialized CfgParams (of available VPL implementations) puts in intersection with optional params. And entersected ( common params) count are remembered. Each VPL implementation tested in the same way with optional params intersection. Then an implementation with MAX intersected params count would chosen in final and finish off source creation

IF no optional params are passed (95% of regular user scenarios) into VPL source during its creation than the first VPL implementation would be used (simplified case)

But, for example (5% cases), I choose optional VPL param version in my development to test & launch my decode pipeline to switch off my-custom debug and ordinary vpl version without recompilation. and some other debug-like, performance-like purposes or VPL-api testing. because ( in last case it looks not-finalized at the moment and might or might not come with testing & unstable features) Especially when it will turn-on TigerLake support, because at least TWO more version of VPL api would become available at that moment

where do we need this? is it debugging purposes only?

serialize to string for printout + for restoring into CfgParams to find intersection

for restoring into CfgParams to find intersection

Why do we need this at all?

this file can be ~2x shorter. :)

this bug was introduced in prev PR fixing

two step logic:
user passed MAJOR & not-MAJOR (optional) params to create as VPL source.
VPL source inside chose several available implementations (by MAJOR params such as ACCEL type, codec and so on) in generic case. So we can got several impls inside. It is possible to select the first one of them but it also possible to introduce not-MAJOR/optional/preferrable params which allow to select preferrable implementation from availavle implementations which provide MAJOR params match already.
Amid optional params VPL version may be present ( in case of use have multiple versions).

So at first step:

1. we request VPL available Implementations using MAJOR params only
2. we printout available implementations ALL params in std::string
3. serialize string into CFG not-major params
4. use max intersection of requested not-major params from user & seriaziled implemnetation params to find the better match

If no not-major params passed then the first VPL implementation would chosen

test-out user-defiend preferred params & serialized impl params to find intersercted params

and remember intersected params count to find better match (by match counts)

yes, throw exception on upper level to invoke dtor to free mfx_handle

Why GSource and not VPLSource/OneVPLSource/GVPLSource/...?

I thought about that, but cv::gapi::wip::onevpl::**VPL**Source and something like that with VPL root looks redundant

I see, good point!
I think that for user it might be easier to distinguish GVPLSource and GStreamerSource rather than cv::gapi::wip::onevpl::GSource and cv::gapi::wip::gstreamer::GSource.
So might be can introduce kind of type alias here in a namespace one-level higher to uniform source names later?

good idea
i'll add aliases into source.hpp

If optional params from multiple implementation create equal max intersections with user ones, first one will be used?

It seems that there are should be intermediate variables for codec, profile and memtype..

i tried to align it with MFX/VPL configurable params name. I mean, it's description can be used to create VPL inner-dependable creation param name. Some of them do not match with object structure

Sorry, I am bit confused with the answer
The comment was about that the code repeatedly duplicated accesses to the same fields of dec variable. Some fields (or field of field...) can be cached in intermediate variable

I got it. lets' introduce caching variables here later? because there are several comments about MACRO & renaming for entire file and I'm getting on this later in next PR series

I still don't get why do we need this. Shouldn't the plain =nullptr; just work in the class declaration?

so do we parse a string here which we generate somewhere previously?

Catching your own exceptions only makes debugging harder not easier - you wan't get into the place where the original exception has been thrown.

Please remove this handling and if you want some better reporting, produce logs such that when an exception is thrown, the context is clear for the reader.