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

chdkptp - alternative ptp client

  • 1106 Replies
  • 513675 Views
*

Offline Microfunguy

  • ****
  • 4037
    • StereoData Maker
Re: alternative ptp client
« Reply #680 on: 07 / July / 2014, 15:10:34 »
Advertisements
I also have the driver files mentioned in this INF file :-

Code: [Select]
;
; e2ecam.INF  -- This file contains installation information for e2eCam,
;                A WDM capture driver that requires no hardware.
;               
;          Copyright (c) 2005-2008 e2eSoft - http://www.e2esoft.cn
;
;
etc

but no use to you as it is for Windows.
« Last Edit: 07 / July / 2014, 15:13:51 by Microfunguy »
Logged
*

Offline reyalp

  • ******
  • 14080
Re: alternative ptp client
« Reply #681 on: 08 / July / 2014, 00:05:53 »
Quote from: Microfunguy on 07 / July / 2014, 15:08:43
It is CHDKCAM by EWAVR (Zosim Mikhaylov).
Ah, not a German after all ;)

It does appear e2esoft offers a free sdk (with watermarked output) http://www.e2esoft.cn/vcam/vcamsdk.asp
One could presumably hack chdkptp to output to this without a huge amount of trouble.
Logged
Don't forget what the H stands for.
*

Offline Microfunguy

  • ****
  • 4037
    • StereoData Maker
Re: alternative ptp client
« Reply #682 on: 08 / July / 2014, 04:55:21 »
Quote from: reyalp on 08 / July / 2014, 00:05:53
One could presumably hack chdkptp to output to this without a huge amount of trouble.

See this http://www.e2esoft.cn/news/pages/vcam_external_source_howto.html

It uses a shared-memory buffer.

As I recall, there is a 'bouncing ball' example in the DirectShow SDK that uses  source images as input.

The output of the FilterGraph can be displayed by any application capable of playing the same files as Windows Media Player does.

Presumably, the e2esoft application is based on a similar method.

On Linux systems it is interesting that GStreamer also provides code for a bouncing-ball source filter.

GStreamer looks like a lot of work http://gstreamer.freedesktop.org/
« Last Edit: 08 / July / 2014, 06:52:14 by Microfunguy »
Logged
*

Offline openuas

  • **
  • 58
  • OpenUAS
    • OpenUAS
Re: alternative ptp client
« Reply #683 on: 10 / July / 2014, 14:30:51 »
Nice to have the new rsint. Compiled chdkptp from source svn 606. All OK can nicely use rs using the Linux chdkptp client. To speed up shooting the idea was to use rsint. Looked briefly at the lua source, will investigate some more to see how rsint actually works.

Using:
Canon IXUS200 IS Firmware  v1.01c
CHDK ixus200_sd980-101c-1.3.0-3496-full (Nightlybuild)
chdkptp svn 606

A hint where to look to make it work would be appreciated.

My bad, first I compiled against LUA5.1 which flag still set was in my custom config.mk. Using Lua 5.1, rsint crashed. Re-compiled with Lue 5.2 and it worked :). However checking out via svn it is easily overlooked one can still have the config.mk hanging around

rsint indeed can indeed be used to speed up the shooting times, in my case from ~3.7sec to 2sec, HURRAY! feels like :xmas thx to all developers involved. this speedup is very important to me.

Now I'll have to figure out how to set exposure and other parameters...

Anyhow, more info or some console example on rsint usage welcomed.
« Last Edit: 10 / July / 2014, 15:23:34 by openuas »
Logged
*

Offline reyalp

  • ******
  • 14080
Re: alternative ptp client
« Reply #684 on: 10 / July / 2014, 23:12:26 »
Quote from: openuas on 10 / July / 2014, 14:30:51
My bad, first I compiled against LUA5.1 which flag still set was in my custom config.mk. Using Lua 5.1, rsint crashed. Re-compiled with Lue 5.2 and it worked :). However checking out via svn it is easily overlooked one can still have the config.mk hanging around
I wasn't aware that it was broken with Lua 5.1, but I plan to remove 5.1 support completely soon. After that it will give you a compile error.

Quote
Now I'll have to figure out how to set exposure and other parameters...

Anyhow, more info or some console example on rsint usage welcomed.
If you want to set the initial exposure, it works just like rsint.

If you want to change the exposure between shots, you currently need to send lua code to the camera using the exec command from rsint. Something like
Code: [Select]
con 1> rsint
rsint> exec set_tv96_direct(768)
rsint> s
rsint> s
...
You can send pretty much any camera side code with exec.

However it's important to know that most exposure overrides will not affect the next s command, they will affect the following one. So in the example above, the first shot would use the cameras auto exposure, and the second would be at 1/1024th.

This happens because the point where the camera waits is right before the shot is taken, after the exposure is already set. However, this isn't universal, for example the ND filter will take immediate effect. It may also vary some between cameras. On my D10, I was able to change focus and zoom in this hook, but this could be dangerous since the camera wouldn't normally expect them to be moving at this point.

In continuous mode, we don't really have a place to wait after the previous shot is finished but before the remote hook, the only other place to wait would be the raw hook, which happens before the jpeg is transferred.

The code is mostly in lua/rsint.lua
Logged
Don't forget what the H stands for.
*

Offline reyalp

  • ******
  • 14080
Re: alternative ptp client
« Reply #685 on: 13 / July / 2014, 21:32:55 »
Streaming success-ish

On rpi
lvdumpimg -count=100 -vp=!"ffmpeg -vcodec pgm -f image2pipe -i - -vcodec mpeg2video -s 640x480 -r 24 -pix_fmt yuv420p -f rtp rtp://192.168.1.2:1234"

