شاهدني بالكامل: اضغط على الفيديوهات على منصات الجوّال على أكمل وجه

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

يمكنك استخدام ExoPlayer وتحسينه ، أو يمكنك حتى كتابة مشغل الفيديو الخاص بك باستخدام برامج الترميز والمقابس فقط. ستتحدث المقالة عن عمل الدفق وتشغيل الفيديو ، وكيفية الحد من التأخير في بدء الفيديو ، وتقليل وقت الاستجابة بين المبرمج والمشاهد ، وتحسين استهلاك الطاقة وتحميل الحديد.

سنحلل ذلك باستخدام تطبيقات محددة كمثال: عميل المحمول Odnoklassniki (حيث يتم تشغيل مقاطع الفيديو) و OK Live (حيث يتم بث البث من الهاتف إلى 1080 بكسل). لن تكون هناك فصول رئيسية حول كيفية تشغيل الفيديو حسب المرجع ، مع أمثلة التعليمات البرمجية. ستركز القصة على كيفية ظهور الفيديو من الداخل ، ومعرفة البنية العامة لمشغلات الفيديو وتدفق الفيديو ، يمكنك فهم أي نظام وجعله أفضل.

تستند المادة إلى نسخة تقرير ألكساندر توبول ( alatobol ) وإيفان غريغوريف ( ivan_a ) من مؤتمر Mobius .

دخول

بالنسبة للمبتدئين - بعض الأرقام حول الفيديو في Odnoklassniki.

يبلغ متوسط ​​ذروة حركة مرور الفيديو اليومية (فيديو عند الطلب) أكثر من نصف تيرابايت في الثانية ، وللإذاعة المباشرة - أكثر من 3 تيرابايت في الثانية.

الآن في OK ، هناك أكثر من 870 مليون مشاهدة فيديو في اليوم ، أكثر من نصفها من الأجهزة المحمولة.



إذا نظرت إلى تاريخ البث ، فظهر مقطع فيديو للجوال على YouTube في عام 2007. لقد قفزنا في هذا القطار لاحقًا ، ولكن في 2014-2015 كان لدينا بالفعل تشغيل فيديو 4K على الأجهزة المحمولة ، وفي السنوات الأخيرة قمنا بتطوير لاعبينا بشكل نشط. حول هذا والمحادثة سوف تذهب.

الاتجاه الثاني الذي نشأ مع بيريسكوب في عام 2015 كان البث من الهواتف. أطلقنا تطبيق OK Live الخاص بنا ، والذي يسمح لك ببث مقاطع فيديو عالية الدقة بالكامل عبر شبكات المحمول. في النصف الثاني من المادة ، سنتحدث أيضًا عن البث.

لن نتطرق إلى واجهة برمجة التطبيقات للتعامل مع الفيديو ، ولكننا نغطس الآن بعمق ونحاول معرفة ما يحدث في الداخل.



عندما تقوم بتصوير فيديو على كاميرا ، فإنه يصل إلى برنامج الترميز ، من هناك إلى المقبس ، ثم إلى الخادم (بغض النظر عما إذا كان VOD أو Live). ثم يقوم الخادم بترتيب عكسي بتوزيعه على الجمهور.

لنبدأ مع لاعب KPI. ماذا نريد منه؟

• الإطار الأول سريع. لا يريد المستخدمون الانتظار لبدء التشغيل.
• عدم وجود التخزين المؤقت. لا أحد يحب أن يصطدم بجذع.
• جودة عالية عندما لم يكن هناك محتوى 4K تقريبًا حتى الآن ، قدمنا ​​بالفعل دعم 4K "للنمو": إذا تم إيقاف تشغيل المشغل له واكتشاف الأداء ، فسيتم تشغيل 1080p بشكل مثالي حتى على الأجهزة الضعيفة.
• متطلبات UX. نحتاج إلى تشغيل الفيديو في الشريط أثناء التمرير ، وللشريط نحتاج إلى جلب الفيديو مسبقًا.

هناك العديد من المشاكل بهذه الطريقة. يعد تدفق الفيديو 4K كبيرًا ، ونعمل على الأجهزة المحمولة حيث توجد مشاكل في الشبكة ، وهناك العديد من ميزات تنسيقات الفيديو والحاويات على الأجهزة المختلفة ، كما يمكن أن تصبح الأجهزة نفسها مشكلة.

أين تعتقد أن الفيديو يبدأ بشكل أسرع ، على نظام iOS أو Android؟

