Certainly with older generation products, most hardware acceleration seemed to be based around (inverse) discreet cosine transforms, so really it's working at a lower level than individual frames.
I'm less familiar with the latest kit, but from what I understand it lets you feed a compressed stream (mpeg, h.264, etc.) direct to the GPU and have it appear as rendered video in the frame buffer. On 30 September 2010 15:03, Chris Adamson <[email protected]> wrote: > I'm not sure about "most" H.26x decoding being done in hardware. On > the Mac, we only got this with QuickTime X in Snow Leopard. Prior to > last year, H.264 decoding was all in software. Of course, it is > genuinely a big deal for mobile to use hardware decoding because of > the performance and energy wins. > > I'll also cop to being ignorant of just how much help you get from the > hardware decode: does the GPU decode individual frames on demand > (which is what I would expect) or does it do more than that? I don't > imagine the GPU depacketizes the stream and renders it all by itself > (for one thing, it wouldn't know what to do with the muxed audio). > > --Chris > > On Sep 30, 9:47 am, Kevin Wright <[email protected]> wrote: > > I think the real issue here is that most h.26x decoding nowadays is done > > with hardware support, via native APIs > > That's where C/C++ has a definite advantage over Java, and not in the > > inherent performance qualities of VM vs statically compiled code. > > > > On 30 September 2010 14:36, Carl Jokl <[email protected]> wrote: > > > > > > > > > > > > > > > > > > > > > It is at lest somewhat comforting to know that even an experience C/C+ > > > + developer makes plenty of pointer errors. > > > > > The way I see it is that even with the Computer Science background and > > > understanding O/S memory allocation models and how C/C++ allocates > > > memory as well as Stack and Heap memory theory the errors still happen > > > because I am human and miss things sometimes. It is all good and well > > > when the program flow is simple enough for the allocations and > > > deallocations to be easy to see and in a straightforward logic. The > > > more complex the application gets the more complicated it becomes to > > > manage the memory correctly. Both feeing memory which something is > > > still using or not freeing it leads to problems. > > > > > I think even someone at Sun implied or said that in an ideal world > > > everyone would write perfect C/C++ code but things like Java exist > > > because in practice it turns out that this is really really hard to > > > do. > > > > > Maybe I should try Assembler just for kicks....I like pain. > > > > > -- > > > You received this message because you are subscribed to the Google > Groups > > > "The Java Posse" group. > > > To post to this group, send email to [email protected]. > > > To unsubscribe from this group, send email to > > > [email protected]<javaposse%[email protected]> > <javaposse%2bunsubscr...@googlegroups .com> > > > . > > > For more options, visit this group at > > >http://groups.google.com/group/javaposse?hl=en. > > > > -- > > Kevin Wright > > > > mail / gtalk / msn : [email protected] > > pulse / skype: kev.lee.wright > > twitter: @thecoda > > -- > You received this message because you are subscribed to the Google Groups > "The Java Posse" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<javaposse%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en. > > -- Kevin Wright mail / gtalk / msn : [email protected] pulse / skype: kev.lee.wright twitter: @thecoda -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
