КОНЦЕПЦИЯ ПЕРЕДАЧИ ПОТОКА УСТРОЙСТВА ДОСТУПА Российский патент 2016 года по МПК H04N7/24 H04L29/00 

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

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

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

Соответственно целью настоящего изобретения является разработка концепции передачи или концепции подготовки передачи, которая позволяет передачу с низкой полосой пропускания и быструю синхронизацию потоков устройств доступа через основной способ передачи или слой.

Эта цель достигается с помощью устройства для подготовки потока устройства доступа в соответствии с п.1, устройства для восстановления потока устройства доступа в соответствии с п.26, способа подготовки потока устройства доступа в соответствии с п.45, способа восстановления потока устройства доступа в соответствии с п.46, сигнала передачи в соответствии с п.47 и компьютерной программы в соответствии с п.48.

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

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

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

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

В частности, предпочтительные варианты использования настоящего приложения описаны ниже с ссылками на следующие рисунки:

На фиг.1 показана схематическая диаграмма, которая иллюстрирует последовательную вставку потока устройства доступа в последовательность логических кадров, и структуру логических кадров в соответствии с вариантом осуществления настоящего изобретения;

На фиг.2 показана схема цепи передачи в соответствии с вариантом осуществления настоящего изобретения;

На фиг.3 показана схема цепи приема в соответствии с вариантом осуществления настоящего изобретения;

На фиг.4 показана блок-схема подготовки потока устройства доступа, которая осуществляется препаратором потока устройства доступа на фиг.2, в соответствии с вариантом осуществления настоящего изобретения;

На фиг.5 показана схематическая диаграмма, которая иллюстрирует структуру логического кадра в соответствии с вариантом осуществления настоящего изобретения;

На фиг.6 показана схематическая диаграмма, которая визуализирует виртуальный чередующийся подход в соответствии с вариантом осуществления настоящего изобретения;

На фиг. с 7а до 7т показаны схемы, которые иллюстрируют режим работы восстановителя потока устройства доступа на фиг.3 в соответствии с вариантом осуществления настоящего изобретения;

На фиг.8 показана схема другого варианта осуществления изобретения для режима работы восстановителя потока устройства доступа на фиг.3 в связи с FEC; и

На фиг.9 показана схема, которая иллюстрирует режим работы восстановителя потока устройства доступа на фиг.3 после проведения FEC или без FEC.

Во-первых, что касается фиг.1 и 2, на них описан вариант осуществления изобретения для подготовки потока устройства доступа последовательных устройств доступа, представляющих медиа-контент, для передачи с помощью сигнала передачи. На фиг.2 показан передатчик или цепь передачи 10, которая включает генератор потока устройства доступа 12, который предназначен для генерации потока устройства доступа 14 последовательных устройств доступа, поток устройства доступа 14, представляющих медиа-контент, например, видео или видео и аудио контент вместе с выравненным по времени текстовым содержанием или содержанием с данными, например новости или тому подобное.

Генератор потока устройства доступа 12 может включать в себя видео кодер, аудио кодер и/или генератор текстового содержания или тому подобное, или может даже принимать AU из внешнего источника (ов). Таким образом, поток устройства доступа 14 может состоять из одного или нескольких отдельных субпотоков устройств доступа с устройствами доступа разных субпотоков, расположенных в потоке устройства доступа 14 в чередующейся форме, так что устройства доступа отдельных субпотоков, относящихся к одному и тому же времени представления, группируются вместе, чтобы быть как можно ближе, или, другими словами, следуют друг за другом в потоке устройства доступа 14 непосредственно или в течение некоторого установленного максимального срока.

Кроме того, цепь передачи 10 на фиг.2 состоит из препаратора потока устройства доступа 16, предназначенного для подготовки потока устройства доступа 14 последовательных устройств доступа для передачи через сигнал передачи. Для этого препаратор потока устройства доступа 16 предназначен для генерации последовательности 18 логических кадров из потока устройства доступа 14 с помощью последовательной вставки последовательных устройств доступа в раздел полезных данных логических кадров в последовательности логических кадров, и обеспечения каждого логического кадра, в который попадает первое устройство доступа, таблицей устройства доступа, включающей, на каждое первое устройство доступа, попадающее в соответствующий логический кадр, указатель к нему. На фиг.1, например, показана примерная часть потока устройства доступа 14, включающая, например, четыре устройства доступа с AU1 до AU4 и соответствующую часть последовательности 18 логических кадров, охватывающих, например, логические кадры LF1, LF2 и LF3. Как показано на фиг.1 препаратор потока устройства доступа 16 может быть настроен так, что каждый логический кадр 20 содержит заголовок логического кадра 22 и раздел полезных данных 24. Как будет описано более подробно ниже, логические кадры 20 не должны быть постоянной длины, хотя логические кадры с LF1 до LF3, изображенные на фиг.1, иллюстрированы подобным образом.

Пунктирные линии 26 на фиг.1 иллюстрируют последовательное включение устройств доступа 28 в раздел полезных данных 24 последовательности 18 логических кадров 20. Как видно из фиг.1, препаратор потока устройства доступа 16 может быть настроен для предоставления только тех логических кадров 20 с таблицей устройства доступа 30, на которые попадает начало 32 любого устройства доступа 28. Среди логических кадров с LF1 до LF3 логическими кадрами 20 являются логические кадры LF1 и LF3, в то время как логический кадр LF2 не содержит начало устройства доступа 24 и, соответственно, не имеет таблицы устройства доступа.

Далее, как показано на фиг.1, препаратор потока устройства доступа 16 может дополнительно быть настроен так, что дополнительные заголовки логического кадра 22 регистрируются своим ведущим концом на ведущем конце соответствующего логического кадра, к которому принадлежит заголовок логического кадра 22. Как показано на фиг.1, заголовки логического кадра 22 могут быть постоянного размера, т.е. размер может быть одинаковым среди логических кадров 20. Что касается таблицы устройства доступа 30, то, препаратор потока устройства доступа 16 может быть настроен на регистрацию таблиц устройства доступа 30 задним концом к заднему концу соответствующего логического кадра, к которому принадлежит соответствующая таблица устройства доступа 30, как показано на фиг.1, или, наоборот, к ведущему концу соответствующего логического кадра, к которому принадлежит соответствующая таблица устройства доступа 30 (например, вставка вперед или назад). Таблицы устройства доступа 30 могут иметь различный размер или длину 34, в зависимости от количества устройств доступа 20, начало 32 которых попадает в соответствующий логический кадр 20. Сравнивая логические кадры LF1 и LF3, например, соответствующие начала 32 двух устройств доступа AU3 и AU4 расположены в разделе полезных данных 24 логического кадра LF3, в то время как лишь одно устройство доступа, а именно устройство доступа AU2, имеет начало 32, которое расположено в разделе полезный данных логического кадра LF1, так что таблица устройства доступа 34 логического кадра LF1 имеет длину 34 меньше, чем длина 34 таблицы устройства доступа 30 логического кадра LF3.

В случае если препаратор потока устройства доступа 16 настроен на расположение заголовка логического кадра 22 и таблицы устройства доступа 30 на разных ведущих концах и задних концах логических кадров 20, как только что было описано, раздел полезных данных 24 расположен между заголовком логического кадра 22 и таблицей устройства доступа 30 для логических кадров 20, на которые попадает начало 32 устройства доступа 28, и заголовок логического кадра 22 и противоположный конец соответствующего логического кадра для логических кадров, на которые не попадает начало 32 устройства доступа 28.

Цепь передачи 10 на фиг.2, при необходимости, включает в себя этап передачи 36 для передачи сигнала передачи 38, включая, или встраивая, последовательность 18 логических кадров 20. Например, этап передачи 36 может транслировать сигнал передачи 38. Этап передачи 36 может представлять собой транспортный слой, который, в соответствии с моделью OSI, находится ниже транспортного слоя, к которому принадлежит препаратор потока устройства доступа 16. Например, последовательность логических кадров может быть встроена в MSC поток, который, в свою очередь, передается на этапе передачи 36 в виде последовательности кадров передачи, последние из которых передаются через соответствующие символы модуляции. Этап передачи 36 может, например, передавать сигнал передачи 38 с помощью выбросов, и, например, в виде сигнала OFDM или тому подобного. Размер логических кадров 20 может быть постоянным во времени или может быть переменным, в этом случае размер соответствующих логических кадров 20 может быть указан в канале побочной информации сигнала передачи 38. Кроме того, канал побочной информации сигнала передачи 38 может включать информацию, например, время обмена данными, указывающее приемнику, когда произойдет следующий выброс, включающий следующий логический кадр, в сигнале передачи 38, с тем чтобы сделать возможным эффективную экономию электроэнергии на стороне получателя, и/или указания о том, где находится начало и конец логических кадров сигнала передачи 38.

Таким образом, при эксплуатации генератор потока устройства доступа 12 генерирует устройство доступа 28, а препаратор потока устройства доступа 16 последовательно вставляет последовательные устройства доступа 28 в раздел полезных данных 24 логических кадров 20, и обеспечивает каждый логический кадр 20, в который попадает начало 32 устройства доступа 28, таблицей устройства доступа 30. Каждая таблица устройства доступа 30 содержит, на каждое начало 32 устройства доступа 28, которое попадает в соответствующий логический кадр 20, указатель 40, указывающий на соответствующее начало 32. В связи с наличием указателей 40, приемник получает логические кадры 20 в сигнале передачи 38 и может сразу обнаружить и получить доступ к первому устройству доступа, как только декодер получает первый временной логический кадр, на который попадает начало 32 устройств доступа 28. Для этого приемник может использовать вышеупомянутые дополнительные указания, например, канал побочной информации сигнала передачи, для того, чтобы знать заранее о начале и конце логических кадров 20, или границы логических кадров могут быть определены неявно по общей структуре сигнала передачи. Таким образом, даже если полоса пропускания, используемая на этапе передачи 36, маленькая, задержка декодера при синхронизации потока устройства доступа через сигнал передачи 38 не увеличивается из-за дополнительных потребностей синхронизации, которые иначе были бы необходимы декодеру для того, чтобы обнаружить устройство доступа.

На фиг.3 показана цепь приема или приемник 50, пригодный для приема сигнала передачи 38, содержащий последовательность 18 логических кадров 20 или с встроенными кадрами, соответственно. Цепь приема 50 включает, при необходимости, этап приема 52, соответствующий этапу передачи 36. Иными словами, этап приема 52 может принадлежать к тому же транспортному уровню, к которому принадлежит этап передачи 36. Этап приема 52 может включать в себя антенну, усилитель, демодулятор, упреждающий корректор ошибки, в том числе включающий, например, турбо декодер и/или дечередователь, а также блок управления для обнаружения логических кадров в сигнале передачи 38 на основе, например, побочной информации, передаваемой в рамках сигнала передачи 38 на определенном канале, как уже говорилось выше.

Этап приема 52 передает последовательность 18 логических кадров 20 к восстановителю потока устройства доступа 54, также входящие в декодер 50. Восстановитель потока устройства доступа 54 предназначен для восстановления потока устройства доступа 14 последовательных устройств доступа 28 из последовательности 18 логических кадров 20. В частности, восстановитель 54 может быть настроен, чтобы извлекать из заданного логического кадра 20, который первым получен из сигнала передачи 38, в котором расположено начало 32 устройства доступа 28, таблицы устройства доступа 30, и обнаруживать и начать извлечение соответствующего устройства доступа 28, начало которого 32 попадает на соответствующий логический кадр 20, с помощью соответствующего указателя 40, входящего в извлеченную таблицу устройства доступа 30. Кроме этого, восстановитель 54 предназначен для последовательного извлечения последовательных устройств доступа 28 потока устройств доступа 14 из раздела полезных данных 24 логических кадров 20 из последовательности 18 логических кадров 20, полученных на этапе приема 52. Кроме того, декодер 50 может включать в себя презентатор 56 для того, чтобы декодировать и/или представлять медиа-контент, переданный с помощью последовательности 14 устройств доступа 28, восстановленный восстановителем 54 из логических кадров 20. Презентатор 56 может, например, содержать видео декодер, аудио декодера и/или обработчик текста или данных. Кроме того, презентатор 56 может включать в себя видео-дисплей и/или громкоговоритель.

Конкретные детали, которые были описаны выше со ссылкой на фиг. от 1 до 3, выгодны, но необязательны. Далее будут описаны преимущества конкретных деталей и альтернатив. Например, как описано выше, препаратор потока устройства доступа 16 может быть настроен для генерации последовательности 18 логических кадров 20, так что таблица устройства доступа 30 находится на границе заднего конца соответствующего логического кадра 20. В этой связи следует отметить, что задний конец логического кадра 20 считается концом логического кадра 20, прибывающие позже в составе сигнала передачи 38 декодером 50 с направлением времени на фиг.1, указывающем на правую сторону, к примеру. Однако, с другой стороны, таблица устройства доступа 30 может граничить с ведущим концом соответствующего логического кадра 20. Еще, таблица устройства доступа 30 может иметь заданное постоянное смещение от заднего или ведущего конца соответствующего логического кадра 20. Во всех этих случаях восстановитель 54 может найти таблицу устройства доступа 30 заданного логического кадра 20, чью таблицу устройства доступа 30 нужно оценить, на заднем или ведущем конце соответствующего логического кадра 20, или на заданном постоянном смещении.

Кроме того, как уже было описано выше, препаратор потока устройства доступа 16 может быть настроен для генерации последовательности 18 логических кадров 20, так что указатели 40 указывают на начало 32 устройства доступа 28, попадающее в соответствующий логический кадр 20 из точки регистрации, расположенной по отношению к заднему или ведущему концу соответствующего логического кадра 20, одинаковым способом для всех логических кадров 20, на которые попадает начало 32 устройства доступа 28. В конкретных вариантах осуществления изобретения, описанных ниже, например, указатели 40 указаны в соответствующих таблицах устройства доступа 30 в байтах или битах или других единицах длины, измеренных от ведущего конца соответствующего логического кадра. Однако, с другой стороны, другие точки в логических кадрах, кроме ведущего конца, могут служить как только что упомянутые точки регистрации, из которых указатели 40 указывают на начало 32 устройства доступа 28. Таким образом, восстановитель 54 может быть настроен для, при обнаружении соответствующих устройств доступа, начала 32 которых попадает на текущий исследуемый логический кадр 20, использования соответствующего указателя 40, как сдвига от точки регистрации.

