beside fglrx code seems to be a trully mess and is very far away from windows equivalent + unstable as hell(at least in rv7xx chips). so adding this new stuff could break it even more(not being ironic it can be even worse than now even if is hard to imagine).
if your budget allow it do like me buy an nvidia gts250 that will fit fine for modest game and clear h264 play with vdpau until OSS drivers get full mesa support and gallium/openCL become usable cuz in fglrx is not going to happen and even if someday in fglrx 20.20 happens i really doubt would be any usable until fglrx 32.14 in 2034. but by then prolly my 128 cores 40 ghz cpu can handle BD just fine lol.
beside the homourus comment up, the truth here seems to be than first AMD dont care too much about fglrx cuz market issues and the code they got from ATI was a trully hellish completly undebugged code, plus AMD is producing new technologies like crazy in the gPU side (most productive part of AMD now) so it will take a long time to get a stable functional code because they seems to be forced to add code on the fly to support at least basically these tech beside the driver is stable or not. so more chaos to a chaotic code lol. so those of us that say ohh i love that 4800 card and commit the sin of use linux, our only hope is the OSS driver (which is going nice btw) cuz devs seems to put more thinking and optimization in the code, i guess is cuz of the lack of pressure of crazy enterprise politics and more access to OS info from already +AAAAA drivers like OSS intel.
so wait for OSS driver/gallium/opencl and later wait for xine/ffmpeg/VA-API opencl video accelaration infrastucture (maybe this come faster cuz nvidia have already a very nice openCL capable driver, so we dont have to wait for gallium or AMd at the very begining)