Фабрика новостей. Хотелось бы что-то подобное от Софтлаб-НСК

[mikhail79]

Пользуемся сейчас продуктом бывшего "Интерньюс", не очень стабильная штука, техподдержка медленная, да и скоро прекратят видимо выпуск и поддержку ПО.
Есть ли у вас планы сделать систему верстки новостей?

[Игорь Таранцев]

У нас были планы интегрироваться с Фабрикой новостей. Даже ездили к ним, общались. Но пока ничего путного не вышло.
Самим сделать с нуля - "рука не поднимается". Очень много работы.
Хотелось бы интегрироваться с кем-нибудь.
Скорее всего начнем с простого "архива" с поиском по метаданным. Но конкретных сроков нет.

[Дмитрий Куцков]

Была подобная идея. Работаю на местном телевидении (город 100 тыс. чел.) и используем «Форвард ТА» для вещания.

Есть идея организовать комплекс по автоматизации телепроизводства. Дело в том, что существующие решения расчитаны на крупных заказчиков, а для небольшой телекомпании подобные решения настолько дорогие, что проще самому сделать.
Форварду можно кормить XMLы с расписанием, например. Серверную логику построить на Linux/Unix, клиентские приложения повесить на службах веб-приложений. База данных opensource и т.п.

Такой системы очень не хватает, ибо количество возможных косяков от ручной работы просто зашкаливает.

В общем, ищу единомышленников и поддержкку.

[gosha71]

Серверную логику построить на Linux/Unix

Софт-Лаб не дружат с Unix. Были предложения создать ПО на LINUX но отказались.

[Даниленко Сергей]

Были предложения создать ПО на LINUX но отказались.

Объясню еще раз. В плате используются драйверы от компании Philips (для медиапроцессора TriMedia). Версии драйверов под Linux не существует. Переписать драйверы самостоятельно мы не можем.

[NETChaser]

Да простят меня хозяева этого форума. Лично мною сейчас готовится к выходу продукт с функционалом аналогичным продукту "Фабрика новостей". Сейчас на этапе производства последние модули программы. Сроков когда готовая система появится написать не могу. Кого интересует данный продукт и кто хочет повлиять на разработку может написать на e-mail.

[vd]

Мы вовсе не против, если вы расскажете здесь о своем продукте подробнее. Если захотите, можем разместить информацию о вашей программе в специальном разделе "Наши партнеры" на нашем сайте:
http://www.softlab-nsk.com/rus/forward/partners.html

[NETChaser]

Небольшая предыстория...
В своё время когда я работал в одной из телекомпаний города системным администратором, меня попросили написать небольшую программу для хранения базы данных с рекламными видеороликами. Написал я в то время её с использованием .NET 2.0 и MSSQL. Программа была очень простой в использовании позволяла добавлять ролики и соответственно искать в ней ролики по ключевым словам.
Сейчас я работаю уже в другом месте. В мае прошлого года меня попросили сделать по сути тоже самое (БД рекламных роликов), но с учётом дополнительного требования а именно кроссплатформенности. Разработка идет не так быстро как хотелось бы, так как имеется ещё основная работа.

Немножко о продукте (который находится в разработке) по просьбам...
Продукт по функционалу аналогичен продуктам (простите тавтология): Фабрика новостей от Интерньюс, Фабрика новостей от Рифей.
Как у всех корпоративных систем документооборота есть управление пользователями и их правами доступа. Один из главных разделов касается, как я уже писал выше, ведения БД рекламной продукции (банальная табличка с метаинформацией по каждому ролику такие как заказчик, номер, дата добавления, номер в архиве, комментарий, кто участвовал в производстве и др.).
Второй раздел касается подготовки программ и новостей. Имеется 3 подраздела. Первый для ведения БД видеоматериалов и метаинформации к ней. Второй предназначен для написания сценариев журналистами (по задумке они смогут отсматривать видеоматериалы, выполнять поиск предыдущих сюжетов и видеоряда). Третий подраздел для сбора готовых сценариев в конечный продукт (передача, новости). Есть загрузка видео, но пока данный функционал слишком медленно работает для загрузки исходного видео (кусков скажем по 50ГБ).

Продукт по сути основан на web технологиях, в качестве ОС выбрал Linux|Unix. Скорее всего после того как выйдет первая версия, будет добавлен нормальный морфологический поиск, и возможность загрузки видео с последующей конвертацией в .flv или может быть в какой нибудь другой формат.

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

[vd]

> с учётом дополнительного требования а именно кроссплатформенности

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

> Есть загрузка видео, но пока данный функционал слишком медленно работает для загрузки исходного видео (кусков скажем по 50ГБ).