Кроме того, хотя это прямо не указано со ссылкой на фиг.1, фиг.1 иллюстрирует случай, когда препаратор потока устройства доступа 16 предназначен для плавной вставки последовательных устройств доступа 28 в раздел полезных данных 24 логических кадров 20, по крайней мере, насколько это возможно. Разрыв 58 между устройством доступа AU2 и AU3 на фиг.1, например, является всего лишь результатом того, что таблицы устройства доступа 30 на фиг.1 имеют длину 34, которая возрастает с увеличением числа начал 32, попадающих на соответствующий логический кадр, так что, следовательно, раздел полезных данных уменьшается на дополнительное начало 32. Однако, кроме таких пробелов 58 устройство доступа 28 на фиг.1 легко вставляется в раздел полезных данных 24 логических кадров 20.

Кроме того, однако, устройство доступа 28 может быть вставлено в раздел полезных данных 24 логических кадров 20, не принимая во внимание заполнение данными, расположенное между ними. Например, в зависимости от приложения, устройства доступа 28, возможно, могут быть сгенерированы генератором устройства потока доступа 12, независимо от определенной скорости, с которой они должны быть переданы с помощью сигнала передачи 38, и для того, чтобы точно соблюдать такую скорость передачи данных, заполнение данными может быть выполнено между некоторыми из них в устройствах доступа 28. Таким образом, заполнение данными может быть объединено в последовательности логических кадров путем установки дополнительных указаний длины, указанных ниже, и указателей 40 на стороне передачи. Кроме того, однако, неиспользуемая или с конкретным "потоком-ID" в AU таблица указывает, например, для соответствующей AU, что эта AU содержит только "заполнение данных", то есть является "AU заполнением", и в этом случае результирующий поток AU, в свою очередь, будет поддерживать вышеуказанные свойства легко устанавливаемого потока AU, что позволяет заполнение на стороне передачи. На приемной стороне это заполнение AU будет пропущено или проигнорировано, просто другие AU будут обработаны далее.

Соответственно восстановитель потока устройства доступа 54 может, бесшовно или просто последовательно, извлечь последовательный устройства доступа 28 из разделов полезных данных 24 логических кадров 20. Для того, чтобы извлечь последовательные устройства доступа 28, восстановитель потока устройства доступа 54 может найти начала 32 следующих устройств доступа 28 либо путем использования вышеупомянутых указателей 40 или, наоборот, путем обнаружения конца соответствующих устройств доступа 28, разбив устройства доступа, с этой целью одновременно представляющие начала 32 следующего устройства доступа 28, за исключением наличия пробелов 58 как на фиг.1, что, однако, можно предвидеть с помощью восстановителя потока устройства доступа 54.

Кроме того, препаратор потока устройства доступа 16 может быть настроен, чтобы указать заголовках 22 логических кадров отсутствие таблицы устройства доступа 30 в соответствующем логическом кадре 20 для логических кадров 20, в которых нет начала 32 любых последовательных устройств доступа 28, а длина 34 таблицы устройства доступа 30 соответствующего логического кадра для логических кадров 20, на которые приходится начало 32 по крайней мере, одного из последовательных устройств доступа. Исходя из этого критерия, восстановитель потока устройства доступа 54 в состоянии извлечь из заголовка 22 логического кадра каждого логического кадра 20 информацию, указывающую на отсутствие или длину таблицы устройства доступа 30 в соответствующем логическом кадре 20, и найти расширение раздела полезных данных 24 соответствующего логического кадра 20. В частности, восстановитель потока устройства доступа 54 в состоянии обнаружить расширение раздела полезных данных 24, даже в случае если соответствующая таблица устройства доступа 30 текущего логического кадра повреждена из-за повреждения данных и, таким образом, восстановитель потока устройства доступа 54 сможет правильно продолжить извлечение устройства доступа 28, выходящего за границу между этой таблицей устройства доступа 30 и разделом полезных данных 24, в раздел полезных данных 24 следующего логического кадра 20, даже через границу логического кадра между ними.

Таким же образом, препаратор потока устройства доступа 16 может быть настроен так, чтобы каждый заголовок 22 логического кадра граничит или имеет определенное постоянное смещение от заднего или ведущего конца соответствующего логического кадр 20. В варианте на фиг.1 все заголовки 22 логических кадров граничат с ведущим концом соответствующего логического кадра 20. Таким образом, восстановитель потока устройства доступа 54 может быть настроен так, чтобы находить в каждом логическом кадре заголовок 22 логического кадра 22 на определенном постоянном смещении или на ведущем или заднем конце соответствующего логического кадра 20, то есть независимо от повреждения данных в оставшейся части логических кадров 20, например, в некоторой части раздела полезных данных 24.

В случае, описанном на фиг.1, препаратор потока устройства доступа 16 настроен на выполнение непрерывного введения последовательных устройств доступа 28 в полезный раздел данных 24 логических кадров 20 с помощью направления ввода полезных данных 60 и на организацию таблицы устройства доступа 30 в логических кадрах 20, на которые приходится начало 32 устройства доступа 28, таким образом, чтобы занимать связанную часть соответствующего логического кадра 20, имеющего постоянно расположенный конец, указывающий на направление ввода полезных данных 60, т.е. постоянно расположенный задний конец и переменный конец, указывающий обратное направление ввода полезных данных 60, т.е. переменно расположенный ведущий конец, который смещен относительно постоянно расположенного конца на длину 34 таблицы устройства доступа 30. Иными словами, указание на длину 34 в заголовках 22 логического кадра может измерить длину или размер таблиц устройства доступа 30, измеряемую из постоянно расположенного конца таблиц устройств доступа 31, а именно из его заднего конца. Таким образом, восстановитель потока устройства доступа 54 может быть настроен для выполнения последовательного извлечения последовательных устройств доступа 28 из логических кадров 20 с помощью направления извлечения полезных данных, равного направлению вставки полезных данных в логических кадрах 20, и для нахождения переменно расположенного конца таблицы устройства доступа 30 с помощью длины 34 таблицы устройства доступа 30 в противоположном направлении относительно направлению извлечения полезных данных 60 в его постоянно расположенном конце.

Это может пригодиться, если препаратор потока устройства доступа 16 настроен на получение последовательности логических кадров 20, так что таблицы устройства доступа 30 и заголовки 22 логических кадров граничат или постоянно смещаются от противоположных ведущих и задних концов логических кадров 20 и, если, соответственно, восстановитель потока устройства доступа 54 настроен на нахождение таблицы устройства доступа 30 и заголовка 22 логического кадра соответствующих логических кадров 20 на постоянном смещении или на разных ведущих и задних концах соответствующих логических кадров 20, что это имеет место на фиг.1. Это особенно верно, если заголовки 22 логических кадров имеют разную длину, которая зависит от содержания LF заголовка. В этом случае восстановитель потока устройства доступа 54 может найти таблицу устройства доступа 30 и заголовок 22 логического кадра независимо от повреждения данных в разделе полезных данных 24 соответствующего логического кадра, и может найти таблицу устройства доступа 30, независимо от повреждения данных в заголовке 22 логического кадра, и наоборот.

Чтобы быть еще более точным, препаратор потока устройства доступа 16 может быть настроен для генерации последовательности 18 логических кадров 20 таких, что таблица устройства доступа 30 и заголовок 22 логического к кадра граничат с противоположными ведущими и задними концами логических кадров 20, так что раздел полезных данных 24 является связанной частью, расширяющейся, для логических кадров 20 на которые приходится начало 32 устройства доступа 28, между таблицей устройства доступа 30 и заголовком 22 логического кадра, соответственно, и для других логических кадров 20 между заголовком 22 логического кадра и противоположными ведущими и задними концами логических кадров 20.

Как уже было показано на фиг.1 препаратор потока устройства доступа 16 может быть предназначен для получения в каждом логическом кадре 20, на который попадает начало 32 устройства доступа 28, который выходит за пределы заднего конца соответствующего логического кадра 20 в последующем логическом кадре 20, например, устройство доступа AU2 на фиг.1, таблицы устройства доступа 30 с указанием длины, указывающим на длину 62 соответствующего устройства доступа 28, то есть указание, позволяющее определять конец соответствующего логического кадра 20 в сочетании с указателем 40, указывающем на его начало. На фиг.1 препаратор потока устройства доступа 16 образцово настроен на то, чтобы сопровождать каждый указатель 40 таким указанием длины 62 устройство устройства доступа 28, начало 32 которого указывается указателем 40. В случае если устройства доступа 28, задний конец которого (в направлении разбора) невозможно определить, разделив устройства доступа 28, или лишен возможности обнаружения из-за местных ошибок в данных, восстановитель потока устройства доступа 54 может использовать указание длины 62 для того, чтобы отделить содержание устройства доступа от заполнения данных в разделе полезных данных 24. Однако, если конец устройства доступа 28 можно обнаружить при помощи восстановителя потока устройства доступа 54, разобрав устройства доступа, например, путем выявления соответствующего флага конца устройства доступа в самом устройстве доступа 28, восстановитель потока устройства доступа 54 может определить конец соответствующего устройства доступа 28 даже в случае, если указание длины 62 в соответствующей таблице устройства доступа 30 было повреждено. В любом случае, преимуществом является то, что восстановитель потока устройства доступа 54 может извлекать такие указания длины 62 из таблицы устройства доступа 30, чтобы получить длину 62 устройства доступа 28, начало которого попадает в соответствующий логический кадр 20, который выходит за пределы заднего конца соответствующего логического кадра 20 в последующем логическом кадре, даже если, например, таблица устройства доступа следующего логического кадра потеряна или повреждена. В случае плавного включения устройств доступа 28 в разделы 24 логического кадра, восстановитель потока устройства доступа 54 может даже использовать указание длины 62 устройств доступа 28, которые расширяются на последующие логические кадры 20, чтобы найти начало 32 последующее устройства доступа. Например, восстановитель потока устройства доступа 54 может использовать длину 62 устройства доступа AU1, чтобы обнаружить начало 32 устройства доступа AU2 в случае, если например, устройство доступа 30 логического кадра LF1 повреждено до такой степени, что указатель 40, указывающий на начало 32 устройства доступа AU2, не налицо.

Следует отметить, однако, что вместо указания длины, указание конца указателя может быть использовано, чтобы указать на конец соответствующего AU напрямую, то есть независимо от указателя 40, указывающего на начало 32. Эффект этого будет похож на выше описанные преимущества. Указание конца указателя может, например, включать указатель, указывающий на вышеупомянутое точку регистрации, например, ведущий конец логического кадра, на который приходится соответствующий конец соответствующего AU, до конца этого AU. Кроме того, указание конца указателя может содержать LF индикатор, указывающий в какой из следующих LF попадает конец соответствующего AU, например, путем подсчета количества LF, начиная с LF после текущего LF. Ради упрощения ниже представленного описания в соответствии со следующими вариантами изобретения используется указание длины. Тем не менее, в этих вариантах указание длины следует понимать просто как представление указания, позволяющего обнаружить конец соответствующего AU.

Как уже упоминалось выше, препаратор потока устройства доступа может быть настроен так, что каждый логический кадр 20 содержит заголовок логического кадра 22, указывающий длину соответствующей таблицы устройство доступа 30. В соответствии с воплощением изобретения изложенным ниже более подробно, препаратор 16 предоставляет каждой таблице устройства доступа 30 запись в таблице устройства доступа на каждое устройство доступа 28, начало 32 которого падает на соответствующий логический кадр 20, при этом заголовок логического 22 указывает на длину измеренной таблицы устройства доступа 30, например, число записей в таблице устройства доступа, имеющей постоянную длину в соответствующей таблице устройства доступа 30. Такой вариант воплощения описан с использованием DRM со ссылкой на фиг.5. Кратко обсудим фиг.5, из фиг.5 следует, что логический кадр 20, как образцово показано на нем, состоит из ряда записей таблицы устройства доступа 64. Так же следует из фиг.5, что раздел полезных данных 24 не может полностью покрыть оставшуюся часть логического кадра 20, кроме заголовка логического кадра 22 и таблицы устройства доступа. Скорее, как показано на фиг.5, раздел полезных данных 24 может быть компенсирован, на определенное количество байт или бит, из заголовка логического кадра 22 и/или таблицы устройства доступа 30, заданное число, например, является известным декодеру или передано декодеру через дополнительный канал сигнала передачи 38. В примере на фиг.5, например, данные FEC 66, в данном случае RS (Рида-Соломона) данные, расположены или могут расположены между заголовком логического кадра 22 и разделом полезных данных 24, при этом данные RS 66 имеют заданную длину, и улучшенный раздел 68 может быть расположен между разделом полезных данных 24 и таблицей устройства доступа 30, у которой либо постоянная длина, или, как это имеет место со следующим вариантом, различная длина, которая, например, также зависит известным образом от числа устройств доступа 28, начало которых приходится на текущий логический кадр 20, или указание на ее длину присутствует в самом разделе улучшения, но в известной границе между разделом повышения и таблицей устройства доступа. Начала записей таблицы устройства доступа 64 могут быть на расстоянии от заднего конца 70 - или, в другом варианте, от ведущего конца - логического кадра 20 в единицах постоянной длины. Таким образом, восстановитель 54 может быть сконфигурированы так что, во время извлечения таблицы устройства доступа 30 логического кадра 20, последовательно извлекать число записей таблицы устройства доступа 64, указанное в LF заголовке 33, начиная с заднего конца 70 логического кадра 20 или с положения в логическом кадре 20 с заданным постоянным смещением от него, пошагово через записи таблицы устройства доступа 64 в единицах постоянной длины этих записей таблицы устройства доступа 64 от одной записи в таблице устройства доступа до другой, чтобы получить для каждой записи в таблице устройства доступа указатель 40, указывающий на соответствующее начало 32 соответствующего устройства доступа 28. Может пригодиться, препаратор потока устройства доступа 16 заполняет таблицу устройства доступа 30 из зарегистрированного заднего конца, т.е. начиная с заднего конца 70 логического кадра 20. Другими словами, первое начало 32 устройства доступа 28, попадающее в соответствующий логический кадр 20 вместе с направлением вставки полезных данных 60, указано в таблице устройства доступа 30 с помощью соответствующего указателя в первой записи таблицы устройства доступа 64 из заднего конца 70 из логического кадра 20, то записи таблицы устройства доступа 64 ближайшей или граничащей с задним концом 70 логического кадра 20. Начала 32, следующие за направлением вставки полезных данных 60, следуют в направлении, противоположном направлению вставки полезных данных 60. Это полезно, потому что препаратор 16 может непрерывно строить логические кадры 20, а не строить их в виде логического кадра сразу.

