Предыдущая тема :: Следующая тема |
Автор |
Сообщение |
N Stanislav

Зарегистрирован: 12.04.2004 Сообщения: 627 Откуда: г.Воронеж
|
Добавлено: Сб Ноя 26, 2011 22:28 Заголовок сообщения: |
|
|
Вопрос наверно больше к Евгению CrazyCat.
Наверняка для многих не секрет, что в стандарте DVBS2 мультистрим - это не только разные транспортные потоки с одинаковыми параметрами модуляций и коррекции ошибок.
Но есть тип мультистрим потоков, где на каждый транспортный поток свой тип модуляции.
Вот пример:
Frequency: 4094.951 Mhz
Symbol rate: 29999 KS
Polarization: Vertical
Spectrum: Normal
Standard/Modulation: DVB-S2/32APSK
FEC: 3/4
RollOff: 0.25
Pilot: on
Coding mode: ACM/VCM
Short frame
Generic continous stream
Multiple input stream
Input Streams IDs: 0
RF-Level: -41 dBm
Signal/Noise: 4.9 dB
Carrier width: 37.499 Mhz
BitRate: 111.596 Mbit/s
Как видно, параметры потока далеко не полные. Т.к. определен единственный тип модуляции присутствующий в потоке (хотя типов там порядка 4-5 различных) и не определены номера входных потоков, т.к. как я понимаю здесь многопоточность на уровне типов модуляций, а не stream ID.
Вопрос вот в чем, как на карте залочить принудительно определенный тип модуляции и фек. Ну и второе - возможно ли при сканировании определить все типы модуляций идущие в потоке.
Из-за того что карта постоянно скачет по типам модуляций - имеем большое количество ошибок и невозможность собрать картику.
Вышеприведенный пример, это характеристики транспондера в generic stream, на одном из потоков которого открыто вещает FoxNews. _________________ 2.5м 15W-76E (C circular +Ku) 3.8м 17Е-113Е (C linear + Ku)
Skype: nstanislav_satellite |
|
Вернуться к началу |
|
 |
crazycat

Зарегистрирован: 12.08.2011 Сообщения: 2279 Откуда: Ukraine, Kharkov
|
Добавлено: Сб Ноя 26, 2011 22:51 Заголовок сообщения: |
|
|
действительно, возможно совмещение фреймов с разным modcode. Комбинирование модуляций также бывает, чаще 16APSK+QPSK, 32APSK+QPSK. Обычно в разных субпотоках идут данные на приемные станции с разными условиями приема, что и обуславливает использование технологии ACM (параметры модуляции адаптирутируют на передающей стороне в зависимости от условий приема).
у меня при слепом поиске выдает modcode для какого-то одного захваченого фрейма (точнее первого не пустого). А вот номера субпотоков определяет опросом MATYPE от 30 фреймов (уже точно не помню). Вообщем ориентировано прежде всего на мультистримы с DVB-T. Всякие навороченные ACM-транспондеры с экзотическими комбинациями модуляции меня не очень интересовали. _________________ Dish Strong 0.95m + Motor PowerTech DG240 + LNB Ku-Universal, Dish Variant CA-902 0.95m + LNB 4W-5E+13E Ku-Universal, STB StarTrack-X1150CU@X800, PC DVB-S/S2 card - Omicom S2 PCI, PC DVB-T/T2 - TBS 6220 PCI-E |
|
Вернуться к началу |
|
 |
Sat-Digest Site Admin

