أساسيات الشبكات ضغط الفيديو والصوت في شبكات طرف إلى طرف الحاسوبية

سنتعرف في هذا المقال على كيفية ضغط كل من الفيديو والصوت في شبكات طرف إلى طرف الحاسوبية.

ضغط الفيديو باستخدام MPEG

نوجّه انتباهنا الآن إلى صيغة MPEG، التي سُميت على اسم مجموعة خبراء الصور المتحركة Moving Picture Experts Group الذين عرّفوها. إن الصورة المتحركة أي الفيديو هي ببساطة سلسلةٌ متعاقبة من الصور الثابتة، وتسمى أيضًا إطارات frames أو صور pictures، تُعرض بمعدلٍ معين للفيديو. يمكن ضغط كل إطار من هذه الإطارات باستخدام نفس التقنية المُعتمِدة على DCT والمُستخدمة في JPEG، ولكن قد يكون التوقف عند هذه النقطة خطأ لأنها تفشل في إزالة التكرار بين الإطارات الموجودة في تسلسل فيديو، حيث سيحتوي إطاران متتاليان من الفيديو على معلومات متطابقة تقريبًا على سبيل المثال إذا لم يكن هناك الكثير من الحركة في المشهد، لذلك لن يكون من الضروري إرسال نفس المعلومات مرتين. قد يكون هناك الكثير من التكرار لأن الجسم المتحرك قد لا يتغير من إطارٍ إلى آخر حتى في حالة وجود حركة، حيث يتغير موقعه فقط في بعض الحالات. يأخذ MPEG هذا التكرار بين الإطارات في الحسبان، ويحدد MPEG أيضًا آليةً لتشفير إشارة صوتية بالفيديو، ولكننا سنهتم بجانب الفيديو من MPEG فقط في هذا القسم.

أنواع الإطارات

يأخذ MPEG سلسلةً من إطارات الفيديو على أنها مدخلات ويضغطها في ثلاثة أنواع من الإطارات: إطارات I للدلالة على داخل الصورة intrapicture، وإطارات P للدلالة على صورة متوقعة predicted picture، وإطارات B أي صورة متوقعة ثنائية الاتجاه bidirectional predicted picture، ويُضغَط كل إطار دخلٍ ضمن أحد أنواع الإطارات الثلاثة هذه. يمكن عدُّ الإطاراتI بمثابة إطاراتٍ مرجعية reference frames؛ فهي مستقلة ذاتيًا ولا تعتمد على الإطارات السابقة ولا على الإطارات اللاحقة. إطار I هو ببساطة نسخة JPEG مضغوطة من الإطار المقابل في مصدر الفيديو. إطارات P وB غير مستقلة ذاتيًا، أي أنها تحدد الاختلافات النسبية مع بعض الإطارات المرجعية. يحدد الإطار P الاختلافات عن الإطار I السابق، بينما يحقق الإطار B استكمالًا بين الإطارات I أو P السابقة واللاحقة.

يوضح الشكل السابق سلسلةً من سبعة إطارات فيديو ينتج عنها سلسلةٌ من إطارات I وP وB بعد ضغطها بواسطة MPEG. الإطاران الأولان منفصلان أي يمكن فك ضغط كلٍ منهما في جهاز الاستقبال بصورة مستقلة عن أي إطاراتٍ أخرى. يعتمد الإطار P على الإطار I السابق أي لا يمكن فك ضغطه في جهاز الاستقبال إلا إذا وصل إطار I السابق أيضًا، ويعتمد كل إطارٍ من إطارات B على كلٍّ من الإطار I أو P السابق والإطار I أو P اللاحق. يجب أن يصل كلا الإطارين المرجعيين إلى جهاز الاستقبال قبل أن يتمكن MPEG من فك ضغط الإطار B لإعادة إنتاج إطار الفيديو الأصلي.

بما أن كل إطار B يعتمد على إطارٍ لاحق في السلسلة، لذلك لا تُرسَل الإطارات المضغوطة بترتيبٍ تسلسلي، وتُرسل بدلًا من ذلك السلسلة I B B P B B I الموضحة في الشكل السابق على أنها I P B B I B B. لا تحدد MPEG نسبة إطارات I إلى إطارات P وB، فقد تختلف هذه النسبة تبعًا للضغط المطلوب وجودة الصورة، حيث يمكن نقل إطارات I فقط على سبيل المثال. سيكون هذا مشابهًا لاستخدام JPEG لضغط الفيديو.

تركز المناقشة التالية على فك تشفير تدفق MPEG على عكس مناقشة JPEG السابقة لسهولة وصفها، وهي العملية التي تُطبَّق غالبًا في أنظمة الشبكات اليوم، لأن تشفير MPEG مكلفٌ للغاية لدرجة أنه يُجرَى بصورةٍ متكررة دون اتصال أي ليس في الوقت الحقيقي. يُشفَّر الفيديو ويُخزَّن على القرص الصلب قبل الوقت المحدد في نظام الفيديو عند الطلب video-on-demand system على سبيل المثال، ويُنقَل تدفق MPEG إلى جهاز المشاهد عندما يرغب المشاهد في مشاهدة الفيديو، ثم يفك جهاز المشاهد تشفير هذا التدفق ويعرضه في الوقت الحقيقي.

