Behind the scenes of Video for Xinet

If the file contains Type and Creator information, 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 /usr/adm/appletalk/webdblog file on Unix systems or the C:\Program Files\Xinet\FullPress\webdblog file on Windows systems. The dblogd(8M) daemon periodically reads the webdblog file.

If the file hasn’t been accompanied by information about its Type and Creator, ksd(1M) refers to the Xinet filetype table located in the directory /var/adm/appletalk/ (Unix) or C:\Program Files\Xinet\FullPress\Admin\ (Windows), and then writes any determined Type and Creator into the file’s ancillary information. See filetype(4) and Video file compatibility for more information about the filetype table.

The Type is used to determine which files are video, SWF or MP3 formats (HTML and CAD are determined by suffix). Once a file has been so identified, dblogd(8M) sends a command and the file’s FileID to fpod(1M).

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.

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:

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.

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.

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.

It uses the first program it encounters within the MPEG TS file that has both a video and an audio stream to generate previews for the main file.

Finally, it queues each extracted program to be processed by the movsync(1M) to provide previews and metadata for all programs.

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.

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 same_file_name_as_the_video.srt or same_file_name_as_the_video.sub.

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.

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.

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.¹ 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.

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.

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.

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.

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.

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.

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.

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):