Follow-up: CoT extraction from RTSP stream (libpdraw build issues)

ANAFI UKR / CHUCK 3
1

Hi everyone,

I am opening this new topic to continue the discussion from our previous thread, which was automatically closed due to inactivity: [Link to original topic: COT extraction from RTSP stream]

Context: Our goal is to extract telemetry metadata (Protobuf/vmeta) from an RTSP stream (sourced from SkyController UKR) for integration with ATAK (CoT). As previously discussed with Remi, we are targeting a NanoPi environment. Remi suggested using pdraw_coded_video_sink to extract Protobuf metadata without the CPU overhead of full video decoding.

The Problem: We are currently unable to move forward because we cannot compile libpdraw within the Alchemy build system. When scanning our workspace, Alchemy automatically disables libpdraw due to missing dependencies.

During our build process, we receive the following error logs:

Disabling libpdraw: has unknown dependency eigen

Disabling libpdraw: has unknown dependency libaac

Disabling libpdraw: has unknown dependency libaudio-decode
…
/home/user/parrot-sdk/alchemy/classes/rules.mk:11: Unknown module libphoto-metadata-defs
/home/user/parrot-sdk/alchemy/classes/rules.mk:11: Unknown module protobuf-c`

It appears our Linux-native target environment is missing the core modules required by libpdraw (protobuf-c, eigen, etc.).

Our request:

  1. Could someone provide guidance on how to properly resolve these missing dependencies within the Parrot SDK/Alchemy environment?
  2. Are there specific configuration steps we are missing to ensure Alchemy recognizes these modules?
  3. Since we are using a NanoPi, is there a recommended way to build a “minimal” version of libpdraw that only focuses on the coded video sink extraction?

We have attempted to reach out via private messages to follow up on this, but unfortunately, we haven’t received a response. We would greatly appreciate any technical insight from the community or the Parrot team to help us resolve these dependency conflicts.

Thank you in advance for your time and assistance.

Best regards,
Jindrich

2

Hello,

  1. libpdraw needs those modules,
    You can find them here: Parrot-Developers repositories · GitHub
    Or follow the installation procedure here: Installation - 8.4.0
  2. If you follow the installation procedure, it is already configured
  3. You can apply this patch in packages/pdraw: raw_vsink_forum.patch (48.9 KB)
    And look at the pdraw-vsink-test (./build.sh -p groundsdk-linux -A pdraw-vsink-test -j)
    This tool extracts the battery level from the metadata of a stream or local video,
    the option --no-decode allows to do it without decoding the frames
3

Hi Remy,
Thank you for your guidance on using libpdraw and the pdraw_coded_video_sink approach for metadata extraction. I have been investigating this path, but I am facing significant hurdles regarding the build environment.
To provide some context, I am working on a setup using a NanoPi (ARM) and a development machine running Ubuntu (x86_64). While I understand that the Alchemy build system is the standard way to compile Parrot projects, setting up the full environment with all its dependencies has proven to be extremely complex for my current setup, leading to various path and configuration issues.
I would like to clarify my options moving forward:

Full build approach: I am currently exploring the possibility of using an official Docker build container to cross-compile for my target (ARM64/ARMv7) to avoid local dependency issues.

Simplified alternative: I wanted to ask if there is any possibility of obtaining a pre-compiled version of the libpdraw library (or a minimal static build), which would allow me to implement a simple C++ parser for the Protobuf metadata without needing to initialize the entire Alchemy workspace?

Given that I primarily need to extract the GPS metadata (Protobuf) from the RTSP stream, is there a recommended “lightweight” way to achieve this, or is libpdraw the only viable solution?
Thank you for your time and for the support you provide to the community.
Best regards
Jindrich

4

Dear Jindrich, Parrot and Remy,
Just to let you know that you are not alone with the desire to get UKR into ATAK environment. We are also most interested in a simple solution to get UKR data into ATAK using the CoT protocol.
Is translating MAVLINK into CoT an option without taking the SkyController out of the equation? Can the MAVLINK data/protocols be accessed from an active SkyController (we want to continue piloting with the controller…)
BR

5

Hi wolfpack,

Thanks for jumping in! It’s great to know there is community interest in this.

To summarize where we are: we have successfully confirmed that the “PC bridge” approach works—using Olympe to route MAVLink/CoT data to ATAK. Our current focus, however, is hardware minimization . We are trying to move away from a full laptop and implement this solution on a small footprint device (NanoPi) to handle both the video decoding/parsing and the MAVLink-to-CoT conversion for ATAK.

Our main bottleneck is the libpdraw build environment for ARM. We are trying to isolate the metadata/Protobuf parsing from the RTSP stream without needing the full, complex Alchemy environment on every device.

To get back to our core technical challenge: does anyone have experience with a lightweight or static compilation of libpdraw for ARM, or is there a recommended way to cross-compile this specifically for NanoPi (ARM64/v7) without needing a full-blown build machine?

Best regards,

Jindrich

6

Hi everyone,

I think we got a bit lost in the build environment details, so I’d like to step back, provide the full context of what I’m building, and ask for your guidance on the best lightweight approach.

Project Context & Goal

I am building a dedicated edge router/bridge on a NanoPi (ARM64, Linux) equipped with two Ethernet ports:

  • Port 1: Connected to the Parrot system (192.168.53.x/24).
  • Port 2: Connected to an external network.

My objective is minimal and specific:

  1. Extract drone position, controller position, and CoT (Cursor on Target) metadata from the stream/network.
  2. Forward/multicast the raw UDP video stream to an internal network.
  3. Send the extracted telemetry/CoT data as multicast packets to ATAK standard 239.2.3.1:6969 so it can be ingested by a BMS (Battle Management System).

I do not need flight control, command execution, or heavy GUI framework features.

Questions for the Community / Developers:

  1. Bypassing Olympe / Full SDK build: Is there a recommended way to bypass the heavy Olympe/Alchemy ecosystem for a lightweight ARM64 C/C++ or Python binary?
  • Can libvmeta / SEI metadata parsing be linked standalone or parsed directly from RTP/H.264 SEI NAL units without pulling in libpdraw, pomp, and the whole SDK dependency graph?
  1. RTSP Stream & Keyframe (IDR) Interval: The incoming video stream seems to have a long keyframe (GOP) interval, which causes some media players to lag or fail to render until the next keyframe arrives.
  • Is there a parameter/API call in the drone settings to request more frequent keyframes (GOP size adjustment)?
  • Or is full video transcoding (e.g., via ffmpeg / hardware H.264 encoder on NanoPi) required to inject keyframes on the fly?

Any advice, minimal working examples for standalone vmeta parsing, or best practices for this lightweight relay setup would be greatly appreciated!

Thanks in advance
Jindrich