x264 development

[rallymax]

http://git.videolan.org/gitweb.cgi?p=x264.git;a=commit;h=c6de86497cdd7b7f3cce7d8a95d723c7d0c9f505 ;)


re BluRay - Awesome work LM and others.


Initialize your 'x264_param_t' via x264_param_default() and then only overwrite the settings you need to overwrite. Use x264_param_default_preset() to apply presets/tunings.

The commit message shows an example on how to configure x264 for BluRay compatibility...

Init with.... hmm it already has the init call...
static av_cold int X264_init(AVCodecContext *avctx)
{
X264Context *x4 = avctx->priv_data;

x4->sei_size = 0;
x264_param_default(&x4->params); <---------------

x4->params.pf_log = X264_log;
x4->params.p_log_private = avctx;

ok... so based on the git commit comments and the ones from kieranrk's google doc page I should be able to get this to go now.

thanks.

[LoRd_MuldeR]

re BluRay - Awesome work LM and others.

Not my work though ;)


Init with.... hmm it already has the init call...
static av_cold int X264_init(AVCodecContext *avctx)
{
X264Context *x4 = avctx->priv_data;

x4->sei_size = 0;
x264_param_default(&x4->params); <---------------

x4->params.pf_log = X264_log;
x4->params.p_log_private = avctx;

Obviously the x264 defaults are still overwritten by FFmpeg (libavcodec) with their own "broken" defaults - after the defaults have been initialized by x264 itself.

As far as I understand, you use libx264 indirectly, through libavcodec. Why not call libx264 directly ???

[rallymax]

Not my work though ;)
Why not call libx264 directly?

I'm using libavformat to make the m2ts container so that it's muxed with AC3 too.

oh, I also use libswscale and the RGB -> YUV planar conversion functions so it's just easier to call the libavformat front end based off of the output-example and have it then call the x264 library for me.

Unfortunately libavformat's mpegts muxer is implemented for true MPEG-TS (vs the slight modification of the timestamp header for .MTS). In many hours of Googling I'm yet to find out what the increment value is of the 4byte timecode on the front of the 188byte mpegts packet. I'm of the impression that it's something to do with the real time divided by the current vbr value. I've hacked that into libavformat/mpegtsenc.c to add ".mts" but will need to fix the increment rate eventually so that, I think, BluRay players can scrub fwd/rev properly.

