Re: New ATSC messages.
Bill Pringlemeir <[email protected]> Mon, 17 Dec 2007 21:25:27 -0500
| Newsgroups | gmane.comp.video.mplayer.user.dvb |
|---|---|
| Message-ID | <[email protected]> |
On 9 Dec 2007, [email protected] wrote: > Date: Sun, 9 Dec 2007 10:11:31 +0100 > From: Nico Sabbi <[email protected]> > Subject: Re: [MPlayer-dvb] New ATSC messages. [snip] >> I have changed the azap code to open in RDONLY mode and according >> to the output, the ber is zero and the channels are locked. It >> appears my CPU is a bottle neck, but the top display never shows >> full cpu usage. > I suspect simply bad reception You are correct. I had never seen these messages before and had just updated from SVN so I thought they were new messages just put in the code. I haven't seen them since. I am also 20km from the CN tower with a CM 4221, so I thought bad reception was unlikely. My neighbour must have started his arc welder. I have been using atscap to capture the streams. It seems that mplayer plays the "ts" stream much better than the direct V4L2 stream. I think that this is due to the fact that the file provides a huge buffer. Is there a FAQ entry somewhere on the preferred method to capture streams? I imagine it is 'cat'ing some device. In the mean time, I have come to the realisation that the i865G driver can not play 1080i on my system. I had read a MythTV entry that said a 3Ghz process was sufficient to drive a 1080i stream. This seems to be consistent with what top reports (~60%). I still have some skipping though. I have began to question memory bandwidth on the Celeron D 350. http://en.wikipedia.org/wiki/List_of_Intel_Celeron_microprocessors I ran a test program (http://home.comcast.net/~fbui/bandwidth.html) and things really seemed to degrade. I believe that the FSB is running at 533Mhz according to my mobo docs (533MT/s according to Wikipedia). It seems that this take 1080*1920*4*60 bytes/sec just for a screen refresh. This is already 400MB/s. In order to do interlaced images, there has to be a double buffer with lots of copying. It would seem that the real bottle neck to using 108Oi is not the CPU clock speed but the memory bandwidth. So, I am guessing that an external card with have dual-ported memory and reduce the amount of traffic on the FSB. A card supporting XvMC will definitely reduce this traffic, but it cann't support more advanced codecs and/or filtering. So, I am looking at a nVidia card that supports XvMC and has 1920x1200 DVI capabilities. I know the XvMC will work, but is it correct that an external card will reduce the FSB memory pressure? None of the HDTV faqs I have read seemed to mention anything of this. It is unfortunate that the i865g Xorg drivers don't due XvMC (it seems only i810 and i815 support this). A MythTV faq seems to say that any card using the i810 driver will have XvMC. http://www.mythtv.org/wiki/index.php/XvMC The i810 driver (now intel) supports many chipsets, but very few have XvMC support. I guess that the 533Mhz mobo docs are correct and I actually have 533*{4,8,16} bytes/second. Otherwise, I don't understand how mplayer can play this 1080i on my system at all. The Mpeg2 decode phase has to run over YUV in several interlaced blocks. Even at 3.2Ghz, this is about ~60,000 instructions/pixel with dual pipline, but the MMX/SSE instructions would have to be all over memory with separate YUV iDCT per pixel (group). It did seem that the libmpeg2 might be able to do a crude scaling at the start of the decode. Ie, use the frequency information to do a nice integer scale that would reduce the memory bw. I am currently trying to play at 1280x1024 resolution. I think if xv is doing the scaling, a complete 1920x1080 memory buffer must be used and the i865G is fitting it to the screen? That isn't a request, just a query to confirm that it could be possible. Am I smoking crack? Is there some place to put some notes like this? The V4L wiki seems to be concern with getting a stream. Not moving the stream onto a display. It is quite amazing that mplayer does such a great job given the amount of data it is dealing with. Thanks, Bill Pringlemeir.