دعنا نلقي نظرةً عن كثب على أنواع الإطارات الثلاثة. إن إطارات I تساوي تقريبًا إصدار JPEG لضغط الإطار المصدر source frame، والاختلاف الرئيسي هو أن MPEG تعمل في وحدات كتلٍ كبيرة macroblocks بأبعاد 16 × 16. تُقسَم مكونات U وV في كل كتلة كبيرة macroblock إلى كتلة 8 × 8 ضمن فيديو ملون ممثَّلٍ في YUV، كما ناقشنا سابقًا ضمن سياق JPEG. تُعطَى كل كتلة فرعية 2 × 2 ضمن كتلةٍ كبيرة بقيمة U واحدة وقيمة V واحدة وهي متوسط قيم البكسلات الأربعة، ويبقى للكتلة الفرعية أربع قيم Y. يوضح الشكل التالي العلاقة بين الإطار والكتل الكبيرة المقابلة.

تُعالَج الإطارات P وB أيضًا في وحدات من الكتل الكبيرة. يمكننا أن نرى أن المعلومات التي تحملها الإطارات لكل كتلةٍ كبيرة تلتقطُ الحركة في الفيديو، أي أنها توضّح في أي اتجاهٍ وإلى أي مدى تحركت الكتلة الكبيرة بالنسبة للإطار أو الإطارات المرجعية. فيما يلي وصفٌ لكيفية استخدام إطار B لإعادة بناء إطارٍ أثناء فك الضغط، حيث يجري التعامل مع إطارات P بطريقةٍ مماثلة، باستثناء أنها تعتمد على إطارٍ مرجعي واحدٍ فقط بدلًا من اثنين.

نلاحظ أولًا قبل الوصول إلى تفاصيل كيفية فك ضغط إطار B أن كل كتلةٍ كبيرة في إطار B ليست بالضرورة معرّفةً بالنسبة إلى كل إطارٍ سابقٍ ولاحق، ولكن يمكن بدلًا من ذلك تحديده بالنسبة لإطارٍ سابقٍ فقط أو إطارٍ لاحق. يمكن لكتلةٍ كبيرة معينة في إطار B أن تستخدم نفس التشفير الداخلي كما هو مستخدَمٌ في إطار I. تتوفر هذه المرونة لأنه إذا تغيرت الصورة المتحركة بسرعةٍ كبيرة، فمن المنطقي أحيانًا تكريس تشفيرٍ داخل الصورة بدلًا من تشفيرٍ متوقَّعٍ أمامي أو خلفي. وبالتالي تشتمل كل كتلةٍ كبيرةٍ في إطار B على حقل نوعٍ يشير إلى التشفير المستخدم في كتلةٍ كبيرة، لكن لن نناقش في المناقشة التالية إلّا الحالة العامة التي تستخدم فيها الكتلةُ الكبيرة التشفيرَ المتوقَّع ثنائي الاتجاه.

تُمثَّل كل كتلةٍ كبيرة في إطار B في مثل هذه الحالة ضمن صفٍ ذو 4 عناصر 4tuple هي:

1. إحداثيات الكتلة الكبيرة في الإطار.
2. متجّه حركةٍ متعلقٌّ بالإطار المرجعي السابق.
3. متجّه حركة متعلقٌ بالإطار المرجعي اللاحق.
4. دلتا δ لكل بكسلٍ في الكتلة الكبيرة وهي مقدار تغير كل بكسلٍ بالنسبة إلى البكسلين المرجعيَّين.

تتمثل المهمة الأولى لكل بكسل في الكتلة الكبيرة في العثور على البكسل المرجعي المقابل في الإطارات المرجعية السابقة والمستقبلية، وذلك باستخدام متجهي الحركة المرتبطين بالكتلة الكبيرة. يُضاف بعد ذلك دلتا البكسل إلى متوسط هذين البيكسلين المرجعيين، أي إذا افترضنا أن F_p و F_f يشيران إلى الإطارات المرجعية السابقة والمستقبلية على التوالي، وتُعطَى متجّهات الحركة السابقة / المستقبلية بواسطة (x_p, y_p) و(x_f, y_f)، يُحسَب البكسل ذو الإحداثيات (x,y) في الإطار الحالي والمشار إليه F_c كما يلي:

Fc(x,y)=(Fp(x+xp,y+yp)+Ff(x+xf,y+yf))/2+δ(x,y)

حيث δ هي دلتا البكسل كما هو محدَّد في الإطار B. تُشفَّر دلتا بنفس طريقة تشفير البكسلات في إطارات I؛ أي تخضع لعملية DCT ثم تُكمم. تكون قيمة دلتا عادةً صغيرة، لذلك فإن معظم معاملات DCT تكون 0 بعد التكميم وبالتالي يمكن ضغطها بفعالية.

يجب أن يكون واضحًا إلى حدٍ ما من المناقشة السابقة كيفية تنفيذ التشفير، مع استثناءٍ واحد وهو أنه يجب أن يقرر MPEG مكان وضع الكتل الكبيرة عند إنشاء إطار B أو P أثناء الضغط. تذكر أن كل كتلةٍ كبيرة في إطار P معرَّفةٌ اعتمادًا على كتلةٍ كبيرة في إطار I على سبيل المثال، ولكن لا يلزم أن تكون الكتلة الكبيرة في الإطار P في نفس الجزء من الإطار مثل الكتلة الكبيرة المقابلة في الإطار I، حيث يُعطى الفرق في الموضع بواسطة متجه الحركة. قد ترغب في اختيار متجه الحركة الذي يجعل كتلة كبيرةً في الإطار P مشابهةً قدر الإمكان للكتلة الكبيرة المقابلة في الإطار I، بحيث يمكن أن تكون قيم دلتا لتلك الكتلة الكبيرة صغيرةً قدر الإمكان. هذا يعني أنك بحاجة إلى معرفة مكان انتقال الكائنات في الصورة من إطارٍ إلى آخر، وتُعرف هذه المشكلة باسم تقدير الحركة motion estimation. هناك العديد من التقنيات المعروفة مثل الاستدلال heuristics لحل هذه المشكلة. صعوبة هذه المشكلة هي أحد الأسباب التي تجعل تشفير MPEG يستغرق وقتًا أطول من فك التشفير على عتادٍ متكافئ. لا تحدد MPEG أي تقنيةٍ معينة، إنما تحدد فقط صيغة تشفير هذه المعلومات في الإطارات B وP وخوارزمية إعادة بناء البكسلات أثناء فك الضغط.

