Encoding Video for Blu-Ray using H264/AVC

[benwaggoner]

Originally Posted by WorldOfCrap

Welp, that didn't work. Despite passing both Sony and Panasonic's verifier, we're still getting weird stuttering errors on PS4. So I guess scratch that, gotta stick with full-blown x264.

Are you getting the errors playing on a disc or via USB? As a .ts or a full BD disc image?

If it’s BD-R, it’s possible you might have have a burn/media issue.

[mp3dom]

Originally Posted by WorldOfCrap

Welp, that didn't work. Despite passing both Sony and Panasonic's verifier, we're still getting weird stuttering errors on PS4. So I guess scratch that, gotta stick with full-blown x264.

There are stb players (maybe even PS4 at this point) that try to output progressive video (progressive scan) without using the RFF flags as support (they use their own internal routines in realtime).
I saw jerking movements/stuttering mainly on panning with "still text" on it (so, generally opening/endings). If that's the case, there's a solution, but not with x264 (create a stream with a mixture of soft and hard pulldown).

[WorldOfCrap]

@ benwaggoner: We always test via BD-R, but we tried multiple burns on multiple players, and got problems in the same general spot of the program. I also doubt it was an I/O issue because the stream that was playing back was NTSC SD with AC3 audio, so the total bitrate was no more than 5500 kbps.

@ mp3dom: This wasn't an interlaced/progressive issue. In fact, it wasn't happening for the entire stream, but randomly in localized parts of the video, for example, within the same minute. The stuttering was unlike anything I'd ever seen before -- we'd get dropped frames and dropped audio, but seldom at the same time, and although it would stutter in the same general area, it wouldn't be in exactly the same frames each time we played it back. We tried with multiple burns on multiple PS4s, and had the same issues in the same general parts of playback.

Here's some cell phone video my QC guy took, sorry for the low quality:
https://www.dropbox.com/s/emrxio2p5v..._5434.MOV?dl=0

I had the Scenarist team take a look, since I initially thought this was a mux problem with their new v8 release, and they were able to reproduce the problem, but had no idea what was causing it. PS3 had some minor hiccups on those discs (same general spot, similar issue), but PS4 was unwatchable. Re-encoding the video with standard x264 fixed everything.

Unfortunately I don't have the ability to keep trying this, so I'll have to give up on ffmpeg for now. I suspect that SOME essential BD-compliant flag isn't getting passed correctly to x264lib, or isn't implemented in that iteration of x264.

[mp3dom]

Well... the only stuttering I can see from your video is the one on the onscreen text... and it's exactly what I told you before (text from the OP/ED). The very fine/razor text details (especially the razor horizontal border of the text) is making the player go crazy and get fooled because, with its own routines, it still try to output a 60p stream but using the wrong field matching.
You can overcome the problem simply encoding OP/ED with hard-pulldown and the rest with soft-pulldown.
This problem happens using other encoders too, and with other players as well... so it's not a direct x264/PS3-4 problem.

[WorldOfCrap]

Originally Posted by mp3dom

Well... the only stuttering I can see from your video is the one on the onscreen text...

