عیب‌یابی و رفع خطاهای Meet Media API

این راهنما دستورالعمل‌هایی درباره نحوه رفع خطاهای رایج Google Meet Media API ارائه می‌دهد.

عیب یابی کدهای خطا

در اینجا نکاتی برای عیب یابی کدهای خطای بازگردانده شده توسط connectActiveConference وجود دارد:

کدهای خطا
NO_ACTIVE_CONFERENCE بررسی کنید که سرویس گیرنده Meet Media API فقط پس از حضور کاربر تأیید شده در کنفرانسی در فضای جلسه تلاش می کند تا متصل شود.
INVALID_OFFER الزامات پیشنهاد را بخوانید تا هرگونه جزئیات گمشده را بررسی کنید، مانند باز کردن کانال‌های مورد نیاز داده‌ها. همچنین می‌توانید رشته پیشنهاد برنامه خود را با پیشنهاد نمونه مقایسه کنید و تفاوت‌ها را بررسی کنید.
INCOMPATIBLE_DEVICE یک یا چند دستگاه در کنفرانس با سرویس گیرندگان Meet Media API سازگار نیست. برنامه شما نمی‌تواند بپیوندد، بنابراین ممکن است این موضوع را به کاربران نهایی خود در میان بگذارید.
CONNECTIONS_EXHAUSTED فقط یک سرویس گیرنده Meet Media API ممکن است در هر زمان به یک کنفرانس متصل شود. اگر برنامه شما از کار بیفتد، در صورت تلاش برای اتصال مجدد، ممکن است این خطا را مشاهده کنید. در این حالت، حدود 30 ثانیه صبر کنید تا Meet اتصال قبلی را متوقف کند. سپس، دوباره امتحان کنید.

طرح یکپارچه

اگر کانال‌های داده هرگز باز نمی‌شوند و هرگز صدا یا تصویر دریافت نمی‌کنید، بررسی کنید که هنگام پیکربندی اتصال همتای محلی فقط از Unified Plan استفاده شود.

خطای سفارش توضیحات رسانه

هنگام ایجاد یک اتصال همتا به همتا با پیشنهاد پروتکل شرح جلسه (SDP) ، ممکن است این خطا را مشاهده کنید:

Failed to execute 'setRemoteDescription' on 'RTCPeerConnection':
Failed to set remote answer sdp:
The order of m-lines in answer doesn't match order in offer. Rejecting answer.

این بدان معناست که خطوط توصیف رسانه در پاسخ SDP با توضیحات رسانه در پیشنهاد SDP مطابقت ندارد:

پیشنهاد SDP پاسخ SDP
✅ m=audio 9 UDP/TLS/RTP/SAVPF 111 ✅ m=audio 9 UDP/TLS/RTP/SAVPF 111
❌ m=video 9 UDP/TLS/RTP/SAVPF 96 97 98 99 ❌ m=audio 9 UDP/TLS/RTP/SAVPF 111
✅ m=audio 9 UDP/TLS/RTP/SAVPF 111 ✅ m=audio 9 UDP/TLS/RTP/SAVPF 111
❌ m=audio 9 UDP/TLS/RTP/SAVPF 111 ❌ m=video 9 UDP/TLS/RTP/SAVPF 96 97 98 99

برای رفع این خطا، هنگام تنظیم شیء اتصال همتا، مطمئن شوید که انواع رسانه های مشابه به درستی پیکربندی شده و با هم گروه بندی شده اند. توصیفات رسانه ای میانبردار پشتیبانی نمی شوند.

نمونه کد زیر نحوه مطابقت صحیح توضیحات رسانه را نشان می دهد:

C++ جاوا اسکریپت 
rtc::scoped_refptr<webrtc::PeerConnectionInterface> peer_connection;

// Signal the entire video at once.
for (uint32_t i = 0; i < configurations.receiving_video_stream_count; ++i) {
    webrtc::RtpTransceiverInit video_init;
    video_init.direction = webrtc::RtpTransceiverDirection::kRecvOnly;
    video_init.stream_ids = {absl::StrCat("video_stream_", i)};

    webrtc::RTCErrorOr<rtc::scoped_refptr<webrtc::RtpTransceiverInterface>>
        video_result = peer_connection->AddTransceiver(
            cricket::MediaType::MEDIA_TYPE_VIDEO, video_init);
  // . . .
}

pc = new RTCPeerConnection();

// Signal the entire video at once.
pc.addTransceiver(video, {'direction':'recvonly'});
pc.addTransceiver(video, {'direction':'recvonly'});
pc.addTransceiver(video, {'direction':'recvonly'});

خطای ویژگی نقش DTLS

هنگام تنظیم ویژگی نقش DTLS، ممکن است این خطا را مشاهده کنید:

All DTLS roles must be one of [ACTIVE, ACTPASS].

این خطا زمانی رخ می دهد که ویژگی a=setup:< > به درستی برای تمام توضیحات رسانه در پیشنهاد SDP تنظیم نشده باشد.

برای رفع این خطا، مطمئن شوید که هر توضیح رسانه در پیشنهاد SDP دارای یکی از ویژگی‌های مورد نیاز زیر است:

  • a=setup:actpass
  • a=setup:active
v=0
o=- 4743178474630771513 3 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE 0 1
a=extmap-allow-mixed
a=msid-semantic: WMS
. . .
m=video 9 UDP/TLS/RTP/SAVPF 96 97 98 99 100 101
. . .
a=setup:actpass
. . .
m=audio 39807 UDP/TLS/RTP/SAVPF 111 63 9 0 8 13 110 126
. . .
a=setup:actpass
. . .

رفع مشکلات صوتی

بخش‌های زیر می‌توانند به حل مشکلات صوتی در برنامه شما کمک کنند.

لاگ ها را بررسی کنید

اگر از سرویس گیرنده وب در مرورگر کروم استفاده می کنید:

  1. یک برگه جدید باز کنید و وارد نوار آدرس شوید: chrome://webrtc-internals .
  2. به بخش با عنوان Stats graph for inbound-rtp بروید.
  3. هر نمودار صوتی را بررسی کنید تا ببینید آیا بسته‌ها دریافت می‌شوند یا خیر.

اگر از مشتری مرجع C++ استفاده می‌کنید، بررسی کنید که آیا OnAudioFrame تاکنون فراخوانی شده است یا خیر.

دامنه های OAuth را تأیید کنید

صدا فقط در صورتی منتقل می شود که محدوده مناسب با درخواست اتصال اولیه ارائه شده باشد. برای رفع خطا، مطمئن شوید که دامنه های OAuth 2.0 صحیح را ارائه کرده اید. برای اطلاعات بیشتر، به حوزه‌های Meet Media API مراجعه کنید.

بررسی کنید که کنفرانس به درستی تنظیم شده است

  • وقتی مشتری با سرورهای Google Meet متصل می شود، به طور خودکار در کنفرانس پذیرفته نمی شود. مطمئن شوید که یک به‌روزرسانی منبع کنترل جلسه را از طریق کانال داده کنترل جلسه با وضعیت STATE_JOINED دریافت کرده‌اید.

    {"sessionStatus":{"connectionState":"STATE_JOINED"}}

  • تأیید کنید که شرکت‌کنندگان دیگری در کنفرانس وجود دارند که پخش‌های صوتی آنها بی‌صدا نیست.

بررسی سیگنال شما برای صدا

Meet فقط در صورتی صدا را ارائه می‌کند که در پیشنهاد SDP به آن علامت دهید. باید سه توصیف رسانه صوتی فقط دریافتی در پیشنهاد وجود داشته باشد.

m=audio 39807 UDP/TLS/RTP/SAVPF 111 63 9 0 8 13 110 126
. . .
a=mid:0
. . .
a=recvonly
. . .
a=rtpmap:111 opus/48000/2
a=rtcp-fb:111 transport-cc
a=fmtp:111 minptime=10;useinbandfec=1
. . .
m=audio 9 UDP/TLS/RTP/SAVPF 111 63 9 0 8 13 110 126
. . .
a=mid:1
. . .
a=recvonly
. . .
a=rtpmap:111 opus/48000/2
a=rtcp-fb:111 transport-cc
a=fmtp:111 minptime=10;useinbandfec=1
. . .
m=audio 9 UDP/TLS/RTP/SAVPF 111 63 9 0 8 13 110 126
. . .
a=mid:2
. . .
a=recvonly
. . .
a=rtpmap:111 opus/48000/2
a=rtcp-fb:111 transport-cc
a=fmtp:111 minptime=10;useinbandfec=1
. . .

اگر یک پیشنهاد معتبر توسط سرورهای Meet دریافت شود، آنها با یک پاسخ SDP با سه توصیف رسانه صوتی فقط برای ارسال پاسخ می دهند.

m=audio 19306 UDP/TLS/RTP/SAVPF 111
. . .
a=mid:0
. . .
a=sendonly
a=msid:virtual-6666 virtual-6666
. . .
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10;useinbandfec=1
. . .
m=audio 9 UDP/TLS/RTP/SAVPF 111
. . .
a=mid:1
. . .
a=sendonly
a=msid:virtual-6667 virtual-6667
. . .
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10;useinbandfec=1
. . .
m=audio 9 UDP/TLS/RTP/SAVPF 111
. . .
a=mid:2
. . .
a=sendonly
a=msid:virtual-6668 virtual-6668
. . .
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10;useinbandfec=1
. . .

اجرای ناظر خود را بررسی کنید

اگر پردازش داده ها را به رشته دیگری منتقل می کنید، حتماً از داده های صوتی کپی تهیه کنید. AudioFrame.pcm16 به طور موثر مرجعی به داده های اساسی است، بنابراین تلاش برای دسترسی به آن پس از OnAudioFrame منجر به رفتار نامشخص، مانند خطای تقسیم بندی می شود.

عیب یابی مشکلات ویدیویی

بخش‌های زیر می‌توانند به حل مشکلات ویدیویی در برنامه شما کمک کنند.

لاگ ها را بررسی کنید

اگر از سرویس گیرنده وب در مرورگر کروم استفاده می کنید:

  1. یک برگه جدید باز کنید و وارد نوار آدرس شوید: chrome://webrtc-internals .
  2. به بخش با عنوان Stats graph for inbound-rtp بروید.
  3. هر گراف ویدئویی را بررسی کنید تا ببینید آیا بسته ها در حال دریافت هستند یا خیر.

اگر از مشتری مرجع C++ استفاده می‌کنید، بررسی کنید که آیا OnVideoFrame تاکنون فراخوانی شده است یا خیر.

دامنه های OAuth را تأیید کنید

ویدئو فقط در صورتی ارسال می شود که محدوده مناسب با درخواست اتصال اولیه ارائه شده باشد. برای رفع خطا، مطمئن شوید که دامنه های OAuth 2.0 صحیح را ارائه کرده اید. برای اطلاعات بیشتر، به حوزه‌های Meet Media API مراجعه کنید.

بررسی کنید که کنفرانس به درستی تنظیم شده است

  • وقتی مشتری با سرورهای Meet متصل می شود، به طور خودکار در کنفرانس پذیرفته نمی شود. مطمئن شوید که یک به‌روزرسانی منبع کنترل جلسه را از طریق کانال داده کنترل جلسه با وضعیت STATE_JOINED دریافت کرده‌اید.

    {"sessionStatus":{"connectionState":"STATE_JOINED"}}

  • تأیید کنید که شرکت‌کنندگان دیگری در کنفرانس وجود دارند که جریان‌های ویدیویی آنها بی‌صدا نیست.

بررسی سیگنال شما برای ویدیو

Meet تنها در صورتی ویدیو را ارائه می‌کند که در پیشنهاد SDP علامت‌گذاری شده باشد. باید حداکثر سه توصیف رسانه ویدیویی، فقط دریافتی، در پیشنهاد وجود داشته باشد. 

v=0
o=- 4743178474630771513 3 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE 0 1
a=extmap-allow-mixed
a=msid-semantic: WMS
. . .
m=video 9 UDP/TLS/RTP/SAVPF 96 97 98 99 100 101 35 36 37 38 102 103 104 105 106 107 108 109 127 125 39 40 41 42 43 44 45 46 47 48 112 113 114 115 116 117 118 49
. . .
a=setup:actpass
a=mid:1
. . .
a=recvonly
. . .
a=rtpmap:96 VP8/90000
a=rtcp-fb:96 goog-remb
a=rtcp-fb:96 transport-cc
a=rtcp-fb:96 ccm fir
a=rtcp-fb:96 nack
a=rtcp-fb:96 nack pli
a=rtpmap:97 rtx/90000
a=fmtp:97 apt=96
. . .

اگر Meet یک پیشنهاد معتبر دریافت کند، با یک پاسخ SDP با n توصیف رسانه ویدیویی فقط ارسال پاسخ می دهد، که در آن n تعداد توضیحات رسانه ویدیویی در پیشنهاد SDP است. 

