Erik Rönnqvist

Which Watchout version are you using? Prores is not supported in releases earlier than Watchout 6. Our recommendation is usually to have separate files for audio and video. If you are running WO6, please try encoding to a file only containing the video and see if that makes a difference. Although prores is supported in Watchout, I would not recommend it for playback, since it is mainly an editing format. Quality is excellent, but files are quite big, and requires quite a lot of resources to decode. Watchout supports all currently available flavours of prores: 422 Proxy 422 LT 422 Standard 422 HQ 4444 4444 XQ /Erik

Hap video are usually in .mov files, so it should be ok. Does the hap video play, meaning that thumbnail generation is the only problem? Which Hap flavour is the file in? (Hap, HapAlpha or HapQ)? Please note that Watchout has no support for HapQAlpha. If you need to run Hap with alpha channel, please stick to HapAlpha. /Erik

Hap support is built in into Watchout, so there is no need to download a codec. Which Watchout version are you using? Hap is not supported in version 5 and earlier. /Erik

HapAlpha would be my first choice when you need transparency. If the quality is not good enough you can try quicktime animation (qtrle). The files will usually be huge for qtle, except for some types of content which can easily be compressed. Image sequences could also work. Targa (.tga) files support transparency and are fully supported in Watchout. .png files with transparency should also work. /Erik

From your description it looks lika a problem with the color conversion shader that is used when playing HapQ movies. Was it HapQ movies that you were trying to play? Did you switch around between Hap and HapQ (by pointing the media object to another file, or possibly switching files)? Was the video plain or presplit? If you find a way to reproduce the issue, please let us know and we will try to reproduce the issue here. /Erik

A video of such size will consume about 40 MB / s (megabytes, not megabit) for Hap at 30 fps, and around 80 MB / s for HapQ at 30 fps. For 60 fps you will have to double the numbers, approximately. This should not be a problem for a WP2 to handle, but I would recommend using 2 or 4 chunks when encoding, if possible. It might run without using chunks. Be aware though that the disk will fill up quite quickly. HapQ at 30 fps will need somewhere around 4.5-5 GB per minute, meaning that a 10 minute movie will more or less fill up the disk. /Erik

Are you absolutely certain that the tiff files are uncompressed? If they are, their size should be equal down to the byte. Although compression would help with the disk load, it adds some (or a lot) of work to the CPU. How did you measure the read speed of the disk? Some test applications use buffers that are too small when testing, meaning that most or all of the transfer speed measured is due to caching somewhere in the system, which is always faster than reading from the disk. You could give targa (.tga) image sequences a try. It is fully supported in Watchout, and is the fastest way to play an uncompressed image sequence, since the internal pixel byte ordering is correct. Tiff files usually need some byte-flipping, which adds a slight delay. /Erik

Have you tried playing the audio file in VLC and one of the video files in another instance of VLC? Does it happen then as well? /Erik

Just add "-r 30" (without the quotes of course) before the -i argument in ffmpeg, and the video will be 30 fps: ffmpeg -r 30 -i Img%06d.tiff -vcodec hap -format hap_q -chunks 4 MovieHap.mov /Erik

Yes, it is possible to use an image sequence as input to ffmpeg. The syntax is far from obvious: If the files are names Img000001.tiff, Img000002.tiff, Img000003.tiff ...., you can use the following command line: ffmpeg -i Img%06d.tiff -vcodec hap -format hap_q -chunks 4 MovieHap.mov The character after the %-sign is a zero, not a capital o. The "%06d" means "an integer with 6 digits, padded with zeroes to the left if shorter than 6 digits". This means that if the files are named Img0001.tiff, Img0002.tiff... You would use "Img%04d.tiff" instead. The "at least one HAP frame was not decoded properly" means exactly what it says, that Watchout failed to decode a part of the file, which in its turn means that there is an error in the file, or possibly a bug in Watchout. A HapQ at 3200x3200 in 60 fps will require about 400 megabytes per second, which is pushing the limits for many single SSD:s. If you have several disks in a RAID-0 configuration you will of course get higher speeds. I would advise you to actually measure the disk performance and compare to the data rate of the movie(s) you are trying to play. AS SSD Benchmark can be downloaded for free and provides a reasonable estimate of the disk speed. /Erik