where 192.168.1.2 is the IP of the client you want to stream to.

On the client system, open rtp://192.168.1.2:1234 (that's the client IP again, NOT the pi IP) as a network stream in VLC or ffplay

The resulting video streams to vlc at about 3 fps over wifi with several seconds of latency. Dropping the resolution to 320x240 brings it up to 4 fps ;)

Note the codec and transport are just what I got working being fairly clueless about this stuff. From what I understand you would normally have an sdp for the rtp stream and have more flexibility on the codec etc, or would send it to a streaming server instead. The -r 24 is there because ffmpeg on the pi refuses accept lower rates with mpeg2video

Using the same settings on my core i5 windows desktop only gives ~8 fps clearly things are sub-optimal. PEBCAK see below.

edit:
According to http://www.raspberrypi.org/new-video-features/ hardware h264 encode is available (without even paying the couple bucks for additional codecs). I'm not yet clear what software you would use to do this though.
« Last Edit: 13 / July / 2014, 23:03:34 by reyalp »
Logged
Don't forget what the H stands for.
*

Offline reyalp

  • ******
  • 14080
Re: alternative ptp client
« Reply #686 on: 13 / July / 2014, 23:03:13 »
Oops, I'd forgotten that lvdumpimg defaults to waiting 100ms between frame grabs, and this is added on top of the transfer and save times.

Using -wait=0 like
lvdumpimg -count=250 -wait=0 -vp=!"ffmpeg -vcodec pgm -f image2pipe -i - -vcodec mpeg2video -s 640x480 -r 24 -pix_fmt yuv420p -f rtp rtp://192.168.1.2:1234"

on my desktop gets a frame rate over 30 fps (despite the -r 24...) and brings the pi up slightly.

On the pi, writing to /dev/null with -wait=0 gets about 8 fps. Finding a way to send YUV directly to the video encoder should improve this quite a bit.

edit:
One more note. Supposedly you can use ffmpeg to feed a video4linux loopback device https://github.com/umlaeute/v4l2loopback/wiki/Ffmpeg so theoretically you could use this method to use the live view in applications that expect a webcam etc.

Looking at hardware encoding on the pi, it appears to require YUV420 "packed planer" http://home.nouwen.name/RaspberryPi/documentation/ilcomponents/video_encode.html so unfortunately it couldn't be fed directly from the the camera live view.
« Last Edit: 14 / July / 2014, 16:41:57 by reyalp »
Logged
Don't forget what the H stands for.
*

Offline openuas

  • **
  • 58
  • OpenUAS
    • OpenUAS
Re: alternative ptp client
« Reply #687 on: 15 / July / 2014, 20:44:09 »
Thx Reyalp for rsint hints. I'll have some time to test all of it soon.
Logged
*

Offline reyalp

  • ******
  • 14080
Re: alternative ptp client
« Reply #688 on: 20 / July / 2014, 01:55:49 »
In changeset 613, I changed how pipe output is handled in lvdumpimg. Instead of using ! on the filespec, -pipevp and -pipebm are used to specify that the output is to a pipe. Additionally, you can have all frames of a given type either go to a single process (by using -pipevp=oneproc), or invoke the command once per frame. The once per frame option is useful for resizing and converting netpbm to other formats.

Some examples (copied from USAGE.TXT)

Grab 10 viewport frames to files organized in date and time directories
Code: [Select]
lvdumpimg -vp=vp_${date,%Y%m%d}/${date,%H%M%S}/${frame}.ppm -count=10
Grab a single viewport frame, use imagemagick to convert to jpeg, re-size to 640x480 and naming by date and time:

Code: [Select]
lvdumpimg -vp='convert - -resize 640x480! vp_${date,%B_%d_%Y-%H_%M_%S}.jpg' -pipevp -count=1
NOTE:
On windows, convert conflicts with system file. You might need to use a full path.

Capture viewport and bitmap, and merge them into a single PNG:
Code: [Select]
lvdumpimg -pipebm -count=3 -vp=tmp.ppm -bm='convert tmp.ppm - -resize 640x480! -layers merge merged_${frame}.png'
pipe 100 frames of viewport to ffmpeg and stream over rtp
Code: [Select]
lvdumpimg -pipevp=oneproc -count=100 -vp='ffmpeg -vcodec pgm -f image2pipe -i - -vcodec mpeg2video -s 640x480 -r 24 -pix_fmt yuv420p -f rtp rtp://127.0.0.1:1234'
NOTE:
You could use VLC and open rtp://127.0.0.1:1234 to watch the stream
These probably aren't the best parameters to use
Logged
Don't forget what the H stands for.
*

Offline reyalp

  • ******
  • 14080
Re: alternative ptp client
« Reply #689 on: 27 / July / 2014, 00:18:00 »
I've uploaded snapshot build r650 to the files area https://www.assembla.com/spaces/chdkptp/documents

Major changes
lvdumpimg pipe stuff described above

multicam improvements discussed in http://chdk.setepontos.com/index.php?topic=11667.80

Three new cli commands for managing image files on the card
imls - lists files in the dcim directory
imdl - downloads and optionally deletes files. It has extensive options for selecting the download files and controlling the file paths they are downloaded to.
imrm - delete images files

All three commands use exactly the same options to select the files. There are a few examples in usage.txt. imdl and imrm both accept a pretend option so you can see what they will do.

Both imdl and mdl now default to asking what to do if a file would be overwritten. This can be overridden with the -overwrite option.
Logged
Don't forget what the H stands for.
Pages: 1 ... 64 65 66 67 68 [69] 70 71 72 73 74 ... 111   Go Up
« previous next »
 

Related Topics