LongoMatch: a sports video analysis tool based on Free Software.

Transcription

1 Facoltà di ingegneria LongoMatch: a sports video analysis tool based on Free Software. Author: Andoni Morales Alastruey Director: Massimo Mecella Academic Year:

2 Copyright (c) 2008 Andoni Morales Alastruey Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled "GNU Free Documentation License".

3 Agradecimientos Me gustaría agradecer en primer lugar a quién más se lo merece, mi familia, que ha sabido apoyarme cuando más lo he necesitado y que siempre ha tenido una confianza ciega en mi. Se lo dedico a mi hermano, por ser mi alma gemela, a mi madre, por quererme como ella me quiere, y a mi padre, por todo lo que representa y por ser el principal motivo por el que me aventuré en este proyecto. Quisiera también agradecer al resto de miembros de mi familia, que desde la distancia, han sabido aportar su pequeño granito de arena. Sin ellos nada de esto hubiera sido posible. Otra mención especial va dirigida a mis compañeros de Erasmus de via dello Statuto, que han seguido paso a paso todo el desarrollo del proyecto, ofreciéndome su apoyo y compañía, y dándome ánimos cuando más lo he necesitado. No existen palabras para agradecéroslo y un simple Grazie lo resume todo. Me gustaría también agradecer a Malena y a Diego, que han sufrido mi desorden, mis nervios y mis horarios intempestivos durante estos últimos tres meses, que me han dado fuerzas cuando no las tenía y que me han ayudado a finalizar este proyecto. Por último, me gustaría agradecer a toda la comunidad de Software Libre, por haberme ofrecido todas las herramientas que han hecho posible este proyecto y por su inestimable ayuda. Gracias a todos...

4 Abstract LongoMatch is a project which aims to create a sports video analysis software based on Free Software. In the practical side, this project will try to create a free tool that help sports specialists to analyze games using video and images by simplifying the process of identifying, storing and retrieving important plays of the game. In the technical side, this paper describes all the phases in the development of a Free Software project. Besides, it will try to give the guidelines to implement a cross platform multimedia application using exclusively free tools, describing the available technologies and procedures to achieve it.

5 Table of Contents Chapter 1.Introduction Background What do we mean by tactical video analysis? Video analysis in the analogue era Video analysis in the digital era A Multi platform Free Software Project Project contributors...5 Chapter 2.Methodology Characteristics Values Principles Practices Iterations First Iteration: Multimedia player Second Iteration: Base System and GUI Third Iteration: System Stabilization and refactoring Fourth Iteration: Management tools Fifth Iteration: Timeline Sixth Iteration: General improvements Seventh Iteration: Playlist support Eighth Iteration: Non linear video editor Ninth Iteration: Port to windows Tenth Iteration: Packaging Eleventh Iteration: Documentation, translations and web page Futures Iterations...12 Chapter 3.Requirements Analysis Functional requirements User Stories System GUI Multimedia system Use Case diagrams Main Use Case Descriptions Create New Project Open Project Edit Project Mark new play Edit a play Select play Create a playlist Create a new video from a playlist Play a playlist Non functional requirements...23 Chapter 4.System Design System Components...25 I

6 4.2Architectural view Workflows Data Data Model Data Dictionary Project Section Play Static design Packages diagram Class Diagrams LongoMatch LongoMatch.Time LongoMatch.DB LongoMatch.IO LongoMatch.Handlers LongoMatch.GUI...40 LongoMatch.Component...40 LongoMatch.Dialog...41 LongoMatch.Popup LongoMatch.PlayList LongoMatch.Multimedia...43 LongoMatch.Multimedia.Utils...43 LongoMatch.Multimedia.Player...44 LongoMatch.Multimedia.Capturer...46 LongoMatch.Multimedia.Editor...47 LongoMatch.Multimedia.Gui...47 Chapter 5.Mock up: The Graphical User Interface Starting Window File Menu Tools Menu View Menu Player Menu Project management dialogs Creation of a new project New project dialog Void file entry Video file error Opening a project Projects Manager Projects manager dialog Confirm deletion message Templates Management Project Template Edition Templates manager Capture and analysis window Multimedia player Plays list widget...60 II

7 5.2.8Play marker Buttons Widget Timeline widget Playlist widget Creating and editing playlists Creating a new from a playlist Opened project error...65 Chapter 6.Introduction to the used technologies Programing language Runtime Components Framework architecture Class library Common Language Infrastructure and Common Language Specification Managed and unmanaged code GStreamer Foundations Elements Pads Bins and pipelines GTK# Db4o: a Free Software object oriented database Relational database vs object oriented database Relational Model Object Oriented model Conclusions Db4o basics One line of code database Non needs to bother with Persistence Powerful Retrieval APIs and UIs...80 Chapter 7.System Implementation Design patterns Singleton Protected Variations Factory Delegation Event Model Controller Command Multimedia System Player Capturer Decode bin Display bin Encode bin Creating C# bindings for GStreamer Porting the multimedia system to Windows Coding GStreamer compilation Non linear editor...95 III

8 Extracting video segment from a video file Merging the video files Coding Graphical interface Design Timeline Timeline structure Drawing plays in the timeline Making the timeline interactive Database Interfaces Examples Storing a project Retrieving all the projects Deleting a project Internationalization Programing Translating Running Chapter 8.System Management and Deployment Monodevelop: an Integrated Development Environment for Mono Hosting the project in a forge Subversion Repository Layout Using Subversion Checkout Updating the working copy Committing changes Packaging Unix like systems Source code package Packaging for debian like systems changelog control copyright rules Creating the binary package Uploading the sources to a Personal Package Archiver (PPA) Windows Web page Chapter 9.Conclusions Appraisal Impact Future works IV

9 Figure Index Figure 1: Analysis process in the analogue era...2 Figure 2: Analyze process in the digital era...3 Figure 3: Use Case diagram: first approach...17 Figure 4: Final Use Case diagram...18 Figure 5: Component diagram...26 Figure 6: Event driven architecture...27 Figure 7: Model view controller diagram...28 Figure 8: Activity diagram...29 Figure 9: Entity relationship diagram...30 Figure 10: Packages diagram...32 Figure 11: MainClass class diagram...33 Figure 12: EventsManager class diagram...34 Figure 13: LongoMatch.Time class diagram...36 Figure 14: LongoMatch.DB class diagram...37 Figure 15: LongoMatch.IO class diagram...38 Figure 16: Delegates class diagram...40 Figure 17: LongoMatch.GUI class diagram...42 Figure 18: LongoMatch.Playlist class diagram...43 Figure 19: LongoMatch.Multimedia.Editor...44 Figure 20: LongoMatch.Video.Player class diagram...45 Figure 21: LongoMatch.Multimedia.Capturer...46 Figure 22: LongoMatch.Multimedia.Editor class diagram...47 Figure 23: LongoMatch.Multimedia.GUI class diagram...48 Figure 24: Starting Window...50 Figure 25: File Menu...50 Figure 26: Tools Menu...51 Figure 27: View Menu...51 Figure 28: Player Menu...51 Figure 29: New project dialog...52 Figure 30: Void file entry warning...53 Figure 31: Invalid video file error...53 Figure 32: Open project dialog...54 Figure 33: Projects manager...55 Figure 34: Confirm deletion message...56 Figure 35: Section properties...56 Figure 36: Project templates editor...57 Figure 37: Template creation and deletion...58 Figure 38: Templates manager...58 Figure 39: Main window in analyze mode...59 Figure 40: Multimedia player widget...60 Figure 41: Plays list widget...61 Figure 42: Plays control menu...62 Figure 43: Play marker buttons widget...62 V

