Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Wonderful news!

Allow streaming and URL connections, and there's no stopping iOS.

You got to love the VideoLan team for this. I think they should charge us for this, give these guys the means to continue supporting the Mac and iOS.
 
Apple makes a ton of money on hardware, yes. But Apple does indeed makes money off of the content ecosystem. They wouldn't be in the business if it didn't make them money.

As of 2007, billboard seems to think they were operating on a profit.
http://news.cnet.com/8301-13526_3-9894585-27.html

Writing black numbers is not exactly the same as making a profit worth mentioning on something. Apple's doing the mediastuff to sell Hardware. There are the big margins for them.
 
Cool. I use yxplayer to watch avi, wmv, flv, etc on the iPad and it works surprisingly well, hopefully VLC will be even better.
 
Great news, VLC manages to play everything. I wish all players were as consistently reliable as VLC is.
 
I'm stunned.

This is fantastic news.

I've converted a load of stuff for the ipad with handbrake for long flights etc but to get access to a lot of my older avi's without converting would be great.

Cinexplayer etc only plays the DIVX codec within the avi container, most of mine seem to be h.264, frustrating to have to convert the codec just to change the container.

Unless I'm being dumb when I have to handbrake them.

Anyway, VLC as a backup even in software will be ace. We'll soon see how good that A4 chip is.

I wonder if those containers, as long as they contain H.264 video, will be hardware accelerated?

Does anyone know if Perian within QT hardware decodes h.264 in the mkv/avi container?

If so, its not beyond the realms of possibility that VLC would have access to h.264 acceleration too.
 
And seriously, there's no proof that this app will drain more battery than the iPhone's video player. VLC on Mac and Quicktime X, one being GPU accelerated and the other not, don't have much different power draws. You have no tests that can even show what it is you're claiming as fact. Hence, you have no facts.

What the heck is wrong with you and your attitude?

For those of us who have even the slightest digital logic design experience, it's a given that hardware acceleration for a computationally expensive algorithm, when done reasonably correctly will always win out over a plain CPU in power and throughput. (yes, it's possible for software to beat out hardware when one has different and crappier design, but that's obvious too)

Want an actual example? Here's a sample size of one.
http://forum.thinkpads.com/viewtopic.php?f=2&t=83880

That's a guy using a Broadcom Crystal HD H264 coprocessor measuring the laptop's run time off battery. Obviously the percentage increase is much smaller on a laptop since there's so many more power hungry components that don't change. From what I hear, the coprocessor around 1 - 2.5 watts. A Core2 Duo is many times that at idle, and over 10X that with a full pipeline.
So even without basic arithmetic, it's obvious that coprocessor wins out versus CPU.

Certainly the raw numbers involved are smaller, but it all scales.
A Cortex A8 is like 2W at 100% utilization, and milliwatts completely idle.
A PowerVR SGX is also around 2W at 100% and ~70 milliwatts idle.
Since they're practically the same numbers, if the SGX does the job using less time than the A8, it spends less energy.

(numbers for the chips can be found online somewhere, these are rough estimates off to top of my head)

Really, why do 3D games using the GPU drain my laptop battery ?

Because 3D games render the scene using the GPU, and process game logic on the CPU. In other words, using 2 processors at full blast spends more than 1 processor. Example? Supreme Commander uses the CPUs to handle the physics for all of the weapons fired, and uses the GPU to handle drawing all 400+ units in your army and all who-knows-how-many missiles and particle beams are in flight. Hence it's a decent benchmark for 4+ core systems with decent GPUs running a RTS on two screens.
 
:rolleyes: You state this as fact. Do you have any backing for these assumptions? :D

The site's FAQ good enough for you ? :rolleyes:

https://macrumors.zendesk.com/hc/en...nd_negative_ratings_on_the_front_page_mean.3F

Yes, I don't just state things as facts unless I can provide some backup evidence.

What the heck is wrong with you and your attitude?

What is wrong with asking for simple evidence to back up a claim ? :rolleyes:

What is wrong with you and your attitude ? We should just accept any bozo making a claim as fact as the truth ?

