Jump to content
Dataton Forum


  • Content count

  • Joined

  • Last visited

About Miro

  • Rank

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

154 profile views
  1. Watchout 6.2 Mask/Edge Blend Issues

    Hi, this issue is related to a bug in some rare cases when using multi-sampling anti-aliasing. This is solved in 6.2.1 which will be out soon. A workaround is to turn on and off the AA-settings in WATCHOUT 6.2. Sorry for any inconvenience.
  2. HDMI 2.0 HDCP 2.2

    Hi, HDCP in any version will not work with WATCHOUT or similar applications. Datapath can only support HDCP using their software with their graphics cards to ensure an encrypted path from source to display. The idea with copy protection is to prevent recording or processing of a captured signal which is a bit contradictory of what WATCHOUT does.
  3. NDI latency vs SDI

    For the SDI to NDI conversion took place in a different computer. This computer transmitted over standard gigabit network to the WATCHMAX that received and displayed the captured stream. I created a custom software (based on libAV/FFmpeg) for the capture to NDI where I could optimize the flow as much as possible. Datapath can convert RGB to UYVY directly in the capture card and since NDI uses the UYVY-format no conversion needed to takes place which reduces latency slightly. Also a less powerful computer can do the job so I actually used an Intel NUC or my laptop as NDI server (with a thunderbolt3 PCIe expansion box for the capture card). I just noticed that FFmpeg 3.4 added native support for NDI so I will test that one too.. We briefly tested the BirdDog and first noticed that it's only using TCP (NDI v2 or older) so we could only stream 1080p60 to 5-6 computers before frames started to drop. Probably hitting the bandwidth limit of the 1 gigabit network. After 8 streams it gave up. So don't expect it work with larger clusters and it's probably intended as a peer-to-peer device. Didn't measure any latency this time.
  4. NDI latency vs SDI

    I did quite a lot of testing before the summer and it's the same delay using DataPath SC SDI card as using the DataPath LC SDI card. I had the following setup: Where I connected a SDI source (with frame numbers) to a splitter. One of the outputs of the splitter was connected to a computer equipped with a capture card. The signal was captured and transmitted using NDI to a WATCHMAX server that displayed the image on a low latency monitor. The other output from the splitter was connected directly to another identical monitor. The both screens were filmed with a 240 Hz camera so I could measure the frame offset. For 720p60 and 720p59.94 I got 4 frames offset which is roughly 67 milliseconds. The type of content didn't really matter. At this time I used NDI v2 and the current version 3 is probably slightly more efficient. I will try to find some time and test this with the updated SDK version and also 1080p60 and 2160p60 resolutions. We also got the BirdDog NDI converter today so we will test that one as well. Just running the capture card locally in the WATCHMAX results in 2-2.5 frames latency between capture and display. So if 4 frames are acceptable then NDI is much more cost efficient since most of your servers doesn't need capture cards. Great when using WATCHPAX units. //Miro
  5. WATCHOUT 6.2 - Available NOW!

    Hi Dorian, Constant systems either using file based write filter (FBWF, windows 7 embedded), enhanced write filter (EWF, windows 8.1 embedded) or unified write filter (UWF, windows 10 "embedded" aka Enterprise LTSB) is great for long term stability. Our WATCHPAX hardware is using FBWF by the way just for this purpose. For your off topic question. WATCHOUT 6.2 is using NDI v3. Multicasting is taking place in the NDI transmitter and for the receiver it make no difference if multicasted or not. The dynamic image server software can be configured to use multicasting though WATCHOUT. Previous versions used RTSP and since 6.2 the image server is using NDI with alpha channel.
  6. WATCHOUT 6.2 - Available NOW!

    Nice and very well written post Jochri! =) When putting together system critical hardware it doesn't make any sense to use the current branch (CB) or current branch for business (CBB) of Windows. Long term servicing branch (LTSB) is the way to go. If you want to take it to the next level and maximize robustness then make the OS partition constant (read-only) using the unified write filter that is provided by the enterprise versions. Never start windows explorer/desktop because it spawns tons of unnecessary disturbing processes (that can cause frame drops) and use the shell launcher to boot directly into WATCHOUT. Sure professional processors will provide you with ECC memory (increasing stability) and more cache memory making video decoding more efficient but Xeon W, Xeon Scalable or AMD Epyc might be overkill and too expensive for some setups. But if you want to go hi-end then these are the best options designed for heavy 24-7 usage. Dual CPUs might make things worse due to a lot of added overhead in memory sharing between the CPUs. You won't get 2x gain with dual processors and in some cases this might be counterproductive (like intense HAP playback). This is the reason behind Xeon Scalable and AMD Epyc which are basically multiple processors packaged as one sharing the same silicon in order to minimize overhead. //Miro
  7. WATCHOUT 6.2

    Have you tried to re-build the cache? Both on the production computer and the display server(s)? //Miro
  8. Luca, it might be possible to configure the playback device in windows to a 7.1 output device. In this case you can use it as a multi-channel WASAPI device in WATCHOUT. Using ASIO4ALL you can probably setup an 8 channel output in the ASIO4ALL control panel. Additionally some motherboard manufacturers are supplying ASIO drivers for their onboard audio chips. For example my dell laptop audio drivers comes with native ASIO support (Realtek). Did you install the drivers from Asrock or are you using generic ones?
  9. WATCHOUT 6.2 Bugs

    Michele, unfortunately this is a limitation/bug in 6.2 and we are working on a solution. Also the playhead is reset when recalling a layout preset and this one will also be solved in an upcoming bugfix release.
  10. WATCHOUT 6.2 Bugs

    Thomas, compared to 6.1.6 the selected audio device is initialized as well as the NDI listener (so it can populate the combo box with available NDI devices). If your selected audio device is broken or has a damaged driver then the production interface could hang or crash on startup. In this case it would help to disconnect the problematic audio device and try to open WATCHOUT again. What type of media item does your show file contain? What you also can do is to check the Window's event viewer and look for clues under Windows Logs->Application.
  11. Control Dmx channels with Artnet

    Hey, also check that you only have one network adapter active so you don't broadcast on network port 1 while your gear is connected to a network on port 2. On a laptop I would enter airplane mode to disable the wifi in order to force all traffic through the wired network adapter. The subnet mask is used to narrow down the broadcast range. In most setups the subnet mask is which allows you to broadcast to class C subnet. As example, if your IP is you can broadcast to all 192.168.0.xxx addresses (255 destinations). But if your light gear is located in a different subnet like 192.168.1.xxx the artNet commands will not reach those devices. You can modify the subnet mask to in order to reach both subets (192.168.0 and 192.168.1). Double check your ip addresses and network settings.
  12. Experience with WX 9100 and S400

    Which version of windows 10 did you test and which AMD drivers? If hardware sync is not important then 4x 4K works fine with W5100 or better (probably works fine with W4100 too but I haven't tested that one). Here is a picture from my tests running 4x 4K 60 Hz using AMD W5100 in a Win10 x64 Enterprise LTSB server. Also make sure to run the same display mode on all displays.. Some cards seems to default to using 8-bit color depth on some ports and 10-bit color depth on others. Set all to 8-bit.
  13. Watchpax sync

    Hi, frame sync happens over network so that all devices are rendering the same frame at the same time. Scan sync or genlock means that the scan out of the ports of the GPU are synchronized. A synchronization card can also achieve genlock across several GPUs/servers. If two GPUs are not connected using a synchronization card the following will happen: Even if booth GPUs are rendering at 60 Hz they will not scan out/transmit the signal at the same time and will be out of phase. They will render the correct frame (frame sync) but there might be a slight offset between the display devices (mostly not noticeable) The timing devices in each GPU are not synchronized so the perception of time is a bit different. Both of the GPUs will render at 60 Hz relative their internal clock, but relative to the production computer (cluster master) clock they might actually render at 59.9999 and 60.00001 Hz.. The slower GPU will need to drop a frame after some time while the faster GPU will need to duplicate a frame after a while. If using synchronization cards but having a bad network might result in bad frame sync.. Even if all GPUs will keep the exact 60 Hz timing and scan out the signals to the displays at the same time, the rendered content might be out of sync. The clock time stamp from the master will be multicasted using UDP. On a normal setup this time stamp can have an offset of +- 0.5 milliseconds (in 60 Hz each frame time is 16.666667 ms) between servers. In extremely rare cases this could result in that a video frame would be scheduled into the incorrect display frame causing a very brief mismatch between what is shown on the outputs. On Nvidia and AMD GPUs (pro and gamer versions) all outputs are automatically genlocked if they output a signal with the same timing (same resolution and refresh rate). Hope this make some sense.. //Miro
  14. WATCHOUT 6.2 - Available NOW!

    Hey, I just tested the Echo Audio Fire 12. Works fine with the ASIO driver and all 12 outputs works as expected. WATCHOUT 6.2 doesn't have any support for time code input through ASIO yet but it will come in a minor update version soon (6.2.2). This is a bit limiting since ASIO takes exclusive control over the whole sound device, which makes it impossible to use the directsound input from the Echo simultaneously. We also discovered a multi-channel WASAPI bug in WATCHOUT that is corrected in version 6.2.1 which makes it possible to use 8 outputs and TC input from the Echo Audio Fire 12. WATCHOUT 6.2.1 is finalized this week and released in the beginning of next year.
  15. Audio Phasing Issue

    Which version of WATCHOUT? 6.2 doesn't have this problem and doesn't have any confusing checkboxes either. For RME, use the ASIO driver.