ffmped + rtp c камеры = udp destination unreachable

RTP работает без RTSP? Просто мысль...

Установление и разрыв соединения не входит в список возможностей RTP, такие действия выполняются сигнальным протоколом (например, RTSP или SIP протоколом).

Вполне работает если есть SDP манифест, в его нет, avconv останавливается, порт закрывается, icmp шлётся. Вобщем проблемма как оказалась не в этом.

А в чем была проблема? Просто я около темы RTP/RTSP витаю, мне это интересно :)

А после icmp destination unreachable камера перестает слать пакеты? Тогда запусти её второй раз, не трогая avconv.

Дело в том, что avconv (ffmpeg) делает так: открывает порт для анализа потока, читает его до появления описания, закрывает его, открывает его повторно для основной работы. При первом открытии он сам формирует sdp-пакет, чтобы использовать его для второго открытия. Это позволяет использовать тот же код и для rtsp демуксера.

ffmpeg плохо работает с китайкамерами, пиши свой клиент.

ffmpeg плохо работает с китайкамерами, пиши свой клиент.

Бабушкин перелогинтесь

А в чем была проблема? Просто я около темы RTP/RTSP витаю, мне это интересно :)

В том что avconv открывает порт, не получает sdp описания, расстраивается и закрывает порт.

открывает порт для анализа потока, читает его до появления описания, закрывает его, открывает его повторно для основной работы

А после icmp destination unreachable камера перестает слать пакеты?

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

При первом открытии он сам формирует sdp-пакет, чтобы использовать его для второго открытия. Это позволяет использовать тот же код и для rtsp демуксера.

Спасибо большой за описание, это точно работает для rtp, кстати я же могу сам послать SDP пакет , поможет?

не не вышло

[rtp @ 0x12bf020] Unable to receive RTP payload type 96 without an SDP file describing it
[rtp @ 0x12bf020] Estimating duration from bitrate, this may be inaccurate
Input #0, rtp, from 'rtp://@0.0.0.0:60005':
  Duration: N/A, bitrate: N/A
File 'abc.mp4' already exists. Overwrite ? [y/N] n
Not overwriting - exiting

Он завершается до прекращения потока от камеры.

Конечно, поможет. Cам напиши sdp файл и вместо «avconv -i rtp://@0.0.0.0:41760» передай его: «avconv -i camera.sdp ...». Это обычное дело, такой файл размещают на http или ftp сервере, и потом его любым проигрывателем можно открыть, не только ffmpeg-ом: «avconv -i http://мой.сервер/camera.sdp» или «mplayer http://мой.сервер/camera.sdp».

А порт и адрес для RTP я должен тогда в параметрах команды писать или в SDP файле?

А нет, туплю

Пользуясь случаем спрошу: Есть ли способ ffmpegом переписывать mp4 файл с более качественного потока? Предположим я записал файл с плохого потока, через некоторое время ко мне прилетят пропущенные пакеты (может и день) вроде если ffmpeg был запущен с самого начала то по идее он их скушает и дозапишет в файл, а если ffmpeg остановился, он сможет дозаписать пропущенные в файл? И кстати есть ли возможность накладывать блокировку на файл, чтобы не получились весёлоси при чтении?

В sdp-файле. Там все параметры rtp потока должны быть.

Я тебя не понял, но отвечу точно - нет. И блокировок на файл тоже нет.

Ок спасибо большое, придётся идти странным мазохистическим путём.

нет, не все параметры там.

С помощью SDP можно подключиться к мультикасту RTP, но нельзя сообщить камере: шли сюда юникастом. Это только с RTSP

Параметры потока есть все для воспроизведения rtp. А «шли сюда юникастом» - это управление соединением, которое автор взял в свои руки («настраиваю камеру вещать мне на 41760-41761 порты, запускаю вещание»). А ты ему еще про ONVIF расскажи. :)

ну а чего рассказывать. Теоретически по онвифу можно мультикаст запустить, особо больше тут ничего не сделать.