I'm using the following flags to build a filter graph iteratively. I've observed that compared to normal operations fanout doesn't happen at the correct place. I feel like this is highly dependant on my implementation with gpac but if I could get an insight on it, that would be perfect.

|flag|
|---|
|GF_FS_FLAG_NON_BLOCKING|
|GF_FS_FLAG_NO_REASSIGN|
|GF_FS_FLAG_REQUIRE_SOURCE_ID|
|GF_FS_FLAG_FORCE_DEFER_LINK|
|GF_FS_FLAG_PREVENT_PLAY|

Basically I'm loading `fin` then two `reframer` consecutively. I then explicitly define the connections. The resulting graph has two `mp4dmx` going to reframers. I was expecting this fanout to happen after `mp4dmx`. I know I haven't given any implementation details but I just want to know if this is expected given the flags list above.

> After every API call to libgpac I'm running the session

Question about deferred linking
This is a GitHub Issue
repo:gpac
owner:gpac
Title : Question about deferred linking
Issue date:

--- start body ---
I'm using the following flags to build a filter graph iteratively. I've observed that compared to normal operations fanout doesn't happen at the correct place. I feel like this is highly dependant on my implementation with gpac but if I could get an insight on it, that would be perfect.

|flag|
|---|
|GF_FS_FLAG_NON_BLOCKING|
|GF_FS_FLAG_NO_REASSIGN|
|GF_FS_FLAG_REQUIRE_SOURCE_ID|
|GF_FS_FLAG_FORCE_DEFER_LINK|
|GF_FS_FLAG_PREVENT_PLAY|

Basically I'm loading `fin` then two `reframer` consecutively. I then explicitly define the connections. The resulting graph has two `mp4dmx` going to reframers. I was expecting this fanout to happen after `mp4dmx`. I know I haven't given any implementation details but I just want to know if this is expected given the flags list above.

> After every API call to libgpac I'm running the session

--- end body ---
