[El_Vago]

Добрый день. Кто -нибудь использует программы или устройства для перегонки каналов из rtp в udp. Устройства конечно гуглятся, но насколько это надежно нам не известно. Из программных пока на ум приходит Astra.

[sky star]

я EMR это делаю :)

работает как АК47 или MG-39

[paradox_]

vlc/ffmpeg/gstreamer/итд гугл забит вариациями выбирайте любую

[sky star]

если этот станция CATV , если это в России , то брать RTRS 20 федералов надо по оптике ,

хотя бы для этого надо поставить шлюз ,

потом плюшкой от шлюза идут возможности принимая "из вне"

отдать в том виде и с теми параметрами pid & SI в свое вещание ,

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

 

 

[El_Vago]

43 минуты назад, paradox_ сказал:

vlc/ffmpeg/gstreamer/итд гугл забит вариациями выбирайте любую

Устройства конечно гуглятся, но насколько это надежно нам не известно.

 

29 минут назад, sky star сказал:

если этот станция CATV , если это в России , то брать RTRS 20 федералов надо по оптике ,

Нет, не Россия. Объясню для чего это нам нужно. Имеем старые приставки, которые поддерживают только rtp. Теперь же решили закупать приставки, которые поддерживают только udp(не мы решили, более умные люди). И чтобы паралельно вещать и тем и тем решили делать и rtp и udp. Тут конечно же печалит увеличение потока в два раза.

[sky star]

я бы поставил EMR и не парился ,

по уму взял бы с двумя портами ( 2+2 )

[paradox_]

Дайте определение надежности

udp и rtp никогда надежными не были

тем более если это не в одной вашей локальной сети

[sky star]

я бы не ставил удп и ртп на одну полку ,

у меня личных наблюдений анализатором ETR101209

как летит удп и ртп , и летит по разному , очень по разному ,

ртп чуток веселей

[El_Vago]

2 минуты назад, paradox_ сказал:

Дайте определение надежности

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

А по умному

Надёжность — свойство объекта сохранять во времени в установленных пределах значения всех параметров, характеризующих способность выполнять требуемые функции в заданных условиях применения, технического обслуживания, хранения и транспортирования.

4 минуты назад, paradox_ сказал:

udp и rtp никогда надежными не были

А что для мультикаста предложить можете?

 

4 минуты назад, paradox_ сказал:

тем более если это не в одной вашей локальной сети

Про то что не только в нашей локальной сети, не было разговора.

[paradox_]

rtp от udp отличается только заголовком в 12 байт

любой админ вам програмку на пару строк набросает на любом языке которая или клеит 12 байт к udp и получаем rtp

либо наоборот режем 12 байт из rtp и получаем чистый udp

поэтому ваша зарапа не понятна

ну если мультикаст значит в локальной сети, все равно что там udp или rtp или еще что то

если данные потерялись то ничего не поможет, разве что fec для rtp но уверен, такое приставки не умеют

Изменено 4 мая, 2018 пользователем paradox_

[sky star]

12 байт :)

 

мне по знакомству и личному интерес у с обоих сторон РТРС 

давал RTRS I и у udp и в rtp,

так вот на РТРС стоит ящерица , источник сигнала

один и тот же , мне вещали доп mpts в rtp ,

и я смотрел , месяц смотрел и собирал статистику ,

rtp имел на 15-20% меньше ошибок по ETR

 

а Вы пишите 12 байт  

[El_Vago]

29 минут назад, paradox_ сказал:

любой админ вам програмку на пару строк набросает на любом языке которая или клеит 12 байт к udp и получаем rtp

Не буду устраивать бесполезный спор. У Вас есть что конкретно предложить свой вариант, как Sky_star?

Изменено 4 мая, 2018 пользователем El_Vago

[paradox_]

мы же умные люди ? и понимаем что разницы никакой между rtp и udp кроме заголовка нет

я бы еще понял если бы один из них в мультикасте летел, тогда можно грешить на роутер или на подписки или на свичи которые рулят мультикастом

 

 

если вам нужно будет решение - вы его сами найдете

если вы занимаетесь распилом денег, то EMR в самый раз

[Ivan_83]

7 часов назад, paradox_ сказал:

rtp от udp отличается только заголовком в 12 байт

Вот автор астры тоже так думал, а потом фиксил, потому что оказалось что 12 байт обычно но не всегда.

 

7 часов назад, sky star сказал:

rtp имел на 15-20% меньше ошибок по ETR

Видимо там ваш глючный EMR стоял и конвертировал криво RTP в обычный UDP, от чего там и терялось.

 

10 часов назад, El_Vago сказал:

Кто -нибудь использует программы или устройства для перегонки каналов из rtp в udp.

Да как бы никому и не надо особо :)

 

Выше написали - накодить такое очень просто.

https://github.com/rozhuk-im/liblcb/blob/master/include/proto/rtp.h

rtp_payload_get() в помощь, она правильно вытаскивает данные из RTP пакетов, их потом можно сразу в sendto() сплавлять.

Я и сам могу накодить за выходные но мне лень/не надо :)

 

Меня интересует административная часть вопроса: вы будет 100500 мапингов адресов писать или хотите сразу диапазоны конвертить?

 

8 часов назад, El_Vago сказал:

Тут конечно же печалит увеличение потока в два раза.

Вещайте юникастом по хттп. %)

