Clips are segments of audio and video. Managing clips involves adding and removing them to and from the SGI Media Server clip cache.
Managing clips is discussed in the following sections:
This section provides a procedural overview of the tasks involved in adding clips to the SGI Media Server.
The following sections explain the steps in the following procedure in greater detail.
To add clips to the cache, use the following procedure.
Copy media to the SGI Media Server.
You must use a real-time filesystem. The vtrftp command included with Video Server Technology (VST) works in conjunction with the vtrftpd daemon, which is installable from the VST image. Use get, the familiar FTP command, with vtrftp to add files to the server.
Note: Before ingesting or transferring (via FTP) clips to your server, ensure that a clip with the same name does not already reside in the clip cache. Attempting to overwrite a clip without first deleting it could result in corrupt clips and/or unexpected behavior. For more information, see “Adding Clips to the SGI Media Server”.
Register the clip with the SGI Media Server.
Clips are registered automatically at VST startup. At times, however,VST may not auto detect a clip because of an unrecognized format. In that case or if you want to notify the SGI Media Server more quickly or if you have added clips to the system in a different way from those listed in step 1, use one of the following options:
Use the Multiport Video Computer Protocol ( MVCP) command CADD.
-
Caution: The clip cache is critical to proper SGI Media Server execution. Native UNIX filesystem operations against clip cache components—specifically, clip content and index files—will corrupt (possibly permanently) the cache structure. Doing so may lead to adverse or inconsistent SGI Media Server operation. Therefore, you must use the vtrutil utility and the other VST commands exclusively to manipulate clip content elements outside of MVCP sessions. DO NOT use rm, mv, cp, or other native UNIX filesystem commands to manipulate clip content elements residing in the real-time filesystem.
The SGI Media Server supports two media types, intraframe and interframe media, and several media formats: DIF, SGI MPEG-2, SMPTE 360M (playout only), and MXF.
The SGI Media Server supports intraframe media. In intraframe media, the video data for each frame is self-contained and does not depend on the data from neighboring frames. The SGI Media Server supports MPEG-2 I-frame, DVCPRO 25, DVCPRO 50, DVCAM, and DV (16-bit/48 Khz audio only) intraframe media. The MPEG-2 DVCPRO 25 and DVCPRO 50 formats may be contained within an MXF content file.
The SGI Media Server also supports interframe media using MPEG-2 long GOP. The media type depends on the information content contained in neighboring frames of a video sequence. The SGI Media Server video codec controls parameterize the interframe compression.
The SGI Media Server uses several formats for storing digital media in its clip cache filesystem(s): intraframe media in DIF format—for fixed-sized frames, including DVCPRO 25, DVCPRO 50, DVCAM, and DV (16-bit/48 Khz audio only). Further, MPEG-2 and IMX formats may be created under appropriate hardware and VST setup. The SGI Media Server supports the following file formats:
The simplest way to move clips from an editing workstation to the SGI Media Server is with FTP. VST contains a customized version of ftpd tailored for the VST environment and strictly dependent on a real-time filesystem. The VST version of the FTP daemon is the program vtrftpd. The ftp client is unchanged. In VST, the inetd process is configured to invoke /usr/vtr/bin/vtrftpd when a connection request from a FTP client arrives on port 20 to initiate a file transfer.
The VST FTP daemon vtrftpd has the following features:
Stores to the real-time subvolume of a filesystem.
Has configurable guaranteed rate I/O (GRIO) for stores or retrievals.
Automatic disk- and network-I/O sizing.
Honors in and out points while transferring DIF files.
Updates the clip cache so that the clip is available before the end of the transfer.
Does not quit on the end-of-file condition for growing clips.
Can be used to set start, in, and out points of a clip.
See the vtrftpd(1) man page for syntax and usage options. The vst_eoe.sw.ftpd subsystem contains the vtrftpd daemon and other file transfer-related components.
The SGI Media Server depends on the XFS real-time filesystem, an optional component of IRIX. A real-time filesystem consists of two partitions: a data partition and the real-time partition. The real-time partition stores SGI Media Server clip content for playout and the ingested media processed during the encoding process.
Most applications, including /usr/bsd/ftp, have no means to distinguish among temporary filesystem characteristics. If you invoke ftp and use the get command on a SGI Media Server to get a file from another platform, the content is stored on the data partition, but not the real-time partition. However, if the put command is used on a remote FTP client or a passive transfer is performed, then vtrftpd correctly writes to the real-time partition, because vtrftpd is aware of the temporary filesystem.
During the put or passive file transfer process, vtrftpd periodically informs VST about clip size. This implies that an MVCP CINF command applied to the clip will reveal growth and change in the clip as the transfer progresses.
While the transfer is in progress, the clip is available for playout before the transfer concludes. This is useful for large clip transfers over a slow network. A transfer may also be initiated against a clip being actively recorded, thereby providing the ability to stream to another platform, such as an editing station. Unlike the standard FTP daemon ftpd, vtrftpd does not close the connection at the end of the file. The connection persists until clip growth ceases.
If the available FTP transfer bandwidth is greater than the clip compression bit rate, almost all of the clip will be available at the destination server for playout in real-time. It is also possible to daisy-chain a number of servers to concurrently stream a recorded clip over multiple hops.
The XFS real-time component provides a GRIO subsystem, which is a feature for reserving and managing filesystem resources necessary to ensure predictable response times under real-time conditions. The GRIO is necessary to avoid oversubscribing disk bandwidth. The standard FTP daemon ftpd consumes resources without restraint, which requires GRIO to regulate the filesystem access. Under this regulation, playout and record channels are not affected. You can specify these contraints using the controls in the /usr/vtr/config/vtrftpd.conf file. See the vtrftpd(1) man page for details.
For DIF clips, vtrftpd transfers only the segment within the in and out points of the clip (if they are set). This is useful when only a small portion of a large clip is needed. A clip segment can be extracted by using an FTP transfer to the local host, and then dividing a DIF clip into subclips by changing the edit points. This feature can also be disabled with the toggle command site marks. Consequently, the marks will be ignored and the whole clip will be transferred.
You can set the start, in, and out points of a clip using the command site editpoints. By default, these attributes are not transferred with the clip.
As mentioned previously, a get command with the FTP client on a server will do the wrong thing by writing the file to the data partition of your real-time filesystem. Avoid this use of ftp with vtrftpd. Instead, use proxy transfers between servers, as described in the following paragraphs.
FTP allows an FTP client to control the daemon on two servers. The FTP client can be on either of the servers or on a third server. Typically, the FTP client connects both servers with a control connection, instructs one of the daemons (vtrftpd) to open a data connection with the other, and then initiates the transfer between the two servers. The two vtrftpd processes then correctly read and write the real-time files while performing GRIO reservations.
The simplest way to achieve proxy FTP transfers is to use the vtrftp command, a Perl FTP client that performs passive FTP transfers between servers. The vtrftp command copies the start, in, and out points. Enter the following command sequence to use proxy FTP with the UNIX ftp client:
server1 4# ftp server2 Connected to server2.csd.sgi.com 220 server2.csd.sgi.com FTP server ready. Name (server2.csd:root): vtrsync 331 Password required for vtrsync. Password: 230 User vtrsync logged in. Remote system type is UNIX. Using binary mode to transfer files. ftp> proxy open server1 Connected to server1.csd.sgi.com. 220 server1.csd.sgi.com FTP server ready. Name (server1.csd:root): vtrsync 331 Password required for vtrsync. Password: 230 User vtrsync logged in. Remote system type is UNIX. Using binary mode to transfer files. ftp> proxy put testftp local: testftp remote: testftp server1.csd.sgi.com:200 Type set to I. server1.csd.sgi.com:227 Entering Passive Mode (130,62,124,44,8,11) server2.csd.sgi.com:200 Type set to I. server2.csd.sgi.com:200 PORT command successful. server2.csd.sgi.com:150 Opening BINARY mode data connection for 'testftp'. server1.csd.sgi.com:150 Opening BINARY mode data connection for 'testftp' (108969984 bytes). server1.csd.sgi.com:226 Transfer complete. server2.csd.sgi.com:226 Transfer complete. ftp> |
Some SGI Media Server clip formats, including MPEG-2 clips, have both clip content and a companion index file. The index file has a clip content frame directory, consisting of metadata and frame index information essential to play the clip correctly. Both the index and clip content file must be transferred for these formats.
If the clip is being recorded and is subject to an FTP transfer to another server for playout, transfer the index and clip files simultaneously. If concurrent transfer and playout is not a requirement, transfer the index file first, and then transfer the clip content file.
Index files reside under the /usr/vtr/index directory and have the same name as their companion clip. Index files are small compared to the content file they describe. The /usr/vtr/index path is a non-real-time data partition managed by the SGI Media Server.
Use a small window size with vtrftp. If you use a large window size (typical for clip files), FTP will time out before the window is filled and you will get an incomplete index file.
Certain clips might need to be aligned in the filesystem for enhanced performance. In single-disk systems, media files are aligned only with the filesystem's block size so that only one I/O operation is needed to access the data.
In multidisk, RAID striped systems, the media files must also be aligned with the stripes.
When the SGI Media Server is used to record media, it automatically places the media data in the correct, aligned locations on the disk.
Frame-oriented media data in an intraframe clip is aligned along the following two boundaries:
Minor alignment boundary
Major alignment boundary
A single element of a frame (a video field or audio chunk) never crosses a minor or major alignment boundary. The SGI Media Server will not do a read or write operation to the clip media file that crosses a major alignment boundary.
The minor alignment matches the greater of the filesystem block size or the system memory page size. On the SGI Media Server, the minor alignment is usually 16 KB, unless a larger filesystem block size was used.
The major alignment matches the stripe size of the disk volume that holds the clip cache filesystem.
If the clip cache resides on a single disk, no major alignment is required.
If the clip cache resides on a single RAID subsystem, major alignment is required for efficient I/O access to the media data. Create a real-time filesystem on the RAID LUN and set the real-time extent size of the XFS filesystem to the desired I/O operation size.
| Note: If the clip cache resides on a striped XLV volume, the major alignment matches the stripe size of the XLV volume. |
The SGI Media Server detects the clips when the clip is first loaded and every time the SGI Media Server starts. The clips are then listed in mcclips.
If you place a clip in the clip filesystem, the first time you attempt to access the clip through the SGI Media Server, it attempts to auto-detect the clip's format and add it to the clip list. However, until you attempt to access the clip, it will not be visible in a list of clips you obtain from the Clip Manager. To see the clip immediately, use the following command:
# vtrclip add clip-name |
| Note: There might be a delay because adding clips always has a lower priority than playout or record. |
You can also use the following MVCP command to notify the SGI Media Server of an added clip:
# CADD clip-name |
The vtrftpd utility honors in and out points on DIF clips for transfers from the real-time filesystem on the server. You can transfer the segment of a clip between in and out points instead of having to transfer the whole clip, saving transfer time and disk space in many cases.
If a clip has no in or out point set, vtrftpd uses the following defaults:
If the start point (beginning of the file) is invalid or missing, it is set to 00:00:00.00.
If the in point is invalid or missing, it is set to the start point.
If the out point is invalid or missing, it is set to the end of the file.
If in and out points are set in a clip, but you want to transfer the entire clip, you can override this feature. To transfer an entire file that has in and out points set, enter the following at any point in the session:
ftp> site marks |
This command is a toggle. To turn the clip segment transfer feature on again, enter the command again.
There are three ways to remove clips from the SGI Media Server.
-
For more information about using the Media Server Control Panel to remove a clip, see Appendix A, “The SGI Media Server Control GUIs”.
Command line
You can completely remove a clip from the server using the following command:
# vtrclip rm clip-name
The value clip-name specifies the name of the clip file.
The SGI Media Server provides full record and playout support for the following Material Exchange Format (MXF) compression types:
Media compression formats such as MPEG-2 require a collateral frame index file to enable reliable playout and ingestion processing. This index contains a frame-by-frame description of the content clip that includes a frame directory for the content file, frame size, offset, timecode, and other pertinent information.
The following example shows truncated output of vtrmpegutil for the frame content of an index file:
param 10# vtrmpegutil -p frames /usr/vtr/index/myclip |
index 250, pictures 250, start 01:39:00:00 (148500) entry offset frame size audio offset audio size Timecode 0: 0 250000 (I) 250000 30744 (0) 0 0 (0) 01:39:00:00 1: 280744 250000 (I) 530744 30744 (0) 0 0 (0) 01:39:00:01 2: 561488 250000 (I) 811488 30744 (0) 0 0 (0) 01:39:00:02 3: 842232 250000 (I) 1092232 30744 (0) 0 0 (0) 01:39:00:03 4: 1122976 250000 (I) 1372976 30744 (0) 0 0 (0) 01:39:00:04 5: 1403720 250000 (I) 1653720 30744 (0) 0 0 (0) 01:39:00:05 6: 1684464 250000 (I) 1934464 30744 (0) 0 0 (0) 01:39:00:06 7: 1965208 250000 (I) 2215208 30744 (0) 0 0 (0) 01:39:00:07 8: 2245952 250000 (I) 2495952 30744 (0) 0 0 (0) 01:39:00:08 9: 2526696 250000 (I) 2776696 30744 (0) 0 0 (0) 01:39:00:09 10: 2807440 250000 (I) 3057440 30744 (0) 0 0 (0) 01:39:00:10 |
Certain imported media formats, such as MXF, do not have native index files, and they must be generated before the SGI Media Server can play out the clip content. Playout of MXF content can be accomplished by using the vtrmpegutil command to generate an index file and then by invoking either CADD clipname from MVCP or by using the vtrclip command.
The following is an example of generating an index file for MXF content:
$ vtrmpegutil -i mxf clip1.mxf /usr/vtr/index/clip1.mxf |