D4.2.3 CAR Experiment Results and Recommendations v1.0

7/27/2019 D4.2.3 CAR Experiment Results and Recommendations v1.0

http://slidepdf.com/reader/full/d423-car-experiment-results-and-recommendations-v10 1/32

This deliverable describes the CAR driving experiment. It includes information and results on

architecture implementation, as well as the integration and use of the software. The

document provides facility developers and testbed operators with information on aspects of

usability prior to usage by open call experiments and the next release of baseline components.

D4.2.3

CAR Experiment Results and

Recommendations

2013-10-17

Elena Garrido, Pablo Salinero, Diego Esteban, David Salama (ATOS)

Josep Escoda (CAR)

www.experimedia.eu



EXPERIMEDIA Dissemination level: PU

© Copyright ATOS and other members of the EXPERIMEDIA consortium 2013 1

Project acronym EXPERIMEDIA

Full title Experiments in live social and networked media experiences

Grant agreement number 287966

Funding scheme Large-scale Integrating Project (IP) Work programme topic Objective ICT-2011.1.6 Future Internet Research and Experimentation

(FIRE)

Project start date 2011-10-01

Project duration 36 months

Activity 4 Experimentation

Workpackage 4.2 EX2: Content production and delivery for high quality and 3DInternet-based remote sports analysis

Deliverable lead organisation ATOS Authors Elena Garrido, Pablo Salinero, Diego Esteban, David Salama (ATOS)

Josep Escoda (CAR)

Reviewers Sandra Murg (JRS), Stephen C. Phillips (IT Innovation)

Version 1.0

Status Final

Dissemination level PU: Public

Due date PM21 (2013-06-30)

Delivery date 2013-10-17





Table of Contents

1. Executive Summary ............................................................................................................................ 3

2. Introduction ........................................................................................................................................ 4

2.1. Working procedure: current and new .................................................................................... 4

3. Experiment Architecture and Implementation .............................................................................. 6

3.1. Implementation ......................................................................................................................... 6

3.1.1. Installation of components .................................................................................................. 6

3.1.2. Software workflow ................................................................................................................ 7

3.1.3. Data analysis ........................................................................................................................ 13

4. Experiment in CAR Synchronized Swimming ............................................................................. 14

4.1. Experiment execution ............................................................................................................ 14

4.2. Challenges ................................................................................................................................ 18

4.2.1. Preliminary challenges ........................................................................................................ 18

4.2.2. Implementation challenges ................................................................................................ 19

5. Statistics and Results ........................................................................................................................ 22

5.1. Statistics of use of the application ........................................................................................ 22

5.1.1. Administration module ...................................................................................................... 22

5.1.2. Synchronized swimming module ...................................................................................... 22

5.1.3. Connections to the video server ....................................................................................... 22

5.2. Quality of experience and interviews ................................................................................... 25

5.2.1. Suggestions from the users ................................................................................................ 26

5.2.2. Session review: ..................................................................................................................... 29

6. Conclusion ......................................................................................................................................... 30

6.1. Exploitation within synchronized swimming ..................................................................... 30

6.2. Exploitation for other sports ................................................................................................. 30





1. Executive Summary

This deliverable presents the final report for EXPERIMEDIA's CAR driving experiment, and its

results and recommendations for the future. The focus is on providing information about the

progress in the experiment and the final results, as well as issues and delays encountered during the experiment and their resolution.

CAR Driving Experiment is one of the three experiments deployed at the Centre of High

Performance (CAR) headquarters during the second year of EXPERIMEDIA. The proposed

change of the current working training procedure of the synchronized swimming to the new one

proposed with EXPERIMEDIA tools (AVCC module together with metadata embedded into de

the video) has been successful.

This experiment was run in October, from 8th to 10; the progress has been very satisfactory.

Some incidences have happened and caused some delay. This delay in any case affected to theprogress of the rest of experiments or the project. During the execution of the experiment some

challenges were also faced and successfully resolved.

The architecture and the practical execution of the experiment were feasible. Concrete results

