NAL HRD has been committed!

[stax76]

Just a wrong assumption, some switches lack <string>, --profile, --preset etc.

The default value for --nal-hrd is none, right?

[LoRd_MuldeR]

The default value for --nal-hrd is none, right?

void x264_param_default( x264_param_t *param )
{
[...]
param->i_nal_hrd = X264_NAL_HRD_NONE;
[...]
}

[Dark Shikari]

x264 build with (hopefully) HRD fixed. (http://mirror05.x264.nl/Dark/x264_HRD_fixed.7z)

Test this build and see if it passes muxing--if it does, we'll push it and x264 will be Blu-ray compliant. Really, this time! :p

[jpsdr]

Ok, i've got it. Result from me not before tomorrow, time to encode...

Encoding will be with :
@echo off

SET E_SRC=%6%1.avs
SET E_DST=%3%1.264
SET STAT_FILE=%1.stats
SET TUNING=%4
SET LOG_FILE_1=%1_log_1.txt

REM Set of max bitrate (ici le bitrate max)
set MAX_BR=39000

REM Set of Buffer (ici le buffer)
set BUF_BR=30000

x264_x86.exe --profile "high" --preset "placebo" --tune %TUNING% --bitrate %2 --stats %STAT_FILE% --level "4.1" --qpmin 0 --qpstep 2 --vbv-maxrate %MAX_BR% --vbv-bufsize %BUF_BR% --keyint 24 --min-keyint 2 --mvrange 511 --ref 4 --bframe 3 --slices 4 --b-pyramid "strict" --aq-mode 2 --aud --nal-hrd "vbr" --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --sar 1:1 --qpfile %5 --threads 0 --thread-input --output %E_DST% %E_SRC% 2> %LOG_FILE_1%

tuning : animation
bitrate : 39000

[deank]

x264 build with (hopefully) HRD fixed. (http://mirror05.x264.nl/Dark/x264_HRD_fixed.7z)

Test this build and see if it passes muxing--if it does, we'll push it and x264 will be Blu-ray compliant. Really, this time! :p

Here is the .264 (http://multiavchd.deanbg.com/[1510-7-NOT_WORKING].[NAL-HRD].[1920x1080-23.976].rar) encoded with this +7 build. It is not working yet - hddvdmux just sits there and takes CPU/memory, but not showing the muxing progress and produces no output. :(

[Dark Shikari]

Here is the .264 (http://multiavchd.deanbg.com/[1510-7-NOT_WORKING].[NAL-HRD].[1920x1080-23.976].rar) encoded with this +7 build. It is not working yet - hddvdmux just sits there and takes CPU/memory, but not showing the muxing progress and produces no output. :(Given that it doesn't give any compliance errors or whatnot--and it didn't work earlier--and probably doesn't even read HRD--I'm going to guess this is not x264's fault.

[deank]

Well... I never said it is x264's fault...

I'm not much into c++ programming, but I took the liberty to edit the source of this tool which seems to use code fragments from h264_info.

For some reason it can't properly detect/find the required data to start decoding the frames...

I added some log lines and here is what I get:

The working:
(9)Access unit delimeter
(7)Sequence parameter set
(8)Picture parameter set
(6)SEI
(6)SEI
(5)Coded slice of an IDR picture
(9)Access unit delimeter
(6)SEI
(1)Coded slice of non-IDR picture
(9)Access unit delimeter
(6)SEI
(1)Coded slice of non-IDR picture
(9)Access unit delimeter
(6)SEI
(1)Coded slice of non-IDR picture

Non-working one...
(9)Access unit delimeter
(7)Sequence parameter set
(8)Picture parameter set
(9)Access unit delimeter <<-- I guess here it gets confused because it misses 3 important packets
(9)Access unit delimeter
(9)Access unit delimeter
(9)Access unit delimeter
(?)unknown value
(7)Sequence parameter set
(9)Access unit delimeter
(9)Access unit delimeter
(9)Access unit delimeter
(9)Access unit delimeter
(9)Access unit delimeter
(9)Access unit delimeter
(9)Access unit delimeter
(9)Access unit delimeter
(9)Access unit delimeter
(7)Sequence parameter set
(8)Picture parameter set
(2)Coded slice of data partition A
(9)Access unit delimeter
(9)Access unit delimeter
(9)Access unit delimeter
(9)Access unit delimeter
(9)Access unit delimeter
(9)Access unit delimeter
(9)Access unit delimeter
(9)Access unit delimeter
(9)Access unit delimeter
(9)Access unit delimeter
(9)Access unit delimeter
(9)Access unit delimeter
(9)Access unit delimeter
(3)Coded slice of data partition B
(9)Access unit delimeter
(7)Sequence parameter set
(8)Picture parameter set
(?)unknown value


I can clearly see differences between the working and non-working streams, for example at offset 0x38 where the next packet should start:

the working stream has 00 00 00 01 06, while
the non working has 00 00 01 06 --- and that's exactly what confuses the tool (the red-bold text above). Probably it doesn't recognize the bitstream. I also tried with 0 and 4 slices with the same result.

The resolution in 2 packets back is proper: (04 16) (07 8C) while in the other is (48 28) (07 8C)...

I'm probably completely wrong to compare these things, but I just wanted to report my limited findings. I hope it is not a complete waste of your time to check it. :)

Dean

[kieranrk]

the working stream has 00 00 00 01 06, while
the non working has 00 00 01 06 --- and that's exactly what confuses the tool (the red-bold text above). Probably it doesn't recognize the bitstream. I also tried with 0 and 4 slices with the same result.


Your application doesn't understand short startcodes.

[deank]

It is not my application... It is "programmed" by a guy who would not support it and I was just trying to find out why it is not working with the newer x264 versions.

[Boulder]

Does anybody have any figures how much more efficient the interlaced encoding should now be compared to the previous version without this patch? I did a test on an interlaced clip (5000 frames) and the bitrates were almost the same with r1471 and r1510. I did apply the TFF option in r1510 and "interlaced" in r1471. Other settings stayed the same.

[Dark Shikari]

It is not my application... It is "programmed" by a guy who would not support it and I was just trying to find out why it is not working with the newer x264 versions.Sounds like the guy needs to read the spec then.

In the meantime, change:

x264_nal_encode( nal_buffer, &h->out.nal[i], h->param.b_annexb, long_startcode );

to

x264_nal_encode( nal_buffer, &h->out.nal[i], h->param.b_annexb, 1);

[jpsdr]

Finaly, encoding is complete.
Nevertheless, something bothering me.
Result is the following :

avs [info]: avisynth 2.6+ detected, forcing conversion to YV12
avs [info]: 1920x1080p 1:1 @ 24000/1001 fps (cfr)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2
x264 [info]: profile High, level 4.1
x264 [info]: frame P:29988 Avg QP: 6.33 size:364601
x264 [info]: frame B:60184 Avg QP:11.77 size: 45928
x264 [info]: consecutive B-frames: 6.1% 8.8% 17.7% 67.4%
x264 [info]: mb I I16..4: 29.8% 13.2% 56.9%
x264 [info]: mb P I16..4: 6.7% 21.2% 14.6% P16..4: 29.0% 16.3% 7.2% 0.5% 1.3% skip: 3.1%
x264 [info]: mb B I16..4: 0.2% 1.3% 0.3% B16..8: 39.4% 3.2% 7.5% direct:15.7% skip:32.5% L0:37.7% L1:42.1% BI:20.2%
x264 [info]: 8x8 transform intra:42.6% inter:21.1%
x264 [info]: direct mvs spatial:100.0% temporal:0.0%
x264 [info]: coded y,uvDC,uvAC intra: 96.2% 79.8% 77.4% inter: 41.0% 33.4% 24.3%
x264 [info]: i16 v,h,dc,p: 13% 10% 53% 24%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 18% 15% 28% 6% 6% 6% 5% 7% 9%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 17% 12% 12% 9% 10% 10% 9% 10% 11%
x264 [info]: Weighted P-Frames: Y:3.3%
x264 [info]: ref P L0: 81.4% 9.4% 8.0% 1.1% 0.1%
x264 [info]: ref B L0: 97.4% 2.6%
x264 [info]: ref B L1: 97.7% 2.3%
x264 [info]: kb/s:33662.25

encoded 94401 frames, 1.29 fps, 33662.24 kb/s

With an around 15GB file result.
With previous version (1510 rack 04 build), 40000kB (max and bitrate), and 'cbr' NAL_HRD, my result file was around 18GB.
I don't think reducing 40000 to 39000 change so much. The bitrate result here is lower than the 39000 expected...
The previous version provided me the 40000kB bitare expected.
Is it normal ? (My enconding parameters are on my post #454).

Otherwise, just in case, mux pass ok.

[deank]

Sounds like the guy needs to read the spec then.

In the meantime, change:

x264_nal_encode( nal_buffer, &h->out.nal[i], h->param.b_annexb, long_startcode );

to

x264_nal_encode( nal_buffer, &h->out.nal[i], h->param.b_annexb, 1);

You mean to change that in the x264 sources? I doubt I can do that :) I changed the source of that hdvdmux tool to accept short and long start codes. Now it works and completes, although I get a lot of broken frames. The build you sent a link to (+7) produces watchable frames and the standard r1510 produces garbled (gray) frames.

I think I'll drop that for the moment, unless someone of the guys who release the patched versions can compile 1510 with long-start support.

[deank]

Well.. I didn't stop and rack04 compiled x264 for me, so now:

1) the originial hddvdmux works with the build compiled by rack04
2) i recompiled hddvdmux to accept short-starts and it works with both jeebs and DS's (+7) but only if I use --nal-hrd none.

Thanks for your help, guys!

Dean

[shon3i]

I am back with possitive results :)

With Dark Shikari +7 buld no more C-15/16 equation errors with Sony Verifier, and verfication passes with 0 errors/warnings, aslo BDQuest 1.3.3 show 0 errors/warnings.

jpsdr which face with possible underflows in scenarist now report that passes now, so i assume that we finaly put to bed all problems.

btw jpsdr, i can't find you previous post, did you test with exatcly same settings like in first place, to be more sure that we finaly be safe with possible underflows during muxing in scenarist/blu-print

[jpsdr]

It's the post #454 in previous page (p23) of this thread...
Not exactly, because of the time needed to encode (around 18h...), i wanted to make directly the final file i'll use.
Differences are :
In the new encode, i've had --qpmin 0 and --qpstep 2 they weren't in the previous encode... i think... but in fact, i'm not totaly sure if they weren't already...
The previous encode was made with --nal-hrd cbr because i thought that an encoded cbr file needed the cbr for nal-hrd, but DS said i'm supposed to use vbr for nal-hrd, so, i used vbr.
I've reduced bitrate and max bitrate from 40000 to 39000, following some advices here.

[shon3i]

That is enough to change decisions for VBV/HRD models and good for scenarist to pass verification. Since you fail twice with r1510 and simmilar settings, please if you can test one more time with same settings as first time including HRD CBR, so we can finaly say that underflow problem gone. I know that 18h is huge time.

Thanks

[jpsdr]

I'll try to do this on the 2nd part of the week...

[Dark Shikari]

I am back with possitive results :)

