[mythtv] Prebuffering pause (again)
bdillahu at peachbush.com
bdillahu at peachbush.com
Tue Dec 9 13:00:31 EST 2003
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.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
More information about the mythtv-dev
mailing list