Omneon Spectrum™ System

Protocol Reference Guide

Release 5.4
Omneon, Inc.™ • Omneon Spectrum™ System • Protocol Reference Guide
Part Number: 28-0105. Version 5.4. May 2009.

Copyright and Trademarks

Copyright © 2000-2009 Omneon, Inc. All rights reserved. Omneon, Omneon, Inc., and the Omneon, Inc. logo
are trademarks of Omneon, Inc.. All other trademarks are the property of their respective holders. May be
covered by one or more of U.S. Patents No. 6,571,351; 6,696,996; 6,545,721; 6,574,225; 6,895,003; 6,522,649;
6,643,702; foreign counterparts and pending patent applications.
This system is distributed with certain other software that may require disclosure or distribution of licenses,
copyright notices, conditions of use, disclaimers and/or other matter. Use of this system or otherwise fulfilling
their conditions constitutes your acceptance of them, as necessary. Copies of such licenses, notices, conditions,
disclaimers and/or other matter are available in any one of the following locations: the LEGAL NOTICES
AND LICENSES directory of the distribution disk of the software, the root directory of the hard disk drive of
the Products, online at http://support.omneon.com/LEGAL or by contacting us at [email protected].

Software Release
Release 5.4

Notice
Information contained in this guide is subject to change without notice or obligation. While every effort has
been made to ensure that the information is accurate as of the publication date, Omneon, Inc., assumes no
liability for errors or omissions. In addition, Omneon, Inc.,. assumes no responsibility for damages resulting
from the use of this guide.

Company Address

Omneon, Inc.
1237 E. Arques Ave.
Sunnyvale, CA 94085-4701

Business Office: +1 (866) 861-5690

Fax (Business Office): +1 (408) 585-5099
Technical Support: +1 (408) 585-5200
Fax (Sales and Technical Support): +1 (408) 585-5090
Web Site: www.omneon.com
E-mail (Sales): [email protected]
E-mail (Support): [email protected]

Protocol Reference Guide

 Contents
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
New in this Version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Omneon End User Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Omneon SystemManager Documentation Suite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Omneon Spectrum System Documentation Suite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Available Media and Wrapper Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Technical Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Chapter 1 Command Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

VDCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
CmdSystem (0x00) and CmdVarIdSystem (0x08) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
CmdImmediate (0x01) and CmdVarIdImmediate (0x09) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
CmdPresetSelect (0x02) and CmdVarIdPresetSelect (0x0a) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
CmdSenseRequest (0x03) and CmdVarIdSenseRequest (0x0b) . . . . . . . . . . . . . . . . . . . . . . . . . . 11
VDCP Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3X.70 / BX.70V_ID_INFO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
ID Information 3 – Timecode Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
VDCP User Data Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
User Data Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2X.60 / AX.60OPEN_USER_INFO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2X.61CLOSE_USER_INFO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2X.62ADD_USER_INFO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3X.63GET USER INFO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
VDCP Enhancements For Back-to-Back Play of Short Clips . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
20.78/A0.78: scheduleID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
30.07 activeIdRequest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
VDCP Enhancements for Improved Media Status Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Changes to ID Request (3X.16, BX.16) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Changes to Play Cue (2X.24, AX.24) and Play Cue With Data (2X.25, AX.25) . . . . . . . . . . 21
About Compatibility Switches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Sony Serial Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Setting Preroll Timing Parameters for Automation Systems Controlling Omneon MediaDirector. . 23

Omneon Spectrum™ System Release 5.4 i

 Chapter 2 FTP Server Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Commands Definitions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Access Control Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
USER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
PASS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
CDW, CDUP, XCWD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
ACCT, SMNT, REIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
QUIT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Transfer Parameter Commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
PORT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
PASV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
TYPE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
STRU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
MODE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
FTP Service Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
RETR <file>, STOR <file> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
STOU, APPE, ALLO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
REST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
RNFR <file>, RNTO <file> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
ABOR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
DELE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
RMD <dir>, XRMD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
MKD <dir>, XMKD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
PWD, XPWD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
LIST, NLST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
SYST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
STAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
HELP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
NOOP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
SIZE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
MDTM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
SITE Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
HELP SITE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
SITE LISTFMT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
File Striping and Associated Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
SITE STRIPE <type> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Clip Manipulation and Associated Commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
SITE LIST <dir/clip> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
SITE DELE <clip> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
SITE RNFR <clip>, SITE RNTO<clip> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Server Timeouts and Associated Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
SITE TIMEOUT <min> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
SITE RBW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

ii Protocol Reference Guide

 Transferring Clips Between Omneon Spectrum Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Notes on Parsing QuickTime Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
FTP Transfer While Recording . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i

Omneon, Inc. iii

iv Protocol Reference Guide
 Introduction

The Omneon Spectrum™ System from Omneon, Inc., is a scalable storage architecture that combines
a SAN (Storage Area Network) and NAS (Network Attached Storage) and that is designed to take on
all creative challenges for today’s digital media applications.
This document provides reference material relating to the Omneon Spectrum System and its
components as follows:
• Introduction provides an overview of the Omneon Spectrum System documentation suite,
lists terms and conventions, and provides Technical Support information.
• Command Sets provides information regarding a variety of command sets and preroll
parameters for controlling Omneon MediaDirectors.
• FTP Server Implementation provides information regarding File Transfer Protocol (FTP)
server implementation on Omneon MediaDirectors.

New in this Version

The following change were made in this version of the guide:
• Added information regarding the enhancements which improve the accuracy of media status
reporting via VDCP on Spectrum and MediaDeck Servers. Refer to VDCP Enhancements for
Improved Media Status Reporting for additional details.

Omneon Spectrum™ System Release 5.3 1

 Omneon End User Documentation
Omneon provides the following end user documentation:
• Omneon SystemManager Documentation Suite
• Omneon Spectrum System Documentation Suite

Omneon SystemManager Documentation Suite

Table 1 describes the documents which comprise the Omneon SystemManager Documentation Suite.
All items are packaged in self-extracting files and available for download from the Omneon Support
Server at the following location:
ftp://ftp.omneon.com/Updates/Omneon/Current/SystemManager/
All files on the Omneon Support Server are password protected. Contact Omneon Technical Support
if you need assistance with unlocking the files.
Acrobat® Reader® is needed to view the product documentation. Download this for free from:
http://www.adobe.com

Table 1. SystemManager Documentation Suite

This document... Provides this information...

Omneon SystemManager User’s Guide and • new features in the SystemManager release
Online Help System • system operations procedures
• system configuration procedures
• ClipTool installation and operation procedures
Omneon SystemManager Installation Guide • software installation and upgrade details
Omneon SystemManager Release Notes • last minute information regarding a product
release

Omneon Spectrum System Documentation Suite

Table 2 describes the documents which comprise the Omneon Spectrum System Documentation
Suite. All items are packaged in self-extracting files and available for download from the Omneon
Support Server at the following location:
ftp://ftp.omneon.com/Updates/Omneon/Current/Spectrum/
All files on the Omneon Support Server are password protected. Contact Omneon Technical Support
if you need assistance with unlocking the files.
Acrobat ® Reader® is needed to view the product documentation. Download this for free from:
http://www.adobe.com

2 Protocol Reference Guide

 Table 2. Spectrum System Documentation Suite

This document... Provides this information...

Omneon Spectrum System Getting Started Guide • new features in this release
• system installation
• software installation and upgrade details
• licensing information
Omneon Spectrum System Hardware Orientation • orientation to system components including
Guide MediaDirector, MediaPort, MediaStore, and Sys-
temManager Platform
• troubleshooting system components
• specifications for system components
Omneon Spectrum System Protocol Reference • command sets and preroll parameters for con-
Guide (this guide) trolling Omneon MediaDirectors, Omneon
implementation of ftp server
Omneon Spectrum System Quick Reference • front and back panel views of Spectrum hard-
Guides ware components
• component LED assignments and legends
Omneon Spectrum System Release Notes • last minute information regarding a product
release

Omneon, Inc. 3
 Available Media and Wrapper Formats
The Omneon Spectrum System supports the following compressed and uncompressed media
formats, depending upon the selected MediaPort:
• DV (25 Mbps)
• DVCPRO (25, 50 Mbps)
• DVCPRO HD (100 Mbps)
• MPEG-2 (various data rates and GOP structures)
• HDCAM
• DNxHD
• XDCAM-HD., XDCAM-EX
• HDV720
• 436M (VBI/VANC)
• DVB/ASI
• ITU-601 (Uncompressed)
• AES/EBU (48 kHz, 16 or 24-bits), AC-3 and Dolby™ E
Table 3 shows supported combinations of media wrapper formats and track types:
QuickTime MXF
QuickTime Self MXF OP1a MXF OP1b MXF OP1a OP0TypeA MXF OP1a
Reference Contained (Internal) (External) (eVTR) (External) Low Latency

