• 1
  • 6
  • 7
  • 8(current)
  • 9
  • 10
  • 34
[LINUX] Problems compiling crystalhd branch
dan1son Wrote:Wow Davilla, those changes made the GUI super smooth.

I turned off vsync inside the xbmc interface and left it on in the nvidia-settings and so far I haven't noticed the oddities.

The interface is uncomparably smoother than it is on the ATV OS. It's quite wonderful with this setup. Thanks for forcing me to go through the long trouble of putting Ubuntu on this box and for the crystalHD support. Consider me BLOWN AWAY!

1080p/24hz playback is amazing on this thing.

Scratch that vsync fix... still having same issue with odd jitters and black bars at the top occasionally.

Dan1son, or any other for that matter, what did you do make the ATV spit out a 1080p/24hz signal? Sorry for being a n00b...
Reply
pouldam Wrote:Dan1son, or any other for that matter, what did you do make the ATV spit out a 1080p/24hz signal? Sorry for being a n00b...
Me, I had to do nothing at all. As soon as the NVidia drivers were installed the Screen Resolution control pane correctly identified the refresh rates of my TV 24, 25, 50 and 60hz. XBMC switches between then seamlessly. Ubuntu 8.04 btw.
Reply
pouldam Wrote:Dan1son, or any other for that matter, what did you do make the ATV spit out a 1080p/24hz signal? Sorry for being a n00b...

Well my blown away statement was probably a little premature, there are still some pretty significant playback glitches that I've talked about in this and the other thread. Although I'm still blown away with the potential and am certain everything will get settled.

I ended up putting modelines in my xorg.conf file for 1080p/24, 1080p/23.976 ,1080p/60, and 1080p/59.94 since my TV only supports those. My TV apparently gives conflicting EDID stats and I was getting mismatched refresh rates between nvidia-settings/what my TV claimed and xbmc. Forcing specific resolutions/refresh rates seemed to clear all of that up and XBMC now properly changes between them. I doubt this is specifically if you're getting proper resolution/refresh rates in your xorg log file.

