Мультикаст & юникаст - что выбрать?

[DK]

Всё верно, но к сожалению нет инфы где найти требуемое?

Eii_External_Integration_Interface_a21.pdf

Код: [Выделить]

3.2 Detailed information for one Transport Stream
When accessing the URL /probe/etrdata?inputId=XX&tuningSetupId=YY where XX
is set to the input ID and YY to the tuning setup ID for a given stream (found in
the /probe/etrdata xml), the probe will return detailed information for the
specified transport stream.
● PID list. Key parameters: id, current, minimum and maximum bitrates, PID
type, maximum pcr jitter, cc error count, [b]scrambling [/b]information

Это не оно?

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

Лучше читать первоисточник, а именно, стандарт, описывающий методику MDI (RFC 4445 https://tools.ietf.org/html/rfc4445)
Но, в принципе, бриджтех прав. Высокие значения IAT говорят о "некачественном" транспорте и потеря пакетов здесь вполне возможна. Да, конечно, нарушение последовательности пакетов, это тоже MLR.

[skarxxl]

чем один от другова отличается можно почитать

чем отличается TCP от UDP на самом деле я представляю, но в плане работы ГС не понял.
DK, дадите ссылку на Eii_External_Integr ation_Interface_a21 .pdf ?

Это не оно?

не оно, т.к. идет описание ETR (через него мы и сделали), а не Mon, да и про scrambling нет информации

Код: [Выделить]

<pidList>
<pid id="0" bitrate="3256" minBitrate="1472" maxBitrate="5304" pidType="PAT" numCcErrors="8"/>
<pid id="8" bitrate="3256" minBitrate="1472" maxBitrate="5304" pidType="Unknown" numCcErrors="3"/>
<pid id="1760" bitrate="3256" minBitrate="1464" maxBitrate="5440" pidType="PMT" numCcErrors="4"/>
<pid id="2104" bitrate="2491736" minBitrate="2437992" maxBitrate="2560960" pidType="MPEG2 Video" maxPcrJitter="NA" numCcErrors="21"/>
<pid id="2105" bitrate="74912" minBitrate="72384" maxBitrate="78232" pidType="MPEG1 Audio" numCcErrors="9"/>
</pidList>

[1076]

в первую и решающую тем что ,
юникаст это фактически TCP ,

Вот поэтому  и  в  стране  разруха.
Ампер - это  фактически сечение. Как-то   так .

[sky star]

Ну тут целая поэма получиться если расписывать.
Вот смотрите ,  у нас станция маленькая, 15 sat приемников, 1 T2 , и 1 Gate , и 2 SDI mpeg2
получается 19 штук источников сервисов.

Далее у нас 4 QAM модулятора
и 2 SDI приема .

Получается что все что будет принято от всех возможных источников , будет иметь быть отправлено не более чем в 6 адресов !
Улавливаете мысль ?
Тут обычно возникает улыбка и возглас "мол куй то угодал товарищь !" а как же IP TV ?
как ты мол его юникастом то мол , а ? умник мол !

На что я говорю, что мы не стали мудрствовать лукаво и у нас все QAM EMR имеют лецензию на все порты ,
тут апонент обычно скисает , мол дорого ...
А поскольку список в ТВ и IP TV почти не отличается, все что приходит юникастом в порт GBE2 ,
отправляется в QAM card и отправляется в GBE1 но уже мультикастом ,
но что там за GBE1 происходит меня волнует примерно так же как события на Альфа Центавре .

Отправляя трафик юникастом я минимализирую любые ошибки в логистике потока ,
ибо если я ошибусь, то я просто сервиса на искомом порту не увижу ,
отправляя трафик юникастом я более разумно использую "стафинг"
в QAM я подаю CBR .
Завершая поэму , можно сказать , что протокол TCP он изначально родной для передачи данных,
а вот UPD приручали , приручают, и еще будут приручать ой как долго .

[1076]

Завершая поэму , можно сказать , что протокол TCP он изначально родной для передачи данных,
а вот UPD приручали , приручают, и еще будут приручать ой как долго .

:-\Теперь  все  стало понятно. Даже не поспорить.

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

На  самом деле в  мультикаст  пакетах значение некоторых  байтов  попадает  во определенный диапазон,  из  чего коммутатор делает  вывод,  что  пакет нужно  рассылать по  другим  правилам.
Более существенных  различий  как  бэ  нет   

[sky star]

1076 Я с очень большим вниманием прочитаю Вашу трактовку передачи данных юникастом .

[DK]

DK, дадите ссылку на Eii_External_Integr ation_Interface_a21 .pdf ?

Ссылку не могу дать, оно в закрытом разделе Bridgetech. Запросите у своего поставщика доступ. Там не только инструкции лежат, но и обновления ПО.

Описание интерфейса интеграции во вложении.

[sky star]

1076 Вы знаете что в юникасте указывается порт получателя
и для этого не требуется дополнительный "светлый разум" между отправителем и получателем,
это как бы сразу делается , чего проще то ?

[atx]

Ну во-первых ТСР как был изобретен для г...о линий связи, где была необходима проверка и отправка запроса отправителю на повторное получение потереного куска.

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

Для MPEG-TS - TCP зло! Потому как проще одбросить битый кусок потока и рассыпать картинку на квадратики, чем пытаться восстановить целостность повторным запросом этого куска. В первую очередь это ударит по синхронизации.

Для хорошей сети (читай идеальной), который является коммутационная шина коммутатора - фиолето вообщем то ТСР или UDP. Но "стандарт" де-факто передавать MPEG-TS в UDP-пакетах.

Юникаст - один отправитель = один получатель (на сессию), т.е. для каждого отправителя надо создавать отдельный канал связи - сессию, поэтому там стандарт де-факто TCP (но не всегда). Не мало важно, что необходимо дублировать трафик. Это у вас все подключения точка-точка, а если надо отдать поток в несколько железок? Это уже битрейт*железки.

Мультикаст - один отправитель - пофиг сколько получателей. Там не важно кто получит трафик, главное идентифицировать его (ip группы) и сообщить стеку tcp/ip, что шлет его Вася с ip 1.2.3.4 и порта 1234. Значит не надо устанавливать сессию, значит идеально для передачи в одну сторону, значит идеально подходит UDP.

А чтобы трафик у вас без присмотра не блуждал по коммутатору, умные дядьки и придумали мультикаст-маршрутизацию, где PIM стал стандартом де факто (кроме особых случаев).

По поводу вашей схемы, не вижу смысла собирать все по юникаст на одном шасси, тем более с него стримить и в QAM и в IPTV. Как минимум это нужно вторую железку рядом в горячий резерв. И да именно под вашу схему фиолетово мульти или юни.

[sky star]

НЕ вижу не чего того что бы я не знал,
но вижу то что мне совсем не сложно при гигабитных портах ,
отдать несколько десятков каналов в QAM, единицы в IP - PAL.

Да и трафик у меня не блюждает и без присмотра "светлого разума" ,
он просто изначально не может блуждать, я ему это не дозволил .

Ударов по синхонинизациям не выявляли несколько недельные
мониторы ERT 290 /

Да и я не собираю весь трафик юникаста в одном шасси ,
таких шасси 6 .