Track Type Record/Play Record/Play Record/Play Record/Play Record/Play Record/Play Record/Play

DV 25 Both Both Both Both N/A Both Both

DVCPRO Both Both Both Both N/A Both Both

DVCPRO 50 Both Both Both Both N/A Both Both

DVCPRO HD Both Both Both Both N/A Both Both

MPEG-2 I-Frame Both Neither Both Both N/A Both Both

MPEG-2 IMX 30, Both Both Both Both Both Both Both
40, 50

MPEG-2 Long Both Neither Both Both N/A Both Both

GOP

HDCAM Both Neither Neither Neither N/A Neither Neither

DNxHD Both Neither Both Neither N/A Neither Both

XDCAM-HD Both Play only Play only Play only N/A Play only Play only

HDV720p Both Play only Play only Play only N/A Play only Play only

Table 3. Media Track Types and Wrapper Formats

4 Protocol Reference Guide

 QuickTime MXF
QuickTime Self MXF OP1a MXF OP1b MXF OP1a OP0TypeA MXF OP1a
Reference Contained (Internal) (External) (eVTR) (External) Low Latency

Track Type Record/Play Record/Play Record/Play Record/Play Record/Play Record/Play Record/Play

XDCAM-EX Both Play only Play only Play only N/A Play only Play only

XDCAM-HD (50 Both Play only Neither Neither N/A Neither Neither
Mbps)

Neither Neither Both (VBI) Play only N/A Play only Both (VBI)
436M Play only Play only
(VBI/VANC) (VANC) (VANC)

10Bit SDI Both Neither Neither Neither N/A Neither Neither

Table 3. Media Track Types and Wrapper Formats

About Omneon’s XDCAM Compatibility

Omneon's implementations of XDCAM-HD and XDCAM-EX are not RDD9 compliant. Hence, the
clips are not interoperable with Sony XDCAM-HD or XDCAM-EX devices. The clips are compliant
with several NLEs, including Final Cut Pro.
Table 4displays supported combinations of audio track types and media wrapper formats
AIFF (Big Endian) and WAV (Little
Wrapper Format Endian) AES3 8-bit A law

QuickTime Reference Total of (2, 4, 6, 8, or 16) audio No No

QuickTime Self Contained
channels recorded with (1, 2, 4, or
8) channels per file or per track
MXF OP1a (Internal) with sample size (16, or 24) bits.
MXF OP1b (External)

N/A Total 8 audio channels N/A

recorded with 8 channels
per file with sample size
24 bits encoded into 32
MXF OP1a (eVTR) bit wrappers.
MXF OP0TypeA (External) Total of (2, 4, 6, 8, or 16) audio No No
channels recorded with (1, 2, 4, or
8) channels per file with sample Yes
MXF OP1a Low Latency size (16, or 24) bits.

Table 4. Audio Track Types and Wrapper Formats

Omneon, Inc. 5
 Technical Support
Omneon, Inc. provides many ways for you to obtain technical support. In addition to contacting your
Distributor, System Integrator, or Omneon Account Manager, you can contact the Omneon Technical
Support department as follows:
For support in the Americas:
• Telephone (Toll Free): +1(888) OVN SPT1 (686 7781)
• Telephone (Local): +1(408) 585 5200
• Fax: (408) 521 2191
• Email: [email protected]
• http://www.omneon.com/support
• ftp://ftp.omneon.com/Updates/Omneon/Current/
For support in Europe, Middle East, and Africa:
• Telephone: +44 1256 347 401
• Fax: +44 (0) 1256 347 410
• Email: [email protected]
• http://www.omneon.com/support
For support in China (mainland)
• Telephone: +86 10 5811 1949
• Fax: +86 10 5811 1951
• Email: [email protected]
• http://www.omneon.com/support
For support in Japan:
• Telephone: +81 3 5565 6737
• Fax: +81 3 5565 6736
• Email: [email protected]
• http://www.omneon.com/support
For support in Asia Pacific (other territories):
• Telephone: +65 6548 0500
• Fax: +65 6548 0504
• Email: [email protected]
• http://www.omneon.com/support

6 Protocol Reference Guide

 Company Address

Omneon, Inc.
1237 E. Arques Ave.
Sunnyvale, CA 94085-4701

Omneon, Inc. 7
8 Protocol Reference Guide
 CHAPTER 1
Command Sets

This section provides information regarding a variety of command sets and preroll parameters for
controlling Omneon MediaDirectors. Choose from the following topics:
• VDCP
• Sony Serial Protocol
• Setting Preroll Timing Parameters for Automation Systems Controlling Omneon
MediaDirector

VDCP
Choose from the following topics:
• CmdSystem (0x00) and CmdVarIdSystem (0x08)
• CmdImmediate (0x01) and CmdVarIdImmediate (0x09))
• CmdPresetSelect (0x02) and CmdVarIdPresetSelect (0x0a)
• CmdSenseRequest (0x03) and CmdVarIdSenseRequest (0x0b)
• VDCP Extensions
• VDCP User Data Extensions
• User Data Commands
• VDCP Enhancements For Back-to-Back Play of Short Clips
• VDCP Enhancements for Improved Media Status Reporting

CmdSystem (0x00) and CmdVarIdSystem (0x08)

Command Code

CmdDeleteProtectId (0x15)
CmdUndeleteProtectId (0x16)

Omneon Spectrum™ System Release 5.4 9

 CmdImmediate (0x01) and CmdVarIdImmediate (0x09)

Command Code Note

CmdStop (0x00)
CmdPlay (0x01) When playing clip1, with clip2 immediately
following, the minimum preroll time needed to
ensure that all fields within clip2 are decoded is
2 sec.
CmdRecord (0x02)
CmdStill (0x04)
CmdStep (0x05)
CmdContinue (0x06)
CmdJog (0x07)
CmdVariablePlay (0x08)

CmdPresetSelect (0x02) and CmdVarIdPresetSelect (0x0a)

Command Code Note

CmdRenameId (0x1d)
CmdClosePort (0x21)
CmdSelectPort (0x22)
CmdRecordInit (0x23)
CmdPlayCue (0x24) PlayCue loads the clip using the clips defaultIn
and defaultOut points.
CmdCueWithData (0x25)
CmdDeleteId (0x26)
CmdPctToSignalFull (0x2b)
CmdRecordInitWithData (0x2c)
CmdDiskPrerollTime (0x43) When playing clip1, with clip2 immediately
following, the minimum preroll time needed to
ensure that all fields within clip2 are decoded is
2 sec.

10 Protocol Reference Guide

 CmdSenseRequest (0x03) and CmdVarIdSenseRequest (0x0b)

Command Code Notes

CmdOpenPort (0x01)
CmdNextIds (0x02) May exceed the 6 msec turn-around required by
the protocol. Ids are reported in order of
creation date.
CmdPortStatusRequest (0x05)
CmdPositionRequest (0x06) Position Request uses the player settings to
select the reporting mode among drop525,
nondrop525 and 625.
CmdActiveIdRequest (0x07)
CmdDeviceTypeRequest (0x08)
CmdSystemStatusRequest (0x10) The calculation of storage time uses the current
Player’s record bitrate. If a Player is not selected,
the calculation uses the record bitrate of the last
enabled VDCP input port. If there are no
VDCP input ports, then 50 Mbps is used. The
frames fields will always be zero. Drop/Non-
drop setting has no effect.
CmdIdList (0x11) May exceed the 6 msec turn-around required by
the protocol. Ids are reported in order of
creation date.
CmdIdSizeRequest (0x14) Id Size Request uses the clip frame rate to select
the reporting mode between drop525 and 625.
If a player is selected and the player mode is
nondrop525 and the clip is 29.97 Hz, then
nondrop525 is selected.
CmdIdRequest (0x16)
CmdIdsAddedList (0x18)
CmdIdsDeletedList (0x19)

Omneon, Inc. 11
 VDCP Extensions
The following information describes additional commands that have been implemented by Omneon
as a extension to the VDCP protocol. The additional commands are:
• 3X.70 / BX.70V_ID_INFO
• 2X.60 / AX.60OPEN_USER_INFO
• 2X.61CLOSE_USER_INFO
• 2X.62ADD_USER_INFO
• 3X.63GET USER INFO

3X.70 / BX.70V_ID_INFO
The V_ ID_INFO command will return the Start of Material and Duration information for the
specified file ID.

Command from Controller:

02 Byte 30 70 BITMAP ID NAME (8 bytes) Check

Count Sum

or
02 Byte B0 70 BITMAP ID ID NAME Check
Count LENGTH Sum

Where:
• ID LENGTH is a byte containing the size of the ID name (only used in the BX.70 command
format).
• ID NAME is the ASCII character of the ID (8 characters for the 3X.70 format and up to 32
characters for the variable length BX.70 format).
• BITMAP is a byte containing a bitmap that specifies which information items will be returned.
Only the ID Info 3 (Timecode) bit is used.
:
ID Info 8 ID Info 7 ID Info 6 ID Info 5 ID Info 4 ID Info 3 ID Info ID Info 1
(Not (Not (Not (Not (Not (Timecode) 2 (Not (Not
Used) Used) Used) Used) Used) Used) Used)

:
02 Byte CMD F0 BITMAP BYTE BYTE ----- BYTE Check
Count ECHO 1 2 8 Sum

12 Protocol Reference Guide

 02 Byte CMD F0 BITMAP Check Sum
Count ECHO

:Where:
• CMD ECHO matches the CMD1 byte of the command and will be either 30 or B0.
• BITMAP is a byte containing a bitmap that specifies which information items will be returned.
Only the ID Info 3 (Timecode) bit is used.
• BYTE 1 through to BYTE 8 return the following values:

ID Information 3 – Timecode Information

Byte MSB LSB Notes

Byte 1 FRAMES x 10 FRAMES x 1 Start of Material Timecode

Byte 2 SECONDS x 10 SECONDS x 1 Start of Material Timecode
Byte 3 MINUTES x 10 MINUTES x 1 Start of Material Timecode
Byte 4 HOURS x 10 HOURS x 1 Start of Material Timecode
Byte 5 FRAMES x 10 FRAMES x 1 Duration Timecode
Byte 6 SECONDS x 10 SECONDS x 1 Duration Timecode
Byte 7 MINUTES x 10 MINUTES x 1 Duration Timecode
Byte 8 HOURS x 10 HOURS x 1 Duration Timecode

Timecode values are returned in BCD format. No flags bits are set (such as the Drop Frame flag).
If the ID info 3 bit is set in the BITMAP and if the specified file cannot be found, then:
• The format of the reply will not change.
• The BITMAP will still be the same as the BITMAP byte in the command.
• The values of BYTE 1 through BYTE 8 will be 0.
• The IdNotFound bit is set in the port error status.

Omneon, Inc. 13
 VDCP User Data Extensions
User Data will be stored in VALUE blocks within the file. Each VALUE block will be addressed by a
KEYWORD name.
The KEYWORD must be an ASCII string; it has a variable length of up to 32 bytes. It does not need
to have a terminating 0 since the command format includes a length value. A value of 0x00 is not
allowed within the KEYWORD; all other values are allowed.
The VALUE block can hold arbitrary binary data; it has a variable length of up to 128 bytes.

User Data Commands

The following commands are available:
• 2X.60 / AX.60OPEN_USER_INFO
• 2X.61CLOSE_USER_INFO
• 2X.62ADD_USER_INFO
• 3X.63GET USER INFO

2X.60 / AX.60OPEN_USER_INFO
The OPEN_USER_INFO command will open the specified file ID for reading or writing User Data.
If any file ID is already open for User Data by the communications port it will be closed.

Command from Controller:

02 BC 20 60 MODE ID NAME (8 bytes) CS

or
02 BC A0 60 MODE ID ID CS
Length NAME

Where:
• MODE is 1 for read access, 2 for write access, 3 for read/write access.
• ID LENGTH is the size of the ID name (only used for the AX.60 command format).
• ID NAME is the ASCII character of the ID; it is either a fixed length of 8 bytes or a variable
length.

14 Protocol Reference Guide

 If the specified file ID cannot be found, the CueOrOperationFailed bit is set in the port error status.

Return from Controlled Device:

ACK

2X.61CLOSE_USER_INFO
The CLOSE_USER_INFO command will close the file ID currently open for User Data.

Command from Controller:

02 02 20 61 CS

Return from Controlled Device:

ACK

2X.62ADD_USER_INFO
The ADD_USER_INFO command will add or replace the VALUE of the specified KEYWORD in
the currently open file.

Command from Controller:

02 BC 20 62 KEYWORD KEYWORD VALUE VALUE CS

LENGTH LENGTH

Where:
• KEYWORD LENGTH is a single byte containing the size of the KEYWORD.
• KEYWORD is a variable number of bytes containing the ASCII characters of the keyword (max.
32 characters). A value of 0x00 is not allowed within KEYWORD; any other value is allowed.
KEYWORD does not need to have a terminator.
• VALUE LENGTH is a single byte containing the size of the VALUE.
• VALUE is a variable number of bytes containing the User Data (max. 128 bytes).

NOTE: An existing KEYWORD / VALUE set can be removed from the specified file by using this command
that has the desired KEYWORD, has a VALUE LENGTH of 0, and has no VALUE bytes.

Omneon, Inc. 15
 Return from Controlled Device:

ACK

3X.63GET USER INFO

The GET_USER_INFO command will return the VALUE from the specified KEYWORD in the
currently open file. The keyword supplied with the command must be an exact match for an existing
keyword that is stored within the specified file. The match is case sensitive. Another
GET_USER_INFO command should not be started until after the first has completed.

Command from Controller:

02 BC 30 63 KEYWORD KEYWORD CS
LENGTH

Where:
• KEYWORD LENGTH is a byte containing the size of the KEYWORD.
• KEYWORD is a variable number of bytes containing the ASCII characters of the keyword (max.
32 characters). A value of 0x00 is not allowed within KEYWORD; any other value is allowed.
KEYWORD does not need to have a terminator.

Return from Controlled Device:

02 BC 30 E3 VALUE VALUE CS
LENGTH

Where:
• VALUE LENGTH is a byte containing the size of the VALUE.
• VALUE is a variable number of bytes containing the User Data. (max. 128 bytes). If the keyword
can’t be found in the specified file, then:
• The VALUE LENGTH byte will be 0.
• There will be no VALUE bytes in the reply.
• The SystemError bit will be set in the port error status.

16 Protocol Reference Guide

 VDCP Enhancements For Back-to-Back Play of Short Clips
Standard VDCP makes it difficult for video servers to play back-to-back short clips. Normally, each
successive ID to be played is cued with a cue command and then played with a play command. These
cue and play commands alternate because:
• A cued ID does not play until a play command is received.
• Cueing another ID while an ID is already cued un-cues the previously cued ID and cues the new
ID.
• At most one ID is playing while another ID is cued.
This procedure only allows for the server to know about the currently playing ID and the next ID to
play. If the next ID to play has a short duration, the server does not get much time to process the ID
after that.
Adding a new VDCP command enables a disk server to play a sequence of short clips. The command
is scheduleID. This command essentially schedules an ID to play immediately following the current
ID.
The scheduleID command requires one or three arguments: ID or ID, start position, and duration. Its
response is ACK/NACK. The portStatus command must be used to determine if the scheduleID
command completed successfully. The port will indicate cueInit in the port status while the
scheduleID command is processing. An error while processing the scheduleID command will set one
of the error bits in the port status.
This addition of this command is sufficient to play sequences of short clips. However, it adds to the
complexity of the current state of a play port. Retrieving additional state information may be desirable
and is achieved with a modification to the existing activeIdRequest command.

20.78/A0.78: scheduleID
The scheduleID command is used in conjunction with the standard playCue (or cueWithData) and the
play commands. If the VDCP server port (the port) has an ID cued, then the scheduleID command
schedules an ID to play immediately following the play of the cued ID. For example, let’s assume ID
xx1 is playing and ID xx2 is cued. A scheduleID command is issued for ID xx3. Play will pause at the
end of ID xx1 if a play command is not issued before the end of ID xx1. A play command is now
issued which causes ID xx2 to start playing. At this point, the port is in a play state and not cued.
Issuing another play command would result in a cueNotDone error. ID xx2 plays to the end and ID
xx3 automatically follows it. Play will pause at the end of ID xx3 if no further commands are issued.
The scheduleID command can also be used when the port is in a play and not cued state. In this state,
a scheduleID command schedules the ID to play immediately following the currently playing ID. For
example, let’s assume ID xx1 is playing and no ID is cued. A scheduleID command is issued for ID
xx2. This schedules ID xx2 to play immediately following ID xx1. Play will pause at the end of ID xx2
if no further commands are issued.
Multiple scheduleID commands can be issued in both the play and cued state. The successive
commands simply add to the scheduled list of IDs to play. For example, IDs xx1 through xx5 could be
played using the following command sequence: playCue xx1, play, scheduleID xx2, scheduleID xx3,
scheduleID xx4, scheduleID xx5. Play would start after the play command and before the scheduleID
xx2 command. The following command sequence would also play all five IDs: playCue xx1,

Omneon, Inc. 17
 scheduleID xx2, scheduleID xx3, play, scheduleIDxx4, scheduleID xx5. The difference is that the
latter sequence tells the disk server more of what is to play before play starts.

NOTE: Mixing the usage of the scheduleID command while the port is cued or not cued is also allowed.

Another command sequence to play the above IDs would be: playCue xx1, scheduleID xx2, play,
scheduleID xx3, playCue xx4, scheduleID xx5, play. The first play command will cause IDs xx1, xx2,
and xx3 to play. The second play command would cause ID’s xx4 and xx5 to play.
The playCue and cueWithData commands still work as usual in the sense that cueing an ID un-cues a
currently cued ID. This un-cueing action also applies to any IDs that have been scheduled since the
last playCue command. For example, let’s assume the following command sequence has been issued:
playCue xx1, play, playCue xx2, scheduleID xx3, and scheduleID xx4. The port is playing ID xx1, ID
xx2 is cued, and IDs xx3 and xx4 will play immediately following the play of ID xx2. Now a playCue
for ID xx5 is issued. This will un-cue ID xx2, unscheduled ID’s xx3 and xx4, and cue ID xx5. A play
command now will cause the ID xx5 to play.
A scheduleID command can only be issued while in the play or cued state. The cueInit bit in the port
status is set upon receiving a valid scheduleID command. The cueInit bit is cleared upon completion
of the scheduleID command. Additionally, a port status error bit may be set that would indicate a
problem occurred. If an error bit is set, the ID is not scheduled. Processing a scheduleID command
may set the port busy bit. Processing a scheduleID command does not block the processing of
immediate commands.
Note the following usage:
• The cueInit bit is used to indicate ID cueing. It is set when processing a scheduleID, playCue or
cueWithData command. The bit is cleared when all ID cueing is complete. These commands may
be overlapped in which case the cueInit bit stays set until all cueing is complete. However, it is not
recommended to overlap these commands because there are no error conditions to indicate
which command failed. Coherent use of the error bits requires waiting for the cueInit bit to clear
before issuing any of these commands.
• The cueInitDone bit is only set when a playCue or cueWithData command successfully cues an
ID. It is generally cleared by the play command, however these commands also clear it: stop, step,
continue, jog, variablePlay, and record.
Any one of several port status error bits may be set by the scheduleID command. In all cases the error
is unrecoverable and the command is ignored. Following is a list of the error bits that may be set:
• portNotActive - Issuing the command while not playing or cued.
• wrongPortType - Issuing the command to a recording port.
• cmdWhileBusy - Issuing the command while the port is busy.
• illegalValue - Malformed ID, start or duration values.
• idNotFound – Failed to open ID.
• cueOrOperationFailed - An internal error.
• scheduleFull (extended ps3, 5th byte, 6th bit) – Too many IDs scheduled.

18 Protocol Reference Guide

 The timing requirements for a scheduleID command are disk server dependent. The disk server
manufacturer should be able to specify something like the minimum time a scheduleID command
should be issued before the ID is expected to play. For example, an Omneon Server requires the
scheduleID command roughly three seconds before the ID is to play.

Command (ID only format):

02 BC 20/A0 78 ID CS

Command (ID plus start and duration format):

02 BC 20/A0 78 ID SOM DUR CS

Where:
• ID is the eight-byte (20 case) or variable length (A0 case) ASCII encoded ID.
• SOM is the four-byte BCD encoded start position in frames, seconds, minutes, and hours.
• DUR is the four-byte BCD encoded duration in frames, seconds, minutes, and hours.

Response:

ACK

30.07 activeIdRequest
ActiveIdRequest is an existing command that takes no arguments. The behavior is modified with the
addition of a single argument. Without the argument, it behaves as normal. The argument is a
sequence number referring to an ID that is playing, scheduled, or cued. A sequence number of zero
refers to the currently playing ID (or cued ID if not currently playing), a value of one refers to the next
ID to play, a value of two to the ID after that and so on. A sequence number greater than or equal to
the number of active IDs, returns a shortened response consisting only of the port state.
The response to an activeIdRequest command with the optional index argument contains the same
information as a normal activeIdRequest response plus three more items. These additional items are:
start position, duration, and state. The start position and duration items are the respective values
specified when the ID was scheduled or cued. The state item describes the ID’s scheduled versus cued
state. The state item may take on the values described in the following table.

State Value Definition

0 Currently playing (only one ID may have this value)

1 Scheduled to play (many IDs may have this value)
2 Cued (only one ID may have this value)
3 Scheduled after cue (many IDs may have this value)

Omneon, Inc. 19
 Command:

02 03 30/BO 07 SN CS

Where:
• SN is the sequence number

Response:

02 BC 30/BO 87 PS ID SOM DUR ST CS

Where:
• PS is the one-byte port state, 0 for inactive, 1 for active
• ID is the eight-byte or variable length ID
• SOM is the four-byte BCD encoded start position in frames, seconds, minutes, and hours.
• DUR is the four-byte BCD encoded duration in frames, seconds, minutes, and hours.
• ST is the one-byte ID state

VDCP Enhancements for Improved Media Status Reporting

Starting with Release 5.4, enhancements are in place in the Spectrum software which improves the
accuracy of media status reporting via VDCP on Spectrum and MediaDeck Servers. The
enhancements improve the robustness of the video server by improving the accuracy of the
information provided to automation clients when querying media state and cueing material for
playout.
Prior to Release 5.4, Omneon's implementation of VDCP only reported on the state of the clip
metadata (“movie”) file; and not if other parts of the clip – video, audio, and VBI essence – were
missing. In Release 5.4 and later releases, the behavior and response to the VDCP ID Request
command and the behavior of the VDCP Play Cue and Play Cue With Data commands has changed
to support the reporting of these missing essence files.

Changes to ID Request (3X.16, BX.16)

Previously, the implementation of this command returned IN DISK if the clip metadata file existed,
and NOT READY TO PLAY only if the clip was currently recording but had not recorded enough
(based on information in the clip metadata) to start play-behind safely. Missing essence files did not
alter the return value.
In Release 5.4 and later releases, the return value reports NOT READY TO PLAY if any of the
essence files described in the clip metadata file are missing, or are of zero length. VDCP requires that
the server responds to the client within 10ms; if the system is unable to determine, completely, the clip
state in this time, QUERY PENDING is set and returned to the client. This causes the client to ask

20 Protocol Reference Guide

 again for status to complete the request. The timing of these requests from the client prevents race
conditions from occurring.
The system’s first response to a new ID Request is QUERY PENDING. Further ID Request
commands for the same ID will continue to respond QUERY PENDING for possibly several
seconds. Once the states of all essence files for the ID are known, the response will clear QUERY
PENDING and will indicate correct information (IN DISK, NOT READY TO PLAY, etc) as of that
time.
If the server cannot immediately answer an ID Request then it will return QUERY PENDING and
initiate an internal request for the information. Subsequent ID Requests for the same ID will
eventually return a correct answer. An ID request for a different ID will also return QUERY
PENDING but will not initiate an internal request. A subsequent request for this ID when an internal
request is not already active generates an internal request. This serializes the internal work needed to
satisfy ID Requests, in order to keep system load reasonable.
Automation systems must ensure that they follow up on a QUERY PENDING response in a timely
manner, in order to prevent misleading or stale status. Thus, if automation gets a QUERY PENDING
response it must ask again for the same ID within 4 seconds to get a non QUERY PENDING
answer. If automation takes longer than 4 seconds to follow up, the internal process starts over for
that ID. The server flushes the information once a non QUERY PENDING response is sent. This
means another request for the same ID returns QUERY PENDING and the process starts over.

Changes to Play Cue (2X.24, AX.24) and Play Cue With Data (2X.25, AX.25)
Previously, the implementation of these commands set CUE DONE if the clip metadata file existed.
(The state of CUE DONE was sensed using Port Status.) Missing essence files were undetected by the
client and resulted in missing tracks playing black or silent. There was no mechanism available for the
client to determine that tracks were missing from a playout.
In Release 5.4 and later releases, CUE DONE gets set only if all of the essence files described in the
clip metadata file are present and have lengths greater than zero. Note that this does not guarantee that
playout of all tracks will occur; the files could be corrupt, short, or otherwise unusable and this cannot
be determined until play starts. As a result of this change, the time between the client’s issuance of the
Cue command, and achieving CUE DONE state may be longer than previously.

NOTE: If you have automation client(s) that require this functionality, be prepared to handle delays of several
seconds or more between Cue and CUE DONE.

About Compatibility Switches

The changes described above can be controlled by two compatibility switches which are user-
configurable. The default states for the switches should be the behavior prior to Release 5.4. One
switch should govern the behavior of ID Request, and the other should control Play Cue and Play Cue
With Data. Ensure that the switches can be set independently.

