QuickTime 6.6 to support high-resolution audio, B-Frame video

QuickTime 6.6 will also feature several video enhancements, such as support for B-Frame and H.264 video compression. The release will also introduce a new visual context that provides an abstraction layer decoupling QuickTime from GWorlds.

B-Frame video compression is a major advancement that involves new sample tables for video, allowing video frames to have independent decode and display times. This will result in improved display, editing, and capture in H.264 and other advanced video codec formats. The implementation will reportedly include a new API for working with media sample times, adding and finding samples, and a new Image Compression Manager API.

The H.264 codec is the latest standards-based video codec. Also known as the Advanced Video Codec (AVC) and as MPEG-4 Part 10, the H.264 codec promises to deliver better live streaming characteristics and better image quality at lower bit rates than the current MPEG-4 video codec.

Meanwhile, a new QuickTime visual context will provide an abstraction layer, decoupling QuickTime movies from GWorlds. The context allows programmers to work in QuickTime without needing to understand QuickDraw concepts and structures, and making it easier to render QuickTime output using engines such as OpenGL.

Likewise, QuickTime 6.6 with also mark the debut of an OpenGL texture context, a specific implementation of the aforementioned visual context that will provide a movie's visual data to a client applications as OpenGL textures. These textures can then be rendered to the screen using OpenGL, composited with other graphics, or run through CoreImage filters.

This post seems to suggest that MPEG2 conversions will no longer lose the audio:
B-frames don't really hurt decode complexity that much. They do increase memory requirements (effectively irrelevant on a personal computer, but this matters for consumer electronic devices), and increase latency when streaming. B-frames do improve random access, since a B-frame can reference a P-frame, but no frames, not even other B-frames, reference a B-frame. So, with a MPEG-2 like IBBP, where there are two B-frames per P-frame, only roughly 1/3rd of the frames need to be decoded during random access.

This is a huge issue for QuickTime, since lack of B-frames is behind some of the big limitations in QuickTime to date that might otherwise seem unrelated. These include:

The inability to edit MPEG-1 and MPEG-2 like a normal .mov. Since they use B-frames, QuickTime implements decode as a component instead of a codec.

And because MPEG-1/2 is a component, QuickTime can't export audio from a .mpg source, which comes up a LOT.

No B-frame support in the current MPEG-4 implementation. Since MPEG-4 is a codec, QuickTime can't use B-frames, and since that's a required part of MPEG-4 Part 2 Advanced Simple, QuickTime doesn't support the other useful features of that spec, like quarter pel motion estimation, global motion compensation, and interlaced support.

We QuickTime professionals have been bugging Apple for the features in this proposed 6.6 for over five years now.