All But Reality

Imagine a catchphrase here

Simple template. Background and Customization by Shihab Elagib. Powered by Blogger

September 28, 2015

من الخادم الى المستخدم - تحويل عمليات ضغط واعادة تشفير الصور والفيديو المرفوعة للانترنت لجانب العميل.

"لماذا يجب ان انتظر كل هذا الوقت لرفع صورة حجمها كذا ميقابايت، في حين ان الفيسبوك سيقوم بضغطها لبضع مئات من الكيلوبايتات في النهاية؟" سؤال طرحته على نفسي في يوم ما وانا -ان لم تكن قد حزرت بعد- انتظر اكتمال عملية رفع صورة ما لحسابي على الفيسبوك. 
ولكوني لست جاهلاً (كثيراً) بأمور الصوتيات والمرئيات اجبت على نفسي بنفسي: "كان بإمكانك -ببساطة- ان تضغطها لملف jpeg صغير الحجم بنفسك، عوضاً عن الاصرار على استخدام ملف png بدون ضغط يذكر!".
وهنا سألت نفسي مجدداً، اذاً لماذا لا تصبح عملية ضغط الصوتيات والمرئيات على جهة المستخدم (client-side)؟ اي ان تشمل عملية الرفع نفسها -سواءاً عن طريق المتصفح عبر اضافات ومكتبات معينة او عن طريق برامج متخصصة- عمليات ضغط واعادة تشفير؟

مبدئياً اسمحوا لي ان اوضح امراً يفترض ان يكون معلوماً لكل من القى نظرة على العامود الجانبي التعريفي للكاتب: انا لست مختصاً بالشبكات، لست مبرمجاً (محترفاً) ولست مدير نظم حواسيب. فقط  "منظراتي"!
وعليكم الله، ركزوا مع الفرق بين الـ  "بِت  " والـ  " بايت  "!

عندما طرحت هذا السؤال على الفيسبوك، رد احد اصدقائي ان السبب ربما يكون التأثير السلبي على الاداء والزمن بالنسبة للمستخدم. حينها قمت بتجربة عملية سريعة للتأكد من مدى سؤ هذا التأثير كان نتيجتها ان تطبيق ضغط الصور على جانب المستخدم ربما يكون اكثر كفاءة من العكس! السبب -ببساطة- ان "عنق الزجاجة" في هذه العملية ليست قدرة المعالجة المتوفرة للمستخدم بقدر ما هي الباندويدث المتاح للإتصال بالإنترنت. ولتوضيح الفكرة اكثر قمت بإعادة التجربة والحسابات بصورة اقرب مماثلة لأرض الواقع.

في التجربة المبدئية كنت قد استخدمت صورة png كبيرة قمت بإعدادها بنفسي. اما عملية الضغط فتمت على معالج Core i7 4770k، وان لم يكن اسرع معالج متوفر حالياً، الا انه لا يزال اعلى بكثير من ما يمكن اعتباره متاحاً لعموم المستخدمين. 

هذه المرة قمت بتجربة الضغط بصورة اكثر دقة، استخدمت صورتين التقطتهما بواسطة هاتفي المحمول وقمت بضغطهما على معالج Core 2 Duo T6400. المعالج قديم جداً، والجهاز حالته مهترئة الصراحة، لذا لا يمكنني القول انه يعمل بكامل قدرته (او حتى نصفها للأمانة >_>)، لكن يمكن القول انه يمثل حالة worst case scenario عوضاً عن اداء جهاز متوسط. 
عملية الضغط تمت بإستخدام برنامج ScriptJPG، واختيار اعلى خيارات الضغط الممكنة فيه (والتي ليست بتلك الكفاءة، مقارنة ببرامج اخرها اكثر حرية في حذف البيانات من الصورة). الصورتين المستخدميت كليهما بصيغة .jpg، حجميهما 2732 و 3323 كيلوبايت. تم اجراء التجربة اربع مرات على كل صورة واخذ المدة الزمنية المتوسطة لكل عملية.

المدة الزمنية التي تطلبت لضغط الصورة الأولى من 2732 ك.ب الى 728 ك.ب كانت 3 ثوانٍ فقط.
 "        "      "     "       "         "     الثاتية  من 3323 ك.ب الى 641 ك.ب كانت ثانيتين فقط.

