I have an assignment to display, into a Hololens 2 (Unity Project), two video feeds (stereo camera) coming from a LattéPanda. For now, I successfully manage to do the demo from the Mixed-Reality WebRTC project locally, but I have some difficulties with the remote streaming.
The problem is how to make my application based on the Mixed-Reality C# Core 3.1 connect to my NodeDSS signaler since the demo uses a NamedPipeSignaler class that can't reach out to localhost? So I look up the classes they provided in the hope of getting the required method to implement, also with the interaction it needs to do with the PeerConnection object. It started to be a little complicated, so we look up other solutions.
One of the solutions we found was the OWT-Server (Open WebRTC Toolkit) which seems to give us already dockerize application to videocast on its own. However, the documentation doesn't specify much other than we need to link the docker image to an "application", which is not clear what it is supposed to do. We don't have any way to specify the STUN/TURN server, nor the signaler IP address for that matter.
So my goal at this point is very simple: just make one feed appear into my Unity project. The LattéPanda's only objective right now is to cast the video without caring much for any interaction (for now): it won't receive or even need to listen to any feed coming back ever, and for now, there is no need to interact with other tools. I've been searching for about 2 weeks now and my GoogleFu is not that good apparently. Is there any tool that could achieve this?
A little disclaimer: I do believe I still lack an understanding of the Signaling process. It seems that WebRTC does not enforce any standard in that regard. What I understand is the communication protocol (WebSocket, HTTP/2) is not standardized, only the messaging is (what message needs to be sent/handle).
EDIT
To be clear, the LattéPanda currently runs a console application written in C# Core 3.1. The reason is, like I said, that the LattéPanda should not display any of its feed to a monitor connected to it, nor received/handle any feed from outside. We can see it like a surveillance camera that outputs its feed through WebRTC and doesn't need to receive any feed.
Related
Hi I have started a project which connects to a database and creates/logs in a user at the moment i have a LAN messenger that works very well, and a FTP chat which is not exactly what i was hoping for.
my idea now is to create two tables in the database message 1 and message 2 both of which display the user who is sending and the message sent. and the program uses threading to connect and download the messages.
My question is, is there a better way of completing this task (if so could you send a link or two this way? or express your opinion).
and or any problems you guys/girls think i would run into. Cheers :D
If you require to see some code just ask and i'll edit the post thanks
Although its easy on paper to do a chat application that uses a 'DB' as a backend/comms layer .. its not really the best approach. It will work... but with load, it may not be a very good approach.
Most chat clients uses a peer to peer connection, or even client server with the coding and implementation of a server that handles what happens with messages going/destined where ever.
If you really want to get low down and dirty, google for 'TCP chat application' examples. If you want to operate a bit higher (not handle the really gritty low down mechanics), then look for some 'wcf chat' examples.
I have a client/server audio synthesizer where the server (java) dynamically generates an audio stream (Ogg/Vorbis) to be rendered by the client using an HTML5 audio element. Users can tweak various parameters and the server immediately alters the output accordingly. Unfortunately the audio element buffers (prefetches) very aggressively so changes made by the user won't be heard until minutes later, literally.
Trying to disable preload has no effect, and apparently this setting is only 'advisory' so there's no guarantee that it's behavior would be consistent across browsers.
I've been reading everything that I can find on WebRTC and the evolving WebAudio API and it seems like all of the pieces I need are there but I don't know if it's possible to connect them up the way I'd like to.
I looked at RTCPeerConnection, it does provide low latency but it brings in a lot of baggage that I don't want or need (STUN, ICE, offer/answer, etc) and currently it seems to only support a limited set of codecs, mostly geared towards voice. Also since the server side is in java I think I'd have to do a lot of work to teach it to 'speak' the various protocols and formats involved.
AudioContext.decodeAudioData works great for a static sample, but not for a stream since it doesn't process the incoming data until it's consumed the entire stream.
What I want is the exact functionality of the audio tag (i.e. HTMLAudioElement) without any buffering. If I could somehow create a MediaStream object that uses the server URL for its input then I could create a MediaStreamAudioSourceNode and send that output to context.destination. This is not very different than what AudioContext.decodeAudioData already does, except that method creates a static buffer, not a stream.
I would like to keep the Ogg/Vorbis compression and eventually use other codecs, but one thing that I may try next is to send raw PCM and build audio buffers on the fly, just as if they were being generated programatically by javascript code. But again, I think all of the parts already exist, and if there's any way to leverage that I would be most thrilled to know about it!
Thanks in advance,
Joe
How are you getting on ? Did you resolve this question ? I am solving a similar challenge. On the browser side I'm using web audio API which has nice ways to render streaming input audio data, and nodejs on the server side using web sockets as the middleware to send the browser streaming PCM buffers.
I have been working on Reachability class for a while and have tried both the one from Apple sample and the one from ddg. I wonder whether the Reachability class keep sending / receiving data after starting the notifier.
As I'm developing an app which connect to different hosts quite often, I decided to write a singleton and attach the reachability classes I need on it. The reacability classes would be initiated and start their notifiers once the app start. I use the singleton approach as I want this singleton class to be portable and can be applied to other apps without much rewriting. I am not sure if it is good idea to implement like this but it worked quite well.
However, someone reported that the battery of his device drain significantly faster after using the app and someone reported more data usage. My app does not send / receive data on background so I start wondering if it is related to the reachability.
I tried profiling the energy usage with Instrument and I notice that there are continuous small data (few hundred bytes in average) coming in via the network interfaces even I put my app in idle. However, there are almost no data sending out.
I know that Reachability requires data usage when initiate (resolving DNS etc) but I am not sure that whether it still keep using data after starting notifier. Does anyone can tell?
I am not familiar with the low-level programming, it would be nice if someone could explain how does the Reachability work.
I use Reachability, and while I haven't monitored the connections, I have browsed the code, and I can't see any reason why it would keep sending ( or receiving).
If you have a ethernet connection to your Mac, it is quite easy to check. Enable sharing over wifi of your ethernet connection. Install little snitch, it will run in demo mode for three hours after every boot. Turn off the data connection on the test device and connect it to your mac over wifi.
This will allow you to see any network access your test device is making.
If this isn't possible, you can also run your app in the simulator as the network side should be the same, so you should be able to check.
There are also a ton of other tools to track network activity, but I think little snitch is the easiest to use.
All
I am looking for a bit of inspiration here, a client has requested me to build a simple remote process monitoring application with capability for smtp notification, when monitored processes go down or come back on-line. Can anyone point me in the direction of some sample code to get me started. I have briefly looked at .net remoting as a potential development path, from my understanding of how this works, the remoting architecture would require both a client and remote server component, (though I am not a 100% sure on this one), however if this is the case, then it will not fit the bill, as one of the fundamental requirements is that no additional software can be deployed on the servers which are to be monitored.
Alternatively, if you know of a finished 'lightweight' product out there, which would deliver this sort of functionality then this would probably work as well.
Kind Regards
Paul J.
Net-SNMP actually has the ability to monitor processes and send out notifications now. If you look in the snmpd.conf manual page (http://www.net-snmp.org/docs/man/snmpd.conf.html) under "process monitoring" (http://www.net-snmp.org/docs/man/snmpd.conf.html#lbAR) and "disman event-mib" support (http://www.net-snmp.org/docs/man/snmpd.conf.html#lbAX) to get the two features you need. Also the notification sending support (http://www.net-snmp.org/docs/man/snmpd.conf.html#lbAW).
I don't remember the windows support for it and how well it works though (it looks like you're aiming for windows).
I'm trying to create an embedded outdoor display of bus arrival times at my university. I'd like the device to utilize my school's secured WiFi network to show arrival time updates determined from a server script I have running.
I was hoping to get some advice on the high-level operation of this thing -- would it be better for the display board to poll a hosted database via the WiFi network or should I have a script try to communicate with the board directly over 802.11? (Push or Pull?)
I was planning to use a Wifly or WIZnet ethernet board in combination with a wireless access hub. Mostly inspired by this project: http://www.circuitcellar.com/Wiznet/winners/001166.html Would anyone recommend something else over one of the WIZnet boards? I saw SPI/UART options and thought these boards could work with an AVR platform.
And out of curiosity -- if you were to 'cold start' this device (ie, request a bus arrival time by pushing the display's on button) you might expect it to take 10-20 seconds to get assigned an IP and successfully connect to the database, does that sound right?
I'd go pull. In fact, I'd have outdoor display make http or https requests of the server. That way the server could tell it how long to show a given set of data before polling for a new one using standard http page expiration.
I think pull would make it easier to have multiple displays, and to test your server as well. I've also got a gut feeling that this would make your display more secure. Someone would have to hack your server to hijack your display.
There's a very cool looking Arduino-targetted product called the WiShield. Seems super easy to use and he provides some source code. It uses SPI for host communication. If you're not interested in going the Arduino route, I'm sure the source code wouldn't be too hard to port to something like avr-gcc. Check it out, might save you some time and headaches for $55. Worth checking out anyway.