ADTF  v2.14.3
ADTF FilterGraph Manager uses the Message Bus Service

The ADTF FilterGraph Manager uses the Message Bus (adtf::IMessageBus) to communicate with the outside world.

Filtergraph Manager on example UDP Protocol


There are 2 possiblities to configure a communication between different systems:

Typed Communication with an asynchronous "handshake" (ADTF-to-ADTF-Communication)

The typed communication is to connect a "far pin" to a pin within the FilterGraph. For a better understanding of the described system have a look at the following illustration:

dx_api_1.png
ADTF Configuration Example (local configuration)



The FilterGraph Manager will only receive data from another system request a type on the first incoming data (when the channel.message is a source) via "<message>ADTF_DX_MESSAGE_TYPE_REQUEST" through the channel.The C++ macro ADTF_DX_MESSAGE_TYPE_REQUEST will help you. Data area of this message is empty ... it uses the asynchronous way on the channel without waiting for the reply.

I.e.: The channel name is "system1" and the message name is set to "farpin".
There exists a Filter within the FilterGraph named "device" which has an "input"-Pin.

dx_api_2.png
ADTF Configuration Example (remote configuration)


By establishing a connection through adtf::IFilterGraph::AddConnection between the far "system1.farpin" and the intern Filter "device.input" the FilterGraph Manager will look for the channel "system1" within the Data Exchange Service and subscribes for messages called "farpin_type" and sends a message called "farpin_type_request".

It will also subscribe for a message called "farpin", which are sample(-data) messages. If no "farpin_type" is received yet and a "farpin" message arrives, the FilterGraph will re-request the type again until the type is send by the "system1"!
When the MediaType is successfully received the samples will be redirect to the "device.input"-Pin.



The sender part for the channel must react on the type request with a "<message>ADTF_DX_MESSAGE_TYPE" message (in the example it is the message "farpin_type"). The C++ macro ADTF_DX_MESSAGE_TYPE will help you. The data area of the type message is separated into class identifier of MediaType (adtf::IMediaType, ucom::IClassInfo).

OID_MEDIATYPE with 128 bytes serialized MediaType ucom::ISerializable



The sender part can send messages with MediaSamples in the data area. The data area of the sample message is separated into class identifier of MediaSample NULL terminated (adtf::IMediaSample, ucom::IClassInfo).

OID_MEDIASAMPLE with 128 bytes serialized MediaSample ucom::ISerializable




When using the channel as a destination (the "channel.message" is the destination part of adtf::IFilterGraph::AddConnection):
- The FilterGraph will send a type message on when requesting from somewhere.
- The FilterGraph will also send the sample messages on the channel.

i.e.: The channelname is "system1" and the messagename is set to "farpin".
There exists a filter within the FilterGraph named "device" which has a "output"-pin.
By establishing a connection through adtf::IFilterGraph::AddConnection between the far "device.output" and the a intern filter "system1.farpin" the FilterGraph Manager will look for the channel "system1" within the data exchange service and subscribes for messages called "farpin_type_request".
When this message is received the FilterGraph will send the type of the "device.output" with the message called "farpin_type" and will send all MediaSamples with the message "farpin" on the channel "system1".

Remarks
  • Important Note: If the MediaType of sender is not known at the receiver, all common data-samples will be ignored (not received), till this MediaType-Request handling is done. Usually this may happen at the beginning of a MessageBus communication, means: the first data-sample(s) of a new communication may be "lost".
  • Keep in Mind: When MediaType of sender changes then it must send the type message again!
  • Be sure that the channels will use different ports otherwise it is not possible to receive all data
  • A configuration examples for data exchange usage can be found at Demo MessageBus Project 1, Demo MessageBus Project 2 and Demo MessageBus Project 3

Untyped Communication (ADTF-to-X-Communication)

It is also possible to communicate to another nonADTF system.

This communication method is called "Raw-Method". You are able to connect the ADTF Filtergraph Manager to another system.

  • When using the untyped communication the connection identifier of the messages you want to receive or send must have a trailing "_raw" which is defined in the macro also ADTF_DX_MESSAGE_RAW.

This configuration example will only show you the default ADTF UDP Network connections with the protocol UDP.
All other protocol will work with similar principals.

Receive Data from another system as an ADTF UDP Channel Server
messagebus_confgure_server_global.png
Configure a ADTF UDP Channel Server - Possibility 1


The following configuration example will overwrite the Possibility 1.

messagebus_confgure_server_local.png
Configure a ADTF UDP Channel Server - Possibility 2


The FilterGraph will only receive and send sample raw messages. The data area of the message is always the whole binary buffer of the MediaSample (adtf::IMediaSample::Lock). The size of the data area is always the size of the MediaSamples data area.

Remarks
  • Be sure the type of the pin which is connected to the channel fits with the data you are expecting.
  • No MediaType checking is available!
  • for detailed usage of the raw communication without an real ADTF System as sender have a look at the example Demo ADTF external data exchange communication

Copyright © Audi Electronics Venture GmbH. All rights reserved. (Generated on Fri Mar 22 2019 by doxygen 1.8.10)