[svn 5126, MacGUI]

[mac_man_ad]

HI All,

With the recent x264 profile et. al. changes, should I be getting 32 ref frames in the Unparse when using veryslow and animation? Only the preset and tune show in the log when the encode starts, so I assume x264 itself is cool, just the Unparse being odd?

Code: Select all

[21:23:33] job configuration:
[21:23:33]  * source
[21:23:33]    + /Volumes/Recordings/Chobits Disc 1
[21:23:33]    + title 28, chapter(s) 1 to 6
[21:23:33]  * destination
[21:23:33]    + /Users/***/Desktop/tmp tv shows/Chobits Disc 1-28.m4v
[21:23:33]    + container: MPEG-4 (.mp4 and .m4v)
[21:23:33]      + chapter markers
[21:23:33]  * video track
[21:23:33]    + decoder: h264
[21:23:33]      + bitrate 200 kbps
[21:23:33]    + frame rate: same as source (around 29.970 fps)
[21:23:33]    + filters
[21:23:33]      + Framerate Shaper (0:27000000:900900)
[21:23:33]        + frame rate: same as source (around 29.970 fps)
[21:23:33]      + Subtitle renderer (0:0:0:0)
[21:23:33]      + Crop and Scale (1920:1080:0:0:0:0)
[21:23:33]        + source: 1920 * 1080, crop (0/0/0/0): 1920 * 1080, scale: 1920 * 1080
[21:23:33]    + strict anamorphic
[21:23:33]      + storage dimensions: 1920 * 1080, mod 16
[21:23:33]      + pixel aspect ratio: 1 / 1
[21:23:33]      + display dimensions: 1920 * 1080
[21:23:33]    + encoder: H.264 (x264)
[21:23:33]      + x264 preset: veryslow
[21:23:33]      + x264 tune: animation
[21:23:33]      + quality: 20.00 (RF)
[21:23:33]  * subtitle track 1, English (track 0, id 0x1200) Picture [PGS] -> Render/Burn-in
[21:23:33]  * audio track 1
[21:23:33]    + decoder: Japanese (TrueHD) (2.0 ch) (track 4, id 0x721101)
[21:23:33]      + bitrate: 200 kbps, samplerate: 48000 Hz
[21:23:33]    + mixdown: Stereo
[21:23:33]    + encoder: AAC (CoreAudio)
[21:23:33]      + bitrate: 160 kbps, samplerate: 48000 Hz
[21:23:33]  * audio track 2
[21:23:33]    + decoder: English (TrueHD) (2.0 ch) (track 2, id 0x721100)
[21:23:33]      + bitrate: 200 kbps, samplerate: 48000 Hz
[21:23:33]    + mixdown: Stereo
[21:23:33]    + encoder: AAC (CoreAudio)
[21:23:33]      + bitrate: 160 kbps, samplerate: 48000 Hz

(Once HB Preset support works, this'll replace my current hand-made advanced option version of this combination)

Regards, Andrew

[Deleted User 11865]

Hmm… I hadn't though about that. I'm not sure we can do much about this. What happens is:

1) --x264-preset veryslow sets refs to 16

2) --x264-tune animation doubles the ref count to 32

3) we unparse

4) libx264 sanitizes this before encoding

(4) does a great many things, some of which we don't want before (3), so we can't hack it to run before we unparse.

It's not such a big deal though, as (4) does happen anyway.

[JohnAStebbins]

This is kind of a bug in x264_param_apply_tune(). I wonder if x264 would accept a patch to fix it?

libx264 calls the static function x264_validate_parameters() first thing when we call x264_encoder_open(). x264_validate_parameters() appears to do all the work to sanitize things. Aside from reducing some fractions (i_fps and i_timebase), I don't see any other param values being changed in x264_encoder_open(). So we could conceivably open and close the encoder to force the validation.

It would be better if we could convince x264 to expose x264_validate_parameters(). Unfortunately, in it's current form, it does a combination of validation and initialization of x264_t which is all kinds of f*cked up. My proposal would be to create a static internal function that takes both x264_t and x264_param_t as parameters and performs the validation/initialization. But, if x264_t is NULL, it only does validation.Then make a new function that is public that calls this function with a NULL x264_t. This would be a fairly unintrusive change to current code.

[Deleted User 11865]

It would be better if we could convince x264 to expose x264_validate_parameters(). Unfortunately, in it's current form, it does a combination of validation and initialization of x264_t which is all kinds of f*cked up.

Which is why we can't fix this by a simple open/close.

[JohnAStebbins]

Which is why we can't fix this by a simple open/close.

I don't understand this comment. What happens that we would not want to happen?

[mac_man_ad]

Encode over, and MediaInfo shows 16 ref frames, so this bug is functionally a non-issue.

Cheers All (and sorry this thread has a not very useful name)

[Deleted User 11865]

Which is why we can't fix this by a simple open/close.

I don't understand this comment. What happens that we would not want to happen?

open() -> x264_validate_parameters() -> combination of validation and initialization of x264_t which is all kinds of f*cked up -> close()

Or did I miss something?

[JohnAStebbins]

You still haven't told me what the problem is with that sequence. Yes, it retarded, but it should work to sanitize the params.