and conclusion are exposed in the final part of the document.





2. Introduction

This deliverable is a report for EXPERIMEDIA's CAR driving experiment results, focusing on

high quality content productions for remote sports analysis and training at live events, and

executed at the Centre of High Performance (CAR) premises.

The focus of the CAR experiment is to implement a new procedure to improve the accuracy and

execution of the performance of the synchronized swimming (synchro) duo or group team on a

mandatory routine of the Olympic Games.

The main objectives of this experiment are the following:

To determine the feasibility of the collaborative work between the trainers and athletes.

To determine the actual athletes performance improvement.

In a sport like synchro, having processed AV content and being able to watch and learn from it

can improve the training results. The CAR experiment provides interaction between athletes,

coaches and other professionals involved in the preparation of the athletes in a local and remote

manner.

The main challenge of this experiment has been to enhance the process to improve execution on

quality and accuracy of the synchronized swimming routines and improving the training sessions

of the team, including quality of the artistic and technical results and increasing the collaboration

by getting input from remote trainers and making it easier for athletes to make their own

contributions to the choreography.

The experiment also offered trainers the opportunity to use a system helping them to see how

streaming in the EXPERIMEDIA system works.

Personnel involved in the experiment have tested the experiment tools in three phases:

1) Installation and testing of the different components of the experiment

2) Execution of the experiment itself.

3) Analysis of the obtained results.

For the purpose of the experiment, data were only captured during the experiments themselves,inside their ethically and legally controlled environment.

2.1. Working procedure: current and new

With this experiment we are also proposing to change the process the training is done. Currently,

the training goes as follows: the swimmers perform part or the entire routine to the music;

another coach or helper records the athletes with a person holding a consumer-grade video

camera. Once the performance has been done, the swimmers go to the border of the swimming

pool and the coach connects the camera to a screen and the coach connects the camera to the

TV. The coach searches the position with the forward and rewind options of the camera. W e’vedetected that big part of time is spent just searching the exact point of the music/video they





want to review. This means that not just the coach is losing time, it is also the time of the whole

team that is being wasted. With this experiment we’re also proposing a new way to work, using

the existing technologies and collaborative tools, in order to optimize the time where the whole

team is at the swimming pool.

We have introduced the concept of training pattern: the athletes execute the same routine with

the same music so many times to be synchronised as much as possible with the music and the

other team members. They should always start a figure or element (annotation) at the same

millisecond of the music. Therefore, we consider that it would make sense to have the

information of all these figures and elements associated to the music. Each time the routine or

part of it is performed, we just have to synchronize the music with the video in order to calculate

the exact frame where an annotation starts in the video. To introduce the pattern of a music

takes lot of work for one person but will optimize the whole team training process.

The athletes are currently sharing the videos when they arrive at home: they copy the file to the

local computer and send it by email. With this experiment we’re showing them how the

information can be shared while they’re next to the swimming pool.





3. Experiment Architecture and Implementation

The CAR driving experiment architecture and implementation have already been described in

D4.2.2; experiment background were also described in deliverable D4.2.1 and all related

operational aspects around the experiment were exposed in previous deliverables D3.1.1, D3.1.2,D3.1.3 and D3.1.4.

For this reason, in this report we will just focus in the new changes made on the implementation

of the experiment.

3.1. Implementation

Implementation of the experiment is carried out in three different phases: Installation of

components, where all infrastructures was tested, software workflow and data analysis.

These phases are described in the next subsections.

3.1.1. Installation of components

In this first phase, the infrastructure is tested in order to assure that all systems worked properly.

All devices included in the experiment (cameras, sensors, Wi-Fi and audio infrastructure) are

installed and tested in order to avoid any problem during the development of the experiment.

These tests were done with the supervision of the technical personnel involved in the

experiment.

Two virtual machines where created and deployed in order to host the software. One of themhad the AVCC installed and the other one the web services and web sites developed for the

experiment. Both virtual machines had to map a directory to the CAR network storage in order

to host the recorded video files. A recorded routine is about 250Mb 1280x720 at 60fps. A

