-
Notifications
You must be signed in to change notification settings - Fork 112
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ffmpeg can't process the RTSP stream #36
Comments
Does ffmpeg work properly with the stream? |
Unfortunately not, the RTSP works flawlessly through VLC, and the homebridge plugin (Camera-ffmpeg) says:
I pass the RTSP stream in this way: the log is: ffmpeg tcp -re -i rtsp://user:psw@192.168..........:554/ch0_0.h264 -map 0:0 -vcodec libx264 -pix_fmt yuv420p -r 30 -f rawvideo -tune zerolatency -b:v 299k -bufsize 299k -maxrate 299k -payload_type 99 -ssrc 5794419 -f rtp -srtp_out_suite AES_CM_128_HMAC_SHA1_80 -srtp_out_params J0rzUWbvTfF5ml6WLngZFqU2+8i6+0NksAlniZmm srtp://192.168.1.101:61337?rtcpport=61337&localrtcpport=61337&pkt_size=1316 -loglevel debug libavutil 56. 22.100 / 56. 22.100 Parsing a group of options: input url rtsp://user:psw@192.168..........:554/ch0_0.h264. [tcp @ 0xb69ec770] Successfully connected to 192.168……. port 554 [rtsp @ 0xb4edc5d0] SDP: Failed to parse interval end specification '' [rtsp @ 0xb4edc5d0] setting jitter buffer size to 500 Failed to parse interval end specification '' [h264 @ 0xb4eba3c0] nal_unit_type: 7(SPS), nal_ref_idc: 3 [h264 @ 0xb4eba3c0] nal_unit_type: 7(SPS), nal_ref_idc: 3 [h264 @ 0xb4eba3c0] unknown SEI type 240 [h264 @ 0xb4eba3c0] nal_unit_type: 6(SEI), nal_ref_idc: 0 [h264 @ 0xb4eba3c0] nal_unit_type: 1(Coded slice of a non-IDR picture), nal_ref_idc: 2 [h264 @ 0xb4eba3c0] Frame num gap 21 19 [h264 @ 0xb4eba3c0] unknown SEI type 240 [h264 @ 0xb4eba3c0] nal_unit_type: 6(SEI), nal_ref_idc: 0
[h264 @ 0xb4eba3c0] nal_unit_type: 6(SEI), nal_ref_idc: 0 [h264 @ 0xb4eba3c0] unknown SEI type 240
[h264 @ 0xb4eba3c0] nal_unit_type: 6(SEI), nal_ref_idc: 0 [h264 @ 0xb4eba3c0] unknown SEI type 240
[h264 @ 0xb4eba3c0] nal_unit_type: 6(SEI), nal_ref_idc: 0
[h264 @ 0xb4eba3c0] nal_unit_type: 6(SEI), nal_ref_idc: 0
[h264 @ 0xb4eba3c0] nal_unit_type: 6(SEI), nal_ref_idc: 0 [h264 @ 0xb4eba3c0] unknown SEI type 240
[h264 @ 0xb4eba3c0] nal_unit_type: 6(SEI), nal_ref_idc: 0
[h264 @ 0xb4eba3c0] nal_unit_type: 6(SEI), nal_ref_idc: 0 [h264 @ 0xb4eba3c0] unknown SEI type 240
[h264 @ 0xb4eba3c0] nal_unit_type: 6(SEI), nal_ref_idc: 0 [h264 @ 0xb4eba3c0] unknown SEI type 240
[h264 @ 0xb4eba3c0] nal_unit_type: 6(SEI), nal_ref_idc: 0 [h264 @ 0xb4eba3c0] unknown SEI type 240
[h264 @ 0xb4eba3c0] nal_unit_type: 6(SEI), nal_ref_idc: 0 [h264 @ 0xb4eba3c0] unknown SEI type 240 [h264 @ 0xb4eba3c0] no picture ooo [h264 @ 0xb4eba3c0] concealing 4062 DC, 4062 AC, 4062 MV errors in P frame [h264 @ 0xb4eba3c0] unknown SEI type 240 [h264 @ 0xb4eba3c0] nal_unit_type: 6(SEI), nal_ref_idc: 0 [h264 @ 0xb4eba3c0] no picture ooo [h264 @ 0xb4eba3c0] unknown SEI type 240 [h264 @ 0xb4eba3c0] nal_unit_type: 6(SEI), nal_ref_idc: 0 [h264 @ 0xb4eba3c0] no picture ooo [h264 @ 0xb4eba3c0] unknown SEI type 240 [h264 @ 0xb4eba3c0] nal_unit_type: 6(SEI), nal_ref_idc: 0 [h264 @ 0xb4eba3c0] no picture ooo [h264 @ 0xb4eba3c0] unknown SEI type 240 [h264 @ 0xb4eba3c0] nal_unit_type: 6(SEI), nal_ref_idc: 0 [h264 @ 0xb4eba3c0] unknown SEI type 240 [h264 @ 0xb4eba3c0] nal_unit_type: 6(SEI), nal_ref_idc: 0 [h264 @ 0xb4eba3c0] no picture ooo [h264 @ 0xb4eba3c0] unknown SEI type 240 [h264 @ 0xb4eba3c0] nal_unit_type: 6(SEI), nal_ref_idc: 0 [h264 @ 0xb4eba3c0] no picture ooo [h264 @ 0xb4eba3c0] unknown SEI type 240 [h264 @ 0xb4eba3c0] nal_unit_type: 1(Coded slice of a non-IDR picture), nal_ref_idc: 2 [h264 @ 0xb4eba3c0] no picture ooo [h264 @ 0xb4eba3c0] unknown SEI type 240 [h264 @ 0xb4eba3c0] nal_unit_type: 6(SEI), nal_ref_idc: 0 [h264 @ 0xb4eba3c0] no picture ooo [h264 @ 0xb4eba3c0] unknown SEI type 240 [h264 @ 0xb4eba3c0] nal_unit_type: 6(SEI), nal_ref_idc: 0 [h264 @ 0xb4eba3c0] no picture ooo [h264 @ 0xb4eba3c0] unknown SEI type 240 [h264 @ 0xb4eba3c0] nal_unit_type: 6(SEI), nal_ref_idc: 0 [h264 @ 0xb4eba3c0] no picture ooo [h264 @ 0xb4eba3c0] unknown SEI type 240 [h264 @ 0xb4eba3c0] no picture ooo [h264 @ 0xb4eba3c0] unknown SEI type 240 [h264 @ 0xb4eba3c0] nal_unit_type: 6(SEI), nal_ref_idc: 0 [h264 @ 0xb4eba3c0] no picture ooo [h264 @ 0xb4eba3c0] unknown SEI type 240 [h264 @ 0xb4eba3c0] nal_unit_type: 6(SEI), nal_ref_idc: 0 [h264 @ 0xb4eba3c0] no picture ooo [h264 @ 0xb4eba3c0] unknown SEI type 240 [h264 @ 0xb4eba3c0] nal_unit_type: 6(SEI), nal_ref_idc: 0 [h264 @ 0xb4eba3c0] no picture ooo [h264 @ 0xb4eba3c0] unknown SEI type 240 [h264 @ 0xb4eba3c0] nal_unit_type: 6(SEI), nal_ref_idc: 0 [h264 @ 0xb4eba3c0] no picture ooo [h264 @ 0xb4eba3c0] unknown SEI type 240 [h264 @ 0xb4eba3c0] nal_unit_type: 6(SEI), nal_ref_idc: 0 [h264 @ 0xb4eba3c0] no picture ooo [h264 @ 0xb4eba3c0] unknown SEI type 240 [h264 @ 0xb4eba3c0] nal_unit_type: 6(SEI), nal_ref_idc: 0 [h264 @ 0xb4eba3c0] no picture ooo [h264 @ 0xb4eba3c0] unknown SEI type 240 [h264 @ 0xb4eba3c0] nal_unit_type: 6(SEI), nal_ref_idc: 0
[h264 @ 0xb4eba3c0] nal_unit_type: 6(SEI), nal_ref_idc: 0
[h264 @ 0xb4eba3c0] nal_unit_type: 6(SEI), nal_ref_idc: 0
[h264 @ 0xb4eba3c0] nal_unit_type: 6(SEI), nal_ref_idc: 0
[h264 @ 0xb4eba3c0] nal_unit_type: 6(SEI), nal_ref_idc: 0 [h264 @ 0xb4eba3c0] unknown SEI type 240
[h264 @ 0xb4eba3c0] nal_unit_type: 6(SEI), nal_ref_idc: 0 [h264 @ 0xb4eba3c0] unknown SEI type 240
[h264 @ 0xb4eba3c0] nal_unit_type: 6(SEI), nal_ref_idc: 0 [h264 @ 0xb4eba3c0] unknown SEI type 240
[h264 @ 0xb4eba3c0] nal_unit_type: 6(SEI), nal_ref_idc: 0
[h264 @ 0xb4eba3c0] nal_unit_type: 6(SEI), nal_ref_idc: 0 [h264 @ 0xb4eba3c0] unknown SEI type 240
[h264 @ 0xb4eba3c0] nal_unit_type: 7(SPS), nal_ref_idc: 3 [h264 @ 0xb4eba3c0] nal_unit_type: 5(IDR), nal_ref_idc: 3
[h264 @ 0xb4eba3c0] nal_unit_type: 6(SEI), nal_ref_idc: 0 [h264 @ 0xb4eba3c0] nal_unit_type: 1(Coded slice of a non-IDR picture), nal_ref_idc: 2
[h264 @ 0xb4eba3c0] nal_unit_type: 6(SEI), nal_ref_idc: 0
[h264 @ 0xb4eba3c0] nal_unit_type: 6(SEI), nal_ref_idc: 0 [h264 @ 0xb4eba3c0] unknown SEI type 240
[h264 @ 0xb4eba3c0] nal_unit_type: 6(SEI), nal_ref_idc: 0
[h264 @ 0xb4eba3c0] nal_unit_type: 6(SEI), nal_ref_idc: 0 [h264 @ 0xb4eba3c0] unknown SEI type 240
[h264 @ 0xb4eba3c0] nal_unit_type: 6(SEI), nal_ref_idc: 0
[rtsp @ 0xb4edc5d0] All info found Input #0, rtsp, from 'rtsp://user:psw@192.168..........:554/ch0_0.h264': Successfully opened the file. [11/27/2019, 5:19:11 PM] [Camera-ffmpeg] ERROR: FFmpeg exited with code 1 |
I think that the problem is tcp option. |
I removed that, so you think it is needed? But anyway it wasn’t working.. I’ll post the log after I removed “tcp” that was a residue of the option you mentioned |
If the wifi connection is not good, it's better to use "-rtsp_transport tcp" option. |
Okay, I removed it and left the config like this (the standard as readme said): Now it doesn't give any exit erroneous exit code, but the stream is very bad and works for 1-2 secs then it freezes on a still image (in HomeKit) and the logs even after quitting the viewer goes on...and on... with [libx264 @ .............. This is the log: [libx264 @ 0xb4df8500] frame=1223 QP=16.07 NAL=2 Slice:P Poc:446 I:3 P:154 SKIP:8003 size=867 bytes [rtp @ 0xb4523030] Sending NAL 1 of len 195 M=0 [libx264 @ 0xb4df8500] frame=1224 QP=21.97 NAL=2 Slice:P Poc:448 I:314 P:3522 SKIP:4324 size=15908 bytes [rtp @ 0xb4523030] Sending NAL 1 of len 2905 M=0 [rtp @ 0xb4523030] Sending NAL 1 of len 5003 M=0 [rtp @ 0xb4523030] Sending NAL 1 of len 4731 M=0 [rtp @ 0xb4523030] Sending NAL 1 of len 3256 M=1 frame= 1225 fps=6.0 q=25.0 Lsize= 1140kB time=00:00:42.43 bitrate= 220.1kbits/s dup=1175 drop=0 speed=0.208x 51 frames successfully decoded, 0 decoding errors [AVIOContext @ 0xb48a1bc0] Statistics: 0 seeks, 1560 writeouts [libx264 @ 0xb4df8500] frame I:5 Avg QP:35.08 size: 25381 [libx264 @ 0xb4df8500] mb I I16..4: 33.6% 57.2% 9.2% [libx264 @ 0xb4df8500] i8c dc,h,v,p: 74% 14% 11% 1% Exiting normally, received signal 15. |
Mmmmmh... |
unfortunately always the same thing... 2 secs of low quality stream, then it freezes on a still image that gradually gets definition (from blocky to perfectly displayed). |
I cannot RTSP stream and got "VLC is unable to open the MRL 'rtsp://CAM_IP:554/ch0_0.h264'. Check the log for details." Any advice please? Can I disable Yi Could and APP and use RTSP streaming? Thanks |
Manage to stream using ch0_1 channel, guess it is because audio is not supported. Can I stream without Ti cloud/app being enabled? |
RTSP does not depend on the Cloud setting. |
Yes you can, I disabled cloud and both RTSP streams work. Anyway I didn’t succeed in fixing that ffmpeg issue, I tried every possible settings, even using another homebridge plugin with ffmpeg OMX, someone is guessing it could be a problem with the 555 RTSP implementation (a version had some problems) that is not complying with ffmpeg RTSP “guidelines” |
I tried to compile different version of 555 but withou solving the problem. |
Thanks so much for testing and the efforts! So you experienced the same problem when connecting the RTSP stream to a ffmpeg decoding instance? Can you confirm isn’t my issue? Anyway, my network is really solid and the camera is placed directly over the router... does Yi hack v4 use the same live555 lib? There is a dedicated plugin homebridge-ffmpeg-ui that is based on the same one I use and it used to work for Yi hack v4 users, I tried it but no luck.. same problem |
ch0_0 seems to be for high resolution, and ch0_1 is for low resolution. |
I have the same issue with ffmpeg. |
I have this issue too unfortunately. My setup is a BFUS Yi Home 1080p, updated to 0.2.5 right now. Running homebridge-camera-ffmpeg. The stream lasts a few seconds then fails entirely. Sometimes after a few minutes/hours Homekit refuses to fetch the feed at all. Does this provide any other kind of stream, such as hls? |
I also posted the issue in the ffmpeg hombridge git, and one user last day mentioned he found a "solution", I tested it.. and it works flawlessly! But anyway still ffmpeg can't process the live555 stream this hack is generating as it isn't compliant! You need to set the video codec-> vcodec to "copy", so homebridge-ffmpeg passes the h264 to HomeKit directly without further processing, here is an example of my config: { |
Interesting. Unfortunately this is my Homebridge output when I try that:
Also, how does this work for iPads, which request a 1080p stream? |
I think the log is normal.. as you are trying to scale the video but the codec is set to copy, I don’t have an iPad but on my mac it works flawlessly |
Very interesting.
|
This appears to work for me for livestreaming on lovelace ui on latest hassio. I was getting intermittent lockups before adding '-err_detect ignore_err' flag. Can anyone confirm?
There are also '-err_detect aggressive -fflags discardcorrupt' and ignore_io_errors flags, I've not tested those. |
I tried your recommondation to test it but no success. Still getting the error with homebridge-ffmpeg latest version and as well ffmpeg directly from ffmpeg.org latest version and YI cam. Every other application like vlc, video surveillance software etc. is working inside out. Below homebridge config:
and below log level with debug activated: [1/22/2020, 7:20:15 PM] [Camera ffmpeg] Start streaming video from YI with 1280x720@299kBit built with Apple clang version 11.0.0 (clang-1100.0.33.16) [tcp @ 0x7fdae9d2ff80] No default whitelist set [tcp @ 0x7fdae9d2ff80] Original list of addresses: [tcp @ 0x7fdae9d2ff80] Successfully connected to 192.168.10.55 port 554 [rtsp @ 0x7fdaea000000] SDP: Failed to parse interval end specification '' [rtsp @ 0x7fdaea000000] setting jitter buffer size to 0 [rtsp @ 0x7fdaea000000] hello state=0 Failed to parse interval end specification '' [h264 @ 0x7fdaea817000] nal_unit_type: 7(SPS), nal_ref_idc: 3 [h264 @ 0x7fdaea817000] nal_unit_type: 7(SPS), nal_ref_idc: 3 [h264 @ 0x7fdaea817000] unknown SEI type 240 [h264 @ 0x7fdaea817000] nal_unit_type: 6(SEI), nal_ref_idc: 0 [h264 @ 0x7fdaea817000] Frame num gap 34 32 [1/22/2020, 7:20:15 PM] [Camera ffmpeg] Stopped streaming |
You cant'use vcodec copy with a 1280x720 res. |
Thanks for the updates. I tried this yesterday and now have it fully working. The feed now rarely breaks. I'm using homebridge-camera-ui (which I believe is forked from homebridge-camera-ffmpeg), and these are my settings:
|
Hi folks, thanks very much for your comment based on the issue I'm facing. See below homebridge-camera-ffmpeg configuration: platform": "Camera-ffmpeg", Another note as I was also playing with motion events etc and now everything is configured and working over home app, I'm wondering how can I get the motion triggering happening in the right way. I was thinking over MQTT and pass the message to a pseudo trigger in home app, which triggers then a movement event via IOS. Again thanks for your help guys to get it at least running with SD and very stable :-) |
Hi All, I can confirm what @efkayx saying. I am also running low-resolution streams from few cameras for the last few days without any issues. It seems that the 1080p stream itself not good, I don't know what is the difference between low and high res streams. @roleoroleo any chance you can take a look? Thanks in advance! |
What did you manage to get related to motion events in “home” app? (Home kit?) I would like to know |
Yes, I'll take a look but I have already studied the stream a lot without luck. |
Thanks a lot @roleoroleo! Btw, for those who interested I am running following config:
In my opinion, the following params don't play any rule because "vcodec": "copy" is in use:
@Vannixxo regarding motion events, you need to represent it somehow, for example as "fake" motion sensors. If you want to do it, you will need to run some MQTT broker. I am running mosquitto together with homebridge and homebridge-mqttthing plugin and everything works very well. |
Great discussion here folks and glad to see the help and responve from all of you. @stickpin exactly this is what I want to realize via MQTT and triggering motion events with a fake motion sensor and the homebridge-mttting plugin. Would you be able to share your configuration with homebridge-mqttthing plugin and mosquitto. I do have mosquitto running on the same instance as the homebridge server and as well activated MQTT on the YI-Cam webinterface. |
I think the h264 stream is correct.
copy to a desktop system
Something is wrong in the live555 library or the wireless network is not working properly (driver unstable, far router, too much traffic...). |
720p seems to be better behaved with home assistant for me. I haven't looked too deeply but load on the camera in top seems to be on the high side with 1080p and there is a lot of jitter when pinging the camera. On a strong wifi I get 500ms+ pings. Is this a load issue? As a side note, I managed to clock the soc to 1ghz from 800mhz but haven't tested to see if that helps the issue. The camera remains stable though. Also, it appears to use alsa for audio, that could be mux'd into the stream fairly easily I guess |
With RTSP client running, my camera is stable with a ping < 10ms Interesting your work about the overclocking and audio. |
Clocking is easy, just echo 1000000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq. I am not sure about alsa being used, but there is a playback and capture device in the device tree if you look around in the FS. |
Audio would be awesome.. |
I don't konw if the toggle enable/disable works as you espect.
and another API to save the setting permanently:
I'm working on a bug fixing about these files. |
So are this the same settings as the new option In the user panel? What’s the difference with saving the option permanently? I thought this would turn off or on all the functions of the camera but it is still physically on waiting and accepting the command of turning back on |
If someone has a toolchain set up it would be interesting to see if its possible to capture audio. I am a bit busy to take a look but this example could be used to do a quick test. https://gist.github.com/albanpeignier/104902 |
Yes these API are called when you press "Save" on the web page. |
Please, open new issue or reuse old issues for audio and enable/disable switch. |
Apologies is this has already been mentioned/tried. I noticed the max buffer size for 1080p on rtspserver is set at 30000, I have seen recommendations to up that to 65000 to alight with UDP limits. |
Could you share these recommendations? |
Hi @stickpin ...exactly this is what I want to realize via MQTT and triggering motion events with a fake motion sensor and the homebridge-mttting plugin. Would you be able to share your configuration with homebridge-mqttthing plugin and mosquitto. I do have mosquitto running on the same instance as the homebridge server and as well activated MQTT on the YI-Cam webinterface. Do you have any chance and time to help me out here? |
@efkayx I've moved to homebridge-camera-ui instead of homebridge-camera-ffmpeg. It's a fork of it, but it adds an inbuilt motion sensor accessory to the camera so you don't need a fake sensor. Here is the config for one of my cameras: {
"platform": "CameraUI",
"videoProcessor": "ffmpeg",
"cameras": [{
"name": "Lobby Camera",
"debug": true,
"active": true,
"videoConfig": {
"debug": true,
"source": "-rtsp_transport tcp -err_detect ignore_err -i rtsp://192.168.50.69/ch0_0.h264",
"stillImageSource": "-i http://192.168.50.69:8080/cgi-bin/snapshot.sh?res=low&base64=no",
"maxStreams": 3,
"additionalCommandline": "-fflags +discardcorrupt",
"maxWidth": 1280,
"maxHeight": 720,
"maxBitrate": 300,
"maxFPS": 30,
"vcodec": "copy",
"packetSize": 1316,
"audio": false
},
"mqtt": {
"active": true,
"host": "192.168.50.47",
"port": 1883,
"username": "",
"password": "",
"topicPrefix": "agema",
"topicSuffix": "motion",
"startMessage": "motion_start",
"stopMessage": "motion_stop",
"recordOnMovement": false,
"recordVideoSize": 30,
"interval": 120
}
}]
} As mentioned above, this setup has been working perfectly for me for weeks now. :) (On iPhone, iPad Pro, and macOS) One thing to note with this setup is I've configured the snapshot to be the low res version. The high res version takes a second or two, and I think Homebridge/Homekit things its taking too long, and displays a half complete corrupted snapshot. The low res version works fine and is clear enough for the thumbnail. |
I saw it mentioned here, it might not be the problem but it could be worth seeing if increasing the buffer helps. http://lists.live555.com/pipermail/live-devel/2013-April/016816.html |
The maxSize value in rRTSPServer.cpp now is 300000. |
I agree. I am implementing a baby cam monitor under homeassistant but there is no way to filter any noise with ffmpeg_noise. Since audio is missing, ffmpeg_noise is always "Unavailable". |
I was testing the RTSP with ffmpeg to see what was the issue. On the Pi it hangs after 2 or 3 seconds with the 1080p stream, on Windows using homebridge + ffmpeg works fine with no issues. I got the Yi Home 1080p stream running on Apple Home app for more than 10 minutes without crashing. It looks like we are depending on an update from the devs from ffmpeg to fix this problem in the Linux distribution. |
On a related note, i was getting similar behavior when building an RTSP server for the YI using libx265 and using ffmpeg as the RSTP client. |
Sorry for the delayed response. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
Hello, I installed the latest version on my 6FUS and everything seems fine. I wanted to use this camera through homebridge and expose the RTSP stream to Apple Home Kit.
The ffmpeg plugin is extracting stills successfully from the dedicated http url, but the video stream doesn't work, is this a know issue?
The text was updated successfully, but these errors were encountered: