chdkptp - alternative ptp client - page 67 - General Discussion and Assistance - CHDK Forum  
« previous next »
Pages: 1 ... 62 63 64 65 66 [67] 68 69 70 71 72 ... 111   Go Down

chdkptp - alternative ptp client

  • 1106 Replies
  • 451399 Views
*

Offline reyalp

  • ******
  • 13878
Re: alternative ptp client
« Reply #660 on: 26 / May / 2014, 17:26:24 »
Advertisements
Quote from: reyalp on 05 / May / 2014, 16:02:55
Quote from: adong on 05 / May / 2014, 06:24:50
Hello,

I've made a simple patch to rename some functions in chdkptp, so that lua can import them as libraries (eg require('chdkptp'))

This is pretty much a blind patch, as I do not have devices to test it with, but it should hopefully work

made against chdkptp r571.
Thanks for doing this, it should be quite useful.
I looked at this some more. There's quite a bit more that needs to be done to really make it work, particularly on windows.

It's still something I would like to add, but it's going to be a bit more than merging the patch.

A few notes:
Since the luaopen_* functions now return an int, so they need to return a value. In general they should return 1 with table created for the module on top of the stack (in Lua 5.2, they really shouldn't set a global).

On windows, the luaopen_* and other public functions need to be exported, either using __declspec(dllexport) or a .def file.

When linking, the libraries like chdkptp lbuf and liveimg need to be linked with a shared Lua and IUP, CD etc. They should probably also be linked to the shared versions of the other chdkptp libraries (e.g. liveimg to the shared lbuf rather than lbuf.o)

I'm not sure it's worth making lbuf, liveimage etc all separate dlls. Lua can load mutliple sub-modules from a single dll/so, which might make the build configuration simpler.

edit:
I should add that building lbuf with a shared Lua is somewhat dangerous. It assumes that it can use C stdio functions on the FILE * used by the Lua IO library. If Lua and lbuf are compiled with different C libraries, this will fail. This is likely if using a pre-built Lua on windows.
« Last Edit: 26 / May / 2014, 17:31:14 by reyalp »
Logged
Don't forget what the H stands for.
*

Offline jpq5588

  • *
  • 9
Re: alternative ptp client
« Reply #661 on: 27 / May / 2014, 10:16:31 »
Hi.

Previously, I was using a cli cmd window on Win32 and send to it keystrokes with post_key/send_key api.
It was very ugly because the cmd window can't be hidden and need focus to receive keystrokes.

So, I made a library which communicate with the command window witch use two pipes to send and receive data from stdin and stdout.

It works well with some programs like ImageMagick 'convert' and I get the response.

With chdkptp -i, I can send commands but I don't receive the prompt and responses.
It seems like chdkptp don't write to stdout, although it seems to be the case when looking at the source.

Same behavior if I call chdkptp.exe embedde in cmd.exe or directly.

Any ideas are welcomes !


Quote from: reyalp on 10 / March / 2014, 02:14:25
I also plan to add an option to pipe the pbm data directly to another command.

Would be very usefull !

reyalp, thanks for the A490 fix on this other thread
http://chdk.setepontos.com/index.php?topic=4338.msg113097#msg113097
Logged
*

Offline reyalp

  • ******
  • 13878
Re: alternative ptp client
« Reply #662 on: 27 / May / 2014, 17:23:30 »
Quote from: jpq5588 on 27 / May / 2014, 10:16:31
With chdkptp -i, I can send commands but I don't receive the prompt and responses.
It seems like chdkptp don't write to stdout, although it seems to be the case when looking at the source.
It should mostly go to stdout (most errors / warnings go to stderr). It uses the Lua IO to to write to stdout, which should be very normal. Maybe it doesn't get flushed right away?

You might want to try lua setvbuf on stdout http://www.lua.org/manual/5.1/manual.html#5.7

Something like io.stdout:setvuf('no') or io.stdout:setvuf('line')

If I do

chdkptp -i < foo.txt > bar.txt

with some commands in foo.txt, the output and prompts go to bar.txt as expected.
Logged
Don't forget what the H stands for.
*

Offline adong

  • **
  • 66
Re: alternative ptp client
« Reply #663 on: 28 / May / 2014, 05:00:57 »
Quote from: reyalp on 26 / May / 2014, 17:26:24
Quote from: reyalp on 05 / May / 2014, 16:02:55
Quote from: adong on 05 / May / 2014, 06:24:50
Hello,

I've made a simple patch to rename some functions in chdkptp, so that lua can import them as libraries (eg require('chdkptp'))

This is pretty much a blind patch, as I do not have devices to test it with, but it should hopefully work

made against chdkptp r571.
Thanks for doing this, it should be quite useful.
I looked at this some more. There's quite a bit more that needs to be done to really make it work, particularly on windows.

It's still something I would like to add, but it's going to be a bit more than merging the patch.

A few notes:
Since the luaopen_* functions now return an int, so they need to return a value. In general they should return 1 with table created for the module on top of the stack (in Lua 5.2, they really shouldn't set a global).

On windows, the luaopen_* and other public functions need to be exported, either using __declspec(dllexport) or a .def file.

When linking, the libraries like chdkptp lbuf and liveimg need to be linked with a shared Lua and IUP, CD etc. They should probably also be linked to the shared versions of the other chdkptp libraries (e.g. liveimg to the shared lbuf rather than lbuf.o)

I'm not sure it's worth making lbuf, liveimage etc all separate dlls. Lua can load mutliple sub-modules from a single dll/so, which might make the build configuration simpler.

edit:
I should add that building lbuf with a shared Lua is somewhat dangerous. It assumes that it can use C stdio functions on the FILE * used by the Lua IO library. If Lua and lbuf are compiled with different C libraries, this will fail. This is likely if using a pre-built Lua on windows.


I compiled it on windows using mingw, so that it doesn't need the __declspec to export the dll.

For the libraries, lua5.2 (the official supported version) changed how to use a C module.
http://lua-users.org/lists/lua-l/2012-09/msg00596.html says you can use luaL_newlib, but we have to change the code so that it doesn't register a global table (or we could always use lua_register from 5.1 to keep the table global and keep changes 5.1-compatible)

I'll create a patch to load the sub-modules from the chdkptp module.
Logged
*

Offline reyalp

  • ******
  • 13878
Re: alternative ptp client
« Reply #664 on: 28 / May / 2014, 16:47:41 »
Quote from: adong on 28 / May / 2014, 05:00:57
I compiled it on windows using mingw, so that it doesn't need the __declspec to export the dll.
This doesn't work for me, using mingw and gcc 4.8. It compiles fine, but you can't actually load the module because the luaopen_* isn'texported. I believe there are some gcc options to export everything by default.

Also, using your patch the resulting DLLs were not actually usable even if I exported the luaopen, because Lua ended up statically linked to *each* dll.

My standard windows builds are a monolithic, static exe because this is easier to distribute and install.
Quote
For the libraries, lua5.2 (the official supported version) changed how to use a C module.
http://lua-users.org/lists/lua-l/2012-09/msg00596.html says you can use luaL_newlib, but we have to change the code so that it doesn't register a global table (or we could always use lua_register from 5.1 to keep the table global and keep changes 5.1-compatible)

I'll create a patch to load the sub-modules from the chdkptp module.
I plan to drop 5.1 compatibility soon, because maintain testing and takes extra time, but haven't done it yet, so it should stay 5.1 compatible for now.

I did convert the sub-modules to luaopen in changeset 594, but my feeling is that additional work is needed in the makefiles need to be reworked a bit so static and dynamic linking is controlled more explicitly.
Logged
Don't forget what the H stands for.
*

Offline reyalp

  • ******
  • 13878
Re: alternative ptp client
« Reply #665 on: 31 / May / 2014, 16:50:20 »
chdkptp snapshot 592 has a silly bug where the "lua" aka . command will print something like
ERROR: . failed
for every command, even if it succeeded. This is fixed in r597.

edit:
I've uploaded snapshot build 599 to fix this issue. There aren't any other significant changes.

« Last Edit: 02 / June / 2014, 01:33:08 by reyalp »
Logged
Don't forget what the H stands for.
*

Offline ladiko

  • *
  • 20
Re: alternative ptp client
« Reply #666 on: 04 / July / 2014, 07:39:57 »
Hey reyalp,

is it possible to stream to stdout like "gphoto2 --capture-movie --stdout" would do? I would like to pipe it into VLC to make it available via HTTP as a mjpeg-stream like an IP camera.
« Last Edit: 04 / July / 2014, 07:42:53 by ladiko »
Logged
*

Offline reyalp

  • ******
  • 13878
Re: alternative ptp client
« Reply #667 on: 05 / July / 2014, 01:51:38 »
Quote from: ladiko on 04 / July / 2014, 07:39:57
Hey reyalp,

is it possible to stream to stdout like "gphoto2 --capture-movie --stdout" would do? I would like to pipe it into VLC to make it available via HTTP as a mjpeg-stream like an IP camera.
Not currently.  The closest you could get without writing actual code is to display the live gui and use something like vlc or ffmpeg to capture the region of the screen it displays on. Of course this means you need X on the host running chdkptp and adds a lot of overhead.

You could also use lvdumpimg to dump frames into a directory have have some process pick them up.

It shouldn't be terribly hard to make lvdumpimg (or something like it) write continuously to a pipe or stdout.
Logged
Don't forget what the H stands for.
*

Offline ladiko

  • *
  • 20
Re: alternative ptp client
« Reply #668 on: 05 / July / 2014, 03:42:33 »
Screen capture is not an Option for me, it adds too much overhead. Do you think you could add it to the wish list? May a beer or a box of beer or something else be helpful?

I look for a way to setup a canon camera that provides a live stream that even works after a power failure. So the camera has to switch on automatically f.e. by holding down the power button with a cable tie. The computer also boots again and starts a command line which starts the video stream. And I would like to have a better quality than a Logitech C920 webcam.

I tested gphoto2 with a borrowed Canon DSLR and it worked great but it's not within the budget.
Logged
*

Offline Microfunguy

  • ****
  • 4037
    • StereoData Maker
Re: alternative ptp client
« Reply #669 on: 05 / July / 2014, 10:14:18 »
Quote from: reyalp on 05 / July / 2014, 01:51:38
You could also use lvdumpimg to dump frames into a directory have have some process pick them up.

Are you familiar with frame-serving ?

Basically, a programme such as AviSynth or VDub can sequentially send minimal AVI frames to an external application.
As far as the application is concerned, it is reading a normal AVI file, it does not know anything about the source movie, such as its size (which may be larger than the application normally supports).

I am not sure but maybe the application and frame-server share a common buffer that is setup when opening AVI files.
Maybe the frame format is simple RGB ?

Source code is available for frame servers but is rather complicated.
Of course, your application has to know how to read the assumed-buffered frame.
Logged
Pages: 1 ... 62 63 64 65 66 [67] 68 69 70 71 72 ... 111   Go Up
« previous next »
 

Related Topics