With Dark Shikari +7 buld no more C-15/16 equation errors with Sony Verifier, and verfication passes with 0 errors/warnings, aslo BDQuest 1.3.3 show 0 errors/warnings.:cool:

[deank]

The build you sent a link to (+7) produces watchable frames and the standard r1510 produces garbled (gray) frames.


Test this build and see if it passes muxing--if it does, we'll push it and x264 will be Blu-ray compliant. Really, this time!

:cool:

Please :) :rolleyes: would you 'push' it forward?

[jpsdr]

Argh... Bad news...

I've encoded with the fix posted here with these parameters, which are those i've used to report the problem :

@echo off

SET E_SRC=%6%1.avs
SET E_DST=%3%1.264
SET STAT_FILE=%1.stats
SET TUNING=%4
SET LOG_FILE_1=%1_log_1.txt

REM Set of max bitrate (ici le bitrate max)
set MAX_BR=40000

REM Set of Buffer (ici le buffer)
set BUF_BR=30000

x264_x64.exe --profile "high" --preset "placebo" --tune %TUNING% --bitrate %2 --stats %STAT_FILE% --level "4.1" --qpmin 0 --qpstep 2 --vbv-maxrate %MAX_BR% --vbv-bufsize %BUF_BR% --keyint 24 --min-keyint 2 --mvrange 511 --ref 4 --bframe 3 --slices 4 --b-pyramid "strict" --aq-mode 2 --aud --nal-hrd "cbr" --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --sar 1:1 --qpfile %5 --threads 0 --thread-input --output %E_DST% %E_SRC% 2> %LOG_FILE_1%