IMPORTANT: If you wish to avail of the VDCP enhancements described in this section, be prepared to set
the switches as described above, and test and change automation system timing if indicated.

Omneon, Inc. 21
 Sony Serial Protocol
Support of the Sony serial protocol facilitates the interconnection of MediaPorts to third party devices
such as automation, archiving, and editing systems. Insert and assemble edit commands are not
supported. Sony serial protocol functions include:
• Timecode Query — allows the timecode information to be registered by the editing application
and lets the editing application issue a timecode query to get information about the current clip
position (or timecode).
• Play — starts playing clips at 1.0x play speed (normal speed), in the forward direction.
• Stop — stops playback or recording at the current frame. The MediaPort switches to E-E.
• Pause — pauses a playing clip (even those in fast forward, record or rewind) and displays the
current frame.
• Fast Forward — (full speed) moves instantly from the current mode to full fast forward (the clip
shuttles forward at full speed and displays picture in shuttle).
• Rewind — (full speed) instantly changes from the current mode to full rewind (the clip rewinds
at full speed and displays picture in shuttle).
• Jog Forward — (one frame) advances by one frame and then pauses.
• Jog Reverse — (one frame) backs up by one frame and then pauses.
• Vari-Shuttle — lets users incrementally change clip shuttle mode from full rewind to full fast
forward speed.
• Record — starts recording into the current clip (which must have been created by the application
through the API or through use of the Avid protocol extensions). All channels of video and audio
will be recorded.
• Eject — removes (ejects) the clip from the Player and allows users to load a new clip from
ClipTool, using the API, or using the Avid protocol extensions.
• Mark In-point — sets a user defined (marked) timecode value within the playback clip, usually
the frame at which the user wants to begin digitizing. Clicking Mark In a second time (on the
editing system) overwrites the old mark with a new one.
• Mark Out-point — sets a user defined (marked) timecode value within the playback clip, usually
the frame at which the user wants to stop digitizing. Clicking Mark Out a second time (on the
editing system) overwrites the old mark with a new one.
• Go To Mark In — cues the clip to the marked in-point. When the clip reaches the specified
frame, it enters Pause mode.
• Go To Mark Out — cues the clip to the marked out-point. When the clip reaches the specified
frame, it enters Pause mode.
• Go To a Supplied Timecode — cues the clip to a specified timecode. When the clip reaches the
specified timecode, the clip enters Pause mode.
• Data Sense and Current Time Sense commands — for control and emulation purposes,
provides the capability for retrieving all manner of status bits (not just timecode).

22 Protocol Reference Guide

 • Avid Extended protocol — allows (from within the editing application) the listing and loading
of clips currently in the file system as well as creation and naming of new clips.

Setting Preroll Timing Parameters for Automation Systems

Controlling Omneon MediaDirector
To set preroll values in an automation system controlling a MediaDirector, refer to the automation
system documentation. We recommend that you set the values for "disk preroll", "frames to send play
early", and "frames to send record early" to 2 seconds.

Omneon, Inc. 23
24 Protocol Reference Guide
 CHAPTER 2
FTP Server Implementation

This section provides information regarding File Transfer Protocol (FTP) server implementation on
Omneon MediaDirectors as follows:
• Commands Definitions
• Transferring Clips Between Omneon Spectrum Systems
• Notes on Parsing QuickTime Files
• FTP Transfer While Recording

NOTE: The FTP server is an independent implementation, created directly from the specification (RFC 959).
The Omneon FTP server follows the specification, RFC 959, which is an open standard available at:
http://www.ietf.org/rfc/rfc959.txt. This chapter does not duplicate the specification, but notes instead where
the Omneon FTP server adheres to or diverges from the specification.

Commands Definitions
This section lists the FTP commands in an Omneon Spectrum System in the following categories:
• Access Control Commands
• Transfer Parameter Commands
• FTP Service Commands
• SITE Commands

NOTE: For completeness, commands specified in RFC 959 but not implemented by Omneon are identified
as “not implemented.”

Omneon Spectrum™ System Release 5.4 25

 Access Control Commands
Table 5 identifies the Access Control Commands used in an Omneon Spectrum System.

Table 5. Access Control Commands

Command(s) Support

USER Implemented as per RFC 959.

PASS

CDW, CDUP, XCWD

ACCT, SMNT, REIN Not implemented.

QUIT Implemented as per RFC 959.

USER
Implemented as per RFC 959. If domain level security in use, returns:
331, "User name "mrftp" in domain "studio", need password."

Otherwise returns:
230, "Welcome to Director. There are currently "3"users."

PASS
Implemented as per RFC 959. On success returns:
230, "User" mrftp" logged in, proceed..."

Returns these errors:

530, "User" mrftp"failed to log in, try again!"

CDW, CDUP, XCWD

Implemented as per RFC 959. On success returns:
250, "Current directory is now: "/fs/mydirectory" "

Returns these errors:

550, "Directory invalid"
553, "Absolute name too long"

ACCT, SMNT, REIN

Not implemented. Returns these errors:
500, "Command unrecognized"

26 Protocol Reference Guide

 QUIT
Implemented as per RFC 959. On success returns:
221, "Be seeing you"

Limitations for FTP Sessions

Table 6 shows the maximum number of FTP sessions according to MediaDirector and session type.

Table 6. FTP Session Limitations

MCP 2102, 2102B

MCP 2101 MediaDirectors and
Session Types MediaDirector MediaDecks

max. # store sessions 8 12

max. # retrieve sessions 10 12
max. # store/retrieve sessions 18 16
max. # login sessions 20 28

Transfer Parameter Commands

Table 7 identifies the Transfer Parameter Commands used in an Omneon Spectrum System.
Table 7. Transfer Parameter Commands

Command Support

PORT Implemented as per RFC 959.

PASV Implemented as per RFC 959.
TYPE Implemented as per RFC 959. Types A and I are
supported.
STRU Implemented as per RFC 959. File structure is supported.
MODE Implemented as per RFC 959. Stream Mode is
supported.

PORT
Implemented as per RFC 959. On success returns:
200, "PORT command successful."

Returns these errors:

501, "Failure on PORT command"

Omneon, Inc. 27
 PASV
Implemented as per RFC 959. On success returns:
227, "Entering Passive Mode (10,35,74,26,4,20)".

Returns these errors:

425, "Cannot get listening connection",
425, "Cannot bind listening connection",
425, "Cannot listen connection"

TYPE
Implemented as per RFC 959. Types A and I are supported. On success returns:
200, "Using I for file transfers"

Returns these errors:

504, "Unimplemented parameter for TYPE, "C"",

STRU
Implemented as per RFC 959. File structure is supported. On success returns
200, "Using file structure".

Returns these errors:

504, "Unimplemented parameter for STRU, "F"",

MODE
Implemented as per RFC 959. Stream mode is supported. On success returns:
200, "Using stream mode"

Returns these errors:

504, "Unimplemented parameter for MODE, "T"",

FTP Service Commands

Table 8 identifies the FTP Service Commands used in an Omneon Spectrum System.
Table 8. FTP Service Commands

Command Support

RETR <file>, STOR Implemented as per RFC 959.

<file>
STOU, APPE, ALLO Not implemented.
REST Implemented as per RFC 959.

28 Protocol Reference Guide

 Table 8. FTP Service Commands

RNFR <file>, RNTO Implemented as per RFC 959.

<file>,
ABOR
DELE
RMD <dir>, XRMD
MKD <dir>, XMKD
PWD, XPWD
LIST, NLST
SYST
STAT Not implemented.
HELP Implemented as per RFC 959.
NOOP
SIZE
MDTM

RETR <file>, STOR <file>

Implemented as per RFC 959. On success returns:
226, "File transfer completed."

Returns these errors:

553, "Absolute name too long"
550, "File "myfile"" is a directory",
550, "Could not open file "myfile"",
550, "Could not create file "myfile"",
550, "Only binary mode transfers allowed."
550, "Could not start data transfer task."
425, "Can't open data connection."
426, "Connection closed; transfer aborted."
452, "Requested action not taken. Insufficient storage space in system."
451, "Requested action aborted: local error in processing."
226, "Abort successfully processed."

Omneon, Inc. 29
 Additional information about STOR <File>:

Starting with Spectrum Release 4.7 SR4, support is available for an overwrite mode for STOR <file>.
By default, STOR <file> does not overwrite files. To switch to overwrite mode, in a Telnet session
enter:
>ftp overwrite [1:0]

Enter 1 to turn ON overwriting during file transmission. This is applied only to the specific
MediaDirector host to which you connected. You will need to repeat the command for each additional
host, if overwrite mode is required. The overwrite mode is N-V RAM and as such will survive a
reboot.

