Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Comparing H.265 (HEVC) and H265 video file size

janstechtalk.blogspot.com

Post reply on HN
Print view View original

91–100 of 121 posts

Re: Comparing H.265 (HEVC) and H265 video file size

#91

Post by Dylan16807 »

bawolff wrote: post #86
Dylan16807 wrote: post #83

Earlier quoted context omitted.

If you assume there's only one file you could probably skip it. But the question was about using the zip file as a source for streaming, and that will work fine even if you have to spend an extra read to load the directory first.

I don't think you can safely assume random reads if you are streaming. Usually the point of a stream is you have to process the file in-order. Regardless, if for some weird reason you really liked the zip compression algorithm (DEFLATE), you would probably just use gzip instead (same compression algorithm, no weird file format with critical metadata at the end). Its also the compression algo used by PNGs.

> I don't think you ca safely assume random reads if you are streaming.

I could interpret this a couple ways, so let me try to clarify.

If you're talking about the ability to seek around inside the video, it is correct that this will not work well.

If you're talking about seeking to the end of the zip file to read the directory, I don't think that was part of the scenario. My interpretation of the question is that the server has a zip file and has to output a video stream directly from the zip.

If the zip itself is being delivered as a single stream, start to end... I have no idea what kind of scenario this is. There's no zip-streaming protocol out there. Filesystems can give you the end of a zip. HTTP can give you the end of a zip.

> Regardless, if for some weird reason you really liked the zip compression algorithm (DEFLATE), you would probably just use gzip instead (same compression algorithm, no weird file format with critical metadata at the end). Its also the compression algo used by PNGs.

Maybe. You might want windows users to be able to easily extract the video.

Re: Comparing H.265 (HEVC) and H265 video file size

#92

Post by jraph »

dylan604 wrote: post #55
jetzzz wrote: post #40

The comparison of H.264 and H.265 in this article doesn't make any sense. Lossy codecs can make files almost arbitrarily small at the expanse of quality. You should look at both quality and size; size alone doesn't mean anything. Also H.264 and H.265 are just formats; there are many encoders of varying quality which can generate such files and each encoder has tons of settings. I don't know which encoder macOS uses b…

ffmpeg only uses x264 if you tell it too. if you don't set -c:v libx264 when creating a .mp4 output, i'm pretty sure it uses the libav h264 encoder. if you use a binary of ffmpeg without --non-free/--non-gpl (forget which) enabled, do you even get x264?

Probably not --non-gpl, x264 is under the GNU GPL.

Re: Comparing H.265 (HEVC) and H265 video file size

#93

Post by dylan604 »

fireattack wrote: post #87
dylan604 wrote: post #49

Earlier quoted context omitted.

For science, I just took a 10 second screen recording of my Mac with nothing but my tiny mouse cursor moving around for a few seconds which means a very static shot. The recording came out at 7.5MB. There was no audio in the original recoding. I then used that as a source to transcode with x264 crf 23. New filesize 2.0M. ~26% ffmpeg -i input.mov -c:v libx264 -crf 23 x264.mp4 Next, I used the same 7.5MB source to tran…

Without at least some semi-objective compassions on the "visual quality", your data is meaningless. Like, how can you tell crf23 of x264 is closer to your x265-x265 version than, say, a crf24 x264 one? As a rule of thumb, x265 works better (compared to x264) at lower bitrate / worse quality. You won't be able to achieve "same quality, half size" at higher bitrate easily.

Sure, we could runs some PSNR or SSIM comparisons. However, I've been doing this for a hot minute, and h.265 is pretty damn good. Getting 4K video filesize for VR to run on a phone based headset was never going to happen without it. h.264 encodes just were never going to make it in the real world for the frame size and TRTs. Once we knew the target devices could handle h.265, it was a game changer. That was way back in 2015 when live action VR was almost a thing.

From years of real world experience, h.265 produces much smaller files by being able to use a lower bitrate to achieve the same visual quality has previous h.264. Guess what. H.264 did the same thing to MPEG2. Not really sure why this is so unbelievable.

Re: Comparing H.265 (HEVC) and H265 video file size

#94

Post by dylan604 »

boomboomsubban wrote: post #21
dylan604 wrote: post #16

Earlier quoted context omitted.

h.265 makes files smaller than h.264 for a given bit rate. So an h.265 I-frame will be smaller than an h.264 I-frame. If it's a mostly static computer screen, then you can get even better encoding effeciency by using a longer GOP structure so the I-frames are spread out even futher. Of course, the trade of is seeking gets worse, but works out great for push play and watch type of deliverables. h.264 can do this as we…

Is there any reason to suspect that they used a longer GOP structure? Is the default one for ffmpeg longer than the recording software?

From my specific tests from elsewhere in this thread, I did further analysis of the files that were run based on the examples listed in the comment.

The original screen capture H.264 files did have a 1 second GOP size. However, the very simplistic ffmpeg commands to make the h.265 & h.264 files that I made used the default GOP settings from ffmpeg. Turns out, the default is 4 seconds. That would easily help get the final file size down.

Re: Comparing H.265 (HEVC) and H265 video file size

#95

Post by fireattack »

dylan604 wrote: post #93
fireattack wrote: post #87

Earlier quoted context omitted.

Without at least some semi-objective compassions on the "visual quality", your data is meaningless. Like, how can you tell crf23 of x264 is closer to your x265-x265 version than, say, a crf24 x264 one? As a rule of thumb, x265 works better (compared to x264) at lower bitrate / worse quality. You won't be able to achieve "same quality, half size" at higher bitrate easily.

Sure, we could runs some PSNR or SSIM comparisons. However, I've been doing this for a hot minute, and h.265 is pretty damn good. Getting 4K video filesize for VR to run on a phone based headset was never going to happen without it. h.264 encodes just were never going to make it in the real world for the frame size and TRTs. Once we knew the target devices could handle h.265, it was a game changer. That was way back…

> Not really sure why this is so unbelievable

No one is saying that. Everyone knows H265 is better than H264. Just saying your number is meaningless without either fixing the bitrate or the quality.

Re: Comparing H.265 (HEVC) and H265 video file size

#96

Post by mckirk »

> video: the H.264 codec (or MPEG-4 Part 10), once upon a time know in the scene as DIVX.

That is incorrect and bothered me enough that I scoured the web trying to find old scene release standards. Fascinatingly, there's a whole Wikipedia article on those[1] and it's still possible to find the original .nfos in strange corners of the internet[2].

But long story short, a DivX release was standardized to DivX 3.11, which was actually a reverse-engineered Microsoft codec and not actually MPEG-4 compatible[3]. But later DivX versions implemented MPEG-4 Part 2[4] -- that is still a completely different thing than MPEG-4 Part 10[5] though, which describes H.264 (but calls it AVC).

[1]: https://en.wikipedia.org/wiki/Standard_(warez) [2]: http://lunamoth.biz/pe.kr/cgi-bin/gm/archives/tdx2k2.nfo [3]: https://en.wikipedia.org/wiki/DivX [4]: https://en.wikipedia.org/wiki/MPEG-4_Part_2 [5]: https://en.wikipedia.org/wiki/Advanced_Video_Coding

Re: Comparing H.265 (HEVC) and H265 video file size

#97

Post by boomboomsubban »

dylan604 wrote: post #94
boomboomsubban wrote: post #21

Earlier quoted context omitted.

Is there any reason to suspect that they used a longer GOP structure? Is the default one for ffmpeg longer than the recording software?

From my specific tests from elsewhere in this thread, I did further analysis of the files that were run based on the examples listed in the comment. The original screen capture H.264 files did have a 1 second GOP size. However, the very simplistic ffmpeg commands to make the h.265 & h.264 files that I made used the default GOP settings from ffmpeg. Turns out, the default is 4 seconds. That would easily help get the f…

You have went far beyond what I expected, thank you. And yet the original post I replied to is still a bit of a mystery. A recording of a desktop played a role, but h.265 still seems like a large part.

Re: Comparing H.265 (HEVC) and H265 video file size

#98

Post by chii »

Dylan16807 wrote: post #91
bawolff wrote: post #86

Earlier quoted context omitted.

I don't think you can safely assume random reads if you are streaming. Usually the point of a stream is you have to process the file in-order. Regardless, if for some weird reason you really liked the zip compression algorithm (DEFLATE), you would probably just use gzip instead (same compression algorithm, no weird file format with critical metadata at the end). Its also the compression algo used by PNGs.

> I don't think you ca safely assume random reads if you are streaming. I could interpret this a couple ways, so let me try to clarify. If you're talking about the ability to seek around inside the video, it is correct that this will not work well. If you're talking about seeking to the end of the zip file to read the directory, I don't think that was part of the scenario. My interpretation of the question is that th…

the question in the OP was to have the avi file be zipped, and it would offer similar levels of compression.

But if you're streaming a zip file down the line, can you view the stream as it partially loads, which is possible with certain video formats (esp. if the player can handle missing key frames etc).

I was under the impression that a zip file cannot be partially read and reconstruct partially the contents.

Re: Comparing H.265 (HEVC) and H265 video file size

#99

Post by dylan604 »

fireattack wrote: post #95
dylan604 wrote: post #93

Earlier quoted context omitted.

Sure, we could runs some PSNR or SSIM comparisons. However, I've been doing this for a hot minute, and h.265 is pretty damn good. Getting 4K video filesize for VR to run on a phone based headset was never going to happen without it. h.264 encodes just were never going to make it in the real world for the frame size and TRTs. Once we knew the target devices could handle h.265, it was a game changer. That was way back…

> Not really sure why this is so unbelievable No one is saying that. Everyone knows H265 is better than H264. Just saying your number is meaningless without either fixing the bitrate or the quality.

Sure. Don't believe some random dude from the internet. But if you're not going to go through the hassle of running the tests on your own, your "meaningless" claims are meaningless. Have you spent time in your career as a compressionist? Have you encoded hundred of hours in various codecs looking at the best tweaks to get the highest visual quality for the smallest file sizes?

The test files that I produced resulted in the h.264/crf23 with a bitrate of 970kbps while the h.264/crf28 result with a bitrate of 800kbps. The h.265 used less bitrate to achieve half the filesize. I have stacked the 2 videos and toggle between the two. There is no visible difference. I have done this experiment. It is up to you to do the same thing to see if you can replicate the results or not. That's science. But it is much easier to just post "no it doesn't" comments on the internet.

Re: Comparing H.265 (HEVC) and H265 video file size

#100

Post by bawolff »

dylan604 wrote: post #90
bawolff wrote: post #81

Earlier quoted context omitted.

If you mean raw, in the sense of a stream of RGB (or YUV) images one after each other, i would expect zip to give significant compression, especially for something with solid colours like a desktop screen. H.265 is obviously going to be a lot better, but compared to doing nothing, even something stupid like RLE compression is going to be helpful.

that's not how Zip works though Edit: You can disagree, but video files do not compress with zip. Feel free to do the experiments on your own time. Zip looks for combinations of letters/sequences. That's not how a video file structured. To make video smaller, smart people created a dedicated type of compressors.

Which part is not how zip works?

> That's not how a video file structured

You're under the impression that uncompresed raw video does not contain repeated bit patterns??? How do you think it is structured?

Post reply on HN