قياس الفعالية Effectiveness والأداء

تحقق MPEG عادةً نسبة ضغط تبلغ 90:1، على الرغم من أن النسب التي تصل إلى 150:1 معروفة سابقًا. فيما يتعلق بأنواع الإطارات الفردية، يمكننا أن نتوقع نسبة ضغطٍ تبلغ حوالي 30:1 للإطارات I وهذا يتوافق مع النسب المُحقَّقة باستخدام JPEG عند تقليل لون 24 بت أولاً إلى لون 8 بت، بينما تكون نسب ضغط الإطارات P وB عادةً ثلاث إلى خمس مرات أصغر من معدلات ضغط الإطار I. يكون الضغط المُحقق باستخدام MPEG عادةً بين 30:1 و50:1 بدون تقليل 24 بت من اللون إلى 8 بت أولًا.

تتضمن MPEG عمليةً حسابيةً باهظة الثمن. يُجرَى الضغط عادةً في وضع عدم الاتصال، وليس ذلك مشكلةً عند إعداد الأفلام لخدمة الفيديو عند الطلب. يمكن ضغط الفيديو في الوقت الحقيقي باستخدام العتاد اليوم، ولكن تطبيقات البرامج تسد الفجوة بسرعة. أما من ناحية فك الضغط، تتوفر لوحات فيديو MPEG منخفضة التكلفة، لكنها تفعل أكثر من مجرد البحث عن ألوان YUV، والتي لحسن الحظ هي الخطوة الأكثر تكلفةً، وتحدث معظم عمليات فك تشفير MPEG الفعلية ضمن البرامج. أصبحت المعالجات في السنوات الأخيرة سريعةً بما يكفي لمواكبة معدلات الفيديو عند 30 إطارًا في الثانية لدى فك تشفير تدفقات MPEG في البرامج فقط، كما يمكن للمعالجات الحديثة فك تشفير تدفقات MPEG للفيديو عالي الوضوح high definition video أو اختصارًا HDTV.

معايير تشفير الفيديو

إن MPEG هو معيار معقدٌ، ويأتي هذا التعقيد من الرغبة في منح خوارزمية التشفير كل درجةٍ ممكنةٍ من الحرية في كيفية تشفيرها لتدفق فيديو معين، مما يؤدي إلى معدلات نقل فيديو مختلفة، ويأتي أيضًا من تطور المعيار مع مرور الوقت، حيث تعمل مجموعة Moving Picture Experts Group جاهدةً للاحتفاظ بالتوافق مع الإصدارات السابقة مثل MPEG-1 وMPEG-2 وMPEG-4. ستُوصف في هذه السلسلة الأفكار الأساسية الكامنة وراء الضغط المستند إلى MPEG، ولكن بالتأكيد ليس كل التعقيدات التي ينطوي عليها معيارٌ دولي.

ليس MPEG المعيار الوحيد المتاح لتشفير الفيديو، حيث حدد اتحاد ITU-T أيضًا سلسلة H لتشفير بيانات الوسائط المتعددة في الوقت الحقيقي على سبيل المثال. تتضمن سلسلة H معاييرًا للفيديو والصوت والتحكم وتعدد الإرسال مثل مزج الصوت والفيديو والبيانات في تدفق بتاتٍ واحد. كان H.261 وH.263 معيارَي الجيل الأول والثاني ضمن هذه السلسلة لتشفير الفيديو. يشبه كلٌّ من H.261 وH.263 كثيرًا MPEG من حيث المبدأ؛ فهما يستخدمان DCT والتكميم والضغط بين الإطارات.

أدت اليوم الشراكة بين ITU-T ومجموعة MPEG إلى معيار H.264 / MPEG-4 المشترك، والذي يستخدمه كلٌّ من الأقراص الضوئية عالية السعة Blu-ray Discs والعديد من مصادر البث الشائعة مثل YouTube وVimeo.

إرسال MPEG عبر شبكة

لا تعد MPEG وJPEG معايير ضغط فحسب، ولكنها أيضًا تعريفاتٌ لصيغ الفيديو والصور على التوالي. إن أول شيءٍ يجب مراعاته مع MPEG هو أنه يحدد صيغة تدفق الفيديو ولا يحدد كيفية تقسيم هذا التدفق إلى رزم شبكة، وبالتالي يمكن استخدام MPEG لمقاطع الفيديو المخزنة على القرص، وكذلك مقاطع الفيديو المنقولة عبر اتصال شبكة موجهٍ بالتدفق، مثل تلك التي يوفرها بروتوكول TCP.

ما سنشرحه أدناه يُسمى ملف التعريف الرئيسي main profile لتدفق فيديو MPEG مُرسَل عبر شبكة. يمكنك التفكير في ملف تعريف MPEG على أنه مشابهٌ "لإصدارٍ version" باستثناء عدم تحديد ملف التعريف صراحةً في ترويسة MPEG، حيث يجب على المستقبل استنتاج ملف التعريف من مجموعة حقول الترويسات التي يراها.

