نظرة عامة على Meet Media API

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

حالات الاستخدام

يمكن للتطبيقات المسجّلة في Google Cloud Console استخدام Meet Media API ل الاتصال بمؤتمرات Meet، ما يتيح لها إجراء ما يلي:

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

عبارات عامة

رقم مشروع Cloud

معرّف int64 تم إنشاؤه ولا يمكن تغييره لمشروع على Google Cloud تنشئ Google Cloud Console هذه القيم لكل تطبيق مسجَّل.

المؤتمر

مثيل ينشئه الخادم لمكالمة ضمن مساحة اجتماع يعتبر المستخدمون عادةً هذا السيناريو اجتماعًا واحدًا.

قناة بيانات مراجع المؤتمر

بدلاً من طلب الموارد عبر بروتوكول HTTP، كما هو الحال مع Google Meet REST API، يطلب عملاء Meet Media API الموارد من الخادم عبر قنوات البيانات.

يمكن فتح قناة بيانات مخصّصة لكل نوع من أنواع الموارد. بعد فتح القناة، يمكن للعميل إرسال الطلبات عبرها. سيتم إرسال تعديلات الموارد عبر القناة نفسها.

المصدر المساهِم (CSRC)

في حال استخدام أحداث الوسائط الافتراضية، لا يمكنك افتراض أنّ حدث بث وسائط معيّنًا يشير دائمًا إلى المشارك نفسه. تحدِّد قيمة CSRC في رأس كل حزمة RTP المصدر الحقيقي للحزمة.

تحدِّد Meet لكل مشارك في مؤتمر قيمة فريدة لعنوان CSRC عند انضمامه. وتظل هذه القيمة ثابتة إلى أن يغادروا.

قنوات البيانات

تتيح قنوات بيانات WebRTC تبادل البيانات العشوائية (النصوص والملفات وما إلى ذلك) بشكل مستقل عن مجرى البث الصوتي والمرئي. تستخدم "قنوات البيانات" الاتصال نفسه الذي تستخدمه عمليات بث الوسائط، ما يوفر طريقة فعّالة لإضافة ميزة تبادل البيانات إلى تطبيقات WebRTC.

Interactive Connectivity Establishment (ICE)

بروتوكول لإنشاء الاتصال والعثور على جميع المسارات الممكنة لجهازين كمبيوتر للتواصل مع بعضهما البعض من خلال شبكة "نظير إلى نظير"، ثم التأكّد من بقائك متصلاً

بث الوسائط

يمثّل بثّ وسائط WebRTC تدفقًا لبيانات الوسائط، عادةً ما يكون صوتًا أو فيديو، يتم تسجيله من جهاز مثل كاميرا أو ميكروفون. ويتكوّن من مسار بث وسائط واحد أو عدّة مسارات، يمثّل كلّ منها مصدرًا واحدًا للوسائط، مثل مسار فيديو أو مسار صوتي).

مسار بث الوسائط

يتكوّن من تدفق أحادي الاتجاه لحِزم RTP. يمكن أن يكون مقطع بث الوسائط صوتيًا أو فيديو، ولكن ليس كليهما. يتألّف الاتصال ببروتوكول النقل الآمن في الوقت الفعلي (SRTP) الثنائي الاتجاه عادةً من مقطعَين لبث الوسائط، وهما الخروج من المعادل المحلي إلى المعادل البعيد والدخول من المعادل البعيد إلى المعادل المحلي.

مساحة الاجتماع

مكان افتراضي أو عنصر دائم (مثل غرفة اجتماعات) يتم فيه عقد مؤتمر. يمكن عقد اجتماع فيديو نشط واحد فقط في مساحة واحدة في أي وقت. تساعد مساحة الاجتماعات المستخدمين أيضًا في الاجتماع والعثور على موارد مشترَكة.

المشارك

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

ساحات المشاركات ذات الصلة

هناك حدّ أقصى لعدد عمليات بث الصوت الافتراضي وعمليات بث الفيديو الافتراضي التي يمكن للعميل فتحها.

من الممكن أن يتجاوز عدد المشاركين في المؤتمر هذا العدد. في هذه الحالات، تُرسِل ملفّات خادم Meet بثّ الصوت والفيديو للمشاركين الذين يُعتبرون "الأكثر صلة". يتم تحديد مدى الصلة من خلال سمات مختلفة، مثل مشاركة الشاشة ووقت حديث أحد المشاركين.

وحدة إعادة التوجيه الانتقائي (SFU)

وحدة إعادة التوجيه الانتقائية (SFU) هي مكوّن من جهة الخادم في مؤتمرات WebRTC التي تدير توزيع بث الوسائط. يتصل المشاركون بوحدة التحكّم في حدود الجلسة فقط، وهي تعيد توجيه أحداث البث ذات الصلة بشكل انتقائي إلى المشاركين الآخرين. ويؤدي ذلك إلى تقليل احتياجات معالجة العميل ومعدل نقل البيانات، ما يتيح عقد مؤتمرات قابلة للتوسّع.

بروتوكول وصف الجلسة (SDP)

آلية إرسال الإشارات التي تستخدمها WebRTC للتفاوض على اتصال بين نقطتَي اتصال تخضع هذه السياسة RFC 8866.