А как тут ускорить процесс, если исходное видео, например, в формате DV, который занимает 13 гигабайт на час? Что с этим поделать-то?

> Продукт по сути основан на web технологиях

А Фабрика новостей на них не основана? Какие здесь преимущества в использовании веб-технологий? Только то, что работа ведется через любой веб-браузер? А так ли это принципиально?

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

[NETChaser]

Опять же почему не десктоп... Не ставилась задача монтажа видео или его нарезки. Ставилась задача организации видеоархива с поиском (поиск ведется по метаинформации или тексту). Ещё неявно преследуется цель снизить стоимость владения рабочим местом журналиста (переход на Linux, MacOS, отказ от Word и Антивируса). Централизованное хранение информации вместо файловой помойки, и совместная работа с системой (то есть всякие Excel, Access отменяются).
Журналисту что собственно нужно? Отсмотреть видеоматериал, написать некий сценарий (здесь журналист может указать видео с которым он работает и поставить метки времени, что бы потом на монтаже не искать долго нужные куски), ну и распечатать этот сценарий.
Теперь ещё раз немного о видео... видео закачивается и храниться на веб-сервере постоянно, в формате не пригодном для монтажа (возможно в низком качестве, в низком разрешении). Таким образом можно хранить достаточно большие объемы видео с мгновенным доступом. Если архивный вариант чем-то заинтересует при написании очередного сценария, то это видео уже в DV|HD качестве можно достать из архива на DVD.
Таким образом телекомпания будет иметь свой аналог ютуба в малых масштабах.
Зачем загружать видео большого объема на веб сервер? Что бы не приходилось перекодировать видео вручную отнимая время у операторов монтажа.

[vd]

