كشف تلقائي أو رفض تحميلات فيديو VP9 غير متوافقة مع iOS Safari

ساهم ميزة
1

اكتشفتُ مؤخرًا أن عدة مقاطع فيديو على منتدى Discourse المضيف ذاتيًا فشلت في التشغيل على أجهزة iPhone وiPad دون إصدار أي تنبيه. وبعد التحقيق، تبين أن السبب الجذري هو أن هذه المقاطع قد تم ترميزها باستخدام مرشح VP9 داخل حاوية MP4 — وهو مزيج لا يستطيع متصفح Safari على نظام iOS تشغيله.

كيف يحدث ذلك

قد يقوم فيسبوك (وربما منصات أخرى) بتسليم مقاطع فيديو مُرمَّزة بمرشح VP9 عندما يقوم المستخدمون بتنزيل محتواهم. وعند رفع هذه الملفات إلى Discourse، يتم قبولها دون مشاكل — فامتداد .mp4 لا يُظهر أي دلالة على نوع المرشح الداخلي. وعلى متصفحات سطح المكتب وأجهزة Android، تعمل المقاطع بشكل صحيح، لذا يظل المشكلة غير ملحوظة. أما على Safari في أجهزة iOS، فيظهر الفيديو صورة مصغرة وزر تشغيل، لكن عند النقر عليه يظهر مؤشر دوران فقط. وغالبًا ما يفترض المستخدمون أن المشكلة تتعلق بالشبكة ويستمرون دون الإبلاغ عنها.

لماذا يصعب اكتشافها

  • امتداد الملف (.mp4) مطابق لملف H.264 يعمل بشكل صحيح
  • متصفحات سطح المكتب تدعم VP9، لذا لا يلاحظ المسؤولون أي مشكلة عند الاختبار على سطح المكتب
  • غالبًا لا يبلغ مستخدمو iOS عن فشل الوسائط الفردية، خاصة عندما يكون المحتوى الآخر في نفس المنشور مرئيًا وقابلًا للتشغيل
  • لا يوجد تحذير أو خطأ يظهر في لوحة تحكم المسؤول

الحل المقترح

عند رفع فيديو، يمكن لـ Discourse فحص مرشح الفيديو (أداة ffprobe متاحة بالفعل داخل حاوية Docker) وإما:

  1. رفض الرفع مع عرض رسالة واضحة توضح أن VP9 غير مدعوم على iOS، وطلب من المستخدم إعادة الترميز إلى H.264، أو
  2. إعادة ترميز الفيديو تلقائيًا إلى H.264 عند الرفع (مشابهًا لكيفية قيام بعض المنصات بتوحيد الملفات المرفوعة)

الخيار الأول أقل تعقيدًا وسيكون تحسنًا كبيرًا بالفعل. أما الخيار الثاني فهو مثالي لتجربة مستخدم سلسة.

البيئة

  • Discourse مستضاف ذاتيًا داخل Docker، مع تخزين محلي (بدون S3)
  • إصدار Discourse: 2026.4.0-latest
  • وكيل عكسي Apache أمام nginx الخاص بـ Discourse

حل بديل

بالنسبة للمسؤولين الذين يواجهون هذه المشكلة، يتضمن الإصلاح الخطوات التالية:

  1. تحديد ملفات VP9 باستخدام ffprobe
  2. إعادة الترميز إلى H.264 باستخدام الأمر: ffmpeg -c:v libx264 -profile:v main -level 3.1 -r 30 -movflags +faststart
  3. تحديث قيم sha1 وurl وfilesize في جدول uploads
  4. تحديث رموز عناوين URL القصيرة upload:// في تنسيق Markdown الخام للمنشورات المتأثرة
  5. إعادة معالجة المنشورات المتأثرة

هذه عملية يدوية غير بسيطة، ولا يمتلك معظم مسؤولي المنتديات الأدوات اللازمة لتنفيذها.

إعجاب واحد (1)
2

بالنسبة للتحويل التلقائي، يمكنك الاطلاع على Discourse Video Stream :movie_camera:.

يعمل التحويل المحلي التلقائي، لكن المشكلة الرئيسية تكمن في تقديمه بطريقة آمنة لمعظم الإعدادات.

إعجابَين (2)
3

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

ملاحظتك حول التحويل المحلي (transcoding) مثيرة للاهتمام. قمت بتشغيل ffmpeg يدويًا على الملفات التسعة المتأثرة على خادم VPS الخاص بي أثناء عملية الإصلاح، وتعامل الخادم معها دون مشاكل. أفهم القلق بشأن القيام بذلك بشكل متزامن أثناء الرفع — حيث إن ارتفاعات استخدام وحدة المعالجة المركزية، وانتهاء المهلة، وضغط القرص كلها مخاطر حقيقية. لكن هل يمكن لنهج المهمة الخلفية غير المتزامن معالجة معظم هذه المخاوف؟ يتم إكمال الرفع بشكل طبيعي، ويحدث التحويل في مهمة مكدسة لاحقًا — تمامًا كما تتعامل منصة Discourse بالفعل مع إنشاء صور مصغرة للصور. ببساطة لن يكون الفيديو قابلًا للتشغيل على iOS حتى تكتمل المهمة، وهو ما يبدو مقايضة مقبولة.

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

إعجاب واحد (1)
4

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

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

3 إعجابات