Bitrate (%2) : 40000
Tuning : animation

Result is :

avs [info]: avisynth 2.6+ detected, forcing conversion to YV12
avs [info]: 1920x1080p 1:1 @ 24000/1001 fps (cfr)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2
x264 [info]: profile High, level 4.1
x264 [info]: frame P:29988 Avg QP: 6.18 size:374928
x264 [info]: frame B:60184 Avg QP:11.74 size: 92370
x264 [info]: consecutive B-frames: 6.1% 8.8% 17.7% 67.4%
x264 [info]: mb I I16..4: 30.0% 12.9% 57.1%
x264 [info]: mb P I16..4: 7.1% 20.6% 15.0% P16..4: 29.0% 16.2% 7.2% 0.5% 1.3% skip: 3.1%
x264 [info]: mb B I16..4: 0.2% 1.3% 0.3% B16..8: 39.4% 3.2% 7.5% direct:15.7% skip:32.4% L0:37.7% L1:42.1% BI:20.2%
x264 [info]: 8x8 transform intra:41.4% inter:20.8%
x264 [info]: direct mvs spatial:100.0% temporal:0.0%
x264 [info]: coded y,uvDC,uvAC intra: 96.3% 79.9% 77.6% inter: 41.2% 33.5% 24.6%
x264 [info]: i16 v,h,dc,p: 13% 10% 54% 23%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 19% 15% 28% 6% 6% 6% 5% 7% 9%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 17% 12% 12% 8% 10% 10% 9% 10% 11%
x264 [info]: Weighted P-Frames: Y:3.3%
x264 [info]: ref P L0: 81.5% 9.3% 8.0% 1.1% 0.1%
x264 [info]: ref B L0: 97.4% 2.6%
x264 [info]: ref B L1: 97.7% 2.3%
x264 [info]: kb/s:39999.24