10 Figure 44: Timeline Widget...63 Figure 45: Timeline menu...64 Figure 46: Playlist widget...64 Figure 47: New video properties dialog...65 Figure 48: Playlist error...65 Figure 49: Mono Framework Architecture...71 Figure 50: GStreamer overview...74 Figure 51: GStreamer pipeline for a basic ogg player...76 Figure 52: Events delegation to the "controller"...87 Figure 53: Player pipeline...89 Figure 54: Digital Video capturer...90 Figure 55: Decode bin...90 Figure 56: Display bin...91 Figure 57: Encode bin...91 Figure 58: Repository checkout Figure 59: Update the working copy with the Subversion plugin Figure 60: Commit the changes using the Subversion plugin Figure 61: LongoMatch web page VI

11 Chapter 1.Introduction Chapter 1. Introduction 1.1 Background In high-level sports, the use of new technologies is becoming an indispensable tool when improving the performances of a sportsman or a team. In sports team with a huge technical- tactical component, like basketball, soccer, or field hockey, the video analysis of the opponent (also denominated "scouting") has acquired a great importance. This importance is such, that to end up making a good analysis study and to be able to present it in an effective way to the players has become decisive to determine who wins the match. 1.2 What do we mean by tactical video analysis? The main goal of the head-coach is to give the guidelines on how should the team work together in the field to defeat the opponent. This depends basically on how he understands the game, but it's also conditioned by external factors, like the way the opponent plays. Hence, a coach must prepare his team depending on the rival, which is done analyzing the way he plays. This analysis can be done in-field or using recordings from a previous game. This last method is called tactical video analysis, and can be split up in three phases: Capture: Recording the match and storing it on a physical drive. Analysis: Annotating the important plays of a match and grouping them by categories. Presentation: Creating new videos with a subset of important plays that let 1

12 Chapter 1.Introduction understand relevant aspects of the opponent, and showing the to the interested parts Video analysis in the analogue era At the end of the 90's, with the arrival of the first video cameras and video recorders, trainers and coaches started using these new tools to analyze the opponents and their own teams. This process is very complex in the analogue era and demands a lot of waisted time. The plays' annotations are done in a bloc-notes, writing the plays' start and stop time and a little comment about the play. The review a specific play is not that simple, as the positioning of the tape is done manually having to wait until the tape reaches the chosen position, becoming many times an annoying task. Besides, the video edition requirements are very high (at least 3 specialized devices), and the final quality is not good enough. This process is described in the figure below. Figure 1: Analysis process in the analogue era Video analysis in the digital era At the half of the 90's, the Digital Video standard and the DVD made the process simpler. But we had to wait until the appearance of the first domestic DV cams and the new 2

13 Chapter 1.Introduction compressed video formats to finally get a standalone video analysis device: the personal computer. At this point, the PC can be used as a capturer and lets store the captured video in many formats, depending on the quality needs or the available space. The seeks are instantaneous and the video edition can be done with no need for other devices. The process becomes simpler as we can do all the process with just one device. Figure 2: Analyze process in the digital era A new idea started to grow-up into every one's mind. It consists in creating a software that integrates all the process with these basic requirements: Capture DV stream, display them and encode/store them in the hard disk. Be able to store in a database the most important plays of a game and be able to edit and review them. Order all the plays in a time-line to get a general vision of the game in a graphical way. Make instantaneous game statistics. Edit new videos with a set of selected plays. 3

14 Chapter 1.Introduction This is just a first approach to the wide brand-new set of possibilities offered by the use of the PC as standalone device to accomplish all the tasks. This project aims to give an integrated solution for most of these basics needs and the upcoming one, more specifics, and defined by the requirements of the potential users. 1.3 A Multi platform Free Software Project There is an upcoming new market around sports video analysis tools and, actually, there are just two professional tools that fulfill the needs of all the potential users, but that just reach a small portion of the market. These tools are privative tools and it cost is definitively too high for many of the final users, which goes from 6000 to depending on the software functionalities. These is the reason why I decided to created LongoMatch. This project does not want to provide a replacement for these tool as it's very hard to compete against two mature projects, the main scope is to provide an alternative tool to reach this huge missing part of the market. Besides, this project follows the Free Software philosophy [1] as the final goal is to offer a free alternative to these teams that couldn't afford the high cost of the privative tools. It is an effort to democratizes the world of sports, offering the possibility to everyone to compete in the sames conditions of equality. For this reason, this project is released using the GNU General Public License v2 (GPL) [2], the free software license created by the Free Software Foundation. In order to reach the highest number of users, another of the goals of the project is to develop a multiplatform software that can run both under Unix, Windows and Mac OS X systems. Creating such a system requires a bigger effort that becomes a challenge when it is a multimedia application as actually, every Operating System (OS) as it's own multimedia framework, like DirectShow for Windows, GStreamer or Xine for Linux and Quick Time for Mac OS X. In this paper I will introduce some of the available free software tools that can be used to develop a multiplatform application and I will give the guidelines, based on my researches, 4

15 Chapter 1.Introduction to create a multimedia system that can run on various OS. 1.4 Project contributors This project received the contribution from Antonio Morales López, president of the Spanish National Referees Committee. He is considered an expert in hockey video analysis, and was one the first Referees Manager to introduce the video analysis for studying referees and critical plays on internationals hockey championships. He contributed in the requirements' specifications, giving ideas for interesting new features and reviewing many others. He also helped on the design of the GUI, making it more usable and testing the final software. The Hockey Club Complutense also gave a great help to the project testing the system and using it in real conditions to analyze games of the Spanish Hockey Honor Division. 5

16 Chapter 1.Introduction 6

