WebRTC স্ক্রিন শেয়ারিং আসলে কতটা ভালো? আমি ৪টি কোডেক পরীক্ষা করে দেখেছি

WebRTC-তে স্ক্রিন শেয়ারিংয়ের ক্ষেত্রে বিভিন্ন কোডেক কীভাবে একত্রিত হয় তা নিয়ে আমার সবসময়ই কৌতূহল ছিল। তাই, আমি চারটি সাধারণ কোডেক পরীক্ষা করে নিজেই এটি খুঁজে বের করার সিদ্ধান্ত নিয়েছি: VP8, VP9, H.264, এবং AV1।

ফলাফলগুলি নিশ্চিত করার জন্য, আমি বিভিন্ন ধরণের কন্টেন্ট এবং নেটওয়ার্ক অবস্থার উপর পরীক্ষা চালিয়েছি। আমি কেবল ভিজ্যুয়াল ইমপ্রেশনের উপর নির্ভর করিনি - আমি ফ্রেম-বাই-ফ্রেম তুলনা ব্যবহার করেছি, পিক সিগন্যাল-টু-নয়েজ রেশিও (PSNR) গণনা করেছি এবং একটি স্পষ্ট, ডেটা-চালিত ভিউ পেতে বিস্তারিত WebRTC পরিসংখ্যান সংগ্রহ করেছি।

আরও এক ধাপ এগিয়ে, আমি এমন একটি কাস্টম ক্রোম প্লাগইন তৈরি করেছি যা এনকোডিং এবং ডিকোডিং উভয়ের সময় CPU ব্যবহার ট্র্যাক করে। এটি আমাকে প্রতিটি কোডেক সিস্টেমের কর্মক্ষমতাকে কীভাবে প্রভাবিত করে তা ভালভাবে বুঝতে সাহায্য করেছে - কারণ মান দুর্দান্ত, তবে যদি আপনার কম্পিউটারটি তাল মিলিয়ে চলার চেষ্টা করে তবে তা নয়।

আমি বিটরেট, ফ্রেম রেট, রেজোলিউশন, কোয়ান্টাইজেশন (QP), PSNR এবং CPU লোডের মতো গুরুত্বপূর্ণ মেট্রিক্সগুলি দেখেছি। এই সবকিছুর উপর ভিত্তি করে, আমি কিছু ব্যবহারিক সুপারিশ নিয়ে এসেছি যা তাদের নিজস্ব ব্যবহারের ক্ষেত্রে WebRTC স্ক্রিন শেয়ারিং অপ্টিমাইজ করার চেষ্টা করা ব্যক্তিদের সাহায্য করবে।

পরীক্ষা সম্পর্কে

স্ক্রিন শেয়ারিং কেন এত সহজ নয় যতটা মনে হয়

যদি আপনি কখনও ভিডিও কলের সময় আপনার স্ক্রিন শেয়ার করে দেখে থাকেন যে এর মান কমে যাচ্ছে - অথবা ভিডিওটি খারাপ হচ্ছে - তাহলে আপনি একা নন। স্ক্রিন শেয়ারিংকে মসৃণ এবং স্পষ্ট রাখা আসলে যতটা কঠিন মনে হচ্ছে তার চেয়েও বেশি জটিল।

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

প্যাকেট লস বা ব্যান্ডউইথ কমে যাওয়ার মতো বাস্তব ইন্টারনেট সমস্যাগুলো যুক্ত করলে পরিস্থিতি আরও জটিল হয়ে পড়বে। এজন্যই স্ক্রিন শেয়ারিংকে উচ্চমানের এবং প্রতিক্রিয়াশীল করে তোলার জন্য সঠিক কোডেক নির্বাচন করা - এবং এটি কীভাবে কাজ করে তা ঠিক করা - খুবই গুরুত্বপূর্ণ।

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

আমি যা করতে শুরু করেছি

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

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

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

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

বাস্তব জীবনের স্ক্রিন শেয়ারিং পরিস্থিতি অনুকরণ করার জন্য আমি দুটি ভিন্ন টেস্ট কেস তৈরি করেছি:

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

• স্বয়ংক্রিয়ভাবে লেখা স্ক্রল করা - আমি লেখা এবং ছবি দিয়ে একটি সাধারণ HTML পৃষ্ঠা তৈরি করেছি, তারপর জাভাস্ক্রিপ্ট ব্যবহার করে এটিকে একটি স্থির গতিতে স্ক্রোল করেছি। এটি একটি সাধারণ ব্যবহারের ক্ষেত্রে যেমন একটি ডকুমেন্ট শেয়ার করা বা একটি ওয়েবপৃষ্ঠা থেকে পড়া অনুকরণ করে।

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

