Actually we always use cv::Size for that purposes since pair isn't representative

ok

This test isn't related to preprocessing, is it? Why it's in this PR then?
Honestly I didn't get the point what it actually measures here, is it resize + crop?

These tests are performance suite: it measures absolute value of execution time for different kinds of flow:
-source decode by itself
-source decode+processing (transcode)
-source decode + PPEngine (resize)
-source decode + PPEngine in bypass mode (measure pass-through PP const)

These absolute values manual comparison represents relative performance cost of components invocation

Sorry for that:
On the one hand/On the other hand

????

allows to invoke private method of testing component in UTs

BTW, why it's handled only for ROI? I believe our main use case when:

• IE device - GPU
• User passed remote context
• MediaFrame comes with VPL adapter

In that case we have to do preprocessing on our end since IE isn't able to do it for us...

In not-long time ago there was simple function SetBlob in a way SetBlob(...make_shared_blob(Blob, roi)...) which actually prepare ROI Blob from it's argument - which doesn't work in case of GPU blob
Now SetROIBlob take care about decision: prepare ROI blob (legacy way) or not (GPU approach)

Can we remember this frame somewhere in the process() (pipeline's lambdas)?

i don't think about that..
But as far i remember pipeline-lambdas was designed as pure- and is cutting from the other world and cannot receive different kind of data across session

actually it can be passed as another aggregated member of session_type::op_handle_t as well.
Moreover a subsequent PR about ROI extention follows this approach: https://github.com/opencv/opencv/pull/21554/files#diff-d281efabce2ff069582bd99d9c40e910c4386b65d60010ed9e4b106f4f2b237bR384

@rgarnov Let's move Frame into op_handle_t, what do you think ?

uh can this be done via some map lookup?

anyway it is better now than it used to be

i'm afraid it would require to introduce std::map with lambdas and to fill that lambdas in the same way as this huge if-else implemented with the same amount of conditions

Why do we need this, given that < and == are available already?

in different namespaces:
std::less which is required for std::map try to find operator< in global or std namespace and ignored cv::gapi::wip::onevpl. By this reason i use FrameInfoComparator in std::map
On the other side my UnitTests on preproc requires checking FrameInfo before and after preproc, which means i should make operator<, and operator== for FrameInfo visible as public symbols in utils.hpp which looks confusing (for me) because utils is not part of interface

On the other side, because VPPPreprocEngine is already visible (for UT) purposes and it still require operator< (because ADL doesn't work) then i put aditional operation equal_to for this comparator class and made the whole file with VPPPreprocEngine visible for UTs

it should be CRITICAL not WARNING, isn't it?

I believe @TolyaTalamanov has added it recently

Then It requires to rearrange all logger severities in namespace onevpl ( warning ->error/critical). I would implement it in the next PR including other vpl components - not preproc only

https://github.com/opencv/opencv/blob/4.x/modules/gapi/src/backends/ie/giebackend.cpp#L728

It produces a MediaFrame as output? What's the reason behind this?

it emphasizes that it produces new MediaFrame with surface from different pool (not from decoding one).
In bypass-mode (when input & output params are the same) then it is the same in_frame

Since method is called as run_sync then I suppose it must return result

P.S. It is possible to "upgrade" method for copy-elision and accept R-Value here. Something in a way:

std::string  to_lower(std::string &&str) 
{
...
return std::move(str);
}

/ ?

nice catch! it's strange but no compiles error
Aha... it's been built for Windows only in CI by now

???

mfx_handle is a global variable by now. It was implemented to overcome oneVPL issue with cloning session:

all VPL operations (decode, VPP) must belong to mfxSession context. this mfxSession holds DevicePtr, bitstream settings and some other infrastructural data. So to queue VPP preprocessing operation we must create different mfxSession wich will share some settings with decoding mfxSession and has different another's. At least both session must share the same VPL Library Implementation and version which selected in VPLSource configuration step.
The ideas was:
pass decode session object as MediaFrameAdapter data, then PreprocEngine extract it from MediaFrameAdapter in is_applicable method and perform mfxSessionClone in order to share the MAJOR session params: Implementation, Version, Decoder ID and so; then operates with VPP cloned session and forget about decode session (to avoid huge operation for mfxLoad and choosing implementation based on selected criteria, which may be diffrent from producing VPL source and so on).

But i faced with some issue in oneVPL implementation which rejects cloning session due to some inner bug.
To overcome this issue i made mfx_handle as global variable (temporary) with limitation "only single VPL Source can exist" then i just use this global mfx_handle state to create a NEW session (not as clone) from it's state.
After new VPL version releases we will reactivate idea with Cloning Session and revert such commented lines back

???