VLAN was set up for these two computers that were accessible via internet. Just the required

ports were open in the firewall and the system was accessible from internet. The camera was set-

up in another VLAN that was only accessible from the AVCC. For security reasons, the AVCC

only streams and records information when it is requested by the experiment web services. This,

together with the special VLAN for the camera, was done in order to avoid hacking from

outside and the risk that anyone could get images from the software.

The camera had to be calibrated and configured before being used in the experiment. Several

steps had to be done with the camera in different days in order to be useful for the experiment: a

proper IP had to be assigned, users had to be created, the lens had to be focused, codec

parameters had to be set, etc.

Once the hardware was installed and tested, the video server running and the experiment

software deployed, the administration tool provided is used to manage:

The modalities associated to the discipline involved into the experiment.

The hardware, particularly cameras.





The annotations and terms used during the normal execution of the synchronized

swimming training sessions.

The experiment participants and their profile (coach, athlete, staff).

Figure below is a capture of the EXPERIMEDIA administration user tool; in this figure it is

possible to see the different management activities listed above on the left:

Figure 1. Administration tool capture

3.1.2. Software workflow

This phase can be divided into several smaller tasks which are described below.

3.1.2.1. Folder administration

First of all, folder structure must be agreed with the synchronized swimming personnel (staff,

coaches) and created, in order to organize the recording of training pattern and sessions.

Figure below shows a capture of the folder administration screen:

Figure 2. Folder administration screen capture

3.1.2.2. Training pattern creation

Once the folder creation is completed, a training pattern can be created. The figure below shows

a capture of how the application allows creating a new pattern:





Figure 3. Creation of a new pattern

A training pattern combines an audio file with a series of annotations and terms, belonging to a

given synchro modality. Some of these annotations have predefined terms and others are left to

introduce a free text. The participant who is creating the training pattern can listen to the

fragment of the audio file corresponding to the exact start and duration of every annotation. The

Figure below illustrates this:

Figure 4. Capture of the tool screen where users are able to listen to audio fragments

When all training pattern attributes are introduced, the pattern is saved and the coach can start a

training session if he wishes.

A training pattern may be edited later, but only its annotations can be edited (adding new

annotations and modifying or deleting existing annotations). Other information like the audio

file associated to the pattern or their participants cannot be modified after the training pattern

creation.

Figure below shows a capture of the annotation edition screen:





Figure 5. Capture of the annotation addition screen

Once the training pattern has been created or edited, there exists the possibility of seeing itsattributes, just by clicking on it, as shown in the Figure below:

Figure 6. Attributes screen

3.1.2.3. Training session execution

A training session is the physical representation of a training pattern and can be started

immediately after the creation of the training pattern or at any other moment from a saved

training pattern.

A started training session is broadcasted live, in order to allow coaches or staff to follow the

performance of the athletes, either at the side of the pool or remotely. The training session is

also recorded to provide the involved personnel the possibility of seeing it on demand, locally or

remotely, at any time after the ending of the training session. Just a few seconds are required

from the moment the event is broadcasted until it is available on demand.

A training session can be terminated when the audio file associated to the training pattern ends

or at any moment by any joined participant to the session. Just after the ending of the execution

of the training session, the participant who started the session has the possibility of seeing the

video on demand of the training session.





Figure 7. Live training session capture

Videos associated to the training sessions are placed in the same folder where the training pattern

is placed. It can also be watched from the folder structure.

3.1.2.4. Joining a live session

A participant, different from who started the training session, can join the session while is still

live in order to allow the interaction and collaboration between participants.

Figure below is a caption of the tool login screen:

Figure 8. Login screen

3.1.2.5. Adding recorded marks

During the execution of the training session, participants can insert a mark, which is seen by

other participant, to signal an important event. After the ending of the training session, these

marks can be edited to add further information.





Figure 9. Mark addition

3.1.2.6. Sending and deleting notifications

After the ending of the training session, the participant who started the session is allowed to

send a notification to a selected group of participants. This participant can also make a comment

