Topic: SVP и TCPServer/TCPSource

Существуют ли реализации или хотябы идеи как заставить SVP работать распараллеленно на нескольких пк?

Re: SVP и TCPServer/TCPSource

Считать четные кадры на одном компьютере, нечетные - на втором?
Или про что разговор?

3 (edited by tracker35 20-09-2016 12:23:28)

Re: SVP и TCPServer/TCPSource

Как вариант. Главное, чтобы заставить работать связку нескольких ПК.
И при расчете учесть разницу в производительности. а то получится, что первый ПК в простое, а второй будет пыхтеть как паровоз.

Re: SVP и TCPServer/TCPSource

Пока могу предложить лишь повышение плавности с сохранением видео. Либо видео по кускам, либо разных видео параллельно.
Только в таком случае удастся загрузить два и более компьютеров, причем на полную катушку.
Других реальных вариантов не вижу.

Почему бы не воспользоваться одним компьютером с достаточной производительностью вместо двух слабых?

5 (edited by tracker35 20-09-2016 13:09:57)

Re: SVP и TCPServer/TCPSource

Скажите где меняют два старых пк/ноутбука на один мощный wink

А если делать через бОльшой буфер.

1. Идёт запуск файла
2. первые 10 сек обрабатываются первым пк, вторые 10 сек вторым пк.
3. как только первые 10 сек обработаются, запускается проигрывание, и тут-же первый пк приступает к обработке третьих 10 сек.
3. как только второй пк обработает вторые 10 сек он передает их плееру и ждет команды от первого пк, чтобы приступить к обработке четвертых 10 сек
4. как только третьи 10 сек были обработаны, первый пк ждёт пока плеер не начнет воспроизводить вторые 10 сек.
5. как только плеер начинает воспроизводить вторые 10 сек, он отдает команду на обработку третих 10 сек, который отдает команду на обработку четвертых 10 сек второму пк
6. и так далее.

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

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

6 (edited by tracker35 20-09-2016 13:14:14)

Re: SVP и TCPServer/TCPSource

хотя нагрузку можно и распараллелить более грамотно оперируя значением svpmark исходя из которого строится значение разности.
исходя из этой разности идет подсчет разности секунд на каждом пк.

т.е. если svpmark на первом пк больше в 2 раза, то и секунд в буфер он обрабатывает в 2 раза больше второго пк.

7 (edited by tracker35 20-09-2016 13:18:25)

Re: SVP и TCPServer/TCPSource

кстати такой способ распаралеливания может даже заменить MT у ависинта, при этом позволяя делать 99% нагрузку на ЦП без 'заиканий' в просмотре.

Re: SVP и TCPServer/TCPSource

Прикинем, посчитаем необходимую пропускную способность.
Допустим кино 720p 24 к/сек надо уплавнить до 60 к/сек.
1. Декодирование видео. Этим должен заниматься один компьютер. Чтение с диска (из сети) потока 5 Мб/сек.
2. Отправка порции на обработку. Пусть будет 5 сек. 5 сек * 24 к/сек = 120 кадров.
Один кадр 1280х720 точек, каждая точка занимает 12 бит в цветовом пространстве YUV 4:2:0. Итого на 1 кадр потребуется 1280x720x12 = 11 Мбит.
Если передавать поток 24 к/сек в реальном времени, то потребуется канал связи 11*24 = 264 Мбит/сек. И это только в одну сторону.
3. Прием результата обработки. Кадры такого же размера, но уже 60 к/сек. Это 11*60 = 660 Мбит/сек.

Ноутбук потянет такой поток туда-сюда передавать? Нужна как минимум гигабитная сетевая карточка. И главное - софт, который это все сумеет организовать wink

Re: SVP и TCPServer/TCPSource

ужосы какие...

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

Re: SVP и TCPServer/TCPSource

В общем затения так себе, если только для кодирования.
обработка скрипта на одном пк, а последующий енкод на другом. Этот способ всем известный.

Просто как-то неподумалось, что сырой yuv кушает немало трафика...