Does anyone know if there is an option to tell Video.js to subscribe to a live rtmp stream? There is an option for this in flowplayer and jwplayer. I'm using Edgecast for a CDN and they require this option.
from flowplayer subscribe:
Set to true to make the plugin 'subscribe' to the stream. Needed for RTMP live streams from Akamai, Limelight and other CDNs which may require the FCSubscribe command.
If I use jwplayer on the same computer to play the stream, Video.js starts to play. When I stop the jwplayer the Video.js player stops.
Thanks
Austin
I compiled video-js-swf manually and modified the RTMPVideoProvider implementation to call FCSubscribe during the NetStream initialization.
_nc.call("FCSubscribe", null, _src.streamURL);
Simply requesting the live stream from EdgeCast, Akamai and other CDN is not sufficient. We must tell the edge server (the CDN node) to subscribe and pull the stream from its origin.
Then I implemented onFCSubscribe that was a #NOOP to start the stream
public function onFCSubscribe(pInfo:Object):void {
if (pInfo.code == "NetStream.Play.Start") {
_ns.play(_src.streamURL);
_videoReference.attachNetStream(_ns);
}
}
Related
I have a transfer of a live video stream from a server to the javascript function of a client browser:
server: gstreamer x264enc-hardware ! whatever-I-want ! appsink
=== transfer of data stream with a proprietary protocol ===>
HTML5 browser client: javascript function receives data sent by the appsink
In other words, I'm trying to display a h264 live stream created on a server with a proprietary transfer protocol, the data re-appearing in a javascript function inside an HTML5 client browser.
I was thinking of using MediaSource MSE in the browser to decode h264 and display the image.
Note that the video stream settings (video only, resolution, bandwidth) are fixed and known on both sides. So, everything can be hard-coded and the purpose is not to implement a generic solution.
What could I use on the server side (replacement of the "whatever-I-want" gstreamer plugin) so that the work in the HTML5 browser is not too complicated?
One solution would be to do nothing on the server side and use the broadway.js library to decode NALU h264 in javascript but it obviously doesn't leverage video MediaSource and the decoding capability of the browser.
Could I use Gstreamer avmux_dash and hope that MediaSource can input the transmitted data?
Alternatively, how could I create "MP4 fragments" and could MediaSource read them "easily"?
One approach, that has been used by some major players in the past to translate from one streaming protocol to another, is to receive in your proprietary transfer protocol and then re-package into HLS or DASH on a local server on the device.
You can then stream from that local host to a regular HLS or DASh player on the device.
It sounds inefficient (it is inefficient) but it works, even on mobile devices which their lower processing and power capabilities.
I am using kurento's master git to make a WebRTC to RTP bridge.
MediaPipeline pipeline = kurento.createMediaPipeline();
WebRtcEndpoint webRtcEndpoint = new WebRtcEndpoint.Builder(pipeline).build();
HttpGetEndpoint httpEndpoint=new HttpGetEndpoint.Builder(pipeline).build();
org.kurento.client.Fraction fr= new org.kurento.client.Fraction(1, 30);
VideoCaps vc= new VideoCaps(VideoCodec.H264,fr);
httpEndpoint.setVideoFormat(vc);
AudioCaps ac= new AudioCaps(AudioCodec.PCMU, 65536);
httpEndpoint.setAudioFormat(ac);
webRtcEndpoint.connect(httpEndpoint);
However inspite of this the output video playing is encoded to webm . I have tried various other approaches as well ( using RTP ENdpoint , using Gstream filter , using VLC HTTP to RTP streamer ) . however no method gives me a video playable on safari and IE ie H264 encoded . Requesting media developers and kurento team for help .
Safari and IE do not support RTP/H.264. From you code, I understand that you are trying to create a WebRTC to tag bridge. In that case, the HttpGetEndpoint will provide media through HTTP pseudostreaming. However, Kurento only provides that type of live HTTP pseudostreaming in WebM format. To be best of my knowledge, neither Safari nor IE support WebM, hence what you want to do will not work independenlty on the caps you force to the HttpGetEndpoint. You will be only able to see it working on Chrome, Fireforx or other browsers with WebM support.
The only solution for you could be the HttpGetEndpoint providing media in MP4 format (or any other format supported by IE and Safari), but creating the live stream in that format is very tricky and we (the Kurento team) did not had the time for implementing that and this feature is not in our short term roadmap.
However, we have many users integrating WebRTC with IE and Safari using RTMP. In that case, you need to integrate Kurento with an RTMP capable media server (this can be done in different ways) and later let the RTMP media server to serve media to the browsers.
I want to let WebRTC encoded and play h264(NAL) stream(local file).
In the WebRTC tutorial, getUserMedia is use for get local camera connecting to the system, I don`t know if the getUserMedia function support
capture the local stream file like h264 stream.
If it doesn't work that way, may be I should modify WebRTC source code(I'm studying it).
Here is the question, If i change WebRTC code, how can i integration the new code into browser? Made it a plugin?
Firefox supports an extension to the <video> element that you can use to do this.
First, set the source of a video element:
v1.src = "file:///...";
Then you can call the (currently prefixed) mozCaptureStream or mozCaptureStreamUntilEnded function to get a MediaStream.
stream = v1.mozCaptureStream();
The proposed specification.
Note however that you need to ensure that the file is same origin with respect to the page. The same origin rules for file:/// are probably going to cause issues. Otherwise your MediaStream isn't going to be accessible to you. One way to ensure that is not to set the location directly, but to load the file using an <input type="file"> element.
As noted in other answers, Firefox currently only supports the baseline profile of H.264.
First, you are right getusermedia will not work for you. However, there are a couple of options.
Hack a stream together using RTCDataChannel. Breaking up the media stream and delivering each packet and then handling it on the client side.
Take a look at this demo for precorded media streams. I do not believe that H264 is addressed but it could help you on your way(probably for Firefox only)
Use some sort of webrtc breaker/endpoint that is native to stream the file. I know specifically that others(including myself) have streamed H264 to Firefox through the Janus-Gateway
Couple of asides:
Firefox only supports Baseline profiles in streaming h264 for a webrtc peerconnection
Chrome does not support h264 for webrtc at all
Are you trying to have getUserMedia return a h.264 encoded stream?
In which case, today it will only be possible with Firefox today, under some specific environment (cisco 264 plugin installed) and only for the base profile.
Chrome promised in november to add this capacity, but there is no timeline that I know of Expect at least Q2 2015.
Using our (temasys) commercial plugin you will soon be able to do that in IE and Safari.
Those are the only options on client side I can think of. On server side you can use whatever you want to transcode, including janus, kurento, powermedia, licode/lynkia, ....
Note: using other means like Datachannel or WebSocket are ok to transfer files, but would greatly reduce the user experience as you would not have all the added recovery (and security) mechanisms included in SRTP, DTLS, and would also not have specific mistreated media enhancements that are in webRTC like jitter, buffers, netQ, ect ...
So I want to be able to send a normal video from a video file (AVI or any other) through WebRTC, can that be done? The only examples I see of WebRTC are video chats, so I feel as if its only geared towards webcam and chats.
So my question is, technically can sending normal video from a video file (not webcam) over WebRTC be done?
Try: "Pre-recorded media streaming" --- Documentation and Source Code.
This experiment uses MediaSource API to render Blobs in <video> element. This experiment has some issues need to be fixed e.g. it can't send longer WebM videos.
You can try this experiment as well.
The codecs typically used in AVI are not directly supported by WebRTC clients, but if you are writing your own standalone client then of course it could read an AVI or other video file and transcode it to VP8 video and Opus audio (or whatever other codecs you were able to negotiate), and transmit it via RTP. If you are trying to do video transcoding in JavaScript in a browser then that will be very slow.
I'm trying used mediaplay play http or rtsp protocol uri from server, when I play the
address as http://**.wma or *.mp3 ,it can working,but I tryed played the address as
"http://qr.fm.qq.com/qqradio?qqradio",it didn't working.
and also I'trying used VideoView play rstp protocol uri from server,when I play the adress as
“rstp：//*.sdp”,it can working ,but I tryed play the adress as "rtsp://vs1.thmz.com/radio31"
,it didn't working.
Anybody help me and tell me how
These are live streams, not static files, so, while it may play back some .wma and .mp3 content - these live streams are not defined like that.
Are you sure the first stream link is valid? After a quick scan with nmap, it seems you may need to be in china to connect to this feed (qq.com Registrant Country Code - CN) I get 1000 scanned ports all filtered, usually means a firewall blocking specific geographic regions.
rtsp://vs1.thmz.com/radio31 -> This is a Windows Media Audio stream, using WMA2 codec, delivered via RTSP, which according to the Android Supported Media Formats: http://developer.android.com/guide/appendix/media-formats.html - is NOT supported.