STOU, APPE, ALLO

Not implemented. Returns this error:
500, "Command unrecognized."

REST
Implemented as per RFC 959. Returns this error:
501, "Failure on REST command"

Upon success returns:

350, "Restarting at ___ bytes" "Send RETR to initiate"

RNFR <file>, RNTO <file>

Implemented as per RFC 959. On success returns:
350, "Source file OK, waiting for RNTO"
250, "File rename successful"

Returns these errors:

503, "RNTO does not follow RNFR"
553, "Absolute name too long"
550, "Destination file "myfile" exists"
550, "File rename failed, "ox abcd", error”
550, "Source file "myfile" does not exist"

ABOR
Implemented as per RFC 959. On success returns:
226, "Abort successfully processed"

30 Protocol Reference Guide

 DELE
Implemented as per RFC 959. On success returns:
250, "File successfully deleted."

Returns these errors:

553, "Absolute name too long"
450, "Failure deleting file."

RMD <dir>, XRMD

Implemented as per RFC 959. On success returns:
257, "Directory "/fs/mydirectory" removed"

Returns these errors:

553, "Absolute name too long"
550, "Failure removing directory "/fs/mydirectory"",

MKD <dir>, XMKD

Implemented as per RFC 959. On success returns:
257, "Directory "/fs/mydirectory" created",

Returns these errors:

553, "Absolute name too long"
550, "Failure creating directory "/fs/mydirectory""

PWD, XPWD
Implemented as per RFC 959. On success returns:
257, "Current directory is: "/fs/mydirectory"",

LIST, NLST
Implemented as per RFC 959 on a separate connection. On success returns:
<directory listing>
226, "List succeeded."

Omneon, Inc. 31
 Returns these errors:
553, "Absolute name too long"
550, "Name not found."
550, "Could not access name."
550, "Could not start data transfer task."
451, "Failure writing on socket."
451, "No memory."
425, "Can't open data connection."
426, "Connection closed; transfer aborted."
226, "Abort successfully processed."

SYST
Implemented as per RFC 959. On success returns:
213, "Omneon File System - stylelist format"

STAT
Not implemented: Returns these errors:
211, "Sorry, no status yet."

HELP
Implemented as per RFC 959. On success returns:
214, "Recognized commands:" <A list of commands>
214, "Commands marked with a * are not implemented."

Returns these errors:

501, "No specific help for command "Accio""

NOOP
Implemented as per RFC 959. On success returns:
200, "No operation completed okay."

SIZE
Implemented as per RFC 959. On success returns:
213 <file size>

Returns these errors:

553, "Absolute name too long"
550, "Could not open "/fs/mydirectory/myfile""

32 Protocol Reference Guide

 MDTM
Implemented as per RFC 3659. On success returns:
213 <file modify time>

Returns these errors:

553, "Absolute name too long"
550, "Could not open "/fs/mydirectory/myfile""

SITE Commands
Table 9 lists the Site Commands used in an Omneon Spectrum System.

Table 9. Site Commands

Command Support

HELP SITE Implemented as per RFC 959.

SITE LISTFMT

SITE STRIPE <type>

SITE DELE <clip>

SITE LIST <dir/clip>

SITE RNFR <clip>,

SITE RNTO<clip>

SITE TIMEOUT <min>

SITE RBW

HELP SITE
Implemented as per RFC 959. On success returns:
214, "Recognized SITE commands:" <A list of commands>
214, ""

SITE LISTFMT
This command toggles the directory listing format returned in response to a LIST command. Each
change affects the session making the change. Other sessions are not affected.
The default is UNIX style directory listing.

Omneon, Inc. 33
 On success returns:
200, "Now using Unix list format"
200, "Now not using Unix list format"

The Omneon MediaDirector’s file system supports three kinds of file stripe:
• Large stripe: Optimized for large bandwidth media types, for example video
• Small stripe: Optimized for smaller bandwidth media types, for example audio
• Blocked: Optimized for random access data

File Striping and Associated Commands

A file’s stripe type is chosen when the file is created. FTP can be instructed by the SITE STRIPE
command to select a particular stripe type when next creating a new file using the STOR command.
Each change affects the session (login instance) making the change but other sessions are not affected.
With no explicit STRIPE instruction, the FTP server selects the file stripe type based on the file name
suffix.

SITE STRIPE <type>

The type parameter can have a value of LARGE, SMALL, or NO, or not be present. With no type
parameter present, the current stripe type is returned.
On success returns:
200, "Current creation is NO_STRIPE"
200, "Current creation is now LARGE_STRIPE"

Returns these errors:

501, "Unknown argument to SITE STRIPE, "SUPER-SIZE""

Clip Manipulation and Associated Commands

The Omneon MediaDirector creates and uses video clips which consist of a QuickTime or MXF
wrapper file and media files, including video, audio, and VBI. The MediaDirector will use video clips
which are flattened into a single file and have internal media. Wrapper files are typically stored in the
clip.dir and media files are typically stored in the sub directory clip.dir/media.dir. The names of the
media files and their directories are held in the QuickTime .mov file. When a wrapper file is retrieved,
from the Omneon FTP server, for instance, the media file name and directory information is in the
wrapper file and remains unchanged. When a wrapper file is stored to the Omneon FTP server, as
part of restoring a video clip from tape, for instance, the media files should be stored to the FTP
server maintaining their names and directories. A problem occurs if there is a name conflict between
the wrapper or one of the incoming media files and an existing media file on the server.
The following FTP SITE delete and rename commands allow clips to be transferred from an FTP
client, for example an archive system, to the Omneon MediaDirector such that any media file name
conflicts in the server's working directory will be resolved by the server. The process requires
transferring the clips from the client to a temporary directory on the server, and then using the SITE
rename-from and SITE rename-to command sequence to move the clip to the desired working

34 Protocol Reference Guide

 directory. The Omneon FTP server identifies any conflicts in media files, and renames the incoming
files to avoid name conflicts with other existing media files. It modifies the wrapper file to
accommodate the name changes, and it maintains the directory structure expressed in the wrapper file.
In addition, a clip delete command is added.
The new SITE commands provide delete and rename functions on whole clips. They should only be
used on a QuickTime, or MXF wrapper file (having the .mov suffix), and will read that file to
determine which media files (eg. .mpg, .aiff) are entailed. These clip commands reuse the syntax of the
existing ftp file commands for delete file and rename files.

SITE LIST <dir/clip>

The List command creates a file (.lst) listing all media files in the clip whose QuickTime wrapper file is
<dir/clip>. The list file is created in the same directory <dir>. The name of the list file is the name
of the QuickTime file <clip> with the suffix (.lst) added. If a list file already exists with that name, it is
overwritten with the new list file. You can then use FTP to copy the list file to local storage to examine
its contents, and delete the original on the Omneon Spectrum System.
Following is a trace of the control connection of an FTP session that uses the SITE LIST command.
<220
>USER mrftp
<230 Welcome. There are currently 1 users.
>SYST
<213 Omneon File System - Unix style list format
>CWD fs/clip.dir
<250 Current directory is now: "/fs/clip.dir"
>PORT 10,1,1,108,18,245
<200 PORT command successful
>LIST
<150 Opening data connection.
<226 List succeeded.
>SITE LIST mpeg25.mov
<350 Listmedia OK, ready for retrieving
>TYPE I
<200 Using binary for file transfers
>PORT 10,1,1,108,18,249
<200 PORT command successful
>RETR mpeg25.mov.lst
<150 Opening data connection.
<226 File transfer completed.
>QUIT
<221 Be seeing you.

Omneon, Inc. 35
 The contents of the list file can now be printed.
> more mpeg25.mov.lst
/fs/clip.dir/mpeg25.mov
/fs/clip.dir/media.dir/mpeg25.m2v
/fs/clip.dir/media.dir/mpeg25.aiff

Returns these errors:

501 "Missing argument"
553 "Absolute name too long"
550 "Source clip does not exist"
450 "Failure finding source clip"

SITE DELE <clip>

The delete clip command will delete an entire clip, including the QuickTime wrapper file, and the
media files pointed to by the wrapper file.

SITE RNFR <clip>, SITE RNTO<clip>

The rename-from clip command and the rename-to clip command are both required. These
commands must appear in sequence, first the rename-from command, then the rename-to command
(as with existing rename). The clip name can include a complete pathname, or it can state only the file
name, leaving the full path left unstated, but implied to be the CWD path. All directories in both the
rename-from and the rename-to path must exist.

Server Timeouts and Associated Commands

