What do you use x264/h.264 for now?

[miniyoyo]

Currently I use Xvid for video, but interest to know more about x264/h.264 usage. What do you use it for? DVD backup? DV encoding? HDTV(1080i or something like that)?

[Kostarum Rex Persia]

I use x264 for normal purposes,for DVD backup and alot more.

[Sirber]

I use x264. Period. :D

[Chainmax]

I use Indeo ;) :p.

[Sharktooth]

I use it for everything... including (and not limited to) sleeping, eating, working, having sex, etc...:D

[hpn]

Now seriously. The only reason to keep using XviD, especially for low/mid bitrates (<=800kbits) would be if you are stuck with very old hardware, like CPU<=1.0 GHz, cause a "relatively good" computer is needed to decode and play H.264 (x264 in particular) content. But cheap and fast PCs are now mainstream, so the choice is no brainer and you could safely switch to x264 or another H264 codec for your backup needs.

[miniyoyo]

you could safely switch to x264 or another H264 codec for your backup needs.
Say, with Xvid, the output file is of 1/4 size of the original DVD to get good quality(1100kbps), how is that with x264? Just an abstract is ok.

[hpn]

Well, for 1100kpbs and above the x264 - XviD quality difference is not so big. Keep in mind that XviD is an old, very mature and well tweaked codec, so if you're aiming at 2 CDs backup at about 1500kbps you'll get a very good quality with XviD. At this early development stage x264 has minor issues preserving some fine details at high bitrates (discussed around here if you use search), but it may not be true in you case (depending on your video source), so just make 2 encodes and compare the results yourself. For 1CD backup x264 is the clear choice.

[miniyoyo]

Thanks for the info, hpn. :p

[uray]

I always use x264 for everythings,and I got headache when i see file with .wmv extension...

[miniyoyo]

But most of the files on the net are either Xvid or Divx, it is very rare to see x264/h.264...

[akupenguin]

And divx3 was used for years after it was obsolete. What does popularity have to do with technical merit?

[IgorC]

In fact x264 is geting more popular very fast like other open source codec Xvid.

[Czarek Kwasny]

I'm a newbe here but I'd really like to use h.264 for my animations... I'm especially interested in the lossless mode to keep the material as rich as possible while mantaining original quality for archival purposes :). Hope the hardware in the future will allow to playback 1080p streams in lossless mode in real time. Also not sure about quality advantages in case of 8000-10000 kbps hd streams when compared to h.263 compression but still i prefer those (h.264) if they play smoothly on my pc. I'm quite impressed with the mp4 container and multiple scenario of its usage. It seems to be very flexible. And h.264 together with he-aac it makes a good company for putting the media content optimized for Internet conncections on-line. Good looking lowbitrated video with 5.1 soundtrack with just 128kbps would be perfect :). Still miss QuickTime7 support for he-aac as it would allow to embed mp4 files into html documents with nice playback controls. Anyway hope to be able to playback mp4 files created now on future hardware solutions ;) and for me h.264 helps to keep the quality as good as possible which is quite hard for animation as theres usually high range of saturation and often lots of noise, textures and sharp edges.

[hpn]

I'm especially interested in the lossless mode to keep the material as rich as possible while mantaining original quality for archival purposes :)
I hope you're not trying to backup your DVDs with the lossless option, cause you'll end up with much bigger files (20-30Mbps) than the ones you're trying to backup (4-6Mbps). Lossless makes sense if you compress some uncompressed source that you probably don't have (I may be wrong), cause all DVD's are already compressed from uncompressed master tapes to MPEG-2 format at about 4-6Mbps.

[Czarek Kwasny]

Thank you for replying. Fortunately you are wrong ;). I'm very much into video content creation. I'm studying animation at Academy of Fine Arts (Poland) and always wondering about poor quality of final material students bring. I guess its caused most of people stuck with DV codec which is optimized for camera footage not for animation itself. And getting 20-30Mbps is just right if you spent about half a year on making some short animation. You don't care about the bitrate so much (for archival purposes), but to keep the quality :). Here are some samples: http://gfx.artivo.pl/ I guess the night express is the most demanding, since it has lots of moving textures.
And I'm thinking of converting animations to mp4 for online preview.

As you see not only not only dvd backupers are deeply interested in advanced video coding, some animators too :).

[hpn]

