ওয়েবক্যাম স্ট্রিম — অন্য দিকে কী দেখে

আপনি ওয়েবক্যাম প্রিভিউতে যা দেখেন তা একটি লোকাল ক্যাপচার ভিউ — getUserMedia() এর মাধ্যমে ক্যামেরা ফিড। আপনার ভিডিও কল প্রাপক যা দেখেন তা একটি ব্রাউজার-এনকোডেড স্ট্রিম যা WebRTC দ্বারা নেগোশিয়েট, কম্প্রেস এবং সম্ভবত ডাউনগ্রেড করা হয়েছে। এই গাইড WebRTC codec নেগোশিয়েশন কীভাবে কাজ করে, getStats() ব্যবহার করে রিয়েল স্ট্রিম প্যারামিটার পরিমাপ করা, এবং কোয়ালিটি লসের সাধারণ কারণ ঠিক করা ব্যাখ্যা করে।

আপনি একটি ভিডিও কলে বসে আছেন এবং আপনার নিজের উইন্ডো একটি স্পষ্ট, ভালভাবে আলোকিত ১০৮০p চিত্র দেখায়। আপনি তীক্ষ্ণ দেখাচ্ছেন, ব্যাকগ্রাউন্ড পরিষ্কার, এবং ফ্রেমিং ঠিক আছে। তারপর একজন সহকর্মী বলেন আপনার ভিডিও জমে যাচ্ছে এবং অস্পষ্ট দেখাচ্ছে, এবং যখন তারা তাদের স্ক্রিন শেয়ার করেন আপনি নিজেকে একটি ব্লকি, নরম-প্রান্তের ছবি হিসেবে দেখেন যা এক দশক আগের একটি বাজে ওয়েবক্যামও উৎপাদন করত। একই ক্যামেরা। একই আলো। একই মেশিন। একটি ভিন্ন চিত্র।

বেশিরভাগ ভিডিও কল গাইড যা এড়িয়ে যায়: সেই ব্যবধান সাধারণত হার্ডওয়্যার ত্রুটি বা সেন্সর ত্রুটি নয় — যদিও একটি অসুস্থ ড্রাইভার মাঝে মাঝে এটি ঘটাতে পারে। এটি সাধারণত আপনার ক্যামেরা যা উৎপাদন করে এবং আপনার ব্রাউজার আসলে যা পাঠায় তার মধ্যে পার্থক্য। আপনার প্রিভিউ লোকাল ক্যাপচার পথ থেকে খাওয়ানো হয় — getUserMedia() এর মাধ্যমে ক্যামেরা যা উৎপাদন করেছে সেই ফ্রেম — WebRTC এনকোডিংয়ের আগে, যা এটিকে আপনার ভিডিওর চেয়ে একটি অনুকূল দৃশ্য তৈরি করে যা অন্য অংশগ্রহণকারীরা পান। সেই দৃশ্যে ব্রাউজার প্রয়োগ করা স্কেলিং, কালার কনভার্সন, বা কনস্ট্রেইন্ট প্রসেসিং অন্তর্ভুক্ত থাকতে পারে, তাই এটি র সেন্সর আউটপুট নয়। অন্য অংশগ্রহণকারীরা যা পান তা একটি কম্প্রেসড স্ট্রিম যা WebRTC দ্বারা নেগোশিয়েট, পুনরায় এনকোডেড, রেট-লিমিটেড, এবং সম্ভবত ডাউনগ্রেড করা হয়েছে — আপনার মেশিন ছাড়ার আগে মিলিসেকেন্ডের মধ্যে।

সেই এনকোডিং স্তরটি ব্যবহারকারী ইন্টারফেস থেকে অদৃশ্য এবং স্বাভাবিক অপারেশনের সময় নীরব। কল উইন্ডোর কিছুই আপনাকে বলে না এটি বিদ্যমান, কিছুই এর সিদ্ধান্ত রিপোর্ট করে না, এবং আপনার প্রিভিউয়ের কিছুই সেগুলি প্রতিফলিত করে না। একটি পরিচিত দৃশ্য: একজন ব্যবহারকারী ঘণ্টার পর ঘণ্টা ক্যামেরা ড্রাইভার পুনরায় ইনস্টল করেন কারণ একটি কল অস্পষ্ট ছবি দেখায় — শুধুমাত্র chrome://webrtc-internals এর মাধ্যমে আবিষ্কার করেন যে ব্রাউজার ব্যান্ডউইডথ অনুমানের উপর ভিত্তি করে ৪৮০p15-এ নেগোশিয়েট করছিল, ক্যামেরা বা ড্রাইভারের কারণে নয়। এই পৃষ্ঠা ব্যাখ্যা করে ক্যামেরা সেন্সর এবং আপনার কল পার্টনারের স্ক্রিনের মধ্যে কী ঘটে, কেন ব্রাউজার নীরবে আপনার কোয়ালিটি কমায়, এবং — সবচেয়ে গুরুত্বপূর্ণ — কীভাবে প্রিভিউয়ের উপর ভরসা না করে আপনার মেশিন ছাড়া প্রকৃত স্ট্রিম পরিমাপ করবেন।

