ڇا؟ هڪ وڊيو ڪوڊيڪ سافٽ ويئر/هارڊويئر جو هڪ ٽڪرو آهي جيڪو ڊجيٽل وڊيو کي دٻائي ٿو ۽/يا ڊمپپريس ڪري ٿو.
ڇا جي لاءِ؟ بينڊوڊٿ جي لحاظ کان ڪجهه حدن جي باوجود ۽
۽ ڊيٽا اسٽوريج جي جڳهه جي لحاظ کان، مارڪيٽ کي تيزيء سان اعلي معيار جي وڊيو جي گهرج آهي. ڇا توهان کي ياد آهي ته آخري پوسٽ ۾ اسان 30x24 جي ريزوليوشن سان 480 فريم في سيڪنڊ، 240 بٽ في پکسل، گهربل گھٽ ۾ گھٽ حساب ڪيئن ڪيو؟ اسان حاصل ڪيو 82,944 Mbit/s بغير ڪمپريشن. ڪمپريشن هن وقت صرف ٽيليويزن اسڪرين ۽ انٽرنيٽ تي HD/FullHD/4K منتقل ڪرڻ جو واحد طريقو آهي. اهو ڪيئن حاصل آهي؟ هاڻي اچو ته مختصر طور تي مکيه طريقن کي ڏسو.
هڪ عام غلطي نوان نوان ٺاهيندا آهن ڊجيٽل ويڊيو ڪوڊيڪ ۽ ڊجيٽل وڊيو ڪنٽينر کي پريشان ڪري رهيا آهن. هڪ ڪنٽينر هڪ خاص شڪل آهي. هڪ لفافي جنهن ۾ وڊيو (۽ ممڪن طور تي آڊيو) ميٽا ڊيٽا. کمپريس ٿيل وڊيو کي سمجهي سگهجي ٿو هڪ ڪنٽينر پيل لوڊ جي طور تي.
عام طور تي، هڪ وڊيو فائل جي واڌ کي ظاهر ڪري ٿو ان جي قسم جي ڪنٽينر. مثال طور، فائل video.mp4 شايد هڪ ڪنٽينر آهي MPEG-4 حصو 14، ۽ هڪ فائيل نالي video.mkv تمام گهڻو امڪان آهي ميٽرڪ. ڪوڊيڪ ۽ ڪنٽينر فارميٽ جي مڪمل طور تي پڪ ڪرڻ لاء، توهان استعمال ڪري سگهو ٿا FFmpeg يا MediaInfo.
اچو ته ڏسو بنيادي ميکانيزم جو بنيادي مکيه يونيورسل وڊيو ڪوڊيڪ. انهن مان گھڻا مفهوم مفيد آهن ۽ جديد ڪوڊيڪس ۾ استعمال ٿيندا آهن جهڙوڪ VP9, AV1 и HEVC. مان توهان کي ڊيڄاريان ٿو ته وضاحت ڪيل ڪيتريون ئي شيون آسان ٿي وينديون. ڪڏهن ڪڏهن حقيقي دنيا جا مثال (جيئن H.264 سان) ٽيڪنالاجي کي ظاهر ڪرڻ لاءِ استعمال ڪيا ويندا.
1st قدم - تصوير کي ورهائڻ
پهريون قدم فريم کي ڪيترن ئي حصن، ذيلي حصن ۽ ان کان ٻاهر ۾ ورهائڻ آهي.
ڇا جي لاءِ؟ ان جا ڪيترائي سبب آهن. جڏهن اسان هڪ تصوير کي ورهائي سگهون ٿا، ته اسان ننڍڙن حصن لاءِ ننڍڙن حصن کي استعمال ڪندي موشن ويڪر جي وڌيڪ صحيح اڳڪٿي ڪري سگهون ٿا. جڏهن ته جامد پس منظر لاءِ توهان پنهنجو پاڻ کي وڏن حصن تائين محدود ڪري سگهو ٿا.
ڪوڊيڪس عام طور تي انهن حصن کي سيڪشن (يا ٽڪڙن)، ميڪرو بلاڪس (يا ڪوڊنگ ٽري بلاڪ)، ۽ گھڻن ذيلي حصن ۾ منظم ڪن ٿا. انهن ڀاڱن جي وڌ ۾ وڌ ماپ مختلف آهي، HEVC ان کي 64x64 تي سيٽ ڪري ٿو جڏهن ته AVC 16x16 استعمال ڪري ٿو، ۽ ذيلي پارٽيشن کي 4x4 سائيز تائين ورهائي سگهجي ٿو.
ڇا توهان کي ياد آهي فريم جا قسم گذريل مضمون کان؟! ساڳيو ئي بلاڪ تي لاڳو ٿي سگهي ٿو، تنهنڪري اسان وٽ هڪ I-fragment، هڪ B-block، هڪ P-macroblock، وغيره ٿي سگهي ٿو.
هڪ دفعو اسان وٽ سيڪشن آهن، اسان انهن لاءِ علم نجوم جي اڳڪٿي ڪري سگهون ٿا. لاءِ INTER اڳڪٿيون منتقل ٿيڻ گهرجي حرڪت ویکٹر ۽ باقي، ۽ INTRA جي اڳڪٿي لاءِ ان کي منتقل ڪيو ويو آهي اڳڪٿي جي هدايت ۽ باقي.
ٽيون قدم - تبديلي
هڪ دفعو اسان وٽ هڪ بقايا بلاڪ (پيش ڪيل سيڪشن → حقيقي سيڪشن)، اهو ممڪن آهي ته ان کي اهڙي طريقي سان تبديل ڪيو وڃي ته اسان ڄاڻون ٿا ته مجموعي معيار کي برقرار رکڻ دوران ڪهڙن پکسلز کي رد ڪري سگهجي ٿو. ڪجھ تبديليون آھن جيڪي صحيح رويي کي مهيا ڪن ٿيون.
جيتوڻيڪ اتي ٻيا طريقا آهن، اچو ته انهن کي وڌيڪ تفصيل سان ڏسو. discrete cosine transform (ڊي سي سي کان discrete cosine transform). DCT جا مکيه ڪم:
پکسلز جي بلاڪ کي فريڪوئنسي ڪوئفينٽس جي برابر سائيز جي بلاڪن ۾ تبديل ڪري ٿو.
مقامي بيڪارگي کي ختم ڪرڻ ۾ مدد لاءِ طاقت کي گھٽائي ٿو.
reversibility مهيا ڪري.
فيبروري 2، 2017 Sintra R.J. (Cintra, RJ) ۽ Bayer F.M. (Bayer FM) تصويري ڪمپريشن لاءِ ڊي سي ٽي-جهڙي تبديلي بابت هڪ مضمون شايع ڪيو جنهن کي صرف 14 اضافو جي ضرورت آهي.
پريشان نه ڪريو جيڪڏهن توهان هر شيء جي فائدن کي نه سمجهي. ھاڻي اچو ته خاص مثال استعمال ڪريون انھن جي حقيقي قدر کي ڏسڻ لاءِ.
پکسلز جي هن بلاڪ تي ڊي سي ٽي لاڳو ڪريو ۽ 8x8 بلاڪ جي کوٽائي حاصل ڪريو:
۽ جيڪڏهن اسان هن بلاڪ جي کوٽائي کي ترتيب ڏيون ٿا، اسان هيٺ ڏنل تصوير حاصل ڪنداسين:
جئين توهان ڏسي سگهو ٿا، اهو اصل تصوير وانگر نظر نٿو اچي. توھان ڏسي سگھو ٿا ته پھريون کوٽائي ٻين سڀني کان بلڪل مختلف آھي. هي پهريون ڪوفيشيٽ DC ڪوفيشيٽ جي نالي سان سڃاتو وڃي ٿو، جيڪو سڀني نمونن جي نمائندگي ڪري ٿو ان پٽ صفن ۾، ڪجهه سراسري وانگر.
ڳڻپيوڪر جو هي بلاڪ هڪ دلچسپ ملڪيت آهي: اهو اعلي تعدد حصن کي گهٽ فريکوئنسي وارن کان جدا ڪري ٿو.
ھڪڙي تصوير ۾، گھڻي طاقت گھٽ فريڪوئنسيز تي مرڪوز آھي، تنھنڪري جيڪڏھن توھان تصوير کي ان جي فريڪوئنسي حصن ۾ تبديل ڪريو ۽ اعلي تعدد ڪوئفينٽس کي رد ڪريو، توھان گھٽائي سگھوٿا ڊيٽا جي مقدار کي گھٽائڻ لاءِ تصوير کي بيان ڪرڻ لاءِ تمام گھڻي تصوير جي معيار کي قربان ڪرڻ کان سواءِ.
اچو ته ٽيسٽ ڪيس ۾ حاصل ڪيل ڄاڻ کي لاڳو ڪرڻ جي ڪوشش ڪريون، اصل تصوير کي ان جي فريڪوئنسي ۾ تبديل ڪري (بلاڪ آف ڪوفيفينٽس) DCT استعمال ڪندي ۽ پوءِ گھٽ ۾ گھٽ اهم ڪوئفينٽس جو حصو رد ڪري.
پهرين اسان ان کي فريڪوئنسي ڊومين ۾ تبديل ڪريون ٿا.
اڳيون، اسان کوٽائي جو حصو (67٪) رد ڪريون ٿا، خاص طور تي هيٺين ساڄي حصو.
آخر ۾، اسان تصوير کي ٻيهر ٺاھيون ٿا ھن رد ٿيل بلاڪ جي کوٽائيز مان (ياد رکو، اھو ناقابل واپسي ھئڻ گھرجي) ۽ ان کي اصل سان ڀيٽيو.
اسان ڏسون ٿا ته اهو اصل تصوير سان مشابهت رکي ٿو، پر اصل کان ڪيترائي اختلاف آهن. اسان 67,1875٪ ڪڍي ڇڏيو ۽ اڃا تائين اصل وانگر ڪجهه حاصل ڪيو. ان کان به وڌيڪ بهتر معيار جي تصوير حاصل ڪرڻ لاءِ ڪوئفينٽس کي وڌيڪ سوچڻ سان رد ڪرڻ ممڪن هو، پر اهو هڪ ايندڙ موضوع آهي.
هر ڪوئفائٽيٽ سڀني پکسلز استعمال ڪندي ٺاهي وئي آهي
اھم: ھر ڪوفيشيٽ سڌو سنئون ھڪڙي پکسل تي نقشو نه ڪيو ويو آھي، پر سڀني پکسلز جو وزن آھي. هي حيرت انگيز گراف ڏيکاري ٿو ته هر انڊيڪس لاءِ منفرد وزن استعمال ڪندي پهريون ۽ ٻيو ڪوفيفينٽ ڪيئن ڳڻيو وڃي ٿو.
توھان پڻ ڪوشش ڪري سگھوٿا ڊي سي ٽي کي ڏسڻ سان ان جي بنياد تي ھڪڙي سادي تصوير ٺاھڻ کي. مثال طور، ھتي آھي علامت A ھر ھڪڙي وزن جي استعمال سان ٺاھيل آھي:
چوٿين قدم - quantization
پوئين مرحلي تي اسان ڪي ڪوئفيشيٽ ڪڍي ڇڏڻ کان پوءِ، آخري مرحلي (تبديلي) تي اسين مقدار جي هڪ خاص شڪل کي انجام ڏيون ٿا. هن مرحلي تي، معلومات وڃائڻ قبول آهي. يا، وڌيڪ آسانيءَ سان، اسان ڪمپريشن حاصل ڪرڻ لاءِ ڪوئفينٽس کي مقدار ۾ آڻينداسين.
توھان ڪھڙي ريت ڪري سگھوٿا ڪوئفٽينٽ جي ھڪڙي بلاڪ کي مقدار ۾؟ ھڪڙو آسان طريقو آھي يونيفارم ڪوانٽيائيزيشن، جڏھن اسان ھڪ بلاڪ وٺون ٿا، ان کي ھڪڙي قدر (10 کان) ورهايو ۽ نتيجو گول ڪريو.
ڇا اسان کوٽائي جي هن بلاڪ کي رد ڪري سگهون ٿا؟ ها، اسان ڪري سگهون ٿا، ساڳئي قدر سان ضرب ڪريون جنهن سان اسان ورهايو.
اھو طريقو بھترين ناھي ڇو جو اھو ھر ھڪ عدد جي اھميت کي نظر ۾ نٿو رکي. ھڪڙي ھڪڙي ھڪڙي قيمت جي بدران مقدار جي ميٽرڪس کي استعمال ڪري سگھي ٿو، ۽ ھي ميٽرڪس ھيٺين ساڄي جي اڪثريت ۽ مٿين کاٻي جي اقليت کي مقدار جي حساب سان DCT ملڪيت جو استحصال ڪري سگھي ٿو.
قدم 5 - اينٽراپي ڪوڊنگ
هڪ دفعو اسان ڊيٽا (تصوير بلاڪ، ٽڪرا، فريم) کي مقدار ۾ ڪيو آهي، اسان اڃا تائين ان کي نقصان پهچائڻ سان گڏ ڪري سگهون ٿا. ڊيٽا کي گڏ ڪرڻ لاء ڪيترائي الگورتھم طريقا آھن. اسان انهن مان ڪجهه تي هڪ تڪڙو نظر وجهڻ وارا آهيون، وڌيڪ تفصيل لاءِ توهان ڪتاب پڙهي سگهو ٿا Understanding Compression: Data Compression for Modern Developers ("سمجھڻ کمپريشن: جديد ڊولپرز لاء ڊيٽا کمپريشن").
VLC استعمال ڪندي وڊيو انڪوڊنگ
اچو ته چئو ته اسان وٽ ڪردارن جو سلسلو آهي: a, e, r и t. امڪان (0 کان 1 تائين) جو هر اکر ڪيترا ڀيرا هڪ وهڪرو ۾ ظاهر ٿئي ٿو هن جدول ۾ پيش ڪيو ويو آهي.
اسان وهڪرو کي دٻايو، فرض ڪيو ته اسان هر ڪردار لاء 8 بٽ خرچ ڪنداسين. بغير ڪمپريشن، 24 بٽ في ڪردار جي ضرورت پوندي. جيڪڏهن توهان هر ڪردار کي ان جي ڪوڊ سان مٽايو، توهان کي بچت ملندي!
پهريون قدم ڪردار کي انڪوڊ ڪرڻ آهي e، جيڪو 10 جي برابر آهي، ۽ ٻيو اکر آهي a، جيڪو شامل ڪيو ويو آهي (نه رياضياتي طريقي سان): [10] [0]، ۽ آخرڪار ٽيون ڪردار t، جيڪو اسان جي آخري ڪمپريس ٿيل بٽ اسٽريم کي برابر ڪري ٿو [10][0][1110] يا 1001110، جنهن کي صرف 7 بِٽ جي ضرورت آهي (اصل کان 3,4 ڀيرا گهٽ جاءِ).
مهرباني ڪري نوٽ ڪريو ته هر ڪوڊ هڪ اڳي سان گڏ هڪ منفرد ڪوڊ هجڻ گهرجي. Huffman الگورتھم اهي نمبر ڳولڻ ۾ توهان جي مدد ڪندو. جيتوڻيڪ اهو طريقو ان جي خامين کان سواء ناهي، اتي وڊيو ڪوڊيڪس موجود آهن جيڪي اڃا تائين پيش ڪن ٿا هي الورورٿمڪ طريقو کمپريشن لاء.
ٻنهي انڪوڊر ۽ ڊيڪوڊر کي لازمي طور تي انهن جي بائنري ڪوڊس سان گڏ علامت ٽيبل تائين رسائي هوندي. تنهن ڪري، ان پٽ جي طور تي ٽيبل موڪلڻ پڻ ضروري آهي.
رياضي جي ڪوڊنگ
اچو ته چئو ته اسان وٽ ڪردارن جو سلسلو آهي: a, e, r, s и t، ۽ انهن جو امڪان هن جدول ۾ پيش ڪيو ويو آهي.
a
e
r
s
t
امڪان
0,3
0,3
0,15
0,05
0,2
ھن جدول کي استعمال ڪندي، اسين سڀ ممڪن اکر تي مشتمل حدون ٺاھينداسين، سڀ کان وڏي انگ جي ترتيب سان.
ھاڻي اچو ته ٽن اکرن جي ھڪڙي وهڪرو کي انڪوڊ ڪريون: کاڌو.
پهرين پهريون ڪردار چونڊيو e، جيڪو 0,3 کان 0,6 تائين زير زمين ۾ آھي (شامل نه آھي). اسان هن ذيلي رينج کي وٺون ٿا ۽ ان کي ٻيهر ساڳئي تناسب ۾ ورهايو ٿا جيئن اڳ ۾، پر هن نئين حد لاء.
اچو ته اسان جي وهڪرو ڪوڊنگ جاري رکون کاڌو. هاڻي ٻيو ڪردار وٺو a، جيڪو 0,3 کان 0,39 تائين نئين ذيلي رينج ۾ آهي، ۽ پوء اسان جو آخري ڪردار وٺو t ۽ ساڳئي عمل کي ٻيهر ورجائڻ سان، اسان کي 0,354 کان 0,372 تائين حتمي ذيلي رينج حاصل ٿئي ٿي.
اسان کي صرف 0,354 کان 0,372 تائين آخري ذيلي رينج ۾ ھڪڙو نمبر چونڊڻو آھي. اچو ته 0,36 چونڊيو (پر توھان ھن ذيلي رينج ۾ ڪو ٻيو نمبر چونڊي سگھو ٿا). صرف هن نمبر سان اسان کي اسان جي اصل وهڪرو بحال ڪرڻ جي قابل ٿي ويندي. اهو ائين آهي ڄڻ ته اسان پنهنجي وهڪري کي انڪوڊ ڪرڻ لاءِ حدن اندر هڪ لڪير ٺاهي رهيا هئاسين.
ريورس آپريشن (يعني، ڊيڪوڊنگ) بلڪل سادو آهي: اسان جي نمبر 0,36 ۽ اسان جي شروعاتي حد سان، اسان ساڳيو عمل هلائي سگهون ٿا. پر ھاڻي، ھن نمبر کي استعمال ڪندي، اسان ھن نمبر کي استعمال ڪندي انڪوڊ ٿيل وهڪرو کي سڃاڻون ٿا.
پهرين رينج سان، اسان کي خبر آهي ته اسان جو نمبر سلائس سان ملندو آهي، تنهنڪري هي اسان جو پهريون ڪردار آهي. هاڻي اسان هن ذيلي رينج کي ٻيهر ورهائي رهيا آهيون ساڳئي عمل تي عمل ڪندي. هتي توهان ڏسي سگهو ٿا ته 0,36 علامت سان ملندڙ جلندڙ آهي a، ۽ عمل کي ورجائڻ کان پوءِ اسان آخري ڪردار تي پهتاسين t (اسان جي اصل انڪوڊ ٿيل وهڪرو ٺاهيندي کاڌو).
ٻنهي انڪوڊر ۽ ڊيڪوڊر وٽ علامت جي امڪانن جي جدول هجڻ لازمي آهي، تنهنڪري ان کي ان پٽ ڊيٽا ۾ پڻ موڪلڻ ضروري آهي.
ڪافي خوبصورت، آهي نه؟ جيڪو به هن حل سان آيو هو تمام هوشيار هو. ڪجهه وڊيو ڪوڊيڪس هن ٽيڪنڪ کي استعمال ڪن ٿا (يا گهٽ ۾ گهٽ ان کي هڪ اختيار طور پيش ڪريو).
خيال اهو آهي ته بغير ڪنهن مقدار جي بٽ وهڪرو کي نقصان پهچائڻ. يقينن هي مضمون غائب آهي تفصيلات، سببن، واپار بند، وغيره. پر جيڪڏهن توهان هڪ ڊولپر آهيو، توهان کي وڌيڪ ڄاڻڻ گهرجي. نوان ڪوڊيڪس مختلف اينٽراپي انڪوڊنگ الگورتھم استعمال ڪرڻ جي ڪوشش ڪندا آهن جهڙوڪ ANS.
قدم 6 - بٽ اسٽريم فارميٽ
اهو سڀ ڪجهه ڪرڻ کان پوءِ، باقي رهي ٿو ته ڪمپريس ٿيل فريم کي کولڻ لاءِ قدمن جي حوالي سان. ڊيڪوڊر کي انڪوڊر پاران ڪيل فيصلن جي واضح طور تي ڄاڻ ڏني وڃي. ڊيڪوڊر کي لازمي طور تي تمام ضروري معلومات مهيا ڪرڻ گهرجي: سا جي کوٽائي، رنگ جي جاء، قرارداد، اڳڪٿي جي ڄاڻ (موشن ویکٹر، هدايتي INTER اڳڪٿي)، پروفائل، سطح، فريم جي شرح، فريم جو قسم، فريم نمبر ۽ گهڻو ڪجهه.
اسان بٽ اسٽريم تي تڪڙو نظر وجهنداسين H.264. اسان جو پهريون قدم آهي هڪ گهٽ ۾ گهٽ H.264 بٽ اسٽريم ٺاهڻ (FFmpeg ڊفالٽ طور سڀني انڪوڊنگ آپشنز کي شامل ڪري ٿو جهڙوڪ SEI NAL - اسان اهو معلوم ڪنداسين ته اهو ٿورو اڳتي آهي). اسان اهو ڪري سگهون ٿا اسان جي پنهنجي مخزن ۽ FFmpeg استعمال ڪندي.
هي حڪم هڪ خام بٽ اسٽريم ٺاهيندو H.264 ھڪڙي فريم سان، 64 × 64 قرارداد، رنگ جي جڳھ سان يو يو وي 420. انهي حالت ۾، هيٺ ڏنل تصوير کي فريم طور استعمال ڪيو ويندو آهي.
H.264 بٽ اسٽريم
معياري AVC (H.264) طئي ڪري ٿو ته معلومات موڪلي ويندي macroframes ۾ (نيٽ ورڪ جي معني ۾)، سڏيو ويندو آهي نال (هي هڪ نيٽ ورڪ تجزيي جي سطح آهي). NAL جو بنيادي مقصد هڪ "ويب-دوستانه" وڊيو پيشڪش مهيا ڪرڻ آهي. اهو معيار ٽي وي تي ڪم ڪرڻ گهرجي (اسٽريم تي ٻڌل)، انٽرنيٽ (پيڪٽ تي ٻڌل).
NAL عناصر جي حدن کي بيان ڪرڻ لاء ھڪڙو هم وقت سازي مارڪر آھي. هر سنڪ ٽوڪن ۾ هڪ قدر شامل آهي 0x00 0x00 0x01, سواءِ پهرين جي، جيڪو برابر آهي 0x00 0x00 0x00 0x01. جيڪڏهن اسان لانچ ڪنداسين هيڪسڊمپ ٺاهيل H.264 بٽ اسٽريم لاءِ، اسان فائل جي شروعات ۾ گهٽ ۾ گهٽ ٽي NAL نمونن کي سڃاڻون ٿا.
جيئن چيو ويو آهي، ڊيڪوڊر کي نه رڳو تصويري ڊيٽا، پر وڊيو جا تفصيل، فريم، رنگ، استعمال ٿيل پيٽرولر، ۽ گهڻو ڪجهه ڄاڻڻ گهرجي. هر NAL جو پهريون بائيٽ ان جي درجي ۽ قسم کي بيان ڪري ٿو.
NAL قسم جي سڃاڻپ ڪندڙ
بيان
0
اڻڄاتل قسم
1
IDR کان سواءِ انڪوڊ ٿيل تصوير جو ٽڪرو
2
ڪوڊ ٿيل سلائس ڊيٽا سيڪشن A
3
ڪوڊ ٿيل سلائس ڊيٽا سيڪشن B
4
ڪوڊ ٿيل سلائس ڊيٽا سيڪشن C
5
IDR تصوير جو انڪوڊ ٿيل IDR ٽڪرو
6
SEI توسيع بابت وڌيڪ معلومات
7
SPS Sequence Parameter Set
8
PPS تصويري پيٽرولن جو سيٽ
9
رسائي ڌار ڪندڙ
10
تسلسل جي پڄاڻي
11
سلسلي جي پڄاڻي
...
...
عام طور تي bitstream جو پهريون NAL هوندو آهي ايس ايس ايس. هن قسم جي NAL عام انڪوڊنگ متغيرن جهڙوڪ پروفائل، ليول، ريزوليوشن وغيره بابت آگاهي ڏيڻ جو ذميوار آهي.
جيڪڏهن اسان پهرين هم وقت سازي مارڪر کي ڇڏي ڏيون ٿا، اسان پهرين بائيٽ کي ڊيڪوڊ ڪري سگھون ٿا اهو معلوم ڪرڻ لاءِ ته ڪهڙو NAL قسم پهريون آهي.
مثال طور، sync ٽوڪن کان پوء پهريون بائيٽ آهي 01100111جتي پهريون ساٽ (0) فيلڊ ۾ آهي forbidden_zero_bit. اڳيون 2 بٽ (11) اسان کي فيلڊ ٻڌائي ٿو nal_ref_idc, جنهن مان ظاهر ٿئي ٿو ته هي NAL هڪ ريفرنس فيلڊ آهي يا نه. ۽ باقي 5 بٽ (00111) اسان کي فيلڊ ٻڌائي ٿو nal_unit_type, انهي صورت ۾ اهو آهي SPS بلاڪ (7) NAL.
جيڪڏھن توھان ڏسو ٿا bitstream specification H.264 SPS NAL لاءِ، اسان پيراميٽر جو نالو، ڪيٽيگري ۽ وضاحت لاءِ ڪيترائي قدر ڳوليندا. مثال طور، اچو ته شعبن کي ڏسو pic_width_in_mbs_minus_1 и pic_height_in_map_units_minus_1.
پيٽرولر جو نالو
درجه بندي
بيان
pic_width_in_mbs_minus_1
0
ue(v)
pic_height_in_map_units_minus_1
0
ue(v)
جيڪڏهن اسان انهن شعبن جي قدرن سان گڏ ڪجهه رياضياتي عملن کي انجام ڏيون ٿا، اسان حل حاصل ڪنداسين. ھڪڙو نمائندگي ڪري سگھي ٿو 1920 x 1080 استعمال ڪندي pic_width_in_mbs_minus_1 119 جي قيمت سان (119 + 1) * macroblock_size = 120 * 16 = 1920). ٻيهر، خلا کي بچائڻ لاء، 1920 انڪوڊنگ جي بدران، اسان ان کي 119 سان ڪيو.
هتي اسان ان جي پهرين 6 بائيٽ قدر ڏسون ٿا: 01100101 10001000 10000100 00000000 00100001 11111111. جيئن ته پهريون بائيٽ معلوم ٿئي ٿو ته NAL قسم کي ظاهر ڪرڻ لاء، هن صورت ۾ (00101) هڪ IDR ٽڪرو آهي (5)، ۽ پوء توهان ان کي وڌيڪ ڳولي سگهو ٿا:
وضاحت جي معلومات کي استعمال ڪندي، اهو ممڪن ٿيندو ته ٽڪر جي قسم کي ڊيڪوڊ ڪرڻ (سلائس_قسم) ۽ فريم نمبر (فريم_نمبر) ٻين اهم شعبن جي وچ ۾.
حاصل ڪرڻ لاء ڪجھ فيلڊ جا قدر (ue(v), me(v), se(vيا te(v))، اسان جي بنياد تي هڪ خاص ڊيڪوڊر استعمال ڪندي ٽڪرا کي ڊيڪوڊ ڪرڻ جي ضرورت آهي تجزياتي Golomb ڪوڊ. اهو طريقو متغير قدرن کي انڪوڊنگ ڪرڻ لاءِ تمام ڪارائتو آهي، خاص طور تي جڏهن اتي ڪيترائي ڊفالٽ قدر آهن.
قدر سلائس_قسم и فريم_نمبر هن وڊيو جا 7 (I-fragment) ۽ 0 (پهريون فريم) آهن.
هڪ bitstream هڪ پروٽوڪول جي طور تي سمجهي سگهجي ٿو. جيڪڏهن توهان بٽ اسٽريم بابت وڌيڪ ڄاڻڻ چاهيو ٿا، توهان کي وضاحت ڪرڻ گهرجي ITU H.264. ھتي ھڪڙو ميڪرو ڊراگرام آھي ڏيکاريو جتي تصوير ڊيٽا آھي (يو يو وي compressed فارم ۾).
ٻيا بٽ اسٽريم جاچ ڪري سگهجن ٿا، جهڙوڪ VP9, H.265 (HEVC) يا اڃا به اسان جو نئون بهترين بٽ اسٽريم AV1. ڇا اهي سڀ هڪجهڙا آهن؟ نه، پر هڪ دفعو توهان گهٽ ۾ گهٽ هڪ کي سمجهي، باقي سمجهڻ تمام آسان آهي.
مشق ڪرڻ چاهيو ٿا؟ H.264 بٽ اسٽريم جي ڳولا ڪريو
توھان ٺاھي سگھوٿا ھڪڙو فريم وڊيو ۽ استعمال ڪري سگھوٿا MediaInfo بٽ اسٽريم کي جانچڻ لاءِ H.264. حقيقت ۾، ڪجھ به توهان کي روڪڻ کان روڪي ٿو ماخذ ڪوڊ کي ڏسڻ کان جيڪو بٽ وهڪرو جو تجزيو ڪري ٿو H.264 (AVC).
مشق لاء، توهان استعمال ڪري سگهو ٿا Intel Video Pro Analyzer (ڇا مون اڳ ۾ ئي چيو آهي ته پروگرام ادا ڪيو ويو آهي، پر 10 فريم جي حد سان مفت آزمائشي نسخو آهي؟).
جو جائزو
نوٽ ڪريو ته ڪيترائي جديد ڪوڊيڪس ساڳيا ماڊل استعمال ڪن ٿا جيڪو اسان صرف اڀياس ڪيو. هتي، اچو ته وڊيو ڪوڊيڪ جي بلاڪ ڊراگرام تي هڪ نظر وٺو کان وٺي. اهو سڀني مرحلن تي مشتمل آهي جنهن مان گذري چڪا آهيون. هن پوسٽ جو سڄو نقطو گهٽ ۾ گهٽ توهان کي هن علائقي ۾ جدت ۽ دستاويزن جي بهتر سمجهه ڏيڻ آهي.
اڳي، اهو حساب ڪيو ويو ته 139 GB ڊسڪ اسپيس جي ضرورت پوندي هڪ وڊيو فائل کي ذخيرو ڪرڻ لاء هڪ ڪلاڪ 720p معيار ۽ 30 fps تي. جيڪڏهن توهان هن مضمون ۾ بحث ڪيل طريقا استعمال ڪندا آهيو (انٽر فريم ۽ اندروني اڳڪٿيون، تبديلي، مقدار، اينٽراپي ڪوڊنگ، وغيره)، ته پوء توهان حاصل ڪري سگهو ٿا (حقيقت جي بنياد تي ته اسان 0,031 بٽ في پکسل خرچ ڪندا آهيون)، ڪافي وڊيو اطمينان بخش معيار، صرف 367,82 MB تي قبضو ڪندي، ميموري جي 139 GB نه.
H.265 H.264 کان بهتر ڪمپريشن تناسب ڪيئن حاصل ڪري ٿو؟