আমি কীভাবে সবকিছু সেট আপ করি

কোডেকগুলো সঠিকভাবে পরীক্ষা করার জন্য, আমার এমন একটি শক্ত সেটআপের প্রয়োজন ছিল যা সবকিছু ক্যাপচার করতে পারে - যা পাঠানো হচ্ছে এবং যা গ্রহণ করা হচ্ছে উভয়ই। আমি webrtc-sandbox নামক একটি টুল দিয়ে শুরু করেছিলাম (যাইহোক, আপনি এই টুল এবং আরও অনেক কিছু সম্পর্কে আমার অন্য পোস্টে জানতে পারবেন: " Learning WebRTC in Practice: Best Tools and Demos "), যা WebRTC ইন্টার্নালের সাথে ঝামেলা করার জন্য দুর্দান্ত। স্ক্রিন শেয়ারিং আরও ভালভাবে পরিচালনা করার জন্য এবং বহির্গামী এবং আগত উভয় ভিডিও স্ট্রিম রেকর্ড করতে নিশ্চিত করার জন্য আমি এটিতে বেশ কিছু পরিবর্তন করেছি। প্রতিটি পরীক্ষা চালানোর সময় আমাকে দুটি ভিডিও ফাইল দেওয়া হয়েছিল - একটি পাঠানো ভিডিওর জন্য এবং একটি প্রাপ্ত ভিডিওর জন্য - যা আমি পরে পাশাপাশি বিশ্লেষণের জন্য ব্যবহার করেছি।

কিন্তু আমি ভিডিও করেই থেমে থাকিনি। আমি গোপনে কী ঘটছে তাও ট্র্যাক করতে চেয়েছিলাম। এর জন্য, আমি সরাসরি Chrome ব্রাউজার থেকে বিস্তারিত WebRTC পরিসংখ্যান সংগ্রহ করেছি। এই পরিসংখ্যানগুলি আমাকে প্রতিটি কোডেক কীভাবে কাজ করে এবং প্রতিটি পরীক্ষার সময় সিমুলেটেড নেটওয়ার্ক কীভাবে আচরণ করে তা জানার একটি উইন্ডো দিয়েছে।

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

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

তথ্য সংগ্রহ: ১৫৭টি পরীক্ষামূলক রান পরে...

সেটআপ প্রস্তুত হয়ে গেলে, আসল পরীক্ষা চালানোর সময় এসে গেল - এবং আমি অনেকগুলি পরীক্ষা চালিয়েছি। একই মেশিনে বারবার পরীক্ষাগুলি পুনরাবৃত্তি করেছি, বিভিন্ন নেটওয়ার্ক কন্ডিশন এবং কোডেক সেটিংস ব্যবহার করে কীভাবে সবকিছু ঠিকঠাক আছে তা দেখার জন্য। মোট, আমি ১৫৭টি ডেটা পয়েন্ট সংগ্রহ করেছি, নিশ্চিত করেছি যে পরীক্ষার প্রতিটি কন্ডিশনের সমন্বয় ভালভাবে উপস্থাপন করা হয়েছে।

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

• ভিডিওর ধরণ :
  সাধারণ ব্যবহারের ক্ষেত্রে প্রতিফলিত করার জন্য আমি দুই ধরণের স্ক্রিন শেয়ার কন্টেন্ট ব্যবহার করেছি:
  • হাই-মোশন ভিডিও - প্রচুর পিক্সেল সহ বাস্তব-বিশ্বের ফুটেজ প্রতিটি ফ্রেম পরিবর্তন করে।
  • অটো-স্ক্রল করা টেক্সট - বেশিরভাগ স্ট্যাটিক ভিজ্যুয়াল, কিন্তু টেক্সট স্ক্রোল করার সাথে সাথে পিক্সেলের অবস্থান পরিবর্তন হয়।
• কোডেক :
  আমি চারটি জনপ্রিয় স্ক্রিন-শেয়ারিং কোডেক পরীক্ষা করেছি:
  • AV1 সম্পর্কে
  • এইচ.২৬৪
  • ভিপি৮
  • ভিপি৯
• নেটওয়ার্ক ব্যান্ডউইথ :
  যেহেতু ভিডিওর মানের ক্ষেত্রে (বিশেষ করে ভিডিও কলে) ব্যান্ডউইথ একটি বিশাল ভূমিকা পালন করে, তাই প্রতিটি কোডেক কতটা ভালোভাবে আঁটসাঁট বা ওঠানামাকারী ব্যান্ডউইথ পরিচালনা করে তা দেখার জন্য আমি বিভিন্ন নেটওয়ার্ক অবস্থার সিমুলেশন করেছি।

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

