2015-04-07 4 views
1

Мне нужно подключиться к аппаратной части, ожидающей поток MPEG-4 RTP с камеры (на самом деле несколько потоков из нескольких разных камер). Мы хотели бы предоставить это видео из набора небольших файлов .mp4, зацикливаясь бесконечно.Looping MP4 video

Что я сейчас пытаюсь использовать libVLC в режиме сервера с аргументом «-loop». Код для этого выглядит следующим образом:

libvlc_vlm_add_broadcast(vlc, "test", ("file:///" + video).c_str(), 
          "#rtp{dst=localhost,port=1234,sdp=rtsp://localhost:8080/test.sdp}", 
          1, broadcast_options, true, true); 
    const auto play_result = libvlc_vlm_play_media(vlc, "test"); 

Это, кажется, работает на моем рабочем столе, с одним вопросом: я должен поставить плеер на петле тоже. Если я просто попрошу игрока воспроизвести поток один раз, он остановится, когда достигнут конец файла с сервера.

Есть ли способ заставить это смотреть на клиента как один непрерывный (бесконечный) поток? VLC не является требованием, но поток RTP MP4 есть.

1 - Нет, я не пытаюсь ограбить музей. Это для симулятора.

ответ

1

Выполнение эквивалента вашего кода в cvlc (CLI VLC) приводит к «мертвому вводу», возможно, из-за разрыва (говорит, что больше ES не играет ...).

Существует способ сделать это, используя FFmpeg, но это не очень прямолинейно. Если есть более простой способ, я бы тоже хотел знать.

1. Создайте плейлист с файлами для воспроизведения (скажем playlist.txt). Нет опции петли плейлиста, поэтому вам нужно повторять файлы в списке воспроизведения столько раз, сколько вы сочтете нужным. Используйте формат:

file '/path/to/file/1.mp4'  
file '/path/to/file/2.mp4'  
file '/path/to/file/3.mp4'  
[... repeat ...]  
file '/path/to/file/1.mp4'  
file '/path/to/file/2.mp4'  
file '/path/to/file/3.mp4' 

Оттуда вы будете использовать concat demuxer для создания бесшовного потока. У вас есть два варианта:

2-A. Используйте RTP и предоставьте файл SDP вручную. Вы можете использовать только один поток на порт, поэтому, если вам нужен звук, вам нужно сопоставить его со вторым выходом.

ffmpeg -re -f concat -i playlist.txt -an -vcodec mpeg4 -f rtp rtp://127.0.0.1:1234 

СДП показан на выходе консоли:

v=0 
o=- 0 0 IN IP4 127.0.0.1 
s=No Name 
c=IN IP4 127.0.0.1 
t=0 0 
a=tool:libavformat 56.26.101 
m=video 1234 RTP/AVP 96 
b=AS:200 
a=rtpmap:96 MP4V-ES/90000 
a=fmtp:96 profile-level-id=1 

2-Б. Используйте RTSP для отправки потока на сервер, поддерживающий его (в документации указывается сервер потока Дарвин и сервер RTSP Mischa Spiegelmock). Вам необходимо установить и настроить серверы перед выполнением:

ffmpeg -re -f concat -i playlist.txt -an -vcodec mpeg4 -f rtsp rtsp://server:port/stream_name.sdp 

Затем используйте rtsp://server/stream_name.sdp на клиенте.

* Кража музея должна быть выполнена с использованием автоматических мусорных банок для роботов.

+0

Настоящие клиенты в этом случае являются (с нашей точки зрения) черными ящиками, висящими на линии Ethernet. Это означает, что мы должны дать им * точно * то, что они ожидают, и их протокол ничего не говорит о RTSP (только RTP и MP4). Поэтому я не уверен, связаны ли RTSP и/или SDP или нет. Протокол документирует упоминание ICMP и ARP, поэтому вы думаете, что если бы RTSP или SDP были задействованы, они бы так сказали.Но, возможно, RTP подразумевает одного или обоих из них, и это просто мое невежество? Я попробую и посмотрю, что произойдет. –

+0

Я как бы представлял себе, что это непрерывный поток RTP/MP4 (трансляция на адрес многоадресной рассылки), с помощью которого клиент может вскочить и вылететь «на лету». –

+0

Я думал, что вы используете SDP, потому что команда вашего примера говорит 'sdp = rtsp: // localhost: 8080/test.sdp'. Без протокола описания сеанса он может не знать, как играть в поток, поскольку FFmpeg использует идентификатор типа динамической полезной нагрузки (96), поэтому необходимо сопоставить его с фактическим типом потока в SDP. Как вы его протестировали до сих пор? – aergistal

Смежные вопросы