I found the info for proper modelines in one of the VDPAU threads on here.
Reply
csbook Wrote:
Code:
--- ../../bcm70012_linux_01142009/linux_release_generic/Driver/bc_link_misc.c   2009-01-14 15:00:45.000000000 -0500
+++ bc_link_misc.c      2009-12-02 08:02:08.000000000 -0500
@@ -681,6 +681,7 @@

                bc_link_wait_on_event(&ioq->event, (ioq->count>0), 1000, rc, 0);
                if(rc == 0){
+                        mpc_lock_irq(&ioq->lock,flags);
                        break;
                }else if(rc == -EINTR){
                        MPCLOG(MPCLOG_INFO,"Cancelling fetch wait\n");

I'm not actually getting the same driver errors that I sent before. Instead of getting the timeout returned from the driver, I now get a different timeout message from the xbmc code:

Code:
#
10:02:47 T:2729888656 M: 68497408   DEBUG: DVDVideoCodecCrystalHD: Timeout in CDVDVideoCodecCrystalHD::Decode. ret: 0x00000002 pData: (nil)
#
10:02:47 T:2729888656 M: 68497408   DEBUG: DVDVideoCodecCrystalHD: Timeout in CDVDVideoCodecCrystalHD::Decode. ret: 0x00000002 pData: (nil)
#
10:02:47 T:2729888656 M: 68497408   DEBUG: DVDVideoCodecCrystalHD: Timeout in CDVDVideoCodecCrystalHD::Decode. ret: 0x00000002 pData: (nil)

http://pastebin.com/m2f44876b
Reply
csbook Wrote:I'm not actually getting the same driver errors that I sent before. Instead of getting the timeout returned from the driver, I now get a different timeout message from the xbmc code:

Try this;

Code:
    while( (ioq->count == 0) && (count) ){
        mpc_unlock_irq(&ioq->lock,flags);

        bc_link_wait_on_event(&ioq->event, (ioq->count>0), 1000, rc, 0);
        if (rc == 0) {
            goto out;
        } else if(rc == -EINTR) {
            MPCLOG(MPCLOG_INFO,"Cancelling fetch wait\n");
            *sig_pend = 1;
            return tmp;
        }
        mpc_lock_irq(&ioq->lock,flags);
        count--;
    }
    mpc_unlock_irq(&ioq->lock,flags);

out:
    return bc_link_dioq_fetch(ioq);
Reply
davilla Wrote:Try this;

Code:
    while( (ioq->count == 0) && (count) ){
        mpc_unlock_irq(&ioq->lock,flags);

        bc_link_wait_on_event(&ioq->event, (ioq->count>0), 1000, rc, 0);
        if (rc == 0) {
            goto out;
        } else if(rc == -EINTR) {
            MPCLOG(MPCLOG_INFO,"Cancelling fetch wait\n");
            *sig_pend = 1;
            return tmp;
        }
        mpc_lock_irq(&ioq->lock,flags);
        count--;
    }
    mpc_unlock_irq(&ioq->lock,flags);

out:
    return bc_link_dioq_fetch(ioq);

I had tried something like this before to skip the extra lock, and with this I still get the same error. It actually turns out that the error is more to do with the file I'm playing, not 9.0.4 or my patched driver.

So now I have:
- One video that plays perfectly (yay!)
- One that gives the timeout errors from that log and essentially 1 frame per minute
- One that shows diagonal coloured blocks with the actual picture slightly visible in a few of the blocks. I think this is similar to what has already been reported.
- One that doesn't start at all (log of the last few attempts to play this at http://pastebin.com/m2556000a).
Reply
csbook Wrote:I had tried something like this before to skip the extra lock, and with this I still get the same error. It actually turns out that the error is more to do with the file I'm playing, not 9.0.4 or my patched driver.

So now I have:
- One video that plays perfectly (yay!)
- One that gives the timeout errors from that log and essentially 1 frame per minute
- One that shows diagonal coloured blocks with the actual picture slightly visible in a few of the blocks. I think this is similar to what has already been reported.
- One that doesn't start at all (log of the last few attempts to play this at http://pastebin.com/m2556000a).

All hell breaking loose Smile Use mediainfo to check for differences as to the various videos that play and don't play.
Reply
mediainfo dumps:

> One video that plays perfectly (yay!)
http://pastebin.com/m79d4bfa4

> One that gives the timeout errors from that log and essentially 1 frame per minute
http://pastebin.com/m614ee3a4

> One that shows diagonal coloured blocks with the actual picture slightly visible in a few of the blocks. I think this is similar to what has already been reported.
http://pastebin.com/m1a8accde

> One that doesn't start at all (log of the last few attempts to play this at http://pastebin.com/m2556000a).
http://pastebin.com/m4bad1a5c
Reply
Broadcom has posted "official" windows drivers, see http://www.broadcom.com/support/crystal_hd/

It's an .exe install that checks for an installed card before completing the install. Grrr. I just hate these types. My cards are in AppleTVs and MacMini right now and don't have one in the Zotac where I could install and check the firmware. If anyone running under windows can do this, I'd be interested in the firmware md5 checksum. Note that these windows drivers will be seen by the new adobe flash and you should get accelerated flash playback with the broadcom crystal hd card (under Windows).
Reply
davilla Wrote:Broadcom has posted "official" windows drivers, see http://www.broadcom.com/support/crystal_hd/

It's an .exe install that checks for an installed card before completing the install. Grrr. I just hate these types. My cards are in AppleTVs and MacMini right now and don't have one in the Zotac where I could install and check the firmware. If anyone running under windows can do this, I'd be interested in the firmware md5 checksum. Note that these windows drivers will be seen by the new adobe flash and you should get accelerated flash playback with the broadcom crystal hd card (under Windows).

What's this Windows you speak of?
Reply
Warning, R25355's merge from trunk broke something bad. Crash and burn until I can fix it.

EDIT: fixed in R25356 Smile
Reply
Has anyone tried to run windows xp on the appleTV?

(just curious (a))
Reply
davilla Wrote:It's an .exe install that checks for an installed card before completing the install. Grrr. I just hate these types. ... If anyone running under windows can do this, I'd be interested in the firmware md5 checksum.

MD5 of bcmFilePlayFw.bin Version: 2.60.34.0 is:
358334f95b44079cb8492d30b36c261c

FYI, when you run an EXE or MSI installer, it usually extracts the contents to "Local Settings\Temp\"

This one put another msi installer in that folder, so I had to copy the contents to my own folder, c:\broadcomdriver, before closing the installer.

I then used the command
Code:
msiexec /a "Broadcom CrystalHD Decoder.msi" /qb TARGETDIR=c:\BroadcomMSIContents

I don't have the card yet, but I think this worked fine.

This left me with a folder with a whole lot of stuff in it, but most importantly, in the
Code:
c:\BroadcomMSIContents\program files\Broadcom\Broadcom CrystalHD Decoder
folder, I have the following:
(all dated 8/14/2009)
Code:
# Broadcom WDM Driver for 7001X series Controller. (Version:2.36.0.0)
## brcmhd32.inf
## brcmhd32.sys
## brcmhd32.cat
# Driver Interface Library (bcmDIL.dll) - (Version:2.37.0)
# DirectShow Filter (bcmDFilter_ns.dll) - (Version:2.57.0)
# Firmware file (bcmFilePlayFw.bin)  - (Version: 2.60.34.0)

... so there is a DirectShow filter Big Grin

What does that mean for tiben20's DS branch? If we use his DSPlayer with that filter, do we need to compile the CrystalHD branch at all on Windows?

-Wes

PS. now if I could just do that type of stuff in Linux, I would be much more useful
Reply
Jaken Wrote:Has anyone tried to run windows xp on the appleTV?

(just curious (a))

LOL, that would need some help from me. The AppleTV runs a pure EFI bootloader, no BIOS emulation. But the Nvidia VBIOS is there and can be init'ed. So add a simple BIOS emulation layer (hint SeaBios), init VBIOS and Windows should boot. That's the theory and I have a slow burn project working on that.
Reply
waldo22 Wrote:MD5 of bcmFilePlayFw.bin Version: 2.60.34.0 is:
358334f95b44079cb8492d30b36c261c

Cool, thanks for the info. This matches the latest firmware that we have internally. So no firmware change to support FLASH, good.

Yes, there is a DirectShow filter, don't think you would need CrystalHD branch as the decoding is handled by the DirectShow filter. Not sure how that all works, tiben20 would know. I think all he needs to know are the DirectShow filter details and it should just work. Bluray demuxing might/might not work, CrystalHD branch is using the demuxer from the xdmx branch to demux m2ts files.
Reply
  • 1
  • 6
  • 7
  • 8(current)
  • 9
  • 10
  • 34

Logout Mark Read Team Forum Stats Members Help
[LINUX] Problems compiling crystalhd branch2