ত্রুটিগুলি ঠিক করা: আমি কীভাবে পরীক্ষাগুলিকে আরও নির্ভরযোগ্য করে তুলেছি

বেশিরভাগ পরীক্ষার মতো, প্রথম কয়েকটি রান আমার প্রত্যাশা অনুযায়ী মসৃণভাবে হয়নি। দুটি বড় সমস্যা তখনই সামনে এসে পড়ে:

1. ম্যানুয়াল স্টার্ট = এলোমেলো সময়। প্রথমে, আমি স্ক্রিন শেয়ারিং ম্যানুয়ালি শুরু করছিলাম - আক্ষরিক অর্থেই একটা বোতামে ক্লিক করে কাজ শুরু করছিলাম। সমস্যাটা কী? ভিডিও কন্টেন্ট শুরুর সাথে রেকর্ডিং শুরু করা প্রায় অসম্ভব ছিল। এর মানে হল প্রতিটি টেস্ট রানের সময় একটু আলাদা ছিল, যা তুলনামূলকভাবে ভুল ছিল।
2. প্রেরিত বনাম প্রাপ্ত = সিঙ্কের বাইরে। সঠিক সময় নির্ধারণের পরেও, রিয়েল-টাইম ভিডিওর নিজস্ব কিছু বৈশিষ্ট্য রয়েছে। এনকোডিং, ডিকোডিং এবং নেটওয়ার্ক বিলম্বের কারণে, প্রেরিত এবং প্রাপ্ত স্ট্রিমগুলি কখনই নিখুঁতভাবে সারিবদ্ধ হয়নি। এর ফলে ফ্রেম-বাই-ফ্রেম মানের তুলনা প্রায় অসম্ভব হয়ে পড়ে।

এই সমস্যাগুলি সমাধানের জন্য, আমি কয়েকটি গুরুত্বপূর্ণ উন্নতি করেছি:

• প্রোগ্রাম্যাটিক সিঙ্কিং : সবকিছু ম্যানুয়ালি শুরু করার পরিবর্তে, আমি ভিডিওর শুরু বা স্ক্রলিং টেক্সট রেকর্ডিং প্রক্রিয়ার সাথে সিঙ্ক করার জন্য কিছু কোড লিখেছিলাম। এইভাবে, প্রতিটি পরীক্ষা উভয় প্রান্তে ঠিক একই মুহূর্তে শুরু হয়েছিল - সমস্যার সমাধান হয়েছে।
• QR কোড ফ্রেম ম্যাচিং : ডিসিঙ্ক সমস্যার জন্য, আমি শেয়ার করা ভিডিওতে একটি ছোট QR কোড ওভারলে যোগ করেছি। এই ছোট্ট মার্কারটি একটি টাইমস্ট্যাম্পের মতো কাজ করেছে - এটি আমাকে প্রেরিত এবং প্রাপ্ত স্ট্রিমগুলির মধ্যে ফ্রেমগুলিকে নির্ভুলতার সাথে মেলাতে সাহায্য করেছে। হঠাৎ করে, ফ্রেম-বাই-ফ্রেম বিশ্লেষণ করা সম্ভব (এবং আরও নির্ভুল) হয়ে ওঠে।

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

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

আমি কী পরিমাপ করেছি (এবং কেন এটি গুরুত্বপূর্ণ)

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

আমি যা দেখেছি তা এখানে:

• ফ্রেম রেট
  এটি আমাকে বলে যে প্রতি সেকেন্ডে আসলে কতগুলি ফ্রেম এনকোড করা, পাঠানো এবং গ্রহণ করা হয়েছিল। এটি ভিডিও স্ট্রিম কতটা মসৃণ অনুভূত হয় তার একটি ভাল সূচক - উচ্চতর ফ্রেম রেট সাধারণত আরও তরল অভিজ্ঞতা বোঝায়।
• রেজোলিউশন
  রেজোলিউশনের উপর নির্ভর করে ভিজ্যুয়াল ডিটেইল কতটা সংরক্ষিত আছে। আমি প্রতিটি পর্যায়ে (প্রেরিত এবং প্রাপ্ত) ফ্রেমের পিক্সেলের সংখ্যা ট্র্যাক করেছি, কোডেকগুলি ছবির মানের উপর নির্ভর করে কিনা, নাকি ব্যান্ডউইথ সংরক্ষণের জন্য এটি ফেলে দিয়েছে কিনা তা দেখার জন্য।
• ভিডিও কোয়ালিটি
  আমি এখানে কয়েকটি মূল মেট্রিক্স ব্যবহার করেছি:
  • কোয়ান্টাইজেশন প্যারামিটার (QP) - কম QP বলতে সাধারণত ভালো মানের বোঝায়।
  • পিক সিগন্যাল-টু-নয়েজ রেশিও (PSNR) – এটি একটি সংখ্যাসূচক ধারণা দেয় যে প্রাপ্ত ভিডিওটি আসল ভিডিও থেকে কতটা আলাদা। উচ্চতর = ভালো।
• সিপিইউ ব্যবহার
  কোডেক পারফরম্যান্স কেবল আপনি যা দেখেন তার উপর নির্ভর করে না - এটি পর্দার আড়ালে আপনার মেশিন কী করছে তার উপরও নির্ভর করে। প্রতিটি পরীক্ষার সময় এনকোডিং এবং ডিকোডিংয়ের জন্য কতটা CPU পাওয়ার ব্যবহৃত হয়েছিল তা আমি পরিমাপ করেছি, সময়ের সাথে সাথে স্বাভাবিক করা হয়েছে, কোন কোডেকগুলি হালকা এবং কোনগুলি রিসোর্স হগ তা দেখার জন্য।

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

অবশেষে ফলাফলের দিকে আসছি

কন্টেন্টের ধরণ কতটা গুরুত্বপূর্ণ? আপনি যা ভাবেন তার চেয়ে অনেক বেশি

আমার পরীক্ষা-নিরীক্ষা থেকে সবচেয়ে অবাক করা তথ্য হলো, আপনি যে ধরণের কন্টেন্ট শেয়ার করছেন তা স্ক্রিন শেয়ারিং পারফর্ম্যান্সকে কতটা প্রভাবিত করে - ভিডিওর মান এবং রিসোর্স ব্যবহারের ক্ষেত্রে - উভয় ক্ষেত্রেই। এবং আমি যে প্রতিটি কোডেক পরীক্ষা করেছি তার ক্ষেত্রেও এটি সত্য ছিল।

এর পেছনের ধারণাটি বেশ সহজ: যখন আরও পিক্সেল ফ্রেম থেকে ফ্রেমে পরিবর্তিত হয় (যেমন একটি দ্রুত চলমান ভিডিওতে), তখন সিস্টেমটিকে আরও কঠোর পরিশ্রম করতে হয়। এর অর্থ হল আরও ব্যান্ডউইথের প্রয়োজন, এবং আপনার সিপিইউকে তাল মিলিয়ে চলতে আরও বেশি তাড়াহুড়ো করতে হয়।

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

কিন্তু এটা শুধু ব্যান্ডউইথ নয় - তোমার হার্ডওয়্যারও এটা অনুভব করে।

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

এটি কেবল AV1 জিনিস নয়। সমস্ত কোডেক ভিডিও এনকোডিং এবং ডিকোডিংয়ের জন্য একই মৌলিক নীতির উপর নির্ভর করে, তাই আপনি তাদের একই আচরণ দেখাবেন বলে আশা করতে পারেন - তবে ডেটা ভিন্ন গল্প বলে। CPU লোড কেবল কন্টেন্টের সাথে পরিবর্তিত হয় না, এটি আপনি কোন কোডেক ব্যবহার করছেন তার উপর নির্ভর করেও পরিবর্তিত হয়।

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

সুতরাং, যদি আপনি এমন কিছু তৈরি বা অপ্টিমাইজ করেন যা WebRTC স্ক্রিন শেয়ারিংয়ের উপর নির্ভর করে, তাহলে মূল কথাটি স্পষ্ট: আপনার কন্টেন্ট এবং কোডেকের পছন্দ উভয়ই গুরুত্বপূর্ণ। অনেক কিছু।

কোডেক শোডাউন: ফ্রেম রেট, সিপিইউ লোড এবং মানের প্রকৃত খরচ

স্ক্রিন শেয়ারিংয়ের ক্ষেত্রে, আপনার প্রথমেই লক্ষ্য করা যায় ভিডিওটি কতটা মসৃণ (অথবা না) অনুভূত হচ্ছে। এখানেই ফ্রেম রেট আসে। আপনি যদি ভিডিও প্লেব্যাক বা অ্যানিমেশনের মতো হাই-মোশন কন্টেন্ট শেয়ার করেন, তাহলে বিশৃঙ্খলা, দেখা কঠিন স্ট্রিম এড়াতে উচ্চতর ফ্রেম রেট অপরিহার্য।

পরীক্ষার এই অংশে, আমি বিভিন্ন কোডেকের ফ্রেম রেট পারফরম্যান্সের উপর মনোযোগ দিয়েছি, বাকি সবকিছু স্থির রেখে: একই রেজোলিউশন (প্রায় ১.৫ মেগাপিক্সেল) এবং প্রতিটি পরীক্ষার জন্য একই কন্টেন্ট। রেজোলিউশন যাতে সমগ্র বোর্ডে লক থাকে তা নিশ্চিত করার জন্য আমি contentHint WebRTC সেটিং ব্যবহার করেছি।

নিচের ছবিতে , আপনি দেখতে পাচ্ছেন কিভাবে বিভিন্ন কোডেক ব্যান্ডউইথ বৃদ্ধির সাথে সাথে উচ্চ-গতির কন্টেন্ট পরিচালনা করে। x-অক্ষে: বিটরেট Mbps-এ। y-অক্ষে: ফ্রেম রেট প্রতি সেকেন্ডে ফ্রেম (fps)।

এখানে যা উল্লেখযোগ্য ছিল তা হল:

• ব্যান্ডউইথ ২ এমবিপিএস বা তার বেশি হওয়ার পর H.264 এবং AV1 এগিয়ে যায়, উভয়ই ২০+ এফপিএস প্রদান করে - একটি মসৃণ অভিজ্ঞতা যা একটি ভালো 3G সংযোগেও অর্জন করা যায়।
• VP8 এবং VP9 ও তেমনটা ধরে রাখতে পারেনি। একই পরিস্থিতিতে তারা ফ্রেম রেটের প্রায় অর্ধেকে অবস্থান করছিল, এবং ব্যবহারযোগ্য বোধ করার জন্য সত্যিই 4 Mbps বা তার বেশি প্রয়োজন ছিল - যা নিম্ন-স্তরের নেটওয়ার্কগুলিতে সবসময় বাস্তবসম্মত নয়।

তারপর আমি লো-মোশন কন্টেন্টে চলে গেলাম - একটি ধীরে ধীরে স্ক্রোল করা টেক্সট পৃষ্ঠা - ফ্রেমের মধ্যে খুব বেশি পরিবর্তন না হলে কোডেকগুলি কীভাবে কাজ করে তা দেখার জন্য।

আশ্চর্যের বিষয় হলো, এই পরিস্থিতিতে H.264 এবং AV1 উভয়ই আরও ভালো করেছে, AV1 শীর্ষে এসেছে । এটি ইন্ট্রা ব্লক কপি নামক একটি বৈশিষ্ট্যের জন্য ধন্যবাদ, যা AV1 কে স্ক্রিনের এমন অংশগুলিকে পুনরায় এনকোড করা এড়িয়ে যেতে দেয় যা পরিবর্তিত হয়নি। এটি স্ট্যাটিক বা সেমি-স্ট্যাটিক স্ক্রিন শেয়ারিংয়ের জন্য অবিশ্বাস্যভাবে কার্যকর।

পরবর্তী গ্রাফে , আপনি দেখতে পাবেন যে AV1 এই লো-মোশন পরিস্থিতিগুলি কতটা দক্ষতার সাথে পরিচালনা করে, উচ্চ ভিজ্যুয়াল মান বজায় রেখে ব্যান্ডউইথের ব্যবহার চিত্তাকর্ষকভাবে কম রাখে।

কিন্তু... একটা বিনিময় আছে।

AV1 আপনাকে আরও ভালো ভিজ্যুয়াল এবং কম্প্রেশন দিতে পারে, কিন্তু এটি আরও বেশি CPU গ্রাস করে । পরবর্তী ছবিতে এটি স্পষ্টভাবে দেখানো হয়েছে: বিটরেট বৃদ্ধির সাথে সাথে AV1 এর CPU ব্যবহার ক্রমাগত বৃদ্ধি পায়, যা H.264 কে অনেক বেশি ছাড়িয়ে যায়। H.264 এর এখানে একটি বড় সুবিধা রয়েছে কারণ এর ব্যাপক হার্ডওয়্যার ত্বরণ , যা এর CPU লোড কম এবং স্থিতিশীল রাখে।

মজার ব্যাপার হলো, VP9 AV1 এর তুলনায় আরও বেশি CPU ব্যবহার করে - একই ধরণের প্রবণতা অনুসরণ করে কিন্তু উচ্চতর শিখর সহ। VP9 এবং AV1 উভয়ই ভালো মানের ডেলিভারি দেওয়ার জন্য জটিল অ্যালগরিদমের উপর নির্ভর করে, কিন্তু এর জন্য একটি মূল্য দিতে হয়: তারা আপনার প্রসেসরের উপর ভারী আঘাতকারী।

যখন আমি লো-মোশন কন্টেন্টটি আবার দেখলাম, তখন একটা মোড় এসে গেল। এবার, VP8 এবং VP9 আসলে বেশ দক্ষ দেখাচ্ছিল - AV1 এর চেয়ে কম CPU ব্যবহার করে, যেমনটি পরবর্তী গ্রাফে দেখানো হয়েছে।

AV1, স্ক্রিন শেয়ারিংয়ের কথা মাথায় রেখে ডিজাইন করা হলেও, এটিতে সবচেয়ে বেশি CPU ব্যবহার করা হয়েছে। কেন? হাই-মোশন ভিডিও কম্প্রেস করতে সাহায্য করে এমন সমস্ত অপ্টিমাইজেশন ওভারহেডও যোগ করে - এমনকি যখন স্ক্রিনে খুব বেশি কিছু ঘটছে না।

এর একটা বড় কারণ? AV1-এ এখনও ব্যাপক হার্ডওয়্যার এনকোডিং সাপোর্টের অভাব রয়েছে । ডিকোডিং তুলনামূলকভাবে হালকা হলেও, এনকোডিং এখনও বেশিরভাগ ক্ষেত্রেই সফটওয়্যারে করা হয় - এবং এটি একটি CPU-নিবিড় কাজ, বিশেষ করে স্ক্রিন শেয়ারিংয়ের মতো রিয়েল-টাইম পরিস্থিতিতে যেখানে এনকোডিং এবং ডিকোডিং উভয়ই ক্রমাগত ঘটে।

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

কোডেক এবং রেজোলিউশন: ফ্রেম রেটকে অগ্রাধিকার দিলে কী হয়?

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

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

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

এই আচরণ বিশ্লেষণে সাহায্য করার জন্য, আমি একটি নতুন মেট্রিক চালু করেছি:

প্রতি সেকেন্ডে পাঠানো পিক্সেল = ফ্রেম রেট × রেজোলিউশন

এটি কেবল FPS বা রেজোলিউশনের দিকে তাকিয়ে থাকার চেয়ে আরও সম্পূর্ণ চিত্র দেয়। এটি দেখায় যে বিভিন্ন পরিস্থিতিতে কোডেকটি প্রতি সেকেন্ডে আসলে কত ভিজ্যুয়াল ডেটা সরবরাহ করছে।

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

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

বাস্তবে এই সবের অর্থ কী?

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

ধীর গতির কন্টেন্টের ক্ষেত্রেও, AV1 শক্তি প্রদর্শন করে চলেছে। যদিও পার্থক্যটি কম হতে পারে, এটি ধারাবাহিকভাবে আরও ভিজ্যুয়াল ডেটা পাঠাতে সক্ষম হয় - যার অর্থ একই বা কম ব্যান্ডউইথের সাথে আরও ভাল মানের - এর উন্নত কম্প্রেশন কৌশলগুলির জন্য ধন্যবাদ।

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

ছবিটি কতটা পরিষ্কার? আসুন PSNR নিয়ে কথা বলি

ফ্রেম রেট, রেজোলিউশন এবং সিপিইউ ব্যবহারের বাইরেও, স্ক্রিন শেয়ারিং ধাঁধার আরও একটি গুরুত্বপূর্ণ অংশ রয়েছে: প্রাপ্ত ছবিটি আসলটির কতটা কাছাকাছি দেখাচ্ছে? এখানেই পিক সিগন্যাল-টু-নয়েজ রেশিও (PSNR) আসে।

PSNR হল সংকুচিত ভিডিওর মান পরিমাপের জন্য একটি বহুল ব্যবহৃত মেট্রিক। এটি আপনাকে বলে যে এনকোডিংয়ের সময় কতটা বিকৃতি - বা "শব্দ" - প্রবর্তিত হয়েছে। এটি ডেসিবেলে (dB) পরিমাপ করা হয় এবং মূল নিয়মটি সহজ: যত বেশি, তত ভালো । উচ্চ PSNR মানে ছবিটি প্রায় আসলটির মতোই দেখাচ্ছে; কম স্কোর মানে আরও দৃশ্যমান অবক্ষয়।

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

এই সেটআপে, যেখানে স্পষ্টতাই মূল বিষয় (যদিও ভিডিওটি একটু এলোমেলো হয়), H.264 বিশেষভাবে ভালো পারফর্ম করেছে , ন্যূনতম বিকৃতির সাথে তীক্ষ্ণ ভিজ্যুয়াল প্রদান করেছে। যখন মসৃণতা ততটা গুরুত্বপূর্ণ নয় তখন এটি একটি শক্তিশালী পছন্দ।

যখন লক্ষ্যটি তরল গতি বজায় রাখার দিকে স্থানান্তরিত হয়, তখন AV1 এগিয়ে আসে , বিশেষ করে উচ্চ বিটরেটে। এটি ফ্রেম রেট লক্ষ্যমাত্রা অর্জনের জন্য আক্রমণাত্মকভাবে সংকুচিত হওয়ার পরেও ছবির মান সংরক্ষণ করতে সক্ষম হয়।

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

তারপর আমি আবার একই পরীক্ষা চালিয়েছি, এবার স্ক্রোল করা টেক্সট কন্টেন্ট ব্যবহার করে - যা সত্যিই রেজোলিউশন এবং স্পষ্টতার গুরুত্বের উপর জোর দেয়।

যখন গতিকে অগ্রাধিকার দেওয়া হয়, তখন সমস্ত কোডেকের PSNR মানগুলি বেশ একই রকম দেখায়। কন্টেন্ট খুব বেশি পরিবর্তন হচ্ছে না, তাই কম্প্রেশন কৌশলের পার্থক্য সামগ্রিক ছবির মানের উপর খুব বেশি প্রভাব ফেলে না।

এখানেই জিনিসগুলি আকর্ষণীয় হয়ে ওঠে। রেজোলিউশনকে অগ্রাধিকার দেওয়ার সাথে সাথে, AV1 অন্যান্য কোডেকগুলির তুলনায় অনেক এগিয়ে - বিশেষ করে উচ্চ বিটরেটে। এখানে এর কর্মক্ষমতা ব্যতিক্রমী।

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

সংক্ষেপে, PSNR স্ক্রিন শেয়ারিং মানের একটি সূক্ষ্ম কিন্তু গুরুত্বপূর্ণ দিক তুলে ধরতে সাহায্য করে। আপনি গতি বা তীক্ষ্ণতাকে অগ্রাধিকার দিন না কেন, বিভিন্ন সীমাবদ্ধতার মধ্যে কোডেক কীভাবে আচরণ করে তা বোঝা আপনাকে কাজের জন্য সঠিকটি বেছে নিতে সাহায্য করে।

QP এর সাথে কী চুক্তি? কম্প্রেশন বনাম গুণমান বোঝা

স্ক্রিন শেয়ারিং মানের আরেকটি গুরুত্বপূর্ণ বিষয় হল কোয়ান্টাইজেশন প্যারামিটার , বা QP । যদি আপনি কখনও ভেবে থাকেন যে কম্প্রেশনের সময় কত বিবরণ হারিয়ে যায় তা কী নিয়ন্ত্রণ করে, তাহলে এটিই।

সহজ ভাষায়, QP এনকোডারকে বলে যে ভিডিওটি কতটা আক্রমণাত্মকভাবে সংকুচিত করতে হবে ।

• কম QP মানে কম কম্প্রেশন এবং উন্নত ছবির মান।
• উচ্চ QP মানে বেশি কম্প্রেশন - যা ব্যান্ডউইথ সাশ্রয় করে, কিন্তু ভিডিওটিকে আরও খারাপ দেখাতে পারে।

যদিও PSNR আমাদের একটি ফলাফল দেয় - ছবির মান কতটা সংরক্ষণ করা হয়েছিল - QP আমাদের বলে যে এনকোডারটি কী লক্ষ্য করছিল । তাই, আমি উভয় দিকেই নজর দিলাম।

এই গবেষণায়:

• QP মানগুলি স্ট্যান্ডার্ড WebRTC মেট্রিক্স থেকে নেওয়া হয়েছিল।
• প্রতিটি মূল ফ্রেমের সাথে তার প্রাপ্ত সংস্করণের তুলনা করে PSNR পরিমাপ করা হয়েছিল।

এখানেই বিষয়গুলো আকর্ষণীয় হয়ে ওঠে। AV1-এর PSNR স্কোর সবচেয়ে ভালো ছিল , অর্থাৎ এটি ছবির মান সবচেয়ে ভালোভাবে সংরক্ষণ করেছে - কিন্তু এর QP মান অন্যান্য কোডেকগুলির তুলনায় চার গুণ বেশি ছিল। প্রথম নজরে এটি পরস্পরবিরোধী বলে মনে হয়।

কিন্তু এখানেই সমস্যা: প্রতিটি কোডেক QP কে ভিন্নভাবে সংজ্ঞায়িত করে এবং পরিচালনা করে , তাই মানগুলি সরাসরি তুলনাযোগ্য নয়। একটি কোডেকে ৫০ এর QP মানে অন্য কোডেকে ৫০ এর QP এর সমান কম্প্রেশন স্তর নয়।

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

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

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

চূড়ান্ত ভাবনা: WebRTC স্ক্রিন শেয়ারিংয়ের জন্য এর অর্থ কী?

WebRTC কীভাবে কাজ করে তা গভীরভাবে বিশ্লেষণ করার পর, একটি জিনিস স্পষ্ট: সমস্ত কোডেক সমানভাবে তৈরি হয় না - এবং সেরা পছন্দটি আসলে আপনার অগ্রাধিকার এবং পরিবেশের উপর নির্ভর করে।

আমার পরীক্ষা-নিরীক্ষা থেকে প্রাপ্ত মূল বিষয়গুলি এখানে দেওয়া হল:

AV1: সেরা মানের, সর্বোচ্চ খরচ

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

H.264: দ্য সলিড অল-রাউন্ডার

যদি আপনি কর্মক্ষমতা এবং দক্ষতার মধ্যে ভারসাম্য খুঁজছেন, তাহলে H.264 এখনও একটি দুর্দান্ত পছন্দ। এটি ব্যাপকভাবে সমর্থিত, বেশিরভাগ প্ল্যাটফর্মে হার্ডওয়্যার-ত্বরিত, এবং প্রায় প্রতিটি পরিস্থিতিতেই ভালো কাজ করে - বিশেষ করে যখন সিস্টেম রিসোর্স বা ব্যাটারি লাইফ একটি উদ্বেগের বিষয়।

আপনার ধারণার চেয়ে বিষয়বস্তু বেশি গুরুত্বপূর্ণ

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

সিপিইউ ব্যবহার কেবল একটি পাদটীকা নয়

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

এরপর কী? এই গবেষণা কোথায় যেতে পারে?

এই পরীক্ষাটি পরবর্তী কিছু উত্তেজনাপূর্ণ পদক্ষেপের দরজা খুলে দিয়েছে। এখানেই আমার মনে হয় ভবিষ্যতের কাজ আরও বড় প্রভাব ফেলতে পারে:

মোবাইল ডিভাইসে পরীক্ষা করা হচ্ছে

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

শক্তি দক্ষতা

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

এআই-চালিত কোডেক টিউনিং

কল্পনা করুন যদি WebRTC আপনার বর্তমান কন্টেন্ট এবং নেটওয়ার্কের গতির উপর ভিত্তি করে স্বয়ংক্রিয়ভাবে কোডেক সেটিংস সামঞ্জস্য করতে পারে। AI এটি সম্ভব করে তুলতে পারে , রিয়েল-টাইমে গুণমান এবং কর্মক্ষমতার মধ্যে গতিশীলভাবে নিখুঁত ভারসাম্য খুঁজে পেতে।

এটি গুছিয়ে নেওয়া

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

WebRTC-এর বিকশিত হওয়ার সাথে সাথে এর চারপাশের সরঞ্জাম এবং কৌশলগুলিও বিকশিত হবে। আমি আশা করি এই গভীর অনুসন্ধান অন্যদের পর্দার আড়ালে কী ঘটছে - এবং কীভাবে তাদের স্ক্রিন শেয়ারিং স্ট্যাক থেকে সর্বাধিক সুবিধা পাওয়া যায় তা আরও ভালভাবে বুঝতে সাহায্য করবে।

নিজে ডেটা অন্বেষণ করতে চান?

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

Kaggle-এ ডেটাসেট ডাউনলোড করুন

এতে ফ্রেম রেট, রেজোলিউশন, PSNR, QP, CPU ব্যবহার এবং আরও অনেক কিছুর জন্য কাঁচা মেট্রিক্স অন্তর্ভুক্ত রয়েছে - সবকিছুই কোডেক, কন্টেন্টের ধরণ এবং ব্যান্ডউইথের অবস্থা অনুসারে সংগঠিত। আপনার নিজস্ব পরীক্ষা, বেঞ্চমার্কিং, অথবা বিভিন্ন পরিস্থিতিতে WebRTC কীভাবে আচরণ করে তা অন্বেষণ করার জন্য এটি ব্যবহার করতে দ্বিধা করবেন না।