I'm using the MediaSource in browsers to play H264 streams. This works very stable and good.
Now I just received a new device which produces H265 (hevc), and I stucked here.
I need to add the mimetype to addSourceBuffer, which in my case seems hev1.1.2.L153.
This is not supported by any browsers on my notebook.
From 2018 I found a forum post on Dash.js quoting:
I think Dash.js doesn't support any kind of HEVC. This maybe be confined to MediaSource, which doesn't support HEVC at present.
My question: does MediaSource support any HEVC currently, or it is still stuck with H264?
My question: does MediaSource support any HEVC currently, or it is
still stuck with H264?
Depends on the browser, Edge may support it in some cases (hardware support), as well as safari, but Chrome (which is the majority of the market) will never support it due to h.265 outrages licensing costs.
Related
WebRTC requires too much processing power on server so doing it massively will be cost-prohibitive.
For nearly all other platforms - both for Windows and Mac - Chrome, Safari desktop, even IE and Edge, and Android - there is a Media Source Extensions API (https://en.wikipedia.org/wiki/Media_Source_Extensions) which allows sending stream over websockets and play it, it works. Problem is just with iOS.
Is there anything better (lower latency) than HLS which would work for me?
If not, is there a WebRTC server which is free and better scalable/more stable than Kurento Media Server (https://github.com/Kurento/kurento-media-server)?
There is a jsmpeg player http://jsmpeg.com/ but it is MPEG-1 only so will require unacceptable amount of bandwidth. There is broadway.js but it does not support audio...
Is there anything better (lower latency) than HLS which would work for me?
HTTP Progressive is a fine technology for this. It can be ran at much lower latencies than a segmented technology like DASH or HLS, and requires very little in terms of server-side resources. Look into Icecast for your server, and FFmpeg as your source.
There's no point in sending video over Web Sockets, unless you're implementing a bi-directional protocol. This isn't uncommon for ABR support, but it's definitely not the most efficient or simple way to do it.
Since you don't want to implement webRTC by yourself and need lower latency than HLS, I would prefer a media server. There are many media servers available in the market. But if you are looking for free and open source media server, your options are limited to few.
I would suggest red5 media server which is free and open source. Please check this link to find more about red5. If you use free red 5 media server you need little knowledge of java. Red5 also has a paid version called red5 pro which has better webRTC support and higher capabilities. Red5 is mostly for rtmp with flash player pulgin and its fairly new for red 5 webRTC streaming.
Also you can use wowza streaming engine trail version with limited number of connections. So these are the easiest options for you.
I am trying to make a web site with IIS smooth streaming but all the tutorials and examples that I found use Microsoft Expression Encoder 4 pro. According to them only the pro version is capable of using H.264 compression. But the problem is Microsoft Expression Encoder 4 pro is discontinued and the available free version dose not support H.264 compression. So I want to know whether there any other encoders(commercial or freeware) that I can use with IIS 7. Please help me
I have used Sorenson Squeeze with relative success for on-demand video encoding. It does not do live video but can successfully encode plan video files into many different formats. This is the "cheap" encoder I recommend for everyday light use. It does most of what Expression Encoder used to do.
For professional-quality encoding needs, you will want to look towards products from Harmonic, Envivio and similar vendors. Together with high quality and broad feature set you will, of course, also be faced with a significant pricetag.
There are also Wowza and Unified Streaming Platform which offer such services for relatively low cost, though my personal opinion of them is not very high - they seem more marketing than functionality oriented businesses.
I'm trying to build an iOS app that plays video files and does some interesting things using MTAudioProcessingTap. I need it to be able to play all sorts of formats, including some that are not supported by Apple. I'm thinking of branching out from VLC, but I can't figure out if it uses Core Audio/Video at any point or if it's running something else completely.
If it's not, is there a library I can use to take care of the 203572964 codecs being used out there?
Thanks.
Preliminary note: I'm the developer of VLC for iOS so the following may be biased.
MobileVLCKit for iOS includes 2 different audio output modules. One of them is a high level module based on AudioQueue which is fairly incomplex but a bit slow. The other is based on AudioUnit, the low level framework of CoreAudio, quite a bit more complex, but way faster. Depending on your current experience, either module would be a good way to start.
Regarding the one library supporting all codecs thing: basically there are two forks of the same library: libav and FFmpeg. VLC supports either flavor and abstracts the complexity and the ever-changing APIs (which are a real pain if you intend to keep maintaining your app across multiple releases of those libraries). Additionally, we include a quite well performing OpenGL ES 2 video output module which is using shaders to do chroma conversation. All you need to do is embedding a UIView. MobileVLCKit handles the rest.
Speaking of MobileVLCKit: this is a thin ObjC layer on top of libvlc simplifying the use of this library in third party applications by abstracting most commonly used features.
As implicitly mentioned by HalR, libvlc does not use hardware accelerated decoding on iOS yet. We are working with the libav developers on a generic approach, but we are not quite there yet. Thus, we have to do all the decoding on the CPU, which leads to the heating but allows us to play virtually anything instead of H264/MP4 using the default, accelerated API.
If you can't figure out how its playing the video, at its lower level, that perhaps is a sign that you should keep working with it instead of trying to outdo it. Video processing is pretty difficult and often unsupported formats are unsupported due to patent issues. I really haven't seen anything better than VLC that is publicly available.
VLC 2.1.x appears to use AudioToolbox and AVFoundation.
One other issue, though, is that when I was doing work with VLC, I was stunned how it turned my iPod Touch into a miniature iron, because it was working so hard to process the video. Manually processing video is very processor intensive and really is a drain. So your way or VLC could still have some additional issues.
I'm putting together a site that will include some instructional videos that will be 1 to 3 minutes long. The users will be accessing these through standard and mobile browsers. I'm particularly concerned with users of i-devices, such as iPhone/iPod Touch/iPad.
To deliver the videos, I'm will probably use videojs.com player - it seems like a pretty robust choice. Unfortunately, I don't know first thing about what file formats and standards to use for encoding files. H.264 Baseline profile seems to be a good choice, but I really need some direction on where to read up on what might be the best choice.
Please help :)
The best resource I've found for this information is Dive Into HTML 5. They have a very concise breakdown of which formats will work with each of the browsers.
The long and short of it, however, is that h264 baseline is the way to go, especially if your HTML5 video player has Flash failover.
While HTML5 video is currently the standard in the mobile space, a back of the envelope calculation reveals that only about 40% of desktop browsers users can view it as compared to Flash's 99%+ market penetration. Moreover, you'd have to encode and store your videos twice (h264 and Theora) in order to reach all HTML5 video capable browsers.
However, by using h264 video and a Flash failover, you can cover all iDevices plus all browser that either don't support HTML5 video, or support HTML5 video for a format other than h264.
One word of warning: iDevices only support the h264 baseline up to level 3.0, so make sure to stay within these specs.
Hopefully that helps.
My software encodes videos using the standard Windows AVIFile functionality. That means, it can use all the DirectShow Codecs that are installed.
I recommend my users to download the XVid Codec themselves, but that's inconvenient.
I cannot bundle XVid since my software is not GPL. Is there any good direct-show-compatible video codec that can be redistributed with a commercial application? Requirement: The videos must look great on YouTube.
If not, I could switch from AViFile to another library (e.g. FFMpeg). But I'd like to avoid that if possible.
Thanks! :-)
Edit: The videos are computer animation with very sharp details (explosions and sparks). The video should be high-bitrate.
Theora is an excellent open source codec with very good DirectShow support. You also might consider google's newer WebM codecs. You dont say what kind of video you are distributing (from a camcorder, animation/computer rendered graphics, etc), so some of the choice of codec may depend on the exact nature of your video.