প্রিভিউ আপনাকে কী দেখায় না

ভিডিও কলিং একটি পাইপলাইনের উপর নির্ভর করে যা সম্পূর্ণরূপে আপনার সচেতনতার বাইরে চলে। আপনি যে প্রতিটি ফ্রেম পাঠান তা নিম্নলিখিত পর্যায়গুলির মধ্য দিয়ে যায়:

1. ক্যামেরা সেন্সর একটি ফ্রেম ক্যাপচার করে; ব্রাউজার তারপর getUserMedia() এর মাধ্যমে অনুরোধ করা রেজোলিউশন এবং ফ্রেম রেটে ফ্রেমটি ডেলিভার করে, যা স্কেলিং, কালার কনভার্সন, এবং কনস্ট্রেইন্ট প্রসেসিং জড়িত থাকতে পারে।
2. ব্রাউজার getUserMedia() API এর মাধ্যমে সেই ফ্রেম গ্রহণ করে এবং WebRTC ইঞ্জিনে দেয়। আপনার লোকাল প্রিভিউ এই পর্যায় থেকে খাওয়ানো হয় — যা কিছু এরপর ঘটুক না কেন এটি সর্বদা নিখুঁত দেখায়।
3. WebRTC এনকোডার একটি নেগোশিয়েটেড codec-এ নির্দিষ্ট রেজোলিউশন, ফ্রেম রেট, এবং বিট রেটে ফ্রেমটি কম্প্রেস করে।
4. এনকোডেড ফ্রেম RTP প্যাকেটে বিভক্ত হয় এবং নেটওয়ার্কে পাঠানো হয়, সাধারণত একটি মিডিয়া সার্ভারের মাধ্যমে যা অন্য সবাইকে রিলে করে।
5. প্রতিটি রিসিভার প্যাকেট ডিকোড করে এবং তাদের স্ক্রিনে রেন্ডার করে।

আপনার প্রিভিউ পাইপলাইনের দ্বিতীয় পর্যায়ে প্রবেশ করে। এটি ক্যামেরা যা উৎপাদন করেছে সেই ফ্রেম দেখায়, getUserMedia() এর মাধ্যমে ডেলিভার্ড, WebRTC এনকোডিংয়ের আগে। ব্রাউজার এই পর্যায়ে স্কেলিং, কালার কনভার্সন, বা কনস্ট্রেইন্ট প্রসেসিং প্রয়োগ করতে পারে, কিন্তু কোনো WebRTC কম্প্রেশন প্রয়োগ করা হয় না। আপনার কল পার্টনার যে স্ট্রিম দেখেন তা তৃতীয় পর্যায় থেকে আসে। সেই দুটি পয়েন্টের মধ্যে, এনকোডার সিদ্ধান্ত নেয় বিশ্ব কী গ্রহণ করবে, এবং এটি সেই সিদ্ধান্ত এমন পরিস্থিতির উপর ভিত্তি করে নেয় যা আপনি কখনো দেখেন না।

এনকোডার নীরবে তিনটি প্যারামিটার নেগোশিয়েট করে, এবং প্রতিটি কলের মধ্যে কোনো নোটিফিকেশন ছাড়াই পরিবর্তিত হতে পারে:

• রেজোলিউশন — এনকোডেড ফ্রেমের প্রস্থ এবং উচ্চতা, যা নিজে থেকে ১৯২০ × ১০৮০ থেকে ১২৮০ × ৭২০ বা ৬৪০ × ৪৮০-এ নামতে পারে।
• ফ্রেম রেট — এনকোডিংয়ের পর প্রতি সেকেন্ডে কতগুলি ফ্রেম টিকে থাকে, যা সাধারণত প্রথমে কমে (৩০ থেকে ১৫ বা তার নিচে), কারণ ফ্রেম রেট অর্ধেক করা রেজোলিউশন না বদলে ডেটা রেট অর্ধেক করে — যদিও কিছু ইমপ্লিমেন্টেশন কোডেক এবং প্ল্যাটফর্মের উপর নির্ভর করে রেজোলিউশন কমাতে পারে।
• বিট রেট — এনকোডারকে প্রতি সেকেন্ডে কতগুলি বিট খরচ করতে দেওয়া হয়, যা সামগ্রিক কম্প্রেশন লেভেল নির্ধারণ করে।

এই তিনটি মান নির্ধারণ করে অন্য দিকে যা দেখা যায় তার সবকিছু। একটি ১০৮০p ছবি কম বিট রেটে কম্প্রেস করলে নরম এবং মলিন দেখায়। একটি ৩০ fps স্ট্রিম হঠাৎ ১০ fps-এ চললে কাঁপছ এবং অস্বাভাবিক দেখায়। যখন আপনি বুঝতে পারেন যে প্রিভিউ এই মানগুলির কোনোটিই রিপোর্ট করে না, তখন ভাল ক্যামেরা সহ খারাপ কলের রহস্য দূর হয়।