يحتوي تدفق MPEG للملف التعريفي الرئيسي على بنيةٍ متداخلةٍ كما هو موضح في الشكل السابق الذي يخفي الكثير من التفاصيل الفوضوية. يحتوي الفيديو في المستوى الخارجي على سلسلةٍ من مجموعات الصور GOP مفصولةٍ بواسطة SeqHdr. تُنهَى السلسلة بواسطة SeqEndCode الذي هو 0xb7. يحدد SeqHdr الذي يسبق كل مجموعة GOP، من بين أشياءٍ أخرى، حجمَ كل صورةٍ أو إطارٍ في مجموعة الصور ويُقاس بالبكسلات والكتل الكبيرة؛ وفترة بين الصور وتقاس بالميكرو ثانية؛ ومصفوفتي تكميم للكتل الكبيرة داخل هذه GOP، الأولى هي مصفوفةٌ للكتل الكبيرة داخل التشفير أي كتل I، والأخرى للكتل الكبيرة أي كتل B وP. بما أنه يجري تقديم هذه المعلومات لكل مجموعة GOP بدلًا من مرةٍ واحدة لتدفق الفيديو بأكمله، فمن الممكن تغيير جدول التكميم ومعدل الإطارات عند حدود GOP خلال الفيديو، وهذا يجعل من الممكن تكييف تدفق الفيديو بمرور الوقت كما سنناقش أدناه.

تُمثَّل كل مجموعةٍ GOP بواسطة GOPHdr متبوعًا بمجموعة الصور التي تشكل GOP. يحدد GOPHdr عدد الصور في GOP، إضافةً إلى معلومات مزامنة GOP أي وقت تشغيل GOP بالنسبة إلى بداية الفيديو. تُمثَّل كل صورةٍ بدورها بواسطة PictureHdr ومجموعةٍ من الشرائح slices التي تشكّل الصورة، حبث تشير الشريحة إلى منطقةٍ من الصورة مثل خط أفقي واحد. يحدد PictureHdr نوع الصورة إذا كانت I أو B أو P وجدول تكميمٍ خاصٍ بالصورة. يعطي SliceHdr الوضع الشاقولي للشريحة، بالإضافة إلى فرصةٍ أخرى لتغيير جدول التكميم وهذه المرة بواسطة عامل قياسٍ ثابت بدلًا من إعطاء جدولٍ جديد بالكامل، ثم يُتبع SliceHdr بسلسلةٍ من الكتل الكبيرة. أخيرًا، تتضمن كل كتلةٍ كبيرةٍ ترويسةً تحدد عنوان الكتلة داخل الصورة، جنبًا إلى جنب مع البيانات الخاصة بالكتل الست داخل الكتلة الكبيرة، وهي كتلة للمكون U، وكتلة للمكون V، وأربع كتل للمكون Y. تذكر أن المكون Y هو 16 × 16، بينما المكونان U وV هما 8 × 8.

يجب أن يكون واضحًا أن إحدى صلاحيات صيغة MPEG هي منح المشفِّر فرصةً لتغيير التشفير بمرور الوقت، فيمكنها تغيير معدل الإطارات، والدقة، ومزيجٌ من أنواع الإطارات التي تحدد GOP، وجدول التكميم، والتشفير المُستخدَم للكتل الكبيرة الفردية؛ لذلك من الممكن تكييف معدل نقل الفيديو عبر الشبكة عن طريق تداول جودة الصورة لحيز النطاق التراسلي للشبكة. إن كيفية استغلال لبروتوكول الشبكة لهذه القدرة على التكيف هو موضوع بحثٍ حاليًا.

جانبٌ آخر مهمٌ لإرسال تدفق MPEG عبر الشبكة هو كيفية تقسيم التدفق إلى رزم، فإذا كان الإرسال عبر اتصال TCP، فلا تُعد الرزم مشكلةً، حيث يقرر TCP متى يكون لديه عدد كافٍ من البايتات لإرسال مخطط بيانات IP التالي. لكن من النادر نقل الفيديو المُستخدَم بصورةٍ تفاعلية عبر بروتوكول TCP، نظرًا لأن TCP يحتوي على العديد من الميزات التي لا تناسب التطبيقات شديدة الحساسية لوقت الاستجابة مثل التغيرات المفاجئة في المعدل بعد فقدان الرزمة وإعادة إرسال الرزم المفقودة. إذا نقلنا الفيديو باستخدام بروتوكول UDP على سبيل المثال، فمن المنطقي كسر التدفق في نقاطٍ محددة بعناية مثل حدود الكتل الكبيرة، لأننا نرغب في قصر تأثيرات الرزمة المفقودة على كتلةٍ كبيرة واحدة، بدلًا من إتلاف العديد من الكتل الكبيرة مع خسارةٍ واحدة. يُعد هذا مثالًا عن تأطير مستوى التطبيق Application Level Framing.

