Now a days since HTML5 is around, neither Flash nor Java is supported by browsers for audio/video recording. As per my knowledge WebRTC is leading framework being used by developers to achieve this. In a web based application my client wants to provide audio/video/screen recording. I can quickly think of WebRTC as I believe Google Meet uses same. However when digging out little further I realized WebRTC cannot record screen. Then question came to my mind:
What framework is mostly used for audio/video/screen recordings? There are few other web services (for e.g. Loom) they too provided similar interface and allow a/v/s recordings. Please can someone share what framework and technologies these web applications use now a days?
Many thanks in advance.
Related
The task is to be able to connect to cameras from car DVRs and to save video from cameras to a database or file system in real time (i.e. somehow stream should be saved, but not the whole video object at once). Now I am making a prototype and trying to make sure that the video from my webcam is broadcast in a browser and saved in parallel to a database or file system. I googled for several days on how to do this and how it will be better and a little confused (between WebRtc and SignalR, since the first one is hard to understand and the second is not fully described on the internet examples which I found). I will be very glad if someone tell me with the help of which technologies and how exactly this can be done (examples are welcome, since the task needs to be done quickly). Now I look towards ASP.NET CORE and SignalR (asynchronous streams). but I don’t really understand, is it possible to solve my problem with the help of these technologies? if not, what technologies should I try? if so, how to implement the solution using these technologies?
UPD: I need to implement something like Azure Media Services (https://azure.microsoft.com/en-us/services/media-services/)
On my current job, we are developing an application that uses WebRTC technology.
And we want to test the work of our application with 30 users in real time -- a conference call with video, sound, and microphone (and everything must work). We know that we can do it by real users (real users connected to our application).
Question is: How to test our requirement if we don't have such a number of real persons? Maybe exists some tool for that.
Thanks.
You'll need a Selenium Grid.
And you'll need to build the automation part on your own on top of it.
Alternatively, you can check out https://testrtc.com -- it enables automating 100's of browsers and more with a focus on WebRTC based services.
I am the co-founder, so take this with a grain of salt
That said, I am not aware of any other commercial tool or otherwise that makes this as simple and straightforward
You have two peer-reviewed IEEE scientific articles that were written on WebRTC testing state of the art this year. They both list and compare several solutions including but not limited to testRTC cited in the other answer.
On July 2017, "WebRTC Testing: Challenges and Practical Solutions" was published in an IEEE venue by the Kurento / Twilio team, and lead by the Spanish researchers that did not join Twilio but went on to start ElasTest, a millions-Euros, EU-funded project that looks very promising but is still in alpha stage.
http://ieeexplore.ieee.org/document/7992926/.
On September 2017, "Real-time communication testing evolution with WebRTC 1.0" was published in Principles, systems and Applications of IP Telecommunication by the CoSMo team behind the original Temasys infrastructure, the symphony solution, and the new Google Testing Engine (KITE). It is a full paper about the state of the art Before google decided to go for KITE, and include a thorough review of all possible testing layers, and existing solutions. There are many solutions to do what you want today. If you need an on-premise solution, and/or test mobile browser, and/or test native apps, IoT, ... AFAIK testRTC.com will not help you, however good for other aspects.
http://ieeexplore.ieee.org/document/8169751/.
You might want to read both articles, and citation therein before you make your choice.
Disclaimer: I am the original author of that last publication.
There was some discussion on this topic here but not specific to my questions. You can consider this as an extension to the question asked there. Googling gives only two possible solutions: Kurento and Janus. The questions I have are:
Are there other options, opensource or otherwise?
Among these options, can someone share some experience based upon actual use?
Is there a list of IP Cameras which are compatible with such gateways? Or
What specific features must an IP camera have to be able to use such a WebRTC gateway?
Is is correct to say that if webRTC indeed takes off, then webRTC support for IP cameras is just a matter of time, which will get incorporated in standards such as Onvif?
I do not need an application per se but just the bare minimum so that other WebRTC components can be plugged in to create an application. The issue is not just about codec conversion but about some related signalling (as distinct from the WebRTC signalling which is anyway not standardized). This is discussed nicely on Kurento here.
I have also read about IP Camera standards, in particular Onvif. I am not looking for any compatibility with this standard which is a different issue.
I did take a look at arguably the most popular opensource software for CCTV cameras: Zoneminder but that is a very bloated software, a full-fledged application and does not have any support for streaming camera video/audio over webRTC.
Kurento has been reported to work well with RTSP camera feeds in many occasions. You can check the official mailing list for that. There's a demo here, if you are interested on how it would be done. There's a pull-request that you'll need to include, and though it could be outdated, the demo works just fine still, for letting you know how to do that.
Disclaimer: I'm part of the Kurento project.
Most of the applications these days provide an API...be it twitter,gmail,fb and millions others.
I understand API Design can not be explained in just an answer but I would like some suggestions on how to get started with API design. Maybe some tutorial/book that makes an application and has some chapters on how to go about providing API's for it. I'm mostly a java developer (learning Groovy) but am open to other languages also, if it is easier to get started with API design in that language.
As a side note, before I was curious about the difference between an API and a webservice. But now as I understand it, webservice is just a form of an API
I don't have any great resources however, I want to stress how correct that API is Application Programing Interface, and is simply a mechanism for how you expose your application to be consumed by others. Be it from script, web service (soap or rest), Win32 API Style Calls....
About 10 years ago when we talked API it seemed like everyone felt like all APIs were like Win32, and that was it. One of the more interesting I've worked on was an API with a PICK based Management System. In this case we wrote an XML processor in PICK and were screen scraping XML back and forth over a telnet session.
The first thing you need to decide, is how do you want to expose your data. Are you going to expose over the web? Or is your application a desktop application? How I would structure an API for cross machine communication tends to be different then if the API is running in a single process or even on a single machine.
I would also start by writting a test client, You have to understand how your API will be used first and try to make it as simple as possible. If you dive right in with the implementation you might loose perspective and make assumptions that a client developer might not.
We're about to build a Blackberry application but would love some input on whether to implement using J2ME (MIDlet based) or Blackberry native (UIApplication).
I understand some of the tradeoffs. J2ME will be more flexible if we want to port the app to other devices. RIM has better support for Blackberry native.
The place I'm still lacking information, though, is on the UI side. We want to build an app that has a great user experience, and one that looks like other apps BB users are accustomed to. Can we do this if we go the J2ME route?
Apologies for the somewhat subjective and less technical nature of the question.
I've tried it both ways - building a pure MIDP app to run on BlackBerry and non-BLackBerry platforms and building a separate BlackBerry app (often using much of the same business-logic and networking code as the MIDP app). Definitely go the BlackBerry native route.
It's all about the BB UI classes. They'll give you the ability to (among other things) respond to the different type of menu events (trackball and menu key), respond to BB specific key codes, if you're interested in the Storm take advantage of the orientation sensor and touch support. Plus they're a much richer set of UI elements to work with. You can build up a lot (but not all) of what they do in pure MIDP, but end up customizing so much of it for each platform that you won't save anything in the end. Starting with the BB UI and customizing saves a lot of time and effort.
Even in gaming applications, or for applications where you're custom drawing all your components, you have better access to the BlackBerry graphics APIs and get better performance going the BlackBerry native app route. And you still have better detail about input events.
Finally there are some nice lifecycle things you can do with BlackBerry native apps, like pushing to the background, or auto-running on system startup that you can't do with MIDlets, which may be of interest depending on your application.
Also think about market - if you're planning on supporting BlackBerry right away, and then maybe other MIDP platforms down the road, it's usually a better plan to execute the best you can on your initial platform. There probably won't be much of a reason to port to MIDP later if you don't succeed on BlackBerry first.
BlackBerry is a very difficult platform to program for. I went the native route and found it to be very poorly documented and overall just a miserable design to work with. I did feel it to be necessary because you will lose the ability for certain features (scroll wheel?) if you go the J2ME route. It's a tradeoff and you'll have to choose the one that fits better for your specific need.
I have been working with J2ME since 2002 when the Nextel/Motorola phones were in the forefront of J2ME functionality. I deal primarily with non-gaming applications. Today with J2ME evolving and more phones conforming to the JSRs my application continues to port smoothly. This year I finally got around to moving it to a Blackberry device. Two days later my application is fully functional on a Blackberry. The application is purely generic J2ME and uses many of the JSRs (location, bluetooth, xml, etc ). A strong UI design helps. I extended some of my UI classes to support the QWERTY/SureType keypads. I have used a variety of native applications found on Blackberry devices (not games) and I have yet to justify any reason to venture off to the RIM API to see what I would benefit. The arguments expressed above by other fellow programmers further prove that there is very little to gain unless you are purely devoted to a Blackberry device platform.
Without knowing the scope of your application, meaning which devices you will target, another thing that you will need to take into consideration is the ever expanding differences in input for each BlackBerry model. Some devices, like the Curve and the Bold, are standard QWERTY pads where other devices, like the PEARL, have SureType pads. And then there's the Storm which supports both depending on the orientation of the screen. Also, the SureType pad needs to be used as a standard number pad if the user has it set that way. The native APIs have support for all of this where you won't have that luxury with standard MIDP.
Another tip when designing your user experience, I would get my hands on a few different BlackBerry models and try out some of the apps that come standard as there are a lot of shortcuts that users become accustomed to using that you might not even realize exist. For instance, the SPACE bar pages down. This is huge for reading docs, however I have a third party RSS feed reader that does not have this functionality and I always attempt to use it first before remembering that it doesn't exist in this app. That kind of small detail can make a huge difference to BlackBerry users.
There is a way in between: You could use J2ME-Polish and code natively in J2ME. Polish will add the look and feel of a native BlackBerry app to some extent. That has the advantage of porting your app to other J2ME phones and not be limited to BlackBerry.
I agree with Anthony, I'd go with the BlackBerry specific APIs for BlackBerry apps. J2ME is just not portable, and BlackBerry has a lot better support for their proprietary APIs.
From my experience: stick with the native BlackBerry UiApplication. It is the best for BlackBerry and provides the best user experience for BlackBerry users. You can't copy that with J2ME easily.
J2ME is simple to develop. And, BlackBerry API has many feature also you can use restricted class with simple signing. BlackBerry sells their sign certificate and it is cheap. 20$. You can use this certificate to sign and use all restricted class. In J2ME, sometimes you must use more than one certificate, even you can not use all phone capabilities. So, my suggestion is, use BlackBerry native API and some J2ME Wrapper Codes. So that, you can code easly as J2ME and can use all capabilities of BlackBerry native API.