OberonCore

Эмм. Первый это который 25 килострок?
Я кстати, ошибся. Там в сырцах были ещё сторонние компоненты. Реально там где-то 10-15 тыс. строк.
Но хм. опыт у меня с ним такой: нужно было написать к этому делу плагин. На изучение того, как же это написать ушел день, при чем я в джаббере, т.е. в онлайне при этом общался с автором этой программы. И собственно даже он мне не правильно (первый раз, через полчаса разбирательств был выдан правильный рецепт (он вспомнил как там у него это реализовано )) сказал как там сделать одну штуку. В програмке другой это же было сделано минут за 10.

Первый - это вариант, который Вы оценили как Что касается "хранить"-"не хранить" - формат всё равно влияет - кешировать-то придётся по-любому.

Эмм.. Кэшировать где и что? Вот смотрят у меня видеофайло 300 клиентов. Один и тот же. Файлик скажем ну, три гига размером. Каждый естественно смотрит какую-то свою часть. Что и где кэшировать будем?

Могу добавить только следующее: можно использовать вообще "полуфабрикат" RTMP-чанков для хранения на диске/буфере/кеше, подставляя только таймштампы и заголовки непосредственно при передаче. Далее - просто смотрите, насколько близок к этому формат других планируемых контейнеров и, может быть, находите некую общую базу. Вот её-то и стоит поискать в потрохах проектов, с которыми Вы ознакомились. Преимущество, на мой взгляд, стОит отдать тому, который хоть как-то ближе к общей базе.

Но вся эта техническая лабуда меркнет перед уже упомянутой эмпирикой. Если Вы не <НазваниеФирмы>Fellow, то, видимо, придётся выбирать базу, обеспечивающую эффективность Вашей работы на "сегодня-завтра". Мэйнстрим, однако.

Если мне склероз не изменяет, то размер чанка там может меняться. В принципе кэшировать (на стороне сервера) нечего (точнее то кэширование которое можно сделать отлично сделает просто системный кэш диска), буферизирует плеер на стороне клиента.

Да, хранение в виде такого вот полуфабриката будет сделано в первую очередь и это часть необходимого функционала который обязательно потребуется.
Именно такой формат потому что это:

a) проще (формат много более примитивен, не универсален, и легче реализуем).
б) позволит докрутить то что важно мне (там будет не только аудио+видео, но и некие сигналинговые события, которые должны быть четко синхронизированны с видео и аудио рядом, я не уверен что это можно сделать без большого геморроя в умных универсальных контейнерах).

Искать некую общую не тривиальную базу для дополнительных форматов опасно в том плане, что потом внезапно потребуется ещё один формат, который в эту базу не вписывается, и либо ваять костыль, либо перелопачивать всё. Проходили такое уже

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


Если что-то получится, то это не на сегодня-завтра, т.е. проект длительный. В отличае от многих иных. Собственно вопрос в том, какой ресурс стратегически важнее -- наличие сторонних разработчиков, сообщества (и как следствие быстрое обрастание продукта всякими фичами, резвый, хотя за частую и спонтанный, багофиксинг), или же ясная архитектура и полный контроль проекта.

В принципе, если идти по второму пути, то наиболее эффективно и правильно было бы поднять флаг, оживить проект и попробовать сформировать сообщество вокруг него (читай привлечь разработчиков сторонних). По сути -- составить конкуренцию тому проекту. Но тут есть опасность что средство (программа) станет целью. Ну и вообще лидером быть очень тяжело.