17 Chapter 2.Methodology Chapter 2. Methodology This project has been developed using the extreme Programing (XP) methodology [3], a form of agile software development. It was created by Kent Beck, Ward Cunningham and Ron Jeffries during the C3 (Chrysler Comprehensive Compensation System) development. Proponents believe that exercising these practices traditional software engineering practices taken to so-called "extreme" levels leads to a development process that is more responsive to customer needs ("agile") than traditional methods, while creating software of better quality. Proponents of Extreme Programming and agile methodologies in general regard ongoing changes to requirements as a natural, inescapable and desirable aspect of software development projects; they believe that adaptability to changing requirements at any point during the project life is a more realistic and better approach than attempting to define all requirements at the beginning of a project and then expending effort to control changes to the requirements. 2.1 Characteristics XP is an agile software development model that can be applied in small and medium projects, in team no bigger than 12 persons. In agile development all kind of unnecessary documentation and process is ruled out, allowing the team to focus into the important aspects without losing time with formal aspects of the process. 7

18 Chapter 2.Methodology In XP, details are communicated directly among the interested parts (including the client), solving confusions and doubts at this precise moment. So, XP is more focused to persons rather than to the process, and to get an usable software rather following a strict and bureaucratic process. On each iteration, a functional version of the software is released, so the client can test it and increase the information for the next iteration. 2.2 Values Here are describe some of the values the an XP project must have in mind: Simplicity: The simpler solution is always the best one. This does not means that we have to choose the first solution we have in mind, but this solution should: Make all that we wanted to do. Not contain any duplication. Pass the tests. Have the less elements as possible. Communication: The goal is to give all developers a shared view of the system which matches the view held by the users of the system. To this end, Extreme Programming favors simple designs, common metaphors, collaboration of users and programmers, frequent verbal communication, and feedback. Courage: Always design and code for today and not for tomorrow. This is an effort to avoid getting bogged down in design and requiring a lot of effort to implement anything else. Courage enables developers to feel comfortable with refactoring their code when necessary. This means reviewing the existing system and modifying it so that future changes can be implemented more easily. Another example of courage is knowing when to throw code away: courage to remove source code that is obsolete, no matter how much effort was used to create that source code. 8

19 Chapter 2.Methodology Principles To follow these values, some principles are proposed: Feed back: Extreme Programming sees feedback as most useful if it is done rapidly and expresses that the time between an action and its feedback is critical to learning and making changes. Unlike traditional system development methods, contact with the customer occurs in more frequent iterations. The customer has clear insight into the system that is being developed. He or she can give feedback and steer the development as needed. Assuming simplicity: This is about treating every problem as if its solution were "extremely simple". Traditional system development methods say to plan for the future and to code for reusability. Extreme programming rejects these ideas. The advocates of Extreme Programming say that making big changes all at once does not work. Extreme Programming applies incremental changes: for example, a system might have small releases every three weeks. By making many little steps the customer has more control over the development process and the system that is being developed. Embracing change: The principle of embracing change is about not working against changes but embracing them. For instance, if at one of the iterative meetings it appears that the customer's requirements have changed dramatically, programmers are to embrace this and plan the new requirements for the next iteration Practices The XP practices are divide in two parts: a set of rules that every XP project should use and some recommended practices but not compulsory, that must fulfill all the main rules. In this project, some of these practices could not be used for obvious reasons, like Pair programming or Whole Team. Some of the practices used are: 9

20 Chapter 2.Methodology Continuous integration. Maintain a code repository. Automate the build. Code refactoring. Design improvements. Small releases. Coding standard. Simple design. 2.3 Iterations Here, I describe the iterations I made during the development process until I wrote this paper First Iteration: Multimedia player The first iteration is focused on the development of the multimedia player. This iteration includes the coding of the video backend and the bindings for C#, as well as the development of the player GUI Second Iteration: Base System and GUI The second iteration is focused on the development of the base system and the GUI. In this iteration the oriented-object database is implemented, the first graphical interface is designed with a list of plays and a set of buttons to add new plays and the multimedia player is integrated to the system Third Iteration: System Stabilization and refactoring In this iteration, all the previous code is revised trying to fix errors. As the previous work are the foundations of the system it is reviewed and checked to continue with the 10

21 Chapter 2.Methodology development. Some of the code is refactored as some of the classes' names chosen at the beginning do not describe them correctly as well as for some methods Fourth Iteration: Management tools This iterations includes the development of the Projects Manager and the Templates Manager tools. These two tools adds a better projects support to the system Fifth Iteration: Timeline In this iteration a new feature is added: the timeline. This element is very important as all the plays' edition is done through using the timeline. It's a very specialized widget ans it must be created from the scratch. It took a whole iteration to implement it Sixth Iteration: General improvements In this iteration, the multimedia player player is improved (the play-rate can be change to view the video in slow motion and some minor bugs are corrected). The timeline is also improved with a better graphical design and more functions to interact with the user as well as the plays list that can now show a little preview of the play Seventh Iteration: Playlist support In this iteration I introduced palylists support to the system, including a graphical component to manage them Eighth Iteration: Non linear video editor In this iteration I created the non-linear video editor and I added a GUI element to launch it Ninth Iteration: Port to windows In this iteration the port to win32 system is started. Some parts of the code are reviewed to let compile it in both operating systems and GStreamer is compiled for Windows. 11

22 Chapter 2.Methodology Tenth Iteration: Packaging In this iteration the work is focused in packaging the application both for Linux and for Windows Eleventh Iteration: Documentation, translations and web page A user manual is written, the application is translated to Spanish, French and Italian and the web page is finally published Futures Iterations In futures iteration it's planned to add DV capture support for real-time analysis. It's also planed to add support for parallel view mode to compare similar plays in tow players and synchronize them. Later, I have also planed to create a kind of client-server application to share plays among computers in the same area via wireless connexions. 12

23 Chapter 3.Requirements Analysis Chapter 3. Requirements Analysis In XP requirements are specified using User Stories. They serve the same purpose as Use Cases but they are not same. User Stories are written by the customers as things that the system needs to do for them and not by the developers. On the other hand, Use Cases describe the interaction between a primary Actor (the initiator of the interaction) and the system itself, represented as a sequence of simple steps. XP doesn't forbid the use of Use Cases. In fact they can be used in combination, using the Use Case as a generalization for one or more User Stories. For this project we can consider that the clients are Antonio Morales and the HC Complutense as the requirements requests comes from them. As we saw, in XP the system requirements may increase along the development, and new requirements can often be specified after an iteration. The actual description is based on the last iteration before writing this paper, this is, the ninth iteration. 3.1 Functional requirements User Stories In this section, I will list all the user stories accumulated along the development process until the ninth iteration 13

24 Chapter 3.Requirements Analysis System I want to store in a database projects for media files. A project must contain basic information of the game, like the teams playing the game, the final score and the date of the game. A project must store plays of the game. These plays are described by a name, the start time, the stop time and the team related to the play. I want to classify plays by categories. 20 categories are enough for analyze a game. I want to identify categories with a name and a color and a default start gap and stop gap. A project must be flexible, and the number of categories used for a project can different from 20. The categories should be represented as project templates, this way a user can define new templates and select them when creating a new project without redoing the same work each time. The system should have support for playlists. A playlist can be made with plays from different projects. A project can be created from a stored file or captured from a DV device. Playlist are stored in files, outside the database. The system should be able to create new videos from a playlist. When an element of a playlist is loaded, the system plays all the following elements of the playlist until it reaches the end of the playlist GUI I want to see the game in a player embedded in the main window. The video stream is controlled with buttons and a scale to change the actual position. The play 14

