تست استریم واقعی وبکم و نمای طرف مقابل

پیشنمایش وبکم نمای محلی است نه خروجی سنسور؛ آنچه طرف مقابل میبیند استریمی است که WebRTC بیصدا فشرده و احتمالاً تنزل داده است. این راهنما مذاکره کدک، اندازهگیری پارامترهای واقعی استریم با getStats() و رفع علل رایج افت کیفیت را توضیح میدهد.

در یک تماس ویدیویی نشستهاید و پنجره خودتان تصویری شارپ و روشن 1080p نشان میدهد. خوشتیپ به نظر میرسید، پسزمینه تمیز است و کادر درست. بعد یک همکار میگوید ویدیوی شما مدام یخ میزند و تار است، و وقتی صفحهاش را اشتراک میگذارد، خودتان را تصویری بلوکی با لبههای نرم میبینید که یک وبکم ارزانقیمت ده سال پیش هم میتوانست تولید کند. همان دوربین. همان نور. همان دستگاه. تصویری متفاوت.

اینجا همان چیزی است که بیشتر راهنماهای تماس ویدیویی از قلم میاندازند: آن فاصله معمولاً خطای سختافزاری یا نقص سنسور نیست — گرچه درایور بدرفتار گاهی هم میتواند باعثش شود. معمولاً تفاوت بین چیزی است که دوربین شما تولید میکند و چیزی که مرورگرتان واقعاً میفرستد. پیشنمایش شما از مسیر ضبط محلی تغذیه میشود — فریمی که دوربین تولید کرده و از طریق getUserMedia() تحویل شده — پیش از رمزگذاری WebRTC، که آن را نمای مطلوبتری از ویدیوی شما نسبت به آنچه سایر شرکتکنندگان دریافت میکنند میسازد. آن نما ممکن است همچنان شامل مقیاسبندی، تبدیل رنگ یا پردازش محدودیتهایی باشد که مرورگر اعمال میکند، پس خروجی خام سنسور نیست. چیزی که سایر شرکتکنندگان دریافت میکنند، استریمی فشرده است که در میلیثانیههای پیش از خروج از دستگاه شما توسط WebRTC مذاکره، رمزگذاری مجدد، محدود نرخ و احتمالاً تنزل شده است.

آن لایه رمزگذاری از رابط کاربری نامرئی و در عملکرد عادی بیصدا است. هیچ چیزی در پنجره تماس نمیگوید وجود دارد، هیچ چیزی تصمیمهایش را گزارش نمیکند و هیچ چیزی در پیشنمایش شما آنها را بازتاب نمیدهد. صحنهای آشنا: کاربری ساعتها صرف نصب دوباره درایور دوربین میکند چون تماس ویدیویی تار نشان میدهد — فقط بعداً از طریق chrome://webrtc-internals کشف میکند که مرورگر بر اساس تخمین پهنای باند به 480p15 پایین مذاکره کرده بود، نه بهخاطر دوربین یا درایور. این صفحه توضیح میدهد بین سنسور دوربین و صفحه همکارِ تماس شما چه اتفاقی میافتد، چرا مرورگر بیصدا کیفیت شما را پایین میآورد و — مهمتر از همه — چگونه استریم واقعی در حال خروج از دستگاهتان را اندازه بگیرید بهجای اعتماد به پیشنمایش.

آنچه پیشنمایش شما نشان نمیدهد

تماس ویدیویی بر خط لولهای استوار است که کاملاً خارج از آگاهی شما اجرا میشود. هر فریمی که میفرستید مراحل زیر را میگذراند:

