[MiO]

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

 

	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 заканчивая флоу контролем...)

[maxlapshin]

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

[Ivan_83]

Нет, это ретрансмиты уже на 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]

[maxlapshin]

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

[Барагоз]

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

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

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

[maxlapshin]

А чего, ondemand не может?

[Ivan_83]

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

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

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

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

 

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

[maxlapshin]

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

[Ivan_83]

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

[Helios]

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

[Ivan_83]

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

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

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

 

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

[Helios]

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

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

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

[shicoy]

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

[and_cesbo]

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

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

[Helios]

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

[Ivan_83]

Добавил Lite версию в шапку.