This MPEG-TS & Timecode hack for Bluray (http://en.wikipedia.org/wiki/MPEG_transport_stream#Modifications_of_transport_stream_specification_for_random-access_media_.28M2TS.29) is Wikipedia info on the issue.

You wouldn't happen to have an info on that would you?

[LoRd_MuldeR]

I'm using libavformat to make the m2ts container so that it's muxed with AC3 too.

Unfortunately libavformat's mpegts muxer is implemented for true MPEG-TS (vs the slight modification of the timestamp header for .MTS). In many hours of Googling I'm yet to find out what the increment value is of the 4byte timecode on the front of the 188byte mpegts packet. I'm of the impression that it's something to do with the real time divided by the current vbr value. I've hacked that into libavformat/mpegtsenc.c to add ".mts" but will need to fix the increment rate eventually so that, I think, BluRay players can scrub fwd/rev properly.

This MPEG-TS & Timecode hack for Bluray (http://en.wikipedia.org/wiki/MPEG_transport_stream#Modifications_of_transport_stream_specification_for_random-access_media_.28M2TS.29) is Wikipedia info on the issue.

You wouldn't happen to have an info on that would you?

No, but why not encode with the x264 CLI encoder to "raw" H.264 stream and mux it to M2TS afterwards, with something like tsMuxeR?

(BTW: If you are hacking FFmpeg anyway, why not kick out everything they overwrite in 'x4->params' after the x264_param_default() call, except for the things you really need?)

[rallymax]

No, but why not encode with the x264 CLI encoder to "raw" H.264 stream and mux it to M2TS afterwards, with something like tsMuxeR?

(BTW: If you are hacking FFmpeg anyway, why not kick out everything they overwrite in x264_paramt_t after the x264_param_default() call, except for those you really need?)

I'm trying to make it all just one program vs a workflow (otherwise I could have done this a yr ago with AVS scripts etc)

yes, I'm going to blow away all the libx264.c changes to the defaults and just plug in the ones needed to make BluRay based on the x264 arguments given on the google doc page for legal bluray.

I think we're on the same page.

[rallymax]

(BTW: If you are hacking FFmpeg anyway, why not kick out everything they overwrite in 'x4->params' after the x264_param_default() call, except for the things you really need?)

'just home, pulled everything out except the size and SAR and tried it... and it worked! :thanks:

Now to pop in the BluRay values...

$ ./output-example.exe xxx.h264
Output #0, h264, to 'xxx.h264':
Stream #0.0: Video: libx264, yuv420p, 352x288, q=2-31, 400 kb/s, 90k tbn, 25 tbc
[libx264 @ 00544500] using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
[libx264 @ 00544500] profile High, level 1.3
[libx264 @ 00544500] non-strictly-monotonic PTS
Last message repeated 49 times
[libx264 @ 00544500] invalid DTS: PTS is less than DTS
[libx264 @ 00544500] non-strictly-monotonic PTS
[libx264 @ 00544500] invalid DTS: PTS is less than DTS
[libx264 @ 00544500] non-strictly-monotonic PTS
[libx264 @ 00544500] invalid DTS: PTS is less than DTS
[libx264 @ 00544500] non-strictly-monotonic PTS
Last message repeated 121 times
[libx264 @ 00544500] frame I:1 Avg QP:23.49 size: 2556
[libx264 @ 00544500] frame P:31 Avg QP:22.84 size: 903
[libx264 @ 00544500] frame B:93 Avg QP:29.04 size: 558
[libx264 @ 00544500] consecutive B-frames: 0.0% 0.0% 0.0% 100.0%
[libx264 @ 00544500] mb I I16..4: 78.3% 15.7% 6.1%
[libx264 @ 00544500] mb P I16..4: 77.2% 4.7% 0.3% P16..4: 17.1% 0.4% 0.2% 0.0% 0.0% skip: 0.0%
[libx264 @ 00544500] mb B I16..4: 0.0% 0.0% 0.0% B16..8: 14.3% 0.2% 0.0% direct:25.0% skip:60.5% L0:57.1% L1:38.6% BI: 4.2%
[libx264 @ 00544500] 8x8 transform intra:6.1% inter:41.6%
[libx264 @ 00544500] coded y,uvDC,uvAC intra: 3.3% 27.8% 4.9% inter: 0.2% 42.2% 6.3%
[libx264 @ 00544500] i16 v,h,dc,p: 0% 0% 0% 100%
[libx264 @ 00544500] i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 0% 29% 3% 66% 0% 0% 0% 1% 0%
[libx264 @ 00544500] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 0% 9% 20% 69% 0% 0% 0% 1% 1%
[libx264 @ 00544500] i8c dc,h,v,p: 0% 3% 7% 89%
[libx264 @ 00544500] Weighted P-Frames: Y:0.0%
[libx264 @ 00544500] ref P L0: 91.5% 0.7% 6.5% 1.2%
[libx264 @ 00544500] ref B L0: 66.4% 26.5% 7.1%
[libx264 @ 00544500] ref B L1: 97.9% 2.1%
[libx264 @ 00544500] kb/s:-0.00

[Dark Shikari]

I'm trying to make it all just one program vs a workflow (otherwise I could have done this a yr ago with AVS scripts etc)

yes, I'm going to blow away all the libx264.c changes to the defaults and just plug in the ones needed to make BluRay based on the x264 arguments given on the google doc page for legal bluray.

I think we're on the same page.ffmpeg has preset files (accessed with -vpre) that set the x264 default settings accordingly for various presets.

Of course, it's better to just do it right, and you'll have to modify the code if only because not all necessary options are exposed (e.g. NAL HRD).

[iwod]

After the license change for x264, all seems rather quiet on x264 side. Any new things going on?

[Dark Shikari]

After the license change for x264, all seems rather quiet on x264 side. Any new things going on?Well, if you paid attention to git or the weekly newsletter, we now have high bit depth support finished, among other things. I have about 8 local patches that'll go in soon, but nothing really big at the moment.

Also, there was no license change, only a license addition. It's still GPL.

[shon3i]

@Dark Shikari, is it possible in near future to make more friendly bitdepth, as single switch like Mainconcept, not at comple?

[Dark Shikari]

@Dark Shikari, is it possible in near future to make more friendly bitdepth, as single switch like Mainconcept, not at comple?That would involve compiling x264 twice and putting them both in the same application. That's probably what Mainconcept does.

Patches welcome; it'd require symbol versioning, at least, due to duplicate symbols.

[shon3i]

i don't know what they do, but i have one cli exe (standalone) or one directshow fiter that can choose bithdepth, which is more friendly to me, and i hope for other users too. I hope will someone help here and write patch :) or make webpage with compiled builds.

[Dark Shikari]

i don't know what they do, but i have one cli exe (standalone) or one directshow fiter that can choose bithdepth, which is more friendly to me, and i hope for other users too.Why not make a 5-line shell script that chooses between two executables if you're going to do that?

[shon3i]

Why not make a 5-line shell script that chooses between two executables if you're going to do that?
making front-end or script isn't problem, bigger problem is where to find(and download) >8bit builds, and keep it updated. I am not familiar with compiling x264

[Dark Shikari]

making front-end or script isn't problem, bigger problem is where to find(and download) >8bit builds, and keep it updated. I am not familiar with compiling x264Once we have a decoder ready and thus 10-bit becomes useful, it'll be easy to find such builds.

[Disabled]

the weekly newsletter
Is there a way to get the newsletter without joining the x264-dev mailinglist? (or manually searching the archives.)

[JoeH]

I think this issue is probably know to the developers by now, but just wanted to confirm that with recent builds (tested with 1724), the B-Pyramid strict option breaks compatibility with Panasonic Blu-ray players with the latest firmware (tested on BD60 with latest European firmware, v2.5, also with firmware v2.4 same problem). Disabling B-Pyramid enables playback.

Using MeGUI x264 profiles, I never saw this problem with build 1364 of x264 and previous, although I can't confirm for sure whether I was using the B-Pyramid strict option in those builds (I always use the MeGUI defaults if that is of any use).
----------------------------------------------------------------------------------------------------------------------
Just noted this thread is not for bug reports - feel free to move the message. Sorry about that.

[Trahald]

What do you mean breaks compatibility? Does the disk play, but plays corrupt? Does it not recognize the disk at all. Does it start to play but then stop? What authoring software do u use? Do your streams play properly on the pc? You are not clear if the problem has always been there for u with strict or did it just stArt with the firmware update. If not, why wait 400 revisions to report it?

[shon3i]

@JoeH, as Trahald requested, be more specific and describe how it look. What i need to know, what muxer you use? And what exact comandline you use to encode video? I realy don't know what is defaults for megui.

[kieranrk]

@JoeH, as Trahald requested, be more specific and describe how it look. What i need to know, what muxer you use? And what exact comandline you use to encode video? I realy don't know what is defaults for megui.

I would speculate tsmuxer is the problem.

[shon3i]

Once we have a decoder ready and thus 10-bit becomes useful, it'll be easy to find such builds.
I little playing with 10-bit (finaly buids arrived on x264.nl) using Mainconcept decoder which fully compatible wtih high bit support, i must say am very pleased with quality. I am only notice that encoding is slow like hell or just me.

[Underground78]

I little playing with 10-bit (finaly buids arrived on x264.nl) using Mainconcept decoder which fully compatible wtih high bit support, i must say am very pleased with quality. I am only notice that encoding is slow like hell or just me.

It is probably not just you, the asm for high bitdepth support has not been committed yet ...

[laserfan]

B-Pyramid strict option breaks compatibility with Panasonic Blu-ray players...
As an aside, b-pyramid also doesn't work with Sony DVD Architect. At least, while it APPEARS to work i.e. you can import and output/mux to BD, the result does not play-back all frames in the proper order. You have to leave this off if using x264 with DVDA.

[julius666]

I little playing with 10-bit (finaly buids arrived on x264.nl) using Mainconcept decoder which fully compatible wtih high bit support, i must say am very pleased with quality. I am only notice that encoding is slow like hell or just me.

Could you post some comparison pictures please? I bet most of us on the forum don't have any 10-bit capable h264 decoder, but are interested in the quality gain that it gives.

[shon3i]

Could you post some comparison pictures please? I bet most of us on the forum don't have any 10-bit capable h264 decoder, but are interested in the quality gain that it gives.
Currently i am trying to find good source that easly produce banding. And i will post screens.

[Dark Shikari]

Currently i am trying to find good source that easly produce banding. And i will post screens.Here's one from a bit back:

8-bit (http://kuukunen.net/misc/banddenoise_8bit.png)

10-bit (http://kuukunen.net/misc/banddenoise_10bit.png)

[mariush]

why is the woman's face more pink on the 8bit version? consequence of 4:2:0 or something like that?

[Dark Shikari]

why is the woman's face more pink on the 8bit version? consequence of 4:2:0 or something like that?I think there was a BT.601/709 screwup somewhere in the process. Blame Kuukunen.

[JoeH]

@JoeH, as Trahald requested, be more specific and describe how it look. What i need to know, what muxer you use? And what exact comandline you use to encode video? I realy don't know what is defaults for megui.

Sure. Here are the settings that work properly with the Panasonic Blu-ray players:
--preset slow --pass 2 --bitrate 16000 --stats ".stats" --b-pyramid none --level 4.1 --bframes 3 --ref 4 --slices 4 --aud --nal-hrd vbr --keyint 24 --min-keyint 2 --vbv-bufsize 30000 --vbv-maxrate 40000 --weightp 0 --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --output "output" "input"

These are the settings I used which do NOT work:
--preset slow --pass 2 --bitrate 16000 --stats ".stats" --b-pyramid strict --level 4.1 --bframes 3 --ref 4 --slices 4 --aud --nal-hrd vbr --keyint 24 --min-keyint 2 --vbv-bufsize 30000 --vbv-maxrate 40000 --weightp 0 --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --output "output" "input"

The only change is the bpyramid option. I have tested this many times with the same result each time.

I mux with TSMuxer. Here are the options I used. They were identical in both runs:
MUXOPT --no-pcr-on-video-pid --new-audio-pes --blu-ray --vbr --auto-chapters=5 --vbv-len=500
V_MPEG4/ISO/AVC, "F:\4 Peliculas\Movie\Movie.mkv", fps=23.976, insertSEI, contSPS, track=1, lang=eng
A_LPCM, "F:\4 Peliculas\Movie\EditedStreams\EditedAudio.w64", lang=eng
A_AC3, "F:\4 Peliculas\Movie\EditedStreams\EditedAudio.ac3", lang=eng
S_TEXT/UTF8, "F:\4 Peliculas\Movie\Subtitles\Edited con cortes.srt",font-name="Calibri",font-size=85,font-color=0x00ffffff,bottom-offset=135,font-border=3,text-align=center,video-width=1920,video-height=1080,fps=23.976, lang=spa

Here's what happens in the Panasonic Bluray Player when I insert a disk with bpyramid strict:
- The players LCD says "BD"
- On the display monitor I want to watch the BD it says "Reading"
- The LCD says 00:00:00
- It waits for a while trying to read it. It can't.
- The whole process repeats indefinitely.

This problem has been commented on here as well:
http://doom10.org/index.php?topic=324.0

I know for sure that previously when I had this problem and didn't know it was caused by the b-pyramid option I switched out x264 with the 1364 build and then it worked. I don't know if I made any additional changes to the command line that time.

[kieranrk]

Your --vbv-len is not 500ms. It is 750ms (bufsize/bitrate)

Also remove insertSEI, contSPS,

I think tsmuxer will still try to "fix" bpyramid and this is why it fails.

[shon3i]

Your --vbv-len is not 500ms. It is 750ms (bufsize/bitrate)That should not be problem even is higher than 1000ms, it's not by standard, but i think will not produce problem like here described.

@JoeH can you try to download x264 BluRay demo disc? and see is playing propertly. All clips on disc use bpyramid. That will be posibly eleminate is muxer or encoder problem.

[Trahald]

Just like the sync problem disappeared when ADDING b-frames. Yet it turned out mp4box was broken. Just because changing the option in x264 is fixing the issue doesn't mean it's x264s fault. Shoni uses professional muxers with x264 and makes valid BDs.

x264 uses more advanced h264 features when doing bpyramid than it used to. Tsmuxer is probably getting confused and puking on the stream. Submit a stream to the tsmuxer ppl and help them fix it. (if u want) If it were open source I'd try to write a patch but it's not. A complete playback failure is almost gauranteed to be the muxer especially factoring in b-pyramid works on other software/hardware players fine. Corrupted output then possibly encoder. For now u will have to turn off pyramid or use older revision.

[laserfan]

Your --vbv-len is not 500ms. It is 750ms (bufsize/bitrate)
How'd you determine this? Can you explain please; I've never seen any posts about changing --vbv-len before.

[Underground78]

How'd you determine this? Can you explain please; I've never seen any posts about changing --vbv-len before.

vbv-len (in seconds) = vbv-bufsize / vbv-maxrate

Here vbv-bufsize = 30000 and vbv-maxrate = 40000 so vbv-len is 30000 / 40000 = 0.75 s = 750 ms.

[laserfan]

vbv-len (in seconds) = vbv-bufsize / vbv-maxrate

Here vbv-bufsize = 30000 and vbv-maxrate = 40000 so vbv-len is 30000 / 40000 = 0.75 s = 750 ms.
Ah, it was bufsize/bitrate that threw me off, thanks.

I hafta wonder still how critical/important (or not) this vbv-len setting is? I have never fiddled with it, though I do use 30000 & 40000 for BDs and 15000 & 15000 for DVD discs.

[sneaker_ger]

It mustn't be greater than 1 second to meet the Blu-Ray specifications. (i.e. bufsize mustn't be larger than maxrate)

[shon3i]

After bit researching, i found two thing that can break playback on Panasonic players.

First is if user use MKV or MP4 output instead raw 264. That will tell tsmuxer to break original AUD data and make broken stream. outputing to raw 264 is strongly recommend and outputing to MKV or MP4 is impossible for BD, we already haved simmilar situation in BD-Rebulder, which make same behavior with Panasonic players
Second is insertSEI, contSPS options in tsmuxer, but they are should no effect on stream if everyting is right but for sure (especialy on raw 264 stream), disabling them is strongly recommend.

@JoeH if you will try these combinations

Thanks

EDIT: And as i can see in your TSMuxer cmd you use MKV as video input, and that will not go. TsMuxer definitly break your stream.

[laserfan]

It mustn't be greater than 1 second to meet the Blu-Ray specifications. (i.e. bufsize mustn't be larger than maxrate)
Thank you for this. :)
:thanks:

[JoeH]

Thanks for the ideas. I'll try these suggestions out in the next few days and report back. I can't get to it today.

Is there a link to download the X264 Bluray demo disk which does not use torrent? My companies firewalls block torrent.

As far as the muxer goes, are there any real alternatives (free or at least cheap) to TSMuxer?

Here's an idea - even though TSMuxer isn't open source, an alternative GUI could be built, which might be able to get around these problems. The TSMuxer command line I copied is simply created by the GUI.

[JoeH]

I'll have some test results tomorrow for sure.

[DanielSun]

intel new sandy bridge processor will have a video transcode engine build into the cpu die, so will this feature be supported by X264?

[Blue_MiSfit]

DanielSun: If you do some research into this kind of thing, you'll see that hardware encoding solutions - be it on a GPU or special portion of a CPU - never have application when it comes to x264, and this is a good thing.

GPU accelerated transcoding is always slower and/or worse quality than x264. Usually both. This is because video encoding algorithms aren't easily parallelizable to the scale that's necessary to take advantage of GPU architecture.

The Sandy Bridges transcode engine (as far as I understand) is a fixed function piece of hardware that can't simply be used to accelerate portions of x264 or other H.264 encoders. It is in fact a full hardware encoder. I'm not 100% certain of this, but I'm sure I'm close to the mark :)

