Skip to content

Forward context queries #1

Draft
ABeltramo wants to merge 1 commit intomasterfrom
forward-queries
Draft

Forward context queries #1
ABeltramo wants to merge 1 commit intomasterfrom
forward-queries

Conversation

@ABeltramo
Copy link
Copy Markdown
Member

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 RidgeRun#111: managing the context from the "outside" directly in Wolf by listening to the NEED/HAVE_CONTEXT messages on both buses.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant