Снар, а кодирование подправить, чтобы I-frames чаще ходили?

Wrtten on soft keybord, sori for mistyps...

On Nov 12, 2012 6:12 PM, "Alexandre Snarskii" <snar@snar.spb.ru> wrote:
On Sun, Nov 11, 2012 at 11:26:45AM +0100, Maksym wrote:
> Привет!
>
> Транспорт через MPLS? Если да, то можно построить 2 статических RSVP-TE
> LSP туннеля через два разных маршрута и прописать, что если первый туннель
> падает, то переключать весь трафик во второй. Между всеми раутерами нужно
> поднять BFD.
>
> Если MPLS нет, то можно построить тоже самое на "обычном" RSVP (Resource
> Reservation Protocol), но сам такое не делал.
>
> Из плюсов: скорость переключения - "как у SDH", недостаток: все
> туннели/flows прийдется прописывать вручнуюю

.... есть еще один, наверное, самый главный, недостаток: в случае данного
сферического приложения в ваккууме скорость схождения "как у SDH" совершенно
недостаточна. Ему нужно не чтобы сеть сходилась а чтобы пакеты не терялись.
_Вообще_ не терялись.
Тот один пакет, который будет потерян за время схождения сети - это уже
unacceptable :)

Я уже скромно молчу, что потеря одного пакета в минуту не приводит к
срабатыванию bfd (равно как и errored second не приводит к переключению
на sdh), а на работе некоторых отдельно взятых приложений это сказывается
крайне негативно.

case studio: живая трансляция телевизера (iirc, в mpeg4). Одна crc-ошибка
в три минуты - и всё, картинка рассыпается и "невозможно работать!" (c)(tm).


> Best wishes,
> Maksym
>
> On 9 Nov 2012, at 09:31, Alexandr Turovsky <tav@imc.org.ua> wrote:
>
> > Доброе утро коллеги .
> >
> > Вообщем предистория такова , что у клиента имеется клиент-серверное приложение , которое не терпит "пропадание 1-2-4 пакетов" в сеансе связи ,  технологически имеем разветвленную сеть (точка-многоточка)  ,
> > на каждый конечный сайт заходит 2 канала передачи данных , как L2 транспорт так и L2 поверх L3 . Каналы от 1 до 5 мбит/с , скорость передачи данных в каналах  - <<1мбит/с .
> >
> > На текущий момент поднят протокол RSTP  , который плохо  работает .
> >
> > Есть ли решения , которые позволяют избежать "в конечном канале" для клиента  потерь пакетов и имеет быструю (очень)  скорость переключения работоспособного канала ?
> >
> > (нв голову приходит что то типа потока Е1 овер L2 , но по IP и резервированием )
>

--
In theory, there is no difference between theory and practice.
But, in practice, there is.