1. سنسور دوربین یک فریم میگیرد؛ مرورگر سپس آن را از طریق getUserMedia() با وضوح و نرخ فریم درخواستی تحویل میدهد، که ممکن است شامل مقیاسبندی، تبدیل رنگ و پردازش محدودیتها باشد.
2. مرورگر آن فریم را از طریق API getUserMedia() دریافت و به موتور WebRTC میدهد. پیشنمایش محلی شما از همین مرحله تغذیه میشود — برای همین است که همیشه بینقص به نظر میرسد، فارغ از اینکه بعداً چه اتفاقی میافتد.
3. رمزگذار WebRTC فریم را با کدک مذاکرهشده، در وضوح، نرخ فریم و نرخ بیت مذاکرهشده، به یک بیتاستریم فشرده میکند.
4. فریم رمزگذاریشده به بستههای RTP تقسیم و از شبکه ارسال میشود، معمولاً از طریق سرور رسانهای که آن را به بقیه بازپخش میکند.
5. هر گیرنده بستهها را رمزگشایی میکند و به تصویر برمیگرداند و روی صفحهاش رندر میکند.

پیشنمایش شما در مرحله دو به خط لوله متصل میشود. فریمی را نمایش میدهد که دوربین تولید کرده و از طریق getUserMedia() تحویل شده، پیش از رمزگذاری WebRTC. مرورگر ممکن است در این مرحله مقیاسبندی، تبدیل رنگ یا پردازش محدودیتها اعمال کند، اما هیچ فشردهسازی WebRTC اعمال نمیشود. استریمی که همکار تماس شما میبیند همان چیزی است که از مرحله سه بیرون میآید. بین این دو نقطه، رمزگذار تصمیم میگیرد دنیا چه چیزی دریافت کند و آن تصمیم را بر اساس شرایطی میگیرد که هرگز نمیبینید.

رمزگذار بیصدا سه پارامتر را مذاکره میکند و هر کدام میتواند وسط تماس بدون هیچ اعلانی تغییر کند:

• وضوح — عرض و ارتفاع فریمهای رمزگذاریشده، که میتواند خودبهخود از 1920 در 1080 به 1280 در 720 یا 640 در 480 افت کند.
• نرخ فریم — چند فریم در ثانیه از رمزگذاری جان سالم به در میبرد، که معمولاً اول افت میکند (از 30 به 15 یا پایینتر)، چون نصفکردن نرخ فریم نرخ داده را بدون تغییر وضوح نصف میکند — گرچه برخی پیادهسازیها بسته به کدک و پلتفرم ممکن است بهجایش وضوح را کم کنند.
• نرخ بیت — چند بیت در ثانیه رمزگذار مجاز است خرج کند، که سطح کلی فشردهسازی را تعیین میکند.

این سه مقدار هر چیزی را که طرف دیگر میبیند تعیین میکنند. تصویر 1080p فشردهشده در نرخ بیت پایین نرم و لکهدار دیده میشود. استریم 30 فریمی که ناگهان با 10 فریم اجرا میشود یخی و غیرطبیعی دیده میشود. وقتی بدانید پیشنمایش هیچیک از این مقادیر را گزارش نمیکند، معمای تماس بد با دوربین عالی حل میشود.

SDP پیش از ارسال اولین فریم مذاکره میکند

مذاکره پیش از ارسال اولین فریم آغاز میشود. وقتی به تماسی میپیوندید، پلتفرم و مرورگر شما یک پیشنهاد و پاسخ پروتکل توصیف جلسه (SDP) تبادل میکنند. SDP کدکها و قابلیتهای رسانهای را که هر طرف پشتیبانی میکند آگهی میکند؛ وضوح و نرخ فریم واقعی سپس از طریق پارامترهای ارسال و دریافت بیشتر مذاکره و توسط تخمین پهنای باند محدود میشوند. در آزمون غیررسمی روی Chrome 125 در ویندوز 10 (می 2024)، مشاهده شد که پاسخ SDP اول VP9 را پیشنهاد میدهد، بعد H.264 و بعد VP8؛ در Safari 17 روی macOS 14 (همان دوره)، H.264 اول ظاهر شد. این مشاهدات روی یک دستگاه واحد برای هر مرورگر و بدون شرایط شبکهای کنترلشده انجام شد، پس تنوع موجود را نشان میدهند، نه یک ترتیب جهانی را تعریف نمیکنند. کدک واقعی انتخابشده به مرورگر، پلتفرم، پارامترهای SDP و قابلیتهای سختافزار بستگی دارد. انتخابهای رایج VP9، H.264، VP8 و AV1 هستند، اما هیچ ترتیب ترجیحی ثابت واحدی در همه پلتفرمها وجود ندارد.