related to the notification.

The notification is a link to the reproduction to the recorded training session associated to it.

Figure 10. Send notification screen

Every participant has the possibility to watch all the notifications, either sent by them or sent to

them. The unread notifications are displayed in a highlighted manner (and once it has been

watched the highlight disappears).





Figure 11. See notification screen

A participant (sender or recipient) can delete any notification when desired and it will not bedisplayed anymore, but this does not mean that the notification disappears for the other

participant associated to it.

3.1.2.7. Visualizing recorded training session on demand

As said previously, a notification is a link to the reproduction to the recorded training session

associated to it. So, every participant who has a notification received will be able to watch the

performance of the athletes and see and make comment on the marks recorded by every other

participant.

Participants will have the possibility of watching the video of the training session as long as thenotification has not been deleted.

Figure 12. Training session visualization

3.1.2.8. Editing recorded marks

While watching a video-on-demand training session, every participant who has received the

notification is allowed to make comments on the recorded marks. These comments will be seenby every other recipients and the sender of the notification.





Figure 13. Training session recorded marks edition

3.1.3. Data analysisResults obtained from the experiment at prior phases have to be analysed, in order to allow

coaches and athletes to take different decisions in order to improve the performance and the

efficiency of the trainings.

Personal involved in the experiments have been interviewed; their opinion is the best feedback

we can obtain due to the fact that they have been the end users of all EXPERIMEDIA software

developed up to this moment.

On the other hand, statistics of use of the application have been implemented, in order to

quantify the use of the application, either on the administration module or the synchronized

swimming specific module.

On the administration module, statistics measure the use of actions such as:

o Users management

o Disciplines and modalities management

o Hardware management

o Annotations and terms management

On the synchronized swimming module, statistics measure the use of actions such as:

o Adding and editing new training patterns.

o Seeing training pattern attributes.

o Starting and joining live training sessions.

o Sending and reading notifications on training sessions.

o Watching training session videos on demand.

Some of this these statistics can be found in section "5 - Results and Impact" of this document.





4. Experiment in CAR Synchronized Swimming

This section provides information on the progress of the experiment and the challenges

encountered during its execution. An explanation of the progress made is provided here,

following the phases indicated at the implementation section.

4.1. Experiment execution

The experiment ran from 8th to 10th October 2013 at the CAR headquarters, at the swimming

pool for synchronized swimming team training. It was carried out in two phases.

The first phase of the experiment was dedicated to finishing the configuration and to test the

infrastructure (cameras, WiFi network, video server, application server). The tasks performed

during this phase were:

Testing of audiovisual infrastructure Testing of WiFi and mobile environment

Deployment of the application in the CAR server

Installation of the video server in the CAR server

Figure below illustrates the strategic position of one of the cameras used in the experiment:

Figure 14. Camera pointing to the swimming pool

This other picture captures the moment when network access was configuring:





Figure 15. Configuring the network access

In the second phase, the application was shown to biomechanical experts and IT staff, while

coaches and athletes watched the application after, when they used it in real training sessions.

Figure below captures the moment of one of the meetings arranged with coaches:





Figure 16. Meeting with coaches

Figure below catches one of the meetings with the athlete involved in the training session:

Figure 17. Meeting with athletes





During the real training sessions the experiment was performed. Two pictures below were taken

in one of these training sessions:

Figure 18. Recording a real training session

Previous image is a capture of the coaches looking at the progress of the exercise in the

swimming pool. In the image below, David is showing the features of the application to the

coaches

Figure 19. Recording a real training session





Biomechanical and IT staff were shown both the part of administration (to show how it could be

used for different disciplines) and the part of synchronized swimming, while synchro coaches

and athletes were shown only the specific part of synchro.

4.2. Challenges

CAR driving experiment meant to overcome some challenges; these challenges were found

during the development of the experiment, but also in the preparation phases. In the following

subsection, these challenges will be detailed.

4.2.1. Preliminary challenges

4.2.1.1. Olympics