في الواقع ، أي إجابة صحيحة: ذلك يعتمد على ماذا وأين وكيف لعب. إذا أخذنا منطقة من روسيا بشبكة غير جيدة ، فسنرى أن AVPlayer يبدأ من حوالي 800 مللي ثانية. ولكن مع نفس الشبكة ، ستقوم ExoPlayer على Android ، التي تلعب تنسيقًا مختلفًا ، بإطلاقها في 660 مللي ثانية. وإذا قمت بإنشاء لاعب على نظام التشغيل iOS ، فسيكون بإمكانه التشغيل بشكل أسرع.



هناك فارق بسيط في أننا نقيس المتوسط ​​للمستخدمين ، ومتوسط ​​قوة أجهزة iOS أعلى منه على Android.

سيكون الجزء الأول من المادة نظريًا: سنتعرف على نوع الفيديو وماهية بنية أي لاعب Live. وفي الجزء الثاني ، دعنا نقارن اللاعبين ونتحدث عن وقت كتابة ما لديك.

الجزء الأول

ما هو الفيديو

لنبدأ مع أبسط. الفيديو 60 أو 24 صورة في الثانية الواحدة.

من الواضح أن تخزين هذا مع مجموعة كاملة من الصور باهظ الثمن. لذلك ، يتم تخزينها بهذه الطريقة: تسمى بعض الإطارات الإطارات المرجعية (I-frames) ، بينما تسمى الإطارات الأخرى (B-frames و P-frames) باسم "diffs". في الواقع ، لديك ملف jpg ومجموعة محددة من التغييرات عليه.



هناك أيضًا مفهوم GOP (مجموعة صور) - هذه مجموعة مستقلة من الإطارات ، والتي تبدأ بإطار مرجعي وتستمر بمجموعة من الاختلافات. يمكن أن تلعبه بشكل مستقل ، تفكيك وهلم جرا. في الوقت نفسه ، إذا فقدت opornik في المجموعة ، فإن الإطارات المتبقية لم تعد ذات صلة.

هناك الكثير من خوارزميات الترميز ، ومصفوفات التحويل ، والبحث عن الحركة ، وما شابه ذلك - وهذا ما يختلف فيه برامج الترميز.

أداء الترميز

H.264 الكلاسيكية معروفة منذ عام 2003 وتطورت بشكل جيد. سنتخذ فعاليتها كقاعدة. انه يعمل ويلعب في كل مكان. لديه دعم الأجهزة لوحدة المعالجة المركزية / GPU (سواء على نظام التشغيل iOS ، على نظام Android). هذا يعني أنه إما أن يكون هناك نوع من المعالجات الخاصة التي يمكنها تشفيرها ، أو مجموعات التعليمات المدمجة التي تسمح لك بذلك بسرعة. في المتوسط ​​، يوفر دعم الأجهزة أداء أسرع حتى 10x ويوفر عمر البطارية.

في عام 2010 ، ظهر VP8 من جوجل. من حيث الكفاءة ، فإنه لا يختلف عن H.264. حسنًا ، إن فعالية برنامج الترميز أمر مثير للجدل للغاية. في الجبهة ، يتم قياسها كنسبة الفيديو الأصلي إلى المضغوطة ، ولكن من الواضح أن هناك قطع فيديو مختلفة. لذلك ، نحن نقدم رابطًا لمقارنات تفصيلية لبرامج الترميز من جامعة موسكو الحكومية. لكننا هنا نقتصر على حقيقة أن VP8 يركز على مؤسسة برمجية ، ويمكنك سحبها معك في أي مكان ، وعادة ما تستخدم كخلفية احتياطية إذا لم يكن هناك دعم محلي H.264.

في عام 2013 ، ظهر جيل جديد من برامج الترميز - H.265 (HEVC) و VP9. يوفر برنامج الترميز H.265 زيادة في الكفاءة بنسبة 50٪ ، لكن لا يمكن تشفيرها على فيديو Android ، فقد ظهر جهاز فك الترميز فقط مع Android 5.0+. لكن على نظام iOS هناك دعم.

هناك بديل ل H.265 - VP9. كل نفس ، ولكن بدعم من جوجل. حسنًا ، V9 هو YouTube ، و H.265 هو Netflix. لذلك لكل منها خصائصه الخاصة: لن يعمل أحدهما على نظام التشغيل iOS ، بينما يواجه الآخر مشاكل على نظام Android. في النهاية ، يظل الكثيرون على H.264.

في المستقبل ، لقد وعدنا بترميز AV1 ، وهو يحتوي بالفعل على تنفيذ برنامج ، وكفاءته أعلى بنسبة 35٪ من كفاءة برامج الترميز 2013. متوفر الآن في Chrome و Firefox ، وفي عام 2020 وعدت Google بدعم الأجهزة - أعتقد ، على الأرجح ، أننا سننتقل إليه جميعًا.

وأخيراً ، أعلنوا مؤخرًا عن برنامج الترميز H.266 / JVEC ، قائلين إن كل شيء سيكون أفضل وأسرع.

النمط الرئيسي: كلما زادت كفاءة برنامج الترميز ، زادت موارد الحوسبة التي يتطلبها من الأجهزة.

بشكل عام ، بشكل افتراضي ، يأخذ الجميع H.264 ، ومن ثم بالنسبة إلى أجهزة معينة ، يمكن أن يكون الأمر معقدًا.

الجودة والقرار ومعدل البت

في عام 2019 ، لن تفاجئ أي شخص بالجودة التكيفية: يقوم المستخدمون بتحميل مقاطع الفيديو أو بثها بجودة واحدة ، فنحن نقطع مجموعة من الصفات المختلفة ونرسل الأكثر ملاءمة للأجهزة.

في هذه الحالة ، من الضروري أن ترتبط دقة الفيديو مع معدل البت. في حالة مضاعفة الدقة ، يجب أيضًا مضاعفة معدل البت:



من الواضح ، إذا قمت بضغط دقة كبيرة بمعدل بت منخفض أو بالعكس ، فستكون هناك قطع أثرية أو حرق معدل البت دون فائدة.

كيف يمكن مقارنة معدل البت في الفيديو المشفر بالكمية الأصلية من المعلومات؟ على شاشة 4K ، يمكننا تشغيل ما يقرب من 6 جيجابت / ثانية من المعلومات (إذا قمت بحساب جميع وحدات البكسل وترددها بمعدل 60 إطارًا في الثانية) ، بينما يمكن أن يكون معدل البت في الترميز 50 ميجابايت / ثانية. وهذا يعني أن برنامج الترميز يضغط الفيديو حتى 100 مرة.

تكنولوجيا التسليم

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



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

هذه البروتوكولات معقدة للغاية بالنسبة للخادم ويصعب تسليمها. بالنسبة للترجمات المحملة بكثافة ، نستخدم بروتوكولات مجزأة تعمل على رأس HTTP ، ويمكن تخزينها مؤقتًا بواسطة nginx و CDN ، وهي أسهل بكثير في التوزيع. والخادم ليست مسؤولة عن أي شيء ، وفي هذه الحالة ، عديمي الجنسية.

كيف يبدو تسليم المقطع: قمنا بتقطيع الفيديو الحالي إلى مقاطع ، ومرافقتهم برأس للصوت والفيديو ، MPEG-TS و MP4 كمثال على النقل. على الهاتف ، نقدم بيانًا يحتوي على معلومات حول مكان وجودة القطاع ، ويمكن تحديث هذا البيان بشكل دوري.

تاريخياً ، تقدم Apple من خلال HLS و Android من خلال DASH. دعونا نرى كيف تختلف.

لنبدأ بـ HLS الأقدم ، حيث يحتوي على بيان يصف كل الصفات المتاحة - منخفضة ومتوسطة وعالية وما إلى ذلك. هناك معدل البت لهذه الصفات بحيث يمكن للاعب اختيار الفور واحد الصحيح. يختار الجودة ويحصل على بيان متداخل مع قائمة من الروابط إلى القطاعات. يشار أيضا إلى مدة هذه القطاعات.



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



الصعوبة الثانية: تم تصميم HLS للعمل على الإنترنت عبر HTTP ، ولكن تم اختيار MPEG-2 Transport Stream القديمة كحاوية لبيانات الفيديو ، والتي تم تطويرها لأغراض مختلفة تمامًا: إرسال إشارة من قمر صناعي في قنوات صاخبة. نتيجة لذلك ، نحصل على رؤوس إضافية ، والتي في حالة HLS لا طائل من ورائها وتضيف فقط النفقات العامة.



أضف النفقات العامة على الشبكة وتعقيد التحليل: إذا حاولت تشغيل 4K في DASH و HLS في Chrome ، فسوف تشعر بالفرق عندما "ينطلق" الكمبيوتر الخاص بك مع حزم HLS.

آبل تحاول حل هذا. في عام 2016 ، أعلنوا عن إمكانية استخدام Fragmented MPEG-4 ، وكان هناك بعض الدعم لـ DASH في HLS ، لكن RTT الإضافي وميزاته لم تختف.



