October 31, 2002

Emailed Tyler

As I mentioned in my previous post, we need to figure out the best way to gather link characteristics from endpoints. Since I thought ICMP packets would be the best way to do this and would let endpoints initiate traces by themselves, I emailed Tyler Johnson and asked if the NCNI routers would handle ICMP packets differently from UDP packets. Hopefully the answer will be no. I also asked him what sort of systems clients will be using, since our link probing software will have to run on those systems. Once he gets back to me on that I will be able to start writing up a new tool or choosing an existing tool to do this probing.

Posted by josuah at 7:41 PM UTC+00:00 | Comments (0) | TrackBack

More Dumps and More

I got a bunch more video dumps off vidcap4-cs from the cable TV hookup. I used FXTV to change the channel and tuner settings. I grabbed some from The Weather Channel, FOXNews, and Nickelodeon, among others. I also wanted to get some sports and music videos off ESPN and MTV, but they weren't showing anything suitable for several dumps over a period of minutes. All in all that would give me a good spectrum of video stream types.

At today's meeting with Ketan, we talked about what's necessary to get link characteristics. I think a great way to go about this would be to get ICMP traces instead of TCP or UDP because ICMP does not require both endpoints to cooperate. This way, a single endpoint can gather link statistics without having to worry about setting anything up with the other end. However, this raises the interesting question of whether or not routers will treat ICMP packets differently than UDP packets (which is what RTP is encapsulated in). Ketan suggested I email Tyler Johnson with a status update to find out how well ICMP packets will work, and also what sort of environment we can expect on the enduser systems. Tyler can answer this because many of those clients will be using the NCNI infrastructure to communicate, so the intermediate routers and client environments are known.

On another topic, Ketan also suggested I look into collaborating with a Duke student to run some Chord stress tests in either the DiRT lab or Modelnet at Duke. Using Modelnet makes more sense because it can better emulate a WAN while the DiRT lab is pretty much a heterogeneous, isolated, and dedicated network. I'll look into this at this week's TONIC.

Posted by josuah at 6:17 AM UTC+00:00 | Comments (0) | TrackBack

October 28, 2002

Cable TV

Since Ketan suggested grabbing some video sequences off cable TV (there is a cable drop into just about every room in Sitterson), I went about trying to get vic to pick up the cable signal and use it. Didn't have any luck at first, so I poked around for sample code of how to interface with the TV tuner on a Bt878; the card in vidcap4-cs is one of the Hauppauge WinTV models. I found FXTV which does everything necessary. I'm going to take a look at the source for FXTV and see how I might go about adding Bt8x8 TV tuner capabilities to Open Mash. This may or may not be something I actually get around to doing, as this isn't really necessary for the NCNI project.

Posted by josuah at 10:49 PM UTC+00:00 | Comments (0) | TrackBack

October 25, 2002

Some Sitting Captures

I didn't come in to NetLunch today but I did grab several frame sequences from home via vidcap4-cs, which is hooked up to the fourth video camera in 155 Sitterson. I grabbed video of a few people sitting in chairs using h.261 with qualities 10 and 1 at CIF and QCIF sizes, and using MJPEG with qualities 30, 60, and 90 at 640x480, 320x240, and 160x112 sizes.

One annoyance with the current dump code is that the RTP dump filename does not match up with the YUV dump. Unfortunately, the base encoder class does not guarantee knowledge of the frame characteristics, so I'm not sure how I can go about fixing this without more tightly coupling the frame with the encoder. The base encoder is only guaranteed to know about the RTP packets.

Posted by josuah at 4:10 PM UTC+00:00 | Comments (0) | TrackBack

October 24, 2002

NCNI Progress Update

It's been a while since I last posted anything about the NCNI video quality project. This is because we've been waiting on the VQM Software. It was made available today to people who sign the electronic license agreement mentioned earlier, but only for HPUX, IRIX, and Sun OS on non-x86 processors. The x86 Windows NT/2k version is not yet available and won't be available for a couple more weeks.

I thought the VQM Software would be available for Windows NT/2k at the beginning of this week, but Stephen Wolf has stated it will be 2-4 more weeks. So, Ketan and I briefly talked about what sort of image sequences I should dump to disk. I'm going to try and capture some video conferencing sequences tomorrow during the weekly NetLunch discussion. Ketan also suggested grabbing some dumps from the internal cable TV drops; I need to see if there's a TV tuner in Open Mash for that. We didn't get a chance to discuss what tools would be best suited for characterizing links or the best way to use that information.

Posted by josuah at 6:34 PM UTC+00:00 | Comments (0) | TrackBack

October 20, 2002

Mac OS X Video Capture Complete

After several hours of work, I finished support for Open Mash video capture in Mac OS X with the IOXperts Universal FireWire WebCam driver.

