View Full Version : iXXXXX - Apple Products and x264 encoding vs battery life (CPU usage)
Mr. Monte
25th June 2010, 20:21
I just recently purchased an iPad and want to re-encode some of my movies to load to it.
I understand certain X264 switches affect CPU usage, which can affect battery life.
Could someone advise which x264 options effect decoding CPU/Battery life the most and which ones I should keep for video quality.
I encoded the below movie with two encoding GUI's/SW
[spam] (has a iPad profile)
I selected the iPad HD profile, but adjusted the bitrate to 2500 from 3500. Here is the Media Info.
Format : MPEG-4
Format profile : Base Media
Codec ID : isom
File size : 2.61 GiB
Duration : 1h 54mn
Overall bit rate : 3 252 Kbps
Encoded date : UTC 2010-06-23 00:37:34
Tagged date : UTC 2010-06-23 00:37:34
Writing application : Lavf51.12.1
Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : Baseline@L3.1
Format settings, CABAC : No
Format settings, ReFrames : 1 frame
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 1h 54mn
Bit rate mode : Variable
Bit rate : 3 119 Kbps
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 29.970 fps
Original frame rate : 24.000 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.113
Stream size : 2.50 GiB (96%)
Language : English
Encoded date : UTC 2010-06-23 00:37:34
Tagged date : UTC 2010-06-23 00:37:34
Audio
ID : 2
Format : AAC
Format/Info : Advanced Audio Codec
Format version : Version 4
Format profile : LC
Format settings, SBR : No
Codec ID : 40
Duration : 1h 54mn
Bit rate mode : Variable
Bit rate : 128 Kbps
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 KHz
Stream size : 105 MiB (4%)
Language : English
Encoded date : UTC 2010-06-23 00:37:34
Tagged date : UTC 2010-06-23 00:37:34
Here's the same movie encoded with Ripbot using the AppleTv profile I modified
Format : MPEG-4
Format profile : Base Media
Codec ID : isom
File size : 2.29 GiB
Duration : 1h 54mn
Overall bit rate : 2 863 Kbps
Encoded date : UTC 2010-06-24 05:17:38
Tagged date : UTC 2010-06-24 05:17:38
Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : Main@L3.0
Format settings, CABAC : Yes
Format settings, ReFrames : 3 frames
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 1h 54mn
Bit rate mode : Variable
Bit rate : 2 731 Kbps
Maximum bit rate : 12.6 Mbps
Width : 1 280 pixels
Height : 536 pixels
Display aspect ratio : 2.35:1
Frame rate mode : Constant
Frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.166
Stream size : 2.19 GiB (95%)
Title : greenzone 720p ipad crf 22 100
Writing library : x264 core 98 r1649 20cbe10
Encoding settings : cabac=1 / ref=3 / deblock=1:-2:-2 / analyse=0x1:0x131 / me=umh / subme=7 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=0 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=12 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / constrained_intra=0 / bframes=3 / b_pyramid=0 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / weightp=2 / keyint=240 / keyint_min=24 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=crf / mbtree=1 / crf=22.0 / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / vbv_maxrate=10000 / vbv_bufsize=10000 / crf_max=0.0 / ip_ratio=1.40 / aq=1:1.00 / nal_hrd=vbr
Encoded date : UTC 2010-06-24 05:17:38
Tagged date : UTC 2010-06-24 05:19:44
Audio
ID : 2
Format : AAC
Format/Info : Advanced Audio Codec
Format version : Version 4
Format profile : LC
Format settings, SBR : No
Codec ID : 40
Duration : 1h 54mn
Bit rate mode : Variable
Bit rate : 128 Kbps
Maximum bit rate : 134 Kbps
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 KHz
Stream size : 105 MiB (4%)
Title : Imported with GPAC 0.4.6-DEV (internal rev. 5)
Language : English
Encoded date : UTC 2010-06-24 05:19:21
Tagged date : UTC 2010-06-24 05:19:44
What I noticed is the [spam] uses only 1 bframe and noCABAC.
So, will my version with Ripbot use more CPU/Battery life and by how much?
:thanks:
Atak_Snajpera
25th June 2010, 20:34
Here's the same movie encoded with Ripbot using the AppleTv profile I modified
I reckon you mean iPAD profile ;)
What I noticed is the [spam] uses only 1 bframe and noCABAC.
it should be r-frame not b-frame ;)
Also i don't understand why you encode to 1280x... . Native resolution is only 1024x600. I would stick to 720x576 or 720x480.
If I were you I would just check which file will play longer in loop. BTW. first encode has incorrect fps of 29.97! Also make sure that both videos have the same kbps.
Mr. Monte
25th June 2010, 21:14
Atak,
You are correct on both statements.
I could fully charge and then play in loop (I'll have to see how to do that with video files, I do not see an option to loop.)
Until multi-tasking is added to ipad this fall...no way I know of to look at CPU usage during decode.
Was just curious what has the biggest impact on decoding ( # of bframes, # of reference frames, does CABAC effect decoding or just encoding?) etc..etc
Thanks
nurbs
25th June 2010, 21:24
At a set resolution and framerate CABAC and deblocking have the biggest impact on decoding speed. Time spent on CABAC decoding is proportional to bitrate. Then there is weighted b and p prediction, but I don't think you'll gain much speed by turning them off compared to the others. The number of b-frames and reference frames doesn't have a noticeable impact if any.
Atak_Snajpera
25th June 2010, 21:25
oes CABAC effect decoding or just encoding?)
both.
Mr. Monte
25th June 2010, 21:40
I'm confused. The posted Apple specs for iPad are:
H.264 video up to 720p, 30 frames per second, Main Profile level 3.1 with AAC-LC audio up to 160 Kbps per channel, 48kHz, stereo audio in .m4v, .mp4, and .mov file formats; MPEG-4 video, up to 2.5 Mbps, 640 by 480 pixels, 30 frames per second, Simple Profile with AAC-LC audio up to 160 Kbps, 48kHz, stereo audio in .m4v, .mp4, and .mov file formats; Motion JPEG (M-JPEG) up to 35 Mbps, 1280 by 720 pixels, 30 frames per second, audio in ulaw, PCM stereo audio in .avi file format
So, it says supports 720p video, then says resolution of 640x480...then down further says M-JPEG of 1280x720.
The software I used prior to Ripbot (I apparently cannot mention its name here, but we can mention Ripbot, DVD-RB, HConvertX, DivX..etc..etc. Someone thought I was spamming..My iintention was in no way to do that..just wanted someone to know what SW I was using that has a iPad profile built in.)....had 1280x720 for the video for iPad....Atak says it's native is 1024x600....so...where is the math wrong?
nurbs, so you would agree that CABAC on will drain the battery faster than it off. I really did not see a quality difference on or off..so off would be ultimately better?
Thanks
Atak_Snajpera
25th June 2010, 22:02
MPEG-4 video, up to 2.5 Mbps, 640 by 480 pixels, 30 frames per second, Simple Profile
this means MPEG-4 ASP (Divx,Xvid,...)
Atak says it's native is 1024x600....so...where is the math wrong?
As the matter a fact it is 1024x768. Nevertheless encoding to 1280x... still does not make sense.
nurbs
25th June 2010, 22:15
I think when apple says "MPEG-4 video" they mean MPEG-4 SP, but I'm not 100% sure about that.
Your math isn't wrong. The iPad simply has a smaller screen resolution than the maximum playback resolution it supports so your 720p files will be downscaled on playback.
I have no idea how much CABAC costs in decoding, especially on hardware. CABAC gives you at least around 10% to 15% higher compression efficiency in typical scenarios and it's benefit becomes greater (http://akuvian.org/src/x264/entropy.png) at high QP (low bitrate) for a given source. If you turn it off you'll also lose trellis and psy-trellis. Personally I wouldn't turn anything off. I'd also try to encode high profile since there are several reports that the newer iPhone/iPad/iPod Touch versions can handle 8x8dct without problems and apple is just being dicks as usual by not officially supporting a H.264 feature that gives a big compression gain at almost 0 decoding speed cost. I think the developers have stated it has the best gain to speed cost ratio in the H.264 standard.
Yes, the current iPod touch does x264 High Profile just fine, the only limitations are reference frames and resolution (level 3.0 on touch 3G, level 3.1 on iPad).
You should try the handbrake forum for compatibility questions on iDevices. They discuss these issues a lot.
Blue_MiSfit
25th June 2010, 23:52
It shouldn't matter, really. I'm almost totally sure the iPhone / iPad devices have ASICs that handle decoding for it. AFAIK, power usage should be pretty linear across the board.
I'm not 100% sure though :)
~MiSfit
CruNcher
26th June 2010, 13:25
I loughed not bad to see that my Archos 5IT is more Powerfull then the IPAD :)
especially seeing of course the Price difference Hardware wise (i never gonna understand People who buy Apples to expensive Gadgets)
Mr. Monte
26th June 2010, 15:26
It shouldn't matter, really. I'm almost totally sure the iPhone / iPad devices have ASICs that handle decoding for it. AFAIK, power usage should be pretty linear across the board.
I'm not 100% sure though :)
~MiSfit
I guess all I can do is try it. Gonna take some time to encode the same movie with all those different options and then run it multiple times to measure battery life.
THanks,
Lam3rD
26th June 2010, 16:26
You don't need an entire movie, just go with the most complex 5-20 minutes of it. :)
Reimar
26th June 2010, 18:59
It shouldn't matter, really. I'm almost totally sure the iPhone / iPad devices have ASICs that handle decoding for it. AFAIK, power usage should be pretty linear across the board.
Not sure what you mean by "linear", but memory accesses tend to be somewhat costly on mobile devices, so at least resolution and bitrate should change power consumption.
For the same reason, more B-frames could mean higher power usage (more reference data to read), however using them also decrease bandwidth.
CABAC also decreases bandwidth, so with hardware decoders may actually save power.
I guess all this is just a long-winded way of saying: testing is probably the only way to figure out (though personally I expect there won't be any significant difference either way).
Mr. Monte
26th June 2010, 21:48
Reimar,
I hope your correct. I would love to use the highest settings to achieve picture quaility and reduced filesize. This would allow me the ability to load more movies.
Mr. Monte
5th July 2010, 18:28
Well it took some time..did it a few times to make sure I was as accurate as could be.
Test Subject: Apple iPad 3G/WiFi 32 Gig Model (2010)
Test Conducted: To see how much if any the x264 encoding switches had on battery life due to high decoding demands
Test Conditions: Battery charged for 12 hours before each test, reading 100% on screen. Movie Used: Das Boot (242 minute - 4:41:51) 6,399,282 KB
Encode movie @ CRF 23 with RipBot at both ends of the spectrum (pertaining to x264 switches to facilitate the easiest decode to the close to hardness decode. To do this I used two x264 profile (ultrafast & slow (with deblock set to -2,-2). See below for all info:
Ultrafast Profile: (finished encoded size 4,610,088)
General
Complete name : C:\Users\Doug\Videos\iPad Video Project\Das Boot German Uncut 282min ultrafast.mp4
Format : MPEG-4
Format profile : Base Media
Codec ID : isom
File size : 4.40 GiB
Duration : 4h 41mn
Overall bit rate : 2 233 Kbps
Encoded date : UTC 2010-07-01 19:25:56
Tagged date : UTC 2010-07-01 19:25:56
Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : Baseline@L3.0
Format settings, CABAC : No
Format settings, ReFrames : 1 frame
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 4h 41mn
Bit rate mode : Variable
Bit rate : 2 102 Kbps
Maximum bit rate : 18.4 Mbps
Width : 1 024 pixels
Height : 554 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 25.000 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.148
Stream size : 4.14 GiB (94%)
Title : Das Boot German Uncut 282min ultrafast
Writing library : x264 core 100 r1659 57b2e56
Encoding settings : cabac=0 / ref=1 / deblock=0:0:0 / analyse=0:0 / me=dia / subme=0 / psy=1 / psy_rd=0.00:0.00 / mixed_ref=0 / me_range=16 / chroma_me=1 / trellis=0 / 8x8dct=0 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=0 / threads=12 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / constrained_intra=0 / bframes=0 / weightp=0 / keyint=250 / keyint_min=25 / scenecut=0 / intra_refresh=0 / rc=crf / mbtree=0 / crf=23.0 / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / ip_ratio=1.40 / aq=0
Encoded date : UTC 2010-07-01 19:25:56
Tagged date : UTC 2010-07-01 19:29:35
Audio
ID : 2
Format : AAC
Format/Info : Advanced Audio Codec
Format version : Version 4
Format profile : LC
Format settings, SBR : No
Codec ID : 40
Duration : 4h 41mn
Bit rate mode : Variable
Bit rate : 128 Kbps
Maximum bit rate : 135 Kbps
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 KHz
Stream size : 259 MiB (6%)
Title : Imported with GPAC 0.4.6-DEV (internal rev. 5)
Language : German
Encoded date : UTC 2010-07-01 19:28:50
Tagged date : UTC 2010-07-01 19:29:35
Slow Profile with deblock set to -2,-2 (finished encoded size 2,282,191 KB)
General
Complete name : C:\Users\Doug\Videos\iPad Video Project\Das Boot German Uncut 282min Doug custom ipad.mp4
Format : MPEG-4
Format profile : Base Media
Codec ID : isom
File size : 2.18 GiB
Duration : 4h 41mn
Overall bit rate : 1 106 Kbps
Encoded date : UTC 2010-07-02 05:15:20
Tagged date : UTC 2010-07-02 05:15:20
Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L3.0
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 4h 41mn
Bit rate mode : Variable
Bit rate : 973 Kbps
Maximum bit rate : 14.4 Mbps
Width : 1 024 pixels
Height : 554 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 25.000 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.069
Stream size : 1.92 GiB (88%)
Title : Das Boot German Uncut 282min Doug custom ipad
Writing library : x264 core 100 r1659 57b2e56
Encoding settings : cabac=1 / ref=3 / deblock=1:-2:-2 / analyse=0x3:0x113 / me=umh / subme=8 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=12 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=50 / rc=crf / mbtree=1 / crf=23.0 / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00
Encoded date : UTC 2010-07-02 05:15:20
Tagged date : UTC 2010-07-02 05:17:16
Audio
ID : 2
Format : AAC
Format/Info : Advanced Audio Codec
Format version : Version 4
Format profile : LC
Format settings, SBR : No
Codec ID : 40
Duration : 4h 41mn
Bit rate mode : Variable
Bit rate : 128 Kbps
Maximum bit rate : 135 Kbps
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 KHz
Stream size : 259 MiB (12%)
Title : Imported with GPAC 0.4.6-DEV (internal rev. 5)
Language : German
Encoded date : UTC 2010-07-02 05:16:42
Tagged date : UTC 2010-07-02 05:17:16
Drum-roll please :cool:
After 4:41:51
Ultrafast profile battery meter was at 76%
So, based on my calculations
242 minutes consuming 24% of battery = X% per minute
24% / 242 min = 0.0992 % per minute or 5.95% of battery used per hour at this setting. Assuming the iPad shuts off at 15% battery. This would give us a approximate total viewing time of 14.2 hours.
Slow setting battery meter was at 72%
So, based on my calculations
242 minutes consuming 28% of battery = X% per minute
28% / 242 min = 0.1157 % per minute or 6.95% of battery used per hour at this setting. Assuming the iPad shuts off at 15% battery. This would give us a approximate total viewing time of 12.2 hours.
So, as you can see...encoding adds MARGINAL extra battery consumption. I accept that slight increase since I get better picture quality and almost twice the file space !
I know the discharge rates are not linear and that the times will be more like 10 or 9 hours (which is what Apple states)....and that the scenes and action and lighting and blah..blah..blah will effect battery life.
However, this is a very basic, non scientific approximation of the impact of decoding the same movie that was encoded with two opposite sides of the switches.
Hope this helps. It was "fun" :thanks:
Sharktooth
5th July 2010, 18:40
CABAC is all but a battery saver, same for deblocking.
if you want to spare battery just use CAVLC and NO DEBLOCK or just add --tune fastdecode to your encoder options.
Mr. Monte
5th July 2010, 18:46
Shark,
However, based off my testing...it makes very LITTLE difference what you encode with for the iPad..battery life as almost the same
Sharktooth
7th July 2010, 03:26
Mr. Monte some devices have ASICs for h.264 decoding. In that case power draw could not directly depend on how "heavy" are some features to decode.
the iPad may have one.
Blue_MiSfit
7th July 2010, 03:39
As I said, it certainly does, as do all iProducts :)
The A4 CPU in the iPad / iPhone 4 (really a Cortex A8) is pretty quick, but I don't think it can efficiently decode high profile 3.1 without some help ;)
Derek
Sharktooth
7th July 2010, 03:45
Sorry, i missed your post.
Well, if it's the case, then we cant predict what options may influence the battery life unless we know what chip it uses... hoping that's not custom...
diimaan
7th July 2010, 16:35
--tune fastdecode
certainly helps improving playback on mobile devices!
i'm not sure about the support for high profiles...
i think it's main 3.0... the maximum supported... :)
diimaan
7th July 2010, 16:38
this is from this following link
http://www.apple.com/ipad/specs/
TV and video
* Support for 1024 by 768 pixels with Dock Connector to VGA Adapter; 576p and 480p with Apple Component AV Cable; 576i and 480i with Apple Composite AV Cable
* H.264 video up to 720p, 30 frames per second, Main Profile level 3.1 with AAC-LC audio up to 160 Kbps per channel, 48kHz, stereo audio in .m4v, .mp4, and .mov file formats; MPEG-4 video, up to 2.5 Mbps, 640 by 480 pixels, 30 frames per second, Simple Profile with AAC-LC audio up to 160 Kbps, 48kHz, stereo audio in .m4v, .mp4, and .mov file formats; Motion JPEG (M-JPEG) up to 35 Mbps, 1280 by 720 pixels, 30 frames per second, audio in ulaw, PCM stereo audio in .avi file format
Sharktooth
7th July 2010, 17:20
yep, those are the "official" specs. BUT it can play more than main profile... using another non-apple software to upload your vids...
diimaan
7th July 2010, 17:37
but its not 100% advisable to go beyond the recommended specs...
it may play or may not... :)
nurbs
7th July 2010, 17:44
It plays. The only High Profile feature that is commonly used is 8x8dct and that brings a big quality gain at practically no decoding cost. Since you can drop the bitrate a High Profile stream will be easier to decode than a Main Profile stram at the same quality level.
Mr. Monte
8th July 2010, 17:08
yep, those are the "official" specs. BUT it can play more than main profile... using another non-apple software to upload your vids...
I know people have used outside itunes SW to upload movies. However, the switches I used are not all supported in main 3.0. I was advised that as long as I "spoofed" the iTunes into thinking it was main 3.0, which I did..it would transfer them..and it did.
Ritsuka
8th July 2010, 21:37
iTunes let you transfer even high profile. It has some limitations, but they are not the ones of the specs on Apple's site.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.