[MPlayer-dvb] New ATSC messages.

[Bill Pringlemeir]

On  9 Dec 2007, mplayer-dvb-request at mplayerhq.hu wrote:

> Date: Sun, 9 Dec 2007 10:11:31 +0100
> From: Nico Sabbi <Nicola.Sabbi at poste.it>
> 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.