Your fix is looking good:

Nice job!

According to my tests, these changes do allow the size of the Dedicated NDI output filter to reflect the size and content of the previous filter in the chain. You mentioned some edge cases where it does not work. Could you elaborate on the cases so we can determine if they are show stoppers?

As mentioned in Discord already, this behavior is currently in place:

when the source is hidden it will still try to render whats in the chain and it does the weird double draw again

I've tried finding a way to make sure we just don't render it at all when the parent source is hidden but I am not sure if that exists...

There is no way to tell if a source has been hidden in a scene. So I dont think this should stop us from implementing the code to react to the closed window. However, the 2x2 pixel empty frame seems a little kludgy. It would be better to destroy the sender and create when we get a non empty frame.

Well the 2x2 pixel code is part of the other PR, #1276

Though yes, I can see how to best implement that in the other one

As I've mentioned in the Discord, I've found a much better way to fix not just the issue I've had with the disabled source and opening the filters tab or properties (where it started to render it a 2nd time with all filters applied once again)

I need more testing on the new code though. It also uses the render callbacks again and not the renderED ones.

Edit:
Even better: The render callbacks aren't necessary at all. Not even for async sources.

After much investigation, it is not possible to output the previous filter output in the NDI dedicated output filter. This is mostly due to the way we extract the frame data from OBS. Since we use non-public APIs to achieve this, we are not left with a way to fix this deficiency. @Lordmau5 had this summary in Discord:

So the bottom line is that I see 2 approaches now:

Use synchronous video_render callback (which also works on Async sources since it's added as an effect filter) - The problem is that it will only send the video over NDI when the source is active in the main view as otherwise the video_render function isn't being called, however it would allow rendering the target (as in, previous filter or parent, depending on the position)
Another problem is that I've so far only tested it with frames, but not with audio as well (e.g. a media source) - I've noticed when the media source stutters in the main OBS output then so will the one that is on the receiver.,

Keep using render or rendered callbacks but draw the parent as a whole. That way we can still support Crop/Pad, Aspect Ratio, etc. but the problem is that it will only take the final output, no matter at which position the NDI filter is at.
As a compromise, it is possible to use the Source Clone plugin to make a clone of the specific source with no filters enabled, then adding the NDI filter on that one.

I personally believe the best approach would be to go with the final output from the parent after all filters.

As I've said, this would be in line with what would be possible with Canvases as well once support for those is available.

That way users can already prepare themselves for how to use it going forward.

Do you want me to adapt the PR to have that functionality instead?

Bumping this up.

Source with filter (in this order):

• Filter A
• Filter B
• NDI Output Filter
• Filter C
• Filter D

Here are some of the test cases I had in mind (please add / suggest)

Case 1 :

Filter chain rendering

• NDI Output Filter Stream to be : Source + Filter A + Filter B

Filter C & D are only visible in OBS but do not output to NDI

Case 2

Hidden source behavior

• Source is hidden
• NDI Stream is not stopped
• Source resolution should NOT change ( this will break havoc with hardware decoders & is more a hack than anything else, also for some user 2x2 will not be an acceptable solution)
• Source could keep the same resolution BUT send and Alpha-frame (aka 100% transparent) - NB: Might not be possible

Case 3

Stop Hidden Source

• Source is hidden
• The filter should have an option similar to the one we have in "NDI Source" : "Keep active, send source", "Keep active, Send Transparent only", "Stop NDI Output".

@Lordmau5 Are Case 1 & 2 fixed with this PR?

Case 3 should be a dedicated PR as it will be quite a bigger change.

The PR in its current form doesn't 100% fix the issue that's present currently.

The better approach I've mentioned a few times, which would then also prepare users for the eventual Canvases implementation, would be to use the synchronous video_render callback from the filter (Yes, this also works for Asynchronous sources)

Case 1 would not be functional in that way anymore - it would send whatever the final output of the parent / source is that is also visible inside OBS. However, this can be worked around by simply cloning the source without any active filters (e.g. with Exeldro's Source Clone plugin) and then attaching either just the filters necessary or not use filters at all (besides the Dedicated NDI Output filter of course)

Case 2 is not really possible with this approach as the source is simply not giving any video output in the video_render callback when the source is hidden in the main OBS view. It would pick up rendering again when the properties or filters menu for it is being opened again (as in, the popup) as that would cause it to be rendered again.

Case 3 would pretty much be the only realistic solution I see with this that wouldn't cause issues.
However, it seems that by using this native video_render callback of the filter with a Group does not cause higher CPU usage compared to the current implementation. The downside: Audio of the sources within that group will not be sent.
Audio with Canvases hasn't even been properly thought through on the OBS side unfortunately so I have no idea what the plan for that would be anyway sadly...