How can I get two tablets to receive vid feed simultaneously?

Joined
Jun 6, 2017
Messages
77
Reaction score
24
Age
68
When I connect my tablet to either Solo app or Solex app it connects and gives me a viewable vid signal; and it works perfect. However, when I try to connect a SECOND tablet to the same app it connects but does not give me a video signal on that second tablet.

Is there a way that I could connect my one tablet (with all the parameter functions available) AND connect a second tablet and app that would give me a second video feed for others to use for watching the video?
 
Only the first device connected to the WiFi will be fed the live video. Secondary devices (I.e. Laptop running Mission Planner) can send and receive on the network but no video.
 
Only the first device connected to the WiFi will be fed the live video. Secondary devices (I.e. Laptop running Mission Planner) can send and receive on the network but no video.
That's what I have found.
While i can understand the conflict that would arise with having two devices sending info to Solo, I don't know why a second tablet could not simply just receive a vid signal.
I am hoping for a "go around" method. Perhaps changing the settings on the secondary tablet that would allow for just a receive signal from vid signal.
 
You can't connect both wirelessly. You would need to connect to the HDMI port on the back of the solo controller or use a slim port.
Check out this thread:
https://3drpilots.com/threads/can-a...-with-latest-2-4-1-6-please.6608/#post-100941
I am porting out of my tablet and into goggles via a cable.
Tablet and goggles work simultaneously. I like that.
However, it would be great to have a second wireless tablet for someone to hold and look at without an umbilical cord to tangle on.
I am hoping there is a tablet "go around" setting or method of connect that would work.
Hmmm. Could the first tablet acting as a "hot spot" send a separate signal to the second tablet?
 
only one on feed but you can do the HDMI out on the controller to a second tablet
That's true. I have done that and it works.

What protocol connects the one tablet but locks out the second tablets vid signal?
I am hoping to find a way to overide that lock out.
Any ideas, or a wifi message board, or even a hacker site that would know these things?
 
its not a lock that I know of, just the way the streaming protocol works. first one to connect gets the feed
 
its not a lock that I know of, just the way the streaming protocol works. first one to connect gets the feed
Anyway around that? That is my quest.
Wouldn't it be possible to change that protocol in Solo to allow for more than one feed?
Could lines of code or a code edit change this limitation of one feed only?
 
You'd have to get involved with the OpenSolo project and get a kernel which supports gstreamer 1.0 (>3.14.0, I believe) functional on the IMX.6. After that, the tee() module is available to build into the video pipeline, which would allow for the creation of multiple sockets to support streaming.

Sorry you asked?

;)
 
You'd have to get involved with the OpenSolo project and get a kernel which supports gstreamer 1.0 (>3.14.0, I believe) functional on the IMX.6. After that, the tee() module is available to build into the video pipeline, which would allow for the creation of multiple sockets to support streaming.

Sorry you asked?

;)
Wow. Sounds good....if I only knew half of how to do that I would be half way there.
This may be more involved than the reward.
 
I mean, I'd have to look at the code, but it might be possible to redirect the hardware port's feed to a socket. But then you'd have no HDMI out if that were accomplishable...
 
  • Like
Reactions: Saijin_Naib
I mean, I'd have to look at the code, but it might be possible to redirect the hardware port's feed to a socket. But then you'd have no HDMI out if that were accomplishable...

My understanding of the connections to wifi is rather rudimentary. It would seem though that Solo is sending out and/or looking for a wifi signal to connect to or vice versa. Once Solo connects to that one wifi signal (in my case a tablet) then the protocol (if that;s the proper terminolgy here) shuts off a port, disables/blocks, or doesn't allow for a second signal request in order to prevent a secondary connect. Why then can't the code be changed or written over, or added to the coding stream a way to allow a secondary connect request? If the wifi can be turned on once why not twice? I would have to think that a code change is the most desirable and perhaps the only way.

Since coding isn't my forte', I wouldn't know where to begin and how to begin it. So I'm no help here.
So this is in the coders corner now.

Having the ability to connect one or more signal requests could allow multiple tablets/screens. This could enable and allow for multiple individual tablet connects if wanted.

That sounds like a desirable option to have, especially if it's fairly easy and doable by code. Might be a cool feather in one's cap to take credit for the coding.
 
Your understanding is a bit skewed. Solo is a *client* on the network. The GCS (controller) is the AP/router. Solo sends the video stream as part of a compressed, intermixed stream of bits back to the GCS. There, it is separated from telemetry, status, gjmbal, and other traffic and directed to a socket for the tablet/laptop to connect to and to the hardware HDMI port. The tablet or laptop is also a client on the network.

Would it be possible to eavesdrop on that traffic and decode the video stream oneself? Sure, but it's gonna involve things like MAC and IP spoofing.
 
  • Like
Reactions: Saijin_Naib
Your understanding is a bit skewed. Solo is a *client* on the network. The GCS (controller) is the AP/router. Solo sends the video stream as part of a compressed, intermixed stream of bits back to the GCS. There, it is separated from telemetry, status, gjmbal, and other traffic and directed to a socket for the tablet/laptop to connect to and to the hardware HDMI port. The tablet or laptop is also a client on the network.

Would it be possible to eavesdrop on that traffic and decode the video stream oneself? Sure, but it's gonna involve things like MAC and IP spoofing.
Well, hmmmmm......As Foghorn Leghorn would say, "Your built to low son, everythings over you head."
I am seeing that this is beyond my scope. Is there any easy way to do what I am asking for?
And why can't the vid signal just be sent out to a secondary device like it's sent to the first? (sorry for the redundant and naive question)
 
Is there an easy way without an umbilical? Not that I see.

And as for the second question, it has to do with the kernel version used by 3DR since it didn't have support for the version of gstreamer which has the tee() module available. In gstreamer, you build up a pipeline for processing video, with inputs and outputs. The tee() module allows splitting of the pipeline to multiple outputs, which would allow for the creation of a second or third socket for mobile devices to connect to.

At present there just isn't the programmatic structure for multiple outputs, and I don't know if there is the processing horsepower for an RTSP or RTMP stream encoder onboard the Artoo (controller).

Though it would be an interesting experiment to have a PC grab the stream socket and push it to RTSP/RTMP. Wonder if @Kelly Schrock would be able to code Solex to accept video from external streaming sources...
 
  • Like
Reactions: Saijin_Naib
Is there an easy way without an umbilical? Not that I see.

And as for the second question, it has to do with the kernel version used by 3DR since it didn't have support for the version of gstreamer which has the tee() module available. In gstreamer, you build up a pipeline for processing video, with inputs and outputs. The tee() module allows splitting of the pipeline to multiple outputs, which would allow for the creation of a second or third socket for mobile devices to connect to.

At present there just isn't the programmatic structure for multiple outputs, and I don't know if there is the processing horsepower for an RTSP or RTMP stream encoder onboard the Artoo (controller).

Though it would be an interesting experiment to have a PC grab the stream socket and push it to RTSP/RTMP. Wonder if @Kelly Schrock would be able to code Solex to accept video from external streaming sources...
Thanks for the in depth overview. I appreciate your consideration in discussing this.
 

New Posts

Members online

Forum statistics

Threads
13,095
Messages
147,750
Members
16,063
Latest member
No idea