> a) VLC, when _not_ using the GPU, doesn’t struggle
> remotely as much as Flash
> b) VLC also overlays text and graphics over video

Again using the GPU for compositing.

> c) YV12->RGB _can_ be tightly optimised if you’re
> crazy enough to do
> things that way around
> 
> The key there is that the YV12->RGB conversion that
> Flash does is
> slow, rather than it necessarily being software (i.e., it
> could be
> relatively efficient and still software).
> 

Thanks to overlays and other transforms the YV12->RGBA conversion has to be 
done that way can still be quite slow considering other browser threads have 
priority. It's not an easy problem to solve at high-resolutions while keeping 
the plugin size as low as possible.

Also like VLC's upcoming DXVA implementation I think the Flash version is a 
hack by not actually using a proper renderer but pulling the processed frames 
beforehand. (I'm no Directshow expert so I can't explain how it's done there) 
However, if there is an ASIC on the PC designed to decode H.264 it might as 
well be used.

Hopefully this will lead to more use of non-filmic framerates online. Such 
overuse of filmic framerates online and on TV and probably on IPTV will 
inevitably devalue the effect in my opinion.

> Frankly, the sooner the codec mess behind <video />
> gets sorted out
> and Flash can be avoided in the few remaining contexts that
> it’s used,
> the better.

<video /> doesn't have a proper method for specifying the buffering time. This 
means it can't formally support any of the modern video buffering features 
(such as HRD in H.264). Also the ogg container format doesn't have any index 
making the "official" method through javascript a non-starter. 

As far as I know most (all?) HTML5 video implementations suffer from 
similar/worse performance than flash thanks to browser compositing engines 
requiring RGB input.

-
Sent via the backstage.bbc.co.uk discussion group.  To unsubscribe, please 
visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html.  
Unofficial list archive: http://www.mail-archive.com/[email protected]/

Reply via email to