Difference between revisions of "Talk:Camogmgui"
OneArtPlease (talk | contribs) |
|||
(2 intermediate revisions by 2 users not shown) | |||
Line 6: | Line 6: | ||
Good idea! Actually working on camogmgui right now, anything HDD mounting related should be possible from within the GUI now as well. --[[User:OneArtPlease|OneArtPlease]] 08:51, 21 October 2008 (CDT) | Good idea! Actually working on camogmgui right now, anything HDD mounting related should be possible from within the GUI now as well. --[[User:OneArtPlease|OneArtPlease]] 08:51, 21 October 2008 (CDT) | ||
+ | |||
+ | |||
+ | ---- | ||
+ | Tried v0.5 - great job! | ||
+ | |||
+ | Some problems I noticed/suggestions: | ||
+ | *could not open subdirectories in file selection box. Maybe php should generate xml for the directory structure and javascript use standard tree representation (with "+" changing to "-" in front of directories that you can open? | ||
+ | *Exif checkbox did not work - when you check it, click OK, get to different tab, come back - it is unchecked''' - Done''' | ||
+ | *I would use MOV by default - it uses less CPU resources than OGM''' - this seems to be the camogm default''' | ||
+ | *Splitting recording in chunks is designed to have zero drops/overlaps (if you see it actually does drop - it is a bug that should be fixed), so it may be safer to use smaller file (track) size by default. If something goes wrong and the recording terminates with an error (i.e. dead battery) it will be easier to save the footage. Theoretically it is possible to repair unfinished files, but we do not have the software for that - normally camogm leaves the room for the index at the beginning of the file, then records JPEG-encoded frames while building the index in memory and writes that index in the reserved space when closing the file. (it is possible to put index after the track, but then the large file can not be played over the Internet when it is supposed to start to play while still loading). | ||
+ | *Add image window that periodically shows last frame through http://1920.168.0.9:8081/bimg ? That should not eat up much of the CPU resources. | ||
+ | |||
+ | --[[User:Andrey.filippov|Andrey.filippov]] 12:54, 9 November 2008 (CST) | ||
+ | |||
+ | Any code that references sensor/compressor state and parameters may require changes in the coming 8.0 software --[[User:Andrey.filippov|Andrey.filippov]] 12:57, 22 November 2008 (CST) |
Latest revision as of 11:57, 22 November 2008
It would be nice to be able to open "control panel" where you can view/modify all the other parameters supported by camogm/camogm2. Or did I just miss this functionality and it is already there?--Andrey.filippov 12:36, 19 October 2008 (CDT)
Not all functions camogm supports are yet integrated. For some time I have now been thinking if it's really a good idea to have 2 fps (one in camvc and one in camogm: timescale, timelapse) options or if it would be too confusing for users. Options for max filesize, max length, etc. are set very high or to hardware max by camogmgui. --OneArtPlease 13:26, 20 October 2008 (CDT)
What I meant - make a "technical" ("advanced") settings panel (normally closed) that supplements supported parameters and allows to view/modify all of the camogm settings (they may have the names exactly as internal names with tooltips with short explanations). Normally user will use supported controls, better integrated into the user interface--Andrey.filippov 08:16, 21 October 2008 (CDT)
Good idea! Actually working on camogmgui right now, anything HDD mounting related should be possible from within the GUI now as well. --OneArtPlease 08:51, 21 October 2008 (CDT)
Tried v0.5 - great job!
Some problems I noticed/suggestions:
- could not open subdirectories in file selection box. Maybe php should generate xml for the directory structure and javascript use standard tree representation (with "+" changing to "-" in front of directories that you can open?
- Exif checkbox did not work - when you check it, click OK, get to different tab, come back - it is unchecked - Done
- I would use MOV by default - it uses less CPU resources than OGM - this seems to be the camogm default
- Splitting recording in chunks is designed to have zero drops/overlaps (if you see it actually does drop - it is a bug that should be fixed), so it may be safer to use smaller file (track) size by default. If something goes wrong and the recording terminates with an error (i.e. dead battery) it will be easier to save the footage. Theoretically it is possible to repair unfinished files, but we do not have the software for that - normally camogm leaves the room for the index at the beginning of the file, then records JPEG-encoded frames while building the index in memory and writes that index in the reserved space when closing the file. (it is possible to put index after the track, but then the large file can not be played over the Internet when it is supposed to start to play while still loading).
- Add image window that periodically shows last frame through http://1920.168.0.9:8081/bimg ? That should not eat up much of the CPU resources.
--Andrey.filippov 12:54, 9 November 2008 (CST)
Any code that references sensor/compressor state and parameters may require changes in the coming 8.0 software --Andrey.filippov 12:57, 22 November 2008 (CST)