OberonCore

Наверно лучше сюда.

Итак имею сейчас следующую ситуацию (ситуация типична для индустрии, но вот сейчас она особенно четко передо мною встала):

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

Нужно также учесть, что возможно в дальнейшем могут потребоваться некий функционал который реализован в первой программа, а во второй нет. Скопипастить код из первой во вторую нельзя -- лицензионные ограничения. Т.е. придется видимо реализовывать самому, ежели таковая потребность возникнет. Характерное время возникновения таковой потребности -- где-то полгода.

Вот сижу как буриданов осёл между этими двумя вариантами и рискую повторить его судьбу..

Прибавьте к 4 тыс. строк размер копипейстного куска и вернитесь к началу цикла

Не больше 4 тыс. строк. Думаю меньше. Т.е. суммарно 8 килострок.

я бы выбрал большую определённость: хорошая документация = возможность разобраться и дорабатывать самому без проблем = зависимость только от себя
(припоминая поговорку: хочешь сделать хорошо --- сделай сам)
особенно, учитывая объёмы

Объемы, кстати, достаточно значительные. В переводе на объемы Си или Оерон-кода это где-то порядка 20 тыс. строк кода нужно будет дописать. Ну и потребуется проработать порядка 300 страниц всяких rfc.

Какая у Вас производительность труда - сколько в среднем строк в день выдаете?

Это очень и очень зависит от. Бывает и до 600 строк в день (java, реализация того, что сам придумал и продумал). А бывает что и ноль в неделю.

В этом случае нельзя сразу садиться кодить. Вначале нужно будет проштудировать rfc. Потом провести ряд экспериментов на предмет того насколько эти rfc соответствуют реальному миру. И вот уже опосля-я.. Ориентировочный объем rfc я привел выше.

Ноль в неделю - это знакомо
600 - круто.

А в "активно развивающейся" программе эта функциональность точно будет? Это я в том смысле, что уже сейчас известно, что вам может понадобиться и что будет в этой программе, но только имеется некотороя неопределённость в виде отсутствия отмашки от начальства? Просто как бы потом в этой "активной" программе для задейстования появившегося функционала не пришлось переписывать свои допилы, прекрасно работавшие уже полгода-год.

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

Для определенности -- эти приложения, это rtmp-сервера. Ну, или, как в народе называют, flash-сервера. Сервер для flash приложения. (http://en.wikipedia.org/wiki/Real_Time_ ... g_Protocol http://ru.wikipedia.org/wiki/RTMP).

Кроме бизнес-логики и собственно rtmp на стороне сервера возможно нужно будет реализовать вещание видео. На вход серверу идет rtp либо rtsp либо rtmp. Он раздает это видео множеству подключенных клиентов по rtmp. Также возможно потребуется показывать уже записанное и уже хранящееся на диске видео. Соответственно нужна поддержка mp4, avi, mp3 и проч форматов-контейнеров.

rtp, rtsp, mp4, mpeg, mp3 -- реализованы в одном сервере и не реализованы в другом. И это может понадобиться с некоторой вероятностью.

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

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

А озвучьте, для определенности, Главную Проблему.


Про копипасту речи нет. Вопрос в том, на базе чего делать своё решение.
На счет форматов -- вот залил тебе пользователь на сервер файл в mp4, а другие хотят просмотреть то, что он залил. Либо хранить его as is, либо конвертировать. В обоих случаях нужно уметь mp4 формат. Это первый случай. Случай второй -- вот есть у нас сетевая камера. Она выдает скажем rtp поток. Или rtsp. Польователь зашел и хочет посмотреть что видно с этой камеры. Как тут быть не умея rtp и/или rtsp?

Другое дело что я не знаю точно понадобится это (именно эти варианты использования сервиса) или нет. А решать надо сейчас.

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

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


Я ж говорю -- перосто перекладываение из одного контейнера в другой. О конвертации самих медиаданных речи не идет. Я ж написал поддержка mp4, avi а не h264, h261 и т.п.


Вещать в этих форматах никто собственно не (пока) собирается. В этих форматах оно может идти на вход сервера. Вещание идет в rtmp.
Это функционал может понадобиться, а может не понадобиться. Точный объем rfc описывающих эти форматы и протоколы вы можете посмотреть сами.

Как-то Вы на ходу меняете исходные..А теперь "не хранить", "не конвертировать", "не вещать".. Но дело даже не в этом - какбэ нас не отстрелили за флейм .

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

Неа. Не меняю. Сейчас уточню.

Да. Вещание по rtmp. (не путать с rtsp и rtp).

Да, на вход идет rtmp, rtp, rtsp. При этом rtmp -- точно. rtp и rtsp могут понадобиться, а могут не понадобится. Тот самый не однозначный функционал. о котором было сказано сразу в первом же сообщении.


Не вещать (а может и вещать) в rtp и rtsp, вещать в rtmp. Эти волшебные непонятные аббревиатуры, такие похожие и все начинающиеся на букву 'r' всё же сильно разные и это имеет значение

Нужно будет хранить (читать или писать) в mp4, avi формате или нет -- также не известно. Возможно, что да.


Что-то тут второй раз уже упоминается некое мифическое начальство. Эмм.. Попытка переложить ответственность? Решение целиком на мне. Собственно обычная вилка -- тут допиливать проще, но нужно будет пилить существенно больше, а там допиливать сильно сложнее, но возможно не придется допиливать вообще, либо допилит кто-то другой, либо допил потребуется небольшой, с малой долей вероятности -- большой и геморройный. В первом мы контролируем и понимаем весь код, во втором нет.


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

В дальнейшем может потребоваться уметь понимать mp4, avi, rtp, rtsp. Просто потому, что расширение функционала решения может пойти в сторону расширения видов источников данных. Т.е. пользователь сможет залить видеофайл. Сможет подключить сетевую видеокамеру и т.п.

Нууу.. С такой "бородой" - только из собственного бизнес-модуля vlc батником пускать . Правда есть сомнения по поводу наличия rtmp у vlc'шки. Да и архитектура у неё совсем дурная. Больше смахивает на бытовой ложковилконожик. Я не стал бы такое допиливать.

VLC вообще не вариант. Разве что прикручивать его сбоку, для конвертирования куда-то там. Это как-то слишком криво...

Честно говоря, это ближе к "сдохнет либо шах, либо ишак". По первому варианту ишак сдохнет точно. Вот такая эмпирика получается