تبدو DASH أبسط قليلاً: لديك بيان واحد مع كل الصفات في الداخل ، وكل جودة عبارة عن مجموعة من القطاعات. يمكنك تشغيل مقطع واحد للعب بجودة واحدة ، ثم إدراك أن السرعة زادت ، من المقطع التالي للتبديل إلى مقطع آخر. تبدأ جميع القطاعات دائمًا بإطارات مرجعية ، مما يتيح التبديل.

فيما يلي صفيحة صغيرة حول ما يمكنك الاختيار منه:



في HLS ، تكون برامج ترميز الفيديو المدعومة تاريخياً هي H.264 فقط ، في MPEG-DASH يمكنك دفع أي شخص. المشكلة الرئيسية في HLS هي رحلة ذهاب وإياب إضافية في البداية ، فهي تلعب بشكل جيد على كل من iOS و Android مع 4.0. يتم دعم DASH بشكل أساسي بواسطة Google (Chrome و Android) ولا يمكن تشغيلها على iOS.

العمارة لاعب

لقد قمنا بتسوية الفيديو بشكل أو بآخر ، والآن لنرى كيف يبدو أي لاعب.



لنبدأ بجزء الشبكة: عند بدء تشغيل الفيديو ، يتابع المشغل البيان ، ويختار الجودة بطريقة ما ، ثم يتبع المقطع ، ويقوم بتنزيله ، ثم يحتاج إلى فك تشفير الإطارات ، وفهم أن هناك إطارات كافية في المخزن المؤقت للتشغيل ، ثم يبدأ التشغيل.

الهيكل العام للاعب:



هناك جزء الشبكة ، ومأخذ ، حيث تأتي البيانات.

بعد ذلك - مزيل تعدد الإرسال أو نوع من الأشياء التي تحصل على دفق الصوت والفيديو من النقل (HLS / DASH). إنها ترسلهم إلى برامج الترميز المناسبة.

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

ثم تحتاج إلى تقديمه في مكان ما - في الملمس ، السطح ، GL أو المعدن ، في أي مكان.

وعند الإدخال ، يوجد تحكم في الحمل ، والذي يقوم بتحميل البيانات والتحكم في المخزن المؤقت.

كيف يبدو التحكم في الحمل في جميع اللاعبين؟ هناك بعض كمية البيانات التي يجب تنزيلها. ينتظر المشغل حتى يتم تنزيله ، ثم يبدأ اللعب ، ونقوم بالتنزيل أكثر. لدينا الحد الأقصى للمخزن المؤقت ، عند الوصول إلى توقف التنزيل. بعد ذلك ، أثناء التشغيل ، ينخفض ​​مقدار البيانات في المخزن المؤقت - وهناك حد أدنى يبدأ عنده التنزيل. لذلك كل هذا يعيش أيضا:



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



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

مقدر

عند التكيف ، يعتمد المشغل على معلمتين رئيسيتين: سرعة الشبكة ومخزن البيانات المؤقت.

كيف يبدو: أولاً ، يتم إعادة إنتاج جودة معينة ، على سبيل المثال ، 720p. لديك المخزن المؤقت المتزايد ، التخزين المؤقت أكثر وأكثر. ثم تنمو السرعة ، أنت تدرك أنه يمكنك تنزيل المزيد ، ينمو المخزن المؤقت. وفي هذه اللحظة ، تفهم أنك تخطو بعض حدود الحد الأدنى للمخزن المؤقت عندما يمكنك تجربة الجودة التالية.



من الواضح أنك تحتاج إلى تجربتها بعناية: يوجد أيضًا مقدر يوضح ما إذا كان بإمكانك تلبية هذه الجودة من حيث سرعة الشبكة. إذا كنت تندرج في هذا التقييم وتسمح الأسهم العازلة ، فيمكنك التبديل ، على سبيل المثال ، إلى 1080 بكسل والاستمرار في اللعب.

على حماية الضغط

معنا ، ظهرت مع مرور الوقت من خلال التجربة والخطأ. تنشأ الحاجة إلى ذلك عندما تفرط في شحن جهازك بشكل طفيف.

هناك موقف عندما تكون الشبكة مبللة أثناء التشغيل أو نفاد الموارد في الخلفية. عندما يستأنف اللاعب التشغيل ، يبدأ في اللحاق بالركب.

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

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



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

لاعبين

