Юрий Удовиченко

Если вещание идёт по известном протоколу вроде RTMP или HLS, но в конечном счёте вы не можете воспрепятствовать записи. Как только контент физически оказался на машине пользователя - он в его полном распоряжении. Вы можете усложнить задачу, используя проприетарные протоколы - напрмиер наш SLDP. Ещё можете рассмотреть вариант использовать DRM - дорогая штука, но она сильно повышает порог вхождения для граберов.
Чем больше вложите в защиту, тем труднее будет получить контент, но и тем меньше будет ваша маржа, так что вам нужно найти золотую середину именно для вашего случая.

Вот здесь есть ответ.

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

Выше уже верно подметили, что как только контент появляется на стороне клиента - вы его не контролируете. Как вариант, можно рассмотрть DRM, но это весьма дорого. Для отсечения совсем уж недалёких можно использовать системы hotlink protection и pay-per-view (например, у нас такие есть), но надо понимать, что это повышает порог, но не убирает его совсем.

Если вы раздаёте видео через Wowza или Nimble Streamer - тогда это к нам на WMSPanel.

У нас клиенты - как раз компании, создающие свои системы доставки, от одного до десятков серверов. В целом всё основано на создании набора edge-серверов, распределённых географически.
Далее, в зависимости от типа контента, можно выделить два наиболее явных кейса.

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

2. Живые трансляции. Принципиально отличается от предыдущего тем, что актуальность контент - в пределах пары минут (ну, разве что владелец контента разрешает применить DVR). Соответственно, сеть эджей настраивается на ретрансляцию с энкодеров. Причем можно ставить промежуточные хабы, которые будут ретранслировать на нужные эджи. Есть подвид этой техники, когда сами эджи тянут потоки "по запросу", т.е. только тогда, когда их реально начинают смотреть - в этом случае можно неплохо сэкономить на трафике. По формату доставки самый оптимальный вариант - доставлять потоки в бинарных риал-таймовых форматах - RTMP или RTSP - и уже на эджах делать перепаковку в другие форматы (HLS, DASH, Icecast) и формировать ABR на их основе.

Это если вкратце. Нужны подробности - спрашивайте.

У video.js есть плагины для этого.

А где именно вы видели подобную классификацию?
В англоязычных источниках встречаю только два термина - Acquisition и Distribution, т.е. создание и распространение соответственно. Внутри каждого этапа всё зависит от типа контента.

Работа с АБР - да, это один из основных весомых плюсов для VOD HLS и VOD DASH.

нужно ли будет все имеющиеся уже видео нарезать на мелкие куски заранее или это делается на лету и особой мороки с переходом на эти технологии нет?

Предварительное пакетирование - неплохой вариант, но у него есть ряд недостатков. Поэтому медиа-сервера делают это на лету и кешируют.

Если рассматриваете вариант разработки самостоятельно, то:
1. Для деталей реализации серверной части почитайте этот ранее данный ответ.
2. По поводу передачи с мобильного - посмотрите например, на наш Larix Broadcaster или любое другое приложение для трансляции по RTSP или RTMP.

Если есть вариант брать готовые сервисы, то смотрите Ustream, Livestream, Periscope.

FFMPEG вам в помощь.

Ваша задача обычно решается несколько по-другому.
1. Поток с камеры идёт на софт, который называется медиа-сервер. Вот здесь я расписал, что это и какие есть примеры: На каких платформах работают сервисы онлайн-трансляций?
2. Медиа-сервер преобразует поток из формата, поддерживаемого камерой, в формат, понимаемый плеером конечных пользователей. В данный момент самые распространённые форматы (или протоколы) - это HLS, RTMP, MPEG-DASH. Этот же медиа-сервер может и записать видео для последующего воспроизведения.
3. На веб-сайте вы вешаете веб-плеер, который понимает потоки из п.2. Могу порекомендовать JWPlayer, video.js, bitdash.

Приложение под Андроид в этой цепочке - лишнее.

В составе транскодера Wowza есть возможность graphic overlay, попробуйте.

Если вариант сбребовать обратно деньги с продавца не подходит, стоит попробовать поставить на сайт другой веб-плеер, который будет играть ссылки на ваше видео. Выбирать стоит в зависимости от используемых протоколов и таргет-устройств.

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

Какое видело пытаетесь играть? Я о протоколе.