London Olympic Games took place in summer 2012 during the preparation phase of the

experiment. Olympics implied trainers and athletes not to be able to attend experimenters even

for a long time after the games. However, smart planning allowed all personnel involved in thepreparation of the experiment to make some progress on work before the Olympics; this

advance, together with the hard work done after the Olympic Games made possible to change a

serious threat to the experiment into a non-significant delay.

4.2.1.2. Internal changes in CAR staff

After the Olympics, internal changes occurred in CAR technical staff. These changes implied

again personnel involved in the training sessions were not able to attend experimenters for some

time. Again, good planning and the hard work done after these changes made possible to run the

experiment with a minimal delay.

4.2.1.3. Camera

To choose a good camera became other important challenge in the experiment. Initially a set of

cameras with specifics features were selected but changes in CAR available budget made not

possible to buy them; a new selection process started again and a new camera was bought. The

use of an inexpensive camera for the project was not possible, because one of the requirements

was to have a HD camera with at least 50fps.

Two of the chosen cameras were giving problems from the beginning. The first camera was sold

as GigE camera but didn’t follow exactly the standard. The second camera was a frame grabber

GigE standard. It was decided to modify the ffmpeg application in order to incorporate as adevice of the GigE camera and generate the video from the live captured images. With ffmpeg

we should have been able to send a live stream to the AVCC. It was impossible to make the

camera libraries work with the ffmpeg software. Technical staff from CAR and ATOS tried to

solve the problem; even several meetings with the camera brand technical support were arranged

in order to solve the problems. Finally, due to the incompatibility between the camera and

ffmpeg, technical staff quickly decided to buy a new camera fully compatible with the AVCC:

SONY IP Camera 1080 60P; the test with the new camera successfully exceeded the level of

accuracy required for the frame rate of the experiment, that have a very challenging short sync

time between the video and the music.





The issue of the cameras wasted a lot of time and caused a delay in the implementation of the

experiment. In any case, this delay didn't affect the successful run of the overall experiment.

4.2.2. Implementation challenges

In order to setup the camera for the experiment, finding a proper view to place the camera

became an important challenge for the technical staff involved in the experiment.

A new point of view of the camera position was required and it was necessary to find an

Ethernet connection point. One point was identified in the building next to the pool deck, but

this connection links to a full rack without available ports on the switch, on RACK 1 at Level -2.

To achieve this issue, CAR included a new infrastructure CISCO switch 3750x in order to have

available ports for the project. That process required reordering all the cabling of the rack in

order to scale accordingly to future requirements and created additional workload, but it was

done successfully and the experiment could be run with no problems.

A virtualized server was used, instead of a physical one. As explained in deliverable "D3.1.1 First

infrastructure and assets inventory" and "D3.1.5 infrastructure and assets inventory", CAR have

huge CISCO virtualization structures which makes more suitable to use virtual servers rather

than introduce new physical equipment. Previous experiences with a physical server indicated the

necessity of a computer with 4GB RAM and only one core. However, technical staff involved in

the project detected that this configuration could be insufficient and cause malfunctions in the

systems due to the fact that virtualization consumes more resources; They anticipated to this

possible issue and a computer with 8GB RAM and eight cores was provided for running the

experiment. And it works perfectly.

The overall feedback of the video was around 1 second of latency from the actual time. This was

a good value, taking into account that usual values for latency in video streaming are around 30

seconds.

This was verified by making recorded marks at the same time as a hand movement, as could be

seen in figure below:





Figure 20. Checking camera latency

At the beginning audio and video was not synchronised when using the camera at the requested

frequency (60 fps) and there was up to one second difference. There was no real impact in the

concept of the proposed solution as the ambience audio was only to enrich the experience. The

ambient noise at the swimming pool does not enrich the actual experience of the viewing of the

