HeaderSIS.jpg

Difference between revisions of "IS480 Team wiki: 2011T1 AUSTIN/AUSTIN Functionalities"

From IS480
Jump to navigation Jump to search
 
Line 176: Line 176:
 
=== Windows Service ===
 
=== Windows Service ===
  
The AUSTIN windows service will be the main central processing system for the project. The windows service would be collecting data from the dashboard and sending it into the encoder (an external system). In layman terms, it is the brain of the system, determining which jobs to send out and at which time interval. We have segregated WIndows Service into 3 different processing points: Basic Service, Monitor Service and Publisher.  
+
The AUSTIN windows service will be the main central processing system for the project. The windows service would be collecting data from the dashboard and sending it into the encoder (an external system). In layman terms, it is the brain of the system, determining which jobs to send out and at which time interval. We have segregated WIndows Service into 3 different processing points: Basic/Monitor Service,Verifier Service and Publisher.  
  
Basic and Monitor service form the main central processing part of the Windows Service whilst the Publisher must have the option to trigger automatically based on the different profiles or manual entries in the rare event the end-user wishes to send output to a different FTP server. Also, the publish system would make use of the high-flying technology called ASPERA FileConnect.
+
Basic/Monitor service form the main central processing part of the Windows Service before passing to the Verifier service for data integrity checks whilst the Publisher must have the option to trigger automatically based on the different profiles or manual entries in the rare event the end-user wishes to send output to a different FTP server. Also, the publish system would make use of the high-flying technology called ASPERA FileConnect.
  
==== Functionalities of Basic Service ====
+
==== Functionalities of Basic/Monitor Service ====
  
 
{| class="wikitable"
 
{| class="wikitable"
Line 207: Line 207:
 
|}
 
|}
  
==== Functionalities of Monitor Service ====
+
==== Functionalities of Verifier Service ====
  
 
{| class="wikitable"
 
{| class="wikitable"
Line 218: Line 218:
  
 
|-
 
|-
| Check filename in output folder
+
| Check video asset file integrity
| The service would have to be able to check the filename of the video in the output folder with time interval of 5 minutes again. If the filename exists in the output folder, it simply means either that the encoder has already started working on the file.
+
| The service would have to be able to check for the file integrity of the videos that have been uploaded to prevent any corruption of videos that will eventually affect the output folder.  
 
 
We would use File.IO to check whether the file can be accessed. If the encoder is still working on the file, the file would be locked and return error in terms of File.IO. At this point in time, the service must update the VideoOrders table with status set to 'In-Process'. If the file is not locked, it means that the encoding is completed. At this point in time, the service must update the VideoOrders table with status set to 'Completed'.
 
 
 
|-
 
| Update filename extension
 
| Once the encoder has finished working on the file, the service must update the filename based on the extension inside the Profile table for the services attached to video metadata.
 
  
 
|-
 
|-
 
| Notify the user
 
| Notify the user
| The service is required to notify the user via 2 platforms for any event change. For example, if the video has stalled within the encoder, the service must be capable of sending data to the dashboard to notify user and be able to send out an email in the event of status of video assets being changed to 'Error' within Video Orders table. This error might come about via the file being locked by the encoder for a long period, such as 2 hours. It simply means that the encoder has stopped working.
+
| The service is required to notify the user via 2 platforms for any file integrity alerts. For example, if the video has contained corrupted elements, the service must be capable of sending data to the dashboard to notify user and be able to send out an email. The encoder would then not be able to process the videos until issues have been solved.  
 
 
 
|}
 
|}
  
Line 244: Line 237:
  
 
|-
 
|-
| Check Business Logic for Automatic or Manual
+
| Check Business Logic Automatically or Manually
 
| The publisher would have to check the business logic attached to the video metadata whether a specific video asset has been tagged as manual or automatic upload.
 
| The publisher would have to check the business logic attached to the video metadata whether a specific video asset has been tagged as manual or automatic upload.
  
Line 254: Line 247:
  
 
|-
 
|-
| Generate JSON Format
+
| Upload Entire Video Asset in generated format
| The publisher must be capable of generating JSON format for a particular video asset after it has been encoded successfully.
 
 
 
|-
 
| Generate 3rd Party Formats
 
| The publisher must be capable of generating 3rd Party formats for a particular video asset after it has been encoded successfully.
 
 
 
|-
 
| Upload Entire Video Asset
 
 
| The publisher must upload the entire video asset which includes the thumbnail attached to the metadata to the appropriate FTP Address which is tagged to the id of the video in the Video table.  
 
| The publisher must upload the entire video asset which includes the thumbnail attached to the metadata to the appropriate FTP Address which is tagged to the id of the video in the Video table.  
  
