Автоматизация управления телевизионным эфиром
18 января 2012 в 17:30

Автоматизация управления телевизионным эфиром

На сколько, по Вашему мнению, необходимо автоматизировать процесс управления телевизионным эфиром на ТВ каналах, путем создания специализированного программного обеспечения, которое координировало работу всех отделов в том числе и рекламного?

4220
Комментарии (53)
  • 18 января 2012 в 19:05 • #
    Ирина Дмитриева

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

  • 18 января 2012 в 21:23 • #
    Алексей Подлубный

    Имееться ввиду программа(одна) позволяющая:
    Планирование объема и структуры телевизионного вещания на год.

    Создание и редактирование жанровых телевизионных сеток.

    Создание и редактирование еженедельных детальных телевизионных сеток.

    Наполнение межпрограммных вставок (рекламные блоки, анонсы, служебные вставки).

    Формирование ежедневных плей-листов.

    Создание фактической сетки по факту выхода в эфир.

    Подготовка статистических отчетов об объемах и структуре телевизионного вещания.

    Гибкая система прав пользователей в работе с базой данных в зависимости от настроек администрирования.

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

    Спасибо за вопрос!

  • 19 января 2012 в 01:09 • #
    Дмитрий Куцков

    Я работал 6 лет на региональном, точнее даже городском телевидении. И идея автоматизации очень правильная, особенно когда встает вопрос квалификации персонала.
    Сегодня на мой взгляд автоматизация нужна везде, на каждом участке телепроизводства. Связано это в первую очередь с переходом на безленточные технологии. При правильном подходе (вернее сказать, при правильно поставленном техзадании) с помощью системы автоматизации можно не только сэкономить массу времени, но и снизить вероятность действия человеческого фактора.
    Такие системы обычно комплексные и достаточно сложны в организации. А про доступность таких систем для небольших телекомпаний пока говорить не приходится. В связи с этим у меня даже были собственные идеи "исключения человеческого фактора". То есть, избавить эфир от работы "чьих-то рук". Например, подготовка титров. Не у всех глазомер хороший. Титры в эфир идут криво выстроенные, ошибки в тексте... Сделал БД и две софтины. Для забивки титров и для получения готовых .PNG-файлов с выровненными полями. Ответственность за ошибки упала целиком на службу новостей. Избавились от проблем...
    Это только маленький пример на одной простейшей задаче... А комплекс оказался бы весьма мощным.

    Есть вообще идея разработать свою недорогую и легковесную систему автоматизации производства. Хотелось бы еще и Media Asset Management поднять... но пока не встречал единомышленников.

  • 19 января 2012 в 15:32 • #
    Алексей Подлубный

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

  • 19 января 2012 в 16:08 • #
    Дмитрий Куцков

    Очень рад приятной встрече с единомышленником.

    Да. Титры это частный случай. А на счёт общего рабочего процесса – здесь Вы совершенно правы. Система должна быть интегрирована. У меня к сожелению нет какого-либо серьезного опыта разработки ПО (разве что мелкие утилиты), хотя есть желание что-то сделать серьезное.
    В организации такой системы есть несколько сторон. Одна сторона – производство материала. Другая – вещание. Эфирные справки, отчеты и работа с медиа-сервером – это часть вещательная. Думаю, её организация значительно проще, чем производственная... хотя, есть различные вещательные системы. В России многие регионы используют нечто вроде Forward'а ( www.softlab-nsk.com ). У нас такая же система на эфире. И когда я думал о выдаче готового плей-листа эфира, я расчитывал именно под эту систему. Хотя, тут дело касается просто интерфейса. А его реализация для конкретной системы вещания может быть различной.
    А вот производственная часть очень зависит от конкретного рабочего процесса. И тут нужна значительная гибкость. Скажем, кроме телевизионного вещания, ведется еще и радиовещание. В таком случае, часть синхронов (интервью) в виде звуковых файлов необходимо передавать звукорежиссерам для выпусков новостей...
    Таких нюансов в работе – пруд пруди. Вплоть до того, что в работе могут использоваться даже разные платформы (Mac и Win)...

  • 19 января 2012 в 18:04 • #
    Алексей Подлубный

    У нас достаточный опыт разработки подобных систем, нами разработана система"ТВ Маркет"- предназначена для учета рекламного времени на ТВ каналах(http://www.planetasoft.com.ua), но она больше подходит для сейлз-хаузов(оптовики покупающие рекламное время на нескольких каналах таких как ВидеоИнтернейшл(ВИ) и продающим его рекламным агентствам.
    О производстве:каналы- это коммерческие организации, которые получают лицензию, в которой указывается в направленность канала(детский, музыкальный и т. д.)и доля рекламы на канале в % или части от общего эфира, превышать указанный лимит не рекомендуется т.к. после этого могут последовать штрафные санкции(вплоть до лишения лицензии) за этим надо следить.При создании телевизионной сетки надо учитывать жанр,наполнять меж программные вставки(рекламные блоки,анонсы,служебные вставки)и сетка формируется посекундно, чтобы не было окон, если таковые есть, то их также заполняют.Сетку формируют на год, месяц,неделю,на день формируют плей лист, а затем создают фактическую сетку по факту выхода в эфир.Права всех пользователей разграничены в зависимости от функциональных обязанностей.Я не вижу сложностей для использования такой программы на радио, т.к. принцип работы тот же.А что касается Мас, то они позиционируют свое оборудование и ПО как лучшее для использование в ТВ сфере, так это или нет спорить не буду, но знаю точно, что оно в разы дороже от аналогичного.

  • 20 января 2012 в 00:14 • #
    Дмитрий Куцков

    По поводу лицензий и концепции вещания – всё так и есть. Единственно, что такого рода нарушения обычно не караются (или по крайней мере не сразу). Больше наказывают за объём вещания (недобор/перебор)...

    О производстве я говорю, потому что существует огромное количество каналов, на которых производство осуществляется в тех же стенах, из которых осуществляется вещание. Это как правило небольшие городские телкомпании. Для выпуска регулярной передачи не создаются отдельные коммерческие проекты, а выделяется творческий состав, который и делает всю работу от съемки до выдачи мастера на эфир. И вот меня интересует именно организация этого процесса в рамках небольшой телекомпании (собственный эфир которой порядка 30 часов в неделю, остальное – эфир федерального телеканала).
    Система автоматизации телепроизводства обязана взаимодействовать с системами нелинейного монтажа. Они существуют и для Mac (Apple Final Cut, Avid Media Composer, Adobe Premiere) и для Win (Avid, Premiere, Canopus Edius, Sony Vegas, etc). Это может быть простая работа на уровне общих ресурсов сети типа SMB/NFS/AFP, тогда приходится монтажерам вручную «шариться» по дискам/массивам/хранилищам в поисках материала. Но я вижу некоторые дополнительные программные средства на рабочих станциях, которые позволят автоматизировать импорт и экспорт материала в/из монтажной системы на хранилище или видео-сервер и указать некоторые мета-данные. А зоопарк в студиях никто не отменял. И упомянутая выше «титровалка» не работала на Mac'е без танцев с бубном и MONO. Потому машина выпала из процесса монтажа новостей.
    offtop =) То что маки в разы дороже – факт. Но кто использовал, тот знает, что оно того стоит.

  • 20 января 2012 в 13:15 • #
    Алексей Подлубный

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

  • 20 января 2012 в 13:59 • #
    Дмитрий Куцков

    Это так только в одной части...
    Вообще задача такая.
    Есть задание на съёмку материала. Заносим информацию о грядущей съемке в БД. (информация о съёмочной группе и рабочее название сюжета).
    Снятый материал «загоняется» в хранилище. Сразу к этому материалу приписываются метаданные (место съёмки, что снимали, кто был на кадрах и т.п.)
    Сразу генерируются прокси-медиа, для обеспечения возможности отсмотра этого материала (ассистентами или корреспондентами).
    Далее на монтаже для импорта материала в монтажную программу выбираем просто указанное название сюжета и «Импорт». Нужные файлы сами «ложатся» на монтажный стол. Титровалка может быть прикручена здесь. Одновременно с импортом материала импортируются готовые титры, которые просто нужно поместить на линию (или же вариант, когда титры накладываются автоматически системой автоматизации вещания, тогда при монтаже они не нужны, а отмечаются только точки входа и выхода титров).
    После монтажа «Экспорт», при котором указывается только имя монтажера, категория и название материала. Экспортируемый файл сам «ложится» в нужное место. И «привязывается» к БД.
    Плей-лист эфира состоит из блока новостей, межпрограммного пространства, рекламы и тематических телепередач (+ прямые эфиры).
    Из готовых материалов составляется плей-лист эфира (различные категории наполняют различные блоки).
    Этот плей-лист каким-то способом (различным для разных систем автоматизации эфира) отдается на эфир.
    Соответственно, нужны участки контроля выпускающими редакторами и главным редактором.
    То есть до внесения материала в плей-лист он должен быть утвержден двумя подписями.
    В целом, картина примерно такая. Есть еще детали...

  • 20 января 2012 в 15:50 • #
    Алексей Подлубный

    Давайте по порядку- что у Вас есть , а чего нету?
    БД о сьемке у Вас есть?Что такое хранилище, где оно находиться, есть оно у Вас? Прокси медиа есть или нет,что оно из себя представляет?Монтажная программа Ваша?После монтажа при Экспорте куда попадает файл(нужное место)?БД единая(общая)?Плей- лист попадает в Эфир-когда программа по указанным путям находит необходимый материал и подает в эфир(желательно знать механизм,алгоритм).У Вас есть видео сервер:Аппаратная и программная части, какие?Контроль редакторами плей-листа осуществляется подписывается на бумажном носителе(т.е. плей-лист должен быть преобразован в excel-это форма отчета?) Можно и другие детали:)

  • 20 января 2012 в 17:49 • #
    Дмитрий Куцков

    Прокси-медиа, это копии видеофайлов, только небольшого разрешения с качеством компрессии достаточным для просмотра и оценки содержимого видеосъёмки. Они генерируются серверной стороной сразу после того, как полученный со съёмки материал окажется в хранилище (так называемый ingest). Система сама определяет как на диске разместить полученный материал и заносит информацию о каждом файле (хронометраж, кодеки, разрешение, а также метаданные) в базу данных. Для базы данных отдельно имеем выделенную машину (SATA RAID1 + System HDD) MySQL / PostgreSQL на базе FreeBSD.
    Есть отдельная машина, хранилище с внешним массивом на 9 Тб (пока что), Windows Server 2008 (чисто файл-сервер).
    Есть станция вещания, она же видео-сервер (Forward TA), станции NLE на базе Edius, Premiere, Final Cut Pro. В настоящее время для вещания материал копируется с хранилища на локальный диск видео-сервера и потом вручную заносится в плей-лист на основании утвержденного бумажного плей-листа, ранее подготовленного выпускающим и утверженного главным редактором. Без подписей лист в эфир не выходит.

    Есть отдельная машина, которую планировали выделить под автоматизацию различных нужд (FreeBSD, JDK6, библиотека ffmpeg). Она мониторит изменения на хранилище и обрабатывает все запросы от всех клиентов системы, вносит изменения в БД (одним словом, сервер приложений).

    Плей-лист составляется выпускающими редакторами только из готового материала (или планируемого), но никак не из исходного.
    Структуру БД необходимо прорабатывать. БД единая для всех компонентов комплкса.
    Размещение файлов на хранилище определяет серверная сторона автоматически.
    Любой отмонтированный материал должен попадать в архив. Оттуда же все дальнейшие движения готового материала.
    Плей-лист составляется в электронном виде и печатается для отчетности.
    Мы в последнее время делаем иначе. Плей-листы не печатаем, а только храним в электронном виде. Печатаем только для Роскомнадзора, по их требованию (обычно они месячный или недельный плейлист просят и журнал выхода в эфир за месяц).
    У монтажера программа, в которой указывается готовый файл отмонтированной передачи (находится на монтажной станции), информация о том, что это за передача (информация уже запланирована, готовый список), кто монтировал (список монтажеров). Файл отправляется на сервер (я делал отпраялялку по FTP) и отдается команда серверу приложений на получение материала и информации. Сервер приложений ожидает получения всего файла и потом перемещает в нужное (на его «взгляд») место. Аналогичным методом можно осуществить перенос исходного материала... Для ingest'а как правило нужна отдельная станция. Условно считаем, что имеется.

    По поводу программной части всех компонентов, думаю её можно реализовать на .NET или Java (если хотеть кросс-платформенность). Сервисы – с помощью .NET/Java, а некоторые компоненты можно и на Сях =) (напрмер, для транскодирования). Я на FreeBSD это начинал делать, но всё только эскизно и сказывается недостаток опыта проектирования...
    Для получения плей-листа и файлов для эфира нужен другой клиент. В общем получается, что клиенты нужны для редакторов (заносится название сюжета, подготавливается плей-лист блока/эфира, просмотр готового материала для утверждения), диспетчера (информация о составе съёмочной группы, дате и времени съёмки заносится им), монтажера (связывает файл готового материала с его записями в БД, получает исходный материал на основании записей из БД), архивариуса (осуществляет «загон» сырого материала в архив и занесение метаданных, поиск сырого и готово материала в архиве по метаданным), оператора эфира (получает плей-лист, файлы для выпуска в эфир и др. возможную информацию, может также вносить в БД отчеты видеосервера о выпуске в эфир)

  • 23 января 2012 в 12:37 • #
    Алексей Подлубный

    Здравствуйте Дмитрий.
    В нашем общении возникла пауза- связаная с оценкой сложности задачи, но как только результат будет я отвечу.

  • 23 января 2012 в 13:15 • #
    Дмитрий Куцков

    Существуют аналогичные решения от Dalet, SkyLark, VizRt. Они все содержат компоненты управления медиафайлами, т.н. Media Asset Managment, MAM, но "заточены" для видеосерверов на подобие Omneon, SkyLark...
    Только это – неподъёмные цены

  • 23 января 2012 в 13:48 • #
    Алексей Подлубный

    И что по чем?Если не секрет?)

  • 23 января 2012 в 15:31 • #
    Дмитрий Куцков

    Точно не скажу (уже не помню), но проект автоматизации (с оборудованием) для новостей нам посчитали на 7 лимонов рублей.

  • 23 января 2012 в 18:57 • #
    Алексей Подлубный

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

  • 25 января 2012 в 21:41 • #
    Дмитрий Куцков

    Думаю, в общем нужно считать, что всё необходимое железо имеется.
    От системы требуется в общем-то одно. Исключить работу людей с самими файлами и серверами. Вместо этого они используют средства, которые их от этого абстрагируют.
    Есть архив, куда должен быть "сложен" весь материал (и готовый, и "сырой").
    Есть ежедневный эфир (утро, обед, вечер), в котором имеется новостной блок, тематический и реклама. Реклама вставляется также в течение дня во время вещания сетевого партнёра (т.н. местные блоки).
    Любой материал (как информационная единица) должен быть утвержден в эфир. Иметь о себе всю необходимую информацию для его выборки из архива по любому полю.
    Основная информация о материале заполняется его автором в момент постановки задачи о его создании. В этот момент появляется эта "единица", поля которой будут заполнены к концу производства. Имя видео файла (или его содержимое) – это одно из полей этой "единицы".
    Выпускающий редактор должен иметь возможность отсмотреть любой готовый материал и внести его в плей-лист любого будущего дня (этот материал не обязан иметь готовые присутствующие видеофайлы). Главный редактор должен иметь возможность отсмотреть любой из материалов, занесенных в плей-лист и утвердить плей-лист в эфир (все материалы должны быть готовы). В случае не утверждения ставится пометка на той позции плей-листа, которая стала причиной неутверждения (с комментарием).
    Без утверждения главным редактором плей-лист эфира получить невозможно, как и получить все файлы для их внесения в плей-лист вещательной станции...
    По пунктам.
    1. Создание записи о материале (только БД).
    2. Внесение отснятого материала в хранилище, запись информации о съёмке (видео+БД).
    3. Импорт материала для монтажа, т.е. получение материала с сервера или импорт файлов с хранилища и работа с ним по сети. (видео+БД).
    4. Экспорт материала из монтажной программы и перенос его в хранилище. Указание, информации о материале указанной в п. 1 и указание имени готового файла.
    5. Контрольный отсмотр материала выпускающим редактором. Внесение материала и других материалов в плей-лист эфира.
    6. Контрольный отсмотр материала плей-листа главным редактором. Утверждение плей-листа. Распечатка утвержденного плей-листа и подписывание выпускающим и главным редактором.
    7. Генерация плей-листа для вещательной системы и получение материала для внесения в видео-сервер. Эфир. Также оператор эфира получает на руки бумагу с визами редакторов.
    8. Парсинг отчета вещательной системы о выходе материала в эфир. Распечатка отчета. Прикладывается к плей-листу.

    К сожелению я не знаю какие правильные формы установлены законодательством для документооборота внутри телевизионной компании.

    В описанной системе основное – софт. Копирование или некопирование материалов с архива (хранилища) на локальный диск монтажной станции или видео-сервера – опционально (например, сеть позволяет надёжно воспроизводить файлы не с локального источника).
    Серверную сторону я вижу на системах Unix-like. С использованием или Win-based или Web-based (а может Java) интерфейса для её администирования.
    Хранилище примонтировано к любому каталогу сервера. Соответственно мы абстрагируемся от типа этого хранилища – NAS, внутренний RAID или еще что-то.
    Серверный софт может брать из хранилища материалы, перекодировать их в другие форматы и "выдавать" клиентам (ПО системы для видео-сервера, ПО системы для монтажных станций).
    В БД хранится информация о всех членах творческого коллектива. Указаны их должности. Должностями определяются права (архивариус, диспетчер, монтажер, корреспондент, редакторы, операторы трансляции). Понятно, что все действия логируются.
    Удалить или внести изменения в материал с архива (хранилища) может только архивариус с согласия редакторов. Заменить файл материала – только монтажер с согласия автора и редакторов (в случае если материал отмечен на перемонтаж, это может быть поле в самой "единице" которое заполняется при составлении/просмотре плей-листа).

    Надеюсь, что что-то еще прояснил... =)) Я честно пока толком не знаю как это системно изложить. Есть в моей голове ч

  • 30 января 2012 в 16:56 • #
    Алексей Подлубный

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

  • 30 января 2012 в 18:55 • #
    Дмитрий Куцков

    ээ... я бы не торопился с реализацией конкретного заказа... =) как такового его еще нет.

  • 30 января 2012 в 20:16 • #
    Алексей Подлубный

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

  • 30 января 2012 в 21:12 • #
    Алексей Подлубный

    1. Архив материалов (файловое хранилище) - в настройках программы
    отображается через локальный или сетевой путь.

    2. БД:
    1) Таблица материалов
    Поля:
    ID
    Дата последней правки
    Время последней правки
    Пользователь, кот. правил (ID)
    Флаги (в т.ч. статус материала - есть файл в наличии или нет, есть файл
    для просмотра - нет, флаг активный/архивный)
    Название материала
    Автор (ID пользователя)
    Дата съемки
    Описание материала
    Имя видеофайла для материала
    Имя низкокачественного видеофайла материала для просмотра
    2) Таблица пользователей
    Поля:
    ID
    Дата последней правки
    Время последней правки
    Пользователь, кот. правил (ID)
    Флаги (в т.ч. активный/архивный пользователь)
    Фамилия
    Имя
    Логин
    Пароль
    Группа (ID)
    Права
    3) Таблица групп пользователей (в первой версии программы создается
    автоматом при установке, интерфейса по редактированию групп нет)
    Поля:
    ID
    Дата последней правки
    Время последней правки
    Пользователь, кот. правил (ID)
    Название группы
    Шаблон прав для пользователей группы

    3. Клиентская часть (интерфейс пользователя), позволяющая выполнять
    следующие действия:

    0. Соединение с серверной частью, аутентификация и авторизация
    пользователя (в том случае, если без сервера обойтись не удастся).
    1. Добавить новый материал в БД
    2. Редактировать информацию о существующем материале
    3. Загрузить видео для материала в хранилище (с созданием версии для
    просмотра и без создания)
    4. Создать версию для просмотра материала
    5. Выгрузить видео материала из хранилища
    6. Удалить видео материал в хранилище
    7. Обновить видео материала в хранилище (одновременно с изменением
    статуса материла - н: до монтажа - после монтажа) с созданием версии для
    просмотра
    8. Отсмотр материала в хранилище (только для тех материалов, у кот. есть
    низкокачественная версия для отсмотра)
    9. Добавить нового пользователя
    10. Редактировать пользователя
    11. Редактировать права пользователя
    12. Набор функций по плей-листам (КАКИЕ ИМЕННО функции нужны ???)

    4. Серверная часть (система авторизации) выполняет все запросы клиентов
    в зависимости от прав подключенного пользователя

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

  • 30 января 2012 в 22:17 • #
    Дмитрий Куцков

    Функции плей-листов:

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

    гл. редакторские - утвердить плей-лист, вернуть на доработку, отметить позицию плей-листа на удаление/изменение с комментарием.

    эфирные – получить плей-лист для станции автоматизации вещания, получить файлы для вещания по плей-листу... Может быть здесь же: прикрепить отчет станции вещания о выпуске плей-листа в эфир.

    Думаю, здесь серверная часть ПО может быть размещена на сервере, обслуживающем хранилище... На мой взгляд она желательна, потому что позволит разместить логику в одной точке, что скажется позитивно на перспективе развития данного софта. В таком случае – полная свобода реализации клиентской части (буть то .NET/Java код на клиентской машине или веб-интерфейс с сервера). Более того, нужен компонент координирующий одновременное действие нескольких монтажек/точек загона материала/редакторов. Генерация низкокачественного материала в любом случае должна происходить на сервере.

    В моем представлении рабочего процесса пользователь не должен вообще видеть файловую систему хранилища, так сказать, от греха подальше. Он запрашивает материал и получает его, например, по FTP. Складывает в хранилище готовый материал – складывает на FTP.
    Причем, FTP можно делать в chroot варианте, чтоб пользователь видел только то, что нужно.
    Для хранения материала я рассматривал вариант единого каталога на файловой системе (можно с разбивкой на подкаталоги). Файлы переименовываются и информация об исходном и новом имени заносится в БД (таблица – Файлы: id, ориг_имя, хеш_имя, дата/время загрузки, дата/время обновления, id_загрузившего, id_обновившего).
    Для работы с клиентом можно отображать ориг_имя и реагировать на команду GET ориг_имя отправляя содержимое соответствующего переименованного файла.
    Другой вариант – на каждое внесение материала в хранилище – отдельный каталог. Но, на мой взгляд файлы нужно переименовывать, чтоб исключить нестандартные имена файлов на диске...

    В общем, всё примерно так. Дополнительное деление таблиц и т.п. это уже технические мелочи.

  • 31 января 2012 в 12:43 • #
    Алексей Подлубный

    Права пользователя в данной системе будут сильно разграничены администратором и пользователь будет видеть только то, что ему позволит администратор и выполнять только разрешенные действия.Мы рассматриваем возможность работы системы с разными ОС- особенно в клиентской части, т.к. явно не все машины и пользователи будут работать на Юникс-Линукс, а часть под Винд(может мас). Где будет стоять сервер, как по мне не важно- хоть на удаленном хосте(что реально для работы в тестовом режиме). Есть еще вопросы, которые я бы хотел обсудить по почте,чтобы людям глаза не мозолить.Напишите мне пожалуйста письмо по адресу #

  • 23 января 2012 в 01:17 • #
    Владимир ЧЕРНЫШЕВ

    Вообще система могла бы быть весьма актуальной для деятельности даже печатного СМИ... Ваша компания в Москве?

  • 23 января 2012 в 11:34 • #
    Алексей Подлубный

    Наша компания работает в Украине.В чем Вы видите ее актуальность для печатного СМИ? Если несложно опишите детали системы,которая по Вашему мнению необходима.

  • 23 января 2012 в 11:35 • #
    Владимир ЧЕРНЫШЕВ

    Это нужно обсуждать с разработчиком )))

  • 23 января 2012 в 13:01 • #
    Алексей Подлубный

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

  • 23 января 2012 в 14:58 • #
    Владимир ЧЕРНЫШЕВ

    Да, примерно это так. Но есть ещё масса существенных деталей )))

  • 23 января 2012 в 13:59 • #
    Константин Черняков

    зачем велосипед изобретать , решений масса готовых )))))

  • 23 января 2012 в 16:02 • #
    Алексей Подлубный

    Не изобретайте,если цена велосипеда устраивает!))

  • 24 января 2012 в 11:15 • #
    Константин Черняков

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

  • 24 января 2012 в 19:11 • #
    Алексей Подлубный

    А можно и не сделать - не понимающий этого точно обречен!) Дороговизна любого продукта обусловлена прежде всего отсутствием более дешевого аналога(низкой конкуренцией)на рынке это касаеться и "ТВ игрушек"- а специфика ТВ в том,что важна скорость работы приложений, поэтому чем ниже уровень средств разработки тем- лучше(идеально работают программы на ассемблере), а это второй важный фактор влияющий на цену.Значит или мощное дорогое оборудование, позволющее подымать громоздкий софт без потери производительности, или дорогой софт не требовательный к железу!)

  • 24 января 2012 в 20:02 • #
    Константин Черняков

    требование к железу обуслелонно лиш форматом контента)) а что ваш сафт на какой то другой оси своей работает??
    а конкуренции хватает))кстати вещательный софт как раз и не много ресурсов отьедает))

  • 24 января 2012 в 22:20 • #
    Алексей Подлубный

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

  • 25 января 2012 в 13:24 • #
    Константин Черняков

    а как можно ознакомиться с вашим продуктом?

  • 25 января 2012 в 15:56 • #
    Алексей Подлубный

    Можно на сайте:http://www.planetasoft.com.ua, а то что касается автоматизации называется ТВ Маркет".

  • 3 февраля 2012 в 18:29 • #
    Владимир Некрасов

    Алексей, при всем уважении к Вашей позиции, позвольте возразить по некоторым пунктам.
    В системах автоматизации просматривается стойкая закономерность. Одни производители делают "вещь в себе", т.е. полностью замкнутую систему, содержащую софт и достаточно ограниченный набор "железа", чаще всего от своих партнеров. Любая попытка модификации такой системы требует вложений, соизмеримых с ценой базовой конфигурации. Типа "у нас все продумано до вас, берите что есть и не выделывайтесь". А хотите еще чего-то - платите, наш труд дорого стоит. Особенно этим грешат англичане и американцы.
    Другие исповедуют модульный подход. Система - как конструктор. Есть обязательная часть (ядро) и есть куча надстроек. Бери, что хочешь.
    Третьи идут еще дальше. Они имеют набор модулей+очень доброжелательное отношение к заказчику. Система строится и, при необходимости, кастомизируется под конкретный технологический процесс.
    Вот разработчики второго и третьего вида вызывают наибольшие симпатии.
    Теперь конкретнее. Три года назад, в начале 2009, перед нами стала задача привести накопившуюся за два предыдущих года файлопомойку в порядок. Как всегда, вариантов поначалу была масса. Ограничений по ресурсам особых не было, можно было выбирать среди самых именитых. Вот они-то и оказались самыми слабыми по части интеграции их систем в существующую структуру. Кто-то наотрез отказался от задачи, кто-то потребовал совершенно безбашенную цену чтобы "допилить" свою систему до предъявленных требований, в ком-то мы усомнились. Для примера приведу названия компаний, с которыми велись переговоры. Это Dalet, ProBel, SGT, Harris, MediaProfi, Media Alliance, Miranda, Omnibus и еще другие, которые и не вспомнить сейчас. В конечном итоге остановились на компании IT Media Group из Белоруссии, которая сделала полную автоматизацию планирования, архива и эфира. Система умеет практически все, а также полностью готова для удовлетворения любых "хотелок" пользователей. И за вполне адекватные деньги, мало соизмеримые с аппетитами перечисленных выше брендов.
    По поводу систем, которые умеют абсолютно все, то на мой скромный взгляд не стоит смешивать задачи управления эфиром как технологическим процессом и бухгалтерией, рейтингами и пр. как процессами управленческими. Такая интеграция в один момент может выйти боком.

  • 6 февраля 2012 в 13:11 • #
    Алексей Подлубный

    Здравствуйте.
    Спасибо за возражения.В системах автоматизации связь "железа" с софтом производителями делается умышлено для уменьшения рисков с вязаных нелегальным использованием данных систем. Я также больше склоняюсь к системам в которым главным есть софт не при вязаный к аппаратной части. К сожалению я не знаком с белорусской компанией и их софтом поэтому ничего сказать не могу. Хочу отметить, что я и не выступаю за смешивание процессов управления эфиром и планированием (управленческий процесс), хотя с технической точки зрения проблем для этого я не вижу, при условии, что софт имеет достаточную гибкость и может взаимодействовать с другими системами автоматизации, на что очень часто при внедрении таких систем внимания не обращают. Планирование процесс немаловажный, думаю Вы с этим согласитесь, т.к. отражает процесс получения прибыли прибыли каналом, а прибыль образуется от размещения рекламных блоков и зависит от эффективности их размещения в эфире, а рекламные агентства планируя рекламную компанию(чего либо) где попало размещать рекламу не будут, т.к. эффективность такой рекламы окажется под большим вопросом и перечислять эти факторы которых очень много не стоит, для этого есть рейтинговые компании. Ваш канал кабельный, поэтому вы рекламное время продаете поминутно и как у Вас налажено взаимодействие с рекламными агентствами? А что касается бухгалтерии , то разве плохо, если данные о контенте за который вы получили доход будут автоматически подтягиваться в Вашу бухгалтерскую программу, если последняя есть у Вас в наличии.

  • 6 февраля 2012 в 14:03 • #
    Владимир Некрасов

    Здравствуйте! Планирование эфира и управление эфиром - процессы очень сильно взаимосвязанные и оба - технологические. Возможно, мы по-разному понимаем термин "планирование". Я под планированием понимаю процесс составления перспективной и текущей сеток вещания, генерацию плей-листов, контроль за соблюдением авторских прав. Вы его рассматриваете как процесс управленческий, связанный с балансировкой затрат на приобретение контента и доходов от рекламы. Несколько разные точки зрения, не находите?
    По поводу белорусской системы. Сумы не так далеко от Киева, будете в наших краях - заезжайте, покажу.
    Наш канал не кабельный, он уже больше 5 лет в эфире в Киеве, три года на спутнике. Рекламу продавали как и все, по рейтингам GFK, Сейчас небольшие изменения в управлении каналом, из панели временно вышли, но думаю, что скоро вернемся.
    По поводу последней фразы. Программа, конечно есть, у кого их сейчас нет? Но смысла в интеграции не вижу. Более того, на одном из крупных киевских каналов умудрились планирование эфира засунуть в 1С. бухгалтерия и рекламщики довольны, эфирщики и программная служба плачут... Не хотелось бы на подобные грабли наступить.

  • 6 февраля 2012 в 14:11 • #
    Алексей Подлубный

    Спасибо за приглашение). А какая программа, если не секрет? Вы продаетесь сами?

  • 6 февраля 2012 в 14:30 • #
    Владимир Некрасов

    Описание программы здесь: http://www.igroup-media.com/ru/products/ixferusmam.html
    Сейчас рекламы на канале практически нет. То, что есть - напрямую.

  • 6 февраля 2012 в 15:02 • #
    Алексей Подлубный

    Спасибо.
    А чем Вас не устроил отечественный "Телепорт"? Напрямую с РА, а остальное ВИ забрал?
    Простите за назойливость.

  • 6 февраля 2012 в 15:09 • #
    Владимир Некрасов

    Простите за откровенность, но Телепорт - жалкая любительская поделка по сравнению с... Плюс та же самая проблема - привязанность к определенному "железу". А оно у нас очень нестандартное для украинского ТВ.

  • 6 февраля 2012 в 15:49 • #
    Алексей Подлубный

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

  • 6 февраля 2012 в 16:23 • #
    Владимир Некрасов

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

  • 13 февраля 2012 в 16:27 • #
    Алексей Подлубный

    Добрый день.
    А сколько если не секрет стоит белорусская система, а точнее ее модули iArchive и iTraffic?

  • 13 февраля 2012 в 16:34 • #
    Владимир Некрасов

    Алексей, ну такие вопросы в паблике все же не задают :-) Я могу ответить, во сколько нам обошлась система и что входило в поддержку, но только в частном порядке. Пишите, отвечу.

  • 13 февраля 2012 в 21:27 • #
    Алексей Подлубный

    Прошу прощения за прямой эфир).У меня не получается отправить в личное через профессионалы.ру, поэтому даю свой адрес:# или ,если можно дайте мне свой адрес почты и я напишу Вам.

  • 14 февраля 2012 в 13:45 • #
    Владимир Некрасов

    Ответил на указанный адрес. Ловите.

  • 23 сентября 2014 в 17:43 • #
    Гудин Александр

    Посмотрите систему http://AdvertiZoom.com (AZ), она предназначена для автоматизации бизнес-процессов телерадиоканалов, а также рекламных агентств. Функции системы можно разделить на три категории. Первая категория — это функции по управлению системой вещания канала. Вторая категория функций — это управление продажами и размещением рекламы. И наконец третья часть функций направлена на решение задач управления ресурсами и проектами телерадиоканала.

  • 19 апреля 2015 в 22:10 • #
    Виктор Решедько

    Да-да... хотелось бы оживить ветку? Как-то продвинулись? появился ли "продукт" измышленный три года назад? :)