يُعد تقسيم التدفق إلى رزم Packetizing المشكلة الأولى فقط في إرسال فيديو مضغوط بصيغة MPEG عبر شبكة، والمضاعفات التالية هي التعامل مع فقدان الرزم. إذا أسقطت الشبكة إطار B، فمن الممكن ببساطة إعادة تشغيل الإطار السابق دون المساس بالفيديو كثيرًا، فليس إسقاط إطارٍ 1 من بين 30 إطارًا مشكلةً كبيرة. إن فقدان الإطار I له عواقب وخيمة، حيث لا يمكن معالجة أي من الإطارات B وP اللاحقة بدونه، وبالتالي قد يؤدي فقدان إطار I إلى فقدان إطارات متعددة من الفيديو. يمكنك إعادة إرسال الإطار I المفقود، ولكن قد لا يكون التأخير الناتج مقبولًا في مؤتمر الفيديو في الوقت الحقيقي. قد يكون أحد الحلول لهذه المشكلة هو استخدام تقنيات الخدمات المميزة الموضحة في المقال السابق لتمييز الرزم التي تحتوي على إطارات I مع احتمال إسقاطٍ أقل من الرزم الأخرى.

تعتمد الطريقة التي تختار بها تشفير الفيديو على أكثر من مجرد حيز النطاق التراسلي للشبكة المتاح، كما تعتمد أيضًا على قيود وقت استجابة للتطبيق. يحتاج تطبيق تفاعلي مثل مؤتمرات الفيديو إلى وقت استجابةٍ صغير. العامل الحساس هو الجمع بين إطارات I وP وB في مجموعة الصور GOP. افترض GOP التالية:

I B B B B P B B B B I

تكمن المشكلة التي تسببها GOP في تطبيق مؤتمرات الفيديو في أنه يتعين على المرسل تأخير إرسال إطارات B الأربعة حتى يتوفر إطار P أو I الذي يليها، لأن كل إطار B يعتمد على إطار P أو I اللاحق. إذا شُغِّل الفيديو بمعدل 15 إطارًا في الثانية أي إطارٌ واحدٌ كل 67 ميلي ثانية، فهذا يعني أن أول إطار B يتأخر 4 × 67 ميلي ثانية أي أكثر من ربع ثانية، ويُضاف هذا التأخير إلى أي تأخير انتشارٍ تفرضه الشبكة. ربع ثانية أكبر بكثير من عتبة 100 ميلي ثانية التي يستطيع البشر إدراكها، لذلك تجري العديد من تطبيقات مؤتمرات الفيديو تشفيرَ الفيديو باستخدام JPEG، والتي تسمى غالبًا motion-JPEG والتي تعالج أيضًا مشكلة إسقاط إطارٍ مرجعي نظرًا لأن جميع الإطارات قادرة على الاستقلال. لاحظ مع ذلك أن تشفير بين الإطارات المُعتمد على الإطارات السابقة فقط بدلًا من الإطارات اللاحقة ليس مشكلة، وبالتالي ستعمل GOP التالية بصورةٍ جيدة لعقد مؤتمرات الفيديو التفاعلية.

I P P P P I

التدفق المتكيف Adaptive Streaming

تسمح أنظمة التشفير مثل MPEG بالمقايضة بين حيز النطاق التراسلي المستهلك وجودة الصورة، فهناك فرصة لتكييف تدفق فيديو لمطابقة حيز النطاق التراسلي للشبكة المتاح، وهذا ما تفعله خدمات بث الفيديو مثل Netflix اليوم بفعالية.

دعنا نفترض أن لدينا طريقةً ما لقياس مقدار السعة المتاحة ومستوى الازدحام على طول المسار على سبيل المثال، من خلال مراقبة معدل وصول الرزم بنجاح إلى الوجهة. يمكننا إعادة هذه المعلومات إلى برنامج التشفير بسبب تذبذب حيز النطاق التراسلي المتاح بحيث يضبُط معاملات التشفير الخاصة به للتراجع عند حدوث ازدحام، ثم الإرسال بصورةٍ أقوى وبجودة صورةٍ أعلى عندما تكون الشبكة في وضع الخمول. هذا مشابهٌ لسلوك بروتوكول TCP باستثناء حالة الفيديو، حيث نعدّل الكمية الإجمالية للبيانات المرسلة بدلًا من تعديل الوقت الذي نستغرقه لإرسال كميةٍ ثابتة من البيانات، نظرًا لأننا لا نريد إدخال تأخير في تطبيق الفيديو.

لا نكيّف التشفير سريعًا في حالة خدمات الفيديو حسب الطلب مثل Netflix، ولكن بدلًا من ذلك نشفِّر عددًا قليلًا من مستويات جودة الفيديو مسبقًا ونحفظها في الملفات المسماة وفقًا لذلك. يغيّر المستقبل ببساطة اسم الملف الذي يطلبه لمطابقة الجودة التي تشير قياساتها إلى أن الشبكة ستكون قادرة على تقديمها، ويراقب المستقبل رتل التشغيل الخاص به، ويطلب تشفيرًا عالي الجودة عندما يصبح الرتل ممتلئًا جدًا، ويطلب تشفيرًا أقل جودةً عندما يصبح الرتل فارغًا.

كيف يعرف هذا النهج المكان الذي يجب أن تتغير فيه الجودة المطلوبة لدى الانتقال إليه في الفيلم؟ لا يطلب المستقبل من المرسل تدفق الفيلم بأكمله، ولكنه يطلب بدلًا من ذلك سلسلةً من أجزاء الفيلم القصيرة، وتكون عادةً مدتها بضع ثوانٍ ودائمًا على حدود GOP. يمثل كل جزءٍ فرصةً لتغيير مستوى الجودة لمطابقة ما تستطيع الشبكة تقديمه. اتضح أن طلب مقاطع الفيلم يسهّل أيضًا تطبيق لعبةٍ خادعةٍ trick play، والانتقال من مكانٍ إلى آخر في الفيلم. يُخزَّن الفيلم عادةً على أنه مجموعةٌ من مقاطع أو ملفات بحجم N × M، حيث تشير N إلى مستويات الجودة لكل مقطعٍ من M مقطع.

