Administration Guide : Working with Videos : Behind the scenes of Video for Xinet

Behind the scenes of Video for Xinet
This section provides details about how the various programs that comprise Video for Xinet work. You may also be interested in Xinet TechNote 313,Troubleshooting interactive formats (Xinet Video module).”
In this section
Identifying a file
Identifying a file
The following steps show how the Xinet software identifies video file types when files are placed on the server:
If the file contains Type and Creator information (assigned by the client system upon which it originates), the Xinet ksd(1M) daemon writes that information into the file system as part of the file’s Macintosh ancillary (desktop) information and also writes information about the file’s arrival into the weblog files at the following locations:
/usr/adm/appletalk/webdblog file on Unix systems
C:\Program Files\Xinet\FullPress\webdblog file on Windows systems
The dblogd(8M) daemon periodically reads the webdblog file.
a. The suffix or extension of the file name itself. This is a common method for identifying the type for many video files, CAD files (DWG, DXF, SAT), and interactive files (HTM, HTML, MHT, and so on), which must have their type identified this way because their file type is TEXT (plain ASCII).
b. The presence of file signatures at the beginning of the file (that is, within the file’s data fork), including magic numbers. For example:
MPEG video files are recognized by one of the following magic numbers: 0x001BA, 0x001B3.
The following file types are recognized by information within the data fork: AVI, AIFF, QuickTime, RIFF, WAVE.
These methods refer to the Xinet filetype table, located in the following locations:
/var/adm/appletalk/ (for Unix)
C:\Program Files\Xinet\FullPress\Admin\ (for Windows)
In turn, fpod(1M) passes the information to movsync(1M) and asks movsync(1M) to process the file, which it does depending on what type of video or interactive file it has received.
The movsync(1M) program reads XML configuration data entered through the nativeadmin GUI and stored in the database Volumes table. From these settings, movsync(1M) determines whether it will send files to the Xinet Video Engine, the htmlsync(1M) program, the browcapt(1M), the cad2jpg(1M), the dgn2jpg(1M) program or exr2jpg program.
About the movsync(1M) program
An overview
Depending on the type of file it receives along with various configuration settings, movsync(1) passes on the file to another program for preview or key frame generation and once those have been returned, adds them to the Xinet database. In some cases, movsync(1M) also determines which of the frames to keep and may also generate low-resolution videos that it also adds to the database. The following presents an overview of its activities:
Some details about processing files
The movsync(1M) program processes a file depending on information it receives about its type. The following subsections discuss the five categories and their subcategories.
Video files
The movsync(1M) program treats the following file types as video files: mpg4, M4V, M4VP, MPEG, MooV, SWFL, AIFC, RIFF, ASF. It also processes Apple ProRes 422 and 4444 video files, MPEG TS files, OpenEXR files and files with subtitles, but as a special cases, discussed in the following subsections.
For video files, movsync(1M) takes as input a video file and generates as output individual JPEG frames which are subsequently stored in the Xinet database. Depending upon how you configure the system, movsync(1M) will use the Xinet Video Engine to generate images. When using the Xinet Video Engine, movsync(1M) employs a motion-detection algorithm configured in the nativeadmin GUI to detect scene changes. Only when a change in scene content differs enough from a previous scene will a given image be stored in the database. Configuring Video for the Xinet Video Engine and When movsync(1M) uses the Xinet Video Engine to generate key frames provide more information about this.
The movsync(1M) program may also be configured to generate multiple low-resolution videos from one of these input types. The low-resolution video data is stored directly in the database and not on the file system. Automatically generating Low Resolution Videos provides more information about this.
About MPEG Transport Stream (MPEG TS) files
An MPEG Transport Stream may carry multiple programs within it of varying kinds. Some programs may contain both audio and video streams; others, simply audio streams.  The figure above shows a MPEG TS file, 104654.ts, on a Xinet Portal server. Note that the file is accompanied by a folder, 104654, which contains the individual programs extracted from the original file. Also note, that within that folder, some files are movies and others are audio files (those with the .mp2 extension). That folder has been populated, metadata has been extracted and previews made in this way:
The movsync(1M) creates a subfolder using the original file’s name but does not include its extension.
Then, movsync(1M) extracts each program into the subfolder, named as base_file_name-unique_program_ID.appropriate_format_extension, for example 104654-4112.mpg.
Finally, it queues each extracted program to be processed by the movsync(1M) to provide previews and metadata for all programs.
About OpenEXR files
OpenEXR is a high dynamic-range (HDR) image file format developed by Industrial Light & Magic for use in computer imaging applications. For OpenEXR files, movsync(1M) calls on the exr2jpg binary (which resides inside /usr/etc/venture/bin on Unix servers only making use of its -i OpenEXR_input_file and -o name_of_the_output_JPEG_file options.
About files with subtitles
When the Xinet Video Engine process a video file, it checks to see whether the file has either embedded or sidecar subtitles. Sidecar subtitle files, themselves, are not passed to movsync(1M); so they must already be present in the same directory when movsync(1M) processes the video file with which they are associated and must be named or same_file_name_as_the_video.sub.
The Xinet Video Engine recognizes both SubRip Subtitle Files (SRT) and MicroDVD sidecar files. SRT files take the form:
1 00:02:26,407 --> 00:02:31,356
Neque porro quisquam est qui dolorem ipsum quia dolor sit amet, consectetur, adipisci velit
While MicroDVD files take the form:
{421}{551}Neque porro quisquam est qui dolorem ipsum quia dolor sit amet,
{552}{660}consectetur, adipisci velit
With these formats, the timeline information from each is used to associate subtitles with extracted frames, with sidecar files appearing as linked files in Xinet Portal’s media viewer (mview). Subtitle text can be searched for with the Search Engine and any frame with subtitles associated with it can also viewed in browsers using the Text Contents option in the media viewer.
When subtitles have been embedded into a movie file using a stream rather than traveling in a sidecar file, the Xinet Video Engine does not extract timeline information; thus, all subtitles will be associated with the first frame.
Shockwave Flash (SWF) files
The movsync(1M) program identifies SWF files, which typically have the Type SWFL, via the first three bytes, recognizing CWS as a compressed SWF and FWS as an uncompressed SWF. The movsync(1M) program also reads the SWF dimension from the header, making a temporary HTML Flash wrapper located in the same folder as the SWF file it references, thus allowing the SWF itself to locate any relative assets it needs to import. Movsync(1M) will uncompress the file before doing so, if necessary. It then hands these files to the browser capture process, browcapt(1M), to capture frames. (See “Settings for browcapt(1M)” in the vsp.conf(4) man page in Appendix A for details.) Once captured, movsync(1M) uses the same motion-detection algorithm it uses for video files to process and select frames for storage in the database.
The movsync(1M) program does not generate low-resolution videos from SWF files; but the captured frames can be used as static images in the Video Reel Generator. Xinet TechNote 303 provides more information about Flash video files.
HTML files
The movsync(1M) program determines which files are HTML files via their file extensions, recognizing those with following extensions as valid HTML files: htm, html, url, webloc, mht, and webarchive.1 It then passes HTML files on to htmlsync(1M) to process.
When files use the htm or html extension, htmlsync(1M) will add locally-linked resources such as images, JavaScript files and HTML pages to the spreadlink table in the Xinet database, thus making these resources viewable through the mview CGI. For example, if an HTML file which contained <img src=’MyCompany/logo.jpg’> were to reside inside /FPAssets/MainWebPage, and, if the file logo.jpg resided in the directory /FPAsset/MainWebPage/MyCompany, htmlsync(1M) would place this link in the spreadlink table, making the asset viewable through mview.
The movsync(1M) program does not generate low-resolution videos from HTML files, but captured frames can be used as static images in the Video Reel Generator.
MP3 files
Movsync(1M) identifies MP3 files by file type. After determining the file is an MP3 file, it extracts and stores album artwork in the database, as well as metadata, such as codec name, sample rate, bit rate and the number of channels. Movsync(1M) assumes that art tagged as ID3PT_COVERFRONT appears on the album’s cover and adds that preview to the database so that it will be the first preview displayed in mview and what users see when viewing the file in Short View. It adds other pieces of album artwork in the order in which they have been stored in the MP3 file. All images from MP3 files will be displayed with watermarks if the volume they are stored on has been configured to do so. At this time, movsync(1M) does not store full ID3 information from MP3s in the database.
CAD files
AutoCad files
The movsync(1M) passes 2D and 3D CAD files on to the cad2jpg(1M) program to generate previews. The cad2jpg(1M) program renders previews for DWG, DXF, BDXF and a number of ACIS SAT formats. (Xinet tested ACIS SAT versions 1.0 through 8.0, 10.0, 11.0, 20.0 and 21.0.)
The cad2jpg(1M) program uses the Open Design Alliance libraries to render and rotate 3D AutoCAD files coupled with the Mesa 3D OpenGL software renderer. How files are rendered depends upon both the file type and contents. For more information about the cad2jpg(1M) program, refer to the cad2jpg(1M) man page in of this manual or if you are using a Unix system, you can use man(1) to review it on-line.
DGN files
The dgn2jpg(1M) program uses the Open Design Alliance libraries to render and rotate DGN CAD files (formats supported by Bentley Systems’ MicroStation and Intergraph’s Interactive Graphics Design System (IGDS) CAD programs), coupled with the Mesa 3D OpenGL software renderer. It supports DGV versions 7 and 8.
How files are rendered depends upon a combination of settings that have been established within the Xinet Administration GUI and properties within the individual file. For more information, refer to dgn2jpg(1M) in of this manual or if you are using a Unix system, you can use man(1) to review it on-line.
When movsync(1M) uses the Xinet Video Engine to generate key frames
Xinet servers with the Video module can also generate key frames using the Xinet Video Engine. In this case, the Video module and the Xinet Video Engine run on the same server.
At the global level
The Xinet Video Engine checks on a global setting (or settings) found in the /usr/etc/venture/var/vsp.conf file on Unix systems. This is an XML-global-settings file which About the vsp.conf file explains in greater detail.
At the volume level
The following steps take place when video files are placed on the Xinet server and key frames are generated using the Xinet Video Engine:
The engine processes the video file and extracts key frames based on threshold settings, reading and scoring differences between frames. It saves key frames in a temporary file on the system (on Unix, /tmp; on Windows the Administrator’s tmp folder), and when it’s done, provides movsync(1M) with the total key-frame count. Each key frame is identified by a name with a unique ID in it.
As it works, the Xinet Video Engine writes information which you can view on the Logging, Preview Generation, Syncing History page.
With the Xinet Video Engine key frame count as a prompt, movsync(1M) stores selected key frames in the Xinet database. Once stored, all frames are removed/deleted from disc.
Depending on options set in the nativeadmin GUI (Automatically generating Low Resolution Videos describes these options), movsync(1M) generates lower resolution videos and also adds them to the database.
End users either browse through key frames or engage the mview CGI to view them (Annotations) or, when using Xinet Portal, the videos at their original or lower resolution.
[optionally] Users add metadata which [also, optionally] trigger an Action in the workflow. Users may also use the Xinet Portal Collection’s Video Reel Generator plug-in to create storyboards.
About the vsp.conf file
The vsp.conf file is an XML global settings file used by various components of the Video module, including movsync(1M), htmlsync(1M), browcapt(1M), the Video Reel Generator, cad2jpg(1M), and dgn2jpg(1M). You can find the file in /usr/etc/venture/var/ on Unix systems and C:\Program Files\Xinet\Venture\var\ on Windows systems.
For full details about how components of Xinet Video make use of the vsp.conf(4), refer to the vsp.conf(4) manual page in Appendix A of this volume or if you are on a Unix system, online, using the man(1) command.
About browcapt(1M)
The browcapt(1M) process captures previews of Web page content, launching a hidden browser window and capturing its contents. Depending on the server’s platform it relies on the following program(s):
OS X: WebKit
Linux and Altix: Xvfb(1), xwd(1) and Firefox
Windows: Internet Explorer
See Video server requirements, Video for Xinet installation procedure, and the browcapt(1M) manual page for more information.

Only WebKit on OS X servers processes the webarchive format.