zeus.json, online
player.json, online
config.json, online
Причём, первые два — на config.playwire.com, а третий — на cdn.playwire.com, а я, читая не выполняющуюся часть кода JavaScript, пытался налепить на первый домен.
В своей работе я нашёл наиболее полезным zeus.json, в нём наибольшее количество желаемой информации: и длина, и постер, и ссылка на manifest.f4m. Я поначалу этот f4m проигнорировал, мол, а зачем мне HDS, если я знаю, как делать ссылки вида cdn.phoenix.intergi.com . Напрасно. Во–первых, узнал, что manifest.f4m — не обязательно HDS, а может быть и сборник прямых ссылок на mp4. Большинство последних видео сейчас всё же залиты по моему шаблону, так что заказчик был доволен, заплатил, но процентов 15% видео криво спарсились из–за того, что я не смотрел в f4m. Некоторые видео залиты под другим адресом, пример выше как раз такой. Если посмотреть в config.playwire.com можно сконструировать URL вида cdn.playwire.com , и этот URL работает. У большинства видео, впрочем, f4m такой: config.playwire.com , здесь есть 2 формата видео, для мобилок и обычный, и адрес у обоих по шаблону.
Некоторый интерес может представлять config.json, там дан rtmp адрес, вдруг кому–то это именно то, что нужно.
Нулевой или отсутствующий duration — видимо, бывает, как раз у видео старого образца. Видео может быть нормальным, но вот длина неизвестна, если, конечно, сайт с видео не предоставил её каким–то другим образом.
Постеров, на самом, деле, похоже, может быть 10. Если URL постера выглядит так: cdn.phoenix.intergi.com , то последнюю цифру можно менять от 0 до 9 или ставить по рандому. Про другие URL постеров не скажу, но ситуация может быть похожая. Очень может быть, что всё отличается от клиента к клиенту.
1) artchive-st.cdn.ngenix.net
2) artchive.cdnvideo.ru
3) artchive.ru
Желательно указать город, регион или хотя бы страну.
Спасибо за тест.
1. Как минимум нам нужно знать количество пустого места. Тут все просто.
2. Так как диски у нас трех типов hdd 3.5, hdd 2.5 и ssd, то они, соответственно, имеют разные задержки и пропускную способность. Что делать с latency пока непонятно — если только складывать мелкие файлы, чтобы уменьшить количество fseek'ов на винт. Что делать с пропускной способностью тоже не ясно, т.к. она зависит от характера нагрузки. В голову приходит только экспериментально посчитать для каждого типа показатель "производительности".
3. Некоторые наши файлы являются важными и должны иметь несколько копий в системе. Тут мнения разделились.
a) если исходить из того, что вылет двух винтов на коротком промежутке времени, это маловероятное событие. Соответственно, мы просто храним две копии, и каждые 5 минут долбимся на машину и проверяем жив ли винт. Если нет, то делаем новую копию файла. Минусы — при вылете винчестера придется большая нагрузка на менеджер-раскладыватель(нужно научить ноды копировать файлы друг у друга, чтобы не тратить память менеджера впустую).
b) у каждого винчестера есть какой-то показатель надежности(рассчитываемый по возрасту и типу), и надежность файла это сумма надежностей его копий. Т.е. файл может оказаться на 2-х молодых винтах, или 3-4 старых. Доступность файла не проверяем, и делаем его копию только в случае, если пользователь не может скачать.
c) на части машин ставим RAID 6, т.е. делаем надежность свойством машины. Из минусов — либо ставим железный контроллер и увеличиваем стоимость отдельной машины, либо молимся на прямоту софтверной реализации. Еще один минус — все копии файла лежат на одной машине. Если какой-то файл становится сильно популярным, то он отъест большую часть канала.
Скорее всего будет вариант a, возможно, временно сделаем raid.
4. Получать информацию будем через опрос менеджером нод, чтобы не пришлось узнавать о вылете ноды какими то окольными способами.