xf86-video-intel Textured Video vs Video Overlay
km at mathcs.emory.edu
Sat Apr 21 18:10:12 PDT 2007
Today was the first chance I had to run the 2.0.0 code on my i915 2ghz
Pentium M processor Laptop. Until now I had been running on a dual core
I was surprised that running HD video through any of the media players
with the default Textured Video port was unusable. The frame drops were
staggering. The media player would use close to half the cpu, and the X
server would use all the rest (and needed more). This didn't show on the
dual core, because there were cycles to burn.
As it happens I've been generally flip flopping the Textured Video with
the Video Overlay initaliization on the mac, just to get brightness and
contrast control. Thats a fairly subtle need. On the single core laptop
Overlay its essential. Using the Overlay the X server uses negligible
cpu, and the media player has enough cpu to keep up.
I know the client can intelligently pick the port, but the reality is
that most of them don't (MythTV, xine, vlc). Actually, I think it would
be expecting a lot for them to know if CPU limitation, or the need for
dual monitors was more important.
I really think it would be a good idea in a future release to make the
default XV port an xorg.conf option.
Keith Packard wrote:
> On Sun, 2007-03-18 at 14:27 -0400, Ken Mandelberg wrote:
>> Tristan Willy wrote:
>>> As I understand it, the intel driver provides video overlay if the
>>> chip supports it (no overlay in the 965). This is the only XV port
>>> that will not experience tearing, at least until there's a way for the
>>> driver to get a cheap vertical retrace signal.
>> If the overlay code only has advantages compared with the textured code,
>> on the hardware that supports it (like the 945), I wonder why the
>> decision was made to make it the second adapter?
> Textured video can support multiple players, and the image is visible on
> multiple monitors. Plus, it (should) support the Composite extension.
> "dumb" applications that just want to show video should get the adapter
> with the fewest weird restrictions (at least, that was my thought).
> "smart" applications that want better output should be able to figure
> out which adapter to use.
More information about the xorg