25 Chapter 3.Requirements Analysis speed is changed using another scale. Plays in a project should be listed in a widget at the left of the player. They should use a tree structure, where the roots of the tree are the categories and plays are the leafs of these categories. When I click a play of the list, this play must be shown in the media player. The player sets the position to the start time, and stop when it reaches the final of the play. Something must change in the GUI to tel me know that a play is actually loaded in the system. Plays are added to the database with a set of 20 buttons. These buttons should display the name's category and should be located under the media player. When a button is clicked the play is stored using the default start gap and stop gap defined for this section. Plays can be deleted from the project's database directly from the list, maybe using a pop-up menu. The name of the play is edited directly from the list. The GUI should have a timeline. This timeline is divided in 20 sections, one for each category, and it displays the play as a colored rectangle. The user should be able to edit the start and stop time of a play using the timeline. The timeline should be able to zoom-in and zoom out. The GUI should have a dialog to manage projects The GUI should have a dialog to create and edit projects templates. Playlist are shown in a widget at the right of the player. This widget can be visible or not. With this widget the user should be able to create new playlists, load a saved playlist, and launch the video editor to create new plays. The player is controlled using the keyboard and the mouse. If we click in the video 15

26 Chapter 3.Requirements Analysis window, the player toggle its current state. 'z' and 'x' makes the player go one frame backward and one frame forward Multimedia system The player should be able to load plays. When a play is loaded the player displays only the video segment defined by the start time and the stop time of the play. The player can change the playrate The capturer can encode DV stream and store them in the hard disk. Creation of an utility that can split segment from a video file and merge them into a new file. Utility to read meta-data from a video file. We should be able to captures individual frames from a video stream Use Case diagrams From the previous user stories we can define uses cases to describe the system requirements. As we saw before, an use case in the XP development model is usually made by joining various user stories. A deeper analysis of the system requirements, based on the first Use Case diagram (Figure 3), lets us to identify some of the system's components for the design step. The final use case diagram (Figure 4) gives a better global vision on how will the system be designed, grouping the use cases by similar functionality. 16

27 Chapter 3.Requirements Analysis Figure 3: Use Case diagram: first approach 17

28 Chapter 3.Requirements Analysis Figure 4: Final Use Case diagram 3.2 Main Use Case Descriptions When working with use cases, the most important part is the description of each one, not the diagram itself. In this section I will describe the most important use cases using a template with the following data: 18

29 Chapter 3.Requirements Analysis Name: The name of the use case. Initiator: Actor who launches the use case. Goal: Main purpose of the use case. Preconditions: Defines all the conditions that must be true to meaningfully cause the initiation of the use case. Main success scenario: Description step-by-step of the use case. Alternative paths: secondary paths or alternative scenarios, which are variations on the main theme. Postcondition: describes what the change in state of the system will be after the use case completes Create New Project Name: Create Project Initiator: User Goal: Create a new project from a video file Preconditions: 1.The user clicks the menu item to create a new project. 2.The system shows a dialog to edit the project properties. 3.The user fills all the project's properties. 4.The system checks that any of the properties is void. 5.The system checks the validity of the chosen video file. 6.The system creates the project. 7.The system stores the project in the database. 8.The system loads the project in the GUI. Alternative Paths: 4.The system informs the user that one of the fields is void 5.Go to step 3. Main Success Scenario: 5. The system informs the user that the file chosen is not a valid video file. 6.Go to step 3. Postconditions: 19

30 Chapter 3.Requirements Analysis Open Project Name: Open Project Initiator: User Goal: Open a project stored in the database Preconditions: Main Success Scenario: 1.The user clicks the menu item to open a new project. 2.The system retrieves all the projects from the database. 3.The system shows a dialog with a list of all the projects. 4.The user select one of the projects. 5.The system loads the project in the GUI. Alternative Paths: Postconditions: The project is loaded on the GUI Edit Project Name: Edit Project Initiator: User Goal: Edit the properties of a stored project Preconditions: The project is not actually loaded 1.The user clicks the item menu to edit a project. 2.The user selects the project to edit. 3.The user edit the project properties. 4.The user clicks the button to save the project. 5.The system checks that any of the properties is void. 6.The system checks the validity of the chosen video file. 7.The system saves the project. Alternative Paths: 5.The system informs the user that one of the fields is void. 6.Go to step 3. Main Success Scenario: 6. The system informs the user that the file chosen is not a valid video file. 7. Go to step 3. Postconditions: 20

31 Chapter 3.Requirements Analysis Mark new play Name: Mark New Play Initiator: User Goal: Mark a new play in the project. Preconditions: A project is loaded Main Success Scenario: 1.The user clicks the button to mark a new play. 2.The system gets the actual position of the stream. 3.The system calculates the start time and the stop time from the project's properties. 4.The system takes a snapshot of the play. 5.The system creates a new play. 6.The system refresh the plays list. 7.The system stores the play in the project. 8.The system saves the project changes in the database. Alternative Paths: Postconditions: The new play has been created an stored in the project Edit a play Name: Edit Play Initiator: User Goal: The user edit the properties of a play Preconditions: A project is loaded Main Success Scenario: 1.The user edit a play 2.The system refresh the plays list 3.The system saves the changes of the play. 4.The system saves the project's changes in the database. Alternative Paths: Postconditions: The edited play has been saved in the project 21

32 Chapter 3.Requirements Analysis Select play Name: Select Play Initiator: User Goal: Select a play to view in the multimedia player Preconditions: A project is loaded Main Success Scenario: 1.The user selects a play. 2.The system gets the start time and the stop time from the play. 3.The system sets a start time and a stop time in the player. 4.The system starts playing the video segment. Alternative Paths: Postconditions: The play has been loaded into the multimedia player Create a playlist Name: Create Playlist Initiator: User Goal: Create a playlist with a set a plays from any of the projects from the database Preconditions: Main Success Scenario: 1.The user clicks the button to create a playlist. 2.The system opens a dialog with an entry to set the playlist's name. 3.The user enters the playlist name. 4.The system creates the playlist. 5.The system stores the playlist. Alternative Paths: Postconditions: The new play has been saved in the database Create a new video from a playlist Name: Create A New Video From a Playlist Initiator: User Goal: Create a new video with the plays in the playlist. Preconditions: A playlist is loaded Main Success Scenario: 1.The user clicks the button to create a new video. 2.The system prompts the user to select the output filename and the video quality. 22

