Olin Atkinson wrote: > Doesn't the ts stream come in mpeg2? > For the ATSC standard (which applies to your device), the underlying content contained in transmission streams is indeed MPEG2 encoded. The transport stream itself is a container format, specifically an MPEG2 TS. ... i.e. the MPEG2 TS container is packed with MPEG2 encoded content. Other digital standards also use a MPEG2 TS for transmission, and, in general, the underlying content contained in the TS is typically MPEG2 encoded, however, the adoption of MPEG4 encoded content is beginning in some regions.... i.e. the MPEG2 TS container is usually packed with MPEG2 encoded content, but in some cases MPEG4 encoded content may be now be used instead. > I don't know much about how these things work, I was hoping that dvb > would nit need the mpeg decoder. > I'll note that it is very difficult to write a brief reply/explanation because of the broad scope of concepts that must be addressed in relation to your device. Unfortunately, its not a very good device with which to acquaint a newbie, so to speak, on how DVB devices function. For now, I'd direct you to to the following (unfortunately, incomplete/WIP) wiki article that may provide some elementary background context: http://www.linuxtv.org/wiki/index.php/Hardware_or_Software_Decoder%3F In any regard, in order to _display_ the content received, which as mentioned above is encoded in MPEG2 format, it will need to be decoded somewhere -- either performed on the DVB card or shuttled "downstream" to be decoded by the CPU (with or without GPU assistance). I also kind of suspect that, although you wrote "decoder", you might be confusing together the concepts of encoding and decoding. Now, when it comes to _storing_ (as opposed to displaying) the content to disk, a decoder most certainly need not be employed. However, your card is a particular case, so I don't know if the decoder actually can be circumvented for straight streaming of the TS to disk -- it would all depend on the wiring on board. Essentially, the WinTV-D was designed back during the inauguration of digital television services in N.A. With the WinTV-D, Hauppauge's design decisions (which were based/rationalized on factors such as the processing power required to decode MPEG2 HDTV, the number of users with HDTV displays/screens etc.) allowed the reception of DTV content, though limited the experience to SDTV resolutions. What the WinTV-D was intended to do for live playback was decode the TS on board (via the LG 802 MPEG2 decoder) and then, if it was HDTV, down-res the stream to a SD (standard definition) resolution (via the Xilinx IC) and then send that resultant SD stream offboard, across the PCI bus, to the graphics adaptor for display. Whether it repeats similar steps for saving to disk, I can't tell you --- i.e. decode the TS on board (via the LG 802 MPEG2 decoder) and then down-res the stream to a SD (standard definition) resolution AND encode it as a SD MPEG2 stream (all via the Xilinx IC), and then send that resultant off board, across the PCI bus, to the hard disk. Ideally, it would be very nice to circumvent the above outlined steps and just have the demodulated TS (i.e that coming out of the Philips demodulator) be streamed straight off the card to disk....or for sending the TS straight to the CPU for decoding i.e. running this hardware decoding card in software decoding mode. In that wiki article linked to above, you may find mention of the "Full Featured" cards being run in software mode. There is somewhat of a comparative difference though -- with those Full Featured DVB-[S,C,T] cards, the on board MPEG2 decoder was limited to SDTV resolutions, hence to use these cards with HDTV streams it is necessary to drive them in so called software decoding mode. With the WinTV-D, on the other hand, the LG MPEG2 decoder can handle HDTV resolutions. But then, as this card lacks any facility to get a raw undecoded HDTV stream off the card (read: too big to stream across the PCI bus and no framebuffer out device like the MIT MyHD cards use) , it is necessary to run the card in software decoding mode, or utilize the pathway intended by Hauppauge. > Would you be able to help me find the best jumping off point? Are > there any existing projects that would have close to what I need? > Where would be a good place to host the project? Are there and good > documents on the architecture and design principles. I have always > wanted to get in to this kind of stuff, but there has never been any > time and what little research I have done there was soo much > information that I could not get my hands around it. > - look into developing a driver for the Philips demodulator (TDA8960) on the card ... the datasheet is available via google. - look at the full featured stuff (ttpci) in LinuxTV ... also see the DVB API - look at the IVTV stuff for the (analog) Hauppauge WinTV-PVR-350 card ... as it has implements a hardware MPEG2 decoder - see the MyHD Project: http://myhd.sourceforge.net/index.php ... unfortunately, progress has been slow with this project ... one thread that would be of interest is this one: http://sourceforge.net/mailarchive/forum.php?thread_name=BAY144-F34F1962A8BBC741E57BE34A8C30%40phx.gbl&forum_name=myhd-develop All in all, I think running the WinTV-D in "software" decoding mode is the most appropriate route to go with this card....but whether it is feasible is another story ... investigation of the routing available on the card is needed, and undoubtedly requires obtaining some info about the LG decoder. _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
