Концепція потоку відеоданих
Номер патенту: 114909
Опубліковано: 28.08.2017
Автори: Хенкель Анастасія, Георге Валері, Марпе Детлеф, Грюнеберг Карстен, Скупін Роберт, Шірль Томас
Формула / Реферат
1. Машинозчитуваний носій даних, який містить потік відеоданих, який має в собі кодований відеозміст (16) в одиницях фрагментів (24) картинок (18) відеозмісту (16), при цьому кожен фрагмент (24), відповідно, кодований з одержанням одного або більшої кількості пакетів (32) корисної інформації послідовності (34) пакетів потоку відеоданих (22), при цьому послідовність (34) пакетів розбивається на послідовність блоків доступу (30) таким чином, що кожен блок доступу (30) збирає пакети (32) корисної інформації, які належать до відповідної картинки (18) відеозмісту (16), при цьому послідовність (34) пакетів має розкидані в ній пакети (36) керування синхронізацією таким чином, що пакети (36) керування синхронізацією підрозбивають блоки доступу (30) на декодувальні блоки (38) таким чином, що принаймні деякі блоки доступу (30) підрозбиваються на два або більшу кількість декодувальних блоків (38), при цьому кожен пакет (38) керування синхронізацією сигналізує для декодувального блока (38) годину відновлення буфера декодера, пакети (32) корисної інформації якого слідують за відповідним пакетом (38) керування синхронізацією в послідовності (34) пакетів.
2. Машинозчитуваний носій даних за п. 1, який відрізняється тим, що фрагменти (24) є вирізками і кожен пакет (32) корисної інформації охоплює одну або більшу кількість вирізок.
3. Машинозчитуваний носій даних за п. 2, який відрізняється тим, що вирізки включають здатні до незалежного декодування вирізки і залежні вирізки, які передбачають WPP, декодування з використанням ентропійного і прогнозувального декодування за межами вирізки.
4. Машинозчитуваний носій даних за будь-яким із пп. 1-3, який відрізняється тим, що кожен пакет послідовності (34) пакетів може присвоюватися точно одному типу пакета з множини типів пакета з пакетами (32) корисної інформації і пакетами (36) керування синхронізацією, які є пакетами різного типу, при цьому появи пакетів з множиною типів в послідовності (34) пакетів піддаються певним обмеженням, які визначають порядок серед типів пакета, який повинен дотримуватися пакетами в кожному блоці доступу (30) таким чином, що межі блока доступу здатні виявлятися з використанням обмежень шляхом виявлення моментів часу, де застосовуються обмеження, і залишаються у тому ж положенні в послідовності пакетів навіть, якщо пакети будь-якого здатного до видалення типу видаляються з потоку відеоданих, при цьому пакети (32) корисної інформації є не здатними до видалення пакетами, а пакети (36) керування синхронізацією є здатними до видалення пакетами.
5. Машинозчитуваний носій даних за будь-яким із пп. 1-4, який відрізняється тим, що кожен пакет містить частину синтаксичного елемента, який вказує тип пакета.
6. Машинозчитуваний носій даних за п. 5, який відрізняється тим, що частина синтаксичного елемента, яка вказує тип пакета, містить поле типу пакета в заголовку відповідного пакета, зміст якого відрізняється між пакетами корисної інформації і пакетами керування синхронізацією, і для пакетів керування синхронізацією поле типу SEI пакета, розрізняється між пакетами керування синхронізацією, з одного боку, і SEI пакетами іншого типу, з іншого боку.
7. Машинозчитуваний носій даних за п. 1, який відрізняється тим, що потік відеоданих є здатним до масштабування потоком даних (SVC) кодування відеосигналу.
8. Кодер для кодування з одержанням потоку відеоданих (22) відеозмісту (16) в одиницях фрагментів (24) картинок (18) відеозмісту (16) з, відповідно, кодуванням кожного фрагмента (24) з одержанням одного або більшої кількості пакетів (32) корисної інформації послідовності (34) пакетів потоку відеоданих (22) таким чином, що послідовність (34) пакетів розбивається на послідовність блоків доступу (30) і кожен блок доступу (30) збирає пакети (32) корисної інформації, які належать до відповідної картинки (18) відеозмісту (16), при цьому кодер сконфігурований для розкидування в послідовності (34) пакетів (36) керування синхронізацією таким чином, що пакети (36) керування синхронізацією підрозбивають блоки доступу (30) на декодувальні блоки (38) таким чином, що принаймні деякі блоки доступу (30) підрозбиваються на два або більшу кількість декодувальних блоків (38), при цьому кожен пакет (36) керування синхронізацією сигналізує для декодувального блока (38) годину відновлення буфера декодера, пакети (32) корисної інформації якого слідують за відповідним пакетом (36) керування синхронізацією в послідовності (34) пакетів.
9. Кодер за п. 8, який відрізняється тим, що сконфігурований для кодування поточного фрагмента (24) поточної картинки (18) з одержанням поточного пакета (32) корисної інформації поточного декодувального блока (38) під час кодування поточної картинки відеозмісту, для передачі в потоці даних поточного декодувального блока (38), префікс до якого додається поточним пакетом (36) керування синхронізацією з встановленням години відновлення буфера декодера, сигналізованої поточним пакетом (36) керування синхронізацією в перший момент часу; і для кодування подальшого фрагмента поточної картинки в другий момент часу, пізніший за перший момент часу.
10. Кодер за п. 8, який відрізняється тим, що потік відеоданих є здатним до масштабування потоком даних (SVC) кодування відеосигналу.
11. Спосіб кодування з одержанням потоку відеоданих (22) відеозмісту (16) в одиницях фрагментів (24) картинок (18) відеозмісту (16) з, відповідно, кодуванням кожного фрагмента (24) з одержанням одного або більшої кількості пакетів (32) корисної інформації послідовності (34) пакетів потоку (22) відеоданих таким чином, що послідовність (34) пакетів розбивають на послідовність блоків доступу (30) і кожен блок доступу (30) збирає пакети (32) корисної інформації, які належать до відповідної картинки (18) відеозмісту (16), при цьому у способі розкидають в послідовності (34) пакетів пакети (36) керування синхронізацією таким чином, що пакети (36) керування синхронізацією підрозбивають блоки доступу (30) на декодувальні блоки (38) таким чином, що принаймні деякі блоки доступу (30) підрозбивають на два або більшу кількість декодувальних блоків (38), при цьому кожен пакет (36) керування синхронізацією сигналізує для декодувального блока (38) годину відновлення буфера декодера, пакети (32) корисної інформації якого йдуть за відповідним пакетом (36) керування синхронізацією в послідовності (34) пакетів.
12. Декодер для декодування потоку відеоданих (22), який має в собі кодований відеозміст (16) в одиницях фрагментів (24) картинок (18) відеозмісту (16), при цьому кожен фрагмент, відповідно, кодується з одержанням одного або більшої кількості пакетів (32) корисної інформації послідовності (34) пакетів потоку відеоданих (22), при цьому послідовність (34) пакетів розбивається на послідовність блоків доступу (30) таким чином, що кожен блок доступу (30) збирає пакети (32) корисної інформації, які належать до відповідної картинки (18) відеозмісту (16), при цьому декодер містить буфер для буферизації потоку відеоданих або відновлення відеозмісту, одержаного з нього, шляхом декодування потоку відеоданих і сконфігурований для пошуку пакетів (36) керування синхронізацією, розкиданих в послідовності пакетів, для підрозбиття блоків доступу (30) на декодувальні блоки (38) в пакетах (36) керування синхронізацією таким чином, що принаймні деякі блоки доступу підрозбиваються на два або більшу кількість декодувальних блоків, і для спорожнення буфера в одиницях декодувальних блоків.
13. Декодер за п. 12, який відрізняється тим, що сконфігурований для перевірки в кожному пакеті частини синтаксичного елемента, яка вказує тип пакету, під час пошуку пакетів (36) керування синхронізацією, і якщо величина частини синтаксичного елемента, яка вказує тип пакету, дорівнює наперед встановленій величині, то для розгляду відповідного пакета як пакета (36) керування синхронізацією.
14. Декодер за п. 12, який відрізняється тим, що потік відеоданих є здатним до масштабування потоком даних (SVC) кодування відеосигналу.
15. Спосіб декодування потоку відеоданих (22), який має кодований в ньому відеозміст (16) в одиницях фрагментів (24) картинок (18) відеозмісту (16), при цьому кожен фрагмент, відповідно, кодують з одержанням одного або більшої кількості пакетів (32) корисної інформації послідовності (34) пакетів потоку відеоданих (22), при цьому послідовність (34) пакетів розбивають на послідовність блоків доступу (30) таким чином, що кожен блок доступу (30) збирає пакети (32) корисної інформації, які належать до відповідної картинки (18) відеозмісту (16), при цьому у способі використовують буфер для буферизації потоку відеоданих або для відтворення відеозмісту, одержаного з нього, шляхом декодування потоку відеоданих і шукають пакети (36) керування синхронізацією, розкидані в послідовності пакетів, підрозбивають блоки доступу (30) на декодувальні блоки (38) в пакетах (36) керування синхронізацією таким чином, що принаймні деякі блоки доступу підрозбиваються на два або більшу кількість декодувальних блоків, і спорожнюють буфер в одиницях декодувальних блоків.
16. Мережевий об'єкт для передачі потоку відеоданих (22), який має кодований в собі відеозміст (16) в одиницях фрагментів (24) картинок (18) відеозмісту (16), при цьому кожен фрагмент, відповідно, кодований з одержанням одного або більшої кількості пакетів (32) корисної інформації послідовності (34) пакетів потоку відеоданих (22), при цьому послідовність (34) пакетів розбивають на послідовність блоків доступу (30) таким чином, що кожен блок доступу (30) збирає пакети (32) корисної інформації, які належать до відповідної картинки (18) відеозмісту (16), при цьому декодер сконфігурований для пошуку пакетів (36) керування синхронізацією, розкиданих в послідовності пакетів, для підрозбиття блоків доступу на декодувальні блоки в пакетах (36) керування синхронізацією таким чином, що принаймні деякі блоки доступу (30) підрозбиваються на два або більшу кількість декодувальних блоків (38), для одержання з кожного пакету (36) керування синхронізацією години відновлення буфера декодера для декодувального блока (38), пакети (32) корисної інформації якого слідують за відповідним пакетом (36) керування синхронізацією в послідовності (34) пакетів, і для виконання передачі потоку відеоданих в залежності від годин відновлення буфера декодера для декодувальних блоків (38).
17. Спосіб передачі потоку відеоданих (22), який має кодований в ньому відеозміст (16) в одиницях фрагментів (24) картинок (18) відеозмісту (16), при цьому кожен фрагмент, відповідно, кодують з одержанням одного або більшої кількості пакетів (32) корисної інформації послідовності (34) пакетів потоку (22) відеоданих, при цьому послідовність (34) пакетів розбивають на послідовність блоків доступу (30) таким чином, що кожен блок доступу (30) збирає пакети (32) корисної інформації, які належать до відповідної картинки (18) відеозмісту (16), при цьому у способі шукають пакети (36) керування синхронізацією, розкидані в послідовності пакетів, підрозбивають блоки доступу на декодувальні блоки в пакетах (36) керування синхронізацією таким чином, що принаймні деякі блоки доступу (30) підрозбиваються на два або більшу кількість декодувальних блоків (38), одержують для декодувального блока (38) з кожного пакета (36) керування синхронізацією годину відновлення буфера декодера, пакети (32) корисної інформації якого слудують за відповідним пакетом (36) керування синхронізацією в послідовності (34) пакетів, і виконують передачу потоку відеоданих в залежності від годин відновлення буфера декодера для декодувальних блоків (38).
Текст
Реферат: Інформація про години відновлення декодера, ROI інформація і ідентифікаційна інформація мозаїки передаються в потоці відеоданих на рівні, який передбачає легкий доступ для мережевих об'єктів, таких як MANEs або декодер. Для досягання такого рівня, інформація про такі типи передається в потоці відеоданих за допомогою пакетів, розкиданих в пакетах блоків доступу потоку відеоданих. У відповідності з варіантом виконання розкидані пакети є здатними до видалення пакетами, тобто, видалення цих розкиданих пакетів зберігає здатність декодера повністю відновлювати відеозміст, який переноситься потоком відеоданих. UA 114909 C2 (12) UA 114909 C2 UA 114909 C2 5 10 15 20 25 30 35 40 45 50 55 60 Представлений винахід стосується концепцій потоку відеоданих, які, зокрема, є вигідними у зв‘язку із застосуваннями з малою затримкою. Стандарт HEVC [2] передбачає різні засоби синтаксису високого рівня, який сигналізується для прикладного рівня. Такі засоби є заголовком блока NAL, множинами значень параметра і повідомленнями додаткової розширювальної інформації (SEI). Останні не використовуються в процесі декодування. Інші засоби сигналізації синтаксису високого рівня одержуються з відповідних специфікацій транспортного протоколу, такого як транспортний протокол MPEG2 [3] або транспортний протокол реального часу [4], і спеціальні специфікації його корисної інформації, наприклад рекомендацій для стандарту H.264/AVC [5], здатне до масштабування кодування відеоданих (SVC) [6] або стандарт HEVC [7]. Такі транспортні протоколи можуть вносити сигналізацію високого рівня, яка використовує подібні структури і механізм як сигналізацію високого рівня відповідної специфікації кодека прикладного рівня, наприклад HEVC [2]. Одним прикладом такої сигналізації є блок NAL інформації про масштабованість змісту корисних даних (PACSI), як описано в роботі [6], яка надає додаткову інформацію для транспортного рівня. Для множин значень параметра стандарт HEVC містить множину значень параметра відеоданих (VPS), яка вибирає потік найважливішої інформації для використання прикладним рівнем в єдиному центральному місці. В раніших наближеннях цю інформацію необхідно було збирати з багатьох множин значень параметрів і заголовків блоків NAL. До появи даної заявки статус стандарту стосовно операцій буферизації кодованої картинки (CPB) гіпотетичного еталонного декодера (HRD) і увесь відповідний синтаксис, наданий в множині значень параметра послідовності (SPS)/Інформації про корисність відеоданих (VUI), SEI синхронізації картинки, SEI періоду буферизації, а також визначення декодувального блока, опис фрагмента картинки і синтаксис залежних вирізок, які присутні в заголовку вирізки, а також множина значень параметра картинки (PPS) були наступними. Для забезпечення операції CPB з малою затримкою на рівні фрагмента картинки, були запропоновані операції CPB фрагмента картинки і інтегровані в схематичний стандарт HEVC (7 JCTVC-I1003) [2]. Тут, зокрема, декодувальний блок був визначений в розділі 3 документа [2] як: декодувальний блок: блок доступу або підмножина блока доступу. Якщо SubPicCpbFlag дорівнює 0, то декодувальний блок є блоком доступу. Інакше, декодувальний блок складається з одного або більшої кількості блоків VCL NAL в блоці доступу і відповідних блоків не-VCL NAL. Для першого блока VCL NAL в блоці доступу відповідними блоками є блоки не-VCL NAL, а блоки NAL даних заповнювача, якщо такі є, безпосередньо слідують за першим блоком VCL NAL і усіма блоками не-VCL NAL в блоці доступу, які передують першому блоку VCL NAL. Для блока VCL NAL, який не є першим блоком VCL NAL в блоці доступу, відповідні блоки не-VCL NAL є блоком NAL даних заповнювача, якщо це має місце, який слідує безпосередньо за блоком VCL NAL. В стандарті, визначеному до цього часу, "Синхронізація видалення декодувального блока і декодування декодувального блока" була описана і додана до Додатку C "Гіпотетичний еталонний декодер". Для сигналізації синхронізації фрагмента картинки, SEI повідомлення періоду буферизації і SEI повідомлення синхронізації картинки, а також HRD параметри в VUI були розширені для підтримки декодувальних блоків як блоків фрагмента картинки. Синтаксис SEI повідомлення періоду буферизації документа [2] зображений на Фіг. 1. Коли NalHrdBpPresentFlag або VclHrdBpPresentFlag дорівнюють 1, то SEI повідомлення періоду буферизації може зв‘язуватися з будь-яким блоком доступу в потоці бітів і SEI повідомлення періоду буферизації повинно зв‘язуватися з кожним RAP блоком доступу і з кожним блоком доступу, зв‘язаним з SEI повідомленням точки відновлення. Для деяких застосувань часта присутність SEI повідомлення періоду буферизації може бути бажаною. Період буферизації був специфікований як множина блоків доступу між двома подіями SEI повідомлення періоду буферизації в порядку декодування. Семантика була наступною: seq_parameter_set_id вказує множину значень параметра послідовності, яка містить HRD атрибути послідовності. Величина seq_parameter_set_id повинна дорівнювати величині seq_parameter_set_id в множині значень параметра картинки, на яку посилається головна кодована картинка, зв‘язана з SEI повідомленням періоду буферизації. Величина seq_parameter_set_id повинна становити 0 - 31 включно. rap_cpb_params_present_flag equal to 1 вказує присутність синтаксичних елементів initial_alt_cpb_removal_delay[ SchedSelIdx ] і initial_alt_cpb_removal_delay_offset[ SchedSelIdx ]. Коли вони відсутні, то величина rap_cpb_params_present_flag вважається рівною 0. Коли 1 UA 114909 C2 5 10 15 20 25 30 35 40 45 50 55 відповідна картинка не є ні CRA картинкою, ні BLA картинкою, то величина rap_cpb_params_present_flag повинна дорівнювати 0. initial_cpb_removal_delay[ SchedSelIdx ] і initial_alt_cpb_removal_delay[ SchedSelIdx ] вказують початкові затримки у видаленні з CPB для SchedSelIdx-th CPB. Синтаксичні елементи мають довжину в бітах, задану initial_cpb_removal_delay_length_minus1 + 1, і надаються в одиницях тактового генератора з тактовою частотою 90 кГц. Величини синтаксичних елементів не повинні дорівнювати 0 і не повинні перевищувати 90000 * ( CpbSize[ SchedSelIdx ] BitRate[ SchedSelIdx ] ) – годинний еквівалент розміру CPB в одиницях тактового генератора з тактовою частотою 90 кГц. initial_cpb_removal_delay_offset[ SchedSelIdx ] і initial_alt_cpb_removal_delay_offset[ SchedSelIdx ] використовуються для SchedSelIdx-th CPB для вказання початкової години доставки блоків кодованих даних до CPB. Синтаксичні елементи мають довжину в бітах, задану initial_cpb_removal_delay_length_minus1 + 1, і надаються в одиницях тактового генератора з тактовою частотою 90 кГц. Ці синтаксичні елементи не використовуються декодерами і можуть потребуватися тільки для подавального диспетчера (HSS). У всій послідовності кодованих відеоданих сума initial_cpb_removal_delay[ SchedSelIdx ] і initial_cpb_removal_delay_offset[ SchedSelIdx ] повинна бути сталою для кожної величини SchedSelIdx, і сума initial_alt_cpb_removal_delay[ SchedSelIdx ] і initial_alt_cpb_removal_delay_offset[ SchedSelIdx ] повинна бути сталою для кожної величини SchedSelIdx. Синтаксис SEI повідомлення синхронізації картинки документа [2] зображений на Фіг. 2. Синтаксис SEI повідомлення синхронізації картинки залежить від змісту множини значень параметра послідовності, яка активна для кодованої картинки, зв‘язаної з SEI повідомленням синхронізації картинки. Однак, якщо SEI повідомленню синхронізації картинки IDR або BLA блока доступу не передує SEI повідомлення періоду буферизації в тому ж блоці доступу, то активування відповідної множини значень параметра послідовності (і для IDR або BLA картинок, які не є першою картинкою в потоці бітів, визначення, що кодована картинка є IDR картинкою або BLA картинкою) не відбувається до декодування першого блока NAL кодованої вирізки кодованої картинки. Оскільки блок NAL кодованої вирізки кодованої картинки слідує за SEI повідомленням синхронізації картинки в порядку блока NAL, то можуть бути випадку, у яких декодеру необхідно зберігати RBSP, яка містить SEI повідомлення синхронізації картинки, до визначення параметрів послідовності, яка буде активною для кодованої картинки, і потім здійснюватиме синтаксичний аналіз SEI повідомлення синхронізації картинки. Присутність SEI повідомлення синхронізації картинки в потоці бітів вказано наступним чином. – Якщо CpbDpbDelaysPresentFlag дорівнює 1, то в кожному блоці доступу послідовності кодованих відеоданих повинне бути присутнім одне SEI повідомлення синхронізації картинки. – Інакше, (CpbDpbDelaysPresentFlag дорівнює 0), в жодному блоці доступу послідовності кодованих відеоданих не повинні бути присутніми SEI повідомлення синхронізації картинки. Семантика визначається наступним чином: cpb_removal_delay вказує скільки потрібно очікувати тактів тактового генератора після видалення з CPB блока доступу, зв‘язаного з найостаннішим SEI повідомленням періоду буферизації в попередньому блоці доступу перед видаленням з буфера даних блока доступу, зв‘язаних з SEI повідомленням синхронізації картинки. Ця величина також використовується для підрахунку найранішої можливої години надходження даних блока доступу в CPB для HSS. Синтаксичний елемент є кодом фіксованої довжини, яка в бітах задається cpb_removal_delay_length_minus1 + 1. cpb_removal_delay є залишком лічильника по модулю (cpb_removal_delay_length_minus1 + 1) 2 . Величина cpb_removal_delay_length_minus1, яка визначає довжину (в бітах) синтаксичного елемента cpb_removal_delay є величиною cpb_removal_delay_length_minus1, кодованого в множині значень параметра послідовності, яка активна для першої кодованої картинки, зв‘язаної з SEI повідомленням синхронізації картинки, хоча cpb_removal_delay вказує кількість тактів тактового генератора відносно години видалення попереднього блока доступу, який містить SEI повідомлення періоду буферизації, який може бути блоком доступу іншої послідовності кодованих відеоданих. dpb_output_delay використовується для підрахунку DPB години виходу картинки. Він вказує скільки тактів тактового генератора очікується після видалення останнього декодувального блока в блоці доступу з CPB перед виходом декодованої картинки з DPB. 2 UA 114909 C2 5 10 15 20 25 30 35 40 45 50 55 60 Картинку не видаляють з DPB в момент її виходу, коли вона все ще позначена як "використовувати для короткотермінового посилання" або "використовувати для довготермінового посилання". Для декодованої картинки вказується тільки один dpb_output_delay. Довжина синтаксичного елемента dpb_output_delay задається в бітах dpb_output_delay_length_minus1 + 1. Коли sps_max_dec_pic_buffering[ max_temporal_layers_minus1 ] дорівнює 0, то dpb_output_delay повинен дорівнювати 0. Година виходу, одержана з dpb_output_delay будь-якої картинки, яка є вихідним параметром з синхронізації виходу, яка узгоджується з декодером, повинна передувати годині виходу, одержаній з dpb_output_delay усіх картинок в будь-якій наступній послідовності кодованих відеоданих в порядку декодування. Порядок виходу картинки, встановлений величинами цього синтаксичного елемента, повинен бути тим же порядком, який встановлений величинами PicOrderCntVal. Для картинок, які не видаються процесом "штовхання", оскільки вони передують в порядку декодування IDR або BLA картинці з no_output_of_prior_pics_flag equal to 1 або вважаються рівними 1, години виходу, одержані з dpb_output_delay, повинні збільшуватися із збільшенням величини PicOrderCntVal відносно усіх картинок в тій же послідовності кодованих відеоданих. num_decoding_units_minus1 plus 1 вказує кількість декодувальних блоків в блоці доступу, з яким зв‘язане SEI повідомлення синхронізації картинки. Величина num_decoding_units_minus1 повинна становити 0 - PicWidthInCtbs * PicHeightInCtbs – 1 включно. num_nalus_in_du_minus1[ i ] plus 1 вказує кількість блоків NAL в i-му декодувальному блоці блока доступу, з яким зв‘язане SEI повідомлення синхронізації картинки. Величина num_nalus_in_du_minus1[ i ] повинна становити 0 - PicWidthInCtbs * PicHeightInCtbs – 1 включно. Перший декодувальний блок блока доступу складається з перших num_nalus_in_du_minus1[ 0 ] + 1 послідовних блоків NAL в порядку декодування в блоці доступу. i-й (з i більшим за 0) декодувальний блок блока доступу складається з num_nalus_in_du_minus1[ i ] + 1 послідовних блоків NAL, які безпосередньо слідують за останнім блоком NAL в попередньому декодувальному блоці блока доступу в порядку декодування. Тут в кожному декодувальному блоці повинен бути принаймні один блок VCL NAL. Усі блоки не-VCL NAL, зв‘язані з блоком VCL NAL, повинні бути включені в той же декодувальний блок. du_cpb_removal_delay[ i ] вказує скільки очікується тактів тактового генератора фрагмента картинки після видалення з CPB першого декодувального блока в блоці доступу, зв‘язаному з найостаннішим SEI повідомленням періоду буферизації в попередньому блоці доступу перед видаленням з CPB i-го декодувального блока в блоці доступу, зв‘язаному з SEI повідомленням синхронізації картинки. Ця величина також використовується для підрахунку найранішої можливої години надходження даних декодувального блока в CPB для HSS. Синтаксичний елемент є кодом фіксованої довжини, яка надається в бітах cpb_removal_delay_length_minus1 + (cpb_removal_delay_length_minus1 + 1) 1. du_cpb_removal_delay[ i ] є залишком лічильника по модулю 2 . Величина cpb_removal_delay_length_minus1, яка визначає довжину (в бітах) синтаксичного елемента du_cpb_removal_delay[ i ], є величиною cpb_removal_delay_length_minus1, кодованого в множині значень параметрів послідовності, яка активна для кодованої картинки, зв‘язаної з SEI повідомленням синхронізації картинки, хоча du_cpb_removal_delay[ i ] вказує кількість тактів тактового генератора фрагмента картинки відносно години видалення першого декодувального блока в попередньому блоці доступу, який містить SEI повідомлення періоду буферизації, який може бути блоком доступу іншої послідовності кодованих відеоданих. Деяка інформація міститься в VUI синтаксисі документа [2]. VUI синтаксис параметрів документа [2] зображений на Фіг. 3. HRD синтаксис параметрів документа [2] зображений на Фіг. 4. Семантика визначається наступним чином: sub_pic_cpb_params_present_flag equal to 1 вказує, що представлені параметри видалення в CPB із затримкою на рівні фрагмента картинки і CPB може функціонувати на рівні блока доступу або на рівні фрагмента картинки. sub_pic_cpb_params_present_flag equal to 0 вказує, що відсутні параметри видалення в CPB із затримкою на рівні фрагмента картинки і CPB функціонує на рівні блока доступу. Коли sub_pic_cpb_params_present_flag відсутній, то його величина дорівнює 0. num_units_in_sub_tick є кількістю тактів тактового генератора, який працює з частотою time_scale Hz, яка відповідає одному інкременту (названий такт тактового генератора фрагмента картинки) лічильника тактів тактового генератора фрагмента картинки. num_units_in_sub_tick повинен бути більшим за 0. Такт тактового генератора фрагмента картинки є мінімальним інтервалом часу, який може представлятися в кодованих даних, коли sub_pic_cpb_params_present_flag дорівнює 1. 3 UA 114909 C2 5 10 15 20 25 30 35 40 45 50 55 tiles_fixed_structure_flag equal to 1 вказує, що кожна множина значень параметра картинки, яка є активною в послідовності кодованих відеоданих, має ту ж величину синтаксичних елементів num_tile_columns_minus1, num_tile_rows_minus1, uniform_spacing_flag, column_width[ i ], row_height[ i ] і loop_filter_across_tiles_enabled_flag, коли вони присутні. tiles_fixed_structure_flag equal to 0 вказує, що синтаксичні елементи мозаїк в інших множинах значень параметрів картинки можуть або можуть не мати однакову величину. Коли синтаксичний елемент tiles_fixed_structure_flag відсутній, то він вважається рівним 0. Сигналізація tiles_fixed_structure_flag equal to 1 є гарантією для декодера, що кожна картинка в послідовності кодованих відеоданих має однакову кількість мозаїк, розподілених однаковим способом, що може бути корисним для розподілу робочого навантаження у випадку багатопотокового декодування. Дані заповнювача документа [2] сигналізуються з використанням RBSP синтаксису даних фільтра, зображеного на Фіг. 5. Гіпотетичний еталонний декодер документа [2], використовуваний для перевірки потоку бітів і узгодженості декодера, визначається наступним чином: Два типи потоків бітів піддаються HRD перевірці на узгодженість для цієї Рекомендації | Міжнародного Стандарту. Перший такий тип потоку бітів, названий потік бітів Типу I, є потік блоків NAL, який містить тільки блоки VCL NAL і блоки NAL даних заповнювача для усіх блоків доступу в потоці бітів. Другий тип потоку бітів, названий потік бітів Типу II, містить, на додаток до блоків VCL NAL і блоків NAL даних заповнювача для усіх блоків доступу в потоці бітів, принаймні один з наступного: – додаткових блоків не-VCL NAL, відмінних від блоків NAL даних заповнювача, – усіх синтаксичних елементів leading_zero_8bits, zero_byte, start_code_prefix_one_3bytes і trailing_zero_8bits, які формують потік байтів з потоку блока NAL. Фіг. 6 зображає типи точок узгодженості потоку бітів, які перевіряються HRD документа [2]. Використовуються два типи HRD множин значень параметрів (NAL HRD параметри і VCL HRD параметри). HRD множини значень параметрів сигналізуються за допомогою інформації про корисність відеоданих, яка є частиною структури синтаксису множини значень параметра послідовності. Усі множини значень параметрів послідовності і множини значень параметрів картинки, на які посилаються в блоках VCL NAL, і відповідні SEI повідомлення періоду буферизації та синхронізації картинки повинні передаватися до HRD синхронним чином або в потоці бітів або іншими засобами. Специфікація для "присутності" блоків не-VCL NAL також задовольняється, коли такі блоки NAL (або тільки деякі з них) передаються до декодерів (або до HRD) іншими засобами, не специфікованими цією/цим Рекомендацією | Міжнародним Стандартом. Для підрахунку бітів, підраховуються тільки відповідні біти, які реально присутні в потоці бітів. Як приклад, синхронізація блока не-VCL NAL, який передається іншим засобом, не присутнім в потоці бітів, з блоками NAL, які присутні в потоці бітів, може досягатися вказанням двох точок в потоці бітів, між якими повинен бути присутнім блок не-VCL NAL в потоці бітів, який кодер вирішив передати в потоці бітів. Коли зміст блока не-VCL NAL передається для застосування деяким засобом, відмінним від присутнього в потоці бітів, то представлення змісту блока не-VCL NAL не вимагається для використання однакового синтаксису, специфікованого в цьому додатку. Відзначається, що, коли HRD інформація міститься в потоці бітів, можна перевіряти узгодженість потоку бітів з вимогами цього підпункту виключно на основі інформації, яка міститься в потоці бітів. Коли HRD інформація відсутня в потоці бітів, як у випадку для "автономних" потоків бітів Типу I, узгодженість може перевірятися тільки, коли HRD дані постачаються деяким іншим засобом, не специфікованим в цій Рекомендації | Міжнародному Стандарті. HRD містить буфер (CPB) кодованої картинки, миттєвий процес декодування, буфер (DPB) декодованої картинки і вихідні дані, які збираються, зображені на Фіг. 7. Розмір CPB (кількість бітів) становить CpbSize[ SchedSelIdx ]. Розмір DPB (кількість буферів для збереження картинки) для тимчасового рівня X становить sps_max_dec_pic_buffering[ X ] для кожного X в інтервалі 0 - sps_max_temporal_layers_minus1 включно. Змінна SubPicCpbPreferredFlag або специфікується зовнішнім засобом або, коли вона не специфікована зовнішнім засобом, встановлюється рівною 0. Змінна SubPicCpbFlag одержується наступним чином: SubPicCpbFlag = SubPicCpbPreferredFlag && sub_pic_cpb_params_present_flag 4 UA 114909 C2 5 10 15 20 25 30 35 40 45 50 55 Якщо SubPicCpbFlag дорівнює 0, то CPB працює на рівні блока доступу і кожен декодувальний блок є блоком доступу. Інакше, CPB працює на рівні фрагмента картинки і кожен декодувальний блок є підмножиною блока доступу. HRD працює наступним чином. Дані, зв‘язані з декодувальними блоками, які вставляються в CPB згідно з специфікованим графіком надходження, подаються за допомогою HSS. Дані, зв‘язані з кожним декодувальним блоком, видаляються і миттєво декодуються способом миттєвого декодування в моменти видалення в CPB. Кожну декодовану картинку поміщають в DPB. Декодовану картинку видаляють з DPB пізніше за DPB годину виходу або годину, коли він стає більше не потрібним для посилання на інтерпрогнозування. HRD ініціалізується, як специфіковано SEI періодом буферизації. Синхронізація видалення декодувальних блоків з CPB і синхронізація виходу декодованих картинок з DPB специфіковано в SEI повідомленні синхронізації картинки. Уся інформація синхронізації, яка відноситься до спеціального декодувального блока, повинна надходити до моменту видалення з CPB декодувального блока. HRD використовують для перевірки узгодженості потоків бітів і декодерів. Хоча узгодженість гарантується згідно з припущенням, що всі частоти кадрів і тактових генераторів, використовувані для генерування потоку бітів, точно відповідають величинам, сигналізованим в потоці бітів, в реальній системі, при цьому кожна з цих величини може відрізнятися від сигналізованої або специфікованої величини. Усі арифметичні операції проводяться з реальними величинами таким чином, що не можуть поширюватися помилки округлення. Наприклад, кількість бітів в CPB безпосередньо перед або після видалення декодувального блока необов‘язково є цілим числом. Змінна tc одержується наступним чином і називається тактом тактового генератора. tc = num_units_in_tick time_scale Змінна tc_sub одержується наступним чином і називається тактом тактового генератора фрагмента картинки: tc_sub = num_units_in_sub_tick time_scale Наступне вказується для вираження обмежень: - Нехай блок доступу n буде n-м блоком доступу в порядку декодування, при цьому перший блок доступу є блоком доступу 0. - Нехай картинка n буде кодованою картинкою або декодованою картинкою блока доступу n. - Нехай декодувальний блок m буде m-м декодувальним блоком в порядку декодування, при цьому перший декодувальний блок є декодувальним блоком 0. В документі [2] синтаксис заголовка вирізки передбачений для так званих залежних вирізок. Фіг. 8 зображає синтаксис заголовка вирізки документа [2]. Семантика заголовка вирізки визначається наступним чином: dependent_slice_flag equal to 1 вказує, що величина кожного відсутнього синтаксичного елемента заголовка вирізки вважається рівною величині відповідного синтаксичного елемента заголовка вирізки в попередній вирізці, яка містить кодувальний деревоподібний блок, адресою якого є SliceCtbAddrRS − 1. Коли він відсутній, величина dependent_slice_flag вважається рівною 0. Величина dependent_slice_flag повинна дорівнювати 0, коли SliceCtbAddrRS дорівнює 0. slice_address вказує адресу в гранулярності вирізки, у якій починається вирізка. Довжина синтаксичного елемента slice_address дорівнює ( Ceil( Log2( PicWidthInCtbs * PicHeightInCtbs ) ) + SliceGranularity ) біт. Змінна SliceCtbAddrRS, яка вказує кодувальний деревоподібний блок, у якому починається вирізка в порядку проходження растру кодувального деревоподібного блока, одержується наступним чином. SliceCtbAddrRS = ( slice_address >> SliceGranularity ) Змінна SliceCbAddrZS, яка вказує адресу першого кодувального блока у вирізці в гранулярності мінімального кодувального блока в порядку z-проходження, одержується наступним чином. SliceCbAddrZS = slice_address
ДивитисяДодаткова інформація
Назва патенту англійськоюVideo data stream concept
Автори англійськоюSchierl, Thomas, George, Valeri, Henkel, Anastasia, Marpe, Detlev, Gruneberg, Karsten, Skupin, Robert
Автори російськоюШирль Томас, Георге Валери, Хенкель Анастасия, Марпэ Дэтлеф, Грюнэбэрг Карстэн, Скупин Роберт
МПК / Мітки
МПК: H04N 7/00, H04N 21/00
Мітки: потоку, відеоданих, концепція
Код посилання
<a href="https://ua.patents.su/66-114909-koncepciya-potoku-videodanikh.html" target="_blank" rel="follow" title="База патентів України">Концепція потоку відеоданих</a>
Попередній патент: Джерело струму для дугового зварювання, наплавлення або паяння плавким електродом
Наступний патент: Композиція, що містить надпоглинаючий полімер
Випадковий патент: Спосіб оцінки токсичності водного середовища за допомогою ліпідів організму риб