CDN للفيديو: كيف يعمل توصيل HLS فعليًا

لماذا يختلف الفيديو عن كل ما تقدّمه سواه

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

والاقتصاد يتبع المنحنى نفسه. لدى المزوّدين الذين يفوترون الخروج (egress) بالغيغابايت، فيديو ناجح باعتدال هو فاتورة ملحوظة؛ وفيديو منتشر هو مكالمة هاتفية من قسم المالية. كلتا المشكلتين — سقف النطاق الترددي والفاتورة — لهما شكل كل مشكلة محتوى ثابت أخرى، ما يعني أن لهما الحل نفسه: أجب عن الطلبات المتكررة من ذاكرة مؤقتة قريبة من المشاهد بدلًا من الخادم الأصلي، في كل مرة دون استثناء.

HLS بلا غموض: قائمة تشغيل ومجلد ملفات

يبدو HLS (بث HTTP المباشر) غريبًا حتى تفتح الملفات. يقطّع المُرمّز الفيديو إلى مقاطع قصيرة — بضع ثوانٍ لكلٍّ منها — ويكتب قائمة تشغيل نصية عادية (.m3u8) تسردها بالترتيب. يُنزّل المُشغّل قائمة التشغيل ثم يجلب المقاطع واحدًا تلو الآخر عبر HTTP عادي، متقدمًا ببضع ثوانٍ عمّا يعرضه. والجودة التكيّفية هي الحيلة نفسها مرتين: قائمة تشغيل رئيسية (master) تشير إلى عدة قوائم تشغيل متغايرة (1080p و720p و480p)، ويتنقّل المُشغّل بينها مع تغيّر النطاق الترددي.

والنتيجة تستحق أن تُقال بوضوح: لا يوجد بروتوكول فيديو خاص في مسار التوصيل. لا مقابس (sockets)، ولا خادم بث، ولا بنية تحتية غريبة. كل طلب يُرسله المُشغّل هو GET لملف ثابت صغير — وملفات ثابتة صغيرة تُقدَّم ملايين المرات هي بالضبط الحمل الذي وُجد edge شبكة CDN لأجله.

قائمة تشغيل متغايرة — نص عادي يشير إلى ملفات عادية

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-TARGETDURATION:6
#EXT-X-MEDIA-SEQUENCE:0
#EXTINF:6.000,
segment_000.ts
#EXTINF:6.000,
segment_001.ts
#EXTINF:6.000,
segment_002.ts
#EXT-X-ENDLIST

مسار VOD: رمّز مرة، خزّن مرة، قدّم من الـ edge

للفيديو عند الطلب ثلاث محطات في المسار. رمّز مرة واحدة، على جهازك أو في خط البناء لديك — يحوّل ffmpeg فيديو المصدر إلى مجلد قائمة التشغيل والمقاطع بأمر واحد. خزّن مرة واحدة، في تخزين كائنات متوافق مع S3، الموجود تحديدًا لملفات تُكتب مرة وتُقرأ كثيرًا مثل هذه. قدّم من الـ edge: مع وضع الـ bucket خلف شبكة CDN، يملأ أول مشاهد لكل مقطع الذاكرة المؤقتة ويُجاب كل من بعده قرب مكانه، بينما يجيب تخزينك عن كل ملف فريد مرة واحدة تقريبًا.

على cdn.com.tr التخزين والـ edge منصة واحدة، فلا يكون هذا مشروع تكامل: أنشئ bucket، وارفع المجلد، ويتصدّره edge الحساب نفسه — بما فيه WAF وحماية DDoS.

من ملف المصدر إلى بث يُقدَّم عبر CDN

# 1) encode into HLS (6-second segments, one quality for brevity)
ffmpeg -i talk.mp4 -c:v h264 -c:a aac \
  -hls_time 6 -hls_playlist_type vod \
  -hls_segment_filename 'talk/segment_%03d.ts' talk/playlist.m3u8

# 2) create the bucket and an access key (panel works too)
cdnctl object-storage buckets create --account <uuid> --name videos
cdnctl object-storage access-keys create --account <uuid> --bucket <bucket_uuid>