প্রথম ফ্রেম পাঠানোর আগে SDP নেগোশিয়েট করে

নেগোশিয়েশন প্রথম ফ্রেম পাঠানোর আগেই শুরু হয়। কলে যোগ দেওয়ার সময়, প্ল্যাটফর্ম এবং আপনার ব্রাউজার Session Description Protocol (SDP) অফার এবং উত্তর বিনিময় করে। SDP প্রতিটি পক্ষ সমর্থন করে এমন codec এবং মিডিয়া ক্ষমতা বিজ্ঞাপন করে; প্রকৃত রেজোলিউশন এবং ফ্রেম রেট তারপর send এবং receive প্যারামিটারের মাধ্যমে আরও নেগোশিয়েট করা হয় এবং ব্যান্ডউইডথ অনুমান দ্বারা সীমাবদ্ধ থাকে। অনৌপচারিক পরীক্ষায় Chrome 125 (Windows 10, মে ২০২৪) এ VP9 প্রথমে, তারপর H.264, তারপর VP8 দেখা গেছে। Safari 17 (macOS 14, একই সময়ে) এ H.264 প্রথমে দেখা গেছে। এই পর্যবেক্ষণগুলি প্রতিটি ব্রাউজারে একটি মেশিনে নিয়ন্ত্রিত নেটওয়ার্ক পরিস্থিতি ছাড়া করা হয়েছে, তাই এগুলি বিদ্যমান পরিবর্তনকে চিত্রিত করে, সার্বজনীন ক্রম নির্ধারণ করে না। প্রকৃত codec ব্রাউজার, প্ল্যাটফর্ম, SDP প্যারামিটার এবং হার্ডওয়্যার ক্ষমতার উপর নির্ভর করে। সাধারণ পছন্দগুলির মধ্যে রয়েছে VP9, H.264, VP8 এবং AV1, তবে সব প্ল্যাটফর্ম জুড়ে কোনো নির্দিষ্ট পছন্দ ক্রম নেই।

codec নির্বাচন শুধু শুরু। কল চলার পর দ্বিতীয় একটি প্রক্রিয়া দায়িত্ব নেয়: ব্যান্ডউইডথ অনুমান। WebRTC উভয় দিকে নেটওয়ার্ক পথ ক্রমাগত পর্যবেক্ষণ করে এবং একটি কনজেশন কন্ট্রোল অ্যালগরিদম চালায় — সাধারণত Google Congestion Control — যা ক্রমাগত তিনটি পরিমাপ করে:

• প্যাকেট লস, রিসিভারের মাধ্যমে RTCP ফিডব্যাক মেসেজে রিপোর্ট করা হয়।
• রাউন্ড-ট্রিপ টাইম, একটি প্যাকেট পাঠানো এবং তার পৌঁছানোর স্বীকৃতি পাওয়ার মধ্যে বিলম্ব।
• থ্রুপুট, যে কার্যকর হারে ডেটা সংযোগ অতিক্রম করে।

অ্যালগরিদম এই পরিমাপগুলিকে একটি মডেলে প্রবেশ করায় যা অনুমান করে নেটওয়ার্ক বর্তমানে কত ব্যান্ডউইডথ বহন করতে পারে। সেই অনুমান একটি টার্গেট বিট রেট হয়ে এনকোডারের কাছে যায়, এবং এনকোডার তার আউটপুট সেই অনুযায়ী মানিয়ে নেয়। লুপটি ক্রমাগত এবং দ্রুত: অনুমান কমলে, এনকোডার এক সেকেন্ডের ভগ্নাংশের মধ্যে কম বিট রেটে পুনরায় এনকোড করে।