Yeah, not what I was referring to -- I'm aware that there was some interlacing issues there. It's more like full-on drop-outs where the video stops for a good half-second while the audio keeps going, or the audio drops for a half-second or so while the video keeps going. (I'm not sure if that clip captured an incident where the video was affected, but it sure got several incidents with the audio, which was just fine. Again, this cleared after re-encoding the video.)

[kolak]

Maybe your problematic place is at layer break?

[infoeater]

Is it possible to use x264 zones with ffmpeg? If so, how?

[poisondeathray]

Originally Posted by infoeater

Is it possible to use x264 zones with ffmpeg? If so, how?

-x264opts

e.g bitrate multiplier x2 for frames 100-200

-x264opts zones=100,200,b=2

[infoeater]

Thanks,
I used similar command before and it failed. After you wrote it, it started working. You have great power

[WSC4]

First of all, I am not "Authoring" a Blu-ray Disc with x264. The disc will be a data disc of just 10 video files. There will be no BDMV, CLIPINF, PLAYLIST OR STREAM FOLDERS. The videos will be in the root directory on the Blu-ray disc.

Is this still OK to encode with x264?

1080p at 25 fps:

x264 --bitrate XXXXX --preset veryslow --tune film --bluray-compat --vbv-maxrate 40000 --vbv-bufsize 30000 --level 4.1 --keyint 25 --open-gop --slices 4 --fake-interlaced --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --sar 1:1 --pass 2 -o out.mkv input.mov

From the first page of this thread:

Output file must be in raw 264 elementary stream (extension .264) otherwise settings will not applied correctly. DO NOT USE MKV OR MP4.

I have to use the MKV extension. Is there a problem with this? Again, the disc will not have menus, chapters et cetera and I am not authoring it with Blu-ray authoring programs.

[poisondeathray]

Originally Posted by WSC4

I have to use the MKV extension. Is there a problem with this? Again, the disc will not have menus, chapters et cetera and I am not authoring it with Blu-ray authoring programs.

No problem if it's just a data disc

[WSC4]

Thank you. That is good news.

The videos to be burnt onto the discs are actually from a camcorder. MediaInfo state they are all progressive. Do I have to use the --fake-interlaced option?

Looking at these files from the video camera, MediaInfo also displays --colorprim, --transfer and --colormatrix as "bt709". Do I still need to include those options? My guess is that x264 will copy them anyway.

The discs would be played on current to maybe 9 year old Blu-ray players.

[Asmodian]

You do need to include those options, x264 will not copy them.

No need for --fake-interlaced.

[Bordo32]

I was reading trough many different posts on various forums, still did to find a definitive answer on what is recommended by Blu Ray specs Min GOP size (encoding with X264, H264), what min keyint value has to be set to have Blu Ray compliant encoded file?

I know that the Max GOP has to match the bitrate for 4.1 level, hence keint = 60 for 59.94fps video.
But the Min size is a mystery.
I am leaning towards min keyint = 1.
But found other recommendations:
min keyint = 2
min keyint = 0
min keyint = 1
min keyint = fps/2
min keyint = fps/2 + 1

But what is actual value is described by Blu Ray specs, if it is described?

Looking for your comments/advise.

[benwaggoner]

Originally Posted by Bordo32

I was reading trough many different posts on various forums, still did to find a definitive answer on what is recommended by Blu Ray specs Min GOP size (encoding with X264, H264), what min keyint value has to be set to have Blu Ray compliant encoded file?

I know that the Max GOP has to match the bitrate for 4.1 level, hence keint = 60 for 59.94fps video.

It's not about the bitrate. The limitation is 1 second for Level 4.0 and 2 seconds for Profile 4.0 with a --vbv-maxrate of 15000 or less, IIRC. I used that combo burning BD images to DVD-R media way back in the day when BD-R replication wasn't cost-effective for smaller runs due to the requirement to purchase a per-title encryption key.

But the Min size is a mystery.
I am leaning towards min keyint = 1.
But found other recommendations:
min keyint = 2
min keyint = 0
min keyint = 1
min keyint = fps/2
min keyint = fps/2 + 1

But what is actual value is described by Blu Ray specs, if it is described?

It's been a long time since I made an old-school Blu-ray, but my dim memory agrees with --min-keyint 2. Some of the limitations are/have been due to a combination of x264 implementation and BD spec limitations, not strictly the Blu-ray spec itself. For example, open-gop wasn't allowed with --bluray-compat in older versions of x264 even though the spec allowed it. There's a lot fewer parameters changed in --bluray-compat today than in olden times.

[MasterNobody]

    if( h->param.b_bluray_compat )
    {
        h->param.i_bframe_pyramid = X264_MIN( X264_B_PYRAMID_STRICT, h->param.i_bframe_pyramid );
        h->param.i_bframe = X264_MIN( h->param.i_bframe, 3 );
        h->param.b_aud = 1;
        h->param.i_nal_hrd = X264_MAX( h->param.i_nal_hrd, X264_NAL_HRD_VBR );
        h->param.i_slice_max_size = 0;
        h->param.i_slice_max_mbs = 0;
        h->param.b_intra_refresh = 0;
        h->param.i_frame_reference = X264_MIN( h->param.i_frame_reference, 6 );
        h->param.i_dpb_size = X264_MIN( h->param.i_dpb_size, 6 );
        /* Don't use I-frames, because Blu-ray treats them the same as IDR. */
        h->param.i_keyint_min = 1;
        /* Due to the proliferation of broken players that don't handle dupes properly. */
        h->param.analyse.i_weighted_pred = X264_MIN( h->param.analyse.i_weighted_pred, X264_WEIGHTP_SIMPLE );
        if( h->param.b_fake_interlaced )
            h->param.b_pic_struct = 1;
    }

Link to encoder/encoder.c
Commit from 2012.

[Bordo32]

It means has to be set keyint_min = 1 for Blu Ray compliant.
Correct?

[MasterNobody]

Yes. And it is automatically forced set when --bluray-compat is used i.e. no matter what --min-keyint you set, it still will be 1.

[Bordo32]

MasterNobody, thanks for your help.
Now is clear, set keyint_min = 1 just be on the safe side.

The images in the first post have disappeared. Good job sneaker made a backup. Maybe a mod can edit the OP.