[paradox_]

ну то фикс был потому что кроме rtp MS додумалась еще rtp extension добавлять

в целом он и не нужен этот extension

я то говорю о том что заголовок rtp никак на качество передачи не влияет, если если бы хотя бы еще rtcp был довесок

он бы еще мог влиять восстановление от потерь, но его в iptv никто не поддерживает

оно и в voip то только для статистики используется, не смотря на его огромный функционал

[Ivan_83]

3 часа назад, paradox_ сказал:

ну то фикс был потому что кроме rtp MS додумалась еще rtp extension добавлять

Нет, это кто то наговнокодил по быстрому, лишь бы работало как то.

 

3 часа назад, paradox_ сказал:

я то говорю о том что заголовок rtp никак на качество передачи не влияет

С этим я полностью согласен, скайстар несёт какую то херню.

[maxlapshin]

19 minutes ago, Ivan_83 said:

Нет, это кто то наговнокодил по быстрому, лишь бы работало как то.

 

практически все видеостандарты устроены так, что их никогда никто полностью досконально не имплементит.

[paradox_]

40 минут назад, Ivan_83 сказал:

Нет, это кто то наговнокодил по быстрому, лишь бы работало как то

а что есть какой то стандарт или rfc намекающее что в iptv для передачи rtp нужно добавлять extension ?

и самое главное правило, что полезное есть в rtp extension ?

вот выдержка из астериска текущей ветки

	/* Look for any RTP extensions, currently we do not support any */
	if (ext) {
		hdrlen += (ntohl(rtpheader[hdrlen/4]) & 0xffff) << 2;
		hdrlen += 4;
		if (DEBUG_ATLEAST(1)) {
			unsigned int profile;
			profile = (ntohl(rtpheader[3]) & 0xffff0000) >> 16;
			if (profile == 0x505a) {
				ast_log(LOG_DEBUG, "Found Zfone extension in RTP stream - zrtp - not supported.\n");
			} else {
				ast_log(LOG_DEBUG, "Found unknown RTP Extensions %x\n", profile);
			}
		}
	}

 

[Ivan_83]

3 часа назад, maxlapshin сказал:

практически все видеостандарты устроены так, что их никогда никто полностью досконально не имплементит.

 

3 часа назад, paradox_ сказал:

а что есть какой то стандарт или rfc намекающее что в iptv для передачи rtp нужно добавлять extension ?

Речь не о разборе опций и их обработке а о том, чтобы корректно обрабатывать наличие как опций так и падинга в конце.

[El_Vago]

В 04.05.2018 в 12:25, paradox_ сказал:

любой админ вам програмку на пару строк набросает на любом языке которая или клеит 12 байт к udp и получаем rtp

Надеюсь понимаете скольким участникам форума самооценку опустили.

 

В 04.05.2018 в 12:46, paradox_ сказал:

если вам нужно будет решение - вы его сами найдете

Возможно у нас с Вами разные понятия. Но для меня, этот форум был создан, чтобы делиться опытом в использовании программных и аппаратных комплексов, а не кичиться своими знаниями. Уверен, что Вы -  молодец, и буду рад почитать ваш блог с умными статьями, или даже воспользоваться платной поддержкой в дальнейшем. Но тут  я не просил что-то настроить или создать за меня, а поделиться своим опытом использования решений, которые используете у себя. 

 

И всех с велики праздником и хороших выходных дней.

[paradox_]

если вы не поняли что я вам сказал, то не надо делать обидки

я вам как человек с опытом, сказал - абсолютно пофиг что вы там поставите, конвертировать rtp-udp/udp-rtp могут даже перл скрипты

будет надежно как танк

не можете нагуглить любой софт который клеит туда сюда лишних 12 байт

берите ffmpeg

у вас не работает ffmpeg ? ну тогда не знаю, вот автор udpxy http://udpxy.com/gigaplus-en.html скомпиленный ffmpeg за деньги продает

а у вас он бесплатно не работает ?

ну тогда для таких как вы только покупать EMR

 

[sky star]

В 04.05.2018 в 23:25, Ivan_83 сказал:

Вот автор астры тоже так думал, а потом фиксил, потому что оказалось что 12 байт обычно но не всегда.

 

Видимо там ваш глючный EMR стоял и конвертировал криво RTP в обычный UDP, от чего там и терялось.

 

Да как бы никому и не надо особо :)

 

Выше написали - накодить такое очень просто.

https://github.com/rozhuk-im/liblcb/blob/master/include/proto/rtp.h

rtp_payload_get() в помощь, она правильно вытаскивает данные из RTP пакетов, их потом можно сразу в sendto() сплавлять.

Я и сам могу накодить за выходные но мне лень/не надо :)

 

Меня интересует административная часть вопроса: вы будет 100500 мапингов адресов писать или хотите сразу диапазоны конвертить?

 

Вещайте юникастом по хттп. %)

Вас глючит , EMR в этом не участвовал , голову полечите , а то пукаете в лужу громко

 

Да и херня у тебя в черепной коробке

Изменено 6 мая, 2018 пользователем sky star

[Ivan_83]

2 часа назад, sky star сказал:

EMR в этом не участвовал

Видимо в этом вся проблема, нужно везде по EMR поставить, а лучше по три, для резервирования и лампово-скрепной реалтаймовости :)

Как сааб95 с его глюкотиками, один в один.