v=0
o=- 0 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE 0 1
a=msid-semantic: WMS virtual-video-7777/7777
a=ice-lite
. . .
m=video 9 UDP/TLS/RTP/SAVPF 96 97 98 99
. . .
a=setup:passive
a=mid:1
. . .
a=msid:virtual-video-7777/7777 virtual-video-7777/7777
a=rtcp-mux
a=rtpmap:96 VP8/90000
a=rtcp-fb:96 ccm fir
a=rtcp-fb:96 nack
a=rtcp-fb:96 nack pli
a=rtcp-fb:96 goog-remb
. . .

عیب یابی بدون ویدیو

  • بررسی کنید که m=video … در پیشنهاد SDP ارسال شده به سرورهای Meet وجود دارد.
  • بررسی کنید که a=recvonly یک ویژگی زیر هر خط m=video باشد.
  • بررسی کنید که تعداد مساوی خطوط m=video در پاسخ SDP وجود داشته باشد.
  • بررسی کنید که a=sendonly یا a=sendrecv ویژگی های زیر هر خط m=video در پاسخ SDP هستند.
  • بررسی کنید که یک VideoAssignmentRequest موفقیت آمیز به سرورهای Meet ارسال و دریافت شده است. موفقیت یا شکست باید از طریق همان کانال داده به مشتری منتقل شود.

عیب‌یابی جریان‌های ویدیویی کمتر از حد انتظار

  • بررسی کنید که پیشنهاد SDP دارای تعداد صحیح خطوط m=video … باشد.
  • اطمینان حاصل کنید که تمام توضیحات m=video در پاسخ SDP دارای ویژگی a=sendonly یا a=sendrecv هستند. هر خطی که a=recvonly در پاسخ علامت گذاری شده باشد، مقدار استریم های ارسال شده به مشتری را تا این حد کاهش می دهد.

اجرای ناظر خود را بررسی کنید

اگر پردازش داده ها را به رشته دیگری منتقل می کنید، حتماً از داده های ویدیو کپی تهیه کنید. VideoFrame.frame به طور موثر مرجعی به داده های اساسی است، بنابراین تلاش برای دسترسی به آن پس از OnVideoFrame منجر به رفتار نامشخص، مانند خطای تقسیم بندی می شود.

،

این راهنما دستورالعمل‌هایی درباره نحوه رفع خطاهای رایج Google Meet Media API ارائه می‌دهد.

عیب یابی کدهای خطا

در اینجا نکاتی برای عیب یابی کدهای خطای بازگردانده شده توسط connectActiveConference وجود دارد:

کدهای خطا
NO_ACTIVE_CONFERENCE بررسی کنید که سرویس گیرنده Meet Media API فقط پس از حضور کاربر تأیید شده در کنفرانسی در فضای جلسه تلاش می کند تا متصل شود.
INVALID_OFFER الزامات پیشنهاد را بخوانید تا هرگونه جزئیات گمشده را بررسی کنید، مانند باز کردن کانال‌های مورد نیاز داده‌ها. همچنین می‌توانید رشته پیشنهاد برنامه خود را با پیشنهاد نمونه مقایسه کنید و تفاوت‌ها را بررسی کنید.
INCOMPATIBLE_DEVICE یک یا چند دستگاه در کنفرانس با سرویس گیرندگان Meet Media API سازگار نیست. برنامه شما نمی‌تواند بپیوندد، بنابراین ممکن است این موضوع را به کاربران نهایی خود در میان بگذارید.
CONNECTIONS_EXHAUSTED فقط یک سرویس گیرنده Meet Media API ممکن است در هر زمان به یک کنفرانس متصل شود. اگر برنامه شما از کار بیفتد، در صورت تلاش برای اتصال مجدد، ممکن است این خطا را مشاهده کنید. در این حالت، حدود 30 ثانیه صبر کنید تا Meet اتصال قبلی را متوقف کند. سپس، دوباره امتحان کنید.

طرح یکپارچه

اگر کانال‌های داده هرگز باز نمی‌شوند و هرگز صدا یا تصویر دریافت نمی‌کنید، بررسی کنید که هنگام پیکربندی اتصال همتای محلی فقط از Unified Plan استفاده شود.

خطای سفارش توضیحات رسانه

هنگام ایجاد یک اتصال همتا به همتا با پیشنهاد پروتکل شرح جلسه (SDP) ، ممکن است این خطا را مشاهده کنید:

