🥇 የአይፒ(TS) ዥረቶችን ለመቆጣጠር TSDuckን መጠቀም

ዛሬ, ለምሳሌ IP (TS) ዥረቶችን ለመከታተል ዝግጁ የሆኑ (የባለቤትነት) መፍትሄዎች አሉ VB и iQእነሱ በትክክል የበለፀጉ የተግባር ስብስቦች አሏቸው እና ብዙውን ጊዜ ከቴሌቪዥን አገልግሎቶች ጋር የሚሰሩ ትልልቅ ኦፕሬተሮች እንደዚህ አይነት መፍትሄዎች አሏቸው። ይህ ጽሑፍ በክፍት ምንጭ ፕሮጀክት ላይ የተመሰረተ መፍትሄን ይገልፃል TSDuck, በ CC (ቀጣይ ቆጣሪ) ቆጣሪ እና ቢትሬት የ IP (TS) ዥረቶችን በትንሹ ለመቆጣጠር የተነደፈ። የሚቻለው አፕሊኬሽን የፓኬቶችን መጥፋት ወይም አጠቃላይ ፍሰቱን በሊዝ ኤል2 ቻናል መቆጣጠር ነው (ይህም በመደበኛነት ቁጥጥር ሊደረግበት አይችልም ለምሳሌ በወረፋ ውስጥ ያሉ ኪሳራ ቆጣሪዎችን በማንበብ)።

ስለ TSDuck በጣም በአጭሩ

TSDuck የቲኤስ ዥረቶችን ለመቆጣጠር ክፍት ምንጭ (2-Clause BSD ፍቃድ) ሶፍትዌር (የኮንሶል መገልገያዎች ስብስብ እና ብጁ መገልገያዎችን ወይም ተሰኪዎችን ለማዳበር ቤተ-መጽሐፍት) ነው። እንደ ግብአት፣ ከአይፒ (multicast/unicast)፣ http፣ hls፣ dvb tuners፣ dektec dvb-asi demodulator ጋር አብሮ መስራት ይችላል፣ የውስጥ ቲኤስ-ዥረት ጀነሬተር እና ከፋይሎች ማንበብ አለ። ውጤቱ ወደ ፋይል፣ አይፒ (መልቲካስት/ዩኒካስት)፣ hls፣ dektec dvb-asi እና HiDes ሞዱላተሮች፣ ተጫዋቾች (mplayer፣ vlc፣ xine) እና መጣል ሊሆን ይችላል። የተለያዩ የትራፊክ ማቀነባበሪያዎች በግብአት እና በውጤት መካከል ሊካተቱ ይችላሉ፡- ለምሳሌ፡- PID remaping, scrambling/decrambling, CC counter analysis, bitrate ስሌት እና ሌሎች ለቲኤስ ዥረቶች የተለመዱ ኦፕሬሽኖች።

በዚህ ጽሑፍ ውስጥ የአይፒ ዥረቶች (multicast) እንደ ግብአት ጥቅም ላይ ይውላሉ, ፕሮሰሰሮቹ bitrate_monitor (ከስሙ ምን እንደሆነ ግልጽ ነው) እና ቀጣይነት (የሲሲ ቆጣሪዎች ትንተና) ጥቅም ላይ ይውላሉ. የአይፒ መልቲካስትን በቀላሉ በTSDuck በሚደገፍ ሌላ የግቤት አይነት መተካት ይችላሉ።

ይገኛል። ኦፊሴላዊ ግንባታዎች / ጥቅሎች TSDuck ለአብዛኛዎቹ የስርዓተ ክወናዎች። ለዴቢያን አይገኙም ነገርግን በዲቢያን 8 እና በዴቢያን 10 ስር ያለ ምንም ችግር መገንባት ችለናል።

በመቀጠል፣ TSDuck 3.19-1520 እትም ጥቅም ላይ ይውላል፣ ሊኑክስ እንደ ኦኤስ ጥቅም ላይ ይውላል (debian 10 መፍትሄውን ለማዘጋጀት ጥቅም ላይ ውሏል፣ CentOS 7 ለትክክለኛ ጥቅም ጥቅም ላይ ውሏል)

