On 5/29/07, leon zadorin <[email protected]<mailto:[email protected]>> wrote:
> Hmm, it seemed to be sending fine when I got in today implying that it was > running over the (long) weekend. I restarted it with a higher TTL, and I'll > try and keep it running as much as I can (I can guarantee 10am EDT - 6pm > EDT, sorry that that's an awful time for you guys in Australia, heh). Well, some news... Firstly, I am able to receive and see your stream here in Birsbane, Australia :-) ... Although the whole thing is rather dark - but I presume that it is nighttime over in NY (it is noon here :-) and there are no lights "on" in your office :-) Great! Glad to know it's working, thanks. I guess if you want to see some activity or light you should try checking it earlier in the morning, like 8am-11am your time which is 6pm-9pm here, while it's still light outside. I'll point it out a window before i leave :) > Both the sender and receiver are 91M; they're from checkouts I did on > Thursday/Friday. 91M - the "M" part is interesting, what does cd ag-media svn diff >> leonlog3 say? Basically, the "M" means modified... it could be nothing (e.g. there are some runtime generated files which should not be a part of svn repository), but it would be interesting to see anyway (i.e. if possible, email me the leonlog3 file)... The only difference is a #define of the svn revision number in an ffmpeg revision file: Index: Ffmpeg/Revision6182/version.h =================================================================== --- Ffmpeg/Revision6182/version.h (revision 91) +++ Ffmpeg/Revision6182/version.h (working copy) @@ -1 +1 @@ -#define FFMPEG_VERSION "SVN-rUNKNOWN" +#define FFMPEG_VERSION "SVN-r91" Not sure how that happened but it doesn't seem to be affecting anything. Now on to your system/logs :-) ... thanks for the log files by the way! From leonlog1: "libGL warning: 3D driver claims to not support visual 0x4b" This could mean that your system is having issues with OpenGL (we use OpenGL by default for efficient synchronisation with the vertical refreshing of your monitor) so try running vic with "-g" option: ./vic -g IP/PORT I was trying the ./runDV script before, so I was already using -g. (I just tried it with only -g and the same freezing happened) This will instruct the vic not to use OpenGL for syncing to VBlank (so in case it was OpenGL issue that made vic "pause" and wait indefinitely for a vertical retrace - it will be avoided this time)... Minor side-note: it appears that you are using an Intel graphics card with i810 driver - this combination will not have proper accelerated rendering (XVideo's "Overlay" is not sufficient, we need "Blitter" or "Texture" and even then, the newest intel drivers are still rather "slowish")... ... current recommended setup would be nvidia card with "nvidia" [ binary / closed-source ] Xorg driver - something as per http://www.vislab.uq.edu.au/research/accessgrid/software/advideo/system_characteristics.html Yeah, I had a feeling it might have to do with the lack of a decent video card in this machine. Without the XVideo accelerated rendering vic should fallback to Imlib2 (software) rendering... but from log files I don't see it using Imlib2 rendering though... (vic would output something like "using Imlib2 for rendering" or similar) - this could mean that the runtime execution path did not get around to it or that Imlib2 was not included in the build... what does cat ag-media/vic/IMLIB2INCLUDE.H >> leonlog3 say? #include "../Imlib2/Installed/include/Imlib2.h" And that is a valid path. From leonlog2: Minor side-note: you have 2 vics running (one of them is listed as defunct) so *really* killing it (kill -KILL PID) would be a good thing to try... if this does not help and you end up restarting the machine, then please run the "setSystem" script again (so that /sbin/sysctl net.core.rmem_max shows ~17000000 value) I just had to kill the original ./runDV script, that got rid of it. Didn't make a difference with the freezing, though. If running vic with "-g" option does not help, try ./vic -g -i -x IP/PORT and then (if possible) click on the black thumbnail to see if the larger video window comes up... this is not a deployment solution, but would help with testing... Hmm, this actually works... but in a strange way. Sometimes, if I leave the main window open and visible for too long (5ish seconds sometimes, this part is inconsistent), it freezes. (Sometimes it doesn't freeze at all) But before it freezes, I can open the video windows (which are receiving the videos fine) by clicking on the thumbnails. If the main vic window is visible/frozen (and trying to render I presume?) the video windows keep on displaying fine but they can't process any input (like s/m/l for resizing). If the main vic window is not frozen, the windows can process input just fine. Occasionally the main window thaws if I leave it open long enough. Oh and I wouldn't worry about 2 vics running on the same machine, using the same class D (multicalt) address and not seing each others traffic - I think this is OK (i.e. by design this was never an intended scenario - in fact the original vic (from anl) behaves in exactly the same way - so we have inherited this behaviour)... Ah, that's what I thought. Thanks for the clarification. --Andrew