В случае воплощения, описанного ниже, препаратор 16 может обеспечить каждую таблицу устройства доступа 30 дополнительными избыточными данными, позволяя обнаружение и/или коррекцию отдельных повреждений данных записей таблицы устройства доступа. В частности, каждая запись таблицы устройства доступа 64 сама по себе может содержать отдельные дополнительные избыточные данные. Каждая запись таблицы устройства доступа 64 может быть снабжена первыми избыточными данными, рассчитанными, и позволяющими обнаружение коррекции данных, по крайней мере по указателю 40 и, при необходимости, дополнительному указанию длины, указывающему длину 62 соответствующей записи таблицы устройства доступа 64. Как следствие, восстановитель 54 может проверить правильность AUT записей индивидуально, и повреждение одной из AUT записей не ставит под угрозу возможности использования другой AUT записи той же таблице AUT. Кроме того, как будет изложено более подробно ниже, существование первых избыточных данных позволяет даже проверить действительность или наличие следующей записи AUT, при пошаговом анализе AUT записей с постоянной длиной, если, например, общее количество записей в AUT неизвестно из-за, например, поврежденного LF заголовка.

Кроме того, каждая запись таблицы устройства доступа 64 может быть снабжена вторыми избыточными данными, рассчитанными, и позволяющими обнаружение повреждения данных, содержания устройства доступа, связанного с соответствующей записью таблицы устройства доступа 64. Таким образом, правильность каждой AU обнаруживается в индивидуальном порядке.

Кроме того, в соответствии с вариантом использования изобретения, первые избыточные данные вычисляется по, а также позволяет обнаружение коррекции данных, указателю 40, дополнительному указанию длины - возможно - и вторыми избыточными данными из соответствующих записей таблицы устройства доступа 64.

На фиг.4 описан режим работы препаратор потока устройства доступа 16 с последовательной вставкой устройств доступа 28 в логические кадры 20 с вставкой указателей 40 в таблицы устройства доступа 30 в соответствии с вариантом использования изобретения. На фиг.4 процесс начинается, когда препаратор потока устройства доступа 16 переходит к следующему устройству доступа 28 в шаге 80, чтобы продолжать последовательно вставлять устройства доступа 28 в логические кадры 20. На шаге 82 препаратор потока устройства доступа 16 проверяет, нужно ли начало 32 текущего устройства доступа 28 размещать в текущем логическом 20 кадре или нет. В этой связи отметим, что раздел полезных данных 24 текущего логического кадра уменьшается в размерах, как только следующее начало 32 устройства доступа 28 попадает в логический кадр 20, когда следующая запись таблицы устройства доступа 64 добавляется в таблицу устройства доступа 30 или длина таблицы устройства доступа 30 увеличивается. В связи с этим, препаратор 16 может решить разместить начало 32 устройства доступа 28 в следующий логический кадр, хотя, в настоящее время, раздел полезных данных 24 текущего логического кадра 20 имеет возможность размещения небольшого количества большего содержания устройства доступа в данный момент, и, хотя препаратор 16 стремится, например, плавно вставлять устройства доступа 28 в логические кадры: как только начало 32 помещается в текущий логический кадр, оставшегося объема раздела полезных данных 24 текущего логического кадра 20 кадр не хватит, чтобы разместить количество, необходимое для добавления новой записи таблицы устройства доступа 64, необходимой для индикации указателя 14 этому новому началу 32 нового устройства доступа. Пример такой ситуации показан на фиг.1 в случае начала 32 устройства доступа AU 3.

Тем не менее, разрывы, как разрыв 58, могут иметь и другие причины, чем упоминалось выше, например, следующие AU данные в очереди на обработку препаратором могут просто не быть доступны, когда LF должен быть собран, и вывод, например, этап передачи 36 для гарантии, например, непрерывной передачи сигнала 38, и в этом случае заполнение вводится препаратором 16, как указано выше.

Если препаратор 16 решает в шаге 82 разместить начало 32 текущего устройства доступа 28 в следующий логический кадр, препаратор 16 обращается к следующему логическому кадру в шаге 84, включая, например, закрытие текущего логического кадра и открытие следующего логического кадра. Закрытие текущего логического кадра может включать в себя препаратор 16, вычисляющий вышеупомянутые дополнительные избыточные данные для обнаружения / коррекции повреждения данных, такие как форвардные данные обнаружения / коррекции ошибок, которые будут более подробно описаны ниже, и рассылку логического кадра на этап передачи 36. Открытие следующего логического кадра 20 может включать предварительную установку заголовка логического кадра в исходное состояние с указанием, например, что до сих пор не существует таблицы устройства доступа в этих следующих логических кадрах. После шага 84 процесс возвращается к шагу 82 снова.

Если проверка в шаге 82 показывает, что текущее устройство доступа 28 должно разместить свое начало 32 в текущий логический кадр, процесс переходит к этапу 86, где препаратор 16 заполняет таблицу устройства доступа и обновляет заголовок логического кадра. В частности, шаг 86 может включать генерацию таблицы устройства доступа 30 в текущем логическом кадре 20, в случае если начало 32, которое является предметом шага 82, является первым началом 32 в текущем логическом кадре. Для этого начала 32, указатель 40 и, при необходимости, указание длины, указывающее длину 62, вставляется в соответствующую запись таблицы устройства доступа 64, при необходимости включая дополнительную избыточность данных для записи таблицы устройства доступа 64, и, дополнительно, отдельно для указания длины. Обновление заголовка логического кадра 22 содержит увеличения числа записей таблицы устройства доступа, указанное в этом заголовке логического кадра 22.

Как следствие да-варианта в шаге 82 препаратор потока устройства доступа 16 также вставляет текущее устройство доступа 28 в текущий логической 20 кадр в шаге 88. Во время этого препаратор 16 постоянно проверяет на шаге 90, является ли текущий логический 20 кадр полным, т.е. данные устройства доступа не могут быть вставлены в раздел полезных данных 24 текущего логического кадра 20. Если это так, препаратор 16 переходит к шагу 92, чтобы перейти к следующему логическому 20 кадру, то есть закрыть текущий логический кадр и открыть следующий логический кадр. После шага 92 процесс возвращается к шагу 88 снова. Однако, если текущий логический 20 кадр до сих пор не завершен или полностью не заполнен, препаратор 16 выполняет другую проверку непрерывно в течение вставки на шаге 88, а именно: проверка 94, является ли устройство доступа, в настоящее время вставляемое, полностью вставленным, то есть достигнут ли конец текущего устройства доступа. Если это так, то процесс возвращается к шагу 80, чтобы перейти к следующему устройству доступа в последовательности 14. Если нет, возвращается к шагу 88.

Описав в целом варианты использования цепи передачи 10, препаратор потока устройства доступа 16, декодер 50 и восстановитель потока устройства доступа 54, а также другие элементы на фиг.2 и 3, далее будут описаны варианты осуществления настоящего изобретения, которые представляют возможность расширить возможности передачи, предоставляемые DRM (DRM=Digital Radio Mondiale) до такой степени, что не только аудио, текст или данные информации могут передаваться через DRM, но и видео, смесь аудио и видео или другая выравненная по времени текстовая информация могут передаваться через DRM таким образом, чтобы качество было приемлемым на приемной стороне. Эта концепция передачи для расширения возможностей DRM далее называется Diveemo. Через Diveemo, образовательные и информационные видео программы могут передаваться через DRM.

Варианты использования для Diveemo, ранее известного как DRTV, описанные ниже, делают возможным передачу аудио и видео (возможно, вместе с данными услуг) через DRM (Digital Radio Mondiale). Возможные области применения могут включать в себя снабжение граждан, проживающих за рубежом, информацией и образовательными программами. Качество полученного изображения и звука относится к самым низким пределам ожиданий клиента, что, однако, вполне достаточно для многих областей применения.

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

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

Функциональность Diveemo: Diveemo открывает двери для широкого спектра новых информационных и образовательных услуг. Он является идеальной платформой для достижения аудитории, разбросанной в широком географическом районе, при помощи одного передатчика, и сообщения гражданам, проживающих за рубежом, о том, что происходит в их стране. Это мультимедийное приложение может быть основано на экономически эффективном глобальном стандарте наземного вещания DRM. DRM передачи на короткой волне имеют практически неограниченные возможности покрытия от 100 квадратных километров до более чем 5'000'000 квадратных километров, в зависимости от системы передачи. Применение Diveemo дает возможность бесплатного приема и не зависит от "привратников" и сторонних провайдеров, таких как спутники и кабельные сети. Возможности безграничны: один передатчик может вещать для миллионов людей в любом месте и в любое время.

Diveemo может обеспечить очень эффективное транспортное кодирование и пакетирование, и в то же время позволяет приемникам надежно и быстро декодировать и (ре-) синхронизировать передаваемое содержание. Видео поток может сопровождаться одним или несколькими аудио потоками, что позволяет поддержку синхронного многоязычия. Кроме того, система обладает всеми преимуществами платформы DRM, такими как выбор услуг по Unicode совместимым этикеткам, сигнализация и коммутация по альтернативным частотам, функции объявления и предупреждения / оповещения и т.д.

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

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

Nx Где значение N выражается как корень x. Корень x должен быть десятичным, таким образом, 2А16 является шестнадцатеричным представлением десятичного числа 42.

[x] Наименьшее целое число, численно большее, чем х. Иногда его еще называют «потолок» функции.

[x] Наибольшее целое значение численно меньшее, чем х. Иногда его еще называют "пол" функции.

$$\frac{x}{y}$$ Результат деления величины х на величину у.

MIN{a,…,z] Наименьшее значение в списке.

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

- В цифрах, бит или байт, отображаемый слева, считается первым;

- В таблицах, бит или байт, отображаемый слева, считается первым;

- В поле байтов самый старший бит (MSB) считается первым и обозначается большим числом. Например, старший бит одного байта обозначается "b7" и младший бит (LSB) обозначается "b0";

- В векторы (математических выражениях) бит с самым низким индексом считается первым.

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

Diveemo может иметь ряд "устройств доступа" с аудио, видео, и, возможно, другим содержанием в подканале MSC. Этот подканал MSC настроен для выполнения услуг данных в «потоковом режиме», т.е. не используя режим DRM пакетов. Все устройства доступа, принадлежащие к одному виртуальному потоку данных (например, все, имеющие видео данные), отмечены виртуальным идентификатором потока, который называется "Тип AU". Устройства доступа с одинаковым типом AU передаются в MSC подканале в порядке их представлении. Устройства доступа с разными типами AU передаются в MSC подканале в чередующейся форме, например, так что, устройства доступа, охватывающие одно и то же время представления, переносятся сгруппированными, насколько это возможно. По желанию нагрузка полезных данных в раздел полезных данных и вся информация заголовков защищена от ошибок передачи форвардной коррекцией ошибок (FEC) на основе алгоритма Рида-Соломона алгоритма. Это похоже на спецификацию расширенного пакетного режима пакетного режима DRM, чтобы повторно использовать декодер RS, а также виртуальные перемежения. Структура DRM сигнализации, на которой Diveemo базируется, уже дает следующие возможности:

До 4 DRM услуг, определенных в FAC (Fast Access Channel); DRM службы являются виртуальными пунктами, представленными пользователю на выбор, каждая DRM служба имеет аудио тип (плюс дополнительный компонент услуги данных - PAD, программа связанных данных) или отдельная услуга данных

MSC (Main Channel Service) передает фактические битовые потоки в до 4 потоках MSC, каждый поток MSC имеет один компонент услуги постоянного битрейта (аудио или Diveemo содержание), или до 4 сервисных компонентов в пакетном режиме

Защита MSC потоков может быть выбрана из до 2-х уровней защиты / кода (как определяется в мультиплексе DRM), ЕЕР (Equal Error Protection) назначает один из них потоку MSC, UEP использует оба на один поток MSC (с более защищенными байтами в начале каждого кадра передачи)

SDC (Service Description Channel) передает описательную информацию для служб DRM (например, этикетки, язык, страна происхождения и т.д.) и общую сигнальную информацию (альтернативные частоты, текущая дата / время и т.д.), он также несет объекты, описывающие кодирование аудио (объект 9) и данные (объект 5) компонентов служб, последние могут быть использованы для Diveemo

Структура транспорта MSC данных, на которой Diveemo основан, имеет следующие особенности:

Структура кадра передачи (TF) и супер кадра передачи (TSF) с постоянным битрейтом потока данных для Diveemo;

DRM30: TF=400 мс; TSF=1200 мс

DRM+: TF=100 мс; TSF=400 мс

TF в TSF обозначен: DRM30: 0-3; DRM+0-4;

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

Структура кадра

Далее описывается, как для передачи Diveemo информации в MSC подканал DRM ETSI ES 201 980 V3.1.1: Digital Radio Mondiale, спецификация системы. DRM логический кадр содержит данные для 100 мс (DRM режим A-D) или 400 мс (DRM режим Е), равные транслируемому сигналу, соответственно. Если DRM логический кадр несет Diveemo информацию, он называется Diveemo логический кадр.

Структура Diveemo логического кадра 20 показана на рисунке 5. Она включает в себя обязательный заголовок LF 22, избыточность информации Рида-Соломона в разделе дополнительных данных RS 66, обязательный раздел полезных данных 24, а затем дополнительный раздел расширения 68, и таблицу AU в конце 70.

Раздел полезных данных 24 содержит полезную информацию (например, аудио и видео информацию) в виде устройства доступа 28. Каждое устройство доступа 28 описывает содержание, которое охватывает определенное время представления. Оно прямо следует за предыдущим устройством доступа в разделе полезных данных 24 и образует непрерывный поток байтов. Этот байтовый поток 14 информации устройства доступа разделен на блоки данных. Эти блоки данных затем помещаются в раздел полезных данных 24 последовательных логических Diveemo кадров 20. Поэтому устройство доступа 28 может начинаться в любой точке раздела полезных данных 24, и может занимать несколько разделов полезных данных 26 последовательных логических кадров 20.