> Ещё неявно преследуется цель снизить стоимость владения рабочим местом журналиста (переход на Linux, MacOS

Стоимость MacOS разве не входит в стоимость компьютера? Или это и впрямь бесплатная система?

> Журналисту что собственно нужно? Отсмотреть видеоматериал, написать некий сценарий (здесь журналист может указать видео с которым он работает и поставить метки времени, что бы потом на монтаже не искать долго нужные куски), ну и распечатать этот сценарий.

А что дальше с этим сценарием делают?

> Если архивный вариант чем-то заинтересует при написании очередного сценария, то это видео уже в DV|HD качестве можно достать из архива на DVD.

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

> Зачем загружать видео большого объема на веб сервер? Что бы не приходилось перекодировать видео вручную отнимая время у операторов монтажа.

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

[NETChaser]

> Ещё неявно преследуется цель снизить стоимость владения рабочим местом журналиста (переход на Linux, MacOS

Стоимость MacOS разве не входит в стоимость компьютера? Или это и впрямь бесплатная система?

Ну по мнению некоторых товарищей эксплуатировать скажем Mac mini c MacOS дешевле чем систему c Windows. Но это всё относится к религиозным войнам. Так же не редки зоопарки Win+MacOS.

> Журналисту что собственно нужно? Отсмотреть видеоматериал, написать некий сценарий (здесь журналист может указать видео с которым он работает и поставить метки времени, что бы потом на монтаже не искать долго нужные куски), ну и распечатать этот сценарий.

А что дальше с этим сценарием делают?

Далее как я полагаю он проходит цензуру, правку редактором, утверждение и тп. После этого уже проводиться монтаж по утвержденному сценарию.

>Если архивный вариант чем-то заинтересует при написании очередного сценария, то это видео уже в DV|HD качестве можно достать из архива на DVD.

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

Вариант с использованием рейдов и хранением видео без перекодирования так же прорабатывается.
Клиент будет сам решать хранить ему видео низкого качества с перекодированием или полного качества, учитывая свои финансовые возможности и возможности имеющегося оборудования.
Могу сказать одно - хранить весь видеоматериал на ФС это очень замечательная идея и я вовсе не против её и учту это в своем продукте... но при таком подходе клиенту придется разоряться на схд (любую систему хранения данных, будь то простой сервер подключенный к портам FC или 10Gbit, или сеть хранения данных где скорость записи около 700 МБ/с), плюс менять сетевое оборудование под свои нагрузки (в большинстве телекомпаний рабочие места журналистов как правило подключены к сетевому оборудованию с низкой пропускной способностью, например обыкновенный офисный свитч с 24/48 портами по гигабиту на каждом в некоторых случаях может стать узким местом, так как коммутационная матрица на самом деле сможет пропустить 14Гбит/с).
Если же в архиве будет храниться видео низкого качества то получиться довольно бюджетный вариант, который сможет организовать любая мелкая телекомпания, схд небольшого объема и куча пронумерованных болванок.
Кроме того необходимо учитывать что любая большая СХД имеет недостатки:
1. Когда нибудь у вас заканчивается место в рейде.
2. Со временем дохнут диски которые уже не продаются.
3. Невозможно поменять диски в рейде на диски большего объема.
За год если записывать все подряд в телекомпании численностью ~50 человек наберется 10-15 ТБ видео... В зеркале это будет 20-30 ТБ... пускай 12 самых больших дисков. А что если архив за лет 5 наберется? Сетевая СХД слишком дорога для большинства телекомпаний, как в покупке так и в содержании. Поэтому они выбирают более скромные решения.
С различными HD форматами ситуация ещё более усугубиться. Представьте что будет если каждому журналисту гнать исходное HD видео по сетке. И сколько будет стоить хранение всего записанного используя схд.
Вероятность что журналист будет копаться в старых записях и ему немедленно понадобятся старые материалы из архива крайне мала и я даже не знаю будет ли телекомпания вкладывать достаточно большие деньги, что бы поддерживать хранение материалов 3-5 летней давности с использованием схд.

> Зачем загружать видео большого объема на веб сервер? Что бы не приходилось перекодировать видео вручную отнимая время у операторов монтажа.
Видео можно перекодировать в автоматическом режиме в клиентской программе, перед закачкой или даже прямо в процессе закачки "на лету". Подозреваю, при больших объемах исходных (неперекодированных) данных может получиться ощутимо быстрее.

Я в курсе... потом будем мерить как быстрее и оперативнее.

Главная задача стоит в поиске видео по метаинформации и просмотре его теми средствами которые есть в телекомпании на текущий момент. Поставить СХД относительно большого объема при наличии денег телекомпания всегда сможет.

[vd]

Далее как я полагаю он проходит цензуру, правку редактором, утверждение и тп. После этого уже проводиться монтаж по утвержденному сценарию.

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

Вероятность что журналист будет копаться в старых записях и ему немедленно понадобятся старые материалы из архива крайне мала и я даже не знаю будет ли телекомпания вкладывать достаточно большие деньги, что бы поддерживать хранение материалов 3-5 летней давности с использованием схд.

Ну а часто ли нужно показывать в новостях что-то, что было даже вчера или пару дней назад? Мне кажется, что на сервере хранить материалы более недельной давности и смысла нет, либо нужно переносить на болванки то, что уже неделю назад было. Но вот так, чтобы прямо вообще все материалы хранить только на болванках - все-таки это неудобно, на мой взгляд. Помимо экономии денег, есть еще экономия времени, а оно, на самом деле, тоже не бесплатно даже в небольшой телекомпании. Плюс, даже новые болванки, записанные всего один раз, могут не прочитаться сразу после записи. Сталкивался с такими случаями неоднократно. И понятия "идеальная болванка", к сожалению, не существует ни за какие деньги. Даже относительно дорогие болванки, бывает, сразу после записи с ошибками читаются.

[NETChaser]

> Далее как я полагаю он проходит цензуру, правку редактором, утверждение и тп. После этого уже проводиться монтаж по утвержденному сценарию.

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

Низкое качество остается на веб сервере навсегда, полное качество скидывается на рабочее место где будет монтироваться или на сетевой ресурс. После окончания работы монтажа и выхода программы материал скидывается на болванку (если нет места где хранить постоянно большие объемы), болванка нумеруется, в программе указывается номер болванки, текстовые данные (сценарий и описание видеоряда, по которым производиться поиск остаются в БД.

[NETChaser]

Ну а часто ли нужно показывать в новостях что-то, что было даже вчера или пару дней назад? Мне кажется, что на сервере хранить материалы более недельной давности и смысла нет, либо нужно переносить на болванки то, что уже неделю назад было. Но вот так, чтобы прямо вообще все материалы хранить только на болванках - все-таки это неудобно, на мой взгляд. Помимо экономии денег, есть еще экономия времени, а оно, на самом деле, тоже не бесплатно даже в небольшой телекомпании. Плюс, даже новые болванки, записанные всего один раз, могут не прочитаться сразу после записи. Сталкивался с такими случаями неоднократно. И понятия "идеальная болванка", к сожалению, не существует ни за какие деньги. Даже относительно дорогие болванки, бывает, сразу после записи с ошибками читаются.

Этот вопрос обсуждался с заказчиком. Пришли в выводу что дешевле записывать все подряд, чем делать нарезку удачных кадров. Да в конце концов это могут быть не только болванки. Тип носителя не так важен. С тем же успехом можно нумеровать хоть жесткие диски, хоть старые кассеты.