Зарегистрирован: 02.04.2004 Сообщения: 5123 Откуда: Европа
|
Добавлено: Пн Ноя 28, 2011 15:06 Заголовок сообщения: |
|
|
N Stanislav писал(а): | Вопрос вот в чем, как на карте залочить принудительно определенный тип модуляции и фек. Ну и второе - возможно ли при сканировании определить все типы модуляций идущие в потоке.
Из-за того что карта постоянно скачет по типам модуляций - имеем большое количество ошибок и невозможность собрать картику. |
Так ведь если всё идёт под одним stream ID, то его и следует воспринимать как единый неделимый поток, вне зависимости от того, в каких модуляциях и FEC идут его пакеты.
Классически, варианты применения технологии динамической смены параметров разделяют на два случая:
1. VCM - Variable coding and modulation.
Может применяться для ТВ. Каждый субпоток идёт со своей фиксированой комбинацией модуляции и FEC.
2. ACM - Adaptive coding and modulation.
Субпотоков может быть один или несколько. Режим требует обязательной обратной связи с приёмной станцией, поэтому для телевещания обычно не применяется. В рамках каждого субпотока параметры меняются динамически, в зависимости от условий на приёме.
На практике это всё достаточно условно и могут возникать различные комбинации режимов для конкретных нужд.
Поддерживаю пожелание видеть в CrazyScan все варианты используемых режимов модуляции и FEC, желательно собрать значения за время рисования созвездия и потом представить в виде таблички с количеством (или процентом) встреченных фреймов для каждого режима. Так можно будет видеть, какой режим используется больше, а какой меньше.
В представленном примере потока используется режим Generic continous stream. Это режим для передачи данных прямо в Baseband фреймах, не используя вообще TS контейнер. Сейчас пытаюсь понять, есть ли стандартизация на этот режим работы.
Нашёл стандарт DVB-GSE - Generic Stream Encapsulation (GSE Protocol).
Вполне возможно, что именно в этом стандарте идут данные в режиме Generic continous stream, нужно только реализовать софт, который превращает их в вид, удобный для анализа.
http://www.etsi.org/deliver/etsi_ts/102600_102699/102606/01.01.01_60/ts_102606v010101p.pdf
http://www.etsi.org/deliver/etsi_ts/102700_102799/102771/01.02.01_60/ts_102771v010201p.pdf
Предлагаю ознакомиться.
Полезная нагрузка (PDU на схеме - Ethernet, IP) может распределяться на несколько GSE пакетов, которые могут быть переменной длинны для оптимальной стыковки с полезной нагрузкой. Максимальный размер GSE пакета - 4 КБ. Максимальное количество фрагментов PDU, которые могут одновременно присутствовать в одном GS потоке - 256. Несколько GSE пакетов могут быть помещены в один BaseBand Frame. Фрагментация GSE пакета на два фрейма не допускается. BB Frame в потоке могут быть фиксированной или переменной длинны и каждый Frame может иметь свои независимые параметры модуляции и FEC.
Как я понимаю, поток из BB Frame фиксированной длинны называется Generic packetized stream, а поток из BB Frame переменной длинны - Generic continous stream. Имеются в виду потоки, содержащие GSE пакеты.
В режиме ACM допускается, что приёмник сможет принять только часть фреймов, которые будут в модуляции/FEC, которые возможно принять при данных условиях (размер антенны, погодные условия). С учётом этого данные распределяются между фреймами таким образом, чтобы каждая приёмная станция смогла получить предназначенные ей данные.
Использование для передачи данных GSE протокола (доступен только в DVB-S2) позволяет уменьшить накладные расходы по сравнению c режимом MPE/MPEG-TS (данные поверх MPEG-TS) с 10% до 2-3%.
В стандарте DVB-GSE указано, что GSE поддерживает инкапсуляцию множества протоколов, в том числе Ethernet, IPv4, IPv6, MPEG2-TS.
Возможно, что именно в таком экзотическом виде - MPEG2-TS поверх GSE передаётся телеканал FoxNews в пакете, который приводил в пример N Stanislav. На каком спутнике работает этот пакет?
В таком случае действительно, телеканал может работать в одном пакете с данными, который работает в ACM режиме, но фреймы с GSE пакетами, содержащими телеканал, могут идти с одинаковыми стабильными параметрами модуляции и FEC (нет смысла вещать телеканал с динамичными модуляцией и FEC). Как я понимаю, и пакеты с данными и пакеты с ТВ могут находиться в едином стриме, и разделяться уже на уровне наполнения GSE пакетов путём фильтрования GSE пакетов на основе названия протокола.
Такой режим описан в разделе 7.2 в DVB-GSE implementation guidelines.
Также возможно, что телеканал работает просто в MPEG-TS поверх IP.
Уточню, что режимы Generic stream на сегодня способна принимать по сути только плата TBS 6925.
Было бы хорошо реализовать в CrazyScan для начала хоть базовый анализ GS потоков, например, определять какие протоколы используются в полезной нагрузке GSE пакетов. В будущем теоретически хотелось бы анализировать потоки более предметно.
ID протокола нагрузки GSE пакета такой же, как используется в MPE/MPEG-TS.
Возможно ли перепаковывать содержимое GSE пакетов в пакеты MPE/MPEG-TS и отправлять для дальнейшего анализа в TS Reader?
Может для начала можно отлавливать GSE пакеты, в которых идёт MPEG2-TS (как в пакете в примере N Stanislav) и перенаправлять его в TS Reader?
Я тут набрёл на радикальный доклад на одной из конференций, предлагающий в будущем полностью перейти на вещание только через GSE пакеты (которые позволяют передавать и MPEG-TS и IP-данные), сделав все другие режимы частными случаями GSE пакетов, и благодаря этому убрать из заголовка BB-фреймов большинство ненужных полей, сэкономив при этом часть полосы!
http://www.scribd.com/doc/52525241/Optimization-of-the-headers-in-DVB-S2-and-GSE-for-conveying-IP-packets-over-GSE-v04 _________________ С уважением,
Андрей Ищенко.
Последний раз редактировалось: Sat-Digest (Вт Ноя 29, 2011 21:48), всего редактировалось 8 раз(а) |
|
Вернуться к началу |
|
 |
