[MAC] VDADecoder performance over HDMI on new Mac Mini?

davilla Wrote:EDIT2: WARNING: CDVDMessageQueue(audio)::Get - asked for new data packet, with nothing available. if you type 'o' and look for aq, bet it's zero.

Oh, I think that was when I hit pause. :-) Sequence of events was, start xbmc, play that video, hit pause, grab the xbmc.log. That's why those warnings only appear at the end.

Until then the sound is the only thing that works perfectly. :-)

Rachel Wrote:Oh, I think that was when I hit pause. :-) Sequence of events was, start xbmc, play that video, hit pause, grab the xbmc.log. That's why those warnings only appear at the end.

Until then the sound is the only thing that works perfectly. :-)

OK, correction, having played it again looking specifically for that. After a minute or so of playback the aq% does indeed drop and when it hits 0% the sound starts to break up. And those warnings appear in the log then.

davilla Wrote:Patches welcome

:-P If I was to do anything it would probably be towards an x86_64 build for snow leopard only. :-) I wonder if that would improve performance and/or solve problems and thus be worth doing...

davilla Wrote:dtp is demuxer timestamp, pts is present timestamp. h.264 can have out of display order demux packets. So if you were to look at dts, pts going into decoder, pts would be out of order but coming out, then dts would be our of order. In other words, ignore dts, pts is the important one.

EDIT: looks like this video is 25 fps, that's 1/25 = 0.04 ms per frame which is the 40000 delta in pts.

Well, to reiterate the visual symptoms we're seeing. (I'm seeing anyway); the video is playing and it looks like all the frames are playing in the right order. :-) It's just playing slowly. that is, all frames are shown, but too slowly, at about 10fps, so the video lags behind the audio, which plays normally until, presumably, the difference becomes too great (possibly caused by trying to read from too-distant parts of the stream at the same time?)

Rachel Wrote:Well, to reiterate the visual symptoms we're seeing. (I'm seeing anyway); the video is playing and it looks like all the frames are playing in the right order. :-) It's just playing slowly. that is, all frames are shown, but too slowly, at about 10fps, so the video lags behind the audio, which plays normally until, presumably, the difference becomes too great (possibly caused by trying to read from too-distant parts of the stream at the same time?)

I wouldn't say it is play "slowly"...I believe it is dropping so many frames that it is falling behind the audio.

On a side note...I just created 2 more sources (h.264 "2012" & VC-1 "The Crazies") I'm going to play them without transcoding them first. Then this weekend I will transcode based on MediaInfo and see if I run into the same issues.

OK...Both are .mkv Sources:

The Crazies -


This VC-1 plays like crap in XBMC regardless of VDA or not. But it seemed to play fine in Movist within OS.

2012


This source played fine as long as VDA was turned off. Pic above shows with VDA turned on.

Next, I will be transcoding VC-1 to x.264 .mkv and see how that will play.

Rachel Wrote::-P If I was to do anything it would probably be towards an x86_64 build for snow leopard only. :-) I wonder if that would improve performance and/or solve problems and thus be worth doing...

about +10 percent. not worth it as it's not just building xbmc x86_64 but every lib and depends. Probably take a week or more to sort out and you would still have an issue with SDL.

davilla Wrote:about +10 percent. not worth it as it's not just building xbmc x86_64 but every lib and depends. Probably take a week or more to sort out and you would still have an issue with SDL.

Heh, actually given software ff-h264 playback works fine on everything but is *borderline* fast enough on this hardware, 10% is not necessarily to be sniffed at. It could tip me over to not needing VDADecoder to work properly. I may have a play, but I don't expect it'll be trivial. Of course xbmc for x86_64 runs fine on Linux so I expect if there are any hard code problems they're going to be in the osx-specific portion of the codebase. :-)

Rachel Wrote:Heh, actually given software ff-h264 playback works fine on everything but is *borderline* fast enough on this hardware, 10% is not necessarily to be sniffed at. It could tip me over to not needing VDADecoder to work properly. I may have a play, but I don't expect it'll be trivial. Of course xbmc for x86_64 runs fine on Linux so I expect if there are any hard code problems they're going to be in the osx-specific portion of the codebase. :-)

It's not a code problem, it's a build system problem. And plus the fact we require SDL and SDL does not work under 10.6.x (86_64)

[/threadjack]