Support Request #14745
closedCreating output pins via qml not calling RequestDynamicOutputPin
Description
Supportanfrage
Ich habe folgendes Problem: wenn ich via qml dynamische Output Pins erzeuge (sind im Filtergraphen zu sehen) wird für diese RequestDynamicOutputPin nicht gecalled, für welche die ich selber im FilterGraphen erzeuge aber schon. Ist das bekannt / umgehbar?
Lösung
Wenn ein Pin nicht mit einem Sample Stream verbunden ist, fließen auch keine Daten, die Callbacks werden dann auch nicht gerufen.
Hier ein kleines Bsp:
Die Pins data_ce und data_ce_out hab ich im CE angelegt.
Die Pins data_qml und data_qml_out kommen vom Filter Editor:
EditorPluginBase
{
id: root
onExecute:
{
createInputPin("data_qml")
createOutputPin("data_qml_out")
}
}
Im Filter selbst mach ich folgendes:
tResult cDynamicFilter::RequestDynamicOutputPin(const tChar* strName,
const adtf::ucom::ant::iobject_ptr<const adtf::streaming::ant::IStreamType>& pType)
{
LOG_INFO("########### %s", strName);
RETURN_NOERROR;
}
Und beim Launch wird die Funktion auch wunderbar gecalled:
// ... 2021-07-16 13:06:40 [INFO]: ########### data_ce_out [synchronizer_filter.cpp(64)] 2021-07-16 13:06:40 [INFO]: ########### data_qml_out [synchronizer_filter.cpp(64)]
Files
Updated by hidden over 2 years ago
- Status changed from New to In Progress
- Customer set to AUDI
- Department set to EFS
Updated by hidden over 2 years ago
- Affected Products ADTF 3.12.5 added
- Platform Windows 10 64bit added
Updated by hidden over 2 years ago
- File filter_ce.png filter_ce.png added
- Status changed from In Progress to Customer Feedback Required
Hallo Dennis,
kann es sein, dass die Pins nicht verbunden sind ?
Hier ein kleines Bsp:
Die Pins data_ce und data_ce_out hab ich im CE angelegt.
Die Pins data_qml und data_qml_out kommen vom Filter Editor:
EditorPluginBase
{
id: root
onExecute:
{
createInputPin("data_qml")
createOutputPin("data_qml_out")
}
}
Im Filter selbst mach ich folgendes:
tResult cDynamicFilter::RequestDynamicOutputPin(const tChar* strName,
const adtf::ucom::ant::iobject_ptr<const adtf::streaming::ant::IStreamType>& pType)
{
LOG_INFO("########### %s", strName);
RETURN_NOERROR;
}
Und beim Launch wird die Funktion auch wunderbar gecalled:
// ... 2021-07-16 13:06:40 [INFO]: ########### data_ce_out [synchronizer_filter.cpp(64)] 2021-07-16 13:06:40 [INFO]: ########### data_qml_out [synchronizer_filter.cpp(64)]
Das dürfe ziemlich vereinfacht deinen Use Case treffen oder ?
Updated by hidden over 2 years ago
Hallo Florian, ja, die waren nicht verbunden. Die Funktion wird dann nur gecalled wenn sie verbunden sind? Das würde die Frage beantworten
Updated by hidden over 2 years ago
- Project changed from 4 to Public Support
- Description updated (diff)
- Status changed from Customer Feedback Required to To Be Closed
- Resolution set to Solved Issue
Hallo Dennis,
Die Funktion wird dann nur gecalled wenn sie verbunden sind?
Korrekt! Dann werden Daten übertragen, dann springen auch die entsprechenden Callbacks an.
Pins sind am Ende nur die konfigurierbare Hülle im Graphen, um Sample Streams, Reader und Write zu definieren.
Von der Architektur her wollte man auch vermeiden, dass Daten an Pins gesendet werden und Perfomance kosten, die keiner abgreift, deshalb ist das entkoppelt.