Для каждого старта устройства доступа 32, начинающегося в разделе полезных данных 24 текущего Diveemo логического кадра 20, раздел таблицы AU 30 несет одну запись таблицы AU 64. Эти записи таблицы AU 64 упорядочены таким образом, чтобы "запись 0 таблицы AU", описывающая первое устройство доступа, начиная с этого раздела полезных данных 24, осуществляется в конце раздела таблицы AU 36, "запись 1 таблицы AU", описывающая второе устройство доступа, начиная с этого раздела полезных данных 24, осуществляется перед "записью 0 таблицы AU", и т.д.

Заголовок LF 22 состоит из следующих бит - описанных в порядке их передачи:

1 бит: флаг расширения

7 бит: количество записей таблицы AU

8 бит: CRC рассчитывается из первого байта заголовка LF, то есть по числу записей в AU таблице.

Данные RS 66 являются блоком избыточности информации Рида-Соломона, как описано ниже. Естественно, другой код избыточности, например, систематический код избыточности, может быть использован для защиты LF и размещен в разделе 66, соответственно.

Каждая запись в AU таблице состоит из следующих бит - описанных в порядке их передачи, то есть слева направо на фиг.5:

3 бит: AU поток ID ("виртуальный идентификатор потока"), он принимает значения от 0-7; "7" может быть зарезервировано для проведения заполнения данными; эти биты не являются обязательными и могут быть прерваны в соответствии с альтернативным вариантом использования.

1 бит: Флаг содержания; если содержанием является тип видео: I-кадр флаг, в противном случае: RFA. Этот бит может быть пропущен в соответствии с другим вариантом использования.

12 бит: AU смещение 40 (абсолютное значение индекса, 0, указывающее на первый байт Diveemo логического кадра 20). AU смещение, таким образом, соответствует вышеупомянутому указателю 40, измеренному от ведущего конца текущего логического кадра 20 в байтах. Количество бит, т.е. 12, может изменяться в соответствии с другим вариантом, используя, например, более короткие логические кадры, и дополнительно или в качестве альтернативы, AU смещение может измерять длину указателя 40 в единицах, отличных от байтов.

16 бит: Длина AU. Длина AU, таким образом, соответствует вышеупомянутой длине 62. Опять же, количество бит, т.е. 16, зависит от приложения и может изменяться в соответствии с альтернативным вариантом. Дополнительно или альтернативно, длина AU может измерять длину соответствующих AU в единицах, отличных от байтов, и даже точка регистрации может быть выбрана по-иному так, чтобы она указывала на конец соответствующего AU не так, как указано выше.

16 бит: AU временная метка (см. детальное описание времени ниже). Эта информация в записи таблицы AU 64 также является не обязательной и может отсутствовать в соответствии с другими вариантами.

16 бит: AU CRC. AU CRC рассчитывается из байт "AU длины" содержания устройства доступа. Таким образом, AU CRC уже было упомянуто выше, а именно в качестве второй избыточности данных, оно позволяет обнаруживать повреждения данных в содержании AU, связанное с соответствующей записью в AUT. Опять же, количество бит не является обязательным и может быть изменено.

8 бит: CRC записи таблицы AU рассчитывается за первые 8 байтов этой записи AU таблицы, то из AU потока ID, AU флага содержимого, AU смещения, AU длины, AU временной метки и AU CRC. CRC записи таблицы AU уже было приведено выше в качестве первой избыточности данных, рассчитанной из указания длины, указывающего длину 62, указателя 40, а также при необходимости, второй избыточности данных. Здесь, CRC записи таблицы AU также защищает дополнительную информацию в записи таблицы AU. Это, конечно, является необязательным. Это также верно и для числа битов, потраченных на CRC записи таблицы AU.

Если флаг повышение установлен на 1, есть раздел повышения 68, вставленный непосредственно перед таблицей AU 30. В противном случае, это не так. Раздел повышения 68 может быть использован для расширения в будущем, то есть для будущих функций. Раздел повышения 68 имеет следующий формат и состоит из следующих бит, описанных в порядке их передачи: п х 8 бит: данные раздела повышения

8 бит: CRC, рассчитываемый из последнего байта раздела повышения

8 бит: длина "N" данных раздела повышения

Отметим, что статическая информация передается в конце раздела повышения 68, таким образом, что длина раздела повышения 68 может быть получена на стороне декодера и восстановителем потока устройства доступа 54, соответственно, начиная с известной границы 26 раздела таблицы AU 30.

Таким образом, препаратор 16 устанавливает, в соответствии с воплощением Diveemo, описываемым сейчас, вышеупомянутые биты в заголовке LF 22, записи таблицы AU 64 и другие биты логического кадра, как обозначено выше, используя, например, процесс, показанный на фиг.4.

По желанию, содержание Diveemo логического кадра или даже нескольких последовательных LF вместе могут быть защищены форвардной коррекцией ошибок Рида-Соломона (FEC). Чтобы вычислить код Рида-Соломона, избыточность информации 66 рассчитывается по разделу заголовка LF 22, разделу полезных данных 24, разделу повышения 68 (если имеется) и таблице информации 30 (если имеется). Для повышения надежности схемы FEC, эти входные данные для алгоритма Рида-Соломона практически чередуются, как описано ниже, то есть препаратор 16 рассчитывает избыточность данных 66 систематического кода RS, практически чередуя вышеупомянутые данные логического кадра 20, но посылает логический кадр в нечередующемся формате, а восстановитель потока устройства доступа 54 проверяет или не проверяет правильность, и исправляет информацию в полученном логическом кадре, полученную в правильном порядке, де-чередуя соответствующий раздел полученного логического кадра, и проверить таким образом чередование логического кадра с помощью избыточности данных 66.

Схема FEC может быть применена на основе каждого отдельного Diveemo логического кадра 20 или на основе супер кадра передачи DRM, охватывающего 3 (DRM режим A-D) или 4 (DRM режим Е) Diveemo логических кадра 20 соответственно. Включена или нет FEC защита, точная конфигурация схемы FEC может быть определена путем применения конкретных данных, передаваемых в SDC объектом данных типа 5 DRM. Алгоритм Рида-Соломона может быть определен RS (255, 239, 8), т.е. создавая 16 избыточность информации байтов на 239 содержания.

Схема на фиг.6 отображает подход виртуального чередования. То есть, для вышеупомянутого виртуального чередования препаратор потока устройства доступа 16 может вставить соответствующие вышеупомянутые LF данные, то есть все, кроме избыточности данных, например - в таблице данных приложения 98, столбцами по пути вставки 100, а восстановитель 54 эмулирует эту процедуру с полученными данными. Таблица данных приложения 98 и таблица данных RS 102 соприкасаются друг с другом столбцом. Препаратор 16 вычисляет данные RS в таблице данных RS 102 по строкам, то есть каждая строка сочетания таблиц 98 и 102 образует одно RS кодовое слово, и препаратор 16 затем читает биты из таблицы 102 по столбцам по пути 104 и заполняет раздел данных RS 66 в этом чередованном порядке. Восстановитель 54 отменяет чередование данных RS 66 при заполнении таблицы 102.

Следующие определения относятся к значениям R и С на фиг.6: R: количество строк в таблице виртуального чередования, допустимыми значениями которой являются, например, от 1 до 511.

С: неявно заданное значением R, так как количество байт, которые должны быть защищены в LF, известно

Величина R может быть сигнализирована в данных SDC объекта типа 14. Значение С можно рассчитать из таблицы данных приложения, которая должна быть достаточно большой, чтобы удерживать 1, 3 или 4 Diveemo логических кадра, как указано в SDC.

Число столбцов определяет служебные расходы FEC данных 66; чем меньше значение С, тем выше расходы. Число строк определяет глубину чередования и задержку блока, чем меньше значение R, тем меньше чередование и ниже задержка перед обработкой полученных данных.

Неявное заполнение может быть применено, если меньше данных передается, чтобы заполнить все клетки в таблицах 98 и 102, соответственно DRM сигнализации

Служба Diveemo может быть сигнализирована в быстром канале доступа (FAC) со значением идентификатора приложения "27 10" (5 бит). Объект данных SDC 5 может иметь следующую структуру:

1 бит: РМ флаг: 0 (DRM потоковый режим)

3 бита: rfa

1 бит: флаг расширения

3 бит: область приложения: 0×00 (DRM приложение)

16 бит: Приложение ID: 0×5456 (ASCII для "TV")

m×8 бит: Данные приложения (см. ниже)

Формат объекта данных SDC 5: Раздел данных приложения:

2 бит: Основная версия, в настоящее время значение 0

3 бит: Второстепенная версия, в настоящее время значение 0

1 бит: FEC флаг (включен: 1; FEC не используется: 0)

1 бит: Флаг супер кадра (FEC рассчитывается из Diveemo логического кадра: 0; из 3 или 4 LF, то есть один DRM супер кадр передачи: 1)

9 бит: Количество строк для виртуального чередования (0…511; 0, только если флаг FEC=0)

n×8bits: один или более блоков конфигурации AU (см. ниже)

Каждый блок конфигурации AU:

5 бит: Длина блока конфигурации в байтах

3 бит: AU поток ID (свободно выбирается для идентификации виртуального потока устройств доступа, несущих тот же тип контента, он может принимать значения от 0-7, а "7" предназначено для проведения заполнений данных)

3 бит: Тип содержимого (0: видео, 1: аудио, другие значения: rfa)

5 бит: Кодек ID (см. ниже)

n×8 бит: Конкретные конфигурации кодека (см. ниже)

Конкретные конфигурации кодека для НЕ AAC v2 с дополнительными аудио MPS, кодек ID 0×00 (тип содержимого 1)

1 бит: SBR флаг

2 бит: режим аудио (см. системы DRM)

3 бит: частота дискретизации звука (см. системы DRM)

2 бит: MPEG Surround (0: нет, 1: 5.1, 2: 7.1, 3: в группе)

Конкретные конфигурации кодека для H.264/AVC видео, кодек ID 0×00: (тип содержимого 0)

2 бит: пропорции (0: 4:3,1: 16: 9, другие значения: rfa)

11 бит: количество пикселей по горизонтали в кадре

11 бит: количество пикселей по вертикали в кадре

8 бит: число кадров в секунду в l/4th шага.

Естественно, только проработанные варианты использования являются просто иллюстративными, другие коды и значения могут быть использованы в будущем.

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

Возможные соображения / основы для определения Diveemo состояли в том, что сигнализация может быть выполнена как объектом SDC 5 (новое приложение данных типа Diveemo) и что, передача осуществляется как синхронный поток данных. Следующие ограничения должны быть соблюдены: фиксированная длина кадра 400 мс (DRM 30) /100 мс (DRM+), и фиксированный байт / кадр (бит) в диапазоне: DRM30: 1..3598 bpf (71.960 bps) или DRM+: 1..2325 bpf (186.000 bps).

Следующие ограничения / требования в определении формата содержания должны быть выполнены: переменное и динамическое назначение аудио / видео битрейта внутри канала; некоторое минимальное требование буферизации, аудио и видео декодер должен принимать любой гибкий размер устройства доступа (битрейт эквивалент); видео декодер должен быть в состоянии справиться "любой" (динамической) скоростью кадров в секунду, то есть кодер может приспосабливаться к содержанию динамически, видео декодер должен быть в состоянии обрабатывать отсутствующие кадры, так что в 1-кадрах можно использовать сплайсинг (перемещение в независимое AU); временная отметка должна быть указана в AU (счетчик переполнения относительно общих базовых часов).

Форматы, которые могут быть использованы для видео содержания в AU, это AVC/H.264 для видео и НЕ-ААС v.2 (+Surround) или будущий MPEG стандарт USAC ("Единый кодек речи и аудио") для аудио. Новые / более эффективные кодеки позже возможны.

Сумма задержки доступа при применении Diveemo к DRM может быть обусловлена следующими факторами: задержка приема DRM (FAC / SDC декодирование, MSC чередование и т.д.), Diveemo FEC (чередование) (опционально), размер GoP (чтобы получать первые I-кадры) видео кодека.

Кроме того, видео параметрами, которые следует учитывать при передаче видео через Diveemo, являются: I-кадры занимают до 50% от битрейта (критично для ошибок получения), только форвардное прогнозирование должно быть использовано по причине обеспечения устойчивости, и частота кадров является динамично адоптируемой (по кодеру).

Что касается вышеупомянутых отметок времени, следующие соображения должны быть рассмотрены: общая база часов для аудио и видео должна быть использована, основные часы с зернистостью в 1 мс кажутся хорошим компромиссом, так что макс, дрожание в 1/3 мс с характерной частотой кадров (например, 15 кадров в секунду); 16 бит счетчика часов на AU должно хватить (около 65 сек за круг).

Задержка начала представления, с которой сталкивается приемник Diveemo, это: макс.1xGoP продолжительность (настроена после первых битов i-кадра)+1x GoP продолжительность (передача последующего i-кадра).

Кроме того, при реализации описанного ниже Diveemo варианта необходимо учитывать следующее: на начальной синхронизации приемнику придется ждать запись заголовка Diveemo с активным флагом i-кадра (→ первое видео AU из GoP и соответствующий аудио AU). Чтобы добавить избыточность, заголовки Diveemo могут быть отражены в конце MSC-LF. Либо полностью, чтобы приемник мог исправить испорченные записи путем сравнения двух экземплярах, или только первый байт заголовка Diveemo+CRC, включая первый байта каждой записи в конце MSC-LF. Каждая AU может быть определена по идентификатору потока AU. AU поток ID 7 может быть использован для описания виртуальных данных AU, несущих байты заполнения в непрерывном потоке содержания AU. Значение отметки времени в AU может быть основано на 1 мс детализации (т.е. 16, охватывающих 65 секунд), как упоминалось выше.

Различные схемы Diveemo декодирования описаны со ссылкой на фиг.7а до 7m. Diveemo декодирование, описанное на этих рисунках, может быть выполнено восстановителем 54. На фиг.7а-7 т декодирование разделено на два типа. Во-первых, описывается декодирование "Diveemo логических кадров", которое кратко называется DLF декодирование. Во-вторых, описывается "Diveemo супер кадр" декодирование, которое кратко называется DSF декодирование.

В DLF декодировании один логический кадр (LF) буферизируется до того, как фактическое декодирование начинается, когда FEC осуществляется на LF. В DSF декодировании, в зависимости от стандарта, три или четыре последовательных логических кадра буферизируются до начала фактического декодирования, когда FEC осуществляется в течение трех или четырех логических кадров.