33 Chapter 3.Requirements Analysis 3.The user enters the output filename and the video quality. 4.The system creates the new video. Alternative Paths: Postconditions: A new video has been created Play a playlist Name: Play a Playlist Initiator: User Goal: Open a playlist and plays all the elements Preconditions: No project is loaded Main Success Scenario: 1.The user loads a playlist. 2.The system plays the first element of the playlist. 3.The system still playing elements from the playlist until it reaches the end of the playlist. Postconditions: 3.3 Non functional requirements Non-functional requirements are requirements that specify criteria that can be used to judge the operation of a system, rather than specific behaviors, they define how a system is supposed to be. As we saw in the introduction, the system must fulfill some requirements about the runtime, the license, the portability and the usability: Use a Free Software license. Free Software third-parties dependencies. Implemented in C#. Run using the Mono runtime. OS independent, portable. Must run under Unix systems and Windows systems. Usable: intuitive and easy-to-use Graphical User Interface. Support for most common video/audio codecs. Multilingual (localized). 23

34 Chapter 3.Requirements Analysis 24

35 Chapter 4.System Design Chapter 4. System Design This chapter is focused on the system design, which is the definition of the architecture, components, modules, interfaces and data for the system to satisfy the specified requirements described in the last chapter. Using the Unified Modeling Language (UML), I will try to create an abstract model using components diagrams(to model the system's components and the system's architecture), an activity diagram (to model the workflow of the system), class diagrams (to model the static structure of the system) and an entityrelation diagram to represent the data of the system. 4.1 System Components The component diagram (Figure 4) depicts how the software system is split up into components and the dependencies among them. The system is composed of the following components: Graphical User Interface: This components manage all the GUI stuff that let the user interact with the system. Multimedia System: This component provides multimedia support to the system, like a media player, a video capturer and a video editor. Projects Management System: Manage all the system's data, handling project's creation, edition and deletion. Playlist Management System: Adds playlists support to the system and lets create, edit, and save playlists. 25

36 Chapter 4.System Design System Manager: Interconnects all the system's components. It's the system's brain as it handle all the intercommunication in the system. Figure 5: Component diagram The third-parties components like the Database, the GUI Framework and the Multimedia Framework are wrappers between the low-level components and the system. Each component provides a set of interfaces that give access to its functionalities to other components. The Graphical User Interface component provides an interface called IGUImanager, used by the System Manager to update it with the changes notified by other components. The Playlist Management System provides the interface IPlaylistManager, used by the System Manager to create, edit and save playlists. The Multimedia System provides 4 interfaces, IPlayer, ICaturer, IVideoEditor, IMetadataReader, that let access the System Manager to the media player, the video 26

37 Chapter 4.System Design capturer, the video editor and the stream meta-data reader, respectively. Finally, the Projects Management System provides the IProjectsManager interface which is connected to the System Manager to let him create, edit, list, and delete the projects stored in the database. 4.2 Architectural view As the system is a GUI-oriented software, the best architectural pattern to describe it is the event-driven architectural view. In the last section ( 3.1) I described how are the components interconnected, but I did not describe how does they intercommunicate. A GUI-oriented system is based on the interaction between the user and the GUI, which sends events that are processed by the system. Besides, other elements could also need to notify other components of the system, as for example the media player, that needs to update the GUI with the current position of the stream. The next diagram shows the eventdriven architecture of the system. Figure 6: Event driven architecture A good design for a system relies on separating business logic from user interface considerations, resulting in an application where it is easier to modify either the visual appearance of the application or the underlying business rules without affecting the other. For this, I chose to design the architecture using also the model-view-controller (MVC) 27

38 Chapter 4.System Design architectural pattern. In MVC, the model represents the information (the data) of the application and the business rules used to manipulate the data; the view corresponds to elements of the user interface such as text, checkbox items, and so forth; and the controller manages details involving the communication to the model of user actions such as keystrokes and mouse clicks or movements. The next diagram (Figure 7) depicts the relationship between the Model, View, and Controller. Figure 7: Model view controller diagram Applying this pattern to our system we can identify the View as the GUI, the controller as the Events Manager/System Manager and the Model as the rest of the components listed in the Figure 6. To explain it better I will describe the control flow when a user wants to open a project: 1. The user interacts with the GUI (View) clicking the open project menu item. 2. The System Manager (Controller) handles the input event from the user interface, via a registered handler in the Events Manager. 3. The System Manager notifies the Model of the user action, the Project Manager 4. The GUI uses the Model (indirectly) to generate an appropriate user interface listing all the projects in the system. The view gets its own data from the model. The model has no direct knowledge of the view. 5. The user interface waits for further user interactions, which begins then a new cycle. 4.3 Workflows The next step is to represent the business and operational step-by-step workflows of components in a system, using an activity diagram that shows the overall flow of control. 28

39 Applying UML and design patterns to design an implement a video sports analyze tool based on Free Software. Chapter 4.System Design Figure 8: Activity diagram 29

40 Chapter 4.System Design 4.4 Data The system is nothing but an application that stores data about a video stream. The users stores video segments with a title to identify plays of the game. These plays, grouped by categories, set up a project for a media file Data Model The abstract and conceptual representation of the system's data is done through the entity-relationship model. Diagrams creating using this process are called entityrelationship diagrams (ERD). The ERD derived from the system's data representation is shown in the next figure (Figure 9). Figure 9: Entity relationship diagram 30

41 Chapter 4.System Design Data Dictionary Project Name Type Description File Name string (Primary Key) Path of the media file used for this project Local Team string Name of the local team Visitor Team string Name of the visitor team Local Goals int Goals scored by the local team Visitor Goals Int Goals scored by the visitor team Match Date Date Date Section Name Type Description ID Int (Foreign key) Unique identifier for a section Name string Section's Name Start Time long Start time gap in ms Stop Time long Stop time gap in ms Color string String representation of the section's rgb color Visibility Boolean Whether this section is in use or not Play Name Type Description ID Int (Foreign key) Unique identifier for a play Name string Play Name Start Time long Play start time in ms Stop Time long Play stop time in ms Team string Identifies a play with a team (local, visitor or none) Snapshot path string Path for the snapshot file 31

42 Chapter 4.System Design 4.5 Static design Packages diagram The system is split up in packages directly related with the components defined previously. The representation of the system for this kind of view is done using the packages diagram. Figure 9 depicts the logical hierarchical decomposition of the system. Figure 10: Packages diagram LongoMatch is the main package. It holds all the sub-packages that compounds the system. The GUI package contains all the classes directly related with the user interface that allow to set-up all the windows, dialogs, and widgets of the Graphical User Interface. The Multimedia packages contains all the classes that set up the multimedia system and provide video display,capture, and edition features. The DB package contains all the database-related classes that add persistence to the system. The Playlist package contains all the classes that add playlist support to the system. The Time package contains the classes related with time structures, as plays, playlist 32

