Green video stream when playing back on iOS device
TheCJGCJG opened this issue · comments
Hey, thanks for your time on this project, it is a great idea and really easy to use. I apologise if this issue has been submitted previously, but I did have a look through the previous ones and may have missed it
I have setup Homebridge and Shinobi - both are running on the same network (both in Docker on the same machine actually). There are currently 2 RTSP cameras connected to Shinobi (also on the same network).
Most things seems to work for me within homebridge-shinobi, including motion detection alerts, jpeg previews - however, I am having an issue when I attempt to play the live camera stream - the display goes green (or mostly green) with some artifacts at the top left. Image previews seem to work as expected, and this only becomes an issue once you try and play back a live stream. It sits and loads for about 10 seconds, and then this screen comes up.
Some IP addresses for context in the logs, in case it's useful
192.168.1.196 - Homebridge (host bridged network) and Shinobi (inside container, no host-bridge network)
192.168.1.211 - Apple TV
192.168.1.242 - RTSP Camera
I am currently using version homebridge-shinobi v3.0.11
Log output from Homebridge relevant to this monitor
[7/5/2022, 9:37:53 PM] [Shinobi] createMonitor()
[7/5/2022, 9:37:53 PM] [Shinobi] processing monitor: BackGardenLoft
[7/5/2022, 9:37:53 PM] [Shinobi] found existing accessory for UUID: 87713182-cb64-474d-9ad5-a6755012ac47 => BackGardenLoft monitor
[7/5/2022, 9:37:53 PM] [Shinobi] creating ShinobiStreamingDelegate using shinobi config: {"mid":"BackGardenLoft","ke":"charlesgillham","name":"Back Garden","shto":"[]","shfr":"[]","details":"{\"max_keep_days\":\"\",\"notes\":\"\",\"dir\":\"\",\"rtmp_key\":\"\",\"auto_host_enable\":\"1\",\"auto_host\":\"rtsp://192.168.1.242/11\",\"rtsp_transport\":\"tcp\",\"muser\":\"\",\"mpass\":\"\",\"port_force\":\"0\",\"fatal_max\":\"0\",\"skip_ping\":null,\"is_onvif\":null,\"onvif_non_standard\":null,\"onvif_port\":\"\",\"primary_input\":\"0:0\",\"aduration\":\"1000000\",\"probesize\":\"1000000\",\"stream_loop\":\"0\",\"sfps\":\"\",\"wall_clock_timestamp_ignore\":null,\"accelerator\":\"0\",\"hwaccel\":\"auto\",\"hwaccel_vcodec\":\"\",\"hwaccel_device\":\"\",\"stream_type\":\"hls\",\"stream_flv_type\":\"ws\",\"stream_flv_maxLatency\":\"\",\"stream_mjpeg_clients\":\"\",\"stream_vcodec\":\"copy\",\"stream_acodec\":\"no\",\"hls_time\":\"2\",\"hls_list_size\":\"3\",\"preset_stream\":\"ultrafast\",\"stream_quality\":\"15\",\"stream_fps\":\"\",\"stream_scale_x\":\"\",\"stream_scale_y\":\"\",\"stream_rotate\":null,\"signal_check\":\"5\",\"signal_check_log\":\"0\",\"stream_vf\":\"\",\"tv_channel\":\"0\",\"tv_channel_id\":\"\",\"tv_channel_group_title\":\"\",\"stream_timestamp\":\"0\",\"stream_timestamp_font\":\"\",\"stream_timestamp_font_size\":\"\",\"stream_timestamp_color\":\"\",\"stream_timestamp_box_color\":\"\",\"stream_timestamp_x\":\"\",\"stream_timestamp_y\":\"\",\"stream_watermark\":\"0\",\"stream_watermark_location\":\"\",\"stream_watermark_position\":\"tr\",\"snap\":\"1\",\"snap_fps\":\"1\",\"snap_scale_x\":\"1920\",\"snap_scale_y\":\"1080\",\"snap_vf\":\"\",\"vcodec\":\"copy\",\"crf\":\"1\",\"preset_record\":\"\",\"acodec\":\"no\",\"record_scale_y\":\"\",\"record_scale_x\":\"\",\"cutoff\":\"5\",\"rotate\":null,\"vf\":\"\",\"timestamp\":\"0\",\"timestamp_font\":\"\",\"timestamp_font_size\":\"10\",\"timestamp_color\":\"white\",\"timestamp_box_color\":\"0x00000000@1\",\"timestamp_x\":\"(w-tw)/2\",\"timestamp_y\":\"0\",\"watermark\":\"0\",\"watermark_location\":\"\",\"watermark_position\":\"tr\",\"record_timelapse\":\"0\",\"record_timelapse_mp4\":null,\"record_timelapse_fps\":null,\"record_timelapse_scale_x\":\"\",\"record_timelapse_scale_y\":\"\",\"record_timelapse_vf\":\"\",\"record_timelapse_watermark\":null,\"record_timelapse_watermark_location\":\"\",\"record_timelapse_watermark_position\":null,\"cust_input\":\"\",\"cust_stream\":\"\",\"cust_snap\":\"\",\"cust_record\":\"\",\"cust_detect\":\"\",\"cust_detect_object\":\"\",\"cust_sip_record\":\"\",\"custom_output\":\"\",\"detector\":\"1\",\"detector_http_api\":null,\"detector_send_frames\":\"1\",\"detector_fps\":\"\",\"detector_scale_x\":\"640\",\"detector_scale_y\":\"480\",\"detector_lock_timeout\":\"\",\"detector_save\":\"0\",\"detector_record_method\":\"sip\",\"detector_trigger\":\"1\",\"detector_trigger_record_fps\":\"\",\"detector_timeout\":\"10\",\"detector_send_video_length\":\"\",\"watchdog_reset\":\"0\",\"detector_delete_motionless_videos\":\"0\",\"det_multi_trig\":null,\"group_detector_multi\":\"\",\"detector_webhook\":\"1\",\"detector_webhook_timeout\":\"2\",\"detector_webhook_url\":\"https://{MY_HOMEBRIDGE_SHINOBI_WEBHOOK_DOMAIN}/?mid=BackGardenLoft&group=charlesgillham\",\"detector_webhook_method\":\"GET\",\"detector_command_enable\":\"0\",\"detector_command\":\"\",\"detector_command_timeout\":\"\",\"snap_seconds_inward\":\"\",\"detector_mail\":\"0\",\"detector_mail_timeout\":\"\",\"use_detector_filters\":null,\"use_detector_filters_object\":null,\"cords\":\"{\\\"JLq11\\\":{\\\"name\\\":\\\"Decking\\\",\\\"sensitivity\\\":\\\"25\\\",\\\"max_sensitivity\\\":\\\"80\\\",\\\"threshold\\\":1,\\\"color_threshold\\\":9,\\\"points\\\":[[\\\"197\\\",\\\"327\\\"],[\\\"274\\\",\\\"480\\\"],[\\\"447\\\",\\\"478\\\"],[\\\"524\\\",\\\"386\\\"],[\\\"375\\\",\\\"176\\\"]]},\\\"WQTdU\\\":{\\\"name\\\":\\\"Stairs\\\",\\\"sensitivity\\\":\\\"30\\\",\\\"max_sensitivity\\\":\\\"80\\\",\\\"threshold\\\":1,\\\"color_threshold\\\":9,\\\"points\\\":[[\\\"449\\\",\\\"307\\\"],[\\\"502\\\",\\\"390\\\"],[\\\"600\\\",\\\"287\\\"],[\\\"536\\\",\\\"221\\\"]]},\\\"0ngvY\\\":{\\\"name\\\":\\\"Garden Middle\\\",\\\"sensitivity\\\":\\\"15\\\",\\\"max_sensitivity\\\":\\\"80\\\",\\\"threshold\\\":1,\\\"color_threshold\\\":9,\\\"points\\\":[[\\\"153\\\",\\\"94\\\"],[\\\"153\\\",\\\"194\\\"],[\\\"239\\\",\\\"343\\\"],[\\\"390\\\",\\\"204\\\"],[\\\"294\\\",\\\"11\\\"]]},\\\"57eon\\\":{\\\"name\\\":\\\"Bottom of Stairs Against Fence\\\",\\\"sensitivity\\\":\\\"15\\\",\\\"max_sensitivity\\\":\\\"80\\\",\\\"threshold\\\":1,\\\"color_threshold\\\":9,\\\"points\\\":[[\\\"337\\\",\\\"104\\\"],[\\\"383\\\",\\\"226\\\"],[\\\"456\\\",\\\"307\\\"],[\\\"548\\\",\\\"243\\\"],[\\\"397\\\",\\\"102\\\"]]}}\",\"detector_filters\":\"\",\"detector_pam\":\"1\",\"detector_sensitivity\":\"\",\"detector_max_sensitivity\":\"\",\"detector_threshold\":\"1\",\"detector_color_threshold\":\"\",\"inverse_trigger\":null,\"detector_frame\":\"0\",\"detector_noise_filter\":null,\"detector_noise_filter_range\":\"\",\"detector_notrigger\":\"0\",\"detector_notrigger_mail\":\"0\",\"detector_notrigger_discord\":null,\"detector_notrigger_timeout\":\"\",\"detector_notrigger_webhook\":null,\"detector_notrigger_webhook_url\":\"\",\"detector_notrigger_webhook_method\":null,\"detector_notrigger_command_enable\":null,\"detector_notrigger_command\":\"\",\"detector_notrigger_command_timeout\":\"\",\"detector_audio\":null,\"detector_audio_min_db\":\"\",\"detector_audio_max_db\":\"\",\"detector_use_detect_object\":\"0\",\"detector_send_frames_object\":null,\"detector_obj_count_in_region\":null,\"detector_obj_region\":null,\"detector_use_motion\":\"1\",\"detector_fps_object\":\"\",\"detector_scale_x_object\":\"\",\"detector_scale_y_object\":\"\",\"detector_lisence_plate\":\"0\",\"detector_lisence_plate_country\":\"us\",\"detector_buffer_vcodec\":\"copy\",\"detector_buffer_acodec\":\"no\",\"detector_buffer_fps\":\"\",\"event_record_scale_x\":\"\",\"event_record_scale_y\":\"\",\"detector_buffer_hls_time\":\"\",\"detector_buffer_hls_list_size\":\"\",\"detector_buffer_start_number\":\"\",\"detector_buffer_live_start_index\":\"\",\"control\":\"0\",\"control_base_url\":\"\",\"control_url_method\":null,\"control_digest_auth\":null,\"control_stop\":\"0\",\"control_url_stop_timeout\":\"\",\"control_turn_speed\":\"\",\"detector_ptz_follow\":null,\"detector_ptz_follow_target\":\"\",\"detector_obj_count\":null,\"control_url_center\":\"\",\"control_url_left\":\"\",\"control_url_left_stop\":\"\",\"control_url_right\":\"\",\"control_url_right_stop\":\"\",\"control_url_up\":\"\",\"control_url_up_stop\":\"\",\"control_url_down\":\"\",\"control_url_down_stop\":\"\",\"control_url_enable_nv\":\"\",\"control_url_disable_nv\":\"\",\"control_url_zoom_out\":\"\",\"control_url_zoom_out_stop\":\"\",\"control_url_zoom_in\":\"\",\"control_url_zoom_in_stop\":\"\",\"control_invert_y\":null,\"groups\":\"[]\",\"notify_email\":null,\"notify_onUnexpectedExit\":null,\"notify_useRawSnapshot\":null,\"loglevel\":\"warning\",\"sqllog\":\"0\",\"detector_cascades\":\"\",\"stream_channels\":\"\",\"input_maps\":\"\",\"input_map_choices\":\"\"}","type":"h264","ext":"mp4","protocol":"rtsp","host":"192.168.1.242","path":"/11","port":80,"fps":1,"mode":"record","width":640,"height":480,"currentlyWatching":1,"currentCpuUsage":0,"status":"Recording","code":"3","snapshot":"/{MY_API_KEY}/jpeg/charlesgillham/BackGardenLoft/s.jpg","streams":["/{MY_API_KEY}/hls/charlesgillham/BackGardenLoft/s.m3u8"],"streamsSortedByType":{"hls":["/{MY_API_KEY}/hls/charlesgillham/BackGardenLoft/s.m3u8"]}}
[7/5/2022, 9:37:53 PM] [Shinobi] ShinobiStreamingDelegate using direct camera source: rtsp://192.168.1.242/11
[7/5/2022, 9:39:30 PM] [Shinobi] getMotionDetected() -> false
[7/5/2022, 9:39:30 PM] [Shinobi] getMotionDetected() -> false
[7/5/2022, 9:39:31 PM] [Shinobi] handleSnapshotRequest: FrontGardenLoft => {"height":360,"width":640} from https://{MY_SHINOBI_DOMAIN}/{MY_API_KEY}/jpeg/charlesgillham/FrontGardenLoft/s.jpg
[7/5/2022, 9:39:31 PM] [Shinobi] handleSnapshotRequest() success
[7/5/2022, 9:39:31 PM] [Shinobi] handleSnapshotRequest: BackGardenLoft => {"height":360,"width":640} from https://{MY_SHINOBI_DOMAIN}/{MY_API_KEY}/jpeg/charlesgillham/BackGardenLoft/s.jpg
[7/5/2022, 9:39:31 PM] [Shinobi] handleSnapshotRequest() success
[7/5/2022, 9:39:51 PM] [Shinobi] prepareStream: BackGardenLoft => {"sessionID":"{MY_SESSION_ID_THAT_IM_NOT_SURE_SHOULD_BE_PUBLIC}","targetAddress":"192.168.1.211","addressVersion":"ipv4","video":{"port":63174,"srtpCryptoSuite":0,"srtp_key":{"type":"Buffer","data":[72,12,54,5,114,172,19,56,244,75,194,76,100,54,233,79]},"srtp_salt":{"type":"Buffer","data":[25,103,53,172,104,180,184,55,169,195,142,105,193,202]}},"audio":{"port":57944,"srtpCryptoSuite":0,"srtp_key":{"type":"Buffer","data":[123,87,14,68,68,45,89,235,156,224,118,239,76,43,219,245]},"srtp_salt":{"type":"Buffer","data":[155,128,6,239,246,175,205,134,51,148,148,73,58,56]}}}
[7/5/2022, 9:39:51 PM] [Shinobi] prepareStream() success
[7/5/2022, 9:39:52 PM] [Shinobi] handleStreamRequest: {"sessionID":"{MY_SESSION_ID_THAT_IM_NOT_SURE_SHOULD_BE_PUBLIC}","type":"start","video":{"codec":0,"profile":1,"level":2,"packetizationMode":0,"width":640,"height":360,"fps":30,"pt":99,"ssrc":3333379509,"max_bit_rate":132,"rtcp_interval":0.5,"mtu":1378},"audio":{"codec":"OPUS","channel":1,"bit_rate":0,"sample_rate":24,"packet_time":20,"pt":110,"ssrc":1253487619,"max_bit_rate":24,"rtcp_interval":5,"comfort_pt":13,"comfortNoiseEnabled":false}}
[7/5/2022, 9:39:52 PM] [Shinobi] requested video stream: 640x360, 30 fps, 132 kbps, 1378 mtu
[7/5/2022, 9:39:52 PM] [Shinobi] -fflags +genpts -i rtsp://192.168.1.242/11 -vsync drop -vcodec copy -an -f rtp -payload_type 99 -ssrc 6711737 -srtp_out_suite AES_CM_128_HMAC_SHA1_80 -srtp_out_params SAw2BXKsEzj0S8JMZDbpTxlnNaxotLg3qcOOacHK srtp://192.168.1.211:63174?rtcpport=63174&localrtcpport=63174&pkt_size=1378
[7/5/2022, 9:39:52 PM] [Shinobi] handleStreamRequest() START success
[7/5/2022, 9:39:52 PM] [Shinobi] ffmpeg received first frame
And here is the log output from where the streaming delegate is created
iOS Screenshots
It seems to be using the correct rtsp url, which is rtsp://192.168.1.242/11 - if you open this in VLC the following information is available
Any assistance would be much appreciated
By running ps -aux | grep ffmpeg I found the following running ffmpeg instance that was relevant
ffmpeg -fflags +genpts -i rtsp://192.168.1.242/11 -vsync drop -vcodec copy -an -f rtp -payload_type 99 -ssrc 801513 -srtp_out_suite AES_CM_128_HMAC_SHA1_80 -srtp_out_params x3b/bbihsS/Y2NvxdU8J38ZPNEY75GbJ2r1tVZGU srtp://192.168.1.211:58143?rtcpport=58143&localrtcpport=58143&pkt_size=1378
I mutated this a bit (to validate the ffmpeg command and input etc) by using ffmpeg -fflags +genpts -i rtsp://192.168.1.242/11 -vsync drop -vcodec copy -an -f segment -segment_time 10 -segment_format mp4 "some-video-%03d.mp4"
And what seems to happen is that it outputs at a very low rate (about 0.1 seconds written to the disk for every 5 seconds time elapsed), and also seems to complain about dropping packets (for some reason). If this runs for 30 seconds I end up with a video file that is under 50ms long.
I've confirmed that the input is good at just writing out to the disk (my intention is to slowly build up the command til it doesn't work) with ffmpeg -i rtsp://192.168.1.242/11 -an -c copy -f segment -segment_time 10 -segment_format mp4 "some-video-%03d.mp4" - and this writes as expected.
Adding back all the flags before -i like so ffmpeg -fflags +genpts -i rtsp://192.168.1.242/11 -an -c copy -f segment -segment_time 10 -segment_format mp4 "some-video-%03d.mp4" works as expected, produces the following
➜ /tmp ffmpeg -fflags +genpts -i rtsp://192.168.1.242/11 -an -c copy -f segment -segment_time 10 -segment_format mp4 "some-video-%03d.mp4"
ffmpeg version 5.0.1 Copyright (c) 2000-2022 the FFmpeg developers
built with Apple clang version 13.1.6 (clang-1316.0.21.2.5)
configuration: --prefix=/usr/local/Cellar/ffmpeg/5.0.1_3 --enable-shared --enable-pthreads --enable-version3 --cc=clang --host-cflags= --host-ldflags= --enable-ffplay --enable-gnutls --enable-gpl --enable-libaom --enable-libbluray --enable-libdav1d --enable-libmp3lame --enable-libopus --enable-librav1e --enable-librist --enable-librubberband --enable-libsnappy --enable-libsrt --enable-libtesseract --enable-libtheora --enable-libvidstab --enable-libvmaf --enable-libvorbis --enable-libvpx --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2 --enable-libxvid --enable-lzma --enable-libfontconfig --enable-libfreetype --enable-frei0r --enable-libass --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libspeex --enable-libsoxr --enable-libzmq --enable-libzimg --disable-libjack --disable-indev=jack --enable-videotoolbox
libavutil 57. 17.100 / 57. 17.100
libavcodec 59. 18.100 / 59. 18.100
libavformat 59. 16.100 / 59. 16.100
libavdevice 59. 4.100 / 59. 4.100
libavfilter 8. 24.100 / 8. 24.100
libswscale 6. 4.100 / 6. 4.100
libswresample 4. 3.100 / 4. 3.100
libpostproc 56. 3.100 / 56. 3.100
Input #0, rtsp, from 'rtsp://192.168.1.242/11':
Metadata:
title : 10
Duration: N/A, start: 0.099000, bitrate: N/A
Stream #0:0: Video: h264 (Baseline), yuv420p(tv, bt709, progressive), 1920x1080, 20 fps, 10 tbr, 90k tbn
[segment @ 0x7f89b60054c0] Opening 'some-video-000.mp4' for writing
Output #0, segment, to 'some-video-%03d.mp4':
Metadata:
title : 10
encoder : Lavf59.16.100
Stream #0:0: Video: h264 (Baseline), yuv420p(tv, bt709, progressive), 1920x1080, q=2-31, 20 fps, 10 tbr, 10240 tbn
Stream mapping:
Stream #0:0 -> #0:0 (copy)
Press [q] to stop, [?] for help
[segment @ 0x7f89b60054c0] Timestamps are unset in a packet for stream 0. This is deprecated and will stop working in the future. Fix your code to set the timestamps properly
[segment @ 0x7f89b60054c0] Non-monotonous DTS in output stream 0:0; previous: 0, current: 0; changing to 1. This may result in incorrect timestamps in the output file.
[segment @ 0x7f89b60054c0] Opening 'some-video-001.mp4' for writingeed=1.31x
[segment @ 0x7f89b60054c0] Opening 'some-video-002.mp4' for writingeed=1.15x
frame= 232 fps= 11 q=-1.0 Lsize=N/A time=00:00:23.00 bitrate=N/A speed=1.13x
However, when I add -vsync drop notice the discrepancy between the timestamps compared to the video timestamp on the last line of the ffmpeg output
➜ /tmp ffmpeg -fflags +genpts -i rtsp://192.168.1.242/11 -vsync drop -an -c copy -f segment -segment_time 10 -segment_format mp4 "some-video-%03d.mp4"
ffmpeg version 5.0.1 Copyright (c) 2000-2022 the FFmpeg developers
built with Apple clang version 13.1.6 (clang-1316.0.21.2.5)
configuration: --prefix=/usr/local/Cellar/ffmpeg/5.0.1_3 --enable-shared --enable-pthreads --enable-version3 --cc=clang --host-cflags= --host-ldflags= --enable-ffplay --enable-gnutls --enable-gpl --enable-libaom --enable-libbluray --enable-libdav1d --enable-libmp3lame --enable-libopus --enable-librav1e --enable-librist --enable-librubberband --enable-libsnappy --enable-libsrt --enable-libtesseract --enable-libtheora --enable-libvidstab --enable-libvmaf --enable-libvorbis --enable-libvpx --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2 --enable-libxvid --enable-lzma --enable-libfontconfig --enable-libfreetype --enable-frei0r --enable-libass --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libspeex --enable-libsoxr --enable-libzmq --enable-libzimg --disable-libjack --disable-indev=jack --enable-videotoolbox
libavutil 57. 17.100 / 57. 17.100
libavcodec 59. 18.100 / 59. 18.100
libavformat 59. 16.100 / 59. 16.100
libavdevice 59. 4.100 / 59. 4.100
libavfilter 8. 24.100 / 8. 24.100
libswscale 6. 4.100 / 6. 4.100
libswresample 4. 3.100 / 4. 3.100
libpostproc 56. 3.100 / 56. 3.100
Input #0, rtsp, from 'rtsp://192.168.1.242/11':
Metadata:
title : 10
Duration: N/A, start: 0.100000, bitrate: N/A
Stream #0:0: Video: h264 (Baseline), yuv420p(tv, bt709, progressive), 1920x1080, 20 fps, 10 tbr, 90k tbn
[segment @ 0x7feb6680b700] Opening 'some-video-000.mp4' for writing
Output #0, segment, to 'some-video-%03d.mp4':
Metadata:
title : 10
encoder : Lavf59.16.100
Stream #0:0: Video: h264 (Baseline), yuv420p(tv, bt709, progressive), 1920x1080, q=2-31, 20 fps, 10 tbr, 10240 tbn
Stream mapping:
Stream #0:0 -> #0:0 (copy)
Press [q] to stop, [?] for help
[segment @ 0x7feb6680b700] Timestamps are unset in a packet for stream 0. This is deprecated and will stop working in the future. Fix your code to set the timestamps properly
[segment @ 0x7feb6680b700] Encoder did not produce proper pts, making some up.
frame= 589 fps= 11 q=-1.0 size=N/A time=00:00:00.05 bitrate=N/A speed=0.00103x
So, it seems as if the -vsync drop flag is causing the issue with my particular camera. Whilst I don't know too much about what this option does, or why it might be causing issues for me.
I modified homebridge-shinobi on my local machine to remove this flag (and various combinations of flags here), and my video stream then just never loaded on iOS. So i'd take a guess and say that this is required functionality.
After a bit of playing, I landed on this command (removing the vsync, adding -r 30 on the output), which makes the top part of the video stream be present.
-fflags +genpts -i rtsp://192.168.1.242/11 -vcodec copy -r 30 -an -f rtp -payload_type 99 -ssrc 1528618 -srtp_out_suite AES_CM_128_HMAC_SHA1_80 -srtp_out_params PfI4iEijTNlBxCGuzSszq6dGeFzsuVL59HkyW/c9 srtp://192.168.1.211:63664?rtcpport=63664&localrtcpport=63664&pkt_size=1378
I have noticed that in Shinobi itself, the following is being used for ffmpeg - In here, the rtsp_transport tcp stands out to me.
/usr/bin/ffmpeg -progress pipe:5 -use_wallclock_as_timestamps 1 -analyzeduration 1000000 -probesize 1000000 -fflags +igndts -rtsp_transport tcp -loglevel warning -i rtsp://192.168.1.242/11 -strict -2 -an -c:v copy -preset ultrafast -f hls -hls_time 2 -hls_list_size 3 -start_number 0 -hls_allow_cache 0 -hls_flags +delete_segments+omit_endlist /dev/shm/streams/charlesgillham/BackGardenLoft/s.m3u8 -vf fps=1 -s 1920x1080 -update 1 /dev/shm/streams/charlesgillham/BackGardenLoft/s.jpg -y -an -vcodec copy -strict -2 -movflags +faststart -f segment -segment_atclocktime 1 -reset_timestamps 1 -strftime 1 -segment_list pipe:8 -segment_time 300 /home/Shinobi/videos/charlesgillham/BackGardenLoft/%Y-%m-%dT%H-%M-%S.mp4 -vf fps=2 -s 640x480 -vf fps=2 -s 640x480 -an -c:v pam -pix_fmt gray -f image2pipe pipe:3 -vcodec copy -an -f hls -live_start_index -3 -hls_time 2 -hls_list_size 4 -start_number 0 -hls_allow_cache 0 -hls_flags +delete_segments+omit_endlist /dev/shm/streams/charlesgillham/BackGardenLoft/detectorStream.m3u8
With the following command -rtsp_transport tcp -i rtsp://192.168.1.242/11 -vcodec copy -r 30 -an -f rtp -payload_type 99 -ssrc 14966634 -srtp_out_suite AES_CM_128_HMAC_SHA1_80 -srtp_out_params /k60teqa6eiuESWWTagZQ1Bz+DBnuNzhpwqAcdFh srtp://192.168.1.211:51601?rtcpport=51601&localrtcpport=51601&pkt_size=1378 - the stream loads (eventually) but never refreshes (it seems to get stuck within the same second).
The fact it works when I change my transport mechanism to TCP, implies that the network path is at fault (despite this stream playing back happily in shinobi and in VLC) - so it seems that the ffmpeg command used here is not as forgiving for my camera/network combination.
I've ended up managing to get it to work as expected using the following value here https://github.com/vectronic/homebridge-shinobi/blob/master/src/shinobiStreamingDelegate.ts#L174
-use_wallclock_as_timestamps 1 -rtsp_transport tcp -i ${this.videoSource} -vcodec copy -an
Whilst i've managed to narrow down the issue in my environment, i'd imagine others may also notice a similar issue. It would be useful I think for this to be a configurable option (or even simply default to TCP like Shinobi does).
If I get time over the next few days i'll potentially go and figure out enough about homebridge integrations to do this myself and get it in as a configurable option in a pull request (or even make this whole ffmpeg command configurable).
Hello, thanks for your efforts on this.
I've been quite busy recently so didn't get time to respond.
Did you get any further in your analysis? If you have any PR I would gladly review and merge.
To be honest the ffmpeg command arguments I came up with were very much tied to my scenario. I wasn't expecting other people to use this plugin but am more than happy if they are.
I haven't spent that much time expanding the plugin further as I am not fully happy with the stability or usability of Shinobi. It feels like every time I do an upgrade, something else behaves strangely. For one thing I have never been able to get it to limit recording storage size. It seems to not clean up old recordings.
I am not tied to Shinobi long term, but there isn't much else available.
My main concern at the moment (which may well be a problem in my plugin) is that I end up with more spawned ffmpeg processes than there should be - and they are all using high CPU. I end up needing to restart the FreeBSD jail running Shinobi and everything calms down again.
Hey,
I completely forgot to go and make the PR for this, I resolved this on my side by using an ethernet cable for the cameras (cheap things off of the internet, of course!). I've gone ahead and written the code and opened a PR (#19) to allow others who may be experiencing the same issue to manually tweak the ffmpeg command - in my case
-use_wallclock_as_timestamps 1 -rtsp_transport tcp -i and -vcodec copy -an as the config options seemed to work well.
I much agree with you, around the other points, i'm not particually tied to the product either, if there's anything better available i'd switch over.