If we are leaving device_selector out of aboard - how we then specify device & context type?
In future on Win/Lin there will possible situation when we should support SYCL/ DX11/VA/OCL and others preprocessing together

I still recommend to reconsider IDeviceSelector approach to do not brake GAPI API in future

many changes in this files are just reverting back of CustomParseSSD

I'd propose to accumulate it into single struct because they are used and initialized together

GAPI_Assert

ok

I'd put the layer name here as well.
Probably even path to the model in order to identify which one of infer nodes failed

good idea, thanks. I'll add LOG here with detailed description

What about precision? Will it work if user passes FP16 data?

i checked - it works in both cases

Yep, since it works only with Frame there is only U8 can be.

Can't imagine how it's possible

all is possible in production
or after refactoring this component

Don't about this assert

About what then?

What about precision? I guess it must be U8, since NV12.

i'm not sure how to use it in preproc, because VPP doesn't have this option

In fact, is_applicable was already called from InputFrameDesc in outMeta.

this is another is_applicable which tests if frame is VPL frame or not

ok

I don't like idea about this function existence at all - see my comment about DeviceSelector https://github.com/opencv/opencv/pull/21688/files#r820065528
I propose new function setExecutionDevices (IDeviceSelector selector) as complete solution instead:
And then somewhere in GIEBackend

std::vector<RemoteContext> rctx_array;
for ( auto [d,c] : selector) 
{
rctx_array.push_back(CreateRemoteContext(d,c));
}
std::vector<IPreprocEngine> preproc_array;
for ( auto [d,c] : selector) 
{
preproc_array.push_back(CreatePreprocEnginet(d,c));
}

But when the team is afraid about IDeviceSelector introducing and and if they agree about renaming and some other modification to this part - i will apply it, let's waiting for other feedback

thanks, but current code has more vast covering when it sticks documented logic in parsing layout description: my idea is - since layout is introduced (and documented) then we must adhere its meaning despite on any verbal considerations about behavior

good idea, thanks. I'll add LOG here with detailed description

all is possible in production
or after refactoring this component

i'm not sure how to use it in preproc, because VPP doesn't have this option

this is another is_applicable which tests if frame is VPL frame or not

InputFramesDesc

Consider removing

Discussed online

BTW, why don't you just leave:

std::unordered_map<std::string, cv::GFrameDesc> vpp_preproc_map;

and

cv::GFrameDesc configureVPPPreprocDesc(const IE::TensorDesc& desc) {
    const auto& dims = desc.getDims();
    return GFrameDesc{MediaFormat::NV12, cv::Size(dims[3], dims[2])};
}
for (auto &&it : ade::util::zip(ade::util::toRange(uu.params.input_names),
                                              ade::util::toRange(in_metas))) {
    ...
    if (preproc_engin_impl && cv::holds_alternative<cv::GFrameDesc>()) {
        vpp_preproc_map.emplace(input_name, configureVPPPreprocDesc(ii->getTensorDesc()));
    }
}

I'd also accumulate this map and vpp_preproc_engine to some single place.

class VPPPreprocUnit {
    std::unordered_map<string, MediaFrame>         out_keep_alive_frames;
    std::shared_ptr<cv::gapi::wip::IPreprocEngine> preproc_engine_impl;
    std::unodered_map<string, GFrameDesc>          vpp_preproc_map
}

1. it is intended to be a replacements for IE::InputInfo:Ptr and IE::InputInfo::CPtr without ugly if for load & import
2. it's not supposed to be a VPL/VPP specific preproc_map but input description for possible other preprocess engines

also, because current GIEbackend implementations requires refactoring anyway - i think it is not goof idea to make suggestions about such cosmetic changes before overall refactoring taken place

Extra line

removed

It looks like both for() from if() and else() have the same code. We have reshape option for load and non_const_prepm for import. But inputs will look ugly. MB need to refactor this code.

Does this code deserve own function which will wrap if(load){} else{import} case? Numbers of Mat\Frame inputs in ctx can bring difficulties.

You can also divide the graph inputs:

cv::GOpaque<cv::Rect> in_roi;
auto inputs = cv::gin(cap);
auto graph_inputs = cv::GIn(in);
if (!opt_roi.has_value()) {
    in_roi = custom::LocateROI::on(in);
} else {
    graph_inputs += cv::GIn(in_roi); // <------------------------------- here
    inputs += cv::gin(opt_roi.value())[0]);
}
auto blob = cv::gapi::infer<custom::FaceDetector>(roi, in);
cv::GArray<cv::Rect> rcs = cv::gapi::parseSSD(blob, sz, 0.5f, true, true);
auto out = cv::gapi::wip::draw::render3ch(in, custom::BBoxes::on(rcs, roi));
pipeline = cv::GComputation(std::move(graph_inputs), cv::GOut(out))   // and move here
            .compileStreaming(std::move(face_detection_args));

It's just for information that, I believe, it can be done. But it's not necessary to change

IMHO:
Since vpl_preproc_device & vpl_preproc_ctx aren't used separately, I'd put them into one struct

P.S Already discussed it, consider as optional

Actually don't get how it helps.

ok, let's remove it

Don't get the idea of adding select_devices() & select_context() that are never used now

Both are part pure virtual methods of IDeviceSelector and DeviceSelector is single one whos responsible for creation Device& Context instances

Let it be, but I don't think that it makes sense to add these methods in advance (they aren't used now).

Why DeviceContextCreate is needed if we can create Device/Context via IDeviceSelector::create

because IDeviceSelector::create is protected method

IMHO overcomplicated, but hope you have a future design :)

IMHO
Why don't you group it to a single struct as well :)

don't see any benefits: because in comparison with InputFramesDescr this seems as temporary solution and should be re-designed after refactoring of giebackend has taken place.
But InputFramesDescr should survive factoring because it has got reusable part as input of ipreproc_engine at least

NRVO should work here, shouldn't it?

Despite in-param is r-value (cv::MediaFrame &&in_frame) it treated as l-value inside a function . So when you try to return it back - no NRVO has taken place for l-value here and copying would be performed.
Please find more clarified information in "Modern C++ by Meyers" in "Item 25: Use std::move on rvalue references,
std::forward on universal references"

Agree that it will be treated as l-value, but don't get why NRVO won't work here.

because conditions for NRVO are not satisfied: in_frame is not a local variable at least

Actually the copy of frame should be almost free

ok
but here we have move-operator by the way

Do frame really moves into somewhere?
I doubt this backend code owns the frame to to move it. It comes as an input, and it may go somewhere else down to the pipeline. It may still work here, though, but may give some false understanding for those reading this code in the future.

it moves back :)
Look:

cv::MediaFrame frame = ctx.inFrame(i);
frame = preprocess_frame_impl(std::move(frame));