PTP Setup

Viz Mosart can derive genlock and timecode from a PTP (Precision Time Protocol) Grandmaster instead of a traditional hardware timecode reader such as a Plura PCIe card. The Windows system clock is disciplined to the PTP Grandmaster through the built-in W32Time PTP provider (ptpprov.dll). Viz Mosart then uses the SMPTE ST 2059-1 epoch to calculate frame boundaries, so no additional hardware is needed.

For the frame accuracy concepts, and for the calibration that Viz Mosart needs whichever clock source you choose, see Frame Accurate System Operations.

Requirements

Windows Version

The PTP provider (ptpprov.dll) is available on:

• Windows 10 version 1809 (October 2018 Update) and later

• Windows 11, all versions

• Windows Server 2019 and later

Verify that the file exists:

Network

• UDP ports 319 and 320 must be open (inbound) on the Viz Mosart machine firewall.

• The Viz Mosart machine must have network connectivity to the PTP Grandmaster, or to a PTP boundary clock on the same subnet.

• PTP multicast traffic (224.0.1.129) must be able to reach the NIC on the Viz Mosart machine.

• If the machine has more than one network adapter, make sure PTP multicast reaches the NIC on the same network as the PTP Grandmaster. PTP is typically carried on the media or production network, not the management network.

PTP Grandmaster

A PTP Grandmaster must be operational on the network. You need to know:

• The IP address of the PTP Grandmaster, or of a boundary clock reachable from the Viz Mosart machine.

• The PTP domain number used by the Grandmaster. The SMPTE ST 2059-2 default is 127, but many facilities use a different value.

Viz Mosart Version

PTP support requires Viz Mosart 5.15.0 or later.

Supported Deployment Scenarios

The rest of this section covers the physical machine and in-guest ptpprov.dll setup, which applies to all scenarios except VMware with host PTP.

Setting up the Windows PTP Provider

Run all commands in an elevated PowerShell session (Run as Administrator).

Step 1: Verify that ptpprov.dll is present

This must return True. If it returns False, the Windows version does not include the PTP provider. See Requirements above.

Step 2: Open the firewall ports

Step 3: Register the PTP provider

Replace <GM_IP> with the IP address of the PTP Grandmaster or boundary clock on your local subnet. Replace <DOMAIN> with the PTP domain number, which is 127 by default.

Understanding PtpMasters. The Windows PTP provider is a listen-only client. It receives PTP multicast but sends no outbound PTP traffic. PtpMasters is a whitelist of source IP addresses: the provider accepts PTP Sync and Announce packets only from IP addresses in this list, and ignores all others. The address does not have to be the actual PTP Grandmaster. In most broadcast facilities, a PTP boundary clock, often the PTP-aware network switch that also serves as the subnet gateway, redistributes time from the Grandmaster to each subnet. Set PtpMasters to the IP address of whichever device sends PTP multicast on your local network.

How the three critical settings work together. PTP multicast packets arrive at the NIC regardless of these settings, because they flow on the network at layer 2 and 3. However, ptpprov.dll does not process them unless all three of the following conditions are met:

1. EnableMulticastRx is 1, which enables the provider to listen for multicast PTP.

2. PtpMasters contains the source IP address, because the provider accepts PTP only from whitelisted addresses.

3. DomainNumber matches the PTP domain, because the provider accepts PTP only on the configured domain.

If any one of these is wrong, PTP fails silently and W32Time reports "Local CMOS Clock".

Verify that the registry was written correctly:

Step 4: Disable competing time providers

Disable NTP and the Hyper-V or VMware time integration service (VMIC) so that they do not compete with PTP. This matches the Microsoft reference configuration for a PTP client.

If NTP or VMIC is still enabled and has a valid source, W32Time may choose it over PTP. The Microsoft reference configuration disables both.

On virtual machines, you may also need to disable time synchronization at the hypervisor level:

• VMware: disable Synchronize guest time with host in the VMware Tools settings.

• Hyper-V: disable Time synchronization in Integration Services, or run:

Step 5: Restart W32Time

Step 6: Verify the PTP lock

Example of a successful PTP lock:

What to check:

About Stratum. PTP and NTP use a hierarchy of time sources. A reference clock such as a GPS receiver or atomic clock sits at stratum 0. Any clock synchronized with a stratum 0 clock becomes stratum 1, and so on. The stratum number indicates distance from the reference clock, not the accuracy or reliability of the time. Each boundary clock in the chain adds one level:

• Stratum 1: direct sync to a stratum 0 source such as a GPS or atomic clock. Rare.

• Stratum 2: syncing to a PTP Grandmaster, which is stratum 1.

• Stratum 3: syncing through one boundary clock. This is the common case.

• Stratum 4 and above: syncing through multiple boundary clocks.

• Stratum 0, reported as unspecified: the PTP provider never engaged. Source shows Local CMOS Clock. Re-check Step 3 above.

If the status shows Free Running, Local CMOS Clock, or Stratum 0, see Troubleshooting below.

Viz Mosart Configuration

Once the Windows system clock is PTP-disciplined, confirmed with w32tm /query /status, configure Viz Mosart.

Clock Source, Enable Genlock, and External clock is local time are set in AV Automation. After changing Clock Source, restart AV Automation for the change to take effect.

Verification

Viz Mosart Status Bar

The genlock status bar in AV Automation indicates the current state:

Genlock Statistics

