How to I remove WebRTC and add ZeroMQ to my android app?
Should I reverse the steps I did to add the WebRTC and then add ZeroMQ functionality?
Or is there a different approach?
Hmmm, well WebRTC is a protocol built on top of RTP, which is intended for the non-guaranteed delivery of time critical data (video frames, audio, etc), with no guarantee of order of delivery either.
In contrast, ZMQ is a message oriented Actor Model framework with useful design patterns, guaranteed delivery (assuming the network stays up), and is very good for applications that need to ship messages around.
They are quite different. Am I right in assuming that you've started off using WebRTC (possibly due to familiarity) and have run into the limitation inherent in any protocol based on UDP (which is what RTP uses)?
If you're to use ZMQ, you have have to use it at both ends of every communication path on which you wish to use it. You cannot, for example, have ZMQ on the Android app talking to a WebRTC server. ZMQ speaks to ZMQ, and nothing else.
The good thing is that WebRTC (RTP) is similar. So if you're already using WebRTC, that might mean you control all the software. That means you can change it to use ZMQ. [The alternative, e.g. the other end of the WebRTC link was some server system that could not be change, would prevent you changing just your Android App over to ZMQ.]
As to replacing WebRTC with ZMQ, well that very much depends on what it is you're trying to send. Fundamentally ZMQ deals in messages. A message is an array of bytes. The bytes for a message are transmitted as a block from sender to receiver in a single send/receive operation. If that doesn't fit (e.g. you have a video stream with no obvious demarcation between logical chunks of video) then you may run into problems.
Often people use something like Google Protocol Buffers to define message classes which they then serialise to byte arrays, and it's these that are sent in a message. The receiving end passes the received byte array at the deserialiser, reconstituting the class as was.
Good luck
Related
I am currently working on an android application for a start-up business.
Part of my android app provides viewing and download of video files similar to a podcast app, having both by-network viewing as well local storage capabilities for offline viewing.
However, I need to acquire a service/server that provides the hosting and public sharing capabilities that this process requires.
The usage type is pretty simple. I need to host the videos (of which there are not a considerably large amount) somehow, and somehow access them through direct link in my app.
What kinds of business solution would best serve this type of arrangement?
I've looked into Amazon S3, Microsoft Azure, Rackspace and B2 and these seem like the ideal solutions, but I'm not clear as to whether these are commonly used for such purposes. In addition, Backend as a Service platforms like Kinvey and Parse exist, as well as Vzaar, a video hosting business solution.
With so many different systems and unclear use cases it's hard to tell what would be most cost-effective.
What type of system is common practice to use for this type of arrangement?
Do I need a BaaS, a PaaS, or a CDN? Or would something like Amazon S3 work for this arrangement? Or would it be better of trying to find a way to host these videos through the company Wix website?
I'm not necessarily looking for a "use this" type answer, but more I need the right direction to compare and contrast services.
Note: This isn't a strictly programming question, rather an implementation one. I wasn't sure where on SO to place this, given that many similar questions exist concerning implementation and use of these types of services on the main SO.
Hosting and serving videos is quite a specialist domain - the files are large typically, and most decent video streaming servers will include mechanisms to adjust to quality level depending on the bandwidth available to the client.
The technique used to do this is called adaptive bit rate streaming - essentially multiple different quality levels copies of the video are created and broken into, for example, 10 second chunks. The client requests the video one chunk at a time and can switch between quality levels, and hence size, depending on the current network conditions. Hopefully, this give some feel for the complexity levels.
Because of this, you are often best using a dedicated streaming server - you can either set one up yourself or use a hosted service.
Examples, free and commercial, of streaming servers you can host yourself:
https://www.wowza.com
https://gstreamer.freedesktop.org
And examples of hosted video servers (there are many more...):
https://vimeo.com/
http://wistia.com/
First of all let's be clear: I work at vzaar, so I have both personal experience and bias. Make of that what you will.
Above all else I'd encourage trying the various SaaS options out - almost all of them have a free trial and there should be people on hand to answer any questions then and there.
In the application you're describing, we'd effectively fill the role of both a storage and CDN provider, giving you file hosting space and CDN backed global delivery without the need to set up and manage those aspects yourself.
Another function that's often not considered is video encoding. If your videos are already small, efficient, widely compatible files then that's great. If not, a SaaS platform will generally encode them for you. In the long run this can save huge amounts on both storage and bandwidth costs as well as ensuring the best possible device compatibility.
Most vzaar users are using our built in player embedded into their web page via an iFrame. This works fine in many cases, but for apps like you're describing we mostly see people use the video asset links we provide: simple URLs for the video file as well as thumbnails and the like. Backed by a REST API this provides quite a bit of flexibility.
All in all, a SaaS platform is a pretty common approach for the type of thing you're talking about and I'd strongly recommend giving those that interest you a spin. Of course, if you have any questions about vzaar specifically we're more than happy to answer them over at https://vzaar.com/contact/.
My plan is, to create a instant video chat App for Android. I've found Sipdroid wich gives me the opportunity to make video and voice calls using the SIP.
The user should just open the App and be able to instantly video chat with another stranger from the pool.
Now the question is: I only need to setup a SIP-Server and create a pool of SIP-Accounts or create them on demand. Then I'm able to use Sipdroid and modify it, so it fit's my needs.
Is this all? How about this STUN-Server thing? Am I missing something?
How many connections could take a avarage root-server? Actually it should be a lot, because the stream is transmitted using P2P.
Other suggestions to create a P2P anonymous video chat app? I've seen similar Apps. But they use FLEX. This is not what I want to do.
Seems like you are in the good direction. You will need to do the matching logic between 2 idle users and incorporate that feature into SipDroid. There may be some complexity in finding the idle users due to all kinds of corner cases you will get. It may be similar in features as implementing presence in an IMS system.
For STUN, it is synonym to NAT traversal. You may need to care about that but it depends of your network setup.
For the performance, it will vary upon server implementations and hardware you use. You will need to do your own benchmarks. I would guess you don't need to worry unless you have a few dozen concurrent users.
This is kind of a cross-disciplinary question. My technology choices are Python / Django and Android or iOS. If you can address these specifically great, but it's more a question of technique.
I want to return a number of small images (say, 10 at 10k each) over HTTP as a result of an API query. This will be consumed by a mobile app. I could just get return a list of IDs and get the mobile client to fetch each image individually, but I think the numbers are sufficient to warrant thinking about making this more efficient.
So option 1 is just get the client to pull each image individually. This would involve a separate network connection each time and is probably the simplest but worst way of doing it.
Option 1.1 might be to try and get the mobile client to make multiple HTTP requests on the same connection. I'm a bit hazy about that.
Option 2 might be to somehow return a multi-part response. This might be tricky to write a server and client for. Is there pre-existing Python server? How about Android and iOS client libraries?
Option 3 might be to zip the content. Having used the Python zip library myself, this wouldn't be my first choice (IIRC it only operates on 'real' files not file-like objects).
What's the best way to go?
Option 1 seems to be the best from a reliability standpoint. Especially since the amount of data you are sending over is very large (images).
Send 1 --> verify --> respond that it has succeeded/failed --> send second image.
repeat...
Also it is the easiest. Keep it simple!
I need to synchonize some data accross different phones. For example I want to enable "friends" to (automatically) share notes...
I'm now wondering what would be the best approch to reach this.
At the moment i think I'll have to write my own webservise to reach this goal.
As I started to think about a SOAP webservice I found lots of people saying that they would prpose a REST approach.
What would be the "better" solution in my case or are there any other approches for synchonizing data on different Android phones?
Maybe I should start by mentioning that REST is not a protocol and as such hard to compare to SOAP which is.
The main disadvantages with using SOAP for mobile applications are that it normally uses XML and thereby more data than most other protocols and that it's fairly complex both to set up and to maintain. On the other hand, if one party writes the server and one the client, SOAP gives you good ways to see to that changes are communicated clearly (ie WSDL). SOAP is generally not very well supported in mobile phones and may require third party libraries to make it work.
REST is often (mis)used as a name for HTTP based communication using JSON, which is a pretty easy way to communicate with mobile devices and has low overhead. If you have control over both server and client, it's not the wrong way to go (but not the only one either) JSON is generally very easy to get to work on all mobile platforms, and HTTP is well supported by the phones themselves.
It's better to use REST than SOAP because SOAP is very verbose and will increase the network data size.
Besides, if you use SOAP, you have to include external librairies (like kSOAP) to consume the response. With REST, a standard HTTP client is OK.
About data format: think about JSON that is less verbose than XML.
Concerning synchronization, I don't know if Android SDK provides classes to perform this work.
I have seen the video http://www.youtube.com/watch?v=xHXn3Kg2IQE and it was very interesting.But any one have implemented the REST web service using the services.I am developing the chat app,i need to call the web services in some interval if any one done it then please send me idea about it.
Thank you.
I know you've seen my question about the android restful API service, and think you can do something similar the the answers stated there. You'll need to use a Handler to execute a timed callback from the service.
Also, since that question was answered I've discovered google buffers which may be worth you looking at:
Protocol buffers are a flexible, efficient, automated mechanism for serializing structured data – think XML, but smaller, faster, and simpler. You define how you want your data to be structured once, then you can use special generated source code to easily write and read your structured data to and from a variety of data streams and using a variety of languages. You can even update your data structure without breaking deployed programs that are compiled against the "old" format.
There are some good examples on the tutorial pages - it'll make your chat client super fast!