recordings. In any case, audio and video were synchronized by calibrating the camera (this was

verified by clapping in front of the camera, as shown in figure below.

Figure 21. Checking the synchronization between audio and video

The optics of the camera was originally designed for security purposes; therefore a slightdeformation of the view existed. However, the high quality of the recorded video made possible





that this issue does not interfere with the coaches' needs. In this sense, it is important to remark

that usually a setup of three cameras would be required to properly cover the synchronized

swimming pool; however, the high quality of the recorded video and the details provided by the

EXPERIMEDIA tools made a big impression on coaches; they described the results as "very

satisfactory".

Finally, it was detected that the video server suffered signal interruptions which caused the

videos being recorded to cut off. The solution to the problem was changing the configuration

parameters of the invocation from the web server to the video server to append the fragments in

a same video and implement a solution to re-synchronize the music with the video and data

when it is played.





5. Statistics and Results

In this section, results extracted from the experiment execution, just as statistics of use of the

different modules developed, questionnaires, interviews and statistics of connections to the video

server are described.

5.1. Statistics of use of the application

Two applications were specifically developed for CAR driving experiment: "CAR

EXPERIMEDIA administration module" and "CAR EXPERIMEDIA Synchronized Swimming

module". In the following lines some statistics of their use during the execution of the

experiment are introduced.

5.1.1. Administration module

Statistics of use of the administration module produce these figures:

User management was used 62 times: 32 for adding new users, 10 for modifying an

existing user, 19 for consulting existing users and 1 for deleting users.

Disciplines management was used 24 times: 3 disciplines were added, were modified 3

times and were consulted 18 times

Hardware management was used 16 times: 2 hardware items was added and hardware

was consulted 14 times.

Annotations and terms management was used 27 times: 4 annotations added with 9

terms added and 14 times were consulted.

5.1.2. Synchronized swimming module

Statistics of use of the synchronized swimming module show these figures:

The number of training patterns added was 6.

These training patterns were edited 32 times.

The attributes of these training patterns were consulted 397 times.

The number of training sessions started was 374.

The list of live training sessions at a given moment was consulted 391 times.

From these times, the users joined a live training session 14 times. The number of training sessions watched on demand from the navigation tree or after

the ending of the recording of training sessions was 168.

After the ending of the recording of training sessions, notifications were sent 5 times.

The list of notifications sent or received by the users was consulted 92 times.

The number of video on demand watching from a notification was 2.

5.1.3. Connections to the video server

The AVCC video server allows the monitoring of the number of connections opened and the

data traffic (input and output), either in live mode or on demand mode, since its last reboot.





At the end of the experiment and since the last reboot of the video server, 118 connections were

opened, of which 87 corresponded to live video requests. So, the remaining 31 connections were

for video-on-demand requests corresponding to video on demand requests.

Due to the lack of memory detected the first day of the experiment, statistics were generated in

order to monitor them. These statistics provided information about performance on CPU,

network and RAM, as shown in the following figures:

Figure 22. CPU Performance

After the RAM was increased, the percentage of use of the network remained on very acceptable

levels:





Figure 23. Network performance after RAM increasing

It was noticeable to observe that CAR wireless network was able to support 3 concurrent

streaming session (clients) consuming 8000kbps. This also indicates that the request of three

cameras to cover the whole swimming pool is feasible with this network capacity:





Figure 24. Memory performance

5.2. Quality of experience and interviews

Initially, some questionnaires were created in order to measure the quality of experience of the

personnel involved in the experiment. But at the end, it was decided that the best way to know

the experience of the users was to interview them directly.

Interviews were conducted with participants in order to collect their feedback about the

experiment. The different stakeholders related to the results of the experiments and potential

users of the software have been quite positive. They are very interested in the solution that

would actually require changing their current workflow adapting to what the new technology can

provide.

This new workflow requires an effort in the preparation of the routines, formalising in an IT

system. Although they are used to high-end consumer devices like smart phones, tablets and

computers for tasks like preparing the music, generating manually reports with handcam

recordings, etc., the biomechanical expert was in charge of the scientific and formal follow-up

using video and artificial vision techniques.





The trainers are very interested in using the tool shown to them, in their daily operation, once of

course it would have matured as a product. It has been quite relevant to have all data and video

synchronised with the music stored in the CAR system and available online.

Participants (1 biomechanical expert, 2 coaches and 1 athlete) made suggestions in order to

improve the usability of the application. These suggestions are summarized in the following

section:

5.2.1. Suggestions from the users

The main suggestions coaches made in order to make the application developed even better were

the following ones:

5.2.1.1. How to record a training pattern:

Athlete and coaches are the ones who know the music and the routine well enough to introduce

the pattern. But, while coaches are familiar with the graphical representation of the music, asthey are used to edit the music with software programs, athletes are used to listen to it. They are

able to count the music. They can follow the beat of the music; beat means the basic unit of time

they use to follow the music with in the figures and elements they perform. Usually, a musical

score progresses regularly in time as in counted as “1 2 3 4 5 6 7 8, 1 2 3 4 5 6 7 8…”. These

numbers are related with the choreography performed by the athlete. Both share the same

knowledge, but the preferred way to record the information of the pattern is different from the

coach and the athletes.

There have been some common needs involving the need for zoom in both the information

(music wave, annotation) and in the video. Especially in the information since the density of thedata is quite high and difficult to visualize.

Figure below shows a meeting where coaches are discussing about creating training patterns:

Figure 25. Coaches discussing about creating training patterns





During the experiment we requested to one of the athletes to add ‘recording marks’ when a beat

1 takes place while the music was played in order to know the accuracy of the person and to

know the amount of data and frequency we were talking about. She did it 3 times for the song

they used in the last FINA (International Swimming Federation) championship. The song had a

length of 4 minutes and 16 seconds. She introduces about 150 ‘1’ beats each time. This means

that this musical score has about 1200 beats (1-8) in total. It means that we have a beat every 0,2

seconds. When generating the sound image graph we should consider this information.

We’ve calculated the mean time per beat in order to know when the beat ‘really’ takes place and

we calculated the difference of the time of the recorded mark and ‘real’ beat in order to estimate

the accuracy of the person, we had a precision of 162 milliseconds average difference.

One of the ideas during the experiment in order to introduce the pattern and this amount of data

was to make it as a game. Several athletes should make marks at the same time while they’re

listening to the music. An intelligent system should be able to calculate the position of a beat.

Afterwards, corrections could be done by the coach using the graphics.

The athlete would prefer to listen to the music and record the beat (as shown in Figure 23). The

idea is to record the 1 beat of each segment. Afterwards the rest of the beats can be calculated

dividing the segment into 8. Usually it is 8, but due to changes on the technical figures and

elements performed they might cut a segment and it can be less. For an example, in a given

segment of the song, where the numbers goes up to 4, since the athlete would record “1” the

other “numbers” will be spread evenly in time until the next “1”.

The coaches would like the pattern editor to have a greater resolution, as they are used to music

software. The resolution of the image will depend on the beat frequency. Both, athletes and

coaches would be able to see a beat.

The biomechanical expert and the coaches would like to have each of the beats using a different

colour in order to easily visualise them in the timeline, or at least have a different colour for odd

and even beats.





Figure 26. Athlete recording beats

5.2.1.2. Record training session (at the swimming pool):

These are the suggestions made by coaches for recording training sessions at the swimming pool:

Coaches and staff agree that there is no need to see the video locally while they’re

recording the video. The coach is watching the athletes at the swimming pool and they

won’t be looking at the screen.

The coaches believe that it would be interesting to have the music graph in the timeline,

and have a cursor moving forward.

Coaches suggested to be able to use any device (like phones) to create the “recorded

marks” so they can move around the swimming pool while they’re making the marks.

This can be combined with "the join live" (in the next section suggestions regarding this

issue can be found ). Also, the icon of the “recorded mark” should be bigger and easy to

click. Also, it should be possible to identify who is creating the “recording marks”. The recording session should allow starting at any moment of the music selected by the

trainer and end at any moment, so they can perform specific segments of the routine.

The timeline of the recording session should be adapted to the new time frame.

They would appreciate to add personalised view of the training session using their mobile

devices as camera. Streaming from their mobile device to the AVCC and recording it.

5.2.1.3. Join live

Regarding "join live", coaches suggested that there should be two options: one with video and

other or without video. The coaches who are at the swimming pool could just use this option to

generate “recorded marks” with any device and any other coach or staff could watch the session





remotely. In case of not showing the video it has been proposed to put the music graph with a

cursor.

5.2.2. Session review:

For the session reviewing module, coaches suggested:

Make the video larger; currently, the video was a bit small; Timeline should use as much

horizontal space as possible.

It should allow zooming of the video or at least the image of a frame.

The rows below the video, should be aligned with the video timeline, and ideally provide

the graphical representation of the music below. The user should be able to hide / show

each of the rows in order to setup the working space to their currents needs. Also, zoom

in the timeline should be allowed in order to appreciate the beat.

The video timeline, the music graphical representation and the annotation lines, should

be aligned with the actual timing of the recording, given that it could start at any momentand finish at any moment.

They should be able to generate new recording marks besides editing the original, and

each of the new marks should be in the row of the person who created it.

There should be an option to download the video files





6. Conclusion

We can conclude, from the opinions obtained from the personnel involved in the experiment,

that the experiment has been a success. Of course, the developed tools are not a final product

but, in words of the CAR technical staff, the software complies with their necessities.

The suggestions will be taken into consideration and those which would be considered feasible

would be implemented for a hypothetical future phase. ATOS, together with CAR, are looking

for external and internal funding and are studying the possibility of developing a real product.

Having a fast look to the suggestions the technical team believes that they can be feasible, and

it’s just a matter of invested working hours. The experiment had also as output a better

understanding of how the training of the synchronized swimming is performed. Biomechanical

experts and especially technical staff didn’t have such a deep knowledge of how a choreography

is trained and the precision required for it. Being aware of how the athletes and coaches work,

and having their feedback it would make it much easier to provide a product that matches withthe requirements and need of the synchronized swimming team.

It is important to remark that it has been not possible to scientifically validate an improvement in

the sporting results. To do this would require a much longer term.

6.1. Exploitation within synchronized swimming

Coaches, athletes and staff expressed their interest in this kind of collaborative and accurate tool.

As commented in the introduction it was detected that currently they’re wasting a lot of time just

trying to be accurate reviewing the audiovisual content. They’re performing some tasks, like

sharing the videos, in their ‘free time’ with existing tools (like home video cameras, mail, USB,

etc).

One of the comments of the biomechanical personnel, after watching what can be done with the

EXPERIMEDIA technology and tools, is that probably, the Russian team must be using

something like this. They believe that such technology provided by EXPERIMEDIA would help

them to improve the accuracy of the team.

6.2. Exploitation for other sports

Parts of the tools developed for this experiment have been implemented in a very open manner. This means, that an administration site has been developed in order to be able to add and

remove disciplines and modalities from the central database. Users can be added to these new

disciplines. New installed hardware can be configured and used by the system and assigned to a

modality. Annotations and terms can be managed for any discipline. This mean, that any sport at

the centre could use the system for their purposes. Annotated video could be used in other sport

disciplines not just synchronized swimming.

The software developed as it is could be used for other disciplines with similar characteristics like

artistic gymnastics. Sport federations and sport clubs could be interested in such kind of product.




Most of all other sports use video for reviewing applications but the big jump that may advance

with this video infrastructure is the capacity of multiplexing tasks and the delocalisation. This

allows any of the agents in the athletics preparation to get access to the contents anytime and

anywhere and provide enrichment to the process. This is applicable for all the athletes entourage

which includes all support service staff, sport scientists and doctors but also family and partners

that can be involved without disturbing their daily activities.

But another important characteristic of the software developed for the experiment is that most

interfaces with the database, with the AVCC and with all the logic to make the recording and

video retrieval is implemented with SOA interfaces. This means, that any other software

developer can make its own product integrated with the same database and system.

Documents

D4.2.3 CAR Experiment Results and Recommendations v1.0