Line 268: Line 253:
  
 
|-
 
|-
| Upload Generated Formats
+
| Publish to users and viewers
| The publisher must upload the various generated formats of the video assets to the appropriate XML FTP Address which is tagged to the id of the video in the Video table. Aspera File Connect would be used to achieve this in great speeds compared to the traditional FTP transfer speeds.
+
| The publisher will be able to publish the uploaded videos to users and viewers from the appropriate FTP addresses with the tags that have been created and used in the videos.  
 
 
Aspera File Connect would be used to achieve this in great speeds compared to the traditional FTP transfer speeds.
 
 
 
  
 +
|-
 +
| Notify the user
 +
| The publisher is required to notify the user for any videos that have been published. With this function, the user would be alerted for to know which are the videos that have been published successfully.
 
|}
 
|}

Latest revision as of 19:25, 6 March 2012

AUSTIN System

Functionalities of Create Video Metadata

Function Description
Create new sleek user-interface The aim is to create an enticing brand new user interface for the entire AUSTIN system. We would not be using the existing template from the first STEVE version.

Instead, we would aim to base the interface on HTML5. HTML5 would bring about advantages such as improved semantics, cleaner code and elegant forms amongst others. The brand new interface would encompass the broad-based functionalities and current working tabs such as ‘Dashboard’, ‘Create Video’, ‘In Process’, ‘Setting’ and etc.

List files from FTP servers The current system, due to it being used in localhost circumstances, allows users to only browse the local filesystem. We would implement the users to have a browse FTP function, as the project would be moving into the Intranet and Internet world soon after completion.

However, due to security issues, this browse function would not allow the users to browse all files and folders. Some pre-defined folders for the various FTP sites would be set aside for this system and its users.

Preview image thumbnails We will also allow user to have a smaller sized-resolution preview of the image thumbnail that he selected from the drop down list to attach to the video asset.
View full-resolution image In addition, on clicking the 'View Full Screen Preview', the user would be able to view the image in the glory of its full resolution.
Video tagging The current system does not allow a user to tag videos. Tagging can be an important feature as it allows for a cleaner categorization as well as being able to locate different types of videos easily.

We would implement some pre-defined tag names such as ‘HD’, ‘World Cup’ and ‘Spanish Football’ and also allow the user a textbox to create his own tag if the pre-defined tags do not meet his video requirements.

jQuery Datepicker The current system requires user to input date in a specific format. If the user does not follow the instructions, it could actually lead to the video being forced into errors before or while encoding. The metadata would be corrupted.

We would implement a datepicker style from jQuery which would give the user full control in a calendar sort of view for picking out the date for event date, start date as well as end date to attach to the video asset.

Display metadata look and feel on Mobile/TV ESPN Star Sports would also like users to be able to see how their input on various textboxes looks like on mobile and smart tv screens. With the popularity of mobile and smart tv, the number of users consuming a video asset on devices other than the PC are increasing.

We would implement a function to display how some textboxes, in particular, multi line texboxes, appear on tv and mobile screens to enable the user to see the word limit as well as whether his data would be wrapped into the next line.

jQuery Validation We would implement an up-to-date real-time validation on all user inputs for examples such as empty fields, minimum length as well as fields requiring only number inputs. This will ensure fully that the video metadata does not get corrupted by the user inputting the video metadata.
Confirm Video Details ESPN Star Sports has encountered many problems with the system such that the user has inserted spelling errors or input errors within the metadata. They would like a separate form whereby it displays all of the user's selections before he actually submits the video metadata. He also would have the option to return to a previous screen to amend details.

All the data would be stored in a session. This ensures that data input from the user would not be lost on hitting the back or forward buttons. The session would only be cleared on the user submitting the video metadata.

Save Video Details Similar to the manner to confirm video details except that in future iterations onwards, users can come back to the create video metadata screen to make amendments if they have not submitted yet. The session would only be cleared on submitting a video metadata or by logging out.
Submit Video Details This function basically allows user to submit video metadata and the entry would be stored in the database with the status as 'Not Started'. Windows Service takes over from this stage.

Functionalities of Dashboard

Function Description
Create new sleek user-interface The aim is to create an enticing brand new user interface for the entire AUSTIN system. We would not be using the existing template from the first STEVE version.

Instead, we would aim to base the interface on HTML5. HTML5 would bring about advantages such as improved semantics, cleaner code and elegant forms amongst others. The brand new interface would encompass the broad-based functionalities and current working tabs such as ‘Dashboard’, ‘Create Video’, ‘In Process’, ‘Setting’ and etc.

