1# castengine_wifi_display<a name="ZH-CN_TOPIC_0000001147574647"></a> 2- [Introduction](#e05dce83) 3- [Logical architecture](#x5H5N) 4- [Module responsibilities](#b4Dwq) 5- [directory structure](#767fa455) 6- [Usage](#S3D8i) 7- [Related Repositories](#55ac5bcd) 8 9## Introduction <a name="e05dce83"></a> 10The alias of the "castengine_wifi_display" component is "Sharing", which means "media sharing". This component has the capabilities of streaming media protocol access, media preview, and media redistribution. It is managed and called by the castengine_cast_framework service, and is an important streaming media capability component in the castengine subsystem. It provides simple Native C++ interfaces to support Miracast casting. The component provides the following common functions: 11 12- WFD Source : Indicates the screen capture transmitter, which sends multiple screen data streams to different devices. 13 14- WFD Sink: Indicates the screen data receiver, which receives screen data streams from multiple devices. 15## Logical architecture <a name="x5H5N"></a> 16 17## Module responsibilities <a name="b4Dwq"></a> 18| **Module Name** | **Responsibilities** | 19| --- | --- | 20| Interaction | Framework layer interaction module, responsible for interaction between processes on the device or across devices,supporting concurrent interaction with multiple processes. | 21| Scene | The business implementation part of the Interaction module, together with the Interaction instance, accomplishes external interactions and internal framework calls. | 22| ContextMgr | The service context managerment of the framework. The container associates different agents to implement receiving, distributing, and sending media streams. Each context instance can contain multiple agents. | 23| Agent | The agent object of the service in the framework, responsible for the interaction in the signaling. The Agent is divided into Sink Agent and Source Agent. Sink Agent is responsible for receiving stream (acquiring media data), and Source Agent is responsible for sending stream (outputting media data). | 24| Session | The specific implementation of the service control and works with Agent to complete the signaling interactions of the service. | 25| Configuration | Configuration management module that sets up configuration data for the framework and the service, which is loaded when the service starts. | 26| EventScheduler | Event distribution and scheduling manager, centralized distribution and processing of events reported by the module, using asynchronous thread pool processing, not to deal with time-consuming operations such as disk IO and network IO. | 27| MediachannelMgr | The framework media channel module manages media channels, and each media channel instance can realize the access, preview and sending of media data; it has the ability of coding and decoding, mixing, and transmitting of streaming media packets. | 28| Consumer | Media data input object. The media data can be obtained in any way based on the business properties, usually used for receiving streams. | 29| Producer | Media data output object. The media data can be output in any way based on business properties, usually used for pushing streams. | 30| ServiceMgr | Service management module, management for service monitoring. Each instance is used to monitor the specified tcp or udp port, and exchange data with external processes or devices. | 31| InputBack | Inputback control module, handles cross-device control and coordinate changes. | 32| WindowMgr | Window management. Window instances are used when preview Windows are internal triggered. | 33| Protocol | Encapsulates protocols such as rtsp, rtp, wfd, dlna, and uibc for protocol interaction and interconnection. | 34| Codec | Media data encapsulation and decapsulation, encoding and decoding, hardware decoding acceleration, etc. | 35| Network | Encapsulates the network protocol, including the tcp/udp server and client. | 36 37## Directory structure <a name="767fa455"></a> 38Repositories directory structure is as follows: 39 40``` 41/foundation/CastEngine/castengine_wifi_display # airing parts business code 42├── figures # 43├── interfaces # External interface 44│ ├── kits # Application interface 45│ └── innerkits # System internals interface 46├── frameworks # Client implementation 47│ └── innerkitsimpl # Native c++ implementation 48├── sa_profile # Component configuration 49├── services # Service C/S implementation 50│ ├── interaction # Process interaction 51│ ├── configure # Configuration management 52│ ├── context # Business container 53│ ├── agent # Service agent 54│ ├── mediachannel # Media channel 55│ ├── mediaplayer # Play and render 56│ ├── etc # Inner service configuration 57│ ├── event # Event center 58│ ├── impl # Business implementation 59│ │ └── wfd # WFD service implementation 60│ ├── inputback # Anti-control module 61│ ├── scheduler # Scheduling center 62│ ├── windowmgr # Window management 63│ ├── protocol # Protocol library 64│ ├── codec # Codec library 65│ ├── network # Network library 66│ ├── extend # Third-party library 67│ ├── common # Public classes 68│ └── utils # Tools classes 69├── sa_profile # Service configuration in system 70├── tests # Test cases 71├── bundle.json # Component description file 72└── BUILD.gn # Compilation entry 73``` 74 75 76## Usage <a name="S3D8i"></a> 77The WFD Sink allows multiple devices to cast it simultaneously. The castengine_wifi_display allows individual control of the audio for each casting session, enabling the selection of audio playback or muting in multi-casting scenarios. In general, the WFD Source can only cast to one device at a time. A device can act as a Sink or a Source, but not both simultaneously. 78 79## Related Repositories <a name="55ac5bcd"></a> 80 81[castengine_cast_framework](https://gitee.com/openharmony/castengine_cast_framework) 82 83[castengine_cast_plus_stream](https://gitee.com/openharmony-sig/castengine_cast_plus_stream) 84 85[castengine_dlna](https://gitee.com/openharmony-sig/castengine_dlna)
