QPrompt-Teleprompter
QPrompt-Teleprompter copied to clipboard
Cuperino
Working with 2 computers at the same time
Is your feature request related to a problem or a limitation? Please describe...
It could be very useful to work on 2 computers (the second in spare). This feature to be able to change directly from one to the other in case of a problem. For that we often use a mini video mixer (like Roland V-1HD or BM Atem mini) to switch instantly to the second computer.
The problem is to be at the same position on both computers all the time. In case of a crash the second one must be at the last position... especialy for events. I imagine it is difficult to do that but I recently used a software able to do that on Apple. Trying to retrieve the name... Thanks.
...
Describe the solution you'd preffer
...
Describe alternatives you've considered
...
Provide use examples
...
You mean like a video transmision, right? Have QPrompt send a video feed from one computer and have the image be retained on the receiver end if the feed is cut?
I'm sorry for not being clear. I mean using 2 computers running Qprompt (one is a master, the other a slave). When the master crash, the other could continue... like Teleprompter from Pavonine : https://pavonine.co/teleprompter/#redundancy
An easy way to get a video feed from the prompter on the network already exists with NDI5 (Capture HX or Bridge). Could be interesting to know. Thank you so much for your time and your answers.
No worries. Thanks for the further explanation. I hadn't heard of Pavonine's, I like it! When we created Imaginary Teleprompter, software with rich text editing was very limited. It's good to see people taking them this far.
To have the client computer continue after the server has failed, the client needs to be a fully fledged prompter on its own. Something like this is already in the works for QPrompt... Users will be able to remote control one instance of QPrompt through another, and the controlled instance could be used to create an NDI transmission or a transmission in some other format, which could be sent to other QPrompt instances, switchers, or other clients.
Brief tangent: Regular NDI support is in the to do list (#41). It'll be available in a nonfree version of QPrompt, to comply with Newtek's license requirements. Users should be able to download Newtek's SDK and QPrompt's source code to create 'nonfree' binaries themselves, free of charge. I will be charging for NDI supporting binaries to help keep QPrompt's development sustainable.
Back to topic. While redundancy is a good thing to have, I question whether it is the right solution to what some would consider a network problem:
-
Say connections are dropping at the studio, remote control and NDI wouldn't be reliable... The correct solution here would be to use cabled connections, or to improve WiFi by avoiding competing channels and other sources of interference, or by getting equipment that's better suited for the work load.
-
Now say the operator is controlling a prompter in a remote location, over the internet from the studio. NDI HX could potentially help in this situation, but the ideal solution is having someone on site control the teleprompter for the presenter; the second best options are to have the presenter control the prompter themselves, or have the software adjust its speed automatically. The studio's access should be limited to updating the contents to be prompted, and perhaps sending the cue to start.
A stream could have redundancy by using a local prompter instance as a fallback in case the stream fails, but what I worry is redundancy could be used as an excuse to avoid dealing with the real issues in the first place. Developing this kind of low latency network functionality can be very expensive, and the results would never be as good as having better connectivity or a teleprompter that is operated locally.
Please feel free to share your thoughts on this @avlinkus. I know there's a lot of suppositions in my examples. You're the one who's actually working with teleprompters in the field.
Whaooo ;) Thank you so much Cuperino for all! Good to know that you are in progress to remote control through another instance !
Open to NDI is also a good news.
I agree on having an operator (or 2!!) in the studio but sometimes we use the prompter for someone remotely (like with Vmix). In this case we could send the prompter signal to the caller while we receive his webcam. It works, but I do not imagine remote prompter distantly except in this case.
On Wednesday, I will spend some times on Teleprompter Pavonine. Interesting to send you feedback on the experience: the remote, markers, editing while prompting, etc. Do not hesitate if you have specific questions. Thanks.
I agree on having an operator (or 2!!) in the studio but sometimes we use the prompter for someone remotely (like with Vmix). In this case we could send the prompter signal to the caller while we receive his webcam. It works, but I do not imagine remote prompter distantly except in this case.
I see! I'll keep that in mind.
The problem is to be at the same position on both computers all the time. In case of a crash the second one must be at the last position... especialy for events.
In your experience, what situations would you say could lead to a crash?
On Wednesday, I will spend some times on Teleprompter Pavonine. Interesting to send you feedback on the experience: the remote, markers, editing while prompting, etc.
While I love to hear all about people's experiences in the field, I personally avoid deliberately looking too much into competing software to avoid copying sub-optimal design choices, and approaches in general. Instead I try to look at what challenges you're facing, how they're solved and how could they be solved better.
When sharing your experiences with third party software, try to focus on the experience and not the software itself. Speak only of your challenges and what it takes to solve them. Then share suggestions based on your experiences with me, and give the fully detailed feedback to Pavonine, as I'm sure it could help them improve their software to your and other people's benefit.
Looking forward to your experiences!
I used to use an app called PowerPrompter from ESP that was able to sync (by scanline?) two identical scripts on separate computers via serial or network connections. The slave computer would chase the master akin to slave vtrs chasing a master timecode signal in the videotape days... The idea being if one computer froze, you could do a quick kvm switch to the other and continue scrolling... is that possible here?
?
I used to use an app called PowerPrompter from ESP that was able to sync (by scanline?) two identical scripts on separate computers via serial or network connections. The slave computer would chase the master akin to slave vtrs chasing a master timecode signal in the videotape days... The idea being if one computer froze, you could do a quick kvm switch to the other and continue scrolling... is that possible here?
@videosmith, short answer: Yes.
Currently QPrompt grabs each frame that is being prompted. We could develop backends that do whatever we want with those frames. A scan-line approach wouldn't work here because these images are processed and presented as wholes. The important thing is that whatever is to be done needs to be done efficiently and in parallel. Ideally, we would compress and encode the image before sending them to make better use of bandwidth. This step would add some latency, but it could be crucial for serial connections due to the baud rate being limited, it would also help reduce latency over network transmission. It's a tradeoffs optimization problem.
Metadata, including information such as resolution, compression algorithm and changes to the document, could be sent between images or on a separate stream. Sending between images would be best for serial, due to the limited bandwidth. Nevertheless, I'm more inclined to choose a combined approach.
We'd like to have an up-to-date copy of our script be present in our "client prompter". Therefore a TCP packet would be best there to ensure data integrity. Meanwhile, our video stream could be sent over UDP for lower latency, with resolution and encoding metadata such that any changes to these properties can reflect immediately and no frames are ever garbled.
If the signal cuts off, script metadata could be used to render the script locally on the client. Absolute position and velocity values would have to be transmitted with the frames to allow for a seamless transition.
With regards to data compression, I haven't researched our options. What I'd likely do is experiment with various lossless codecs in ffmpeg to see what works best visually and at various bandwidths.
How about adapting your Timer feature to include an increasing/decreasing row count - only while scrolling - (perhaps focused on the line of text currently adjacent to the pointer) and transmitting that metadata via wifi, network cable, etc. to a second computer which listens for that count and updates accordingly. The receiving computer (in a scroll speed of 0) would continuously jump to each new line#, like a text search, with the chasing automatically disabling when you increased the scroll speed on that computer?
Obviously both machines would need the same script, resolution, font size, scaling etc.
I had already tried an approach very close to what you are suggesting here back when Imaginary Teleprompter was being actively developed. The issue with this approach then was latency. The animation wouldn't be fluid because of the variability in network transmission speeds, plus logic overhead.
Logic overheads were very high with Imaginary Teleprompter, around 120 milliseconds on an Intel i3 processor from 2015. For fluid 60 Hz you'd need something closer to 16 ms, including network latency. For context, a ping to github.com takes up to 75 ms from my present location. Good low latency network code usually keeps latency below 20 ms in good network conditions.
For good latency, one should keep interactions short and spaced in between if possible. Dropping information is a common practice in media transmissions to ensure fast delivery. In video games, there is action prediction logic in place and slow downs that helps mask latency mistakes. Action prediction, such as continuing to scroll at the same speed with all contents pre-fetched, and adjusting speed based on line widths is something that could be worked into QPrompt.