So much for bluescreening component video with one transistor and relaying indie NTSC 10 watts at a time; on the other hand, so much for reaping long yards of broadcast metadata and other data on CC/SAP, and using 8 tuners (why wouldn't BestBuy want to throw more $100 (retail) antennas through their channel, after all) to have device intelligence throw out bad programs and reencode, time-shift, run the deep-data ads (3D broadsheets, yay,) to hyper-refine data before presentation! More USB device declarations and their PCIx correspondences! Would the LED to make an ultra-speed device indicate new 5.2 audio put it over the power draw limits? With the antennas, perhaps it is better as a premium rain barrel or solar power patch first, and video amanuensis second.
Cmathas, Rama and Kinnar,
Thank you for the explanation it is more clear for me right now, and yes, I agree with the data loss in Bulk, well so now I undesrtand that USB 3 is a high step in the quality of the achivement of the PC TV devices. I hope we can meet us again in future articules it is a plesure to be here, it is my first time on this. Thanks again and regards.
Right. Buffering does not help us as the bandwidth offered by USB2.0 is not sufficient to get a clean video from a analog signal, As kinnar rightly pointed out above. You can go for BULK transfers but as you know BULK transfers are bursty in nature. So you will observe some glitches (data loss) in the final video output.
Why the author has limited the application of this interfacing for the PC-USB TV, this scheme is equally applicable to any of the LCD/LED/Plasma TV as well, only display driver hardware will be required in between or may be ARM Processor can taken care of if processing power is there after taking care of the MPEG-TS.
So if we use USB 2.0 is there any other protocol that permits to reach the best TX rate to the computer? O probably any buffering process into the device or in the computer to recover the delay on the transmission via USB 2.0???
Blog Doing Math in FPGAs Tom Burke 15 comments For a recent project, I explored doing "real" (that is, non-integer) math on a Spartan 3 FPGA. FPGAs, by their nature, do integer math. That is, there's no floating-point ...