Если использовать математическую модель в общем виде «для восстановления исходного потока кадров» без оптимизаций вычислений под конкретную платформу, тогда ваш CPU будет очень сильно загружен. Возможно настолько сильно, что система не справится с декодингом в режиме реального времени. Особенно, если это FullHD видео.
Во-первых, океанов несколько. Во-вторых, тут больше вопрос в том, чтобы сегмент роя p2p сети, находящийся в сегменте сети одного провайдера, трафик там и оставлял. Т.е. несколько пиров получали данные из Интернета, остальные от соседних пиров. Ну и еще — есть несколько научных работ на эту тему. Но они несколько абстрактны.
Адреса то произвольные — traceroute и ping не подходит. Операцию можно выполнить приблизительно, т.к. эта метрика нужна лишь для составления натрекере списка n лучших пиров для скачивания куска информации запрашиваемым пиром. Плюс базу BGP или RIPN можно обновлять.
Спасибо за наводну на PureVu — его еще не рассматривали. А необходимость — массовое производство здесь в Азии по нашему проекту, после тестов искизных образцов.
Под перевариванием вы понимаете видео и аудио сжатие? Если да, то есть аппартный видеокодеки на чипе. Или про пропускную способность в 3Гбит для 1920x1080x60p?
Задача — специфический захват HDMI и передача по ethernet/wi-fi. Разработка кода уровня linux kernel. Нет, но есть представление из каких компонентов строить.
Представьте, у вас за день миллион запросов. И каждый запрос обрабатывался в среднем за T тиков процессора, ищя по большим индексам одной таблицы. А с партициями каждый запрос работает в своей, производя поиск по меньшим индексам, что сокращает количество тиков на запрос.
Те же FFMpeg и VLC смогут использовать OpenCapture, как полноценный кросс-платформенный бекэнд для захвата видео и аудио с камер и микрофонов даже на мобильных устройствах.
