DR TCP Transport Control - behavior issues

Ask software engineering and SDK questions for developers working on Mac OS X, Windows or Linux.
  • Author
  • Message
Offline
User avatar

Max Paperno

  • Posts: 54
  • Joined: Sun May 02, 2021 12:49 am
  • Location: Upstate NY, US
  • Real Name: Max Paperno

DR TCP Transport Control - behavior issues

PostMon May 17, 2021 8:28 am

Hello!

I'm working on a basic client for the Resolve TCP Transport Control, v1.2 as described in the DR manual, Chapter 121 (of the v17 edition). Although it's mostly working "as advertised," I've run into a couple issues so far.

DR Studio v17.2 Build 11 (same issues with 17.1), Win 10 (20H2 19042.985, latest updates as of this post). Using Python's socket implementation. Client and DR "server" are on same machine.

  1. When sending play command, all the forward play speeds work as expected. Eg. sending:
    Code: Select all
    [04:00:00:00] [70:6c:61:79] [00:00:80:3e]
    [cmnd length] ["play"]      [0.25 (little-endian)]

    will play forward at 1/4 speed, 0.5 at half speed, 1.0 at full, etc. However, doing the same thing with a negative play speed seems to confuse DR.

    If I send -0.25 (00:00:80:be), Resolve just crashes, with this in the debug log:
    Assertion failed: m_PlaySpeed > 0.0f, file C:\jenkins\workspace\resolve\Resolve\Cyclone\UI\Player\UiPlayerModel.cpp, line 5943

    But, if I send -0.5 (00:00:00:bf), then it plays backwards w/out crashing... at 1/4 speed. I have to send -0.75 (40:bf) for -1/2 speed, -1.0 (80:bf) for -3/4 speed, and -1.5 (c0:bf) for -x1 speed. After that, -2.0 (00:c0), -4 (80:co), -8 (00:c1) all work as expected.

    Either I'm missing something, or something is a bit off :P in the DR code?
  2. On the Fairlight page, the play speed values are interpreted in some other bizarre way... sending 0.25 starts 1x playback, going up to x16 when sending 8.0, but then when going back down, from, say 8.0 to 4.0, the playback speed actually increases to x64, like the 4.0 is being treated as relative instead of absolute. Pretty hard to describe, but clearly not working like on all the other pages.
  3. The goto command also acts strangely. It doesn't actually move the playhead (or change the preview), except on the Color and Deliver pages. On the other pages the command seems to be ignored... but it's more complicated than that.

    When on any UI page, after sending a goto, a subsequent gettc reports the same timecode which was just set with goto, as if the command worked (which on Color & Deliver, it does).

    If the UI is on the Cut or Edit pages, the goto is ignored but gettc keeps reporting incorrect position until the playhead is manually moved.

    If the UI is on Media or Fairlight, the goto appears to be ignored, unless you switch to any other page after that (w/out moving the playhead)... where you'll find that the position has actually changed to the TC specified in goto.

    Maybe I'm not understanding what goto is supposed to do?

Does anyone actually use this protocol? I can find zero information on it, except what is in the manual (and one old thread on this forum regarding the "advanced" setting to enable remote control).

I can't find any other/better (and inexpensive) way to smoothly control forward/reverse playback speeds ([Shift]J/K/L are too "chunky"]. So I got a Python script which reads from a HID and sends playback commands to DR via TCP socket. Seemed like it should be easy. The playback speeds work great, except as mentioned above. I would like to use goto for quick scrubbing/jumps per x frames/seconds (after gettc/getframerate). I plan to publish the code once I know what works or not (but I could post it sooner if anyone wants to play/test).

Let me know if I can provide any further information. I tried to keep this as brief as possible for now. :?

Thanks!
-Max
Offline
User avatar

Max Paperno

  • Posts: 54
  • Joined: Sun May 02, 2021 12:49 am
  • Location: Upstate NY, US
  • Real Name: Max Paperno

Re: DR TCP Transport Control - behavior issues

PostMon May 24, 2021 5:54 pm

Code: Select all
> ping BMD

Pinging BMD with 3,545 bytes of data:
Reply from forum.blackmagicdesign.com: Destination unreachable

Return to Software Developers

Who is online

Users browsing this forum: adamtow and 60 guests