This is a completely different story. If you create your own content lossless backup is the only way to go :). In x264 just use quantizer=0 to compress losslessly (I guess you already know that).

[Shinjite]

I use x264 for every video in my computer
Either x264 or DivX/Xvid XD

Experiment here and there

[Czarek Kwasny]

This is a completely different story. If you create your own content lossless backup is the only way to go :). In x264 just use quantizer=0 to compress losslessly (I guess you already know that).


Yes, exactly.

This may sound a little offtopic
My question is about colorspace. I usually output final uncompressed material in RGB, while x264 allows only YV12 as I assume. The converstion takes away part of information about chroma values. Is it possible somehow to transfer all the informations for lossless compression to x264?

[Teegedeck]

I use it for encoding DVD bonus features. As for the quality; ho-humm, I cannot really and honestly say that x264 is up to par with XviD. Though I'm a fan of progress. Recently I thought, I'd encode the Blackadder TV series with x264 using high profile. I wasn't quite content with the results (mainly problems with texture) and ran some visual tests. In the end XviD with h.263-quantization at quant 4-5 was more efficient and visually pleasing than x264 (also tested with custom-matrices) or Nero AVC. But in the end both looked too shabby for me and I went for bigger filesize, i.e. XviD and SixOfNine at quant=4. As for high-quality sources, the XviD/SixOfNine combo just retained considerably more detail than x264 when I last tested it (but that is some months ago, so it might have changed), I'm sorry to say. Probably I would not be able to see differences on my CRT but for watching movies I use the good TFT. I'm certainly gonna test it again when I have time on my hands.

So, ATM I use x264 when I cannot get something done at, say XviD/h.263 at quant=5. Which is not exactly day-to-day use, as I usually seek transparency.

Edit: Forgot to mention, I use x264 for anime, where it simply works wonders! But I encode anime only twice a year.

[stephanV]

This may sound a little offtopic
My question is about colorspace. I usually output final uncompressed material in RGB, while x264 allows only YV12 as I assume. The converstion takes away part of information about chroma values. Is it possible somehow to transfer all the informations for lossless compression to x264?
While the standard does support YUV 4:4:4 (which as close as you can get to RGB24), x264 does not support this.

If you want lossless RGB24 compression go for HuffYuv or CorePNG, but you will lose the ability to use MP4.

[Tommy Carrot]

@Teegedeck: i do not agree with your stance, imo x264 is very good even at high bitrates (especially in high profile), just don't forget to lower the deblocking strength (or even disable deblocking if possible). Inloop filtering is a two-edged weapon, although it does a good job at masking away the artifacts at lower bitrates, it destroys all the finer details, so use it carefully.

stephanV: ffv1 can also losslessly compress in rgb24 colorspace, and it is about twice as efficient as huffyuv or Corepng.

[stephanV]

Uhm... true, didn't know that (thought it could do YUV only) :rolleyes:

Although, ffv1 is still marked as experimental so I personally wouldn't use it for back-up purposes. I guess lossless JPEG would be another option...

[SeeMoreDigital]

At the moment I'm still backing up using XviD (muxed into the MP4 container with AAC-LC audio).

But as soon as AVC chip-set's start to appear in high-def stand-alone players I too will switch over to x264 full time ;)


Cheers

[Czarek Kwasny]

ok, thank you. Hope the developers consider support for YUV 4:4:4 in further releases. Also I didn't know about CorePNG. I'll try HVF1 provided by ffshow too. These could be nice solutions for transfering data between applications i.e. after effects -> premiere -> avisynth. Got to check it. Thanks for the information.

[akupenguin]

H.264 supports RGB. Though YUV 4:4:4 compresses better.

But since x264 doesn't have either yet, I too recommend FFV1 if you want it now.

[Teegedeck]

@Teegedeck: i do not agree with your stance, imo x264 is very good even at high bitrates (especially in high profile), just don't forget to lower the deblocking strength (or even disable deblocking if possible). Inloop filtering is a two-edged weapon, although it does a good job at masking away the artifacts at lower bitrates, it destroys all the finer details, so use it carefully.Uh, you didn't really believe that I didn't know that, did you? :) Very likely we have different approaches to encoding. I don't aim for 'very good quality' at that-and-that bitrate, but I aim for 'not-perceivable' difference to the original picture. And there even the slightest bit of inloop-filtering is painfully noticeable. It just looks artificial; like the input had been filtered. Many people like that, admittedly. And without inloop; well, that doesn't look too good. Perhaps we will have to wait for a different kind of source material before we should start using AVC for 'transparent' backups? What we have on mainstream DVDs is pretty grainy after all.

