[AG-TECH] Not finding Firewire DV on UQ advanced vic

[Andrew Ford]

On 5/29/07, leon zadorin <leonleon77 at gmail.com> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/ag-tech/attachments/20070530/e0acfc66/attachment.htm>