(22/07/2010 04:52 AM)ZiNgA BuRgA Wrote:  

• Many CPUs can't decode it without lag (especially going to slow Flash); I suspect it will choke all but the best Core 2's, but I can't seem to find reliable results
  
• DXVA (GPU decoding) probably chokes on it too.
  

• MPC-HC won't use DXVA on that video.  So probably not supported.
  
• Ticking the GPU Acceleration box in VLC made my whole goddamn computer blue screen.  Most likely VLC's fault though.

• For some unknown reason, this was actually surprisingly easy to play back.  Only used like 35-50% of CPU usage on my quad, which means any decent dual core should also be able to do it.
  
• Compare to some of the 1080p BDrips that I have lying around, which take about 15-30% CPU to play (depending on complexity), this is extremely unexpected, since it has up to 4x as many pixels per frame.
  
• The could be a combination of... 1). That video I had was probably on the easier-to-decode side (not much motion).  2). The (comparatively) low bitrate also helps decoding speed.  3).  Maybe Google encoded it with settings that favours decoding speed (CAVLC, No in-loop deblocking)?  Don't know, I do not have any stream analysis tools to check with.
  
• CoreAVC is bugged, and refuses to play it.  Actually, I'm just going to stop using CoreAVC as a whole.  I hardly need the speed (my CPU is fast enough to play 3 1080p videos concurrently), and the bugs are not worth it (CoreAVC also has problems with windows thumbnail generation).  Also, these days I use FFMS2 for like 90% of my encoding, and 9% of the rest is (dgdecode_)mpeg2source, so I don't CoreAVC any more for that either.