Lagarith vs. uncompressed...

[wunni]

Hello Robin,
I wanted to record a ISS passing in front of the Sun at maximum speed. As the Sun just fitted on the sensor of the QHY174 GPS, the image field was very large at 1440 x 1200 pixels. To maximise the frame rate, I recorded with 8 bit. I achieved approx. 115 fps.
The recording as ADV with SC 4.1.12590.0 Pro (PC: Lenovo MiniPC with i5-6500, 2.5GHz, 16GB RAM, 230GB NVME, Win10 Pro) ran smoothly. Almost 5,500 frames were recorded, 47 seconds, 8.7 GB (!).
Now I wanted to watch the video with ‘DVTI VideoTools’ by Andreas Schweizer and cut and convert the ‘hot phase’ as MP4. But the programme crashed almost immediately.

Andreas examined my ADV file and found that only the first 6 frames were Lagarith-compressed and then saved uncompressed. I can't imagine that this was done on purpose. Was this perhaps the emergency brake due to the very high data rate?

(Andreas found out that the beta version of the DVTI VideoTool could not yet process the uncompressed video.)

90 minutes later I recorded the ISS passing in front of the Moon, at 16 bit and approx. 65 fps.
I was able to view and edit this video (4.7 GB) with the tool - the Lagarith compression must have worked here.

Bug or feature, that is the question...

Best regards,
Niko

[admin]

Hi,

I had to go and check the code, since it is a long time since I looked at the code for ADV file writing

It turns out to be a feature!

If two or more of the first five frames written to an ADV file take longer to write out than the delay from one frame arriving to the next, SharpCap turns off the compression in the hope of getting the frame writing rate to increase sufficiently so that we don't get dropped frames due to the slow write rates. This was added after I noticed that the compression added quite a big overhead to writing data into ADV files.

I believe that the lower frame rate of the second capture (65fps, so about 15ms between frames rather than 8.7ms for the first capture) means that the trigger threshold for turning off compression was not reached.

If this is a problem for you that cannot be overcome by an update to DVTI then I would be able to add an option to enable/disable this compression change.

cheers,

Robin

[wunni]

Hi Robin,

Thanks for the explanation! So it really is some kind of an "emergency brake". Great thing!
Andreas Schweizer (DVTI VideoTool) has already integrated the reading of uncompressed 8-bit ADV. You don't need to install a switch.
In my case, it really was an extraordinarily high amount of data per second. It's amazing what is possible today...

Thank you and best regards,
Niko