ffmpeg прекращает потоковую передачу через 900 секунд с камеры Axis на FLV RTMP

3868
AcsChristoph

Аудио и видео работают в течение 900 секунд, а затем ffmpegостанавливаются с:

video:1889kB audio:1825kB global headers:0kB muxing overhead 2.162866% 

Я транслирую с IP-камеры AXIS через ffmpegnginx.

ffmpeg -v verbose -i rtsp://root:pass@192.168.0.106/axis-media/media.amp -itsoffset 00:00:05 -acodec copy -ac 1 -ab 64k -ar 16000 -f flv -r 5 -qscale 1 -b 128kB rtmp://192.168.0.107/myapp/test 

Я протестировал много команд, но эта дала мне лучшие результаты.

Консольный вывод:

 ffmpeg -v verbose -i rtsp://root:pass@192.168.0.106/axis-media/media.amp -itsoffset 00:00:05 -acodec copy -ac 1 -ab 64k -ar 16000 -f flv -r 5 -qscale 1 -b 128kB rtmp://192.168.0.107/myapp/test  ffmpeg version 0.8.6-6:0.8.6-1ubuntu2, Copyright (c) 2000-2013 the Libav developers built on Mar 30 2013 22:20:06 with gcc 4.7.2 configuration: --arch=amd64 --enable-pthreads --enable-runtime-cpudetect --extra-version='6:0.8.6-1ubuntu2' --libdir=/usr/lib/x86_64-linux-gnu --prefix=/usr --enable-bzlib --enable-libdc1394 --enable-libfreetype --enable-gnutls --enable-libgsm --enable-libpulse --enable-libschroedinger --enable-libspeex --enable-libtheora --enable-vaapi --enable-vdpau --enable-libvorbis --enable-libvpx --enable-zlib --enable-gpl --enable-postproc --enable-swscale --enable-libcdio --enable-x11grab --shlibdir=/usr/lib/x86_64-linux-gnu --enable-shared --disable-static libavutil 51. 22. 1 / 51. 22. 1 libavcodec 53. 35. 0 / 53. 35. 0 libavformat 53. 21. 1 / 53. 21. 1 libavdevice 53. 2. 0 / 53. 2. 0 libavfilter 2. 15. 0 / 2. 15. 0 libswscale 2. 1. 0 / 2. 1. 0 libpostproc 52. 0. 0 / 52. 0. 0 *** THIS PROGRAM IS DEPRECATED *** This program is only provided for compatibility and will be removed in a future release. Please use avconv instead. [rtsp @ 0x63fb20] SDP: v=0 o=- 1376246125522976 1376246125522976 IN IP4 192.168.0.106 s=Media Presentation e=NONE b=AS:50064 t=0 0 a=control:* a=range:npt=0.000000- m=video 0 RTP/AVP 96 c=IN IP4 0.0.0.0 b=AS:50000 a=framerate:5.0 a=transform:-1,0,0;0,-1,0;0,0,1 a=control:trackID=1 a=rtpmap:96 H264/90000 a=fmtp:96 packetization-mode=1; profile-level-id=4D0029; sprop-parameter-sets=Z00AKeKQKD9gLcBAQGkHiRFQ,aO48gA== m=audio 0 RTP/AVP 97 c=IN IP4 0.0.0.0 b=AS:64 a=control:trackID=2 a=rtpmap:97 mpeg4-generic/16000/1 a=fmtp:97 streamtype=5; profile-level-id=15; mode=AAC-hbr; config=1408; sizeLength=13; indexLength=3; indexDeltaLength=3; profile=1; bitrate=64000;  [rtsp @ 0x63fb20] Estimating duration from bitrate, this may be inaccurate  Seems stream 0 codec frame rate differs from container frame rate: 180000.00 (180000/1) -> 90000.00 (180000/2) Input #0, rtsp, from 'rtsp://root:pass@192.168.0.106/axis-media/media.amp': Metadata: title : Media Presentation Duration: N/A, start: 0.062063, bitrate: N/A Stream #0.0: Video: h264 (Main), yuvj420p, 320x240 [PAR 1:1 DAR 4:3], 90k tbr, 90k tbn, 180k tbc Stream #0.1: Audio: aac, 16000 Hz, mono, s16 Incompatible pixel format 'yuvj420p' for codec 'flv', auto-selecting format 'yuv420p' [buffer @ 0x641aa0] w:320 h:240 pixfmt:yuvj420p [avsink @ 0x6512a0] auto-inserting filter 'auto-inserted scaler 0' between the filter 'src' and the filter 'out' [scale @ 0x645540] w:320 h:240 fmt:yuvj420p -> w:320 h:240 fmt:yuv420p flags:0x4 Output #0, flv, to 'rtmp://192.168.0.107/myapp/test': Metadata: title : Media Presentation encoder : Lavf53.21.1 Stream #0.0: Video: flv, yuv420p, 320x240 [PAR 1:1 DAR 4:3], q=2-31, 1024 kb/s, 1k tbn, 5 tbc Stream #0.1: Audio: aac, 16000 Hz, mono Stream mapping: Stream #0.0 -> #0.0 Stream #0.1 -> #0.1 Press ctrl-c to stop encoding frame= 1185 fps= 5 q=1.0 Lsize= 3794kB time=236.80 bitrate= 131.2kbits/s  video:1889kB audio:1825kB global headers:0kB muxing overhead 2.162866% 
