Application Design Document Developers Uri Goldenberg 039078191 uri

Application Design Document • Developers: Uri Goldenberg 039078191 uri. goldenberg@gmail. com o Henry Abravanel 310739693 o henryabra@gmail. com o • 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

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.

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

Functional requirements • Virtual File System The VFS should list virtual video files according to pre-configured rules. o The VFS should serve virtual video files as if they existed. Upon request to read such a file, the Transcoding module should wrap the source noninterleaved 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. o

Functional requirements • Transcoder o Transcoder should wrap/unwrap non- interleaved/interleaved video files. o Scope of target file formats (containers) are: MPEG 4, MXF, MOV (Quicktime) ordered by priority. Scope of supporting codecs are: H 264, DV, MPEG 2 ordered by priority.

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

Non-Functional Requirements • Performance constraints 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 well documented. Moreover, the configuration file should be written in a <property, value> format that is easily editable. o

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.

Main Classes Overview

Main Classes Configuration • Parse Configuration files o Includes the following parameters: o Input Directory o Cache Directory o Mount Point o 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

Main Classes Formats 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.

Main Classes Fuse 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*

Main Classes Monitor 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.

Algorithms Read 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 o all files = Read All files in Input directory in Alphabetic order( Input Directory) 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)

Algorithms Wrapping • 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 o o Calculate Video elementary file from Virtual file name. Calculate All Audio elementary file from Virtual. Create a new working Proccess o Read file while working § Call FFMPEG module to start wrapping

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.

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)