থ্রেশহোল্ডগুলি আনুমানিক এবং ব্যবহৃত কনজেশন কন্ট্রোল অ্যালগরিদমের উপর নির্ভর করে। প্রায় পাঁচ শতাংশের বেশি ক্রমাগত প্যাকেট লস টার্গেট বিট রেট কমানোর ট্রিগার হতে পারে, কিন্তু সঠিক আচরণ — হার কত কমে, রেজোলিউশন বা ফ্রেম রেট পরিবর্তিত হবে কিনা, এবং কোন লস স্তরে — অ্যালগরিদম, codec এবং প্ল্যাটফর্ম অনুযায়ী ভিন্ন। লস শতাংশ থেকে নির্দিষ্ট আউটপুট রেজোলিউশনে কোনো সার্বজনীন ম্যাপিং নেই। এই সিদ্ধান্তগুলি চালানো ফিডব্যাক লুপটি (Google: WebRTC Congestion Control Whitepaper, 2019; RFC 8888: Congestion Control Feedback for RTP) এ সংজ্ঞায়িত। ১০৮০p ৩০ fps স্ট্রিম পরিষ্কার দেখতে সাধারণত প্রায় চার থেকে ছয় মেগাবিট/সেকেন্ড আপলোড ব্যান্ডউইডথ প্রয়োজন, যদিও এটি codec, এনকোডিং সেটিংস এবং দৃশ্যের জটিলতার উপর নির্ভর করে। যদি অনুমানকারী সিদ্ধান্ত নেয় যে মাত্র এক মেগাবিট উপলব্ধ, তবে সে স্ট্রিম জোর করে পাঠানোর চেষ্টা করে না — সে টার্গেট কমায়, এবং এনকোডার রেজোলিউশন ৪৮০p এবং ফ্রেম রেট ১৫ fps-এ নামিয়ে সাড়া দেয়। অনুমান আরও কমলে, ছবি আবার খারাপ হয়, ৩২০×২৪০ টকিং হেড পর্যন্ত নেমে যায়। প্রতিটি ধাপ ইচ্ছাকৃত: লক্ষ্য হলো কলটিকে জীবিত রাখা এবং অডিও স্থিতিশীল রাখা, এবং ভিডিও কোয়ালিটি হলো সেই লক্ষ্য অর্জনের জন্য প্রথম যে জিনিসটি ত্যাগ করা হয়।

আপনার স্ট্রিম যে তিনটি ব্যর্থতা প্যাটার্ন লুকিয়ে রাখে

প্রিভিউ তিনটি পুনরাবৃত্তিমূলক ব্যর্থতা প্যাটার্নের পেছনে স্ট্রিমের প্রকৃত অবস্থা লুকিয়ে রাখে। প্রতিটির লক্ষণ চেনার চেষ্টা করুন, কারণ সঠিক সমাধান প্রতিটি ক্ষেত্রে আলাদা। তিনটির একটি মিল আছে: প্রিভিউ পুরো সময় নিখুঁত থাকে, কারণ এটি এনকোডারের আগে থেকে নেওয়া। শুধুমাত্র এনকোডেড স্ট্রিম — এবং ফলে অন্য অংশগ্রহণকারীদের স্ক্রিন — ক্ষতি দেখায়।

বিট রেট ফাঁদ

লক্ষণ: আপনার প্রিভিউ নিখুঁত এবং আপনার মেশিনে CPU অলস। অন্য দিকে একটি ঝাপসা, কম-রেজোলিউশনের ছবি দেখে যা কখনো তীক্ষ্ণ হয় না, এমনকি বিরতির সময়ও। স্থানীয় রেকর্ডিং চমৎকার দেখায়; কল খারাপ দেখায়।

নির্ণয়: ব্রাউজার অনুমান করেছে যে নেটওয়ার্ক সম্পূর্ণ স্ট্রিম বহন করতে পারবে না এবং বিট রেট ক্যাপ করেছে, এনকোডারকে রেজোলিউশন কমাতে বাধ্য করেছে। সীমাবদ্ধতা হলো আপনার আপলোড ব্যান্ডউইডথ বা মিডিয়া সার্ভারের রিলে ক্ষমতা, আপনার ক্যামেরা নয়। একটি স্পিড টেস্ট চালান এবং আপনার আপলোডকে ১০৮০p30-এর জন্য প্রয়োজনীয় চার থেকে ছয় মেগাবিটের সাথে তুলনা করুন। আপনি যদি স্ট্রিমিং, ডাউনলোডিং বা সিঙ্কিং করা অন্যান্য ডিভাইসের সাথে সংযোগ শেয়ার করেন, তবে সেগুলি একই বাজেটের জন্য প্রতিযোগিতা করছে।

লস থ্রেশহোল্ড

লক্ষণ: কল থেকে নেওয়া স্থির ছবিগুলি ঠিক দেখায়, কিন্তু যেকোনো নড়াচড়া ঝাঁকুনিপূর্ণ এবং রোবোটিক। ভিডিও কাঁপার সময় অডিও মসৃণ থাকে, এবং কয়েক সেকেন্ড পরপর ছোট ফ্রিজ ঘটে যাওয়ার আগে ছবি কম ফ্রেম রেটে ফিরে আসে।

নির্ণয়: প্যাকেট লস প্রায় পাঁচ শতাংশ থ্রেশহোল্ড অন্তর্বর্তীকালে অতিক্রম করছে, তাই কনজেশন কন্ট্রোলার বারবার টার্গেট বিট রেট কাটছে এবং এনকোডার মানানসই করতে ফ্রেম ফেলে দিচ্ছে। ফ্রেম রেট প্রথমে পড়ে কারণ এটি সবচেয়ে সস্তা লিভার — ৩০ থেকে ১৫ fps-এ কমালে রেজোলিউশন না বদলে ডেটা রেট অর্ধেক হয়ে যায়। Wi-Fi ইন্টারফেরেন্স, একটি মার্জিনাল ইথারনেট ক্যাবল, বা লস এবং লেটেন্সি যোগ করা VPN এর জন্য চেক করুন। নেটওয়ার্ক পথ মেরামত না হওয়া পর্যন্ত ভিডিও খারাপ হতে থাকবে।