The Omneon FTP server will conserve networking resources by timing out a connection if it fails to
make progress, or stalls. Three cases exist. First a control connection goes silent, and no commands
are sent to the FTP server. Second, a data transfer in either direction (store or retrieve) stalls because
of the client, and the FTP server cannot complete the transfer. Third, a data connection expected by
the FTP server (PASV) never arrives from the client. In all three cases, the default timeout is the same,
and can be adjusted using the SITE timeout command.

SITE TIMEOUT <min>

The value of <min> is, first, the duration in minutes that the server will wait for a new command after
a data transfer is completed, and second, the duration that the server will maintain a data connection
while the transfer is stalled, and third, the duration the FTP server will hold a passive port open.
Valid values for the <min> parameter are from 1 minute up to 40 minutes. The default is 5 minutes. If
the timeout command is sent by itself without any minute parameter the current timeout setting will
be returned. The timeout value is local to the session setting it but other sessions are not affected.
Within a session, every subsequent file transfer will use the new setting, either until the setting is
changed, or until the session ends when the control connection terminates. Each new login to the
Omneon server starts with the default setting.

36 Protocol Reference Guide

 SITE RBW
This command gives the current setting for the FTP Transfer While Recording (Read Behind Write)
function.
Returns
200, “Current read behind write setting: ON”

when the setting is on.

Returns
200, “Current read behind write setting: OFF”SITE

when the setting is off.

Enter:
SITE RBW 0

to turn the setting off.

Enter
SITE RBW 1

to turn the setting on (for that connection only).

NOTE: The default for FTP Transfer While Record is ON.

Transferring Clips Between Omneon Spectrum Systems

There are a variety of methods you can use to transfer clips from one Omneon MediaDirector to
another. This section provides an example of using FTP to transfer a clip directly between
MediaDirectors when all these conditions are met:
• The wrapper file format is QuickTime.
• The clip is an MPEG clip with a separate audio file(s).
Refer to Transferring Clips Under Different Conditions for suggestions on how to implement the
transfer when conditions differ to those listed above.
For the purpose of this example, the following information is true:
• "fred.mov" is a QuickTime clip with media files “fred.mpg” and “fred.aiff ”.
• The source MediaDirector has an IP address of: 10.35.74.26.
• The destination MediaDirector has an IP address of: 10.35.74.67.
• The source and destination directory for the clip is /FS1/clip.dir.
• To delete a clip: The Omneon API command OmPlrClipDelete, OmPlrOpen, and OmPlrClose
are used.
• To get a list of clips: The Omneon API commands OmPlrClipGetFirst and OmPlrClipGetNext
are used to enumerate a list of available clips. OmPlrOpen and OmPlrClose are also used.

Omneon, Inc. 37
 NOTE: When transferring between MediaDirectors which are distant from each other, a VPN or other private
network is necessary. The VPN is required so that the Omneon API commands can be used; these
commands utilize an RPC protocol. The VPN is also required so that the server ftp ports are not directly
exposed to the Internet.

To transfer a Clip:

1. Use the OmneonDriver to obtain the necessary information as follows:

a. Query your clip library database to obtain the IP and directory for source device.
b. Query your clip library database to obtain the IP and directory for destination device
c. Obtain the clip name. Add a “.mov” extension if necessary. Combine with source directory.
2. Obtain media names using omPlrLib.dll as follows:
a. Establish a connection to the source MediaDirector using OmPlrOpen and the source
MediaDirector IP address.
b. Confirm that the clip exists using OmPlrClipExists()
c. Query for media names using OmPlrClipGetMediaNames(). Repeat the query as necessary.
d. Close the connection using OmPlrClose.
3. Setup a telnet session as follows:
a. To the source MediaDirector:
>telnet 10.35.74.26. 21
### port 21 is the FTP port
b. To the destination MediaDirector:
>telnet 10.35.74.67. 21
### port 21 is the FTP port

4. Setup a MediaDirector to MediaDirector FTP transfer for the first of the media files. Refer to
“RFC 959” and “RFC 765” for definitions of these commands.
a. Send the following commands to the source MediaDirector:
>PASV
### expect a response of the form "227 Entering Passive Mode
10,35,74,26,4,20"
### which means it is waiting on port 4,20 (number varies) for a response.
### Your app has to parse out the port number for use below.
>TYPE I
### response "200 Using binary for file transfers"
>RETR /FS0/clip.dir/media.dir/fred.mpg
### retrieve off local disk; use full source path

38 Protocol Reference Guide

 b. Send the following commands to the destination MediaDirector:
>PORT 10,35,74,26,4,20
### see response to PASV command for specific numbers to use here
>TYPE I
### response "200 Using binary for file transfers"
>STOR /FS0/clip.dir/media.dir/fred.mpg
### stores onto local disk; use full destination path & name of choice
This is an alternate method with a passive destination:
a. Send the following commands to the destination MediaDirector:
>PASV
### expect a response of the form "227 Entering Passive Mode
10,35,74,67,4,20"
### Your app has to parse out the port number for use below.
>TYPE I
### response "200 Using binary for file transfers"
>STOR /FS0/clip.dir/media.dir/fred.mpg
### stores onto local disk; use full destination path & name of choice
b. Send the following commands to the source MediaDirector:
>PORT 10,35,74,37,4,20
### see response to PASV command for specific numbers to use here
>TYPE I
### response "200 Using binary for file transfers"
>RETR /FS0/clip.dir/media.dir/fred.mpg
### retrieve off local disk; use full source path

5. Repeat the following steps for each of the remaining media files:
a. Send the following commands to the source MediaDirector:
>PASV
### expect a response of the form "227 Entering Passive Mode
10,35,74,26,4,20"
### Your app has to parse out the port number for use below.
>RETR /FS0/clip.dir/media.dir/fred.aiff
b. Send the following commands to the destination MediaDirector:
>PORT 10,35,74,26,4,20
### using port number parsed from PASV response of sending MediaStore
>STOR /FS0/clip.dir/media.dir/fred.aiff

This is an alternate method with a passive destination:

Omneon, Inc. 39
 a. Send the following commands to the destination MediaDirector:
>PASV
### expect a response of the form "227 Entering Passive Mode
10,35,74,67,4,20"
### Your app has to parse out the port number for use below.
>TYPE I
### response "200 Using binary for file transfers"
>STOR /FS0/clip.dir/media.dir/fred.aiff
b. Send the following commands to the source MediaDirector:
>PORT 10,35,74,37,4,20
### see response to PASV command for specific numbers to use here
>TYPE I
### response "200 Using binary for file transfers"
>RETR /FS0/clip.dir/media.dir/fred.aiff

6. Initiate a MediaDirector to MediaDirector FTP transfer for the .mov file using these
commands:
a. Send the following commands to the source MediaDirector
>PASV
### expect a response of the form "227 Entering Passive Mode
10,35,74,26,4,20"
### Your app has to parse out the port number for use below.
>TYPE I
### response "200 Using binary for file transfers"
>RETR /FS0/clip.dir/fred.mov
b. Send the following commands to the destination MediaDirector:
>PORT 10,35,74,26,4,20
### using port number parsed from PASV response of sending MediaStore
>TYPE I
### response "200 Using binary for file transfers"
>STOR /FS0/clip.dir/fred.mov

This is an alternate method with a passive destination:

a. Send the following commands to the destination MediaDirector:
>PASV
### expect a response of the form "227 Entering Passive Mode
10,35,74,67,4,20"
### Your app has to parse out the port number for use below.
>TYPE I
### response "200 Using binary for file transfers"
>STOR /FS0/clip.dir/fred.mov

40 Protocol Reference Guide

 b. Send the following commands to the source MediaDirector:
>PORT 10,35,74,37,4,20
### see response to PASV command for specific numbers to use here
>TYPE I
### response "200 Using binary for file transfers"
>RETR /FS0/clip.dir/fred.mov

This completes the procedure.

Transferring Clips Under Different Conditions

Follow these suggestions to implement a clip transfer when conditions differ to the previous example.
• If you wish to transfer a different media type(s): Follow the procedure above. Be aware that
different file extension(s) to the example will be found and displayed when
OmPlrClipGetMediaNames() is called.
• If you wish to transfer a single clip with Internal Essence: Follow the procedure above
omitting steps 4 and 5 since only one file needs to be transferred.

Notes on Parsing QuickTime Files