في نظام التشغيل iOS ، يوجد فقط برنامج AVPlayer أصلي ، ولكن على نظام Android يوجد خيار. هناك MediaPlayer أصلي ، ولكن هناك ExoPlayer يستند إلى Java مفتوح المصدر أن التطبيقات "تجلب معهم". ما هي إيجابيات وسلبيات؟

قارن الثلاثة:



في حالة الدفق التكيفي ، يقوم ExoPlayer بتشغيل DASH / HLS ولديه العديد من الوحدات القابلة للتوسيع للبروتوكولات الأخرى ، بينما يزداد AVPlayer سوءًا.

دعم إصدارات نظام التشغيل ، من حيث المبدأ ، يناسب الجميع في كل مكان.

الجلب المسبق هو عندما تعلم أنه بعد نهاية مقطع فيديو واحد ، تريد تشغيل ما يلي في الشريط ، وتحميله مسبقًا.

هناك مشكلة في إصلاح الأخطاء للاعبين الأصليين. في حالة ExoPlayer ، يمكنك ببساطة تحويله إلى إصدار جديد من التطبيق الخاص بك ، ولكن في AVPlayer و MediaPlayer الأصليين سيتم إصلاح الخلل فقط في إصدار نظام التشغيل التالي. لقد صادفنا هذا بشكل مؤلم: في نظام التشغيل iOS 8.01 بدأ تشغيل مقطع الفيديو الخاص بنا بشكل سيء ، وفي iOS 8.02 توقفت البوابة بأكملها عن العمل ، في 8.03 كان كل شيء يعمل مرة أخرى. ولا شيء يعتمد علينا في هذه الحالة ، لقد جلسنا وانتظرنا حتى تقوم شركة Apple بطرح الإصدار التالي.

يتحدث فريق ExoPlayer عن عدم كفاءة استهلاك الطاقة في حالة الصوت. هناك توصيات عامة من Google: لتشغيل الصوت ، واستخدام MediaPlayer ، لكل شيء آخر Exo.

فهمنا ، سوف نستخدم ExoPLayer مع DASH للفيديو على Android ، و AVPlayer مع HLS على iOS.

الإطار الأول سريع

مرة أخرى ، تذكر الوقت حتى الإطار الأول. كيف يبدو على نظام التشغيل iOS HLS: أول RTT خلف البيان ، ثم RTT آخر خلف البيان المتداخل ، عندها فقط - الحصول على المقطع واللعب. في Android ، واحد RTT أقل ، يبدأ بشكل أفضل قليلاً.

حجم العازلة

الآن دعونا نتعامل مع المخازن المؤقتة. لدينا الحد الأدنى من البيانات التي يجب تنزيلها قبل بدء اللعب. في AVPlayer ، يتم تكوين هذه القيمة باستخدام AVPlayerItem preferForwardBufferDuration.



على Android ، لدى ExoPlayer الكثير من آليات التكوين. هناك نفس المخزن المؤقت الحد الأدنى المطلوب لبدء. ولكن هناك أيضًا إعداد منفصل للرفض (في حالة تعطل الشبكة ، نفدت البيانات من المخزن المؤقت ، ثم عادت):



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

الجودة الأصلية

تواجه HLS على نظام التشغيل iOS مشكلة رائعة: فهي تبدأ دائمًا في التشغيل من الجودة الأولى في بيان m3u8. ما تعيده سيبدأ. وعندها فقط سيقيس سرعة التنزيل ويبدأ اللعب بجودة عادية. من الواضح أنه لا ينبغي السماح بذلك.

التحسين المنطقي - إعادة فرز الجودة. إما على الخادم (عن طريق إضافة معلمة إضافية إلى preferquality ، فإنه يعيد ترتيب البيان) أو على العميل (قم بعمل بروكسي سيفعل ذلك لك).

وعلى Android ، هناك معلمة DefaultBandwidthMeter لهذا الغرض. يعطي قيمة يعتبرها النطاق الترددي الافتراضي للنطاق الخاص بك.



كيف يعمل: هناك جدول كبير من الثوابت في الكود ، والمعلمات بسيطة - البلد (المنطقة) ونوع الاتصال (واي فاي ، 2G ، 3G ، 4G). ما هي المعاني؟ على سبيل المثال ، إذا كان لديك شبكة Wi-Fi وتقع في الولايات المتحدة الأمريكية ، فإن النطاق الترددي الأولي يبلغ 5.6 ميغابت في الثانية. وإذا كان 3G هو 700 كيلو بايت في الثانية.

يمكن ملاحظة أنه وفقًا لتقديرات Google ، فإن 4G في روسيا أسرع بمعدل 2-3 مرات من مثيله في أمريكا.