crazycat

Зарегистрирован: 12.08.2011 Сообщения: 2279 Откуда: Ukraine, Kharkov
|
Добавлено: Вт Ноя 29, 2011 19:26 Заголовок сообщения: |
|
|
все это конечно интересно, но обработка потока в виде фреймов предполагаеться на коммуникационном процессоре, который получает поток от демодулятора через расширенную транспортную шину (две дополнительные сигнальные линии, сигнализирующие передачу различных секций фрейма).
Что касаеться классических PC DVB девайсов, то медиамосты на них заточены исключительно на прием транспортного потока (небольшие пакеты 188 или 131 байт, через паралельную или последовательную транспортную шины с дополнительным сигналом SYNC начала нового пакета ). На TBS 6925 V2 применен трюк в виде ПЛМ-микросхемы для 'адаптации' фреймового потока в транспортный (попросту отсчитывает 188 байт и генеририет SYNC). Собственно в последних драйверах режим адаптации по умолчанию отключен (передается сигнал SYNC от демода) и включить его можно через какое-то расширение драйвера (с фирменного TSRecorder это как-то делается). Практического применения все это трюкачество не имеет, так как нет контроля целосности принятых фреймов (непонятно с какого места начнеться передача, где там какие секции). _________________ Dish Strong 0.95m + Motor PowerTech DG240 + LNB Ku-Universal, Dish Variant CA-902 0.95m + LNB 4W-5E+13E Ku-Universal, STB StarTrack-X1150CU@X800, PC DVB-S/S2 card - Omicom S2 PCI, PC DVB-T/T2 - TBS 6220 PCI-E |
|
Вернуться к началу |
|
 |
N Stanislav

Зарегистрирован: 12.04.2004 Сообщения: 627 Откуда: г.Воронеж
|
Добавлено: Вт Ноя 29, 2011 19:57 Заголовок сообщения: |
|
|
Хорошо, если мы не сможем полноценно реализовать особенности GS потоков, то можем хотя бы определить типы ВВ-фреймов идущих в потоке (модуляция, фек)? И попытаться сделать фильтрацию фреймов по типу модуляции?
Например, стандартный DVB-софт (AltDVB к примеру) умудряется каким-то чудом выцепить из GS потока таблицы TS и прописать видео-канал.
PS: количество транспондеров работающих в GSE уже на сегодняшний момент очень велико! _________________ 2.5м 15W-76E (C circular +Ku) 3.8м 17Е-113Е (C linear + Ku)
Skype: nstanislav_satellite |
|
Вернуться к началу |
|
 |
Sat-Digest Site Admin

Зарегистрирован: 02.04.2004 Сообщения: 5123 Откуда: Европа
|
Добавлено: Вт Ноя 29, 2011 22:00 Заголовок сообщения: |
|
|
crazycat писал(а): | На TBS 6925 V2 применен трюк в виде ПЛМ-микросхемы для 'адаптации' фреймового потока в транспортный (попросту отсчитывает 188 байт и генеририет SYNC).
...
Практического применения все это трюкачество не имеет, так как нет контроля целосности принятых фреймов (непонятно с какого места начнеться передача, где там какие секции). |
Мы ж вроде делали на TBS 6925 запись сырого потока BB-фреймов пакета Зеонбуда через StreamReaderDemo, отключая PID-фильтрацию. Или это были не BB-фреймы? Тогда что?
Если можно записать поток BB-фреймов, то я думал возможно программно его проанализировать, прочитать заголовки BB-фреймов, взять содержимое фреймов, в которых лежат GSE пакеты.
Все заголовки и расположение пакетов документированы в DVB стандартах.
Где я ошибаюсь? _________________ С уважением,
Андрей Ищенко. |
|
Вернуться к началу |
|
 |
crazycat

Зарегистрирован: 12.08.2011 Сообщения: 2279 Откуда: Ukraine, Kharkov
|
Добавлено: Вт Ноя 29, 2011 22:06 Заголовок сообщения: |
|
|
N Stanislav писал(а): |
Coding mode: ACM/VCM
Short frame
Generic continous stream
Multiple input stream
Input Streams IDs: 0
|
так всего один субпоток, что там определять ? все фреймы для субпотока идут с одним modcode. _________________ Dish Strong 0.95m + Motor PowerTech DG240 + LNB Ku-Universal, Dish Variant CA-902 0.95m + LNB 4W-5E+13E Ku-Universal, STB StarTrack-X1150CU@X800, PC DVB-S/S2 card - Omicom S2 PCI, PC DVB-T/T2 - TBS 6220 PCI-E |
|
Вернуться к началу |
|
 |
Sat-Digest Site Admin

Зарегистрирован: 02.04.2004 Сообщения: 5123 Откуда: Европа
|
Добавлено: Вт Ноя 29, 2011 22:12 Заголовок сообщения: |
|
|
crazycat писал(а): | так всего один субпоток, что там определять ? все фреймы для субпотока идут с одним modcode. |
Да ничего подобного! Это для телевещания каждый стрим идёт строго с постоянными modcode. А для передачи данных в ACM modcode у каждого фрейма может быть разный, но принадлежать все фреймы могут к одному стриму.
Достаточно опыта просмотра созвездий, когда по созвездию видно, что в нём присутствуют больше одной модуляции, при этом стрим один.
ACM даже есть и в TS потоках.
Вот, пожалуйста, 53E:
Этот ACM поток у меня успешно перенаправляется в TS Reader.
 _________________ С уважением,
Андрей Ищенко. |
|
Вернуться к началу |
|
 |
N Stanislav

Зарегистрирован: 12.04.2004 Сообщения: 627 Откуда: г.Воронеж
|
Добавлено: Ср Ноя 30, 2011 5:57 Заголовок сообщения: |
|
|
crazycat, ну как там может быть один суббпоток, если фреймы идут с разными типами модуляций!
А во-вторых, заметил, что любой GS поток определяет с ID - 0.
Если частоту где идет GS-поток несколько раз просканировать, то каждый раз разная модуляция определяется, иногда - очень редко появляются ID отличные от 0. _________________ 2.5м 15W-76E (C circular +Ku) 3.8м 17Е-113Е (C linear + Ku)
Skype: nstanislav_satellite |
|
Вернуться к началу |
|
 |
crazycat

Зарегистрирован: 12.08.2011 Сообщения: 2279 Откуда: Ukraine, Kharkov
|
Добавлено: Ср Ноя 30, 2011 21:18 Заголовок сообщения: |
|
|
N Stanislav, да потому что это вообще левые значения, гляньте на SNR А на констеляции будет сплошное пятно
Скорее всего сканируете с опцией TrickAPSK в конфиге стримридера, и в этом случае не производится проверка FEC lock и тем более Stream lock. Эта экспериментальная опция для того чтобы иметь возможность блиндсканить APSK-транспондеры на железках с STV090xBA (с опциями отсеивания транспондеров с SNR менше заданых в MinSR1, MinSR2).
P.S. О нормальном приеме 16APSK можно говорить при SNR 13-14dB и выше, а 32APSK вообще 16-18 и выше. Для 8PSK примерно 7-8dB. _________________ Dish Strong 0.95m + Motor PowerTech DG240 + LNB Ku-Universal, Dish Variant CA-902 0.95m + LNB 4W-5E+13E Ku-Universal, STB StarTrack-X1150CU@X800, PC DVB-S/S2 card - Omicom S2 PCI, PC DVB-T/T2 - TBS 6220 PCI-E |
|
Вернуться к началу |
|
 |
