[PR #2] [MERGED] Forward upstream context queries across the interpipe boundary #1

New issue

Closed

opened 2026-10-15 12:47:16 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-15 12:47:16 +00:00

Owner

📋 Pull Request Information

Original PR: https://github.com/games-on-whales/gst-interpipe/pull/2
Author: @JBailes
Created: 6/15/2026
Status: ✅ Merged
Merged: 6/17/2026
Merged by: @ABeltramo

Base: master ← Head: feat/forward-context-queries

📝 Commits (1)

17d88c0 feat: forward upstream context queries across the interpipe boundary

📊 Changes

7 files changed (+238 additions, -0 deletions)

View changed files

📝 gst/interpipe/gstinterpipeinode.c (+14 -0)
📝 gst/interpipe/gstinterpipeinode.h (+17 -0)
📝 gst/interpipe/gstinterpipesink.c (+21 -0)
📝 gst/interpipe/gstinterpipesrc.c (+33 -0)
📝 tests/check/Makefile.am (+1 -0)
➕ tests/check/gst/test_context_query.c (+151 -0)
📝 tests/check/meson.build (+1 -0)

📄 Description

Summary

interpipesrc/interpipesink already forward buffers and events between decoupled pipelines, but not queries. That leaves no way for a consumer pipeline to discover a hardware context (e.g. a VADisplay) held by the producer pipeline, so VA/DMABuf elements on either side of an interpipe cannot share a context and each fall back to creating their own. This is the gap described in RidgeRun gst-interpipe#111.

This adds a symmetric upstream query path, mirroring the existing receive_event mechanism:

GstInterPipeINode gains a receive_query vfunc (+ wrapper) so a listener can run a query against the node's own upstream peer.
interpipesink implements it via gst_pad_peer_query() on its sink pad, so the query is answered by the producer pipeline. A read-only query is safe to serve even with multiple listeners, since they share the same single upstream.
interpipesrc overrides GstBaseSrc::query and forwards GST_QUERY_CONTEXT (which would otherwise dead-end at the source) across the boundary, falling through to default handling for everything else.

Why context-only (for now)

GST_QUERY_CONTEXT is the canonical cross-pipeline need (shared VADisplay/CUDA context) and is orthogonal to the existing caps negotiation machinery, so it carries no regression risk to the caps tests. Downstream allocation aggregation already landed in 953db14; upstream caps/allocation forwarding can follow if needed.

Testing

New test_context_query asserts a context query injected into an interpipesrc reaches the producer pipeline and is answered across the boundary.
Full suite: 15/15 pass (14 pre-existing + the new one), no regressions, built against GStreamer headers with meson/ninja.

Context

Enables games-on-whales/wolf to drop its manual DMA-BUF format intersection and let VA zero-copy negotiate through the shared context instead (wolf PR #419).

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/games-on-whales/gst-interpipe/pull/2 **Author:** [@JBailes](https://github.com/JBailes) **Created:** 6/15/2026 **Status:** ✅ Merged **Merged:** 6/17/2026 **Merged by:** [@ABeltramo](https://github.com/ABeltramo) **Base:** `master` ← **Head:** `feat/forward-context-queries` --- ### 📝 Commits (1) - [`17d88c0`](https://github.com/games-on-whales/gst-interpipe/commit/17d88c0aa8603cccabf8a89aa4845503ff8f3003) feat: forward upstream context queries across the interpipe boundary ### 📊 Changes **7 files changed** (+238 additions, -0 deletions) <details> <summary>View changed files</summary> 📝 `gst/interpipe/gstinterpipeinode.c` (+14 -0) 📝 `gst/interpipe/gstinterpipeinode.h` (+17 -0) 📝 `gst/interpipe/gstinterpipesink.c` (+21 -0) 📝 `gst/interpipe/gstinterpipesrc.c` (+33 -0) 📝 `tests/check/Makefile.am` (+1 -0) ➕ `tests/check/gst/test_context_query.c` (+151 -0) 📝 `tests/check/meson.build` (+1 -0) </details> ### 📄 Description ## Summary `interpipesrc`/`interpipesink` already forward buffers and events between decoupled pipelines, but not **queries**. That leaves no way for a consumer pipeline to discover a hardware context (e.g. a `VADisplay`) held by the producer pipeline, so VA/DMABuf elements on either side of an interpipe cannot share a context and each fall back to creating their own. This is the gap described in [RidgeRun gst-interpipe#111](https://github.com/RidgeRun/gst-interpipe/issues/111). This adds a symmetric **upstream query path**, mirroring the existing `receive_event` mechanism: - `GstInterPipeINode` gains a `receive_query` vfunc (+ wrapper) so a listener can run a query against the node's own upstream peer. - `interpipesink` implements it via `gst_pad_peer_query()` on its sink pad, so the query is answered by the producer pipeline. A read-only query is safe to serve even with multiple listeners, since they share the same single upstream. - `interpipesrc` overrides `GstBaseSrc::query` and forwards `GST_QUERY_CONTEXT` (which would otherwise dead-end at the source) across the boundary, falling through to default handling for everything else. ## Why context-only (for now) `GST_QUERY_CONTEXT` is the canonical cross-pipeline need (shared `VADisplay`/CUDA context) and is orthogonal to the existing caps negotiation machinery, so it carries no regression risk to the caps tests. Downstream allocation aggregation already landed in 953db14; upstream caps/allocation forwarding can follow if needed. ## Testing - New `test_context_query` asserts a context query injected into an `interpipesrc` reaches the producer pipeline and is answered across the boundary. - Full suite: **15/15 pass** (14 pre-existing + the new one), no regressions, built against GStreamer headers with `meson`/`ninja`. ## Context Enables games-on-whales/wolf to drop its manual DMA-BUF format intersection and let VA zero-copy negotiate through the shared context instead (wolf PR #419). --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

bsakaguchi added the

pull-request

label

2026-10-15 12:47:16 +00:00

bsakaguchi referenced this issue

2026-10-15 12:47:17 +00:00

[PR #1] Forward context queries #2

bsakaguchi closed this issue

2026-10-15 12:47:17 +00:00