encoded 94401 frames, 1.28 fps, 39999.24 kb/s

This time, file has the expected size (18,5GB) and bitrate for a 40000kb cbr file i've asked to have ! (Unless the command line parameters i use are not the good one for a cbr file).

Unfortunately, buffer underflow has occured with this one.

I'll try, with 39000kb max and bitrate, but with all the others parameters the same, with the 1523 x64 release of rack04. I'll keep the actuel file in case...

[G_M_C]

Argh... Bad news...

I've encoded with the fix posted here with these parameters, which are those i've used to report the problem :

Bitrate (%2) : 40000
Tuning : animation

Result is :

This time, file has the expected size (18,5GB) and bitrate for a 40000kb cbr file i've asked to have ! (Unless the command line parameters i use are not the good one for a cbr file).

Unfortunately, buffer underflow has occured with this one.

I'll try, with 39000kb max and bitrate, but with all the others parameters the same, with the 1523 x64 release of rack04. I'll keep the actuel file in case...

Saw this somewhere before: DS mentioned that --nal-hrd "cbr" is almost never needed, you can use "vbr" instead if trying for BD. It still says --nal-hrd "cbr" in your commandline.

[jpsdr]

Yes, because
- shon3i wanted me to test with the exact parameters i had used the 1rst time.
- I still don't understand why i'm not having the bitrate expected, even after lowering qpmin to 0...

