I had the same issue with the video files i recorded with Kstars/Ekos during the weekend.
My camera is a ToupTek GP-1200-KMB Mono and I was recording in full resolution (1280x960).
IAccording to the manual my camera supports a bit depth of 12.
In the INDI Control Panel inside KStars I selected the camera and on the Image Info tab in it says "Bits per pixel: 16".
And on the Controls tab I can see that "Mono 16" is selected. The only other option is "Mono 8".
I wonder if this is the issue for me? Camera supports only 12 bits but INDI is configured for 16?
However, the live view looked good and recording went fine.
I also captured some normal frames that looks fine (see attached image).
But the movies I recorded with the live view (ser format) looks very weird when i see them in AutoStakkert and I am not even able to open them in PIPP.
The moon appears twice on the videos and it does not look at all like the single frames.
The 2 moons looks like they are made of white and black noise.
If I reduce the SER scaling in Autostakkert to 8 bit there are still 2 moons and each of them looks a bit like the single frames I captured (but much darker).
If I turn up the brightness to 8x the 2 moons starts looking much more like the single frames, but it is obvious that the greyscale quality is much worse.
PIPP shows me this header details for one of the ser files:
I can confirm that I can record video files that works fine if I select "Mono 8" on the Controls tab.
So I will do that going forward. But I still hope to save the videos I took during the weekend if anyone has a tip I will be very happy.
BTW, I can also confirm that trying to record cropped videos from the Live view results in useless video files no matter if "Mono 8" or "Mono 16" are selected.
EDIT: I used a hex editor to change the bit depth in the SER file header from 16 bit to 8 bit. It made it possible to open and watch the files but the video stream was corrupted and the images could not be used for stacking. So I have to delete the files and capture new ones with "Mono 8" next time I have clear skies.
I played a bit around and it looks like Ekos always dumps full resolution 8 bit depth SER videos when recording from the live view (with my camera at least).
However, the SER header gets the correct information about bit depth (Based on INDI settings) and resolution (Based on live view frame size).
If anyone can point me to the place in the code where video files are written to disk I can try to take a look at it.
I am a developer by profession and have some C++ experience from years back, but I have no experience with the KStars/Ekos code or INDI.
Right so when live streaming, bit-depth is automatically reduced to 8bit to help make it faster. This is done in INDI. Thanks for offering to help, it is very much required to improve streaming & recording issues in INDI. You can find the logic in the function
in streammanager.cpp in INDI.
Right now, it's downscaling to 8bit. Though I can see that one improvement could be to immediately record the data before performing the downscaling. At any rate, I'm open to ideas for improvement. A few weeks ago I had to disable the threading for asyncStream when recording is active as I couldn't trace back a thread issue with file descriptors. Right now it's running on the main thread so it's slower but works OK. If you can also investigate this part it would be great!
I would like to set it up locally on my machine so I can debug it.
I guess that it is possible to make the local KStars project use the local INDI project so I can debug it and try out my code changes.
And I guess that you already have that set up so any suggestions would be great before I try to make it work on my own.
I am using Debian for the task.
Here in Denmark we have had clear skies for several days in a row now so I have not spent much time on debugging the issue yet.
But my development setup is ready (following the link you sent) and Ihave verified that I am able to debug the local indi code by connecting in Ekos as you described above.
Everything is working, now I just need some time to debug and see what I can discover
Yesterday, I read through the INDI developer manual to get a better understanding before I start debugging.
Yes, put set follow-fork-mode child in the GDB options. Check below:
You can also start it as:
-v ./indi_simulator_ccd indi_simulator_telescope
Then whenever you make changes to the CCD simulator, you can simply compile and run again without running sudo make install. Please note that when you stop the debugger, it does not kill indiserver. So if you want to truly restart the indiserver, you must type in a terminal pkill indiserver before clicking debug again.
Thank you, that helped a lot.
Now my breakpoints are activated in all different parts of the code.
However, as soon as I start "Live Video" in the CCD module of Ekos in Kstars with CCD Simulator, the debugger exits without stopping anywhere.
In Tools -> Options -> GDB Extended I have checked "Stop when qFatal() is called" and "Stop when abort() is called" but apparently none of those are called when it stops.
Below in the spoiler you can find the content of the Debugger log at that time.
Kstars/Ekos continues behaving normally after the debugger stops.
The CCD Simulator continues showing live view as if nothing happened.
Have you experienced this issue with sudden debugger exit before?
sThread group i4 created.
dTaking notice of pid 5771
sThread 4 in group i3 exited.
sThread group i3 exited.
sThread 5 created.
>~"[New process 5771]\n"
s[New process 5771]
dNOTE: INFERIOR STILL RUNNING IN STATE InferiorRunOk.
>~"process 5771 is executing new program: /usr/bin/gsc\n"
sLibrary /lib64/ld-linux-x86-64.so.2 unloaded.
sLibrary /lib/x86_64-linux-gnu/libc.so.6 unloaded.
sLibrary /lib64/ld-linux-x86-64.so.2 loaded.
sLibrary /lib/x86_64-linux-gnu/libm.so.6 loaded.
sLibrary /lib/x86_64-linux-gnu/libc.so.6 loaded.
>~"[Inferior 4 (process 5771) exited normally]\n"
sThread 5 in group i4 exited.
sThread group i4 exited.
dNOTE: INFERIOR EXITED
dState changed from InferiorRunOk(11) to InferiorShutdownOk(18) [master]
dState changed from InferiorShutdownOk(18) to EngineShutdownRequested(19) [master]
dCALL: SHUTDOWN ENGINE
dPLAIN ADAPTER SHUTDOWN 19
dINITIATE GDBENGINE SHUTDOWN, PROC STATE: 2
dNOTE: INFERIOR STOP OK
dNOTE: ... WHILE DYING.
dNOTE: ... IGNORING STOP MESSAGE
>~"$2 = 0"
dGDB PROCESS FINISHED, status 0, exit code 0
dNOTE: ENGINE SHUTDOWN OK
dState changed from EngineShutdownRequested(19) to EngineShutdownOk(21) [master]
dState changed from EngineShutdownOk(21) to DebuggerFinished(22) [master]
I decided to try with my real ToupCam device connected (and the indi_toupcam_ccd driver started) and here the debugger does not exit, so now I am able to debug what happens while streaming.
I will take a closer look at that one of the next days.