কিফ্রেম ফ্রিজ

লক্ষণ: আপনি যোগ দেওয়ার পর প্রথম দুই থেকে পাঁচ সেকেন্ড, বা স্ক্রিন শেয়ার করার পর, অন্য দিক একটি ফোজন বা ব্যাপকভাবে মলিন ছবি দেখে। তারপর ছবিটি ফোকাসে চলে আসে এবং পরবর্তী বড় দৃশ্য পরিবর্তন পর্যন্ত স্বাভাবিকভাবে আচরণ করে।

নির্ণয়: ভিডিও codec দুই ধরনের ফ্রেম পাঠায়। কিফ্রেম সম্পূর্ণ ছবি এনকোড করে এবং একটি নির্দিষ্ট ব্যবধানে আসে — সাধারণত প্ল্যাটফর্ম এবং কনফিগারেশন অনুযায়ী প্রতি এক থেকে দশ সেকেন্ড। ডেল্টা ফ্রেম শুধুমাত্র আগের ফ্রেম থেকে পরিবর্তনগুলি এনকোড করে, যা সেগুলিকে ছোট করে। যদি একটি ডেল্টা ফ্রেমের প্যাকেট হারিয়ে যায়, রিসিভার সেই ফ্রেমটি পুনরায় নির্মাণ করতে পারে না — এটি একটি রিট্রান্সমিশন (NACK) অনুরোধ করতে পারে, একটি নতুন কিফ্রেমের জন্য (PLI বা FIR) জিজ্ঞাসা করতে পারে, বা অপেক্ষা করার সময় ত্রুটি লুকাতে পারে। অনুরোধ সফল হলে, পুনরুদ্ধার দ্রুত হয়; না হলে, ছবি পরবর্তী নির্ধারিত কিফ্রেম আসা পর্যন্ত ফোজন থাকে। সেই অপেক্ষাই আপনি যে ফ্রিজ দেখেন। ছোট কিফ্রেম ব্যবধান দ্রুত পুনরুদ্ধার করে কিন্তু ব্যান্ডউইডথ খরচ করে; বড় ব্যবধান কার্যকরী কিন্তু প্রতিটি লসকে আরও দৃশ্যমান করে। এটি কোনো ত্রুটি নয় — এটি codec ডিজাইন অনুযায়ী কাজ করছে।

getStats() দিয়ে প্রকৃত স্ট্রিম পরিমাপ

অনুমান করা বন্ধ করুন। সংখ্যাগুলি সন্তোষজনক নয়, কিন্তু সত্য। WebRTC API একটি পরিসংখ্যান ইন্টারফেস উন্মুক্ত করে যা ঠিক রিপোর্ট করে এনকোডার কী করছে, এবং আপনার নিয়ন্ত্রণাধীন যেকোনো ওয়েব পেজ তার নিজস্ব পিয়ার সংযোগ পড়তে পারে। RTCPeerConnection অবজেক্টে getStats() কল করুন, তারপর রিটার্ন করা রিপোর্ট থেকে kind যা video সেই outbound-rtp এন্ট্রি ফিল্টার করুন। media-source এবং outbound-rtp এন্ট্রিতে আপনি গুরুত্বপূর্ণ মানগুলি পাবেন:

• framesPerSecond (media-source এন্ট্রিতে) — ক্যামেরা এনকোডারের কাছে যে ফ্রেম রেট দিচ্ছে। এটি যদি ৩০ fps ক্যামেরায় ৩০-এর নিচে হয়, তবে ক্যাপচার পথ নিজেই সমস্যা।
• framesPerSecond (outbound-rtp এন্ট্রিতে) — এনকোডার আসলে যে ফ্রেম রেট উৎপাদন করছে। এটি ইনপুট রেটের চেয়ে কম হলে, এনকোডার ফ্রেম ফেলে দিচ্ছে।
• frameWidth এবং frameHeight (outbound-rtp এন্ট্রিতে) — এনকোডেড রেজোলিউশন। আপনার কল সেটিংসের সাথে তুলনা করুন; যেকোনো পার্থক্য হলো একটি নীরব ডাউনগ্রেড।
• bytesSent (outbound-rtp এন্ট্রিতে) — মোট এনকোডেড ডেটা। এক সেকেন্ড ব্যবধানে দুবার স্যাম্পল করুন এবং প্রকৃত বিট রেট পেতে পার্থক্য ৮ দিয়ে গুণ করুন।
• packetsSent এবং packetsLost — মনে রাখবেন outbound-rtp এন্ট্রিতে packetsLost সর্বদা পূরণ করা থাকে না; লস অনুপাত আরও নির্ভরযোগ্যভাবে remote-inbound-rtp এন্ট্রি থেকে পড়া যায়, যা রিসিভারের দৃষ্টিভঙ্গি রিপোর্ট করে।
• currentRoundTripTime (candidate-pair এন্ট্রিতে) — নেটওয়ার্ক বিলম্ব। উচ্চ RTT লসের সাথে কনজেশন নির্দেশ করে।

