• 1
  • 2(current)
  • 3
  • 4
  • 5
  • 19
[MAC] VDADecoder performance over HDMI on new Mac Mini?
#16
Quote:If you understand the following two lines, you can run it to automate
the installation of the ports in the above order:

sudo bash
perl -ne 'print `port install $1` if /^ \$ sudo port install (.*)$/;' README.osx

Haha, by the time I saw that I'd automated it a different way. :-)
#17
Completed the build, ran it on one of the problem files. This is the resulting xbmc.log.

http://xbmc.pastebin.com/LY96vZqh
#18
couple of things I noticed with my untutored eye:

Is this being called once per frame? Because in the logs it looks like we're getting about 21 such calls a second; which is slower than the *desired* frame rate but still faster than the reported and evident frame rate actually displayed (which is more like 10-13fps).

Also, the numbers don't always increment. I happened to notice:

Code:
13:34:47 T:2960351232 M:603025408  NOTICE: GetPicture - VDADecoderDecode dts(25280000.000000), pts(25400000.000000)
13:34:47 T:2960351232 M:603025408  NOTICE: GetPicture - VDADecoderDecode dts(25440000.000000), pts(25440000.000000)
13:34:47 T:2960351232 M:603025408  NOTICE: GetPicture - VDADecoderDecode dts(25480000.000000), pts(25480000.000000)
13:34:47 T:2960351232 M:603025408  NOTICE: GetPicture - VDADecoderDecode dts(25400000.000000), pts(25520000.000000)
13:34:48 T:2960351232 M:603025408  NOTICE: GetPicture - VDADecoderDecode dts(25560000.000000), pts(25560000.000000)

Where dts goes *down* from 25480000 to 25400000. I wouldn't be surprised if it appears elsewhere too, that one I just happened to spot. :-)

edit: yes it definitely happens quite a lot; three times in this snippet alone:

Code:
13:34:49 T:2960351232 M:602828800  NOTICE: GetPicture - VDADecoderDecode dts(27000000.000000), pts(27000000.000000)
13:34:49 T:2960351232 M:602828800  NOTICE: GetPicture - VDADecoderDecode dts(27040000.000000), pts(27040000.000000)
13:34:49 T:2960351232 M:602828800  NOTICE: GetPicture - VDADecoderDecode dts(26960000.000000), pts(27080000.000000)
13:34:49 T:2960351232 M:602828800  NOTICE: GetPicture - VDADecoderDecode dts(27120000.000000), pts(27120000.000000)
13:34:49 T:2960351232 M:602828800  NOTICE: GetPicture - VDADecoderDecode dts(27160000.000000), pts(27160000.000000)
13:34:50 T:2960351232 M:602755072  NOTICE: GetPicture - VDADecoderDecode dts(27080000.000000), pts(27200000.000000)
13:34:50 T:2960351232 M:602755072  NOTICE: GetPicture - VDADecoderDecode dts(27240000.000000), pts(27240000.000000)
13:34:50 T:2960351232 M:602755072  NOTICE: GetPicture - VDADecoderDecode dts(27280000.000000), pts(27280000.000000)
13:34:50 T:2960351232 M:602755072  NOTICE: GetPicture - VDADecoderDecode dts(27200000.000000), pts(27320000.000000)
13:34:50 T:2960351232 M:602755072  NOTICE: GetPicture - VDADecoderDecode dts(27320000.000000), pts(27360000.000000)

... although I have to say, what it looks like to me is two threads working in parallel, being a dual-core machine; so is it actually an error? Might be I suppose if they end up delivering complete frames to output in the wrong order...
#19
Rachel Wrote:Ugh, I don't like these instructions. That symlinking is breaking my system for building anything else. I don't have *so* many macs that I want to devote one to just building xbmc...

And it seems to be just for keeping compatibility with 10.4. I'm not even interested in that; not like I'm building for distribution. I suppose it's because the AppleTV OS is still 10.4-based iirc.

Patches welcome Smile
#20
Rachel Wrote:couple of things I noticed with my untutored eye:

Is this being called once per frame? Because in the logs it looks like we're getting about 21 such calls a second; which is slower than the *desired* frame rate but still faster than the reported and evident frame rate actually displayed (which is more like 10-13fps).

Also, the numbers don't always increment. I happened to notice:

Code:
13:34:47 T:2960351232 M:603025408  NOTICE: GetPicture - VDADecoderDecode dts(25280000.000000), pts(25400000.000000)
13:34:47 T:2960351232 M:603025408  NOTICE: GetPicture - VDADecoderDecode dts(25440000.000000), pts(25440000.000000)
13:34:47 T:2960351232 M:603025408  NOTICE: GetPicture - VDADecoderDecode dts(25480000.000000), pts(25480000.000000)
13:34:47 T:2960351232 M:603025408  NOTICE: GetPicture - VDADecoderDecode dts(25400000.000000), pts(25520000.000000)
13:34:48 T:2960351232 M:603025408  NOTICE: GetPicture - VDADecoderDecode dts(25560000.000000), pts(25560000.000000)

Where dts goes *down* from 25480000 to 25400000. I wouldn't be surprised if it appears elsewhere too, that one I just happened to spot. :-)

edit: yes it definitely happens quite a lot; three times in this snippet alone:

