What Is H.264 And H.265

[Kathrine Selvage]

Hi everyone.

My idea is the next, It would be awesome if i can allow transcoding from h.264 to h.265 to get better Bitrates and lower files size.

So basically all my contents is on H.264 because of Web compatibility issues and for some of the content is not available in H265 so my idea is to force transcoding on the fly from H.264 -> H.265 in case the device support it, i really don't want to re convert all my library to h.265 because it can be 45 times the size of already used to maintain the h.264 + h.265 .

So allow people to transcode from h.264 to h.265 on the fly will be awesome to reduce bitrates and size at the end and depending in client support.

I currently i'm not allowing transcoding and as i can see on my networks records the egress from my NAS is very big and some of the content transcoded to h.265 on the fly will gain 40 percent of the bitrate maybe not sure how to calculate this,

An other things to add to this feature Request will be to allow us to Deny Transcoding for a Specific Folder or Library because i have some library like 4K content not playable on web browsers so i deny all transcoding things, but if the things above is featured and developed it requires to allow "Codec UP Scale" Transcoding so it will be nice to have it divided and allow Up Codec transcoding like H.264 TO H.265 but not H.265 TO H.265 i guess this need very improvements to manage the transcoding.

Just wondering if anyone knows why the 4.0 channel option is not coming up? I was able to export it in Apple ProRes but of course I would love to find a way to encode with h.264 or h.265 for smaller sizes and optimal YouTube uploading. I am trying to export a 360 VR video with ambisonic sound. I have read that h.264 has taken this option away recently. Is this true? I am running macOS 11.5 Big Sur, are we still waiting for compatibility? Any help would be much appreciated.

We're sorry about the poor experience. In the latest release only mono, stereo & 5.1 channels are available for Ambisonics audio. We're currently investigating this issue. For the time being, you may try using Premiere Pro 2020 for 4 channel Ambisonic audio support.

Hello, I am having the same issue using Premiere Pro 2022. I need to export the video in h265 with the audio in 4 channels for a VR application. It is still not possible to export the audio in 4 channels. Is something still to be fixed or is there a setting that I've been missing ?

Where can i find the projectsettings for my audio? I think it's having the right settings tough.
Within the exportsettngs i can click on 4 channel audio but it stays at stereo.
When i'm chosing another export format (like AAC or Apple ProRes) it's possible to select the 4 channel option and is seems to work. Why doens't it work with H.264/H.265?
I'm having Adobe Premiere Pro 22.6.2

MJPEG has one clear advantage to everything else: It works in any browser! The problem is that it takes about 5-20x the hard drive space as H.264, which means that long term data retention is absurdly expensive. It also take 5-20x the processing power of H.264, which is why it is usually limited to the lowest resolution cameras or HD cameras that only can record when they detect motion.

Because MJPEG files are so inefficient, MJPEG is really only used on cameras where you don't have to worry about storing lots of data. For example, if you have a consumer-grade doorbell camera, it is recording, on average, about 3 minutes of video - a day. People who have consumer-grade doorbell cameras, also tend to only watch a single camera at a time, so it doesn't really matter if it takes your computer 20x the resources to display that video. If you have a commercial-grade camera, watching say an office or restaurant, you are typically recording 9-20 hours a day, while cameras watching machinery or oil refineries might be recording 24 hours a day. Commercial grade cameras also need to be able to be viewed in a myriad of different grids and views. The difference in how much you have to record and how many videos you need to watch at once, creates a very big difference in the required video compression for devices that might seem to do exactly the same thing: record video.

H.264, H.265 and VP8/VP9/AV1/WebM all have what are called "Golden Frames" which are 100% true images, and then use block oriented compression to define the differences from Frame A to Frame B. If part of Frame B differs from the Golden Frame then it is updated, if not it just uses the Golden Frame's info. This saves massive amounts of storage space without really losing anything of value. It also focuses nearly all of the processing power of the camera on the areas of the screen with activity, so you can record much higher resolution video in H.264/5 than MJPEG. Block Oriented Compression is great, because it reduces storage costs, allows you to stream higher quality, crisp clear video without taking too much data, and is what allows you to be able to watch things like Netflix, Youtube, or your surveillance video in HD. MJPEG video would never be able to load fast enough.