[SeeMoreDigital]

...What we have on mainstream DVDs is pretty grainy after all.Hmmm.... I guess this could raise another quandary!

Given that most of us forum members come from different parts of the world, who's to say the way my DVD source was created will look the same as somebody else's from a different region.

For all we know during the film to MPEG-2 process, subtle differences may have occured.... and who knows how the industry creates and distributes DVD "master" plates (and their back-up plates) to the pressing factories, which are situated all over the world....


Just a thought....

[wdmalik]

I used it for encoding, but my explorer crashes when i double click the file .. :(
from the threads it seems like it can give better quality than other codecs at low bitrates .. still trying to get it in working condition on my pc ..

[Sirber]

Now seriously. The only reason to keep using XviD, especially for low/mid bitrates (<=800kbits) would be if you are stuck with very old hardware, like CPU<=1.0 GHz, cause a "relatively good" computer is needed to decode and play H.264 (x264 in particular) content. But cheap and fast PCs are now mainstream, so the choice is no brainer and you could safely switch to x264 or another H264 codec for your backup needs.
xvid is great for iPAQ! Decodes 320% realtime compared to 17.5% for AVC :(

[nightrhyme]

I have to agree with Teegedeck. If your aim is transparent encodes then H.264 is no match.
I frequently do encodes with X.264 and Nero AVC to see if it has gotten better in preserving detail at very high bitrates.
I too dislike H.264 tendency to create large blocks on textures like sky and walls.

I don't care about filesize. I always make XviD, Single pass, Quant 2, HVS-BEST (I think it looks better than 6of9 Quant 3, sorry Teegedeck :rolleyes: ).

[BoNz1]

I use it for everything now. DVD rips, tv caps, you name it.

[rushin_911]

I use X264 for all of my enocdes, which are mainly low bitrate anime encodes, and the results are simply awesome!
Thx to all the ppl who work on x264 :)

[AVmaniac]

I am using x264 for all of my video backups....

TV,HDTV,DVD and so on

And now that it supports also non mod.16 resolutions it is even more attractive :-D

[pwh04]

I don't care about filesize. I always make XviD, Single pass, Quant 2, HVS-BEST (I think it looks better than 6of9 Quant 3, sorry Teegedeck :rolleyes: ).[/QUOTE]

Ah, With HVSBest, the detail is great, but I just can't stand the blocking. To me, mpeg standard creates less blocking than best. With 6o9 I rarely get any, and even in quant 4 the detail is very nice. (Sorry if this is OT)

paul

[virus]

Perhaps we will have to wait for a different kind of source material before we should start using AVC for 'transparent' backups? What we have on mainstream DVDs is pretty grainy after all.
transcoding MPEG-2 material means using H.264 with a single leg :)

There's no definitive solution to that. Unfortunately, MPEG-4 Visual is much more similar to MPEG-2 than H.264, and generally, when recompressing already compressed stuff, an algorithm whose features/artifacts closely reproduce those of the source is likely to perform very well, even compared to a more efficient (but "more different") one. Uncompressed sources would probably show a larger margin for H.264.

As for the fact that x264 may look worse than XviD at high rates, one should also consider the fact that if you throw enough bitrate up to the point where both codecs "visually saturate" (in the sense that even more bits added would not add anything visible to the output), the only thing that really counts is the amount of detail retained, as a function of the spatial transform type + the quantization matrix + the type of MC involved. You cannot change the transform type in H.264 (only the size), nor you can change the type of MC (always QPel, with a predefined interpolation, which is BTW different than MPEG-2 - which has no QPel at all - and MPEG-4 part 2). But you can change the matrix. From that point, XviD is "better" since a lot of specialized matrices have been developed and fine-tuned for it over the time. You're a 6of9 user, you know that well :D

But keep in mind that the point is generally that x264 is able to retain more detail at the same bitrate, due to its superior efficiency. This is evident when the bitrate goes below the "visual saturation", but it's not necessarily true if you let XviD eat up all the bits it needs to give a transparent result. Please note that "being able to retain detail" is different than actually "retaining detail" ;) (see my points above)

Also, maybe in your setup x264 loses some detail compared to XviD when encoding to, say, 2000 kbit/s for a given source. But maybe x264 is able to basically show the same result at 1700 kbit/s. That is, look a tiny bit "washed" compared to XviD, but with a 15% less rate. Meaning that at 1700 kbit/s it has already "visually saturated", much before XviD. This is surely not what you want, but it's definitely a winning point for rate-constrained encodings.

A final note: if a person watches on average 100 XviD encodes and 2 x264 encodes, it's clear that his/her eyes are well customized to XviD's look. x264 will surely look "different", for obvious reasons. A lot of changes happened under the hood between Part-2 and Part-10, after all. But are we sure that "different" means "worse"? Wouldn't 100 x264s and 2 XviDs made things different? I bet they will (not necessarily for a single person, but on average).

sorry for the long rant, but there were a couple of points that someone had to make. I noted that there's a bit of superficiality when describing H.264's results on this board. And I address this to noone in particular, just in general (actually, here I'm answering to some observations made by one of the few guys here that accurately describes what he sees, and that makes careful tests which make sense, so hopefully Teegedeck will understand that I'm not criticizing his personal views on H.264 :)).

cheers,
virus

[LordRPI]

I second the above, word for word. In fact I think virus said it better than I could, and I'm a native english speaker.

As somebody who has used raw, previously uncompressed video, I can safely say that you haven't seen the real deal if you encoded from even a superb mpeg-2 source.

[Teegedeck]

That is, look a tiny bit "washed" compared to XviD, but with a 15% less rate. Meaning that at 1700 kbit/s it has already "visually saturated", much before XviD. This is surely not what you want, but it's definitely a winning point for rate-constrained encodings.Yes, I use x264 for those cases where I want to devote only little space to material - like, as I said, DVD-bonus stuff (or also DVB-T intermediate storage).

A final note: if a person watches on average 100 XviD encodes and 2 x264 encodes, it's clear that his/her eyes are well customized to XviD's look. x264 will surely look "different", for obvious reasons. A lot of changes happened under the hood between Part-2 and Part-10, after all. But are we sure that "different" means "worse"?The thing is, does it look different from the source? This is not about liking or not liking the look of the codec but about telling apart the original from the copy. For example I 'like' XviD's quarter-pixel accuracy because it gets close to the effect of MPEG-2's DC precision. As noted, AVC is more distantly related to MPEG-2 than MPEG-4 ASP is; that is a problem for as long as our primary sources are MPEG-2. I do like AVC, though. :)

[Sharktooth]

Well, "x264" and "washed" = badly encoded.
x264 and h264 codecs in general have a tendency to kill noise, grain and fine details coz of the 4x4 transform (main profile).
if you like to keep all the grain and all the stuff "artificially" produced by the analog camera and the film, just use the features of the high profile and lower the deblocking strenght.
Yes, finding good settings with x264 is harder than for xvid and needs practice. once you're used to it you will never go back...

HINT: To help keeping details i created a custom matrix (EQM AVC-HR) that is able to keep the film grain at about 1500kbps (for an "average" movie).

[LoRd_MuldeR]

I use x264 whenever I encode video :D

Usually I capture from my TV-Card with MPEG-2 @ 12MBit/s (Hardware Encoder). Extreme Quality, but 300 MB for a short 3 minutes clip. So I convert the capture to x264 in order to save some (actually a lot of) diskspace. IMO much better results than XviD or DivX.

[Teegedeck]

HINT: To help keeping details i created a custom matrix (EQM AVC-HR) that is able to keep the film grain at about 1500kbps (for an "average" movie).At which quantizer should EQM AVC-HR deliver perceived 'transparency' from your experience?

[SeeMoreDigital]

HINT: To help keeping details i created a custom matrix (EQM AVC-HR) that is able to keep the film grain at about 1500kbps (for an "average" movie).And at what pixel frame sizes?


Cheers

[Sharktooth]

At which quantizer should EQM AVC-HR deliver perceived 'transparency' from your experience?
Still dont knonw. "Transparency" depends on the monitor/TV too and im going to buy a LCD soon.

And at what pixel frame sizes?
The "average" movie is the classic 16:9 (1.77:1) DVD movie (PAL).

However this is what i mean keeping the grain at 1500kbps (encoded with x264 and EQM AVC-HR):
http://www.webalice.it/f.corriga/temp/grain_example.png

[SeeMoreDigital]