(And besides, video decoding is one part of this app, while your post is clearly the first with some technical merit showing reduced battery life in a clear and objective way due to hardware acceleration, we still have to address the issue of real world battery drain. Video players do more than just decode video, and as such, the real world power draw would be on either the CPU 100% or on both the CPU and GPU at the same time.

For the people who lost it, this all came about because a poster said this was a negative because it wouldn't use hardware video decoding and as such would be a huge battery drain. Without ever showing that software video decoding on iOS does actually result in a real world augmented battery drain and that such a drain is a justification for rejecting the app (it never is btw, I stated earlier that I am the only one that should be allowed to chose whether my battery drains or not, not Apple)).
 
The site's FAQ good enough for you ? :rolleyes:

https://macrumors.zendesk.com/hc/en...nd_negative_ratings_on_the_front_page_mean.3F

Yes, I don't just state things as facts unless I can provide some backup evidence.



What is wrong with asking for simple evidence to back up a claim ? :rolleyes:

What is wrong with you and your attitude ? We should just accept any bozo making a claim as fact as the truth ? )).

Any bozo? You have a dozen people all saying the same thing.

What is wrong with asking for simple evidence to back up a claim? When that claim is common knowledge. It would be like you asking for evidence that the earth is round.

Facts

Watching a movie in VLC on a Mac laptop drains more battery than watching a movie in QuickTime with GPU video decoding.

Watch flash 10 drains more battery than flash 10.1 with GPU acceleration.

Watching xvid/divx with cinexplayer or xyplayer on iPad drains more battery than QuickTime.

Gaming is far more gpu intensive than video decoding, which is why it's a mofo on your Mac. Try modern gaming without a GPU, it'll make your computer explode, even with a 12-core mac pro.
 
For the people who lost it, this all came about because a poster said this was a negative because it wouldn't use hardware video decoding and as such would be a huge battery drain. Without ever showing that software video decoding on iOS does actually result in a real world augmented battery drain and that such a drain is a justification for rejecting the app (it never is btw, I stated earlier that I am the only one that should be allowed to chose whether my battery drains or not, not Apple)).

No one lost it because they thought a drain is justification for rejecting the app. As said repeatedly, there are many apps that do exactly the same thing as VLC and they've been accepted. These apps do drain battery much quicker than the default player.

People are losing it because you are asking them to back up claims that are common knowledge and is considered a fact by everyone with even the most basic understanding of computing.
 
People are losing it because you are asking them to back up claims that are common knowledge and is considered a fact by everyone with even the most basic understanding of computing.

My most basic understanding of computing tells me that Video players are not video decoders. There is much more going on. My first comment on this issue talked about real world numbers.

The first post to address this basically said the ARM core in current shipping iOS devices and the PowerVR SGX have basically the same power draw of 2W. It remains to be seen how much processing is actually saved by offloading only the decoding to the PVR chip as all other player functions (input, file i/o, overlays, drawing) would still depend on the CPU or tax the GPU more pushing it closer to its peak.

You say it's known fact. Fine, show us the numbers. How many minutes per percent or seconds per percent does offloading video decoding only from the A4 to the SGX saves ? Known facts right, should be easy to get some decent numbers up.

That's what I mean by backing up your "facts". Before you go claiming this will be a huge battery drain, at least try to have some objective info. This is what the initial post I was replying to claimed. VLC on iOS would be a huge battery drain.

I'm happy a few users decided to reply with actual material, even though none of it addressed real world issue, rather than just bash me outright for asking the tough question.
 
Great news!!! I hope that this also feeds some code back into the Mac version of VLC, they haven't had anyone maintaining that port for a long time now (zero developers!). It was even slated to be discontinued or at least not updated anymore.
 
My most basic understanding of computing tells me that Video players are not video decoders. There is much more going on. My first comment on this issue talked about real world numbers.

The first post to address this basically said the ARM core in current shipping iOS devices and the PowerVR SGX have basically the same power draw of 2W. It remains to be seen how much processing is actually saved by offloading only the decoding to the PVR chip as all other player functions (input, file i/o, overlays, drawing) would still depend on the CPU or tax the GPU more pushing it closer to its peak.

You say it's known fact. Fine, show us the numbers. How many minutes per percent or seconds per percent does offloading video decoding only from the A4 to the SGX saves ? Known facts right, should be easy to get some decent numbers up.

That's what I mean by backing up your "facts". Before you go claiming this will be a huge battery drain, at least try to have some objective info. This is what the initial post I was replying to claimed. VLC on iOS would be a huge battery drain.

Since there are players in the app store now that do the same thing as VLC, it's not some hypothetical situation.

I get 7-8 hours of playback using CineXPlayer/YXPlayer vs 12 hours using Quicktime.

It doesn't matter that the PowerVR has a max draw of 2W, decoding video will not use even a quarter of that power.
 
It doesn't matter that the PowerVR has a max draw of 2W, decoding video will not use even a quarter of that power.

There are 2 questions that need answering. One is how much of a power draw is h.264 decoding at a given bit rate (these are important factors, lesser bit rates will require less processing per frame, thus per second) on the PowerVR SGX chip ? The second question is the most important, how much of a power draw is it removing from the A4 chip for the same video encoded at the same bit rate ?

If you want to quantify the power draw as "Huge Battery Drain", let's see some numbers.

Also, you say Cinexplayer allows for 7-8 hours of video playback, while Quicktime does 12. What were your parameters for testing this ? Same video ? Same bit rate ? Obviously you didn't stand there the whole time, what timeframe were these figures extrapolated from, 30 seconds ? A minute ?

All facts that are easy to prove it seems, yet people still claim "Huge Battery drain" without ever even trying to quantify or having an idea what the actual drain is. :rolleyes:

It might sound pedantic, but I'm pretty tired of people going "Huge Battery Drain" in every thread where someone posts about some cool new software coming to iOS.

Great news!!! I hope that this also feeds some code back into the Mac version of VLC, they haven't had anyone maintaining that port for a long time now (zero developers!). It was even slated to be discontinued or at least not updated anymore.

I'm looking at the VLC home page right now and the current version is 1.1.4 for OS X. For Windows, it's ... 1.1.4.

Oh right, everyone read about how the project got abandonned but everyone forgot to read the follow article by the devs which stated that was a very gross exageration and that they were only rewriting the UI and had moved all devs to the new UI project. :rolleyes:
 
I'm not sure on this one, but isn't MKV just a container? So if the MKV contained h264 (or other hardware-accelarated codecs), wouldn't that get hardware-acceleration as well?

If you open a mkv file with QuickTime 7.6.6 under Snow Leopard, and you have the Perian plugin installed, Perian uses the QuickTime H.264 hardware decoder to decompress the video stream, and a software decoder to decompress the AAC stream. I do not think, that it is a problem to watch 720p mkv files (with H.264/AAC streams within the mkv container) on newer iOS devices.
 
Apple states that you can watch videos on the iPad for about 10 hours; video's which are played via hardware acceleration.
If you are going to watch DivX, XviD, MKV, whatever else, on an iOS device, the CPU of said device is going to have to handle *all* of the encoding, which is going to drain the battery like hell.
So instead of 10 hours of video watching pleasure, maybe you'll get 2 or 3.
Granted, you can fix this by using an extra battery or whatnot, but that seems suboptimal to me :)

A song comes to mind to solve the battery issue: "Plug it in, plug it in."

One reason they might reject it is that Apple has a clearly-stated policy that any app that does video streaming must use HTTP Live Streaming. This was later amended to mean any app that streams video for more than 10 minutes over the cellular network. So it might be that streaming of other formats would have to be wi-fi only.

I could live with wifi streaming. I'd kill for any kind of streaming.
 
Question is, does it use the VLC codec libraries (ffplay etc) or Apple's own codecs.

Also, does it use the iPad's DSPs, if not you wont get hardware acceleration, have fun trying to play your SD videos.

VLC is already optimized for ARM-based platforms, and uses some hardware units for video decoding. One of the slowest steps if you try to decode a video stream is the inverse discrete cosine transformation or short iDCT. Last time i looked at the source code of ffmpeg, i did see, that they use idct instructions from some ARM-processors. If these instructions are also available on the A4-processor (it has an unknown ARM-core) video decoding should be much faster. This includes all DCT-based video compression algorithms like MPEG-2 or H.264.
 
Pity they are making an iPad version and they can't even get one developer who is willing to work on the Mac version. Where are the priorities? They would rather support a new platform (iOS) rather than support a legacy platform that's becoming the number 1 requested computer platform. :rolleyes:
 
images
 
Here's the reason why Apple may reject VLC for iOS 4.0: it may encourage the playback of illegal copyrighted content on the iPad. Remember, many fansubbed foreign TV shows are encoded in the .MKV format (though many fansubbers are now switching to the .MP4 format, which will usually work with the iTunes playlist and as such could be copied to an iPad if you use a resolution under 1024x768), and VLC is a favorite software player to play back fansubbed shows, especially on faster machines.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.