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: 76
  • 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: 76
  • 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: 24
  • 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: 76
  • 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: 24
  • 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: 31
  • 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?
Online

Peter Chamberlain

Blackmagic Design

  • Posts: 13851
  • 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: 31
  • 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: 76
  • 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: 31
  • 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
User avatar

SeldomSeenKid

  • Posts: 390
  • 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 judgement comes from experience. Experience comes from bad judgement.
# Threadripper 32 core / 160GB / RTX4000 8GB / WIN10 #
# BMCC / DVR17.4.6 Studio / Speed Editor / Tangent Ripple / X-Touch One / X-Touch mini / Space Explorer / 5.1 HDMI#
Offline

piersdeseilligny

  • Posts: 31
  • 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
User avatar

SeldomSeenKid

  • Posts: 390
  • 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 judgement comes from experience. Experience comes from bad judgement.
# Threadripper 32 core / 160GB / RTX4000 8GB / WIN10 #
# BMCC / DVR17.4.6 Studio / Speed Editor / Tangent Ripple / X-Touch One / X-Touch mini / Space Explorer / 5.1 HDMI#
Offline
User avatar

SeldomSeenKid

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

Re: DR TCP Transport Control - behavior issues

PostWed Dec 22, 2021 4:06 pm

After wrestling some hours with my attempt to implement a smooth remote transport control, I want to add my two cents just in case someone is willing to try something similar.

I am not using TCP but a LUA script with its own MIDI connection. My goal was to implement a smooth scrub or shuttle to be used with my X-Touch device. I was exited when I read that SetCurrentTimecode has been implemented and gave it a try.
I found that is is not useable for anything else but positioning the playhead, which works as advertised. Using it to emulate something like scrub or jog just doesn't work even when using it together with play.
I felt back to my plan B which is using a keystroke emulation. Its jerky but at least I do have sound while "scrubbing" (which isn't the case with SetCurrentTimecode).
Interesting enough: There IS smooth scrubbing in DR! If I connect my X-Touch via MCU MIDI and press the SCRUB button while in Fairlight, I can use the dial-wheel to scrub through my timeline as smooth as warm butter - including sound. Unfortunately this is only available in Fairlight.

If I can express a wish for Christmas: Dear Santa @ BDM R&D, I was a modest and diligent boy all 2021. I worked hard with your software to get the best out of my poor equipment. I know that I am not your target audience but my budget is small and my ambitions are big. If you can please add some butter smooth transportation commands to your API, I promise I will buy a Studio license in 2022...
... not kidding!

Yours sincerely Michael
Good judgement comes from experience. Experience comes from bad judgement.
# Threadripper 32 core / 160GB / RTX4000 8GB / WIN10 #
# BMCC / DVR17.4.6 Studio / Speed Editor / Tangent Ripple / X-Touch One / X-Touch mini / Space Explorer / 5.1 HDMI#
Offline

Octavian Mot

  • Posts: 286
  • Joined: Mon Aug 25, 2014 2:42 pm
  • Location: Germany

Re: DR TCP Transport Control - behavior issues

PostFri Feb 04, 2022 5:25 pm

@Max or anyone who tried to control via TCP Protocol using python sockets

I'm trying to send the 'connect' command, but can't figure out how to encode the command string in this simple script:

Code: Select all
import socket

with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as s:
    command = "7 connect" # <--- this needs to be encoded
    s.connect(('127.0.0.1', 9060))
    s.send(command)
    data = s.recv(1024)

print('Received: ', repr(data))



What is the proper way to do this?
Trying to keep it together at mots.us
Taming AI for filmmaking at StoryToolkit.ai
Offline
User avatar

Igor Riđanović

  • Posts: 1596
  • Joined: Thu Jul 02, 2015 5:11 am
  • Location: Los Angeles, Calif.

Re: DR TCP Transport Control - behavior issues

PostSat Feb 12, 2022 1:02 am

I've developed this client playback controller app using the TCP/IP protocol. It's been five years and I can't remember the details, but I remember running into multiple issues that required some thinking to solve. It certainly would have been easier had the API been available at the time. I don't think I found the protocol buggy, it's just that it was limited.

www.metafide.com - DaVinci Resolve™ Apps
Offline

Octavian Mot

  • Posts: 286
  • Joined: Mon Aug 25, 2014 2:42 pm
  • Location: Germany

Re: DR TCP Transport Control - behavior issues

PostSat Feb 12, 2022 1:12 pm

Hey Igor!

Yes, I've seen your test on youtube a while back!

I'm trying to trigger play/stop from a python script via TCP since the API doesn't have a play/stop function.

I tried multiple encoding functions and combinations, but nothing seems to do the trick...

Was your app also in Python?
Trying to keep it together at mots.us
Taming AI for filmmaking at StoryToolkit.ai
Offline
User avatar

Igor Riđanović

  • Posts: 1596
  • Joined: Thu Jul 02, 2015 5:11 am
  • Location: Los Angeles, Calif.

Re: DR TCP Transport Control - behavior issues

PostMon Feb 14, 2022 5:00 am

Yes, that was Python 2.7.
www.metafide.com - DaVinci Resolve™ Apps

Return to Software Developers

Who is online

Users browsing this forum: No registered users and 5 guests