Jump to content

Miro

Moderator
  • Posts

    144
  • Joined

  • Last visited

Posts posted by Miro

  1. In some cases the GPU power management is a bit stupid. Some systems clocks down the video memory speed when the GPU load is low. Just playing video doesn't really utilize the GPU much but the video will start stutter if video memory is clocked down. Also the PCIe lane speed can be clocked down as well by the system. This can often be solved by a registry setting like:

    [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4d36e968-e325-11ce-bfc1-08002be10318}\0000]
    "ForcePcieLinkSpeed"=dword:00000003

    This assumes that your nvidia GPU is located at 0000. If the intel GPU is at 0000 and nvidia is at 0001 then just change this value instead:

    [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4d36e968-e325-11ce-bfc1-08002be10318}\0001]
    "ForcePcieLinkSpeed"=dword:00000003

    Also force the system to use the Nvidia GPU for WATCHOUT so it doesn't switch. Last, in the nvidia 3D settings change power management from "Optimal Power" to "Prefer maximum performance". Also setting Threaded Optimization to off might improve playback.

     

  2. Hi, can you check if the desktop settings are matching the settings of your show when you are setting up the sync settings? The sync card is setup in desktop mode and if you go full screen with any other settings it will invalidate the sync. For example:

    10bit 1920x1080 59.94 Hz in the desktop and running 8bit 1920x1080 60.00 Hz in WATCHOUT will not synchronize. 10 or 8 bit settings are set in the AMD control panel while resolution and refresh rate is set in Windows settings. You can check output signal details in the AMD control panel as well since that one will show the correct refresh rate. Windows is not consequent and is displaying 59 or 60 Hz in different places for 59.94 Hz signals.

    Also you can test if running eyefinity works. Eyefinity should always be in sync.

     

  3. Ronald, we are using the radeon-pro-software-17.q4.1-whql-dec14 drivers.

    In the WATCHOUT installation folder you will find the following exe-files:

    • WATCHPOINT.EXE (~879 KB)
    • WP.EXE (~9.5 MB)

    The small one WATCHPOINT.EXE has a watchdog functionality. It launches WP.EXE and re-launches if it crashes or hangs. The problem in the 6.1.6 version is that the time-out for detecting if WP.EXE is unresponsive is 10 seconds. Creating many displays in Windows 10 takes time, especially if the driver needs to change display mode. Creating more than 3 displays takes more than 10 seconds which will result in that the watchdog terminates and relaunches WP.EXE infinitely. This has been addressed in later versions of WATCHOUT but in 6.1.6 it's not.

    What you can do is to skip the watchdog and run WP.EXE directly. Also setup the display settings to match your show for a quicker start. If you need the WATCHDOG functionality, Windows has some built in functionality for this using the task scheduler but I haven't tested it. There should also be plenty of 3rd party solutions for this.

    //Miro

  4. It also depends on how you tweak your network adapter driver settings. Default settings are using pretty small buffers and jumbo frames are disabled. You need to change this for reaching actual 10 GbE. There is a trade-off between low latency and transfer speeds.

    Read the documentation from your hardware vendor. Intel has usually good guides on how to tune the adapter for maximum throughput. 

  5. The -TimeOut command was added in 6.3 so it's pretty new. A simple test to determine if you need to use a extended timeout is when WP.exe starts without issues but WATCHPOINT.exe doesn't.

    WATCHPOINT.exe has a watchdog functionality and starts WP.exe and if WP.exe crashes or hangs (timeout), WATCHPOINT.exe will restart WP.exe. Therefore problems with infinite restarts are occurring if the window creation time is longer than the timeout.

    Running WP.exe directly isn't really recommended unless you are using any third part watchdog/safeguard application.

  6. Are you using Win10 LTSC 2019 or LTSB 2016? With LTSB 2016 you need to install at least the kb4057142 update to resolve some Microsoft multi-monitor bugs.

    Most common problem is that the windows output timing is not the same as the one used in the show and that it simply take too long to apply all the changes when entering full screen. This triggers the timeout in WATCHOUT and the process starts over again. For example we have this issue in our lab where we run 6x 3840x2160 monitors that are 10-bits per color component. Before starting WATCHOUT the AMD settings must be changed from 10 bpc to 8 bpc for each monitor. Then it works just fine.

    Also make sure to use WATCHOUT 6.3.1 where the timeout has been extended from 10 secs to 60 secs. It's also possible to use a -TimeOut parameter in order to extend the timeout even further. For example: "WATCHPOINT.EXE -TimeOut 120" will result in a two minute timeout.

    Windows Display Driver Model (WDDM) version 2.x is a lot slower to apply display changes than version 1.x used in Windows 7 & 8.  

  7. Misterk, Nvidia is usually less hassle and more consistent drivers. They follow standards more strictly which means that you need to manually override some display outputs to use full range instead of limited range over HDMI. Same setting needs to be set for video conversion to prevent live video to be in a limited range when converting YUV to RGB.

    Ortfisher, even if you can source drivers via Windows updates, a better way is to obtain drivers from each manufacturer directly. I always extract the core drivers from their software package in order to get rid of all other softwares that comes bundled with it. The risk of getting everything from Microsoft is that you may receive generic drivers that doesn't perform as well as the dedicated drivers.

  8. All windows versions uses a different version of WDDM (Windows Display Driver Model). Windows 7 uses WDDM 1.1 and Windows LTSB uses WDDM 2.1. There are major differences on how fullscreen windows are created between the major versions of WDDM (1 & 2). It simply takes longer for Windows 10 to initiate and create fullscreen windows. We made some improvements for this in WATCHOUT 6.3 in order to speed up the process and create all fullscreen windows at once.

    Display driver version has also a big impact and for AMD the only driver that works well with WDDM 2.1 & 2.2 is the 17q4.1 enterprise driver. Most tested drivers from AMD released in 2018 has various problems, where most of them result in poor HAP playback performance. Some AMD drivers from 2018 might also bluescreen at windows logon if they are forced to run at maximum clock speed using the registry.

  9. Hi, WATCHOUT doesn't really add any latency. However, latency might come from the interface between WATCHOUT and the hardware.

    An application can either use BlackMagic's proprietary framework/API Decklink or DirectShow. WATCHOUT only supports DirectShow so when you are comparing software then make sure that you are comparing using the same framework. WATCHOUT is pulling the frames from the DirectShow capture filter as fast as possible. The BlackMagic DirectShow capture filter is installed when installing the software package from BlackMagic so it might be good to test different versions of their software.

    Another good test is to install the 32-bit version of Media Player Classic Home Cinema because it uses pretty much the identical DirectShow filter graph as WATCHOUT.

    What normally adds latency is re-sampling of any kind like color format re-sampling, color space re-sampling, framerate re-sampling or resolution re-sampling. Especially if the hardware doesn't have these capabilities then the conversion takes place in software. WATCHOUT is capturing using the YUV 4:2:2 8-bit (YUV2) format in the resolution and refresh rate that is specified in WATCHOUT for the live video media.

    Getting the frame from DirectShow and showing it on the screen takes usually two display frames due to double buffering. So if you are running the displays at 60 Hz then WATCHOUT will add around 33 ms. All other latency comes from the DirectShow capture filter and capture hardware. Most hi-end hardware adds around one frame when not re-sampling etc.. So in most cases it should take 3-4 frames from capture to display. Some hardware have low latency modes which makes it possible to capture in less than one frame time (example: Datapath livestream) which results in a 2-3 frames capture to display latency.

    Blackmagic's DirectShow implementation isn't the greatest and you need to make sure that no re sampling is taking place for best results. Test Media Player Classic with the same settings as in WATCHOUT and see if you get the same results there. Make sure to select the YUV2 color format when comparing.

    Best Regards,

    Miro 

  10. What type of signal are you trying to capture? BlackMagic software is using the DeckLink interface while WATCHOUT is using DirectShow filters. I haven't tested this particular card but BlackMagic cards doesn't seem to be able to scale so the capture settings in WATCHOUT must match the signal format exactly.

  11. About windows editions. You can probably use which edition you want. Windows professional editions usually comes with more bloatware and requires more effort when tweaking. Later versions contains more features and has a larger footprint. It's probably easier to obtain a specific version like 1709 for enterprise than pro.

    At Dataton we are using Enterprise 1607 LTSB and Enterprise 1709 and will not spend much time to configure and tweak other editions. Also note you will need a volume licensing agreement if you are deploying a clone image to multiple devices.

  12. Hi Scott,

    I'm not sure about your particular hardware but I have an Echo Audiofire 12. This device can be configured as a 8-output WASAPI device and since WASAPI is half duplex you can also use the inputs for timecode.

    For info ASIO input for TC will be a part of WATCHOUT 6.3 which will be released this summer.

    In the meanwhile... In some cases we use mono mic to USB devices which uses Microsoft's USB class driver (plug & play) like this one: http://www.musictri.be/Categories/Behringer/Computer-Audio/Interfaces/MIC-2-USB/p/P0BBQ 

    //Miro

  13. DVS, some DirectX issues comes from Microsoft where some versions of Windows have issues to initiate multiple DirectX fullscreen windows. However this problem is solved by using an appropriate windows update. Installing the latest updates it's not always a good idea because sometimes new DirectX bugs are introduced. We verify a base configuration that works and are keeping that constant until we discover issues that needs to be addressed.

    There are other fixes that can be applied to make the system more stable and reliable. For example some motherboards like variants of X99 are causing interference in audio when the GPU changes it's link speed. This is most noticeable for AMD cards since they constantly changes their link speed and frequency. It's possible to force the link speed to maximum by using the following registry entry:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\4D36E968-E325-11CE-BFC1-08002BE10318\0000 There you can create a DWORD key named ForcePcieLinkSpeed and set it to 3. If your system had a different GPU previously then you will have several sub-trees like 0001, 0002 etc.. Then you can create and set the ForcePcieLinkSpeed in all those sub-trees. I had issues with early 2018 drivers from AMD where the driver would cause a blue screen when starting windows. The driver from late 2017 mentioned above works fine. You can get it here: https://support.amd.com/en-us/download/workstation/previous/detail?os=Windows 10 - 64&rev=17.Q4.1#pro-driver

    If using the synchronization provided by a S400 card (or using a nvidia card in combinations with a sync card) you might run into issues where windows will kill the GPU driver when all displays are initialized and synchronized. Especially if you have many displays. This is not really related to windows 10 but is good to know about. By default if a driver doesn't respond within 2 seconds windows will interfere and in this case it will end up with a bluescreen. This behavior can be changed in the registry and you can set a different timeout.

    • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\GraphicsDrivers TdrDelay should be increased to 15 seconds (default is 2 seconds, decimal value DWORD)
    • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\GraphicsDrivers TdrDdiDelay should be increased to 60 seconds (default is 5 seconds, decimal value DWORD)

    Setting up hi-end systems usually requires hi-end skills and isn't really related to WATCHOUT but any other visualization software. ;)

    Other issues that may occur in Windows is that if an application steels focus from WATCHOUT it might interfere with the fullscreen state. Make sure to disable all notifications and any conflicting applications. Best advice is to kill explorer.exe which is handling the desktop, taskbar and a lot of other things that you don't need when running a Media Server.

    //Miro 

     

  14. Hi, we have been running Windows 10 servers with WX 9100 for a long time and I haven't experienced this kind of issues.

    There are known issues with AMD's 2018 drivers and we are running the 2017 Q4.1 drivers. I wouldn't recommend using Windows 10 Pro. It's also important to setup and configure the server in a offline mode in order to get control over which updates and drivers that will get installed. Use Microsoft Update Catalog to download necessary updates prior to installation. Here are the combinations of OS + updates that we use.

    • Windows x64 Enterprise 1607 LTSB + update KB4057142
    • Windows x64 Enterprise 1709 + update KB4090913 

    Microsoft has both solved and introduced DirectX bugs and these updates are important to get correct functionality.

    //Miro

  15. Hi, we are running multiple servers with AMD WX 9100 driving 6x 4K monitors/projectors at 60 Hz.

    In our lab we are using the locking AMD miniDP to DP converters with 3 meter hi-quality DP cables connected to each monitor. In real life the distance between server and projectors or monitors is a bit longer and in this case optical DP extenders are used.

    The main difference between displayport and HDMI is that displayport performs continuous link training to evaluate the cable in order to determine how many lanes should be used and at which clock rate. The problem with 4k60 is that all lanes must be used at maximum clock speed and this is only possible in short cable routes. Running normal cables longer than 3 meters is problematic in this case.

    HDMI 2.0 and 2.1 is an option but adapters shorten the theoretical cable length. Also cables are not marked with HDMI 2.0 which makes it a bit confusing. HDMI 4k cables are version 1.4 supporting only 4k30. Look for cables labeled as HDMI 4k HDR (usually 18 Gb/s) which are HDMI 2.0. When using DP to HDMI 2.0 adapters the cables shouldn't be longer than 3 meters. 5 meter cables are rated for connecting directly between source and display and an adapter introduces too much signal loss.

    I never had any good experience using boosters or amplifiers. Fiberoptics or quad link 3G SDI the way to go if you need longer cable routes.

    Additionally I always force emulate EDID especially when using sync cards.

    It takes a while for the driver to synchronize when entering fullscreen mode and with that many outputs Windows might kill the display driver because it doesn't respond fast enough resulting in blue screens. It's recommended to extend this time limit using the registry. 

    . Docs: Microsoft TDR Registry Keys

     

    • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\GraphicsDrivers TdrDelay should be increased to 15 seconds (default is 2 seconds, decimal value DWORD)
    • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\GraphicsDrivers TdrDdiDelay should be increased to 60 seconds (default is 5 seconds, decimal value DWORD)
    //Miro

         

  16. 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.  

  17. 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.

  18. 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:

     

    post-13299-0-55691300-1515440618_thumb.png

     

    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

×
×
  • Create New...