Not to say that these types of encoders won't have their purposes. Consider a notebook user with a fairly slow dual core CPU. Imagine the user has a piece of content they want to put on their mobile phone or other media player. They want it right now, but have to transcode it. Therefore, they want the transcode completed as quickly as possible. With the encoder in Sandy Bridge, they can probably get a usable file quicker than any software encoder, even including x264 (which is by far the best / fastest software encoder out there). Sure, they might have to double or triple the bitrate to get something that's watchable, but they get their TV show on their phone very quickly. They delete it after watching, so who cares?

Definitely a corner case, especially to the average doom9 user, but it's something I've run up against plenty of times. Sure, I have a (relatively) fast Q6600 CPU that can tear through SD H.264 encoding VERY VERY VERY quickly when using x264's ultrafast or superfast preset. Unfortunately not everyone has that kind of CPU power to throw at the problem, though.

I see Sandy Bridges as being an interesting option for these types of cases. I'm definitely going to get my hands on a slow dual core version, and see how the quality/speed ratio of its encoder compares to x264 on ultrafast, at fairly high bitrates (i.e. 20-30mbps for HD and 5-10mbps for SD)

Derek

[mariush]

Is there a link to download the X264 Bluray demo disk which does not use torrent? My companies firewalls block torrent.



Here you are: http://mplayer.savedonthe.net/test_files/download.php?dir=BluRay+DVD%2F

