Handbrake --> MediaInfo log --> will it play?

[latet]

Hello,

This is MediaInfo log of the video I encoded using Handbrake. Could you please tell me if there is anything wrong or potentially problematic? Currently I have no access to ant standalone player (or PS3) to check if it plays (not the .mkv file itself, of course, but multiAVCHD BD compilation based on this file).

In the "Encoding settings" of the report there is no mention about vbv_maxrate and vbv_bufsize settings. What could it mean? If Handbrake did not set them (did not force any values) - would any resonable defaults be used?

Thank you!


General
Unique ID : 957605119865689108962676704992474664 (0xB86D93DE026A8C98CB84EBBE6EB628)
Complete name : F:\test3.mkv
Format : Matroska
File size : 546 MiB
Duration : 3mn 37s
Overall bit rate : 21.0 Mbps
Writing application : HandBrake 0.9.5
Writing library : libmkv 0.6.4.1

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L3.1
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 3mn 37s
Bit rate : 20.4 Mbps
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Frame rate mode : Variable
Frame rate : 25.000 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.885
Stream size : 530 MiB (97%)
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=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=50 / rc=crf
/ mbtree=1 / crf=17.0 / qcomp=0.60 / qpmin=3 / qpmax=51 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00

Language : English
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

Audio
ID : 2
Format : AC-3
Format/Info : Audio Coding 3
Mode extension : CM (complete main)
Codec ID : A_AC3
Duration : 3mn 37s
Bit rate mode : Constant
Bit rate : 224 Kbps
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 KHz
Bit depth : 16 bits
Compression mode : Lossy
Stream size : 5.81 MiB (1%)

[nm]

In the "Encoding settings" of the report there is no mention about vbv_maxrate and vbv_bufsize settings. What could it mean? If Handbrake did not set them (did not force any values) - would any resonable defaults be used?
No, you need to set them manually in a custom settings dialog, IIRC.

[vmrsss]

No, you need to set them manually in a custom settings dialog, IIRC.

but then of course you can save the settings as a new profile, once and for all.

Incidentally, I am starting to like Handbrake: I am finding it very good at keeping A/V sync in complex situations (viz., glitches in DVB/S2 broadcast which I haven't yet found an alternative way to deal with on a Mac). And the fact you can compile from SVN means that your underlying engine will be a recent** version of x264 (which is great).

(**) Though I am not yet sure how recent a version, that is whether the Handbrake build process always fetches the latest git for x264

[JohnAStebbins]

but then of course you can save the settings as a new profile, once and for all.

Incidentally, I am starting to like Handbrake: I am finding it very good at keeping A/V sync in complex situations (viz., glitches in DVB/S2 broadcast which I haven't yet found an alternative way to deal with on a Mac). And the fact you can compile from SVN means that your underlying engine will be a recent** version of x264 (which is great).

(**) Though I am not yet sure how recent a version, that is whether the Handbrake build process always fetches the latest git for x264

The handbrake build process doesn't fetch x264 directly from the git repository. We generally tar up a new version within a day or two of a git update, do some testing, then make the new version available. I've never seen this process take more than a week except in circumstances where we find an x264 bug or there is an API change we must adapt to.