Tell me more about this.
1 Like
Not sure which part you are asking about.
Both the H.265 PR and the audio PRs have been pulled into dev, so they should be available in 0.115.
1 Like
How can I do it?
The PRs for the frontend and the android app have been merged. You can load the dev versions or just wait a few weeks until 0.115 comes out.
1 Like
Hi
Now that 0.115 is out, and installed, I was hoping my existing setup would just work, but sadly it doesn’t!
I have an rtsp HEVC camera, any pointers on a config that works, both the front and back end parts?
Camera url is :-
rtsp://192.168.1.10:554/user=admin&password=&channel=1&stream=0.sdp?
Thanks in advance to anyone who can help.
Ps I’m running hass.io on rpi 4, I don’t expect the performance to be good!
Kind regards
Jonathan
What device/browser are you using?
It will only work in iOS and Safari for now.
The reason for this is that Google has actively blocked H265 in Chromium. It also got Firefox to get on board with its crusade under the banner of promoting “royalty-free codecs”. (In reality it is a strategic business tactic - as a big content provider Google doesn’t want to be on the hook for big royalties to MPEG-LA, so they keep pushing their own codecs even though they are slightly inferior to the MPEG-LA ones.)
As I’ve mentioned above, there are community builds of Chromium which do support H.265.
We did add a workaround for playing H.265 on Android but temporarily removed it for 2 reasons:
- Since the work around involves drawing on top of the webview, it doesn’t work when scrolling or when drawn over, so we had to restrict the usage to exclude live_view picture-entities.
- With the addition of audio, some people realized that it would be better to start play muted. This required a change to our Android workaround. We have made the change to the Android side, but we want to wait until the app gets republished before making the corresponding change on the frontend to avoid causing conflicts.
1 Like
Ah, thanks, that explains it.
I’d misunderstood and thought the Android bit had been enabled.
Thanks for your work on this and for responding.
Time for me to go and play with browsers!
Yeah it’s a bit annoying how we have to work around this. Hope you can get it to work. We’ll try to get the Android part working again soon, but it will most likely always have somewhat limited functionality.
By the way, the browser alternatives I suggested may not work since HEVC is not fully working in hls.js.
For iOS/Safari you have [HLS video source] -> [native Safari HLS player]
For non-Safari, you have [HLS video source] -> [hls.js player] -> [browser]
So for non-Safari, installing a HEVC capable browser is necessary but not sufficient as hls.js HEVC support is also required. HEVC support in hls.js is still lacking, and there isn’t much demand to get it working as most browsers except Safari don’t support HEVC, and Safari users don’t need hls.js.
See https://github.com/video-dev/hls.js/issues/3003#issuecomment-687160523 . I was able to get the Bitmovin stream to play but not the Apple one.
Dang - this is frustrating, for some reason my hikvision cameras keep reverting to h265 even after switching them down to 264.
I can’t get it working with h265 in iOS in the actionable notifications preview, in safari or in Chrome (as mentioned) 
Do you use the mobile or web app? This can force the camera to revert. You should be able to enable logging and see exactly what is changing it. I wound up setting my substreams to h.264 instead. At 960/480@15 the stream is larger than the main stream for the most part at 2560/1440@15.
This literally cuts my storage in half. I just set it up a few days ago and I think I’m just going to disable the feeds in HA. I’m confused to why I can play h.265 streams on the camera’s web page in Firefox but not in HA because of Firefox.
Hmm, that’s weird…they should work fine in the iOS app (not sure about actionable notifications though) and in Safari. The stream should get passed through to the native player the exact same way for both types of codecs.
Chrome won’t work, as I mentioned above.
Everything works fine when using H.264 but not when using H.265? Have you disabled all kinds of proprietary codec enhancements like H.265+?
Yeah, the compatibility issues across various devices sucks, but there’s not much more we can do. As I mentioned above, a lot of the lack of support is due to the codec wars between Google (and the content providers or codec freeloaders depending on your view eg Netflix) and MPEG-LA (the codec developers or codec extortionists depending on your view).
For my own setup I have all the cameras on H.265 except one which I cast since the cast device doesn’t seem to support H.265 as well as H.264. No issues with the iOS app or Safari.
I’m not sure how you get H.265 streams in Firefox. It’s pretty well documented that the browser doesn’t support H.265. Some camera manufacturers provide web browser plugins to help play camera streams, but I thought they removed support for those types of plugins in Firefox. Is it possible that it’s actually just playing a substream?
My sub steams are D1 480x704 aside from the obvious blurry picture you can just switch the resolution from sub to main stream. It also work fine on chrome.
I grabbed the code from the web page it seems to use h5player for the stream.
I’m sure there is someway to view the codec used in the inspector but I just not sure how to find it. In the debbuger I can see the web app is java and there I find h5.js
<div id="h5player_header_2" class="h5player_header"><i class="h5player_closeIcon"></i></div><div id="videoBackground_2" class="video_background" style="margin-left: 494.5px; margin-top: 82.75px; display: none;"></div> <canvas id="canvasplayer_2" style="position: absolute; display: block; top: 15px; left: 0px; width: 1110.67px; height: 241.667px;" width="1920" height="1080"></canvas> <div id="videoLoading_2" class="video_loading" style="display: none;"></div> <video id="videoplayer_2" style="position: absolute; display: none; top: 15px; left: 0px; width: 1110.67px; height: 595.667px;" width="300" height="300"></video> <div id="h5playerProptip_2" class="h5playerProptip" style="display:none"></div> <div id="h5playertip_2" class="h5playertip" style="display:none"><span id="h5playertipWord_2></span><i class=" i-close"=""></span></div><div id="downloadCert" class="download-plugin fn-hide" style="height: 150px; margin-top: -75px; background-color: rgb(0, 0, 0); z-index: 110000; display: none;"> <div style="margin-top: 59px;"> <a class="pluginMsg" id="downloadCert_a" onclick="downloadCert()" href="javascript:void(0)"> <span class="download-plugin-icon"></span> <span t="sys.DownloadCer">Download Certificate</span></a> <div> </div></div></div>
I can’t make much of the html you posted, and googling of “h5” and “h5player” was a bit inconclusive. It looks like there may be some Chinese js libraries that use web assembly to decode H.265 video such as https://github.com/tsingsee/EasyPlayer.js .
Unfortunately I don’t have the time now to look into it much further. If you have time, maybe you could dig into it and get us a H.265 solution that works on all platforms =)
Looking further I found a js wrapper for ffmpeg. I could be wrong but it seems that either of these h.265 libraries can be used with ffmpeg:
https://bitbucket.org/multicoreware/x265_git/src/master/
which is used by VLC and
Which I think the Dahua webapp uses with ffmpeg
You will have to tie the codec to a player which can play HLS streams. Some of those Chinese libraries do that (maybe with ffmpeg in web assembly), but I’m not sure about the licensing on them. Actually I’m not sure HA is allowed to incorporate the codec at all. There seems to be an exemption for costless software but that is only from some of the patent holders - see https://en.wikipedia.org/wiki/High_Efficiency_Video_Coding#Provision_for_costless_software
BTW, hls.js could have gone this route (incorporating ffmpeg in webassembly) but decided against it, possibly for similar reasons - see https://github.com/video-dev/hls.js/issues/2451#issuecomment-592770018
Good luck!
1 Like
I have a hikvision system too. I don’t think I have the problem of it not keeping the setting, but thought it might be worth noting for yourself or others that there are separate settings for the main stream and secondary stream (i.e. 101 vs 102), and it is possible to have one H.264 and another H.265.
I have “Synology DSM” integration enabled with all my cameras on it. Unfortunately, they just show snapshots, looking pretty and doing nothing because they are streaming in h.265.
+1 for this
Is h265 still not implemented through HA and desktop browsers (Chrome)?
1 Like