Jump to content
Калькуляторы

IPTV вещание юникастом msd на тест. multicast->http, http->http

Всё делает прога сама и выдаёт детальную статистику по абоненту в виде:

 

	192.168.10.11:51958 (192.168.10.11:51958)	[conn time: 0+01:30:42, flags: 775, cc: htcp, maxseg: 1348, snd_block_min_size: 64 kb, precache: 4096 kb, data to send: 1104 kb]	[user agent: RealtekVOD/1.0.0 (Linux)]
    TCP FSM state: SYN_SENT
    ca_state: 0
    retransmits: 0
    probes: 0
    backoff: 1
    Options enabled on conn: TIMESTAMPS SACK WSCALE 
    RFC1323 send shift value: 1
    RFC1323 recv shift value: 10
    Retransmission timeout (usec): 220000
    ato (usec): 40000
    Max segment size for send: 1348
    Max segment size for receive: 536
    unacked: 0
    sacked: 0
    lost: 0
    retrans: 0
    fackets: 0
    last_data_sent: 308
    last_ack_sent: 0
    Time since last recv data (usec): 5442464
    last_ack_recv: 88
    pmtu: 1500
    rcv_ssthresh: 30032
    rtt: 22000
    rttvar: 21000
    snd_ssthresh: 8
    snd_cwnd: 10
    advmss: 1448
    reordering: 3
    rcv_rtt: 0
    rcv_space: 28960
    total_retrans: 1356

 

вот конкретно total_retrans, означает что какие-то пакеты до абонента не дошли и были перепосланы (проблема может быть правда в чём угодно, начиная от WIFI заканчивая флоу контролем...)

Share this post


Link to post
Share on other sites

Нет, это ретрансмиты уже на http. Я про захват UDP

Share this post


Link to post
Share on other sites
Нет, это ретрансмиты уже на http. Я про захват UDP

Если только в статистике самой ОС их нарыть.

СС считает, crc32 для psi тоже.

 

	PID: 0 [Packets: 881, Size: 165628, Scrambling: 0, TE count: 0, CC errors: 1, CRC32 errors: 0, Data errors: 0]
	PID: 17 [Packets: 53, Size: 9964, Scrambling: 0, TE count: 0, CC errors: 0, CRC32 errors: 0, Data errors: 0]
	PID: 18 [Packets: 606, Size: 113928, Scrambling: 0, TE count: 0, CC errors: 1, CRC32 errors: 0, Data errors: 0]
Programm: 12101 [PID: 3301, Data PIDs count: 2]
	PID: 3301 [Packets: 319, Size: 59972, Scrambling: 0, TE count: 0, CC errors: 2, CRC32 errors: 0, Data errors: 0]
	PID: 321 [Packets: 212122, Size: 39878936, Scrambling: 0, TE count: 0, CC errors: 1, CRC32 errors: 0, Data errors: 0]
	PID: 401 [Packets: 16172, Size: 3040336, Scrambling: 0, TE count: 0, CC errors: 1, CRC32 errors: 0, Data errors: 0]

Share this post


Link to post
Share on other sites

Из /proc/net/udp оказалось очень полезно прочесть. Там несложно парсится и можно к каждому захватывающему сокету привязать статистику.

Share this post


Link to post
Share on other sites

из минусов (не существенных):

1. раньше потребляли столько мультикаста сколько каналов смотрят - щас из-за того что всё каналы кэшируются потребляем сразу всё

Минус всё-таки очень существенный. У меня, например, бОльшая часть каналов просто так для ассортимента, реально смотрят абоненты процентов 20 из них, и если я с аплинка начну потреблять сразу все, всё умрёт напрочь, т к канал на это не рассчитан.

Share this post


Link to post
Share on other sites

OnDemand может, но тогда не будет прекеша и каналы будут заметно дольше включатся (для первого кто включил канал), как на обычном udpxy.

Есть и крутилки:

- сколько времени держать канал после отключения последнего клиента который этот канал смотрел;

- ждать или нет накопления прекеша для первого клиента.

 

Если сеть своя, и есть узкий канал, то можно поставить мсд с обеих сторон, с одной настроить OnDemand по tcp-http на другой мсд, а с другой чтобы мсд постоянно каналы держал, и получится что прекеш будет довольно шустро прилетать и через узкий канал будет по одному tcp потоку на каждый канал который смотрят, те дубликации потоков на каждого не будет.

Share this post


Link to post
Share on other sites

Ну tradeoff понятен: в режиме ondemand только HLS быстро стартует.

Share this post


Link to post
Share on other sites

Это если аплинк хлс даст, а так будет цедить мультикаст как обычный udpxy.

Share this post


Link to post
Share on other sites

а будет возможность резервирования источников? Допустим 2-3 мультикаст группы и определенные правила по переключению на вторую-третью и обратно если одна отвалилась?

Share this post


Link to post
Share on other sites
а будет возможность резервирования источников? Допустим 2-3 мультикаст группы и определенные правила по переключению на вторую-третью и обратно если одна отвалилась?

Будет, но там есть нюансы: если у вас mpeg2-ts поток различается в источниках (те pid-ы и прочая служебная начинка) то клиентов скорее всего нужно будет скинуть, для их же блага.

Если поток одинаковый то можно не скидывать.

 

Касательно правил, какие примерно вам нужны?

Share this post


Link to post
Share on other sites

- поток пропал

- поток стал "пустой" (ниже определенного битрейта)

- поток стал "с ошибками" (если возможно анализировать качество потока)

Share this post


Link to post
Share on other sites

кстати, было бы круто на события "поток пропал", "поток с ошибками" и т.д. запускать внешние скрипты, можно было бы запилить простенькую систему оповешения

Share this post


Link to post
Share on other sites

Резервирование источников есть в Астре : https://cesbo.com/solutions/streaming/ можно указать любое количество источников разного типа (DVB,UDP,RTP,HTTP,Файлы) переключение будет происходить по порядку на основе данных от встроенного анализатора (Нет потока, Поток зашифрован, Низкий битрейт, Также можно установить лимит потерь пакетов при котором происходит переключение на резерв).

В расширенной версии вся информация передаётся на систему мониторинга.

Share this post


Link to post
Share on other sites

еще хочется чтобы можно было бить выходные http потоки по tcp портам, а не толко по URL. удобнее файрволом ограничивать доступ абонентам

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this