আইপি(টিএস) স্ট্রীম নিরীক্ষণ করতে TSDuck ব্যবহার করা

আজ, আইপি(টিএস) স্ট্রীম নিরীক্ষণের জন্য রেডিমেড (মালিকানা) সমাধান রয়েছে, উদাহরণস্বরূপ VB и iQ, তাদের ফাংশনগুলির একটি মোটামুটি সমৃদ্ধ সেট রয়েছে এবং সাধারণত টিভি পরিষেবাগুলির সাথে কাজ করে এমন বড় অপারেটরদের কাছে এই ধরনের সমাধান রয়েছে৷ এই নিবন্ধটি একটি ওপেন সোর্স প্রকল্পের উপর ভিত্তি করে একটি সমাধান বর্ণনা করে TSDuck, CC(কন্টিনিউটি কাউন্টার) কাউন্টার এবং বিটরেট দ্বারা IP(TS) স্ট্রিমগুলির ন্যূনতম নিয়ন্ত্রণের জন্য ডিজাইন করা হয়েছে৷ একটি সম্ভাব্য অ্যাপ্লিকেশন হল একটি লিজড L2 চ্যানেলের মাধ্যমে প্যাকেটের ক্ষতি বা সম্পূর্ণ প্রবাহ নিয়ন্ত্রণ করা (যা সাধারণত নিরীক্ষণ করা যায় না, উদাহরণস্বরূপ, সারিগুলিতে ক্ষতির কাউন্টার পড়ার মাধ্যমে)।

TSDuck সম্পর্কে খুব সংক্ষেপে

TSDuck একটি ওপেন সোর্স (2-ক্লজ BSD লাইসেন্স) সফ্টওয়্যার (কনসোল ইউটিলিটিগুলির একটি সেট এবং কাস্টম ইউটিলিটি বা প্লাগইনগুলি বিকাশের জন্য একটি লাইব্রেরি) TS স্ট্রিমগুলি পরিচালনা করার জন্য। একটি ইনপুট হিসাবে, এটি আইপি (মাল্টিকাস্ট/ইউনিকাস্ট), http, hls, dvb টিউনার, dektec dvb-asi demodulator এর সাথে কাজ করতে পারে, একটি অভ্যন্তরীণ TS-স্ট্রিম জেনারেটর রয়েছে এবং ফাইলগুলি থেকে রিডিং রয়েছে। আউটপুট একটি ফাইল, IP (মাল্টিকাস্ট/ইউনিকাস্ট), hls, dektec dvb-asi এবং HiDes মডুলেটর, প্লেয়ার (mplayer, vlc, xine) এবং ড্রপে লেখা হতে পারে। ইনপুট এবং আউটপুটের মধ্যে বিভিন্ন ট্র্যাফিক প্রসেসর অন্তর্ভুক্ত করা যেতে পারে, উদাহরণস্বরূপ, পিআইডি রিম্যাপিং, স্ক্র্যাম্বলিং/ডেসক্র্যাম্বলিং, সিসি কাউন্টার বিশ্লেষণ, বিটরেট গণনা এবং টিএস স্ট্রিমগুলির জন্য অন্যান্য সাধারণ ক্রিয়াকলাপ।

এই নিবন্ধে, আইপি স্ট্রীম (মাল্টিকাস্ট) একটি ইনপুট হিসাবে ব্যবহার করা হবে, প্রসেসর bitrate_monitor (নাম থেকেই বোঝা যায় এটি কী) এবং ধারাবাহিকতা (CC কাউন্টারগুলির বিশ্লেষণ) ব্যবহার করা হয়েছে৷ আপনি সহজেই আইপি মাল্টিকাস্ট টিএসডিক দ্বারা সমর্থিত অন্য ইনপুট টাইপ দিয়ে প্রতিস্থাপন করতে পারেন।

পাওয়া যায় অফিসিয়াল বিল্ড/প্যাকেজ বেশিরভাগ বর্তমান অপারেটিং সিস্টেমের জন্য TSDuck। এগুলি ডেবিয়ানের জন্য উপলব্ধ নয়, তবে আমরা কোনও সমস্যা ছাড়াই ডেবিয়ান 8 এবং ডেবিয়ান 10 এর অধীনে সেগুলি তৈরি করতে পেরেছি।

