[LINUX] Problems compiling crystalhd branch - Printable Version +- Kodi Community Forum (https://forum.kodi.tv) +-- Forum: Development (https://forum.kodi.tv/forumdisplay.php?fid=32) +--- Forum: Kodi Application (https://forum.kodi.tv/forumdisplay.php?fid=93) +--- Thread: [LINUX] Problems compiling crystalhd branch (/showthread.php?tid=62708) |
- davilla - 2009-12-09 padukes Wrote:I didn't :-( Can you give me a pointer (no pun intended) on where to look? http://forum.xbmc.org/showpost.php?p=452372&postcount=110 - davilla - 2009-12-09 TeknoJnky Wrote:a couple quickie questions eh ? crystalhd branch is compatible with the various driver/libs floating around. Both Linux releases look similar with the Broadcom Windows release containing the most recent firmware. exact revision (svn version) gets picked up when you do the configure. xbmc/utils/GUIInfoManager.h contains the "xbmc version", this follow svn trunk. - padukes - 2009-12-09 davilla Wrote:http://forum.xbmc.org/showpost.php?p=452372&postcount=110 Thanks Davilla! XBMC doesn't crash for me any more but most of my videos flash for a second and then return to the menu. The ones that play take 100% of the CPU which suggests to me that they're not using the crystalhd. I also get this error in the kern.log which I think you previously said isn't an issue: Quote:Dec 8 20:51:20 mini kernel: [1430261.648249] *ERR*:/usr/src/modules/bcm70012kmod/mpclink/bc_link_cmds.c:464: RX->Invalid Arg (null) 0 Is there anything I can do to help identify the issues? Thanks again! P - davilla - 2009-12-09 padukes Wrote:Thanks Davilla! XBMC doesn't crash for me any more but most of my videos flash for a second and then return to the menu. The ones that play take 100% of the CPU which suggests to me that they're not using the crystalhd. I also get this error in the kern.log which I think you previously said isn't an issue: pastebin the output of dmesg and xbmc.log, you know the usual stuff - TeknoJnky - 2009-12-09 ok I didn't try very hard with hdmi audio, but using the analog audio seems to work. I'm not getting the hardware decode, but from what I can tell the bcm is loading and getting time outs. http://pastebin.com/m13d93952 Code: 22:00:23 T:2877393808 M: 91639808 DEBUG: CDVDPlayerAudio:: Discontinuty - was:333938.774000, should be:20.044480, error:-333918.729520 still working on getting the remote to work also, last I thing I tried was evinyatars eventclient but I don't remember what exactly other stuff I had mangled up before that (lack of sleep). - davilla - 2009-12-09 TeknoJnky Wrote:ok I didn't try very hard with hdmi audio, but using the analog audio seems to work. smb://HALO-6/HD/KILLBILL1_US/BDMV/STREAM/00001.m2ts Your xbmc.log says different, crystalhd is opened, it's decoding but I see drops and skips. Going for gusto right away I see When streaming m2ts over smb, if you are not wired, you will die The data rates from a raw (but decrypted) bluray disks are huge and almost saturate 100T wired networks. Start simple ( 720p content ) then work your way up. - TeknoJnky - 2009-12-09 hmm ok, it is an (old) wired fast ethernet switch to the tv.. i'll have to scrounge up a long cat5/6 to hook up the atv to the gbit switch regular xvid avi or even mkv don't seem to be any less cpu than normal tho, and heres a log from a 720p I had originally made for the osx/atv regular build. http://pastebin.com/m263fcc33 seemed to play ok but cpu a little higher than I expect? cpu ~25% cpu-xbmc ~18.25% I think I was running 720 resolution on the previous log, switched to 1080 for this one. edit: even if my fast ethernet is saturated with raw bluray, my cpu should be way less than 100 % right? - davilla - 2009-12-09 TeknoJnky Wrote:regular xvid avi or even mkv don't seem to be any less cpu than normal tho, and heres a log from a 720p I had originally made for the osx/atv regular build. If you see, "CrystalHD: Format Change Detected" in the log, that's the first thing out of the decoder, the detected format. There's no way any 720p can be decoded on the AppleTV with 25 percent CPU by software only even with skiploopfilter set at 48. What would you expect? Zero ? This is not like the Nvidia chipsets with VDPAU, there, the demux frames are passed to the GPU and it decodes to GPU memory. There's no copy back of decoded frames to CPU space. With Broadcom, the demux frames are passed to the crystalhd card, decoded, then the frames are DMA'ed back to the CPU side where they are then copied, then the copy is DMA'ed to the GPU side. See the difference ? There will be a certain about of overhead for 720p and 1080p but that overhead will not change with encoded profiles or bitrates. So 720p, L3.1, L4.1 or L5.1, same amount of overhead. You can saturate the CPU many ways, thrashing around trying to seek to keep up with the excepted pts is one way. - davilla - 2009-12-09 R25387, R25490 and R25491 will see some interesting changes. Flashes of black, strange tears and other bad behavior should be gone. The initial hacks are now gone and we are passing decoded frames from decoder up to renderer the proper way. CPU will go up a little due to the additional copy of the decoded frame but it's the only way right now to eliminated the artifacts. Remember to enabled pbo's in settings -> video -> playback... It does make a difference. - andrereis - 2009-12-09 davilla Wrote:Remember to enabled pbo's in settings -> video -> playback... It does make a difference.Davilla, can you default that setting to ON in the crystalhd branch? (and maybe revert it to off when it gets committed to trunk, if trunk requires so) - Erik - 2009-12-09 Development seems to be focused on Linux in case of Crystal HD support (great work btw !).. I just happen to stumble upon http://pastebin.com/m29f3261f. This page has the kernel output of an ATV running Darwin which appears to have BCM70012 support, the output ends with: Quote:[ the usual ATV boot up kernel messages ] Anybody working on a Broadcom driver for Darwin ? - davilla - 2009-12-09 Erik Wrote:This page has the kernel output of an ATV running Darwin which appears to have BCM70012 support, the output ends with: Yes, and development is not focused solely on Linux. Darwin kext and libs are up and running. Can't distribute them right now. The other thread mentions why. - dan1son - 2009-12-10 davilla Wrote:R25387, R25490 and R25491 will see some interesting changes. Flashes of black, strange tears and other bad behavior should be gone. The initial hacks are now gone and we are passing decoded frames from decoder up to renderer the proper way. CPU will go up a little due to the additional copy of the decoded frame but it's the only way right now to eliminated the artifacts. Umm... yeah you could say those changes helped. Playback is just about on par with my VDPAU box (Revo R1600) I just got. Has a few odd hickups occasionally on startup or after ff/jump, just sort of drops frames continuously until it feels like stopping (problem you mentioned was related to the crystalhd card decoding the metadata or some such). Other than that it is much improved. Very nice. As long as I don't play the killa sample this thing works great all the way to full 1080p. The ATV needs a bit more ram though... - davilla - 2009-12-10 dan1son Wrote:Umm... yeah you could say those changes helped. Playback is just about on par with my VDPAU box (Revo R1600) I just got. Has a few odd hickups occasionally on startup or after ff/jump, just sort of drops frames continuously until it feels like stopping (problem you mentioned was related to the crystalhd card decoding the metadata or some such). Section "Device" Identifier "Device0" Driver "nvidia" VendorName "NVIDIA Corporation" Option "RegistryDwords" "RMDisableRenderToSysmem=1" Option "DynamicTwinView" "false" EndSection RMDisableRenderToSysmem gives 64MB of ram back to the system. Older nvidia drivers might not support it. - dan1son - 2009-12-10 You sure know all the little tweaks. That definitely made jumping around the menus a bit snappier. Thanks. Amazing how modern and useful my ATV is all of a sudden. |