Google Meet Media API به شما امکان می‌دهد به رسانه‌های بی‌درنگ کنفرانس‌های Google Meet دسترسی داشته باشید. این کار انواع موارد استفاده را امکان‌پذیر می‌کند، مانند برنامه‌هایی که موارد اقدام را مستند می‌کنند، بینش‌های بی‌درنگ درباره جلسه فعلی ارائه می‌دهند یا صدا و ویدیو را به یک سطح جدید پخش می‌کنند.
موارد استفاده کنید
برنامه‌های ثبت‌شده در کنسول Google Cloud می‌توانند از Meet Media API برای اتصال به کنفرانس‌های Meet استفاده کنند و به آنها امکان می‌دهد:
- از جریان های ویدیویی استفاده کنید . به عنوان مثال:
- جریان‌های ویدیویی تولید شده در کنفرانس‌های Meet را به مدل‌های هوش مصنوعی خود تغذیه کنید.
- جریان‌ها را برای ضبط‌های سفارشی فیلتر کنید.
- از جریان های صوتی استفاده کنید . به عنوان مثال:
- صدا را مستقیماً به Gemini وارد کنید و ربات چت هوش مصنوعی جلسه خود را ایجاد کنید.
- جریان‌های صوتی تولید شده در کنفرانس‌های Meet را به سرویس رونویسی خودتان وارد کنید
- زیرنویس ها را به زبان های مختلف ایجاد کنید.
- از صدای ضبط شده، فیدهای زبان اشاره تولید شده توسط مدل ایجاد کنید.
- برای حذف پس‌زمینه و مصنوعات پر سر و صدا از کنفرانس، مدل‌های denoiser خود را ایجاد کنید.
- متادیتای شرکت کننده را مصرف کنید . به عنوان مثال:
- تشخیص اینکه کدام شرکت کنندگان در کنفرانس هستند، به این ترتیب اطلاعات و تجزیه و تحلیل بهتری وجود دارد.
اصطلاحات رایج
- شماره پروژه ابری
- یک شناسه
int64ایجاد شده تغییرناپذیر برای پروژه Google Cloud. این مقادیر توسط کنسول Google Cloud برای هر برنامه ثبت شده ایجاد می شود. - کنفرانس
- نمونه ای از تماس ایجاد شده توسط سرور در فضای جلسه . کاربران معمولاً این سناریو را یک جلسه در نظر می گیرند.
- کانال داده منابع کنفرانس
به جای درخواست منابع از طریق HTTP، مانند Google Meet REST API ، مشتریان Meet Media API منابع را از سرور از طریق کانال های داده درخواست می کنند.
یک کانال داده اختصاصی ممکن است برای هر نوع منبع باز شود. پس از باز شدن، مشتری می تواند درخواست ها را از طریق کانال ارسال کند. به روز رسانی منابع از طریق همان کانال منتقل می شود.
- منبع کمک کننده (CSRC)
با جریان های رسانه های مجازی ، نمی توانید فرض کنید که یک جریان رسانه ای همیشه به یک شرکت کننده اشاره می کند. مقدار CSRC در هدر هر بسته RTP منبع واقعی بسته را مشخص می کند.
Meet به هر یک از شرکت‌کنندگان در کنفرانس یک مقدار CSRC منحصربه‌فرد را هنگام پیوستن به آنها اختصاص می‌دهد. این مقدار تا زمانی که آنها خارج شوند ثابت می ماند.
- کانال های داده
کانال های داده WebRTC تبادل داده های دلخواه (متن، فایل ها و غیره) را مستقل از جریان های صوتی و تصویری امکان پذیر می کند. کانال های داده از همان اتصال جریان های رسانه ای استفاده می کنند و راهی کارآمد برای افزودن تبادل داده به برنامه های WebRTC ارائه می کنند.
- برقراری ارتباط تعاملی (ICE)
پروتکلی برای برقراری اتصال، یافتن تمام مسیرهای ممکن برای دو کامپیوتر برای مکالمه با یکدیگر از طریق شبکه همتا به همتا (P2P) و سپس اطمینان حاصل می‌کند که در ارتباط هستید.
- جریان رسانه ای
WebRTC Media Stream جریانی از داده‌های رسانه‌ای، معمولاً صوتی یا تصویری را نشان می‌دهد که از دستگاهی مانند دوربین یا میکروفون گرفته شده است. این شامل یک یا چند آهنگ جریان رسانه است که هر کدام یک منبع رسانه واحد مانند یک آهنگ ویدیویی یا یک آهنگ صوتی را نشان می دهد.
- آهنگ جریان رسانه
شامل یک جریان یک طرفه بسته های RTP است. یک آهنگ جریان رسانه می تواند صوتی یا تصویری باشد، اما نه هر دو. یک اتصال دو طرفه ایمن پروتکل حمل و نقل بلادرنگ (SRTP) معمولاً از دو مسیر جریان رسانه تشکیل شده است، خروجی از محلی به همتای راه دور و ورودی از همتای راه دور به همتای محلی.
- فضای جلسه
یک مکان مجازی یا یک شیء ثابت (مانند اتاق جلسه) که در آن کنفرانس برگزار می شود. تنها یک کنفرانس فعال در هر زمان می تواند در یک مکان برگزار شود. فضای جلسه همچنین به کاربران کمک می کند تا منابع مشترک را پیدا کنند.
- شرکت کننده
فردی که به یک کنفرانس ملحق شده است یا از حالت همراه استفاده می کند، به عنوان یک بیننده تماشا می کند، یا یک دستگاه اتاق متصل به یک تماس. هنگامی که یک شرکت کننده به کنفرانس ملحق می شود، یک شناسه منحصر به فرد اختصاص داده می شود.
- جریان های مربوطه
محدودیتی برای تعداد جریان‌های صوتی مجازی و جریان‌های ویدیویی مجازی وجود دارد که مشتری می‌تواند باز کند.
این امکان وجود دارد که تعداد شرکت کنندگان در یک کنفرانس از این تعداد بیشتر شود. در این شرایط، سرورهای Meet جریان‌های صوتی و تصویری شرکت‌کنندگانی را که «مرتبط‌ترین» تلقی می‌شوند، منتقل می‌کنند. ارتباط با ویژگی‌های مختلف، مانند اشتراک‌گذاری صفحه نمایش و اینکه یک شرکت‌کننده اخیراً چقدر صحبت کرده است، تعیین می‌شود.
- واحد حمل و نقل انتخابی (SFU)
یک واحد انتقال انتخابی (SFU) یک جزء سمت سرور در کنفرانس WebRTC است که توزیع جریان رسانه را مدیریت می کند. شرکت‌کنندگان فقط به SFU متصل می‌شوند، که به‌طور انتخابی جریان‌های مربوطه را به سایر شرکت‌کنندگان ارسال می‌کند. این امر نیازهای پردازش مشتری و پهنای باند را کاهش می دهد و کنفرانس های مقیاس پذیر را امکان پذیر می کند.
- پروتکل شرح جلسه (SDP)
مکانیسم سیگنال دهی WebRTC برای مذاکره با اتصال P2P استفاده می کند.
RFC 8866بر آن نظارت دارد.- پاسخ SDP
پاسخ به پیشنهاد SDP پاسخ هر جریان دریافتی از همتای راه دور را رد یا می پذیرد. همچنین مذاکره می‌کند که کدام جریان‌ها را می‌خواهد به طرف عرضه‌کننده بازگرداند. توجه به این نکته مهم است که پاسخ SDP نمی تواند جریان های سیگنالی را از پیشنهاد اولیه اضافه کند. به طور حکایتی، اگر یک همتای پیشنهادی سیگنال دهد که حداکثر سه جریان صوتی را از همتای راه دور خود می پذیرد، این همتای راه دور نمی تواند چهار جریان صوتی را برای انتقال سیگنال دهد.
- پیشنهاد SDP
SDP اولیه در جریان مذاکره همتا به همتا پیشنهاد پاسخ. پیشنهاد توسط همتای شروع کننده ایجاد می شود و شرایط جلسه همتا به همتا را دیکته می کند. این پیشنهاد همیشه توسط سرویس گیرنده Meet Media API ایجاد می شود و به سرورهای Meet ارسال می شود.
به عنوان مثال، یک پیشنهاد ممکن است تعداد پخش‌های صوتی یا ویدیویی را که پیشنهاد دهنده ارسال می‌کند (یا می‌تواند دریافت کند) و اینکه آیا کانال‌های داده باز می‌شوند، نشان دهد.
- منبع همگام سازی (SSRC)
یک SSRC یک شناسه 32 بیتی است که به طور منحصر به فرد یک منبع واحد از یک جریان رسانه را در یک جلسه RTP (پروتکل حمل و نقل بلادرنگ) شناسایی می کند. در WebRTC، SSRC ها برای تمایز بین جریان های رسانه های مختلف که از شرکت کنندگان مختلف یا حتی آهنگ های متفاوت از یک شرکت کننده (مانند دوربین های مختلف) نشات می گیرند، استفاده می شود.
- گیرنده Rtp
همانطور که در
RFC 8829توضیح داده شده است، یک فرستنده گیرنده یک انتزاع در اطراف جریان های RTP در یک جلسه همتا به همتا است.یک فرستنده گیرنده منفرد به یک توصیف رسانه واحد در SDP نگاشت و توصیف می شود. یک فرستنده گیرنده از یک
RtpSenderو یکRtpReceiverتشکیل شده است.از آنجایی که RTP دو طرفه است، هر همتا نمونه فرستنده گیرنده خود را برای همان اتصال RTP دارد.
RtpSenderیک فرستنده گیرنده معین برای همتای محلی به گیرندهRtpReceiverیک فرستنده خاص در همتای راه دور نگاشت می شود. عکس آن نیز صادق است.RtpSenderهمان فرستنده گیرنده همتای راه دور بهRtpReceiverهمتای محلی نگاشت می شود.هر توصیف رسانه ای فرستنده گیرنده اختصاصی خود را دارد. از این رو، یک جلسه همتا به همتا با چندین جریان RTP دارای چندین فرستنده گیرنده با چندین
RtpSendersوRtpReceiverبرای هر همتا است.- جریان های رسانه های مجازی
جریان‌های رسانه مجازی، جریان‌های رسانه‌ای انباشته‌ای هستند که توسط یک واحد ارسال انتخابی (SFU) در کنفرانس‌های WebRTC تولید می‌شوند. به جای اینکه هر شرکت‌کننده جریان‌های جداگانه‌ای را برای دیگران ارسال کند، SFU جریان‌های شرکت‌کننده انتخابی را روی جریان‌های مجازی خروجی کمتری چندگانه می‌کند. این توپولوژی اتصال را ساده می کند و بار شرکت کنندگان را کاهش می دهد و کنفرانس های مقیاس پذیر را امکان پذیر می کند. هر جریان مجازی می‌تواند حاوی رسانه‌هایی از چندین شرکت‌کننده باشد که به صورت پویا توسط SFU مدیریت می‌شود.
موضوعات مرتبط
برای یادگیری نحوه شروع توسعه یک سرویس گیرنده Meet Media API، مراحل را در شروع به کار دنبال کنید.
برای یادگیری نحوه راه‌اندازی و اجرای نمونه مشتری مرجع Meet Media API، شروع سریع کلاینت مرجع C++ را بخوانید.
برای دریافت یک نمای کلی مفهومی، به مفاهیم Meet Media API مراجعه کنید.
برای کسب اطلاعات بیشتر درباره WebRTC، WebRTC For The Curious را ببینید.
برای آشنایی با توسعه با Google Workspace APIها، از جمله رسیدگی به احراز هویت و مجوز، به Develop on Google Workspace مراجعه کنید.
Google Meet Media API به شما امکان می‌دهد به رسانه‌های بی‌درنگ کنفرانس‌های Google Meet دسترسی داشته باشید. این کار انواع موارد استفاده را امکان‌پذیر می‌کند، مانند برنامه‌هایی که موارد اقدام را مستند می‌کنند، بینش‌های بی‌درنگ درباره جلسه فعلی ارائه می‌دهند یا صدا و ویدیو را به یک سطح جدید پخش می‌کنند.
موارد استفاده کنید
برنامه‌های ثبت‌شده در کنسول Google Cloud می‌توانند از Meet Media API برای اتصال به کنفرانس‌های Meet استفاده کنند و به آنها امکان می‌دهد:
- از جریان های ویدیویی استفاده کنید . به عنوان مثال:
- جریان‌های ویدیویی تولید شده در کنفرانس‌های Meet را به مدل‌های هوش مصنوعی خود تغذیه کنید.
- جریان‌ها را برای ضبط‌های سفارشی فیلتر کنید.
- از جریان های صوتی استفاده کنید . به عنوان مثال:
- صدا را مستقیماً به Gemini وارد کنید و ربات چت هوش مصنوعی جلسه خود را ایجاد کنید.
- جریان‌های صوتی تولید شده در کنفرانس‌های Meet را به سرویس رونویسی خودتان وارد کنید
- زیرنویس ها را به زبان های مختلف ایجاد کنید.
- از صدای ضبط شده، فیدهای زبان اشاره تولید شده توسط مدل ایجاد کنید.
- برای حذف پس‌زمینه و مصنوعات پر سر و صدا از کنفرانس، مدل‌های denoiser خود را ایجاد کنید.
- متادیتای شرکت کننده را مصرف کنید . به عنوان مثال:
- تشخیص اینکه کدام شرکت کنندگان در کنفرانس هستند، به این ترتیب اطلاعات و تجزیه و تحلیل بهتری وجود دارد.
اصطلاحات رایج
- شماره پروژه ابری
- یک شناسه
int64ایجاد شده تغییرناپذیر برای پروژه Google Cloud. این مقادیر توسط کنسول Google Cloud برای هر برنامه ثبت شده ایجاد می شود. - کنفرانس
- نمونه ای از تماس ایجاد شده توسط سرور در فضای جلسه . کاربران معمولاً این سناریو را یک جلسه در نظر می گیرند.
- کانال داده منابع کنفرانس
به جای درخواست منابع از طریق HTTP، مانند Google Meet REST API ، مشتریان Meet Media API منابع را از سرور از طریق کانال های داده درخواست می کنند.
یک کانال داده اختصاصی ممکن است برای هر نوع منبع باز شود. پس از باز شدن، مشتری می تواند درخواست ها را از طریق کانال ارسال کند. به روز رسانی منابع از طریق همان کانال منتقل می شود.
- منبع کمک کننده (CSRC)
با جریان های رسانه های مجازی ، نمی توانید فرض کنید که یک جریان رسانه ای همیشه به یک شرکت کننده اشاره می کند. مقدار CSRC در هدر هر بسته RTP منبع واقعی بسته را مشخص می کند.
Meet به هر یک از شرکت‌کنندگان در کنفرانس یک مقدار CSRC منحصربه‌فرد را هنگام پیوستن به آنها اختصاص می‌دهد. این مقدار تا زمانی که آنها خارج شوند ثابت می ماند.
- کانال های داده
کانال های داده WebRTC تبادل داده های دلخواه (متن، فایل ها و غیره) را مستقل از جریان های صوتی و تصویری امکان پذیر می کند. کانال های داده از همان اتصال جریان های رسانه ای استفاده می کنند و راهی کارآمد برای افزودن تبادل داده به برنامه های WebRTC ارائه می کنند.
- برقراری ارتباط تعاملی (ICE)
پروتکلی برای برقراری اتصال، یافتن تمام مسیرهای ممکن برای دو کامپیوتر برای مکالمه با یکدیگر از طریق شبکه همتا به همتا (P2P) و سپس اطمینان حاصل می‌کند که در ارتباط هستید.
- جریان رسانه ای
WebRTC Media Stream جریانی از داده‌های رسانه‌ای، معمولاً صوتی یا تصویری را نشان می‌دهد که از دستگاهی مانند دوربین یا میکروفون گرفته شده است. این شامل یک یا چند آهنگ جریان رسانه است که هر کدام یک منبع رسانه واحد مانند یک آهنگ ویدیویی یا یک آهنگ صوتی را نشان می دهد.
- آهنگ جریان رسانه
شامل یک جریان یک طرفه بسته های RTP است. یک آهنگ جریان رسانه می تواند صوتی یا تصویری باشد، اما نه هر دو. یک اتصال دو طرفه ایمن پروتکل حمل و نقل بلادرنگ (SRTP) معمولاً از دو مسیر جریان رسانه تشکیل شده است، خروجی از محلی به همتای راه دور و ورودی از همتای راه دور به همتای محلی.
- فضای جلسه
یک مکان مجازی یا یک شیء ثابت (مانند اتاق جلسه) که در آن کنفرانس برگزار می شود. تنها یک کنفرانس فعال در هر زمان می تواند در یک مکان برگزار شود. فضای جلسه همچنین به کاربران کمک می کند تا منابع مشترک را پیدا کنند.
- شرکت کننده
فردی که به یک کنفرانس ملحق شده است یا از حالت همراه استفاده می کند، به عنوان یک بیننده تماشا می کند، یا یک دستگاه اتاق متصل به یک تماس. هنگامی که یک شرکت کننده به کنفرانس ملحق می شود، یک شناسه منحصر به فرد اختصاص داده می شود.
- جریان های مربوطه
محدودیتی برای تعداد جریان‌های صوتی مجازی و جریان‌های ویدیویی مجازی وجود دارد که مشتری می‌تواند باز کند.
این امکان وجود دارد که تعداد شرکت کنندگان در یک کنفرانس از این تعداد بیشتر شود. در این شرایط، سرورهای Meet جریان‌های صوتی و تصویری شرکت‌کنندگانی را که «مرتبط‌ترین» تلقی می‌شوند، منتقل می‌کنند. ارتباط با ویژگی‌های مختلف، مانند اشتراک‌گذاری صفحه نمایش و اینکه یک شرکت‌کننده اخیراً چقدر صحبت کرده است، تعیین می‌شود.
- واحد حمل و نقل انتخابی (SFU)
یک واحد انتقال انتخابی (SFU) یک جزء سمت سرور در کنفرانس WebRTC است که توزیع جریان رسانه را مدیریت می کند. شرکت‌کنندگان فقط به SFU متصل می‌شوند، که به‌طور انتخابی جریان‌های مربوطه را به سایر شرکت‌کنندگان ارسال می‌کند. این امر نیازهای پردازش مشتری و پهنای باند را کاهش می دهد و کنفرانس های مقیاس پذیر را امکان پذیر می کند.
- پروتکل شرح جلسه (SDP)
مکانیسم سیگنال دهی WebRTC برای مذاکره با اتصال P2P استفاده می کند.
RFC 8866بر آن نظارت دارد.- پاسخ SDP
پاسخ به پیشنهاد SDP پاسخ هر جریان دریافتی از همتای راه دور را رد یا می پذیرد. همچنین مذاکره می‌کند که کدام جریان‌ها را می‌خواهد به طرف عرضه‌کننده بازگرداند. توجه به این نکته مهم است که پاسخ SDP نمی تواند جریان های سیگنالی را از پیشنهاد اولیه اضافه کند. به طور حکایتی، اگر یک همتای پیشنهادی سیگنال دهد که حداکثر سه جریان صوتی را از همتای راه دور خود می پذیرد، این همتای راه دور نمی تواند چهار جریان صوتی را برای انتقال سیگنال دهد.
- پیشنهاد SDP
SDP اولیه در جریان مذاکره همتا به همتا پیشنهاد پاسخ. پیشنهاد توسط همتای شروع کننده ایجاد می شود و شرایط جلسه همتا به همتا را دیکته می کند. این پیشنهاد همیشه توسط سرویس گیرنده Meet Media API ایجاد می شود و به سرورهای Meet ارسال می شود.
به عنوان مثال، یک پیشنهاد ممکن است تعداد پخش‌های صوتی یا ویدیویی را که پیشنهاد دهنده ارسال می‌کند (یا می‌تواند دریافت کند) و اینکه آیا کانال‌های داده باز می‌شوند، نشان دهد.
- منبع همگام سازی (SSRC)
یک SSRC یک شناسه 32 بیتی است که به طور منحصر به فرد یک منبع واحد از یک جریان رسانه را در یک جلسه RTP (پروتکل حمل و نقل بلادرنگ) شناسایی می کند. در WebRTC، SSRC ها برای تمایز بین جریان های رسانه های مختلف که از شرکت کنندگان مختلف یا حتی آهنگ های متفاوت از یک شرکت کننده (مانند دوربین های مختلف) نشات می گیرند، استفاده می شود.
- گیرنده Rtp
همانطور که در
RFC 8829توضیح داده شده است، یک فرستنده گیرنده یک انتزاع در اطراف جریان های RTP در یک جلسه همتا به همتا است.یک فرستنده گیرنده منفرد به یک توصیف رسانه واحد در SDP نگاشت و توصیف می شود. یک فرستنده گیرنده از یک
RtpSenderو یکRtpReceiverتشکیل شده است.از آنجایی که RTP دو طرفه است، هر همتا نمونه فرستنده گیرنده خود را برای همان اتصال RTP دارد.
RtpSenderیک فرستنده گیرنده معین برای همتای محلی به گیرندهRtpReceiverیک فرستنده خاص در همتای راه دور نگاشت می شود. عکس آن نیز صادق است.RtpSenderهمان فرستنده گیرنده همتای راه دور بهRtpReceiverهمتای محلی نگاشت می شود.هر توصیف رسانه ای فرستنده گیرنده اختصاصی خود را دارد. از این رو، یک جلسه همتا به همتا با چندین جریان RTP دارای چندین فرستنده گیرنده با چندین
RtpSendersوRtpReceiverبرای هر همتا است.- جریان های رسانه های مجازی
جریان‌های رسانه مجازی، جریان‌های رسانه‌ای انباشته‌ای هستند که توسط یک واحد ارسال انتخابی (SFU) در کنفرانس‌های WebRTC تولید می‌شوند. به جای اینکه هر شرکت‌کننده جریان‌های جداگانه‌ای را برای دیگران ارسال کند، SFU جریان‌های شرکت‌کننده انتخابی را روی جریان‌های مجازی خروجی کمتری چندگانه می‌کند. این توپولوژی اتصال را ساده می کند و بار شرکت کنندگان را کاهش می دهد و کنفرانس های مقیاس پذیر را امکان پذیر می کند. هر جریان مجازی می‌تواند حاوی رسانه‌هایی از چندین شرکت‌کننده باشد که به صورت پویا توسط SFU مدیریت می‌شود.
موضوعات مرتبط
برای یادگیری نحوه شروع توسعه یک سرویس گیرنده Meet Media API، مراحل را در شروع به کار دنبال کنید.
برای یادگیری نحوه راه‌اندازی و اجرای نمونه مشتری مرجع Meet Media API، شروع سریع کلاینت مرجع C++ را بخوانید.
برای دریافت یک نمای کلی مفهومی، به مفاهیم Meet Media API مراجعه کنید.
برای کسب اطلاعات بیشتر درباره WebRTC، WebRTC For The Curious را ببینید.
برای آشنایی با توسعه با Google Workspace APIها، از جمله رسیدگی به احراز هویت و مجوز، به Develop on Google Workspace مراجعه کنید.