تتيح لك واجهة برمجة التطبيقات Google Meet Media API الوصول إلى الوسائط في الوقت الفعلي من مؤتمرات Google Meet. ويتيح ذلك مجموعة متنوعة من حالات الاستخدام، مثل التطبيقات التي توثّق بنود الإجراءات أو تقدّم إحصاءات في الوقت الفعلي حول الاجتماع الحالي أو تبث الصوت والفيديو إلى سطح جديد.
حالات الاستخدام
يمكن للتطبيقات المسجّلة في Google Cloud Console استخدام Meet Media API للاتصال بمؤتمرات Meet، ما يتيح لها ما يلي:
- استهلاك بث الفيديو : على سبيل المثال:
- إدخال بث الفيديو الذي تم إنشاؤه في مؤتمرات Meet في نماذج الذكاء الاصطناعي الخاصة بك
- فلترة البث للتسجيلات المخصّصة
- استهلاك بث الصوت : على سبيل المثال:
- إدخال الصوت مباشرةً في Gemini وإنشاء روبوت محادثة بالذكاء الاصطناعي للاجتماع
- إدخال بث الصوت الذي تم إنشاؤه في مؤتمرات Meet في خدمة تحويل الصوت إلى نص الخاصة بك
- إنشاء ترجمات في مختلف اللغات
- إنشاء خلاصات بلغة الإشارة من النموذج الذي تم إنشاؤه من الصوت الذي تم التقاطه
- إنشاء نماذج إزالة الضوضاء الخاصة بك لإزالة الضوضاء والتشويش من المؤتمر
- استهلاك البيانات الوصفية للمشاركين : على سبيل المثال:
- اكتشاف المشاركين في المؤتمر، ما يتيح الحصول على معلومات أفضل وتحليلات أفضل
دورة حياة Meet Media API
تعرض الصور التالية دورة حياة Meet Media API:
-
الشكل 1: يحاول روبوت Meet Media API الانضمام إلى الموقع الإلكتروني التابع لطرف ثالث. ويتم رفض الاتصال في حال توفّر حسابات قاصرين. -
الشكل 2: يمكن وضع علامة على الاجتماعات بأنّها مشفّرة وإضافة علامة مائية إليها. لا يمكن ربط Meet Media API عندما يكون الاجتماع مشفّرًا أو يحتوي على علامة مائية. -
الشكل 3: تأكَّد من أنّ إعداد المشرف صحيح. -
الشكل 4: يمكنك إعداد الاجتماع في "تقويم Google". على المضيف منح الإذن للتطبيق الخارجي في إعدادات التقويم، وإلا سيتم رفض الاتصال. -
الشكل 5: تغيير الإعدادات أثناء المكالمة. إذا قرّر المضيف إيقاف إعداد Meet Media API أثناء المكالمة، سيتوقف الاتصال. -
الشكل 6: إذا كان مالك الاجتماع لديه حساب مستهلك (حساب ينتهي باللاحقة @gmail.com)، يجب أن يكون المنشئ حاضرًا في الاجتماع لمنح الموافقة، وإلا سيتم رفض الاتصال. -
الشكل 7: بعد إنشاء الاتصال، يظهر مربّع حوار البدء للمضيف أو المضيف المشارك أو أي مشاركين في المؤسسة نفسها التي يعمل بها المضيف. -
الشكل 8: يمكن لأي مستخدم إيقاف Meet Media API أثناء المكالمة.
متطلبات منح الموافقة
لا يُسمح لتطبيقات Meet Media API بالانضمام إلى اجتماع إلا إذا كان هناك شخص في المكالمة مسموح له بمنح الموافقة نيابةً عن الاجتماع.
بالنسبة إلى اجتماعات Google Workspace
لمنح الموافقة في اجتماعات Google Workspace، يجب أن تكون في الـ مؤسسة التي تملك الاجتماع. في معظم الحالات، يكون مالك الاجتماع هو نفسه المنظّم. إذا كان المضيف أو المنشئ حاضرًا في الاجتماع وكان في المؤسسة التي تملك الاجتماع، سيظهر له مربّع حوار البدء بشكل تفضيلي.
بالنسبة إلى اجتماعات المستهلكين
بالنسبة إلى الاجتماعات التي يتم تنظيمها باستخدام حسابات Gmail، يجب أن يكون المنشئ حاضرًا في الاجتماع لمنح الموافقة.
عبارات عامة
- رقم مشروع على السحابة الإلكترونية
- معرّف
int64غير قابل للتغيير يتم إنشاؤه لمشروع على السحابة الإلكترونية من Google Cloud تنشئ Google Cloud Console هذه القيم لكل تطبيق مسجَّل. - مؤتمر
- مثيل مكالمة يتم إنشاؤه على الخادم ضمن مساحة اجتماع. عادةً ما يعتبر المستخدمون هذا السيناريو اجتماعًا واحدًا.
- قناة بيانات مورد المؤتمر
بدلاً من طلب الموارد عبر HTTP، كما هو الحال مع Google Meet REST API، تطلب برامج Meet Media API من الخادم الموارد عبر قنوات البيانات.
يمكن فتح قناة بيانات مخصّصة لكل نوع من أنواع الموارد. بعد فتح القناة، يمكن للعميل إرسال الطلبات عبرها. وسيتم إرسال تعديلات الموارد عبر القناة نفسها.
- المصدر المساهم (CSRC)
باستخدام بث الوسائط الافتراضي، لا يمكنك افتراض أنّ بث الوسائط يشير دائمًا إلى المشارك نفسه. تحدّد قيمة CSRC في رأس كل حزمة RTP المصدر الحقيقي للحزمة.
يمنح Meet كل مشارك في مؤتمر قيمة CSRC فريدة عند انضمامه. وتظل هذه القيمة ثابتة إلى أن يغادر المشارك.
- قنوات البيانات
قنوات بيانات WebRTC تتيح تبادل البيانات العشوائية (النصوص والملفات وما إلى ذلك) بشكل مستقل عن بث الصوت والفيديو. تستخدم قنوات البيانات الاتصال نفسه الذي تستخدمه بث الوسائط، ما يوفّر طريقة فعّالة لإضافة تبادل البيانات إلى تطبيقات WebRTC.
- بروتوكول إنشاء الاتصالات التفاعلية (ICE)
بروتوكول لإنشاء الاتصال والعثور على جميع الطرق الممكنة لتواصل جهازَي كمبيوتر مع بعضهما البعض من خلال شبكة "نظير إلى نظير" (P2P)، ثم التأكّد من بقائك متصلاً
- بث الوسائط
يمثّل بث الوسائط في WebRTC تدفقًا لبيانات الوسائط، عادةً ما تكون صوتًا أو فيديو، يتم التقاطها من جهاز مثل كاميرا أو ميكروفون. ويتكوّن من مقاطع بث وسائط واحدة أو أكثر، يمثّل كل منها مصدرًا واحدًا للوسائط، مثل مقطع فيديو أو مقطع صوتي.
- مقطع بث الوسائط
يتكوّن من تدفق أحادي الاتجاه لحزم RTP. يمكن أن يكون مقطع بث الوسائط صوتًا أو فيديو، ولكن ليس كلاهما. عادةً ما يتكوّن اتصال بروتوكول النقل الآمن في الوقت الفعلي (SRTP) ثنائي الاتجاه من مقطعَين لبث الوسائط، أحدهما صادر من نظير محلي إلى نظير بعيد والآخر وارد من نظير بعيد إلى نظير محلي.
- مساحة الاجتماع
مكان افتراضي أو عنصر دائم (مثل غرفة اجتماع) يتم فيه عقد مؤتمر يمكن عقد مؤتمر نشط واحد فقط في مساحة واحدة في أي وقت. تساعد مساحة الاجتماع أيضًا المستخدمين في الاجتماع والعثور على الموارد المشتركة.
- مشارك
شخص انضم إلى مؤتمر أو يستخدم وضع المزاملة أو يشاهد كمشاهد أو جهاز غرفة متصل بمكالمة عند انضمام مشارك إلى المؤتمر، يتم تعيين رقم تعريف فريد له.
- البث ذو الصلة
هناك حدّ لعدد بث الصوت الافتراضي و بث الفيديو الافتراضي الذي يمكن للعميل فتحه.
من المحتمل جدًا أن يتجاوز عدد المشاركين في المؤتمر هذا الحد. في هذه الحالات، ترسل خوادم Meet بث الصوت والفيديو للمشاركين الذين يُعتبرون "الأكثر صلةً". يتم تحديد الصلة من خلال خصائص مختلفة، مثل مشاركة الشاشة ومدى حداثة تحدث المشارك.
- وحدة إعادة التوجيه الانتقائية (SFU)
وحدة إعادة التوجيه الانتقائية (SFU) هي مكوّن من جهة الخادم في مؤتمرات WebRTC يدير توزيع بث الوسائط. لا يتصل المشاركون إلا بوحدة إعادة التوجيه الانتقائية، التي تعيد توجيه البث ذي الصلة بشكل انتقائي إلى المشاركين الآخرين. يقلّل ذلك من احتياجات معالجة العميل ومعدل نقل البيانات، ما يتيح إجراء مؤتمرات قابلة للتوسيع.
- بروتوكول وصف الجلسة (SDP)
آلية إرسال الإشارات التي تستخدمها WebRTC للتفاوض على اتصال "نظير إلى نظير"
RFC 8866يحكمها.- إجابة بروتوكول وصف الجلسة (SDP)
الردّ على عرض بروتوكول وصف الجلسة. ترفض الإجابة أو تقبل أي بث يتم استلامه من النظير البعيد. كما تتفاوض على البث الذي تخطط لإرساله مرة أخرى إلى النظير الذي قدّم العرض. من المهم ملاحظة أنّه لا يمكن لإجابة بروتوكول وصف الجلسة إضافة بث تم إرسال إشارات إليه من العرض الأوّلي. على سبيل المثال، إذا أرسل نظير قدّم العرض إشارة إلى أنّه يقبل ما يصل إلى ثلاثة بث صوتي من نظيره البعيد، لا يمكن لهذا النظير البعيد إرسال إشارة إلى أربعة بث صوتي للإرسال.
- عرض بروتوكول وصف الجلسة (SDP)
بروتوكول وصف الجلسة الأوّلي في مسار التفاوض "نظير إلى نظير" بين العرض والإجابة يتم إنشاء العرض من قِبل النظير الذي بدأ التفاوض ويحدد بنود جلسة "نظير إلى نظير". يتم إنشاء العرض دائمًا من قِبل عميل Meet Media API وإرساله إلى خوادم Meet.
على سبيل المثال، قد يشير العرض إلى عدد بث الصوت أو الفيديو الذي يرسله مقدّم العرض (أو يمكنه استلامه) وما إذا كان سيتم فتح قنوات البيانات.
- مصدر المزامنة (SSRC)
معرّف SSRC هو معرّف 32 بت يحدّد بشكل فريد مصدرًا واحدًا لبث الوسائط ضمن جلسة RTP (بروتوكول النقل في الوقت الفعلي). في WebRTC، تُستخدَم معرّفات SSRC للتمييز بين بث الوسائط المختلفة الواردة من مشاركين مختلفين أو حتى مقاطع مختلفة من المشارك نفسه (مثل الكاميرات المختلفة).
- RtpTransceiver
كما هو موضّح بالتفصيل في
RFC 8829، جهاز الإرسال والاستقبال هو تجريد حول بث RTP في جلسة "نظير إلى نظير".يتم ربط جهاز إرسال واستقبال واحد بوصف وسائط واحد في بروتوكول وصف الجلسة ويتم وصفه من خلاله. يتكوّن جهاز الإرسال والاستقبال من
RtpSenderوRtpReceiver.بما أنّ بروتوكول RTP ثنائي الاتجاه، يكون لكل نظير مثيل جهاز إرسال واستقبال خاص به للاتصال نفسه ببروتوكول RTP. يتم ربط
RtpSenderلجهاز إرسال واستقبال معيّن للنظير المحلي بـRtpReceiverلجهاز إرسال واستقبال معيّن في النظير البعيد. وينطبق العكس أيضًا. يتم ربطRtpSenderلجهاز الإرسال والاستقبال نفسه للنظير البعيد بـRtpReceiverللنظير المحلي.لكل وصف وسائط جهاز إرسال واستقبال مخصّص. وبالتالي، تحتوي جلسة "نظير إلى نظير" تتضمّن بث RTP متعددة على أجهزة إرسال واستقبال متعددة تتضمّن
RtpSendersوRtpReceiverمتعددة لكل نظير.- بث الوسائط الافتراضي
بث الوسائط الافتراضي هو بث وسائط مجمّع يتم إنشاؤه من قِبل وحدة إعادة التوجيه الانتقائية (SFU) في مؤتمرات WebRTC. بدلاً من أن يرسل كل مشارك بثًا فرديًا إلى كل شخص آخر، تدمج وحدة إعادة التوجيه الانتقائية بث المشاركين المحدّدة في عدد أقل من بث الوسائط الافتراضي الصادر. يؤدي ذلك إلى تبسيط بنية الاتصال وتقليل الحمل على المشاركين، ما يتيح إجراء مؤتمرات قابلة للتوسيع. يمكن أن يحتوي كل بث افتراضي على وسائط من مشاركين متعددين، وتديرها وحدة إعادة التوجيه الانتقائية بشكل ديناميكي.
مواضيع ذات صلة
للتعرّف على كيفية بدء تطوير عميل Meet Media API، اتّبِع الخطوات الواردة في مقالة البدء.
للتعرّف على كيفية إعداد عميل مرجعي نموذجي لـ Meet Media API وتشغيله، يُرجى قراءة مقالة البدء السريع للعميل المرجعي بلغة C++ .
للحصول على نظرة عامة مفاهيمية، يُرجى الاطّلاع على مفاهيم Meet Media API.
لمزيد من المعلومات عن WebRTC، يُرجى الاطّلاع على WebRTC For The Curious.
للتعرّف على كيفية التطوير باستخدام واجهات برمجة التطبيقات في Google Workspace، بما في ذلك معالجة المصادقة والترخيص، يُرجى الرجوع إلى مقالة التطوير على Google Workspace.