(originally posted here∞)

Nope. Modern motherboards stick ATA controllers on their own port. Shouldn't be a problem, though.


HuffYUV doesn't, but it's lossless so it doesn't matter. PicVideo requires you to set a switch (which will increase the filesize, but it's worth it). ffvfw, alas, does not, so it's extra important to use high quality settings to capture the "detail" of weave artifacts.


FWIW, fine detail is easiest for huff to compress. You get bigger files by increasing the color gamut.

Random info: if you use ffvfw, the MJPEG quality scale is 0-100 instead of 0-20 like most codecs. It doesn't scale the same either -- you have to get up to 98+ to hit the same bitrates as Pegasus/PicVideo @ 19.

---

Not if it keeps the compressed video from clogging the PCI bus. Every time the root hub sends a packet to an PCI ATA controller, the capture card has to wait. If it waits too long, it drops a frame.

On the diagrams you linked, the links to PCI and to ATA can be active simultaneously, or even asynchronously.


Depends what "simple" is. The pattern below has lots of "detail" that would be very difficult for an FFT codec to render, but HuffYUV gives me just 500 bytes/frame. (A few minutes of tweaking with colorspaces got it down to 180; if it were an adaptive huffman codec, it would do every two-tone 20x20 image in only 50!).



In your case, it's likely that your toons simply have fewer colors. (More accurately: since it's not adaptive, its color gamut is closer to that of the clips used to generate the original Huffman tree.) The parts of your natural video sequence that we usually call "detail" (high frequency) don't make any difference to Huff except when they lie on a 2-pixel horizontal boundary where the ADC's chroma subsampling smears them into more colors than necessary.

---

Yes, that's how buses work. One device broadcasts exclusively, then gives it back. There's some overhead in the protocol -- for example, you have to request a timeslice from the current bus master -- which is why you never see topologies like PCI reach their theoretical peak.

(Ethernet is similar; think of the difference between hubs and true switches. Or take USB, which never even gets close to its max because every intermediate device in a daisy-chain is effectively a "hub." Relevant example from a few years ago: the SBLive/Via incompatibility basically boiled down to the Live wanting to xfer longer than PCI's timeslices allow + old Via hubs not enforcing the rules strictly enough. Yet another: the default Win98 ATA driver's inability to do DMA having such a dramatic effect on overall system performance.)

These disadvantages, along with the fact that clockspeed is cheaper than pincount nowadays, are why modern "buses" (e.g. HyperTransport, PCI-E) are translated internally into point-to-point interconnects. In the latter case, the PCI protocol is only kept for compatibility.


It works because 20MB/s (YUY2 to cpu/ram) + 10MB/s (HuffYUV to disk) is well within PCI's capabilities. If you looked at the bus you'd see something like this: the cap card broadcasts a ~10us (720 pixels * 16bpp / 33MHz / 32bit) that the root hub pokes directly into ram (bypassing cpu with dma), then a few clocks of arbitration, then a ~30us (4KB) dma burst from ram to disk, and so on back & forth. "A few clocks" is usually less than 10, so in an ideal burst situation with no other traffic you're wasting less than 1% of your peak b/w. Even after accouting for other I/O cards, PCI remains pretty efficient, which is why it's lasted 15 years.

As for the BX chipset itself, I don't think it supported read prefetching, so you need to add some more latency into such calculations on average. (much more info available at pcisig.com) Not nearly enough to cause 30MB/s of total streaming traffic to choke, obviously.

---

Back to CollectedWritings