Во-первых, восстановитель потока устройства доступа 54 должен прочитать некоторые SDC параметры, т.е. параметры бокового канала сигнала передачи 38, такие как флаг FEC (FECF), указывающий, являются ли все логические кадры защищенными FEC, и флаг супер кадра (SFF), указывающий, являются ли логические кадры объединенными в супер кадры, в этом случае используется DSF декодирование, количество строк в виртуальном чередовании, а именно R, как уже обозначено выше, и тому подобное. Исходя из этих параметров, восстановитель потока устройства доступа 54 начинает процесс декодирования, который в дальнейшем описано со ссылкой на фиг.7а-7 т.

Как показано на фиг.7а, восстановитель 54 с перерывами, то есть каждый LF в DLF, и каждый SF в DSF, совершает все шаги, начала которых показаны на фиг.7а. В этом начале, восстановителю 54 известно о информации бокового канала сигнала передачи 38, а именно его части SDC, а именно о SDC параметрах FECF, SFF и R, как показано на 150. Процесс начинается, когда восстановитель 54 проверяет на шаге 152, сигнализирует ли FECF, что используется или нет защита FEC. Если да, то препаратор 16 встроил логические кадры 20 в транспортные пакеты с данными FEC 66 для защиты содержимого логических кадров. Если используется группировка супер кадра, код FEC потока транспортного уровня определяется в течение последующих трех или четырех логических кадров, как описано выше. Если FECF включен, декодирование с FEC происходит на 154, в противном случае декодирование без FEC происходит на шаге 156. Подробнее о шагах 154 и 156 рассказано со ссылками на фиг.7b и фиг.7i, соответственно.

Декодирование без FEC в шаге 156 показано более подробно на фиг.7b. Процесс декодирования логического кадра без FEC в процессе 154 начинается с априорной информации, известной из декодирования предыдущего логического кадра, как показано на 158. Эта информация называется CAUB. Информация CAUB это структура, состоящая из переменных, которые помогают восстановителю 54 в декодировании, по мимо всего прочего, CAU, то есть переноса AU, то есть начало устройство доступа 32 которого попадает на логический кадр 20, предшествующий логическому кадру 20, который находится на рассмотрении в настоящее время. Следующие сокращения используются в дальнейшем описании и являются известными из информации CAUB:

AU: Устройство доступа, в дальнейшем аббревиатура AU используется для обозначения AU, начала которых приходится на текущий LF, в отличие от CAU.

CAU: Перенос AU;

CAUF: Флаг CAU, то есть флаг, указывающий на наличие или отсутствие переноса AU, которое простирается до текущего LF.

PCAUB: Частичные CAU, обозначающие байты CAU, предшествующие границе между текущим LF и предыдущим LF, то есть байты CAU, которые уже прочитаны.

LPCAUB: Длина PCAUB, т.е. количество байт, или длина PCAUB

CAUSID: ID потока CAU, то есть значение ID потока AU в CAU.

CAUL: Длина CAU, т.е. длина CAU, т.е. длина 62 на фиг.1, указанная указателем длины соответствующей записи таблицы устройства доступа в предыдущем логическом кадре.

CAUCB: биты CAUCRC, т.е. биты CRC для того, чтобы сделать возможным форвардное обнаружение в CAU, передаваемое в вышеуказанном разделе повышения.

Другие значения тоже могут входить в информацию CAUB, например, тип AU содержимого, AU временная отметка, значение флага повышения в LF и т.д.

Пока шаги на фиг.7b выполняются восстановителем 54, CAUB информация остается статичной.

На шаге 160 восстановитель потока устройства доступа 54 читает следующий логический кадр, то есть текущий логический кадр, во внутреннем буфере восстановителя 54, не показанного на на фиг.3. На следующем этапе, а именно шаге 162, восстановитель 54 декодирует этот логический кадр 20 в устройствах доступа, этот шаг более подробно далее описан на фиг.7с. Затем восстановитель потока устройства доступа 54 буферизирует таким образом декодированные устройства доступа на шаге 164 и обновляет CAUB информацию в шаге 166, чтобы начать обработку снова на шаге 158.

Процесс декодирования текущего логического кадра в устройствах доступа, а именно, шаг 162 начинается, как показано на фиг.7с, если восстановитель 54 знает две вещи, а именно LF байты, т.е. байты текущего логического кадра, и CAUB информацию. Количество байт логических кадров 20 либо фиксировано, либо указано по-другому, так, что оно изменяется с помощью соответствующей боковой информации, сигнализирующей в вышеупомянутом отдельном канале боковой информации сигнала передачи 38. В шаге 170 восстановитель 54 читает заголовок LF и его CRC. В шаге 172 восстановитель 54 проверяет CRC, соответствует ли он информации заголовка LF, то есть флаг повышения, а также число записей таблицы устройства доступа, содержащихся в заголовке 22 логического кадра. Если CRC не совпадает на шаге 172, восстановитель проверяет на шаге 174, есть ли там CAU, то есть восстановитель 54 проверяет внутренний флаг CAU, указывает ли он на то, что есть устройство доступа 28, начало которого 32 заключается в любом из предыдущих кадров, в то время как конец этого устройства доступа до сих пор не достигнут. Если это так, то восстановитель 54 выполняет на шаге 176 декодирование байтов CAU. Шаг 176 далее объяснен на фиг.7е. Если, однако, оказывается, что флаг CAU не включен на шаге 174, восстановитель 54 переходит к шагу 178, где текущий логический кадр отбрасывается, или, более предпочтительно, и этот случай рассматривается здесь, подвергается тестированию записей таблицы AU декодированию и байтов Аи, путем поиска нужных AUT записей, оценив CRC записи таблицы AU, после чего процесс возвращается обратно к шагу 158 на фиг.7b. Шаг 178 соответствует объединению разделов обработки на фиг.7f-7g. Аналогично, как указано пунктирными линиями, хотя использование LF может остановиться после шага 176, также возможно, что восстановитель 54 продолжит после шага 176 пытаться восстановить столько AUT записей, сколько возможно из априорного неизвестного (в связи с повреждением заголовка LF) числа действительно присутствующих AUT записей.

Если, однако, проверка CRC в шаге 172 приводит к обнаружению соответствия между информацией CRC и информацией заголовка LF, восстановитель 54 продолжает пытаться извлечь информацию из следующих частей текущего логического кадра. В частности, как указано на 180, если CRC соответствует на шаге 172, восстановитель 54 дополнительно использует по крайней мере две единицы информации, представленные в правильно переданном заголовке 22 логического кадра текущего логического кадра 20, а именно количество записей таблицы устройства доступа таблицы устройства доступа текущего логического кадра, а также знание о значении флага повышения EF. Согласно знанию количества записей таблицы устройства доступа в таблице устройства доступа текущего логического кадра, восстановитель 54 может получить TAUB, т.е. общее количество байт устройства доступа. Согласно знанию EF восстановитель 54 знает о существовании или отсутствии вышеупомянутого раздела повышения 68. В частности, в шаге 182 восстановитель 54 рассчитывает TAUB путем умножения количества записей таблицы устройства доступа, представленных в заголовке 22 логического кадра, с постоянной длиной, общей для всех записей таблицы устройства доступа. После этого, на шаге 184 восстановитель 54 декодирует байты в разделе полезных данных 24 текущего логического кадра, процедура чего описана более подробно в связи с фиг.7d.

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

а) LF заголовок правильно декодируется и, соответственно, устройства доступа будут декодироваться

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

в) LF заголовок не декодируется и, соответственно, устройства доступа не могут быть декодированы, но попытка выяснить действительные записи AUT может быть предпринята. Кроме того, CAU также нет и, следовательно, не будет декодировано.

Декодирование байтов приложения LF в разделе полезных данных 24 описывается далее со ссылкой на фиг.7d. При входе в раздел этого процесса, восстановитель 54 знает о байтах LF, т.е. байтах логического кадра, информации CAUB, EF, TAUE, то есть общем количестве записей таблицы устройства доступа, и TAUB, т.е. общем количестве байт таблицы устройства доступа, как показано на 186. Восстановитель 54 проверяет на шаге 188 CAUF, чтобы проверить, существует ли CAU или нет. Если да, то восстановитель 54 декодирует на шаге 190 байты CAU в текущем LF, шаг, который описан ниже со ссылкой на фиг.7е. После шагов 188 или 190 восстановитель 54 переходит к шагу 192, чтобы проверить TAUE, является ли число записей таблицы устройства доступа равным нулю или нет. Если это число равно нулю, то есть нет таблицы устройства доступа в текущем логическом кадр, процесс на фиг.7е заканчивается. Если нет, восстановитель 54 декодирует на шаге 194 записи таблицы AU и декодирует на шаге 196 байты устройства доступа из раздела полезных данных LF. Шаг 194 далее описан со ссылкой на фиг.7f, и шаг 196 в связи с фиг.7g. В конце этой части процесса на фиг.7d восстановитель 54 обладает знаниями о обновленной CAUB информации и имеет буферные версии устройств доступа, как показано на 198.

Таким образом, часть процесса на фиг.7d относится к следующим случаям, которые могут возникнуть:

а) AU данные в разделе полезных данных 24 логического кадра содержит и CAU, и AU,

б) AU данные в разделе полезных данных 24 текущего логического кадра содержит только CAU, или

с) AU данные в разделе полезных данных текущего логического кадра содержит только AU.

Далее, декодирование байтов CAU на шагах 176 и 190 описано более подробно со ссылкой на фиг.7е. В начале этой части процесса восстановитель 54 уже обладает знанием о байтах LF, т.е. количество байтов в текущем логическом кадре, и CAUB информация, как показано на 200. Вначале восстановитель 54 начинает читать CAU данные на шаге 202. Восстановитель 54 способен найти начало раздела полезных данных 24 текущего логического кадра, из которого начинается чтение в шаге 202, так как эта отправная точка постоянна во времени для логических кадров из-за постоянной длины заголовка 22 логического кадра и знания о существовании (см. FECF) и его постоянной длины, дополнительного раздела данных FEC 66. В частности, на шаге 202 восстановитель 54 пытается прочитать как можно больше бит с начала раздела полезных данных 24 текущего логического кадров, относящегося к CAU, то есть устройство доступа распространяется на текущий логический кадр из предыдущего логического кадра. Возможны два случая. Во-первых, восстановитель 54 может столкнуться с концом CAU до конца раздела полезных данных текущего логического кадра. Во-вторых, восстановитель 54 может столкнуться с концом раздела полезных данных 24 текущего логического кадра до конца CAU. Восстановитель 54 в состоянии спрогнозировать ситуацию на основе двух информации, а именно CAUL, т.е. длины CAU, известной из всех предыдущих логические кадров, в частности соответствующая запись таблицы устройства доступа соответствующей таблицы устройства доступа, а количество байт логического кадра наряду со знанием о существовании или отсутствии раздела повышения 68 (см. флаг повышения) и о длине этого раздела 68, выводимой из заданного расположения в этом разделе, выявляющей длину раздела 68, зарегистрированную по отношению к AUT, так как эта информация также определяет максимальное количество байт, доступных для логического кадра в случае отсутствия таблицы устройства доступа. После прочтения CAU бит, то есть части раздела полезных данных 24 от начала этой части, восстановитель 54 обновляет на шаге 204 внутреннее состояние LPCAU, то есть длины части CAU, уже извлеченной из последовательности логических кадров. В шаге 206 восстановитель 54 проверяет, является ли LPCAU равным CAUL, то есть извлечена ли вся CAU из последовательности логических кадров. Если нет, то CAU продолжает распространяться на следующий логический кадр и восстановитель 54 обновляет в шагах 208 PCAUB и LPCAUB в CAUB информацию, соответственно, то есть обновляет информацию части CAU, уже извлеченной из последовательности логических кадров, включая текущий логический кадр. Однако, если проверка на шаге 206 показывает, что CAU была получена из последовательности логических кадров до конца, т.е. конец CAU попадает на раздел полезных данных 24 текущего логического кадра, восстановитель 54 проверяет на шаге 210, является ли CRC информация CAU выводимой из соответствующей записи таблицы AU 64 внутри логического кадра, в котором начинается 32 CAU, сопоставляет CAU биты, извлеченные и буферизованные в CAU. Если это так, то восстановитель 54 буферизирует декодированный блок CAU на шаге 212 и сбрасывает на шаге 214 параметры в CAUB информации, в той мере, чтобы CAU не было в настоящее время. Если, однако, проверка CRC в шаге 210 показывает, что CAU биты, полученные из последовательности логических кадров повреждены, восстановитель 54 отбрасывает это устройства доступа CAU на шаге 216 и переходит к шагу 214, где эта часть процесса на фиг.7е заканчивается. Кроме того, восстановитель 54 может отметить CAU в шаге 216 как ошибочное и передать то же на представитель 56, который, в свою очередь, может быть сконфигурирован для получения полезного содержания из ошибочных AU другими средствами, такими как AU внутренние FEC или CRC данными и т.п., или просто успешно разобрав AU, ошибочно помеченное как ошибочное из-за повреждения CAUCRC. Таким образом, на фиг.7е рассмотрены три разных случая, а именно:

а) CAU начинается в предыдущем логическом кадре, имеющем, например, число LF п, и заканчивается в текущем логическом кадре, имеющем, например, число n+1, где CAUCRC совпадает с байтом CAU, т.е. байт CAU был уже правильно извлечен из последовательности логических кадров.

б) CAU начинается в любом из предыдущих логических кадров, например, логическом кадре, имеющем число п, и заканчивается в текущем логическом кадре, имеющем, например, число п+1, где CAUCRC не совпадает с байтом CAU, т.е. байты, уже извлеченные для CAU или CAUCRC, повреждены.

в) CAU начинается в любом из предыдущих логических кадров, например, логическом кадре, имеющем число логического кадра п, но эта CAU распространяется за пределы текущего логического кадра, имеющего, например, LF номер N+1, и простирается в и, возможно, заканчивается в следующем логическом кадре, имеющем, например, номер LF п+2 логического кадра.

