chdkptp - alternative ptp client - page 70 - General Discussion and Assistance

ladiko

Re: alternative ptp client

« Reply #690 on: 04 / August / 2014, 12:34:42 »

Advertisements

So the Canon A2500 arrived today after a 2 weeks round trip of the camera caused by the post office. Now i wanted to try the new lvdump feature, but because of my dye sub printer which only has a i386 driver, i tried to compile a 32bit version of chdkptp on Ubuntu 12.04.5 by adding some #includes and ended up here:

The output of make is attached, do you have any idea what's wrong? I would appreciate a pre-compiled i386 version, but even better if i could compile it on my own, so i can compile it everytime a new version has been released.

Thank you in advance!
ladiko

make_output.zip (28.09 kB - downloaded 18 times.)

Logged

reyalp

13718

Re: alternative ptp client

« Reply #691 on: 04 / August / 2014, 13:09:14 »

Quote from: ladiko on 04 / August / 2014, 12:34:42

So the Canon A2500 arrived today after a 2 weeks round trip of the camera caused by the post office. Now i wanted to try the new lvdump feature, but because of my dye sub printer which only has a i386 driver, i tried to compile a 32bit version of chdkptp on Ubuntu 12.04.5 by adding some #includes and ended up here:

You should not need to add any includes. I'm not sure what the stuff in /usr/src is but if it's kernel headers you definitely don't want that. I would assume the errors listed are caused by these headers.

What happens if you when you try to build without those additional includes?

There really shouldn't be anything x64 specific in the default settings, if you don't need the GUI you should pretty much just be able to copy config-sample-linux.mk to config.mk and make.

Logged

Don't forget what the H stands for.

ladiko

Re: alternative ptp client

« Reply #692 on: 05 / August / 2014, 02:43:50 »

copying the config-sample-linux.mk to config.mk made it works!

When i connect the camera to the computer, it is recognized by chdkptp but the lens retracts into the camera, the display switches off and the camera behaves like in the default ptp-file transfer mode. this way i can't take pictures. is there an chdk option that leads to a different behaviour?

When there's a picture on the SD card, this picture will be shown in live viewfinder mode instead of the lens picture, if there's no picture, you see a black screen.

If i stop udev and reconnect the camera, the display doesnt switch off, but the camera goes into play mode and stays there.

Seems to be related to the "Usage notes" here: http://chdk.wikia.com/wiki/PTP_Extension

« Last Edit: 05 / August / 2014, 10:08:04 by ladiko »

Logged

reyalp

13718

Re: alternative ptp client

« Reply #693 on: 05 / August / 2014, 17:10:47 »

Quote from: ladiko on 05 / August / 2014, 02:43:50

When i connect the camera to the computer, it is recognized by chdkptp but the lens retracts into the camera, the display switches off and the camera behaves like in the default ptp-file transfer mode. this way i can't take pictures. is there an chdk option that leads to a different behaviour?

This is due to something your OS is doing when you connect the camera, there are no CHDK options which affect this.

Quote

If i stop udev and reconnect the camera, the display doesnt switch off, but the camera goes into play mode and stays there.

The fact the screen doesn't go black suggests this stops the OS interference. Have you tried to switch back to record mode with the rec command (or GUI button)?

I would generally suggest making sure the camera is in play mode before you connect it to the PC, and then use rec to switch to record mode from chdkptp.

Logged

Don't forget what the H stands for.

ahull

Re: alternative ptp client

« Reply #694 on: 05 / August / 2014, 19:03:12 »

If running Linux, the camera behaviour might be related to the issue described here..
http://chdk.setepontos.com/index.php?topic=10664.20

Logged

ladiko

Re: alternative ptp client

« Reply #695 on: 06 / August / 2014, 08:27:21 »

ok now it works, liveview and taking pictures etc. so the a2500 is supported with the current alpha of chdk 1.3. I also added some stuff to the other thread about the gvfs automount.

Is lvdumping able to output a jpg stream? Because ffmpeg / avconv has a lag of 2 or 3 seconds, while i was streaming mjpeg from Canon EOS 1100 -> gphoto2 -> vlc mjpeg-Stream -> Google Chrome with a lag of around 1 second. But VLC only unterstands JPEG / MJPEG streams as image input.

edit:
This works:

Code: [Select]

LUA_PATH=Downloads/chdkptp/lua/?.lua Downloads/chdkptp/chdkptp -c -e"lvdumpimg -count=10000 -pipevp=oneproc -vp='avconv -vcodec pgm -f image2pipe -i - -vcodec mpeg2video -s 640x480 -r 24 -v quiet -pix_fmt yuv420p -f mpegts - '" | vlc -

This doesnt:

Code: [Select]

LUA_PATH=Downloads/chdkptp/lua/?.lua Downloads/chdkptp/chdkptp -c -e"lvdumpimg -count=10000 -pipevp=oneproc -vp='avconv -vcodec pgm -f image2pipe -i - -vcodec mjpeg -s 640x480 -r 24 -v quiet -pix_fmt yuv420p -f mjpeg - '" | vlc -

Edit2:
This works and has a little less lag:

Code: [Select]

 LUA_PATH=Downloads/chdkptp/lua/?.lua Downloads/chdkptp/chdkptp -c -e"lvdumpimg -count=10000 -pipevp=oneproc -vp='avconv -vcodec pgm -f image2pipe -i - -vcodec mjpeg -s 640x480 -f mpjpeg - | vlc -'"

Edit3
And a bit less lag and better quality:

Code: [Select]

LUA_PATH=Downloads/chdkptp/lua/?.lua Downloads/chdkptp/chdkptp -c -e"lvdumpimg -count=10000 -pipevp=oneproc -vp='avconv -vcodec pgm -f image2pipe -i - -qscale 1 -vcodec mjpeg -s 640x480 -f mpjpeg - | vlc - --file-caching=0'"

With JPG/MJPEG i could just do

Code: [Select]

LUA_PATH=Downloads/chdkptp/lua/?.lua Downloads/chdkpt/chdkptp -c -e"lvdumpimg -count=10000 -pipevp=oneproc -vp='vlc -'"
Note for me: Try to disable ffmpeg pre buffer / cache to minimize the lag: https://trac.ffmpeg.org/wiki/StreamingGuide

Btw.: How to create an endless / continuous stream?

« Last Edit: 06 / August / 2014, 12:00:18 by ladiko »

Logged

ladiko

Re: alternative ptp client

« Reply #696 on: 06 / August / 2014, 09:20:21 »

double post, sorry.

Logged

reyalp

13718

Re: alternative ptp client

« Reply #697 on: 06 / August / 2014, 13:19:56 »

Quote from: ladiko on 06 / August / 2014, 08:27:21

Is lvdumping able to output a jpg stream?

No, it can only output netpbm at the moment.

Quote

Btw.: How to create an endless / continuous stream?

Use an arbitrarily large number for count.

Logged

Don't forget what the H stands for.

ladiko

Re: alternative ptp client

« Reply #698 on: 06 / August / 2014, 13:55:39 »

Could you guess the frame rate? The GUI was limited to 30 and it didn't show any dropped frames. So it's 30? So if I use a timeout of 3 minutes, the frame could should be 30 x 180 = 5400 or 6000 if I want to have a little buffer!?

How hard would it be to provide mjpeg directly?

Logged

reyalp

13718

Re: alternative ptp client

« Reply #699 on: 06 / August / 2014, 16:38:24 »

Quote from: ladiko on 06 / August / 2014, 13:55:39

Could you guess the frame rate? The GUI was limited to 30 and it didn't show any dropped frames.

The way chdkptp live view works by polling, it doesn't know anything about the cameras actual frame rate. It just requests frames repeatedly, and gets whatever is currently in the camera framebuffer. If you request faster than the cameras actual frame rate, you get duplicated frames, and if you request slower, you miss some frames.

The frame rate you can produce is limited by USB transfer and processing overhead. The GUI should show "dropped" frames if the requested rate is faster than the combined transfer and rendering allow and gui_live_dropframes is set. By default, this is only set on Linux because the UI becomes unresponsive when an IUP timer repeatedly takes longer than the timer interval.

If you use -fps=N with lvdumpimg, it should request frames at the rate you specify, or less if it it isn't able to keep up.

Quote

How hard would it be to provide mjpeg directly?

I don't really know anything about mjpeg, so I don't know. At a minimum, it would require linking to a library with jpeg support, and converting the live view data into something the library accepts as input. I may do this eventually, but I'm not in a hurry to add extra dependencies and compile time optional features.

An alternative would be to write a shim program that reads netbpm (or raw live view protocol) on stdin and writes out mjpeg. The second option would have the advantage of allowing the conversion to happen in parallel with transfer.

FWIW, I believe the native Canon live view (as exposed by gphoto etc) the actual USB stream is mjpeg. However, we don't know how to set this up in the Canon firmware, and it's not clear if it would even be possible on cameras without Canon live view.

Logged

Don't forget what the H stands for.