[MPlayer-users] first frame green with directx vo using slave mode

mo mo at avpresentations.com
Fri Nov 15 14:26:26 CET 2013


On 11/15/2013 01:59 AM, Reimar Döffinger wrote:
> On 15.11.2013, at 00:17, mo <mo at avpresentations.com> wrote:
>> On 11/14/2013 03:36 PM, Reimar Döffinger wrote:
>>> On Tue, Nov 12, 2013 at 06:54:09PM -0500, Morris wrote:
>>>> This is using the   sherpya-r36475+g0bf8580-4.6   build.  I have
>>>> found this to be true on all versions of mplayer I've tried in the
>>>> last 6 months to a year.  I had changed to direct3d and the gl vo
>>>> quite some time ago, but some of the videos I have now don't play
>>>> back smoothly enough with those video outputs
>>> Since DirectX is kind of dead, it might be worth checking if you can
>>> get those other vos (in particular gl) up to the same speed though...
>> Do you have any suggestions for how to do this?  I have a pretty good nvidia video card in the laptops I use (nvs4200m).  I can get up to about 50 fps at 1280x720 with using  -vo gl:force-pbo.
> Do not use force-pbo, it should be auto-detected and only help for bad drivers.
> Use -dr to get a bit of speedup for some video types.
> Use -vo gl:swapinterval=0 if you use aero or otherwise can't see vsync issues (aka tearing) with it.
> Use -lavdopts threads=...
>
>> However, I need to be able to get 60 fps since I usually use interframe to frame double 30 fps media (This is for corporate videos that need to look extremely smooth when projected, not just for watching movies).  If you have suggestions on speeding up gl further, that would be great.
> 60 fps is usually the refresh rate, which is problematic. Enabling aero and instead disabling gl's vsync (swapinterval=0) might work better.
> Enabling triple-buffering and vsync in the driver settings might be an option, too.
> Either way I suspect that speed (as in too high CPU load) is not an issue, but running too close to screen refresh rate is.
> Of course the heavy-handed solution to that is a 120 HZ display...
>
>> I get just over 30 fps with direct3d, not sure why, I thought that was supposed to be a newer vo.
> It was never optimized, but exactly 30 seems suspicious...
>
>>   I can provide benchmarks I did with directx, direct3d and gl if that would help.  I couldn't really understand what they showed.
> In particular if they contain performance traces or CPU usage numbers that might indeed help.

[swscaler @ 023c6f00]BICUBIC scaler, from yuv420p to yuyv422 using MMXEXT
VO: [directx] 1280x720 => 1280x720 Packed YUY2
BENCHMARKs: VC:   2.863s VO:  11.166s A:   0.000s Sys:   0.586s =   14.615s
BENCHMARK%: VC: 19.5895% VO: 76.4010% A:  0.0000% Sys:  4.0096% = 100.0000%



VO: [direct3d] 1280x720 => 1280x720 Planar YV12
BENCHMARKs: VC:   4.341s VO:  31.850s A:   0.000s Sys:   0.180s =   36.371s
BENCHMARK%: VC: 11.9354% VO: 87.5696% A:  0.0000% Sys:  0.4950% = 100.0000%



VO: [gl] 1280x720 => 1280x720 Planar YV12
BENCHMARKs: VC:   3.043s VO:  33.065s A:   0.000s Sys:   0.221s =   36.329s
BENCHMARK%: VC:  8.3762% VO: 91.0154% A:  0.0000% Sys:  0.6083% = 100.0000%



>
>>>> I expect that this is related somehow to idle or fixed-vo since it
>>>> doesn't happen with the first video, but don't really know.  Any
>>>> ideas?
>>> Probably the DirectX surface somehow gets filled with 0s.
>>> That results in green output.
>>> How exactly that happens would need proper debugging.
>> Is there anything I can do to provide that debugging?  Not sure exactly what you would need for that.
> Time, or alternatively someone else kind of familiar with the code and/or DirectX and time.
> I suspect you cannot help with that though ;-)
>

Thanks for all this info Reimar.  I'm going into several days on site 
with shows so won't be able to adequately test some of your suggestions 
til late next week.

As far as debugging, I am at best a poor c++ programmer and really don't 
get c all that well at all. I've done some directshow work with another 
project, but it was at a high level and I eventually abandoned the 
directshow technique i was using all together.  If you think it would be 
worthwhile I could try a look at the code around mid to late December.

However, I'dreally like to better understand the issues with 60 fps, 
which is indeed the refresh rate I use.  I had intentionally asked for 
videos to be created at 30 or 60 fps because I thought this would match 
up better to the 60 hz refresh.  What would you suggest for a better 
playback at 60 hz?  Would 59.94 fps work better, or is that still too 
close to the refresh rate?







More information about the MPlayer-users mailing list