37 ms·
H.264 is Magic (2016)
- marcodiego 5y agoWhatever it is, AFAIK, most of its significant patents will expire this decade: https://www.osnews.com/story/24954/us-patent-expiration-for-mp3-mpeg-2-h264/ https://www.osnews.com/story/24954/us-patent-expiration-for-...
- the-dude 5y agoThe article starts off with talking about "raw" video containing 3 bytes for every pixel. However, most video is YUV, which is typically 1.5 bytes/pixel. https://en.wikipedia.org/wiki/YUV https://en.wikipedia.org/wiki/YUV
- _zywo 5y agoWell, if we're being pedantic here, raw RGB video as would be displayed on a RGB monitor does indeed take 3 bytes per pixel. Technically, YUV is either an optimization or a backwards compatibility measure, and hence the adjective "raw" does not apply to it.
- Closi 5y agoIf you define raw video as RGB with 1 byte for red, 1 byte for green and 1 byte for blue, then yes, it will be 3 bytes per pixel. But there are clearly other ways to store a pixel of colour information in less than 3 bytes, which is OP's point. It's not an optimization really - it's just a different coding format (Just as ASCII isn't an optimization of Unicode).
- sly010 5y agoActually the "raw" data coming from most cameras are often already compressed somehow, otherwise the camera would not be able to write it to storage (or send it over USB) fast enough. In fact since decoding also often happens in hardware, the raw size may never materialize anywhere in the pipeline, other than the framebuffer of the video card. Even HDMI has compression now [0] The author probably choose a screenshot as a benchmark, because otherwise it's hard to get your hands on anything compressible but not already compressed.
- iso1631 5y ago10 bit video 444 with 8294400 or 8847360 samples per picture for 4k (tv vs movie) tops out below 270mbit per frame, or at 60hz 16gbit, so you can fit half a dozen signals down a 100G transceiver, or two down a 40G. Throw in YUV compression and you can shift 120hz 8k with relatively little problem.
- jasongill 5y agoIf you actually read the rest of the article, the author covers this in the section about chroma subsampling.
- phire 5y agoYUV alone is still 3 bytes per pixel and can be converted back to rgb without any loss. But YUV is almost always combined with color subsampling, which gets you to 1.5 or 2 bytes per pixel.
- bumblebritches5 5y ago
- fomine3 5y agoYes, OP might want to say YUV422 or YUV420 that most videos are encoded.
- iso1210 5y agoMost video I deal with is YUV (YCbCr) 422 at 30 bits per 2 pixels
- throw0101a 5y agoSee also H.265: * https://en.wikipedia.org/wiki/High_Efficiency_Video_Coding https://en.wikipedia.org/wiki/High_Efficiency_Video_Coding And now even H.266: * https://en.wikipedia.org/wiki/Versatile_Video_Coding https://en.wikipedia.org/wiki/Versatile_Video_Coding Also, at what point will AV1 become "mainstream"? How prevalent is it? Still seems that hardware decoding (never mind encoding) support is still only so-so.
- afavour 5y agoYeah, in this era of mobile device dominance i think hardware decoding is key. Suspect Apple will add it then suddenly the Android SoC folks will suddenly consider it a priority and not before.
- vetinari 5y agoApple won't add it; they traditionally ignore free codecs, and even if they implement them, it is so limited, so it is usable only in the narrow situation, where it is required (see Opus, for example). On the PC side, decoding is supported by Intel (since Tiger Lake), Nvidia (since 30x0) and AMD (since RDNA2). On the mobile side, it is supported by bunch of mobile chip vendors, like Mediatek or Samsung; so you can have an android device that does support AV1 already; on OS-side it is supported since Android 10. Vendors like Amlogic also support it, so settopboxes are also covered.
- Maakuth 5y agoApple is even a governing member of the alliance behind AV1 (https://en.wikipedia.org/wiki/Alliance_for_Open_Media https://en.wikipedia.org/wiki/Alliance_for_Open_Media), so the case could be different than with previous free codecs.
- kmeisthax 5y agoApple didn't care about free codecs before H.265 for the same reason ISO and Leonardo Chiariglione didn't: "the best codecs require big $$$ to research and competitive royalty-free codecs will stifle innovation by not sending money back to researchers"[0]. The ISO business model was to not care about patents as long as everyone agreed to charge FRAND rates, so they could just pick the best technology and rely on their creators' patent royalties to fund research. For Apple, they don't care about the cost, as long as the codec is suitable to implement in iPhones. That business model broke once Velos Media and Access Advance realized they could game the system by offering a handful of net-implementer companies severely reduced patent rates if they agreed to license their patents or, better yet, pull out of MPEG-LA entirely. The end result is that companies have to license significant portions of H.265 multiple times from three different patent pools... and most people who are even remotely cost-sensitive just aren't bothering with it at all and are sticking with H.264 or moving to AV1. Apple has yet to implement AV1 in hardware, which makes using the codec exclusively a non-starter as they have a very dim opinion of software decoders. I imagine they joined AOM to either hedge some bets or extract leverage from H.265/H.266 patent owners. The thing is that their business absolutely does not require the existence of a viable royalty-free codec, unlike Google's, which does. We'll know if Apple's actually decided to join the Free video party if they actually ship an AV1 decoder in their silicon. [0] Leonardo is very vocally opposed to AOM's lack-of-a-business-model, see: https://blog.chiariglione.org/a-crisis-the-causes-and-a-solution/ https://blog.chiariglione.org/a-crisis-the-causes-and-a-solu... https://blog.chiariglione.org/a-future-without-mpeg/ https://blog.chiariglione.org/a-future-without-mpeg/ https://blog.chiariglione.org/revisiting-the-patents-in-standards-issue/ https://blog.chiariglione.org/revisiting-the-patents-in-stan... If you're wondering, he's the former chair of MPEG, before ISO decided to cut up MPEG into a bunch of different pieces and more or less left him without a job. He's salty about that too: https://blog.chiariglione.org/iso/ https://blog.chiariglione.org/iso/
- graderjs 5y agoScoooped: https://news.ycombinator.com/item?id=30686148 https://news.ycombinator.com/item?id=30686148 ;) ;p xx ;p
- amelius 5y agoTiming is everything.
- airstrike 5y agoGotta post on Monday at 8:30am PT
- userbinator 5y agoIt's appeared on HN several years ago: https://news.ycombinator.com/item?id=12871403 https://news.ycombinator.com/item?id=12871403
- ksec 5y agoMissing 2016 in the title.
- tmp65535 5y agoFabrice Bellard's BPG image format uses H.265's keyframe compressor: https://bellard.org/bpg/ https://bellard.org/bpg/ Here is a side-by-side visual comparison: http://xooyoozoo.github.io/yolo-octo-bugfixes/#ballet-exercise&jpg=s&bpg=s http://xooyoozoo.github.io/yolo-octo-bugfixes/#ballet-exerci... Amazing. I ported his BPG decoder to Android ARM for a pornographic app. See my comment history for details. It reduced data transfer by more than 60%.
- aikinai 5y agoIsn’t that exactly what HEIC is?
- innocenat 5y agoIt looks like BGP actually predates HEIC. HEIC technical document finalise in 2015. The GitHub mirror of BGP has history back to 2014.
- thrdbndndn 5y agoI'm not saying which one is earlier as I have no idea, but comparing these two dates doesn't seem to be a good way. Implementation of HEIC existed before its documentation finalized.
- localhost 5y agoIt seems that way - I read this [1] which does a high level comparison of the technologies. It does seem like BPG is patent encumbered by the underlying H265 algorithms (aka HEVC) [2] [1] https://www.zyxtech.org/2019/06/13/what-is-heic-heif-plus-a-brief-timeline-of-image-formats-featuring-jpeg-gif-png-webp-bpg/ https://www.zyxtech.org/2019/06/13/what-is-heic-heif-plus-a-... [2] https://en.wikipedia.org/wiki/High_Efficiency_Video_Coding https://en.wikipedia.org/wiki/High_Efficiency_Video_Coding
- pornel 5y agoHEIC is this plus a kitchen sink of features for digital camera rolls, which aren't useful on the web, all wrapped in a ton of legacy ISO BMFF complexity reaching as far as Classic Mac Quicktime. BPG structure is much more minimal and pragmatic. However, BPG is unnecessary nowadays. Modern browsers support AVIF, which is HEIF+AV1, so basically HEIC with the painfully patented bit swapped for a freely licensed one.
- isaak 5y agoAlmost all of those encoding concepts mentioned are not introduced with H.264, but much earlier with MPEG-2 in the early 90's https://en.wikipedia.org/wiki/MPEG-2 https://en.wikipedia.org/wiki/MPEG-2
- layer8 5y agoYes, I was expecting "a technical walkthrough" of how H.264 managed to improve on its predecessors. There’s nothing specific to H.264 in the article.
- bob1029 5y agoMPEG-2 and JPEG are very similar in philosophy as well. JPEG in particular is still my favorite image encoding technique. Mostly because of how fast it is relative to the competition.
- deleted 5y ago[deleted]
- jicea 5y agoEven earlier with H.261 and MPEG1 which already used block coding motion no ?
- userbinator 5y agoH.264 patents are not expiring yet, if anyone was wondering. 2027 seems to be when that happens. On the other hand, I believe H.263 patents already expired, and MPEG-4 ASP (DivX etc.) is expiring this year.
- ksec 5y agoI often wonder what we could do with a truly patent free codec once all the H.264 patent expired.
- dspillett 5y agoProbably ask what we could do with H.269 (or whatever the common tech of the time is) when that is no longer encumbered by patents!
- ksec 5y agoBut being not encumbered by patents and patents free is two different thing. We have lots of tools that didn't make it into H.264 standard due to complexity are also expiring.
- joshspankit 5y agoYou don’t have to wonder: There have been many truly patent free codecs and the answer is mostly “Try to convince companies to adopt it even though they have a vested interest in using codecs they control” For example: FLAC
- PaulDavisThe1st 5y agoFLAC is actually much more widely supported than, for example, Vorbis.
- joshspankit 5y agoFLAC was released in 2001 and widely popular by at least 2006. With much fanfare, iOS11 (2017) was the first time iOS supported playing FLAC files and that was (and still is) not the Apple-branded “Music” app but only in the “Files” app.
- jstanley 5y agoDoes anything interesting happen if you take the frequency domain representation of an image, represent the frequency domain as an image itself, and compress that with some sort of image compression? For example, encode the frequency domain representation as a low quality JPEG, and then undo the steps to turn it back into the "original". How do the JPEG artifacts on the frequency domain manifest in the resulting image?
- yngvizzle 5y agothe frequency domain of the frequency domain is just a flipped version of the original image, so that would not work. the idea of frequency-domain based compression is that natural images have little high-frequency information.
- thrdbndndn 5y agoWith only a slight compression, the image would go shit or totally unrecognizable. A quick album (there are captions): https://imgur.com/a/7yHPzRH https://imgur.com/a/7yHPzRH
- jstanley 5y agoThanks, this is exactly what I wanted to see.
- verall 5y ago> 4:2:0 chroma subsample the fft This is hilarious but I don't think it makes any sense.
- thrdbndndn 5y agoyeah, just wanted to try a 'typical' one. I also tried 70% 444, still unrecognizable.
- randyrand 5y agoimpressive how quickly you coded that up.
- airstrike 5y ago> "a technical walkthrough" > "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! Easy. I saved you hours of mindfuck lectures." Ahh, my favorite kind of technical walkthrough. Love it
- latexr 5y ago> You wouldn't say HHHHHHHHH. You wouldn’t and shouldn’t. There are only nine “H” in there!
- kibwen 5y agoAh, but perhaps in this encoding scheme the first H is implicit, and a leading T is encoded as _T. Half the time this results in an infinity increase in bytes saved!
- zuminator 5y agoOne could read that as having an implicit ellipsis, ie. "HHHHHHHHH..." After all, you would and should say HHHHHHHHH on the way to saying HHHHHHHHHH.
- gandalfian 5y agoAh ASCII art. Long rows of identical characters. The only thing that actually allowed a dial up modems compression claims to actually live up to the marketing hype....
- MisterTea 5y ago> The only thing that actually allowed a dial up modems compression claims to actually live up to the marketing hype.... Don't for get the HTML and other plain text that is sent/received.
- delusional 5y agoDoesn't that description basically presuppose that you already understand compression? "HHHHHHHHHH" is 10 characters, but "10 tosses, all heads" is 21. Already understanding compression, I of course know that the second part could be efficient if encoded properly, but someone actually needing the explanation probably wouldn't know that. It's not really wrong, and not really an "oversimplification" as the parent article calls it. It's just a bad example, and it seems confused about the audience it's trying to reach. Either they already understand compression, and it's superfluous, or they don't and it's just confusing.
- alevskaya 5y agoFor those interested in this topic, I highly recommend the approachable but more extensive technical introduction at https://github.com/leandromoreira/digital_video_introduction https://github.com/leandromoreira/digital_video_introduction
- exted 5y agoVery intuitive explanations. Love it!
- yboris 5y agoPSA: For images, there's a finally successor to jpeg: JPEG XL (.jxl) - has lossy and lossless mode; is progressive (you can download just the first parts of the bitstream to get a lower resolution image; and other benefits!) https://jpegxl.info/ https://jpegxl.info/
- Cthulhu_ 5y ago"Your browser does not support JPEG XL"; I'm sure it's cool technology but whoever is behind it needs to hire developers and advocates to push code to Webkit / Blink to add support for it, else it won't get mainstream adoption.
- FrenchAmerican 5y agoI have read that both Chrome and Firefox now support it if one enable the proper option in the about:config page (and its Chrome equivalent, but I avoid Chrome by principle). It's in my to do-list in the coming weeks, I have not verified this yet.
- Aachen 5y agofor those that want to try: set image.jxl.enabled and restart the browser (via https://jpegxl.io/tutorials/firefox/#firefoxjpegxltutorial https://jpegxl.io/tutorials/firefox/#firefoxjpegxltutorial)
- mekster 5y agoSo, once again Safari isn't on the list which hinders adoption. I really wish it stop behaving like IE by being on its own.
- jug 5y agoIt’s available behind a flag, perhaps awaiting v1.0 in the reference implementation or something. I really hope it takes off. There was a bit poor timing because widespread AVIF support happened _right_ before and now we need to beg browser vendors to adopt JPEG XL! I hope they don't balk at it for starting introduce too much file format cruft because JPEG XL is really, really something they should implement. It can succeed JPEG as well as PNG (lossless JPEG XL tend to destroy even optimized PNG). I'd much rather abandon AVIF support. It's just one of those annoying single-video-frame-as-a-picture hacks like WebP and HEIF without drive to make them outstanding image formats on their own for photography as well as line art.
- credulousperson 5y agoFor those interested, Ronald Bultje (who co-devloped VP9) wrote some information here on VP9 which has some more concrete details about video coding than this article: https://blogs.gnome.org/rbultje/2016/12/13/overview-of-the-vp9-video-codec/ https://blogs.gnome.org/rbultje/2016/12/13/overview-of-the-v... It's not H.264 but the coding techniques will be similar.
- jancsika 5y ago> 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! Easy. I saved you hours of mindfuck lectures. This is obviously an oversimplification, but you've transformed some data into another shorter representation of the same information. Future generations will disagree it's the "same information." I predict there will be a small but vocal cabal who seize on your example with nine H's to argue that it's not the case. On a more serious note, if you lose the decoder ring does it cease to be a "representation of the same information?"
- donkarma 5y agoIt's curious because where do you draw the line between an algorithm that compresses information and an algorithm that just stores the inforamtion in the algorithm.
- acchow 5y agoRight, you of course also need the decoder in order to reconstruct the data. In this case, the "decoder" is the english language.
- coin 5y agoPretty much all the techniques there are used in MPEG-2. I would have like to hear about the H.264 improvements.
- memco 5y agoOne thing I was curious about is how the PNG would compare after running it through an optimizer since that would be a more fair comparison since the H.264 encoding does optimize. Even so, I bet the H.264 would fare well. I did an experiment with using single-frame H.264 instead of images on a site: I think it’s a viable technique but didn’t have time to flesh it out in full. If you have some kind of asset pipeline for a site it’s not really more work to encode and the HTML is now a video tag with no player controls so isn’t a ton of work client side either. Would love to explore that more at some point.
- zekica 5y agoIt would be better for you to serve .webp and .avif (or optionally .heif for apple devices) inside a <picture> tag with .jpg or .png as fallback, as these formats are designed for static images, but are based on I-frame compressors for vp9, av1 and hevc respectively.
- ollybee 5y agoThere was once a blog titled "Diary Of An x264 Developer" that gave some interesting detail of how h264 worked and the and the x264 implementation. It's still available on via the internet archive.
- mgdlbp 5y ago(https://web.archive.org/web/2012/http://x264dev.multimedia.cx/ https://web.archive.org/web/2012/http://x264dev.multimedia.c...) Tied as the leading implementation by 2006, pulled far ahead in SSIM in 2010, and all FOSS. Hat off to Glaser and Merritt! An interesting Baader–Meinhof for me when I first heard: Glaser (as Dark Shikari) used to be active on HN and wrote the quote (oft misattributed to Descartes), Any community that gets its laughs by pretending to be idiots will eventually be flooded by actual idiots who mistakenly believe that they're in good company. regarding 4chan in 2009. (https://news.ycombinator.com/item?id=1012082 https://news.ycombinator.com/item?id=1012082) If you frequently read older threads, get ready to start noticing the username!
- dang 5y agoRelated: H.264 is magic (2016) - https://news.ycombinator.com/item?id=19997813 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 https://news.ycombinator.com/item?id=17101627 - May 2018 (1 comment) H.264 is Magic - https://news.ycombinator.com/item?id=12871403 https://news.ycombinator.com/item?id=12871403 - Nov 2016 (219 comments)
- rayiner 5y agoThis is an awesome introduction to video coding, though it’s thin on motion compensation: https://users.cs.cf.ac.uk/Dave.Marshall/Multimedia/node259.html https://users.cs.cf.ac.uk/Dave.Marshall/Multimedia/node259.h... An elucidating exercise is to use python to do a DCOS or wavelet transform on an image and then quantize it to look at the results. It’s a few hundred lines of code if that and gives you a solid idea of the significance of working in the frequency domain and how that makes compression much easier.
- atum47 5y agoBack in college when I was taking Digital Image Processing class we discussed h.264. Truly impressive technology no doubt. This article goes in much more detail about it, job well done.
- vbphprubyjsgo 5y ago
- marcoriol 5y agoNice article!
- la64710 5y agoBeautiful beautiful beautiful !!
- lekevicius 5y agoSomeone do this for AV1 / AVIF, and particularly how it compares to H.264 and HEVC / HEIF. I'd love a deep dive.
- tzs 5y agoTwo questions for the compression gurus here. Suppose you have a bunch of raw video. You take extracts of it and put them together to make a movie, M1. You make an H.264 encoded copy of that. Let's call it C1. You then make a new cut of your movie, M2, which is mostly the same footage as M1 except that you've shortened a few scenes and lengthened others. You make an H.264 encoded copy of that. Call this C1. When making C1 and C2 your H.264 encoders have to decide which frames to turn into I-frames and which to turn into P-frames. If they just do something simple like make every Nth frame an I-frame then after the first different between M1 and M2 it is unlikely that C1 and C2 will have many I-frames in common, and therefore also not have many P-frames in common. If they look for scene changes and make new I-frames on scene changes, then we might expect that at least for the scenes that start identically in M1 and M2 they will get identical I-frames and P-frames up to their first edit if any. Scenes that are edited in the front would still end up encoded totally different in C1 and C2. Question: are there any encoders that when encoding M2 to produce C2 can be given M1 and C1 as references using them to adjust I-frame spacing so as make as many C2 I-frames as possible match C1 I-frames? That would allow C2 to be stored efficiently as a binary diff from C1. This could be handy if C1 and C2 needed to be checked into a version control system, or you needed to distribute C2 over a low bandwidth or expensive link to someone who already had C1. The second question concerns recompressing after decompression. I actually thought of this question in terms of audio so will ask in those terms, but I guess it applies to video too. Suppose someone has an uncompressed source S. They compress it with a lossy compressor producing C and distribute C to you. You decompress C producing S'. You then compress S' with a lossy compressor (the same type that the original producer used--e.g.., if C is an MP3 you use an MP3 compressor) producing C'. I don't know about video, but for audio (at least back in days when MP3 was starting to get big) C' would be lower quality than C. Are there any compressors that can figure out that they are dealing with something that already has undergone the "throw out imperceptible parts to make it more compressible" step done and just skip to the next stage, so they produce a C' that is a lossless representation of S'?
- walrus01 5y ago> You make an H.264 encoded copy of that. Let's call it C1. > You then make a new cut of your movie, M2, which is mostly the same footage as M1 except that you've shortened a few scenes and lengthened others. Your new cut gets encoded from whatever you've chosen from frame-index numbers and timestamps in the various original raw yuv project files (or ProRes, etc, depending on what your camreas output). The existence of the original cut should be irrelevent because what you're not doing is taking the compressed output product of C1 and re-cutting it into C2 unless for some catastrophic reason you have lost or deleted all of the original raw/uncompressed original camera files. If you are generating new C2 from your original uncompressed (or lightly compressed) files, of course the encoder will be making new decisions on where to insert I-frames and P-frames based on the duration of each camera cut, changes you've made to CGI, other visual factors in the re-cutting. > Suppose someone has an uncompressed source S. They compress it with a lossy compressor producing C and distribute C to you. You decompress C producing S'. > You then compress S' with a lossy compressor (the same type that the original producer used--e.g.., if C is an MP3 you use an MP3 compressor) producing C'. I don't know about video, but for audio (at least back in days when MP3 was starting to get big) C' would be lower quality than C. all of this is generally a bad idea unless you have no other option but to work with received files that are already compressed. say for example you're working on a documentary about something in a conflict zone and somebody sends you a highly compressed h264 file recorded on a smartphone. in this case there is no uncompressed original available. you're going to want to first extract it into an uncompressed yuv raw file on disk so that you can work with it in your standard editor, and then whatever scenes you choose from within it will get re-encoded into your final output.
- dukeofdoom 5y agoJust got a drone air 2s and it recorded in h.265. I tried to play it on 2013 MacBook retina and it plays a frame every minute or so. I can play 4k h.264 no problem. Am I missing something why its not playing
- vagab0nd 5y agoI worked on a project where I extracted the motion vectors from the h264 encoded stream from the camera, to detect motion. It's like a basic motion detector for free.
- knolan 5y agoCan you provide a reference where one could get started with this?
- vagab0nd 5y agoIt's been a long time. But I remember I started with this page [0]. There are also many resources on github, like [1] or [2], but I haven't tried them. 0: https://trac.ffmpeg.org/wiki/Debug/MacroblocksAndMotionVectors https://trac.ffmpeg.org/wiki/Debug/MacroblocksAndMotionVecto... 1: https://github.com/LukasBommes/mv-extractor https://github.com/LukasBommes/mv-extractor 2: https://github.com/jishnujayakumar/MV-Tractus https://github.com/jishnujayakumar/MV-Tractus
- knolan 5y agoThank you!
- las_balas_tres 5y agoThere is a github project called pikrellcam that utilizes motion vectors generated from the raspberry pi's gpu to detect motion. It's a relatively simple piece of code and it works very well
- AtNightWeCode 5y agoI stopped reading when the author started to do comparisons with PNG. PNG or alternatives should only be used when the errors created by lossy compression is too visible. With that said. Improvements of audio and video compression over the last 25 years are very impressive and have changed how the world works in several areas.
- ricardobeat 5y agoPNG is a good baseline for image sizes before adding any kind of smart compression. Nothing wrong with that, and the comparison would not look much different against JPG (except it would probably look actually worse than the video).
- AtNightWeCode 5y agoThere is no reason to use PNG today except for cases were image size does not matter.
- ricardobeat 5y agoFor the web, you might use it when you want alpha channels. WebP is still not supported everywhere. Regardless, it’s useful as a comparison in the article to show just how good h264 is versus other compression techniques. They are not recommending PNG or anything. WebP would only produce a 20-50% smaller file, not 1000x smaller, so it doesn’t really matter which image format they compare to.
- Melatonic 5y agoI met one of the creators of H264 years ago while photographing a party in Palo Alto. He and his wife were really genuinely nice and interesting people. At the time H265 was not released but it sounded like they were actively working on it and even something past it
- throwawaybbq1 5y agoIs there as a (good) college-level text book on the topic of image and video encoders? I never took a digital image processing course .. curious if someone has a favorite book on this topic.
- thefrozenone 5y agoLectures from a course I took (CS 674 at UNR) can be found online here, along with class exercises and names of textbooks: https://www.cse.unr.edu/~bebis/CS474/ https://www.cse.unr.edu/~bebis/CS474/ Would highly recommend it! We went over pretty much everything in this article, plus more :)