Is it possible to live stream video (& audio) without using the RTSP protocol? Today I tried out Adobe's Flash Media Server and the free alternative Red5. Both seemed like a bit of an overkill (plus had issues with Red5 not supporting AAC audio).
Basically I'm looking for a way to upload live video to my server so it can be viewed using jwplayer, and then stored so it can be viewed later. Does MP4 support live streaming? So that I can record it client-side then upload it for viewing?
I've been experimenting with uploading jpg images and using a HTML5 canvas to display them so it appears like a video.
Here's my code: (using only a few images)
http://jsfiddle.net/QM5EV/
There's several things wrong with it. For one, it's not efficient because it requires mass amounts of jpg's to be uploaded. And most importantly there's no audio.
What would be best to do? Is RTSP the only sensible choice? Thanks. :)
Live via HTTP servers is, for the most part, not an option. But there is "Apple Live Streaming" aka MPEG-TS, although that limits your clients to iOS devices. It uses a plain ol'web server. (This seems to be changing, increasingly desktop browsers are supporting MPEG-TS, but will probably take some time before it is common place.)
For online streaming, rtsp is the best solution. Other protocols such as RTMP ( http://en.wikipedia.org/wiki/Real_Time_Messaging_Protocol) but transmit to any multimedia content using RTSP.
Another thing is that you can make a specific streaming server accepts HTTP redirect requests. Thus, instead of URL's as rtsp://mydomain.com:554/myfile.mp4 can have URL's like http://mydomain.com/myfile.mp4
Regards!
Related
I need to build a web based video player. Something like coursera/udemy. I would like to know the following.
Where we can store videos (Blob,Db..etc)?
Say I uploaded video in Blob storage. How can I make sure nobody is able to download this videos?
What should be an ideal video streaming architecture(BE+FE) if I am expecting 500 concurrent users?
Do I really need to build a video streaming Back End or I can simply use services like vimeo to get this done?
I inspected how Udemy is doing, i could find the following. It looks like they are using some blob to store videos. But when I tried to access this directly it says I cannot. How this works?
There can be no way to protect your video from a determined sophisticated hacker. In the very worst case, they can record the video from their screen using a iPhone.
You can learn more about blob: URL e.g. here. The bottom line: it's a browser-side object, it's not to store videos.
You definitely can use streaming services, but this will even further reduce your control. OTOH, it's not worth your effort to develop some new streaming architecture if you only expect 500 concurrent streams.
I have a live stream of raw h264 (no container) coming from a remote webcam. I wanna stream it live in browser using DASH. DASH requires creating mpd file (and segmentation). I found tools (such as mp4box) that accomplish that in static files, but i'm struggling to find a solution for live streams. any suggestions - preferably using node.js modules?
Threads i have checked:
mp4box - from one hand i saw this comment that states " You cannot feed MP4Box with some live content. You need to feed MP4Box -live with pre-segmented chunks." on the other hand there's a lot of people directing to this bitmovin tutorial which does implement a solution using mp4box. In the toturial they are using mp4box (which has a node.js api implementation) and x264 (which doesn't have node.js module? or is contained in ffmpeg/mp4box?)
ngnix - ngnix has a module that support streaming to DASH using rtmp. for exemple in this toturial. I prefer not to go this path - as mention i'm trying to do it all in node.js.
Although i read couple of posts with similar problem, I couldn't find a suitable solution. Help would be much appreciated!
The typical architecture is to send your live stream to a streaming server which will then do the heavy lifting to make the stream available to other devices, using streaming protocols such as HLS and DASH.
So the client devices connect to the server rather than to your browser.
This allows the video to be encoded and packaged to reach as many devices as possible with the server doing any transcoding necessary and potentially also creating different bit rate versions of your stream to allow for different network conditions, if you want to provide this level of service.
The typical structure is encoded stream (e.g. h.264 video), packaged into a container (e.g. mp4 fragmented) and delivered via a streaming protocol such as HLS or DASH.
Basically trying to play some live audio streams in an app I'm porting to the browser.
Stream example: http://kzzp-fm.akacast.akamaistream.net/7/877/19757/v1/auth.akacast.akamaistream.net/kzzp-fm/
I have tried HTML5 audio tag and jPlayer with no luck. I know next to nothing about streaming audio, however, when I examine the HTTP response header the specified content type is "audio/aacp" (not sure if that helps).
I'm hoping someone with more knowledge of audio formats could point me in the right direction here.
The problem isn't with AAC+ being playable, the issue is with decoding the streaming ACC wrapper called ADTS. The Audio Data Transport Stream [pdf] or "MP4-contained AAC streamed over HTTP using the SHOUTcast protocol" can be decoded and therefore played by only a couple media players (e.g., foobar2000, Winamp, and VLC).
I had the same issue while trying to work with the SHOUTcast API to get HTML5 Audio playback for all the listed stations. Unfortunately it doesn't look like there's anything that can be done from our perspective, only the browser vendors can decide to add support for ADTS decoding. It is a documented issue in Chrome/WebKit. There are 60+ people (including myself) following the issue, which is marked as "WontFix".
I am going to develop a chat based application for mobile which allows video chat. I am using HTML5, javascript and PhoneGap. Using phoneGap, I am able to access mobile camera, capture a video, save the video and upload it in server. I have done it for android. But I need live broadcasting of the video. Is there any solution of that?
Note: It is not any android native app.
You didn't specify what facility you're currently using for the video capture. AFAIK, current WebView doesn't yet support WebRTC which is the w3 standard that will soon enable you to access the video frames in your HTML5 code. So I'm assuming you're using PhoneGap's navigator.device.capture.captureVideo facility.
On Android, captureVideo creates 3gp files. The problem with 3gp is that they cannot be streamed or played while capturing: the MOOV atom of the file is required for parsing the video frames in it, and it is written only after all frames in the file have been encoded. So you must stop the recording before you can make any use of the file.
Your best shot in HTML5 is to implement a loop that captures a short clip (3-5 seconds?) of video, then sends it to a server while the next chunk is being captured. The server will need to concatenate the clips to a single file that can be broadcast with a streaming server. This will add several seconds to the latency of the broadcast, and you are quite likely to suffer from lost frames at the point in the gap between two separate chunk captures. That might be sufficient for some use cases (security cameras, for example).
If your application is such that you cannot afford to lose frames, I see no other option but to implement the video capture and streaming in Java, as a PhoneGap Plugin.
See Spydroid http://code.google.com/p/spydroid-ipcamera/
It uses the solution with the special FileDescriptor you found. Basically they let the video encoder write a .mp4 with H.264 to the special file descriptor that calls your code on write. Then they strip off the MP4 header and turn the H.264 NALUs into RTP packets.
I have a 1080p video that I'm displaying in an HTML5 <video> tag on my page.
Is there a simple(ish) javascript method of detecting bandwidth so I can switch out the video for lower quality versions if the user's connection is too slow to stream the video? Similar to the logic behind YouTube's 'auto' video size chooser.
Depending on what player and encoding platform you are using you may be able to use HLS encoding for your videos. HLS stands for HTTP Live Streaming, a protocol developed by Apple for primarily solving this problem (among others).
HLS basically breaks your video file into multiple small files so they can be "pseudo" streamed using a simple Web server. With HLS you can also encode in multiple resolutions and a player might be able to switch to a lower or higher bandwidth.
The only downside is that most of the players use Flash to play HLS encoded content. Check it out in action here: http://www.flashls.org/latest/examples/chromeless/
Here's HLS demo for flowplayer:
http://demos.flowplayer.org/basics/hls.html
And here is a plugin for VideoJS:
https://github.com/videojs/videojs-contrib-hls
To encode in HLS, you can either use ffmpeg for free and upload files to your server:
https://www.ffmpeg.org/ffmpeg-formats.html#hls-1
Or, you can use a cloud-based solution like AWS Transcoder or Brightcove
https://aws.amazon.com/elastictranscoder/
In google chrome at least there are these properties on a video element:
webkitVideoDecodedByteCount: 0
webkitAudioDecodedByteCount: 0
These should be enough to determine how fast the client can decode the video. As the video plays you would keep track of the delta amount of these bytes which gives you bytes/s the client is processing the video.
For a more up to date answer: MPEG-DASH is in the process of replacing HLS. HLS is used mainly in iOS land. Most desktop browsers do not plan to support it, and DASH is the standard they are moving toward. (However, there are plenty of players designed to allow you to use HLS with HTML5 video player like hls.js). DASH players include Bitmovin, Google Shaka, and more. Many people encode for both HLS and DASH currently. HLS also supports fragmented mp4. Please note that you will need to encode your videos correctly server side. Additional resource: http://www.streamingmedia.com/Articles/Articles/Editorial/Featured-Articles/The-State-of-MPEG-DASH-2016-110099.aspx
I hate that feature! It's usually wrong, and if I want to wait 2 hours to load my dang video, than wait I shall! There's no reliable way to accurately measure this without sending a large dummy file to the user and measure the time it took to get to him.
You should count on user input (and remember it correctly! Also unlike YouTube!).
In short, don't take YouTube as an example.
There are paid services that may give you an indication of what bandwidth the other party is on, like netspeed.
The data accuracy may be enough for you, but I haven't had the chance to test it for myself.