[MPlayer-cvslog] r31015 - trunk/libvo/vo_corevideo.m

Benoît Amiaux benoit.amiaux at gmail.com
Mon Apr 5 19:06:07 CEST 2010

On 05/04/10 18:55, Reimar Döffinger wrote:
> On Mon, Apr 05, 2010 at 12:30:37PM -0400, Alexander Strange wrote:
>> I mean to merge the two sometime - gl is 70%(!) faster than corevideo for me.
> You have my full support for that - I've done some work to make -vo gl quite
> independent from the "backend" but I lack understanding of the OSX API
> and I can't think of a really good way to combine C and Objective C code in
> order to actually get it done anytime soon.
> (I only request that if you think you need to do modifications to gl_common
> you maybe discuss that first with me).
>> BTW the coreaudio AO is fine as far as I know, although it does seem to use the system resampler instead of mplayer's.
> Depends on how you define "fine".
> For AC3-passthrough it waits for the result of AudioStreamSetProperty in an
> indeterministic way, which I suspect is either the cause or hides the cause
> for the issue described here:
> http://lists.mplayerhq.hu/pipermail/mplayer-users/2010-April/079589.html

I looked at that code, because I had a 5s delay each time I was playing 
audio. Apparently, the whole function AudioStreamChangeFormat is broken.
SVN version loops for 5s then aborts.
If i re-use an older version which used pthread_mutex and pthread_cond, 
I get a deadlock, because the callback never get called.
I just removed all of this in my tree, and I don't get unexpected 
behaviors, but it's not a proper solution.

More information about the MPlayer-cvslog mailing list