Erik Rönnqvist

Is there anything else besides video in the Hap file (audio track(s) for example)? I have managed to reproduced similar issues with Hap files containing audio in Watchout 6.2.1. Is the Hap movie stored in a .mov-file or something else? What happens in your case is probably that Watchout fails to play the Hap file using the normal playback mechanism, and when this fails, it reverts to trying to play the file through Quicktime instead. Regarding the pink colors for HapQ, have you ever seen it on a display computer, or is it only in the production software? Do you see the pink colors when displaying the actual movie (Best Quality preview) or only when you have selected "Video as thumbnails"? One last reason I can think of is if you are trying to play a HapQ+alpha files, which is currently not supported in Watchout. As of now, Watchout supports Hap, HapAlpha and HapQ. /Erik

Regarding the Hap and audio issue, where Watchout does not recognise the embedded audio: Have you installed any codec packs or similar on the computer? Haali media splitter is included both here and there, in encoding applications for example, and may cause issues like this. /Erik

Are you somehow trying to export to a Hap file, or are you trying to export a show containing hap file(s), and in that case which format are you trying to export to? /Erik

Yes, going online may take quite a while if you have very long timelines, where at least some parts of it contain a continuously changing tween parameter. The reason is that Watchout needs to sample the timeline(s) at quite short intervals to determine which media is visible on which display server(s). Only media that is actually visible at some point during the show on a certain server will be transfered to that server. The reasoning behind this is to shorten the time it takes to transfer media as well as to preserve disk space on the display servers. That said, if you turn on live update, the process will be faster, since in that case all media used in the show will always be transfered to all display servers, thus eliminating the need to sample the timeline(s). /Erik

As long as the network is properly configured and the switches are of good quality, multicast should work just fine. A few things to keep in mind: Run the cluster on an isolated network, which as few things as possible connected Use high quality smart switches Make sure IGMP snooping is turned on in the switches (which it probably is by default) Prefer to use one switch with many ports, instead of several switches with fewer ports in cast you want to connect many machines. That said, during testing we did run 64 streams without multicast on a local network consisting of 64 computers connected by 3 pcs 10 Gbit switches with 24 ports each. Each stream was filmed content 1920x1080 at 30 fps. Network load was around 80% and it was running for days without issues. /Erik

As mentioned in an earlier post, rebuilding the cache should help. I tried reproducing the issue without success, which makes it quite hard to debug. A more detailed description of the steps taken for this error to appear would be helpful. /Erik

You have to be a bit more specific here. Are you looking at the movie playing on a display computer, or are you looking at the production software? In case you are looking at the production software, what setting do you have for stage preview (Best Quality / Video as thumbnails / etc)? If playing HapQ and displaying just thumbnails in the stage preview, the colors may be off (usually pink, this is a known issue), but I have never seen it with a movie playing. Are you using a show created in 6.2, or was it created in an earlier version an opened in 6.2? Are you just trying to play a HapQ movie, or are you using it to texture a 3D model? Watchout currently has no support for HapQAlpha so I will assume you are talking about HapAlpha. Dropping frames usually indicates that the disk is not fast enough for the content. What is the resolution and frame rate of the movie, and how fast is your disk? /Erik

This is a bug in 6.2, which has now been fixed. The fix will be included in Watchout 6.2.1. /Erik

No, NDI in Watchout is used for input only. /Erik

Yes, there could be a difference between production and display software (although I have not seen any except for the quality), since they use different streams. For the preview in production software, a low-bandwidth stream with lower resolution and quality is used, if available. This can be good to know if you are looking at NDI in Watchmaker and think the quality is not that good. The reasoning behind this is that preview is nice, but you don't want to waste too much bandwidth on it. /Erik

NDI should be the simplest and cheapest solution, as it requires no extra hardware. Download the NDI tools from NewTek and you can do screen capture, generate test patterns etc, that can be displayed in Watchout. The NDI tools also includes a VLC plugin, making it possible to stream any content VLC can play over the network using NDI. /Erik

Could you please tell under which circumstances you get a black screen when pausing and NDI sender? I have never seen it myself, Watchout has always kept displaying the last frame received during my testing, until you leave the cue, of course. It could be debated which approach is correct, but I think it makes sense for Watchout to handle NDI in the same way as other capture sources. /Erik

Yes, both display and production software use the built in Hap decoder. /Erik

Virtual displays use some resources, but I doubt that is the problem here, although I'm not ready to rule it out. What kind of hardware are you running on (GPU, RAM size etc), and which Windows version? Please give us an update when you have had the time to upgrade to 6.1.6 and tested the reencoded files. /Erik

Hello! There has been a few bug fixes between 6.1.1 and 6.1.6, so trying a later version could solve your issue. Have you installed any codecs on the display and/or production computers? The Hap decoder is built in into Watchout, so there is no need to install an external Hap codec. In fact, installing an external Hap codec may confuse Watchout and give similar errors. Are the files looping? How many are you trying to play at the same time, and which resolution? It could possibly be a problem with playing too many files at the same time, but without knowing anything about the show it is hard to tell. Is it standard Hap, HapQ or HapAlpha movies? Also be aware that by checking the looping checkbox in the Cue's dialog, the resource usage will increase quite a lot. /Erik

Yes, you are correct. Unfortunately there is currently no audio support in NDI. /Erik

