H.264 का जादू (2016)
(sidbala.com)- इंटरनेट वीडियो, Blu-ray, मोबाइल फोन, security cameras और drones में इस्तेमाल होने वाला H.264 एक video compression standard है, जो full-motion वीडियो को व्यावहारिक bandwidth में भेजने के लिए विकसित हुआ
- 1080p 60Hz uncompressed वीडियो
1920×1080×60×3के आधार पर लगभग 370MB/s तक पहुंचता है, इसलिए 50GB Blu-ray disc में भी मुश्किल से करीब 2 मिनट ही समा पाते हैं - compression का मूल lossy compression है: आंखों को कम दिखने वाली details घटाना और frequency-domain transform, quantization, chroma subsampling से data की मात्रा कम करना
- temporal compression frames को I-frame, P-frame, B-frame में बांटता है, और 16×16 pixel macroblocks के motion vectors से पूरे frame की जगह बदलावों को reconstruct करता है
- उदाहरण में 5 सेकंड 60fps, 300-frame H.264 वीडियो 175KB था, जबकि एक अकेला PNG screenshot 1015KB था; original 1.2GB वीडियो घटकर 175KB रह गया
H.264 जिस data को घटाने की कोशिश करता है
- H.264 internet video, Blu-ray, मोबाइल फोन, security cameras, drones आदि में व्यापक रूप से इस्तेमाल होने वाला video compression codec standard है
- इसका लक्ष्य full-motion video transmission के लिए जरूरी bandwidth को घटाना है
- यहां चर्चा किए गए कई concepts सिर्फ H.264 ही नहीं, बल्कि video compression के बड़े हिस्से पर भी लागू होते हैं
uncompressed वीडियो इतना बड़ा क्यों होता है
- एक साधारण uncompressed video file हर frame के pixel data वाली 2D buffer array होती है, जिसे 2 spatial dimensions और 1 time dimension वाली 3D byte array के रूप में देखा जा सकता है
- हर pixel लाल, हरे और नीले तीन primary colors के लिए 3 bytes इस्तेमाल करता है
- 1080p 60Hz वीडियो नीचे की calculation से लगभग 370MB/s raw data बनाता है
1920 × 1080 × 60 × 3
- इस size पर 50GB Blu-ray disc में करीब 2 मिनट ही रखे जा सकते हैं, और उसे move या store करना भी मुश्किल हो जाता है
एक PNG image से छोटा 5-second वीडियो
- Apple homepage screen का उदाहरण H.264 compression का असर सहज रूप से दिखाता है
- 5 सेकंड 60fps वीडियो में 300 frames हैं, लेकिन file size एक single PNG frame के लगभग पांचवें हिस्से के बराबर है
- ऊपर से देखने पर 300 गुना ज्यादा data रखने वाला वीडियो छोटा है, इसलिए H.264, PNG की तुलना में बहुत ज्यादा efficient दिखता है
Lossy compression में छोड़ी जाने वाली जानकारी
- H.264 एक lossy compression codec है, जो कम महत्वपूर्ण bits छोड़कर सिर्फ महत्वपूर्ण bits बनाए रखता है
- PNG एक lossless compression codec है, इसलिए encoded image से original source image को bit-level पर recover किया जा सकता है
- H.264 image को काटकर या किसी खास quadrant को फेंककर काम नहीं करता; दूसरे lossy image algorithms की तरह यह detail information घटाता है
- उदाहरण image में MacBook Pro speaker grille के holes जैसी details गायब हो जाती हैं, लेकिन zoom किए बिना फर्क पहचानना मुश्किल होता है
- सिर्फ इस step से ही image original size के करीब 7% तक घट जाती है
Entropy और duplicate data हटाना
- Information entropy किसी जानकारी को represent करने के लिए जरूरी bits की संख्या है, और यह dataset के साधारण size से अलग है
- इसे coin toss result जैसे possible states को represent करने के लिए जरूरी minimum bits की संख्या के रूप में समझा जा सकता है
- अगर 10 बार उछाला गया सिक्का हर बार heads आता है, तो
HHHHHHHHHHलिखने के बजाय “10 बार सभी heads” कहकर इसे छोटा दिखाया जा सकता है - यह प्रक्रिया information को बदले बिना representation घटाकर redundancy हटाती है
- ऐसे general-purpose lossless encoders को entropy encoders कहा जाता है
Frequency domain और quantization
- space या time के साथ बदलने वाले data को दूसरे coordinate system में बदला जा सकता है, और image brightness values को भी frequency domain में represent किया जा सकता है
- frequency domain में low-frequency components center की ओर होते हैं, और high-frequency components edges की ओर होते हैं
- image में fine grille जैसे detailed patterns high-frequency components होते हैं, जबकि smooth color और brightness changes low-frequency components होते हैं
- frequency-domain image के edges को mask करने से high-frequency information छोड़ी जा सकती है, और फिर सामान्य x-y coordinate system में वापस बदलने पर original जैसी, लेकिन कम detail वाली image मिलती है
- mask size बदलने से output image का detail level भी adjust किया जा सकता है
- उदाहरण में information entropy original के सिर्फ 2% स्तर पर हो, तब भी zoom किए बिना फर्क पहचानना मुश्किल होता है
- lossy compression में इस प्रक्रिया को quantization कहा जाता है
Chroma subsampling
- इंसानी आंख और दिमाग brightness changes को अच्छी तरह detect करते हैं, लेकिन color के बेहद छोटे differences को अपेक्षाकृत कम distinguish कर पाते हैं
- TV signal में RGB color data को Y+Cb+Cr में बदला जाता है
Y: luminance, यानी व्यावहारिक रूप से black-and-white brightnessCb,Cr: chroma, यानी color components
- RGB और YCbCr information entropy के लिहाज से equivalent हैं
- black-and-white TV के दौर में केवल Y signal था, और color TV आने पर color information को Cb और Cr में encode करके Y के साथ transmit करने का तरीका इस्तेमाल हुआ
- black-and-white TV सिर्फ Y component देखता है, और color TV chroma components तक इस्तेमाल करके internally RGB में convert करता है
- H.264 में इस्तेमाल होने वाला तरीका यह है कि Y component को full resolution में store किया जाता है, और C components को एक-चौथाई resolution में store किया जाता है
- chroma subsampling color information का कुछ हिस्सा छोड़कर total bandwidth को आधा कर देता है, जबकि visual difference छोटा बनाए रखता है
- यह technique सिर्फ H.264 की feature नहीं है; यह कई दशकों से व्यापक रूप से इस्तेमाल होती आई है
Motion compensation और temporal compression
- H.264 एक motion compensation compression standard है
- single frame के अंदर spatial-domain compression से आगे बढ़कर, यह कई frames को time dimension में एक साथ handle करता है
- tennis match जैसे वीडियो में, जहां camera fixed है और सिर्फ ball चल रही है, background पूरा हर बार store करने की जरूरत नहीं होती
- images आम तौर पर 16×16 pixel macroblocks में बांटी जाती हैं, और इन्हीं block units पर motion estimate किया जाता है
- frame types मुख्य रूप से तीन हैं
- I-frame: पूरे frame को बनाने के लिए जरूरी सभी bits रखने वाला frame
- P-frame: पिछले frame से हर macroblock के motion vector को encode करने वाला predicted frame
- B-frame: past और future दोनों frames से predict करने वाला bidirectional predicted frame
- decoder आखिरी I-frame से शुरू करके बाद के frames के motion-vector deltas जोड़ते हुए current frame बनाता है
- Apple homepage वाले example video में असल में तीन I-frames से macroblocks move होते हैं, इसलिए वह बहुत अच्छी तरह compress होता है
rewind करने के बाद थोड़ी देर रुकने की वजह
- YouTube जैसे वीडियो में कुछ सेकंड पीछे rewind करने पर तुरंत playback न होकर थोड़ी देर रुकने की घटना H.264 structure से जुड़ी है
- जब user किसी arbitrary frame पर jump करता है, तो decoder को पास के I-frame से फिर से calculation करनी पड़ती है
- इसके बाद current frame बनाने के लिए बाद के frames तक motion-vector deltas accumulate करने पड़ते हैं, इसलिए computational cost ज्यादा होती है
- यह तरीका space efficiency में बहुत अच्छा है, लेकिन decoding के लिए computation चाहिए
आखिरी lossless compression step
- lossy steps से गुजर चुके I-frame में भी अभी redundant information बची रहती है
- P-frame और B-frame के macroblock motion vectors में भी समान values वाले groups बन सकते हैं
- खासकर test video की तरह screen panning होने पर कई macroblocks समान मात्रा में move करते हैं
- Entropy encoder इस redundancy को handle करता है
- entropy encoder general-purpose lossless encoder होता है, इसलिए input data recover किया जा सकता है
example compression ratio
- original example video
1232×1154के non-standard resolution में capture किया गया था - 5 सेकंड 60fps के आधार पर original size नीचे की calculation से लगभग 1.2GB है
1232 × 1154 × 60 × 3 × 5
- compressed H.264 video 175KB है
- लेख की car analogy में बदलें तो यह 3000-pound car के 0.4 pound, यानी 6.5 ounces तक घट जाने जैसा है
- compression ratio की यह explanation दशकों के research को काफी simplify करती है, और अधिक detail H.264/MPEG-4 AVC Wikipedia Page पर देखी जा सकती है
1 टिप्पणियां
Hacker News राय
AV1 बेहतर लाइसेंस वाला, और भी ज़्यादा जादुई codec है
Meta वीडियो streaming में धीरे-धीरे VP9/AV1 streams को baseline बना रहा है: https://www.streamingmedia.com/Producer/Articles/Editorial/F...
वीडियो calls में भी AV1 इस्तेमाल कर रहा है: https://engineering.fb.com/2024/03/20/video-engineering/mobi...
Microsoft ने भी Teams में AV1 इस्तेमाल करना शुरू कर दिया है, और AV1 में ऐसे video encoding tools हैं जो screen sharing के लिए खास तौर पर उपयोगी हैं: https://techcommunity.microsoft.com/t5/microsoft-teams-blog/...
आजकल YouTube पर दिखने वाले ज़्यादातर वीडियो VP9 या AV1 होते हैं, H.264 कभी-कभार ही दिखता है
H.264 काफी लंबे समय तक रहेगा, लेकिन AV1 के internet video का नया baseline बनने की संभावना ज़्यादा लगती है
developer के नज़रिए से यह सबके लिए accessible होना चाहिए, लेकिन अभी हम उस feature के ज़्यादातर users तक पहुँचने का इंतज़ार कर रहे हैं
अच्छा होगा कि ज़्यादा users AV1 encoding/decoding वाले hardware खरीदें, और “AV1 inside” जैसा logo चाहिए लगता है
उदाहरण के लिए iPhone lineup में अभी सिर्फ iPhone 15 Pro ही hardware decoding देता है
मुझे lecture videos record करके 720p की अपेक्षाकृत छोटी files में बनाकर upload करने थे; वीडियो में सफेद whiteboard पर पतली, साफ़ lines के सामने धीमे-धीमे चलता व्यक्ति था, वह भी अधूरी-सी lighting में, इसलिए x264 का default encoding profile ठीक फिट नहीं बैठा
फिर भी एक-दो दिन settings से छेड़छाड़ करके ऐसा बना लिया कि करीब 2014 के iGPU-only laptop पर lecture के अगले दिन रात में चला सकूँ और उसके अगले दिन output upload कर सकूँ
दूसरी तरफ libaom ने 3 घंटे के वीडियो को render करने में करीब एक हफ्ता लगने का अनुमान दिया, और defaults इतने खराब थे कि experiment करने की गुंजाइश नहीं थी
यह 4 साल पहले की बात है, तो अब बेहतर हुआ होगा, लेकिन चमत्कार की उम्मीद नहीं है
यह ज़रूरी नहीं कि समस्या ही हो, लेकिन AV1 की असली समस्या यह है कि compression में बहुत ज़्यादा computation लगता है
या शायद मेरी आँखें बेहतर हो गई हों
काश इस topic पर गहराई से लिखा कोई article होता
संबंधित posts:
H.264 is Magic (2016) - https://news.ycombinator.com/item?id=30710574 - मार्च 2022, 219 comments
H.264 is magic (2016) - https://news.ycombinator.com/item?id=19997813 - मई 2019, 180 comments
H.264 is Magic – a technical walkthrough - https://news.ycombinator.com/item?id=17101627 - मई 2018, 1 comment
H.264 is Magic - https://news.ycombinator.com/item?id=12871403 - नवंबर 2016, 219 comments
वह article लिखे हुए 8 साल बीत चुके हैं, और अब H.264 patents में से काफी जल्द expire होने वाले हैं, लगभग 1–2 साल में: https://meta.wikimedia.org/wiki/Have_the_patents_for_H.264_M...
H.264 standard का पहला version 2003 में आया था और patents आम तौर पर 20 साल वैध रहते हैं, यह सोचें तो इसमें हैरानी नहीं है
पिछली generation वाले H.263 और MPEG-4 ASP के patents पहले ही expire हो चुके हैं और वे public domain में हैं
तो H.265 का क्या? नंबर एक ज्यादा बड़ा है न? https://en.wikipedia.org/wiki/High_Efficiency_Video_Coding
H.265 encoding में बचने वाली storage के मुकाबले extra computation बहुत ज्यादा है
जैसे H.264 से जिस file को 1 घंटे में 1GB तक घटाया जा सकता है, H.265 से उसे 12 घंटे लगाकर 850MB तक घटाना
use case के हिसाब से, हो सकता है आपको वैसे भी H.264 version चाहिए हो क्योंकि client support कहीं ज्यादा व्यापक है
अगर आपके पास datacenter-level compute resources हैं, या आप ऐसी streaming service चला रहे हैं जहाँ हर video पर 150MB की बचत जमा होती जाती है, तो H.265 अपनाएँगे, लेकिन कई practical मामलों में इसे justify करना मुश्किल है
यह VP9 के लगभग बराबर स्तर का है, लेकिन licensing issues की वजह से इसे अब भी हर जगह अपनाना मुश्किल रहा है
VVC/H.266 भी वही समस्या झेलता लगता है, और AV1 लगभग उतना ही अच्छा होते हुए पहले से कहीं ज्यादा अपनाया जा रहा है
नए codecs बेहतर compress करते हैं, लेकिन complexity non-linear तरीके से बढ़ जाती है
H.264 की तुलना में file size काफी छोटा हो गया
standard भी H.264 से 10 साल नया है; H.264 2003 का है और H.265 2013 का
“अगर सिक्का 10 बार उछालने पर हर बार heads आए, तो HHHHHHHHHH कहने के बजाय ‘10 बार उछाला और सब heads आए’ कहा जा सकता है” वाले example में, उस H string में शायद थोड़ा lossy compression शामिल है
मुझे याद है जब H.264 पहली बार आया था
उस समय मैं mplayer में बहुत डूबा हुआ था, इसलिए latest releases अक्सर download करके build करता था
जब पहली H.264 file मिली, तो mplayer उसे पढ़ नहीं पाया, इसलिए development version लेकर build करना पड़ा
वह चल गया, और मुझे दो बातें समझ आईं: quality कमाल की थी, और मेरा Athlon 1800+ उसे संभाल नहीं पा रहा था
बाद में mplayer या libavcodec versions में performance काफी बेहतर हुई, लेकिन वह दिन अब भी याद है
mplayer इस्तेमाल किए हुए बहुत लंबा समय हो गया, लेकिन उस दौर में वह best था
पहले मैं एक ऐसी company में काम करता था जो video-based products develop करती थी; Las Vegas की एक दूसरी company ने हमारे executives को “innovative video codec” और player बेचा, और use करने के लिए NDA sign करना पड़ता था
इस्तेमाल करके देखा तो वह mplayer की तरह काम करता था, बल्कि बहुत ही ज्यादा वैसा ही था
5 मिनट और investigate करने पर बात खुल गई, और उस company को बड़ी रकम चुकाने वाले executives की खूब बेइज्जती हुई
tech sector में भी non-technical decision-makers को बेवकूफ बनाना हैरानीजनक रूप से आसान है
क्योंकि उन्हें पीछे छूट जाने की चिंता बहुत ज्यादा होती है
समझदार व्यक्ति evaluation के लिए अच्छे engineers को बुलाता है, और Dunning-Kruger के शिकार लोग wallet लेकर line में लग जाते हैं
1999 में acquired किए गए startup को छोड़ने का एक समय आया था, और उस वक्त मैं MPEG encoding कर रहा था
जिन कंपनियों में मैंने interview दिया था, उनमें से एक ने कहा कि उन्होंने एक नया video compression तरीका बनाया है, और NDA sign कराने के बाद उन्होंने non-realtime software codec से encode/decode की गई एक छोटी clip दिखाई
मैं उनके algorithm का ASIC version बनाने वाले व्यक्ति के तौर पर interview दे रहा था, लेकिन output के 1–2 मिनट देखकर ही मुझे अंदाज़ा हो गया कि वे क्या कर रहे हैं
मुझे लगा कि example algorithm की strengths के हिसाब से चुना गया है, इसलिए मैंने एक ज़्यादा मुश्किल scene सुझाया और यह भी बताया कि मेरे हिसाब से तरीका क्या है
उन्होंने न confirm किया, न deny, लेकिन मुझे second interview के लिए बुलाया
दूसरे round में founder पति-पत्नी CEO/CTO से बात हुई, और उनकी योजना ASIC बेचने की नहीं थी; वे codec को secret रखना चाहते थे और ASIC के जरिए DSL-based cable network बनाकर video distribution करना चाहते थे
मैंने कहा, “ऐसा लगता है कि आपने बेहतर carburetor invent कर लिया है और अब GM से compete करने के लिए car factory बनाना चाहते हैं,” और उन्हें यह बात अच्छी नहीं लगी
इस कहानी का H.264 से संबंध यह है कि उनका दावा था: “मौजूदा compression अपनी limit पर पहुंच चुका है, इसलिए सिर्फ हमारा codec ही DSL line पर high-quality video भेज सकता है”
मैंने जवाब दिया कि compressors बेहतर होते रहेंगे, और अगर ऐसा न भी हुआ तो घरों तक तेज़ Internet आ जाने पर जिस threshold को वे पार करने लायक समझ रहे हैं, वह threshold ही गायब हो जाएगी
उन्होंने कहा कि physics के नियमों के हिसाब से तारों पर भेजी जा सकने वाली bit rate की एक limit होती है और हम already उस limit पर पहुंच चुके हैं
मुझे job offer नहीं मिला, और मैं चाहता भी नहीं था
उस company को VC money मिला, लेकिन कुछ साल बाद वह बंद हो गई; दूसरे लोगों ने कहीं ज्यादा efficient codecs बनाए, और 2Mbps Internet connection कोई limit नहीं था
असली algorithm में बहुत smart math और algorithmic ताकत रही होगी, इसलिए वे technically बेवकूफ नहीं थे; उनमें business sense की कमी थी
इसे दोबारा इस तरह कहने पर मैं घमंडी सर्वज्ञानी जैसा लग सकता हूं, लेकिन मेरी जिंदगी में यह उन दो मौकों में से एक था जब मैंने कुछ देखकर कुछ ही seconds में secret sauce समझ लिया
जिन मामलों में मैं बेवकूफ निकला, वे इससे कहीं ज्यादा हैं
algorithm की पुष्टि मुझे कभी नहीं मिली, लेकिन silhouette artifacts देखकर यह काफी साफ था
MPEG, JPEG की तरह, image को छोटे blocks (8x8, 16x16 आदि) में compress करता है; इससे spatial redundancy का फायदा उठाने का scope सीमित होता है, लेकिन उस redundancy को खोजने की computational cost भी सीमित रहती है
उनका codec कुछ वैसा दिखता था जैसा Microsoft ने 1990s के आखिर में Talisman graphics architecture के लिए propose किया था
fixed blocks में बांटने के बजाय, लगता था कि वे frame sequence analyze करके semi-arbitrary boundaries वाले structurally consistent regions खोजते थे
उदाहरण के लिए tennis match में background काफी हद तक “rigid body” जैसा होता है; camera pan होने पर अगर एक pixel move करता है, तो आसपास के pixels के भी वही spatial transform करने की संभावना होती है
player हर frame में बदलता है, लेकिन उस blob में lighting और position का correlation होता है
ऐसे regions identify करने के बाद वे शायद उस region की image को JPEG-जैसे तरीके से compress करते होंगे, और अगले frame में analyze करते होंगे कि एक region अगले frame में किस तरह affine transform या ज्यादा general transform से गुजरता है, फिर उसे कुछ parameters में encode करते होंगे
यही next-frame prediction का आधार बनता है, और अगर fit अच्छा हो तो prediction error correct करने के लिए ज्यादा bits की जरूरत नहीं होती
VC से 32 मिलियन डॉलर की funding मिली थी और कहा जाता है कि 2002 में stealth mode से बाहर आई
उसके बाद क्या हुआ, यह मुझे नहीं मिला
लेख बहुत शानदार है, लेकिन Information Entropy expression को अलग term की तरह जोड़कर लिखना “ATM machine” वाली expressions में भी सबसे ज्यादा खटकने वालों में आता है
लेख अपने आप में अच्छा है, लेकिन expression वाकई बहुत तीखा है
02016 में H.264 कई देशों में patents से बंधा हुआ magic था
अब standard अगस्त 02004 में 1 साल की open standardization process के बाद प्रकाशित हुआ था, patents filing date से 20 साल तक ही चलते हैं, और जो चीज already public हो चुकी हो उस पर patent नहीं लिया जा सकता, इसलिए उनमें से ज्यादातर expire हो चुके होंगे या कुछ महीनों में expire हो जाएंगे
अमेरिका में अपने खुद के disclosure पर 1 साल का grace period होता है, लेकिन अगर कोई exception है तो मैं जरूर सुनना चाहूंगा
userbinator ने https://meta.m.wikimedia.org/wiki/Have_the_patents_for_H.264... की ओर इशारा किया, लेकिन वहां listed patents में से ज्यादातर की priority dates H.264 standard finalize होने के बाद की हैं, इसलिए वे H.264 को implement करने के लिए essential नहीं हो सकते
हां, अगर यह दावा हो कि standardization के समय यह known नहीं था कि इसे implement करना possible है, तो अलग बात है, लेकिन वह काफी कम convincing है
हैरानी की बात यह है कि पिछले 20 सालों में थोड़े बेहतर कहे जा सकने वाले codecs तो आए, लेकिन ffmpeg implementations से मेरे tests के हिसाब से कोई भी बहुत ज्यादा बेहतर नहीं था
patent-free status सुनिश्चित हो जाए तो अच्छा लगे या न लगे, H.264 के कुछ समय तक standard codec के रूप में और मजबूत होने की संभावना बड़ी लगती है
AV1 समान bandwidth पर visual quality में थोड़ा बेहतर है, लेकिन बहुत ज्यादा slow है, और 02018 जितनी देर से filed patents के लिए भी vulnerable है
“decoder को arbitrary frame पर jump करने को कहा गया, इसलिए nearest I-frame से शुरू करके motion vector deltas को current frame तक जोड़ने की calculation फिर से करनी पड़ती है और इसलिए थोड़ी देर रुकता है” — यह 2016 की बात है
आजकल वजह यह है कि YouTube जानता है कि तुम Firefox इस्तेमाल कर रहे हो