Component Based Media Streaming Framework

Transcription

1 Component Based Media Streaming Framework ECE750 T11 COMPONENT BASED SOFTWARE SYSTEMS Project Presentation - 2 By Sohaib Sajid Hemamalini Vedachalam June 27 th 2009 Professor: Ladan Tahvildari 1

2 Outline Project Overview Existing Solution Approach Restructuring existing code Implementing new features Application of CBSE Principles Expected Results Problems Encountered Performance Testing Conclusion Demo References 2

3 Outline Project Overview Existing Solution Approach Restructuring existing code Implementing new features Application of CBSE Principles Expected Results Problems Encountered Performance Testing Conclusion Demo References 3

4 Project Overview Multiple file formats are available on the PC side Projector s capabilities are limited to a subset of available file formats To be able to play a larger selection of available formats: Convert input container format to projector-compatible format before data is sent to it 4

5 Outline Project Overview Existing Solution Approach Restructuring existing code Implementing new features Application of CBSE Principles Expected Results Problems Encountered Performance Testing Conclusion Demo References 5

6 Existing Solution System Block Diagram User application Multimedia streaming framework (MSF) Parsers Block Parser FIFO Muxers Block Muxer FIFO HTTP Server Projector Developed without any prior knowledge of CBSE principles No clear separation as code from one component Lack of a central controller which results in a lot of glue code High coupling Means to notify the user application of an error can result in a deadlock 6

7 Outline Project Overview Existing Solution Approach Restructuring existing code Implementing new features Application of CBSE Principles Expected Results Problems Encountered Performance Testing Conclusion Demo References 7

8 Approach Critical Analysis of Current System Restructuring Existing Components CBSE Approach Design and Implementation Performance Testing and Evaluation 8

9 Approach Restructuring Existing Code Existing source code size: 488 files, lines of code Updated Source code: 507 files, lines of code Restructuring code is an entire research area on its own Our focus is on the implementation and correcting issues in existing code Let us look at some basic steps we ve taken to restructure the code base 9

10 Approach Restructuring Existing Code (Cont d) Existing Code base Identifying Components Look for code reuse Look for common functionality Apply Le Gear s method [1] Provide well defined interfaces Introduce a centralized controller Component based code 10

11 Approach Implementing New Features Hardware and O/S independence Memory Management Interface Allows firmware to be ported on to embedded platforms (SPL) I/O Interface Allows user application to provide input data from arbitrary sources (SPL) Can take input data from live stream, or other specialized hardware (SPL) Interface function pointers by the application to MSF Interface functions implemented by the application for a given device configuration (platform/os) and input source MSF code has no knowledge of the data source MSF code does not need to be recompiled when adding new input sources or changing hardware platforms or operating systems 11

12 Approach Implementing New Features Memory and I/O interfaces are given to the MSF for its use. They can be, but don t have to be used by the application Similarly, it is possible for the application to implement all other features that MSF may at some point need (for example, implement a new streaming protocol) User Application User GUI User Input Memory Interface I/O Interface GUI Controller MSF Output to projector 12

13 Outline Project Overview Existing Solution Approach Restructuring existing code Implementing new features Application of CBSE Principles Expected Results Problems Encountered Performance Testing Conclusion Demo References 13

14 Application Of CBSE Principles MSF: System Blocks MSF Controller MSF Controller Parser(s) Parser FIFO Muxer(s) Muxer FIFO HTTP Server Lets look at the various blocks, their interactions and interfaces 14

15 Application Of CBSE Principles Overall System Design User Application I/O Interface Memory Interface GUI Controller User GUI User Input I_IO_Int I_Mem_Int I_MSF_Api MSF Controller Parser(s) IParser IFifo_Ctrl IMuxer IFifo_Ctrl Parser FIFO IFifo_Data Media Streaming Framework Muxer(s) Muxer FIFO IFifo_Data HTTP Server IServer Output to projector 15

16 Application Of CBSE Principles Use of Heterogeneous Architectural Styles: Combining different architectural styles, involves a combination of functionalities entailing a combination of styles in the best solution The following different architectural styles are adopted: Model View Controller Client/Server architecture Blackboard architecture Publish/Subscribe interface 16

17 Application Of CBSE Principles Heterogeneous Architectural Style: Model - View - Controller Users interact with the GUI GUI passes messages to Controller Controller sends API calls to MSF GUI requests current status (timestamp, playback state, errors) from MSF (Controller ) GUI Controller User GUI ( View ) User Input ( Model ) MSF Controller 17

18 Application Of CBSE Principles Heterogeneous Architectural Style: Client / Server User application initializes MSF MSF only responsible for sending raw data to projector Projector does not call functions from projector - one way communication with projector User application polls server for run-time information User App (client) MSF (server) Projector (client) 18