43 Chapter 4.System Design segments, etc.. The Handlers package contains the definition for the delegates used by the components to communicate with the System Manager The Utils packages contains helper classes that cannot be classified into any of the other packages Class Diagrams LongoMatch The root package contains the following classes: MainClass: Initialize the system and realize some checking routines. SystemManager: Adds delegate methods for all the system 's events. Figure 11: MainClass class diagram 33

44 Chapter 4.System Design Figure 12: EventsManager class diagram LongoMatch.Time This package contains the followings classes: Time: Represents a millisecond instant. It's used to standardize the time measure in the system. TimeNode: Basic gap time representation. This type is the parent class for any object that needs to define a temporal segment. It sets a name, a stop time, and a start time. PixbufTimeNode: Inherits from TimeNode, adds a Gdk.Pixbuf to the parent class. SectionTimeNode: Used to represent the project's sections. The start time sets 34

45 Chapter 4.System Design the default start gap for a play in this section, and the stop time sets the default stop gap. It adds a property to set the visibility of a section. MediaTimeNode: Represents a play in the system. Inherits from the PixbufTimeNode and adds properties to contextualize the play inside a project and to measure the segment using frames rather than milliseconds. PlayListTimeNode: Represents a playlist element. A playlist element is not associated to any project so a new property has to be defined to link this element to a media file (the filepath property). It also sets the valid property, used to set if the media file is accessible by the system LongoMatch.DB This packages contains the followings classes: MediaFile: Represents a media file in the system. Defines it's path and some metadata information describing it like its length, its frame rate, and if it's contains audio and video Sections: Represents a project template. It's composed of a set of 20 SectionTimeNode to define each one of the project's sections. Project: Represent a project in the system. Contains a Sections object to set-up the project template, 20 arrays to store the plays of each section and a set of properties to describe the project. DB: Wrapper to the database. Provides methods to store, edit, delete, and retrieve projects from the database. 35

46 Applying UML and design patterns to design an implement a video sports analyze tool based on Free Software. Chapter 4.System Design Figure 13: LongoMatch.Time class diagram 36

47 Applying UML and design patterns to design an implement a video sports analyze tool based on Free Software. Chapter 4.System Design Figure 14: LongoMatch.DB class diagram 37

48 Chapter 4.System Design LongoMatch.IO The class diagram for this package is shown in Figure 15 and contains the following elements: SectionsWritter: Serialize a project template to an XML file XMLReader: Provides a set of methods to read primitive types from an XML file. SectionsReader: Deserialize a project template stored in an XML file. Figure 15: LongoMatch.IO class diagram LongoMatch.Handlers The system defines the following delegates: TimeNodeSelectedHandler: Define the method signature that should be used to 38

49 Chapter 4.System Design capture events notifying a TimeNode has been selected passed as the first argument of the method. TimeNodeChangedHandler: Define the method signature that should be used to capture events notifying a TimeNode has been changed passed as the first argument of the method. TimeNodeDeletedHandler: Define the method signature that should be used to a TimeNode has been deleted passed as the first capture events notifying argument of the method. NewMarkHandler: Define the method signature that should be used to capture events notifying a new play has been created. The first argument sets the section the play belongs to NewMarkAtFrameHandler: Define the method signature that should be used to capture events notifying a new play has been created. Used has the previous one but adding the frame position of the new play. PlayListNodeSelectedHandler: Define the method signature that should be used to capture events notifying an element in the playlist has been selected. This element is passed in the first argument. PlayListNodeAddedHandler: Define the method signature that should be used to capture events notifying an element must be added to the playlist. This element is passed in the first argument. PositionChangedHandler: Define the method signature that should be used to capture events notifying a change in the stream's position. This new position is passed in the first argument. ProjectSectedHandler: Define the method signature that should be used to capture events notifying a project has been selected. This element is passed in the first argument. 39

50 Chapter 4.System Design ProgressHandler: Define the method signature that should be used to capture events notifying a progress in a task. SnapshotSeriesHandler: Define the method signature that should be used to capture events notifying to start the snapshot series capturer. Figure 16: Delegates class diagram LongoMatch.GUI The class diagram for this package is shown in Figure 24. The elements inside this package are classified in three groups: components (for the widgets), dialogs and pop-up windows. The main window doesn't belong o any of these categories and remains in the root of the package. LongoMatch.Component ButtonsWidget: Shows 20 buttons with sections' names for the current project. Used to create new plays. FileDescriptionWidget: Lets set-up and edit graphically the project's properties. PlayListTreeView: This widget uses a TreeView to display a list of playlist elements. 40

51 Chapter 4.System Design PlayListWidget: Embed a PlayListTreeView to display the elements of the playlist. Shows 4 buttons to create, open and save playlists and to create a new video from the playlist. ProjectsListWidget: List a set of projects to select one of them. SectionsPropertiesWidget: Lets edit the sections of project template. TimeAdjustWidget: Lets edit the start and stop gap of s SectionsTimeNode. TimeLineWidget: Shows the plays in a timeline. Lets edit and create new plays. TimeNodesProperties: Graphical editor for the SectionsTimeNode properties. TimeNodesTreeView: TreeView that list all the plays in a project. TimeReferenceWidget: Draws a rule for the timeline. TimeScale: Draws a row for each section and the plays they contain TreeWidget: Uses the TimeNodesTreeView to display the plays of the current project LongoMatch.Dialog DBManager: Dialog to manage the projects stored in the database. NewProjectDialog: Dialog to set-up the properties of a new project. OpenProjectDialog: List all the projects in the database to select one of them an open it. SectionsTemplates: Dialog to create and edit new template. TemplateEditor: Dialog to edit the template of a project. LongoMatch.Popup CalendarPopup: Pop-up window containing a calendar. 41

52 Applying UML and design patterns to design an implement a video sports analyze tool based on Free Software. Chapter 4.System Design Figure 17: LongoMatch.GUI class diagram 42

53 Chapter 4.System Design LongoMatch.PlayList IPlayList: Interface that a class must implement to realize the basic playlist functions. Playlist: Implementation of the playlist interface. Figure 18: LongoMatch.Playlist class diagram LongoMatch.Multimedia LongoMatch.Multimedia.Utils IFramesCapturer: Interface definition for a an object that can capture frames from a video file. IMetadataReader: Interface definition for a an object that can capture frames from a video file. 43

54 Chapter 4.System Design FramesSeriesCapturer: Captures frames for interval with a specified framerate. TimeString: String representation of a millisecond instant. Figure 19: LongoMatch.Multimedia.Editor LongoMatch.Multimedia.Player IPlayer: Interface definition for multimedia player. GstPlayer: Implementation of IPlayer, ICapturer, and IMetadataReader based on GStreamer. UseType: Defines various use type for the GstPlayer type. 44