Well.... that would seem to indicate that x264 can be configured to preserve "grain" :D

When I meant by my "And at what pixel frame sizes?" comment was.... It must be much easier for any MPEG-4 codec to preserve detail (such as grain), when the encoder is configured to encode at 1:1.

Logic would dictate that that when reducing the quantity of encoded pixels, from say 720x576 (16:9) anamorphic pixels to 720x400 square pixels, detail would be lost, due to the level of pixel interpolation being carried out during the resizing process!

[hpn]

Ok, rumor has it, in this and other threads, that x264 is not yet up to par with XviD at high bitrates around 1500kbps (2CD backup) and above, in terms of preserving fine details/texture, so I decided to make a few tests with a high quality HD source and the most recent x264 rev. 333 and xvid.2005.10.16 trying to prove or disprove this claim.

Source: Harry Potter and the Goblet of Fire - resolution 1920x816p, 3223 frames, 23.976fps
http://movies.apple.com/movies/wb/harry_potter_goblet/harry_potter_goblet-tlr2_h1080p.mov

Results at 2632 kbps:

http://img484.imageshack.us/img484/4193/0195all0oy.jpg
http://img484.imageshack.us/img484/1236/0605all3hn.jpg
http://img484.imageshack.us/img484/3716/1016all2lm.jpg
http://img484.imageshack.us/img484/2199/1225all7fj.jpg
http://img484.imageshack.us/img484/6785/1917all5qh.jpg
http://img484.imageshack.us/img484/8308/2261all4ml.jpg
http://img484.imageshack.us/img484/8861/2865all8hx.jpg

My conclusion: Although XviD is an extremely good codec, in most cases (some exceptions maybe) it's not comparable to the x264 quality at ANY bitrate, as long as you encode abiding by the rules (2pass, maxed settings, etc.). Of course visually the sreenshots are extremely close at this high bitrate and in slow/no motion scenes almost identical.

----------------------------------------------------------------------
P.S. testing details:
Rename the .mov trailer to .mp4 (harry_potter_goblet-tlr2_h1080p.mov.mp4) and use MP4Box.exe with the YAMB GUI to demux the raw video stream harry_potter_goblet-tlr2_h1080p.mov_track1.h264, then mux the raw .h264 to .mp4 (harry_potter_goblet-tlr2_h1080p.mov_track1.mp4)

For a high quality test input, crop 16 pixels (8 pixels from top and bottom) in order to get mod16 (recommended for x264 encodes) after the resize, then resize to 50% with this avs script:

DirectShowSource("G:\333_test\harry_potter_goblet-tlr2_h1080p.mov_track1.mp4", fps=23.976, pixel_type="YV12")
crop(0,8,1920,800)
LanczosResize(960,400)

2-pass x264 CLI encoding:

x264 -p 1 -B 2632 -A all -r 5 -b 2 -w -8 --mixed-refs --progress -o NUL b.avs
x264 -p 2 -B 2632 -A all -r 5 -b 2 -w -8 --mixed-refs --progress -o x264.264 b.avs

PSNR Mean Y:48.861 U:52.521 V:51.966 Avg:49.623 Global:46.835 b/s:2631.04

Even better results may be achieved by playing with deblocking strength, custom matrices etc.

(why testing with 2632kbps? Because an average cropped, unresized PAL DVD is 720x304 = 218800 pixels = 1500kbps for high quality 2CD backup. This particular HD trailer is 1920x816, cropped, then resized to 50% -> 960x400 = 384000 pixels -> 1.755 more pixels than the DVD -> 1500*1.775 = 2632kbps)

Then encode the same avs with "xvid.cvs.head.2005.10.16.7z" (all settings to max quality - 2-pass, 2632kbps bitrate, etc).

3221 screenshots (complete frames list) generated with mplayer from x264, XviD and the source like this:
mplayer -vo tga x264.264
mplayer -vo tga XviD.avi
mplayer -vo tga b.avs

tga to jpg converted at 85% compression

[berrinam]

]x264 -p 1 -B 2632 -A all -r 5 -b 2 -w -8 --mixed-refs --progress -o NUL b.avs
x264 -p 2 -B 2632 -A all -r 5 -b 2 -w -8 --mixed-refs --progress -o x264.264 b.avsNo RDO?

[hpn]

