Прием видеопотока с @ в адресе

← →
MBo © (2015-04-14 19:42) [0]

Что означает символ "@" в адресе (MRL), передаваемом VLC?
Например:
udp://@192.168..:5000
И какие настройки сокета нужно сделать, чтобы принимать этот udp-поток самому?

← →
brother © (2015-04-14 19:58) [1]

что-то специфичное для конкретного софта?

← →
MBo © (2015-04-14 20:04) [2]

VLC - видеопроигрыватель (videolan.org). С использованием такого адреса он принимает и показывает трансляцию видеопотока со специфической железки. Именно с @ - работает, без этой зюшки - нет.

← →
DVM © (2015-04-14 22:10) [3]

https://trac.videolan.org/vlc/ticket/9492

← →
DVM © (2015-04-14 22:15) [4]

Короче, тут суть в чем, вот здесь: udp://@192.168..:5000 URL схема не udp://, а udp:/
А вот второй слэш - это адрес. @ разделяет два адреса - источник и приемник

← →
MBo © (2015-04-15 12:09) [5]

А что же при этом сделать, чтобы udp сокет принимал данные? recvfrom просто висит, ничего не получает. Wireshark видит, что пакеты летят. Что не даёт программе их принять?

← →
DVM © (2015-04-15 12:11) [6]

> MBo © (15.04.15 12:09) [5]

Ты порт какой открыл на прослушивание?
А еще лучше покажи кусок дампа.

← →
MBo © (2015-04-15 12:37) [7]

Не увидел, как дампа кусок сделать. Могу pcapng сделать, могу содержимое пакета по-дебильному картинкой показать
http://saveimg.ru/show-image.php?id=29e468914671d460f660736c7722404b

← →
DVM © (2015-04-15 13:12) [8]

> MBo © (15.04.15 12:37) [7]

А эта железка она всегда шлет данные на заданный адрес и порт?
Просто в IP телевидении (для мультикаст) клиент сначала должен подписаться на трафик по протоколу IGMP а потом уже сервер начинает ему его слать. VLC все это умеет.

Вообще если железка шлет данные всегда, то все должно приниматься, если сокет правильно открыт и инициализирован.
Ну и проверь, все ли правильно: WSAStartup > socket() > bind() > recvfrom()

← →
brother © (2015-04-15 13:15) [9]

я вот тож думаю, что @ не обязательно в Вашем случае...

← →
MBo © (2015-04-15 13:34) [10]

>А эта железка она всегда шлет данные на заданный адрес и порт?
Да.

>проверь, все ли правильно
Да, порядок такой
WSAStartup($0202, WSAD)
Socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP)
заполнение адреса (ip, порт)
Bind
RecvFrom

При работе программы netstat видит наличие открытого порта
UDP 192.168.2.10:5000 *:*

← →
DVM © (2015-04-15 14:53) [11]

> MBo © (15.04.15 13:34) [10]

Все же непонятно, мультикаст у тебя вещание или юникаст.

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

Посмотри тут http://habrahabr.ru/post/141021/
И тут: http://rsdn.ru/forum/network/3174371.flat

← →
MBo © (2015-04-15 15:15) [12]

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

← →
DVM © (2015-04-15 15:25) [13]

> MBo © (15.04.15 15:15) [12]

> какая может быть группа - неясно.

так она в URL же у тебя

← →
Кто б сомневался © (2015-04-15 16:15) [14]

Вот еще инфа в копилку:

Смотрю телек (провайдер дает плейлист m3u бесплатно) через корейский PotPlayer (смотрю все через него - и ютуб ролики, и 1080 фильмы и торренты видео прямо во время закачки итд.), т.к. VLC медленный и долго думает.

Поток идет через TCP. ICMP и IGMP траф лочится файрволлом.
Проблем никаких.

> Кто б сомневался © (15.04.15 16:15) [14]

> Поток идет через TCP

Потому и:

> Проблем никаких.

Но TCP сильно забивает канал пропорционально количеству смотрящих, в отличие от UDP мультикаст.

> Поток идет через TCP.

кто его направляет на ip телевизора? дома то можно, но в сети провайдера такая роскошь недопустима...

> кто его направляет на ip телевизора?

На компе смотрю.
Чтоб на большой экран вывести, нужно подключить ноут через hdmi.
Или у провайдера купить девайс.
Первый вариант с ноутом лучше, т.к. можно сделать постпроцесс картинке в Potplayer (яркость, цвет, шапр, растянуть итд) .

> Но TCP сильно забивает канал пропорционально количеству
> смотрящих, в отличие от UDP мультикаст.

Чес. говоря я разницы не вижу в плане нагрузки на сервер, как поток отправляется юзеру. Что по TCP передастся мегабайт видео\аудио данных, что по UDP тот же мегабайт.

В моем случае:
Провайдер всем юзерам дает 100 мбит инета.

Для юзеров провайдера, ТВ можно смотреть с сайта http://lanet.tv/
или попросить плейлист у саппорта для виндовых плееров. В каждом плейлисте ссылки вида

http://la.net.ua/tv/9002.m3u8 на каждый канал.

>> шапр,

Всмысле - четкость - sharpen

> Кто б сомневался © (15.04.15 17:37) [17]

> Чес. говоря я разницы не вижу в плане нагрузки на сервер,
> как поток отправляется юзеру. Что по TCP передастся мегабайт
> видео\аудио данных, что по UDP тот же мегабайт.
>

Unicast UDP и TCP разницы действительно нет, а вот Multicast UDP и TCP есть и огромная.
При Multicast UDP пакеты идут не конкретно каждому юзеру, а на мультикаст адрес группы.
Т.е на каждый свитч приходит по одной копии пакета, а потом своя копия пакета уходит каждому из зрителей в его порт.

Если юзер подключился к мультикаст группе (а это управляется через IGMP), то он пакеты получает, если не подключился, то со свитча они к нему даже и не уходят. Свитч должен поддерживать эту фичу.

Прием видеопотока с @ в адресе Найти похожие ветки