0
Извините, но я не думаю, что понимаю ваш вопрос или конкретную проблему. slhck 11 лет назад 0
Моя проблема заключается в накладных расходах при потоковой передаче по ffmpeg. потоковая передача работает в течение 900 секунд, после чего ffmpeg останавливается с ошибкой мультиплексирования. AcsChristoph 11 лет назад 0
Переполнение накладных расходов - это нормально и следовало ожидать; в чем проблема у вас с этим? Вам придется компенсировать накладные расходы, если у вас очень строгие требования к пропускной способности, но в противном случае не беспокойтесь об этом. slhck 11 лет назад 0
я тестирую со строгими настройками пропускной способности в ffmpeg, результаты одинаковы AcsChristoph 11 лет назад 0
Подсказка: ваша версия `ffmpeg` устарела и содержит множество ошибок. Пожалуйста, не используйте `ffmpeg`, предоставляемый в пакетах Ubuntu, но загрузите более новую версию, перейдя по адресу http://ffmpeg.org/download.html - или скомпилируйте ее из исходного кода. slhck 11 лет назад 0

1 ответ на вопрос

1
slhck

If ffmpeg stops encoding, then there's no more input to parse, or the stream has ended. This is a problem with the stream itself, or probably a bug in your ffmpeg version.

The one you're using is an old and (known to be) broken version provided by the Ubuntu package sources. Consider updating to a recent ffmpeg and trying again.


As for the muxing overhead:

Whenever you take video, audio or subtitle streams and put them into a container format (such as FLV in your case), the container needs some additional data to mux (multiplex) these streams.

It's basically metadata that is wrapped around the actual data, and you cannot get rid of this overhead. Every container will introduce a muxing overhead, but it'll usually be less than a few per cent of the actual data.

If you have very strict requirements on how much bandwidth you have available, you should therefore factor in the possible overhead when encoding the video and audio streams. For example, if you have 1500 kBit/s video and 128 kBit/s audio, the whole bandwidth needed is more than 1628 kBit/s (e.g. 1660 kBit/s).

спасибо за ваше воспроизведение ... я уже уменьшил накладные факторы, я работаю со 128 кбит / с для видео (h264) и 64 кбит / с для аудио (aac) AcsChristoph 11 лет назад 0
ffmpeg новая версия свежо скомпилировано -> РАБОТАЕТ БОЛЬШОЙ =) thx AcsChristoph 11 лет назад 0

Похожие вопросы