On 10 May, this message from Rog�rio Brito echoed through cyberspace: > > Well, I'm not having luck getting my iBook 600MHz playing DVDs > in a decent way.
I think you're quite lucky with what you get ;-) > I have woody installed in this iBook and, with xine (0.9.8), I > get a reasonable playback, with around 15% of dropped frames > and with ugly interlaced frames. Enabling the onefield_xv > deinterlace method works and makes the DVD more or less > watchable, though during some stages, I can see artifacts on > the image due to excessive frames being dropped. This is probably as good as it gets right now. I don't think you can do better without using the r128's hardware accelerated iDCT and MC. > I can't get vlc 0.3.0 working well here, because there are > issues with the sound (probably due to endianness problems, > although I'm not really sure). I already tried telling vlc all > different possibilities for endianness or signedness of the > output, but I don't know if the menu is functional, as I saw > little changes when I played with that option. Enabling the > diagnostics seems to suggest that not all frames are played. vlc has had sound problems for quite a while. Here's what Jack Howarth said re. vlc's audio settings: [quote] > On my debian sid machine running benh's current kernel and > alsa 0.9beta12 I was able to get audio working under alsa, esd and > oss. You have to select 3, the 16 bit signed big endian output from > the audio preference section for that to work. I notified Samuel > Hocevar and he is going to try to do something about the default, 0, > native endian code so that it picks up 16 bit big endian on ppc. > The audio problems with bursts of static aren't ppc specific. > There has been and still is a audio starvation problem in vlc > but according to Sam no one has the guts and/or time to rip into > that code yet. [ end quote] I haven't tried this myself. > The output of mplayer shows the amount of time it spends > decoding the frames, showing the frames and dealing with > audio. I notice that the percentage of time it spends with > video output is quite high in comparison to my Celeron 466MHz > (I'll make further tests). That's essentially because of MTRR on i386. I wouldn't know hard numbers to compare, but at least subjectivly, MTRR helps a lot for the copy to VRAM of the video out data. > I tried installing Michel's XFree 4.2.0 binaries and they seem > to make xine work better, dropping around 6 frames less than > with woody's X 4.1.0.1. > > On the other hand, DRI (which, I heard, is supposed to enable > DMA transfers to video) wasn't enabled with XFree 4.2.0 [snip] Note that for DMA you need DRI, which needs large amounts of VRAM. So you may only be able to use that in 16-bit mode. I'm usually running in 32-bit mode :( > I have already tried many things that I could think of, but I > am starting to think that the possibilities are almost > exhausted. :-( You've got it :-) No, there are a few things that still can be done: - get ATI to open the specs for iDCT and MC in hardware. Won't happen anytime soon. - optimize a few of the more processor-intensive parts of the algorithms with handcoded ASM. Good luck... - use DMA: that should be doable with the right pieces of code. Cheers Michel ------------------------------------------------------------------------- Michel Lanners | " Read Philosophy. Study Art. 23, Rue Paul Henkes | Ask Questions. Make Mistakes. L-1710 Luxembourg | email [EMAIL PROTECTED] | http://www.cpu.lu/~mlan | Learn Always. " -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
