Нет сообщения об ошибке декодирования

[Osman]

Столкнулся с ситуацией - при прерванном ручном копировании обнулен кусок мпег2 файла, SLM-индекс остался от полного правильного файла - в результате FDOnAir показывает видео вплоть до битого куска а потом молча без сообщения об ошибке показывает остановившийся последний нормальный кадр до конца времени клипа в расписании.

Предлагаю сделать очевидное - выводить явное сообщение об ошибке декодирования.

[vd]

Здесь есть много разных проблем и вопросов.

Допустим, даже если мы как-то и смогли определить "на лету", что есть какие-то проблемы с декодированием файла, как и где предлагается сообщать об ошибке, и как вообще себя вести при этом? Варианты:
1. Вывесить на экран сообщение, которое, пока не закроешь, вещание остановлено?
2. Выводить сообщение в SLLog-файл, но продолжать вещание со стоячим кадром? Или предлагается отправлять какое-то сообщение об аварийной ситуации по e-mail, например?
3. Просто сразу переходить к следующему файлу в расписании? А что делать с тем, что все времена следующих файлов в расписании после этого файла сдвинутся назад?

Далее, как нам определить, что файл "оборвался"? Проверять, что файл кончился, просто по его длительности, размеру? Теоретически, в общем случае это делать неправильно. В MPEG-файлах могут быть "стоячие кадры", которые "висят" на экране в течение очень длительного времени. Это не AVI-файл, в котором кадры должны следовать строго с определенной частотой. В MPEG-файле в каждом кадре прописано время, в которое кадр должен быть показан. Может быть ситуация, что в файле длительностью один час всего два кадра - один с временем 0, другой с временем 01 час 00 минут 00 секунд. Это для примера.

при прерванном ручном копировании обнулен кусок мпег2 файла, SLM-индекс остался от полного правильного файла

Тут есть еще одна проблема. Чтобы понять, что SLM-файл, вообще говоря, не соответствует MPEG-файлу по длительности, придется заново проиндексировать "битый" MPEG-файл в отдельный SLM-файл, и сравнить этот SLM-файл с уже имеющимся. Другого способа нет, к сожалению.

Боюсь, надо просто быть как-то внимательнее при ручном прерывании копирования. Какими средствами файл копировался, кстати? Проводником Windows?

[Osman]

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

[vd]

Так какой из перечисленных вариантов вас устроит?

[Osman]

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

Ну, и вообще насчет любых ошибок (а не только для этой крайне редкой) - оптимальным будет общая настройка в FDOnAir для вызова заданной пользователем программы с параметрами описывающими ошибку (да, я знаю про SDK, но речь же об обычных пользователях). Тогда, например, можно было бы указать утилиту-почтовик blat или вашу собственную программу, если такая имеется, которая, например, отправит письмо на email2sms техника, и он получит сообщение на мобильный, где бы ни находился.

[vd]

> да, я знаю про SDK

Какой именно SDK вы имеете ввиду в контексте обсуждаемой темы?

[Osman]

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

[vd]

Если ошибка произошла не при подготовке файла, а в процессе декодирования, как этот SDK поможет?

[Osman]

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