Login The current system allows anonymous users access to the functionalities. However, for security as well as user rights scenarios in the future, we would implement a login form. This login form would allow authorized and authenticated users to successfully access the system and make changes.
Display all videos We would implement an intuitive data-grid within the dashboard that displays to the user all the videos in the system currently, with the order of the latest video asset as well as metadata details. We would also have a small image as well as video preview on the click of a button which pops-up the latter and former.
Display video status We want the entire dashboard to be very user friendly to users as well have an element of user interactivity which the current system does not offer at all. Hence, we would implement a side-bar that refreshes every time a video asset status is changed. There are various states and status a video asset can hold such as 'Sent to Watch Folder', 'Not Started', 'In-Process', 'Completed' and 'Error'. For example, once the Encoder has started working on the video, the status would be changed to 'Processing' and this would be shown on the dashboard, in a way that is sleek and interactive but not distracting.
List names/descriptions of videos The current system does not allow users to view the names, metadata and description of the videos that are currently not started or sent to watch folder. It only displays the number of videos. This brings about the problem of the user having to sieve through the huge amounts of videos to check which video has been started.

We aim to implement a simple function such that the user can click on the number for ‘Not Started’ and ‘Sent to watch folder’ to view the names and description of the videos. jQuery would be used to ensure that the form opens in a simple pop-up box and does not drag the user away from the dashboard.

Search The current system does not allow users to search for a certain video. It can get tiring and time-consuming for the user to look through the huge amounts of videos through the different pages.

This might be pivotal if the user wishes to track the past few days videos. Hence, we would implement a search function whereby the user can search for videos either by name, service type and etc.

Sort The dashboard under the current system does not have a sort function. Whilst going through the dashboard, we wanted to be able to sort by the different service types such as SingTel.

We feel that such a function would be beneficial to the user to be able to sort videos very quick through service name, date, status and etc.

Paging The current system does have paging implemented. However, we see the possibility to improve the paging function by having it load within the same grid instead of having to load the form again. jQuery could be used in this aspect to have a nicer and quicker paging load.
Re-queue The current system has a re-queue button. However, this requeue button has the functionality build in such that it deletes the earlier video and sends the video to the queue again.

We would implement re-create a re-queue button that encompass allows the unprocessed videos to be re-queue without having to delete and reupload.

Functionalities of Settings

Function Description
Manage Type The current system does not allow for dynamic management of the video type. If a new type is required, the administrator would have to go into the backend database to manually manipulate the tables in order to create a new type.

We plan to implement complete management capabilities such as Create and Edit Type for the users to create new types or edit existing types at their convenience. We would not be implementing Delete Type after being advised by ESPN Star Sports that might actually mess up the database schema that is the glue holding the whole system up.

Manage Channel The current system does not allow for dynamic management of the channel type. If a new channel is required, the administrator would have to go into the backend database to manually manipulate the tables in order to create a new channel.

We plan to implement complete management capabilities such as Create and Edit Type for the users to create new channels or edit existing channels at their convenience. We would not be implementing Delete Type after being advised by ESPN Star Sports that might actually mess up the database schema that is the glue holding the whole system up.

Manage Sports The current system does not allow for dynamic management of the video sport. If a new sport is required, the administrator would have to go into the backend database to manually manipulate the tables in order to create a new sport.

We plan to implement complete management capabilities such as Create and Edit Sport for the users to create new sports or edit existing sports at their convenience. We would not be implementing Delete Sport after being advised by ESPN Star Sports that might actually mess up the database schema that is the glue holding the whole system up.

Manage Category The current system does not allow for dynamic management of the video category. If a new category is required, the administrator would have to go into the backend database to manually manipulate the tables in order to create a new category.

We plan to implement complete management capabilities such as Create and Edit Category for the users to create new category or edit existing category at their convenience. We would not be implementing Delete Category after being advised by ESPN Star Sports that might actually mess up the database schema that is the glue holding the whole system up.

Manage Tags The current system does not allow for dynamic management of video tagging. If a new tag is required in order to tag the videos that the user have uploaded, the administrator would have to go into the backend database to manually manipulate the tables in order to create a new category.

We plan to implement complete management capabilities such as Create and Edit Category for the users to create new tags or edit existing tags at their convenience. We would not be implementing Delete Category after being advised by ESPN Star Sports that might actually mess up the database schema that is the glue holding the whole system up.

Manage Services The current system does not allow for dynamic management of the different services that can be attached to a video. If a new service is required, the administrator would have to go into the backend database to manually manipulate the tables in order to create a new service.

We plan to implement complete management capabilities such as Create and Edit Service. We would not be implementing Delete Service after being advised by ESPN Star Sports that might actually mess up the database schema that is the glue holding the whole system up.