Video capture is currently done with asynchronous compressed frame grabs. It may be faster to do this with a sequence grabber instead, but I can't tell right now as capturing is CPU bound on my iBook (clamshell G3-466MHz Special Edition). The IOXperts driver always returns a 640x480 kComponentVideoCodecType (yuv2) image and this is cropped and converted from packed to planar.

So finally the Mac OS X port of Open Mash is complete. The first and only set of MBone applications for Mac OS. After the next official binary release of Open Mash, I'll try to get it posted on Apple's Mac OS X Downloads site.

Posted by josuah at 9:57 AM UTC+00:00 | Comments (0) | TrackBack

October 14, 2002

Replayed Dumped Video

Chema got back to me and informed me that vic actually listens for RTP streams on even ports only, and the RTCP stream should show up on the odd ports. This is probably mentioned somewhere in RFC 1889 but all I knew was that the RTP and RTCP port numbers were right next to each other. So I was able to use 'netstat -f inet' to figure out exactly which even numbered port vic was listening on for the RTP stream.

Once I got that figured out, I was able to get the receiving vic to acknowledge my recast RTP packets without sending the RTCP stream. However, my recast program was sending them back out way too fast for vic to display the frames; all it would show is the gray thumbnail. So I calculated the frame delay by taking the difference between RTP packet timestamps and reversing the formula used to generate the timestamps to get a delay time in microseconds.

With RTP packets going out to the correct UDP port and delayed to match the original send pattern as best as possible (as the timestamps are approximations themselves), the receiving vic plays back the recorded frames perfectly. Looks like this part of the project is complete. All I need now is the VQM Software.

Posted by josuah at 11:24 PM UTC+00:00 | Comments (0) | TrackBack

Dumped RTP Headers

I wanted to check out the RTP headers of the RTP packet dump I generated last week, specifically to look at the timestamp value and also to see what the header fields look like over the sequence of packets. I can see that the marker bit is set in the last packet of each frame. The sequence number is monotonically increasing. The synchronization source ID is identical. But the 32-bit timestamp, which is supposed to be based on hardware ticks, is either wrapping around quite quickly or not monotonically increasing. This timestamp is based on the UNIX clock if not coming from the capture device.

So, I need to find out first if the RTCP stream is required for Open Mash to acknowledge and process an RTP stream. And second if the RTP packets must be delayed to somewhat match up with the timestamps.

Posted by josuah at 6:55 PM UTC+00:00 | Comments (0) | TrackBack

October 12, 2002

ImageDescriptionHandle OK

So the problem was I needed to allocate memory for the ImageDescriptionHandle, which is of type **ImageDescription. Basically, it needed 4 bytes allocated with NewHandle() to act as the pointer; VDGetImageDescription() was not assigning an ImageDescriptionHandle but instead an ImageDescriptionPtr (which is of type *ImageDescription). So now that I got that straightened out, the actual frame grabbing seems to work.

I've set the Video Digitizer compression to 16-bit kComponentVideoUnsigned (yuvs) with a bounding rect (0,0,352,288). But the image data returned by VDCompressDone is 614400 bytes and appears to be in 16-bit 640x480 format instead of CIF size 352x288. Regardless, I have a pointer to the image now, so I just need to figure out how to write the VideoCaptureMacOSX suppress() and saveblks() methods and vic should be able to transmit something, even if it looks like junk because I got the internal formats wrong.

Posted by josuah at 12:28 AM UTC+00:00 | Comments (0) | TrackBack

October 11, 2002

VideoDigitizer Call Sequence

I did some more work on adding video capture support to Open Mash but some things aren't working right. NewTimeBase() is choking with a Bus Error, so I commented that out. So I couldn't call VDSetTimeBase(). I also should be using VDGetCompressionTypes() to choose a correct compression type for VDSetCompression(), but since Mash only supports YUV I'm just going ahead and setting it to that explicitly. That's not throwing an error, so I'm guessing that's okay. But VDGetImageDescription() is returning -50 (bad parameter) and I don't know why.

I also emailed Wei about the weird DELAY define which causes parts of degas to be included only on Mac OS X. Apparently DELAY is defined in Apple's gcc for some reason. Wei suggested I check on this by passing the -E argument to gcc. If it turns out DELAY is defined anyway, I'll get around to changing DELAY to DELAY_DEGAS or something like that so it won't cause this problem on Mac OS X.

Posted by josuah at 2:57 AM UTC+00:00 | Comments (0) | TrackBack

October 10, 2002

VQM Software Available Soon

I just copy an email back from Stephen Wolf over at the Institute for Telecommunication Sciences about the VQM Software. They've finished drafting the no-cost evaluation license agreement and after we read it over, sign it, and send it back we should be able to download a copy of the software for research purposes sometime in the next couple of weeks. The timing is just about perfect. I've forwarded the license agreement to Ketan for review but I don't see any real problems with it.

Posted by josuah at 2:55 PM UTC+00:00 | Comments (0) | TrackBack

October 9, 2002

More Dumping to Disk

