يتضمن Chrome 47 العديد من تحسينات WebRTC وتحديثاته المهمة.
تسجيل فيديو من تطبيقات الويب
لطالما كانت واجهة برمجة التطبيقات MediaStreamRecorder هي الأكثر طلبًا على chromium.org، إذ تضم أكثر من 2, 500 نجمة. تمت إضافة ميزة تسجيل الوسائط إلى Chrome في ما يتعلق بعلامة ميزات Web Platform التجريبية، على الرغم من أنها متاحة للاستخدام على سطح المكتب فقط في الوقت الحالي. ويتيح لك ذلك تسجيل الفيديو وتشغيله أو تنزيله. هناك عرض توضيحي بسيط عن مستودع نماذج WebRTC ويمكنك الاطّلاع على مزيد من المعلومات من خلال إشعار discuss-webrtc. ويتوفر نموذج لتطبيق Chrome لتسجيل فيديو من لقطة الشاشة على الرابط github.com/niklasenbom/RecordingApp. هذه عمليات تنفيذ جديدة وقد لا تزال هناك أخطاء تحتاج إلى معالجتها: يُرجى الإبلاغ عن المشاكل في النظام إذا واجهتك مشاكل.
اختيار جهاز إخراج الصوت
تم إلغاء حجز "MediaDevices.enumerateDevices()". يتوفّر مزيد من التفاصيل من خلال مشكلة 504280 من Chromium. يمكنك الآن تعداد أجهزة إخراج الصوت بالإضافة إلى أجهزة إدخال الصوت وإدخال الفيديو التي يوفّرها MediaStreamTrack.getSources(). يمكنك الاطّلاع على المزيد من المعلومات حول كيفية استخدام هذه الميزة في هذا التحديث.
دعم الأجهزة على نظام التشغيل Windows
تمت الآن إضافة إمكانية الاتصال التلقائي لأجهزة الاتصالات على نظام التشغيل Windows. هذا يعني أنه عند تعداد أجهزة الصوت على نظام التشغيل Windows، سيكون هناك إدخال إضافي لجهاز الاتصالات الذي سيكون معرفه "اتصالات".
لن تتمّ تجزئة أرقام تعريف الأجهزة للجهاز السماعي التلقائي (والاتصالات على نظام التشغيل Windows) بعد الآن (المشكلة 535980). بدلاً من ذلك، يتم توفير معرّفَين محجوزَين، وهما "التلقائي" و"الاتصالات" ويكونان متطابقَين في جميع مصادر الأمان. ستتم ترجمة تسميات الجهاز إلى لغة المتصفح، لذا لن يتوقع المطورون أن يكون للتصنيفات قيمة محددة مسبقًا. تم تحسين دقة عرض الفيديو من خلال نشر الطابع الزمني للالتقاط ووصولاً إلى خوارزمية العرض، حيث يمكن اختيار المزامنة الافتراضية المناسبة بناءً على ذلك. بالنسبة إلى النظام الأساسي لنظام التشغيل Windows، يكون الطابع الزمني للالتقاط أكثر دقة في الإصدار 47 من Chrome.
التعامل مع الخادم الوكيل
يضيف Chrome 47 إعدادًا مفضّلاً جديدًا لفرض إرسال حركة بيانات WebRTC من خلال خادم وكيل محلي، في حال ضبط أحد هذه الخوادم، وهو أمر مهم بالنسبة إلى بعض المستخدمين الذين يتصفّحون عبر شبكة VPN. يعني هذا أنّ تطبيق WebRTC لن يطّلع إلا على عنوان IP للخادم الوكيل. عليك الانتباه إلى أنّ هذا الإجراء سيؤثّر سلبًا في أداء التطبيق، ولن يعمل على الإطلاق ما لم يكن التطبيق متوافقًا مع turn/TCP أو ICE-TCP. يمكنك البحث عن إصدار جديد من إضافة WebRTC Network Selecter قريبًا لتوفير واجهة مستخدم لهذا الخيار المفضّل. هناك مزيد من المعلومات حول "تسرُّب" عنوان IP في الخطوة التالية في WebRTC.
...وغير ذلك
تم تحسين سرعة معالجة قناة البيانات بشكل كبير للاتصالات التي تستغرق وقتًا طويلاً.
سنطرح الدعم تدريجيًا للإصدار 1.2 من بروتوكول أمان طبقة النقل لمخطّطات البيانات (DTLS) في الإطار الزمني للإصدار 47 من Chrome.
على الرغم من عدم توفُّر VP9 أو H.264 في هذا الإصدار، لا يزال العمل علىهما مستمرًا ونأمل أن نواصل دعم VP9 وإصدار أولي من H.264 (بدون علامة) في Chrome 48.
إشعارات الخدمة العامة
- بدءًا من الإصدار 47 من Chrome، لا يتم السماح بطلبات
getUserMedia()إلا من مصادر آمنة: HTTPS أو المضيف المحلي. - تمت إزالة دعم قناة بيانات بروتوكول RTP. أمّا بالنسبة إلى التطبيقات المتبقية التي لا تزال تستخدم قنوات بيانات RTP، فيجب أن تستخدم قنوات البيانات العادية بدلاً من ذلك.
وكما هي الحال بالنسبة إلى جميع الإصدارات، نشجع مطوّري البرامج على تجربة Chrome على قنوات إصدار Canary ومطوّري البرامج والقنوات التجريبية والإبلاغ عن أي مشاكل يتم العثور عليها. المساعدة التي نتلقاها لا تقدر بثمن. للحصول على نصائح حول كيفية تقديم تقرير خطأ جيد، يُرجى الاطّلاع على صفحة أخطاء WebRTC.
إصدارات تجريبية
- MediaRecorder
enumerateDevices():
التعرف على المزيد
- حالة تنفيذ MediaRecorder
- مسودة أداة التقاط الوسائط وساحات المشاركات: MediaDevices
- واجهة برمجة تطبيقات أجهزة إخراج الصوت
- تعديل WebRTC