But i'll changed my mind, i'll do another test, with 2 pass vbr but with final bitrate=max bitrate =40000kb, with quicker setting on the 1rst pass to have an "almost" one pass cbr...
I want to see if in this case i can achieve my expected bitrate, and so if average QP will be lower. I've the feeling that with 1 pass cbr settings, between my two test, bitrate is higher, but average QP is almost the same => nal-hrd cbr as only fills (like DS said), and that is what scenarist don't like.
Why in one pass cbr, x264 don't lower QP to achieve bitrate expected, unless..... this is one of the BR restriction ?

[G_M_C]

39999,25 or 40000 jeez. I wouldn't be bothered about that.

As i said in my earlier post, i would have not even bothered with qp-min=0 either and would have been content with the compression x264 achieved in your first try.

But in my general experience: Doing what DS suggests is most often the best choice :D

And i have no idea if qp-min=0 is a restriction in the BD standard. I cant imagine why it would be, but i'm no expert on that subject.

[Dark Shikari]

39999,25 or 40000 jeez. I wouldn't be bothered about that.

As i said in my earlier post, i would have not even bothered with qp-min=0 either and would have been content with the compression x264 achieved in your first try.

But in my general experience: Doing what DS suggests is most often the best choice :D

And i have no idea if qp-min=0 is a restriction in the BD standard. I cant imagine why it would be, but i'm no expert on that subject.qpmin=0 is not a restriction, it is a lack of a restriction.

[jpsdr]

G_M_C : I was refering to my post #462, where my bitrate was 34Mb instead of the 39 expected.
By restriction i mean something related like the story here, of a parameters set to 2 in 4.1 level, but BR restrict it to 4, with result, if i've understood properly, to limit to a certain size the resulting compressed picture. But, i'm still wondering why x264 is so far away of the target bitrate with cbr encoding (and nal-hrd vbr).

[LoRd_MuldeR]

Is it possible that x264 memory usage has increased lately? With lately I mean after NAL-HRD had been added, i.e. after ~r1471.

I ask because I used to be able to encode 1080p material with RC-Lookahead=60 and B-Frames=10 at my "default" settings, while increasing B-Frames to 16 caused memory allocation failure.

Now I updated to r1523 and suddenly B-Frames=10 didn't work anymore. This time I had to reduce it to B-Frames=8, in order to avoid memory allocation failure. And I didn't even use NAL-HRD.

(I know that I can avoid the 2 GB per-process memory limit by going 64-Bit. That's not the point here)


We're planning to release a downloadable free Blu-ray image when we announce x264's official Blu-ray support. As such, we need a free movie to use for this.

I wonder, is this still in the making, now that "full" BluRay support has been committed? If so, what source did you pick after all? :confused:

[Dark Shikari]

Is it possible that x264 memory usage has increased lately? With lately I mean after NAL-HRD had been added, i.e. after ~r1471.

I ask because I used to be able to encode 1080p material with RC-Lookahead=60 and B-Frames=10 at my "default" settings, while increasing B-Frames to 16 caused memory allocation failure.

Now I updated to r1523 and suddenly B-Frames=10 didn't work anymore. This time I had to reduce it to B-Frames=8, in order to avoid memory allocation failure. And I didn't even use NAL-HRD.Sounds like an Avsiynth issue.I wonder, is this still in the making, now that "full" BluRay support has been committed? If so, what source did you pick after all? :confused:It's coming, along with the official announcement.

[LoRd_MuldeR]

Sounds like an Avsiynth issue.It's coming, along with the official announcement.

I'm not using Avisynth, I'm using Avidemux. And all I did is replacing the x264 DLL. So I don't think it's an issue in Avidemux.

Will do more testing this evening...

[kolak]

Tried 5min 60i footage and it did import and mux fine with Scenarist BD. Will try to burn BD-R and check on few BD players.
Looks promising :)

