On May 12 2002, Michel Dänzer wrote:
> On Sun, 2002-05-12 at 14:34, Rogério Brito wrote:
> > I guess that Apple is making false claims about the iBook's
> > ability to play DVDs, since my complete collection of DVDs
> > (all 4 of them :-) ) show interlacing artifacts in the image,
> > even when playing under MacOS X. :-(
>
> Apple's DVD player is known for its lack of any deinterlacing.
> Shouldn't be hard to add...
Shouldn't be hard indeed. I just sent a patch for xine 0.9.9
that added one deinterlacing mode (linear blend) in plain C
(which makes it currently the only portable mode of
deinterlacing, apart from onefield_xv, which is terrible in
terms of image quality).
It is not useful for me with the iBook, but should be useful
for TiBook owners, if the G4s are faster than G3s with code
that is not Altivec enabled.
The actual code didn't take more than, say, 5 or 10 lines.
I can't see why Apple can't include something like this in
their next versions of DVD player. And, obviously, they have
the knowledge for making fast hand-coded assembly versions of
them.
> > All that I can say is that I feel cheated. :-(
>
> Well, the actual movies shouldn't be interlaced.
Well, I read that also in Ben's reply and got surprised, since
without exception all DVDs that I have seen to this day are
interlaced.
> Rumour has it that the current one in benh's tree is 2.2 except the
> version is wrong (somebody posted a patch to 'fix' the version number to
> linuxppc-dev), but if I were you I'd wait for confirmation from benh
> before relying on that. :)
Yes, I went to hunt that message and actually recompiled a new
kernel with the new version, but for some reason, I couldn't
make dri work with the X binaries from your site.
But now my mood is back to the conservative mode and I am
using a standard benh kernel. :-)
> > Perhaps the r128 module isn't being maintained?
>
> It is, kinda, by XFree86 and DRI. Both their CVS repositories have
> the 2.2 version, just nobody has updated the Linux kernel yet.
I see. I'm crossing my fingers for this update to happen
soon. :-)
> > What is the problem with publishing the interfaces for that? I
> > thought that ATI were an open-source friendly company. :-(
>
> They are IMHO. Every company seems to be afraid of releasing that
> kind of information, I have an idea why but people tell me there's
> no reason...
Could you say what could be the possible reasons for ATI to
not release the specifications? I'd be really interested to
know. I promise that I won't start a flamewar if I don't like
what I read. :-)
But how "closed" is ATI to specifying the interface to hw
accel of their chips? Perhaps an organized petition would help
here?
> I'm afraid you'll be disappointed. Seems it was only good for a real
> 'gain' as a hack on top of 4.1. Now that it's done (more :)
> correctly, a lot of cycles are still wasted waiting for the DMA
> transfer to complete.
Well, just using a new X helped performance a bit with xine. I
am hoping that DMA would help more. Any tiny bit would help.
And is the CPU stalled when the DMA transfer is being
performed? I'd say no, given my limited understanding of the
matter (otherwise, there would be not improvement in doing DMA
in the first place, right?)
If it is not, then even lowering the CPU consumption would
help, as there could be more processes decoding the video,
right? Or would the actual video output be slower, in general?
OTOH, perhaps the bottleneck being how the video operations
are slower may be the reason why mplayer's video out benchmark
with X 4.2 was so much higher than with X 4.1?
> Using an interrupt might help there.
I don't understand this, sorry. :-)
Thank you for your comments, Roger...
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Rogério Brito - [EMAIL PROTECTED] - http://www.ime.usp.br/~rbrito/
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
