Enable python nodes and ovms, geti calculators in new python lib by rasapala · Pull Request #134 · openvinotoolkit/mediapipe

rasapala · 2026-07-13T15:09:42Z

This PR aligns the MediaPipe fork with OVMS’s new Python runtime-shared architecture so CLIP Python-node graphs can load and run reliably.

Why this was needed:

OVMS moved Python calculators to dynamic/runtime-shared loading, but MediaPipe Geti/OVMS calculator deps still assumed the old in-tree/static wiring.
That caused build mismatches and runtime registration/load issues (including stale targets and duplicated proto ownership).
What was changed:

Switched Geti inference to use OVMS KServe proto (@ovms//src/kfserving_api:kfserving_api_cpp) instead of local grpc_predict_v2_* targets.
Added runtime-focused OVMS calculator targets (ovms_calculator_runtime, openvinoinferencecalculator_runtime) to support one-point calculator registration in the runtime-shared flow.
Updated OpenVINOInferenceCalculator to support runtime mode with TensorFlow/TFLite paths compile-disabled via OVMS_RUNTIME_DISABLE_TF_TENSORS and explicit guards for unsupported TF/TFLite packet tags in that mode.
Follow-up build fix removed stale grpc_predict_v2_* references from //mediapipe:geti_targets after proto ownership moved to OVMS.
Outcome:

Restores successful MediaPipe fork build in the new integration model.
Unblocks CLIP Python nodes in OVMS runtime-shared setup.
Keeps calculator registration and dependency ownership consistent between MediaPipe and OVMS.

…library solution for mediapipe.

atobiszei · 2026-07-22T13:50:37Z

 #define KSERVE_H

-#include "mediapipe/calculators/geti/inference/grpc_predict_v2.pb.h"
+#include "src/kfserving_api/grpc_predict_v2.pb.h"


Does GETI work with current changes with regards to python binding?

Need to test it.

atobiszei · 2026-07-22T13:53:15Z

 #include "mediapipe/framework/calculator_framework.h"
 #include "mediapipe/framework/port/canonical_errors.h"
 #pragma GCC diagnostic pop
+#if !defined(OVMS_RUNTIME_DISABLE_TF_TENSORS)


rename to OVMS_RUNTIME_DISABLE_TFLITE_TENSORS?

mzegla · 2026-07-22T13:57:38Z

+OVMS_Server* getInheritedServerHandleFromRuntime() {
+    using GetterFn = void* (*)();
+#ifdef _WIN32
+    HMODULE runtimeHandle = GetModuleHandleA("ovms_mediapipe_runtime_shared.dll");


Just filename? No need for path?

Yes. GetModuleHandleA looks up a already-loaded module by name in the current process's module list — it does not load from disk.

atobiszei · 2026-07-22T14:00:24Z

 )

+cc_library(
+    name = "openvinoinferencecalculator_runtime",


Maybe we could have some more meaniingful naming convention - what exactly is the meaning of "_runtime"? I see this uses additional define. Theres issue already that header does use this define but the define is in local_defines section. Any target depending on that won't inherit that define.

Since all the guards are in openvinoinferencecalculator.cc (not the header), local_defines happens to be correct scope-wise here. Renaming to openvinoinferencecalculator_no_tflite.

atobiszei · 2026-07-22T14:05:03Z

+    // Creates (once per process) and returns a shared OVMS server handle for adapters
+    // that are constructed without an explicit server pointer.
+    // This path is used by calculators running in-process when they rely on the default
+    // OVMS singleton instead of receiving a handle from runtime/shared-library plumbing.
+    // Keeping one shared handle avoids repeated OVMS_ServerNew calls and keeps all such
+    // adapters bound to the same server instance.


Earlier on the fact the only one server instance existed was due to not creating new server instance in C-API of OVMS. So if the same instance was being created depended entirely on OVMS desing. Now you add this logic also here. Why we could not call serverNewFn multiple times as earlier on?

Calling OVMS_ServerNew should still work the same way anyway. So this brings new unnecessary logic and checks here I think.

You still can use OVMS_ServerNew — and on Linux with RTLD_GLOBAL it works because symbol resolution finds the main process singleton. The setExternalServerHandle mechanism was added specifically for:

Windows — where GetModuleHandleA("ovms_mediapipe_runtime_shared.dll") + GetProcAddress is the only reliable way to pass a pointer across DLL boundaries.
Deterministic cross-boundary handoff — rather than relying on dlsym(RTLD_DEFAULT, ...) lookup ordering, which can resolve to the wrong copy if both the main binary and the runtime shared library export OVMS_ServerNew.
Issue was found in capi stress test on windows.

atobiszei · 2026-07-22T14:08:06Z

+        }
        ASSERT_CAPI_STATUS_NULL(OVMS_ServerLive(cserver, &isServerLive));
+        // if config is in calc then we start the server
+        {


Why need for additional {}?

atobiszei · 2026-07-22T14:10:07Z

    std::unordered_map<std::string, std::string> outputNameToTag;
    std::vector<std::string> input_order_list;
    std::vector<std::string> output_order_list;
+#if !defined(OVMS_RUNTIME_DISABLE_TF_TENSORS)


In what configuration we need this define? We do not add it here in .bazelrc

When building openvinoinferencecalculator_runtime — the variant used by ovms_calculator_runtime. That target drops the TF/TFLite deps (@org_tensorflow//tensorflow/core:framework and @org_tensorflow//tensorflow/lite/c:c_api) compared to the regular openvinoinferencecalculator.

The use case is when the calculator is compiled as a shared library loaded into another process (OVMS runtime-shared mode) where TensorFlow is not available or not linked. Without the define, the code would try to include and use TF/TFLite headers and types that don't exist in that build environment.

So in short: no TF dependency in the build → define needed to strip the TF/TFLite code paths.

rasapala

Made some fixes.

rasapala

Comments.

rasapala added 2 commits July 13, 2026 17:08

Enable python nodes and ovms, geti calculators in new python dynamic …

13fdb23

…library solution for mediapipe.

Fix build

23ed037

rasapala requested review from atobiszei and mzegla July 14, 2026 13:27

Fix capi ovms ownership handle

f1be143

atobiszei reviewed Jul 22, 2026

View reviewed changes

mzegla reviewed Jul 22, 2026

View reviewed changes

atobiszei reviewed Jul 22, 2026

View reviewed changes

rasapala commented Jul 23, 2026

View reviewed changes

Code review

ec9f5b3

rasapala commented Jul 23, 2026

View reviewed changes

Uh oh!

Conversation

rasapala commented Jul 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rasapala left a comment

Choose a reason for hiding this comment

Uh oh!

rasapala left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

rasapala commented Jul 13, 2026 •

edited

Loading