Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - oakwhiz

Pages: [1]
Software Dev / Re: raw video data
« on: September 15, 2017, 10:54:42 PM »
RAW is in the works, and we have remote RAM saving via network on our "want" list already.
Note that the Gigabit Ethernet interface is not fast enough to handle the camera's live data, it would need to be buffered and slowly downloaded.

Software Dev / Re: "Missing" the out point when saving.
« on: September 08, 2017, 02:41:46 AM »
In a previous post:
Tesla_500: "The SD interface is limited to 48MHz @ 4-bit, so cards above 24MB/s are of no benefit. I've had good luck with normal class 10 cards (10MB/s). Higher speeds may be beneficial later when RAW saving is available, but there doesn't appear to be any benefit for compressed saving, except maybe if you turn the bitrate up very high."

So I made sure I got 40Mb/s + cards. (The common speed up from that point).

What I'm /really/ curious about when it comes to writing out raw data.. Is this RJ45 connector on the side that has some kind of high speed twisted pair interface that can handle rather a lot of data? :)  (Or even the esata interface in a pinch) Maybe directly off the sensor, trade off resolution/fps for external storage? :)   1000fps,  800x600(or lower).. But writing directly to disk, rather than the RAM buffer? :)
But that is just me dreaming for now.

I forgot about the speed limitation on the SD interface. I'd hazard a guess that the eSATA interface would be the fastest way to exfiltrate data from the camera, since it runs at 3 Gbps.

Software Dev / Re: "Missing" the out point when saving.
« on: September 08, 2017, 01:56:55 AM »
Another manifestation of this issue: if your saved footage has a random or semi periodic stutter in it, your disk is too slow, and the encoder is skipping frames as a result.

My 80Mb/s cards write no faster than 40Mb/s ones. 

It's true that this is a limitation of the encoder. It may be technically possible for a lossless compression algorithm to surpass the encoder's speed, but at the cost of SD card free space. We are looking into various lossless compression options such as linear predictive coding over YUV color space data, or raw bayer data.

Chronos User Discussion / Re: List of good (and bad) SD cards
« on: September 07, 2017, 01:05:59 PM »
Can the files be transferred to a computer Via USB without the need of an SD card? Or is the SD card required?
Currently you have to remove the SD card from the camera in order to transfer the files.

In the future, the camera is planned to be able to provide a USB Ethernet interface through the USB OTG port, acting as a USB device. This would create an virtual NIC device on a PC that communicates with the camera directly, which is convenient in many ways. We are thinking about the possibility of exposing the filesystems of the attached disks of the over this network interface, but I don't believe we have made any concrete plans just yet. I'd imagine that SFTP, rsync, HTTP, FTP, etc. could all be used in theory.

Software Dev / Re: "Missing" the out point when saving.
« on: September 07, 2017, 12:25:29 PM »
These cards have been working very well:

I'd like to second this, I have had very good experiences with these cards.

That is known to happen when the card becomes completely full during save, and potentially if the card doesn't have enough write speed. It seems quite rare though, if you find a way to reliably duplicate it, let me know!

I'd also like to elaborate on this, the technical reason for this issue seems to stem from the disk not being able to answer requests in time. Good quality SD cards are able to maintain a certain minimum constant I/O bandwidth, but lower quality SD cards operate in fast bursts followed by periods of inactivity (they probably have internal SRAM cache to make up for the fact that they have poor flash block erase performance.) If the disk blocks on I/O then two things happen: the encoder buffers start to become full, and a certain piece of code feeding frames to the encoder tends to get stuck in an infinite loop when frames are dropped. The encoder is synchronous, but we are working on a way to add flow control. This would enable the encoder is able to pause the flow of frames from RAM when the encoder is unable to push frames onto the disk.

Chronos User Discussion / Re: Can't Play Files
« on: September 07, 2017, 10:36:38 AM »
Any chance you can upload the failed files somewhere? I'd like to investigate.

I had one report of failed files if you ejected the card too soon after a save completed, did you do anything like that?

Edit: One more question, any idea how long (how many frames) the clip was? ie. how far between mark in and mark out?

You can try recovering the files with the utility recover_mp4. This is a somewhat complex command line utility however. If you sent the files I can try running it on them.

I'd like to add that the same utility helped me recover a file that was corrupted by a discharged battery. If the Chronos experiences a power failure during encoding, the MOOV atom is not written to the end of the file. This utility is able to rebuild a new MP4 file with a correct MOOV atom.

Chronos User Discussion / Re: Chronos 1.4 Footage Thread
« on: September 07, 2017, 10:21:20 AM »

Chronos User Discussion / Re: Chronos 1.4 Footage Thread
« on: June 19, 2017, 02:17:53 AM »

Chronos User Discussion / Re: Chronos 1.4 Footage Thread
« on: June 17, 2017, 01:37:28 AM »
Here's another couple of videos taken with a monochrome camera (I think we took the IR filter off as well):

PS: the Verification on every post is a touch over kill. You should only need it if you are allowing guests to be able to wright to the board. (not recommended)
Also to avoid spammers you should turn on verify email address. and install the stop forum spam plugin. I'm pretty sure someone makes one for simple machines. 

Made some changes in that regard.

Pages: [1]