TSDuck እና OS በማዘጋጀት ላይ

እውነተኛ ፍሰቶችን ከመቆጣጠርዎ በፊት TDuck በትክክል እንደሚሰራ እና በኔትወርክ ካርድ ወይም በስርዓተ ክወና (ሶኬት) ደረጃ ላይ ምንም ጠብታዎች አለመኖራቸውን ማረጋገጥ አለብዎት። በኋላ ላይ ጠብታዎቹ የት እንደተከሰቱ ላለመገመት ይህ ያስፈልጋል - በአውታረ መረቡ ላይ ወይም "በአገልጋዩ ውስጥ"። በኔትዎርክ ካርድ ደረጃ ጠብታዎችን በethtool -S ethX ትእዛዝ ማረጋገጥ ይችላሉ ፣ማስተካከል የሚከናወነው በተመሳሳይ ethtool ነው (ብዙውን ጊዜ ፣ የ RX ቋት (-G) ን መጨመር እና አንዳንድ ጊዜ ማጥፋትን (-K) ማሰናከል ያስፈልግዎታል)። እንደ አጠቃላይ ምክር ፣ የተተነተነውን ትራፊክ ለመቀበል የተለየ ወደብ እንዲጠቀሙ ሊመከር ይችላል ፣ ከተቻለ ይህ መውደቅ በሌሎች ትራፊክ መገኘት ምክንያት በትክክል በተተነተነው ወደብ ላይ ከመከሰቱ እውነታ ጋር የተዛመዱ የውሸት አወንቶችን ይቀንሳል። ይህ የማይቻል ከሆነ (አንድ ወደብ ያለው ሚኒ-ኮምፒዩተር/ኤንዩሲ ጥቅም ላይ ይውላል) ፣ ከዚያም ተንታኙ በተገናኘበት መሣሪያ ላይ ካለው ቀሪው ጋር በተገናኘ የተተነተነውን ትራፊክ ቅድሚያ ማዘጋጀት በጣም ጥሩ ነው። ምናባዊ አካባቢዎችን በተመለከተ፣ እዚህ ላይ ጥንቃቄ ማድረግ እና ከአካላዊ ወደብ ጀምሮ እና በቨርቹዋል ማሽን ውስጥ ባለው መተግበሪያ በመጨረስ የፓኬት ጠብታዎችን ማግኘት መቻል አለብዎት።

በአስተናጋጁ ውስጥ ዥረት ማመንጨት እና መቀበል

TSDuckን ለማዘጋጀት እንደ መጀመሪያው እርምጃ፣ መረብን በመጠቀም በአንድ አስተናጋጅ ውስጥ ትራፊክ እንፈጥራለን እና እንቀበላለን።