[shon3i]

Argh... Bad news...damn, can you at least tell me on what percent mux stoped, did is some black scene. Now we know that usually happens with solid/black/animation sources.

[Dark Shikari]

We're preparing everything to author our demo x264 Blu-ray. Here's what we have so far (http://mirror05.x264.nl/Dark/bluray/): three encoded video streams and three 5.1 audio streams (to be encoded however one wants).

Things we'd Like To Have:

1. A menu to pick between the three video clips.

2. A short intro sequence (I can make it, it'd just have to be integrated into the Blu-ray accordingly).

3. Some sort of background image or video loop for the main menu (Again, I can make the actual image/video).

Is there anyone here who has enough experience to do the Blu-ray authoring side of things for these tasks?

[Emulgator]

I can offer test compiles on:
Sony DVD-A 5.0b Build 180
Adobe Encore CS3 Build 3.0.1.008
Sonic/Roxio DVDitProHD 6.4 Build 641B03A
Ulead DVD-MF 6+ Build 6.00.0194.0 (not sure about transcoding preferences though)
(Pegasys TAW 4 Build 4.0.9.37 does not mux H.264 without transcoding anyway)

[kolak]

We're preparing everything to author our demo x264 Blu-ray. Here's what we have so far (http://mirror05.x264.nl/Dark/bluray/): three encoded video streams and three 5.1 audio streams (to be encoded however one wants).

Things we'd Like To Have:

1. A menu to pick between the three video clips.

2. A short intro sequence (I can make it, it'd just have to be integrated into the Blu-ray accordingly).

3. Some sort of background image or video loop for the main menu (Again, I can make the actual image/video).

Is there anyone here who has enough experience to do the Blu-ray authoring side of things for these tasks?


I will ask my colleague if he can put it together in Scenarist.
Can use some stock footage as a background.
Can encode audio to DTS-MA.

[Dark Shikari]

I will ask my colleague if he can put it together in Scenarist.
Can use some stock footage as a background.
Can encode audio to DTS-MA.I'll do all the art and stuff; don't need to do any of that.

Also, as you may be able to tell, I made a small screwup on the tallship encode, so re-doing that ;)

[kolak]

I'll do all the art and stuff; don't need to do any of that.

Also, as you may be able to tell, I made a small screwup on the tallship encode, so re-doing that ;)

Haven't seen it yet.
Is there a banding in this encodes (sources)?

[Dark Shikari]

Haven't seen it yet.
Is there a banding in this encodes (sources)?The mistake in tallship is setting the fps wrong ;)

Both Big Buck Bunny and Elephant's Dream have banding in the source. Do you think we should add grain or such?

[kolak]

The mistake in tallship is setting the fps wrong ;)

Both Big Buck Bunny and Elephant's Dream have banding in the source. Do you think we should add grain or such?

No- take 10bit source and convert to 8bit with Xscaler filter (or GradFun2DB) to have nice 8bit source for encoding :)

[Dark Shikari]

No- take 10bit source and convert to 8bit with Xscaler filter (or GradFun2DB) to have nice 8bit source for encoding :)OK, will redo the encode with that source after making sure there's no banding issues.

[kolak]

OK, will redo the encode with that source after making sure there's no banding issues.

Video with banding would give bad impression about whole Demo Disc :)

[MatLz]

