User:Aegdss\Learning Curve

From ElphelWiki
Revision as of 12:55, 2 September 2008 by Aegdss (talk | contribs) (Progress update)
Jump to: navigation, search

Diary of getting up to speed

Unboxing

--aegdss 09:24:28, 2008-08-08 (CDT)

Got the camera including a few cat-5 and rs-232 Dsub shell etc which was very nice.

Dont have a POE switch and didnt want to cannibalize a cable or open the housing yet, so I bought a POE injector (POI-2000 from CP Technology via amazon).

Camera came right up, could connect via telnet and browser, could acquire images and modify settings. UI seemed a bit flakey at times (using Firefox) but that could certainly have been op error.

Changed IP to 192.168.1.9, so it would work on my lan.

Attempted to get VLC and mplayer to work, but didnt have too much luck. Streamer seemed to start as evidenced by ps and indicator on web ui. But I couldn't get client apps to receive a stream. I did manage to get mplayer to start crashing so It must have been doing something :)

Gonna try streaming with linux client and then once that is all working go back to vista.


VLC should work at least up to HD resolution on any OS. (take the last stable version of VLC. VLC need to be compiled with a liblivemedia >= 2007.02.20) We officially support only patched MPlayer. (Here also, last stable MPlayer, liblivemedia >= 2007.02.20) The patch to apply is just in mplayer-1.0~rc2/libmpdemux/demux_rtp.cpp replace #define MAX_RTP_FRAME_SIZE 50000 by #define MAX_RTP_FRAME_SIZE 5000000.

--Alexandre.Poltorak 02:51, 9 August 2008 (CDT)


Streaming

Yes, VLC seems to work when using HD or less resolution. VLC is a touch on the flaky side, It would crash when using a built in image capture device (not elphel camera). Also, I could only get vlc to work using unicast streaming (rtsp://192.168.0.9:554). But that could easily have been operator error. I'll look into that further later, but first want to test out a patched mplayer under windows. But once I set the frame rate correctly and used unicast I didn't have any problems.

VLC had bad latency, on the order of 2-3 seconds, which seemed independent of resolution. The web interface, used at the same time as the streamer, did NOT exhibit the same latency. PC CPU load was only 25% or so. The other SCINI team members reported "very low" latency using VLC under linux, so evidence points to an issue with vlc on windows.

Aside: The AJAX interface works well and is nice if a bit intimidating for the neophyte user, the tooltips help a lot. I'm curious what is the frame rate limiting factor here, I need to take a peek at the code when I get a sec.

--aegdss 14:01:39, 2008-08-11 (UTC)


Use the src...

Seems like the ajax ui eventually turns off the compressor if streaming is not on, I didnt look at the code yet though.


Please use camvc2.html and not camvc (index.html), camvc2 treat the compressor and the streamer independently. You can also do all the setup using only PHP: PHP Examples, see camera_demo.php --Alexandre.Poltorak 15:42, 21 August 2008 (CDT)


Managed to get pretty good performance using the fast server (port 8081). Just start the compressor with fpcf -jpeg and then read from 8081/img as fast as I could. Gonna write a small little app to do it and see how fast I can get it on windows.

Loaded src onto a ubuntu machine today using install_from_cvs script. Went pretty smooth with only a few glitches...

1) the tcpdump.org was down and ./install_elphel wants to grab libpcap from there. Just download it from somewhere else and put it in the ~/distfiles dir.


we will check it, normally it should take from the mirror automatically in this case. --Alexandre.Poltorak 15:42, 21 August 2008 (CDT)


2) apt-get install lex yacc doesn't work. Those are in flex and bison though, so apt-get install flex bison gets them. (This was corrected in the wiki docs...--aegdss 09:26:52, 2008-08-25 (CDT))

3) the manual install of the cris compiler had problems, but the binary distribution worked just fine.


Please have a look on: Elphel_Software_Kit_for_Ubuntu#For_developers: --Alexandre.Poltorak 15:42, 21 August 2008 (CDT)


Elphel_Software_Kit_for_Ubuntu#For_developers: were the docs I was following, (which are pretty good btw.) The line "sudo apt-get install cvs build-essential lex byacc bison libglib2.0-dev tcl gettext libncurses5-dev patch zlib1g-dev" was a problem cause apt-get couldnt install lex. I think maybe if lex is replaced by flex it would be fine. I didnt really investigate further.

I also first tried to install the cris compiler using the docs on the same page. This failed in the final step (sudo ./install-cris-tools.) I did not note the error and just went straight to the binary package (which worked fine.). Of course this is more an issue with the axis script (install-cris-tools) rather than the wiki doc which seems correct in this case. I just noted it in case anyone else has the same issue and doesnt have the time to debug the install script. I think the problem with the install-cris script is probably machine (or distribution) dependent and may work just fine for most everyone else. FWIW I'm installing on a fairly stock ubuntu 8.04.

Overall the user experience for setting up the dev environment using the binary package install for the cris tools and then elphel353_install_from_cvs.sh was really very nice and easy.

--aegdss 08:28:11, 2008-08-22 (CDT)

SCINI stuff

We are going to try to use a dual headed setup with one sensor fwd and one looking down. So looking into using the 10359 and what exactly is the best operational method of doing that.

--aegdss 14:28:38, 2008-08-21 (CDT)


Plunging into dual head

After getting a great amount of support from the elphel team, I managed to successfully test the 10359 board. Although only with one sensor module (the other I got from SCINI team didnt work, but they had mention that they thought that they had killed it (static, bad voltage, penguin attack?, who knows...).

I'm trying to procure another sensor board today.

But FWIW I got images easily through the 10359 using the following sequence of steps (provide by Alexandre Poltorak):

http://192.168.0.13/camera_demo.php
http://192.168.0.13/359/sensors_init.php
http://192.168.0.13/ccam.php?trig=async&mode=set
http://192.168.0.13/359/tests_for_96mhz.php
http://192.168.0.13/compressor.php?cmd=run


http://192.168.0.13/sync.php?role=self&fps=single
http://192.168.0.13:8081/img

Gonna dig through those scripts now, while awaiting another sensor board.

--aegdss 09:21:27, 2008-08-25 (CDT)


Feet to the fire

Nothing like dangerously close deadlines to speed up the learning process...

Current plan is to have a c#/wpf dual head camera control app that also allows for science annotation...All using http, no rtp.

Actually making good progress. Playing/reading all the php scripts. Got multi-threaded http image reader/display going on windows (C#, WPF). It seems plenty fast, and no noticeably latency: This is using a single sensor running through the 10359 in "Transparent" mode.

(image request, image read, display set source, display invalidate: ) 8-9 ms (320x240)
12-14 ms (640x480)
19 - 20 ms (1296x960) but starts to clobber the UI of the app .
45 - 50 ms (2592x1936) bit of stuttering and UI getting very unresponsive.

So very very promising...need to clean up the app, better thread handling, add dual head, add camera control, etc. etc....


--aegdss 14:55:08, 2008-09-02 (CDT)