বিভিন্ন ব্রাউজার সামান্য ভিন্ন ফিল্ড নাম রিপোর্ট করতে পারে বা কিছু পরিসংখ্যান সম্পূর্ণ বাদ দিতে পারে, তাই ব্রাউজারের WebRTC internals পেজের সাথে ক্রস-চেক করুন যখন উপলব্ধ।

ব্যাখ্যার নিয়মগুলি সহজ। যদি outbound-rtp framesPerSecond media-source framesPerSecond-এর তুলনায় লক্ষণীয়ভাবে কম হয়, এনকোডার চাপে ফ্রেম ফেলে দিচ্ছে। যদি frameWidth এবং frameHeight আপনার কনফিগার করা রেজোলিউশনের নিচে হয়, সংযোগ বাজেট তা বহন করতে পারেনি। যদি bytesSent সেই রেজোলিউশনের জন্য codec-এর প্রয়োজনের চেয়ে অনেক কম বিট রেটে অনুবাদ হয়, ছবিটি পিষ্ট হচ্ছে — এবং প্রিভিউ, যা এনকোডারকে কখনো দেখে না, পুরো সময় ভালো দেখাবে।

কোড লিখে এই মানগুলি পড়ার দরকার নেই। Chrome এবং Edge chrome://webrtc-internals-এ একটি বিল্ট-ইন পরিসংখ্যান ভিউয়ার দেয় যা ব্রাউজারের প্রতিটি WebRTC সংযোগ ক্যাপচার করে, যার মধ্যে কল প্ল্যাটফর্ম তৈরি করাও অন্তর্ভুক্ত। মিটিংয়ে যোগ দেওয়ার আগে এটি খুলুন, রেকর্ড করতে দিন, এবং পরে ভিডিও প্রেরকের জন্য outbound-rtp এন্ট্রিগুলি পরীক্ষা করুন। একই ফ্রেম রেট, রেজোলিউশন, বিট রেট এবং লস পরিসংখ্যান সেখানে আছে, সাথে একটি টাইমলাইন গ্রাফ যা এনকোডার কখন তার আউটপুট পরিবর্তন করেছে তা সঠিকভাবে দেখায়। এটি একটি বাস্তব প্ল্যাটফর্ম কলে ডাউনগ্রেড কার্যে ধরার সবচেয়ে দ্রুত উপায়।

এই পরিমাপটি আপনার নিজের কল ব্যাকগ্রাউন্ডে নিষ্ক্রিয় থাকাকালীন চালান, তারপর ব্যস্ত মিটিংয়ের সময় আবার চালান, এবং দুই সেট সংখ্যা তুলনা করুন। একটি সাধারণ তুলনা: নিষ্ক্রিয় অবস্থায়, outbound-rtp framesPerSecond ৩০ পড়ে; ব্যস্ত মিটিংয়ে এটি ১৮-এ নেমে যেতে পারে যখন লোকাল প্রিভিউ এখনও ৩০ দেখায়। সেই তুলনা প্রকাশ করে আপনার বেসলাইন নেটওয়ার্ক পর্যাপ্ত কিনা এবং কলের সময় প্রতিযোগিতাই ডাউনগ্রেড ট্রিগার করছে কিনা। আমাদের ওয়েবক্যাম টেস্ট টুল getUserMedia()-এর মাধ্যমে নেগোশিয়েট করা লোকাল ক্যাপচার ট্র্যাকের রেজোলিউশন এবং ফ্রেম রেট দেখায় — আপনার ক্যামেরা ব্রাউজারে কী সরবরাহ করতে পারে তার জন্য একটি কার্যকর বেসলাইন, কিন্তু আউটবাউন্ড WebRTC এনকোডেড স্ট্রিমের পরিমাপ নয়, যা একটি পিয়ার সংযোগ বা ব্রাউজারের WebRTC internals পেজ প্রয়োজন।

Zoom, Meet, Teams: তিনটি ভিন্ন ক্যামেরা

একই ক্যামেরা, একই ল্যাপটপ, এবং একই নেটওয়ার্ক ভিন্ন অ্যাপ্লিকেশনে স্পষ্টভাবে ভিন্ন ফলাফল দিতে পারে, কারণ প্রতিটি প্ল্যাটফর্ম ব্রাউজারের WebRTC বাস্তবায়নের উপরে নিজস্ব এনকোডিং নীতি প্রয়োগ করে।