يطلب المستقبل بفعاليةٍ سلسلةً من أجزاء الفيديو المنفصلة من خلال الاسم، لذلك فإن الطريقة الأكثر شيوعًا لإصدار هذه الطلبات هي استخدام بروتوكول HTTP. كل جزءٍ هو طلب HTTP GET منفصل مع عنوان URL يميّز الجزء المحدد الذي يريده المستقبل لاحقًا. ينزّل مشغل الفيديو عندما تبدأ في تنزيل فيلم ملف بيان manifest أولًا، وهو ملفٌ لا يحتوي على أكثر من عناوين URL لمقاطع N × M في الفيلم، ثم يصدر سلسلةً من طلبات HTTP باستخدام عنوان URL المناسب. يُطلق على هذا النهج العام بث HTTP التكيُّفي HTTP adaptive streaming، على الرغم من توحيده بطرقٍ مختلفة قليلًا بواسطة مؤسساتٍ مختلفة مثل MPEG's DASH اختصارًا إلى التدفق الديناميكي التكيفي عبر HTTP أو Dynamic Adaptive Streaming over HTTP وApple’s HLS اختصارًا إلى بث HTTP المباشر HTTP Live Streaming.

ضغط الصوت باستخدام MP3

لا يحدد MPEG كيفية ضغط الفيديو فحسب، بل يحدد أيضًا معيارًا لضغط الصوت. يمكن استخدام هذا المعيار لضغط الجانب الصوتي للفيلم، حيث يحدد معيار MPEG في هذه الحالة كيفية تشابك الصوت المضغوط مع الفيديو المضغوط في تدفق MPEG واحد، أو يمكن استخدامه لضغط الصوت المستقل (قرص صوتي مضغوط على سبيل المثال). يُعد معيار ضغط الصوت MPEG واحدًا فقط من بين العديد من معايير ضغط الصوت، ولكن الدور المحوري الذي لعبه يعني أن MP3 (الذي يرمز إلى معيار MPEG بالطبقة الثالثة MPEG Layer III) أصبح مرادفًا تقريبًا لضغط الصوت.

نحتاج أن نبدأ بالبيانات لفهم ضغط الصوت. تُؤخَذ عينات الصوت بجودة القرص المضغوط، وهو التمثيل الرقمي الفعلي للصوت عالي الجودة، بمعدل 44.1 كيلو هرتز أي تُجمَع عينةٌ مرة واحدة تقريبًا كل 23 ميكرو ثانية. تتكون كل عينة من 16 بتًا، مما يعني أنه سينتج عن تدفق صوت ستيريو ثنائي القناة معدل بت يساوي:

2 × 44.1 × 1000 × 16 = 1.41 Mbps

وتُؤخذ بالمقابل عينات صوت بجودة الهاتف التقليدية بمعدل 8 كيلو هرتز، مع عيناتٍ بحجم 8 بتات، مما ينتج عنه معدل بت 64 كيلو بت في الثانية.

من الواضح أنه لا بد من تطبيق قدرٍ من الضغط لنقل صوتٍ بجودة القرص المضغوط عبر شبكة ذات نطاق ترددي محدود. ضع في الحسبان أن تدفق الصوت وفق المعيار MP3 مثلًا قد أصبح شائعًا في عصرٍ كانت فيه اتصالات الإنترنت المنزلية بسرعة 1.5 ميجا بت في الثانية أمرًا جديدًا، ومما جعل الأمور أسوأ أن عمليات المزامنة وتصحيح الأخطاء قد أدت إلى تضخيم عدد البتات المخزنة على قرص مضغوط بمقدار ثلاثة أضعاف، لذلك إذا قرأت للتو البيانات من القرص المضغوط وأرسلتها عبر الشبكة، فستحتاج إلى 4.32 ميجابت في الثانية. عبر خطَّي ISDN للبيانات / للصوت بسعة 128 كيلو بت في الثانية على سبيل المثال، وتتطلب المزامنة وتصحيح الخطأ استخدام 49 بتًا لتشفير كل عينةٍ مؤلفةٍ من 16 بتًا، مما ينتج عنه معدل بت فعلي يبلغ:

49/16 × 1.41 Mbps = 4.32 Mbps

يستخدم MP3 لتحقيق نسب الضغط هذه تقنياتٍ مشابهة لتلك المستخدمة مع MPEG لضغط الفيديو، حيث يقسم أولًا تدفق الصوت إلى عددٍ من نطاقات التردد الفرعية، وهو أمرٌ مشابهُ للطريقة التي يعالج بها MPEG مكونات Y وU وV لتدفق الفيديو بصورةٍ منفصلة. بعد ذلك يُقسَم كل نطاقٍ فرعي إلى سلسلةٍ من الكتل، والتي تشبه كتل MPEG الكبيرة باستثناء أنها يمكن أن تختلف في الطول من 64 إلى 1024 عينة. يمكن أن تختلف خوارزمية التشفير في حجم الكتلة اعتمادًا على تأثيرات تشويهٍ معينة تتجاوز مناقشتنا. أخيرًا، تُحوَّل كل كتلةٍ باستخدام تعديل وتكميم خوارزمية DCT وتشفير هوفمان Huffman تمامًا مثل فيديو MPEG.

