On Saturday, April 19, 2008 6:20 AM, "Andrew Ford" <acf0...@rit.edu> wrote: > On Wed, Apr 16, 2008 at 8:54 PM, Douglas Kosovic <dougl...@itee.uq.edu.au> > wrote: > >> UQ Vislab vic doesn't do any transcoding from DV (or HDV) firewire >> devices >> to other codecs, so if the codebase was merged as it stands now, it >> wouldn't >> do what you are trying to do anyway. > > Well, doing raw DV without transcoding would be fine (if it were on both > platforms), since we can spare the bandwidth - that's what we're already > doing via the ExtendedVideo services on Windows, but we'd like to be able > to > move on to something more cross-platform. > >> Have you tried using DV4Linux so that your Camcorder can be seen as a V4L >> device? I haven't tried it myself. > > Interesting, I'll have to try that out. Would vic theoretically be able to > transmit 640 (or 720)x480 video from a V4L device?
Unfortunately, I suspect it might end up being SCIF resolution (704 x 576) with black borders as I think that's what happens now with 640x480 webcams. > As for the flashing verticle line artifacts on Windows, I don't seem them, >> but I was using a quad-core 2.6GHz Xeon. > > We've seen it here on a couple of different systems - a Dell w/ a > dual-core > + hyperthreading 3.46Ghz CPU, and Suns with 2x dual-core 2.2Ghz Opterons - > so I doubt it's CPU-related. Can anyone else chime in if they've tried the > firewire capture on Windows? The other difference is that I was using a 576i DV instead of 480i DV (apart from a different resolution and framerate) uses a different colour space, YUV 4:2:0 vs YUV 4:1:1, which might be significant. Last year we used a Dell Optiplex GX620 (3.4Ghz P4) with the beta Windows version of UQ Vislab vic and it was struggling, while a "Core 2" based 2.6GHz Xeon performed okay.