The parsing of QuickTime files should only be attempted by those who need an independent code
base that can handle the QuickTime file format. The following notes are intended to address
QuickTime file format parsing in general, and specifically, the “alis” atom, which is used to hold
pointers to external media files:
• You can download Apple's QuickTime player for free, and upgrade it to the pro version at a low
cost. If you intend to create QuickTime files, you can use it to confirm that they were properly
constructed. If you intend to read QuickTime files, you can use it to confirm resolution of
externally referenced media files. An excellent method to test your code is to use the QuickTime
player, create your own movie from a separate video and audio file, save the movie, and then try to
parse the file. If you cannot parse it, then your code does not match Apple's.
• The Apple QuickTime file format specification is well written. Omneon always strives to maintain
compatibility with Apple's definition of QuickTime, so in general, if Apple's software can
understand the QuickTime files produced by the QuickTime player or Final Cut Pro, then
Omneon MediaDirectors should understand it as well. If this is not the case, contact Omneon
Technical Support for assistance. You can also use Apple's Dumpster to look at the low-level
structure of a QuickTime file. If you are working on a PC or an Apple platform, consider using
Apple's QuickTime API to read and write QuickTime files.
• Apple's open source code for the QuickTime streaming server parses QuickTime files, including
the resolution of “alis” atoms. The streaming server source code is available at:
http://developer.apple.com/darwin/projects/streaming.
Go to QTAtom_dref::ResolveAlias() as a starting point.

Omneon, Inc. 41
 • Since the correct tools are important, especially when trying to decipher binary files, Omneon
strongly suggest downloading a free copy of Bvi from: http://bvi.sourceforge.net/
This allow you to more easily see where the atoms are located and see the encoding of the “pascal
strings” used in QuickTime files. If you prefer “od”, you can get an up-to-date version that
provides both a binary and text view from GNU here:
http://www.gnu.org/directory/GNU/textutils.html.

FTP Transfer While Recording

This section details the FTP Transfer while Recording feature as follows:
• Overview
• Features and Limitations
• Implementation

Overview

The File Transfer Protocol (FTP) is a client/server protocol in which the client requests the server to
transfer whole files. The FTP server will store and retrieve files at the request of an FTP client. Requests
and server responses are carried through a control connection. Each file is transferred separately
through a data connection; several files may be transferred independently and in parallel.
When retrieving a file, the FTP server reads the file and sends it across the network, in accordance
with the FTP protocol. Internally, this read is implemented as a chunk-by-chunk read from the
beginning to the end of the file. If the file changes subsequently, the transferred data represents an
earlier version of the file. If the file changes while the FTP server is transferring it, because another
entity is modifying or adding to it, a snapshot is transferred instead.
The “FTP Transfer While Recording” feature allows for the simultaneous creation/recording and
retrieval of a file via FTP. Previously, neither the exact content, nor the length of the file could be
predicted if a file was retrieved while it is being written to. With this feature, retrieving a file while it is
being written to is supported under certain circumstances. Refer to Features and Limitations and
Implementation for additional information. In particular, the file must be of the type “left to right”.
This feature extends FTP to allow consistent retrieval of a file that is being created “left to right.” If
the file is being created more slowly than retrieval via FTP could run, then FTP will slow down and
transfer data only as it becomes ready.
It is important to distinguish between a single file and all the files needed to play a video clip.
Generally speaking, unless all the files of a clip are available, a video clip is not available. Thus, a video
clip comprised of some files, which are not “left to right”, could not make use of this feature.

NOTE: During storage and retrieval of a clip via FTP, each file is transferred using a separate FTP
connection.

42 Protocol Reference Guide

 Features and Limitations

During a recording, a video clip is created in one of two forms:

• Form 1: A wrapper or meta file plus one or more media files, or,
• Form 2: A file containing both meta information and media (that is internal essence).
With Form 1 clips, there are several files to transfer. Typically the media files are large and the wrapper
file is small.
With Form 2 clips, there is only one file to transfer. The files that make up a clip are either:
• Type A: created “left to right” or,
• Type B: created by “write then modify”.
Type A files are only written/appended to at the end of the file; their size reflects stable data. Type B
files do not follow those rules. If the file to transfer is Type A: “left to right,” it can be retrieved via
FTP while being created. However, if the file to transfer is Type B, it is not consistent until completely
finished. These files cannot be retrieved via FTP while being created.
The QuickTime file format can be created in either a Form 1 wrapper file, or Form 2 wrapper file with
included essence. However, since QuickTime files are typically Type B they cannot take advantage of
this feature.
Video formats which support this feature include:
• D10
• MXF OP1a 25Hz with DV video and any kind of audio
• MXF OP1a 29.97Hz with DV video and no audio

Implementation

Keep the following important points in mind:

• This feature is always on.
• There can only be one writer to a file at a time. This is a requirement of the Omneon file system.
A file can be written by a client using FTP, or by a player as it is creating a clip through a record
operation.
• With this feature, the FTP server retrieves a file, and when “End of File” (EOF) is encountered,
checks if the file is open for write. If the file is open for write, the FTP server monitors the tail of
the file and transfers data once it appears on disk. If the file is no longer open for write, the FTP
server retrieves the rest of the file, and terminates retrieval once it encounters EOF.
• The FTP server monitors the tail of the file by sleeping and re-reading the file where it left off. As
a stripe of data is written to disk, the FTP server will read it and transfer it. Network activity at this
point will look like a flurry of packets following a wait of the sleep duration. Sleep time is set to 1
second. This value is adequate to notice file changes within one sleep period for most media bit

Omneon, Inc. 43
 rates, and 2 or 3 periods for VBI. FTP clients will typically wait forever for data to arrive. If the
file is open for write, but no progress is made in the size of the file, the FTP server will timeout,
stop monitoring the file, and conclude the retrieval. Timeout is set to 10 seconds. This value is
required to avoid a false positive on media files (including VBI) during clip creation.
Since Spectrum Release 4.7 SR4, support is available for configuring the FTP server timeout. Via
a Telnet session enter:
>ftp twrtimeout [no. of seconds]

• If the FTP server attempts to store a file from another FTP server while in passive mode, a
timeout occurs if no data arrives from the other server. The default timeout is set to 5 minutes
and log messages print after 20 seconds. Data must be received within 20 seconds to avoid
engaging the Omneon FTP server’s timeout mechanism. This timing is required to support
retrieval from another Omneon FTP server, which is using the “FTP read while record” feature.

44 Protocol Reference Guide

 Index

A Clip manipulation 34
Access Control Commands 26 SITE DELE 36
ACCT, SMNT, REIN 26 SITE LIST 35
CDW, CDUP, XCWD 26 SITE RBW 37
PASS 26 SITE RNFR , SITE RNTO 36
QUIT 27 SITE TIMEOUT 36
USER 26
FTP Service 28
API
Omneon Media ABOR 30
QuickTime DELE 31
parsing 41 HELP 32
LIST, NLST 31
C MDTM 33
Clip Manipulation 34 MKD , XMKD 31
SITE DELE 36 NOOP 32
SITE LIST 35 PWD, XPWD 31
SITE RBW 37 REST 30
SITE RNFR , SITE RNTO 36 RETR , STOR 29
SITE TIMEOUT 36 RMD , XRMD 31
Commands
RNFR , RNTO 30
Access Control 25
FTP Service 28 SIZE 32
Site 33 STAT 32
Sony Serial Protocol 22 STOU, APE, ALLO 30
Transfer Parameter 27 SYST 32
VDCP 9 SITE 33
Contact Omneon 6 HELP SITE 33
SITE LISTFMT 33
D SITE STRIPE 34
Documentation Transfer Parameter 27
end user 2
MODE 28
Spectrum System 2
PASV 28
SystemManager 2
PORT 27
F STRU 28
FTP Server TYPE 28
commands 25 FTP Transfer While Record
Access Control features 43
ACCT, SMNT, REIN 26 implementation 43
CDW, CDUP, XCWD 26 limitations 43
PASS 26 parsing QuickTime files 41
QUIT 27 RFC spec 25
USER 26 session limitations 27

Omneon Spectrum™ System Release 5.4 i

 transfer clips 37 PASV 28
FTP Service Commands 28 PORT 27
ABOR 30 STRU 28
DELE 31 TYPE 28
HELP 32
LIST, NLST 31 V
MDTM 33 VDCP
MKD , XMKD 31 back-to-back play of short clips 17
NOOP 32 commands 9
PWD, XPWD 31 media status reporting 20
REST 30 user data commands 14
RETR , STOR 29 user data extensions 14
RMD , XRMD 31
RNFR , RNTO 30 W
SIZE 32 Wrapper formats
STAT 32 supported 4
STOU, APE, ALLO 30
SYST 32
M
Media API
QuickTime
parsing 41
Media formats 4
supported 4
O
Omneon
Technical Support 6
Omneon Media API
QuickTime
parsing 41

P
Protocol
Sony Serial
commands 22

Q
QuickTime
parsing 41
parsing files 41
S
Site Commands 33
HELP SITE 33
SITE LISTFMT 33
SITE STRIPE 34
Sony Serial Protocol
commands 22
T
Transfer Parameter Commands 27
MODE 28

ii Protocol Reference Guide