Failed to execute 'setRemoteDescription' on 'RTCPeerConnection':
Failed to set remote answer sdp:
The order of m-lines in answer doesn't match order in offer. Rejecting answer.

این بدان معناست که خطوط توصیف رسانه در پاسخ SDP با توضیحات رسانه در پیشنهاد SDP مطابقت ندارد:

پیشنهاد SDP پاسخ SDP
✅ m=audio 9 UDP/TLS/RTP/SAVPF 111 ✅ m=audio 9 UDP/TLS/RTP/SAVPF 111
❌ m=video 9 UDP/TLS/RTP/SAVPF 96 97 98 99 ❌ m=audio 9 UDP/TLS/RTP/SAVPF 111
✅ m=audio 9 UDP/TLS/RTP/SAVPF 111 ✅ m=audio 9 UDP/TLS/RTP/SAVPF 111
❌ m=audio 9 UDP/TLS/RTP/SAVPF 111 ❌ m=video 9 UDP/TLS/RTP/SAVPF 96 97 98 99

برای رفع این خطا، هنگام تنظیم شیء اتصال همتا، مطمئن شوید که انواع رسانه های مشابه به درستی پیکربندی شده و با هم گروه بندی شده اند. توصیفات رسانه ای میانبردار پشتیبانی نمی شوند.

نمونه کد زیر نحوه مطابقت صحیح توضیحات رسانه را نشان می دهد:

C++ جاوا اسکریپت 
rtc::scoped_refptr<webrtc::PeerConnectionInterface> peer_connection;

// Signal the entire video at once.
for (uint32_t i = 0; i < configurations.receiving_video_stream_count; ++i) {
    webrtc::RtpTransceiverInit video_init;
    video_init.direction = webrtc::RtpTransceiverDirection::kRecvOnly;
    video_init.stream_ids = {absl::StrCat("video_stream_", i)};

    webrtc::RTCErrorOr<rtc::scoped_refptr<webrtc::RtpTransceiverInterface>>
        video_result = peer_connection->AddTransceiver(
            cricket::MediaType::MEDIA_TYPE_VIDEO, video_init);
  // . . .
}

pc = new RTCPeerConnection();

// Signal the entire video at once.
pc.addTransceiver(video, {'direction':'recvonly'});
pc.addTransceiver(video, {'direction':'recvonly'});
pc.addTransceiver(video, {'direction':'recvonly'});

خطای ویژگی نقش DTLS

هنگام تنظیم ویژگی نقش DTLS، ممکن است این خطا را مشاهده کنید:

All DTLS roles must be one of [ACTIVE, ACTPASS].

این خطا زمانی رخ می دهد که ویژگی a=setup:< > به درستی برای تمام توضیحات رسانه در پیشنهاد SDP تنظیم نشده باشد.

برای رفع این خطا، مطمئن شوید که هر توضیح رسانه در پیشنهاد SDP دارای یکی از ویژگی‌های مورد نیاز زیر است:

  • a=setup:actpass
  • a=setup:active
v=0
o=- 4743178474630771513 3 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE 0 1
a=extmap-allow-mixed
a=msid-semantic: WMS
. . .
m=video 9 UDP/TLS/RTP/SAVPF 96 97 98 99 100 101
. . .
a=setup:actpass
. . .
m=audio 39807 UDP/TLS/RTP/SAVPF 111 63 9 0 8 13 110 126
. . .
a=setup:actpass
. . .

رفع مشکلات صوتی

بخش‌های زیر می‌توانند به حل مشکلات صوتی در برنامه شما کمک کنند.

لاگ ها را بررسی کنید

اگر از سرویس گیرنده وب در مرورگر کروم استفاده می کنید:

  1. یک برگه جدید باز کنید و وارد نوار آدرس شوید: chrome://webrtc-internals .
  2. به بخش با عنوان Stats graph for inbound-rtp بروید.
  3. هر نمودار صوتی را بررسی کنید تا ببینید آیا بسته‌ها دریافت می‌شوند یا خیر.

اگر از مشتری مرجع C++ استفاده می‌کنید، بررسی کنید که آیا OnAudioFrame تاکنون فراخوانی شده است یا خیر.

دامنه های OAuth را تأیید کنید

صدا فقط در صورتی منتقل می شود که محدوده مناسب با درخواست اتصال اولیه ارائه شده باشد. برای رفع خطا، مطمئن شوید که دامنه های OAuth 2.0 صحیح را ارائه کرده اید. برای اطلاعات بیشتر، به حوزه‌های Meet Media API مراجعه کنید.

