Dsp Theora


Neko said:
TrashyMG said:
Neko said:
hedwards said:
I wouldn't personally mind h.264 so much if it weren't such a pain to use outside of Windows.
It's somehow easier in Windows? Maybe in windows 7, but H.264 didn't come with XP or Vista.

It's pretty easy for any version of windows.. just need the CCCP codec pack
The CCCP decoder is FFmpeg, which is the same on every other operating system.
And your point is?
 
Last edited by a moderator:
I wouldn't personally mind h.264 so much if it weren't such a pain to use outside of Windows.
I've never had any trouble using it in Linux, ever.
Admittedly I usually manually compile mplayer, but it's hardly difficult to install the necessary gstreamer codecs.
I think Ubuntu even offers to do it for you if you try to play a h264 video?

I'd assume OSX has no trouble either, but then my friend's macbook couldn't seem to play my anime fansubs, so I don't know.
 
TrashyMG said:
And your point is?

I don't think he knows that you can't legally use h.264 for commercial purposes (e.g. every advert you ever see on a streaming service) without someone having to pay for a license of the patent. On Windows, this is easy, because Microsoft had you pay for the license (whether you use it or not) when you bought the OS.

Patented codecs are bad, mmmkay?
 
Last edited by a moderator:
darkblu said:
yet another approach to GPU-assisted theora decoding is passing individual 8bpp textures for the Y, Cb and Cr, respectively, and doing all the colorspace conversion onboard the GPU. A nice feature of that approach is that each of the chrominance textures is 1/4 the resolution of the luminance one, and the final, on-GPU stage gets 'free' scaling of the chrominance textures through the GPU's TUs.

The blog linked mentions this:

"Because there was already work underway to provide OpenGL accelerated compositing in Firefox with the newly conceived Layers API, it seemed logical to try using a GLSL fragment shader to off-load colour-space conversion to the GPU. This turned out to be too slow to play back a full-screen video. Looking at the list of vendor-specific OpenGL extensions available on the N900, I discovered the texture streaming API. This allows a program to directly map texture memory and copy Y'CbCr data into that memory without having to perform an expensive texture upload or colour-space conversion. The colour-space conversion is off-loaded to dedicated graphics hardware inaccessible via the standard OpenGL APIs. Using this and the modified bc-cat kernel module from the gst-bc-cat project, it's possible to play back at 26 FPS with 81% CPU idle.

One drawback of the current bc-cat kernel driver is that there is a very limited set of texture formats supported (NV12, UYVY, RGB565, and YUYV), and none of them are the same as what Theora produces. To work around this, a format conversion is required to convert planar Y'CbCr to packed 4:2:2 UYVY. Fortunately, this conversion is much simpler than a full colour-space conversion. Timothy Terriberry sent me a couple of patches to off-load this conversion work to the DSP. If it's possible to extend the bc-cat driver to support texture formats compatible with Theora's output, performance can be further improved."

IMO the CPU-utilization figures are misleading, because they suggest color space conversion takes 80% of the decode time, which would suggest a pretty lame compression. What you actually see from the FPS numbers (47->26) is that the SGX performing colorspace conversion is probably a pretty substantial bottleneck.

If you think about it it's not very surprising - let's say SGX was at 110MHz. It has only one TMU, so it takes at least 3 cycles to load the texture values, but I think it's actually worse than this because the textures are big (800x480x8bpp, 2x 400x240x8bpp) and unswizzled, and will probably cause many cache misses, especially if the L1 tex caches are only say, 2-way set-associative. Then you pay for cycles for the colorspace conversion that's probably performed in shaders.

The format limitation suggests to me that it was done was using OGL ES 1 instead of 2. So maybe the results can be optimized with better shaders.

I sent an e-mail to Matthew asking if he knew what the SGX was clocked at for this test.

Another thing is that the DSP port was probably not optimized for the DSP - I say this because it was mentioned that it was done quickly. So maybe much more performance can be squeezed out of it, so it's more competitive with the ARM optimized version.
 
Last edited by a moderator:
Neko said:
hedwards said:
I wouldn't personally mind h.264 so much if it weren't such a pain to use outside of Windows.
It's somehow easier in Windows? Maybe in windows 7, but H.264 didn't come with XP or Vista.

KLite Mega. Plays anything. Encodes anything too - except Theora. :lol:

Apparently FFCoder will encode Theora - but it does have a lot of crash bugs.

If I posted some H.264 video here, could someone test to see if it plays on an actual Pandora? I can post Theora video too.
 
Last edited by a moderator:
http://google-opensource.blogspot.com/2010/04/interesting-times-for-video-on-web.html
http://wss.co.uk/pinknoise/theorarm/
 
Back
Top