As I have mentioned in previous posts, given a certain resolution and Hap flavour (Hap, HapQ or HapAlpha) there is no way to control the bitrate. The compression methods are fixed and leave no room for any adjustments. If the bitrate is too high, you will have to render to a lower resolution, or, if playing HapQ, switch to Hap. It the video plays fine without using chunks, don't bother to use chunks. Each chunk will add a slight overhead, both in the form of a slightly higher decoding time and slightly larger files, but the difference is usually (close to) negligible. If you want to use ffmpeg, there are windows binaries to download here: http://ffmpeg.zeranoe.com/builds/ Assuming you are running windows: Just put ffmpeg.exe and the file you wish to convert in a folder, open a windows command prompt and navigate to that folder and issue the following command: ffmpeg -i Movie.mov -vcodec hap -format hap_q -chunks 4 MovieHap.mov This will convert Movie.mov to a HapQ movie using 4 chunks and store the result in MovieHap.mov. Here hap_q can be changed to hap or hap_alpha if you wish to use these flavours instead of HapQ. Chunks can be any number between 1 and 64. There is no point in using more chunks that there are CPU cores in the computer. It is also a good idea to keep the number as small as possible, since each chunks adds a slight overhead. ffmpeg's user interface is not the easiest to master, but once you get the hang of it you really appreciate the flexibility. You can do just about anything, and the number of codecs supported is very long. Over time, the most popular codecs (h264 for example) has evolved to a very high performing codec both in the terms of quality and encoding speed. /Erik

If using chunks makes sense depends on the resolution. If the videos play without using chunks, you are (slightly) better off without using chunks. If not, as few chunks as possible, to get reliable playback without stuttering, would make most sense, since each chunk adds a slight overhead. In case you need to use chunks, four chunks should cover most cases. Going beyond 8 chunks in a WP4 will most likely just make things worse. /Erik

As Rainer mentioned, make sure you put enough memory modules in to utilise the full memory bandwidth. While Watchout is a 32-bit application and as such cannot adress more than 4 GB of memory, there is absolutely a benefit in having more that 4 GB, since watchout can then get its entire adress space mapped to ram. If there is only 4 GB physical RAM in the machine, that will have to be shared among all running processes, including the operating system. This assumes that you are running a 64-bit version of Windows, of course. Additionally, Watchout can in many cases benefit from even more RAM, since windows will use any available RAM for caching files, including media files used by Watchout. However, I don't think going from 8 GB to 16 GB or going from 16 GB to 32 GB will make a big impact on performance in most cases. It might not even be noticeable, while in other cases where you are pushing the system it could make a difference. /Erik

Hello! Thanks for taking the time to record a video and share, it makes everything a lot easier to understand. While I don't (yet) have any explanation for what is going on here, there are a few things worth pointing out. The cues are obviously free running since the videos still play after hitting a pause cue, are they also looping? I will not go into the details here, but by checking the looping checkbox, playing the cue will use more resources (primarily in the form of higher memory consumption), as compared to playing it non-looping. There are also three different cases when playing movies that affect performance in a non-obvious way: 1. As Mike pointed out earlier, if identical cues (identical spec, and same movie file) start at exactly the same time, Watchout will detect this and will only decode one instance. 2. If playing identical cues, that are not started at the same time, they will play as separate instances, meaning that the number of decoders decoding the movie will be the same as the number of cues playing at the same time. However, if there is enough memory in the computer, the file will end up in the Windows file cache, and it will only have to be read from disk once, since all instances of the decoder (except the first one of course) will end up getting the file from the Windows file cache. This means that CPU load will be as high as when playing physically separate files, but disk bandwidth used will in many cases be next to nothing, since the file is only read once for all instances. 3. The common scenario, when you are playing different files, is the most demanding, since there is no sharing of decoders and the disk cache will not make a difference, since all the files are different. There is an exception to the above, though. When playing image sequences the Windows cache is bypassed. Although my points above do not necessarily directly relate to the problems you have experienced, I though it would be worth mentioning them here. /Erik

Hello! Are B-frames enabled in the MPEG-2 videos? If yes, please consider encoding without B-frames. The same goes for h264, you are much better off without B-frames. B-frames are great when you are trying to maximise the quality for a given bitrate (for example if you are trying to squeeze in as much as possible on a DVD disc), but they increase the decoding complexity quite a lot, as well as increasing the memory requirements for decoding. In practice, if encoding at constant quality, you can expect a bitrate reduction of around 5% when enabling B-frames. You will be much better off if you disable B-frames, and if you are worried about the quality, just bump up the bitrate by 10%. The bitrate increase will have much less impact on performance than using a slightly lower bitrate with B-frames enabled. By skipping B-frames, the decoder can decode the frames in the same order as they are going to be displayed, which reduces the risk of stuttering. If using B-frames, the decoder may need to decode several future frames to display a frame, which of course takes time. /Erik

Mike, when you saw the issue, I assume it was in 6.1.4 as mentioned in the previous post, correct? Was the media presplit? Was there anything else out of the ordinary? Was there a preview file attached to the HapQ movie? There has been some problems with presplit and/or media containing a preview, when the video format is HapQ. These issues have hopefully been fixed and will be in the next release of Watchout. If you saw the issue when trying to play a HapQ movie without presplit and/or preview, please let me know. /Erik

There is no way to set the bitrate i Hap, that's why ffmpeg ignores your bitrate setting. It is inherent to the compression algorithms used in Hap that there is no way to control the bitrate, except for the fact that HapQ uses a higher bitrate than regular Hap. This means that the only way to lower the bitrate if using HapQ is to switch to standard Hap (or lower the resolution). I you want a lower bitrate when using standard Hap, the only way is to lower the resolution and scale the movie in Watchout. /Erik

Using all I-frames is usually a bad idea, unless you need to jump around the movie very quickly. All I-frame encoding needs a much higher bit rate to achieve the same quality. If I understand AME correctly, N-frames is the number of frames between I-frames, which is the same as the key-frame interval. Normally, 1-2 I-frames per second is a good compromise between quality and performance, which translates to setting N-frames to 15-30 for a 30 fps movie. Longer I-frame intervals can in some cases produce the "pumping" artefacts. M-frames is the number of B-frames between consecutive I- and P-frames, so I would assume setting this to 0 would eliminate the B-frames. Eliminating B-frames greatly reduces the (CPU/GPU and memory) load of the decoder. The price you have to pay is slightly less compression (if encoding with constant quality) or a slight reduction in quality in case you are encoding with constant bitrate. If you are worried about the quality, just bump up the bitrate by 10% as compared to when encoding with B-frames. /Erik

Hello! A good start is the Watchout 6 user guide which is available for download at dataton.com. Watchout does not split the files for you, you will have to do that yourself, considering overlaps for edge blend areas etc. The users guide has a basic explanation for this. When the files are split, you will have to use a video proxy to be able to play the files. Please note that there are some naming conventions you have to follow for it to work. I would recommend putting the extension on the individual files, not the folder containing the pre split files. Additionally, the files need to have the exact same name as the display they are to be played on. /Erik

Given a certain resolution and hap flavour (standard, HapAlpha or HapQ), there is no way to control the bitrate. The Hap format uses a fixed compression scheme; Dxt1/5/Y texture format + snappy compression, where snappy is a LZW-like compression. The snappy decompressor is able to handle approximately 500 megabytes per second per core on a modern CPU. Going beyond that you will have some stuttering. Of course CPU-speeds vary a lot, so the 500 megabytes per second is a very crude approximation, your mileage may vary. One way around this is to use chunked encoding, where each frame is split up in a number of chunks which can be decoded independently, thus utilising more cores in the CPU. There are at least two encoders that can do chunked encoding, please see the links that jfk posted above. As for the number of chunks to use, there is no point in using more chunks that there are CPU cores in the system. Each chunk added gives a (very) slight overhead in the form of less compression. Under normal circumstances the difference should be less than 1 percent in file size. A good stating point could be 4 chunks. /Erik

Hello! Unfortunately I have no idea about after effects. I have tested chunks mainly with ffmpeg using the following command line: ffmpeg -i Movie.mov -vcodec hap -format hap_q -chunks 8 MovieHapQ.mov This will convert Movie.mov to a HapQ movie using 8 chunks, which means that Watchout can decode the movie using 8 threads simultaneously, which could give a major performance enhancement, as long as the disks are able to keep up. /Erik

Hello! Good news is that we have managed to reproduce the problem here. We are working on it, and a fix will most likely be included in the next service release of Watchout. /Erik

Is the show converted from a previous version of Watchout? What happens if you create a new show, add the files as a presplit and try to play, do you still get the same problem? Regarding the color issues, we are talking about output from the display computers, right? Or are you referring to the preview in the production software. Or both? /Erik

Are you absolutely sure that all files in the proxy folder are in the same format? If not, you might get color issues. Mixing Hap and HapQ in the same folder when used as a proxy is usually not a good idea. Currently, this is not detected in Watchout, the color will just be wrong. This should be fixed though. /Erik

Regarding the Hap presplit issue, which Watchout version are you referring to? There has been a few bugs in this corner, but to my knowledge all had been sorted out for 6.1.2. Could you please be a bit more specific about the error, and I will have a look. /Erik