تكمن الحيلة في MP3 في عدد النطاقات الفرعية التي يختار استخدامها وعدد البتات التي يخصصها لكل نطاقٍ فرعي، مع الأخذ في الحسبان محاولة إنتاج أعلى جودة صوت ممكنة لمعدل البت المستهدَف. تخضع كيفية إجراء هذا التخصيص لنماذج صوتية نفسية خارج نطاق هذه السلسلة، ولكن لتوضيح الفكرة ضع في الحسبان أنه من المنطقي تخصيص المزيد من البتات للنطاقات الفرعية منخفضة التردد عند ضغط صوت ذكر والمزيد من البتات للنطاقات الفرعية عالية التردد عند ضغط صوت أنثى. يغيّر MP3 ديناميكيًا جداول التكميم المستخدمة لكل نطاقٍ فرعي لتحقيق التأثير المطلوب.

تُحزَم النطاقات الفرعية في إطاراتٍ ذات حجمٍ ثابت مع إرفاق الترويسة بعد الضغط. تتضمن هذه الترويسة معلومات التزامن، بالإضافة إلى معلومات تخصيص البتات التي يحتاجها جهاز فك التشفير لتحديد عدد البتات المستخدمة لتشفير كل نطاقٍ فرعي. يمكن بعد ذلك إدخال إطارات الصوت هذه مع إطارات فيديو لتكوين تدفق MPEG كامل. تعلمنا التجربة أنه ليس من الجيد إسقاط الإطارات الصوتية لأن المستخدمين أكثر قدرة على تحمل الفيديو السيئ من الصوت السيء على الرغم من إسقاط إطارات B في الشبكة في حالة حدوث ازدحام.

منظور البيانات الضخمة والتحليلات

تدور هذه الجزئية من السلسلة حول البيانات، وبما أنه لا يوجد موضوعٌ في علوم الحاسوب يحظى باهتمامٍ أكبر من البيانات الضخمة big data أو تحليل البيانات data analytics، فإن السؤال الطبيعي هو ما هي العلاقة التي قد تكون بين البيانات الضخمة وشبكات الحاسوب. تستخدم الصحافة هذا المصطلح غالبًا بصورةٍ غير رسمية إلا أن التعريف العملي له بسيطٌ للغاية، حيث تُجمَّع بيانات جهاز الاستشعار من خلال مراقبة بعض الأنظمة الفيزيائية أو أنظمة من صنع الإنسان ثم تُحلَّل للحصول على رؤيةٍ باستخدام الأساليب الإحصائية للتعلُّم الآلي. تكون كمية البيانات الأولية التي يجري جمعها ضخمة غالبًا، لذلك نستخدم الصفة big. إذًا، هل هناك أي آثار على الشبكات؟

صُممت الشبكات في البداية لتكون حياديةً بالنسبة للبيانات، فإذا جمعتها ورغبت في نقلها إلى مكانٍ ما لتحليلها، فستكون الشبكة سعيدةً لفعل ذلك نيابةً عنك. يمكنك ضغط البيانات لتقليل حيز النطاق التراسلي المطلوب لنقلها، ولكن بخلاف ذلك لا تختلف البيانات الضخمة عن البيانات القديمة العادية، ولكن ذلك يتجاهل عاملين مهمين هما:

العامل الأول هو أنه في حين أن الشبكة لا تهتم بمعنى البيانات أي ما تمثله البتات، فإنها تهتم بحجم البيانات. يؤثر هذا على شبكة الوصول access network خاصةً، والتي صُمِّمت لتفضيل سرعات التنزيل على سرعات التحميل. يكون هذا التحيُّز منطقيًا عندما تكون حالة الاستخدام السائدة هي الفيديو المُتدفق إلى المستخدمين النهائيين، ولكن يجري العكس في عالمٍ تُبلِّغ فيه سيارتك وكل جهازٍ في منزلك والطائرات بدون طيار التي تحلق فوق مدينتك عن البيانات إلى الشبكة أي تُحمَّل إلى السحابة cloud، كما يمكن أن تكون كمية البيانات التي تولّدها المركبات الذاتية وإنترنت الأشياء Internet-of-Things أو اختصارًا IoT هائلة.

يمكنك أن تتخيل التعامل مع هذه المشكلة باستخدام إحدى خوارزميات الضغط، ولكن الناس يفكرون بأفكارٍ خارج الصندوق بدلًا من ذلك ويتابعون تطبيقاتٍ جديدة موجودة على حافة الشبكة. توفر تطبيقات الحافة الأصلية edge-native applications وقت استجابةٍ أقل من جزءٍ من ميلي ثانية وتقلل كثيرًا من حجم البيانات المطلوب تحميلها في النهاية إلى السحابة. يمكنك التفكير في تقليل البيانات هذا على أنه ضغطٌ خاصٌ بالتطبيق، ولكن من الأدق القول إن تطبيق الحافة يحتاج فقط إلى كتابة ملخصات للبيانات غير البيانات الأولية إلى السحابة.

أحد الأمثلة عن تطبيقات الحافة الأصلية هو رغبة الشركات في مجال السيارات والمصانع والمستودعات بصورةٍ متزايدة في نشر شبكات 5G الخاصة بمجموعةٍ متنوعةٍ من حالات استخدام الأتمتة الفيزيائية. يتضمن هذا التطبيق مرآبًا يركن فيه خادمٌ خاص سيارتك عن بعد أو أرضية مصنع تستخدم روبوتات التشغيل الآلي. الموضوع المشترك هو حيز النطاق التراسلي العالي، والاتصال بوقت استجابةٍ منخفض من الروبوت إلى الذكاء الموجود في مكانٍ قريب في سحابة موجودة على الحافة edge cloud. يؤدي هذا إلى خفض تكاليف الروبوت، حيث لا تحتاج إلى وضع حسابات ثقيلة على كلٍ منها، ويتيح ذلك أيضًا تمكين مجموعة روبوتات مع تنسيقٍ أكثر قابلية للتوسع.

