You mentioned you played with bitrate, but did you try turning down the quality? Turning it down to low or lower made the video smooth for me. I occasionally see this on my Hikvision 4MP ColorVu G1 cameras - mostly when the variable bit rate of the stream increases due to image conditions. Let us know what you find out when you contact BI Support. Has anyone seen something like this before and have any ideas? It's got me beat as there's certainly no lack of resources and the direct streams look totally fine. Substreams do not show the stutter, only after double clicking and the main stream pops up does it stutterĪll cameras look perfectly fine in their respective live view websites navigating directly as well as streaming in VLC. No hardware acceleration (have tried every setting) Version 5.3.8.4 fully registered (tried various versions down to 5.3.6.7) I know they don't rate highly here but the camera fits the purpose I need it for. Video Encoding H265 (tested with H264 as well) Recording to 4TB network storage (although same issue occurs recording locally) I do not know if Foscam cameras possess this option.Hoping to get some help with an issue I'm seeing in Blue Iris where every second there is a very brief stutter in the playback, both with live view and recordings. Anyway it controls the length of the video buffer and therefore the length of the video delay, but in some cases it only affects the player embedded in the camera's web interface. I've seen an option on some PTZ cameras that lets you choose the "streaming fluency" I think they call it. The cost is MJPEG uses a lot more bandwidth and does not support an audio stream. MJPEG is a much, much simpler format that avoids most of the buffering and should have much less delay. If you want to reduce the delay, just about your only option is to use MJPEG video instead of h264, if available. The delay is caused by buffering times that are unavoidable. The distance is not going to introduce additional delay. If the fiber is used for ordinary computer networking, you should send the camera data down it, because fiber is better for long distances like 300' (up to many tens of km depending on the sending and receiving devices) whereas 328 feet or so is the maximum range spec of copper-based ethernet runs. Will the 300' length of the network cables slow down the delay even more? Which cable would be best, the dedicated CAT6 or the fiber that will already be sending data from other devices? When I move the camera out to the observatory it'll be 300' away from the computer/router, but I still plan to wire it either with a dedicated CAT6 cable or with a short CAT6 cable (3') to a gigabit switch which will have other devices connected to it also since it's the main network between my house and observatory, but that network uses fiber optics. So what setting will help to get to live with no delay? I noticed that there is a fraction of a second delay in the live feed but I'd like for there to be no delay because I'll be moving the camera out into my observatory and I control all of the astronomy equipment for in my house, so I'd like to be able to have the camera looking over my equipment so I know if there is a problem during a slew so I can stop the scope from moving right away, and having a slight delay could be all the delay needed for something to go majorly wrong and get really expensive. Now that I updated to the latest release of v3 there are a lot of new features and options, so once I'm finished reading through the help document I'm sure I'll have more questions about trigger recording and others stuff. Plus I sent an email to BI's support to see if they can help me with getting v4 because I don't know if I can return software. Now that I installed the BI v3 update my camera is a choice in the drop down menu, so now BI works for me.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |