Log in

View Full Version : iPhone 4S encoding settings seem to work in one X264, but not in another?


demistate
14th February 2012, 16:25
I've been encoding an 8-bit tif sequence with 2 encoding GUI's , MeGUI and Handbrake for my iPhone 4S.

The videos that MEGUI's been producing do not seek, show white frames when the Photos application tries to build a seek image bar, and fail to playback when the video freezes when there are a lot of of cuts. The same file encoded in Handbrake works fine (I feed it an uncompressed AVI of the original) Here is the media info for both files. Is there something going on with the settings, or is this an x264 version issue?

MEGUI:

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 3mn 7s
Bit rate : 20.0 Mbps
Maximum bit rate : 33.9 Mbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
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.402
Stream size : 446 MiB (98%)
Writing library : x264 core 120 r2164 da19765
Encoding settings : cabac=1 / ref=4 / deblock=1:-2:-2 / analyse=0x3:0x113 / me=umh / subme=8 / psy=1 / psy_rd=1.00:0.25 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=6,6 / fast_pskip=1 / chroma_qp_offset=-4 / threads=3 / sliced_threads=0 / nr=0 / decimate=0 / interlaced=0 / bluray_compat=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=240 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=50 / rc=2pass / mbtree=1 / bitrate=20000 / ratetol=1.0 / qcomp=0.80 / qpmin=0 / qpmax=69 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / vbv_maxrate=31250 / vbv_bufsize=31250 / nal_hrd=none / ip_ratio=1.10 / aq=1:0.50
Encoded date : UTC 2012-02-13 03:46:28
Tagged date : UTC 2012-02-13 03:47:42
Material_Duration : 16183
Material_StreamSize : 467259456
Material_FrameCount : 4484

And the working file from Handbrake:


Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 3mn 7s
Bit rate mode : Variable
Bit rate : 20.0 Mbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Variable
Frame rate : 23.955 fps
Minimum frame rate : 7.992 fps
Maximum frame rate : 23.981 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.403
Stream size : 446 MiB (99%)
Writing library : x264 core 112
Encoding settings : cabac=1 / ref=3 / deblock=1:0:0 / analyse=0x3:0x113 / me=hex / subme=7 / 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=3 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=2 / keyint=240 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=50 / rc=2pass / mbtree=1 / bitrate=20000 / ratetol=1.0 / qcomp=0.60 / qpmin=3 / qpmax=51 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / aq=1:1.00
Encoded date : UTC 2012-02-14 04:51:38
Tagged date : UTC 2012-02-14 05:12:27
Material_Duration : 187187
Material_StreamSize : 467703328
Material_FrameCount : 4484
Color primaries : BT.709-5, BT.1361, IEC 61966-2-4, SMPTE RP177
Transfer characteristics : BT.709-5, BT.1361
Matrix coefficients : BT.709-5, BT.1361, IEC 61966-2-4 709, SMPTE RP177

Both files were encoded at 1920x1080 at 20Mbps. Apple's Spec page claims that the iPhone 4S supports AVC level 4.1 at High profile. Is the newer x264 not making 4.1 compliant files, or is this a MEGUI issue?

Emulgator
14th February 2012, 20:49
To get the MeGUI encode running I would compare encoding parameters to handbrake.
What jumps into my sight is: try to reduce some parameters in MeGUI:
Number of refs to 3, Bitrate and vbv-bufsize to 16Mbps, max bitrate to 20Mbps.
But I wonder how the same source file can be VFR in Handbrake and CBR in MeGUI... well, I don't know Handbrake.

phibertron
18th February 2012, 18:25
I am currently using HB 0.9.5
They do have there nightly builds also where some things have changed
in regards syntax and for VFR and CFR
But in any case by deafault HB encodes in VFR
unless told not to

Here are the commands from the command line
in the GUI its just a matter of choosing an FPS
Note, choosing "same as source" could produce a VFR
so picking a numeric choice would be needed
and unticking the Peak Framrate VFR option

-r, --rate

Set video framerate (5/10/12/15/23.976/24/25/29.97)
Be aware that not specifying a framerate lets
HandBrake preserve a source's time stamps,
potentially creating variable framerate video

--vfr, --cfr, --pfr

Select variable, constant or peak-limited
frame rate control. VFR preserves the source
timing. CFR makes the output constant rate at
the rate given by the -r flag (or the source's
average rate if no -r is given). PFR doesn't
allow the rate to go over the rate specified
with the -r flag but won't change the source
timing if it's below that rate.
If none of these flags are given,
the default is --cfr when -r is given and --vfr otherwise

Also
When viewing a file with MediaInfo

Youll notice this when using for ex -r 23.976

Frame rate mode : Variable
Frame rate : 23.976 fps
Minimum frame rate : 23.974 fps
Maximum frame rate : 23.981 fps

I once posted in the HB Forum as to why it states Variable
and as to why there are the Min and Max rates
In a nuthsell they partially blame MediaInfo
but also admit, some work would be needed to
make "true" CFR with HB
In any case the CFR produced by HB does work/play well
with clients that wont work with VFR

I have also used MP4Box to remux the video
to see how it would or would not retain its CFR and or VFR state
Havent done it in a while, since I became ok with HB version of CFR
But if memory serves me well I used this command
which leaves all tracks in place, but changes the output to VFR state
I wouldnt do this on a true VFR file the resulting file would not sync right

mp4box.exe source.mp4:fps=23.976 output.mp4

phibertron
18th February 2012, 19:30
Here is that thread on the HB forums
in where I asked about HB CFR showing as Variable

http://forum.handbrake.fr/viewtopic.php?f=6&t=20158

demistate
21st February 2012, 15:46
I'm still not getting a solid answer from anybody.

Here is my guess what the problem could be:

a) Settings used in MEGUI are not actually level 4.1 compliant.
b) the version of x264 used has a bug
c) The Multiplexing software used in MEGUI has some sort of a bug.


The MeGUI file is PS3 compliant and it doesn't even play on a PS3 either.

phibertron
21st February 2012, 17:15
If you compare the Encoding settings
The megui one has these settings that the hb doesnt

bluray_compat=0 / vbv_maxrate=31250 / vbv_bufsize=31250

I dont know megui, but the bluray_compat=0 sticks out to me
If I had to start, that one peeked my interest as where to

Also, the bit rate types are different

Bit rate : 20.0 Mbps
Maximum bit rate : 33.9 Mbps

Bit rate mode : Variable
Bit rate : 20.0 Mbps

And, these are different

ref=4 / ref=3
direct=3 /direct=1

it could be the audio tracks, probably not though

Emulgator
22nd February 2012, 14:58
I'm still not getting a solid answer from anybody.
demistate, what I was trying to say:
Modify MeGUI settings until they fit the playback device.

The MeGUI setting can not be expected to work for every combination of device type / revision vs.encoder revision coming up.
a) Settings used in MEGUI are not actually level 4.1 compliant.
b) the version of x264 used has a bug
c) The Multiplexing software used in MEGUI has some sort of a bug.

a) Level 4.1 compliance is met (to be compared by search),
but this alone does not guarantee playback on a specific chipset (iPhone4S)
that was not even in use when the MeGUI presets where conceived.
And Apple do not tell the more important constraints to the customer.
This would sound too complicated and they prefer to stay white.
b) Rather not.
c) Rather not.

Is it d) Number of refs ? Max. Bitrate ?
This is where chipsets usually may choke.
Let's keep in mind that power consumption alone in such a mini device like a smartphone
sets lower limits to buffersizes, algorithms, bitrates for FullHD decoding, let alone encoding.
It is the compressionist's job to find how far he can go and then: to keep a safe distance.

Battery life is definitely an issue when it comes to marketing.
Google brings 7.880.000 hits when asked for "iphone 4s battery life"
And there is almost no space for this 3.7V, 1420mAh battery.

phibertron tells the same, BTW.

You may just modify MeGUI's settings and use handbrake's parameters as a hint.
And if you get it to play safely in your iPhone4S you may publish these in MeGUI thread as demistate's iPhone4S profile.
(Firmware version of the iPhone4S appended for distinction). Many people will be thankful.

hunter_aran
23rd February 2012, 07:04
My goal is create high-quality files that I can also play on iPhone, iPad, PS3, HTPC, etc. What I did was I just looked at the command line in Handbrake on the preset that I like (I made my own as a modified version of Handbrake's "High Profile" setting) and copied everything into a custom x264 profile I use in MeGUI. Make sure to use 1 B-frame and 3-reframes max. If you use more, iTunes will not even let the file get copied onto your iPhone or if you get it on there another way, it will not play and be scrambled. Also in MeGUI "settings", not x264 settings, make sure to check the box on the "Main" first tab that says "Force Video File Extension for QT compatibility". I believe this puts in the QT "Fast-start" atom that makes seeking work better. When I do these things, I have no compatibility problems in MeGUI. If you remux using a Mac program like Subler, it can also put the QT atom back in if you select "optimize" in the first menu before muxing. Hope this helps.

hunter_aran
23rd February 2012, 07:12
Specs for video on iPhone 4S from Apple's website:

"Video formats supported: H.264 video up to 1080p, 30 frames per second, High Profile level 4.1 with AAC-LC audio up to 160 Kbps, 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 per channel, 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"

One time I, on accident, I had two audio tracks running simultaneously on a video (forgot to mark them in an alternate group) and that kept making the video crash. I thought I was going crazy because I checked and re-checked that I set up the encoder right and then I found out that too many simultaneous audio channels were fouling it up. :rolleyes: