Есть небольшое пожелание насчёт лога: кидать сообщения в стандартный syslog, либо добавить к собственному логу временные метки. Без них ориентироваться в логе трудно.
Printable View
Есть небольшое пожелание насчёт лога: кидать сообщения в стандартный syslog, либо добавить к собственному логу временные метки. Без них ориентироваться в логе трудно.
Разница в журналах "хороших" и "плохих" каналов, выражающаяся в записях типа,
иллюстрирует вариации в размере пакетов, проходящих через udpxy. Буквально это означает следующее: "Размер нового пакета [xxx] отличен от размера прошлого пакета [yyy] (где разница превышает некую дельту = 32 байтам в сборке 27)". То же с помощью tcpdump уже продемонстрировал Oleg.Code:received new=[xxx] bytes, last=[yyy]
Итак, насколько я понял, vlc прекрасно "слушает" 240-е напрямую из сети (как UDP), но не берёт тот же поток, если он пропущен через udpxy.
Исходя из этого, мои подозрения концентрировались на возможных потерях пакетов - для борьбы с этим и добавлен параметр -R rec_count - udpxy буферизирует поток до rec_count пакетов или же на весь буфер (-B bufK -y), если rec_cout == -1. Пока что версия потерь потока не оправдывает ожиданий.
В связи с чем возникает версия с VBR - возможно, udpxy "коверкает" видео, закодированное с VBR - но видеофайлов с VBR у меня в тестах не было, каюсь (а я, увы, проверять работу приложения могу запуская содержимое файла в сеть с одного vlc - UDP проигрывая через udpxy - HTTP на другом vlc - iptv у меня нет). Попытаюсь нарыть видео с VBR (буду весьма признателен за URL для закачки с сети) и прогнать у себя - попробуйте и вы, у кого есть время, желание и возможности.
Отдельно - в сборке 27 есть параметры: -w filename - будет записывать данные в файл filename.pid (pid - udpxy-client process id) - если не пройдёт версия с файлом с VBR, то почему бы не получить кусок "плохого" канала, записанного таким образом - минуты на 2, например?... Проиграть данные можно параметром -r - данные по multicast каналу тогда игнорируются и чтение идёт из файла. Я пробовал уже - записанные фрагменты проигрываются. Если есть уже приложение, способное "выпихнуть" данные из файла снова на мультикаст, то чистота эксперимента должна быть высокой: берём отрезок потока с 240 и прокручивает как вне так и через udpxy - по идее вне udpxy vlc должен показать видео.
Но это на случай провала версии с VBR - если дело в нём, то всё "проще" (будем копаться в исходниках vlc).
Спасибо всем за участие в тестировании!
Про timestamps в журнале я позабочусь (можно было бы и в syslog всё класть, на засорять syslog не дело, а настраивать его не всякий сподобится).
Про исчезновение каналов multicast сказать мне пока нечего - udpxy достаточно стандартно "подписывается" на данный канал и "отписывается" от него в конце, пока что эта стратегия не создавала особых проблем.
Павел, мы тут уже баловались с записью через udpxy:
http://wl500g.info/showthread.php?t=12966
Записанный таким образом поток играется нормально. Т.е. кое-что проскакивает, но это потери пакетов по дороге от Корбины.
А вот в он-лайне совсем не хочет показывать.
Я выложил поток: http://oleg.wl500g.info/240.mpg (58 секунд, 38 мегабайт)
Выложите мне, пожалуйста, запись "проблемного" потока от Корбины (минуты на 1-2) через tcpdump -w.
Заранее благодарю,
Павел
Ссылку отправил в личкуQuote:
Originally Posted by bsl45
Записанный напрямую udpxy поток с 240 тоже квадратит. Удивительно, но записанный без участия udpxy поток tcpdump'a после конвертации pcap2mpeg представляет такое же зрелище.
Кстати, неплохо бы выделить запись в отдельную функцию, т.к. всё, что мы до сих пор придумали в соседней теме - костыли. Но и ключ -w в текущей форме тоже можно оставить. Можно даже запускать 2 копии udpxy на разных портах - с записью и без. Или включать запись через параметр URL. В общем, вариантов море. Но особо хотелось бы увидеть чисто-консольный вариант для запуска cron'ом или atd.
djet, поясните, пожалуйста, что значит "выделить запись в отдельную функцию" (если это отлично от варианта с параметром -w) - постараюсь обеспечить. По-моему, -w и есть чисто консольный вариант, но я явно чего-то не улавливаю - вот и прошу прояснить.
Также - киньте (кому не лень), пожалуйста, ещё один фрагмент - минут на 5 - записанный с Корбины udpxy сборки 27. Заранее благодарен.
И наконец хорошая новость: дефект удалось воспроизвести на (посторонних) видеофайлах.
Павел
Текущий вариант предполагает, что запись идёт при подключенном к udpxy клиенте. Хочется того же самого, но без необходимости создания подключения, даже фиктивного wget'ом. (wget ещё плох тем, что соединение может разрываться, вследствие запись прекращается)Quote:
Originally Posted by bsl45
Сегодня записал по просьбе Павла фрагмент проблемного канала через udpxy-0.1-27 c помощью wget и обнаружил интересную особенность. Записанный файл при проигрывании с помощью vlc квадратит точно так же, как и при прямом просмотре по http. В то же время, как уже отмечал Олег, mplayerc показывает его с существенно меньшими искажениями, многочисленные квадраты практически отсутствуют, наблюдаются лишь небольшие сбои типа выпадений сигнала с нарушениями синхронизации.Quote:
Originally Posted by bsl45
О как. Я даже не пробовал vlc.
Похоже дело в сплиттере внутри vlc. Надо смотреть, что он там такое ожидает. С другой стороны, можно этот поток отдать автору IPTV Player для изучения.
Попробовал открыть файл c помощью IPTVPlayer. Получил "мега-рассыпания", как при он-лайн просмотре.
Вопрос к Павлу: а как отсылаются полученные по юдп буфера? Каждый буфер с помощью отдельного send, или всё скопом?
Я вот заглянул в код vlc. Обработчик для udp потоков считает, что каждый блок должен начинаться с 0x47. Иначе он пытается трактовать как RTP.
if( p_block->p_buffer[0] == 0x47 )
{
msg_Dbg( p_access, "detected TS over raw UDP" );
Так вот. Смотрю захваченный поток.
Для 210 он действительно начинается с 0x47 0x02,
0000000000: 47 02 59 17 1B 6B 7B 27 │ E1 E5 04 14 78 43 16 23
а вот для 240:
0000000000: 80 21 F5 1E C8 21 FF E8 │ 79 6B 87 D4 47 02 59 18
Т.е. 47 02 оказалось где-то позади.
Вот формат MPEG TS (то, что гугль мне сходу дал)
http://www.erg.abdn.ac.uk/research/f...eg2-trans.html
http://www.erg.abdn.ac.uk/research/f...-ts-header.gifQuote:
Each MPEG-2 TS packet carries 184 B of payload data prefixed by a 4 B (32 bit) header.
The header has the following fields:
The header starts with a well-known Synchronisation Byte (8 bits). This has the bit pattern 0x47 (0100 0111).
A set of three flag bits are used to indicate how the payload should be processed.
The first flag indicates a transport error.
The second flag indicates the start of a payload (payload_unit_start_indicator)
The third flag indicates transport priority bit.
The flags are followed by a 13 bit Packet Identifier (PID). This is used to uniquely identify the stream to which the packet belongs (e.g. PES packets corresponding to an ES) generated by the multiplexer. The PID allows the receiver to differentiate the stream to which each received packet belongs. Some PID values are predefined and are used to indicate various streams of control information. A packet with an unknown PID, or one with a PID which is not required by the receiver, is silently discarded. The particular PID value of 0x1FFF is reserved to indicate that the packet is a null packet (and is to be ignored by the receiver).
The two scrambling control bits are used by conditional access procedures to encrypted the payload of some TS packets.
Two adaption field control bits which may take four values:
01 – no adaptation field, payload only
10 – adaptation field only, no payload
11 – adaptation field followed by payload
00 - RESERVED for future use
Finally there is a half byte Continuity Counter (4 bits)
Демуксер, кстати, в тупую ищет 0x47... А они там попадаются и просто так.
Мне кажется не в одтельную функцию, а в отдельную программу - полнофункциональный PVR с веб-интерфейсом.Quote:
Originally Posted by djet
C плейлистом, телегидом, управлением сделеанными записями, вещанием файлов в сеть. Могу приатачить картинки с дримбокса.
Разговариваю сам с сабой. :)
Смотрите, размер блока фиксированный: 188 байт. Занчит валидные пакеты имеют следующую длину:
188 200
376 388
564 576
752 764
940 952
1128 1140
1316 1328
В левой колонке - длина, в правой - длина+12.
Так вот в 210-х каналах всё чётко. Пакет имеет длину кратную 188. Обратите также внимание на флаг DF.
А в 240 всё не так. :) К каждой посылке добавляются какие-то 12 байт, за исключением пакетов длиной 1348 - там ещё 20 байт чего-то.
Ну а поскольку, дампа у меня под рукой нет, понять я больше ничего не могу. :) Может пакеты где-то по дороге нарезаются на части, но как-то "неудачно". :)
Спасибо всем, кто потратил время на анализ - я, собственно, занимался тем же, но не хотелось забегать вперёд повозки и озвучивать (пока ещё) непроверенные версии, появившиеся в результате изысканий.
До сих пор поток в udpxy не модифицировался вообще, однако теперь будет, поскольку при трянсляции из UDP в TCP/HTTP пакеты RDP нужно обрабатывать и выделять из них MPEG-TS (или какие ни есть иные) данные. Код обработки в udpxy уже пишется, код vlc относящийся к предмету, как и соответствующий RFC (3550) уже в работе. 12 "лишних" байт в потоке Корбины - это (предположительно) и есть заголовок RDP (0x80 0x21 согласно RFC 3550 обозначают RDP_version=2, payload_type=33 (0x21) - type 33, согласно vlc = TS over RTP).
Павел
Павел, если честно, то у меня есть ощущение, что udpxy не должен заниматься обработкой потока. Боюсь, что процессора не хватит.
_Гораздо_ более правильным будет добавить эту поддержку в http.c у vlc.
Там ведь, кроме TS есть ещё и другие типы.
С другой стороны, RTPшные заголовки там встречаются вроде не очень часто. Можно и проверять буфера. Но что делать с mpga/mpgv?
В общем в Корбине перемудрили. А у меня сложилось впечатление, что там сами слегка не понимают, что получилось. :)
Интересно, приставки Корбиновские на какие адреса подписываются?
До сегодняшнего дня все данные, при установке параметра -R count при count > 1 уходили скопом, т.е. N=count сообщений накапливались в едином буфере и посылались одним send. Как можно было убедиться, при "голом" MPEG-TS потоке такой подход вполне оправдан.Quote:
Originally Posted by Oleg
При обработке MPEG-TS on RDP я не уверен, что этот подход уместен (vlc надо разбирать пакеты, а длина данных в RDP-заголовке не указывается), но, естественно, проверю. Параметр -R (в сборке 27 и ранее) по умолчанию имеет значение 1, т.е. указывает на посылку каждого сообщения отдельным send.
Спасибо за ссылку на MPEG-TS спецификацию - как раз сегодня собирался её поискать, чтобы не полагаться вслепую на код vlc.
Павел
Мне кажется, что он и с RTP оправдан. Да и с чем угодно, наверное. Как-то ведь эти потоки читаются из файлов...Quote:
Originally Posted by bsl45
Я вот ещё подумал. :) Нужно править демуксер ts в vlc. Чтобы он там rtp понимал, в части выбрасывания этих хедеров при поиске MPEG TS. Тогда и захваченный поток он будет читать. Это конечно кривовато, но зато просто. :)
К сожалению, не нашёл исходников ts в media player classic, да и не особо искал...
Да, ещё гугль знает довольно много про RTP over HTTP.
Обработку, конечно, уместнее доверить vlc. Но - поддержку RTP я всё же добавлю - на упрощённом уровне (возможно, без отслеживания и реорганизации порядка пакетов, как это следано - по уму - в vlc) - и, разумеется, дам возможность эту поддержку включить/отключить при надобности.Quote:
Originally Posted by Oleg
Поддержка пригодится тем, к кого процессор помощней и тем, у кого будет старый vlc или какой-либо плеер, не обрабатывающий RTP-заголовки в HTTP-пакетах. Если станет критично по размеру кода, сделаем возможность добавления поддержки RTP как модуля при компиляции.
Павел
Павел, тогда вот у меня какое пожелание: сейчас udpxy обрабтывает url такого вида
http://host/udp/xxx:xxx
Добавьте ещё rtp:
http://host/rtp/xxx:xxx
И когда его так запрашивают, гоните поток по старому, но каждый пакет отдельным send, хотя не уверен, что tcp сохранит сообщения (скорее всего нет :( ). А длины там нет.
А вот если в командной строке указывают обработку rtp, то по первому url пусть идёт результат перекодирования потока. Надеюсь понятно объяснил...
Очевидно, что сейчас плейлист с 240 каналами неправильный: там должен быть указан протокол rtp, а не udp.
Либо наоборот: перекодирование осуществляется именно при обращении к rtp.
Так, наверное, будет наиболее правильно. Ибо я не хочу делать непонятную переключалку в веб-интерфейсе. Пусть лучше будет нормальный плейлист и плеер, который либо умеет декодировать rtp, либо передавать "правильный" url.
Кстати, реализовать такую схему можно уже сейчас:
Вот описание канала в плей-лист
#EXTINF:,240+1
http://192.168.0.1:2080/rtp/233.32.240.1:5050
И оно уже сейчас передаётся вот так:
GET /rtp/233.32.240.1:5050
В ответ udpxy должен начать перемалывать входной rtp поток и выдавать MPEG-TS. И vlc и IP TV player его с радостью прожуют.
Только просьба: не делайте в коде memcpy/memmove, когда будете выкидывать RTPшные заголовки. Возможно, для Вас это очевидно, а вот, скажем, писателям pptp клиента это чуждо было. :( Лучше используйте vectored write для посылки...
Это и вправду более-менее очевидно, но спасибо, что напомнили лишний раз - ибо бесы искушали :D Но не будет такого, позабочусь.Quote:
Originally Posted by Oleg
Обработку команды RTP на URL поставлю - и логика слегка упростится, поскольку не надо будет тестировать поток на RTP.
Не исключенно, что подаваемый в 240 поток "улучшен" технологиями MS, т.к. приставки подписываются именно на эти группы. 210 вроде бы как исходный поток, до транскодирования серверами платформы. Возможно, в будущем 210-е потоки закроют для ДС, останутся 240-е.
Кстати, у нас сейчас есть потоки с множеством каналов внутри, в 210-й пускают даже монстров 10-в-1. В связи с чем не помешала бы возможность выделять заданную программу (это поле PID?) из потока, т.к. 70 Мб/с не потянут ни wifi, ни подключенный HDD.
Это бесполезно. Роутер этот поток в любом случае обработать не успеет. Роутить сможет, а что-то ещё делать - нет. Так что монстров пусть на приставках смотрят. :)Quote:
Originally Posted by djet
Имхо, трансляция таких каналов для конечных пользователей - бредовая затея со стороны Корбины. Получается, что абонент получает поток гораздо шире, чем использует в каждый отдельный момент. Т.е., теряется весь смысл мультикастовой передачи. Тут я полностью согласен с Олегом: не стоит этим заморачиваться.Quote:
Originally Posted by djet
Олег, а можно расшифровать для чайников? Ты имеешь в виду вызовы readv()/writev()? А нет ли ссылок о сравнении производительности? Или выигрыш только на отсутствии memcpy() при сборке/вырезке фрагментов?Quote:
Originally Posted by Oleg
Для чайников. :D Да, речь про них. Выигрыш только в том, что memcpy/memmove не вызывается. Ибо каждое копирование зло.
Как делать неправильно (на примере пптп): эти редиски сначала получают в буфер ppp пакет от pppd, затем в другой функции делают буфер большего размера, в начале которого делают заголовок, а после заголовка копируют из первого буфера пакет. Потом второй буфер отсылают целиком. Этот пассаж заменяется на writev: отдельно хедер, отдельно данные, при этом сохраняется семантика: как было одно "сообщение", так и осталось (т.е. дважды вызывать write низя). Там правда есть и более простое решение: пакет от pppd можно было сразу получать во второй буфер, но у них там небольшое "затруднение" в виде хедера переменной длины, но это тоже решается легко и красиво. :) Я правда пошёл по простому пути - сделал writev, чтобы не перепахивать код...
Павел, ещё несколько моих соображений. :) Никаких векторных записей не нужно, на самом деле. :)
Я почитал немного гугль и понял, что в любом полученном по udp пакете может быть только один RTP заголовок (это ведь сообщение) и находится он всегда впереди. Т.е. Я бы решал задачу так: зарезервировал бы сколько-то буферов, длиной равной MTU интерфейса для приёма пакетов. Сделал бы там раунд-робин среди этих буферов. Далее делается просто цикл:
Вызывается poll для принимающего и передающего сокета. Если есть возможность послать - посылаем, если принять - принимаем. При отсылке просто передаём не весь буфер, а вычитаем длину RTP заголовка. Т.е. всё вроде просто.
Посмотрел пакеты длиной 1348 байт. Там стоит бит Х (0x9021) - т.е. за RTP заголовком идёт что-то дополнительное, длину которого понятно как определить. В общем, на производительности udpxy эта штука никак не скажется.
Code:15:24:47.547303 IP 172.16.16.70.1084 > 233.32.240.1.5050: UDP, length: 1364
0x0000: 4588 0570 3b91 0000 1711 cceb ac10 1046 E..p;..........F
0x0010: e920 f001 043c 13ba 055c 5f59 9021 ba98 .....<...\_Y.!..
0x0020: a80c c980 796b 87d4 100b 0008 0206 139c ....yk..........
0x0030: 59b3 8e0f 0306 0000 a80c 4677 010e 5301 Y.........Fw..S.
0x0040: a80c 469c cb5e b18e ebbd d547 4740 0019 ..F..^.....GG@..
0x0050: 0000 b00d 001f cb00 0000 10e0 20f7 574b ..............WK
0x0060: 8cff ffff ffff ffff ffff ffff ffff ffff ................
0x0070: ffff ffff ffff ffff ffff ffff ffff ffff ................
0x0080: ffff ffff ffff ffff ffff ffff ffff ffff ................
0x0090: ffff ffff ffff ffff ffff ffff ffff ffff ................
0x00a0: ffff ffff ffff ffff ffff ffff ffff ffff ................
0x00b0: ffff ffff ffff ffff ffff ffff ffff ffff ................
0x00c0: ffff ffff ffff ffff ffff ffff ffff ffff ................
0x00d0: ffff ffff ffff ffff ffff ffff ffff ffff ................
0x00e0: ffff ffff ffff ffff ffff ffff ffff ffff ................
0x00f0: ffff ffff ffff ffff ffff ffff ffff ffff ................
0x0100: ffff ffff ffff ffff 4740 2019 0002 b023 ........G@.....#
0x0110: 0010 cb00 00e2 59f0 0002 e259 f006 0904 ......Y....Y....
0x0120: 4ae2 ffe0 03e2 5af0 0609 044a e2ff e0af J.....Z....J....
0x0130: f622 40ff ffff ffff ffff ffff ffff ffff ."@.............
0x0140: ffff ffff ffff ffff ffff ffff ffff ffff ................
0x0150: ffff ffff ffff ffff ffff ffff ffff ffff ................
0x0160: ffff ffff ffff ffff ffff ffff ffff ffff ................
0x0170: ffff ffff ffff ffff ffff ffff ffff ffff ................
0x0180: ffff ffff ffff ffff ffff ffff ffff ffff ................
0x0190: ffff ffff ffff ffff ffff ffff ffff ffff ................
0x01a0: ffff ffff ffff ffff ffff ffff ffff ffff ................
0x01b0: ffff ffff ffff ffff ffff ffff ffff ffff ................
0x01c0: ffff ffff 475f e01a 0000 01f0 016a 13a8 ....G_.......j..
0x01d0: 0ce5 a000 0202 592f 0176 5eff 954b 7555 ......Y/.v^..KuU
0x01e0: 3300 00fa 007b 4fa2 1cc1 20c6 409f 9ef9 3....{O.....@...
0x01f0: 8b79 0530 ba00 03ed 0592 68a6 f52b 42f4 .y.0......h..+B.
0x0200: 9653 4c81 fd49 6d76 5eff 954b 7569 780c .SL..Imv^..Kuix.
0x0210: 8000 0000 00ff f1f0 0000 1c20 0000 0e10 ................
0x0220: 0000 3840 0000 2a30 0000 5460 0000 4650 ..8@..*0..T`..FP
0x0230: 0000 7080 0000 6270 0000 8ca0 0000 7e90 ..p...bp......~.
0x0240: 0000 025a 2f01 765e ff95 4b74 5b33 0000 ...Z/.v^..Kt[3..
0x0250: fa00 7b4f a21c c120 c640 9f9e f98b 7905 ..{O.....@....y.
0x0260: 30ba 0003 aeee 0d20 0b7c 46d6 8676 625e 0........|F..vb^
0x0270: 8a7c aaf3 765e ff95 4b74 61f5 0400 ffa1 .|..v^..Kta.....
0x0280: 471f e01b 1e00 ffcb 4e00 fff5 7e00 001f G.......N...~...
0x0290: ae00 00ff ffff ffff ffff ffff ffff ffff ................
0x02a0: ffff ffff ffff ffff ffff ffff ffff ffff ................
0x02b0: ffff ffff ffff ffff ffff ffff ffff ffff ................
0x02c0: ffff ffff ffff ffff ffff ffff ffff ffff ................
0x02d0: ffff ffff ffff ffff ffff ffff ffff ffff ................
0x02e0: ffff ffff ffff ffff ffff ffff ffff ffff ................
0x02f0: ffff ffff ffff ffff ffff ffff ffff ffff ................
0x0300: ffff ffff ffff ffff ffff ffff ffff ffff ................
0x0310: ffff ffff ffff ffff ffff ffff ffff ffff ................
0x0320: ffff ffff ffff ffff ffff ffff ffff ffff ................
0x0330: ffff ffff ffff ffff ffff ffff 4742 5915 ............GBY.
0x0340: 0000 01e0 0000 84c0 0a3d a033 cb41 1da0 .........=.3.A..
0x0350: 3393 0100 0001 b32d 0240 2312 1123 8210 3......-.@#..#..
0x0360: 2020 2620 262c 2c2c 2c2c 2c34 3034 3636 ..&.&,,,,,,40466
0x0370: 3634 3434 3436 3636 3a3a 3a44 4444 3a3a 64444666:::DDD::
0x0380: 3a36 363a 3a40 4044 444a 4c4a 4646 4446 :66::@@DDJLJFFDF
0x0390: 4c4c 5050 5060 605c 5c70 7074 8a8a a710 LLPPP``\\ppt....
0x03a0: 1111 1212 1213 1313 1314 1414 1414 1515 ................
0x03b0: 1515 1515 1616 1616 1616 1617 1717 1717 ................
0x03c0: 1717 1718 1818 1918 1818 191a 1a1a 1a19 ................
0x03d0: 1b1b 1b1b 1b1c 1c1c 1c1e 1e1e 1f1f 2100 ..............!.
0x03e0: 0001 b514 8200 0100 0000 0001 b52b 0202 .............+..
0x03f0: 020b 4212 0000 0001 4702 5936 8a00 ffff ..B.....G.Y6....
0x0400: ffff ffff ffff ffff ffff ffff ffff ffff ................
0x0410: ffff ffff ffff ffff ffff ffff ffff ffff ................
0x0420: ffff ffff ffff ffff ffff ffff ffff ffff ................
0x0430: ffff ffff ffff ffff ffff ffff ffff ffff ................
0x0440: ffff ffff ffff ffff ffff ffff ffff ffff ................
0x0450: ffff ffff ffff ffff ffff ffff ffff ffff ................
0x0460: ffff ffff ffff ffff ffff ffff ffff ffff ................
0x0470: ffff ffff ffff ffff ffff ffff ffff ffff ................
0x0480: ffff ffff ffff ffb8 8e2e a380 0000 0100 ................
0x0490: 004f fff8 0000 01b5 8fff f798 0000 0000 .O..............
0x04a0: 0101 337e 2912 faee 36c2 ac6f 4548 fd80 ..3~)...6..oEH..
0x04b0: 4a85 9edc 4702 5937 0710 d406 234e 7ea6 J...G.Y7....#N~.
0x04c0: 1229 429e debe d35a ab5d a8d4 5c24 7003 .)B....Z.]..\$p.
0x04d0: b76c 042f f9e6 a8ed b842 add3 7f7f 5877 .l./.....B....Xw
0x04e0: 6268 247f ebc9 2d9d dbcf bdce edda 644b bh$...-.......dK
0x04f0: 1295 435b 39d1 b9a3 a5c8 dd7b cecd 6ddc ..C[9......{..m.
0x0500: d23f d602 27fc 8904 9ffc 7925 b45f a914 .?..'.....y%._..
0x0510: 117f e048 24ff e3c9 2de7 6e65 3f23 6b78 ...H$...-.ne?#kx
0x0520: 8eb6 131a af0c 4e6d 6a3f 6800 e7e6 0227 ......Nmj?h....'
0x0530: fd72 17ba 496a e7fc 4c3f 9e68 247f ed84 .r..Ij..L?.h$...
0x0540: b6af 4463 6fd1 4835 b4f2 6af3 ad45 e6e0 ..Dco.H5..j..E..
0x0550: 033e e9e2 c5c0 97eb 5500 1ef6 f3be 7904 .>......U.....y.
0x0560: 9ffc d24b 7a47 bb5c 7ca5 8601 4da4 e38a ...KzG.\|...M...
Огромное спасибо разработчикам за программу!
А нет ли у вас желания зарегистрироваться на sourceforge.net / code.google.com / alioth.debian.org и т.д.? Брать исходники из публичного svn репозитория гораздо удобнее, чем из аттачментов на форуме. К тому же наверняка программа будет интересна не только владельцам роутеров.
Хорошие соображения, спасибо - но пока что я пишу с writev, поскольку его использование наиболее гладко вписывается в архитектуру, учитывая возможность накопления пакетов при чтении и т.п. writev удобен в данной ситуации тем, что пакеты я могу сразу регистрировать в массиве iovec - затем, модифицируя struct iovec для отдельных пакетов, я удаляю данные заголовка и проч. служебную информацию - приложения. (Но можно было бы, конечно, использовать send/write в цикле).Quote:
Originally Posted by Oleg
Всегда пожалуйста.Quote:
Originally Posted by Xander
Проект udpxy уже зарегистрирован на sourceforge.net но код пока что не выложен на страницу проекта - я тут несколько завозился с проблемой Корбины-240 и не довёл пока конфигурацию на sourceforge до ума. Но код будет оттуда доступен в ближайшем будущем (я объявлю на форуме).
Приношу извинения за неудобства.
В этой сборке поддерживается протокол RTP (over UDP), используемый Корбиной на "каналах-240". Эта сборка тестировочная, т.е. устойчивость её под вопросом. Кроме поддержки RTP в сборку не добавлено практически ничего (из пожеланий), эта сборка только для проверки разрешения проблемы с Кробиной-240.
RTP распознаётся в пакетах автоматически (по первому пакету, дальше проверок уже нет), но можно указать RTP и сразу, в URL, вместо UDP - в этом случае проверки пакетов на RTP/UDP вовсе нет - и при ошибке формата клиент закончит работу.
Чтение файлов пока не улучшалось, "проигрывать" RTP поток из файла не рекомендую - обработки пакетов RTP из файла нет.
Попробуйте на Корбине-240 "вживую", сообщите о впечатлениях. Спасибо всем, кто участвует в тестировании.
Павел итог такой: на экране пусто. :(
Я захватил поток с помощью wget. Итог такой - media player classic его играет, а вот IP TV Player (vlc) тот же файл - нет. :(
Вот что пишет vlc (меня смущает skipping 12 bytes of garbage):
main debug: creating new input thread
main debug: waiting for thread completion
main debug: thread 4476 (input) created at priority 1 (input/input.c:261)
main debug: `\\wl700ge\share\out.mpg' gives access `' demux `' path `\\wl700ge\share\out.mpg'
main debug: creating demux: access='' demux='' path='\\wl700ge\share\out.mpg'
main debug: looking for access_demux module: 1 candidate
main debug: creating access '' path='\\wl700ge\share\out.mpg'
main debug: looking for access2 module: 5 candidates
vcd debug: trying .cue file: \\wl700ge\share\out.cue
access_file debug: opening file `\\wl700ge\share\out.mpg'
main debug: using access2 module "access_file"
main debug: pre-buffering...
main debug: received first data for our buffer
main debug: pre-buffering done 327670 bytes in 0s - 1702 kbytes/s
main debug: creating demux: access='' demux='' path='\\wl700ge\share\out.mpg'
main debug: looking for demux2 module: 44 candidates
main debug: using demux2 module "ts"
main debug: looking for a subtitle file in \\wl700ge\share\
ts debug: DEMUX_SET_GROUP 0 00000000
main debug: `\\wl700ge\share\out.mpg' successfully opened
ts debug: pid[601] unknown
ts debug: pid[602] unknown
ts warning: lost synchro
ts debug: skipping 3 bytes of garbage
ts warning: lost synchro
ts debug: skipping 12 bytes of garbage
ts debug: pid[32] unknown
ts debug: pid[8160] unknown
ts warning: lost synchro
ts debug: skipping 12 bytes of garbage
ts warning: lost synchro
ts debug: skipping 3 bytes of garbage
ts warning: lost synchro
ts debug: skipping 12 bytes of garbage
ts warning: lost synchro
ts debug: skipping 12 bytes of garbage
ts warning: lost synchro
ts debug: skipping 3 bytes of garbage
ts warning: lost synchro
ts debug: skipping 12 bytes of garbage
ts warning: lost synchro
ts debug: skipping 12 bytes of garbage
ts warning: lost synchro
ts debug: skipping 3 bytes of garbage
ts warning: lost synchro
ts debug: skipping 12 bytes of garbage
ts warning: lost synchro
ts debug: skipping 12 bytes of garbage
ts warning: lost synchro
ts debug: skipping 3 bytes of garbage
ts warning: lost synchro
ts debug: skipping 12 bytes of garbage
ts warning: lost synchro
ts debug: skipping 12 bytes of garbage
ts warning: lost synchro
ts debug: skipping 12 bytes of garbage
ts warning: lost synchro
ts debug: skipping 12 bytes of garbage
ts warning: lost synchro
ts debug: skipping 3 bytes of garbage
ts warning: lost synchro
ts debug: skipping 3 bytes of garbage
ts warning: lost synchro
ts debug: skipping 24 bytes of garbage
ts warning: lost synchro
ts debug: skipping 3 bytes of garbage
ts warning: lost synchro
ts debug: skipping 12 bytes of garbage
ts warning: lost synchro
ts debug: skipping 12 bytes of garbage
ts warning: lost synchro
ts debug: skipping 3 bytes of garbage
ts warning: lost synchro
ts debug: skipping 24 bytes of garbage
ts warning: lost synchro
ts debug: skipping 3 bytes of garbage
ts warning: lost synchro
ts debug: skipping 12 bytes of garbage
ts warning: lost synchro
ts debug: skipping 12 bytes of garbage
ts warning: lost synchro
ts debug: skipping 3 bytes of garbage
ts warning: lost synchro
ts debug: skipping 12 bytes of garbage
ts warning: lost synchro
ts debug: skipping 12 bytes of garbage
ts warning: lost synchro
ts debug: skipping 3 bytes of garbage
ts warning: lost synchro
ts debug: skipping 12 bytes of garbage
ts warning: lost synchro
ts debug: skipping 12 bytes of garbage
ts warning: lost synchro
ts debug: skipping 3 bytes of garbage
ts warning: lost synchro
ts debug: skipping 12 bytes of garbage
ts warning: lost synchro
ts debug: skipping 12 bytes of garbage
ts warning: lost synchro
ts debug: skipping 3 bytes of garbage
ts warning: lost synchro
ts debug: skipping 12 bytes of garbage
ts warning: lost synchro
ts debug: skipping 12 bytes of garbage
ts warning: lost synchro
ts debug: skipping 3 bytes of garbage
ts warning: lost synchro
ts debug: skipping 12 bytes of garbage
ts warning: lost synchro
ts debug: skipping 12 bytes of garbage
ts warning: lost synchro
ts debug: skipping 3 bytes of garbage
ts warning: lost synchro
ts debug: skipping 12 bytes of garbage
ts warning: lost synchro
ts debug: skipping 12 bytes of garbage
ts warning: lost synchro
ts debug: skipping 3 bytes of garbage
ts warning: lost synchro
ts debug: skipping 12 bytes of garbage
ts warning: lost synchro
ts debug: skipping 12 bytes of garbage
ts warning: lost synchro
ts debug: skipping 3 bytes of garbage
ts warning: lost synchro
ts debug: skipping 12 bytes of garbage
ts warning: lost synchro
ts debug: skipping 12 bytes of garbage
ts warning: lost synchro
ts debug: skipping 3 bytes of garbage
ts warning: lost synchro
ts debug: skipping 12 bytes of garbage
ts warning: lost synchro
ts debug: skipping 12 bytes of garbage
ts warning: lost synchro
ts debug: skipping 3 bytes of garbage
ts warning: lost synchro
ts debug: skipping 24 bytes of garbage
ts warning: lost synchro
ts debug: skipping 3 bytes of garbage
ts warning: lost synchro
ts debug: skipping 12 bytes of garbage
ts warning: lost synchro
ts debug: skipping 12 bytes of garbage
ts warning: lost synchro
ts debug: skipping 3 bytes of garbage
ts warning: lost synchro
ts debug: skipping 12 bytes of garbage
ts warning: lost synchro
ts debug: skipping 12 bytes of garbage
ts warning: lost synchro
ts debug: skipping 3 bytes of garbage
ts warning: lost synchro
ts debug: skipping 12 bytes of garbage
ts warning: lost synchro
ts debug: skipping 12 bytes of garbage
ts warning: lost synchro
ts debug: skipping 3 bytes of garbage
ts warning: lost synchro
ts debug: skipping 12 bytes of garbage
ts warning: lost synchro
ts debug: skipping 12 bytes of garbage
ts warning: lost synchro
ts debug: skipping 3 bytes of garbage
ts warning: lost synchro
ts debug: skipping 12 bytes of garbage
ts warning: lost synchro
ts debug: skipping 12 bytes of garbage
ts warning: lost synchro
ts debug: skipping 3 bytes of garbage
ts warning: lost synchro
ts debug: skipping 12 bytes of garbage
ts warning: lost synchro
ts debug: skipping 12 bytes of garbage
ts warning: lost synchro
ts debug: skipping 3 bytes of garbage
ts warning: lost synchro
ts debug: skipping 12 bytes of garbage
ts warning: lost synchro
ts debug: skipping 12 bytes of garbage
ts warning: lost synchro
ts debug: skipping 3 bytes of garbage
ts warning: lost synchro
ts debug: skipping 12 bytes of garbage
ts warning: lost synchro
ts debug: skipping 12 bytes of garbage
ts warning: lost synchro
ts debug: skipping 3 bytes of garbage
ts warning: lost synchro
ts debug: skipping 12 bytes of garbage
ts warning: lost synchro
ts debug: skipping 12 bytes of garbage
ts warning: lost synchro
ts debug: skipping 3 bytes of garbage
ts warning: lost synchro
ts debug: skipping 12 bytes of garbage
ts warning: lost synchro
ts debug: skipping 12 bytes of garbage
ts warning: lost synchro
ts debug: skipping 12 bytes of garbage
ts warning: lost synchro
ts debug: skipping 12 bytes of garbage
ts warning: lost synchro
ts debug: skipping 3 bytes of garbage
ts warning: lost synchro
ts debug: skipping 3 bytes of garbage
ts warning: lost synchro
ts debug: skipping 12 bytes of garbage
ts warning: lost synchro
ts debug: skipping 12 bytes of garbage
ts warning: lost synchro
ts debug: skipping 3 bytes of garbage
ts warning: lost synchro
ts debug: skipping 12 bytes of garbage
ts warning: lost synchro
ts debug: skipping 12 bytes of garbage
ts warning: lost synchro
ts debug: skipping 12 bytes of garbage
ts warning: lost synchro
ts debug: skipping 12 bytes of garbage
ts warning: lost synchro
ts debug: skipping 3 bytes of garbage
ts warning: lost synchro
ts debug: skipping 3 bytes of garbage
ts warning: lost synchro
ts debug: skipping 12 bytes of garbage
ts warning: lost synchro
ts debug: skipping 12 bytes of garbage
ts warning: lost synchro
ts debug: skipping 3 bytes of garbage
ts warning: lost synchro
ts debug: skipping 12 bytes of garbage
ts warning: lost synchro
ts debug: skipping 12 bytes of garbage
ts debug: eof ?
main debug: EOF reached
main debug: closing input
ts debug: pid list:
ts debug: - pid[32] seen
ts debug: - pid[601] seen
ts debug: - pid[602] seen
ts debug: - pid[8160] seen
ts debug: - pid[8191] seen
main debug: removing module "ts"
main debug: removing module "access_file"
main debug: thread times: real 0m17.531250s, kernel 0m0.156250s, user 0m0.156250s
main debug: thread 4476 joined (input/input.c:399)
main: nothing to play
Посмотрел поток, там попадются и 80 21 и 90 21. А ещё периодически блоки из нулей - не очень похоже на мпег...
У меня по http аналогично, на 240-м vlc даже не пытается что-либо отобразить, лог файлы приложил. 210-й работает нормально.
Результаты не радуют, конечно. Интригуют меня также эти коротенькие пакеты в передаче корбины: у меня создать что-то подобное вещанием видео через vlc по RTP не получается - оттого и тесты мои не вполне коррелируют, возможно... (Посылаем из vlc на RTP - принимаем vlc как HTTP поток через udpxy - всё работает.)
Буду размышлять... и анализировать поток - на крайний случай напишу что-нибудь для запуска сеть пакетов из pcap (tcpdump) файла - там и посмотрим.
Павел