Часть процесса декодирования записей таблицы устройства доступа в шаге 194 и инспектирование части LF, потенциально соответствующей допустимым значениям AUT записей на шаге 178, обсуждается более подробно далее со ссылкой на фиг.7f. При входе в эту часть процесса из шага 194 восстановитель 54 знает о TAUE, т.е. количестве записей таблицы устройства доступа в текущем логическом кадре, и LF байт, т.е. байт текущего логического кадра, как показано на 218. При входе в эту часть процесса из шага 178 восстановитель 54 не знает о TAUE, и восстановитель 54 может устанавливать TAUE на максимально возможное число записей таблицы устройства доступа в логическом кадре, который в данном случае (из-за того, что заголовок FL тратит только постоянное количество - здесь например 7 - бит для указания на количество записей AUT) 128.

В рамках части этого процесса на фиг.7f восстановитель 54 начинает на шаге 220 инициализацию внутреннего значения счета, а именно RAUE, т.е. количество оставшихся записей устройства доступа, до равенства с равную TAUE, общим количеством записей устройства доступа. Конечно, можно посчитать обработанные записи, считая значения счета начиная с единицы, а не уменьшая значение счета.

После проверки на шаге 222, является ли RAUE равным нулю, то есть нет ли оставшихся записей таблицы устройства доступа для прочтения, процесс переходит к шагу 224 в случае, если остались записи таблицы устройства доступа для прочтения в текущем логическом кадре и его таблице устройства доступа, соответственно, где восстановитель 54 читает AUTEB, т.е. байты, соответствующей записи таблицы устройства доступа в очереди, и AUTECB, т.е. соответствующие CRC биты записей таблицы устройства. Как уже было описано выше, порядок, в котором восстановитель 54 обращается к записи таблицы устройства доступа 64 может начинаться от заднего конца 70 в направлении ведущего конца 72 логического кадра, соответственно порядку устройства доступа, начало 32 которого указывается в этих записях таблицы устройства доступа 64. После шага 224 восстановитель 54 проверяет на шаге 226 CRC записи таблицы устройства доступа, только что прочитанного в шаге 224, чтобы проверить, являются ли данные записи таблицы устройства доступа, извлеченными из текущего логического кадра, поврежденными или нет. Если это так, то есть если данные повреждены, восстановитель 54 сбрасывает соответствующую запись таблицы устройства доступа 64 и устанавливает соответствующий флаг, указывающий на отбрасывание на шаге 228. Кроме того, восстановитель 54 может попытаться хотя бы частично воссоздать недостоверную информацию с помощью других средств. Например, восстановитель 54 может попытаться предсказать смещение AU от AU длины или наоборот (если, например, есть бесшовная вставка раздела полезных данных 24, и повторить проверку CRC с соответствующей предсказанной частью записи таблицы AU, замененной на предсказанный результат. Таким образом, восстановитель 54 может получить, несмотря на повреждение данных, правильную запись таблицы AU, соответствующую соответствующей CRC.

Если CRC для текущей записи таблицы устройства доступа 64 совпадает с соответствующими данными, восстановитель 54 интерпретирует на шаге 230 текущую запись таблицы устройства доступа 64 и сохраняет ее. Следует подчеркнуть, что случай совпадения CRC является свидетельством того, что восстановитель 54 только что нашел действительную запись AUT 64. Другими словами, при выполнении шага 226 и войдя в часть процесса на фиг.If с шага 178, восстановитель 54 не знает заранее, является ли в настоящее время проверяемая часть LF - обнаруженная, используя тот факт, что таблица AU зарегистрирована в конце LF и записи таблицы AU расположены в постоянном поле -на самом деле частью раздела полезных данных 24 или раздела повышения 68, или AUT 30 соответственно. Восстановитель 54 может использовать CRC совпадение в качестве достаточного результата проверки, чтобы интерпретировать в настоящее время проверяемую часть LF как запись AUT 64. Кроме того, восстановитель 54 может выполнять дополнительные тесты, такие как проверку достоверности, в зависимости от чего текущий, возможная запись AUT считается действительной или недействительной, LF заголовок поврежден. Например, начало 32 AU только что найденной AUT записи 64 должно лежать после конца предыдущего AU и, наоборот, конец AU только что найденной AUT записи 64 должен лежать до конца последующего AU, и, соответственно, если любая из проверок достоверности показывает противоречие, текущая предполагаемая запись AUT отвергается и считается недействительной.

После шага 230 восстановитель 54 знает о начале 32 соответствующего устройства доступа, связанного с текущей записью таблицы устройства доступа 64, а также, при необходимости, о его длина 62. Что касается дальнейшего содержания записей таблицы устройства доступа 64, ссылаемся на вышеизложенное обсуждение таких дополнительных опций. Независимо от проверки совпадения CRC на шаге 226, восстановитель 54 уменьшается после любых шагов 228 и 230 в шаге 232 внутреннего счетчика состояния RAUE на один и возвращается обратно к шагу 222. Как только эта проверка 222 показывает, что количество оставшихся записей таблицы устройства доступа 64, которое нужно получить из таблицы устройства доступа 30 текущего логического кадра, равно нулю, то часть процесса на фиг.7f заканчивается, когда восстановитель 54 заполняет внутреннюю копию таблицы устройства доступа 30, т.е. структуру записи таблицы устройства доступа, как указано в шаге 234.

Другими словами, в часть процесса на фиг.7f входит восстановитель 54, если любая таблица устройства доступа существует в текущем логическом кадре, т.е. когда любая запись таблицы устройства доступа 64 существует, или для того, чтобы оценить, существуют ли любая AUT запись 64, потому что существование или отсутствие (и количество) записей AUT не известно. Вполне возможно, что CAU может занять весь логический кадр так, что в этом случае, например, восстановитель 54 не может вступить в часть процесса на фиг.7f. Далее представлены различные случаи в части процесса на фиг.7f:

а) текущая запись таблицы устройства доступа и ее CRC совпадают (и все проверки достоверности пройдены)

б) текущая запись таблицы устройства доступа и ее CRC не совпадают (или проверка достоверности не пройдена)

в) все записи таблицы устройства доступа - все записи, существующие, как известно из LF заголовка, или все возможные, лишь предположительно существующие, AUT записи (в связи с повреждением LF заголовка) - были обработаны независимо от того, соответствует или нет CRC (в случаях а и б), при этом условие в является условием выхода для этой части процесса на фиг.7f.

Следует отметить, что причиной, по которой восстановитель 54 умеет читать AUTEB и AUTECB независимо от любых предыдущих записей таблицы устройства доступа одной и той же таблицы устройства доступа текущего логического кадра, поврежденного или нет, является то, что все записи таблицы устройства доступа имеют одинаковый размер, и что таблица устройства доступа 30 зарегистрирована с ее задней частью к задней части 70 текущего логического кадра так, что восстановитель 54 может найти записи таблицы устройства доступа в любом случае. Такими являются альтернативы, уже говорилось выше.

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

Далее, в связи с фиг.7g, описаны детали декодирования байтов AU в шаге 196 или 178. При входе в этот раздел процесса восстановитель 54 знает следующую информацию: TAUE, то есть общее количество записей таблицы устройства доступа, AUE информацию, то есть содержание записей в таблице устройства доступа текущего логического кадра, а также предыдущих логических кадров, CAUB информацию, LF байты и TAUB, т.е. общее количество байт, доступных в разделе полезных данных 24 текущего логического кадра для устройства доступа 28, начало 32 которого приходится на текущий логический кадр, с готовыми знаниями, указанными на 236. 54 восстановитель знает о TAUB по следующим причинам: восстановителю 54 известно, что данные устройства доступа, касающиеся устройства доступа, начало которого приходится на текущий логический 20 кадр, простирается от начала 32 к ближайшему ведущему концу 72 логического кадра 20. Это соответствует позиции, на которую указывает указатель 40 записи таблицы устройства доступа 64, который был получен без повреждения данных в самое раннее время в части процесса на фиг.7f, или был получен, хотя и поврежденный подкупа по FEC, как это описано далее по отношению к DSF или DLF декодированию. Конец раздела полезных данных 24 известен восстановителю 54 на основе информации в заголовке логического кадра, то есть количество записей таблицы устройства доступа 64 вместе с указанием (см. заголовок LF) о наличии или отсутствии раздела повышения 68, непосредственно примыкающий к AU таблице 30 и расположенный между разделом полезных данных 24 и таблицей устройства доступа 30, а также длина раздела 68, выводимая из байта в этом разделе, непосредственно примыкающие к - или, наоборот, с заданным смещением от - границе AUT 30 перед разделом 68. Если последняя информация не доступна, то есть ни число записей AUT, ни существование или отсутствие раздела 68, восстановитель 54 может ограничить TAUB для оценки суб-части раздела полезных данных 24, простирающийся от вышеупомянутого самого левого начала 32, указанного любой из допустимых найденных записей AUT и последнего, то есть самого правого начала 32, указанного любой из допустимых найденных записей AUT, так эта часть просто содержит не-CAUS. В начале этого части процесса на фиг.7g, восстановитель 54 инициализирует в шаге 238 два внутренних параметра, а именно RAU, то есть количество оставшихся устройств доступа, еще не обработанных в разделе процесса на фиг.7g, и RAUB, т.е. число оставшихся байтов AU, еще не прочитанных из раздела полезных данных 24 текущего логического кадра. Оба параметра равны TAU, то есть общее число устройств доступа, начало 32 которых приходится на текущий логический кадр, это количество известно из заголовка логического кадра, и TAUB, соответственно. На шаге 240 восстановитель 54 проверяет, является ли RAU равным нулю, то есть, есть ли устройства доступа, подлежащие обработке, начало 32 которых имеются в текущем логическом кадре. Если нет, то восстановитель 54 продолжает на шаге 242 чтение байтов текущего устройства доступа из раздела полезных данных 54 текущего логического кадра, с шагом который описан более подробно далее со ссылкой на фиг.7h. После этого восстановитель 54 проверяет в шаге 244, совпадает ли CRC, связанное с текущим устройством доступа, с данными текущего устройства доступа, прочитанными в шаге 242. Если это не так, то восстановитель 246 сбрасывает текущее устройство доступа в пункте 246, или, как уже говорилось выше, отмечает это AU как ошибочное и передает его для дальнейшей обработки / следа. Если, однако, CRC соответствует текущему устройству доступа, процесс на фиг.7g протекает, когда восстановитель 54 буферизирует текущее устройство доступа на шаге 248 для отправки их в текущие данные 56, например. После любых шагов 246 и 248, восстановитель 54 обновляет в шаге 250 внутренние состояния RAU и RAUB. В частности, RAU, то есть количество оставшихся устройств доступа, которые нужно обработать, уменьшается на один, a RAUB, т.е. количество байт устройства доступа, доступных в разделе полезных данных 24 обновляется, то есть уменьшается на количество байт, обрабатываемого в данный момент устройства доступа, или, и различается от этого, эта разница между задним концом раздела полезных данных 24 и началом 32 следующего устройства доступа, которое должно быть обработано. В качестве исключительной меры, восстановитель 54 может установить RAUB к нулю при встрече с концом раздела полезных данных 24.

После шага 250 процесс на фиг.7g возвращается к шагу 240 для обработки оставшихся устройств доступа, готовых к обработке и начинающихся в текущем логическом кадре. Как только регистрирующий шаг 240 приводит к тому, что RAU равен нулю или RAUB равен нулю, восстановитель 54 завершает часть процесса на фиг.7g, успешно получив устройства доступа в буфер, как это указано в шаге 252.

В связи с фиг.7 g следует отметить, что приведенное выше описание фиг.7g пренебрегает тем фактом, что некоторое количество - количество, максимально представленное, или количество, правильно переданное, LF заголовком - записи таблицы устройства доступа могут быть повреждены или нет, и, соответственно, соответствующий флаг может быть установлен в шаге 228 на фиг.7f. В приведенном выше описании фиг.7g, например, TAU возможно уже сократился на это число поврежденных записей таблицы устройства доступа, так что TAU просто означает количество устройств доступа, начала которых приходится на текущий логический кадр и для которых связанные записи таблицы устройства доступа были пригодные к использованию / допустимы. В описании части процесса на фиг.7g, опять же, можно выделить три случая, а именно:

а) повторно собранное AU содержание из раздела полезных данных 24 для текущего устройства доступа соответствует связанному CRC,

б) повторно собранное AU содержание из раздела полезных данных 24 для текущего устройства доступа не соответствует связанному CRC,

в) все обработанные AU и все данные в разделе полезных данных 24 были обработаны, что является условием выхода для части процесса на фиг.7g.

При входе в эту часть процесса восстановитель 54 может использовать следующую информацию, как показано на 254, а именно AUE информацию, CAUB информацию и RAUB. Во-первых, восстановитель 54 извлекает длину текущих устройств доступа в шаге 256 от связанной записи таблицы устройства доступа. В шаге 258 восстановитель 54 проверяет, является ли AUL, т.е. длина текущего устройства доступа, больше, чем RAUB, т.е. число оставшихся байтов в разделе полезных данных 24. Если ответом на вопрос 258 является да, то восстановитель 54 устанавливает в 260 параметры в CAUB информации соответственно. В частности, в шаге 260, восстановитель 54 устанавливает CAUF для того, чтобы показать, что есть, снова CAU, то есть устройство доступа распространяется на следующий логический кадр. LPCAUB обозначает число байт CAU, уже возвращенных из текущего логического кадра, то есть длина PCAUB. CAUL является длиной 62 CAU, и CAUC является CRC в CAU.

Если, однако, текущее устройство доступа вписывается в оставшуюся часть раздела полезных данных 24, восстановитель 54 читает на шаге 262 байты текущего устройства доступа до конца текущего устройства доступа, как указано ее длиной 62, т.е. AUL. После этого восстановитель 54 обновляет AU байты.

Таким образом, были выявлены следующие случаи на фиг.7h:

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

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

В связи с фиг.7i, часть процесса, выполняемого восстановителем 54, показана в том случае, когда флаг FEC оказывается включенным в проверке 152. Другими словами, фиг.7i иллюстрирует декодирование FEC в шаге 154. В этом случае восстановитель 54 имеет, как указано в 266, доступ к флагу SFF, LF байтам и R. В шаге 268 восстановитель 54 проверяет, включен ли SFF. Если это так, то восстановитель 54 переходит в шаге 270 к SF декодированию с FEC, а в противном случае в шаге 272 к LF декодированию с FEC. Первая часть процесса шага 272 показана на фиг.7j. Зная о CAUB информации, как показано на 274, восстановитель 54 читает один логический кадр во внутреннем буфере на шаге 276 и подвергает один логический кадр RS-FEC в шаге 278. Далее, этот логический кадр подлежит декодированию в устройстве доступа в шаге 280 так же, как делается в шаге 162, как описано в связи с фиг.7с. После этого декодированные устройства доступа буферизируются в шаге 282, и CAUB информация обновляется на 284.