19 Application Of CBSE Principles Heterogeneous Architectural Style: Blackboard Availability of data from one component can trigger actions in other components. For example, the Parser and the muxer FIFO (same component) provide an interface to read from and write to the FIFO. When parsers write data to the FIFO, muxer is able to read and process the data Similarly, HTTP Server s actions are triggered when a muxer write data to the muxer FIFO and it becomes available for reading by other components Parser(s) Parser FIFO Muxer(s) Muxer FIFO HTTP Server 19

20 Application Of CBSE Principles Heterogeneous Architectural Style: Blackboard State variable change in a central controller can trigger changes in connected components MSF contains a current state variable to let sub components know if the system is paused or playing etc MSF uses the black board architecture to notify components when the system state changes MSF Controller Parser(s) Parser FIFO Muxer(s) Muxer FIFO HTTP Server 20

21 Application Of CBSE Principles Publish/Subscribe Asynchronous Communication: Lets look at the Create function DLLDIR MSF_RESULT MSF_CreateMSFHdl ( APP_HANDLE * papphdl, // (in) some handle to the private APP data MEMINTERFACE *pmeminterface, // (in) memroy manager created by application NotifyFunction pfn_notification, // (in) callback function provided by APP MSF_HANDLE ** pphdl); // (in/out) pointer to the MSF handler User application expects this function to be called any time an error occurs or the application needs to be notified of important events such as playback finished, connection established, connection lost etc The application registers this notification function with MSF when it instantiates it and this function is asynchronously called to notify the application of events as they happen 21

22 Application Of CBSE Principles Enterprise Styles Followed: Session Facade Coarse-Grain Interfaces 22

23 Application Of CBSE Principles Session Facade: GUI Controller MSF Controller Parser(s) Parser FIFO Muxer(s) Muxer FIFO HTTP Server 23

24 Application Of CBSE Principles Coarse-Grain Interfaces: In the Win32 environment, MSF is implemented as a DLL. Methods from the DLL are loaded using GetProcAddress() function which can be slow when getting the function pointers for a large number of entry points DLLDIR MSF_RESULT MSF_CreateMSFHdl ( APP_HANDLE * papphdl, MEMINTERFACE *pmeminterface, NotifyFunction pfn_notification, MSF_HANDLE ** pphdl); // (in) some handle to the private APP data // (in) memroy manager created by application // (in) callback function provided by APP // (in/out) pointer to the MSF handler DLLDIR MSF_RESULT MSF_DestroyMSFHdl ( MSF_HANDLE ** psthdl ); // (in/out) pointer to the MSF handler DLLDIR MSF_RESULT MSF_ProcessCommand ( MSF_HANDLE * psthdl, MSF_COMMAND_TYPE ecommand, void * pindata, void * poutdata ); // (in) pointer to the MSF handler // (in) type of the command being sent to MSF // (in) ptr to additional data needed for the command // (out) ptr to data returned from the command 24

25 Outline Project Overview Existing Solution Approach Restructuring existing code Implementing new features Application of CBSE Principles Expected Results Problems Encountered Performance Testing Conclusion Demo References 25

26 Expected Results Provide Extensibility To improve the capabilities of MSF and applications developed using it, MSF can be updated so that a new parser / multiplexer can be added with minimal effort The system can take input from various sources and not just the native file system Provide Reusability: Design for Reuse All the parsers/multiplexers share a common interface Minimizing dependency on OS Provide Reusability: Design with Reuse With the use of same frame work and library, different applications with different capabilities could be developed 26

27 Outline Project Overview Existing Solution Approach Restructuring existing code Implementing new features Application of CBSE Principles Expected Results Problems Encountered Performance Testing Conclusion Demo References 27

28 Problems Encountered Synchronization Synchronization between projector and PC tedious Latency Increased latency between user actions and their effect on the device Trade-off between memory used and response time/throughput Research Difficult to find research papers on thorough implementation details for Publish/Subscribe interfaces Lag spikes vs. Response Time To improve Response Time, send data right when it is needed on the projector this makes system vulnerable to lag spikes 28

29 Outline Project Overview Existing Solution Approach Restructuring existing code Implementing new features Application of CBSE Principles Expected Results Problems Encountered Performance Testing Conclusion Demo References 29

30 Performance Testing Evaluation Each container format is different and requires a different computing power to extract audio video data. Therefore, all performance related tests need to be performed once for each format The performance metrics we are considering for evaluation are: Throughput - the maximum transfer rate possible from the input to the projector Response Time - the time it takes for user inputs (play/pause/stop) to be seen at the output (projector) Response Time and Throughput are a function of total resources in use 30

31 Performance Testing Evaluation Throughput depends on: System s read/write speed FIFO block size Number of FIFO blocks System s Cache size Response Time depends on: Amount of data sent ahead of time to prevent stuttering against lag spikes Reaction Time 31

32 Performance Evaluation Throughput: ASF/WMV WMV/ASF Throughput (MB/s) Throughput (MB/s) Memory Used (MB) Throughput (MB/s) 32

33 Performance Evaluation Throughput: MPEG2-TS MPEG2 Throughput (MB/s) Throughput (MB/s) Memory Used (MB) Throughput (MB/s) 33

34 Performance Evaluation Throughput: MP4 MP4 Throughput (MB/s) Throughput (MB/s) Memory Used (MB) Throughput (MB/s) 34

35 Performance Evaluation Response Time: ASF/WMV WMV/ASF Response Time (Seconds) Response Time (Seconds) Memory Used (MB) Response Time (Seconds) 35

36 Performance Evaluation Response Time : MPEG2-TS MP4 Response Time (Seconds) Response Time (Seconds) Memory Used (MB) Response Time (Seconds) 36

37 Performance Evaluation Response Time : MP4 MP4 Response Time (Seconds) Response Time (Seconds) Memory Used (MB) Response Time (Seconds) 37

38 Outline Project Overview Existing Solution Approach Restructuring existing code Implementing new features Application of CBSE Principles Expected Results Problems Encountered Performance Testing Conclusion Demo References 38

39 Conclusion Significant number of changes made to the code without serious loss in performance Non-measurable improvements: Reliability: Publish/Subscribe interfaces do not lead to deadlocks Portability: OS and platform independence Reusability: Greater portion of the code is in components, each with a well defined interface Extendibility: Well defined interfaces allow for easier addition of new parsers and multiplexers; Removing dependencies of where the input data comes from, and the addition of new parser/muxer ( Software Product Lines ) Maintainability: Better organized code base 39

40 Outline Project Overview Existing Solution Approach Restructuring existing code Implementing new features Application of CBSE Principles Expected Results Problems Encountered Performance Testing Conclusion Demo References 40

41 Demo Demo 41

42 Outline Project Overview Existing Solution Approach Restructuring existing code Implementing new features Application of CBSE Principles Expected Results Problems Encountered Performance Testing Conclusion Demo References 42

43 References [1] A. Le Gear, J.Buckley, Reengineering towards components using Reconn-exion, ACM SIGSOFT Software Engineering Notes, Volume 30, no.5, September [2] C.Chu; C.Hsu; C.Lu; H.Xudong, "A Semi-Formal Approach to Assist Software Design with Reuse," Proceedings of the 15th IEEE International Conference on Software Maintenance, pp.256, March [3] D.Alur; J.Crupi; D.Malks, Core J2EE Patterns: Best Practices and Design Strategies, Second Edition, Prentice Hall, [4] D.Garlan; M.Shaw, "An Introduction to Software Architecture", Technical Report CMU-CS , January [5] D.Perry; A.Wolf, Foundations for the Study of Software Architecture, ACM Sigsoft - Software Engineering Notes, Volume 17, pp , October [6] GNU GENERAL PUBLIC LICENSE, Version 3, Free Software Foundation, Inc., June [7] I.Song; F.Elizalde; F.Karray, CONCORD: a control framework for distributed real-time systems, IEEE Sensors Journal, Volume 7, no.7, pp , July [8] M.Jackson; D.Besnard; C.Gacek; C.Jones, The Structure of Software Development Thought Structure for Dependability: Computer-Based Systems from an Interdisciplinary Perspective, pp , April

44 References [9] N.Admodisastro; G.Kotonya, Architectural analysis approaches: A componentbased system development perspective, Lecture Notes in Computer Science Volume 5030, pp , July [10]P.Zave; M.Jackson, "A Component-Based Approach to Telecommunication Software", IEEE Software, Volume 15, Issue 5, pp , September [11]S.Wang; S.Rho; Z.Mai; R.Bettati; W.Zhao, Real-time component-based system, Proceedings of the 11th IEEE Real Time on Embedded Technology and Applications Symposium, Volume 7, Issue 7-10, pp , March [12]S.White; J.Hanson; I.Whalley; D.Chess; J.Kephart, An Architectural Approach to Autonomic Computing, Proceedings of the 1st International Conference on Autonomic Computing, IEEE Computer Society Press, pp 2-9, May [13] T.Ziadi; L.Helouet; J.Jezequel,"Towards a UML Profile for Software Product Lines ", in Proceedings of the Fifth International Workshop on Product Familly Engineering (PFE), pp , May 2004 [14] W.Bond; E.Cheung; H.Goguen; J.Hanson; D.Henderson; M.Karam; K.Purdy; M.Smith; P.Zave, Experience with component based development of a telecommunication service, Component Based Software Engineering International Symposium, Volume 3489, pp , May

45 Questions? 45