পরবর্তী, সংস্করণ TSDuck 3.19-1520 ব্যবহার করা হয়, লিনাক্স OS হিসাবে ব্যবহৃত হয় (সলিউশন প্রস্তুত করতে ডেবিয়ান 10 ব্যবহার করা হয়েছিল, CentOS 7 বাস্তব ব্যবহারের জন্য ব্যবহৃত হয়েছিল)

TSDuck এবং OS প্রস্তুত করা হচ্ছে

বাস্তব প্রবাহ পর্যবেক্ষণ করার আগে, আপনাকে নিশ্চিত করতে হবে যে TSDuck সঠিকভাবে কাজ করছে এবং নেটওয়ার্ক কার্ড বা OS (সকেট) স্তরে কোন ড্রপ নেই। ড্রপগুলি কোথায় ঘটেছে তা পরে অনুমান না করার জন্য এটি প্রয়োজন - নেটওয়ার্কে বা "সার্ভারের ভিতরে"। আপনি ethtool -S ethX কমান্ডের সাহায্যে নেটওয়ার্ক কার্ড স্তরে ড্রপগুলি পরীক্ষা করতে পারেন, একই ethtool দ্বারা টিউনিং করা হয় (সাধারণত, আপনাকে RX বাফার (-G) বাড়াতে হবে এবং কখনও কখনও কিছু অফলোড (-K) অক্ষম করতে হবে)। একটি সাধারণ সুপারিশ হিসাবে, বিশ্লেষণ করা ট্র্যাফিক গ্রহণের জন্য একটি পৃথক পোর্ট ব্যবহার করার পরামর্শ দেওয়া যেতে পারে, যদি সম্ভব হয়, এটি অন্যান্য ট্র্যাফিকের উপস্থিতির কারণে বিশ্লেষক পোর্টে ঠিক যে ড্রপটি ঘটেছে তার সাথে যুক্ত মিথ্যা ইতিবাচকতাগুলিকে হ্রাস করে। যদি এটি সম্ভব না হয় (একটি পোর্ট সহ একটি মিনি-কম্পিউটার/NUC ব্যবহার করা হয়), তবে বিশ্লেষকটি যে ডিভাইসে সংযুক্ত রয়েছে তার বাকিগুলির সাথে বিশ্লেষণ করা ট্র্যাফিকের অগ্রাধিকার সেট আপ করা অত্যন্ত বাঞ্ছনীয়। ভার্চুয়াল এনভায়রনমেন্ট সম্পর্কে, এখানে আপনাকে সতর্কতা অবলম্বন করতে হবে এবং একটি ফিজিক্যাল পোর্ট থেকে শুরু করে একটি ভার্চুয়াল মেশিনের ভিতরে একটি অ্যাপ্লিকেশন দিয়ে শেষ হওয়া প্যাকেট ড্রপগুলি খুঁজে পেতে সক্ষম হবেন।

হোস্টের অভ্যন্তরে একটি প্রবাহের প্রজন্ম এবং অভ্যর্থনা

TSDuck প্রস্তুতির প্রথম ধাপ হিসেবে, আমরা netns ব্যবহার করে একটি একক হোস্টের মধ্যে ট্রাফিক তৈরি করব এবং গ্রহণ করব।

পরিবেশের প্রস্তুতি:

ip netns add P #создаём netns P, в нём будет происходить анализ трафика
ip link add type veth #создаём veth-пару - veth0 оставляем в netns по умолчанию (в этот интерфейс будет генерироваться трафик)
ip link set dev veth1 netns P #veth1 - помещаем в netns P (на этом интерфейсе будет приём трафика)
ip netns exec P ifconfig veth1 192.0.2.1/30 up #поднимаем IP на veth1, не имеет значения какой именно
ip netns exec P ip ro add default via 192.0.2.2 #настраиваем маршрут по умолчанию внутри nents P
sysctl net.ipv6.conf.veth0.disable_ipv6=1 #отключаем IPv6 на veth0 - это делается для того, чтобы в счётчик TX не попадал посторонний мусор
ifconfig veth0 up #поднимаем интерфейс veth0
ip route add 239.0.0.1 dev veth0 #создаём маршрут, чтобы ОС направляла трафик к 239.0.0.1 в сторону veth0

পরিবেশ প্রস্তুত। আমরা ট্রাফিক বিশ্লেষক শুরু করি:

ip netns exec P tsp --realtime -t 
 -I ip 239.0.0.1:1234 
 -P continuity 
 -P bitrate_monitor -p 1 -t 1 
 -O drop

যেখানে "-p 1 -t 1" এর অর্থ হল আপনাকে প্রতি সেকেন্ডে বিটরেট গণনা করতে হবে এবং প্রতি সেকেন্ডে বিটরেট সম্পর্কে তথ্য প্রদর্শন করতে হবে
আমরা 10Mbps গতিতে ট্রাফিক জেনারেটর শুরু করি:

tsp -I craft 
 -P regulate -b 10000000 
 -O ip -p 7 -e --local-port 6000 239.0.0.1:1234

যেখানে "-p 7 -e" এর মানে হল যে আপনাকে 7 টি টিএস প্যাকেটকে 1টি আইপি প্যাকেটে প্যাক করতে হবে এবং এটি কঠোরভাবে করতে হবে (-e), অর্থাৎ একটি আইপি প্যাকেট পাঠানোর আগে সর্বদা শেষ প্রসেসর থেকে 7 টি টিএস প্যাকেট অপেক্ষা করুন।

বিশ্লেষক প্রত্যাশিত বার্তাগুলি আউটপুট করা শুরু করে:

* 2020/01/03 14:55:44 - bitrate_monitor: 2020/01/03 14:55:44, TS bitrate: 9,970,016 bits/s
* 2020/01/03 14:55:45 - bitrate_monitor: 2020/01/03 14:55:45, TS bitrate: 10,022,656 bits/s
* 2020/01/03 14:55:46 - bitrate_monitor: 2020/01/03 14:55:46, TS bitrate: 9,980,544 bits/s

এখন কিছু ফোঁটা যোগ করুন:

ip netns exec P iptables -I INPUT -d 239.0.0.1 -m statistic --mode random --probability 0.001 -j DROP

এবং এই মত বার্তা উপস্থিত হয়:

* 2020/01/03 14:57:11 - continuity: packet index: 80,745, PID: 0x0000, missing 7 packets
* 2020/01/03 14:57:11 - continuity: packet index: 83,342, PID: 0x0000, missing 7 packets 

যা প্রত্যাশিত। প্যাকেট লস অক্ষম করুন (ip netns exec P iptables -F) এবং জেনারেটরের বিটরেট 100Mbps-এ বাড়ানোর চেষ্টা করুন। বিশ্লেষক 75 এর পরিবর্তে একগুচ্ছ CC ত্রুটি এবং প্রায় 100 এমবিপিএস রিপোর্ট করে। আমরা কে দায়ী তা বের করার চেষ্টা করছি - জেনারেটরের সময় নেই বা সমস্যা নেই, এর জন্য আমরা একটি নির্দিষ্ট সংখ্যা তৈরি করতে শুরু করি প্যাকেট (700000 TS প্যাকেট = 100000 IP প্যাকেট):

# ifconfig veth0 | grep TX
       TX packets 151825460  bytes 205725459268 (191.5 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
# tsp -I craft -c 700000 -P regulate -b 100000000 -P count -O ip -p 7 -e --local-port 6000 239.0.0.1:1234
* count: PID    0 (0x0000):    700,000 packets
# ifconfig veth0 | grep TX
        TX packets 151925460  bytes 205861259268 (191.7 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

আপনি দেখতে পাচ্ছেন, ঠিক 100000 আইপি প্যাকেট তৈরি হয়েছিল (151925460-151825460)। তাহলে আসুন বিশ্লেষকের সাথে কী ঘটছে তা খুঁজে বের করা যাক, এর জন্য আমরা veth1-এ RX কাউন্টার দিয়ে পরীক্ষা করি, এটি কঠোরভাবে veth0-এর TX কাউন্টারের সমান, তারপর আমরা সকেট স্তরে কী ঘটছে তা দেখি:

# ip netns exec P cat /proc/net/udp                                                                                                           
  sl  local_address rem_address   st tx_queue rx_queue tr tm->when retrnsmt   uid  timeout inode ref pointer drops             
  133: 010000EF:04D2 00000000:0000 07 00000000:00000000 00:00000000 00000000     0        0 72338 2 00000000e0a441df 24355 

এখানে আপনি ড্রপের সংখ্যা = 24355 দেখতে পাচ্ছেন। TS প্যাকেটে, এটি 170485-এর 24.36 বা 700000%, তাই আমরা দেখতে পাচ্ছি যে হারানো বিটরেটের একই 25% ইউডিপি সকেটে ড্রপ। একটি UDP সকেটে ড্রপ সাধারণত বাফারের অভাবের কারণে ঘটে, ডিফল্ট সকেট বাফার আকার এবং সর্বোচ্চ সকেট বাফার আকার দেখুন:

# sysctl net.core.rmem_default
net.core.rmem_default = 212992
# sysctl net.core.rmem_max
net.core.rmem_max = 212992

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

sysctl net.core.rmem_max=8388608
ip netns exec P tsp --realtime -t -I ip 239.0.0.1:1234 -b 8388608 -P continuity -P bitrate_monitor -p 1 -t 1 -O drop

সকেট বাফারের এই টিউনিংয়ের সাথে, এখন রিপোর্ট করা বিটরেট প্রায় 100Mbps, কোন CC ত্রুটি নেই।

সিপিইউ ব্যবহার অনুযায়ী টিএসপি অ্যাপ্লিকেশন নিজেই। একটি কোর i5-4260U CPU @ 1.40GHz, 10Mbps ফ্লো বিশ্লেষণের জন্য 3-4% CPU, 100Mbps - 25%, 200Mbps - 46% প্রয়োজন হবে৷ % প্যাকেট লস সেট করার সময়, CPU-তে লোড কার্যত বাড়ে না (কিন্তু কমতে পারে)।

অধিক উৎপাদনশীল হার্ডওয়্যারে, কোনো সমস্যা ছাড়াই 1Gb/s এর বেশি স্ট্রিম তৈরি এবং বিশ্লেষণ করা সম্ভব ছিল।

বাস্তব নেটওয়ার্ক কার্ডে পরীক্ষা করা হচ্ছে

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

মনিটরিং সিস্টেম দ্বারা প্রাপ্ত ডেটা ব্যবহার করা (Zabbix)

tsp এর SNMP বা অনুরূপ কোন মেশিন-পঠনযোগ্য API নেই। সিসি বার্তাগুলিকে কমপক্ষে 1 সেকেন্ডের জন্য একত্রিত করতে হবে (প্যাকেটের ক্ষতির উচ্চ শতাংশের সাথে, বিটরেটের উপর নির্ভর করে প্রতি সেকেন্ডে শত/হাজার/হাজার হাজার হতে পারে)।

সুতরাং, উভয় তথ্য সংরক্ষণ করতে এবং CC ত্রুটি এবং বিটরেটের জন্য গ্রাফ আঁকা এবং কিছু ধরণের দুর্ঘটনা ঘটাতে, নিম্নলিখিত বিকল্পগুলি থাকতে পারে:

1. tsp এর আউটপুট পার্স করুন এবং একত্রিত করুন (CC দ্বারা), যেমন এটি পছন্দসই আকারে রূপান্তর করুন।
2. tsp নিজেই এবং/অথবা প্রসেসর প্লাগইন bitrate_monitor এবং ধারাবাহিকতা শেষ করুন যাতে ফলাফলটি মনিটরিং সিস্টেমের জন্য উপযুক্ত একটি মেশিন-পাঠযোগ্য আকারে দেওয়া হয়।
3. tsduck লাইব্রেরির উপরে আপনার আবেদনটি লিখুন।

স্পষ্টতই, বিকল্প 1 প্রচেষ্টার দিক থেকে সবচেয়ে সহজ, বিশেষ করে বিবেচনা করে যে tsduck নিজেই একটি নিম্ন-স্তরের (আধুনিক মান অনুসারে) ভাষায় লেখা হয়েছে (C ++)

একটি সাধারণ ব্যাশ পার্সার+এগ্রিগেটর প্রোটোটাইপ দেখায় যে একটি 10Mbps স্ট্রিম এবং 50% প্যাকেট লস (সবচেয়ে খারাপ ক্ষেত্রে), ব্যাশ প্রক্রিয়াটি tsp প্রক্রিয়ার চেয়ে 3-4 গুণ বেশি CPU খরচ করে। এই দৃশ্যকল্প অগ্রহণযোগ্য. আসলে নীচের এই প্রোটোটাইপ একটি টুকরা

উপরে নুডলস

#!/usr/bin/env bash

missingPackets=0
ccErrorSeconds=0
regexMissPackets='^* (.+) - continuity:.*missing ([0-9]+) packets$'
missingPacketsTime=""

ip netns exec P tsp --realtime -t -I ip -b 8388608 "239.0.0.1:1234" -O drop -P bitrate_monitor -p 1 -t 1  -P continuity 2>&1 | 
while read i
do
    #line example:* 2019/12/28 23:41:14 - continuity: packet index: 6,078, PID: 0x0100, missing 5 packets
    #line example 2: * 2019/12/28 23:55:11 - bitrate_monitor: 2019/12/28 23:55:11, TS bitrate: 4,272,864 bits/s
    if [[ "$i" == *continuity:* ]] 
    then
        if [[ "$i" =~ $regexMissPackets ]]
        then
            missingPacketsTimeNew="${BASH_REMATCH[1]}" #timestamp (seconds)
            if [[ "$missingPacketsTime" != "$missingPacketsTimeNew" ]] #new second with CC error
            then
                ((ccErrorSeconds += 1))
            fi
            missingPacketsTime=$missingPacketsTimeNew
            packets=${BASH_REMATCH[2]} #TS missing packets
            ((missingPackets += packets))
        fi
    elif [[ "$i" == *bitrate_monitor:* ]]
    then
        : #...
    fi
done

অগ্রহণযোগ্যভাবে ধীর হওয়ার পাশাপাশি, ব্যাশে কোন স্বাভাবিক থ্রেড নেই, ব্যাশ কাজগুলি পৃথক প্রক্রিয়া, এবং আমাকে পার্শ্ব প্রতিক্রিয়ার উপর সেকেন্ডে একবার অনুপস্থিত প্যাকেটের মান লিখতে হয়েছিল (যখন প্রতি সেকেন্ডে বিটরেট বার্তাগুলি আসে)। ফলস্বরূপ, বাশকে একা ছেড়ে দেওয়া হয়েছিল এবং গোলং-এ একটি মোড়ক (পার্সার + অ্যাগ্রিগেটর) লেখার সিদ্ধান্ত নেওয়া হয়েছিল। অনুরূপ গোলং কোডের CPU খরচ tsp প্রক্রিয়ার চেয়ে 4-5 গুণ কম। গোলাঙ্গের সাথে ব্যাশ প্রতিস্থাপনের কারণে র্যাপারের গতি প্রায় 16 বার পরিণত হয়েছে এবং সাধারণভাবে ফলাফলটি গ্রহণযোগ্য (সবচেয়ে খারাপ ক্ষেত্রে CPU ওভারহেড 25%)। গোলং সোর্স ফাইলটি অবস্থিত এখানে.

মোড়ক চালান

মোড়ক শুরু করতে, সিস্টেমডের জন্য সবচেয়ে সহজ পরিষেবা টেমপ্লেট তৈরি করা হয়েছিল (এখানে) র‍্যাপারটি নিজেই একটি বাইনারি ফাইলে সংকলিত হওয়ার কথা (go build tsduck-stat.go) যা /opt/tsduck-stat/-এ অবস্থিত। এটা ধরে নেওয়া হয় যে আপনি একঘেয়ে ঘড়ির (>=1.9) সমর্থন সহ গোলং ব্যবহার করছেন।

পরিষেবাটির একটি উদাহরণ তৈরি করতে, আপনাকে systemctl enable কমান্ডটি চালাতে হবে [ইমেল সুরক্ষিত]:1234 তারপর systemctl start দিয়ে চালান [ইমেল সুরক্ষিত]: 1234।

Zabbix থেকে আবিষ্কার

zabbix চলমান পরিষেবাগুলি আবিষ্কার করতে সক্ষম হওয়ার জন্য, এটি করা হয়েছে গ্রুপ তালিকা জেনারেটর (discovery.sh), Zabbix আবিষ্কারের জন্য প্রয়োজনীয় বিন্যাসে, এটা ধরে নেওয়া হয় যে এটি একই জায়গায় অবস্থিত - /opt/tsduck-stat-এ। zabbix-এজেন্টের মাধ্যমে আবিষ্কার চালানোর জন্য, আপনাকে যোগ করতে হবে .conf ফাইল ব্যবহারকারী প্যারামিটার যোগ করতে zabbix-এজেন্ট কনফিগারেশন ডিরেক্টরিতে।

Zabbix টেমপ্লেট

টেমপ্লেট তৈরি করা হয়েছে (tsduck_stat_template.xml) অটোডিসকভার নিয়ম, আইটেম প্রোটোটাইপ, গ্রাফ এবং ট্রিগার ধারণ করে।

সংক্ষিপ্ত চেকলিস্ট (ভাল, যদি কেউ এটি ব্যবহার করার সিদ্ধান্ত নেয়)

1. নিশ্চিত করুন যে tsp "আদর্শ" অবস্থার অধীনে প্যাকেট ফেলে না (জেনারেটর এবং বিশ্লেষক সরাসরি সংযুক্ত), যদি ড্রপ থাকে, অনুচ্ছেদ 2 বা এই বিষয়ে নিবন্ধের পাঠ্য দেখুন।
2. সর্বোচ্চ সকেট বাফার টিউনিং করুন (net.core.rmem_max=8388608)।
3. tsduck-stat.go কম্পাইল করুন (tsduck-stat.go তৈরি করুন)।
4. পরিষেবা টেমপ্লেটটি /lib/systemd/system-এ রাখুন।
5. Systemctl দিয়ে পরিষেবাগুলি শুরু করুন, পরীক্ষা করুন যে কাউন্টারগুলি উপস্থিত হতে শুরু করেছে (grep "" /dev/shm/tsduck-stat/*)। মাল্টিকাস্ট স্ট্রীমের সংখ্যা অনুসারে পরিষেবার সংখ্যা। এখানে আপনাকে মাল্টিকাস্ট গ্রুপে একটি রুট তৈরি করতে হতে পারে, সম্ভবত rp_filter নিষ্ক্রিয় করতে হবে বা উৎস ip-এ একটি রুট তৈরি করতে হবে।
6. Discovery.sh চালান, নিশ্চিত করুন যে এটি json তৈরি করে।
7. zabbix এজেন্ট কনফিগার যোগ করুন, zabbix এজেন্ট পুনরায় আরম্ভ করুন।
8. zabbix-এ টেমপ্লেট আপলোড করুন, এটিকে নিরীক্ষণ করা হোস্টে প্রয়োগ করুন এবং zabbix-এজেন্ট ইনস্টল করা আছে, প্রায় 5 মিনিট অপেক্ষা করুন, দেখুন নতুন আইটেম, গ্রাফ এবং ট্রিগার আছে কিনা।

ফল

প্যাকেটের ক্ষতি সনাক্ত করার কাজটির জন্য, এটি প্রায় যথেষ্ট, অন্তত এটি কোনও পর্যবেক্ষণের চেয়ে ভাল।

প্রকৃতপক্ষে, ভিডিও খণ্ডগুলিকে একত্রিত করার সময় CC "ক্ষতি" ঘটতে পারে (যতদূর আমি জানি, রাশিয়ান ফেডারেশনের স্থানীয় টিভি কেন্দ্রগুলিতে এইভাবে সন্নিবেশ করা হয়, অর্থাৎ সিসি কাউন্টার পুনঃগণনা না করে), এটি অবশ্যই মনে রাখতে হবে। মালিকানা সমাধানগুলি SCTE-35 লেবেল সনাক্ত করে (যদি স্ট্রিম জেনারেটর দ্বারা যোগ করা হয়) এই সমস্যাটি আংশিকভাবে প্রতিরোধ করে৷

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

উত্স: www.habr.com