То есть, в случае LF декодирования FEC, текущий логический кадр дополнительно проходит RS форвардную коррекцию / декодирование ошибок до фактического декодирования логического кадра в начале устройства доступа.

Прохождение логического кадра через RS-FEC в шаге 278 проиллюстрировано далее на фиг.7к. В частности, на основе знаний о LF байт и R, как показано на 286, восстановитель 54 устанавливает на шаге 288 смещение LF заголовка, смещение LFAU данных, RS смещение и RS паритетные биты=16+XR и заполняет, в шагах 290 и 292, таблицу RS приложение 98 и паритетную таблицу RS 102, соответственно. После проверки, является ли R равным нулю в шаге 294, восстановитель 54 осуществляет RS коррекцию ошибок на шаге 296, если это не так, и уменьшает R в шаге-298, после чего процесс возвращается обратно к шагу 294. Если проверка на шаге 294 показывает, что R равно нулю, байты приложение RS в таблице данных приложения 98 прочитаны в дечередованном смысле, чтобы получить LF байты в шаге 300. Если RS FEC успешно исправляет ряд R, то RS FEC может быть настроен для возвращения числа исправленных символов и обновляет ряд с исправленными байтами, а если это не удается, возвращает минус один и сохраняет ряд символов, как они есть. Однако, также возможны другие варианты осуществления. Кроме того, различные коды FEC могут быть использованы.

Фиг.71 показывает подробную информацию о SF декодировании FEC в шаге 270 фиг.7i. Как можно увидеть, зная CAUB информацию, как указано на 302, восстановитель 54 читает в шаге 304 три или четыре, или - в соответствии с альтернативным вариантом - любое другое число, последовательных логических кадров, то есть суперкадр, во внутренний буфер, и подвергает этот суперкадр SF в шаге 306 RS FEC в этой связи, декодированию трех / четырех логических кадров в SF в шаге 308 в AU, как описано в связи с фиг.7 с, и буферизации в шаге 310 декодированных устройств доступа. Наконец, восстановитель 54 обновляет CAUB на шаге 312. Как и на фиг.7к, фиг.7 т показывает случай подвергания SF для RS FEC. Как видно, имея доступ к трем / четырем или - просто п - логическим кадрам, то есть байтам логических кадров, и значение R, как показано на 314, восстановитель 54 выполняет настройки на шаге 316, заполняет таблицу RS приложения и RS паритетную таблицу в шагах 318 и 320, соответственно, и проверяет, является ли R равным нулю в шаге 322. Если нет, то восстановитель 54 осуществляет коррекцию RS ошибки на шаге 324, и уменьшает R на шаге 326 для того, чтобы возвратиться к шагу 322. Как только R равен нулю, восстановитель 54 располагает байты приложения RS байт из таблицы данных приложения 98 в формате с чередованием для получения п логических кадров в шаге 328.

Наконец, на фиг.8 и 9 показан обзор защиты переноса FEC, проводимой восстановителем 54 в соответствии с определенным дальнейшим воплощением. Согласно этому варианту воплощения, строится таблица из 100 строк и 36 столбцов, которая соответствует до 3600 байт. На самом деле LF содержит 3598 байт, однако она заполняется на стороне отправителя и получателя до 3600 байт для простоты. Все байты заполняются в этой таблице по столбцам в следующем виде (1,1), (2,1)…(100,1), (1,2), (2,2)…(10,100). Таким образом, очевидно придается чередование. В зависимости от колонн приложения и колонн FEC, определяется возможность коррекции Рида-Соломона FEC и используется для декодирования каждой строки таблицы. Так как мы не знаем местоположение ошибки в таблице, мы должны использовать декодирования ошибки RS. После того как таблица проходит через FEC декодер, на выходе могут или не могут содержаться совершенно безошибочные байты. В обоих случаях нормальное декодирование используется серийно, то есть сначала первый байт LF заголовка может быть декодирован, в соответствии с альтернативным вариантом, похожим на вышеописанный, дает нам размер LF заголовка, в случае успеха полный LF заголовок декодируется и сравниваются с CRC. LF заголовок рассматривается - в соответствии с настоящим воплощение - в составе AUT информации, и далее анализируется для отдельных Аи. Полная схема декодера показана на фиг.8 и 9.

Таким образом, воплощение Diveemo приносит следующие преимущества по следующим аспектам:

1. Способ и устройство для кодирования, передачи и декодирования видео сигналов с помощью DRM системы

- вне сигнализации полосы

- конфигурация доступа к данным в полосе

- по крайней мере один поток логических данных

- аудио / видео / данные (например, Journaline (R) для субтитров)

- например, 1х видео, 5х аудио (на разных языках)

- любые кодеки для аудио и видео кодируемы (обратная совместимость для будущего расширения)

- совместимость DRM (форматирование в MSC, SDC стандартах соответствия)

- эффективное использование скорости передачи данных (например, отсутствие стаффинга)

- гибкая настраиваемость (скорость кадров, битрейт, …)

- дополнительная защита от замыканий (FEC), гибкая параметризация, виртуальное чередование, двухразовый чередователь

- возможная быстрая синхронизация приемника

- структура данных позволяет будущие расширения

- устойчив к приему ошибки

2. Способ кодирования и сигнализации передачи видео сигналов с помощью цифровой системы Radio Mondiale

- аудио-, видео- и AU данные передаются без дополнительных заголовков, как "последовательный поток битов"

- определение AU и их границ / длин зарегистрировано в границах кадров передачи системы вещания (DRM) для обеспечения быстрого доступа и легкой (ре-) до синхронизации

- индекс передается избыточно в логическом кадре (LF)

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

- один или несколько потоков логических данных (с чередованием) разделены на пакеты данных различной длины

- быстрая синхронизация на нагруженные данные возможна

- используется структура передачи (прямой указатель)

- механизм для будущих расширений

- параметр FEC адаптируется к ошибкам передачи

- защита от ошибок в индексе и в пакетах данных позволяет извлечение всех безошибочных нагруженных данных

Подводя итог вышеописанным воплощениям, то есть воплощениям, описанным прежде всего на фиг.1-3, а также следующим вариантам, в том числе Diveemo вариантам, необходимо отметить, что одним преимуществом регистрации таблицы устройства доступа с ведущим / задним концом логических кадров является то, что таблицы быстро и надежно обнаруживаются декодером, и, хотя их длина зависит от числа начал устройств доступа в логических кадрах, начала вложения устройств доступа, т.е. начала раздела полезных данных могут держаться постоянными, так что, например, путем размещения таблицы устройства доступа в конце, когда она видима направлении ввода полезных данных. Указатели указывают на позиции начал устройства доступа в абсолютном смысле, так что местные ошибки в логическом кадре не мешают другим устройствам доступа, которые не имеют ошибок, для анализа и использования. Если таблица устройства доступа теряется, первое переносимое устройство доступа может быть завершено, даже если таблица устройства доступа расположена на ведущем конце, и если первое переносное устройство доступа повреждено, и, таким образом, обнаружение конца этого устройства доступа и начало следующего устройства доступа не обнаруживаются разбором, несмотря на бесшовную вставку, следующее устройство доступа может быть использовано - независимо от точного положения этой таблицы устройства доступа - потому что указатели в таблице устройства доступа определяются в абсолютном смысле, то есть с точки регистрации, которая является статичной.

Кроме того, поскольку таблица устройства доступа и заголовок логического кадра расположены, зарегистрировано к абсолютному началу или абсолютному концу логических кадров, или известному смещению оттуда, таблица устройства доступа и/или заголовок логического кадра просто и надежно обнаруживаются на стороне декодирования на основе кадров передачи. Даже если оба верно, заголовок логического кадра, а также таблица устройства доступа были зарегистрированы по отношению к тому же концу, например, ведущему или заднему концу логического кадра, раздел полезных данных логического кадра может находиться хотя бы один из заголовков логических кадров и таблица устройства доступа имеет постоянную длину, как и в других воплощениях. Размещая, однако, заголовок логического кадра и таблицу устройства доступа на противоположных сторонах, оптимальное использование устройств доступа возможно: если заголовок логического кадра повреждено, начало раздела полезных данных, тем не менее, можно обнаружить на стороне декодирования, и текущее устройство доступа может быть обработано. Если таблица устройств доступа повреждена, то конец раздела полезных данных известен на декодере и, возможно, все устройства доступа восстановимы при помощи парсинга.

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

Вышеизложенная возможность FEC защиты записей таблицы устройства доступа по отдельности позволяет обрабатывать устройства доступа по отдельности, даже если некоторые из записей таблицы устройства доступа повреждены. Таким образом, поврежденные записи в таблице устройства доступа могут быть пропущены из-за их постоянной длины, и последующие записи в таблице устройства доступа могут быть оценены без проблем восстановителем. Это преимущество индивидуальной защиты CRC. Кроме того, даже если число, или даже существование, записей AUT неизвестно, нужные записи можно выискать.

Многие изменения могут быть выполнены по вышеуказанным вариантам. Например, много альтернатив конкретных деталей в вариантах Diveemo легко выводимы из заявлений по отношению к фиг.1-3. Что касается RS FEC, отмечается, что другие коды FEC могут быть использованы. Кроме того, вместо CRC в LF, FEC данные могут быть включены в LF. Хотя некоторые аспекты уже были описаны в связи с устройством, ясно, что эти аспекты также представляют собой описание соответствующего способа, где блок или устройство соответствует шагу способа или особенностью шага способа. Аналогично, аспекты, описанные в контексте шага способа, также представляют собой описание соответствующего блока или элемента или функции соответствующего устройства. Некоторые или все шаги способа могут быть выполнены (или с помощью) такого устройства, как, например, микропроцессор, программируемый компьютер или электронная схема. В некоторых вариантах, один или несколько из самых важных шагов способа могут быть выполнены таким устройством.

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

В зависимости от требований определенных вариантов воплощения изобретения могут быть реализованы в виде устройств конструктивного обеспечения или программного обеспечения. Воплощение может быть осуществлено с помощью цифрового носителя, например дискеты, DVD, Blue-Ray, CD, ROM, PROM, EPROM, EEPROM или флэш-памяти, имеющего сохраненные на нем электронно-читаемые контролирующие сигналы, которые сотрудничают (или способны работать вместе) с программируемой компьютерной системой так, что соответствующий способ выполняется. Таким образом, цифровой носитель может быть прочитан компьютером.

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

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

Другие варианты включают компьютерную программу для выполнения одного из способов, описанных в данном документе, хранящуюся на машиночитаемом носителе.

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

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

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

Еще один вариант использования включает в себя средства обработки, например, компьютер или программируемое логическое устройство, настроенное или адаптированное для выполнения одного из способов, описанных в данном документе.

Еще один вариант использования включает компьютер, с установленной на нем компьютерной программой для выполнения одного из способов, описанных в данном документе.

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

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

Изобретение относится к передаче или подготовке к передаче потока устройства доступа, такого как поток медиа. Технический результат - разработка концепции передачи или концепции подготовки передачи, которая позволяет передачу с низкой полосой пропускания и быструю синхронизацию потоков устройств доступа через основной способ передачи или слой. Для этого устройство для подготовки потока медиа содержания (14) из последовательности медиа содержания (28) для передачи через сигнал передачи (38) выполнено с возможностью генерации последовательности (18) логических кадров из потока медиа содержания (14) с помощью последовательной вставки последовательности медиа содержания (28) в раздел полезных данных (24) логических кадров (20) последовательности (18) логических кадров (20); и снабжения каждого логического кадра (20), на который попадает начало (32) каждого медиа содержания (28), таблицей соответствующего медиа содержания (30), включающей на каждое начало (32) медиа содержания, попадающее в соответствующий логический кадр (20), указатель (40), указывающий на начало (32) соответствующего медиа содержания. 7 н. и 41 з.п. ф-лы, 21 ил.

1. Устройство для подготовки потока медиа содержания (14) из последовательности медиа содержания (28) для передачи через сигнал передачи (38), характеризующееся тем, что оно выполнено с возможностью генерации последовательности (18) логических кадров из потока медиа содержания (14) с помощью последовательной вставки последовательности медиа содержания (28) в раздел полезных данных (24) логических кадров (20) последовательности (18) логических кадров (20); и снабжения каждого логического кадра (20), на который попадает начало (32) каждого медиа содержания (28), таблицей соответствующего медиа содержания (30), включающей на каждое начало (32) медиа содержания, попадающее в соответствующий логический кадр (20), указатель (40), указывающий на начало (32) соответствующего медиа содержания.

2. Устройство по п. 1, характеризующееся тем, что оно настроено на генерацию последовательности (18) логических кадров (20), так что таблица соответствующего медиа содержания (30) граничит или имеет определенное постоянное смещение от заднего или ведущего конца логических кадров (20)

3. Устройство по п. 1, характеризующееся тем, что оно настроено на генерацию последовательности (18) логических кадров (20), так что каждая таблица соответствующего медиа содержания (30) имеет длину в зависимости от количества медиа содержания (28), начало (32) которого попадает в соответствующий логический кадр (20).

4. Устройство по п. 1, характеризующееся тем, что оно настроено на генерацию последовательности (18) логических кадров (20), так что указатели (40) указывают на начало (32) медиа содержания (28), начало которых попадает в соответствующий логический кадр (20) от точки регистрации, расположенной по отношению к ведущему или заднему концу соответствующего логического кадра (20), постоянным образом для логических кадров (20), в которые начало (32) медиа содержания (28) попадает.

5. Устройство по п. 1, характеризующееся тем, что настроено на генерацию последовательности логических кадров (20), так что последовательности медиа содержания (28) бесшовно вставляются в раздел полезных данных (24) логических кадров (20).

6. Устройство по п. 1, характеризующееся тем, что настроено на обеспечение каждого логического кадра заголовком логического кадра (22), указывающим на отсутствие таблицы соответствующего медиа содержания (30) в соответствующем логическом кадре (20) или логических кадрах, в которые не попадает начало (32) любого из последовательности медиа содержания (28) и длины таблицы соответствующего медиа содержания (30) соответствующего логического кадра (20) для логических кадров (20), в которые попадает начало (32) по крайней мере одного из последующего медиа содержания (28).

