Update 19/Nov/2008: This is currently under discussion in the WHATWG and the W3C bug has been marked "won't fix". For now, cross domain usage is fine.
This is a heads up for a change to the HTML5 media elements that may break existing usage. If you use <video> or <audio> then you may need to make changes to the way you serve your media resources.
It looks likely the that <video> and <audio> elements will be restricted so that requests for a media resource from a domain other than the page containing the element will be disallowed. There is a W3C bug (<video> and <audio&ht; should prevent cross-origin media loads) about this.
Once the browsers implement this then default usage of cross domain media resources will fail. This includes requests for resources on subdomains, or different ports. So if you have a page on example.com, this will work in the Firefox implementation now, but will break when the change is made:
Cross domain usage can be enabled by sending headers along with the file being requested. The header explicitly says 'this resource can be used cross domain'. The protocol for doing this is described in this Access Control document.
If you are hosting your media resource on a third party hosting system you'll need to ensure that they support these headers if you want to display video and audio on a different domain. Programs such as Icecast, used to stream video and audio, will also need to be compatible with the Access Control specification if you want to use the streams with <video> or <audio> from a server on a different host or port.
This unfortunately breaks some common patterns for building sites that allow uploadable media, or separate media files into subdomains, until they (or their software/hosting provider) supports access control. Now would seem to be a good time to request access control support if you're in this situation.