انتخاب کدک فقط آغاز است. وقتی تماس فعال شد، مکانیزم دومی کار را میگیرد: تخمین پهنای باند. WebRTC بهطور پیوسته مسیر شبکه را در هر دو جهت زیر نظر میگیرد و یک الگوریتم کنترل ازدحام اجرا میکند — معمولاً Google Congestion Control — که سه اندازهگیری را بهصورت چرخشی انجام میدهد:

• افت بسته که گیرنده از طریق پیامهای بازخورد RTCP گزارش میکند.
• زمان رفتوبرگشت، تأخیر بین فرستادن یک بسته و دریافت تأیید رسیدن آن.
• گذردهی، نرخ مؤثری که داده واقعاً از اتصال عبور میکند.

الگوریتم این اندازهگیریها را به مدلی میریزد که تخمین میزند شبکه در حال حاضر چقدر پهنای باند میتواند حمل کند. آن تخمین به نرخ بیت هدف تبدیل میشود که به رمزگذار داده میشود و رمزگذار خروجیاش را مطابق آن تنظیم میکند. حلقه پیوسته و سریع است: وقتی تخمین افت میکند، رمزگذار در کسری از ثانیه با نرخ بیت پایینتر دوباره رمزگذاری میکند.

آستانهها تقریبیاند و به الگوریتم کنترل ازدحام خاص مورد استفاده بستگی دارند. افت پایدار بسته بالای حدود پنج درصد میتواند کاهش نرخ بیت هدف را فعال کند، اما رفتار دقیق — چقدر نرخ افت کند، آیا وضوح یا نرخ فریم هم تغییر کند و در چه سطح افت — با الگوریتم، کدک و پلتفرم فرق میکند. هیچ نگاشت جهانیای از درصد افت به وضوح خروجی خاص وجود ندارد. حلقه بازخوردی که این تصمیمات را میراند در این مراجع تعریف شده است (Google: WebRTC Congestion Control Whitepaper, 2019؛ RFC 8888: Congestion Control Feedback for RTP). استریم 1080p با 30 فریم بر ثانیه معمولاً برای تمیز دیدهشدن به حدود چهار تا شش مگابیت بر ثانیه پهنای باند آپلود نیاز دارد، گرچه این به کدک، تنظیمات رمزگذاری و پیچیدگی صحنه بستگی دارد. اگر تخمینزننده نتیجه بگیرد فقط یک مگابیت در دسترس است، سعی نمیکند استریم را بهزور عبور دهد — هدف را پایین میآورد و رمزگذار با کاهش وضوح به 480p و نرخ فریم به 15 پاسخ میدهد. اگر تخمین بیشتر پایین بیاید، تصویر دوباره افت میکند، همه راه تا یک سرِ سخنگوی 320 در 240. هر قدم عمدی است: هدف زنده نگهداشتن تماس و پایدار نگهداشتن صوتی است و کیفیت ویدیو اولین چیزی است که برای رسیدن به آن قربانی میشود.

سه الگوی خرابی که استریم شما پنهان میکند

پیشنمایش حالت واقعی استریم را پشت سه الگوی خرابی تکرارشونده پنهان میکند. یاد بگیرید هر کدام را از روی عارضههایش بشناسید، چون راهحل درست برای هر مورد فرق دارد. هر سه یک نشانه مشترک دارند: پیشنمایش تمام مدت بینقص میماند، چون قبل از رمزگذار نمونهبرداری میشود. فقط استریم رمزگذاریشده — و بنابراین صفحههای سایر شرکتکنندگان — آسیب را نشان میدهد.