Code:
13:34:49 T:2960351232 M:602828800  NOTICE: GetPicture - VDADecoderDecode dts(27000000.000000), pts(27000000.000000)
13:34:49 T:2960351232 M:602828800  NOTICE: GetPicture - VDADecoderDecode dts(27040000.000000), pts(27040000.000000)
13:34:49 T:2960351232 M:602828800  NOTICE: GetPicture - VDADecoderDecode dts(26960000.000000), pts(27080000.000000)
13:34:49 T:2960351232 M:602828800  NOTICE: GetPicture - VDADecoderDecode dts(27120000.000000), pts(27120000.000000)
13:34:49 T:2960351232 M:602828800  NOTICE: GetPicture - VDADecoderDecode dts(27160000.000000), pts(27160000.000000)
13:34:50 T:2960351232 M:602755072  NOTICE: GetPicture - VDADecoderDecode dts(27080000.000000), pts(27200000.000000)
13:34:50 T:2960351232 M:602755072  NOTICE: GetPicture - VDADecoderDecode dts(27240000.000000), pts(27240000.000000)
13:34:50 T:2960351232 M:602755072  NOTICE: GetPicture - VDADecoderDecode dts(27280000.000000), pts(27280000.000000)
13:34:50 T:2960351232 M:602755072  NOTICE: GetPicture - VDADecoderDecode dts(27200000.000000), pts(27320000.000000)
13:34:50 T:2960351232 M:602755072  NOTICE: GetPicture - VDADecoderDecode dts(27320000.000000), pts(27360000.000000)

... although I have to say, what it looks like to me is two threads working in parallel, being a dual-core machine; so is it actually an error? Might be I suppose if they end up delivering complete frames to output in the wrong order...

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.
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.
#21
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. :-)
#22
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.
#23
davilla Wrote:Patches welcome Smile

:-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...
#24
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?)
#25
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.
#26
OK...Both are .mkv Sources:

The Crazies -
Code:
*** MediaInfo Mac // Plain text file report
2010-07-09 14:03:17 -0500
Information for File: The Crazies.mkv

General / Container Stream # 1
    Total Video Streams for this File -> 1
    Total Audio Streams for this File -> 1
    Video Codecs Used -> VC-1
    Audio Codecs Used -> AC3
    File Format -> Matroska
    Play Time -> 1h 40mn
    Total File Size -> 18.0 GiB
    Total Stream BitRate -> 25.6 Mbps
    Encoded with -> mkvmerge v4.1.1 ('Bouncin' Back') built on Jul  4 2010 00:14:11
    Encoding Library -> libebml v1.0.0 + libmatroska v1.0.0
Video Stream # 1
    Codec (Human Name) -> VC-1
    Codec (FourCC) -> WVC1
    Codec Profile -> AP@L3
    Frame Width -> 1 920 pixels
    Frame Height -> 1 080 pixels
    Frame Rate -> 23.976 fps
    Total Frames -> 144930
    Display Aspect Ratio -> 16:9
    Scan Type -> Progressive
    Colorimetry -> 4:2:0
    QF (like Gordian Knot) -> 0.492
    Video Stream Length -> 1h 40mn 44s 795ms
    Video Stream BitRate -> 24.4 Mbps
    Bit Depth -> 8 bits
    Video Stream Size -> 17.2 GiB (96%)
Audio Stream # 1
    Codec -> AC-3
    Codec (FourCC) -> A_AC3
    Audio Stream Length -> 1h 40mn 44s 800ms
    Audio Stream BitRate -> 640 Kbps
    Audio Stream BitRate Mode -> CBR
    Number of Audio Channels -> 6
    Audio Channel's Positions -> Front: L C R, Side: L R, LFE
    Sampling Rate -> 48.0 KHz
    Audio Stream Size -> 461 MiB (3%)
Image

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

2012
Code:
*** MediaInfo Mac // Plain text file report
2010-07-09 14:03:58 -0500
Information for File: 2012.mkv

General / Container Stream # 1
    Total Video Streams for this File -> 1
    Total Audio Streams for this File -> 1
    Video Codecs Used -> AVC
    Audio Codecs Used -> DTS-HD
    File Format -> Matroska
    Play Time -> 2h 37mn
    Total File Size -> 28.8 GiB
    Total Stream BitRate -> 26.1 Mbps
    Encoded with -> mkvmerge v4.1.1 ('Bouncin' Back') built on Jul  4 2010 00:14:11
    Encoding Library -> libebml v1.0.0 + libmatroska v1.0.0
Video Stream # 1
    Codec (Human Name) -> AVC
    Codec (FourCC) -> V_MPEG4/ISO/AVC
    Codec Profile -> [email protected]
    Frame Width -> 1 920 pixels
    Frame Height -> 1 080 pixels
    Frame Rate -> 23.976 fps
    Total Frames -> 227040
    Display Aspect Ratio -> 16:9
    Scan Type -> Progressive
    Colorimetry -> 4:2:0
    Codec Settings (Summary) -> CABAC / 4 Ref Frames
    Codec Settings (CABAC) -> Yes
    Video Stream Length -> 2h 37mn 49s 469ms
    Bit Depth -> 8 bits
Audio Stream # 1
    Codec -> DTS
    Codec (FourCC) -> A_DTS
    Audio Stream Length -> 2h 37mn 49s 462ms
    Audio Stream BitRate Mode -> VBR
    Number of Audio Channels -> 6
    Audio Channel's Positions -> Front: L C R, Side: L R, LFE
    Sampling Rate -> 48.0 KHz
    Bit Depth -> 24 bits
Image

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.
#27
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.
#28
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. :-)
#29
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) Smile
#30
[/threadjack]
  • 1
  • 2(current)
  • 3
  • 4
  • 5
  • 19

Logout Mark Read Team Forum Stats Members Help
[MAC] VDADecoder performance over HDMI on new Mac Mini?0