Sat-Digest Site Admin

Зарегистрирован: 02.04.2004 Сообщения: 5123 Откуда: Европа
|
Добавлено: Чт Янв 12, 2012 2:25 Заголовок сообщения: |
|
|
N Stanislav писал(а): | Каждый поток имеет свой StreamID:0, разделение данных тут происходит по типу модуляции. |
Не совсем так.
Из того, что я вычитал в стандарте DVB-GSE, более общим логическим понятием является именно Stream, а не тип модуляции. В рамках одного стрима в GSE пакетах могут идти один или несколько потоков различных данных - ТВ, интернет и т.п. Тип данных указан в заголовке GSE пакета. (см. рисунок).
Каждый BB-Frame имеет в заголовке номер стрима, к которому он принадлежит и каждый BB-Frame может иметь свои параметры модуляции/FEC.
Чуть позже обязательно дополню разъяснение стандарта DVB-GSE.
Если есть конкретные вопросы - спрашивайте - я вычитаю и разъясню, что сказано в стандарте.
 _________________ С уважением,
Андрей Ищенко. |
|
Вернуться к началу |
|
 |
crazycat

Зарегистрирован: 12.08.2011 Сообщения: 2279 Откуда: Ukraine, Kharkov
|
Добавлено: Чт Янв 12, 2012 4:22 Заголовок сообщения: |
|
|
Формально каждый фрейм может быть в разной модуляции, с индивидуальным FEC (modcode). Особый случай - dummy frame, тоесть пустышка как аналог пакета с PId=8191 в DVB-S (на констеляции жирное пятно на PI/4).
На практике можно видеть совмещение фреймов в QPSK с высокой помехозащищенностью (FEC=1/2 и менше) + 8PSK,16APSK,32APSK. Типа критичные секции в фреймах с повышенной момехозащищенностью (заголовки, контрольные суммы). Тоесть это на практике технологии DVB-S2 ACM для передачи данных (типа FlexACM от NewTec). Впринципе там может быть и мультистрим, типа прямой канал на разные точки с индивидуальными параметрами модуляции. Но обычно можно наблюдать низкоскоростные транспондеры с одним субпотоком в комбинированой модуляции, тоесть в одну точку.
Что касается инкапсуляции данных в фрейма в GS-потоке - то там нет формальных стандартов. GSE - лишь одна вариация от ETSI, тупая как бревно. Там может быть все что угодно и реальная обработка этого 'мусора' возможна только на коммуникационном процессоре через расширенную транспортную шину с демода. То что там что-то с TBS6925V2 предается через тупую схемку отсчета 188 байтов - полнейшая ахинея. Там непонятно где какая секция фрейма и если идут ошибки там все превращается в кашу. _________________ Dish Strong 0.95m + Motor PowerTech DG240 + LNB Ku-Universal, Dish Variant CA-902 0.95m + LNB 4W-5E+13E Ku-Universal, STB StarTrack-X1150CU@X800, PC DVB-S/S2 card - Omicom S2 PCI, PC DVB-T/T2 - TBS 6220 PCI-E |
|
Вернуться к началу |
|
 |
Sat-Digest Site Admin