• Zoom সাধারণত স্থিতিশীলতাকে অগ্রাধিকার দেয়। ভার্সন, অ্যাকাউন্ট টাইপ এবং মিটিং সেটিংস অনুযায়ী, এটি আউটগোয়িং রেজোলিউশন ক্যাপ করতে পারে এবং অডিও ও স্ক্রিন শেয়ার স্থিতিশীল রাখতে ভিডিও কোয়ালিটি স্যাক্রিফাইস করতে পারে। ১০৮০p-সক্ষম ক্যামেরা Zoom-এ ৭২০p বা তার নিচে ট্রান্সমিট করতে পারে।
• Google Meet পরিমাপ করা ব্যান্ডউইডথের সাথে মানিয়ে নেওয়ার প্রবণতা রাখে, প্রথমে রেজোলিউশন কমায় এবং শর্ত উন্নত হলে দ্রুত পুনরুদ্ধার করে। এর আচরণ আপনার প্রকৃত নেটওয়ার্ক স্টেট অনুসরণ করে, ভালো এবং খারাপ উভয়ভাবে।
• Microsoft Teams নিজস্ব এনকোডিং এবং পোস্ট-প্রসেসিং পাইপলাইন প্রয়োগ করে। ভার্সন এবং মিটিং সেটিংস অনুযায়ী, ছবিটি র বেবRTC নেগোশিয়েশনের বাইরে আরও কম্প্রেস করা হতে পারে।
• ব্রাউজার-নেটিভ WebRTC, যেমন আপনি একটি সাধারণ ওয়েব পেজে পান, কোনো প্ল্যাটফর্ম নীতি ছাড়াই নেগোশিয়েটেড স্ট্রিম পাঠায়। এটি সেই গ্রাউন্ড ট্রুথের সবচেয়ে কাছের জিনিস যা আপনার হার্ডওয়্যার এবং নেটওয়ার্ক প্লেইন WebRTC-এর অধীনে সরবরাহ করতে পারে। প্ল্যাটফর্ম নীতিগুলি ভার্সন, অ্যাকাউন্ট টাইপ এবং মিটিং কনফিগারেশন অনুযায়ী পরিবর্তিত হয়, তাই এগুলিকে সাধারণ প্রবণতা হিসেবে বিবেচনা করুন, নির্দিষ্ট নিয়ম হিসেবে নয়।

ব্যবহারিক ফলাফল: Zoom কলের সাথে Meet কল তুলনা করা একটি ক্যামেরা টেস্ট নয়। এটি প্রতিটি প্ল্যাটফর্মের এনকোডিং সিদ্ধান্তের টেস্ট। প্রথমে একটি প্লেইন WebRTC পেজ বা ওয়েবক্যাম টেস্ট টুল দিয়ে র স্ট্রিম পরিমাপ করুন। যদি র স্ট্রিম পরিষ্কার থাকে এবং একটি প্ল্যাটফর্ম এখনও খারাপ দেখায়, প্ল্যাটফর্মের নীতিই সীমাবদ্ধতা, এবং কোনো হার্ডওয়্যার আপগ্রেড তা পরিবর্তন করবে না। যখন একটি প্ল্যাটফর্ম কল চলমান থাকে, chrome://webrtc-internals আপনাকে লাইভে এর এনকোডার সিদ্ধান্ত দেখতে দেয়, তাই আপনি দেখতে পারেন ডাউনগ্রেড প্ল্যাটফর্মের নীতি নাকি নেটওয়ার্কের আচরণ, কোনো পক্ষের স্ব-রিপোর্টে বিশ্বাস না করেই।

পরিষ্কার স্ট্রিমের জন্য সাতটি ধাপ

এই ধাপগুলি স্বতন্ত্র কারণগুলিকে আলাদা করে। স্ট্রিম ঠিক দেখতে শুরু করার সাথে সাথেই আপনি থামতে পারেন — কিন্তু প্রতিটি পরিবর্তনের আগে এবং পরে পরিমাপ করুন যাতে নিশ্চিত হন যে সমাধানটি সংখ্যাকে সত্যিকার অর্থে সরিয়েছে।