Manage Status The current system does not allow for dynamic management of the channel type. If a new status is required, the administrator would have to go into the backend database to manually manipulate the tables in order to create a new channel. The user would be able to create and edit the status that are associated with the videos that they have uploaded.

We plan to implement complete management capabilities such as Create and Edit Type for the users to create new status or edit existing statuss at their convenience. We would not be implementing Delete Type after being advised by ESPN Star Sports that might actually mess up the database schema that is the glue holding the whole system up.

Service - Profile Link The current system does not allow for dynamic management of the different profiles that can be attached to a service. In the event that a new profile is brought in by Singtel for example, it might have to be tagged to a service.

We would implement options for the user to link new profiles to existing services. This will ensure dynamic management of data and is future-proof in going forward.

Windows Service

The AUSTIN windows service will be the main central processing system for the project. The windows service would be collecting data from the dashboard and sending it into the encoder (an external system). In layman terms, it is the brain of the system, determining which jobs to send out and at which time interval. We have segregated WIndows Service into 3 different processing points: Basic/Monitor Service,Verifier Service and Publisher.

Basic/Monitor service form the main central processing part of the Windows Service before passing to the Verifier service for data integrity checks whilst the Publisher must have the option to trigger automatically based on the different profiles or manual entries in the rare event the end-user wishes to send output to a different FTP server. Also, the publish system would make use of the high-flying technology called ASPERA FileConnect.

Functionalities of Basic/Monitor Service

Function Description
Retrieving Video Assets The first function of Austin Basic Service would be to retrieve videos from the database which have been tagged as 'Not Started' by the Web Application on submitting video metadata.
Get the video metadata and put into queue (application memory) The service would have to be able to retrieve the video metadata on top of the video itself and put it into the queue entering the encoder, within application memory itself. This queue basically means into Watch Folders which the encoder will then feed on depending on time intervals. At the same time, at this point in time, the service would update the database and change the status of the video in Video Orders table to 'Sent to Watch Folder'.
Validate video metadata The service is required to validate that all video metadata are in place before feeding into the Watch Folders. In the event that metadata is missing such as image url, update VideoOrders table with status set to Error.
Notify the user The service is required to notify the user via 2 platforms for any event change. For example, if the video has stalled within the encoder, the service must be capable of sending data to the dashboard to notify user and be able to send out an email in the event of status of video assets being changed to 'Error' within Video Orders table. This error might come about via missing metadata or the encoder failure or extreme network congestion.
Delete entire video The service would always be checking for same filename in input folder and output folders before sending a video over. In the scenario that the video asset has been sent to the Watch Folders twice for some reason, the service must be capable of deleting the entire video asset from the respective encoder folders (Input or Output folders).

Functionalities of Verifier Service

Function Description
Retrieving Video Assets The first function of Austin Monitor Service would be to retrieve videos from the database which have been tagged as 'Sent to Watch Folder' by the AUSTIN Basic Service in time intervals of 5 minutes as default. This time interval would be dynamic in going forward with different phases of the project.
Check video asset file integrity The service would have to be able to check for the file integrity of the videos that have been uploaded to prevent any corruption of videos that will eventually affect the output folder.
Notify the user The service is required to notify the user via 2 platforms for any file integrity alerts. For example, if the video has contained corrupted elements, the service must be capable of sending data to the dashboard to notify user and be able to send out an email. The encoder would then not be able to process the videos until issues have been solved.

Functionalities of Publisher

Function Description
Retrieving Video Assets The first function of Austin Publisher would be to retrieve videos from the database which have been tagged as 'Completed' by the AUSTIN Monitor Service in time intervals of 5 minutes as default. This time interval would be dynamic in going forward with different phases of the project.
Check Business Logic Automatically or Manually The publisher would have to check the business logic attached to the video metadata whether a specific video asset has been tagged as manual or automatic upload.

In the event of automatic upload, the publisher would have to publish the video asset in 3 different formats: XML, JSON and 3rd Party Formats. In the event of a manual upload, the publisher would have to publish the video asset by only generating a RSS feed for end-users to consume.

Generate XML Format The publisher must be capable of generating XML format for a particular video asset after it has been encoded successfully.
Upload Entire Video Asset in generated format The publisher must upload the entire video asset which includes the thumbnail attached to the metadata to the appropriate FTP Address which is tagged to the id of the video in the Video table.

Aspera File Connect would be used to achieve this in great speeds compared to the traditional FTP transfer speeds.

Publish to users and viewers The publisher will be able to publish the uploaded videos to users and viewers from the appropriate FTP addresses with the tags that have been created and used in the videos.
Notify the user The publisher is required to notify the user for any videos that have been published. With this function, the user would be alerted for to know which are the videos that have been published successfully.