rMBP late 2013, poor battery performance

[Starfyre]

I wonder if it has anything to do with sandboxing. Maybe applications have to take advantage of it and do it the "Mavericks" way or battery life can't truly be optimal?

 

[tpjunkie]

Just messing around with VLC earlier today makes me suspect that the current version is not fully utilizing hardware decoding, as the playback was not appreciably different between my late '06 MBP with a core 2 duo at 2.3ghz and an ATI 1600 w/ 256MB and my new 2.3 ghz 15" rMBP, plus looking at usage in activity monitor showed no activation of the discrete graphics. There is an option for output using openGL, but its not set by default in the preferences. Checking it didn't really result in any changes for me.

As far as my battery life, it's fairly phenomenal in my estimation. Taking the train from my parents place in NJ to my apartment in NYC, I had virtual box open and was messing around and attempting to set up a virtualized snow leopard environment, and at the end of the 40 minute ride, I think the battery had dropped something like 9%.

 

[fotuwe]

I noticed the high battery impact by vlc as well.
As far as I remember there is a codec pack for quicktime (I forgot the name). Wouldnt that solve our problem? All I actually need is the .mkv playback

 

[Beta Particle]

I noticed the high battery impact by vlc as well.
As far as I remember there is a codec pack for quicktime (I forgot the name). Wouldnt that solve our problem? All I actually need is the .mkv playback

I couldn't get Perian working on Mavericks. They stopped developing it a while ago, and now recommend you use NicePlayer. Unfortunately that didn't work with the videos I was trying to play.

 

[magbarn]

VLC is a cpu 'hog' at least compared to iTunes/quicktime player. Pretty much it uses your cpu for the majority of decoding. IT does support some igpu/dgpu decoding but only for H264 - also it isn't enabled by default, you have to go into the video codec menu and change hardware acceleration from 'default' to VDA

This was copy/pasted from vlc wiki....

Mac OS X

Video Decoding Acceleration (VDA) comes with MacOS X.6.3 and later (see API). This is somewhat supported in VLC 2.1.0.
Only H.264 (MPEG-4 AVC) is supported currently.

In other words any other codec is going to be using your cpu exclusively for decoding which is horribly inefficient.

 

[Verloc]

Movist can use hardware acceleration.

 

[Beta Particle]

VLC is a cpu 'hog' at least compared to iTunes/quicktime player. Pretty much it uses your cpu for the majority of decoding. IT does support some igpu/dgpu decoding but only for H264 - also it isn't enabled by default, you have to go into the video codec menu and change hardware acceleration from 'default' to VDA

It seems that the film I was testing with before was using VC-1. It hadn't occurred to me that Apple might have a problem with VC-1 or MPEG-2.
Copying over an H.264 film and enabling VDA dropped the energy impact to about 30, so it's definitely a lack of hardware acceleration that was causing VLC to drain the battery so quickly.

Unfortunately, while it technically plays, the video was just a mess of pixels with VDA enabled. I don't know what Apple is doing, because the Intel HD4000 in my MacBook Pro should have no problem doing hardware accelerated decoding of H.264, VC-1, or MPEG-2 content - and this was straight from a Blu-ray disc on my media PC, so it's completely untouched, not some shady pirated version. (I buy all my media)

Disabling VDA displayed the video properly, but because H.264 is more demanding than VC-1 to decode, energy impact went up to 90.
Results were the same in MPlayerX, though I didn't see an option to disable VDA there. I'm not surprised that VLC has it disabled by default if it can't even play commercial content properly.