አካባቢን ማዘጋጀት;

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 TS ፓኬቶችን ወደ 1 IP ፓኬት ማሸግ እና ጠንክሮ (-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 ለማሳደግ ሞክር። ተንታኙ የ CC ስህተቶችን እና ከ 75 ይልቅ ወደ 100 ሜጋ ባይት ያህል ሪፖርት አድርጓል ። ተጠያቂው ማን እንደሆነ ለማወቅ እየሞከርን ነው - ጄነሬተር ጊዜ የለውም ወይም ችግሩ በውስጡ የለም ፣ ለዚህም ቋሚ ቁጥር ማመንጨት እንጀምራለን ። ጥቅሎች (700000 TS ጥቅሎች = 100000 የአይፒ ፓኬቶች)

# 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

እዚህ የ drops ቁጥር = 24355 ማየት ይችላሉ. በቲኤስ ፓኬቶች ውስጥ, ይህ 170485 ወይም 24.36% ከ 700000% ነው, ስለዚህ እነዚያኑ የጠፋው ቢትሬት 25% በ udp ሶኬት ውስጥ ጠብታዎች መሆናቸውን እናያለን. በ UDP ሶኬት ውስጥ ያሉ ጠብታዎች ብዙውን ጊዜ የሚከሰቱት በመያዣ እጥረት ምክንያት ነው፣ ነባሪውን የሶኬት ቋት መጠን እና ከፍተኛውን የሶኬት ቋት መጠን ይመልከቱ፡-

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

ስለዚህ አፕሊኬሽኖች የቋት መጠንን በግልፅ ካልጠየቁ ሶኬቶች በ208 ኪባ ቋት ይፈጠራሉ ነገርግን ተጨማሪ ከጠየቁ አሁንም የተጠየቀውን አያገኙም። ለአይፒ ግብዓት (-buffer-size) የቋት መጠኑን በቲፒኤስ ውስጥ ማቀናበር ስለቻሉ ነባሪውን የሶኬት መጠን አንነካውም ነገር ግን ከፍተኛውን የሶኬት ቋት መጠን ብቻ እናዘጋጃለን እና የቋት መጠኑን በቲፕ ግቤቶች በኩል በግልፅ ይግለጹ።

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% ሲፒዩ፣ 100Mbps - 25%፣ 200Mbps - 46% ያስፈልገዋል። የ% Packet Loss ን ሲያቀናብሩ በሲፒዩ ላይ ያለው ጭነት በተግባር አይጨምርም (ግን ሊቀንስ ይችላል)።

የበለጠ ውጤታማ ሃርድዌር ላይ፣ ከ1Gb/s በላይ የሆኑ ዥረቶችን ያለምንም ችግር ማመንጨት እና መተንተን ተችሏል።

በእውነተኛ የአውታረ መረብ ካርዶች ላይ መሞከር

በቬት ጥንድ ላይ ከተፈተነ በኋላ ሁለት አስተናጋጆችን ወይም ሁለት ወደቦችን መውሰድ, ወደቦችን እርስ በርስ ማገናኘት, ጄነሬተሩን በአንዱ ላይ እና ትንታኔውን በሁለተኛው ላይ መጀመር ያስፈልግዎታል. እዚህ ምንም አስገራሚ ነገሮች አልነበሩም, ግን በእውነቱ ሁሉም በብረት ላይ የተመሰረተ ነው, ደካማ, እዚህ የበለጠ አስደሳች ይሆናል.

በክትትል ስርዓት (Zabbix) የተቀበለውን ውሂብ በመጠቀም

tsp እንደ SNMP ወይም ተመሳሳይ በማሽን የሚነበብ ኤፒአይ የለውም። የCC መልእክቶች ቢያንስ ለ1 ሰከንድ መጠቃለል አለባቸው (በፓኬት መጥፋት ከፍተኛ መቶኛ፣ እንደ ቢትሬት በሴኮንድ በመቶዎች/ሺህ/በአስር ሺዎች የሚቆጠሩ ሊኖሩ ይችላሉ)።

ስለዚህ ሁለቱንም መረጃዎች ለማስቀመጥ እና ለ CC ስህተቶች እና ቢትሬት ግራፎችን ለመሳል እና አንዳንድ አደጋዎችን ለማድረግ የሚከተሉትን አማራጮች ሊኖሩ ይችላሉ ።

የቲ.ፒ. ውጤትን ተነተን (በሲሲሲ) አዋህድ፣ ማለትም ወደሚፈለገው ቅጽ ይለውጡት.
ውጤቱን ለክትትል ስርዓቱ ተስማሚ በሆነ ማሽን ሊነበብ በሚችል ቅጽ እንዲሰጥ እራሱን እና/ወይም ፕሮሰሰር ተሰኪዎችን ቢትሬት_ሞኒተር እና ቀጣይነት ጨርስ።
ማመልከቻዎን በ tsduck ቤተ-መጽሐፍት ላይ ይፃፉ።

በግልጽ ለማየት እንደሚቻለው፣ አማራጭ 1 በጥረት ረገድ በጣም ቀላሉ ነው፣ በተለይም tsduck እራሱ በዝቅተኛ ደረጃ (በዘመናዊ መስፈርቶች) ቋንቋ (C ++) የተጻፈ መሆኑን ከግምት ውስጥ በማስገባት ነው።

ቀላል የ bash parser+ aggregator prototype እንደሚያሳየው በ10Mbps ዥረት እና 50% ፓኬት መጥፋት (በጣም የከፋው ጉዳይ)፣ የ bash ሂደት ከ tsp ሂደት ከ3-4 እጥፍ የበለጠ ሲፒዩ ይበላል። ይህ ሁኔታ ተቀባይነት የለውም። በእውነቱ የዚህ ምሳሌ ቁራጭ ከዚህ በታች

ኑድል ከላይ

#!/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

ተቀባይነት ከሌለው ዘገምተኛ ከመሆን በተጨማሪ በ bash ውስጥ ምንም መደበኛ ክሮች የሉም ፣ ባሽ ስራዎች የተለያዩ ሂደቶች ናቸው እና የጎደሉትን ፓኬቶች ዋጋ በሰከንድ አንድ ጊዜ በጎን ውጤት ላይ መጻፍ ነበረብኝ (በየሴኮንዱ የሚመጡ የቢትሬት መልዕክቶች ሲደርሱኝ)። በውጤቱም, bash ብቻውን ቀርቷል እና በጎልግ ውስጥ መጠቅለያ (ፓርሰር + ሰብሳቢ) ለመጻፍ ተወሰነ. ተመሳሳይ የጎላንግ ኮድ የሲፒዩ ፍጆታ ከ tsp ሂደት ከ4-5 እጥፍ ያነሰ ነው። ባሽ በጎላንግ በመተካቱ ምክንያት የመጠቅለያው ፍጥነት 16 ጊዜ ያህል ሆነ እና በአጠቃላይ ውጤቱ ተቀባይነት ያለው ነው (በከፋ ሁኔታ ሲፒዩ በ 25% ይበልጣል)። የጎላንግ ምንጭ ፋይል ይገኛል። እዚህ.

መጠቅለያውን አሂድ

መጠቅለያውን ለመጀመር ለስርዓት በጣም ቀላሉ የአገልግሎት አብነት ተሠርቷል (እዚህ). መጠቅለያው ራሱ በ /opt/tsduck-stat/ ውስጥ ወደሚገኘው ወደ ሁለትዮሽ ፋይል (go build tsduck-stat.go) መጠቅለል አለበት። ለሞኖቶኒክ ሰዓት (>=1.9) ድጋፍ ጎላንግ እየተጠቀሙ ነው ተብሎ ይታሰባል።

የአገልግሎቱን ምሳሌ ለመፍጠር የ systemctl አንቃ ትዕዛዝን ማስኬድ ያስፈልግዎታል [ኢሜል የተጠበቀ]: 1234 ከዚያ በ systemctl ጅምር ያሂዱ [ኢሜል የተጠበቀ]: 1234.

ከዛቢክስ ግኝት

zabbix የአሂድ አገልግሎቶችን ማግኘት እንዲችል፣ ተከናውኗል የቡድን ዝርዝር ጀነሬተር (discovery.sh), ለ Zabbix ግኝት በሚያስፈልገው ቅርጸት, በተመሳሳይ ቦታ - በ / opt / tsduck-stat ውስጥ እንደሚገኝ ይገመታል. በ zabbix-ኤጀንት በኩል ግኝትን ለማሄድ ማከል ያስፈልግዎታል .conf ፋይል የተጠቃሚውን መለኪያ ለመጨመር ወደ zabbix-ወኪል ውቅር ማውጫ።

የዛቢቢክስ አብነት

አብነት ተፈጥሯል። (tsduck_stat_template.xml) የራስ ሰር ግኝት ህግን፣ የንጥል ፕሮቶታይፕን፣ ግራፎችን እና ቀስቅሴዎችን ይዟል።

አጭር የፍተሻ ዝርዝር (መልካም፣ አንድ ሰው ሊጠቀምበት ከወሰነ ምን ይሆናል)

ቲፕ እሽጎችን "በጥሩ" ሁኔታዎች ውስጥ እንደማይጥል እርግጠኛ ይሁኑ (ጄነሬተር እና ተንታኝ በቀጥታ የተገናኙ ናቸው) ጠብታዎች ካሉ ፣ በዚህ ጉዳይ ላይ አንቀጽ 2 ወይም የጽሁፉን ጽሑፍ ይመልከቱ ።
ከፍተኛውን የሶኬት ቋት (net.core.rmem_max=8388608) ማስተካከል ያድርጉ።
tsduck-stat.go አጠናቅቅ (go build tsduck-stat.go)።
የአገልግሎት አብነት በ /lib/systemd/system ውስጥ ያስቀምጡ።
አገልግሎቶችን በ systemctl ይጀምሩ፣ ቆጣሪዎቹ መታየት መጀመራቸውን ያረጋግጡ (grep "" /dev/shm/tsduck-stat/*). የአገልግሎቶቹ ብዛት በበርካታ ዥረቶች ብዛት። እዚህ ወደ መልቲካስት ቡድን የሚወስድ መንገድ መፍጠር ሊኖርብዎ ይችላል፣ ምናልባት rp_filter ን ያሰናክሉ ወይም ወደ ምንጭ ip የሚወስድ መንገድ ይፍጠሩ።
Discovery.sh ን ያሂዱ፣ jsonን እንደሚያመነጭ ያረጋግጡ።
የ zabbix ወኪል ውቅረትን ያክሉ፣ የዛቢክስ ወኪልን እንደገና ያስጀምሩ።
አብነቱን ወደ zabbix ይስቀሉ፣ ክትትል እየተደረገለት ባለው አስተናጋጅ ላይ ይተግብሩ እና የዛቢክስ ወኪል ተጭኗል፣ 5 ደቂቃ ያህል ይጠብቁ፣ አዲስ እቃዎች፣ ግራፎች እና ቀስቅሴዎች ካሉ ይመልከቱ።

ውጤት

የፓኬት መጥፋትን ለመለየት ስራው በቂ ነው, ቢያንስ ቢያንስ ቁጥጥር ከሌለው የተሻለ ነው.

በእርግጥ የ CC "ኪሳራዎች" የቪዲዮ ቁርጥራጮችን በማዋሃድ ሊከሰት ይችላል (እኔ እስከማውቀው ድረስ በሩሲያ ፌደሬሽን ውስጥ በአካባቢያዊ የቴሌቪዥን ማእከሎች ውስጥ እንዴት ማስገባት እንደሚቻል ነው, ማለትም የሲ.ሲ.ሲ ቆጣሪውን እንደገና ሳያሰላስል), ይህ መታወስ አለበት. የባለቤትነት መፍትሄዎች የ SCTE-35 መለያዎችን (በዥረት አመንጪው ከተጨመረ) ይህንን ችግር በከፊል ያቋርጣሉ።

በትራንስፖርት ጥራት ቁጥጥር ረገድ የጂተር ክትትል (IAT) እጥረት አለ። የቲቪ መሳሪያዎች (ሞዱላተሮች ወይም የመጨረሻ መሳሪያዎች ይሁኑ) ለዚህ ግቤት መስፈርቶች አሏቸው እና ሁልጊዜም ጂትቡፈርን ወደ ኢንፍሊቲቲ ማስገባት አይቻልም። እና ትልቅ ቋት ያላቸው መሳሪያዎች በትራንዚት ውስጥ ጥቅም ላይ በሚውሉበት ጊዜ እና QoS ያልተዋቀረ ወይም በደንብ ያልተዋቀረ ከሆነ እንደዚህ ያለውን የአሁናዊ ትራፊክ ለማስተላለፍ ጂተር ሊንሳፈፍ ይችላል።

ምንጭ: hab.com

የአይፒ(TS) ዥረቶችን ለመቆጣጠር TSDuckን መጠቀም