I uploaded a mp4 test video to azure blob storage. But the video performance is too slow and takes a while to start streaming.
Is there anything that can be done to improve performance?
The video size is ~ 49MB
http://dzcdn.blob.core.windows.net/dz-cdn-blob/jiju.mp4
Azure Blob Storage does not support streaming it only supports Progressive Download. It is good to have understanding of these. Because it is Progressive download, the player needs to initially fetch some amount of data before start playing it. Although Progressive Streaming, I haven't seen any problems with playing media out of Blob Storage so far (just for the record - the provided video started in just 4 seconds with super quality).
But if you want to cover wider audience, potentiality with slower internet connection, you might want to go and check Azure Media Services. Media Services supports wide range of streaming features including Smooth Streaming, Fixed bitrate streaming, progressive download, Apple HTTP Adaptive streaming (Apple HLS Streaming) etc. And smooth streaming will help with slower connections, while keep the better quality on faster ones.
Related
I am new into RTMP and live streaming.
I have my rtmp server, but the issue is distribution, was looking for a simple rtpms streaming cdn. That can support audio streaming with HSL or dash support.
Or something free similar to youtube live, but for audio but with embeddable html.
Recently(2022.01) most of CDNs support only file-based streaming protocol, like HLS/DASH/CMAF, even you publish the stream by RTMP or WebRTC, the CDN also covert the stream to these protocols.
If you want to build low lagging live streaming application, like RTMP, HTTP-FLV is recommend and you need a CDN to support HTTP-FLV rather than RTMP. HTTP-FLV works well on PC or mobile, please read this post.
You could build your CDN by open-source media-server cluster, like SRS Edge to delivery HTTP-FLV, based on AWS EC2.
For CDN which support HTTP-FLV, you could check Tencent Cloud Streaming Services, which supports publish by RTMP, and deliver by HLS/HTTP-FLV/WebRTC.
I need to generate .ISM files from MP4 files that are uploaded to Azure BLOB storage. Probably as soon as the user uploads a MP4 file to BLOB storage I should be able to fire up a Azure Function that does the conversion.
Can someone please help me how to do the conversion from MP4 to .ISM.
Note: I do not want to use Azure Media Service, it is too expensive.
The .ism file probably won't help you much at all for this situation.
If you are trying to avoid using AMS completely and just do static packaging, you should generate HLS or DASH content directly into storage blobs. You could do that with FFMPEG or the Shaka Packager tool from existing Mp4 file. There are lots of OSS solutions out there that can generate static HLS and DASH content if that is your goal.
The .ism file is primarily a feature of AMS - and it provides the information that the Streaming Endpoint (origin server) needs to dynamically packaging on-the-fly from standard MP4 files to MPEG DASH, HLS, Smooth and add on the DRM encryption for Widevine, Fairplay, and Playready. If you have no need for the multi-format dynamic packaging from MP4, then AMS is probably not the right solution for your needs.
If you can share - what parts are too expensive for you? The encoding, the streaming endpoint monthly cost for (standard endpoint cost?) or is it the overall egress bandwidth needed to deliver content from Azure (which won't go away with a storage based solution and is normally 90% of the cost of streaming if you have popular stuff.)
If you are trying to avoid encoding costs, you can encode locally or in ffmpeg on a server vm at your own costs, and then upload and stream with AMS - I have a good sample of that here - https://github.com/Azure-Samples/media-services-v3-dotnet/tree/main/Streaming/StreamExistingMp4
Thanks,
John
We are using Azure Media Services to play the MP4 videos.
In Azure Media Services there is a option to change the Streaming endpoints and it's units ( 1 unit = 200 mbps)
In my MP4 videos case if I increase my streaming endpoint units there will be any improvement in performance/ speed? or streaming is only applicable for MPEG-DASH/ HLS (.ism) videos only
Currently we didn't put any streaming endpoint units but it is playing instantly using Azure Media Player with out any delay in desktop.
But when it comes to Mobile Device(Android Samsung S4 5.0.1) same Azure Media Player in chrome browser taking 10 sec or more delay, to overcome this finally I used exoplayer to play the video it is also taking 6 to 7 seconds very first time but if we play same video second time it is taking max of 3 seconds delay.
I don't want that delay also and it should come down to 1 or 2 seconds max either first time or any time.
Is Streaming Endpoints really useful in this case or what should be the alternative ways to achieve streaming speed in mobile device.
if you guys suggest me best instant play video player for Xamarin Android also welcome.
If current your video is Multi-bitrate Mp4 and you have no streaming reserved unit, I guess you are getting a SAS URL for your video. That's progressive download and essentially the video is getting downloaded like a file from storage directly and our streaming service is just passing it through. However, if you purchase one reserved unit, you are actually adaptive streaming the video in streaming format such as Smooth Streaming, HLS and MPEG-DASH. The player will pull the right bitrates according to your current bandwidth and device CPU. Therefore, it will minimize the buffering. Here are of my blogs to explain the concept:
http://mingfeiy.com/progressive-download-video-streaming
http://mingfeiy.com/traditional-streaming-video-streaming
http://mingfeiy.com/adaptive-streaming-video-streaming
Therefore, by increasing the reserved unit more than 1 doesn't help on the loading if you don't hit the bandwidth limit. However, turning reserved unit from 0 to 1 does fundamentally improve the performance.
I am planning to write a nodeJS server for streaming videos, One of my critical requirement is
to prevent video download( as much as possible ), something similar to safaribooksonline.com
I am planning to use amazon s3 for storage and nodeJS for streaming the videos to the client.
I want to know if nodeJS is the right tool for streaming videos( max size 100mb ) for an application expecting lot of users. If not then what are the alternatives ?
Let me know if any additional details are required.
In very simple terms you can't prevent video download. If a rogue client wants to do it they they generally can - the video has to make it to the client for the client to be able to play it back.
What is most commonly done is to encrypt the video so the downloaded version is unplayable without the right decryption key. A DRM system will allow the client play the video, without being able to copy it (depending on how determined the user is - a high quality camera pointed at a high quality screen is hard to protect against (!). In these scenarios, other tracing technologies come in to play).
As others have mentioned in the comments, streaming servers are not simple - they have to handle a wide range or encoders, packaging formats, streaming formats etc to allow as much each as possible and will have quite complicated mechanisms to ensure speed and reduce file storage requirements.
It might be an idea to look at some open source streaming servers to get a feel for the area, for example:
VideoLan (http://www.videolan.org/vlc/streaming.html)
GStreamer (https://gstreamer.freedesktop.org)
You can still use noedejs for the main web server component of your solution and just hand off the video streaming to the specialised streaming engines, if this meets your needs.
I have an android application (client), asp.net web api web server (server), and Windows Azure Media Services (WAMS) account.
What I Want: To upload a 3-30 second video from the client to the server and have it encoded with WAMS then available for streaming via HLSv3 as quickly as possible. Ideally a video preview image would be generated as well. As fast as possible is something like sub one minute turn around. That's likely not realistic, I realize, but the faster the better.
Where I'm At: We upload the video to the server as a stream, which then stores it in Azure blob storage. The server returns to the client indicating upload success. The server has an action that kicks off the encoding which then get's called. I run a custom encoding task based off of the H264 Adaptive Bitrate MP4 Set 720p preset modified for taking a 640x480 video and cropping it to 480x480 at the same time as encoding. Then I run a thumbnail job that generates one thumbnail at 480x480. Depending on the reserved encoder quality this can take ~5 mins to ~2 mins. The encoding job time is only 30-60 seconds of that and the rest is a mix of queue time, publishing time, and communication delay.
What can I do to improve the client upload to video streamable turn around time? Where are the bottle necks in the encoding process? Is there a reasonable max speed that can be achieved? Are there config settings that can be tweaked to improve the process performance?
Reduce the number of jobs
The first thing that springs to mind is given you're only interested in a single thumbnail, you should be able to consolidate your encode and thumbnail jobs by adding something like this to the MediaFile element of your encode preset:
<MediaFile ThumbnailTime="00:00:00"
ThumbnailMode="BestFrame"
ThumbnailJpegCompression="75"
ThumbnailCodec="Jpeg"
ThumbnailSize="480, 480"
ThumbnailEmbed="False">
The thumbnail will end up in the output asset along with your video streams.
Reduce the number of presets in the task
Another thing to consider is that the preset that you linked to has multiple presets defined within it in order to produce audio streams at different bitrates. My current understanding is that each of these presets is processed sequentially by the encode unit.
The first preset defines the video streams, and also specifies that each video stream should have the audio muxed in at 96kbps. This means that your video files will be larger than they probably need to be, and some time will be taken up in the muxing process.
The second and third presets just define the audio streams to output - these wouldn't contain any video. The first of these outputs the audio at 96kbps, the second at 56kbps.
Assuming you're happy with a fixed audio quality of 96kbps, I would suggest removing the audio from the video streams and the last of the audio streams (56kbps) - that would save the same audio stream being encoded twice, and audio being muxed in with the video. (Given what I can tell from your usage, you probably don't need that anyway)
The side benefit of this would be that your encoder output file size will go down marginally, and hence the cost of encodes will too.
Workflow optimisation
The only other point I would is regarding the workflow by which you get your video files into Azure in the first place. You say that you're uploading them into blob storage - I assume that you're subsequently copying them into an AMS asset so they can be configured as inputs for the job. If that's right, you may save a bit of time by uploading directly into an asset.
Hope that helps, and good luck!