المثال الآخر هو جهاز المساعدة المعرفيّة القابلة للارتداء Wearable Cognitive Assistance. تكمن الفكرة في تعميم ما يفعله برنامج الملاحة لنا، فهو يستخدم مستشعر GPS ويعطينا إرشاداتٍ خطوةً بخطوة حول مهمةٍ معقدة مثل التجول في مدينةٍ غير معروفة، ويكتشف أخطائنا على الفور ويساعدنا للرجوع عن الخطأ. هل يمكننا تعميم هذا؟ هل يمكن توجيه شخص يرتدي جهازًا مثل Google Glass وMicrosoft Hololens خطوةً بخطوة في مهمةٍ معقدة؟ سيعمل النظام بفعالية "مثل الملاك الموجود على كتفيك ومرشدٍ لك". تُبَث جميع المستشعرات الموجودة على الجهاز مثل الفيديو والصوت ومقياس التسارع والجيروسكوب gyroscope عبر شبكةٍ لاسلكية (ربما بعد معالجةٍ مسبَقةٍ للجهاز) إلى سحابةٍ طرفيةٍ قريبة تتحمّل الحِمل الثقيل. يشبه ذلك إنسانًا ضمن حلقة، مع "شكل وإحساس الواقع المعزَّز augmented reality" ولكنه يُطبَّق بواسطة خوارزميات الذكاء الاصطناعي مثل الرؤية الحاسوبية والتعرف على اللغات الطبيعية.

العامل الثاني هو أنه بما أن الشبكة تشبه العديد من الأنظمة الأخرى التي صنعها الإنسان، فمن الممكن جمع البيانات حول سلوكها مثل الأداء والفشل وأنماط حركة المرور، وتطبيق برامج التحليلات على تلك البيانات، واستخدام الأفكار المكتسبة من أجل تحسين الشبكة. لا ينبغي أن يكون مفاجئًا أن هذا مجال بحثٍ نشط، بهدف بناء حلقة تحكمٍ مغلقة. بغض النظر عن التحليلات نفسها، والتي هي خارج نطاق هذه السلسلة، فإن الأسئلة المهمة هي:

1. ما هي البيانات المفيدة التي يمكننا جمعها؟
2. ما هي جوانب الشبكة التي يمكن التحكم فيها؟

دعنا نلقي نظرةً على إجابتين واعدتين، الأولى هي شبكات الجيل الخامس الخلوية المعقدة بطبيعتها، وهي تشمل طبقاتٍ متعددة من الوظائف الافتراضية، وموجودات assets شبكة RAN الافتراضية والفيزيائية، واستخدام الطيف، وعقد الحوسبة المتطورة. من المتوقع على نطاقٍ واسع أن تصبح تحليلات الشبكة ضرورية لبناء شبكة 5G مرنة، وسيشمل ذلك تخطيط الشبكة الذي سيحتاج إلى تحديد مكان توسيع نطاق وظائف الشبكة وخدمات التطبيقات المحددة بناءً على خوارزميات التعلم الآلي التي تحلل استخدام الشبكة وأنماط بيانات حركة المرور.

تتمحور الإجابة الثانية حول القياس عن بعد للشبكة داخل النطاق In-band Network Telemetry أو اختصارًا INT، وهو إطار عملٍ لجمع حالة الشبكة والإبلاغ عنها مباشرةً في مستوى البيانات، وهذا على عكس التقارير التقليدية التي ينجزها مستوى التحكم في الشبكة. تحتوي الرزم في معمارية INT على حقول ترويسات تُفسَّر على أنها "تعليمات قياسٍ عن بُعد" من قِبل أجهزة الشبكة، حيث تخبر هذه التعليمات الجهاز الذي يدعم INT بالحالة التي يجب جمعها والكتابة في الرزمة أثناء عبورها للشبكة. يمكن لمصادر حركة مرور INT مثل التطبيقات ومكدّسات شبكة المضيف النهائي وبرامج Hypervisors VM تضمين التعليمات إما في رزم البيانات العادية أو في رزم الفحص الخاصة. وتسترجع أحواض حركة مرور INT (وتبلِّغ اختياريًا) النتائج المجمّعة لهذه التعليمات، مما يسمح لأحواض حركة المرور بمراقبة حالة مستوى البيانات الدقيقة التي "رصدتها" الرزم أثناء تمريرها. لا تزال INT في مراحلها المبكرة، وتستفيد من خطوط الأنابيب القابلة للبرمجة، ولكن لديها القدرة على توفير رؤىً أعمق نوعيًا لأنماط حركة المرور والأسباب الجذرية لفشل الشبكة.

اقتباس

نوصي بما يلي:

• لمعرفة المزيد حول التطبيقات الأصلية الواعدة: Open Edge Computing Initiative ،2019.
• لمعرفة المزيد حول القياس عن بعد للشبكة داخل النطاق: In-band Network Telemetry via Programmable Dataplanes، August 2015.

ترجمة -وبتصرّف- للقسم Multimedia Data من فصل End-to-End Data من كتاب Computer Networks: A Systems Approach.

اقرأ أيضًا

• بيانات شبكات طرف إلى طرف الحاسوبية
• بروتوكولات طرف إلى طرف End-to-End Protocols في الشبكات الحاسوبية
• التوجيه Routing بين الأجهزة المتنقلة في الشبكات الحاسوبية