[JoeH]

I've done two tests so far, both with PTI/SPS/PPS turned off and buffer size of 750ms. One test was with an MKV, the other with H264 stream for the video. Unfortunately both gave the same result as my previous BPyramid -strict tests - the Panasonic would not get past 00:00:00.

Here are the TSMuxer configurations:

With MKV video:
MUXOPT --no-pcr-on-video-pid --new-audio-pes --blu-ray --vbr --auto-chapters=5 --vbv-len=750
V_MPEG4/ISO/AVC, "F:\4 Peliculas\Movie\Movie-BPyramid-Strict.mkv", fps=23.976, track=1, lang=eng
A_LPCM, "F:\4 Peliculas\Movie\EditedStreams\v2\EditedAudio-v2.w64", lang=eng
A_AC3, "F:\4 Peliculas\Movie\EditedStreams\v2\EditedAudio-v2.ac3", lang=eng
S_TEXT/UTF8, "F:\4 Peliculas\Movie\Subtitles\New\Edited.srt",font-name="Calibri",font-size=85,font-color=0x00ffffff,bottom-offset=135,font-border=3,text-align=center,video-width=1920,video-height=1080,fps=23.976, lang=spa

With H264 video:
MUXOPT --no-pcr-on-video-pid --new-audio-pes --blu-ray --vbr --auto-chapters=5 --cut-end=2min --vbv-len=750
A_LPCM, "F:\4 Peliculas\Movie\EditedStreams\v2\EditedAudio-v2.w64", lang=eng
A_AC3, "F:\4 Peliculas\Movie\EditedStreams\v2\EditedAudio-v2.ac3", lang=eng
S_TEXT/UTF8, "F:\4 Peliculas\Movie\Subtitles\New\Edited.srt",font-name="Calibri",font-size=85,font-color=0x00ffffff,bottom-offset=135,font-border=3,text-align=center,video-width=1920,video-height=1080,fps=23.976, lang=spa
V_MPEG4/ISO/AVC, "F:\4 Peliculas\Movie\T1_Video - .h264", fps=23.976