55 Chapter 4.System Design Figure 20: LongoMatch.Video.Player class diagram 45

56 Chapter 4.System Design LongoMatch.Multimedia.Capturer ICapturer: Interface definition for a DV capturer. GstVideoCapturer: Implementation of ICapturer based on GStreamer. VideoEncoderType: Enumeration of video encoders. AudioEncoderType: Enumeration of audio encoders. UseType: Enumeration of possible use types of GstVideoCapturer instances. Figure 21: LongoMatch.Multimedia.Capturer 46

57 Chapter 4.System Design LongoMatch.Multimedia.Editor IVideoEditor: Interface definition for a non-linear video editor. MencoderVideoEditor: Implementation of IVideoEditor based on mencoder. AudioQuality: Enumeration of quality levels for the audio encoding. VideoQuality: Enumeration of quality levels for the video encoding. Figure 22: LongoMatch.Multimedia.Editor class diagram LongoMatch.Multimedia.Gui PlayerBin: Multimeda player widget. CapturerBin: Capturer Widget. VolumeWindow: Pop-up window with a scale to set volume level. 47

58 Chapter 4.System Design Figure 23: LongoMatch.Multimedia.GUI class diagram 48

59 Chapter 5.Mock up: The Graphical User Interface Chapter 5. Mock up: The Graphical User Interface LongoMatch is a GUI oriented application, and so, the graphical interface is the most important components. The video analysis requires a clean and easy-to-use interface to take decisions in the fastest way. An overloaded interface can lead to mistakes and a loose of productivity, that's why the project's GUI must be designed to give the user the control of the analysis without making to much confusion between the different elements and without mixing functionalities. In the requirements phase we identified the following components: Multimedia player/capturer: displays the multimedia stream and let control it using buttons. Plays list: shows all the plays stored in a project grouped by categories. Play-marker buttons: this widget contains the buttons to create a new play for each one of the defined categories. Time Line: interactive time line that shows all the plays and let adjust them. Playlist: shows all the plays from a play-list with the option to edit them. The application is also composed with transitive components, like the templates manager, the projects manger and all the dialogs related to information, warnings, and error messages. In this section I will describe all the GUI components, making emphasis on explaining the way they work and how does the user interacts with them. 49

60 Chapter 5.Mock up: The Graphical User Interface 5.1 Starting Window The program starts with an initial window showing LongoMatch's logo. This main window gives access to the all the functions through the main menu. Figure 24: Starting Window File Menu The File menu contains the following elements: New Project (Ctrl+N)1: Opens a dialog to create a new project. Open Project (Ctrl+O): Opens a dialog to create a new project. Save Project (Ctrl+S): Saves the current project in use. Active only when a project is opened. Figure 25: File Menu Close Project (Ctrl+C): Close the current project in use. Active only when a project is opened. 1(Ctrl+N) is the combination key to access the element with a keyboard shortcut. In this case using the CONTROL key in combination with the 'N' key. 50

61 Chapter 5.Mock up: The Graphical User Interface Open Playlist (Ctrl+L): Opens a saved playlist Tools Menu This menu gives access to the different tools provided to manage LongoMatch: Projects Manager (Ctrl+P): Opens LongoMatch's projects manager used to edit all the projects from the database. Templates manger (Ctrl+T): Opens the templates manager, used to create or edit project templates. Figure 26: Tools Menu Take Snapshot: Capture the current frame View Menu This menu controls the different views of LongoMatch: Figure 27: View Menu Full Screen: Toggles full screen view. Playlist: Hides/Shows the playlist. Capture Mode: Sets capture mode. Analyze Mode: Sets analyze mode Player Menu This menu controls the multimedia player: Figure 28: Player Menu Play: Sets the player in play state. Pause: Sets the player in pause state. Next: Jump to the next playlist element Previous: Jump to the previous playlist element or to the start of the selected play. 51

62 Chapter 5.Mock up: The Graphical User Interface 5.2 Project management dialogs Creation of a new project New project dialog The creation of a new project starts in the File menu, selecting the New Project action. It opens a new dialog to set-up the project properties. Figure 29: New project dialog The New Project dialog has the following components: Local Team: Entry to set-up the name of the local team. Visitor Team: Entry to set-up the name of the visitor team. Local Goals: Spin button to select the goals scored by the local team. Visitor Goals: Spin button to select the goals scored by the visitor team. Template: Selector to choose the project template and edit it if needed. Date: Sets the date of the game. 52

63 Chapter 5.Mock up: The Graphical User Interface File: Select the video file to use with the project through the Open button. Accept: validates all the conditions and creates the project. Cancel: Exit to main windows canceling the project creation. The project creation requires to validate the File entry. It's the only property that cannot be void as without a video file we could not do an analysis. This entry is not editable and is only set with the Open button. This way we can check if the selected file exists and if its a valid video file Void file entry When the File entry is void the application shows a warning message telling this entry is void. Figure 30: Void file entry warning Video file error The file selected with the file selector is checked to test if it's a support file by the video player. If it isn't supported an error message is shown with the error2. Figure 31: Invalid video file error 2 The possible errors are many. The error could be thrown, for example, because the video player doesn't support one of the codecs or because the file doesn't contain any video (eg: trying to open an Open Office document or a PDF file). 53

64 Chapter 5.Mock up: The Graphical User Interface Opening a project Opening a project previously created and stored in the database is done selecting the Open action in the File menu. Figure 32: Open project dialog This dialog shows a list with all the projects in the database. Selecting an element of the list and clicking the Accept button opens the project. The Cancel button returns to the main window Projects Manager Projects manager dialog This dialog is used to manage the database. It can be used to edit an existing project or to delete it. It's a combination of the Open Project dialog and the New Project Dialog, the first one used to select the project to edit and the second one to change the properties. The main difference between the New Project Dialog and the widget displayed in this dialog is that there is no more combobox to select the template, just the edit button to edit 54

65 Chapter 5.Mock up: The Graphical User Interface it, because a stored project already contains the sections information. The right part of the widget, the one related with the project's properties is unsensitive until no project is selected. Once a project is selected, the entries are filled-up and the selected project is editable. The Save button and the Delete button are only active when a project is selected. Clicking the Save button saves the selected project and clicking Delete delete from the Database the current project Figure 33: Projects manager Confirm deletion message When deleting a project a confirmation message is shown to inform the user the project that he is going to delete, asking him to confirm the deletion. It's a standard behavior the avoid deletions by mistakes. Figure 34: Confirm deletion message 55

