[OFFICIAL] MPlayer.dll development branch feedback.

elupus, about how much cpu would you say ogg consume for decoding when it's muxed with a video stream such as AVC? I notice that the a/v sync value varies around 0.01 - 0.05 with avc + ogg.
Also, to ensure perfect sync with avc + ac-3, we'd need to delay the audio by -0.1ms. I mean it's kinda obvious, just look at what it says early/late. 0/2.

That's not a big deal though. I'm just wondering if there'll be a way to make interleaved avc/ogg decode properly.



VBR aoTuV ogg = best compressed audio source ever. Well, in my opinion

elupus Wrote:MartinC don't crop logs... post them on pastbin for example

OK.

http://www.pastebin.ca/468416

Elupus,

Me and MartinC have been talking about creating a standard procedure to make benchmarks, so that the ones I do are comparable to his. The only diference between our procedures, is that he outputs to pal 4:3 and I output to pal 16:9.
Is this enough to make the benchmarks incompatible? Our sources are all 16:9

finas, why not set pal 16:9 as a common benchmark then? even if one only has 4:3 screen it does not matter other than image will be wrong aspected when viewed, but that does not matter to performance

doesn't matter. that is only gpu scaling, won't affect anything.

MartinC, that file just looks unsupported. Don't really know what's wrong with it.

elupus, that's what I thought, but why is there a difference between viewing same hd content in 1080i and 720p mode. in 720p mode it's smooth but in 1080i it has drops.
my hd content (1280x720) looks better at 1080i and then scaled down to 1366x768 by the tv than scaled up to 1366x768. maybe it's just me that's what I think

well.. hmm.. well.. there is quite a huge leap from 720p to 1080i (or p as we have handle it). I didn't think we would hit any gpu limit. I assume you tried the different renderers and disabled interlaced handling. If you happen to have the xdk installed and a debug bios you can check the gpu/cpu usage and see the difference.

elupus Wrote:MartinC, that file just looks unsupported. Don't really know what's wrong with it.

Weird it plays back for the most part expect those few seconds.

In the first log I provided XBMC crashed, in the last one it just auto exited the file.

anyway, could we please avoid talking about perf issues with renderers/special cpu's in this thread.. keep it in the other one please.

it's very O.T.

Hi elupus,

first of all let me thank you for putting so much work into the development of mplayer.dll But I am sorry to say I think I may have found a major bug to your latest mplayer.dll.

When playing back a mms:// source the frame duration seems to double whereas the audio plays back in regular speed. Means: Video is at half speed, audio is at full speed.

Here is a debug log I did today:

http://www.xbmc-tv.com/xbmc.log

Funny enough that worked in the previous mplayer.dll as for example in the T3CH build of 2007-02-16 (the then "official" mplayer.dll not your version).

As my project XBMC-TV is using a lot of mms:// sources this is kind of a problem as our "customers" will have a decreased viewing comfort when going for the latest mplayer.dll. Could you plz be so kind and look into that?

If you need any further information feel free to contact me.

Cheers
akaigotchi