I am downloading the X264 demo video right now (thanks Mariush!), but it won't finish for another 6 or 7 hours. I'll post results with it tomorrow.

[shon3i]

OK, since Panasonic players follow strict BD Specification, and while you wait for Demo disc, can you try this also, since i am not saw --sar in your commandlines, and sar should be present in stream, in your case --sar 1:1.

Second thing, when you make raw 264 encode, did you encode from scratch or you just demuxed your previous maked MKV? i ask because demuxing is not fix things, and stream is still "broken"?

vbv-len (in seconds) = vbv-bufsize / vbv-maxrate

Here vbv-bufsize = 30000 and vbv-maxrate = 40000 so vbv-len is 30000 / 40000 = 0.75 s = 750 ms. To be more precise, sine x264's --vbv-init is by default on 0.9 so in this case is not 750ms, because

(30000*0.9)/40000=0.675 which is 675ms, and more correct value :), easly can be checked with Elecard Buffer Analyser.

or vbv-init can be safetly set to 1.0 :)

[kieranrk]

To be more precise, sine x264's --vbv-init is by default on 0.9 so in this case is not 750ms, because

(30000*0.9)/40000=0.675 which is 675ms, and more correct value :), easly can be checked with Elecard Buffer Analyser.

or vbv-init can be safetly set to 1.0 :)

