schloer.jason at tangoinc
Dec 9, 2003, 12:52 PM
Post #3 of 3
(6260 views)
Permalink
|
I did the same thing recently and ditched XVMC cause it wasn't helping(I
also got the M179's). I also have much slower channel changes using the ivtv
cards vs. my old mpeg4 TV wonder VE. Anyway, not complaining, just figured
I'd mention my experience as well.
-Jason
-----Original Message-----
From: mythtv-dev-bounces [at] mythtv [mailto:mythtv-dev-bounces [at] mythtv]
On Behalf Of bdillahu [at] peachbush
Sent: Tuesday, December 09, 2003 1:01 PM
To: Development of mythtv
Subject: Re: [mythtv] Prebuffering pause (again)
Just some added "data points" if it helps somebody... (I'm understanding
this prebuffer to be a cause of the channel change speed arguments)...
I had a Win2000XP card hooked up... worked fine... fast (1 sec. or less
channel changes).
I changed out to (2) Avermedia M179 cards (recent Ebay round)... work
pretty well (couple of driver things, but once you get them going, great)...
Since these are now MPEG2 I activated XvMC... now channel change speed is
4+ seconds... I hadn't thought about the XvMC change at the same time... I
may test on that and try to see if its a factor of MPEG2 or XvMC.
Could something in this be why some people see the slow change problem and
others don't?
Bruce
On Tue, Dec 09, 2003 at 09:27:27AM -0800, Steve Brown wrote:
> EVIDENCE
>
> This seems aggravated by xvmc and hdtv.
>
> It occurs not just with ota playback, but also with recorded playback.
>
> I've tried various combinations of "Experimental A/V Sync", "Extra Audio
> Buffering" and "Jitter reduction" without noticable change.
>
> I've read the dev and user lists and the concensus seems to be that this
> is related to data not being available in time. Maybe low data rate or
> max'ed cpu.
>
> In my case, the cpu is 2.8GHz and the disk is SATA. CPU utilization is
> only about 50%. I suspect there is plenty of cpu and no problem getting
> data. When the "prebuffer..." messages start, the cpu utilization
> actually goes down.
>
> THEORY
>
> Could part of the problem be the latency in the method used for
> synchronism between the main thread in NuppelVideoPlayer and the
> VideoOutputLoop thread it spawns in StartPlaying? Currently, if a free
> buffer isn't available, the thread usleeps for a while and tries again.
> This means that when a buffer is freed by one thread, the other thread
> still completes its usleep interval before getting back to work.
>
> SUGGESTION
>
> If the above is correct, could the QSemaphore mechanism provide lower
> latency and maybe reduce the problem?
>
> I'm inclined to try this and see, but first wanted some feedback.
>
> I know this issue has already been discussed at length and hope I'm not
> wasting your time.
>
> Flame away,
>
> Steve
>
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev [at] mythtv
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
|
