Jump to content

Mike Fahl

Member
  • Posts

    723
  • Joined

  • Last visited

Posts posted by Mike Fahl

  1. There's a general constraint in WATCHOUT of processing about 60 commands per second. This is regardless of command type, and not specific to the setInput command. If you exceed this limit, command processing may lag or may eventually cause processing to stall (in WATCHOUT or, more likely, in the external program feeding commands to WATCHOUT).

     

    In some cases, when you want to control numerous inputs, this may get in your way. Hence, we intend to lift this limit in an upcoming version of WATCHOUT. I have no ETA for this at this point, though, so this is just FYI, that we're aware of this limitation and intend to improve it.

     

    Mike

  2. > When you say it 'coasts' how long does it coast for? are we talking frames or seconds?

     

    Frames.

     

    > does it jump back to the last frame it 'heard' or will it stay where it finished coasting?

     

    No, it will stay where it finished coasting.

     

    Mike

  3. H264 .mov often fails on watchout.

    H264 .mp4 files are rock solid instead.

     

    Do you have an example of a "H264 .mov that often fails on watchout"? If so, please send it to support@dataton.se so we can take a look. In general I'd say the two container formats are equivalent. While a MOV file can contain a wider variety of things than an MP4, the MP4 standard is derived from the MOV file format, so at the core, they're pretty much the same, and are internally treated in the same way in WATCHOUT. Neither touches QuickTime these days, but play using WATCHOUT's native codecs.

     

    Mike

  4.  

    How do the watch out slaves handle timecode playing and pausing?

    I Understand that I feed timecode into one slave and the rest just keep up via the network, I just want to know how I handle "pausing" the timeline

     

    Timecode will control the main timeline in WATCHOUT. Start the timecode and WATCHOUT positions and plays the main timeline in sync with the timecode. Stop the timecode and the timeline stops (after a brief period of "coasting" to account for timecode dropouts). You feed this into the cluster master, and any slaves will follow suit.

     

    Mike

  5. It seems your two methods for sending commands to the projector behave differently. One difference I can think of is that the TCP connection from WATCHOUT remains open for some time after using it (dont' recall the exact time), while netcat likely drops the connection right away. You may be able to get more details on what's different by monitoring the communication using Wireshark.

     

    Mike

  6. I've played 4k H.264 content in WATCHOUT with very good results. The aspect ratio doesn't really matter, as long as you stay withing 4096 pixels in both directions and your hardware is capable of decoding the video. I.e., 7680x1080 should work as well as 3840x2160 (same number of pixels).

     

    Mike

  7. Videos of up to 4096 pixels in width may play without pre-splitting (assuming adequate hardware, of course). Beyond that, you must pre-split due to hardware (graphics card) limitations.

     

    Hence if you're using four outputs from a single computer, you may be able to avoid presplitting by playing a single, wide video (again, asuming adequate hardware and depending on encoding format). Pre-splitting may still offer a performance benefit, though (especiellay on computers with lots of CPU cores).

     

    Mike

  8. free-running means that WATCHOUT triggers the clips in sync but then does not care about synchronity of those clips anymore. Computers can run at different speeds even if you think that they are identical and if WATCHOUT does not check synchronity anymore after the start of a video.

    The above is statement incorrect. WATCHOUT maintains sync across computers even when videos run as "free running". They're still synchronized. The term "free running" here merely means they will not pause when the enclosing timeline is paused.

     

    Mike

  9. I believe you should render the videos horizontally as 1920 wide by 1080 tall. I.e., you'll need to rotate them out of AE or whatever you use to produce them. WATCHOUT will then rotates them according to the screen rotation. So if you already pre-rotated them to vertical orientation, WATCHOUT will then rotate them again, ending up with the wrong orientation.

     

    While this behavior may feel backwards and confusing when using a display rotated by 90 degrees, it makes more sense if the display is rotated 12 degrees or 45 degrees.

     

    Hope this helps.

     

    Mike

  10. Take a look at the network control prococol in the manual, which should give you an idea on what kind of control you have over WATCHOUT. What CMS do you have in mind? Sheduling should be fairly straightforward, However, editing of shows would have to be done using the WATCHOUT production software. An external control system can excert some control over specific aspects of a running presentation, but can not really alter it in any easy way. You could, for example, trigger independent "auxiliary timelines", control "conditional layers" and use "inputs" to control tween parameters (position, scale, opacity, etc).

     

    Hope this helps.

     

    Mike

  11. Actually, you don't need to save the show to persist the MAC addresses for wakeup. Those are stored elsewhere on the production computer (typically in the registry), so you should be able to wake up the displays even if you didn't save the show after power down.

     

    Mike

  12. We're able to run normal images, aswell as swf's that do not require a network connection. It's just for the flash files that do require an internet connection as for example the Instagram.

     

    So what happens? Do they show up at all? I.e. do you see anything rendered from the SWF, such as static items, background color, etc. Is it only the pieces that originate fmor the internret that are amiss? If so, it sounds like its a sandboxing issue. See the description of this topic in the academy docs.

     

    Locally opening the flash works fine and loads perfectly, but when it loads via the DIS it does not show anything.

     

    How do you "load it locally"? E.g., drag it into a browser?

     

     

    Hi Folks .... in a similar boat here as we are looking to work around twitters API rules to be able to bring in a working SWF file accessing twitter feed.

     

    That sounds like a different issue than the one discussed here. The Twitter API has changed, requiring authentication and using a different format to access the data. You need to make "developer arrangements" with Twitter to get the proper credentials to make this work.

     

    Mike

×
×
  • Create New...