[mythtv] MacOS X MMX yuv420_2vuy Patch
mythtv at taoyama.com
Fri Sep 8 04:51:31 UTC 2006
I don't think it is the MMX code. I think there is some timing race
condition between threads. There is quite a difference between the
Quartz and XV videooutput implementation. I'm trying to trace this
back from the reported error of no buffers being available based upon
Daniel's comments earlier in the thread about the lack of locking in
Quartz videooutput code in the input changed code.
The reason I think it is a timing problem is that I can change the
failure from just starting to watch vs. a channel change by enabling
I think with the faster routine we are now hitting the timing race
condition more reliably. One experiment to try would be to add a big
delay loop in the MMX code and see if the failure goes away. (It
might cause the video to stutter but at least this would tell us if
this is a timing problem.)
I'm currently putting a bunch of logging into the code to see if I
can see why the video buffers are not being released. I'm having a
hard time following the code but I'm getting there.
On Sep 7, 2006, at 8:36 PM, Nigel Pearson wrote:
>> I've tried this patch, but the logs don't appear to be any
>> different. Hope I've done everything correctly!
> Sadly, I concur.
> (I blew some money on a new MacBook yesterday).
> Unless the stream is an odd size like 702x576,
> then the behaviour is identical.
> Am slowly narrowing it down by placing a
> return in the body of the for(x...) loop.
> Still hangs? OK. Move it back a few lines. et c.
> Nigel Pearson, nigel at ind.tansu.com.au|"Gentlemen,
> Telstra Net. Eng., Sydney, Australia | you can't fight in here
> Office: 9202 3900 Fax: 9261 3912 | - this is the war room!"
> Mobile: 0408 664435 Home: 9792 6998 | Dr Strangelove
> mythtv-dev mailing list
> mythtv-dev at mythtv.org
More information about the mythtv-dev