This is incorrect. vbv-size refers to the size of the WHOLE buffer in ms, not just the initial fill.

[shon3i]

This is incorrect. vbv-size refers to the size of the WHOLE buffer in ms, not just the initial fill.
Hmm, i am not sure, how x264 calculate size of buffer, but during verifying process, verifyer show that size of buffer is ~0.6 not 0.75. Same what elecard show, and generaly other encoders use init buffer 1

[kieranrk]

Hmm, i am not sure, how x264 calculate size of buffer, but during verifying process, verifyer show that size of buffer is ~0.6 not 0.75. Same what elecard show, and generaly other encoders use init buffer 1

They are then talking about the initial buffer fullness.

[shon3i]

They are then talking about the initial buffer fullness.
Yep, you right, my bad.

[JoeH]

Good news - the Panasonic reads the X264 Bluray demo disk just fine. So, definitely some sort of muxing issue then, or maybe as you suggest the BPyramid Strict option works on Panasonic only when combined with some other option like SAR.

OK, since Panasonic players follow strict BD Specification, and while you wait for Demo disc, can you try this also, since i am not saw --sar in your commandlines, and sar should be present in stream, in your case --sar 1:1.

Second thing, when you make raw 264 encode, did you encode from scratch or you just demuxed your previous maked MKV? i ask because demuxing is not fix things, and stream is still "broken"?

I just demuxed the previous MKV. I'll reencode and include the --sar 1:1 option and let you know how things go!

I'm also going to try remuxing a stream from the Bluray demo disk with TSMuxer, burn, and see what happens.