تله نرخ بیت

عارضهها: پیشنمایش شما بینقص است و CPU دستگاه بیکار. طرف دیگر تصویری تار و کمکوضوح میبیند که هرگز شارپ نمیشود، حتی هنگام مکث. ضبطهای محلی عالیاند؛ تماس ضعیف است.

تشخیص: مرورگر تخمین زده که شبکه نمیتواند استریم کامل را حمل کند و نرخ بیت را سقف بسته و رمزگذار را مجبور به کوچککردن وضوح کرده است. محدودیت پهنای باند آپلود شما یا ظرفیت بازپخش سرور رسانه است، نه دوربین شما. یک تست سرعت اجرا کنید و آپلود اندازهگیریشده خود را با چهار تا شش مگابیتی که 1080p30 نیاز دارد مقایسه کنید. اگر اتصال را با دستگاههای دیگری که استریم میکنند، دانلود میکنند یا سینک میکنند به اشتراک میگذارید، آنها برای همان بودجه رقابت میکنند.

آستانه افت بسته

عارضهها: تصاویر ثابت تماس خوباند، اما هر حرکتی یخی و رباتیک است. صدا نرم میماند در حالی که ویدیو میلرزد، و هر چند ثانیه یک بار یخزدگیهای کوتاه اتفاق میافتد قبل از اینکه تصویر با نرخ فریم پایینتر از سر گرفته شود.

تشخیص: افت بسته بهطور متناوب از آستانه پنج درصد عبور میکند، پس کنترلکننده ازدحام بارها نرخ بیت هدف را میبُرد و رمزگذار برای هماهنگی فریم میاندازد. نرخ فریم اول افت میکند چون ارزانترین اهرم است — کاهش از 30 به 15 فریم بر ثانیه نرخ داده را بدون تغییر وضوح نصف میکند. تداخل Wi-Fi، کابل اترنت ضعیف یا VPN که افت و تأخیر اضافه میکند را بررسی کنید. ویدیو تا وقتی مسیر شبکه تعمیر نشود به افت ادامه میدهد.

یخزدگی فریم کلیدی

عارضهها: در دو تا پنج ثانیه اول پس از پیوستن، یا پس از اشتراکگذاری صفحه، طرف دیگر تصویری یخزده یا بهشدت لکهدار میبیند. بعد تصویر شفاف میشود و تا تغییر صحنه بزرگ بعدی عادی رفتار میکند.

تشخیص: کدکهای ویدیو دو نوع فریم میفرستند. فریمهای کلیدی کل تصویر را رمزگذاری میکنند و در بازه ثابت ظاهر میشوند — معمولاً هر یک تا ده ثانیه بسته به پلتفرم و پیکربندی. فریمهای دلتا فقط تغییرات نسبت به فریم قبلی را رمزگذاری میکنند که آنها را کوچک میکند. اگر بستهای از یک فریم دلتا گم شود، گیرنده نمیتواند آن فریم را بازسازی کند — میتواند بازارسال (NACK) درخواست کند، از فرستنده فریم کلیدی تازه بخواهد (PLI یا FIR) یا در انتظار، خطا را مخفی کند. وقتی درخواست موفق شود، بازیابی سریع است؛ وقتی نشود، تصویر تا رسیدن فریم کلیدی زمانبندیشده بعدی یخزده میماند. همان انتظار، یخزدگیای است که میبینید. بازههای فریم کلیدی کوتاه سریعتر بازیابی میکنند اما پهنای باند میخورند؛ بازههای بلند کارآمدند اما هر افت را بیشتر قابل دید میکنند. این نقص نیست — این کدک است که همانطور که طراحی شده کار میکند.

اندازهگیری استریم واقعی با getStats()

