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

Вопрос -- что выбрать?

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

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

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

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

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

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

потребуется показывать уже записанное и уже хранящееся на диске видео. Соответственно нужна поддержка mp4, avi, mp3 и проч форматов-контейнеров.

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

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

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

Вопрос ещё в том, на базе чего делать своё решение.. Либо хранить его as is, либо конвертировать.

Как тут быть не умея rtp и/или rtsp?

формат хранения

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

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

возможно нужно будет реализовать вещание видео..

На вход серверу идет rtp либо rtsp либо rtmp. Он раздает это видео множеству подключенных клиентов по rtmp.

Либо хранить его as is, либо конвертировать.

Как-то Вы на ходу меняете исходные..

возможно нужно будет реализовать вещание видео..

На вход серверу идет rtp либо rtsp либо rtmp. Он раздает это видео множеству подключенных клиентов по rtmp.

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

1. Сама постановка вопроса "чьё решение допиливать" из-за незаложенного другими функционала не лежит в плоскости проектирования, особенно при отсутствии отмашки от начальства.

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

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

там допиливать сильно сложнее, но возможно не придется допиливать вообще, либо допилит кто-то другой, либо допил потребуется небольшой, с малой долей вероятности -- большой и геморройный.