في كلا الحالتين لم يوجد فرق ظاهري بين الصورة الأصل والمضغوطة.

لننتقل الأن لحساب المدة الزمنية اللازمة لرفع صورة ما الى موقع ما مرة بدون القيام بعملية ضغط. ولنفترض (لغرض الجدل فقط) سرعة الانترنت هي متوسط الباندويدث العالمي، التي  -حسب بيانات مؤسسة اكاماي- تقدر بـ 5.1 ميقابت في الثانية.

بالنسبة للصورة الأولى، في حالة الرفع بدون اي معالجات ستتطلب العملية حوالي 4.3 ثانية. 
اما في حالة الرفع والضغط فستستهلك العملية ما مجموعه 3.1 ثانية. 
او -بلغة اخرى- فإن المدة اللازمة للرفع ستقل بنسبة 28%.

بالنسبة للصورة الثانية، فالمدتين ستكونان 5.2 ثانية و 3.0 ثانية على التوالي. او فرق 42%.

قد تبدو هذه الفروقات تافهة عندما تكون العملية الطبيعية نفسها لا تستهلك سوى بضع ثوان، لكن ما يجب اخذه في الاعتبار تلك الحالات العديدة التي ترفع فيها اكثر من صورة، وليست صورة واحدة فقط! ماذا يحدث عندما نتحدث عن رفع 4 او 5 صور؟ او ربما عن احد اراد مشاركة البوم صور مناسبة زفاف او حفل ما؟
دعك من هذا، ماذا عن من اراد رفع صورة بأحجام كبيرة كتلك الملتقطة بكاميرات احترافية بإعدادات ضغط وتشفير دنيا؟ بعضها قد تتعدى احجام الصورة الواحدة فيها ال10 ميقابايت! بإفتراض انها لم تلتقط raw وتحول لاحقاً لصيغ اقل سماحية في الضغط مثل الpng او الbmp (بتجاهل باقي الاسماء، بما ان مواقع الشبكات الاجتماعية لا تدعم اياً منها)! 
 تقليل زمن رفع صورة واحدة من 5 ثوان بنسبة 42% قد لا يبدو امراً ذو اهمية، لكن ماذا عن عشرٍ من هذه الصور؟ ثلاثون ثانية بالتأكيد فرق ملحوظ من خمسين! وماذا ان كانت كلاً من هذه الصور تأتي بحجمٍ يفوق ال5 ميقابايت؟ 

والأهم من كل هذا، ماذا ان كنا نتحدث عن مستخدمين بسرعات اتصال بالكاد تتعدى الميقابت في الثانية كحال الكثيرين في دول العالم غير الأول؟ الـ5.1 ميقابت المذكورة اعلاه "منفوخة" بقيم متطرفة اخرى كتلك الفي كوريا الجنوبية، السويد واليابان، اما لمثل من هم في حالتنا في السودان، ان تجد سرعة رفع تتعدى ال100 ك.بايت في الثانية امرٌ نادر الحدوث!
اسمحوا لي ان أخذ حالتي كـanecdote، سرعة الاتصال لدي في افضل حالتها تمكنني من الرفع بـ70كيلوبايت في الثانية. باستخدام هذه القيم في حالة الصورة الثانية، تصبح مدة الرفع بدون ضغط 47 ثانية، وبها تصبح مجرد 11 ثانية فقط، او فرق 77%!

ما يجب ان اذكره هو ان ازمنة الضغط المذكورة اعلاه ليست بالضرورة المدة الفعلية التي استغرقها المعالج في ضغط الصورة بقدر ما هي المدة الزمنية التي استغرقها البرنامج من اعطائه الأمر وحتى اخراجه للناتج، اي انها تشمل زمن القراءة والكتابة من وعلي القرص، والزمن الذي يحتاجه البرنامج لتشغيل نفسه (البحث عن المكتبات الضرورية للعمل، التواصل مع النظام، الخ). اعتقادي ان المدة الفعلية للضغط لا تتعدى كسوراً من الثانية، وسبب هذا الاعتقاد ان عملية الضغط بنفس البرنامج في معالج الi7 (الأسرع من الcore 2 duo بما لا يقل عن 300%) اخذت نفس الوقت لنفس الصور. 