H.264 is required for ONVIF support (ONVIF is the Open Video Network Interface Format), which is what different manufacturers devices to talk to each other. If you buy another brand camera and want to record it with a SCW NVR, you would need both devices to have ONVIF compliance for the cameras to talk to each other.

Both H.264 and H.265 were the result of collaboration by many parties including Apple, Microsoft, CIsco, Dolby, and the Moving Picture Experts Group. Most of the movie and tech industry was involved with the creation of the patents which went into H.264, including Google and Mozilla (the maker of Firefox).

H.264 and H.265 require license fees to use them, and this makes adopting a technology difficult and expensive. Google argued that H.264 and H.265 should be open source, so that anyone can use them. At the time, the Moving Picture Experts Group wasn't enforcing the patent fees much anyways, since everyone was just saying "I'll let you use my patents royalty free, if you let me use your patents royalty free." H.264 was kinda free (at least if you had part of the patent contributions). This seemed like a waste to Google - and just to be clear, we think it was a waste. Paying lawyers and requiring complex negotiations to result in, what was usually, just the free trading of patents is a waste of money. Google and a couple other patent providers, including Mozilla, agreed to open source their patents to make it truly free. They thought everyone else would do so as well.

And then, Google lost their power. Not only did the other providers not open source H.264, they did the opposite - they raised the rates of licensing. The equilibrium had shifted. Before Google open sourced their patents, there were no major parties to collect fees from. Now, the other companies now had a major player to charge for the use of their patents. Google could no longer say "I'll let you use my patents royalty free, if you let me use your patents royalty free," since anyone could use their open source patents. Google and Firefox could no longer include H.264 support without paying fees. So, Google and Mozilla (the maker of the Firefox web browser) started working on a different block oriented compression called VP8 (and whcih would evolve into VP9, AV1, and WebM). Then Google blocked H.264 in it's web-browser Chrome to try to force all the other parties to open source their patents or use VP8/VP9/AV1/WebM.

Google largely failed to convince most companies to switch to VP8 compression because it took too long to develop (for example, a full decade later, there is still no camera hardware that can record in VP8/VP9/AV1/WebM natively, on the hardware level), and because it faced massive legal challenges. Yes, VP8/VP9/AV1/WebM all ended up being free and open source, but it wasn't free and open source for some time, and it was very unclear as to whether a brand who adopted it would get their pants sued off for patent infringement. Google has now admitted that VP8/VP9/AV1/WebM infringed on at least some of Apple's H.264 patents. For a while, it was also quite substandard in terms of compression - nowadays, VP9 is in the ballpark of H.265 (it is about 20% worse*), but ONVIF had already settled on H.264/H.265 as the standard.

Google and The Motion Picture Group reached an agreement to be able to use H.264 video in Youtube. The MP4 container format with the H.264 video codec is now supported by Chrome and Firefox again in some, but not all cases (although Chromium and Opera do not support the format).

(We say "supported in some cases" because in each Chrome build, Google frequently changes what h.264 profile(s) that its browser supports. This guide isn't meant to be super technical, but even inside h.264 compression you have different greater or lower levels of compression called "profiles." Most ONVIF cameras use either a manufacturer specific profile or the "advanced" h.264 profile. Lately (since Chrome build 88) Google only wants to support "base" h.264 compression). As of 9/12/2019 for the newer Admiral/Imperial systems, partial support for Chrome, Firefox, and updated Safari browsers has been added.

Sadly, the overlay for motion grids, line crossing, text overlays, etc are not supported by this agreement. As almost all security cameras have configurable text overlays telling you the time and date and name of the camera/location, this means that nearly all security cameras still cannot use Chrome/Firefox. The programming language that the entire security industry uses for those overlays is called NAPI. Chrome and Firefox once supported this plugin language, but don't support it anymore.

The security industry is caught in the middle of this, and this is why you'll notice that Mozilla Firefox / Google Chrome / Safari support is largely missing from most security camera systems and Microsoft Internet Explorer browser support is included. Because ONVIF rejected VP8/VP9/AV1/WebM, if you make a VP8/VP9/AV1/WebM camera, it can't talk to any other devices and people want the ability to use whatever device meets their needs.

c80f0f1006