حدسزدن را کنار بگذارید. اعداد چاپلوس نیستند، اما درستاند. API WebRTC یک رابط آمار در معرض دید قرار میدهد که دقیقاً گزارش میدهد رمزگذار چه میکند و هر صفحهای که کنترلش با شماست میتواند اتصال همتا خودش را بخواند. روی شیء RTCPeerConnection متد getStats() را صدا بزنید و بعد گزارش برگشتی را برای مدخل outbound-rtp که kindاش video است فیلتر کنید. در مدخلهای media-source و outbound-rtp مقادیری را مییابید که اهمیت دارند:

• framesPerSecond (روی مدخل media-source) — نرخ فریمی که دوربین به رمزگذار تحویل میدهد. اگر روی دوربین 30 فریمی زیر 30 باشد، خود مسیر ضبط مشکل است — غالباً مشکل ازدحام پهنای باند USB است؛ راهنمای ما دربارهٔ ازدحام پهنای باند USB توضیح میدهد چگونه آن را تشخیص دهید.
• framesPerSecond (روی مدخل outbound-rtp) — نرخ فریمی که رمزگذار واقعاً تولید میکند. وقتی این از نرخ ورودی پایینتر است، رمزگذار فریم میاندازد.
• frameWidth و frameHeight (روی مدخل outbound-rtp) — وضوح رمزگذاریشده. با تنظیمات تماس خود مقایسه کنید؛ هر تفاوتی یک تنزل بیصدا است.
• bytesSent (روی مدخل outbound-rtp) — کل داده رمزگذاریشده. دو بار با فاصله یک ثانیه نمونه بگیرید و اختلاف ضربدر 8 را محاسبه کنید تا نرخ بیت واقعی را به دست آورید.
• packetsSent و packetsLost — توجه کنید که packetsLost روی مدخل outbound-rtp همیشه پر نمیشود؛ نسبت افت با اطمینان بیشتری از مدخل remote-inbound-rtp خوانده میشود که دیدگاه گیرنده را گزارش میکند.
• currentRoundTripTime (روی مدخل candidate-pair) — تأخیر شبکه. RTT بالا همراه با افت نشاندهنده ازدحام است.

مرورگرهای مختلف ممکن است نام فیلدهای کمی متفاوت گزارش کنند یا برخی آمارها را کلاً حذف کنند، پس وقتی در دسترس بود با صفحه WebRTC internals مرورگر چک متقاطع بزنید.

قواعد تفسیر سادهاند. اگر framesPerSecond خروجی-rtp بهطور قابل دید زیر framesPerSecond منبع-رسانه است، رمزگذار زیر فشار فریم میریزد. اگر frameWidth و frameHeight زیر وضوحی است که پیکربندی کردهاید، بودجه اتصال نتوانسته آن را حمل کند. اگر bytesSent به نرخ بیتی بسیار پایینتر از نیاز کدک برای آن وضوح ترجمه میشود، تصویر در حال لهشدن است — و پیشنمایش که هرگز رمزگذار را نمیبیند، تمام مدت خوب به نظر میرسد.

برای خواندن این مقادیر لازم نیست کد بنویسید. کروم و اج یک نمایشگر آمار داخلی در chrome://webrtc-internals دارند که هر اتصال WebRTC در مرورگر را میگیرد، از جمله اتصالی که پلتفرم تماس ساخته است. پیش از پیوستن به جلسه آن را باز کنید، بگذارید ضبط کند و بعد مدخلهای outbound-rtp فرستنده ویدیو را بررسی کنید. همان نرخ فریم، وضوح، نرخ بیت و افت آنجا هستند، همراه با نمودار زمانی که دقیقاً نشان میدهد رمزگذار چه زمانی خروجیاش را تغییر داد. این سریعترین راه برای گرفتن یک تنزل در عمل روی تماس پلتفرم واقعی است.