نفس هذه النظرية يمكن تطبيقها بالنسبة للفيديوهات. فكما للصور من اساليب ضغط واعادة تشفير منقوصة وغير منقوصة، للفيديوهات نصيب من هذه الاساليب. وان كان تعقيد تركيب الفيديو الرقمي يزيد من صعوبة عملية تشفير الفيديو قبل رفعه، الا انه لا تزال هنالك تخفيض كبير في زمن الرفع في حالة القيام بضغطه قبل رفعه.
للتجربة، قمت بأخذ فيديو صورته ايضاً بإستخدام هاتفي المحمول وحاولت تقليل حجمه بإستخدام برنامج Handbrake. الفيديو الأصلي كان بدقة 720p، صيغة h.264 AVC وحاوية mp4. البتريت المتوسط 11.8 ميقابت في الثانية. الفيديو النهائي اخرج بنفس الدقة والصيغة، لكن ببتريت 4.5 ميقابت في الثانية فقط.
الحجم الأصلي للفيديو كان 45.4 ميقابايت. اما حجم الفيديو الجديد فكان 17 ميقابايت فقط.
زمن الضغط على نفس معالج الCore 2 Duo اعلاه (متوسط 4 تجارب) كان 89 ثانية فقط.
فرق الجودة بين الفيديوهين شبه منعدم.

بإفتراض سرعة الرفع مرة اخرى مساوية للمتوسط العالمي، هذا يعني ان زمن رفع الفيديو الأصلي حوالي 71 ثانية، اما زمن رفع الفيديو مع الضغط حوالي 115 ثانية. 

من هذه النتائج ستفترض ان اضافة اعادة التشفير لمعادلة الرفع سيزيد الطين بلة، اليس كذلك؟
في الحقيقة الأمر ليس بهذه البساطة. فالحسابات اعلاه تفترض ان ضغط واعادة تشفير الفيديو ورفعه عملية تتم على التوالي للفيديو ككل. لكن هذه ليست الطرق الوحيدة لـ"نقل" الفيديو. فكر فيها كالأتي: كيف يعمل اليوتيوب؟ خدمات عرض الفيديو السحابية لا تجعل المستخدم يقوم بـ"تحميل" الفيديو كاملاً، بل تستخدم مفهوم يسمى بالـstreaming ترسل فيه البيانات تسلسلياً ليمكن للمستخدم تشغيل ما تم ارساله دون الحوجة لإكتمال إرسال جميع البيانات.
قم بربط هذا المفهوم مع عملية ضغط الفيديو نفسها، عملية ايضاًَ تسلسلية (مع تجاهل تقنيات معقدة كالـ 2 pass encoding). كل ما يحتاجه الأمر تحكم في توقيت العمليتين ليرسل المستخدم فقط ما تم ضغطه من الفيديو، بالتالي تصبح عملية رفع الفيديو محكومة فقط بأقل سرعة في الخطوتين، او من المثال اعلاه، محكومة فقط بزمن نهاية عملية اعادة تشفير الفيديو.
هذه العملية ليست مجرد فكرة خيالية، بل تستخدم في منظومات خادمات الوسائط المتعددة (Media servers) المنزلية والشخصية. تحديداً تلك المخصصة للتعامل مع العديد من الأجهزة ذات الدعم المختلف للوسائط التي يمكن تشغيلها. خذ مثلاً برنامج PS3 Media Server، برنامج لي معه تجربة شخصية طويلة في عرض افلام موجودة على حاسبي الشخصي وبثها لجهاز بليستيشن 3 متصل بالحاسب عبر شبكة محلية. الPS3 لا يملك نفس المرونة التي يملكها الحاسب الشخصي في التعامل مع السوفتوير المختلف، لذا سيجبر المستخدم لتحويل صيغ الفيديوهات التي يريد تشغيلها عليه لما يمكنه العمل معها، اما تحويلها بالكامل ومن ثم نقلها، او استخدام برنامج بإمكانه القيام بعملية الtranscoding on the fly كبرنامج الميدياسيرفر المذكور.