# 3) upload the folder with the standard AWS CLI
aws --endpoint-url https://s3.cdn.com.tr s3 sync ./talk s3://videos/talk

# the player now points at the playlist behind your CDN hostname:
#   https://video.example.com/talk/playlist.m3u8

قواعد التخزين المؤقت التي تصنع توصيل الفيديو أو تحطّمه

يكافئ الفيديو انضباط رؤوس التخزين المؤقت الذي يكتفي المحتوى الآخر بتقديره، لأن نوعَي الملفات في بث HLS يريدان معاملة متعاكسة.

المقاطع غير قابلة للتغيير بحكم البناء — لن يحتوي segment_042.ts أبدًا على بايتات مختلفة، لأن إعادة الترميز تكتب مجلدًا جديدًا. خزّنها مؤقتًا ما شئت؛ سنة كاملة ليست تهوّرًا بل هي الصواب. كل مقطع مخزَّن مؤقتًا طويلًا هو نطاق ترددي لن يقدّمه خادمك الأصلي مرة أخرى.

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

على cdn.com.tr تضبط هذا التقسيم بعينه كقواعد توصيل في اللوحة: قاعدة تطابق مسار المقاطع بمدة طويلة، وأخرى تطابق ‎*.m3u8 بمدة قصيرة.

تفاصيل تلدغ: النطاقات (ranges) وCORS والضغط

ثلاث ملاحظات عملية توفّر معظم تذاكر دعم الفيديو. أولًا، طلبات النطاق (range requests): تطلب المُشغّلات والمتصفحات بانتظام نطاقات بايت من ملفات الوسائط، ويقدّم الـ edge المحتوى الجزئي من الذاكرة المؤقتة — وهذا أيضًا ما يتيح للمشاهد القفز إلى الدقيقة السادسة دون تنزيل الدقائق من الأولى حتى الخامسة من ملف MP4.

ثانيًا، CORS: إذا كان المُشغّل يعمل على اسم مضيف مختلف عن ملفات الفيديو، فسيطالب المتصفح برؤوس Access-Control-Allow-Origin على المقاطع وقوائم التشغيل، وعَرَض نسيانها مُشغّل يعمل في تبويب مجرّد لكنه لا يعمل مضمَّنًا في صفحتك.

ثالثًا، الضغط: اتركه معطّلًا للوسائط. الفيديو والصوت مضغوطان أصلًا بواسطة الـ codec؛ وتطبيق gzip على مقطع .ts يُنفق معالجًا ليوفّر لا شيء. اضغط قوائم التشغيل إن شئت — فهي نص — لكن المكسب مجهري. الـ edge يعرف أصلًا ألا يعيد ضغط أنواع الوسائط؛ الملاحظة مهمة لإعدادات خادمك الأصلي أنت.

والبث المباشر؟ إجابة صادقة

البث المباشر هو قصة التوصيل نفسها مع سلسلة إمداد أصعب. نصف التوصيل متطابق: بث HLS المباشر لا يزال قائمة تشغيل ومقاطع، غير أن قائمة التشغيل تنمو كل بضع ثوانٍ وتُخزَّن مؤقتًا لوهلة وجيزة جدًا. والـ edge يقدّم ذلك ببراعة — آلاف المشاهدين يقرؤون ملفات عمرها ثوانٍ لا تزال مجرد إصابات ذاكرة مؤقتة.

ما يضيفه البث المباشر هو كل ما يسبق وجود الملفات: الاستقبال (ingest — تلقّي بث الكاميرا عبر RTMP أو SRT)، والتحويل الفوري إلى سُلّم الجودات، والتغليف — خط أنابيب عامل له أنماط فشله الخاصة، لا مجلد ترفعه مرة واحدة. هذا الخط ليس شيئًا تُجمّعه على عجل، وليس ما يفعله منتج هذه المنصة بالخدمة الذاتية: cdn.com.tr هي نصف التخزين والتوصيل من القصة. إن كان مشروعك يحتاج سلسلة البث المباشر كاملة، فتحدّث إلينا مباشرة بدلًا من إجباره على قالب VOD — واحذر أي مزوّد يبيع "البث المباشر" دون أن يقول من يشغّل المُرمّز.