1. প্রথমে পরিমাপ করুন। chrome://webrtc-internals খুলুন বা নিজের পিয়ার সংযোগে getStats() ব্যবহার করুন এবং রেজোলিউশন, ফ্রেম রেট এবং বিট রেট রেকর্ড করুন। যদি র স্ট্রিম ইতিমধ্যে ডাউনগ্রেড করা থাকে, তবে আপনার ক্যামেরা এবং সংযোগই সমস্যা। যদি এটি পরিষ্কার থাকে, তবে প্ল্যাটফর্মই সমস্যা।
2. ব্যান্ডউইডথ চেক করুন। ভিডিও কলের জন্য অন্তত ৭২০p-এর জন্য ১ Mbps এবং ১০৮০p-এর জন্য প্রায় ৪ Mbps আপলোড প্রয়োজন। যে মেশিন থেকে আপনি কল করেন সেখান থেকে টেস্ট করুন, অন্য ডিভাইস থেকে নয়, এবং নেটওয়ার্কে অন্যান্য ট্রাফিক থাকলে পুনরায় টেস্ট করুন। যদি সম্ভব হয় তারযুক্ত সংযোগে চলে যান; Wi-Fi লস অদৃশ্য ডাউনগ্রেডের সবচেয়ে সাধারণ কারণ।
3. লাইটিং ঠিক করুন। ভালো আলোয় থাকা বিষয়টি একটি অন্ধকার বিষয়ের চেয়ে অনেক ভালো কম্প্রেস হয়, কারণ এনকোডার নয়েজের বদলে দৃশ্যমান বিস্তারের জন্য বিট রেট ব্যয় করে। একটি জানালার দিকে মুখ করুন বা একটি সফট লাইট সোর্স ব্যবহার করুন। এর জন্য কিছুই খরচ হয় না এবং প্রায়ই যেকোনো সেটিং থেকে বড় উন্নতি তৈরি করে।
4. ভিডিও নয়েজ রিডাকশন বন্ধ করুন যখন আপনার পরিবেশ ইতিমধ্যে শান্ত এবং ভালো আলোযুক্ত। কিছু প্ল্যাটফর্ম কম-লাইট সিনে আগ্রাসী ডিনয়েজিং প্রয়োগ করে, যা এনকোডেড স্ট্রিমে সূক্ষ্ম বিস্তার লক্ষণীয়ভাবে নরম করতে পারে। লোকাল প্রিভিউ এই পার্থক্য দেখাবে না; শুধুমাত্র এনকোডেড স্ট্রিম দেখাবে। কোন কন্ট্রোলগুলি উপলব্ধ তা নিশ্চিত করতে নির্দিষ্ট প্ল্যাটফর্ম সেটিংস চেক করুন।
5. ভার্চুয়াল ব্যাকগ্রাউন্ড বন্ধ করুন। ব্যাকগ্রাউন্ড সেগমেন্টেশন কার্যকর বিট রেটে ওভারহেড যোগ করে এবং এনকোডার থেকে GPU সাইকেল গ্রাস করে। সামঞ্জস্যপূর্ণ আলো সহ একটি পরিষ্কার বাস্তব ব্যাকগ্রাউন্ড যেকোনো ভার্চুয়াল ব্যাকগ্রাউন্ডকে পরাজিত করে।
6. codec চেক করুন। যদি আপনার CPU হ্যান্ডেল করতে পারে, VP9 প্রতি বিটে সেরা কোয়ালিটি দেয়; যদি আপনি ফ্রেম ড্রপ বা CPU স্পাইক দেখেন, H.264 দ্রুত এনকোড করে। কিছু প্ল্যাটফর্ম সেটিংসে একটি codec পছন্দ প্রকাশ করে।
7. ভিন্ন প্ল্যাটফর্ম টেস্ট করুন। যদি কোয়ালিটি একটি পরিষেবায় ভালো এবং অন্যটিতে খারাপ হয়, প্ল্যাটফর্মের এনকোডিং নীতিই সীমাবদ্ধতা। আপনার প্রত্যাশা বা আপনার মিটিং টুল সেই অনুযায়ী সমন্বয় করুন — আপনার হার্ডওয়্যার দোষী নয়।

উপসংহার

প্রিভিউ হলো আপনার ক্যামেরার লোকাল সেলফ-ইমেজ: আপনার ক্যামেরা ব্রাউজারে কী সরবরাহ করতে পারে তার একটি অনুকূল দৃশ্য। স্ট্রিম হলো বিশ্ব আসলে যা দেখে — নেগোশিয়েটেড, কম্প্রেসড এবং নেটওয়ার্ক কন্ডিশন ও প্ল্যাটফর্ম নীতি দ্বারা রূপান্তরিত। এগুলি একই বিষয়ের দুটি ভিন্ন ভিডিও, এবং আপনি কীভাবে উপস্থিত হন তার জন্য শুধুমাত্র একটিই গুরুত্বপূর্ণ। আপনি যদি কখনও ভেবে থাকেন কেন আপনার ক্যামেরা আপনার স্ক্রিনে দুর্দান্ত দেখায় কিন্তু কলে ভয়ানক দেখায়, আপনার এখন উত্তর আছে এবং এটি পরিমাপ করার টুল আছে।

chrome://webrtc-internals খুলুন। আপনার পরবর্তী কলে যোগ দিন। outbound-rtp এন্ট্রিগুলি দেখুন। যদি frameWidth বা framesPerSecond আপনার ক্যামেরা সেটিংসে যা সেট করেছেন তার নিচে থাকে, ডাউনগ্রেড ঘটছে। কারণ সাধারণত ব্যান্ডউইডথ-সম্পর্কিত — আপনার ব্রাউজারকে কত খরচ করতে দেওয়া হয়েছে, এবং আপনার সংযোগ আপনি যা পাঠাচ্ছেন ভাবছেন তা আসলে বহন করতে পারে কিনা — কিন্তু CPU লোড, এনকোডার নির্বাচন, প্ল্যাটফর্ম নীতি এবং কনস্ট্রেইন্ট কনফিগারেশনও ডিগ্রেডেশনে অবদান রাখতে বা প্রভাবশালী হতে পারে।