Brian Kuschak wrote: > Hi Wolfgang, > > Thanks for your input. Comments inline. > > >>My idea would be to use an (embedded) processor for >>doing >>all the control and network stuff, and have an FPGA >>for >>the TS handling (and demux). Like this you could >>have a >>DVB card that is not only usable for such a server >>but >>also for a "stand-alone" PC. > > > My idea was at least initially to implement a very > minimalist solution, keeping things as simple as > possible. A single FPGA would implement a minimal > Ethernet MAC, FIFOs to buffer data from the > tuners/demods, an i2c master, and a small state > machine to handle control packets. In this case, no > CPU would be used in the device. All control of the > tuners and parsing of the data would be done by the > client PCs. Parsing would need to be done in both directions... it's pretty much unavoidable. More and more information is sent in XML, such as the UPnP tuning, or conversion of EPG to a portable format... And having a processor isn't a big deal... It allows you to have instrumentation, and even in a multicast environment, there is still a certain amount of 2-way traffic: either unicasts in reliable multicast, or else squelching traffic to multicast groups with no members (so you don't generate useless packets). > > If the data is multicast/UDP, then the state machines > wouldn't even need to ARP, and of course wouldn't need > to implement a TCP stack. I'd have a look at how IGMP works, before assuming you can do multicast without a processor... > >>Advantage: you could maybe integrate some more fun >>stuff, >>like packet time stamping (MPEG >>measurement/testing), >>accurate (synchronised) PCM/AC-3 output without >>resampling, >>PCR synchronisation on board, section >>filtering/version >>control, etc. Of course this would then be more >>targeted >>for the stand-alone PC, but this is what I am really >>missing from all the "solutions" available right >>now. > > > The timestamping part would be easy. Reading the PCR > values from the packets wouldn't be too hard in an > FPGA, although it might not be much of an advantage if > the card just sends MPEG-TS over ethernet. The tuners > I was considering output a byte-parallel MPEG TS data > stream. The time delay from demodulation to ethernet > transmission would be very short. Byte parallel? Why? The whole point of multicast is you join a group that is relevant to what you want... If you interlaced all of the streams (which isn't reasonable for large numbers of streams), then you get a lot of traffic, the majority of which gets thrown away. You'd more likely want to have one channel (possibly combining HD, ED, and SD PIDs) per multicast address. This allows the receiver to only get the traffic that is useful to him. -Philip > >>Do you have FPGA experience? Are there other people >>maybe >>already working on such a thing? Anybody already >>implemented >>a video decoder in an FPGA, to have a new >>full-featured >>board like this? ;-) > > > I've done several FPGA designs in the past, and have > some bits of VHDL code which can be leveraged for this > design. A full video decoder is beyond my scope of > experience, though. > > Regards, > Brian > > > > > __________________________________ > Discover Yahoo! > Stay in touch with email, IM, photo sharing and more. Check it out! > http://discover.yahoo.com/stayintouch.html > > _______________________________________________ > > linux-dvb@xxxxxxxxxxx > http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
