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: 72
  • 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: 72
  • 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
Offline

ambustion

  • Posts: 14
  • Joined: Mon Jun 24, 2019 4:36 pm
  • Real Name: Brendon Rathbone

Re: DR TCP Transport Control - behavior issues

PostMon Aug 09, 2021 6:14 pm

Hey Max,

I found same as you, I just think it only works properly in full integers. What's more is some commands only work in color page, and some in edit. Would be very interested in seeing what you have working so far if you are interested in sharing. I have everything working you mentioned with python, but first time trying tcp so would love to compare.

It's super handy for grabbing stills or jumping to notes from a treelist if you are making guis at all though. Seems pretty solid in the color page.
Offline
User avatar

Max Paperno

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

Re: DR TCP Transport Control - behavior issues

PostSat Aug 14, 2021 8:56 pm

Hi Brendon,

FWIW, I submitted a support ticket regarding this issue to BMD, and eventually that led to this reply on June 10th (2021), but I haven't heard anything since then.

I was advised that a developer was assigned to look into the case. This limits our current visibility in the progress of this case, but I will let you know if we get any specific responses or follow-ups.


For this and other similar reasons (lack of support, constant bugs, proprietary everything) I've decided not to invest any more resources into DR or BMD at this time.
Offline

ambustion

  • Posts: 14
  • Joined: Mon Jun 24, 2019 4:36 pm
  • Real Name: Brendon Rathbone

Re: DR TCP Transport Control - behavior issues

PostSat Aug 21, 2021 1:27 am

Too bad. I agree it'd be great to have a line of communication with the developers. They add things I want every update for API and I just use it to increase productivity in my own workflow so understand if you are not using it to just poke around as a bonus it would be frustrating.

If I get any headway I'll share with you as well.
Offline

piersdeseilligny

  • Posts: 22
  • Joined: Tue Apr 07, 2020 8:45 pm
  • Real Name: Piers Deseilligny

Re: DR TCP Transport Control - behavior issues

PostThu Oct 07, 2021 10:58 am

I'm getting this exact same behaviour in Resolve 17.3.1. If anyone working on Resolve reads this, can we hope for a fix in a future update?
Offline

Peter Chamberlain

Blackmagic Design

  • Posts: 11303
  • Joined: Wed Aug 22, 2012 7:08 am

Re: DR TCP Transport Control - behavior issues

PostThu Oct 14, 2021 1:10 am

This TCP control is really designed some years ago for the color page for a remote ctl to use in viewing sessions so its functionality is basic. It't not trying to be nor meant to be a protocol to make a full featured TCP controller.
We now have a better control across all pages with the Speed Editor via BT or USB.
DaVinci Resolve Product Manager
Offline

piersdeseilligny

  • Posts: 22
  • Joined: Tue Apr 07, 2020 8:45 pm
  • Real Name: Piers Deseilligny

Re: DR TCP Transport Control - behavior issues

PostFri Oct 15, 2021 8:25 am

Thank you so much for the response! While the speed editor is great to use while editing, it isn't something I would want to ask someone else to use while I'm editing or grading - whereas a device such as a stream deck, or a locally hosted web page accessible via a phone, etc.. that can control resolve via this TCP protocol could be more flexible in certain use-cases, can be used by several people at a time, etc...

Obviously the speed editor will always be a lot smoother and better integrated (simply because of the significantly broader feature set than is exposed to developers) but that also means that having the TCP Protocol behave as expected and described in the manual wouldn't lead to software which overlaps with the speed editor in terms of functionality or use-cases, which is understandably something I imagine Blackmagic Design wants to ensure.

A working TCP Protocol would simply open up a few more doors to users and developers for a few scenarios which are admittedly niche, but could really benefit from the quality-of-life improvements enabled by functional TCP control.
Offline
User avatar

Max Paperno

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

Re: DR TCP Transport Control - behavior issues

PostFri Oct 15, 2021 8:45 am

Peter Chamberlain wrote:This TCP control is really designed some years ago for the color page for a remote ctl to use in viewing sessions so its functionality is basic. It't not trying to be nor meant to be a protocol to make a full featured TCP controller.
We now have a better control across all pages with the Speed Editor via BT or USB.

We're just looking to use the documented functionality, which is currently broken and/or not clearly described (eg. nothing about it being just for the color page). No one said anything about "full featured TCP controller." Not sure what the SE has to do with this either (can the SE be controlled via API? don't think so), and besides it does not actually provide the type of playback control I was looking for.

If similar functionality could be achieved via the Python/Lua API, that would be a workable replacement for the TCP protocol.
Offline

piersdeseilligny

  • Posts: 22
  • Joined: Tue Apr 07, 2020 8:45 pm
  • Real Name: Piers Deseilligny

Re: DR TCP Transport Control - behavior issues

PostFri Oct 22, 2021 8:16 am

Just looking at the 17.4 release notes, i've seen "Scripting API support to set playhead position on the timeline."

Will test it out, but sounds super promising!

EDIT: Yep, it works great. Thank you so much for implementing this!
Offline

SeldomSeenKid

  • Posts: 30
  • Joined: Mon May 31, 2021 1:16 pm
  • Location: Germany
  • Real Name: Michael Adrian

Re: DR TCP Transport Control - behavior issues

PostFri Nov 19, 2021 4:00 pm

Hi There!

I am trying to connect to DVR using a TCP client but it refuses to connect.
I have added "System.Remote.Control = 1" to my preferences (incl. a restart and try to connect to port 9060 as written in the manual.

Am I missing something here?
Good discrimination comes from experience.
Experience comes from bad discrimination.
Offline

piersdeseilligny

  • Posts: 22
  • Joined: Tue Apr 07, 2020 8:45 pm
  • Real Name: Piers Deseilligny

Re: DR TCP Transport Control - behavior issues

PostTue Nov 23, 2021 3:15 pm

SeldomSeenKid wrote:Hi There!

I am trying to connect to DVR using a TCP client but it refuses to connect.
I have added "System.Remote.Control = 1" to my preferences (incl. a restart and try to connect to port 9060 as written in the manual.

Am I missing something here?


Does the example C code from the manual work for you? I had a bit of difficulty connecting to DVR until I used the example C code as a guide, to ensure I was sending the right data in the right order. It's a bit fiddly, and easy to accidentally disconnect if you don't send Resolve exactly what it's expecting,
Offline

SeldomSeenKid

  • Posts: 30
  • Joined: Mon May 31, 2021 1:16 pm
  • Location: Germany
  • Real Name: Michael Adrian

Re: DR TCP Transport Control - behavior issues

PostTue Nov 23, 2021 7:24 pm

Hi Piers,

The main issue is, that "netstat" (I am on Windows 10) doesn't even show port 9060 as listening. So DVR doesn't open it.

I don't use C for now but connecting from a 3rd party scripting software. I am 100% sure that this software handles the socket correctly since I can connect to everything else. I am also sure that my OS doesn't block this port as I added an exception to the firewall just to be 100% save). I also tried opening port 9060 from my scripting environment and it worked fine. So no blocking from OS side.

My assumption is that TCP transport control is only available in the Studio version, while I am using the free version.

BTW: I am using version 17.4.2.009 but previous versions just behaved the same way.
Good discrimination comes from experience.
Experience comes from bad discrimination.

Return to Software Developers

Who is online

Users browsing this forum: No registered users and 2 guests