H265 H264

[Saundra Balock]

Iwant to convert all videos based on h265 to h264 and at the same time reduce the resolution to for example 720p to avoid working on very big resolutions and later uploading that kind of big size files.

I know that FFMPEG will solve all my problems, but including FFMPEG will increase the app size very much, I'd like to avoid that. I am trying to use currently the Android MediaCodec, but it looks like it would work fine with converting h264 to h264 but not with h265 to h264.

I have raspberry pi 2 with osmc/Kodi installed on it, I have several h265 videos on it which can't be played smoothly. I would like to convert them to h264 using some conversion tool or package that should be installed on pi. Can someone please advise which package and how to use it to achieve the conversion ?

hi, i am new to video ai. i am trying to increase resolution of a movie i have. it is 960x540 and i am enhancing it to full hd. question is which encoder i should use? i chose randomly h264 because it was giving me mp4 instead of mov. what are the differences between encoders? does it affect output quality?

Use the H.265 (auto: bitrate) in the TVAI settings, if this is your final file you want to play on devices.

the quality loss is not noticeable, and you get smaller file size compared to H.264 at the same quality level. ProRes is already diminishing return for playback.

If you planning editing the video later with some video editing tools after Topaz upscale, then use ProRes HQ. (the general Topaz best practice guidelines if you want to edit a video, is to edit your video with external tools 1st and use Topaz as the last step, so you might not need to edit the video Topaz if followed by their best practice)

I always, always process to ProRes and then if I need to will create an MP4 using the x264 encoder (anything but the dreadful MainConcept one) if I need a lower file size. The masters I always keep in best quality - okay, ProRes is also lossy, but nowhere near as lossy as H.264

So we have a test clip that was shot RAW (maybe compressing already compressed footage is easier? I don't know, anyway..), that includes decent movement but isn't some stupid test case that means nothing in real life, that doesn't repeat (because the clips are different lengths), and has some deliberately almost crushed blacks to test the pixelation that h264 and h265 sometimes get in the shadows.

Then I rendered a bunch of clips, either h264 from Resolve, or h264 and h265 from ffmpeg. I tried rendering h265 from Resolve but had issues, and in this test all the maximum bitrates I tried all created the same size file, so I abandoned that. Common wisdom online is that Resolves h265 export mechanism isn't the best and you should use ffmpeg anyway.

I guess the real question is, how much h264 do you have to have to equate to Prores? The answer seems to be "about the same bitrate, but probably a little less for an ALL-I codec, and a little less bitrate again if it's an IPB".

I think the biggest difference for most of these codecs is how easy or hard it is on your CPU and GPU when editing. I think with any of these compression codecs if you turn up the bitrate high enough or reduce the compression ratio far enough they will eventually all look the same, but when you are editing them in post your CPU, GPU, and NLE will definitely be affected by how much information is missing between frames.

I would also imagine the quality differences would be more apparent when a lot of things change between frames. For example, I live in FL, and frequently film drone footage over water.....H.264 completely falls apart when water is involved especially waterfalls because no two frames are alike. I would imagine in that scenario ALL-I would be better but I have not tested it. Timelapses are another place where I've seen YouTube completely destroy my footage. If there is too much motion in the timelapse it turns into a blocky mess on YouTube.

Normally these codecs are discussed in terms of digital intermediaries, or delivery formats, but in todays cameras they are acquisition formats. It doesn't matter what I think about Prores or h264, my GH5 won't grow Prores support regardless of how much I like it, so this investigation was to answer the question about how bad it is to have h264 instead of Prores support in your camera.

The file, which I realise I haven't shared, has a lot of very complex motion in it, and is high-resolution, so combined with a test that is relative, comparisons should be able to be made. The SSIM is a mathematical function, not a perception-based one, so it makes it possible to compare very very high-quality files.

I guess the only news is that h265 is better than h264 or Prores, but it's not 2x better, at least not at this end of the curve. We're in serious bitrate territory here, so not what these h26x codecs were designed to do.

Great tests! One thing I will say is that when I did my ProRes vs H265 tests, I tested on a >HD Raw file in order to maximize the quality of the reference file, to avoid softness and artifacts from debayering. Additionally, my reference file was 4:4:4 rather than 4:2:2... fwiw.

This isn't a completely pure stress-test, but neither is real footage. Most lenses aren't pixel sharp, and our love of bokeh, motion blur and camera stabilisation of any kind ensures that much of the image is blurry and doesn't move that much from frame to frame. I have done stress testing of codecs before but it makes it more of a theoretical exercise rather than a practical real-world test.

I'd share the files, but the source files are currently up to 22Gb, so would take forever to upload and basically no-one would download them. I've done things like this in the past and the download counter just sits there after a week of uploading at my end.

I used 4K raw files, and exported them as uncompressed 10 bit 444 HD files and did all my tests in HD, so yes I downscaled. And that's pretty similar to my workflow, where I always work on an HD timeline using the original files with no transcoding.

Makes sense that you downscaled to match your workflow. I didn't, but considering that we're comparing cameras that have UHD Prores HQ with ones that have UHD 400Mbps 422 10-bit h264 All-I with ones that have UHD 100Mbps 420 8-bit h264 IPB, it seems a reasonable comparison.

For example, Cinemartin claimed that h265 is 100x as efficient as Prores 4444 (which Andrew reported on here along with some other new outlets, presumably before anyone could get their hands on it to actually check). According to this excellent resource at frame.io Prores 4444 HD is 264Mbps and UHD is 1061Mbps.

Does that sound even remotely plausible? Why would people be talking about bitrate? My phone records at many times that rate! The image quality obviously doesn't bear this out, but unfortunately if you google "h265 Prores" you don't really get much else, so that's why I was motivated to do this test myself.

@kye Yes, your H.264 files are 8 bit. So in your initial run, were all your tests generated using either resolve or ffmpeg using your reference file, or were any made directly from the source footage?

1% of the file size is not remotely true, unless you start with a tiny H.265 file and then render it into ProRes which will increase the size without extra quality. I wouldn't trust much that comes from CineMartin.

Of course, the content matters a lot for IPB efficiency. So I guess you might be able to engineer a 1% scenario if your video isn't moving, and you use the worst ProRes encoder that you can find. (Stuff like trees moving in the wind is actually pretty far on the "difficult for IPB" spectrum, though it looks like only about half your frame is that tree).

In my initial run the Resolve ones were from the original timeline, but all the ffmpeg ones were from my 422 reference file, which I have now replaced with a real reference file. I'll start re-running the conversions again.

3a8082e126