লাইভ স্ট্রিমিং আসলে কী
কনটেন্ট যখন এখনো তৈরিই হয়নি, তখন কী কী বদলে যায় — রিয়েল-টাইম বাজেট, দ্বিতীয় সুযোগ না থাকা, glass-to-glass লেটেন্সি, লেটেন্সির শ্রেণি, আর কোন কাজে কতটা লেটেন্সি চলে।
গল্পে বুঝি
মিরপুর শেরে বাংলা স্টেডিয়ামে বাংলাদেশ-ভারত ম্যাচ। রুশদ অফিসে আটকা, টিভি নেই, তাই টেবিলের নিচে একটা ছোট রেডিও চালিয়ে বাংলাদেশ বেতারের ধারাভাষ্য শুনছে। ধারাভাষ্যকার হাইসাম মাঠের প্রেসবক্সে বসে বলছেন, “বল করছেন মুস্তাফিজ… অফ স্টাম্পের বাইরে… ব্যাটসম্যান খোঁচা দিলেন… ক্যাচ! ক্যাচ! আউট!” রুশদ লাফিয়ে ওঠে। মাঠে বলটা যখন উইকেটকিপারের গ্লাভসে ঢুকেছে, তার মাত্র কয়েক সেকেন্ড পরেই রুশদ সেটা শুনে ফেলেছে। হাইসামের মুখ থেকে মাইক্রোফোন, মাইক্রোফোন থেকে বেতারের স্টুডিও, স্টুডিও থেকে ট্রান্সমিটার, ট্রান্সমিটার থেকে রুশদের রেডিও, সবটা ঘটছে খেলার সাথে তাল মিলিয়ে। হাইসামের একটাই শর্ত: কথা থামানো যাবে না। চা খেতে উঠলে, বা একটা শব্দ ঠিকমতো না বললে, পরে আর সেটা ঠিক করার উপায় নেই; বল ততক্ষণে পরের ওভারে।
পরদিন সকালে বিরুনি একই ম্যাচের কথা পড়ছে প্রথম আলোর খেলার পাতায়। সেখানে প্রতিবেদক ফাতিমা রাতভর সময় নিয়ে লিখেছেন, স্কোরকার্ড মিলিয়েছেন, ছবি বেছেছেন, সম্পাদক দুবার ভুল ধরেছেন, তারপর ছাপাখানায় গেছে। বিরুনির খবর নিখুঁত, সাজানো, যত বার ইচ্ছা পড়া যায়, আর সে চাইলে প্রথম ইনিংসের অংশটা বাদ দিয়ে সরাসরি শেষ ওভারে যেতে পারে। কিন্তু খবরটা তার হাতে এসেছে প্রায় বারো ঘণ্টা পরে। আর পত্রিকার একটা কপি ছাপা হলে বাকি লাখ কপিও হুবহু একই, কারণ খবরটা আগে থেকেই পুরোটা তৈরি।
আরেকটা জিনিস খেয়াল করার মতো। হাইসাম মাঠ থেকে স্টুডিওতে তার কণ্ঠ পাঠাচ্ছেন একটা আলাদা, ভালো মানের লাইনে; সেটা শুধু একটাই গন্তব্যে যায়, বেতারের স্টুডিওতে। স্টুডিও থেকে সেটা ট্রান্সমিটারে, তারপর দেশের লাখো রেডিওতে একসাথে ছড়িয়ে পড়ে। মাঠ থেকে স্টুডিওর পথ একজনের জন্য, কিন্তু খুব নির্ভরযোগ্য হতে হবে; স্টুডিও থেকে দেশের পথ কোটি মানুষের জন্য, কিন্তু কেউ এক মুহূর্ত দেরিতে শুনলে ক্ষতি নেই। আর রুশদ যদি জোরে রেডিও বাজায় আর পাশের ডেস্কের ফারাবি মোবাইলে টিভির লাইভ দেখে, তাহলে ফারাবির চিৎকার (“ছক্কা!“) রুশদ শোনে রেডিওতে বল হওয়ার আগেই, বা পরে; দুজনের “লাইভ” এক নয়।
মিলিয়ে নিই: হাইসামের ধারাভাষ্য হলো লাইভ স্ট্রিম, যেখানে কনটেন্ট তৈরি হওয়ার সাথে সাথেই পাঠাতে হয়। প্রথম আলোর প্রতিবেদন হলো VOD, যা পুরোটা তৈরি হওয়ার পর আসে, নিখুঁত, সিক করা যায়। বল গ্লাভসে ঢোকা থেকে রুশদের কানে পৌঁছানো পর্যন্ত সময়টা glass-to-glass latency। “কথা থামানো যাবে না, ভুল শুধরানোর সুযোগ নেই” হলো লাইভের রিয়েল-টাইম বাজেট আর দ্বিতীয় সুযোগ না থাকা। মাঠ থেকে স্টুডিওর আলাদা লাইন হলো contribution, স্টুডিও থেকে দেশজুড়ে ছড়ানো হলো distribution। আর রুশদ ও ফারাবির আলাদা সময়ে শোনা হলো লেটেন্সির শ্রেণি ও sync সমস্যা। বাস্তবে খেলা, ওয়াজ, অনলাইন ক্লাস বা নিলাম, প্রতিটা লাইভ প্ল্যাটফর্মের ডিজাইন শুরু হয় একটাই প্রশ্ন দিয়ে: দর্শক কতটা দেরি মেনে নেবে।
লাইভ মানে কী বদলে যায়
VOD-তে একটা ফাইল আগে থেকে পুরোটা থাকে। আপনি চাইলে সেটা দশ মিনিট ধরে এনকোড করতে পারেন, ভুল হলে আবার চালাতে পারেন, সব রেন্ডিশন বানিয়ে যাচাই করে তারপর প্রকাশ করতে পারেন। লাইভে এই প্রতিটা স্বাধীনতা চলে যায়, কারণ কনটেন্টটা এই মুহূর্তে তৈরি হচ্ছে।
চারটা জিনিস মৌলিকভাবে আলাদা হয়ে যায়:
১. প্রতিটা ধাপের একটা ডেডলাইন আছে। এক সেকেন্ডের ভিডিও এক সেকেন্ডের কম সময়ে এনকোড, প্যাকেজ আর প্রকাশ করতে হবে, প্রতিটা সেকেন্ডে, স্ট্রিম যতক্ষণ চলে ততক্ষণ। একটা ধাপ যদি ১.০২ গুণ ধীর হয়, কিছু সাথে সাথে ভাঙে না, কিন্তু প্রতি মিনিটে দেরি জমতে থাকে আর কখনো পূরণ হয় না। এই ব্যাপারটা ট্রান্সকোডারের দিক থেকে ভিডিও ট্র্যাকের লো-লেটেন্সি চ্যাপ্টারে বিস্তারিত আছে।
২. দ্বিতীয় সুযোগ নেই। VOD-তে এনকোড ব্যর্থ হলে রিট্রাই করা যায়, দর্শক জানেও না। লাইভে এনকোডার দশ সেকেন্ডের জন্য পড়ে গেলে ওই দশ সেকেন্ড চিরতরে হারিয়ে গেল। তাই লাইভ সিস্টেমের ডিজাইনের বড় অংশ হলো ব্যর্থতার সময় কী দেখাবেন (স্লেট, ব্যাকআপ স্ট্রিম, ধরে রাখা শেষ ফ্রেম), শুধু ব্যর্থতা ঠেকানো নয়।
৩. উৎসটা আপনার নিয়ন্ত্রণে নেই। VOD-তে ফাইল একবার আপলোড হলেই হলো, আপলোড ধীর হলে শুধু দেরি হয়। লাইভে উৎস হলো কারও বাড়ির বা মাঠের ইন্টারনেট, আর সেটা পুরো স্ট্রিম জুড়ে টানা কাজ করতে হবে। দর্শক যা দেখে তার মান কখনো উৎসের চেয়ে ভালো হতে পারে না।
৪. সবাই একসাথে আসে। একটা জনপ্রিয় VOD ভিডিও কয়েক দিন ধরে লাখ ভিউ পায়। একটা ম্যাচ বা ঘোষণার লাইভে লাখ মানুষ একই মিনিটে আসে, আর সবাই একই সেগমেন্ট চায়, যেটা মাত্র কয়েক সেকেন্ড আগে তৈরি হয়েছে। এই ভিড় সামলানো আট নম্বর চ্যাপ্টারের বিষয়।
| দিক | VOD | লাইভ |
|---|---|---|
| কনটেন্ট কখন আছে | আগে থেকে পুরোটা | তৈরি হচ্ছে এই মুহূর্তে |
| এনকোডিংয়ের সময় | যত ইচ্ছা, ধীর preset চলে | রিয়েল-টাইমের নিচে, দ্রুত preset |
| ব্যর্থ হলে | রিট্রাই, দর্শক জানে না | ওই অংশ হারিয়ে গেল, দর্শক সাথে সাথে দেখে |
| উৎস | একটা ফাইল, একবার আপলোড | টানা স্ট্রিম, অন্য কারও নেটওয়ার্ক |
| প্লেলিস্ট | স্থির, শেষে EXT-X-ENDLIST | প্রতি সেগমেন্টে বদলায়, শেষ জানা নেই |
| দর্শকের ভিড় | সময়জুড়ে ছড়ানো | একই মিনিটে, একই সেগমেন্টে |
| CDN ক্যাশ | লম্বা TTL, বছরের পর বছর | সেগমেন্ট লম্বা, প্লেলিস্ট কয়েক সেকেন্ড |
| সিক | পুরো ফাইলে যেকোনো জায়গায় | শুধু DVR উইন্ডোর মধ্যে (চ্যাপ্টার ৭) |
| মান যাচাই | প্রকাশের আগে | চলতে চলতে, মনিটরিং দিয়ে (চ্যাপ্টার ১২) |
Glass-to-glass লেটেন্সি
লাইভে সবচেয়ে বেশি আলোচিত সংখ্যা হলো glass-to-glass latency: ক্যামেরার কাচে (লেন্সে) আলো পড়ার মুহূর্ত থেকে দর্শকের কাচে (স্ক্রিনে) সেই ছবি দেখা পর্যন্ত সময়। একে কখনো “end-to-end latency” বা “glass-to-glass delay” বলা হয়।
সময়টা অনেকগুলো ধাপে ভাগ হয়ে যায়:
প্রতিটা তীরে কিছু মিলিসেকেন্ড বা সেকেন্ড যোগ হয়। কোন ধাপে কত যায়, তার একটা পূর্ণ টেবিল ভিডিও ট্র্যাকের নয় নম্বর চ্যাপ্টারে আছে; এখানে শুধু মূল সত্যটা মনে রাখুন, কারণ পুরো ট্র্যাক এর উপর দাঁড়িয়ে: একটা সাধারণ HLS স্ট্রিমের দেরির সিংহভাগ নেটওয়ার্কে যায় না, যায় অপেক্ষায়। সেগমেন্ট পুরো হওয়ার অপেক্ষা, আর প্লেয়ারের হাতে কয়েকটা সেগমেন্ট জমানোর অপেক্ষা। নেটওয়ার্ক আর এনকোডিং মিলে সাধারণত এক-দুই সেকেন্ড।
তাই লেটেন্সি নিয়ে কেউ অভিযোগ করলে প্রথম প্রশ্ন “সার্ভার কোথায়?” নয়, প্রথম প্রশ্ন “সেগমেন্ট কত সেকেন্ডের, আর প্লেয়ার কতগুলো জমিয়ে শুরু করে?”
লেটেন্সি নিজে মাপবেন কীভাবে
সবচেয়ে সৎ মাপ হলো চোখে দেখা ঘড়ি। ক্যামেরার সামনে একটা মিলিসেকেন্ড দেখানো ঘড়ি রাখুন (ফোনে একটা স্টপওয়াচ বা ব্রাউজারে time.is খোলা), আর পাশে প্লেয়ারটা চালান। দুটোকে এক ফ্রেমে রেখে একটা ছবি তুলুন; দুই ঘড়ির পার্থক্যটাই glass-to-glass।
ক্যামেরা না থাকলে ffmpeg দিয়ে উৎসে ঘড়ি বসিয়ে দেওয়া যায়, প্রতিটা ফ্রেমে তখনকার wall-clock সময় লিখে:
# Burn the sender's wall clock into every frame, then compare with a clock beside the player.
ffmpeg -re -f lavfi -i testsrc2=size=1280x720:rate=30 \
-vf "drawtext=text='%{localtime\:%H\\\:%M\\\:%S}.%{eif\:mod(n\,30)*1000/30\:d\:3}':fontsize=64:fontcolor=white:box=1:boxcolor=black@0.6:x=40:y=40" \
-c:v libx264 -preset veryfast -tune zerolatency -g 60 -b:v 2500k \
-f flv "rtmp://ingest.baytalhikma.org/live/test?user=enc&pass=sk_7f3a9c2e"একই স্ট্রিম তিনটা আলাদা প্লেয়ারে পাশাপাশি খুলে দেখুন (একটা ল্যাপটপের ব্রাউজার, একটা ফোন, একটা টিভি অ্যাপ)। প্রায় সবসময় দেখবেন তিনজন তিন রকম পিছিয়ে আছে, কারণ প্রত্যেকটা প্লেয়ার নিজের মতো করে বাফার করে। “আমাদের লেটেন্সি কত?” প্রশ্নের সৎ উত্তর তাই একটা সংখ্যা নয়, একটা রেঞ্জ, আর সেটা প্লেয়ার অনুযায়ী আলাদা।
লেটেন্সির শ্রেণি
ইন্ডাস্ট্রিতে লেটেন্সিকে মোটামুটি চারটা শ্রেণিতে ভাগ করা হয়। সীমাগুলো কোনো মান নয়, ভেন্ডার ভেদে নামও আলাদা; নিচের সংখ্যাগুলো সাধারণত যা দেখা যায় তার আনুমানিক রেঞ্জ।
| শ্রেণি | সাধারণ glass-to-glass | কীভাবে আসে | দাম |
|---|---|---|---|
| স্ট্যান্ডার্ড HLS/DASH | মোটামুটি ১৫-৩০ সেকেন্ড | ৪-৬ সেকেন্ড সেগমেন্ট, প্লেয়ারে ৩টা জমানো | সবচেয়ে সস্তা, সবচেয়ে স্থিতিশীল, যেকোনো CDN |
| রিডিউসড লেটেন্সি | মোটামুটি ৬-১২ সেকেন্ড | ১-২ সেকেন্ড সেগমেন্ট, ছোট প্লেয়ার বাফার | বেশি রিকোয়েস্ট, keyframe বেশি |
| লো লেটেন্সি (LL-HLS ইত্যাদি) | মোটামুটি ২-৫ সেকেন্ড | partial segment, blocking reload, chunked CMAF | CDN ও প্লেয়ার সাপোর্ট লাগে, টিউনিং জটিল |
| রিয়েল-টাইম (WebRTC) | এক সেকেন্ডের নিচে | UDP, প্রায় কোনো বাফার নেই | স্কেল করা কঠিন ও দামি, মান কম স্থিতিশীল |
সম্প্রচারের টিভি (কেবল বা স্যাটেলাইট) নিজেই সাধারণত কয়েক সেকেন্ড পিছিয়ে থাকে, তাই “টিভির মতো” লক্ষ্যটা প্রায়ই লো লেটেন্সির শ্রেণিতে পড়ে, রিয়েল-টাইমে নয়।
লেটেন্সি কমানো বিনামূল্যে নয়। প্রতিটা ধাপ নিচে নামলে প্লেয়ারের হাতে বাফার কমে, আর বাফার কম মানে নেটওয়ার্কের সামান্য ঝাঁকুনিতেও ভিডিও আটকে যায়। বাংলাদেশের মোবাইল নেটওয়ার্কে, যেখানে একই দর্শকের থ্রুপুট কয়েক সেকেন্ডের মধ্যে অনেক ওঠানামা করে, দুই সেকেন্ডের লেটেন্সি ধরে রাখতে গিয়ে রিবাফার বেড়ে যাওয়া খুব সাধারণ। আগে ঠিক করুন আপনার দর্শকের আসলে কতটা লেটেন্সি দরকার, তারপর সবচেয়ে বেশি লেটেন্সিটা বেছে নিন যেটা সেই দরকার মেটায়।
কোন কাজে কতটা লেটেন্সি দরকার
সবচেয়ে দরকারি প্রশ্নটা টেকনিক্যাল নয়: দর্শক কি স্ট্রিমের সাথে কোনোভাবে মিথস্ক্রিয়া করবে, আর অন্য কোনো উৎসের সাথে কি তাকে মিলতে হবে?
| ব্যবহার | কতটা লেটেন্সি চলে | কেন |
|---|---|---|
| ওয়াজ মাহফিল, ধর্মীয় আলোচনা | স্ট্যান্ডার্ড, ২০-৩০ সেকেন্ডও চলে | দর্শক শুধু শোনে, স্থিতিশীলতা সবচেয়ে জরুরি, অনেকেই দুর্বল নেটওয়ার্কে |
| কনসার্ট, অনুষ্ঠান, বিয়ের লাইভ | স্ট্যান্ডার্ড বা রিডিউসড | মিথস্ক্রিয়া নেই, তবে কমেন্টে সাড়া দিলে কম দেরি ভালো |
| খেলা (ক্রিকেট, ফুটবল) | লো লেটেন্সি, মোটামুটি ৩-৮ সেকেন্ড | পাশের বাড়ির টিভি বা মোবাইল নোটিফিকেশন যেন আগে “ছক্কা” না জানায় |
| অনলাইন ক্লাস, প্রশ্নোত্তর | লো লেটেন্সি | শিক্ষক প্রশ্ন করলে উত্তর ২০ সেকেন্ড পরে এলে ক্লাস চলে না |
| নিলাম, বাজি, লাইভ শপিং | লো বা রিয়েল-টাইম | দামের সিদ্ধান্ত দেরিতে নিলে টাকার ক্ষতি |
| ভিডিও কল, রিমোট গেস্ট, ড্রোন কন্ট্রোল | রিয়েল-টাইম, এক সেকেন্ডের নিচে | কথোপকথন বা নিয়ন্ত্রণ দুই দিকেই চলে |
একটা প্ল্যাটফর্মে প্রায়ই দুইটা শ্রেণি একসাথে চলে। একটা টক-শোতে উপস্থাপক আর রিমোট অতিথিরা নিজেদের মধ্যে WebRTC-তে কথা বলেন (রিয়েল-টাইম), আর সেই মিক্স করা আউটপুট লাখ দর্শকের কাছে যায় HLS-এ (স্ট্যান্ডার্ড বা লো)। কাজের অংশ আর দেখার অংশের লেটেন্সি আলাদা রাখাই সাধারণ ও সস্তা নকশা।
Contribution আর distribution
লাইভ পাইপলাইনের দুই অর্ধেকের সমস্যা এত আলাদা যে ইন্ডাস্ট্রিতে এদের আলাদা নাম আছে।
Contribution হলো উৎস থেকে আপনার সিস্টেম পর্যন্ত: এনকোডার থেকে ইনজেস্ট সার্ভার। একটা স্ট্রিম, একটা গন্তব্য, কিন্তু পথটা অনিশ্চিত (কারও ব্রডব্যান্ড, মাঠের মোবাইল হটস্পট, স্যাটেলাইট লিংক)। এখানে প্রশ্ন হলো: প্যাকেট হারালে কী হবে, ব্যান্ডউইথ কমলে কী হবে, সংযোগ কাটলে কত দ্রুত ফিরবে। প্রোটোকল: RTMP, SRT, WHIP, RIST (চ্যাপ্টার ২)।
Distribution হলো আপনার সিস্টেম থেকে দর্শক পর্যন্ত: origin থেকে CDN হয়ে লাখো প্লেয়ার। পথগুলো আপনি নিয়ন্ত্রণ করেন না, কিন্তু প্রতিটা দর্শক একই জিনিস চায়, তাই ক্যাশ করা যায়। এখানে প্রশ্ন হলো: একই মিনিটে লাখ রিকোয়েস্ট কীভাবে সামলাবেন, প্রতিটা দর্শকের নেটওয়ার্ক অনুযায়ী কোয়ালিটি কীভাবে দেবেন। প্রোটোকল: প্রায় সবসময় HTTP-র উপর HLS বা DASH, রিয়েল-টাইম হলে WebRTC (চ্যাপ্টার ৬ ও ৮)।
| দিক | Contribution | Distribution |
|---|---|---|
| সংখ্যা | একটা (বা ব্যাকআপসহ দুইটা) স্ট্রিম | হাজার থেকে লাখ দর্শক |
| মান | সবচেয়ে উঁচু, একটাই রেন্ডিশন | ABR ladder, অনেক রেন্ডিশন |
| নেটওয়ার্ক | একটা অনিশ্চিত আপলিংক | CDN, তারপর দর্শকের ডাউনলিংক |
| প্রধান ভয় | প্যাকেট লস, সংযোগ কাটা | ভিড়, origin-এ চাপ, রিবাফার |
| প্রোটোকল | RTMP, SRT, WHIP, RIST | HLS, DASH, LL-HLS, WebRTC (WHEP) |
| ক্যাশ | অসম্ভব, প্রতিটা বাইট একবারই | মূল কৌশলই ক্যাশ |
এই ভাগটা মাথায় থাকলে ডিবাগিং অর্ধেক সহজ হয়ে যায়: সমস্যাটা কি সব দর্শকের, নাকি কিছু দর্শকের? সবার হলে প্রায় নিশ্চিতভাবে contribution বা প্রসেসিংয়ের দিকে, কিছু দর্শকের হলে distribution বা প্লেয়ারের দিকে।
লাইভ প্লেলিস্ট দেখতে কেমন
লাইভ যে VOD থেকে আলাদা সেটা সবচেয়ে সহজে চোখে পড়ে প্লেলিস্টে। একটা VOD HLS মিডিয়া প্লেলিস্ট পুরোটা একবারে তৈরি, আর শেষে লেখা থাকে “আর কিছু নেই”:
#EXTM3U
#EXT-X-VERSION:7
#EXT-X-TARGETDURATION:6
#EXT-X-PLAYLIST-TYPE:VOD
#EXTINF:6.000,
seg_00000.m4s
#EXTINF:6.000,
seg_00001.m4s
... (all 600 segments)
#EXT-X-ENDLISTএকটা লাইভ প্লেলিস্টে EXT-X-ENDLIST নেই, শুধু শেষ কয়েকটা সেগমেন্টের একটা চলমান জানালা আছে, আর প্লেয়ার কয়েক সেকেন্ড পরপর এটা আবার নিয়ে আসে। প্রতিবার নিচে একটা নতুন সেগমেন্ট যোগ হয়, উপরের একটা বাদ পড়ে, আর EXT-X-MEDIA-SEQUENCE এক বাড়ে (উদাহরণ, সংখ্যাগুলো ব্যাখ্যার জন্য):
#EXTM3U
#EXT-X-VERSION:7
#EXT-X-TARGETDURATION:2
#EXT-X-MEDIA-SEQUENCE:4817
#EXT-X-PROGRAM-DATE-TIME:2026-10-25T14:32:10.000+06:00
#EXTINF:2.000,
seg_04817.m4s
#EXTINF:2.000,
seg_04818.m4s
#EXTINF:2.000,
seg_04819.m4s
#EXTINF:2.000,
seg_04820.m4s
#EXTINF:2.000,
seg_04821.m4sতিনটা জিনিস লক্ষ্য করুন। EXT-X-ENDLIST না থাকাটাই প্লেয়ারকে বলে “এটা লাইভ, আবার এসে দেখো”। EXT-X-MEDIA-SEQUENCE বলে জানালার প্রথম সেগমেন্টের নম্বর, যাতে প্লেয়ার বুঝতে পারে কোনগুলো নতুন। আর EXT-X-PROGRAM-DATE-TIME সেগমেন্টকে wall-clock সময়ের সাথে বাঁধে, যা দিয়ে লেটেন্সি মাপা, DVR আর অন্য স্ক্রিনের সাথে সিঙ্ক করা যায় (চ্যাপ্টার ১০)। প্লেলিস্ট কাঠামোর বাকিটা প্যাকেজিং চ্যাপ্টারে আছে।
নিজের চোখে লাইভ প্লেলিস্ট বদলাতে দেখতে চাইলে যেকোনো লাইভ HLS URL-এ কয়েক সেকেন্ড পরপর curl চালান:
URL=https://live.baytalhikma.org/hls/baytalhikma/video1_stream.m3u8
for i in 1 2 3; do curl -s "$URL" | grep -E 'MEDIA-SEQUENCE|PROGRAM-DATE-TIME' ; sleep 2; done#EXT-X-MEDIA-SEQUENCE:4817
#EXT-X-PROGRAM-DATE-TIME:2026-10-25T14:32:10.000+06:00
#EXT-X-MEDIA-SEQUENCE:4818
#EXT-X-PROGRAM-DATE-TIME:2026-10-25T14:32:12.000+06:00
#EXT-X-MEDIA-SEQUENCE:4819
#EXT-X-PROGRAM-DATE-TIME:2026-10-25T14:32:14.000+06:00(আউটপুটটা উদাহরণ।) সংখ্যা যদি না বাড়ে, প্লেলিস্ট “আটকে” আছে, আর দর্শক কয়েক সেকেন্ড পর বাফারিং দেখবে। এটা লাইভের সবচেয়ে সাধারণ সমস্যাগুলোর একটা, আর ডিবাগিং অংশে আবার আসছে।
একটা লাইভ প্ল্যাটফর্মের অংশগুলো
এই ট্র্যাক যে অংশগুলো একে একে দেখাবে, এক জায়গায়:
| অংশ | কাজ | চ্যাপ্টার |
|---|---|---|
| এনকোডার | ক্যামেরা আর মাইককে একটা কমপ্রেসড স্ট্রিমে বানানো | ৩ |
| Contribution প্রোটোকল | এনকোডার থেকে সার্ভারে স্ট্রিম পাঠানো | ২ |
| ইনজেস্ট সার্ভার | স্ট্রিম গ্রহণ, অথেন্টিকেশন, পরের ধাপে পাঠানো | ৪ |
| লাইভ ট্রান্সকোডার | ABR ladder বানানো, রিয়েল-টাইমের নিচে | ৫ |
| প্যাকেজার ও origin | সেগমেন্ট আর প্লেলিস্ট লেখা, পরিবেশন করা | ৫, ৬ |
| DVR ও আর্কাইভ | পেছনে টানা, ক্লিপ, লাইভ শেষে VOD বানানো | ৭ |
| CDN | লাখ দর্শকের কাছে ছড়ানো | ৮ |
| রিডানডেন্সি | একটা অংশ পড়ে গেলেও স্ট্রিম চালু রাখা | ৯ |
| মেটাডেটা ও সিঙ্ক | স্কোর, চ্যাট, অ্যাড মার্কার ভিডিওর সাথে মেলানো | ১০ |
| মনিটরিং | সমস্যা দর্শকের আগে আপনি জানা | ১২ |
ডিবাগিং: এই চ্যাপ্টারের সমস্যাগুলো
| লক্ষণ | নিশ্চিত হবেন কীভাবে | সমাধান |
|---|---|---|
| “লাইভ ৩০ সেকেন্ড পিছিয়ে” অভিযোগ | মিডিয়া প্লেলিস্টে #EXT-X-TARGETDURATION দেখুন; ৬ হলে আর প্লেয়ার ৩টা সেগমেন্ট জমালে ২০ সেকেন্ডের বেশি স্বাভাবিক | আগে ঠিক করুন আসলে কত দরকার; দরকার হলে সেগমেন্ট ছোট করুন বা লো লেটেন্সিতে যান (চ্যাপ্টার ৬) |
| দুই ডিভাইসে একই স্ট্রিম আলাদা সময়ে | পাশাপাশি চালিয়ে উৎসে বসানো ঘড়ি মেলান | প্লেয়ারের লাইভ-এজ দূরত্ব একই সেট করুন (hls.js-এ liveSyncDuration ইত্যাদি), বা PROGRAM-DATE-TIME দিয়ে সিঙ্ক করুন (চ্যাপ্টার ১০) |
| কিছুক্ষণ পর পর সবাই বাফারিং দেখে | কয়েক সেকেন্ড পরপর curl দিয়ে প্লেলিস্ট আনুন; MEDIA-SEQUENCE না বাড়লে প্লেলিস্ট আটকে আছে | সমস্যা contribution বা ট্রান্সকোডে; এনকোডার আর ইনজেস্ট লগ দেখুন (চ্যাপ্টার ৪, ১৩) |
| কিছু দর্শক আটকে, বাকিরা ঠিক | তাদের দেশ, ISP, ডিভাইস জানুন; একই URL অন্য নেটওয়ার্ক থেকে চালান | সমস্যা distribution বা প্লেয়ারে; CDN আর প্লেয়ার লগ দেখুন (চ্যাপ্টার ৮) |
| লেটেন্সি সময়ের সাথে বাড়তে থাকে | ট্রান্সকোডারের এনকোড স্পিড দেখুন (ffmpeg-এ speed=0.98x ইত্যাদি); ১-এর নিচে হলে জমছে | দ্রুত preset, কম রেন্ডিশন বা হার্ডওয়্যার এনকোডার; স্পিডে অ্যালার্ট বসান |
| প্লেয়ার লাইভকে VOD ভাবছে, শেষে থেমে যায় | প্লেলিস্টে #EXT-X-ENDLIST আছে কিনা দেখুন | প্যাকেজার ভুল করে স্ট্রিম শেষ ঘোষণা করছে, সাধারণত এনকোডার সংযোগ কাটার পরে; রিকানেক্টে নতুন প্লেলিস্ট নয়, একই প্লেলিস্টে ডিসকন্টিনিউটি চাই (চ্যাপ্টার ৯) |
মূল শিক্ষা
- লাইভ মানে কনটেন্ট এখনো তৈরি হচ্ছে। প্রতিটা ধাপের রিয়েল-টাইম ডেডলাইন আছে, আর ব্যর্থ হলে সেই অংশ ফেরত আসে না।
- Glass-to-glass লেটেন্সির বেশিরভাগ যায় অপেক্ষায়, সেগমেন্ট পুরো হওয়া আর প্লেয়ারের বাফারে, নেটওয়ার্কে নয়।
- লেটেন্সির চারটা মোটামুটি শ্রেণি আছে: স্ট্যান্ডার্ড, রিডিউসড, লো, রিয়েল-টাইম। প্রতিটা নিচের ধাপ স্থিতিশীলতা আর খরচের বিনিময়ে আসে।
- ব্যবহারই লেটেন্সি ঠিক করে। শুধু দেখার জন্য স্ট্যান্ডার্ড যথেষ্ট; মিথস্ক্রিয়া বা অন্য উৎসের সাথে মেলাতে হলে নিচে নামুন।
- Contribution আর distribution আলাদা সমস্যা। একটা অনিশ্চিত আপলিংক বনাম লাখো দর্শকের ভিড়; প্রোটোকলও আলাদা।
- সব দর্শকের সমস্যা মানে সাধারণত উৎসের দিকে, কিছু দর্শকের সমস্যা মানে ডেলিভারি বা প্লেয়ারের দিকে। ডিবাগিং এই প্রশ্ন দিয়ে শুরু করুন।
- লাইভ প্লেলিস্ট একটা চলমান জানালা,
EXT-X-ENDLISTছাড়া;MEDIA-SEQUENCEনা বাড়লে স্ট্রিম আটকে আছে।