SlideShare utilise les cookies pour améliorer les fonctionnalités et les performances, et également pour vous montrer des publicités pertinentes. Si vous continuez à naviguer sur ce site, vous acceptez l’utilisation de cookies. Consultez nos Conditions d’utilisation et notre Politique de confidentialité.
SlideShare utilise les cookies pour améliorer les fonctionnalités et les performances, et également pour vous montrer des publicités pertinentes. Si vous continuez à naviguer sur ce site, vous acceptez l’utilisation de cookies. Consultez notre Politique de confidentialité et nos Conditions d’utilisation pour en savoir plus.
Hello! I`d like to introduce SVG Player Project. Which is a tool for putting set of svg images and playing them like a video stream.
I will divide my presentation into 4 parts. Firstly, i`m going to make a brief overview about this project: consider goals and task definition. Secondly, i will talk about some aspects of player architecture and implementation which were used. Where separately we will look at the main details of the mechanism of playing the svg pictures series as a video and at the rendering mechanism. Finally we will look at the conclusions for this projects.
To begin with, I will consider the reason for development SVG Player. Nokia-Siemens Networks uses a customized clone of simulator NS2 for testing network functions and protocols. Network Simulator (Version 2) widely known as NS2 is simply an event-driven simulation tool that has proved useful in studying the dynamic nature of communication networks. There are subprojects of the main Nokia-Siemens project xmlprinter and svgprinter. They produce for the output the series of xml based files and svg pictures. Consequently, these artefacts, resulted from the simulating, need to be analyzed.
Now i will concern myself witht the tool for analysis: They need the tool for analysis of the simulation results both xml-based files and svg images. And these artefacts should be associated between each other. To put it another way, the tool should be able to switch between an svg picture and corresponding xml file. Thus, SVG Player is the first stage in development of such analysis tool.
Moving on the architecture of the SVG Player project, i`d like to draw your attention to actions between users and the application. Users should be able to put a series of SVG images and view them. In addition, Each picture can be displayed to users with navigation tool by acrossing through the series forward or backward direction. Moreover, a picture series can be defined as a set and saved in a separate file. Users can add or delete SVG images from the existing series. It is essential, The application could be used for playback a sequence of images like a video stream.
Let me now make some comments on development tools: C++ Programming Language and Qt,a cross-platform application and User Interface framework, have been chosen. Qt Graphical user interface (GUI) components and classes for displaying the contents of SVG files were used in development of the Svg Player.
Lets turn to some details of architecture. Classes SvgSeries and Shot are responsible for storing the information about file names of pictures in the series and time intervals. According to use cases, Classes MainWidow, SvgLoader, SvgSeriesHandler involve the logic of application such as opening and saving series, navigation between the loaded images and playback the series. And The other classes are used for displaying pictures, status of file loading, That is a composite of picture name and the picture`s number in the series. TimerSlider shows the time scale for the loaded series.
Now i would like to say a few words on the data model. Firs of all, an important thing should be noticed: the images, resulted from the simulating need to be revised in the order they were generated. In addition, time intervals between the moments of generating pictures could be different - irregular. Their duration is essential for the analysis. To recap, information about the images organized into one series should be saved into a file. Such files are xml-based and have extension set. The way of associating images and actual simulation times is based on specific name format. Sequence after the symbol 'at' is a quantity of miliseconds from begining simulating to the time the picture generated. In this way, time intervals are computed by calculating the difference between pictures time values.
On this slide an example of specific file for the concrete series is shown. It has the simplest format, therefore, it is easy-to-use. Let me make some comments on creating specific xml-based files: there entities of series and images (further, shots) are used. Each shot includes information about picture name and time interval to the next shot.
This slide shows the SVG Player graphical user interface. The picture loaded into the player was taken from examples of customized NS2 simulator output.
At this point I'll speak in more detail about process of playing picture series as a video stream. During the implementation the problem with playback appeared: when duration of loading exceeds the time interval to the next picture. Because of this the playback breaks. The decision to synchronize the playback timer and a period of time loading was accepted as the solution of this problem.
Now i will describe the sequence of actions for playback. First of all MainWindow asks for information about the image which is shown at this moment and runs the timer with given time interval. When the timer event is received, it asks CentralWidget for load next picture. Central widget starts loading process in another thread. The reason of using another thread will be clear further. When the process of loading completed, Mainwindow gets the signal and starts reiteration the steps to continue the playback.
Lets turn to rendering. When synchronizing the playback timer and loading process another problem appears: main window takes inactive status for a period of time loading and seems to be buzzed for the user. Solution is loading a picture in another thread, that is separated from the main graphical user interface.
On this slide we can look at the action sequence for displaying svg pictures. When the timer event is received, Main Window object sends the signal timeChanged for updating TimeSlider. Then the loading process begins and central widget starts the timer at once to track if the loading process takes too much time. Further, if the timer event occured before the next image would be loaded, Central widget will display for the user that there is a loading process. And only at the moment when the image is completely loaded and the signal loadComplete is received, the central widget and status bar will be updated.
I would like to say a few words on conclusion. The svg player is mostly completed. It should be noticed that a pplication development was started with the implementation of defined tasks using random SVG images. Therefore besides showing NS2-related images it can be used for playing any SVG series as a cartoon. For the plans is implementation of integration xml and svg result:s by clicking on the picture we can get the full description from xml results.
To summarize, i`d like to talk about some drawbacks and alternative solutions. Namely, it could be difficult to analyze some processes by using this player for picture series with a big size of image files and too short time intervals. For this case there could be an alternative solution, for example, to load all pictures or only part of them before they are shown. But this solution has an imperfection: series with a large quantity of pictures could require too much memory. In my opinion, the right solution will depend on properties of the data for which the Player will be used.
This slide shows the links for the detail information about the SVG Player project. Thanks for your attention.
SVG-player plugin for ns2 simulations
SVG Player Svetlana Marchenko Saint-Petersburg Academic University -Nanotechnology Education and Research Centre 9th FRUCT Conference, 25-29 April, Petrozavodsk, Russia
Table of contents Introduction Architecture Implementation Conclusion