Since I don't want to dump frames to disk all the time, I made some further modifications to Open Mash and specifically vic. Now you can type in a filename and click on a checkbox to start capturing frames to disk right after they are grabbed by the capture device. This is important because it lets me choose when to start and stop recording. Without this, the dump file would have to be post-processed to only include the portion of video I'm interested in. I'm thinking about doing the same thing for reconstructed video, but since I don't really need to do that that may not happen. I haven't decided whether or not to commit my UI changes back into CVS. Maybe I'll just comment out the Tcl/Tk code that draws the UI for this feature and commit everything that way. I'm going to commit my changes to codec/device.[h|cc] no matter what, though, because that append function will be incredibly useful for someone else later on.

I also met with Ketan for our weekly meeting and gave him a progress report. The two of us tracked down where to dump the RTP packet data in rtp/session-rtp.cc. So I'll add that shortly. I'm going to try and link the dumping of the YUV frames to the dumping of the RTP packet data, which will make it much easier to output synchronized RTP packets and the YUV frames being stuffed into those packets. If they are out of sync, then any comparisons will obviously be inaccurate.

No news yet on the licensing for the VQM Software. I've emailed them again to see how that's coming along.

Posted by josuah at 10:34 PM UTC+00:00 | Comments (0) | TrackBack

October 8, 2002

Dumping BigYUV to Disk

Turns out the cameras in 155 Sitterson are just fine. I ran around the entire building today looking for a composite video cable to try and test the cameras directly with the projectors, but when I got back to 156 Sitterson, David Ott was there and explained that the little light on the front needs to be green and not red. Red is some sort of standby mode. Once we found the camera remote I was able to activate all of the cameras and the signal came over the S-Video just fine.

I then modified video/video-meteor.cc (the device used for Brooktree cards) and codec/device.[h|cc] so that I could append frames onto a file. When using YUV 4:2:2 (e.g. JPEG) I dump in BigYUV format--the format expected by the VQM Software. I tested vic with JPEG large, highest-quality, maximum bandwidth/fps and was able to get up to 27fps on vidcap4-cs. So dumping to disk is not putting a significant strain on the process; 27fps is approximately where vic got before I made these changes. vidcap4-cs is a Pentium III 1GHz with 256MB PC-133 SDRAM and 9GB hard disk. I'm not sure what the specifications of the hard disk are, but at 27fps the dump file quickly approached 100MB in just a few seconds.

Posted by josuah at 8:09 PM UTC+00:00 | Comments (0) | TrackBack

October 7, 2002

vic on Vidcap Machines

I compiled the Brooktree 878 device into the kernels on vidcap3-cs and vidcap4-cs, and created the device file /dev/bktr0. I then grabbed the latest Open Mash out of CVS and compiled it into my Vidcap local user account. vic is running fine, but I can't find a signal on the S-Video port of the Bt878 cards where the cameras in 155 Sitterson are plugged in. All I'm getting is a deep blue screen. There's some other signal going into Port-1 of the Bt878 which I can view as a bunch of multicolored snow, so I know the card is working and vic is talking to it. I must need to do something special to either turn on the cameras or activate the signal.

Posted by josuah at 8:44 PM UTC+00:00 | Comments (0) | TrackBack

October 2, 2002

Vidcap(3|4) Installed

Yesterday the ghosted vidcap3-cs and vidcap4-cs machines were returned to the DiRT lab. Today I installed the FreeBSD partition with 4.6.2-RELEASE and a DiRT kernel. So those machines are pretty much ready for some video capture testing with the cameras in 155 Sitterson.

I also had my meeting with Ketan today. We talked a little bit about the data path for this system. After I install Open Mash on these vidcap machines, my first objective will be to start capturing video from the cameras and dump the raw YUV frames to disk. Afterwards, those raw frames need to be read back into vic as a source and encapsulated in RTP packets which will also be dumped to disk. Those packets can then be sent out for test purposes without going through the encoding process again. Finally, a receiving vic needs to dump the raw YUV frames of the reconstructed video out to disk for comparison by the VQM Software.

Posted by josuah at 10:27 PM UTC+00:00 | Comments (0) | TrackBack

October 1, 2002

Using dummynet

I downloaded the latest Open Mash source from CVS and compiled it on Effie. It actually compiled pretty fast over NFS, probably because home directories are on the new WD1200JB hard disk. Effie is a PII-266 with 256MB SDRAM, and I think it compiled faster than when this machine was running Solaris 8 Intel. Of course, Solaris creates much larger binaries of Open Mash, so that might be the reason. But the compile time seemed pretty fast to me regardless. I wonder what performance will be like when Binibik is running nightly tasks, since / and /home share a single IDE controller.

After compiling, I got dummynet going and saw frame rates of MJPEG drop very quickly as packet loss increased. Unfortunately, ipfw also decided to drop a bunch of error messages which got quite annoying and on a slow machine this may actually reduce the amount of CPU available to vic.

Posted by josuah at 4:18 AM UTC+00:00 | Comments (0) | TrackBack