1. Press Ctrl+Shift+I in AV Automation to start collecting genlock statistics. The status bar shows "PTP - STATISTICS ON" while collection is active.

2. Collection stops on its own once 10,000 samples have been gathered. Viz Mosart takes one sample per frame, so how long that takes depends on the frame rate: about 6 to 7 minutes at 25 fps, about 5 and a half minutes at 29.97 fps, and roughly half those times at 50 and 59.94 fps.

3. Press Ctrl+Shift+I again to stop earlier and write the results.

4. Three files are created in C:\MMLogs\GenLockStats\ by default:

   • GenLockStats_Summary_<uid>.txt, a human-readable summary with conclusions.

   • GenLockStats_FrameClock_<uid>.csv, the internal frame execution timing and jitter.

   • GenLockStats_ExternalCS_<uid>.csv, the raw PTP clock source timing, phase shift, and timecode.

5. Send all three files to Vizrt Support.

Key items to check in the report:

• Clock source type should show PTP (SMPTE ST 2059-1).

• W32Time PTP Health shows the sync source IP address, stratum, phase offset, and Reference ID. A Reference ID of 0x4D505450 confirms PTP discipline.

• Jitter should be consistently below 2 ms, and is typically within 0.1 ms.

• Bad frames should be 0 during stable operation.

• PTP Clock Quality in the conclusion section rates the overall quality. "GOOD" means all metrics are healthy.

Checking the PTP Offset Over Time

To monitor the offset between the local clock and the PTP Grandmaster:

Values should be consistently small, below 1 ms. Include this output when contacting Vizrt Support about timing issues.

Continuous Monitoring

Viz Mosart checks w32tm /query /status every 60 seconds to verify that the system clock is still PTP-disciplined. If PTP discipline is lost, for example through a network problem or the Grandmaster going offline, Viz Mosart detects this and shows a warning in the status bar within 60 seconds.

Troubleshooting

The PTP Provider is not Active (Free Running or Local CMOS Clock)

The troubleshooting commands below use variables for the long registry paths:

1. Is ptpprov.dll registered? Verify the registry with reg query $ptp. If values are missing, run Step 3 again.

2. Is the PTP Grandmaster IP address correct? Check with reg query $ptp /v PtpMasters.

3. Is the PTP domain number correct? This is the most common problem, because the domain must match the Grandmaster. Check with reg query $ptp /v DomainNumber.

4. Is multicast reception enabled? It must be 0x1. Check with reg query $ptp /v EnableMulticastRx.

5. Is the firewall blocking PTP? Check with:

6. Is NTP still enabled and overriding PTP? Check with reg query $ntp /v Enabled. The value should be 0x0.

7. Is W32Time running? Check with sc query w32time.

Stratum 0 or Local CMOS Clock, Meaning the Provider never Engaged

Stratum 0 with Source: Local CMOS Clock means ptpprov.dll never engaged and the PTP provider is not properly configured. Verify:

• Network connectivity, using ping <GM_IP>.

• That the PTP domain number matches the Grandmaster.

• That PTP multicast (224.0.1.129) can reach the machine. Check the NIC and VLAN configuration.

• That UDP ports 319 and 320 are not blocked.

The Status Bar shows Yellow and Reports "not PTP-disciplined"

Viz Mosart checks w32tm /query /status every 60 seconds. If the ReferenceId is not 0x4D505450, a yellow warning appears. Fix the Windows PTP configuration first, and Viz Mosart detects the lock automatically within 60 seconds.

The Status Bar shows Red

The PTP clock source failed to start. Check:

• That w32tm /query /status shows a valid PTP lock, with ReferenceId 0x4D505450.

• That Clock Source is set to PTP and Enable Genlock is True in AV Automation.

• That AV Automation was restarted after the settings were changed.

Timecode Mismatch between Viz Mosart and the Recorder

1. Frame rate. The configured frame rate in Viz Mosart must match the frame rate of the PTP Grandmaster. A mismatch causes progressive drift.

2. UTC against local time. If the recorder uses local time and Viz Mosart uses UTC, or the other way round, a fixed offset results. Adjust the External clock is local time setting.

3. Drop-frame. For 29.97 fps and 59.94 fps, make sure both Viz Mosart and the recorder agree on drop-frame timecode.

No PTP Packets reach the Machine

To verify that PTP traffic is arriving, use the built-in Windows packet monitor:

Look for lines containing 224.0.1.129 and port 319 or 320. Press Ctrl+C to stop the capture. If PTP packets appear, traffic is flowing correctly.

Tip: Use an unfiltered capture. The pktmon UDP port filter does not reliably match multicast PTP packets.

If you see PTP packets followed by Drop: DropReason INET: transport endpoint was not found, this is normal before W32Time is configured. It means PTP traffic reaches the machine but nothing is listening on that port yet. Once ptpprov.dll is registered and W32Time is restarted, the drops stop.

If no PTP packets appear:

• Verify that you are monitoring the correct NIC. PTP is typically on the media network, not the management network.

• Check that the switch forwards PTP multicast to this port, which depends on the IGMP snooping configuration.

• Confirm that the Grandmaster is on the same subnet or VLAN.

References

• Microsoft W32Time PTP documentation

• Microsoft: how to set up a Precision Time Protocol client

• VMware vSphere 8: use PTP servers for host time synchronization

• VMware vSphere 8: add a Precision Clock device to a virtual machine

• SMPTE ST 2059-2:2021, SMPTE profile for use of IEEE 1588