Playback Preferences

This page is a comprehensive description of what each specific preference in VirtualVTR and VirtualVTR Pro will do. It does not offer overall guidance on particular setups.

Std.Sync Correction mSec:
When VirtualVTR chases an external timecode source, it aims to get the correct video frame to appear on an attached video monitor to coincide with the incoming frame of timecode. However, most video hardware has a 'latency' between receiving the video from QuickTime, and actually delivering it to its video output. Also, some monitors (especially Plasma Screens and Video Projectors) have a latency of one or more frames. This would result in the displayed video lagging behind the timecode being delivered to VirtualVTR, and so VirtualVTR has a function to offset the picture which VirtualVTR is playing by a number of milliseconds. This will delay both picture and sound by the same amount.

DV Out Sync Correction mSec:
This is similar to above, but is a dedicated setting for use when playing DV format material such as DV-PAL and DV-NTSC. Most hardware DV bridges have an especially large latency of around 300 mSecs, and so we include a special preference for use with DV movies (codec type 'dvcp' or 'dcv '. All other movie codecs will respect the std. sync correction value above.

Sync Tolerance Frames
When VirtualVTR chases an external timecode source, it constantly tracks the timecode values arriving into VVTR, with the timecode position of the virtual timeline being played out. If these 2 values deviate from one another by more than the Sync Tolerance preference value, the picture has drifted out of sync (this only occurs when no genlock is used), or is not yet bumped into sync. At this point, VirtualVTR will attempt to resync the picture, and you will see the 'Resync' LED light briefly. Normally this will correct the sync and playback will continue as normal. However, with some setups, repeated resyncing may occur, indicating that there is an ongoing discrepancy with the sync between timecode in and timeline. This can be because of user error - with a different frame rate in VVTR to the incoming timecode, or in some cases because the computer system is heavily loaded, resulting in 'jitter' in either the timecode arriving into the application, or in VirtualVTR's interpretation of its timeline position.The movie may be playing perfectly in sync, but the jitter may be jumping forward and back by more than the Sync Tolerance. In this case repeated resyncing may ensue, even though it is not appropriate. if this happens, increase the value of the sync tolerance.

Video Head Disengage Threshold
VirtualVTR allows playback of picture at slower, and faster than real time. By default, it will try to play EVERY frame when in faster that real time playback, which can result in very high frame rates. At some point, the additional load of playing excessively high frame rates will start to choke the computer system. Fortunately, VirtualVTR has another playback mode, called 'VirtualMachine' which simultates very high speed playback, but instead of playing every frame, simply skips frames, playing as many as possible with the CPU time available. This usually results in extremely smooth and responsive playback withouth choking the CPU. This is especially important when controlling VirtualVTR from a 9-pin controller, since without it, the choking CPU would cease responding to 9-pin instructions, essentially locking it out. Faster CPUs will support faster disengage thresholds, although if you are only interested in Picture, 101% is an obvious choice. VirtualMachine mode does not playback audio, since its basically jumping from one frame to another very quickly. If varispeed audio is important to you, then use the maximum disengage threshold which maintains good smooth control of VirtualVTR without choking.

Absolute Max Shuttle Speed
See Above. This preference is an absolute max supported shuttle speed which VirtualVTR will respond to, in either real, or virtual machine mode. Requests to shuttle faster than this value will be ignored.

Scrub Filter Ticks
This pref is to accomodate control software issuing long strings of repeated locate commands with the same value. Repeatedly relocating to the same position acheives nothing in VirtualVTR, but can choke the CPU. This parameter determines the minimum time between locate commands which VirtualVTR will recognise, in ticks (1/60ths of a second). If your controller issues very rapid slews of locate commands, and this is choking the system, increase this value.

MTC Stop Overshoot Correct Frames
When chasing timecode, VirtualVTR automatically plays when timecode starts, and stops when the timecode stops. In this mode, the ultimate frame on which VirtualVTR ends up parked will be determined by some ballistics of the timecode generator and reader. This pref allows VirtualVTR to automatically 'back up' by a number of frames after stopping, to compensate for any timecode 'run on'. Ideally the controlling system would issue a locate command after stopping timecode, to explicitly position the machine, but several systems do not do this. Hence this preference. Also see 'relocate to start on stop'

Rollback time Seconds
It is often useful to be able to instantly move the video playhead back by a fixed amount. This preference determines the number of seconds VVTR will back up when the 'Roll Back' transport command is used.

Full Screen On :
When operating VirtualVTR using VGA type playback screens, it is useful to be able to operate them in 'Full Screen' mode, hiding the menu bar. This preference allows users to control this behaviour, and to select one of several attached VGA video cards to be used for full screen playback. You may optionally request that the movie is scaled up to fit the full VGA window. Note that this mode is overriden if you have chosen to explicitly route a particular codec type through a specific video output device ( from the Video Output Assignments page - see later). Also, note that 'Full Screen' behaviour can be toggled without visiting the prefs dialog by holding the OPTION (ALT) key as you double click a movie from the VirtualVTR bin. If you have only one VGA monitor, you can close the movie to get back to the VVTR software using the keystroke Apple-W (close window).

Relocate to start on stop
Some users like their audio and video to 'snap' back to the start of playback after stopping, locating back to the beginning of the playback rather than parking at the end. When this pref is checked, VirtualVTR will relocate (after stopping) back to the last position it was located to before playback begun.

PreRoll Movie
On some VirtualVTR systems, for example, when using uncompressed HD video, there can be a heavy system load as playback begins, as QuickTime caches hundreds of megabytes of video to start playback. This can cause a slight delay before playback begins. To compensate for this, VirtualVTR offers a 'Pre-Roll' mode which will automatically pre-cache data ready to start playback instantly. This operates after VirtualVTR has been parked at the same spot for a few seconds. Because this may interfere with rapid repositioning of the picture (if a locate is received after caching begins), this behaviour is controlled by a preference. If you want instant start, and you are prepared to park the picture at the start point a few seconds before playback is required, then you can use this preference.

Auto Open Movie on Locate
The VirtualVTR 'bin' can contain many movies, available for the user to open at will by clicking on them or via other transport commands. Each movie has a distinct Timecode start time, and the movie will respond to timecode and locate commands in the range of the movie timecode. Some users want to work with multiple movies during the same session, perhaps different versions of the same commercial, which they want to jump between whilst preparing audio for them. VirtualVTR offers an easy way to enable this. When this preference is checked, the following behaviour is enabled.
- if an MMC or 9-pin locate command is received, which is OUTSIDE of the timecode range of the current movie, VirtualVTR will search through the other movies in the VVTR bin, and if it finds a movie which includes that timecode, it will automatically close the current movie, and open the new movie. This allows a user with an audio workstation to timestamp several versions of a commercial at 1 minute, 2 minutes, 3 minutes etc, and to position several versions of the audio for those pictures at 1,2,3 minutes on the audio timeline. Now, by simply moving to different versions of the audio at different times, the appropriate picture will automatically open in VirtualVTR.

Reopen Bin on startup
The VirtualVTR 'bin' can be saved as a document for later reload of a group of files. VirtualVTR maintains a 'default' bin which is automatically saved and reopened when this pref is checked, to make all your recent movie available to you automatically when the app is launched.

Use Varispeed
When VirtualVTR is chasing timecode, it normally does this by playing at normal speed and 'bumping' the picture into Sync. When this pref is checked it allows VirtualVTR to use variable speed playback to try and track the incoming code. In general this is less effective than bumping into sync, so this preference is NOT recommended for most applications.

©2003 Gallery