این اندازهگیری را وقتی تماس خودتان در پسزمینه بیکار است اجرا کنید و بار دیگر در یک جلسه شلوغ، و دو مجموعه عدد را مقایسه کنید. یک مقایسه معمول: بیکار، framesPerSecond خروجی-rtp عدد 30 را میخواند؛ در جلسه شلوغ میتواند به 18 بیفتد در حالی که پیشنمایش محلی همچنان 30 نشان میدهد. همان مقایسه آشکار میکند که آیا شبکه پایه شما کافی است و آیا ازدحام هنگام تماس همان چیزی است که تنزل را فعال میکند. تست وبکم ما وضوح و نرخ فریم ترک ضبط محلی را آنطور که از طریق getUserMedia() مذاکره شده نشان میدهد — خط پایه مفیدی برای آنچه دوربین شما میتواند به مرورگر تحویل دهد، اما اندازهگیری استریم رمزگذاریشده خروجی WebRTC نیست، که به یک اتصال همتا یا صفحه WebRTC internals مرورگر نیاز دارد.

Zoom، Meet، Teams: سه دوربین متفاوت

همان دوربین، همان لپتاپ و همان شبکه میتوانند نتایج قابل دید متفاوتی در برنامههای مختلف تولید کنند، چون هر پلتفرم سیاست رمزگذاری خودش را روی پیادهسازی WebRTC مرورگر اعمال میکند.

• Zoom معمولاً پایداری را اولویت میگذارد. بسته به نسخه، نوع حساب و تنظیمات جلسه، ممکن است وضوح خروجی را سقف بزند و کیفیت ویدیو را برای پایدار نگهداشتن صدا و اشتراک صفحه قربانی کند. دوربین با قابلیت 1080p ممکن است روی Zoom با 720p یا پایینتر ارسال کند.
• Google Meet تمایل دارد با پهنای باند اندازهگیریشده سازگار شود و وضوح را زود میاندازد و وقتی شرایط بهبود یافت سریع بازمیگرداند. رفتارش وضعیت شبکه واقعی شما را دنبال میکند، چه بد چه خوب.
• Microsoft Teams خط لوله رمزگذاری و پردازش پس از تولید خودش را اعمال میکند. بسته به نسخه و تنظیمات جلسه، تصویر ممکن است فراتر از مذاکره خام WebRTC فشردهتر شود.
• WebRTC بومی مرورگر، همان نوعی که در یک صفحه وب خالی میگیرید، استریم مذاکرهشده را بدون هیچ سیاست پلتفرمی روی آن میفرستد. نزدیکترین چیز به حقیقت زمینی است برای آنچه سختافزار و شبکه شما زیر WebRTC خام میتوانند تحویل دهند. سیاستهای پلتفرم با نسخه، نوع حساب و پیکربندی جلسه فرق میکنند، پس اینها را گرایشهای عمومی تلقی کنید نه قواعد ثابت.

نتیجه عملی: مقایسه تماس Zoom با تماس Meet یک تست دوربین نیست. تست تصمیمهای رمزگذاری هر پلتفرم است. اول استریم خام را با یک صفحه WebRTC ساده یا ابزار تست وبکم اندازه بگیرید. اگر استریم خام تمیز است و یک پلتفرم همچنان بد است، سیاست پلتفرم محدودیت است و هیچ ارتقای سختافزاری آن را تغییر نمیدهد. وقتی تماس پلتفرمی در جریان است، chrome://webrtc-internals به شما اجازه میدهد تصمیمهای رمزگذار را زنده تماشا کنید، پس میتوانید بدون اعتماد به گزارش خود هیچ طرف، ببینید تنزل سیاست پلتفرم است یا رفتار شبکه.

هفت قدم تا یک استریم تمیز

این قدمها علتهای جدا را منزوی میکنند. به محض اینکه استریم درست به نظر رسید میتوانید متوقف شوید — اما قبل و بعد از هر تغییر اندازه بگیرید تا تأیید کنید اصلاح واقعاً اعداد را حرکت داده است.

