H.264/H.265), then again SecuritySpy has to decode every incoming frame, and then encode and save the right frame(s) as JPEG. But if this incoming video is anything else (e.g. If the incoming video from the camera is JPEG, then SecuritySpy can use the source data as-is for this. >Still images are always written in JPEG format. SecuritySpy uses Apple's VideoToolbox API for video encoding/decoding, not ffmpeg. scientific experiments, interviews, film sets), where they need to capture very high quality video from sources such as Blackmagic devices, and this option is to make SecuritySpy even more useful for this set of customers. We have many customers using SecuritySpy for non-CCTV purposes (e.g. H.264/H.265), then again SecuritySpy has to decode every incoming frame, and then encode and save the right frame(s) as JPEG.Īs for ProRes - yes this option has just been added, but it's not useful for CCTV purposes as the file sizes will be far too large. Still images are always written in JPEG format. This is the only way to change the frame rate of an H.264/H.265 stream. In this case, SecuritySpy has to decode all incoming frames, and then encode just the ones it needs for the captured files. If the camera is supplying JPEG video, then SecuritySpy can drop frames from the incoming stream in order to satisfy any frame rate requirement for recording, however this is not possible for temporally-compressed streams such as H.264 or H.265. If this option is on, then SecuritySpy decodes this incoming data, and then encodes it to the format specified under Preferences -> Compression. If the "Recompress video data" option is off (as it is by default), then SecuritySpy writes the video data supplied by the camera directly to the recorded files. ? Which should be fine, because you allow for a separate playback rate specified in the resulting movie so the capture rate is mutually exclusive and arbitrary. I realize this could result in users specifying some non-integer results, ie 3 frames per 5 seconds, but that would actually be ok, wouldn't it? If your timer is perhaps working out the capture time in the nearest millisecond or something like that, then it would simply capture every 600 milliseconds, etc. If I could capture a continuous MOVIE at 1 frame per 5 seconds (or 'n' seconds) that would be a lot less hassle than managing image sequences.Ĭapture Rate: _ frames per _ second(s) (adding a text field for the seconds value) This is a nice balance for me in terms of data management vs continuous monitor vs motion capture. If I could lower the frame rate on Continuous Capture > Movie Capture to less than 1 frame per second that would be very helpful and perhaps a lot less work.Īs I mentioned before, my cameras are generally configured to capture continuous image 1 frame every 5 seconds, while motion capture is around 60-120 seconds with 60-240 seconds pre/post roll. I'm doing a lot of work to utilize the Continuous Capture > Image Capture feature the way I need it - which is all good, but.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |