[HN Gopher] H.264 Is Magic (2016)
___________________________________________________________________
H.264 Is Magic (2016)
Author : tosh
Score : 105 points
Date : 2024-06-14 14:35 UTC (8 hours ago)
(HTM) web link (sidbala.com)
(TXT) w3m dump (sidbala.com)
| dang wrote:
| Related:
|
| _H.264 is Magic (2016)_ -
| https://news.ycombinator.com/item?id=30710574 - March 2022 (219
| comments)
|
| _H.264 is magic (2016)_ -
| https://news.ycombinator.com/item?id=19997813 - May 2019 (180
| comments)
|
| _H.264 is Magic - a technical walkthrough_ -
| https://news.ycombinator.com/item?id=17101627 - May 2018 (1
| comment)
|
| _H.264 is Magic_ - https://news.ycombinator.com/item?id=12871403
| - Nov 2016 (219 comments)
| jpm_sd wrote:
| Well OK, but what about H.265? It's one louder, isn't it?
|
| https://en.wikipedia.org/wiki/High_Efficiency_Video_Coding
| cornstalks wrote:
| I've always felt like H.264 hit a great sweet spot of
| complexity vs compression. Newer codecs compress better, but
| they're increasingly complex in a nonlinear way.
| TimeBearingDown wrote:
| It also benefits from the extremely optimized encoder x264,
| which has many easily approachable tunings and
| speed/compression presets.
|
| I'm not sure I'd trust x265 to preserve film grain better
| than x264 --tune film unless I gave x265 much, much more time
| as well as pretty similar bitrate.
| LeoPanthera wrote:
| x265 has a specific "--tune grain" mode _specifically_ for
| video with a lot of film grain.
| ronsor wrote:
| H.264 will probably never die, especially once all the
| patents expire in a few years.
| palata wrote:
| When do they expire?
| edflsafoiewq wrote:
| According to https://meta.wikimedia.org/wiki/Have_the_pat
| ents_for_H.264_M..., probably September 2027.
|
| There are an additional two patents on that list that
| expire in 2028 and 2030, but it's not clear if they
| apply. So probably November 2030 at the latest.
| toast0 wrote:
| H.262 has a long future too. New DVDs and OTA broadcasts
| (at least for ATSC 1.0) will probably end at some point,
| but the discs won't go away for a long time, even if disc
| players are less and less popular.
| SirMaster wrote:
| But with hardware acceleration for both encoding and decoding
| of HEVC it feels like less of a problem IMO.
| ugjka wrote:
| Video piracy is pretty much all in HEVC
| Kirby64 wrote:
| Not really. Only 4k content and anime seems to use
| HEVC/h265. Anything lower resolution has stuck to h264
| for the time being.
| contingencies wrote:
| FWIW IIRC yts.mx began offering H.265 on standard
| resolution films about a year or two back.
| Kirby64 wrote:
| Yeah, and most people consider stuff off yts to be of
| poor quality. Encodes are bad and do not meet standards.
| JamesSwift wrote:
| Uhh, not in my experience. Its extremely difficult to
| find h265 sources for a large majority of content. Its
| basically a meme where if you tell people you want to try
| and get h265 by default, they talk down to you like "why
| would you do that".
|
| From https://trash-guides.info/Misc/x265-4k/
|
| > Something like 95% of video files are x264 and have
| much better direct play support.
| babypuncher wrote:
| That info seems a little out of date. The utility of
| h.265 at resolutions below 1080p can be questionable, but
| everything these days is 1080p or 4k.
|
| Hardware support has also been ubiquitous for a while
| now. iPhones have had it since 2016. I usually "move on"
| to the next codec for my encodes once I run out of
| hardware that doesn't support it, and that happened for
| me with h.265 in 2019. My iPad, laptop, and Shield TV are
| still holding me back from bothering with AV1. Though
| with how slow it is, I might stick with h.265 anyways.
| JamesSwift wrote:
| The guide isnt saying 95% of source content is h264. Its
| saying 95% of files you would download when pirating are
| h264. The scene, by and large, is transcoding h265 4k to
| h264 720/1080. The 4k h265 is available but its
| considered the 'premium' option.
| Melatonic wrote:
| I think the big switch will happen once most people have
| TV's that can do 10bit color and true HDR. H264 can
| definitely do 10 bit but I'm not sure how well it handles
| higher dynamic range content (or if it even can) but H265
| definitely can.
| babypuncher wrote:
| I feel like the switch from AVC (h.264) to HEVC (h.265)
| has already happened. It's used in 4k blu rays, most
| premium streaming services, and hardware support has been
| ubiquitous for at least 6 years.
| Dylan16807 wrote:
| Doesn't every state of the art codec do that, including H.264
| versus previous?
|
| Also I haven't seen charts of decode difficulty, but as far
| as encoding goes, codecs a generation more advanced can crush
| H.264 at any particular level of effort. The even newer
| codecs can probably get there too with more encoder work.
| https://engineering.fb.com/wp-
| content/uploads/2023/02/AV1-Co...
| cornstalks wrote:
| Generally yes, but I wasn't only talking about compute
| costs. Mentally grokking H.264's features and inner
| workings is a lot easier than newer, better codecs.
| SirMaster wrote:
| What about VVC (H.266)?
|
| https://en.wikipedia.org/wiki/Versatile_Video_Coding
| adzm wrote:
| VVC has a lot of the same issues that plagued HEVC adoption.
| There really isn't much reason to not use AV1 if you want the
| best codec currently.
| jl6 wrote:
| VVC is a generational improvement in compression ratio over
| AV1, which might make it the best for a lot of
| applications. Too bad it will probably languish in patent
| licensing hell.
| lokidokiiki wrote:
| Well, it's two louder, obviously.
| Melatonic wrote:
| Have you experimented with it much? First I am hearing of it
| asveikau wrote:
| Maybe I need to change some options, but I find whatever
| encoder I get when I ask ffmpeg to encode h265 takes a very
| long time. Then decoding 4k h265 is very slow on most of my
| PCs.
|
| It sure gets the file size down though.
| adzm wrote:
| I really like HEVC/h265. It's pretty much on par with VP9. but
| licensing trouble has made it difficult to get adopted
| everywhere even now. VVC/h266 seems to be having the same
| issues; AV1 is pretty much just as good and already seeing much
| more adoption.
| radicality wrote:
| What's the tldr of the licensing problems?
|
| I've started reading this article which list the various
| H.26x proposals -
| https://en.m.wikipedia.org/wiki/Video_Coding_Experts_Group
|
| Seems like the group that comes with these is eventually part
| of the UN ? https://en.m.wikipedia.org/wiki/International_Tel
| ecommunicat...
|
| Is it because they come with the codecs "jointly" with the
| MPEG organization, which is for profit? If the group is part
| of a standards organization that's part of the UN, I feel
| like they should come up with non-patent-encumbered
| "recommendations".
| peutetre wrote:
| > _What's the tldr of the licensing problems?_
|
| There are multiple patent pools for H.265 wanting to be
| paid licensing fees (MPEG LA, HEVC Advance, Velos Media).
| HEVC Advance and Velos Media even want content distribution
| licensing fees.
|
| And there are patent holders not in any pool who also want
| to be paid (Technicolor, Motorola, Nokia, etc.).
|
| It's a mess.
| TacticalCoder wrote:
| > Well OK, but what about H.265? It's one louder, isn't it?
|
| I had some old, gigantic, video footage (in a variety of old,
| inefficient, formats at a super high quality).
|
| So I did some testing and, well, ended up re-
| encoding/transcoding everything to H.265. It makes for _much_
| smaller files than H.264. The standard is also ten years
| younger than H.264 (2013 for H.265 vs 2003 for H.264).
| Melatonic wrote:
| Years ago I was photographing a party in silicon valley (had
| just graduated college and was taking any job I could get). I
| take a nice photo of a couple and the wife looks at me and
| says " You know my husband invented H264? Do you know what
| that is?".
|
| Ended up having a long conversation with the husband (the
| engineer) and he hinted many times that they were working
| currently on something even better. Years later now of course
| we have H265. Everytime I play something in H264 or H265 I
| think of that moment and how much work that guy and his
| colleagues must have put into coding such a widely used codec
| (and how proud his wife was!)
| drmpeg wrote:
| She should say "helped to invent". Video codec standard
| development is most definitely a group effort.
| rebeccaskinner wrote:
| I do a lot of video compression for hobby projects, and I stick
| with h264 for the most part because h265 encoding requires far
| too much extra compute relative to the space savings. I can
| spend an hour compressing a file down to 1gb with h264, or I
| can spend 12 hours compressing the same file to 850mb with
| h265. Depending on the use-case, I might still need the h264
| version anyway since it's far more widely supported by clients.
| If I had a data center worth of compute to throw at encoding,
| or I were running a streaming service where the extra 150mb per
| video started to add up, then I'd definitely on-board with h265
| but it's really hard to justify for a lot of practical use-
| cases.
| radicality wrote:
| What about when you're recording (say your iPhone / android /
| standalone camera) - are you choosing h264 or h265 (or
| something else like an intra-frame only codec for easier
| editing).
| tbalsam wrote:
| This is very cool but the use of the terms "Information Entropy"
| together as if they were a separate thing is maybe the furthest
| that any "ATM-machine"-type phrase has rustled my jimmies.
|
| It is a cool article, just, wowzers, what a phrase.
| cobbzilla wrote:
| are signal and noise the same thing?
| tbalsam wrote:
| _grabs water spritzer_
|
| Stop that, now. Bad cat.
| lazide wrote:
| Yes, also no.
| ClassyJacket wrote:
| I mean, it's obviously not relevant here, but technically there
| is also heat entropy, isn't there? It's not always information.
| hughesjj wrote:
| To be fair I think information entropy is more self descriptive
| than Shannon entropy
| tasty_freeze wrote:
| Story time.
|
| Back in 1999, I was leaving a startup that had been acquired, but
| I didn't want to stick around. I had been doing in mpeg encoding;
| this is relevant later.
|
| One of the companies I interviewed with had come up with a new
| video compression scheme. They were very tight lipped but after
| signing NDA paperwork, they showed me some short clips they had
| encoded/decoded via a non-realtime software codec. I was
| interviewing to create an ASIC version of the algorithm. Even
| seeing just a minute or two of their codec output, I guessed what
| they were doing. I suggested that their examples were playing to
| the strengths of their algorithm and suggested some scenarios
| that would be more challenging. I also described what I thought
| they were doing. They neither confirmed nor denied, but they had
| me come back for a second round.
|
| In the second round I talked with the founders, a husband/wife
| CEO/CTO (IIRC) team. That is when I learned their plan wasn't to
| sell ASICs, but they wanted to keep their codec secret and
| instead create DSL-based cable network using the ASICs for video
| distribution. I said something like, it sounds like you have
| invented a better carburetor and instead of selling carburetors
| you are planning on building a car factory to compete with GM. It
| was cheeky, and they didn't take it well.
|
| Getting to the point of how this story relates to H.264, their
| claim was: conventional compression has reached the limit, and so
| their codec would allow them to do something nobody else can do:
| send high-def video over DSL lines. I replied: I think
| compressors will continue to get better, and even if not, higher
| speed internet service will eventually come to houses and remove
| the particular threshhold they think only they can cross. Oh, no,
| they replied, physics dictates the speed bits can be sent on a
| wire and we are at that limit.
|
| I didn't get (and didn't want) a job offer. The company did get
| some VC money but folded a few years later, much more efficient
| codecs were developed by others, and 2 Mbps internet connections
| were not a limit. I'm sure the actual algorithm (which I describe
| later at a high level) had a lot of clever math and algorithmic
| muscle to make it work -- they weren't stupid technically, just
| stupid from a business sense.
|
| This retelling makes me sound like a smug know-it-all, but it is
| one of two times in my life where I looked at something and in
| seconds figured out their secret sauce. There are far more
| examples where I am an idiot.
|
| What was their algorithm? They never confirmed it, but based on
| silhouette artifacts, it seemed pretty clear what they were
| doing. MPEG (like jpeg) works by compressing images in small
| blocks (8x8, 16x16, and a few others). That limits how much
| spatial redundancy can be used to compress the image, but it also
| limits the computational costs of finding that redundancy. Their
| codec was similar to what Microsoft had proposed for their
| Talisman graphics architecture in the late 90s.
|
| From what I could tell, they would analyze a sequence of frames
| and rather than segmenting the image into fixed blocks like mpeg,
| they would find regions with semi-arbitrary boundaries that were
| structurally coherent -- eg, if the scene was a tennis match,
| they could tell that the background was pretty "rigid" -- if a
| pixel appeared to move (the camera panned) then the nearby pixels
| were highly likely to make the same spatial transformation.
| Although each player changed frame to frame, that blob had some
| kind of correlation in lighting and position. Once identified,
| they would isolate a given region and compress that image using
| whatever (probably similar to jpeg). In subsequent frames they'd
| analyze the affine (or perhaps more general) transformation from
| a region from one frame to the next, then encode that
| transformation via a few parameters. That would be the basis of
| the next frame prediction, and if done well, not many bits need
| to be sent to fix up the misprediction errors.
| zabeltech wrote:
| Thx for telling
| tasty_freeze wrote:
| I couldn't remember the name of the company, nor the founders,
| but google found it for me:
|
| https://www.zdnet.com/article/high-hopes-for-video-compressi...
|
| It says they raised $32M from VCs, came out of stealth mode in
| 2002. I was unable to find what happened after that.
| tosh wrote:
| Sounds like they are doing drugs now
|
| https://www.verseon.com
| function_seven wrote:
| I'm always amused when I read an article from years ago that
| uses perfectly-fine-but-quaint terminology:
|
| > _...that hope to deliver broadcast quality programming over
| the Internet--the holy grail for nascent video-on-demand
| (VOD) services_
|
| What year did we all suddenly stop using the term "video-on-
| demand" and start saying "streaming"? I don't remember it
| happening, but obviously it did.
|
| Well at least "broadcast quality" still means the same thing.
| An ancient antenna on my roof can still kick Youtube's ass
| when it comes to clarity and resolution.
| duskwuff wrote:
| > What year did we all suddenly stop using the term "video-
| on-demand" and start saying "streaming"?
|
| "VOD" is still used pretty frequently in some contexts to
| distinguish between live and prerecorded video. It's common
| parlance on Twitch, for example.
|
| > An ancient antenna on my roof can still kick Youtube's
| ass when it comes to clarity and resolution.
|
| How so? ATSC is MPEG-2 at an absolute maximum of ~18 Mbps -
| and most broadcasters cut it down much lower than that to
| add subchannels. It doesn't support 1080p60 video at all,
| only 1080p30 or 720p60. Youtube routinely uses higher
| resolutions and bitrates, as well as newer codecs (H.264 at
| the oldest).
| polpo wrote:
| The grandparent poster may be talking about ATSC 3.0
| which has been rolling out for a while. H.265 at a
| reported 28-36Mbps is nothing to sneeze at!
| ElFitz wrote:
| These stories are a big part of what I love in HN. Thank you.
| samlinnfer wrote:
| To nitpick, comparing with PNG is misleading, because it's
| comparing a lossless format with lossy. a JPEG would be around
| the same size has H.264.
| bigstrat2003 wrote:
| Yeah that jumped out at me as well. It's a really unfair
| comparison.
| g4zj wrote:
| > Suppose you have some strange coin - you've tossed it 10 times,
| and every time it lands on heads. How would you describe this
| information to someone? You wouldn't say HHHHHHHHH. You would
| just say "10 tosses, all heads" - bam! You've just compressed
| some data!
|
| There appears to be some lossy compression on that string of
| "H"s.
| lupusreal wrote:
| Try _saying_ each of those though.
| Agingcoder wrote:
| I remember when h264 appeared.
|
| At that time, I was obsessed with mplayer and would download and
| build the latest releases on a regular basis. The first time I
| got an h264 file, mplayer wouldn't read it so I had to get the
| dev version and build it.
|
| It worked, and I realized two things : the quality was
| incredible, and my athlon 1800+ couldn't cope with it. Subsequent
| mplayer versions ( or libavcodec ?) vastly improved performance,
| but I still remember that day.
| peutetre wrote:
| AV1 is more magic with better licensing.
|
| For their use case Meta is gradually getting to a baseline of VP9
| and AV1 streams for their video streaming:
| https://www.streamingmedia.com/Producer/Articles/Editorial/F...
|
| And AV1 for video calls:
| https://engineering.fb.com/2024/03/20/video-engineering/mobi...
|
| Microsoft is starting to use AV1 in Teams. AV1 has video coding
| tools that are particularly useful for screen sharing:
| https://techcommunity.microsoft.com/t5/microsoft-teams-blog/...
|
| H.264 will still be around for quite some time, but AV1 looks set
| to become the new baseline for internet video.
___________________________________________________________________
(page generated 2024-06-14 23:01 UTC)