, — , . , , , , .

, , , , . , ( Android ).

(seek), , . , , , .



, , - . iOS, , , , ( , , ).

ExoPlayer 2.7.0 , , « ». . , .



( , ), - , Android prepare(mediaSource), seekTo(). , , , . — :



, ( , ), . ( 100 ), , .

iOS , Android legacy-.
TextureView. , , , , UI. — .

SurfaceView. , . Android- . YouTube , .

GLSurfaceView — . , .



: , ExoPlayer, 23%. «» 10%. 4% . 4% — , .

: Android

• MediaPlayer , ExoPlayer
• start, seek, swap
• ,
• view

: iOS

iOS :

• RTT HLS AVPlayer
• AVPlayer#pause
• — , iOS

DASH-, « live-». :

• cURL GCDAsyncSocket
• AVAssetReader,
• CADisplayLink
• AVSampleBufferDisplayLayer

, . 28%, «» 6%. , HLS DASH 100 /, 6%.

iOS :

• start seek
• HLS over Fragmented mp4
• DASH-

, .

:

, , .

• ( mp4)
• (ExoPlayer, AVPlayer)
• firstFrame, seek, emptyBuffer
• ( )
• - , . 4, : performance, , .

— .

:

, ?



API . API iOS Android, — , .

: - wrapper , POSIX-, , .

?

• بداية سريعة

?

• bandwidth
• (N x RTT, RTT)

— . , , .

: , , . — low latency.

, — . .

— 4K. , , . , 30 , . , .

, , , . ( 100 ).

- , , .

. 100 , . , 300 kbps FullHD- 480p, FullHD . , : , , overhead-. .

:



, , . , - , , .

MediaCodec VideoToolbox ( ). Server Transcoder.

— , .

, . , , reliability — ( ), throughput — ( ) low latency — ( ).



, . , - .

, : RTMP WebRTC — , OKMP — .

, RTMP TCP, — UDP.

RTMP

ماذا يعطي؟ بطريقة معينة ، يعد هذا معيارًا تدعمه جميع الخدمات - YouTube و Twitch و Flash و OK. يستخدمونها بحيث يمكن للمستخدمين تحميل البث المباشر. إذا كنت ترغب في دفق دفق مباشر إلى خدمة تابعة لجهات أخرى ، فستضطر على الأرجح إلى العمل مع RTMP.

الحد الأدنى للتأخير الذي استطعنا تحقيقه من محرك الشريط إلى المشغل هو 300 مللي ثانية ، ولكن هذا في شبكة مثالية في الطقس الجيد. عندما يكون لدينا شبكة حقيقية ، عادة ما ينمو التأخير إلى 2-3 ثوان ، وإذا كان كل شيء سيئًا على الشبكة ، فيمكن أن ينمو إلى عشرات الثواني.

يدعم RTMP تغيير الدقة ومعدل البت على الطاير (البروتوكولات الأخرى المذكورة هي نفسها ، ولكن هناك معلومات خاطئة حول RTMP أنه لا يوجد أي تغيير على الطاير).

من السلبيات: مبنية على TCP (سنشرح لاحقًا سبب هذا الخطأ) ، التأخير غير محكم.

إذا نظرت إلى المثلث ، فلن يتمكن RTMP من إعطاء زمن انتقال منخفض. يمكن الحصول عليها ، ولكن ليس مضمونة على الإطلاق.

بالإضافة إلى ذلك ، يعد RTMP مجرد هراء: فهو لا يدعم برامج الترميز الجديدة ، نظرًا لأن Adobe لا يقوم بذلك ، والوثائق قديمة ومتعرجة.



لماذا لا يناسب TCP البث المباشر؟ يوفر TCP ضمانًا للتسليم: سيتم تسليم البيانات التي تضعها على المقبس بالترتيب وبالشكل الذي وضعته فيه بالضبط. لن يتم إسقاط أي شيء أو إعادة ترتيبه. سوف TCP إما القيام بذلك أو يموت. ولكن هذا يعني أن ضمان التأخير مستبعد - لن يكون قادرًا على إسقاط البيانات القديمة ، والتي ربما لا تحتاج بالفعل إلى إرسالها. يبدأ المخزن المؤقت ، المتراكمة وما إلى ذلك في النمو.



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

ما هذا لدينا في البداية مخزن مؤقت فارغ. نحن نتلقى البيانات من مكان ما: الكثير من البيانات والكثير من حزم IP. تلقينا أول حزمة IP ، وعلى المتلقي باستخدام طريقة recv () يمكننا طرح هذه الحزمة ، والحصول على البيانات ، والخسارة ، وتقديم. ولكن فجأة فقدت الحزمة الثانية. ماذا يحدث بعد ذلك؟

لاستعادة حزمة IP المفقودة ، يجب على TCP إعادة الإرسال. لكي يحدث هذا ، تحتاج إلى إنفاق RTT ، في حين أن إعادة الإرسال يمكن أن تضيع أيضًا ، وسوف نذهب في دورات. إذا كان هناك العديد من الحزم ، فسيحدث هذا بالتأكيد.

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

لفهم مشكلة أخرى ، دعونا نلقي نظرة على التكيف RTMP. نحن نفعل التكيف على جانب المرسل. إذا لم تتمكن الشبكة من حشر البيانات بالسرعة التي يتم وضعها بها في المقبس ، يتم تعبئة المخزن المؤقت ويقول مأخذ التوصيل EWOULDBLOCK أو تم حظره إذا تم استخدام الحظر في هذه اللحظة.



في هذه اللحظة فقط نفهم أن لدينا مشاكل ، ونحن بحاجة إلى تقليل الجودة.

دعنا نقول أن لدينا شبكة بسرعة محددة قدرها 4 ميغابت في الثانية. اخترنا حجم المقبس من 250 كيلو بايت (الموافق 0.5 ثانية في سرعتنا). فجأة ، فشلت الشبكة 10 مرات - وهذا هو الوضع الطبيعي. لدينا 400 كيلو بايت في الثانية. تملأ المخزن المؤقت بسرعة في نصف ثانية ، وفقط في تلك اللحظة نفهم أننا بحاجة إلى التبديل.



ولكن المشكلة الآن هي أن لدينا 250 كيلو بايت من المخزن المؤقت الذي سيتم إرساله لمدة 5 ثوان. لقد تأخرنا تمامًا: نحن بحاجة إلى دفع البيانات القديمة أولاً ، وعندها فقط ستذهب البيانات الجديدة والمكيفة للحاق بالوقت الفعلي.

ما يجب القيام به هنا لدينا "مثلث التسويات" هو ذات الصلة فقط.

• يمكننا تقليل المخزن المؤقت للمرسل ، ووضع بدلاً من 0.5 ثانية - 0.1 ثانية. لكننا نفقد عرض النطاق الترددي ، حيث أننا "سنشعر بالذعر" ونتوقف عن العمل. علاوة على ذلك ، يعمل TCP بطريقة بحيث إذا وضعت مخزنًا مؤقتًا للمرسل أصغر من RTT ، فلن تتمكن من استخدام عرض النطاق الترددي الكامل للقناة ، فستقل هذه النسبة عدة مرات.
• يمكننا زيادة المخزن المؤقت المتلقي. مع وجود مخزن مؤقت كبير ، تصل البيانات ، يمكننا تلطيف بعض المخالفات داخل المخزن المؤقت. لكن ، بالطبع ، نحن نفقد الكمون المنخفض ، حيث أنشأنا على الفور مؤقتًا لمدة 5 ثوانٍ.
• يمكننا إسقاط البيانات القديمة بقوة. في TCP ، الخيار الوحيد لذلك هو قطع الاتصال وإعادة إنشائه. نفقد الموثوقية ، لأنه في هذا الوقت لا يوجد لدى اللاعب شيء يظهره.

يتطلب WebRTC

هذه مكتبة C ++ تأخذ في الاعتبار تجربة بالفعل وتعمل على رأس UDP. بنيت تحت iOS ، أندرويد ، في المتصفحات ، ويدعم HTML5. نظرًا لأنه مسجون لمكالمات P2P ، يكون التأخير هو 0.1-1 ثانية.



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

يجب أيضًا مراعاة أن المكتبة موجهة نحو العميل لإجراء محادثة بين عميلين بدون خادم. تحتاج إلى البحث عن خادم جهة خارجية ، أو كتابة خادمك الخاص.

ماذا تختار - RTMP أو WebRTC؟ طبقنا كلا البروتوكولات واختبرناها في سيناريوهات مختلفة. على الرسم البياني ، لدى WebRTC تأخير منخفض ، لكن إنتاجية منخفضة ، في حين أن RTMP له عكس ذلك. وبينهم ثقب.

وأردنا إنشاء بروتوكول يغطي هذه الفتحة تمامًا ويمكنه العمل في WebRTC وفي وضع RTMP. صنعوا وأطلقوا عليها اسم OKMP.