1. اول اندازه بگیرید. chrome://webrtc-internals را باز کنید یا از getStats() روی اتصال همتای خودتان استفاده کنید و وضوح، نرخ فریم و نرخ بیت را ثبت کنید. اگر استریم خام از قبل تنزل یافته، دوربین و اتصال شما مشکلاند. اگر تمیز است، پلتفرم است.
2. پهنای باند را بررسی کنید. تماس ویدیویی به حداقل 1 مگابیت بر ثانیه آپلود برای 720p و تقریباً 4 مگابیت برای 1080p نیاز دارد. از همان دستگاهی که با آن تماس میگیرید تست بگیرید، نه دستگاه دیگر، و با وجود ترافیک دیگر روی شبکه دوباره تست کنید. اگر میتوانید به اتصال باسیم بروید؛ افت Wi-Fi رایجترین علت تنزلهای نامرئی است.
3. نور را درست کنید. سوژه خوشنور بهطور قابل توجهی بهتر از تاریک فشرده میشود، چون رمزگذار نرخ بیت را صرف جزئیات قابل دید میکند نه نویز. رو به پنجره بنشینید یا از منبع نور نرم استفاده کنید. این هیچ هزینهای ندارد و اغلب بهبودی بزرگتر از هر تنظیمی میدهد.
4. کاهش نویز ویدیو را غیرفعال کنید وقتی محیطتان از قبل ساکت و خوشنور است. برخی پلتفرمها در صحنههای کمنور کاهشنویز تهاجمی اعمال میکنند که میتواند جزئیات ریز را در استریم رمزگذاریشده بهطور قابل دید نرم کند. پیشنمایش محلی این تفاوت را نشان نمیدهد؛ فقط استریم رمزگذاریشده. تنظیمات پلتفرم خاص را بررسی کنید تا تأیید کنید چه کنترلهایی در دسترساند.
5. پسزمینه مجازی را غیرفعال کنید. تفکیک پسزمینه سرباری به نرخ بیت مؤثر اضافه میکند و چرخههای GPU را از رمزگذار میگیرد. پسزمینه واقعی تمیز با نور یکنواخت از هر پسزمینه مجازی بهتر است.
6. کدک را بررسی کنید. اگر CPU شما از پسش برمیآید، VP9 بهترین کیفیت به ازای هر بیت را میدهد؛ اگر افت فریم یا پرش CPU میبینید، H.264 سریعتر رمزگذاری میکند. برخی پلتفرمها ترجیح کدک را در تنظیمات در معرض دید قرار میدهند.
7. پلتفرم دیگری را تست کنید. اگر کیفیت روی یک سرویس خوب و روی سرویس دیگر بد است، سیاست رمزگذاری پلتفرم محدودیت است. انتظارات یا ابزار جلسهتان را مطابق آن تنظیم کنید — سختافزار شما مقصر نیست.

جمعبندی

پیشنمایش تصویر شخصی محلی دوربین شماست: نمایی مطلوب از آنچه دوربین میتواند به مرورگر تحویل دهد. استریم چیزی است که دنیا واقعاً میبیند — مذاکرهشده، فشرده و شکلگرفته توسط شرایط شبکه و سیاست پلتفرم. آنها دو ویدیوی متفاوت از همان سوژهاند و فقط یکی از آنها برای اینکه چطور به نظر میرسید اهمیت دارد. اگر تا به حال فکر کردهاید چرا دوربینتان روی صفحه شما عالی اما در تماس افتضاح است، حالا پاسخ و ابزار اندازهگیری آن را دارید.

chrome://webrtc-internals را باز کنید. به تماس بعدی بپیوندید. مدخلهای outbound-rtp را تماشا کنید. اگر frameWidth یا framesPerSecond پایینتر از چیزی است که در تنظیمات دوربین تعیین کردهاید، تنزل در حال وقوع است. علت معمولاً به پهنای باند مربوط است — اینکه مرورگر شما مجاز است چقدر خرج کند و آیا اتصال شما واقعاً میتواند استریمی را که فکر میکنید میفرستید حمل کند — اما بار CPU، انتخاب رمزگذار، سیاستهای پلتفرم و پیکربندی محدودیتها هم میتوانند در افت نقش داشته باشند یا بر آن مسلط شوند.