7. Устройство по п. 6, характеризующееся тем, что оно настроено на обеспечение каждого логического кадра (20) заголовком логического кадра (22), так что соответствующий заголовок логического кадра граничит или имеет определенное постоянное смещение с задним или ведущим концом соответствующего логического кадра (20).

8. Устройство по п. 6, характеризующееся тем, что оно настроено на выполнение непрерывной вставки последовательности медиа содержания (28) в раздел полезных данных (24) логических кадров (20) с помощью направления вставки полезных данных (60), а также для организации таблицы соответствующего медиа содержания (30) и заголовка логического кадра в логических кадрах (20), в которые попадает начало (32) медиа содержания (28), так что раздел полезных данных (24) занимает связанную часть соответствующего логического кадра (20), имеющего одну постоянно расположенную границу, и изменяющуюся расположенную границу, смещенную от постоянно расположенной границы в зависимости от длины (34) таблицы соответствующего медиа содержания (30).

9. Устройство по п. 6, характеризующееся тем, что оно настроено на генерацию последовательности логических кадров (20), так что таблицы соответствующего медиа содержания (30) и заголовок логического кадра (22) граничат или имеют постоянное смещение от противоположных концов ведущих и задних концов логических кадров (20).

10. Устройство по п. 6, характеризующееся тем, что оно настроено на генерацию последовательности (18) логических кадров (20), так что таблица соответствующего медиа содержания (30) и заголовок логического кадра (22) граничат с противоположными концами ведущих и задних концов логических кадров (20), так что раздел полезных данных (24) является связной частью простирающейся для логических кадров (20), в которых начало (32) последовательности медиа содержания(28) попадает между таблицей соответствующего медиа содержания (30) и заголовком логического кадра (22) соответственно, а для логических кадров (20), кроме логических кадров, в которые попадает начало соответствующего медиа содержания, между заголовком логического кадра (22) и противоположными концами ведущих и задних концов логических кадров (20).

11. Устройство по п. 6, характеризующееся тем, что оно настроено на генерацию последовательности (18) логических кадров (20), так что заголовки логических кадров (22) имеют постоянную длину для всех логических кадров (20).

12. Устройство по п. 6, характеризующееся тем, что оно настроено на предоставление в каждом логическом кадре (20), в которые попадает начало (32) медиа содержания (28), таблицы соответствующего медиа содержания (30) с указанием длины, указывающим на длину (62) соответствующего медиа содержания, начало которого попадает в соответствующий логический кадр.

13. Устройство по п. 1, характеризующееся тем, что оно настроено на предоставление каждой таблице соответствующего медиа содержания (30) записи таблицы последовательности медиа содержания (28), начало (32) которой попадает в соответствующий логический кадр (20), и заголовка логического кадра (32), указывающего на количество записей таблицы медиа содержания в таблице соответствующего медиа содержания (30), соответствующих логических кадров (20), при этом начала записей таблицы соответствующего медиа содержания отделены от ведущего (72) или заднего конца (70) логического кадра (20) в единицах постоянной длины, каждая запись таблицы соответствующего медиа содержания (64) содержит указатель (40), указывающий на соответствующее начало (32) медиа содержания (28), попадающее в соответствующий логический кадр (20), причем каждая таблица медиа содержания снабжена дополнительной избыточностью данных, что позволяет осуществлять обнаружение и/или коррекцию повреждения данных в отдельных записях таблицы медиа содержания.

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

15. Устройство по п. 1, характеризующееся тем, что оно настроено на предоставление каждой таблице соответствующего медиа содержания записи таблицы соответствующего медиа содержания на каждое начало соответствующего медиа содержания, которое попадает в соответствующий логический кадр, каждая запись таблицы соответствующего медиа содержания содержит указатель, указывающий на соответствующее начало медиа содержания, попадающее в соответствующий логический кадр, причем каждая запись таблицы соответствующего медиа содержания снабжена рассчитанной второй дополнительной избыточностью данных и позволяет обнаруживать повреждения данных, медиа содержания, на начало которого указатель соответствующей записи таблицы медиа содержания (64) указывает.

16. Устройство по п. 1, характеризующееся тем, что медиа содержание включает в себя аудио, видео, текстовые и другие данные.

17. Устройство по п. 1, характеризующееся тем, что оно настроено на продолжение непрерывной вставки последовательности медиа содержания в логические кадры при переходе из одного логического кадра к следующему логическому кадру, начиная вставку с места в следующем логическом кадре, независимо от количества медиа содержания, начало которых попадает на соответствующий логический кадр.

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

19. Устройство по п. 1, характеризующееся тем, что оно содержит генератор потока, настроенный на генерацию потока медиа содержания из по крайней мере двух отдельных входных потоков медиа содержания, каждое из которых представляет видео, аудио, текстовые данные, причем генератор потока настроен на генерацию потока медиа содержания, так что для каждого входного потока последовательности медиа содержания последовательности медиа содержания соответствующего входного потока расположены в порядке представления, и медиа содержания различных входных потоков располагаются в потоке последовательности медиа содержания в чередованной форме, так что медиа содержания, относящиеся к одному времени преставления, сгруппированы вместе.

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

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

22. Устройство по п. 17, характеризующееся тем, что заголовки логического кадра граничат с или имеют заданное смещение от ведущего конца или заднего конца соответствующих логических кадров, и логические кадры содержат раздел данных FEC (66) постоянной длины и расположенные рядом с соответствующим заголовком логического кадра, разделы данных FEC, определяющие систематические FEC данные, FEC-защищающие части логических кадров, внешних по отношению к разделам FEC данных и содержащих, по крайней мере, раздел полезных данных, заголовок логического кадра и таблицу медиа содержания, если они там есть.

23. Устройство по п. 1, характеризующееся тем, что оно настроено на генерацию последовательности логических кадров, так что каждый заголовок логического кадра дополнительно содержит флаг сигнализации наличия или отсутствия раздела повышения в соответствующем заголовке логического кадра, и, если сигнализируется наличие, раздела повышения в дополнение к заголовку логического кадра и разделу полезных данных.

24. Цепь передачи, характеризующаяся тем, что включает устройство для подготовки потока медиа содержания из последовательности медиа содержания для передачи по сигналу передачи в соответствии с любым из пп. 1-23, и стадию передачи для передачи сигнала передачи.

25. Цепь передачи по п. 24, характеризующаяся тем, что стадия передачи настроена на трансляцию сигнала передачи.

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

27. Устройство по п. 26, характеризующееся тем, что оно настроено на обнаружение таблицы соответствующего медиа содержания (30) заданного логического кадра (20) на, или с заданным постоянным смещением, заднем или ведущем конце логических кадров (20).

28. Устройство по п. 25, характеризующееся тем, что оно настроено на, при поиске соответствующего медиа содержания (28), начало (32), которое попадает в заданный логический кадр (20), с помощью соответствующего указателя (40) в качестве перемещения от точки регистрации, расположенной по отношению к заднему или ведущему концу заданного логического кадра (20), устройство настроено также на извлечение таблицы медиа содержания (30) других логических кадров (20), в которые попадает начало (32) медиа содержания (28), и использование соответствующего указателя (40), содержащего таким образом перемещение относительно точки регистрации в указанном другом логическом кадре (20).

29. Устройство по 26, характеризующееся тем, что оно настроено на извлечение из каждого логического кадра (20) заголовка логического кадра (22), указывающего на отсутствие или длину (34) таблицы соответствующего медиа содержания (30) соответствующего логического кадра (20), и обнаружение расширения раздела полезных данных (24) соответствующего логического кадра (20) в зависимости от этого.

30. Устройство по п. 29, характеризующееся тем, что оно настроено на нахождение в каждом логическом кадре (20) заголовка логического кадра (22) на или на определенном постоянном смещении от ведущего или заднего конца соответствующего логического кадра (20).

31. Устройство по п. 29, характеризующееся тем, что оно настроено на выполнение последовательного извлечения последовательности медиа содержания (28) из логических кадров (20) с помощью направления извлечения полезных данных в логических кадрах (20), и обнаружение изменяющегося положения конца таблицы медиа содержания (30) с применением длины (34) таблицы соответствующего медиа содержания (30) в направлении, противоположном направлению извлечения полезных данных из постоянно расположенного конца.

32. Устройство по п. 29, характеризующееся тем, что оно настроено на обнаружение таблицы соответствующего медиа содержания (30) и заголовка логического кадра (22) логического кадра (20) на, или на постоянном смещении от, противоположном конце ведущего и заднего концов заданного логического кадра (20).

33. Устройство по п. 29, характеризующееся тем, что оно настроено на обнаружение таблицы соответствующего медиа содержания (30) и заголовка логического кадра (22) заданного логического кадра (20) на противоположном конце ведущего и заднего концов логических кадров (20).

34. Устройство по п. 26, характеризующееся тем, что оно настроено на извлечение из таблицы соответствующего медиа содержания (30) указания длины, указывающего на длину (62) последовательности медиа содержания (28), начало которого попадает в заданный логический кадр (20).

35. Устройство по п. 29, характеризующееся тем, что заголовок логического кадра указывает на длину соответствующей таблицы соответствующего медиа содержания (30), а количество записей таблицы медиа содержания (64) в таблице соответствующего медиа содержания (30) соответствующих логических кадров (20) и количество медиа содержания (28), начала которых (32) попадает в заданный логический кадр (20), соответственно, устройство настроено на, при извлечении таблицы соответствующего медиа содержания (30) из заданного логического кадра (20), последовательное извлечение количества записей в таблице соответствующего медиа содержания (64) пошагово, начиная с ведущего или заднего конца логического кадра (20) или с места в заданном логическом кадре (20), имеющем заданное постоянное смещением от него в единицах постоянной длины от одной записи таблицы соответствующего медиа содержания (64) до другой, чтобы получить для каждой записи таблицы соответствующего медиа содержания (64) указатель (40), указывающий на соответствующее положение начала соответствующего медиа содержания (28).

36. Устройство по п. 35, характеризующееся тем, что оно настроено на извлечение дополнительной избыточной информации для заголовка логического кадра из заданного логического кадра и использование ее, чтобы выполнить обнаружение повреждения данных (172) или попытки исправления ошибок в заголовке логического кадра, и, если последний оказывается поврежденным, извлечение (176, 190), если оно присутствует, остальная часть раздела полезных данных заданного логического кадра, принадлежащего медиа содержанию, начало которого попадает на любой предыдущий логический кадр, и распространяется на заданный логический кадр, оставшаяся часть, начинаясь с начального положения раздела полезных данных заданного логического кадра, постоянно расположена для всех логических кадров.

37. Устройство по п. 36, характеризующееся тем, что устройство настроено на, если заголовок логического кадра оказывается поврежденным, выполнение шага (178), начиная с ведущего или заднего конца логического кадра (20) или с места в заданном логическом кадре (20), имеющем заданное постоянное смещение от него, в единицах постоянной длины от одной, возможно присутствующей записи таблицы медиа содержания (64) к другой для того, чтобы получить для каждой, возможно присутствующей записи таблицы медиа содержания (64) предполагаемый указатель (40), указывающий на предполагаемое место начала соответствующей последовательности медиа содержания (28) и дополнительную избыточность данных, для того, чтобы выполнить обнаружение повреждения данных отдельных записей таблицы медиа содержания в возможно присутствующих записях таблицы медиа содержания, и чтобы найти и начать извлечение, только из предполагаемых мест соответствующего медиа содержания, на которые указатели этих предполагаемых возможно присутствующих записей таблицы медиа содержания указывают, которые оказываются правильными после обнаружения повреждения данных.

38. Устройство по п. 35, характеризующееся тем, что настроено на извлечение для каждой записи в таблице медиа содержания дополнительной избыточности данных и выполнения обнаружения повреждения данных отдельных записей таблицы медиа содержания и/или коррекцию записей таблицы медиа содержания, а также найти и начать извлечение, только тех последовательностей медиа содержания, начало которых попадает в заданный логический кадр, соответствующая запись таблицы медиа содержания которых не повреждена/исправлена.

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

40. Устройство по п. 25, характеризующееся тем, что медиа содержание включает в себя аудио, видео, текстовые и/или содержание данных.

41. Устройство по п. 25, характеризующееся тем, что настроено на продолжение последовательного извлечения последовательностей медиа содержания из логических кадров при переходе от заданного логического кадра к следующему логическому кадру, начиная извлечение с места в следующем логическом кадре, независимо от количества последовательности медиа содержания, начало которых попадает в заданный логический кадр.

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

43. Устройство по п. 25, характеризующееся тем, что заголовки логического кадра граничат или имеют заданное смещение от одного из ведущих концов или задних концов соответствующих логических кадров, и логические кадры, каждый, включают данные FEC (66) постоянной длины и расположенные рядом с соответствующим заголовком логического кадра разделы FEC данных, определяющие систематические FEC данные, FEC-защищающие части логических кадров, внешних по отношению к разделам FEC данных и содержащих, по крайней мере, раздел полезных данных, заголовок логического кадра и таблицу медиа содержания, если они там есть, устройство настроено на выполнение FEC обработки с помощью FEC данных в разделах FEC данных FEC-защищающих частей логических кадров.

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

45. Способ подготовки потока медиа содержания (14) из последовательности медиа содержания (28), представляющий медиа содержание для передачи через сигнал передачи (38), характеризующийся тем, что включает генерацию последовательности (18) логических кадров из потока медиа содержания с помощью последовательной вставки последовательности медиа содержания(28) в раздел полезных данных (24) логических кадров (20) последовательности (18) логических кадров (20); и обеспечения каждого логического кадра (20), в который попадает начало (32) медиа содержания (28), таблицей соответствующего медиа содержания (30), при этом таблица соответствующего медиа содержания (30) включает на начало (32) медиа содержания, попадающего в соответствующий логический кадр (20), указатель (40), указывающий на начало (32) соответствующего медиа содержания.

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

47. Машиночитаемый носитель информации с записанной на него компьютерной программой, имеющей программный код для выполнения, при работе на компьютере способа по п. 45.

48. Машиночитаемый носитель информации с записанной на него компьютерной программой, имеющей программный код для выполнения, при работе на компьютере способа по п. 46.