66 Chapter 5.Mock up: The Graphical User Interface Templates Management Every project has a set of properties that are set-up through the project template in which is defined the name of each category, the default start gap, the default stop gap and its color. LongoMatch provides one dialog to create and edit the user templates, and another one to edit the specific template used by a project Project Template Edition The edition of a project's templates can be done, as we saw previously, with the projects manager clicking the Edit button in the template section. This opens a dialog with 20 section properties, one for each category. Figure 35: Section properties For each section we can configure the followings properties: Name: The name used to identify the section. Start gap: Seconds gap to set-up the start time of a play. Stop gap: Seconds gap to set-up the stop time of a play. Color: Color to identify the play of the same section. Visible: Sets the visibility of the section3. The dialog contains 2 control buttons: Accept: Save the changes to the project template. Cancel: Cancel all changes and closes the dialog. 3 For some projects 20 sections are too much. With this property the user can select the number of visible sections. This way, a project can be configurable to fit the user requirements. 56

67 Chapter 5.Mock up: The Graphical User Interface Figure 36: Project templates editor Templates manager The templates manager is a tool accessible through the Templates Manager action in the Tools menu. This tool is used to create, delete and edit projects templates. On the left side, a list and a set of 3 buttons lets the user to create and delete existing templates as well as select a template to edit it: List: Shows the existing templates. Left button: Creates a new template launching a dialog to select the template's name. Center button: Saves selected template. Right button: Delete selected template launching a dialog to confirm the action Figure 37: Template creation and deletion 57

68 Chapter 5.Mock up: The Graphical User Interface On the right side of the dialog there are 20 sections properties' editors that let change the properties of each project's section as we saw in To edit a templates the user just has to select the template in the list, make all the changes in the section properties' editor and the save the templates using it's correspondent button. Figure 38: Templates manager Capture and analysis window When a project is loaded, the logo is hidden and the application shows its main widgets, the ones used to do the analyze of the match. In this chapter we will discuss the basics of each one. 58

69 Chapter 5.Mock up: The Graphical User Interface Figure 39: Main window in analyze mode Multimedia player The multimedia player is maybe the most important widget of the project as its in charge of showing all the video streams. Its user interface lets the user to control the stream, changing the stream position, change the actual state (eg: to play to pause) as well as change the playback speed: Close button: This button is only shown when a play is loaded in the player. Clicking this button close the actual play and sets the player in a normal sate (without a start and a stop time, the one from the loaded play) Play button: Sets the player in the play state. Pause button: Sets the player in a paused state. 59

70 Chapter 5.Mock up: The Graphical User Interface Previous button: If no play is loaded, it reset the player to beginning of the stream. If there is loaded play, it seeks to start time of the play. Next button: Jump to next play in the playlist. Seek bar: Lets perform seeks in the video. Time label: Shows the actually position of the stream and the total length of the clip. Volume button: Changes the volume of the multimedia player. Playback speed bar: Changes the playback speed from 2x to 1/25x. Figure 40: Multimedia player widget Plays list widget Every project as a set of 20 sections with a variable number of plays for each one. This widget shows all the plays in the project grouped by sections, The roots of the tree are the section their self. The plays of a sections are represented like their children. For each play, the widget shows a snapshot of the play, the name assigned to this play, its assigned 60

71 Chapter 5.Mock up: The Graphical User Interface team, and its start time and its stop time. The widget also lets the user to select and edit them: Section name edition: Clicking in the section's name lets the user change the name of the section. Play name edition: Clicking on the play' name lets the user to edit its name. Play selection: Double-clicking on the play' row loads the play on the multimedia editor. Figure 41: Plays list widget Right-clicking on a play' row opens a pop-up menu that lets control other aspects of a play: Team Selection: Lets change the team actually assigned to this play. Add to playlist: If the playlist is loaded, adds this play to the playlist. Delete: Delete the play from the project's database. 61

72 Chapter 5.Mock up: The Graphical User Interface Figure 42: Plays control menu Play marker Buttons Widget The first time the user analyzes a match he must be able to add plays to the project with the default start and stop gap for each play defined in the project template. This widget is composed by a set of 20 buttons, each one associated to one of the 20 sections. The button's name is taken from the name of the section it is linked to. When the user clicks one of these buttons, a new play is added to the project in the section the button belongs to. If one the section is set a non-visible by the user, the button is not active and cannot be clicked. Figure 43: Play marker buttons widget 62

73 Chapter 5.Mock up: The Graphical User Interface Timeline widget The timeline widget is probably the most used widget in the application as its capable to do almost all the analysis work. Its main function is to represent all the plays to give to the user an overall view of the match in a graphical way. Thus, the user can have a kind of overview of the match just by watching how the plays are organized in the timeline. To achieve this goal, it includes a zoom function to fit the timeline granularity to user requirements. On the top, the timeline shows a rule that divides it in smaller sections. It has has one row for each section, and each play is drawn with a rectangle starting at the start time and with the length of the play, colored with the assigned color in the project's template as shown in the next figure. Besides, it shows a moving-line that indicates the actual position of the stream. Figure 44: Timeline Widget The left side of the timeline has 3 buttons that lets control the timeline itself: Zoom in: Increase the zoom level. Zoom level: Decrease the zoom level. Auto seek: Move the start of the visible timeline to current position. The timeline, besides its graphical function, is also used to manage the plays. Setting the 63

74 Chapter 5.Mock up: The Graphical User Interface cursor in the borders of the rectangle delimiting the start and stop time of play, the user can change these values by moving the start or the stop time to desired position. Right clicking on a play shows a pop-up menu with the followings functions: Add play: Adds a new play with a central time defined by the cursor position. Delete play: Delete the selected play Playlist widget Figure 45: Timeline menu This widget is used to create/open/edit playlists. It's not visible by default, and can be shown by selecting the Playlist action in the View menu. It's composed by a list that show the elements of a the loaded playlist and a set of buttons that lets open, create and save a playlist. The list is not visible until a playlist is loaded or a new one is created Creating and editing playlists To create a new Playlist the user has to click the New button. This shows a dialog to select the playlist name. The user can load a saved playlist by clicking the Open button witch opens a file chooser to select the desired playlist. Saving a playlist is done by clicking the Save button. Figure 46: Playlist widget To add an element to the playlist the user has to go to the 64

75 Chapter 5.Mock up: The Graphical User Interface plays list widget, and select the Add to playlist action in the pop-menu as we saw in The playlist can also be edit drag-dropping the elements between row or right-clicking a row to delete them. The last thing to take in consideration is that a playlist element cannot be selected if project is currently opened, as an element of the playlist can below to a different video video than the one actually used with the project in use. To activate playlist, the user must close the current project or load the playlist using the action Load Playlist in the File menu Creating a new from a playlist The user can create a new video file with the elements in the playlist by clicking the Record button. Its shows a dialog that lets select the output filename for the new video and the encoding quality, among: Low Normal Good Excellent Figure 47: New video properties dialog Opened project error If a projected is opened and the user tries to select an element of the playlist, an error message is shown to advice the user. Figure 48: Playlist error 65