بررسی کنید که کنفرانس به درستی تنظیم شده است

  • وقتی مشتری با سرورهای Google Meet متصل می شود، به طور خودکار در کنفرانس پذیرفته نمی شود. مطمئن شوید که یک به‌روزرسانی منبع کنترل جلسه را از طریق کانال داده کنترل جلسه با وضعیت STATE_JOINED دریافت کرده‌اید.

    {"sessionStatus":{"connectionState":"STATE_JOINED"}}

  • تأیید کنید که شرکت‌کنندگان دیگری در کنفرانس وجود دارند که پخش‌های صوتی آنها بی‌صدا نیست.

بررسی سیگنال شما برای صدا

Meet فقط در صورتی صدا را ارائه می‌کند که در پیشنهاد SDP به آن علامت دهید. باید سه توصیف رسانه صوتی فقط دریافتی در پیشنهاد وجود داشته باشد.

m=audio 39807 UDP/TLS/RTP/SAVPF 111 63 9 0 8 13 110 126
. . .
a=mid:0
. . .
a=recvonly
. . .
a=rtpmap:111 opus/48000/2
a=rtcp-fb:111 transport-cc
a=fmtp:111 minptime=10;useinbandfec=1
. . .
m=audio 9 UDP/TLS/RTP/SAVPF 111 63 9 0 8 13 110 126
. . .
a=mid:1
. . .
a=recvonly
. . .
a=rtpmap:111 opus/48000/2
a=rtcp-fb:111 transport-cc
a=fmtp:111 minptime=10;useinbandfec=1
. . .
m=audio 9 UDP/TLS/RTP/SAVPF 111 63 9 0 8 13 110 126
. . .
a=mid:2
. . .
a=recvonly
. . .
a=rtpmap:111 opus/48000/2
a=rtcp-fb:111 transport-cc
a=fmtp:111 minptime=10;useinbandfec=1
. . .

اگر یک پیشنهاد معتبر توسط سرورهای Meet دریافت شود، آنها با یک پاسخ SDP با سه توصیف رسانه صوتی فقط برای ارسال پاسخ می دهند.

m=audio 19306 UDP/TLS/RTP/SAVPF 111
. . .
a=mid:0
. . .
a=sendonly
a=msid:virtual-6666 virtual-6666
. . .
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10;useinbandfec=1
. . .
m=audio 9 UDP/TLS/RTP/SAVPF 111
. . .
a=mid:1
. . .
a=sendonly
a=msid:virtual-6667 virtual-6667
. . .
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10;useinbandfec=1
. . .
m=audio 9 UDP/TLS/RTP/SAVPF 111
. . .
a=mid:2
. . .
a=sendonly
a=msid:virtual-6668 virtual-6668
. . .
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10;useinbandfec=1
. . .

اجرای ناظر خود را بررسی کنید

اگر پردازش داده ها را به رشته دیگری منتقل می کنید، حتماً از داده های صوتی کپی تهیه کنید. AudioFrame.pcm16 به طور موثر مرجعی به داده های اساسی است، بنابراین تلاش برای دسترسی به آن پس از OnAudioFrame منجر به رفتار نامشخص، مانند خطای تقسیم بندی می شود.

عیب یابی مشکلات ویدیویی

بخش‌های زیر می‌توانند به حل مشکلات ویدیویی در برنامه شما کمک کنند.

لاگ ها را بررسی کنید

اگر از سرویس گیرنده وب در مرورگر کروم استفاده می کنید:

  1. یک برگه جدید باز کنید و وارد نوار آدرس شوید: chrome://webrtc-internals .
  2. به بخش با عنوان Stats graph for inbound-rtp بروید.
  3. هر گراف ویدئویی را بررسی کنید تا ببینید آیا بسته ها در حال دریافت هستند یا خیر.

اگر از مشتری مرجع C++ استفاده می‌کنید، بررسی کنید که آیا OnVideoFrame تاکنون فراخوانی شده است یا خیر.

دامنه های OAuth را تأیید کنید

ویدئو فقط در صورتی ارسال می شود که محدوده مناسب با درخواست اتصال اولیه ارائه شده باشد. برای رفع خطا، مطمئن شوید که دامنه های OAuth 2.0 صحیح را ارائه کرده اید. برای اطلاعات بیشتر، به حوزه‌های Meet Media API مراجعه کنید.