إجابة SDP

الردّ على عرض وصف الجلسة (SDP) يرفض الردّ أي عمليات بث تمّ استلامها من المثيّر البعيد أو يقبلها. ويتفاوض أيضًا بشأن أحداث البث التي يعتزم نقلها إلى الخادم الشقيق الذي يقدّم المحتوى. تجدر الإشارة إلى أنّه لا يمكن لملف الردّ SDP إضافة أحداث بث تم إرسال إشارات لها من العرض الأوّلي. على سبيل المثال، إذا أرسل جهاز عرض إشارة بأنّه يقبل ما يصل إلى ثلاثة مصادر صوتية من الجهاز البعيد، لا يمكن للجهاز البعيد إرسال إشارة بأنّه يقبل أربعة مصادر صوتية للبث.

عرض بروتوكول وصف الجلسة (SDP)

بروتوكول وصف الجلسة (SDP) الأوّلي في عملية التفاوض بين الأقران في مسار الإرسال والاستلام يتم إنشاء العرض من قِبل الجهاز المشغِّل للاتصال ويحدِّد أحكام جلسة التواصل بين الأجهزة. يتم إنشاء العرض دائمًا من خلال برنامج Meet Media API العميل ويتم إرساله إلى خوادم Meet.

على سبيل المثال، قد يشير العرض إلى عدد عمليات بث الصوت أو الفيديو التي يرسلها (أو يمكنه تلقّيها) مقدّم العرض وما إذا كان سيتم فتح قنوات البيانات.

مصدر المزامنة (SSRC)

معرّف SSRC هو معرّف 32 بت يحدّد بشكل فريد مصدرًا واحدًا لبث الوسائط ضمن جلسة بروتوكول النقل في الوقت الفعلي (RTP). في WebRTC، تُستخدَم أرقام SSRC للتمييز بين مصادر الوسائط المختلفة التي تأتي من مشاركين مختلفين أو حتى مسارات مختلفة من المشارك نفسه (مثل كاميرات مختلفة).

RtpTransceiver

كما هو موضّح بالتفصيل في RFC 8829، فإنّ جهاز الإرسال والاستقبال هو عنصر مجرد حول أحداث بث بروتوكول RTP في جلسة بين نظيرَين.

يتم ربط جهاز إرسال/استقبال واحد بوصف واحد لوسائط في ملف وصف الجلسة (SDP). يتكوّن جهاز الإرسال والاستقبال من RtpSender و RtpReceiver.

بما أنّ بروتوكول RTP ثنائي الاتجاه، يكون لكل جهاز نظير مثيل جهاز إرسال واستقبال خاص به للعمل على اتصال RTP نفسه. يتمّ ربط RtpSender لجهاز إرسال/استقبال معيّن في الجهاز المضيف المحلي بـ RtpReceiver لجهاز إرسال/استقبال معيّن في الجهاز المضيف البعيد. وينطبق العكس أيضًا. يتم ربط RtpSender لجهاز التحكّم عن بُعد بجهاز التحكّم المحلي RtpReceiver.

يحتوي كل وصف وسائط على جهاز إرسال واستلام مخصّص. وبالتالي، فإنّ جلسة الند للند التي تتضمّن عدة مصادر بث RTP تحتوي على أجهزة إرسال واستقبال متعددة مع عدة RtpSenders وRtpReceiver لكل جهاز ند.

أحداث البث الافتراضي للوسائط

يتم تجميع أحداث تدفق الوسائط الافتراضية من خلال أحداث تدفق الوسائط التي يتم إنشاؤها بواسطة وحدة توجيه انتقائي (SFU) في مؤتمرات WebRTC. بدلاً من أن يرسل كل مشارك محتوًى منفصلاً إلى جميع المشاركين الآخرين، تُعدّل تقنية SFU محتوًى من المشاركين المحدّدين إلى عدد أقل من أحداث البث الافتراضي. يؤدي ذلك إلى تبسيط بنية الاتصال وتقليل الضغط على المشاركين، ما يتيح إجراء مكالمات فيديو قابلة للتوسّع. يمكن أن يحتوي كل بث افتراضي على وسائط من مشاركين متعدّدين، تُدار ديناميكيًا من خلال وحدة التحكّم في حدود الجلسة.

مواضيع ذات صلة

• للتعرّف على كيفية بدء تطوير برنامج Meet Media API، اتّبِع الخطوات الواردة في البدء.

• للتعرّف على كيفية إعداد نموذج برمجي لتطبيق Meet Media API وتشغيله، يُرجى الاطّلاع على دليل بدء استخدام برمجة التطبيقات المرجعية لـ C++.

• للحصول على نظرة عامة على المفاهيم، يُرجى الاطّلاع على Meet Media API concepts.

• لمعرفة المزيد من المعلومات عن WebRTC، يمكنك الاطّلاع على WebRTC للمهتمين.

• للتعرّف على كيفية التطوير باستخدام واجهات برمجة تطبيقات Google Workspace، بما في ذلك التعامل مع مصادقة وتفويض، يُرجى الاطّلاع على مقالة التطوير على Google Workspace.