[PR #1] Forward context queries #2

New issue

Open

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

bsakaguchi commented

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

Owner

📋 Pull Request Information

Original PR: https://github.com/games-on-whales/gst-interpipe/pull/1
Author: @ABeltramo
Created: 10/17/2025
Status: 🔄 Open

Base: master ← Head: forward-queries

📝 Commits (1)

4f0330f feat: forwarding queries from src->sink

📊 Changes

7 files changed (+217 additions, -69 deletions)

View changed files

📝 .gitignore (+2 -0)
📝 common (+1 -1)
📝 gst/interpipe/gstinterpipeinode.c (+17 -6)
📝 gst/interpipe/gstinterpipeinode.h (+3 -0)
📝 gst/interpipe/gstinterpipesink.c (+44 -31)
📝 gst/interpipe/gstinterpipesrc.c (+149 -30)
📝 meson_options.txt (+1 -1)

📄 Description

Tried to implement sharing context (mostly aiming at CUDA) between pipelines, but I'm hitting a hard wall here. It seems that the CONTEXT query comes very early, before the two src/sink element can link to each other. The link seems to be done via setting the property listen-to in the sink element.

My plan was to listen to the queries in interpipesrc, save them in a queue then, once connected to a sink, relay the queries upstream to interpipesink. If we get a hit we can get the GstContext from upstream. Now, the problem is that I'm not sure how to pass that context to the element that originally started the query. I've tried with

GST_DEBUG_OBJECT(src, "Sending have context message");
msg = gst_message_new_have_context(GST_OBJECT(src), context);
gst_element_post_message(GST_ELEMENT(src), msg);

but I end up with

Got context from element 'nvh265enc0': gst.cuda.context=context, gst.cuda.context=(GstCudaContext)"\(GstCudaContext\)\ cudacontext2", cuda-device-id=(uint)0;
Got context from element 'interpipesrc0': gst.cuda.context=context, gst.cuda.context=(GstCudaContext)"\(GstCudaContext\)\ cudacontext0", cuda-device-id=(uint)0;

when running the following example pipeline:

gst-launch-1.0 waylanddisplaysrc ! 'video/x-raw(memory:CUDAMemory),width=1920,height=1080,framerate=60/1' ! interpipesink name=sink  interpipesrc listen-to=sink ! nvh265enc ! fakesink

Because nvh265enc0 queries for the context before we've managed to connect interpipesrc and interpipesink, so it sends the NEED CONTEXT message and ultimately just creates a CUDA context. After that, there's no point in manually setting the pipeline element context since it's too late..

See for example: gstcudabasetransform.c#L179-L197: by the time we set ask for context (and ultimately create one) filter->stream has already be assigned, so changing the context afterwards doesn't do anything..

I'm going to park this for now and try implementing what was suggested in https://github.com/RidgeRun/gst-interpipe/issues/111: managing the context from the "outside" directly in Wolf by listening to the NEED/HAVE_CONTEXT messages on both buses.

_{🔄 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/1 **Author:** [@ABeltramo](https://github.com/ABeltramo) **Created:** 10/17/2025 **Status:** 🔄 Open **Base:** `master` ← **Head:** `forward-queries` --- ### 📝 Commits (1) - [`4f0330f`](https://github.com/games-on-whales/gst-interpipe/commit/4f0330f64ef98e82d5560f823a02e21fa6243b46) feat: forwarding queries from src->sink ### 📊 Changes **7 files changed** (+217 additions, -69 deletions) <details> <summary>View changed files</summary> 📝 `.gitignore` (+2 -0) 📝 `common` (+1 -1) 📝 `gst/interpipe/gstinterpipeinode.c` (+17 -6) 📝 `gst/interpipe/gstinterpipeinode.h` (+3 -0) 📝 `gst/interpipe/gstinterpipesink.c` (+44 -31) 📝 `gst/interpipe/gstinterpipesrc.c` (+149 -30) 📝 `meson_options.txt` (+1 -1) </details> ### 📄 Description Tried to implement sharing context (mostly aiming at CUDA) between pipelines, but I'm hitting a hard wall here. It seems that the `CONTEXT` query comes very early, before the two src/sink element can link to each other. The link seems to be done via setting the property `listen-to` in the sink element. My plan was to listen to the queries in `interpipesrc`, save them in a queue then, once connected to a sink, relay the queries upstream to `interpipesink`. If we get a hit we can get the `GstContext` from upstream. Now, the problem is that I'm not sure how to pass that context to the element that originally started the query. I've tried with ```c GST_DEBUG_OBJECT(src, "Sending have context message"); msg = gst_message_new_have_context(GST_OBJECT(src), context); gst_element_post_message(GST_ELEMENT(src), msg); ``` but I end up with ``` Got context from element 'nvh265enc0': gst.cuda.context=context, gst.cuda.context=(GstCudaContext)"\(GstCudaContext\)\ cudacontext2", cuda-device-id=(uint)0; Got context from element 'interpipesrc0': gst.cuda.context=context, gst.cuda.context=(GstCudaContext)"\(GstCudaContext\)\ cudacontext0", cuda-device-id=(uint)0; ``` when running the following example pipeline: ``` gst-launch-1.0 waylanddisplaysrc ! 'video/x-raw(memory:CUDAMemory),width=1920,height=1080,framerate=60/1' ! interpipesink name=sink interpipesrc listen-to=sink ! nvh265enc ! fakesink ``` Because `nvh265enc0` queries for the context before we've managed to connect `interpipesrc` and `interpipesink`, so it sends the NEED CONTEXT message and ultimately just creates a CUDA context. After that, there's no point in manually setting the pipeline element context since it's too late.. See for example: [gstcudabasetransform.c#L179-L197](https://github.com/GStreamer/gstreamer/blob/2dd1b4bf270995fd4dd6aa240cb51cfcdf3c71b8/subprojects/gst-plugins-bad/sys/nvcodec/gstcudabasetransform.c#L179-L197): by the time we set ask for context (and ultimately create one) `filter->stream` has already be assigned, so changing the context afterwards doesn't do anything.. I'm going to park this for now and try implementing what was suggested in https://github.com/RidgeRun/gst-interpipe/issues/111: managing the context from the "outside" directly in Wolf by listening to the `NEED`/`HAVE_CONTEXT` messages on both buses. --- <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:17 +00:00

bsakaguchi referenced this issue from games-on-whales/wolf

2026-10-15 13:00:40 +00:00

[PR #419] [CLOSED] 10-bit SDR streaming + DMA-BUF zero-copy via gst-interpipe context sharing #452