Erik Rönnqvist

Not really, we still recommend using separate video and audio files. /Erik

Normally I would recommend the latest version, since it probably contains important bug fixes. If you are running Watchout 6.1.2 you may also used chunked encoding, which is useful to increase decoding speed especially for very large videos. But stay away from HapQ+Alpha. /Erik

Hello! Could you be a bit more specific on the hardware used? Also, how is the audio played, embedded in a movie file, or as a standalone audio file? Which audio format are you using? If embedded in a video file, what kind of file and which codec? /Erik

Hello! I do seem to recall that this example only works with the original Kinect, and using newer units might not work. /Erik

Hello! As jfk mentioned, a few bugs in the prores decoder have been fixed along the way. If you're not using 6.1.2 yet, please give it a try and see if the artefacts disappear. If this does not work, provide support with sample prores files that show the problem, and we will have a look. /Erik

The simplest solution would be to use Live Update. That way, all media is always present in all display computers. Without Live Update, Watchout analyses the timeline(s) by sampling it every 100 ms (if I recall correctly) to see which media is present in which displays. That way only the media actually needed in a specific display computer is transferred to that display computer, which in many cases speed things up. However, if the timeline is very long (many hours) the analyse process may take quite some time, especially if there are tween tracks with a continuously changing parameter present. If using Live Update, it will persist even if starting the show by other means (not using Watchout production software). Another option would be to add the "-TweenSampleMs TimeInMilliseconds" argument to Watchpoint, where TimeInMilliseconds would be something larger than the default interval (100 ms), for example "-TweenSampleMs 1000" to increase the sampling interval to one second. The drawback of this is that the hit testing for determining which pieces of media should go to which computers will become somewhat less accurate, and you might be missing some media for a few hundred milliseconds in on or more displays. In practice, this is quite unlikely to happen in most cases, and in case it does happen, it is quite likely to pass unnoticed. /Erik

In Watchout 6 we currently support three different flavours of Hap: Hap: Standard Hap, no alpha HapAlpha: Same quality as Hap (Standard), but with alpha channel. HapQ: Higher quality than standard Hap (mainly in the form of better color resolution), but with no support for alpha. There is now also HapQAlpha, which has the same quality as HapQ, and with aalpha channel. This is not (yet) supported in Watchout. I hope this clears it up! /Erik

The Hap codec will not be affected by uninstalling quicktime. Support for prores and qt animation will not be affected either. In most cases you will not notice any difference, as long as you are not using any codec that is only available in quicktime. However, as mentioned earlier, the export function will not (yet) work without quicktime. /Erik

And not yet supported in Watchout. /Erik

Which encoder have you been using? One of the more common encoders was recently updated, and the new version is not compatible with Watchout 6.0.x. This has been fixed in Watchout 6.1. /Erik

Hello! Is the video presplit? There has been some issues with presplit HapQ videos in 6.0.x, but these issues have been resolved in Watchout 6.1. Which encoders have you been using? One of the most popular encoders was recently released in version 9, which is not compatible with Watchout 6.0.x, but this has also been resolved in Watchout 6.1. /Erik

The issue has now been resolved, and the fix will be included in an upcoming release of Watchout. /Erik

Hello! There have been some issues with HapQ when used in a presplit. We believe most of the issues have been sorted out, and the fixes will be release soon, but please let us know if you find any strange behaviour. There have not been any changes in the Hap standard for the past few years, so the version numbers you are referring to are for a specific implementation of the Hap codec. However, looking through the changes from version 8 to 9 of this codec, there have been some changes that could affect the playback in Watchout. Work is in progress on the issue. I will let you know when the issue has been resolved. /Erik

Yes, you can configure several Wiretags identically and connect to the same display computer to cover a larger area. They should work with any powered USB hub, in case there aren't enough USB ports on the display computer. However, when connecting more than a few (say four or more) to the same computer, Windows takes its time making all Wiretags available, so you may need to add a delay to the startup script, before trying to open them I'm Watchout. /Erik

I would recommend skipping the "-bf 2" option in ffmpeg, alternatively select an IPPP... gop structure (no B-frames) if using some other tool for encoding, for best playback performance. If encoding in constant quality, the bitrate gain from allowing B-frames is quite small (around 5%, but it depends somewhat on the kind of content), but the decoding process is a lot more complex, with the need to keep more reference frames in memory. If encoding using constant bitrate, it will be very hard (if at all possible) to tell the difference between the two (no B-frames or allow B-frames). If you're worried about the quality, just bump up the bitrate by 5-10%, this bitrate increase will have a much smaller impact on the performance than allowing B-frames. /Erik

Although we support Prores 4444 and Prores 4444XQ, I would not recommend any of these for playback. Both are high bitrate codecs aimed at editing, and are very heavy on the CPU. Prores 422 plays a lot better, but are still quite heavy on the cpu, and lack support for alpha. Since you need alpha, an alternative could be image sequences, which is supported in WO6 (tiff, bmp, png, jpeg, gif). The least CPU-intensive format is Hap-alpha. It is a compressed format, and the quality is not as good as prores, but if you are happy with the results, I would recommend using this format. /Erik

Sounds like a possible bug. If you need further assistance, please contact support and provide a video file that shows the behaviour. /Erik

The manual for Watchout 6 actually mentions both naming conventions (extension of the folder or extension on the files), but I can confirm that only one of them (extension on files) seems to work. Example: If you have a video "Background.mov" and two displays, "Disp1" and "Disp2", and you want to use pre split, create a folder named "Background", and put the pre split video files in that folder, using the names "Disp1.mov" and "Disp2.mov". According to the manual it should be possible to do the opposite: Name the folder "Background.mov" and name the movie files "Disp1" and "Disp2", but apparently this has stopped working. /Erik

Are you sure Watchout is allocating all that memory? Watchout is still a 32-bit application, and as such it cannot allocate more then 4 GB of memory before it runs out of address space, which is quite far from the 16 GB installed in the machine. /Erik

Yes, you are correct, GPU acceleration is only used for Hap playback. /Erik

There has been some changes in Watchout regarding adding media in 6.0.1 which will be released soon. Since I cannot see the problems you are experiencing here (neither in 6.0 nor in a 6.0.1 beta), I don't know if these changes would make any difference for you, but possibly it could. /Erik

Hap is based on the DXT1 and DXT5 texture formats, which are decoded directly in the GPU when using HAP in Watchout. For better compression, an additional stage of compression is usually added (snappy), which is decoded in the CPU. The snappy algorithm is very fast at decompressing, so CPU load is not an issue here. /Erik

Which version of Watchout are you using? I had some test running during the weekend, with looping and free running h264 videos, and it still plays in sync after 60 hours, using Watchout 6. If the problem persists, please contact support@dataton, preferably with a minimal test case that shows the problem. /Erik

Yes, there has been another issue with the prores decoder, affecting certain resolutions. One video played ok when not looping, but the output when looping looked very strange. With another video it was the exact opposite. The frame rate should not be the problem, rather the resolution. This has however been solved, and will be included in the upcoming service release of Watchout 6.

It should have affected all six flavours of prores (Proxy, LT, SD, HQ, 4444 and 4444XQ), but I may be overlooking something here. Do you have quicktime installed on the system? If Quicktime is installed, Watchout may have used the prores decoder in Quicktime as a fallback when looping failed with our own decoder. /Erik