No RDO?
As I said even better results may be achieved by playing with the command line, so if you have time you could try with other options. Also in order to outline the general trend I made it to be a visual, not PSNR comparison, so I didn't try to get the max possible result by skipping some options and leaving other to their default, or at least not max value (like --subme 5 instead of 6 or 7, or --me hex instead of umh or esa, or -r 5 instead of -r 16), simply because the encoding time should be reasonably short.

Edit:
adding --subme 7 (RDO level 2) instead of the default -m 5 produces
PSNR Mean Y:48.861 U:52.521 V:51.966 Avg:49.623 Global:46.835 b/s:2631.04

the default --subme 5
PSNR Mean Y:48.715 U:52.373 V:51.943 Avg:49.488 Global:46.627 kb/s:2631.09

so it's not so bad after all although it's slower :)

[*.mp4 guy]

There are easily visible blocks in the Xvid encode, what was the average quantisizer? I'm assuming you used the H.263 matrix, for a more indicative test you should get Xvid neer saturation, mostly Q2-3.5 and use a detail oriented matrix.

[hpn]

Yes, the default H.263 quantization type was used. I guess someone more experienced with custom XviD matrices could retest and get slightly better results for this particular source.

[Caroliano]

It's said that --subme 7 is yet suboptimal with --mixed-refs. Maybe --subme 6 can be better in this case.

[akupenguin]

No, subme6 will never be better than subme7. "Suboptimal" means that subme7 doesn't help as much as it could.

[Caroliano]

Oh. Thanks for clarification.

[AVmaniac]

Last weekend i did some tests with HDTVmaterial (Spiderman1 - Pro7HD - freeTV - 1920x1040)....
i've transcoded the whole movie to x264@2383kbps and the result looks really nice.
BUT a playback results in a 99% CPU load, using ffdshow-filter-playback, without any sound on my AMD64-3400+ system :-(

[denise]

Last weekend i did some tests with HDTVmaterial (Spiderman1 - Pro7HD - freeTV - 1920x1040)....
i've transcoded the whole movie to x264@2383kbps and the result looks really nice.
BUT a playback results in a 99% CPU load, using ffdshow-filter-playback, without any sound on my AMD64-3400+ system :-(
decode 99% CPU usage with 3400+... :(
May be your resolution quite big(I'm never reach 1920x1024).
I wonder what happen if this Spiderman movie play on 1Ghz CPU.

I use x264 only for low bitrate video file,my PC so slow.

[AVmaniac]

Originally Posted by denise
May be your resolution quite big(I'm never reach 1920x1024).
I wonder what happen if this Spiderman movie play on 1Ghz CPU.

I use x264 only for low bitrate video file,my PC so slow.

I just wanted to know how x264 works like at HD resolutions.
Until now i also only encoded SD material for backup purposes.

I wonder if there is any software beside ffdshow that has a
better playback performance.
Even Nero-Show-Time did a poorer job.

[nm]

There are no dramatically faster software decoders. Read bond's comparison (http://forum.doom9.org/showthread.php?t=99402).
You could try MPlayer, which is pretty fast when set up correctly.

[kurt]

You could try MPlayer, which is pretty fast when set up correctly.
that's the point: do you know a simple guide how to setup mplayer correctly (under windows)? :rolleyes:
(i know the huge mplayer docs (http://www4.mplayerhq.hu/DOCS/HTML-single/en/MPlayer.html))

[nm]

I don't have Windows, but the MPlayer docs are really quite good and IMHO simple enough: http://www.mplayerhq.hu/DOCS/HTML-single/en/MPlayer.html#windows
They even explain setting up colorspaces and other rendering options (-dr and -double). For H.264 decoding you'll need to compile MPlayer yourself or use unofficial builds. At least Celtic Druid seems to provide them (http://www.aziendeassociate.it/cd.asp?dir=/mplayer).

[kurt]

ok, I'll take a deeper look in the docs, thx :)

[bond]

hm imho there is no need to do anything special when playing in mplayer

[nm]

Well, the defaults should work fine, but there are some settings worth exploring especially on older graphics hardware. On Windows DirectX output is probably the fastest, but on other platforms there are more options like Vidix, Xv, XvMC for MPEG-2, mga_vid and DirectFB each of witch may be the fastest on some specific card (usually because of driver issues). Audio output drivers can also have an effect on performance. Then there are timer settings (hardware/software), different framedrop settings, colorspace conversion filters for faster overlays, a few drawing modes (dr, slices) and double buffering.