Increasing the bitrate (while keeping all other parameters equal) for h264 or MPEG-2 will increase the CPU load, not the opposite. The reason is quite simple, higher bitrate means a greater amount of compressed data to process, which increases the CPU load. I just did a test with a 4k h264 movie encoded at fixed bitrate 5 Mbit/s and 30 Mbit/s, and the 30 Mbit video uses about twice as much CPU in Watchout. It will probably be possible to find a codec that behaves in the opposite way, but for most of the common codecs it is a good idea to keep the bitrate as low as possible as long as you are happy with the picture quality. To increase the decoding performance for h264 and MPEG-2, it is a good idea to not use B-frames. If there is a setting for the number of reference frames to use in the encoder, it is also a good idea to keep this number quite low. 4 is a good starting point, going beyond that will hardly be helpful in terms of quality or lowering the bitrate, but the memory consumption and decoding complexity will increase dramatically. /Erik

Do you mean how you can tell if the movie is limited or full range? The easiest way is to encode a video just like you did and play it in a player you trust not to do any conversions (I would tend to believe VLC is a good choice here). Set the desktop background to black and compare it to the darkest bar in the video. If the darkest bar in the video is lighter than the black desktop background, the video is most likely in limited range. /Erik

I have now tried encoding with some prores encoders, and all of them encode to full range by default. This means that the stretching does not really make sense anymore. This will be fixed in the next release of Watchout. As a side note, some years ago, when the prores decoder was implemented in Watchout, this was not the case. Many encoders used the limited range then. /Erik

The prores decoder in watchout assumes that the video is encoded in limited range, meaning that the luma range (translated to 8 bits) is assumed to be 16-235, and the chroma range is assumed to be 16-240. In the process of decoding, these ranges are stretched to 0-255, which also means that the values 0-16 will all be mapped to 0, and the values 235(240)-255 will all be mapped to 255 for luma(chroma). This is the effect you are seeing in the sample movie you provided. The two leftmost bars have luma 0 and 16, which will both be mapped to 0 for display. Same goes for the two rightmost bars which have luma 239 and 255, which will both be mapped to 255, making them look identical. To further complicate things, in the header of a prores file, there is a field indicating if the pixels are in ITU-R BT.709-2 or ITU-R BT.601-4, which could be used to adjust the stretching automatically. Unfortunately this field is quite often empty, contains an incorrect value or simply says unknown, which makes it impossible to use. Which way is the correct way of doing it (stretching or no stretching) is up for discussion. /Erik

As I mentioned earlier, if the problem is in the production computer, try selecting "Video as thumbnails" in the Preview menu. That way the production software will not try to play the video in the stage window. There might still be issues when adding the video, so you might need to add it by selecting "Add Video Proxy" from the Media menu. /Erik

To clarify, there is no inherent 11 megapixel barrier in the Hap decoder. But there are some things to consider when encoding and testing performance to get correct results. 1. A single-chunk Hap movie has its limitations, since the part of the decoding that takes place on the CPU can only use one core. For better performance and to be able to play more movies, use chunked encoding. 2. When measuring how many movies of a certain kind you can play at once, it is important to use physically separate files. If not, the test is not valid. If you create several cues from the same media in Watchout, and they start at the same time, the playback engine will be shared among all the cues starting at the same time. This means that from a Watchout perspective, it is only playing one movie. If you create several cues from the same media, but they don't start at the same time, there will be as many instances of playback as there are cues, but the test is still not valid, since the Windows Cache is playing us some tricks here. If you have plenty of RAM in the machine, windows will cache the most recent parts of the movie, and only the cue that starts first will actually have to read the file from disk. The rest of the cues get the file directly from RAM. While testing single chunk movies you are likely to hit a barrier around 500 MB/sec, since that's about as much as a single core on a modern CPU can handle when decoding the part of the Hap format that uses the CPU. It is perfectly possible to play 30+ megapixel Hap movies in Watchout. What you need is a fast computer, very fast disk and a Hap movie encoded with chunks. /Erik

It means that the GPU in your computer is not able to create a texture of that size, which is required to be able to play the movie. Most likely the limit is 8192x8192 pixels. This is not a limitation om Watchout, but rather a limitation of the computer you are working on. If the problem only appears on the production computer, you can select "Video as thumbnails" in the preview menu, to avoid actually playing the video on the production computer. If the problem is on a display computer, you will either have to pre split the video, or get a more capable graphics card. /Erik

When creating an NDI source in Watchout, you enter a resolution for it, and it will always be rendered in that resolution. If the NDI input's resolution does not match, the frames will be scaled to the entered resolution before displaying. Watchout will even accept an NDI input that changes resolution along the way. The same goes for frame rate, Watchout will accept any frame rate from the NDI source, regardless of the rendering frame rate set in Watchout. I would recommend having the frame rate set in Watchout to equal or higher than the NDI source's frame rate. If WO:s frame rate is lower, it will have to skip frames in the NDI stream, and you might experience slightly higher latency. For smoothest possible playback of NDI streams in WO, frame blending is available, which is quite useful if the NDI source's frame rate is lower, especially if the frame rates are not multiples of each other. For example, if WO is rendering in 60 fps and the NDI source is 25 fps, by using frame blending you will get smooth playback. /Erik

I do seem to recall a bug where Watchout would not play prores with audio if the audio stream was stream 0 and video stream 1. The other way around was ok, and I can see from your post above that the first stream is audio. I don't remember in which version this was fixed, but your file could very well be playable in a more recent Watchout version. If you absolutely need to have video and audio in the same file, try to switch the order of the streams so that video is first. Stream switching can easily be done in ffmpeg using the -map option without having to reencode: ffmpeg -i input.mov -map 0:1 -map 0:0 -map 0:2 output.mov will remap the file so that video is the first stream without reencoding. /Erik