Mirroring of 32pixels (16 are sometimes not enough; try with a strength of 200 and search all along the video, you will see)
Second stage with 28pixels mirroring because it's not the same effect (a kind of shifting something, I don't know what, I'm not expert enough; try with a strength of 200, you will see) and is REALLY a nice complement/addition to the first stage.
Strength at the minimum (1.001) is enough for two stages filtering.

Code in my next post.
Hope that can help for quality's project.

[MatLz]

function dbd(clip DBDIN,float "str", int "mp")
{
str=default(str,1.001)
mp=default(mp,32)
DBDIN
stackhorizontal(fliphorizontal(crop(0,0,mp-width,0)),last,fliphorizontal(crop(width-mp,0,0,0)))
stackvertical(flipvertical(crop(0,0,0,mp-height)),last,flipvertical(crop(0,height-mp,0,0)))
crop(gradfun2db(str),mp,mp,-mp,-mp)
}source
dbd()
#<- good place of a sharpening if it's needed
dbd(mp=28)

[rack04]

I noticed that Elephants Dream is 1080p @ 24000/1000fps. Is this allowable on Blu-ray?

[sneaker_ger]

Yes. Pretty much every movie released on Blu-Ray has that format.

[rack04]

Yes. Pretty much every movie released on Blu-Ray has that format.

Actually pretty much every movie is 1080p @ 24000/1001fps.

From the GIT commit:

Furthermore, note the Blu-ray spec has very strict limitations on allowed resolution/fps combinations. Examples include 1080p @ 24000/1001fps (NTSC FILM) and 720p @ 60000/1001fps.

[sneaker_ger]

Ah, sorry, saw so many numbers that my brain assumed 24000/1001. But 24000/1000 is also allowed.

[MadMonkey57]

We're preparing everything to author our demo x264 Blu-ray. Here's what we have so far (http://mirror05.x264.nl/Dark/bluray/): three encoded video streams and three 5.1 audio streams (to be encoded however one wants).

Things we'd Like To Have:

1. A menu to pick between the three video clips.

2. A short intro sequence (I can make it, it'd just have to be integrated into the Blu-ray accordingly).

3. Some sort of background image or video loop for the main menu (Again, I can make the actual image/video).

Is there anyone here who has enough experience to do the Blu-ray authoring side of things for these tasks?

Well I am not an expert, but I have authored a few BDs with TV show episodes, family movies, menus/sub-menus, with/without subtitles, ... I use Adobe Encore CS4.

While I am pretty much useless with the art stuff, I am *confortable* with the authoring itself. I seem to understand that is what you are looking for.

Another thing is that I'll be on vacation april 14th - april 30th thus unable to help at that time.

[G_M_C]

OK, will redo the encode with that source after making sure there's no banding issues.


Also make note that the projects for 10 bit and/or 4:2:2/4:4:4 processing get the priority they deserve in the upcoming GSoC


Until then: Wow, this is a huge milestone for x264 in the making http://gathering.tweakers.net/global/smileys/worshippy.gif

[jpsdr]

damn, can you at least tell me on what percent mux stoped, did is some black scene. Now we know that usually happens with solid/black/animation sources.

It's stopping at 63%, my mux is going to 33% almost instantly,
after, big ts file begin, during this, i'm switching screen/keybord on my other PC.
But, it seems that this 63% are the end of the file, wich is the black rolling ending credit.
Problem seems only to happen with nal-hrd cbr, wich is not to be used, according DS.
Last encoded with 2 pass asking for bitrate=max=40000, with faster parameters on 1rst pass, and nal-hrd vbr, give me better expected bitrate (around 38800), than one pass with asked bitrate at 39000 and nal-hrd vbr (result was 33000). My last encode (the 2 pass) muxed fine yesterday evening, so, actualy, nal-hrd cbr is not BR compliant, but nal-hrd vbr is. That's my conclusion, and i'll stop my tests wich take 18h each time !

[shon3i]

@jpsdr thank you so much. Btw Blu-Ray only requires Type2 HRD, cbr hrd is fine with BD too,