OKMP

هذا هو بروتوكول مرن ل UDP.

يدعم تعدد الإرسال. ماذا يعني هذا: هناك عدة قنوات داخل الجلسة (في حالة OK Live - المدير والصوت والفيديو). ضمن كل قناة ، يتم ضمان تسليم البيانات بترتيب معين (لكنها ليست مضمونة في حد ذاتها للتسليم) ، والترتيب بين القنوات غير مضمون ، لأنه غير مهم.

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



بالإضافة إلى ذلك ، يحتوي بروتوكولنا على ضمان تسليم اختياري. يمكننا القول أنه في قناة معينة ، نعمل في وضع TCP ، مع تسليم مضمون ، وفي البقية نسمح ببعض الانخفاضات.

بفضل هذا ، يمكن أيضًا تقديم ضمان للتأخير: لا يوجد أي ضمان للتأخير على قناة TCP ، ولكن في الحالات الأخرى التي يُسمح فيها بالسقوط ، يتم تعيين عتبة ، وبعدها تبدأ البيانات في الانخفاض ونتوقف عن تسليم البيانات القديمة.

على سبيل المثال ، بالنسبة للصوت ، هذا هو ثانية واحدة ، وفي الفيديو ، 0.5 ثانية. لماذا تختلف العتبة؟ هذه هي آلية تحديد الأولويات الأخرى. نظرًا لأنه من المهم بالنسبة لنا أن يكون الصوت سلسًا ، فقد بدأنا في إسقاط الفيديو أولاً.

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



بالطبع ، إذا قررت كتابة بروتوكولك في UDP ، فستواجه بعض المشكلات. باستخدام TCP ، نحصل على آليات يجب أن نكتبها على UDP بأنفسنا:

• packetizing / depacketizing. تحتاج إلى قص البيانات في حزم بحجم 1.5 كيلوبايت تقريبًا بحيث تتناسب مع شبكة MTU.
• إعادة ترتيب. يمكنك إرسال حزم في ترتيب واحد ، ويتم إعادة ترتيبها في الطريق وتأتي في ترتيب آخر. للتغلب على هذا ، تحتاج إلى تعيين التسلسل مع رقم الحزمة ، وإعادة ترتيبها على المتلقي.
• الخسائر. بالطبع ، هناك خسائر. عند حدوث خسارة ، يجب على المتلقي إخبار المرسل بشكل منفصل "لقد استلمت هذه الحزم ، لكن لم أتلقها" ، ويجب على المرسل إعادة إرسال الحزم المفقودة. أو إسقاطها.
• التحكم في التدفق إذا لم يتلق المستلم البيانات ، ولم يواكب السرعة التي دفعنا بها ، فقد تبدأ البيانات في الضياع ، ويجب علينا معالجة هذا الموقف. في حالة TCP ، سيتم حظر مأخذ الإرسال ، وفي حالة UDP لن يتم حظره ، يجب أن تفهم نفسك أن المتلقي لا يتلقى البيانات ، ويقلل من كمية البيانات المرسلة.
• مراقبة الازدحام. شيء مشابه ، فقط في هذه الحالة ماتت الشبكة. إذا أرسلنا حزمًا إلى شبكة المتوفى ، فسوف ندمر ليس فقط اتصالنا ، ولكن أيضًا الحزم المجاورة.
• التشفير. تحتاج إلى رعاية التشفير
• ... وأكثر من ذلك بكثير

OKMP مقابل RTMP

ماذا حصل عندما بدأنا استخدام OKMP بدلاً من RTMP؟

• متوسط ​​الزيادة في معدل البت OKLive هو 30 ٪.
• ارتعاش (قياس وصول الحزمة غير المستوية) - 0٪ (في المتوسط ​​نفسه).
• ارتعاش الصوت - -25 ٪
• غضب الفيديو - 40 ٪

التغييرات في الصوت والفيديو - إظهار الأولويات في بروتوكولنا. الصوت نعطي أولوية أعلى ، وبدأت تأتي أكثر سلاسة بسبب الفيديو.

كيفية اختيار بروتوكول للتدفق

إذا كنت بحاجة إلى الكمون المنخفض - WebRTC.

إذا كنت ترغب في العمل مع الخدمات الخارجية ، ونشر مقاطع الفيديو على خدمات الطرف الثالث ، فسيتعين عليك استخدام RTMP.

إذا كنت تريد بروتوكولًا مخصصًا للنصوص البرمجية - فقم بتنفيذ البروتوكول الخاص بك.