Weekly Edition
Return to the Announcements page
| |||||||||||||
|
| |||||||||||||
Interesting times for Video on the Web
Robin Watts has weblog
post about Google funding for the TheorARM project. From the
blog: "These ARM based devices represent the single biggest class of
devices still needing work for decent Theora playback. Any efficiency
savings we can make feed back directly into being able to cope with larger
screen sizes or giving longer battery life. This is where Google's grant
comes in - by helping fund the development of TheorARM (a free optimised
ARM version of Theora), they are helping to hasten the day when video works
everywhere on the web, for everyone. That's got to be something to be
pleased about." (Thanks to Paul Wise)
(Log in to post comments)
Interesting times for Video on the Web Posted Apr 12, 2010 19:41 UTC (Mon) by magila (subscriber, #49627) [Link]
Maybe I'm just a pessimist, but the prospects for this becoming a viable solution for playing theora video on mobile devices seem rather dim. I'm guessing the h264 decoding hardware commonly used in these devices draws substantially less power than running the ARM processor with any significant load. So even if it achieves the requisite performance, the hit to battery life would surely be considered unacceptable by most.
Interesting times for Video on the Web Posted Apr 12, 2010 19:48 UTC (Mon) by DOT (subscriber, #58786) [Link]
Why would an optimized ARM-based decoder use substantially more power than a decoder chip? Obviously a decoder chip can have some more optimizations, but would that really have so much effect?
Interesting times for Video on the Web Posted Apr 12, 2010 21:31 UTC (Mon) by drag (subscriber, #31333) [Link]
Just because dedicated hardware is _really_ _really_ fast.
The amount of cycles that it takes to decode a video is going to be substantially less then what a similar effort on a general purpose processor. Not to mention also that dedicated hardware is a lot smaller and a lot cheaper to produce.
The thing that sucks about dedicated hardware is that it's, well, dedicated. It can only do a few things.
But optimizing for ARM is going to be same as optimizing for dedicated hardware anyways. Not much difference
There are a lot more variations and whatnot to the ARM architecture then x86. When compiling for PC systems the difference between targeting a 586 and a 686 era processor versus a Core 2 Duo system is not really going to net you much advantage.
However between multiple ARM architectures you can have HUGE difference in performance, especially when it comes to floating point performance between specific processors.
Also you have all the variations of 'system on the chip' with dedicated DSPs and things like Ti's 'DaVinci' that any codec targeting a specific system will have to take into account.
So I am assuming that 'optimizing for the arm platform' means taking all that into account.
For example....
You can easily have a phone processor that will choke on a simple OpenOffice.org spreadsheet, but will be able to simultaneously display, encode into mpeg2, decode from H.264, a 720p sized video stream without breaking a sweat. Just depends on what other processors that the vendor has thrown in. Not even really 'dedicated h.264' either, but something like DaVinci.
There is nothing terribly magical about H.264. Theora uses more memory bandwidth so some chips that are capable of high resolutions with H.264 can only display moderately high Theora, but it's just a matter of tweaking the design and the codecs I expect.
Interesting times for Video on the Web Posted Apr 12, 2010 21:33 UTC (Mon) by drag (subscriber, #31333) [Link]
Nevrmind, should of looked at the post a couple posts down.
Interesting times for Video on the Web Posted Apr 12, 2010 22:00 UTC (Mon) by dlang (✭ supporter ✭, #313) [Link]
what you are missing is that dedicated hardware also can't be updated.
it's per-unit cost and efficiancies are very good, but there is a HUGE initial cost that you have to recoup, and there is also a very long development cycle of the hardware.
As a result of these things and the performance/power improvements in normal processors (including DSPs) make it that companies that use general processors/DSPs get their product to market faster, and can update their product if bugs are found, so just about everyone goes this route.
dedicated hardware is something very different from optimizing for a DSP or ARM processor.
ARM is just a different cpu architecture, and just like the optimizations to run efficiantly on a core2 are vastly different from the optmizations that you would need to run efficiantly on a pentium II, the optimizations that you need to run efficiantly on an ARM are different.
DSP support is like SSE/floating point support, it's additional commands that are available that can do some things much better than without those commands. In addition, many (if not most) DSPs support setting up commands that can do more than one calculation per clock cycle.
dedicated hardware is very different, it's less a processor than a chip with a huge state engine and lookup tables. once built to decode mp3 it cannot do anything else. As such a player with a dedicated hardware playback chip would still need a processor to run the display, read from memory/storage and send the data to the playback chip. Since that processor can do the music decoding it's seldom a win to have two chips splitting the work instead of one slightly more powerful chip doing everything itself.
Interesting times for Video on the Web Posted Apr 12, 2010 19:58 UTC (Mon) by mjr (subscriber, #6979) [Link]
Kinda tiring to see overly pessimist fud on the subject over and over again.
1) Not every use case everyone cares about needs long-running video playback, and further, guessing on this without any solid basis for either the likely level of performance or in fact what people find acceptable is, well, kinda useless. (I don't have much of those either, but I'm not making claims here.)
Interesting times for Video on the Web Posted Apr 12, 2010 20:17 UTC (Mon) by gmaxwell (subscriber, #30048) [Link]
The performance numbers there were deflated by the fact that the frame decodes were serialized with reads to a remote NFS server. David doesn't seem to have gotten around to publishing some revised numbers— but what he said on IRC was "roughly 720x480@30fps".
Interesting times for Video on the Web Posted Apr 13, 2010 19:57 UTC (Tue) by jzbiciak (✭ supporter ✭, #5246) [Link]
Well, there are both DSPs and dedicated hardware, really, and often both on the same chip. I should know, I sit next to the guy who wrote a fair bit of the H.264 codec code for the C64+, and who also developed a number of dedicated, configurable accelerators in that space as well.
The trend seems to be for dedicated, configurable accelerators to support standards that we know about or can reasonably predict, and then keep the DSP around for new standards that arise, and other processing tasks that the accelerators don't pick up.
Interesting times for Video on the Web Posted Apr 12, 2010 20:55 UTC (Mon) by robert_s (subscriber, #42402) [Link]
"I'm guessing the h264 decoding hardware commonly used in these devices"
These "hardware decoders" are generally a myth. These days the huge majority of them are small DSPs. The important distinction here is that new codecs can probably be implemented with new firmware.
Interesting times for Video on the Web Posted Apr 12, 2010 21:24 UTC (Mon) by magila (subscriber, #49627) [Link]
Whether they are DSPs or ASICs, as far as I know none of the relevant vendors have shown any inclination to implement theora support for their decoders. In any case that's not what we are talking about doing here, TheorARM is an implementation designed to run on the device's main application processor.
Interesting times for Video on the Web Posted Apr 12, 2010 22:07 UTC (Mon) by DOT (subscriber, #58786) [Link]
All you can do is build the software. If vendors don't want to implement it, the road ends there. According to another post, DSP software has been produced for a popular chip. It just needs implementation.
Interesting times for Video on the Web Posted Apr 12, 2010 19:56 UTC (Mon) by robswain (subscriber, #61516) [Link]
FFmpeg's Theora decoder is already well optimised for ARM (~10% faster than TheorARM with current ARM cores), though it is LGPL which may be an issue for some compared to BSD.
Interesting times for Video on the Web Posted Apr 12, 2010 20:08 UTC (Mon) by gmaxwell (subscriber, #30048) [Link]
Perhaps some development branch is the fast. But the last released ffmpeg was only very slightly faster than libtheora on ARM, in spite of the fact that libtheora had no arm assembly.
In any case, it's equally good news that the ffmpeg decoder has been improving in performance. Google's chrome efforts have apparently done a decent job pushing improvements there. I look forward to seeing improvements in both implementations.
There is also a lot of activity on the java decoder implementation right now, with new work which promises to be considerably faster once its production ready.
Interesting times for Video on the Web Posted Apr 12, 2010 20:45 UTC (Mon) by robswain (subscriber, #61516) [Link]
We expect a 0.6 release in the not too distant future. I think it was actually improvements in the libtheora decoder and competitiveness of some of the devs that lead to the improvements, nothing to do with Chrome.
Interesting times for Video on the Web Posted Apr 13, 2010 8:06 UTC (Tue) by DonDiego (subscriber, #24141) [Link]
> The last released ffmpeg was only very slightly faster than libtheora on
> ARM, in spite of the fact that libtheora had no arm assembly.
Current FFmpeg is faster than libtheora on both ARM and x86.
> In any case, it's equally good news that the ffmpeg decoder has been
The Chrome people contributed a few bug fixes, but no speedup work. Go thank David Conrad for writing the code and me for triggering everybody's competitiveness.
Interesting times for Video on the Web Posted Apr 12, 2010 22:02 UTC (Mon) by jebba (✭ supporter ✭, #4439) [Link]
Nokia did a version of Ogg Vorbis that was optimized for ARM. Unfortunately, they kept the code to themselves.
https://bugs.maemo.org/show_bug.cgi?id=176
Interesting times for Video on the Web Posted Apr 13, 2010 7:59 UTC (Tue) by bawjaws (guest, #56952) [Link]
Are you sure? I scanned that bug and couldn't see anything like that.
I was under the impression that the Nokia situation involved them refusing to include Vorbis or Theora codecs out-of-the-box. (They also protested against Theora in HTML5, saying it was "proprietary" and was unsuitable as it couldn't do DRM). It would seem strange for them to be putting effort into optimizing codecs they weren't planning to ship.
They seem to have changed their stance on Vorbis at least as part of the Meego merge.
Interesting times for Video on the Web Posted Apr 13, 2010 16:33 UTC (Tue) by jebba (✭ supporter ✭, #4439) [Link]
They did ship them, if putting them in the repo is "shipping" (it's not on the device by default). Originally they weren't available at all (when that bug was started). But the codec is in the non-free repo--it doesn't come with source.
Interesting times for Video on the Web Posted Apr 13, 2010 19:53 UTC (Tue) by bawjaws (guest, #56952) [Link]
That's very odd behaviour. I can't find any mention of their non-free Vorbis, maybe it's been superceded by a free version. But I did find that they also have a closed source fork of the Speex codec
.
There is a chance it's not their fault, the Theora DSP work linked above has a comment about how they could make it go faster if they used some more facilities provided by the TI Hardware but if they did they would not be able to release it as open source because of some kind of legal problem. Maybe they hit the same issue with Vorbis?
Interesting times for Video on the Web Posted Apr 13, 2010 20:35 UTC (Tue) by jebba (✭ supporter ✭, #4439) [Link]
Actually, you have refreshed my memory. It was speex (with optimizations) not vorbis that I was thinking of. Sorry for the misinfo. Vorbis is in free (AFAICT) and speex is in non-free.
no, 2016 will be "Interesting times for Video on the Web" Posted Apr 12, 2010 22:09 UTC (Mon) by b7j0c (subscriber, #27559) [Link]
that is when the MPEG-LA no-look/no-tell grace period ends on h264 use and the they start enforcing the patent in ernest. get ready for the GIF debacle all over again
they would have started this year but the MPEG-LA wasn't convinced that h264 had a lock on the market.
google to open source VP8 Posted Apr 12, 2010 23:51 UTC (Mon) by Webexcess (subscriber, #197) [Link]
Seems related to this article
http://newteevee.com/2010/04/12/google-to-open-source-vp8...
google to open source VP8 Posted Apr 13, 2010 3:54 UTC (Tue) by Kit (guest, #55925) [Link]
That just makes this whole situation make even less sense! If Google was already planning on open sourcing VP8 (and, I assume, a patent pledge), then why bother with Theora? It would seem that Google would want to get VP8 support into Chrome, Firefox, and YouTube (at a minimum) as soon as possible, and try to kill of Theora in an attempt to prevent a multiplication of codecs.
---
For that matter, what *audio* codecs does the video tag support anyways? I'd assume it's currently Vorbis/Theora and AAC/H264, but what would VP8 be paired with?
google to open source VP8 Posted Apr 13, 2010 7:52 UTC (Tue) by njs (guest, #40338) [Link]
There have been rumours about Google open-sourcing VP8 for months; I'll believe it when I see an announcement from Google, not yet another "my private sources claim" like that article. Hopefully we're just waiting for them to transcode Youtube or something to make the announcement more exciting, but it's a curiously long silence.
That said, even if they do release VP8, I can certainly see benefits to putting resources into both it and Theora. "But there's nothing out there in VP8!" "Yeah, but there is in Theora, you can use that." "But Theora isn't as good as H.264!" "Yeah, but VP8 is, you can use that." Repeat until critics are dizzy and confused. (I'm joking... I think?)
Presumably VP8 would be paired with Vorbis? Does anyone even have any real complaints about Vorbis?
google to open source VP8 Posted Apr 13, 2010 8:12 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]
besides which, can't you just see what the cry would be if they opened VP8 and didn't also support Theora?
"Google is an evil monopoly pushing their solution on everyone else" or words to that effect.
supporting both, while running the risk of fragmentation between the two options also means that if anything happens with one of them people still have the option of using the other.
google to open source VP8 Posted Apr 13, 2010 13:43 UTC (Tue) by SEJeff (subscriber, #51588) [Link]
But some people will always hate other people/companies more successful than themselves. In reality, if google open sources VP8 and ends the "IE/Safari vs Mozilla" war over the codec for html5, they are a win for interoperability and the net as a whole.
VP8 will be open-sourced, but it'll not end the debate Posted Apr 14, 2010 6:46 UTC (Wed) by khim (guest, #9252) [Link]
I'm pretty sure Microsoft finally accepted H.264 because of Google's On2 acquisition. They hoped for the long time to push their own proprietary standard, but when faced with possibility of getting free one they decided that patent-encumbered standard is not as good as Microsoft-controlled one but still better then FOSS-friendly free VP8.
I'm pretty sure speech-writers in both Apple and Microsoft are investigation right now the ways to present refusal of VP8 as boon to the users. We'll be interesting to see what they cook up - what I'm not expecting is acceptance of the free codec.
VP8 will be open-sourced, but it'll not end the debate Posted Apr 14, 2010 12:06 UTC (Wed) by SEJeff (subscriber, #51588) [Link]
But no matter what Micro/Apple say... If Google makes VP8 the preferred codec for youtube and gently nudges *cough* forces users to start using it more then there isn't much of anything the dynamic duo can do.
Users will freak out if youtube stops working. Where else will they find videos of dogs skateboarding?
google to open source VP8 Posted Apr 13, 2010 13:35 UTC (Tue) by bawjaws (guest, #56952) [Link]
There's so many possibilities that there's not much benefit in speculating until Google actually shows their hand. It could get even more confusing than it is now.
Will they release VP6 and 7? The former is supported in Adobe Flash and the latter is used in Skype. VP8 isn't used anywhere yet, therefore backwards compatibility is moot, so will Google rewrite the spec to suit their own particular needs and plans? Have they had time to do that yet, or are they just going to announce what they're planning to do over the next few years?
Despite many geeks focussing on the simplistic comparisons of complex and tricky benchmarks, the business relationships are going to make or break any new codec just like they have done for MPEG codecs. Are the patent worries real or is that just a convenient smokescreen for companies that have decided to throw their lot in with MPEG because there isn't corporate-friendly competitor? I guess we'll find out.
My personal guess is that freeing VP8 as-is would only make sense if they convince Adobe to roll out support in Flash. Otherwise they'd be best playing the long game and getting a royalty-free standard based on it passed by ISO or whoever.
There's some good analysis of what freeing VP8 would involve here:
http://blog.gingertech.net/2010/02/20/googles-challenges-...
Regarding your question on Vorbis, I believe it's the only real candidate for such a role, it is technically very good and I've seen people who are incredibly paranoid about video patents have no issue with it. I'm surprised more fuss wasn't made about this at the time it was removed from the spec. It appears that on the web audio only matters if accompanied by video.
google to open source VP8 Posted Apr 15, 2010 0:57 UTC (Thu) by kjp (subscriber, #39639) [Link]
I think Google should petition the FCC to buy out the H264 patents and set them free.
|
|
||||||||||||