بررسی کنید که کنفرانس به درستی تنظیم شده است

  • وقتی مشتری با سرورهای Meet متصل می شود، به طور خودکار در کنفرانس پذیرفته نمی شود. مطمئن شوید که یک به‌روزرسانی منبع کنترل جلسه را از طریق کانال داده کنترل جلسه با وضعیت STATE_JOINED دریافت کرده‌اید.

    {"sessionStatus":{"connectionState":"STATE_JOINED"}}

  • تأیید کنید که شرکت‌کنندگان دیگری در کنفرانس وجود دارند که جریان‌های ویدیویی آنها بی‌صدا نیست.

بررسی سیگنال شما برای ویدیو

Meet تنها در صورتی ویدیو را ارائه می‌کند که در پیشنهاد SDP علامت‌گذاری شده باشد. باید حداکثر سه توصیف رسانه ویدیویی، فقط دریافتی، در پیشنهاد وجود داشته باشد. 

v=0
o=- 4743178474630771513 3 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE 0 1
a=extmap-allow-mixed
a=msid-semantic: WMS
. . .
m=video 9 UDP/TLS/RTP/SAVPF 96 97 98 99 100 101 35 36 37 38 102 103 104 105 106 107 108 109 127 125 39 40 41 42 43 44 45 46 47 48 112 113 114 115 116 117 118 49
. . .
a=setup:actpass
a=mid:1
. . .
a=recvonly
. . .
a=rtpmap:96 VP8/90000
a=rtcp-fb:96 goog-remb
a=rtcp-fb:96 transport-cc
a=rtcp-fb:96 ccm fir
a=rtcp-fb:96 nack
a=rtcp-fb:96 nack pli
a=rtpmap:97 rtx/90000
a=fmtp:97 apt=96
. . .

اگر Meet یک پیشنهاد معتبر دریافت کند، با یک پاسخ SDP با n توصیف رسانه ویدیویی فقط ارسال پاسخ می دهد، که در آن n تعداد توضیحات رسانه ویدیویی در پیشنهاد SDP است. 

v=0
o=- 0 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE 0 1
a=msid-semantic: WMS virtual-video-7777/7777
a=ice-lite
. . .
m=video 9 UDP/TLS/RTP/SAVPF 96 97 98 99
. . .
a=setup:passive
a=mid:1
. . .
a=msid:virtual-video-7777/7777 virtual-video-7777/7777
a=rtcp-mux
a=rtpmap:96 VP8/90000
a=rtcp-fb:96 ccm fir
a=rtcp-fb:96 nack
a=rtcp-fb:96 nack pli
a=rtcp-fb:96 goog-remb
. . .

عیب یابی بدون ویدیو

  • بررسی کنید که m=video … در پیشنهاد SDP ارسال شده به سرورهای Meet وجود دارد.
  • بررسی کنید که a=recvonly یک ویژگی زیر هر خط m=video باشد.
  • بررسی کنید که تعداد مساوی خطوط m=video در پاسخ SDP وجود داشته باشد.
  • بررسی کنید که a=sendonly یا a=sendrecv ویژگی های زیر هر خط m=video در پاسخ SDP هستند.
  • بررسی کنید که یک VideoAssignmentRequest موفقیت آمیز به سرورهای Meet ارسال و دریافت شده است. موفقیت یا شکست باید از طریق همان کانال داده به مشتری منتقل شود.

عیب‌یابی جریان‌های ویدیویی کمتر از حد انتظار

  • بررسی کنید که پیشنهاد SDP دارای تعداد صحیح خطوط m=video … باشد.
  • اطمینان حاصل کنید که تمام توضیحات m=video در پاسخ SDP دارای ویژگی a=sendonly یا a=sendrecv هستند. هر خطی که a=recvonly در پاسخ علامت گذاری شده باشد، مقدار استریم های ارسال شده به مشتری را تا این حد کاهش می دهد.

اجرای ناظر خود را بررسی کنید

اگر پردازش داده ها را به رشته دیگری منتقل می کنید، حتماً از داده های ویدیو کپی تهیه کنید. VideoFrame.frame به طور موثر مرجعی به داده های اساسی است، بنابراین تلاش برای دسترسی به آن پس از OnVideoFrame منجر به رفتار نامشخص، مانند خطای تقسیم بندی می شود.