عودة للمثال السابق، هذا يعني ان الزمن الفعلي المستغرق لرفع الفيديو مع الضغط ليس 115 ثانية بالضرورة، وانما ال 89 ثانية (بالإضافة لoverhead بسيط)‍ فقط. لكنها لا تزال اكثر من ال71 ثانية الضرورية لرفع الفيديو غير المضغوط. هنا تجب الإشارة لأمرين: الأولى ان معالج الcore 2 duo المستخدم في التجربة -بالإضافة لتأخر اداءه لقدم الجهاز ككل- معالج قديم جداً. وان حاولنا تعميم الاحصائيات التي تقول ان متوسط عمر الحاسب الشخصي 4 لـ 5 اعوام على انها المتوسط للعالم اجمع، هذا يعني ان اقل الأجهزة الموجودة حالياً تعمل معالجات Core i من معماريتي نيهاليم، ويستمير او ساندي بريدج، والثلاثة يتقدمون على معالج الCore 2 Duo المستخدم بفرق كبير في القدرة الحوسبية  الصرفة!

الأمر الثاني هو الإنتشار الكبير للتسريع الفيزيائي لعمليات تشفير واعادة تشفير الفيديو في السنين الأواخر على صعيدي الهاردوير والسوفتوير. جميع معالجات انتل منذ معمارية ساندي بريدج (اطلقت في 2011، تلتها اربع اجيال حتى الأن) تأتي بتقنية QuickSync لتسريع ضغط وتشفير فيديوهات الh.264. اما التسريع بإستخدام قدرات البطاقات الصورية فقد بدأ قبل ذلك بكثير. إنفيديا اطلقت مفهوم الCUDA منذ 2007 مع بطاقات سلسلة ال Geforce 8000، اما اليوم، فجميع بطاقات معماريات كيبلر وماكسويل تأتي بوحدات داخلية مخصصة لتسريع عمليات تشفير فيديوهات ال h.264 تسمى NVENC.
 AMD كانت من اوائل الداعمين لواجهة الOpenCL والاستخدامات المستفيدة منها، اهمها -طبعاً- تسريع عمليات معالجة الفيديو. ولا ننسى ايضاً ان بطاقتها تأتي بوحدات الـ VCE داخلية مخصصة لتشفير الـh.264، التي اصبحت تأتي ايضاً في معالجات الشركة المسرعة (APUs).

اذاً لماذا لا نرى المتصفحات وخدمات الشبكات الاجتماعية تسعى لتبني سبل الضغط واعادة التشفيرعلى جانب العميل؟ مثل هذه العمليات لم تعد تحتاج اجهزة workstation او سيرفرات ضخمة مخصصة فقط لها كما كان الحال في الماضي، بل حتى الأجهزة المتوسطة وقليلة الأداء بإمكانها ضغط مجلدات ممتلئة بالصور في دقائق معدودات. اما على الجانب الأخر فالتطور في سعات النواقل الموصلة بالشبكات العالمية لم يستطع مواكبة متطلبات هذا الزمن الذي اصبحت فيه حتى الهواتف المحمولة تخرج فيديوهات ببتريتس تتعدى ال 10 ميقابت في الثانية!
مبادرة نقل معالجة البيانات للمستخدم عوضاً عن دفع الملايين والمليارات في مئات الرفوف من السيرفرات ليست فكرة خيالية، بل متبعة بالفعل في العديد من حملات الـDistributed computing. خذ Folding @ Home كمثال. ان كانت ستانفورد تثق في ان جهازك يمكنه المساعدة في عملية معقدة كتحليل البروتين، لا اعتقد ان امراً تافهاً كتقليل حجم صورة ما سيتعصي عليه!

ربما تكون هنالك صعوبات تقنية اخفتها عني خلفيتي البسيطة عن الموضوع، لكن من ذاك القليل الذي اعرفه، هذه احدى الامور الكثيرة التي تجد اقصى كفاءة فيها في الحوسبة المحلية، وليس في عتادٍ لا تراه ولا تملكه.