Kodi Community Forum
[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)

Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34


- davilla - 2009-12-09

padukes Wrote:I didn't :-( Can you give me a pointer (no pun intended) on where to look?

Thanks!
P

http://forum.xbmc.org/showpost.php?p=452372&postcount=110


- davilla - 2009-12-09

TeknoJnky Wrote:a couple quickie questions

- is it considered 'safe' to svn up, from say 'svn co -r 25101' on the crystalhd branch ? assuming there aren't any issues with latest rev at that point in time. IE Will it break the norco (or other) drivers ?

- now that there are a few different driver releases floating around, is there a 'better' or more preferred one than the norco?

- I wonder why the exact revision wasn't listed in the system info (said something about alpha 2 if I remember)

Asking now so I don't screw everything up if/when I get what I got working...

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:



Is there anything I can do to help identify the issues?

Thanks again!
P

pastebin the output of dmesg and xbmc.log, you know the usual stuff Smile


- 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
22:00:23 T:2877393808 M: 91586560   DEBUG: CDVDPlayerAudio - CDVDMsg::GENERAL_DELAY(160000.000000)
22:00:23 T:2896104336 M: 91394048   DEBUG: DVDVideoCodecCrystalHD: Timeout in CDVDVideoCodecCrystalHD::Decode. ret: 0x00000002 pData: (nil)
22:00:23 T:2904497040 M: 91332608   DEBUG: CrystalHD: Added a new Buffer (count=0). Size: 1988
22:00:23 T:2896104336 M: 91332608  NOTICE:  fps: 25.000000, pwidth: 1920, pheight: 1080, dwidth: 1920, dheight: 1080
22:00:23 T:2896104336 M: 91332608   DEBUG: OutputPicture - change configuration. 1920x1080. framerate: 25.00
22:00:23 T:2896104336 M: 91332608  NOTICE: Display resolution DESKTOP : 1280x720 @ 65.00 - Full Screen (12)
22:00:23 T:3051579232 M: 91209728   DEBUG: Activating window ID: 12005
22:00:23 T:3051579232 M: 91209728   DEBUG: Checking if window ID 12005 is locked.
22:00:23 T:3051579232 M: 91209728   DEBUG: ------ Window Deinit (Home.xml) ------
22:00:23 T:3051579232 M: 91189248   DEBUG: ------ Window Init (VideoFullScreen.xml) ------
22:00:23 T:3051579232 M: 91189248    INFO: Loading skin file: VideoFullScreen.xml
22:00:23 T:3051579232 M: 90763264   DEBUG: Load VideoFullScreen.xml: 34.58ms
22:00:23 T:3051579232 M: 90763264   DEBUG: Alloc resources: 34.93ms (34.93 ms skin load)
22:00:23 T:3051579232 M: 90763264    INFO: Loading skin file: VideoOSD.xml
22:00:23 T:2877393808 M: 90431488   DEBUG: CDVDPlayerAudio - CDVDMsg::GENERAL_RESYNC(160000.000000, 0)
22:00:23 T:3051579232 M: 90460160   DEBUG: Load VideoOSD.xml: 36.92ms

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.

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

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 Smile When streaming m2ts over smb, if you are not wired, you will die Smile 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.

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?

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 ]

RTL8139::registerEEPROM: 0000 0000 0000 0000 0000 0000 0000 0000
Jettisoning kernel linker.
Resetting IOCatalogue.
com_apple_driver_RTL8139: Ethernet address 00:24:36:ed:b7:8f
netsmb_dev: loaded
BroadcomMediaPC:Confusedtart
BroadcomMediaPC::bsd_create_device
BroadcomMediaPC::bsd_create_node
BroadcomMediaPC::bsd_register_node
allocated 18 elem
Starting BCM70012 Device
clock is moving to 175 with n 35 with vco_mg 2
CStopping BCM70012 Device
BroadcomMediaPC: Found HW and started driver SW.
Opening new user[0] handle
Starting BCM70012 Device
clock is moving to 175 with n 35 with vco_mg 2
CInitializing Dio pool 10 1024 3058 0x1b08c74
Firmware Downloaded Successfully
DelQAddr:4fdc8 RelQAddr:4fecc
App PIB:0 0 420 2 18 2d0 500 0 0 0
*ERR*:/Volumes/Storage/XBMC development/crystalhd/broadcom/driver/darwin/bc_link_cmds.cpp:467: RX->Invalid Arg 0 0
list_index:1 rx[1] Y:10 UV:10 Int:2900 YDnSz:0 UVDnSz:0
list_index:0 rx[2] Y:2 UV:2 Int:28 YDnSz:0 UVDnSz:0
list_index:0 rx[3] Y:2 UV:2 Int:28 YDnSz:0 UVDnSz:0
list_index:1 rx[4] Y:10 UV:10 Int:2800 YDnSz:0 UVDnSz:0
list_index:0 rx[5] Y:2 UV:2 Int:28 YDnSz:0 UVDnSz:0

Anybody working on a Broadcom driver for Darwin Big Grin ?


- 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:

Anybody working on a Broadcom driver for Darwin Big Grin ?

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.

Remember to enabled pbo's in settings -> video -> playback... It does make a difference.

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... Smile


- 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).

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... Smile

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. Smile