Application Design Document

17
Application Design Document Developers: o Uri Goldenberg 039078191 [email protected] o Henry Abravanel 310739693 o [email protected] Academic Advisor: o Prop. Michael Elhadad, Senior Lecturer at the Department of Computer Science, Ben-Gurion University of the Negev. Professional Advisor: o Barak Bar-Orion, Team Leader at Gefen Dekel Technologies LTD, Dalet

description

Developers: Uri Goldenberg 039078191 [email protected] Henry Abravanel 310739693 [email protected] Academic Advisor: Prop. Michael Elhadad , Senior Lecturer at the Department of Computer Science, Ben-Gurion University of the Negev. Professional Advisor: - PowerPoint PPT Presentation

Transcript of Application Design Document

Page 1: Application  Design Document

Application DesignDocument• Developers:

o Uri Goldenberg 039078191 [email protected]

o Henry Abravanel 310739693 o [email protected]

• Academic Advisor:o Prop. Michael Elhadad, Senior Lecturer at the

Department of Computer Science, Ben-Gurion University of the Negev.

• Professional Advisor:o Barak Bar-Orion, Team Leader at Gefen Dekel

Technologies LTD, Dalet

Page 2: Application  Design Document

Abstract

We would like to enable applications that require digital video with specific container format and video codec as data source to use digital video actually stored with a different container format transparently using a Virtual File System (VFS).  The VFS module will give access to “virtual” video files in the desired container format, by producing the desired format on the fly given the actual file format as input.

Page 3: Application  Design Document

System Architecture• Fuse kernel module register with

VFS.• Our user space file system will link

with FUSE library.• File system calls are passed to FUSE

library which invokes associated FUSE operation in our file system.

• The user is not aware of the underline wrapping system and all system calls are handled transparently by our file system

Page 4: Application  Design Document

Functional requirements• Virtual File System

o The VFS should list virtual video files according to pre-configured rules.

o The VFS should serve virtual video files as if the they existed. Upon request to read such a file, the Transcoding module should wrap the source non-interleaved video files, and then the VFS should serve it.

o The VFS should allow write operations on interleaved files. Upon such a request, the VFS should pass the video file to the Transcoding module for unwrapping and writing of non-interleaved files.

Page 5: Application  Design Document

Functional requirements• Transcoder

o Transcoder should wrap/unwrap non-interleaved/interleaved video files.

o Scope of target file formats (containers) are: MPEG4, MXF, MOV (Quicktime) ordered by priority. Scope of supporting codecs are: H264, DV, MPEG2 ordered by priority.

Page 6: Application  Design Document

Functional requirements• Configuring

o The system should allow configuration of these parameters: Source files directory Cache directory Mount directory Target files naming convention and container formats

Page 7: Application  Design Document

Non-Functional Requirements • Performance constraints

o Reliability - It is essential that the system will work without errors and will not require reload especially assuming that it should work all the time.

o Availability - The system should be available all the time.

o Usability -  Due to the fact that the system is essentially a VFS, its interface is as any other file system. Hence there is no usability considerations on this interface. The monitoring interface should be easy to understand and well documented. Moreover, the configuration file should be written in a <property,value> format that is easily editable.

Page 8: Application  Design Document

Non-Functional Requirements • Platform constraints

o Operating System The system will only work under Linux with kernel

version of 2.6.X. o Extra Dependencies

FFmpeg is a complete, cross-platform solution to record, convert and stream audio and video.

FUSE (Filesystem in Userspace ) is a loadable kernel module for Unix-like computer operating systems, that allows non-privileged users to create their own file systems without editing the kernel code. This is achieved by running the file system code in user space, while the FUSE module only provides a "bridge" to the actual kernel interfaces.

Page 9: Application  Design Document

Main ClassesOverview

Page 10: Application  Design Document

Main ClassesConfiguration• Parse Configuration files

o Includes the following parameters:o Input Directoryo Cache Directoryo Mount Pointo Audio and Video to Container mappings

• Check existence of the above directories• Create bitmaps for containers and formats for fast lookups

FFMPEG Handler• Allocate resources for wrapping.• Call FFMpeg with correct command line for wrapping and unwrapping

Page 11: Application  Design Document

Main ClassesFormats Manager• All elementary files read must comply to the following naming

convention.• <file name>.<video extension>• <file name> _<audio track number>.<audio extension>• For each target container must have one video elementary file and

one or more audio elementary files.• Virtual target naming convention will be

• <file name>_<audio track 1>..._<audio track N>.<container ext>• Find All possible target containers for all elementary files in input

directory in order to support the virtual directory listing.• Find Elementary file names from virtual file name in order to correctly

wrap request for the virtual file.

Page 12: Application  Design Document

Main ClassesFuse Main• Main class of the project

o Read and parse configuration.o Call FUSE to create a virtual file system in the

configured mount point.o Implements virtual file system functions:

Read Directory (similar to Dir) Open File Get attributes Read File Write File*

Page 13: Application  Design Document

Main ClassesMonitor Data• This class Is responsible of monitoring the following parameters:Files being wrapped.Serve bit rate.Cache size.RAM usage.CPU usage.Files that already wrapped.

• The interface to this class for the user will be a virtual file that when reading it return all the information stored in this class.

Page 14: Application  Design Document

AlgorithmsRead Directory (Get file list of all virtual files)• The following algorithm allows us to calculate all virtual files in 1 pass

over input directory regardless number of configurations available and number of files.o all files = Read All files in Input directory in Alphabetic order( Input Directory)o For each group X of files with the same name in all files

Elementary extensions = 0 For each file Y in X

extension bit = Find configuration bit (Y) (Elementary extensions) = (Extension bit) | (Elementary extensions)

Find all Available containers (Elementary extensions)

Page 15: Application  Design Document

AlgorithmsWrapping• Execution of Wrapping file will be upon opening it.• Check if file is already in cache, or in input directory.• If Virtual file does not exist.

o Calculate Video elementary file from Virtual file name.o Calculate All Audio elementary file from Virtual.o Create a new working Proccess

Call FFMPEG module to start wrappingo Read file while working

Page 16: Application  Design Document

Testing

Testing the project is done in 3 levels.Unit testing:To accomplish unit testing we use Cunit module. Each main function is tested in a success scenario, fail scenario and Interesting input scenarios we might find. Every revision of the project must pass all unit tests or at least understand why a specific test fail.

Functional testing:The system should pass an easy scenario of listing 1 file, wrapping it and running it simultaneously. System testing:These tests are done manually. We should test difficult scenarios of multiple wrapping, Various formats. And examine Ram usage ,CPU usage and possible synchronization bugs.

Page 17: Application  Design Document

Tasks List• Finish coding for the functional requirements. (15.5)• Check system performance. (Memory usage, CPU usage , How many

wrappings can be done simultaneously) (22.5)• MXF, MOV format checking and testing. (29.5)• Un-wrapping coding and testing. (12.6)