Зарегистрирован: 02.04.2004 Сообщения: 5123 Откуда: Европа
|
Добавлено: Чт Окт 04, 2012 2:42 Заголовок сообщения: |
|
|
crazycat писал(а): | кстати этот 12645 16APSK вполне может быть с транспортным потоком, только на модуляторе врубили что лажовую инфу о том что Generic continous в MATYPE передавало и соотв. вводить демод на приемном оборудовании в блудняк (STV0900AA уж точно).
у кого TBS6925 - запишите кусок потока с этого транса через CrazyScan или фирменный TBSRecorder. При условии что сигнал хотя-бы SNR 12dB  |
Перенёс сюда обсуждение по поводу пакета на 72E, 12645H в 16APSK/CCM.
Не думаю, что там какая-то ошибка. Скорее там именно телеканал работает в Generic Stream Encapsulation.
Думаю надо начинать копать от того, как в этом потоке выделить отдельные BB-фреймы. Например по какой-то маске, характерной только для заголовка BB-фрейма. Можно определить такую маску?
В заголовке мы найдём длину полезной нагрузки фрейма.
Затем за заголовком BB-фрейма идёт заголовок GSE-пакета, в котором также содержится длинна полезной нагрузки GSE фрейма, а также тип нагрузки - Protocol Type.
Значения Protocol Type назначаются в соответствии с RFC 4326:
(The set of values that may be assigned to this field is divided into two ranges, similar to the allocation of Ethernet and
shall follow the rules described in RFC 4326)
http://www.ietf.org/rfc/rfc4326.txt
Значение Protocol Type от нуля до 0x0599 - это, как я понял, нечто вроде Ethernet-пакета.
Protocol Type от 0x0600 до 0xFFFF - это нагрузка данными, маркируемая аналогично таковой в Ethernet-пакетах:
http://standards.ieee.org/develop/regauth/ethertype/eth.txt
Например, 0x0800 - это IPv4.
Как обозначается нагрузка в виде MPEG-2 TS - пока не понял.
Ещё момент для более полного понимания. Если в пакете несколько стримов, то, цитирую:
"In DVB-S2, multiple streams may be multiplexed at the transmitter. Generic Stream Encapsulation (including fragmentation) shall be carried out separately for the incoming data of each generic stream. Each stream is identified by a specific Input Stream Identifier (ISI)."
Т.е. в Generic пакетах после BB-фрейма следующее, что мы отбираем - это BB-фреймы одного выбраного стрима (в том числе с разными modcode!), отбрасывая другие фреймы. В пакете на 72E стрим один, так что тут случай проще.
http://www.etsi.org/deliver/etsi_ts/102700_102799/102771/01.02.01_60/ts_102771v010201p.pdf
Тут на стр. 30-31 уточняется, чем характеризуются GS-потоки при CCM и ACM/VCM.
-------------------------------------------------------------------------------------------------------------------------
Через несколько дней....
CrazyCat подсказал, что для записи сырых BB-фреймов в StreamReader.ini нужно включить опцию FrameMode=1 и убедиться, что установлено NoPidFilter=1. После этого лочим сигнал в CrazyScan и ставим птичку "Поток в файл", выбираем имя файла, нажимаем кнопку "DVB", пишем данные в файл.
Вот кусок, который я записал в таком режиме с 72E, 12645H:
http://www.ex.ua/view_storage/497059220523
Для просмотра данных я использовал редактор WinHex.
http://www.x-ways.net/winhex.zip
Воспользуемся документом ETSI EN 302 307, описывающим стандарт DVB-S2, и попробуем разобраться в потоке.
http://www.etsi.org/deliver/etsi_en/302300_302399/302307/01.02.01_40/en_302307v010201o.pdf
Удалось легко найти заголовок BB-фрейма, т.к. там полно фреймов без данных и заголовки торчат, как палки среди пустого поля.
Вот содержание заголовка BB-фрейма (10 байт):
72 00 00 00 BC C8 00 00 00 5C
Расшифруем заголовок.
72 - это первая половинка Matype
Раскладываем в двоичный код:
0111 0010
01 - это Generic continuous поток
1 - Single stream
1 - CCM
0 - ISSYI - нет
0 - Null Packet Deletion - нет
10 - Roll-Off = 0,20
Всё совпало с данными, показанными CrazyScan при локе сигнала!
После 72 в заголовке идёт 00. Если бы это был мультистрим, то вместо 00 был бы ISI (Input Stream Identifier).
Далее, UPL (User Packet Length) = 00 00. Для GS-потоков там всегда нули.
DFL = BC C8 - длина поля данных фрейма в битах, т.е. в байтах будет 0x1799
Ставим курсор сразу за заголовком, нажимаем Alt-G (Go To Offset...), ввожу 1799, выбираем "relative to current position", OK. И попадаем как раз на начало заголовка следующего BB-фрейма. Теория совпала с практикой!
Дальше будем анализировать заголовок GSE-пакета, идущий сразу за заголовком BB-фрейма.
В потоке встречаются как пустые фреймы-заглушки, фреймы, где данных мало, и фреймы, забитые данными.
Заглядываем в документы, описывающие стандарт DVB-GSE:
http://www.etsi.org/deliver/etsi_ts/102600_102699/102606/01.01.01_60/ts_102606v010101p.pdf
http://www.etsi.org/deliver/etsi_ts/102700_102799/102771/01.02.01_60/ts_102771v010201p.pdf
Структура заголовка GSE-пакета:
Белым отмечены обязательные поля, а заштрихованы - необязательные.
Продолжу анализ позже... _________________ С уважением,
Андрей Ищенко. |
|
Вернуться к началу |
|
 |
crazycat

Зарегистрирован: 12.08.2011 Сообщения: 2279 Откуда: Ukraine, Kharkov
|
Добавлено: Вс Дек 23, 2012 22:22 Заголовок сообщения: |
|
|
Нашел кое-что по обработке фреймового потока в линуховом мире
Еще в 2007 году Christian Prähauser (учавствовал в реализации поддержки MPE-IP и ULE в V4L dvb-net) предложил реализацию поддержки обработки фреймового потока на уровне V4L демукса - http://www.linuxtv.org/pipermail/linux-dvb/2007-December/022217.html. Фильтрация главным образом по типу потока и IS ID (для мультистрима). Понятно что оно тогда тестировалось на дампе с файла и писалось под доклад на конференции (http://202.194.20.8/proc/ASMS2008/DATA/B-14-03.PDF). Да и там оно расчитано что на обработку поступает один фрейм (BBHeader + данные).
В конце прошлого года в контексте обсуждения моих патчей для поддержки аппаратной MIS-фильтрации возникла дисскусия о программной обработке фреймов http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/42312 (Konstantin Dimitrov пишет драйвера для TBS под linux). Ну и в последствии Christian адаптировал свои прежние "потуги" под текущие V4L-дрова TBS, а Konstantin это дело "подрихтовал" Я сегодня пробовал, что-то нихрена не заработало (вообще перестало даже транспортные потоки на всех железках обрабатывать). Но не в этом суть, а главное что понял как BBHeader находить в "валовом" потоке от TBS6925/6926 - вычисляем контрольную сумму 9 байт и сравниваем с 10 байтом (и так сдвигаемся пока не найдем корректный BBHeader и по нему уже опеределяем длинну данных в фрейме). _________________ Dish Strong 0.95m + Motor PowerTech DG240 + LNB Ku-Universal, Dish Variant CA-902 0.95m + LNB 4W-5E+13E Ku-Universal, STB StarTrack-X1150CU@X800, PC DVB-S/S2 card - Omicom S2 PCI, PC DVB-T/T2 - TBS 6220 PCI-E |
|
Вернуться к началу |
|
 |
Sat-Digest Site Admin

Зарегистрирован: 02.04.2004 Сообщения: 5123 Откуда: Европа
|
Добавлено: Вт Дек 25, 2012 1:40 Заголовок сообщения: |
|
|
crazycat писал(а): | ...а главное что понял как BBHeader находить в "валовом" потоке от TBS6925/6926 - вычисляем контрольную сумму 9 байт и сравниваем с 10 байтом (и так сдвигаемся пока не найдем корректный BBHeader и по нему уже опеределяем длинну данных в фрейме). |
Гениально и просто!
Как же мы не догадались!
Спасибо, отличная новость! Теперь дело за попыткой реализации.
Теоретически возможно случайное совпадение CRC с 9-ю байтами. Стоит проверять, чтобы совпадал не только текущий фрейм, но и следующий и только тогда считалось, что словили синхронизацию. И видимо после успешной синхронизации нужно будет продолжать проверять CRC заголовков фреймов и в случае несовпадения заново инициировать синхронизацию. _________________ С уважением,
Андрей Ищенко. |
|
Вернуться к началу |
|
 |
crazycat

Зарегистрирован: 12.08.2011 Сообщения: 2279 Откуда: Ukraine, Kharkov
|
Добавлено: Вт Дек 25, 2012 3:29 Заголовок сообщения: |
|
|
Sat-Digest писал(а): | Теоретически возможно случайное совпадение CRC с 9-ю байтами. |
вот это по-ходу самое страшное вчера в процессе реализации фильтрации фреймов в стримридере с этим столкнулся и по-ходу ситуация там патологическая - поэтому вся эта 'линуксовая братия' на все это дело скоропостижно забили  _________________ Dish Strong 0.95m + Motor PowerTech DG240 + LNB Ku-Universal, Dish Variant CA-902 0.95m + LNB 4W-5E+13E Ku-Universal, STB StarTrack-X1150CU@X800, PC DVB-S/S2 card - Omicom S2 PCI, PC DVB-T/T2 - TBS 6220 PCI-E |
|
Вернуться к началу |
|
 |
backspase
Зарегистрирован: 14.01.2013 Сообщения: 2 Откуда: RU
|
Добавлено: Пн Янв 14, 2013 23:48 Заголовок сообщения: |
|
|
Пробовал синхронизироваться в "валовом" потоке по заголовку BBHeader'ов все получается замечательно, использовал синхронизацию с проверкой CRC 10-го байта. На потоке размером 2 Гб "сбой синхронизации" был один раз.
CRC проверяю каждый раз, после смещения на следующий фрейм. _________________ TBS6925->more, more streams->happiness |
|
Вернуться к началу |
|
 |
crazycat

Зарегистрирован: 12.08.2011 Сообщения: 2279 Откуда: Ukraine, Kharkov
|
Добавлено: Вт Янв 15, 2013 0:24 Заголовок сообщения: |
|
|
ну я тоже попробовал, даже поддержку фильтрации BBFrame в тестовом стриридере сделал:
Код: | //BBFrame filter
STREAMREADER_API BOOL SetBBFilter(DWORD is, PVOID lpFunc, DWORD CallBackType, PDWORD lpFilter_num);
|
но "обломов" наблюдал гораздо больше (как GS-потоки ACM/VCM, так и обычные CCM транспортные с отключенным делинеатором). дело было перед НГ, так что мож где и накосячил  _________________ Dish Strong 0.95m + Motor PowerTech DG240 + LNB Ku-Universal, Dish Variant CA-902 0.95m + LNB 4W-5E+13E Ku-Universal, STB StarTrack-X1150CU@X800, PC DVB-S/S2 card - Omicom S2 PCI, PC DVB-T/T2 - TBS 6220 PCI-E |
|
Вернуться к началу |
|
 |
backspase
Зарегистрирован: 14.01.2013 Сообщения: 2 Откуда: RU
|
Добавлено: Ср Янв 16, 2013 21:22 Заголовок сообщения: |
|
|
Возможно не скажу ничего нового, но копаясь на просторах интернета наткнулся на интересную страничку:
http://wiki.wireshark.org/DVB-S2
Люди уже практически полностью сделали анализатор для потока DVB-S2, однако в последнюю сборку этот словарь пока не включен:
http://ask.wireshark.org/questions/16246/dvb-s2-dissector-missing-in-183
сборку 46080, которую упоминает спрашающий мне пока найти не удалось.
надеюсь кому нибудь повезет больше и он поделится ссылочкой.
а так жду выхода "стабильного" релиза WIRESHARK, и, возможно, многие вопросы станут яснее. _________________ TBS6925->more, more streams->happiness |
|
Вернуться к началу |
|
 |
crazycat

Зарегистрирован: 12.08.2011 Сообщения: 2279 Откуда: Ukraine, Kharkov
|
Добавлено: Ср Янв 16, 2013 21:33 Заголовок сообщения: |
|
|
Это передача фреймов через IP (UDP/RTP) или ASI. Главным образом это интерфейс между агрегатором и модулятором.
Также подобное реализовано в обновленном приемнике DekTec DTA-2137С - http://www.dektec.com/Products/PCIe/DTA-2137/index.asp
http://www.dektec.com/Products/PCIe/DTA-2137/Downloads/DT-AN-2137-1.pdf
P.S. К обработке "фреймового мусора" c TBS6925 это никакого отношения не имеет  _________________ Dish Strong 0.95m + Motor PowerTech DG240 + LNB Ku-Universal, Dish Variant CA-902 0.95m + LNB 4W-5E+13E Ku-Universal, STB StarTrack-X1150CU@X800, PC DVB-S/S2 card - Omicom S2 PCI, PC DVB-T/T2 - TBS 6220 PCI-E |
|
Вернуться к началу |
|
 |
|
|
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете голосовать в опросах
|
|