NAL HRD has been committed!

[kieranrk]

Patch has now been committed.

Features

Writing of pic_timing and buffering_period SEI units as required by Blu-Ray etc.
libx264 returns hrd timing information. This means muxers don't have to parse the bitstream to utilise this information (new)
CBR (filler rbsp) and VBR HRD
Valid support for pulldown
VFR VBV and VFR ratecontrol

[sneaker_ger]

"pthreadGC2.dll not found" on start even with standard settings. Windows XP SP3.

[bnshrdr]

"pthreadGC2.dll not found" on start even with standard settings. Windows XP SP3.

You will need to either obtain the specified pthread dll or use the patch to compile your own static x264 build. The OP hast just provided a x264 build with that dependency.

@kieranrk: Also what else is in your binary, just vanilla + your patch?

[moviefan]

What is the difference of this patch to the x264_hrd_interlace_xxxx.diff?

[sneaker_ger]

Thx, works now. (Get pthreadGC2.dll (ftp://sourceware.org/pub/pthreads-win32/dll-latest/lib/pthreadGC2.dll) here, if anyone else needs it)

[shon3i]

What is the difference of this patch to the x264_hrd_interlace_xxxx.diff?
and

1. Who is author
2. Did this patch are completly different to Alex or Trahald
3. Did you work for x264 team? i mean did this after some testing get finaly into git. I won't give my feedback if this is another try. I want to know if this is for merging into git.
4. please somebody do a normal compile

[kieranrk]

What is the difference of this patch to the x264_hrd_interlace_xxxx.diff?

Cleaned up and minor things fixed up.

1. Who is author
2. Did this patch are completly different to Alex or Trahald
3. Did you work for x264 team? i mean did this after some testing get finaly into git. I won't give my feedback if this is another try. I want to know if this is for merging into git.
4. please somebody do a normal compile

1/2 - Zmgorynych == Alex Giladi. I added the hrd timing parts.
3. Yes. Yes this is for merging into git. Alex isn't going to be around much so I'm going to push to get this patch merged.
4. Sorry about that. EDIT: new one should be static.

@kieranrk: Also what else is in your binary, just vanilla + your patch?
Yes. Just vanilla and the patch.

[sneaker_ger]

New build works fine without the dll. Two typos in the help:
--nal-hrd, Signal HRD information (needed e.g. for blu-ray compliance
requires vbv-maxrate and vbv-bufsize
1. ","
2. missing ")"

[VFR maniac]

Hi Kieranrk, your patch doesn't write Buffering Period SEI unless the muxer is raw.

[shon3i]

Ok, patch working corectly, muxing passes, BD verification passes. What we need to test more?

[kieranrk]

Ok, patch working corectly, muxing passes, BD verification passes. What we need to test more?

I've changed it a bit now, fixed some bugs and am adding CBR HRD. Possibly this might have introduced a bug so I'll upload a new patch either tonight or tomorrow.

[komisar]

kieranrk, build 1400 version of x264 with you patch get failure...
checkasm report:x264: SSSE3
- pixel ssd : [OK]
- pixel satd : [OK]
- pixel sa8d : [OK]
- pixel var2 : [OK]
- pixel hadamard_ac : [OK]
- intra satd_x3 : [OK]
- intra sad_x3 : [OK]
- esa ads: [OK]
- sub_dct4 : [OK]
- sub_dct8 : [OK]
- add_idct4 : [OK]
- zigzag_frame : [OK]
- zigzag_field : [OK]
- mc chroma : [OK]
- mc wpredb : [OK]
- hpel filter : [OK]
- lowres init : [OK]
predict_16x16[3] : [FAILED]
30 69 9d 71 4d 5d 71 a0 c4 b1 8d 86 a0 af 9e ae cf
4e 51 57 5d 62 68 6e 74 7a 80 86 8c 92 98 9e a3 a9
8f 58 5e 64 6a 70 76 7c 81 87 8d 93 99 9f a5 ab b1
85 5f 65 6b 71 77 7d 83 89 8f 95 9b a0 a6 ac b2 b8
37 67 6d 73 79 7e 84 8a 90 96 9c a2 a8 ae b4 b9 bf
2d 6e 74 7a 80 86 8c 92 97 9d a3 a9 af b5 bb c1 c7
70 75 7b 81 87 8d 93 99 9f a5 ab b1 b6 bc c2 c8 ce
87 7d 83 89 8f 94 9a a0 a6 ac b2 b8 be c4 ca d0 d5
5d 84 8a 90 96 9c a2 a8 ae b3 b9 bf c5 cb d1 d7 dd
0 8c 91 97 9d a3 a9 af b5 bb c1 c7 cc d2 d8 de e4
0 93 99 9f a5 aa b0 b6 bc c2 c8 ce d4 da e0 e6 eb
1 9a a0 a6 ac b2 b8 be c4 c9 cf d5 db e1 e7 ed f3
0 a2 a7 ad b3 b9 bf c5 cb d1 d7 dd e3 e8 ee f4 fa
0 a9 af b5 bb c1 c6 cc d2 d8 de e4 ea f0 f6 fc ff
0 b0 b6 bc c2 c8 ce d4 da df e5 eb f1 f7 fd ff ff
0 b8 bd c3 c9 cf d5 db e1 e7 ed f3 f9 fe ff ff ff
0 bf c5 cb d1 d7 dc e2 e8 ee f4 fa ff ff ff ff ff

4b 52 59 5f 66 6d 73 7a 81 88 8e 95 9c a2 a9 b0
52 59 60 67 6d 74 7b 81 88 8f 96 9c a3 aa b0 b7
5a 60 67 6e 75 7b 82 89 90 96 9d a4 aa b1 b8 bf
61 68 6f 75 7c 83 89 90 97 9e a4 ab b2 b8 bf c6
68 6f 76 7d 83 8a 91 97 9e a5 ac b2 b9 c0 c7 cd
70 77 7d 84 8b 91 98 9f a6 ac b3 ba c0 c7 ce d5
77 7e 85 8b 92 99 9f a6 ad b4 ba c1 c8 ce d5 dc
7e 85 8c 93 99 a0 a7 ae b4 bb c2 c8 cf d6 dd e3
86 8d 93 9a a1 a7 ae b5 bc c2 c9 d0 d6 dd e4 eb
8d 94 9b a1 a8 af b5 bc c3 ca d0 d7 de e5 eb f2
95 9b a2 a9 af b6 bd c4 ca d1 d8 de e5 ec f3 f9
9c a3 a9 b0 b7 bd c4 cb d2 d8 df e6 ec f3 fa ff
a3 aa b1 b7 be c5 cc d2 d9 e0 e6 ed f4 fb ff ff
ab b1 b8 bf c5 cc d3 da e0 e7 ee f4 fb ff ff ff
b2 b9 bf c6 cd d3 da e1 e8 ee f5 fc ff ff ff ff
b9 c0 c7 cd d4 db e2 e8 ef f6 fc ff ff ff ff ff
- intra pred : [FAILED]
- quant : [OK]
- denoise dct : [OK]
- decimate_score : [OK]

P.S. huh, maybe this is not nal-hrd-patch... investigation continues...
P.P.S. apparently I broke intel-support patch... sorry...

[kieranrk]

Please test this new revision to make sure I haven't broke anything.

There are a few things left and it should be ready for final review.

[shon3i]

I just successfully produced two Blu-ray movies ;). Tell me about CBR-HRD what is recommendation for ratecontrol? With CRF i can't specify bitrate, is it only for ABR and 2pass, and what is advantage of CBR instead VBR HRD

[Dark Shikari]

I just successfully produced two Blu-ray movies ;). Tell me about CBR-HRD what is recommendation for ratecontrol? With CRF i can't specify bitrate, is it only for ABR and 2pass, and what is advantage of CBR instead VBR HRDCBR HRD implies filler bytes; it is not necessary or recommended for Blu-ray.

[mopurist]

When I try http://pastebin.com/d51413f02 pastebin says "Unknown post id, it may have expired or been deleted."

Is there a new version about? Merged into git? Anyone care to share?

Thanks.

[kieranrk]

When I try http://pastebin.com/d51413f02 pastebin says "Unknown post id, it may have expired or been deleted."

Is there a new version about? Merged into git? Anyone care to share?

Thanks.

I probably set the expiration date too soon.

See: http://pastebin.com/m44061f19

(some minor changes)

[VFR maniac]

http://pastebin.com/m44061f19

bs_realign is missing...

[mp3dom]

I don't know which BD verifier were used by shon3i, anyway I've made an encode with x264+1.1 NAL-HRD (the version at the 1st post) on the Elephant's Dream video. Using the Interra BDQuest Verifier it gave me 3 fatal errors. I must say that Scenarist MUI Generator (and Scenarist itself) accepts and mux without problems.
I've activated the --nal-hrd, --slices 4 and --aud, fps were 24p and resolution were 1920x1080 (obviously)
The error output of BDQuest says:
- 'pict_struct_present_flag', expected (1), found (0)
- Compression Ratio (CR) is less than MinCR (4). Number of bytes in NAL unit (1096693) is more than the maximum limit (983040)
- 'slice_type' in 'I Type' picture must be (7), found (2)

Regarding the first error (pict_struct_present_flag) I've see that in this x264 version there's a specific flag (--pict-struct) that is enabled by default for interlaced footage... Could be that it is mandatory for bluray?
I've got 8 errors regarding the "Compression Ratio (CR) is less than etc. etc. etc.". In every error the NAL unit value change and it's value is always bigger than the maximum limit of 983040.
About the third error, I want to say that this error appear even on encodes made by CineVision or the Scenarist Still Image Encoder. I think that this error could be ignored...

Hope this helps!
Thanks!

[kieranrk]

bs_realign is missing...

Forgot about that. Will post a corrected one.

Regarding the first error (pict_struct_present_flag) I've see that in this x264 version there's a specific flag (--pict-struct) that is enabled by default for interlaced footage... Could be that it is mandatory for bluray?

Presumably so. (See the spec ;) )

I've got 8 errors regarding the "Compression Ratio (CR) is less than etc. etc. etc.". In every error the NAL unit value change and it's value is always bigger than the maximum limit of 983040.

Not sure about this one; I'm double checking the H.264 spec about this. Try with the new patch and build I will post in a second to double check it isn't related to the bitstream issues.

[shon3i]

I don't know which BD verifier were used by shon3iI have both Sony and Interra, but last time i didn't checked with verifier :) so maybe is problem something with patch 1.1. I will test now with 1.2.

And about MinCR from specs:

Minimum compression ratio (MinCR) (Note) for Main profile and the equivalent constraint for High
profile shall be restricted as follows;
�� For Main profile level 4.1, MinCR=4 for movie stream, MinCR=2 for still picture
�� For High profile level 4.1, the same semantic constraint as described above shall be applied.
�� For other levels of High profile, the same semantic constraint on MinCR for Main profile shall
be applied.
(Note): The semantic constraint on MinCR for Main profile is described in Annex A of the ISO/IEC
14496-10[11].


btw here is about for pict_struct_present_flag

• pic_struct (in Picture timing SEI) shall be present if frame_mbs_only_flag in SPS is set to 0.
pic_struct_present_flag shall be set to 1 to satisfy this restriction.


Btw so we always must use --pict-struct ? is this something changed, because earler version don't have this command and stream came out with this assumed. I think, this should be always on since is mandatory for Blu-Ray

[kieranrk]

btw here is about for pict_struct_present_flag

..

Btw so we always must use --pict-struct ? is this something changed, because earler version don't have this command and stream came out with this assumed.

In progressive mode we set frame_mbs_only_flag to 1 so pic_struct is not necessary.

In the past pic_struct was on automatically with interlaced. Now it only turns on automatically if you use pulldown. I've changed it to be on in interlaced mode.

About the third error, I want to say that this error appear even on encodes made by CineVision or the Scenarist Still Image Encoder. I think that this error could be ignored...

Yes that error is wrong. The first one is also wrong. Dark Shikari also tried that verifier a while ago and it kept claiming things that were clearly not true.

[mp3dom]

With 1.21 patch the problem of "Compression Ratio (CR) is less than MinCR(4)... bytes in NAL unit (xxx) more than maximum limit etc etc" still persist.

[kolak]

I don't know which BD verifier were used by shon3i, anyway I've made an encode with x264+1.1 NAL-HRD (the version at the 1st post) on the Elephant's Dream video. Using the Interra BDQuest Verifier it gave me 3 fatal errors. I must say that Scenarist MUI Generator (and Scenarist itself) accepts and mux without problems.
I've activated the --nal-hrd, --slices 4 and --aud, fps were 24p and resolution were 1920x1080 (obviously)
The error output of BDQuest says:
- 'pict_struct_present_flag', expected (1), found (0)
- Compression Ratio (CR) is less than MinCR (4). Number of bytes in NAL unit (1096693) is more than the maximum limit (983040)
- 'slice_type' in 'I Type' picture must be (7), found (2)

Regarding the first error (pict_struct_present_flag) I've see that in this x264 version there's a specific flag (--pict-struct) that is enabled by default for interlaced footage... Could be that it is mandatory for bluray?
I've got 8 errors regarding the "Compression Ratio (CR) is less than etc. etc. etc.". In every error the NAL unit value change and it's value is always bigger than the maximum limit of 983040.
About the third error, I want to say that this error appear even on encodes made by CineVision or the Scenarist Still Image Encoder. I think that this error could be ignored...

Hope this helps!
Thanks!

3rd error seams to be Interra verifier bug- it's also reported on Cinevision and Blu-code streams.
Does Sony verifier show the same?

MUI generator does very basic checks- it can't be used to verify compliance- way not good enough.

[mp3dom]

We only have the Interra verifier and don't have the Sony. I'm more "worried" about the second (Compression Ratio) since with the CineVision encodes that error doesn't show.

[moviefan]

MUI generator does very basic checks- it can't be used to verify compliance- way not good enough.

Does that mean that the x264_hrd_interlace patch might be broken too? It passed MUI Generator and thus I thought it produces BD compliant steams.

[mp3dom]

Like kolak says, the MUI generator made only a basic check and it's not reliable. Only the verifier (and not all of them, like you can see :)) can validate a stream as 100% BD compliant. Also the mastering factory have it's own verifier (before pressing the BD). Don't know if it's 100% reliable, but the EclipseSuite BD it's renowned to be very strict about specs.

[shon3i]

Does Sony verifier show the same?I can test, but not until next week, because i am on short vacation, and i don't have access to BD Verifier on my work.

Does that mean that the x264_hrd_interlace patch might be broken too? I don't think so, muxing stage do other checks like VBV and HRD VBV, so broken HRD will affect on muxing. I saw many streams which not pass muxing in scenarist even some are demuxed from original titles.

Anyway did we sure that many DVD's today are 100% DVD compilant, and now many broken streams work on most standalones :)

I want to say both Verifiers maybe are not good and have bugs ;)

[kolak]

I can test, but not until next week, because i am on short vacation, and i don't have access to BD Verifier on my work.

I don't think so, muxing stage do other checks like VBV and HRD VBV, so broken HRD will affect on muxing. I saw many streams which not pass muxing in scenarist even some are demuxed from original titles.

Anyway did we sure that many DVD's today are 100% DVD compilant, and now many broken streams work on most standalones :)

I want to say both Verifiers maybe are not good and have bugs ;)

There are lots DVDs, which are out of DVD spec, but mainly because of lack of knowledge or because some people just don't care. It's also because there are many DVD authoring softwares which don't produce fully compliant projects and again even if authors know about it, they just don't care (because client doesn't care and wants everything as cheap as possible). There are also many well authored DVDs, which don't work on some players, because these players (even if they have official DVD-Video logo on them) never went through any compatibility checks or test. These players should not be on the market or at least they should not have DVD logo- it's kind of crime :)

Interra verifier is not very reliable (there are still many missing features). Sony verifier is an "old" software and way more reliable, so it's the best to use this one to check x264 streams.

[rack04]

Version 1.21 does not patch correctly the latest git. I get 6 failed hunks.

[kieranrk]

Version 1.21 does not patch correctly the latest git. I get 6 failed hunks.

I'll upload the fixed patch in a few minutes.

[Emulgator]

BTW: Sony Vegas 9.0c MPEG-4 Encoder .avc outputs pic_struct_present =1.

http://doom10.org/index.php?topic=7.0

Post 18, last screenshot. (Sony Vegas Header SPS bottom)

[shon3i]

BTW: Sony Vegas 9.0c MPEG-4 Encoder .avc outputs pic_struct_present =1.

http://doom10.org/index.php?topic=7.0

Post 18, last screenshot. (Sony Vegas Header SPS bottom)
In bd specs clearly stay "pic_struct (in Picture timing SEI) shall be present if frame_mbs_only_flag in SPS is set to 0", frame_mbs_only is 1 for progressive encodes.

[kieranrk]

Just use --pic-struct if for whatever reason the program you use wants it.

[mp3dom]

Correct me if I'm wrong: the 'picture structure' field could have different values for what I've read... like (i.e., dunno if it's wrong or not, i don't have the specs) 3 for TFF or 4 for BFF. In case of a progressive encode the --pic-struct parameter write 1?
Latest question: the 1.22 patch tries in some way to fix the 'problem' regarding MinCR? I can try to encode again and redo the verification pass if necessary otherwise I'll wait for anoter patch version (I don't have a performant CPU, so I need a bit of time)
Thank you very much!

[kieranrk]

Correct me if I'm wrong: the 'picture structure' field could have different values for what I've read... like (i.e., dunno if it's wrong or not, i don't have the specs) 3 for TFF or 4 for BFF. In case of a progressive encode the --pic-struct parameter write 1?

Latest question: the 1.22 patch tries in some way to fix the 'problem' regarding MinCR? I can try to encode again and redo the verification pass if necessary otherwise I'll wait for anoter patch version (I don't have a performant CPU, so I need a bit of time)
Thank you very much!

For progressive the value of pic_struct is 0.

I'm almost certain this 'problem' with MinCR is a mistake by the validator.

[rack04]

V1.22

patch: Unexpectedly ends in the middle of line
patch: **** only garbage was found in the patch input.

[Emulgator]

Reading H.264 further, but well, I will rather post that without my conclusions, I have none at the moment ;-)
Hopefully it helps developers and the people who have verifiers...

frame_mbs_only_flag equal to 0 specifies that coded pictures of the coded video sequence may either be coded fields or coded frames.
frame_mbs_only_flag equal to 1 specifies that every coded picture of the coded video sequence is a coded frame containing only frame macroblocks.

When the value of profile_idc does not indicate conformance to any of the profiles specified in Annex A
and vui_parameters_present_flag is equal to 1,
timing_info_present_flag shall be equal to 0,
nal_hrd_parameters_present_flag shall be equal to 0,
vcl_hrd_parameters_present_flag shall be equal to 0,
and pic_struct_present_flag shall be equal to 0.

When the value of profile_idc does indicate conformance to one or more of the profiles specified in Annex A
and vui_parameters_present_flag is equal to 1,
the values of
timing_info_present_flag,
num_units_in_tick,
time_scale,
fixed_frame_rate_flag,
nal_hrd_parameters_present_flag,
vcl_hrd_parameters_present_flag,
low_delay_hrd_flag,
pic_struct_present_flag
and the values of syntax elements included in the hrd_parameters( ) syntax structures,
when present,
shall be such that the bitstream activating the sequence parameter set
is conforming to one or more of the profiles specified in Annex A.


pic_struct_present_flag equal to 1 specifies that picture timing SEI messages (subclause D.2.2) are present that include the pic_struct syntax element.
pic_struct_present_flag equal to 0 specifies that the pic_struct syntax element is not present in picture timing SEI messages.
When pic_struct_present_flag is not present, its value shall be inferred to be equal to 0.


D.2.2 Picture timing SEI message semantics
The presence of picture timing SEI message in the bitstream is specified as follows.
– If CpbDpbDelaysPresentFlag is equal to 1 or pic_struct_present_flag is equal to 1,
one picture timing SEI message shall be present in every access unit of the coded video sequence.
– Otherwise (CpbDpbDelaysPresentFlag is equal to 0 and pic_struct_present_flag is equal to 0),
no picture timing SEI messages shall be present in any access unit of the coded video sequence.

Table D-1 – Interpretation of pic_struct
Value -> Indicated display of picture, Restrictions; NumClockTS
0 -> frame -> field_pic_flag shall be 0; NumClockTS=1
1 -> top field ->field_pic_flag shall be 1, bottom_field_flag shall be 0; NumClockTS=1
2 -> bottom field ->field_pic_flag shall be 1, bottom_field_flag shall be 1; NumClockTS=1
3 -> top field, bottom field, in that order -> field_pic_flag shall be 0; NumClockTS=2
4 -> bottom field, top field, in that order -> field_pic_flag shall be 0; NumClockTS=2
5 -> top field, bottom field, top field repeated, in that order -> field_pic_flag shall be 0; NumClockTS=3
6 -> bottom field, top field, bottom field repeated, in that order -> field_pic_flag shall be 0; NumClockTS=3
7 -> frame doubling -> field_pic_flag shall be 0, fixed_frame_rate_flag shall be 1; NumClockTS=2
8 -> frame tripling -> field_pic_flag shall be 0, fixed_frame_rate_flag shall be 1; NumClockTS=3
9-15 -> Reserved

[kieranrk]

Just out of interest does Blu-ray let you code 1080p25 without using interlacing? Can you use 1080p25 will pic_struct or something?

Also is there anything about NumClockTS?

[Rumbah]

I've seen a German BluRay with 1080p25 if i remember correctly, but I don't know which one it was. If it's important I can search for it ;) .

[shon3i]

Just out of interest does Blu-ray let you code 1080p25 without using interlacing? Can you use 1080p25 will pic_struct or something?

Also is there anything about NumClockTS?
Not without --interlaced switch (scenarist) and earler version of HRD patches. I will now test with or without pic_struct. Please give me few hours :)

[Trahald]

While in practice it may be different, 1080p25 is not allowed.

[shon3i]

While in practice it may be different, 1080p25 is not allowed.
Encocoding progressive material with interlaced switch you get interlaced video 1080i25 which is allowed, and scenarist detect it as 1080i25.

[kolak]

While in practice it may be different, 1080p25 is not allowed.

You ave to encode it as it would be 50i and it does work.
If you have a good player you may get original 25p on your TV.

Andrew

[Atak_Snajpera]

PS3 plays 1080p 25fps without problems. I wouldn't be surprised if this also applies to other good brands.

[kolak]

PS3 plays 1080p 25fps without problems. I wouldn't be surprised if this also applies to other good brands.

It's not about what PS3 or even any other player can play- BD doesn't support pure 25p/30p modes.
PS3 can play much more than BD spec allows- it did play 100Mbit AVC, but at maybe 5fps :)


Andrew

[mp3dom]

Back to the NAL patch: At the end I'm not understanding if the current patch version (1.22) match the specs posted by Emulgator.

[kieranrk]

Back to the NAL patch: At the end I'm not understanding if the current patch version (1.22) match the specs posted by Emulgator.

It does.

[shon3i]

BD doesn't support pure 25p/30p modes.Well support it as Secondary video, so is generaly supported. That's why i liked HDDVD, maybe is less overall bitrate and storage, but twice more Video and Audio combination are allowed.

[renqian]

here some primary question:
which Splitter Filter should i use to keep the field won't loss when i encoding?
and which decoder can playback the product correctly in 60fps on LCD or LCD TV?(i mean if i use the HTPC)

[rack04]

Is anyone able to patch the latest git with v1.22?

[rallymax]

no. I've just manually done the change . When I get home I'll copy it onto my SVN tree so that I can generate a diff and post it.

[mp3dom]

It does.
Thank you very much! Since you're so kind, can I ask what are the next steps before final commit? Is there something new that need to be tested? (with the Interra verifier I cannot test anything more). Thanks again!

[alwa]

Is anyone able to patch the latest git with v1.22?

Ready to patch. (http://www.mediafire.com/file/imdmvtyngyz/nal-hrd1.22_fix.diff) The @@ get removed by patebin...

[jpsdr]

Can someone make a patch with it and the autoVAQ ?

Thanks.

[kieranrk]

Thank you very much! Since you're so kind, can I ask what are the next steps before final commit? Is there something new that need to be tested? (with the Interra verifier I cannot test anything more). Thanks again!

Need to fix max_cpb_delay_length with pulldown changes because it's wrong.
Also need to fix bug with calculation of displayed frames because it doesn't take into account any new parameters pass with the frame.

Needs a pengvado review.

Ready to patch. The @@ get removed by patebin...

Use the download button in pastebin.

[rallymax]

Use the download button in pastebin.

I did that and it still wouldn't apply.
what are you all using as your patching command line - and is in on Msys?

[kieranrk]

patch -p1 <in.diff

If it doesn't work I'll post a new one.

[rallymax]

Version 1.22.

Patch: http://pastebin.com/m6ed0b13a

I used the above URL and did "download" and saved it as "nal-hrd-1.2.2.diff".

I then applied it in a Msys to a vanilla git checkout on Windows7 and got this error...

rallymax@CARTMAN /c/SVN/x264 <--- don't let the SVN throw you off. it is a git directory.
$ patch -p1 < nal-hrd-1.2.2.diff
patch unexpectedly ends in middle of line
patch: **** Only garbage was found in the patch input.

So I have no idea what's wrong. Note, that I've never applied a patch before so it could be the host that's screwed up not the patch itself.

[alwa]

Use the download button in pastebin.
That does not help, the @@ are still missing... Try yourself if you don't believe me.


The file i uploaded on mediafire (http://www.mediafire.com/file/imdmvtyngyz/nal-hrd1.22_fix.diff) contains them, it works with the following command:

patch -p1 < nal-hrd1.22_fix.diff

[rack04]

That does not help, the @@ are still missing... Try yourself if you don't believe me.


The file i uploaded on mediafire (http://www.mediafire.com/file/imdmvtyngyz/nal-hrd1.22_fix.diff) contains them, it works with the following command:

patch -p1 < nal-hrd1.22_fix.diff

I concur.

[rallymax]

I concur.

yup. worked for me using that one too. thanks for that!

[woah!]

ok so should i be using nalhrd vbr or cbr with a 2 pass bluray encode for a standalone player.... i am getting lost again with this stuff...

[rack04]

ok so should i be using nalhrd vbr or cbr with a 2 pass bluray encode for a standalone player.... i am getting lost again with this stuff...

You should be using vbr.

[woah!]

thank you :0

[rallymax]

Is this pair of commands correct for BD legal output?

--pass 1 --nal-hrd vbr --slices 4 --aud --vbv-bufsize 2 --bitrate 48000000
--pass 2 --nal-hrd vbr --slices 4 --aud --vbv-bufsize 2 --bitrate 48000000

How about for a AVCHD/DVD as the target? Is it the same but with lower bitrate to keep up with the DVD-R's maximum?
thx.

[kieranrk]

Is this pair of commands correct for BD legal output?

--pass 1 --nal-hrd vbr --slices 4 --aud --vbv-bufsize 2 --bitrate 48000000
--pass 2 --nal-hrd vbr --slices 4 --aud --vbv-bufsize 2 --bitrate 48000000

How about for a AVCHD/DVD as the target? Is it the same but with lower bitrate to keep up with the DVD-R's maximum?
thx.

--vbv bufsize 30000 --vbv-maxrate 40000 --bitrate xxx (in kbit/s) along with what you wrote.

[poisondeathray]

you also need to specify gop size (assuming 1080p24), and ref frames

--keyint 24 --min-keyint 2 --ref 4

look up some posts by "shon3i" , he's posted some charts and info on what settings to use for different sources (e.g. 720p vs. 1080p , gop size, buffer, reference frames etc...) and tested them with several BD verification tools

for dvd5/9 media, you can't use that high of bufsize and maxrate, you have to use something lower (has to do with read speeds). I think jdobbs in bdrebuilder uses

--vbv bufsize 17500 --vbv-maxrate 14500

There were several threads that attempted to centralize all that info, but none got "stickied", and the search engine here is well... you know...

If shon3i would volunteer to write up all that info (since he has access to the verifcation tools) , and a mod could "sticky" it ; I think that would be a great help to many folks

[rallymax]

thanks PDR for the pointer. I found shon3i's post (http://forum.doom9.org/showthread.php?p=1368828#post1368828)
That plus your info from jdobbs will get me over the line I think.

[rallymax]

If shon3i would volunteer to write up all that info (since he has access to the verifcation tools) , and a mod could "sticky" it ; I think that would be a great help to many folks
:goodpost:
I AGREE! It's a serious challenge to work it all out!
But... I do have output now and am very close to throwing a beta out to see if it breaks.

[mp3dom]

48 Mbps is the total mux rate but the maximum allowed for the video is 40 Mbps.

[rack04]

I haven't had much success using v1.22 on my Panasonic BD35. It refuses to play. I plan on testing x264_hrd_pd_interlace.21_r1416 to see if it works.

[shon3i]

x264_hrd_pd_interlace.21_r1416So Trahald continue his work? I know that rev16 is last working and passes all verificators. rev18 has ben screwed i didn't know there is newer revesion.

[rack04]

So Trahald continue his work? I know that rev16 is last working and passes all verificators. rev18 has ben screwed i didn't know there is newer revesion.

http://komisar.gin.by/x.patch/last.used/x264_hrd_pd_interlace.21_r1416.diff

[shon3i]

If shon3i would volunteer to write up all that info (since he has access to the verifcation tools) , and a mod could "sticky" it ; I think that would be a great help to many folksinstead of writing, i started to make a small application (GUI) for x264 which will generate commandline

[MuLTiTaSK]

@shon3i

generate compatible switches for devices or just BluRay?

[Selur]

Not totally sure if this is the right thread to ask, but could someone explain the pulldown options ?
- 32 = 3:2 pull-down 24fps -> 30fps (for NTSC source)
- 64 = 6:4 pull-down 24fps -> 120fps (or was it 60fps? for NTSC source)
what does double, triple and euro do? (guessing that euro is ment for FILM->PAL)

Cu Selur

[poisondeathray]

instead of writing, i started to make a small application (GUI) for x264 which will generate commandline

Thanks shon3i , for sharing your testing results and helping with settings. I actually have many of your older posts bookmarked. Looking foward to that application

Cheers

[poisondeathray]

Not totally sure if this is the right thread to ask, but could someone explain the pulldown options ?
- 32 = 3:2 pull-down 24fps -> 30fps (for NTSC source)
- 64 = 6:4 pull-down 24fps -> 120fps (for NTSC source)
what does double, triple and euro do? (guessing that euro is ment for FILM->PAL)



Good question. I thought x264 pulldown hasn't been implemented yet? Maybe someone can clarify

Another option could be DGAVCPulldown for 3:2 (not sure how well it works for soft pulldown)

[Selur]

after some digging:
- 32: 3:2 pulldown e.g. 24->30fps
- 64: 6:4 pulldown e.g. 24->60fps
- double double the frames e.g. 24->48fps
- triple triples the frames e.g. 24->72fps
- euro 24->25 fps
Not sure if the pulldown flags work, since I'm not sure which decoder honors the flags. :) (at least ffdshow-mt doesn't or the flags are not working)

Cu Selur

[komisar]

I don't have time to test correctness of this patch (http://komisar.gin.by/x.patch/last.used/x264_NAL-HRD.1.22.r1442.diff). Who can test his?

[ts4053]

Interlacing is not working with hw deinterlacer when source is interlaced. Only bob working. Temporal and Temporal spatial from vdpau:deint is not working. Tested with nvidia opengl display adapter and also with Sony mpeg4 TV. Last working version was "x264_hrd_pd_interlace.21_r1416.diff" against x264_rev1416M. I can't patch "x264_hrd_pd_interlace.21_r1416.diff" against r1442 so i don't know is the problem with patch or in r1442 revision.

encoder params: x264 -o 1080i25_parkrun_ter.264 --profile high --level 4 --ref 4 --vbv-bufsize 10000 --vbv-maxrate 10000 --bitrate 10000 --fps 25 --interlace --videoformat pal --colorprim bt709 --transfer bt709 --colormatrix bt709 1080i25_parkrun_ter.yuv 1920x1080

[rack04]

I don't have time to test correctness of this patch (http://komisar.gin.by/x.patch/last.used/x264_NAL-HRD.1.22.r1442.diff). Who can test his?

Here (http://www.multiupload.com/PK44PG1ORI) is a sample that I encoded using x264 r1442M patched with x264_NAL-HRD.1.22.r1442.diff. I would appreciate if someone with Sceanarist could verify whether or not this stream is Blu-ray compliant. Thanks.

[Fr4nz]

With latest 1442 Komisar build apparently --nal-hrd parameter isn't working properly (in fact, the encoding doesn't start at all!); here's the error message reported from avs2yuv:

Source: E:\work\Up.avs
Output: E:\Output.mkv
Preset: Slow
Tuning: Film
Profile: High
Params: --nal-hrd --vbv-bufsize 15000 --vbv-maxrate 15000 --slices 4 --aud

Analyzing source file:
E:\work\Up.avs: 1920x1080, 2500000/104271 fps, 138282 frames

Resolution: 1920 x 1080
Frame No. : 138282
Frame Rate: 2500000/104271

x264 0.85.1442kGIT 781d300
built by Komisar on Feb 15 2010, gcc: 4.4.3 (x86_64.core2.Komisar)
Revision: 1442

Commandline for x264:
E:\dvd\avs2yuv\pipebuf.exe E:\dvd\avs2yuv\avs2yuv.exe E:\work\Up.avs - : E:\dvd\avs2yuv
\x264_x64.exe --preset slow --tune film --bitrate 4185 --pass 1 --stats E:\Output.mkv.x264-stats
--nal-hrd --vbv-bufsize 15000 --vbv-maxrate 15000 --slices 4 --aud --output E:\Output.mkv --frames
138282 --stdin y4m - : 4

x264 [error]: could not open input file `15000'
E:\work\Up.avs: 1920x1080, 2500000/104271 fps, 138282 frames
Output error: wrote only 2358715 of 3110400 bytes

Fatal Error: The encoder has encountered an unexpected error!

If I remove --nal-hrd parameter then the encoding starts properly. It seems a command-line parsing bug.

[rack04]

With latest 1442 Komisar build apparently --nal-hrd parameter isn't working properly (in fact, the encoding doesn't start at all!)

Check --fullhelp and you will notice the parameter has changed.

--nal-hrd <string> Signal HRD information (needed e.g. for Blu-Ray compliance)
- vbr, cbr. (requires vbv-bufsize; cbr-hrd not allowed in .mp4)

[Fr4nz]

Check --fullhelp and you will notice the parameter has changed.

--nal-hrd <string> Signal HRD information (needed e.g. for Blu-Ray compliance)
- vbr, cbr. (requires vbv-bufsize; cbr-hrd not allowed in .mp4)

Okay, thank you. I didn't notice this change...

[winnydows]

Hi.
Anybody know why interlaced TFF encoding don`t work ? BFF encoded fine. TFF encoded as BFF, all frames marked as BFF. PS3 play file as interlaced, but with frame jitter, as usual for wrong field order.
Tested with exe from first post, with own build, with libx264 + libavcodec too.
x264 --crf 21 --tff -o HD_Interlaced_MPEG_X264.mkv HD_Interlaced_MPEG.avs

[kieranrk]

Hi.
Anybody know why interlaced TFF encoding don`t work ? BFF encoded fine. TFF encoded as BFF, all frames marked as BFF.


Fixed locally. New version will be up later today.

[winnydows]

Thanks. Fix already uploaded or will be version number change?

How work with this .diff ? It`s different from standart patches.


$ patch -p0 < patch.diff
patch unexpectedly ends in middle of line
patch: **** Only garbage was found in the patch input.



$ git apply patch.diff
fatal: patch with only garbage at line 5



diff --git a/common/common.c b/common/common.c
index 6d1d7f0..ef401cb 100644
--- a/common/common.c
+++ b/common/common.c
-60,6 +60,9 @@ void x264_param_default( x264_param_t *param )
...


Normal patch look like:

diff -uNrp a/common/common.c b/common/common.c
--- a/common/common.c 2010-02-15 12:48:41 +0200
+++ b/common/common.c 2010-02-15 12:54:15 +0200
@@ -60,6 +60,9 @@ void x264_param_default( x264_param_t
...

[kemuri-_9]

Thanks. Fix already uploaded or will be version number change?
How work with this .diff ? It`s different from standart patches.


pastebin has a tendency to strip initial @@ in unified diff files.
you'll have to manually add them back if did strip them in the file.
strangely we usually don't have an issue with it during code reviews so it sounds like there's some bad copy/pasting going around.

[winnydows]

I found info in google about "pastebin has a tendency to strip initial @@ in unified diff files.".
But how users must apply this patch ? Block by block add removed @@ by hands and than "git apply patch.diff" ? Or exists other trick?

I`m don`t copy/paste patch:
Open pastebin page, use download button, save files as patch.diff.

fatal: patch with only garbage at line 5
Line 5 is:
-60,6 +60,9 @@ void x264_param_default( x264_param_t *param )
Line with removed @@.

[kemuri-_9]

I`m don`t copy/paste patch:
Open pastebin page, use download button, save files as patch.diff.

yes this patch is completely borked, i expect from bad copy/pasting from pastebin back to pastebin or something like the sort.

try doing something like

sed -e 's/^ -/@@ -/' borkpatch > workingpatch

i think that should restore the broken patch to the proper format.

[kieranrk]

New version should be fine.

[winnydows]

Thanks :).
Last patch + sed fix = clear patch.

If use patched x264 from code, how I must set pulldown type?
param->b_pulldown or cli_opt_t.i_pulldown ?
If cli_opt_t.i_pulldown only, can You please add posibility set pulldown type from param->.

I can explane why:
1. It`s better for logic.
2. libx264.c from ffmpeg don`t have any places for set cli_opt_t.

[Dark Shikari]

Thanks :).
Last patch + sed fix = clear patch.

If use patched x264 from code, how I must set pulldown type?
param->b_pulldown or cli_opt_t.i_pulldown ?
If cli_opt_t.i_pulldown only, can You please add posibility set pulldown type from param->.

I can explane why:
1. It`s better for logic.
2. libx264.c from ffmpeg don`t have any places for set cli_opt_t.It doesn't work that way. Pulldown requires that the calling application modify timestamps and set pic struct flags. libx264 does not modify timestamps. Therefore, libx264 cannot perform pulldown, it can only signal pulldown which has already been performed.

[winnydows]

Dark Shikari
Thanks for tip.

kieranrk
TFF encoding work fine now. Thanks a lot! :)

b_pic_struct
i_nal_hrd
Can be set from libx264.c without modify timestamps?

[shon3i]

Dark Shikari, when we celebrate :)

[Dark Shikari]

Dark Shikari, when we celebrate :)When we get approval from people with Blu-ray analyzers that this patch works.

[mp3dom]

I'll try tonight to made an encode and pass through BDQuest and see if it's ok. What need to be checked? VBR progressive/interlaced and CBR progressive/interlaced?
If shon3i could test with Sony Verifier :)

I don't really want to be tedious to kieranrk (really), but I've tested in BDQuest AVC streams coming from CineVision, Blu-Print and CC-HDe (commercial BD titles) and none of them create the "MinCR" problem in BDQuest. I know that the NAL-HRD patch coud adhere to the AVC specs but to be 100% sure, could you please put a look at it? Really, really thanks!!

[shon3i]

I still have no access to my workplace ;) but earler version eg. 1.22 passes normaly. Anyway sony verifier don't show any error or warning, but BDQuest show that MinCR, which not shoved in comercial encoders as mp3dom says.

[MadMonkey57]

I haven't had much success using v1.22 on my Panasonic BD35. It refuses to play. I plan on testing x264_hrd_pd_interlace.21_r1416 to see if it works.

Here (http://www.multiupload.com/PK44PG1ORI) is a sample that I encoded using x264 r1442M patched with x264_NAL-HRD.1.22.r1442.diff. I would appreciate if someone with Sceanarist could verify whether or not this stream is Blu-ray compliant. Thanks.

My 2 cents: x264-rev1442 + x264_NAL-HRD.1.22.r1442.diff are working fine on my BD35 (EU version, latest firmware).

[mp3dom]

Here (http://www.multiupload.com/PK44PG1ORI) is a sample that I encoded using x264 r1442M patched with x264_NAL-HRD.1.22.r1442.diff. I would appreciate if someone with Sceanarist could verify whether or not this stream is Blu-ray compliant. Thanks.

Scenarist accept and mux the file, however BDQuest (one of those BD Verifier) doesn't pass the validation.
The errors are:

- Max number of frames or field pairs which are stored in DPB is expected (4), found (6)
- 'frame_mbs_only_flag' is 0, and 'mb_adaptive_frame_field_flag' is 0, 1920x1080 video (field) is expected to contain '11/11/11/12' rows in slice. Found '11/12/11/11'

I'm reporting the errors 'as is'. For the first error I think the verifier is referring to "reference frames". The second error seems to refer to a fullhd video (your sorce is 720p24) but I haven't any idea about this error.

[shon3i]

Seems that BDQuest not follow BD-Specs, because clearly stay that 720p can use max 6 reference frames, and here is parametar limits for AVC

Parameter limits
Following constraints are applied for all HDMV MPEG-4 AVC video streams.
• Minimum size per one slice is 1 macroblock row (macroblock row or macroblock pair row). A slice
shall be composed of one or more macroblock rows. A macroblock row indicates all the
macroblocks in a horizontal row of macroblocks.
• Maximum number of frames or complementary field pairs which are stored in DPB is restricted in
addition to ITU-T H.264 | ISO/IEC 14496-10.
�� In case of level 4.1 and 4
�� For 1920x1080: 4 (as defined in ITU-T H.264 | ISO/IEC 14496-10[11].)
�� For 1440x1080: 4
�� For 1280x720: 6
�� For 720x480 or 720x576: 6
�� In case of level 3.2 and 3.1
�� For 720x480 or 720x576: 6
�� In case of level 3
�� For 720x480:6
�� For 720x576: 5
• In case of level 4 and level 4.1, the size of CPB shall be less than or equal to 30000 [1000bits].
• Minimum compression ratio (MinCR) (Note) for Main profile and the equivalent constraint for High
profile shall be restricted as follows;
�� For Main profile level 4.1, MinCR=4 for movie stream, MinCR=2 for still picture
�� For High profile level 4.1, the same semantic constraint as described above shall be applied.
�� For other levels of High profile, the same semantic constraint on MinCR for Main profile shall
be applied.
(Note): The semantic constraint on MinCR for Main profile is described in Annex A of the ISO/IEC
14496-10[11].
• If level_idc in SPS indicates level 4.1, each picture shall be encoded as multi-slice picture with 4 or
more slices per picture. The number of macroblocks in any slice shall not exceed 1/2 of the total
number of macroblocks. The number of macroblock rows in every slice in the picture should be as
equal as possible for the current picture height and interlace coding mode.
�� In case of 1920x1080 video format with frame_mbs_only_flag=1, it is recommended that
each slice has 17 macroblock rows (17/17/17/17 configuration).
�� In case of 1920x1080 video format with frame_mbs_only_flag=0 and
mb_adaptive_frame_field_flag=0, it is recommended that in each field, odd numbered slices
have 8 macroblock rows each and even numbered slices have 9 macroblock rows each
(8/9/8/9 configuration) or some similar configuration.
�� In case of 1920x1080 video format with frame_mbs_only_flag=0 and
mb_adaptive_frame_field_flag=1, it is recommended that odd numbered slices have 16
macroblock rows each and even numbered slices have 18 macroblock rows each
(16/18/16/18 configuration) or some similar configuration.
�� In case of 1280x720 video format, it is recommended that four slices have 11/11/11/12 or
some similar configuration.

[kieranrk]

As shon3i says, our experience of BDQuest is that it's rubbish.

[mp3dom]

Kieranrk, I agree with you regarding the errors that I've reported above. My only worry regards the MinCR error that BDQuest show only on the x264 encodes (like I said previously, this error doesn't come up with encodes made by CineVision, Blu-Code and CC-HDe) so it seems a bit 'strange'. For example BDQuest show some errors that are common for x264 encodes but also for CineVision/BluCode/CC-HDe, and those errors doesn't worry me at all. If the patch will be committed (as I really wish), the BD-compliance need to be 'sure'.

I'm really thankful to your work and I really don't want to seems surly or ungrateful in any way.

[MadMonkey57]

My 2 cents: x264-rev1442 + x264_NAL-HRD.1.22.r1442.diff are working fine on my BD35 (EU version, latest firmware).

x264_NAL-HRD.1.30 also working fine.

[ts4053]

Can anyone guide me how to set nal-hrd=cbr with ffmpeg when using libx264?

[rack04]

x264_NAL-HRD.1.30 also working fine.

Same here.

[J_Darnley]

Can anyone guide me how to set nal-hrd=cbr with ffmpeg when using libx264?

Are you going to modify ffmpeg to add the option? Are you just going to hard code it in libavcodec/libx264.c? Regardless, you should read the patch. I looked at it for the first time and saw the new option, and the #defines of the values it accepts. You need to set i_nal_hrd in the x264_param_t structure to X264_NAL_HRD_CBR

[kieranrk]

Kieranrk, I agree with you regarding the errors that I've reported above. My only worry regards the MinCR error that BDQuest show only on the x264 encodes (like I said previously, this error doesn't come up with encodes made by CineVision, Blu-Code and CC-HDe) so it seems a bit 'strange'. For example BDQuest show some errors that are common for x264 encodes but also for CineVision/BluCode/CC-HDe, and those errors doesn't worry me at all. If the patch will be committed (as I really wish), the BD-compliance need to be 'sure'.


Dark Shikari has posted a fix. BDQuest shouldn't complain any more.

[mp3dom]

Really thanks! I'll try asap!

[komisar]

adaptation for r1460
x264_NAL-HRD.1.31.r1460.diff (http://komisar.gin.by/x.patch/last.used/x264_NAL-HRD.1.31.r1460.diff)

[mp3dom]

I've tested the patch with r1462+NAL 1.31 but the MinCR problem still persist. In about 7min. of video (1080p24), BDQuest throw about 42 errors of 'bytes in NAL' that exceed the standard of "983040". I don't know if it's "bitrate dependent" (actually I'm using an average bitrate of 30 Mbps). Thanks.

[Dark Shikari]

I've tested the patch with r1462+NAL 1.31 but the MinCR problem still persist. In about 7min. of video (1080p24), BDQuest throw about 42 errors of 'bytes in NAL' that exceed the standard of "983040". I don't know if it's "bitrate dependent" (actually I'm using an average bitrate of 30 Mbps). Thanks.Can you post a clip of the .h264 file containing at least one example of a frame that it complains about?

[mp3dom]

Sure, but you need to wait a little (saturday). Since the file is about 2 GiB (it's Elephants Dreams anyway), is there a free tool that allows to cut an AVC ES (between 2 IDR-frames I suppose)?. :thanks:

[nm]

Since the file is about 2 GiB (it's Elephants Dreams anyway), is there a free tool that allows to cut an AVC ES (between 2 IDR-frames I suppose)?

You could mux to a container and use appropriate tools. MKV can be split with mkvmerge/mmg, MP4 with MP4Box/Yamb and MPEG-TS with tsMuxeR.

[mp3dom]

Ok! Thanks. Saturday I'll upload the file (sorry but i'm not at work at the moment)

[shon3i]

Better to use DGSplit, coz muxing in container can discard aud's.

[jpsdr]

DGSplit is indeed the best choice to keep the bitstream absolutely untouched, but it may be hard to get a specific part of the file...
Nevertheless, if purpose is only to split the file, but you intend to upload the whole file, the best thing to do in that case is a splitted archive (multi rar for exemple).

[Dark Shikari]

If you posted the settings you used, I could test it myself now instead of waiting for Saturday. I have a rather fast connection and can probably acquire the raws for Elephant's Dream faster than I can encode them ;)

[Revgen]

I muxed a 1920x1080i TFF Interlaced video just fine with Scenarist using Rack04's 1462 build with the 1460 NRD-HRD patch. I don't have BDQuest, so I can't verify anything with that.

For some reason Neuron2's DGIndexNV says the stream is MBAFF. Does x264 support MBAFF now? I thought it only did PAFF.

[Boolsheet]

For some reason Neuron2's DGIndexNV says the stream is MBAFF. Does x264 support MBAFF now? I thought it only did PAFF.

There's some information about that in this thread (http://forum.doom9.org/showthread.php?t=144584). So it's MBAFF without the adaptive?

Also, from Dark Shikari's blog (Comment #12 (http://x264dev.multimedia.cx/?p=270#comment-2458)):Complete MBAFF support… I may put that on the plate for Summer of Code. Do note that there is at least $7500 at stake, potentially 2-3 times that, for anyone who can implement full MBAFF and get it committed.

[Dark Shikari]

x264 has always used non-adaptive MBAFF for interlacing.

[mp3dom]

If you posted the settings you used, I could test it myself now instead of waiting for Saturday. I have a rather fast connection and can probably acquire the raws for Elephant's Dream faster than I can encode them ;)

Sure, these are the settings extended:

--profile "high" --preset "veryslow" --slow-firstpass --keyint 24 --min-keyint 2 --bframes 3 --b-adapt 2 --b-pyramid strict
--ref 4 --deblock 0:0 --slices 4 --bitrate 30000 --vbv-maxrate 40000 --vbv-bufsize 30000 --qpmin 1 --qpmax 40 --aq-mode 1
--aq-strength 0.7 --partitions "all" --direct "auto" --weightp 2 --merange 32 --mvrange 511 --subme 9 --psy-rd 0.4
--trellis 2 --no-fast-pskip --no-dct-decimate --colorprim "bt709" --transfer "bt709" --colormatrix "bt709"
--nal-hrd "vbr" --pic-struct --sar 1:1 --fps 24 --level "4.1" --thread-input --aud

[Audionut]

At a quick glance, you can minimize that to,

--preset "veryslow" --keyint 24 --min-keyint 2 --bframes 3 --b-pyramid strict
--ref 4 --slices 4 --bitrate 30000 --vbv-maxrate 40000 --vbv-bufsize 30000 --qpmin 1 --qpmax 40
--aq-strength 0.7 --merange 32 --subme 9 --psy-rd 0.4
--no-fast-pskip --no-dct-decimate --colorprim "bt709" --transfer "bt709" --colormatrix "bt709"
--nal-hrd "vbr" --pic-struct --fps 24 --level "4.1" --aud

[Dark Shikari]

I encoded it myself with those settings (without NAL HRD) and the largest frame was 1,347,215 bytes. The maximum frame size dictated by MinCR is 1,966,080 bytes. No violation occurred.

[mp3dom]

Thanks Dark Shikari for testing it.
So it's a NAL patch problem or no problem at all? BDQuest put 983.040 as maximum bytes in NAL unit. In my encode BDQuest throw an error i.e. at frame 911 saying that I have 1.012.031 bytes in NAL unit which is more than 983.040 bytes.
If it's all ok, is there a reason why other encoder doesn't made errors in BDQuest?
Specifically BDQuest made errors at frames: 911/935/2103/2127/2151/2157/2199/2223 and others (if you want I can post the full list if needed)
Thanks again!

[Dark Shikari]

Thanks Dark Shikari for testing it.
So it's a NAL patch problem or no problem at all? BDQuest put 983.040 as maximum bytes in NAL unit. In my encode BDQuest throw an error i.e. at frame 911 saying that I have 1.012.031 bytes in NAL unit which is more than 983.040 bytes.It's wrong. MinCR is 2 for level 4.1, not 4. 983040 would be the max bytes in a NAL unit if MinCR was 4.

...

For Main Profile level 4.1, MinCR=4 for movie stream, MinCR=2 for still picture. For High Profile level 4.1, the same semantic constraint as described above shall be applied.

What the hell, Blu-ray spec? Telling us to override the H.264 spec's own level restrictions?

[mp3dom]

Sorry DS for asking but:
- Could the patch/x264 be modified to adhere to the BD spec?
- The MinCR limit could affect the overall quality/encode in any way? (I mean in a real life encoding). Would it mean that a single image cannot be more than 1 MiB in size?

Thank you!

[kieranrk]

Sorry DS for asking but:
- Could the patch/x264 be modified to adhere to the BD spec?
- The MinCR limit could affect the overall quality/encode in any way? (I mean in a real life encoding). Would it mean that a single image cannot be more than 1 MiB in size?

Thank you!

It's been changed in my tree. Shouldn't be much of a problem in the real-world.

[mp3dom]

Thanks!
I have a question regarding pulldown. I have a 23.976p file (it's an SD video) that I'm encoding with 3.2 profile. I've setup x264's fps parameter to 23.976 (24000/1001) and --pulldown "32" but the final file plays at 59.94 rather than 29.97. Have I made something wrong? Also does pulldown works also with --pic-struct enabled? (I'm asking this because neuron2 DGAVCPulldown tool seems to have some limitation with pic-struct flag)
Thanks!

[Selur]

@mp3dom: did some tests a few week ago and it seemed fine when I don't set the fps-parameter at all, so that might be worth a try. :)

[kieranrk]

Thanks!
I have a question regarding pulldown. I have a 23.976p file (it's an SD video) that I'm encoding with 3.2 profile. I've setup x264's fps parameter to 23.976 (24000/1001) and --pulldown "32" but the final file plays at 59.94 rather than 29.97. Have I made something wrong? Also does pulldown works also with --pic-struct enabled? (I'm asking this because neuron2 DGAVCPulldown tool seems to have some limitation with pic-struct flag)
Thanks!

What player does this? If you are playing the raw .264 stream virtually all the players will just assume that the video is cfr. Pulldown is a form of vfr, so it won't play well.

[mp3dom]

DgAVCDec (not the "NV" version since I don't have an nVidia GPU) says it's 59.94. Anyway I'm re-encode without specify the framerate (as Selur suggested). If it could help, the file is an AVI and I have forced the demuxer as "avs" (otherwise doesn't work). The AVI itself is in Ut Video Codec YV12 (fourcc: ULY0). I'll let you know something when encode will finish (quite soon).

Edit1: Without specify the framerate, the result is the same. I'm testing with direct avs input

[kieranrk]

Then it's a problem with DgAVCDec not supporting vfr.
Changing the input method will not change anything.

[mp3dom]

Infact nothing has changed. But even mediainfo says it's 59.94, and MUI Generator (the Scenarist tool to make .ves file for import in Scenarist BD) refuse the file saying: "ERROR: Invalid timing info. (DTS of 15th AU is not greater than DTS of previous AU)".
Uhmm.. now I'm trying pulldown without NAL-HRD

[kieranrk]

Again, mediainfo doesn't understand what vfr is and just blindly reads the time_scale in the SPS as the framerate.

However, if scenarist refuses to take the file that may be indicative of a problem. I'm speculating that it doesn't like the fact that we use double the timebase in order to make it possible to have valid PTSs for frames which have a length that is not a multiple of a frame since PTS in x264 is based on frames, not fields like in HRD.

[mp3dom]

In this weekend I can made every test you want, if it could be helpful.
If it could help, 24p+NAL+AUD (no pic-struct) into DGAVCPulldown works (mediainfo and DGAVCDec both recognize the file as 29.97 with repeated fields) anyway MUI Generator refuse immediately the file with a generic "ERROR!"
Same 24p file into h264Info (alpha .26) throw an error during the pulldown process and then the program crash.

[jpsdr]

Now that apparently the MinCR problem has been identified, i just wanted to know what is the actual status, and what will be the next step.

[J_Darnley]

Now that apparently the MinCR problem has been identified, i just wanted to know what is the actual status, and what will be the next step.

http://git.videolan.org/?p=x264.git;a=commit;h=a6c91c9f2af09d666755eef0ac2cc18228ce7a7c

[jpsdr]

No, this is related to post #110. Problem was still present, and identified AFTER this update, in post #128.

[kieranrk]

Basically if Level 4.1 is on and nal-hrd is on, a MinCR of 4 will be used irrespective.

[mp3dom]

Is the MinCR value the same (4) for level 3.x?
Also it seems that there are some problems with Panasonic BD that refuse or have problems to play BD with NAL-HRD.

[jpsdr]

Same question for level 4.0...

[J_Darnley]

Same question for level 4.0...

Level 4.0 already has MinCR = 4

[shon3i]

Here what Blu-Ray specs need:

• Minimum compression ratio (MinCR) (Note) for Main profile and the equivalent constraint for High
profile shall be restricted as follows;
-For Main profile level 4.1, MinCR=4 for movie stream, MinCR=2 for still picture
-For High profile level 4.1, the same semantic constraint as described above shall be applied.
-For other levels of High profile, the same semantic constraint on MinCR for Main profile shall
be applied.
(Note): The semantic constraint on MinCR for Main profile is described in Annex A of the ISO/IEC
14496-10[11].

Which mean MinCR should be always 4 for movie stream

[jpsdr]

Euh... Doest it mean in fact that in the actual situation, for level 4.0, everything is fine, and video stream is 100% blu-ray compliant ???
And problem is only for level 4.1...?

[Atak_Snajpera]

Euh... Doest it mean in fact that in the actual situation, for level 4.0, everything is fine, and video stream is 100% blu-ray compliant ???
And problem is only for level 4.1...?
I was also wondering if this patch is ok for AVCHD (level 4.0)

[Dark Shikari]

Wait until it's committed; it's almost done.

I just finished writing VFR 1-pass and 2-pass bitrate modes.

[kieranrk]

1.32 should be the last patch.

[Dark Shikari]

Here's the full details on the hopefully-final NAL-HRD patch from the commit message. Do note that it includes much much much more than just NAL-HRD, including many features useful for ordinary encoding (such as VFR ratecontrol).

Blu-ray support: NAL-HRD, VFR ratecontrol, filler, pulldown
x264 can now generate Blu-ray-compliant streams for authoring Blu-ray Discs!

An example command, using constant quality mode, for 1080p24 content:
x264 --crf 16 --preset veryslow --tune film --weightp 0 --bframes 3 --nal-hrd vbr --vbv-maxrate 40000 --vbv-bufsize 30000 --level 4.1 --keyint 24 --b-pyramid strict --slices 4 --aud --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --sar 1:1 <input> -o <output>

This command is much more complicated than usual due to the very complicated restrictions the Blu-ray spec has.
Most options after "tune" are required by the spec.
--weightp 0 is not, but there are known bugged Blu-ray player chipsets (Mediatek, notably) that will decode such video incorrectly.
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.

Detailed features introduced in this patch:

Full NAL-HRD compliance, with both VBR (no filler) and CBR (filler) modes.
Can be enabled with --nal-hrd vbr/cbr.
libx264 now returns HRD timing information to the caller in the form of an x264_hrd_t.
x264cli doesn't currently use it, but this information is critical for compliant TS muxing.

Full VFR ratecontrol support: VBV, 1-pass ABR, and 2-pass modes.
This means that, even without knowing the average framerate, x264 can get achieve a correct bitrate in target bitrate modes.

Pulldown support: libx264 allows the calling application to specify a pulldown mode for each frame.
This is similar to the way that RFFs (Repeat Field Flags) work in MPEG-2.
Note that libx264 does not modify timestamps: it assumes the calling application has set timestamps correctly for pulldown!
x264cli contains an example implementation of caller-side pulldown code.

Pic_struct support: necessary for pulldown and allows interlaced signalling.
Also signal TFF vs BFF with delta_poc_bottom: should significantly improve interlaced compression.
--tff and --bff should be preferred to the old --interlaced in order to tell x264 what field order to use.

Huge thanks to Alex Giladi and Lamont Alston for their work on code that eventually became part of this patch.

[mp3dom]

Wow, thanks! I have some questions:
- Is the problem regarding Panasonic BD (that don't play or play with problems a stream with NAL-HRD patch) supposed to be fixed? (I don't have a Panasonic BD nor know its chipset so I'm asking only to know.)
- The 'incorrectly decode' of weightp for MediaTek chipset means play with macroblock (like the weightp 2 problem with some software AVC decoder?) Is the quality loss (from weightp from 2 to 0) noticeably in a 'bluray bitrates' (quite high) even on fades?
- Is 3:2 pulldown supposed to works in a 'BD-spec' way? I have made some test with 1.31 patch and wasn't able to import the stream in Scenarist BD (encoded as 23.976+nal+aud+pic-struct+pulldown 3:2)
Thank you very much!

[rack04]

- Is the problem regarding Panasonic BD (that don't play or play with problems a stream with NAL-HRD patch) supposed to be fixed? (I don't have a Panasonic BD nor know its chipset so I'm asking only to know.)

I have a Panasonic BD35 and haven't experienced any problems in the last several revisions.

[mp3dom]

The supposed problem is located in the BD Rebuilder thread (if I remember correctly the player was a Panasonic BD30)

[shon3i]

Wow, many thanks.

First, buld on first page, is something wrong, i don't saw hrd or pulldown switches.
Second, about VFR ratecontrol? How to use it? and is Blu-Ray compatible?

EDIT: i just download Rack04 build and seem that have all switches :)

[Dark Shikari]

Wow, many thanks.

First, buld on first page, is something wrong, i don't saw hrd or pulldown switches.
Second, about VFR ratecontrol? How to use it?

oldx264 some_vfr_anime.mkv -o output.mkv --bitrate 1000

Result: 300kbps (what?!)

newx264 some_vfr_anime.mkv -o output.mkv --bitrate 1000

Result: 1000kbps (yay!)

[shon3i]

oldx264 some_vfr_anime.mkv -o output.mkv --bitrate 1000

Result: 300kbps (what?!)

newx264 some_vfr_anime.mkv -o output.mkv --bitrate 1000

Result: 1000kbps (yay!)
Amazing :) I can't beleve ;)

I need to test ASAP :)

[rack04]

Here (http://www.multiupload.com/W6I41HO6UE) is a file that I just encoded. Can anyone with access to a verifier verify this stream? Thanks.

[mp3dom]

I'm already testing on my own (for reference... a 3.2 HL + 3:2 soft pulldown and a 1080p24 4.1 HL)

Edit1: L3.2 High + 3:2 soft pulldown (SD) doesn't work. It is refused by MUI Generator (same error as previous 1.31 patch). It's not an issue but the file still is recognized as 59.94 fps while CineVision/Blu-Code encodes are recognized at 29.97.

Edit2: L4.1 High HD 24p pass both mux and verification successfully! (tested on a clip with about 15.700 frames) :)

[creamyhorror]

Congratulations devs and testing team! It might almost be time to call Lyris (http://forum.doom9.org/showthread.php?t=148826) back.

[Lyris]

I have been reading the whole time. I am lost for words :) Thank you!

[shon3i]

Edit1: L3.2 High + 3:2 soft pulldown (SD) doesn't work. It is refused by MUI Generator (same error as previous 1.31 patch). It's not an issue but the file still is recognized as 59.94 fps while CineVision/Blu-Code encodes are recognized at 29.97.I have same issue, i even try with DGPulldown, which produce 29.97 stream, but MUI Generator refuse stream completly.

Edit2: L4.1 High HD 24p pass both mux and verification successfully! (tested on a clip with about 15.700 frames) Confirmed, same here :)

[Revgen]

Wow, thanks! I have some questions:
- Is the problem regarding Panasonic BD (that don't play or play with problems a stream with NAL-HRD patch) supposed to be fixed? (I don't have a Panasonic BD nor know its chipset so I'm asking only to know.)
- The 'incorrectly decode' of weightp for MediaTek chipset means play with macroblock (like the weightp 2 problem with some software AVC decoder?) Is the quality loss (from weightp from 2 to 0) noticeably in a 'bluray bitrates' (quite high) even on fades?
- Is 3:2 pulldown supposed to works in a 'BD-spec' way? I have made some test with 1.31 patch and wasn't able to import the stream in Scenarist BD (encoded as 23.976+nal+aud+pic-struct+pulldown 3:2)
Thank you very much!

From the BDRebuilder Bug Thread.

Try adding MIN_M2TS_SIZE=700 to the BDREBUILDER .ini file. You can copy and past it from the HIDDENOPTS.TXT file. This should keep the menus from being re-encoded (I think this command means do not re-encode anything under 700 Mb). If you still have the problem try a larger number. I use this command this for all concert blu-rays because for some reason thier menus refuse to work after being re-encoded.Hey Willobee,

I have been trying for weeks to get Groundhog Day Region A to work in my Panasonic BD-35. I ripped and transcoded as BD25 full disk and the studio logo would play but would go no further. It would not play the Blu-ray ad video or the menus.

I tried your trick above and lo and behold, my Panasonic will now play the BD25 complete with menus. All other movies that I have tried (except for Drag Me To Hell) worked so I could not figure out why Groundhog Day would not. Now I am going to try Drag Me To Hell with the same setting and see what happens.

So the Panasonic BD-35 is very picky about what get transcoded.

Thank you for your tip. I am very please that it worked.

Jdobbs, thanks again for the great program and all the hard work you are putting into it. A donation will definitely be coming your way.

From what I understand, Menus use a different MiniCR than the movie does. That may be causing the problem.

[kieranrk]

I have same issue, i even try with DGPulldown, which produce 29.97 stream, but MUI Generator refuse stream completly.


Therefore I have to conclude that it has no idea what it wants...
One way to try and tackle this is to make x264 timebase work in fields which is something I'm reluctant to do.

It's not that major for Blu-ray anyways since x264.c can't do mixed pulldown and your source framerate must be supported anyway.

[mp3dom]

I doubt that MinCR for menu is different simply because menu are plain video with an IG in subpath (or muxed together). When you encode there's no way to tell that you're making a movie or a menu. It could be different if you're making still for menu (in that case if I remember correctly, the MinCR is 2). Reading the response from the thread bug, the workaround in that particular case is simply to avoid recompression so it's working because BDRebuilder is using the original menu.
Can someone with a BD30/BD35 confirm if the 1.32 NAL patch is safe even for that picky SAP?

[Lyris]

Sorry if this derails the thread slightly, but I just thought I would post this as a reminder of your hard work is going to be such a boost to high quality video.

This is a frame grab from a Scandinavian Blu-ray Disc. The film source is 16mm, so there is quite a lot of high frequency grain. The bit-rate during this scene is about 34-35mbps (seriously). This is the sort of encoders small distributors are currently resorting to to pass verification:

http://www.lyris-lite.net/2010/girl_hornet.png (~3mb PNG)

[kolak]

Sorry if this derails the thread slightly, but I just thought I would post this as a reminder of your hard work is going to be such a boost to high quality video.

This is a frame grab from a Scandinavian Blu-ray Disc. The film source is 16mm, so there is quite a lot of high frequency grain. The bit-rate during this scene is about 34-35mbps (seriously). This is the sort of encoders small distributors are currently resorting to to pass verification:

http://www.lyris-lite.net/2010/girl_hornet.png (~3mb PNG)

It looks similar to one of the Pro encoders problem :)

[Blue_MiSfit]

_O_M_G_

MPEG-2 would be better. FAIL.

Why they would do this crap instead of lowpassing it is utterly beyond me...

~MiSfit

[mp3dom]

It's anyway a bit difficult to say if that frame is the result of a bad encoder or bad setting. I've made in the past some encode of grainy sources with CineVision and honestly the results were not that bad, maybe your source is very hard for an encoder :)

[Lyris]

I tend to find that many of the bad encoders tend not to let you tweak much, so it's maybe a bit of both?

[kolak]

It's anyway a bit difficult to say if that frame is the result of a bad encoder or bad setting. I've made in the past some encode of grainy sources with CineVision and honestly the results were not that bad, maybe your source is very hard for an encoder :)

Yes, it's not to bad, but with some sources it has strange problems and sometimes there is no way to avoid them whatever setting you use.

[kolak]

I tend to find that many of the bad encoders tend not to let you tweak much, so it's maybe a bit of both?

Blu-code doesn't let you tweak to much, but it's actually very good encoder.

Back to BD patch- there is still work which needs to be done- it's not 100% compatible yet, but very promising.

[Dark Shikari]

Blu-code doesn't let you tweak to much, but it's actually very good encoder.

Back to BD patch- there is still work which needs to be done- it's not 100% compatible yet, but very promising.If it's not 100% compatible, tell us what isn't.

[kolak]

If it's not 100% compatible, tell us what isn't.

Just few posts above people say Scenarist doesn't even import some files.

1080 24p seams to working (confirmed by more than one user).

I can't tell what is not working- I don't have enough knowledge :), but what about different BD frame rates and frame sizes?

If we have all of them verified by more than one person than it's very close to the end :)

Dark Shikari, you have done some projects for the companies and I assume you know what do they want?

Yes- black box which just simply works :)

[Moviewatcher666]

From the BDRebuilder Bug Thread.



From what I understand, Menus use a different MiniCR than the movie does. That may be causing the problem.

Hi Revgen,

Thanks for the comment. I didn't know what MinCR was so I did a search on the net and it brought me here.

I thought the problem was solved until I tested my BD25 of Groundhog Day a little more.

What works:
The menu, playing movie from the menu, selecting audio and subtitle options from the menu, scene selection from the menu and only some special features from the menu (deleted scenes, previews).

What doesn't work:
3 of the special feature videos selected from the special features menu. The video freezes and I have to stop or eject.

I used PROCESS_SECONDARY=0 (audio is DTS Express and doesn't work anyway) & MIN_M2TS_SIZE=700 BD Rebuilder .32.05.

Any other suggestion to try to have it work 100%? Appreciate any suggestions

Thanks for reading!

[Revgen]

^I'll post my reply in the BD Rebuilder Bug thread.

[shon3i]

Just few posts above people say Scenarist doesn't even import some files.That is because pulldown is used. Pulldown have nothing with Blu-Ray compilancy, and x264 now produce 100% compilant streams, none of allowed combinations for Blu-Ray not require pulldown and pulldown is not mandatory at all.

If we have all of them verified by more than one person than it's very close to the endMore than one person lol, how many peoples allredy use BD-Rebulder and multiAVCHD, which use earlier versions that passes verificators and plays on every SAP, this is just the icing on the cake :)

[Atak_Snajpera]

1280x720p @ 23.976/24/25/50/60 is also ok?

[shon3i]

I checked 23.976 and 24, work fine, i don't have 50 or 60 material to test, 25p/i is not allowed for 720.

[jpsdr]

You take your file, just change the frame rate (not convert) , and encode it.
Ok, it will be ...slighty... speed-up, but it's not important in that case, if it's just to check.

[Sharc]

I get the warning "b-pyramid + mbtree is not supported".
Is this a limitation of the encoder or of the Blu-Ray spec?

[Dark Shikari]

I get the warning "b-pyramid + mbtree is not supported".
Is this a limitation of the encoder or of the Blu-Ray spec?This means your x264 is way too old.

[Sharc]

Yes, you are right, it's x264 core 79 r0+1360 528c100 from the first post in this thread. From where can I download the latest version?

[mp3dom]

Use this link (http://forum.doom9.org/showthread.php?p=1379904#post1379904) (choose the version suits better for you)

[MadMonkey57]

...Can someone with a BD30/BD35 confirm if the 1.32 NAL patch is safe even for that picky SAP?

Been watching for 10mn on my BD35... so far so good...

[Sharc]

@mp3dom
Thank you.

[kieranrk]

Yes, you are right, it's x264 core 79 r0+1360 528c100 from the first post in this thread. From where can I download the latest version?

Not sure why that happened. Fixed now.

[mp3dom]

Been watching for 10mn on my BD35... so far so good...
Very good!:)

[mp3dom]

1280x720p @ 23.976/24/25/50/60 is also ok?
If i have some time this weekend I'll try to make some test on all kind of progressive sources allowed by Bluray specs (1920x1080p23.976/24, 1440x1080p23.976/24, 1280x720p23.976/24/50/60). Probably it could be useful to test 576p25 and 480p29.97 too as these format are allowed for secondary video.

[Dark Shikari]

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.

We really would like to avoid Elephant's Dream or Big Buck Bunny if possible due to horrific overuse.

Eyes on the Skies (http://www.eyesontheskies.org/movie.php") was a potential option, but after contacting them, it turns out they only have an MPEG-2 Intra 50mbps source, and nothing better; hardly suitable for authoring a Blu-ray.

What other options do people know of for a free film or short in top-quality HD?

[pokazene_maslo]

What other options do people know of for a free film or short in top-quality HD?Maybe Home (http://en.wikipedia.org/wiki/Home_%282009_film%29)

[Boolsheet]

Perhaps benwaggoner's "Lady Washington"? ;)

(Download links/torrents are outdated and down)
http://forum.doom9.org/showthread.php?t=137671
http://forum.doom9.org/showthread.php?t=135938

[Dark Shikari]

Perhaps benwaggoner's "Lady Washington"? ;)

(Download links/torrents are outdated and down)
http://forum.doom9.org/showthread.php?t=137671
http://forum.doom9.org/showthread.php?t=135938I'd prefer an actual film...Maybe Home (http://en.wikipedia.org/wiki/Home_%282009_film%29)Will look into it.

[LoRd_MuldeR]

Well, it's not an "actual film" but concert footage. It may be an option anyway:
Nine Inch Nails offers 405GB of free HD concert footage, fans make free Blu-ray, DVD (http://forum.nin.com/bb/read.php?52,378166)

[Lyris]

There's also various .R3D clips (output of the RED ONE camera) available on RedRelay.net (although the site was down for maintenance last time I checked). I've been using those with added synthetic grain for AVC encoder tests. You would never guess which of the encoders kept winning ;)

What about the trailer for "The Island" that BenWaggoner shared with us? The source isn't perfect and has banding during fades, but it provides clips of a real film, with a lot of detail.

I also have some raw 1920x1080 4:2:2 clips, sourced from film, of various shots: sunflowers, a field, traffic at rush hour, that I can somehow share with people because I forgot where I originally downloaded them from (maybe someone else knows).

[kieranrk]

I also have some raw 1920x1080 4:2:2 clips, sourced from film, of various shots: sunflowers, a field, traffic at rush hour, that I can somehow share with people because I forgot where I originally downloaded them from (maybe someone else knows).

The idea is that it's a proper film.

[Lyris]

"The Island" trailer is the only choice I can think of, then...

[Biggiesized]

You could also use the Match Point trailer. There is less banding but thicker grain and not as much high frequency detail.

[mp3dom]

I'll investigate tonight, but I had a buffer underflow in Scenarist today in a clip of 3 mins (it stops after 6 seconds of mux) with an avg bitrate of 25 Mbps (which is quite 'standard') and only one audio (DD at 640Kbps). It could be the vbv-bufsize set to 30.000 so tonight I'll try with a more conservative value.

[Sharc]

I made some 720p encodes with rack04's build and DS' Blu-ray settings (--preset medium). Worked flawlessly. I noticed improved back and forward seeking, with no audio/video sync issues as before. Is this thanks to the nal-hrd patch?

[shon3i]

I'll investigate tonight, but I had a buffer underflow in Scenarist today in a clip of 3 mins (it stops after 6 seconds of mux) with an avg bitrate of 25 Mbps (which is quite 'standard') and only one audio (DD at 640Kbps). It could be the vbv-bufsize set to 30.000 so tonight I'll try with a more conservative value.
What exact settings you use for buffer and max rate? I discovered in past (on earlier HRD patches aslo) that if use buffer different that max rate, scenarist discover potential buffer uder/overflow and stop muxing. I found if i set VBV 30000/30000 or 15000/15000 or anything same for buffer and maxrate scenarist mux flawlessy. IIRC CBP removal delay should be always 0.9, i don't know is that same as x264 VBV-Int option, which i try to adjust, to achieve that delay, but without success, i even get VBV errors durring encode :). I read somewhere in scenarist documentation that delay should be always near 0.9. Other encoders (Cinevision, MC, Elecard) keep that on 0.7-1.0 nevemind i set for buffer/maxrate, while with x264 can be anything, for example if i set 30000/40000 it will be around 0.5-0.6, if buffer is higer will be over 1.0 and around 1.80

[mp3dom]

I have used 30.000 for vbv-bufsize and 40.000 for vbv-maxrate which, if I'm not mistaken, are also the standard values. I haven't tried the CBP delay, nice suggestion, I'm trying it!

[kieranrk]

Can you upload the encoded clip somewhere (or send it to me privately) so I can see if it's a real buffer underflow or Scenarist being wrong.

[mp3dom]

You have a PM. :)

[shon3i]

I have used 30.000 for vbv-bufsize and 40.000 for vbv-maxrate which, if I'm not mistaken, are also the standard values.Exactly, but removal delay will be 0.6 in that case which is maybe not recommended.

Can you upload the encoded clip somewhere (or send it to me privately) so I can see if it's a real buffer underflow or Scenarist being wrong. You not find any underflows in stream itself, its problem in VBV delay that must be some constant value. I will post some examples, of different encoders

[mp3dom]

Anyway it's kinda strange that I've encoded full Elephants Dream with even higher settings (same vbv_bufsize/vbv_maxrate but avg bitrate raised from 25Mbps to 30Mbps) without any problem (and it's a 10min clip where the clip that fail to mux is only 3 minutes and scenarist fail after 2 seconds!)

[shon3i]

Anyway it's kinda strange that I've encoded full Elephants Dream with even higher settings (same vbv_bufsize/vbv_maxrate but avg bitrate raised from 25Mbps to 30Mbps) without any problem (and it's a 10min clip where the clip that fail to mux is only 3 minutes and scenarist fail after 2 seconds!)
What exactly settings? you use?

[mp3dom]

keyint at 24, min keyint at 2, bpyramid, 4 reference, 3 bframes, 4 slices, 30 mbps of bitrate, aq 1, all partitions, weight prediction at 2 and so trellis

[shon3i]

I mean VBV :)

[mp3dom]

Ah, sorry ^^; I'm using always 40K and 30K for maxrate and buffersize respectively.

[shon3i]

Ah, sorry ^^; I'm using always 40K and 30K for maxrate and buffersize respectively.
Can you try with 30K for both max rate and buffer, you will not loose any quality anyway. Just for test. Because CBP removal will be then 0.9

[mp3dom]

Tested with both vbv values at 30K and Scenarist always throws a buffer underflow... :(

[kieranrk]

Well the file you sent me is valid. The H.264 spec only specifies a cap for the initial_cbp_removal_delay in VBR mode.

[mp3dom]

So is Scenarist wrong or there's really a underflow? It complains at about 2 secs.

[kieranrk]

So is Scenarist wrong or there's really a underflow? It complains at about 2 secs.

There's definitely no underflow.

[mp3dom]

From a certain point of view I'm glad, from the other I'm a bit sad because I can't find a way to let Scenarist accept that footage encoded with x264. Anyway, thank you very much for the patience

[shon3i]

mp3dom can you send me source and encoded clip, for testing on PM?

[mp3dom]

The original clip is too huge for my adsl line (we are speaking of 2.7GiB of a YV12 video already compressed in lossless way, also is a working project so I can not redistribute it). I can send the portion that I've already sent to kieranrk and it's about 5 sec of video but I doubt that it's possible to reproduce the underflow (or the problem) with few seconds...

[shon3i]

Ok, can send then 5 sec of source and encoded video which fail to mux?

[shon3i]

Btw i found rule about VBV Buffer in Cinevision manual.

Bitrate buffer specifies the size of the virtual buffer verifier in bytes or bits. This value
should be adjusted to bitrate (Constant Bitrate) or to maximum bitrate (Variable Bitrate), to
avoid DTS/PTS underflows during muxing.

So if stream itself not contain any underflow, scenarist can detect possible underflow that not exist, but can result incorrect playback on SAP.

[renqian]

can't download the Binary .anyone can help me? :)

[mp3dom]

So if stream itself not contain any underflow, scenarist can detect possible underflow that not exist, but can result incorrect playback on SAP.

Ok but it seems there's no a simple way to avoid this because even with 30.000 for both bufsize and maxrate Scenarist gave me a buffer underflow... :confused:

[jpsdr]

Btw i found rule about VBV Buffer in Cinevision manual.

Bitrate buffer specifies the size of the virtual buffer verifier in bytes or bits. This value
should be adjusted to bitrate (Constant Bitrate) or to maximum bitrate (Variable Bitrate), to
avoid DTS/PTS underflows during muxing.



Does it mean that there is something to update/fix in the patch or in x264 ?

[shon3i]

Ok but it seems there's no a simple way to avoid this because even with 30.000 for both bufsize and maxrate Scenarist gave me a buffer underflow... :confused:
I don't know what you do but with your sample i sucessfuliy mux.

Here is mine cmd i used during encoding

x264.exe --preset slow --tune film --pass 2 --bitrate 30000 --level 4.1 --ref 4 --keyint 24 --min-ke
yint 2 --vbv-maxrate 30000 --vbv-bufsize 30000 --slices 4 --aud
--nal-hrd vbr --sar 1:1 --no-fast-pskip --no-dct-decimate --pic-struct --colorpr
im "bt709" --transfer "bt709" --colormatrix "bt709" --b-pyramid strict -o "AoD-Ut.264" "AoD-Ut.avi"

Does it mean that there is something to update/fix in the patch or in x264 ? No this is mean to keep possible near VBV-Bufsize and VBV-Maxrate to target bitrate. There is no reason to set VBV to 30/40 which is max for BD standard if your target bitrate is 10mbps for example. You can safetly use lower VBV valuses such 15/15

[mp3dom]

The only difference between my CMD and yours is that I've used an average bitrate of 25 Mbps rather than 30. I think the main difference is that you have an avg bitrate of 30 in a static 5sec clip which is somewhat too short for reproduce the problem (i think). I've the 3 min. clip and probably in the same static scene the avg bitrate is lower causing the underflow. It's not your fault, since I can't upload the full clip at all... :(

[jpsdr]

Is the --pic-struct also necessary for BR ?

[shon3i]

The only difference between my CMD and yours is that I've used an average bitrate of 25 Mbps rather than 30. I think the main difference is that you have an avg bitrate of 30 in a static 5sec clip which is somewhat too short for reproduce the problem (i think). I've the 3 min. clip and probably in the same static scene the avg bitrate is lower causing the underflow. It's not your fault, since I can't upload the full clip at all...

Ok i will now test with 25mbps maybe i have luck to reproduce problem :) That's why i told you to keep VBV's near to bitrate. Maybe you can try with VBV 25/25.

Is the --pic-struct also necessary for BR ? Only when interlaced/pulldown used, but some verifiers aslo notice that pic-struct should be used always. Anyway nobody have problem. Current HDR patch use when need.

[mp3dom]

Tried to encode the same file with same parameters (for buffer and maxrate) with CineVision and it mux without problems :confused:

[shon3i]

Tried to encode the same file with same parameters (for buffer and maxrate) with CineVision and it mux without problems :confused:
Well you can't watch like this, because encoders have completly different ratecontrols and decisions. If you look HRD model via some buffer analyser you see that graph is totaly different. Anyway i have same problem with some retail discs in past, few of these have realy unusual VBV (29/38) and very distant from target bitrate.

[mp3dom]

Yeah, I know. Anyway it doesn't work even with 25/25/25 (bitrate/maxrate/bufsize). I think I'll encode this video with something else... Good it's 3 min long but think what happends if it appear after a full film (I try to imagine after 5 days of encode, Scenarist refuse to mux)

Edit: With your exact settings it pass that point and continue to mux, however it fails 10 seconds after.

[shon3i]

Yeah, I know. Anyway it doesn't work even with 25/25/25 (bitrate/maxrate/bufsize). I think I'll encode this video with something else... Good it's 3 min long but think what happends if it appear after a full film (I try to imagine after 5 days of encode, Scenarist refuse to mux)

Edit: With your exact settings it pass that point and continue to mux, however it fails 10 seconds after.
Can you try with higher buffer than max-rate for example 25/25/30 (bitrate/maxrate/bufsize) or add to x264 cmd --vbv-int 0.4 to raise buffer/maxrate ratio

[mp3dom]

Tried both and nothing new (buffer underflow)

Edit: It could be that I've resolved. I'm testing a bit more...

Edit2: Resolved! Lowering the qcomp parameter does the trick for me.

[shon3i]

Tried both and nothing new (buffer underflow)

Edit: It could be that I've resolved. I'm testing a bit more...

Edit2: Resolved! Lowering the qcomp parameter does the trick for me.
haha i just want to suggest you that, or something that will change ratecontrol decisions :)

Btw how much you lower it? 0.5?

[Dark Shikari]

haha i just want to suggest you that, or something that will change ratecontrol decisions :)It's generally highly inadvisable to lower qcomp. If it "fixes" a problem, it's by luck, not something you should touch.

[mp3dom]

I've set to 0.5. Anyway as Dark Shikari said, probably it's a rare clip where the underflow occours. I've encoded some other clips without any underflow issue so better to leave qcomp as its default.

[shon3i]

I agree absolutely, but sometimes need to tweak it a little. Anyway That why MC/Cinevision have more two options for VBV/HRD which serve to prevent such possible events (VBV/HRD buffer fullness).

Btw when i already mention Mainconcept encoder, in his option there is several ability to write HRD info: Type 1, Type 2, Type 1+SEI and Type 2 without SEI. Aslo some other options are NAL, VCL, Both NAL and VCL is that can be usefull anyway. I know that Blu-Ray need Type 2.

[jpsdr]

Can this story of 'type 2' explain the problem mp3dom is having with his little clip ?
In that case, does it mean an update of the patch may be needed ?

[kieranrk]

Can this story of 'type 2' explain the problem mp3dom is having with his little clip ?
In that case, does it mean an update of the patch may be needed ?

There is no problem with the clip as far as I can see. I tried it on a copy of Muigenerator and it said that only 3 slices instead of 4 were present. Therefore I have to conclude that muigenerator is broken.

[shon3i]

There is no problem with the clip as far as I can see. I tried it on a copy of Muigenerator and it said that only 3 slices instead of 4 were present. Therefore I have to conclude that muigenerator is broken.
Yes it's realy wierd, but maybe something broken during cut, because i never had problem with slices and muigenerator, only with mp3dom sample.

Anyway, i just playing with Buffer Analyzer which scans whole BD structure (BD Quest Buffer Analyzer), and show three types of buffers, first of raw stream (like elecard), second of stream during mux (if muxer cause), and third of muxed inside transport stream. So as i already say, if stream itself is prefectly clean and without underflows, that not mean, will stay after muxing with other streams. Maybe is need to have some option like HRD buffer fullness to control that.

[kieranrk]

So as i already say, if stream itself is prefectly clean and without underflows, that not mean, will stay after muxing with other streams. Maybe is need to have some option like HRD buffer fullness to control that.

The muxer should handle all of these issues.

[shon3i]

Yes it should, for instance Scenarist automatically stop mux. But what is happend if we that stream mux with TsMuxer? Here i used mp3dom problematic sample, and muxed it with TsMuxer. Here is graph analysis.

http://img138.imageshack.us/img138/557/bufff.th.jpg (http://img138.imageshack.us/my.php?image=bufff.jpg)

Clearly visible that buffer after muxing (video only) goes over all restrictions.

Aslo Neuron's VBVChecker 1.7 with strict checking aslo found underflow with this file.

[mp3dom]

The problem of 3 slices comes up with the 'cut' made. I've encoded it with 4 slices and the full avc stream doesn't show any warning in MUI Generator. Probably the 'cut' has changed something in the header. Apart that clip, all the other clips that I've made are OK and muxed perfectly. Also BDQuest doens't show any warning regarding bitrate allocation (always pass). To me this patch is really fine (the only thing left is the pulldown that it could be really nice for standard definition as primary video, since it would be possible to encode a 480p24 stream and pulldown to 60i to adhere the BD specs)

[Guest]

Aslo Neuron's VBVChecker 1.7 with strict checking aslo found underflow with this file. It's not appropriate to use strict checking unless the encoder implements stuffing.

[kieranrk]

The transport buffer overflows, and note the BDAV-STD (System Target Decoder) at the top; therefore it's a transport issue.

On another note; what software produces that?

[Guest]

the only thing left is the pulldown DGAVCPulldown can apply pulldown.

[kieranrk]

(it would be possible to encode a 480p24 stream and pulldown to 60i to adhere the BD specs)

You're not allowed to do that. The framerate prior to pulldown must be valid.

DGAVCPulldown can apply pulldown.

As far as I know it doesn't correct HRD to match the new frame durations...(and apply appropriate hacks because HRD was not designed with pulldown in mind)

[mp3dom]

DGAVCPulldown can apply pulldown.
Yes, I know and I've tried it but the stream is refused by MUI generator

You're not allowed to do that. The framerate prior to pulldown must be valid.
Uhmm, are you sure? I've made an SD video (the source is 720x480, 23.976p) with CineVision. During importing it says (correctly) 23.98p. I've set the encoder as 'Primary Video', 720x480 and the encoder shows a 23.98->29.98 (pulldown) as final target. The final AVC file is detected as 29.98 fps and DGAVCDec show the incremental counter of 'repeated field flag'. This file is accepted and muxed by Scenarist (it's anyway detected as 29.98)

[kieranrk]

Uhmm, are you sure? I've made an SD video (the source is 720x480, 23.976p) with CineVision. During importing it says (correctly) 23.98p. I've set the encoder as 'Primary Video', 720x480 and the encoder shows a 23.98->29.98 (pulldown) as final target. The final AVC file is detected as 29.98 fps and DGAVCDec show the incremental counter of 'repeated field flag'. This file is accepted and muxed by Scenarist (it's anyway detected as 29.98)

The spec specifically says in "Table 9-29 – Allowed combinations of parameters for 525/60 video format" frame_mbs_only_flag must be zero. (i.e. must be interlaced)

[mp3dom]

Infact it is detected as 'frame' structure by DGAVCdec even if it has field pulldown (Scenarist, If I remember correctly, detect the file as interlaced). I think that some other parameters will tell that it's a soft pulldown or something similar (maybe pic-struct?)

Edit: Here is what DGAVCDec detect:
http://xs.to/thumb-F663_4B992852.jpg (http://xs.to/share-F663_4B992852.html)

And here is what Scenarist detect:
http://xs.to/thumb-BE4F_4B992852.jpg (http://xs.to/share-BE4F_4B992852.html)

[kieranrk]

Scenarist is wrong, DGAVCDec is right.

[shon3i]

The transport buffer overflows, and note the BDAV-STD (System Target Decoder) at the top; therefore it's a transport issue.

On another note; what software produces that?
With tsmuxer as i said, which not make aditional checking during mux for possible undeflows. But sonic scenarist will probably make same, but they are have checker, which automaticlly stop muxing and prevent this as in mp3dom case, and report underflow. Adjusting qpcomp in x264 solove mp3dom problem, this change HRD model which passes muxing.

Also BDQuest doens't show any warning regarding bitrate allocation (always pass)Bitrate!=Buffer Analysis.

[mp3dom]

Bitrate!=Buffer Analysis.
Yeah! You're right, my mistake!

[kieranrk]

With tsmuxer as i said, which not make aditional checking during mux for possible undeflows. But sonic scenarist will probably make same, but they are have checker, which automaticlly stop muxing and prevent this as in mp3dom case, and report underflow. Adjusting qpcomp in x264 solove mp3dom problem, this change HRD model which passes muxing.

Bitrate!=Buffer Analysis.

I mean which program created the graphic.

You haven't grasped what I've said. In that picture the buffer analysis is of the Transport stream buffers (which are part of the STD). It is not the fault of x264 when STD buffers overflow. (There's one exception but that's not allowed in Blu-Ray) The muxer needs to deliver packets at the correct rate.

[shon3i]

I mean which program created the graphic.Aha ;) sorry, with BD Quest Buffer Analyzer :)

It is not the fault of x264 when STD buffers overflow. But what then make that muxer "incorrectly" mux stream, i don't use other streams (video,audio,sub). I use tsmuxer for example because is "non strict", while Sonic Scenarist will tend to do same, but stops when see things goes wrong. There is must some rule for VBV or HRD buffer, something that like min/max (not mean for -vbv-bufsize), some tolerance.

Btw mp3dom, report that Cinvision stream with "same" settings passes mux, i know is not good comparing these encoders with x264 because ratecontrols are different, but i know that Mainconcept have very strict VBV, from ealier days.

[kolak]

Aha ;) sorry, with BD Quest Buffer Analyzer :)

But what then make that muxer "incorrectly" mux stream, i don't use other streams (video,audio,sub). I use tsmuxer for example because is "non strict", while Sonic Scenarist will tend to do same, but stops when see things goes wrong. There is must some rule for VBV or HRD buffer, something that like min/max (not mean for -vbv-bufsize), some tolerance.

Btw mp3dom, report that Cinvision stream with "same" settings passes mux, i know is not good comparing these encoders with x264 because ratecontrols are different, but i know that Mainconcept have very strict VBV, from ealier days.

This is exactly what I was talking about- it looks like x264 can produce compliant streams, but in reality (muxing stage) there are still unpredictable problems.

I've never had problems with Cinevision even if I quite often push all settings to the limits and done already hundreds encodes for BD.

[Dark Shikari]

This is exactly what I was talking about- it looks like x264 can produce compliant streams, but in reality (muxing stage) there are still unpredictable problems.Then why blame x264? If there are problems in the muxing stage, your muxer is broken, plain and simple.

[kolak]

Then why blame x264? If there are problems in the muxing stage, your muxer is broken, plain and simple.

Can be, but muxer works fine with 3 other encoders (each of them is from different company). Muxer also uses some information from AVC headers, so problem can be there.
It's more about making them working together- there are many things which are not specified in BD spec and this may be responsible for problems.

[kieranrk]

there are many things which are not specified in BD spec and this may be responsible for problems.

Feel free to go into more detail...

[Revgen]

Let's be honest here.

Do you think the scenarist programmers are going to fix the problem?

[kolak]

Feel free to go into more detail...

I'm not technical enough, but have seen early stages of HD DVD and used few beta software (Cinemacraft HDe and MemoryTech software for HD DVD authoring). There were issues at the beginning, because BD spec is just a small section of AVC spec, so there is room for different interpretation of unspecified parameters.

[shon3i]

This is exactly what I was talking about- it looks like x264 can produce compliant streams, but in reality (muxing stage) there are still unpredictable problems.

I've never had problems with Cinevision even if I quite often push all settings to the limits and done already hundreds encodes for BD.
Well now i can't say what is precent of this streams encoded with x264 that fail mux in scenarist, because i use various HRD patches, so they are not been so perfect. For now i don't have any issue. So probably percent is something about 1-2% not more But i am still afraid because mp3dom reported this issue. Anyway i see most of retail BD that can't be remuxed with same error, that disc is mostly form small distributors, so i suspect they probably use cheap encoders/muxers.

It's more about making them working together- there are many things which are not specified in BD spec and this may be responsible for problems. I totaly agree with this.

Do you think the scenarist programmers are going to fix the problem? Scenarist don't have problem. Tsmuxer detect same.

[Dark Shikari]

Let's be honest here.

Do you think the scenarist programmers are going to fix the problem?Why do we care? Our eventual goal is to create an open source Blu-ray authoring pipeline, which means Scenarist can die in a fire.

[Revgen]

Why do we care? Our eventual goal is to create an open source Blu-ray authoring pipeline, which means Scenarist can die in a fire.

I wasn't aware of this.

That's good news.

[kolak]

Well now i can't say what is precent of this streams encoded with x264 that fail mux in scenarist, because i use various HRD patches, so they are not been so perfect. For now i don't have any issue. So probably percent is something about 1-2% not more But i am still afraid because mp3dom reported this issue. Anyway i see most of retail BD that can't be remuxed with same error, that disc is mostly form small distributors, so i suspect they probably use cheap encoders/muxers.

I totaly agree with this.

Scenarist don't have problem. Tsmuxer detect same.

What do you use for demuxing? Are you sure that AACS is striped properly?

I would be careful about these re-authoring statements.
BD is not DVD- there are not many authoring software, which can do project ready for replication. Probably 98% (or more) BDs in the shops will be made with Scenarist or Blu-print, which are quite strict.

I use DVD Reuathor and already found few projects (which I made in the first place) not ripping and re-authorign properly.
BD can be only worse- it's very new compared to DVD.

[shon3i]

What do you use for demuxing? Are you sure that AACS is striped properly?Absolutely, tryed with both comercial and free software, BDReauthor, BD Demuxer and some ts demuxer and eac3to/tsmuxer as for free soft. I very sure that demuxed streams are good.

[kolak]

Absolutely, tryed with both comercial and free software, BDReauthor, BD Demuxer and some ts demuxer and eac3to/tsmuxer as for free soft. I very sure that demuxed streams are good.

Neither of these programs is very accurate.
BDReauthor comes from the same company as DVDReauthor and I would not blindly trust in it.
We tried it on simple project and didn't restore it as original. It's very useful in some cases, but not 100% reliable.
It can "fix" AVC header, so out of spec file can be imported into Scenarist, but this is not a proper fix, just trick to pass Scenarist checks-it's very dangerous option.

Do a project, replicate it and try to rip and restore- you may be surprised.

[shon3i]

Do a project, replicate it and try to rip and restore- you may be surprised.
I already have that expirience. But here is something different, i tryed with all possible TS demuxers, raw streams aren't been identical, but all failed on same place, so it's definitly wrong in stream itself.

@Dark Shikari i just want to ask? how can be on muxer side, because all present muxers (not only Blu-Ray) produce sam behavior. Aslo why qpcomp solve the problem, and vbv-int (in my earler case). Does not this make conclusion that something missing. All encoders i tryed for BD encoding are usualy are focus on BD encoding only, they are more restrictive then we know. I want to say that it is very difficult to make general use Encoder, to cover all places

[Dark Shikari]

@Dark Shikari i just want to ask? how can be on muxer side, because all present muxers (not only Blu-Ray) produce sam behavior. Aslo why qpcomp solve the problem, and vbv-int (in my earler case). Does not this make conclusion that something missing.If every day I drive my car to work, and then one day I bring a can of soda with me, and I get into a car accident, does that mean the can of soda is responsible for the crash?All encoders i tryed for BD encoding are usualy are focus on BD encoding only, they are more restrictive then we know. I want to say that it is very difficult to make general use Encoder, to cover all placesAre you sure that the Blu-ray encoders are using the same VBV restrictions as x264? Because I'm pretty sure that you aren't.

Have you checked any with vbv.pl?

[kolak]

If every day I drive my car to work, and then one day I bring a can of soda with me, and I get into a car accident, does that mean the can of soda is responsible for the crash?Are you sure that the Blu-ray encoders are using the same VBV restrictions as x264? Because I'm pretty sure that you aren't.

Have you checked any with vbv.pl?

All pro encoders are very strict in terms of VBV and that's why I've never had any muxing problems and as I said- I quite often push parameters to the max.

[Dark Shikari]

All pro encoders are very strict in terms of VBV and that's why I've never had any muxing problems and as I said- I quite often push parameters to the max.But do you know that they're actually maxing out the VBV parameters? No, you don't, because you haven't checked.

It's quite possible they're intentionally leaving extra leeway beyond what is necessary (e.g. for the sake of the muxer).

[shon3i]

Are you sure that the Blu-ray encoders are using the same VBV restrictions as x264? Because I'm pretty sure that you aren't.They are not in first place offcourse, but beleve me i do anything to make it, even i scan streams with various tools to make it indentical. Only thing that i notice is CPB removal relay is always been different, for example cinevision encode always keep it around 0.9, while x264 very vary. I didn't checke with VBV.pl, because is as other buffer analyzers. Here we need something that know what is Blu-Ray restriction (like BD Quest Buffer Analyzer), that will contorol HRD model that follow VBV model etc, in Blu-Ray range.

Like kolak say, i neve have that expirience with other encoders. I always check stream with analyzer and notice, that buffer came out for example 29999 if i use default HRD/VBV buffersize which is 30000. But that is not porblem, i mean i tryed exatly same settings with x264.

[kieranrk]

I always check stream with analyzer and notice, that buffer came out for example 29999 if i use default HRD/VBV buffersize. But that is not porblem, i mean i tryed exatly same settings with x264.

EDIT: never mind; Blu-Ray fixed the issue I was talking about long before TS did.

[shon3i]

What can be done then? Probably other encoders have some workaround

[kieranrk]

What can be done then? Probably other encoders have some workaround

Fix the muxer.

Do you have any apps that show how many bits per second are entering the transport buffer?

[Dark Shikari]

What can be done then? Probably other encoders have some workaroundWell, if you don't tell us the results of vbv.pl, we can't figure out now can we?

What I want to know is if you set maxrate=40k, what bufsize does vbv.pl come up with? And if you set bufsize=30k, what maxrate does vbv.pl come up with?

[shon3i]

Fix the muxer.
Well i can contact Authors of tsmuxer and sonic support and send problematic stream.

Do you have any apps that show how many bits per second are entering the transport buffer? I think i not, but if you have something on mind (name of program) i can check maybe i have it on work.

Well, if you don't tell us the results of vbv.pl, we can't figure out now can we?

What I want to know is if you set maxrate=40k, what bufsize does vbv.pl come up with? And if you set bufsize=30k, what maxrate does vbv.pl come up with? Ok, no problem i will do everything you need, but tomorow now i go to sleep ;)

[shon3i]

I don't know why i get this message when i try to use vbv.pl

List form of pipe open not implemented at C:\vbv.pl line 32

I have ActivePeal 5.10.1 installed on Windows 7 64bit

cmd that i use is

vbv.pl --bufsize 30000 video.mkv

[kieranrk]

cmd that i use is

vbv.pl --bufsize 30000 video.mkv

Do it on a raw .264 file.

[shon3i]

Do it on a raw .264 file.
Well in help of VBV.pl stay what is supported for infile:

Infile can be:
a text file containing frame sizes in bytes, 1 per line
a text file containing the output of `x264 -v`
matroska (only the first track is analyzed)

Maybe i have some old version of VBV.pl

[kieranrk]

Well in help of VBV.pl stay what is supported for infile:


Yes but when you are muxing Blu-Rays, you are not muxing mkv files. There are differences between muxing into raw .264 and mkv.

[shon3i]

Yes but when you are muxing Blu-Rays, you are not muxing mkv files. There are differences between muxing into raw .264 and mkv.
Agree, but what can i do then ?

[kieranrk]

x264 -v should probably work.

[mp3dom]

Today I've tried to made an encode. I've used the "zones" parameter to change some values (trellis and deadzone). x264 shows a warning saying that VBV parameters could not be modified with HRD activated. Since it's the first time that I've received this warning (also I haven't changed any VBV value, only trellis and deadzone) I'm asking if this is ok (only a warning), or if the zones is trying to change the VBV parameters in any way. Thanks.

[shon3i]

@kieranrk, since i can't find good stream to replicate muxing underflow problem (mp3dom has no access to master anymore), i found some little older documents "Method for preventing buffer underflow during digital transport stream transmission, multiplexing and splicing" where clearly say that HRD/VBV model need to be adjusted and there is min/max. I can send you pdf document in case you don't have, just send me pm.

[kieranrk]

I'm asking if this is ok (only a warning), or if the zones is trying to change the VBV parameters in any way. Thanks.

This is a bug and it's been fixed locally.

[MadMonkey57]

ouch.
I've authored about 100 BD5s with this toolchain (including like 15 with x264-rev1471-nal-hrd-1.32) and so far all was fine. And now, I have a problem.
My toolchain:

- kubuntu 9.10 64 bits
- reading source video (m2ts file): mplayer SVN-r30531 (build from source)
- video encoding: x264-rev1471 + nal-hrd 1.32 (build from source)
- audio reading/encoding: ffmpeg + sox + aften
- tsmuxer 1.10.6
- home made scripts to perform all the work (reading source file, calculating bitrates, encoding audio/video, muxing, creating iso)

All isos ended up 4.3GB and played OK in my Pana BD35, but my last iso is 4.1GB and is rejected by the SAP.

When I play the m2ts within the iso, mplayer says at the very beginning:
[h264 @ 0xd4da00]reference picture missing during reorder 0.6% 0 0
[h264 @ 0xd4da00]reference picture missing during reorder
[h264 @ 0xd4da00]Missing reference picture
[h264 @ 0xd4da00]Missing reference picture
[h264 @ 0xd4da00]reference picture missing during reorder 0.6% 0 0
[h264 @ 0xd4da00]Missing reference picture
[h264 @ 0xd4da00]reference picture missing during reorder 0.6% 0 0
[h264 @ 0xd4da00]Missing reference picture

mediainfo shows:
Video
ID : 4113 (0x1011)
Menu ID : 1 (0x1)
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.0
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Duration : 2h 1mn
Bit rate : 3 816 Kbps
Nominal bit rate : 3 680 Kbps
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Frame rate : 23.976 fps
Resolution : 8 bits
Colorimetry : 4:2:0
Scan type : Progressive
Bits/(Pixel*Frame) : 0.173
Stream size : 3.25 GiB (79%)
Writing library : x264 core 89
Encoding settings : cabac=1 / ref=4 / deblock=1:-1:-1 / analyse=0x3:0x133 / me=umh / subme=10 /
psy=1 / psy_rd=1.00:0.15 / mixed_ref=1 / me_range=24 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 /
fast_pskip=1 / chroma_qp_offset=-3 / threads=12 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 /
constrained_intra=0 / bframes=3 / b_pyramid=0 / b_adapt=2 / b_bias=0 / direct=3 / wpredb=1 /
wpredp=2 / keyint=24 / keyint_min=2 / scenecut=40 / intra_refresh=0 / rc_lookahead=24 / rc=2pass / mbtree=1 /
bitrate=3680 / ratetol=1.0 / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / vbv_maxrate=15000 /
vbv_bufsize=15000 / ip_ratio=1.40 / aq=1:1.00 / pulldown=0 / nal_hrd=vbr
I will investigate deeper but it looks it *could* be an encoding issue.

Does it ring any bell ?

[kolak]

ouch.
I've authored about 100 BD5s with this toolchain (including like 15 with x264-rev1471-nal-hrd-1.32) and so far all was fine. And now, I have a problem.
My toolchain:

- kubuntu 9.10 64 bits
- reading source video (m2ts file): mplayer SVN-r30531 (build from source)
- video encoding: x264-rev1471 + nal-hrd 1.32 (build from source)
- audio reading/encoding: ffmpeg + sox + aften
- tsmuxer 1.10.6
- home made scripts to perform all the work (reading source file, calculating bitrates, encoding audio/video, muxing, creating iso)

All isos ended up 4.3GB and played OK in my Pana BD35, but my last iso is 4.1GB and is rejected by the SAP.

When I play the m2ts within the iso, mplayer says at the very beginning:
[h264 @ 0xd4da00]reference picture missing during reorder 0.6% 0 0
[h264 @ 0xd4da00]reference picture missing during reorder
[h264 @ 0xd4da00]Missing reference picture
[h264 @ 0xd4da00]Missing reference picture
[h264 @ 0xd4da00]reference picture missing during reorder 0.6% 0 0
[h264 @ 0xd4da00]Missing reference picture
[h264 @ 0xd4da00]reference picture missing during reorder 0.6% 0 0
[h264 @ 0xd4da00]Missing reference picture

mediainfo shows:
Video
ID : 4113 (0x1011)
Menu ID : 1 (0x1)
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.0
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Duration : 2h 1mn
Bit rate : 3 816 Kbps
Nominal bit rate : 3 680 Kbps
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Frame rate : 23.976 fps
Resolution : 8 bits
Colorimetry : 4:2:0
Scan type : Progressive
Bits/(Pixel*Frame) : 0.173
Stream size : 3.25 GiB (79%)
Writing library : x264 core 89
Encoding settings : cabac=1 / ref=4 / deblock=1:-1:-1 / analyse=0x3:0x133 / me=umh / subme=10 /
psy=1 / psy_rd=1.00:0.15 / mixed_ref=1 / me_range=24 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 /
fast_pskip=1 / chroma_qp_offset=-3 / threads=12 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 /
constrained_intra=0 / bframes=3 / b_pyramid=0 / b_adapt=2 / b_bias=0 / direct=3 / wpredb=1 /
wpredp=2 / keyint=24 / keyint_min=2 / scenecut=40 / intra_refresh=0 / rc_lookahead=24 / rc=2pass / mbtree=1 /
bitrate=3680 / ratetol=1.0 / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / vbv_maxrate=15000 /
vbv_bufsize=15000 / ip_ratio=1.40 / aq=1:1.00 / pulldown=0 / nal_hrd=vbr
I will investigate deeper but it looks it *could* be an encoding issue.

Does it ring any bell ?

1280x720 at 24p is not officially supported combination on BD.

[mp3dom]

1280x720 is supported at 23.976p/24p/50p/60p

[kieranrk]

Post a raw .264 sample where this occurs. The ts muxer may have used the wrong DTS for whatever reason.

[Sharc]

1280x720 is supported at 23.976p/24p/50p/60p
60p? Isn't it 59.94 according to Blu-ray spec?

[kolak]

1280x720 is supported at 23.976p/24p/50p/60p

Ups- sorry:)

[shon3i]

60p? Isn't it 59.94 according to Blu-ray spec?
Exactly :)

[mp3dom]

Yes, I wrote 60p but I mean 59.94 (60000/1001) :P

[MadMonkey57]

Post a raw .264 sample where this occurs. The ts muxer may have used the wrong DTS for whatever reason.

I've made a couple of x264 encodings. Depending on the video length / bitrate, sometimes I get no error, sometimes I get an "cpb_count 33 invalid" (http://www.megaupload.com/?d=K6NAK8U8) playing with mplayer...

EDIT: Damn it. Upgraded mplayer to latest SVN (mplayer is used to feed x264 and for playing resulting .264 file), ran the exact same encoding as before and I get:
[h264 @ 0xd64fe0]illegal num_reorder_frames 26
[h264 @ 0xd64fe0]illegal num_reorder_frames 26

EDIT 2: same behaviour
- a change in bitrate shows "cpb_count 33 invalid" 3 times now
- another change in bitrate shows no error...

I can post the "illegal num_reorder_frames 26" if necessary.

[kieranrk]

Looks like mplayer is complaining about issues that don't exist in that sherlock holmes clip.

[MadMonkey57]

Some other thing I have noticed:

- I run twice the exact same commands and end up in .264 file that are different (binary comp). Might be normal, I don't know
- ran x264-rev1376 + x264_hrd_pd_interlace.16_r1369 and had one "llegal num_reorder_frames 47" twice

This is really confusing. Maybe it's just mplayer.

Still I don't understand why my BD35 rejects the resulting .264 stream...

[MadMonkey57]

Got it. Serious PEBKAC issue... My subtitle file was corrupted hence muxing problem... Duh!

Sorry guys.

[LoRd_MuldeR]

Some other thing I have noticed:

- I run twice the exact same commands and end up in .264 file that are different (binary comp). Might be normal, I don't know
- ran x264-rev1376 + x264_hrd_pd_interlace.16_r1369 and had one "llegal num_reorder_frames 47" twice

This is really confusing. Maybe it's just mplayer.

First of all x264 should be deterministic (i.e. it should always give the identical output for the identical input), unless you explicitely specify the "--non-deterministic" parameter.

And this usually works for me. For example I regularly do bit-by-bit comparison to test different GCC versions with x264.

Anyway, if MPlayer complains about the stream then this means that libavcodec's H.264 decoder complains. That's the H.264 decoder used in practically all OpenSource applications.

[MadMonkey57]

First of all x264 should be deterministic
Thanks for the clarification. Don't know why I couldn't verify it. Maybe one of those PEBKAC, who knows... I'll try again tomorrow.

Anyway, if MPlayer complains about the stream then this means that libavcodec's H.264 decoder complains. That's the H.264 decoder used in practically all OpenSource applications.
You're right. mplayer's latest SVN won't help here.

[Dark Shikari]

First of all x264 should be deterministic (i.e. it should always give the identical output for the identical input), unless you explicitely specify the "--non-deterministic" parameter.Not with VBV...

[MasterNobody]

First of all x264 should be deterministic (i.e. it should always give the identical output for the identical input), unless you explicitely specify the "--non-deterministic" parameter.

And this usually works for me. For example I regularly do bit-by-bit comparison to test different GCC versions with x264.
There are two bugs that cause nondeterministic results in current version (which are locally fixed in next update). Also VBV is inherently nondeterministic (and this is not the bug).

[LoRd_MuldeR]

Good to know that VBV is inherently nondeterministic. If I remember correctly, the x264 developers once said that an application should always be deterministic ;)

However I didn't enable VBV for my tests, so that's probably why it worked for me...

[Dark Shikari]

Good to know that VBV is inherently nondeterministic. If I remember correctly, the x264 developers once said that an application should always be deterministic ;)Except when forcing such determinism would significantly decrease the quality of output...

[kypec]

Except when forcing such determinism would significantly decrease the quality of output...

:confused: Quality or Encoding time only? Pardon my ignorance and lack of knowledge about video encoding but how can determinism decrease quality here?

[Dark Shikari]

:confused: Quality or Encoding time only? Pardon my ignorance and lack of knowledge about video encoding but how can determinism decrease quality here?Because determinism limits the amount of information that each thread can request from the others, since you cannot request any information that isn't deterministic.

[kolak]

Except when forcing such determinism would significantly decrease the quality of output...

This is one of the reasons why x264 has better quality than pro encoders.

[jpsdr]

I want to extract the raw video data stream from an .mts/.m2ts ripped from a blu-ray, to be able to re-use it afterward directly, untouched, in Scenarist.
Is tsmuxer the right tool to do this ?
If yes, is there some specific command line to put to ensure the video data stream will be correct ?
Thanks.

[shon3i]

Use eac3to to get untoched stream, Tsmuxer can rewritte aud's or hrd model

[mp3dom]

Is BD Reauthor Pro/BD Demuxer safe for extract raw streams from M2TS?

[jpsdr]

Use eac3to to get untoched stream, Tsmuxer can rewritte aud's or hrd model

That was the 2nd tool i was thinking about, but as it was first dedicated to audio (as name stated), i didn't know if it was handling properly video stream.

After a quick look at the doc, i assume the command line
will be only :
eac3to File.mts -demux
or is there other parameters, things to do ?

[shon3i]

Is ABR RC ok with VBV? i do some encodes and I am very pleased with the quality/speed ratio, and I had no problems to mux it with scenarist. Everything work flawlessly.

What is progress, when the patch will be commited, is there something we need to test more?

[kolak]

I want to extract the raw video data stream from an .mts/.m2ts ripped from a blu-ray, to be able to re-use it afterward directly, untouched, in Scenarist.
Is tsmuxer the right tool to do this ?
If yes, is there some specific command line to put to ensure the video data stream will be correct ?
Thanks.

None of these tools seams to be very reliable.

Andrew

[jpsdr]

Can someone explain to me, why a 163000 frames 23.976fps file, encoded with the following command line :

1rst pass :
x264_x86.exe --profile "high" --preset "placebo" --tune animation --pass 1 --bitrate 26517 --stats %STAT_FILE% --level "4.1" --vbv-maxrate 40000 --vbv-bufsize 30000 --keyint 24 --min-keyint 2 --mvrange 511 --ref 4 --bframe 3 --slices 4 --b-pyramid "strict" --subme 9 --trellis 1 --me "umh" --aq-mode 2 --aud --nal-hrd "vbr" --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --sar 1:1 --qpfile %5 --threads 0 --thread-input --output NUL %E_SRC%

2nd pass :
x264_x86.exe --profile "high" --preset "placebo" --tune animation --pass 2 --bitrate 26517 --stats %STAT_FILE% --level "4.1" --vbv-maxrate 40000 --vbv-bufsize 30000 --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%

Give me a result file of 14.9GB, instead of the 21.5GB expected ????

[G_M_C]

Can someone explain to me, why a 163000 frames 23.976fps file, encoded with the following command line :

1rst pass :
x264_x86.exe --profile "high" --preset "placebo" --tune animation --pass 1 --bitrate 26517 --stats %STAT_FILE% --level "4.1" --vbv-maxrate 40000 --vbv-bufsize 30000 --keyint 24 --min-keyint 2 --mvrange 511 --ref 4 --bframe 3 --slices 4 --b-pyramid "strict" --subme 9 --trellis 1 --me "umh" --aq-mode 2 --aud --nal-hrd "vbr" --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --sar 1:1 --qpfile %5 --threads 0 --thread-input --output NUL %E_SRC%

2nd pass :
x264_x86.exe --profile "high" --preset "placebo" --tune animation --pass 2 --bitrate 26517 --stats %STAT_FILE% --level "4.1" --vbv-maxrate 40000 --vbv-bufsize 30000 --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%

Give me a result file of 14.9GB, instead of the 21.5GB expected ????

Because the encode is bitrate saturated ? At least thats my guess. Others might not agree with me.

x264 reaches its lowest possible qp's (quantizers) at a lower bitrate than you specify. Lower QP-min, or just be satified that x264 is much more efficient then you expected (which is the recommended reaction).

[Fr4nz]

Can someone explain to me, why a 163000 frames 23.976fps file, encoded with the following command line :

1rst pass :
x264_x86.exe --profile "high" --preset "placebo" --tune animation --pass 1 --bitrate 26517 --stats %STAT_FILE% --level "4.1" --vbv-maxrate 40000 --vbv-bufsize 30000 --keyint 24 --min-keyint 2 --mvrange 511 --ref 4 --bframe 3 --slices 4 --b-pyramid "strict" --subme 9 --trellis 1 --me "umh" --aq-mode 2 --aud --nal-hrd "vbr" --colorprim "bt709" --transfer "bt709" --colormatrix "bt709"
--sar 1:1 --qpfile %5 --threads 0 --thread-input --output NUL %E_SRC%
[...]


As a side-note: why you use the following parameters which, in your case, override many "placebo" preset settings (or are totally useless)?

--mvrange 511 --ref 4 --bframe 3 --slices 4 --subme 9 --trellis 1 --me "umh" --aq-mode 2

Read here:
http://forum.doom9.org/showthread.php?t=148149

[shon3i]

Well --slices 4 is not used by any preset ;) so always must be added manualy, and --ref 4 is better for safetly reason, we don't know what is his source i mean 1080/720/576/480, x264 level detector use H264 specs so if you miss something with that high preset you can get 8-16 refs instead 4-6.

[jpsdr]

My source is 1080p. In the 1rst pass, some preset are overrided to speed it up. After, there is some parameters i prefer set manualy, to be sure they stay Blu-Ray compliant, as tuning may modify them, even if it's useless. I prefer safety.
Now, bitrate saturated ? I realy doubt it... I've encoded an 1h video at CBR at 40000mb, because even with this, file still fill on a single layer blu-ray, and result was a 19GB file, as expected. This one should have more reason to be saturated. And it's the first time i'm seeing this. I'll will redo the encoding (almost one day...), in case something unexpected had happened, and remove the shutdown command from my bat file, to see the result output by x264.

[G_M_C]

My source is 1080p. In the 1rst pass, some preset are overrided to speed it up. After, there is some parameters i prefer set manualy, to be sure they stay Blu-Ray compliant, as tuning may modify them, even if it's useless. I prefer safety.
Now, bitrate saturated ? I realy doubt it... I've encoded an 1h video at CBR at 40000mb, because even with this, file still fill on a single layer blu-ray, and result was a 19GB file, as expected. This one should have more reason to be saturated. And it's the first time i'm seeing this. I'll will redo the encoding (almost one day...), in case something unexpected had happened, and remove the shutdown command from my bat file, to see the result output by x264.

Yes look at the avg QP's x264 achieved to code.

But before i go into this further: This tread is used for something else, so this subject is actually off topic.

[kieranrk]

My source is 1080p. In the 1rst pass, some preset are overrided to speed it up. After, there is some parameters i prefer set manualy, to be sure they stay Blu-Ray compliant, as tuning may modify them, even if it's useless. I prefer safety.
Now, bitrate saturated ? I realy doubt it... I've encoded an 1h video at CBR at 40000mb, because even with this, file still fill on a single layer blu-ray, and result was a 19GB file, as expected. This one should have more reason to be saturated. And it's the first time i'm seeing this. I'll will redo the encoding (almost one day...), in case something unexpected had happened, and remove the shutdown command from my bat file, to see the result output by x264.

Use a build with a more recent set of patches. (like JEEBs)

[jpsdr]

In fact, closing this, G_M_C was right. After the 1rst pass, i was having encoded at 19589.
And, in the begining of the 2nd pass, i had a warning : Target 26517, expected 20260 avg qp :10, try lower qp or bitrate.
I'll add --qpmin 0 in my command line. Thanks for the information and the help. This close this off topic.

[Underground78]

Commit : Blu-ray support: NAL-HRD, VFR ratecontrol, filler, pulldown (http://git.videolan.org/gitweb.cgi?p=x264.git;a=commit;h=c6de86497cdd7b7f3cce7d8a95d723c7d0c9f505)

[Firebird]

Finally :)

[shon3i]

Champagne was opened :D Cheers!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

[kolak]

Commit : Blu-ray support: NAL-HRD, VFR ratecontrol, filler, pulldown (http://git.videolan.org/gitweb.cgi?p=x264.git;a=commit;h=c6de86497cdd7b7f3cce7d8a95d723c7d0c9f505)

Not sure about all rules, but does it mean it's finished?
Where can I find version with patch (finally can compare it with Cinemacraft HD)
Is there a MeGUI version, which works with it?

Andrew

[JEEB]

Not sure about all rules, but does it mean it's finished?
Where can I find version with patch (finally can compare it with Cinemacraft HD)
Is there a MeGUI version, which works with it?

Andrew

Yes, it seems to be finished on a level, and if anyone has bugs they should be reported so that they could be fixed ASAP. Kierank and the guys have made a tremendous effort at keeping to the standards, though, so it should be usable.

I build builds over at x264.fushizen.eu (http://x264.fushizen.eu) , and it seems like MeGUI 0.3.4.0 can take use of it (at some level), as it could take use of the patched 1471s (which, with megapatches, pretty much were the same as the resulting revision). I haven't tested MeGUI with nal-hrd usage lately, though. So I have no idea if they've updated their things. I would guess that they've updated it, since it has been quite some time that the patch has been around.

Edit:
Jarod, of course, should also get done with the 32bit build at x264.nl at some point as well.

[Zathor]

Is there a MeGUI version, which works with it?
The latest development version should work with it. You have to replace x264.exe and x264_64.exe with the new ones.

[JEEB]

The latest development version should work with it. You have to replace x264.exe and x264_64.exe with the new ones.

And here we have the answer to the question, great job at keeping the application up-to-date.

[mp3dom]

Great work and great results! :) Thanks to all the developers.

[kolak]

The latest development version should work with it. You have to replace x264.exe and x264_64.exe with the new ones.

Thanks- will report my findings about quality (compared to PRO encoders) and compatibility.
Are there any advantages to use 64bit version on WinXP with 6GB of RAM?

[MadMonkey57]

Congratulations and Thanks to ALL OF YOU guys !

[shon3i]

Where can I find version with patch (finally can compare it with Cinemacraft HD)What you need to test more, that not allready tested/proven many times before, now we have officialy one more switch which not affect on quality, just add support for devices.

I now run encode, to see what verificators say :) I have access to Sony Verifier 1.3 again and i have new BDQuest 1.3.2 which have all comformace bugs fixed.

[LoRd_MuldeR]

Are there any advantages to use 64bit version on WinXP with 6GB of RAM?

The 64-Bit version should give ~10% speed-up. And you cannot run into the 2 GB per-process memory limit. The latter probably is only an issue with insane settings.

However be aware that you'll need 64-Bit Avisynth, if you want to use Avisynth input with 64-Bit x264. And you'll need the "x64 Edition" of WinXP, which is only available as OEM version!

[kolak]

What you need to test more, that not allready tested/proven many times before, now we have officialy one more switch which not affect on quality, just add support for devices.

I now run encode, to see what verificators say :) I have access to Sony Verifier 1.3 again and i have new BDQuest 1.3.2 which have all comformace bugs fixed.

Haven't seen anyone testing it against Cinemaraft HD, did you?
Blu-code was very close to x264 (bit less sharp), but CC-HDe is yet another league, so there is something to test.

[laserfan]

Commit : Blu-ray support: NAL-HRD, VFR ratecontrol, filler, pulldown (http://git.videolan.org/gitweb.cgi?p=x264.git;a=commit;h=c6de86497cdd7b7f3cce7d8a95d723c7d0c9f505)
Am I the only one who's a little bit dizzy in noting that we've gone from 1471 to 1510 (not sure how that happens)!?

I mean, the Criterion evaluation appears to be back at 1480, now all-of-a-sudden we have 1510 and with a lot of names associated with the versions that I've not seen often.

I'm clueless tho about how stuff gets "committed" and maybe there is lots of testing that the rest of us don't see....

[LoRd_MuldeR]

Am I the only one who's a little bit dizzy in noting that we've gone from 1471 to 1510 (not sure how that happens)!?

I mean, the Criterion evaluation appears to be back at 1480, now all-of-a-sudden we have 1510 and with a lot of names associated with the versions that I've not seen often.

I'm clueless tho about how stuff gets "committed" and maybe there is lots of testing that the rest of us don't see....

That's how Git works. In contrast to the client/sever-based SVN or CVS, Git is organized in a decentralized way. It doesn't distinguish between "local" and "remote" repositories.

So you can commit your changes "locally" (into your own local Git repository), but they won't appear on the public server, until the pending changes are merged into the "remote" repository.

Obviously the devs hold back their local changes until they feel they are ready for a broader audience. Then a bunch of changes is merged into the public repository at once...

[dstln]

Recently they've been taking longer between commits, likely for testing/stability reasons. Not sure if it's more of a fundamental change to only release more stable code or just how it's happened to occur recently, but either way it doesn't matter too much.

[kieranrk]

Recently they've been taking longer between commits, likely for testing/stability reasons. Not sure if it's more of a fundamental change to only release more stable code or just how it's happened to occur recently, but either way it doesn't matter too much.

Because the commits have been huge patches where a lot of user testing was necessary. (lavf/ffms input and nal-hrd)

Sod's law also states that there will now be countless bugreports

[julius666]

However be aware that you'll need 64-Bit Avisynth, if you want to use Avisynth input with 64-Bit x264.

Or use avs2yuv to pipe the videostream from the 32 bit avisynth to the 64 bit x264.

[laserfan]

That's how Git works... Obviously the devs hold back their local changes until they feel they are ready for a broader audience. Then a bunch of changes is merged into the public repository at once...Thanks I appreciate your reply and look forward to trying 1510. :)

[Lyris]

Thank you so much and congratulations. I am in awe of the people who can make this sort of thing happen. I look forward to using the best quality AVC encoder in the world on Blu-ray Discs.

Now I just have to hope that we can find a nice master :)

[Revgen]

Commit : Blu-ray support: NAL-HRD, VFR ratecontrol, filler, pulldown (http://git.videolan.org/gitweb.cgi?p=x264.git;a=commit;h=c6de86497cdd7b7f3cce7d8a95d723c7d0c9f505)

Why are some of the features missing in x264cli?

Will this be fixed soon?

[Dark Shikari]

Why are some of the features missing in x264cli?

Will this be fixed soon?Which features?

[Revgen]

libx264 now returns HRD timing information to the caller in the form of an x264_hrd_t.

x264cli doesn't currently use it, but this information is critical for compliant TS muxing.

^This.

Pulldown support: libx264 allows the calling application to specify a pulldown mode for each frame.

This is similar to the way that RFFs (Repeat Field Flags) work in MPEG-2.

Note that libx264 does not modify timestamps: it assumes the calling application has set timestamps correctly for pulldown!

x264cli contains an example implementation of caller-side pulldown code.

^And This.

[Dark Shikari]

^This.x264cli doesn't use it because x264cli doesn't need it. It's not a missing feature.

[Revgen]

^Ahh, thanks for clarifying.

[G_M_C]

Brilliant, another milestone for x264 :cool:

:thanks: and cuda's for all who made this possible !

And on a sidenote:
I find x264 a great example on how an open source model can be used by many different people and companies. Both have their own wishes, and their own motivations. But if you sponsor some feature, or if you actually code a feature; it all becomes part of this greater good.

x264 becomes better and better, and has quite possible become the best h264 encoder around, all because of this Open Source model imho.

Super isn't it :).

[Atak_Snajpera]

x264 becomes better and better, and has quite possible become the best h264 encoder around, all because of this Open Source model imho.
I'm not afraid to say that it is already the best video encoder at the moment.

[G_M_C]

I'm not afraid to say that it is already the best video encoder at the moment.

I haven't tested them all, and there are sure to be people pointing to whatever comparison to say it's not (for whatever motivation). So i'd thought I circumvent that swampy area of discussion :p

But I'd agree on that

[Firebird]

I'm not afraid to say that it is already the best video encoder at the moment.

And i think it would be best for at least next 3 years.I mean, seriously, the only encoder that can beat it in feature is x265 :D

[Lyris]

If I thought there was an AVC encoder (at least within my reach) producing better quality results than x264, I would have used it instead of wishing for BD compliance :)

The fact that it's free and open source is the icing on the cake!

[kolak]

Done some testing and x264 is definately on pair with Pro encoders, but not really better. It's sharp, but does a bit of artefacts and speed is low compared to Blu-code or Cinemacraft HD.
I have only 4fps at veryslow preset and 8-10 at slow on 8 core, 3GHz machine. Tested on quite grainy 24p uncompressed movie source.

Can anyone share a command line optimised for film source with more grain than average source.
I've sued:

--preset slow --pass 1 --bitrate 19000 --stats "stats" --deblock -4:-4 --profile high --level 4.1 --tune film --bframes 3 --ref 4 --slices 4 --aud --nal-hrd vbr --b-pyramid strict --keyint 24 --min-keyint 2 --vbv-bufsize 30000 --vbv-maxrate 36000 --sar 1:1

[Mr VacBob]

Did you look at --tune grain?

[Dark Shikari]

Done some testing and x264 is definately on pair with Pro encoders, but not really better. It's sharp, but does a bit of artefacts and speed is low compared to Blu-code or Cinemacraft HD.

I have only 4fps at veryslow preset and 8-10 at slow on 8 core, 3GHz machine.veryslow is slow? Next thing you'll tell me that it's wet outside when it rains.

[kieranrk]

--vbv-bufsize 30000 --vbv-maxrate 36000

These settings could be increased to the maximum as allowed by the Blu-Ray spec.

[kolak]

veryslow is slow? Next thing you'll tell me that it's wet outside when it rains.

Hmmm- compared to Cinemacraft HD is few times slower- so slow :)

What can I change to adapt settings to grainy film source?
I frames are much betetr quality than P and B, what can I add to cmd line to change it?

[kolak]

These settings could be increased to the maximum as allowed by the Blu-Ray spec.

No- becuse there are DTS-MA and 24bit PCM audio tracks, so 36Mbit has to stay. It's a real world Blu-ray encoding, with real limitation, which you have to deal with once making Blu-ray project :)

[kieranrk]

What do VBV settings have to do with the existence of DTS-HD MA and LPCM tracks?

[kolak]

What do VBV settings have to do with the existence of DTS-HD MA and LPCM tracks?

VBV is at 30Mbit it's BD limit.
Is vbv max rate maximum bitrate?

[kolak]

Did you look at --tune grain?

Almost the same- maybe slightly better than tune film.

[RunningSkittle]

VBV is at 30Mbit it's BD limit.
Is vbv max rate maximum bitrate?

...read the help file!
"Sets the minimum rate the VBV buffer should be assumed to refill at. "
"Recommendation: VBV reduces quality, so you should only use it if you're encoding for a playback scenario that requires it. Set this to the minimum transfer speed that the decoder will receive data at."

And if you think veryslow is "too slow" use a faster preset!

[kolak]

...read the help file!
"Sets the minimum rate the VBV buffer should be assumed to refill at. "
"Recommendation: VBV reduces quality, so you should only use it if you're encoding for a playback scenario that requires it. Set this to the minimum transfer speed that the decoder will receive data at."

And if you think veryslow is "too slow" use a faster preset!

This is for Blu-ray project.

[bob0r]

If you want x264 to encoder faster use:
--let-our-powers-combine

You need all five though.

[kolak]

If you want x264 to encoder faster use:
--let-our-powers-combine

You need all five though.

or

--use pro encoder

:)

[RunningSkittle]

This is for Blu-ray project.

Then why complain about the speed? Do you think cinemacraft has magic elf that does encoding? NO! you just have x264 using slower options than cinemacraft

[kolak]

Then why complain about the speed? Do you think cinemacraft has magic elf that does encoding? NO! you just have x264 using slower options than cinemacraft

Yes, ELf in form of very optimised coding.

I'm using slow to have some acceptable speed, but quality is not any better than pro encoders. Almost everyone on this forum said that it's the best AVC encoder and studios shoudl use it for BD encodes- just wanted to check it.

[kieranrk]

I'm using slow to have some acceptable speed, but quality is not any better than pro encoders. Almost everyone on this forum said that it's the best AVC encoder and studios shoudl use it for BD encodes- just wanted to check it.

It's almost certain you're not using like-for-like settings.

[poisondeathray]

Can you post some quality comparisons, screenshots please?

I should hope a "pro encoder" would be better, or they would go out of business pretty fast

[kolak]

Can you post some quality comparisons, screenshots please?

I should hope a "pro encoder" would be better, or they would go out of business pretty fast

It does not have to be better, becasue x264 has huge testing comunity, so it could be better.
Can't post screens with current source, but I'm doing 1:1 compare frame by frame with source.

[RunningSkittle]

Can you do a test and post screen/sample with some HD source from here? http://media.xiph.org/video/derf/

[kolak]

Can you do a test and post screen/sample with some HD source from here? http://media.xiph.org/video/derf/

Probably yes.

[RunningSkittle]

for fairness could you also do x264 with your preferred (veryslow/slow?) preset and one with a preset that matches cinemacraft speed?
Im sure people would like to see the results :)

and perhaps put that in a new thread, so not off topic here

[Dark Shikari]

Hmmm- compared to Cinemacraft HD is few times slower- so slow :)x264 with slow settings is slower than another encoder with fast settings? CALL THE PRESSES!What can I change to adapt settings to grainy film source?
I frames are much betetr quality than P and B, what can I add to cmd line to change it?--tune grain

[shon3i]

Nothing new here, and i don't know why repeat same story.

Pro encoders for same "relative" quality have "much" faster speeds, for example an Pro Encoder with highest possible quality have tied quality with x264 --preset medium, but --preset medium is little slower. x264 --preset slow have much better quality that any pro encoder can't produce, but is almost double times slower than preset medium.

[kolak]

x264 with slow settings is slower than another encoder with fast settings? CALL THE PRESSES!--tune grain

CC-HDe does not go below 15fps for 24p in qulity mode (I don't use Normal or Fast at all), becuse 15fps is good. It's way faster on Nehalems, but I compare on the same PC.

Tried tune grain- good I frames, much worse P and B- difference is to big. Highier bitrate bigger advantage of pro encoders.

[kolak]

Nothing new here, and i don't know why repeat same story.

Pro encoders for same "relative" quality have "much" faster speeds, for example an Pro Encoder with highest possible quality have tied quality with x264 --preset medium, but --preset medium is little slower. x264 --preset slow have much better quality, but is almost double times slower than preset medium.

It's not even about speed- can't match pro encoders quality with x264 at all. It's closer at 19Mbit, but loose a lot at 25Mbit average.

[Dark Shikari]

It's not even about speed- can't match pro encoders quality with x264 at all. It's closer at 19Mbit, but loose a lot at 25Mbit average.You have a long history of posting dubious claims on these forums with no proof whatsoever.

Where are your samples? If you can't post them, stop this viral marketing charade now.

[Lyris]

Yes, ELf in form of very optimised coding.

I'm using slow to have some acceptable speed, but quality is not any better than pro encoders. Almost everyone on this forum said that it's the best AVC encoder and studios shoudl use it for BD encodes- just wanted to check it.
Thanks for sharing your findings, Kolak - I've not had the chance to use all of the pro encoders, so will take your word on it!

It's a harsh reality that speed counts for so much in production, but as they say, time is money. Thankfully time is not much of a restriction on the projects I work on.

If you can post some screen shot comparisons, I'd be very interested to see the differences.

[kolak]

You have a long history of posting dubious claims on these forums with no proof whatsoever.

Where are your samples? If you can't post them, stop this viral marketing charade now.

You're smart person- I can post whatever I want and you will belive it becussde you can see 2 frames?
...but you don't belive becuse I said it?

I can post some frames, but from some free source, as someone sugested.

[kolak]

You have a long history of posting dubious claims on these forums with no proof whatsoever.

Where are your samples? If you can't post them, stop this viral marketing charade now.

We have long story of you saying that x264 is the best, but noone ever compared it to best pro encoders- so your statement is empty.

[Dark Shikari]

We have long story of you saying that x264 is the best, but noone ever compared it to best pro encoders- so your statement is empty.I never compared x264 to the "pro encoders" you are using. You are the one comparing x264 to said pro encoders, therefore you have to post results. Furthermore, comparisons of x264 against publicly available "pro" encoders like Mainconcept have been wins for x264, thus there is the implicit assumption that x264 will beat other pro encoders unless you prove otherwise with actual examples.

You are posting claims without any proof. Stop it.You're smart person- I can post whatever I want and you will belive it becussde you can see 2 frames?
...but you don't belive becuse I said it?I asked for a sample, not a frame. This means a bitstream, a .h264 file. I want to see why x264 loses in these cases so that I can improve x264. How hard is this to understand?!

Finally, you are taking a thread about new x264 features and completely derailing it to promote your pet encoder. Per rule 3, please stop trying to repurpose this thread as a promotional vehicle for unrelated products. This is a discussion of NAL-HRD in x264, not CinemaCraft HD. If you want to post comparisons of x264 and other encoders, do it in a more relevant topic.

[MadMonkey57]

I usually don't post such comments, but frankly I don't get it.

This thread is about nal-hrd and the enormous amount of energy, time and effort that a lot of people have put into it.
Now it's finally commited and many of us are very excited. We want to express our happiness and gratitude.
We go like "Wow! I love x264! I love you guys! I love the power of Open Source! It's good to be part of this community ! x264 is the best encoder in the world !".

In this thread, we're supposed to be celebrating and not complaining about speed / quality / whatever.

Separate threads would be a lot more appropriate.

[G_M_C]

Brilliant, another milestone for x264 :cool:

:thanks: and cuda's for all who made this possible !

And on a sidenote:
I find x264 a great example on how an open source model can be used by many different people and companies. Both have their own wishes, and their own motivations. But if you sponsor some feature, or if you actually code a feature; it all becomes part of this greater good.

x264 becomes better and better, and has quite possible become the best h264 encoder around, all because of this Open Source model imho.

Super isn't it :).

I'm not afraid to say that it is already the best video encoder at the moment.

I haven't tested them all, and there are sure to be people pointing to whatever comparison to say it's not (for whatever motivation). So i'd thought I circumvent that swampy area of discussion :p

But I'd agree on that

The discussion in the posts above this one was the "swampy area of discussion" i tried to circumvent :(

I hope this thread doesnt end like many of the so called "comparison threads", where results are without proof. And in the cases where there actually was some proof, the proof proved invalid because the test wasnt preformed with equal settings.

If this "swampy area of discussion" arose because of my earlier post, i'm sorry. So back to the topic on hand: NAL-HRD is committed, and we thank Dark Shikari once again for his great effords :)

[Guest]

@all (especially kolak)

This thread is about the NAL-HRD patch. It is not about comparing x264 to other encoders. Further off topic posts will result in strikes.

[kolak]

I've had a problem with interlaced source.
PowerDVD displayed some blocking, pixelation during playback.
On the encode I had warning that interlaced is not implemented, I had --tff in the command. Is there is something special about interlaced sources?

[Dark Shikari]

I've had a problem with interlaced source.
PowerDVD displayed some blocking, pixelation during playback.
On the encode I had warning that interlaced is not implemented, I had --tff in the command. Is there is something special about interlaced sources?The warning is about weightp, which gets automatically turned off in interlaced mode.

The only issue I know with interlaced playback is that libavcodec currently has a bug with MBAFF-interlaced (what x264 uses) + weightb.

[jpsdr]

I'm going back to topic : I've run on a buffer underflow with Scenarist (5.1.3) during mux, using a file encoded with the following batch file :

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

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%

tuning : animation
bitrate (%2) : 40000
I've used the x64 build of rack04.
I can hardly provide the 64GB source or the 19GB file result...
But, i keep them, so, is there anything i can do to help to try to find the source of the problem...?

[Dark Shikari]

I'm going back to topic : I've run on a buffer underflow with Scenarist (5.1.3) during mux, using a file encoded with the following batch fileGoing by previous reports, Scenarist is known to have muxing issues. I would suggest using another tool, such as Sony Blu-print.

Also, you're generally supposed to use VBR, not CBR NAL-HRD.

[jpsdr]

Will it accept to import XML subtitles format use by Scenarist ?

[shon3i]

Going by previous reports, Scenarist is known to have muxing issues. I would suggest using another tool, such as Sony Blu-print.

Also, you're generally supposed to use VBR, not CBR NAL-HRD.
Well Sony Blu-print, DVD Architect and other avaible tools, will fail at same place as scenarist, i test with mp3dom sample, so here we go again with that problem i try to catch. Tsmuxer is only tool that pass mux, but if examine transport stream, buffers is over all restrictions.

@jpsdr you can only to tray what mp3dom success, try to use --qpcomp 0.5 to change ratecontrol decisions.

It is interesting that anime movies deal often with this problem

[jpsdr]

@dark shiraki : So, even if my encode is a constant bitrate at 40000kb, i must put --nal-hrd "vbr" and not --nal-hrd "cbr" ?
@shon3i : Encode restart with 0.5, result tomorow around the same time...

[Dark Shikari]

Well Sony Blu-print, DVD Architect and other avaible tools, will fail at same place as scenarist, i test with mp3dom sample, so here we go again with that problem i try to catch. Tsmuxer is only tool that pass mux, but if examine transport stream, buffers is over all restrictions.

@jpsdr you can only to tray what mp3dom success, try to use --qpcomp 0.5 to change ratecontrol decisions.

It is interesting that anime movies deal often with this problemqcomp 0.5 is not a solution. If there is a buffer underflow problem, show it to me so I can fix it. I have seen loads of complaining but nobody actually shows me anything so I can't do anything about it! I need the graphs, I need the error messages, I need the streams, I need the settings! Don't tell me about it, show it to me.

Let me state this in unequivocal terms:

Show me the problem so I can fix it!@dark shiraki : So, even if my encode is a constant bitrate at 40000kb, i must put --nal-hrd "vbr" and not --nal-hrd "cbr" ?I don't know what the Blu-ray spec says about it, but all "cbr" will do is waste space by adding padding bits. It's not necessary for Blu-ray.

[shon3i]

Show me the problem so I can fix it!When i found source, definitely i will, no problem for me, i just want to help. Here we talking about possible problems/solutions.

May again say i never saw this behavior with other encoder's, when i face with same problem in near past.

Anyway i googled a little bit and i found some documents interest about this, i don't know if they are usefull here

"Method for preventing buffer underflow during digital transport stream transmission, multiplexing and splicing"
http://www.freepatentsonline.com/7139241.pdf

Just look and tell me is something that maybe help. There is some graph's that show how VBV/HRD model need to be adjusted, depend of case.

And when i find good evidence i will inform you.

[kieranrk]

Anyway i googled a little bit and i found some documents interest about this, i don't know if they are usefull here

"Method for preventing buffer underflow during digital transport stream transmission, multiplexing and splicing"
http://www.freepatentsonline.com/7139241.pdf

Just look and tell me is something that maybe help. There is some graph's that show how VBV/HRD model need to be adjusted, depend of case.


That document refers to MPEG-2 only.

[jpsdr]

I repeat what i've said : Tell me what i can do to help.
Is there any way i can send you a 19GB file !?
Error message : Scenarist doesn't say more than buffer underflow during mux. It doesn't give any more detail, nothing like number of frame or anything else. At least, i haven't seen anything. So, i don't know where in the file Scenarist complain.
The graph : Tell me what to use (and how if necessary), and i'll provide you any graph you want.
The settings : You have them on my message.
The stream : considering the size, it could be a problem, but, as i've said, if you have a way to provide me a good connection, i can try to send you the 19GB result file. I REALY prefer avoid having to send you the 64GB source file...

[kolak]

I'm going back to topic : I've run on a buffer underflow with Scenarist (5.1.3) during mux, using a file encoded with the following batch file :

tuning : animation
bitrate (%2) : 40000
I've used the x64 build of rack04.
I can hardly provide the 64GB source or the 19GB file result...
But, i keep them, so, is there anything i can do to help to try to find the source of the problem...?

1st simply advise- don't use 40Mbit as max bitrate- always leave some room- it's advise from real word :)
Stay with 38Mbit.

Don't get upset Dark Shikari, but I have done hundreds of projects and never had even one muxing issue with Scenarist (with different versions), so there has to be something with AVC stream. Don't ask what- I don't know- just saying facts. If there would be a problem with muxing engine, there would be many people reporting it. Blu-print uses the same engine (or rather Scenarist uses the same as Blu-print)

[jpsdr]

What is the max bitrate allowed video+audio ?
For DVD, i've never set the max bitrate to 9800, but lower it to 9500, because max audio+video was very close to 9800.

[Lyris]

What is the max bitrate allowed video+audio ?
I know that the max bit rate in total is 54mbit/sec - but not all of that is video or audio.

I also wouldn't want to hit the maximum too much for the problematic players.

[kolak]

What is the max bitrate allowed video+audio ?
For DVD, i've never set the max bitrate to 9800, but lower it to 9500, because max audio+video was very close to 9800.

48Mbit, but by real world rule leave 1 or 2mbit room :)

[Dark Shikari]

1st simply advise- don't use 40Mbit as max bitrate- always leave some room- it's advise from real word :)
Stay with 38Mbit.Actually, that's a good point. Perhaps the 40mbps is supposed to include the TS overhead?I repeat what i've said : Tell me what i can do to help.
Is there any way i can send you a 19GB file !?
Error message : Scenarist doesn't say more than buffer underflow during mux. It doesn't give any more detail, nothing like number of frame or anything else. At least, i haven't seen anything. So, i don't know where in the file Scenarist complain.
The graph : Tell me what to use (and how if necessary), and i'll provide you any graph you want.
The settings : You have them on my message.
The stream : considering the size, it could be a problem, but, as i've said, if you have a way to provide me a good connection, i can try to send you the 19GB result file. I REALY prefer avoid having to send you the 64GB source file... Yeah, your situation is somewhat worse than others; 19GB is rather large (I recall some smaller cases from earlier).

Maybe you could burn and mail a Blu-ray disc?

[kieranrk]

Perhaps the 40mbps is supposed to include the TS overhead?

This is accounted for in the Blu-Ray buffering model. 1.2 * 40mbps (i.e. a large ts overhead) is used as the leak rate from the transport buffer.

[mariush]

Actually, that's a good point. Perhaps the 40mbps is supposed to include the TS overhead?Yeah, your situation is somewhat worse than others; 19GB is rather large (I recall some smaller cases from earlier).

Maybe you could burn and mail a Blu-ray disc?

Maybe you can use Remote Desktop Connection or some kind of desktop sharing...

[Dark Shikari]

Maybe you can use Remote Desktop Connection or some kind of desktop sharing...That doesn't let me analyze the file with my own tools though.

[RunningSkittle]

sending your tools to his system is probably easier than sending a disc through the mail :p

[Dark Shikari]

sending your tools to his system is probably easier than sending a disc through the mail :pThe former is also likely much more illegal ;)

[jpsdr]

Yes, i think also, and faster, sending something to the US will take around 2 to 3 weeks for me.
But, if there is realy no other way, PM me your mail address.
But sending the tools, i realy prefer the idea...
EDIT : Just see your answer... My level in english is not enough to understand your answer.
What do you meen by "former"...?
EDIT2 : Ok, dictionary, "former" mean "previous statement/proposition" in that case => sending file
on BR... Illegal... Yes, in that case, probably...

[Dark Shikari]

Yes, i think also, and faster, sending something to the US will take around 2 to 3 weeks for me.
But, if there is realy no other way, PM me your mail address.
But sending the tools, i realy prefer the idea...
EDIT : Just see your answer... My level in english is not enough to understand your answer.
What do you meen by "former"...?
EDIT2 : Ok, dictionary, "former" mean "previous statement/proposition" in that case => sending file
on BR... Illegal... Yes, in that case, probably...No, I meant that sending you the tools that I have, many of which are proprietary, is illegal.

[shon3i]

That document refers to MPEG-2 only.
Yes i notice, i thought, VBV model is simmilar.

A little bit more googling i found one more document http://www.faqs.org/patents/app/20100074340, but this time story is about MPEG4-AVC.

I read it and found interesting quotes.


[0006]One of the major challenges of splicing a video stream compliant with the MPEG-4 AVC Standard (hereinafter "MPEG-4 AVC Standard stream") is to ensure that a stream spliced with two independent source streams still meets the hypothetical reference decoder requirement, as defined by the MPEG-4 AVC standard. However, using the current specification, there is no guarantee that the stream combined by source streams which are already HRD-compliant is still going to be HRD-compliant. Therefore, splicing a MPEG-4 AVC Standard stream is not simply a cut-and-paste operation.

[0007]The hypothetical reference decoder is specified in the MPEG-4 AVC Standard. As defined therein, the hypothetical reference decoder model prevents an MPEG-4 AVC stream that has been encoded sequentially to cause buffer overflows or underflows at the decoder. However, we have identified three issues in the current hypothetical reference decoder model that prevent a spliced stream from being hypothetical reference decoder compliant. These issues are: [0008]1. Incorrect time of removal from the coded picture buffer of the first picture after the concatenation point. [0009]2. Incorrect picture output timing when concatenated with source streams with different initial decoded picture buffer delay. [0010]3. Violation of Equations C-15 and C-16, which may lead to buffer underflow or overflow.

Violation of Equation C-15/C-16

[0029]The current hypothetical reference decoder sets constraints to the initial_cpb_removal_delay in a buffering period supplemental enhancement information message as follows.

[0030]For each access unit n, with n>0, associated with a buffering period SEI message, with .DELTA.t.sub.g,90(n) specified by

.DELTA.t.sub.g,90(n)=90000*(t.sub.r,n(n)-t.sub.af(n-1)) (C-14)

[0031]If cbr_flag[SchedSelldx] is equal to 0,

initial_cpb_removal_delay[SchedSelldx]<=Ceil(.DELTA.t.sub.g,90(n)) (C-15)

[0032]Otherwise (cbr_flag[SchedSelldx] is equal to 1),

Floor(.DELTA.t.sub.g,90(n))<=initial_cpb_removal_delay[SchedSelldx]<- =Ceil(.DELTA.t.sub.g,90(n)) (C-16)

[0033]When the source streams are independently encoded, the spliced stream may violate these conditions easily, since the constraint (.DELTA.t.sub.g,90(n)) imposed to the initial_cpb_removal_delay of the later source stream is changed. Turning to FIG. 7, an example of spliced video violating the initial_cpb_removal_delay constraint is indicated generally by the reference numeral 700. In particular, a first source stream is indicated by the reference numeral 710, and a second source stream is indicated by the reference numeral 720.

[0034]In previous video coding standards such as, for example, the International Organization for Standardization/International Electrotechnical Commission (ISO/IEC) Moving Picture Experts Group-2 standard (hereinafter the "MPEG-2 AVC standard"), stream splicing is not a challenge since the behavior of the MPEG-2 Video Buffer Verifier, a similar concept to the hypothetical reference decoder in the MPEG-4 AVC Standard, differs in implementation and ultimately in end result from the hypothetical reference decoder in the MPEG-4 AVC Standard. The problems caused by the HRD behavior in regards to the MPEG-4 AVC Standard are not present in video implementations relating to the MPEG-2 Standard due to the following reasons: [0035]1. The decoding time of a picture is derived by the previous picture's type and, therefore, the decoding time has no problems with simple concatenation. [0036]2. There is no requirement on the picture output timing. [0037]3. There are no limits for the initial_cpb_removal_delay. The initial buffer fullness is based on the vbv_delay which is sent with each picture. The buffer underflow or overflow can be prevented by inserting zero stuffing bits or extra waiting time.

[0038]A MPEG-2 elementary stream can also be packed into a transport stream (TS) for transmission. The Society of Motion Picture and Television Engineers (SMPTE) standardized the splicing for MPEG-2 transport streams. The basic idea is to define constraints for MPEG-2 transport streams that enable them to be spliced without modifying the payload of the packetized elementary stream (PES) packets included therein.

[0039]However, no solution for MPEG-4 AVC stream splicing exists to overcome the above-described problems associated therewith.



I don't know is this can help, but is realy interesting.

[shon3i]

I found new moment, i use mp3dom sample which fail muxing. I just reencode it with

--pass 2 --bitrate 40000 --level 4.1 --ref 4 --keyint 24 --min-keyint 2 --vbv-maxrate 40000 --vbv-bufsize 30000 --slices 4 --aud --nal-hrd vbr --sar 1:1 --no-fast-pskip --no-dct-decimate --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --b-pyramid strict --qpmin 0

I use maximum possible settings to try reproduce, here is x264.log which clearly not show any underflow

y4m [info]: 1920x1080p 1:1 @ 24000/1001 fps (cfr)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast FastShuffle SSEMisalign LZCNT
x264 [info]: profile High, level 4.1
[0.6%] 1/166 frames, 1.00 fps, 1.#J kb/s, eta 0:02:45
[93.4%] 155/166 frames, 4.43 fps, 43265.01 kb/s, eta 0:00:02
C:\Users\shon3i\Desktop\AoDc1\New folder\test.avs: 1920x1080, 24000/1001 fps, 166 frames
[94.0%] 156/166 frames, 4.46 fps, 43202.91 kb/s, eta 0:00:02
[100.0%] 166/166 frames, 4.49 fps, 43313.12 kb/s, eta 0:00:00

x264 [info]: frame I:9 Avg QP: 5.81 size:230891
x264 [info]: frame P:131 Avg QP: 5.94 size:234346
x264 [info]: frame B:26 Avg QP: 6.42 size:172390
x264 [info]: consecutive B-frames: 66.9% 33.1% 0.0% 0.0%
x264 [info]: mb I I16..4: 15.2% 76.5% 8.4%
x264 [info]: mb P I16..4: 2.4% 69.3% 1.6% P16..4: 9.1% 8.8% 8.5% 0.0% 0.0% skip: 0.3%
x264 [info]: mb B I16..4: 15.7% 57.3% 0.3% B16..8: 13.9% 1.2% 0.7% direct: 4.0% skip: 7.0% L0:46.1% L1:36.4% BI:17.4%
x264 [info]: 8x8 transform intra:90.8% inter:23.4%
x264 [info]: coded y,uvDC,uvAC intra: 99.1% 17.5% 17.0% inter: 76.5% 53.2% 47.4%
x264 [info]: i16 v,h,dc,p: 9% 2% 81% 8%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 4% 1% 90% 1% 1% 1% 1% 1% 1%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 26% 4% 47% 5% 4% 4% 3% 4% 2%
x264 [info]: Weighted P-Frames: Y:1.5%
x264 [info]: ref P L0: 66.9% 19.3% 3.8% 10.1%
x264 [info]: ref B L0: 78.6% 21.4%
x264 [info]: kb/s:43052.20
encoded 166 frames, 4.49 fps, 43052.19 kb/s


I sucesfully muxed with scenarist, but after that i use Sony Verifier and i get this:

Error N.A. BDMV/STREAM/AU[12] 9.5.1.3.1 Equation C-15 of ITU-T Rec. H.264 | ISO/IEC 14496-10 standard is not satisfied
Error N.A. BDMV/STREAM/AU[35] 9.5.1.3.1 Equation C-15 of ITU-T Rec. H.264 | ISO/IEC 14496-10 standard is not satisfied
Error N.A. BDMV/STREAM/AU[59] 9.5.1.3.1 Equation C-15 of ITU-T Rec. H.264 | ISO/IEC 14496-10 standard is not satisfied
Error N.A. BDMV/STREAM/AU[83] 9.5.1.3.1 Equation C-15 of ITU-T Rec. H.264 | ISO/IEC 14496-10 standard is not satisfied
Error N.A. BDMV/STREAM/AU[131] 9.5.1.3.1 Equation C-15 of ITU-T Rec. H.264 | ISO/IEC 14496-10 standard is not satisfied
Error N.A. BDMV/STREAM/AU[155] 9.5.1.3.1 Equation C-15 of ITU-T Rec. H.264 | ISO/IEC 14496-10 standard is not satisfied

Interesting that is all of this fails are most on black video (scorlling credits) some dark scene.

[Dark Shikari]

I found new moment, i use mp3dom sample which fail muxing. I just reencode it with



I use maximum possible settings to try reproduce, here is x264.log which clearly not show any underflowBut where is the actual file so I can look at it?

[shon3i]

Sorry, here you go

*link removed during copyright law

[kieranrk]

Ok, this has been replicated and will be fixed soon.

[jpsdr]

Problem on the muxing on Scenarist occored after a 'long time'. Very high possibility it was also on the scrolling credit (white text on black background) on the end of the file.
Edit : If you want, you can send me a beta release version to test the fix.

[kolak]

I found new moment, i use mp3dom sample which fail muxing. I just reencode it with



I use maximum possible settings to try reproduce, here is x264.log which clearly not show any underflow

y4m [info]: 1920x1080p 1:1 @ 24000/1001 fps (cfr)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast FastShuffle SSEMisalign LZCNT
x264 [info]: profile High, level 4.1
[0.6%] 1/166 frames, 1.00 fps, 1.#J kb/s, eta 0:02:45
[93.4%] 155/166 frames, 4.43 fps, 43265.01 kb/s, eta 0:00:02
C:\Users\shon3i\Desktop\AoDc1\New folder\test.avs: 1920x1080, 24000/1001 fps, 166 frames
[94.0%] 156/166 frames, 4.46 fps, 43202.91 kb/s, eta 0:00:02
[100.0%] 166/166 frames, 4.49 fps, 43313.12 kb/s, eta 0:00:00

x264 [info]: frame I:9 Avg QP: 5.81 size:230891
x264 [info]: frame P:131 Avg QP: 5.94 size:234346
x264 [info]: frame B:26 Avg QP: 6.42 size:172390
x264 [info]: consecutive B-frames: 66.9% 33.1% 0.0% 0.0%
x264 [info]: mb I I16..4: 15.2% 76.5% 8.4%
x264 [info]: mb P I16..4: 2.4% 69.3% 1.6% P16..4: 9.1% 8.8% 8.5% 0.0% 0.0% skip: 0.3%
x264 [info]: mb B I16..4: 15.7% 57.3% 0.3% B16..8: 13.9% 1.2% 0.7% direct: 4.0% skip: 7.0% L0:46.1% L1:36.4% BI:17.4%
x264 [info]: 8x8 transform intra:90.8% inter:23.4%
x264 [info]: coded y,uvDC,uvAC intra: 99.1% 17.5% 17.0% inter: 76.5% 53.2% 47.4%
x264 [info]: i16 v,h,dc,p: 9% 2% 81% 8%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 4% 1% 90% 1% 1% 1% 1% 1% 1%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 26% 4% 47% 5% 4% 4% 3% 4% 2%
x264 [info]: Weighted P-Frames: Y:1.5%
x264 [info]: ref P L0: 66.9% 19.3% 3.8% 10.1%
x264 [info]: ref B L0: 78.6% 21.4%
x264 [info]: kb/s:43052.20
encoded 166 frames, 4.49 fps, 43052.19 kb/s


I sucesfully muxed with scenarist, but after that i use Sony Verifier and i get this:



Interesting that is all of this fails are most on black video (scorlling credits) some dark scene.


You have 43052.19 kb/s bitrate!
It's above BD 40Mbit limit.
As I said - don't ever use 40Mbit as maximum- definatelly not as average.

You have 40Mbit average and 40Mbit maximum- this is definatelly going to cause a problem becuse it's very difficult to achive for encoder. In your case you end up with 43Mbit average!

This is encoding for hardare players not for playing in sotware players- bit different rules apply.

[Dark Shikari]

You have 43052.19 kb/s bitrate!
It's above BD 40Mbit limit.
As I said - don't ever use 40Mbit as maximum- definatelly not as average.

You have 40Mbit average and 40Mbit maximum- this is definatelly going to cause a problem becuse it's very difficult to achive for encoder. In your case you end up with 43Mbit average!You have not a clue what you are talking about. The average is 43mbit because that doesn't include the time spent filling the VBV at the start of playback.

The stream x264 outputted was, VBV-wise, completely legal. The issue is one of invalid HRD parameters, not VBV compliance.

[kolak]

You have not a clue what you are talking about. The average is 43mbit because that doesn't include the time spent filling the VBV at the start of playback.

The stream x264 outputted was, VBV-wise, completely legal. The issue is one of invalid HRD parameters, not VBV compliance.

I don't, but see numbers, which are very close to limits, so advising not to use them for BD encodes.
Is 40mbit average and 40mbit max difficult for encoder? Some of the encoders advise to use at least 20% difference between avg and max to avoid buffer problems.

9.5.1.3.1 in BD spec describes main restriction for AVC, size, ref frames, CPB, MinRC, macrcoblocks and rows.

[kieranrk]

shon3i: Can you test with CBR? As far as I know CBR is spot on with regards to HRD parameters.

[shon3i]

shon3i: Can you test with CBR? As far as I know CBR is spot on with regards to HRD parameters.
It's same but is not C-15 its C-16 equation ;P

Error N.A. BDMV/STREAM/AU[12] 9.5.1.3.1 Equation C-16 of ITU-T Rec. H.264 | ISO/IEC 14496-10 standard is not satisfied
Error N.A. BDMV/STREAM/AU[35] 9.5.1.3.1 Equation C-16 of ITU-T Rec. H.264 | ISO/IEC 14496-10 standard is not satisfied
Error N.A. BDMV/STREAM/AU[59] 9.5.1.3.1 Equation C-16 of ITU-T Rec. H.264 | ISO/IEC 14496-10 standard is not satisfied
Error N.A. BDMV/STREAM/AU[83] 9.5.1.3.1 Equation C-16 of ITU-T Rec. H.264 | ISO/IEC 14496-10 standard is not satisfied
Error N.A. BDMV/STREAM/AU[107] 9.5.1.3.1 Equation C-16 of ITU-T Rec. H.264 | ISO/IEC 14496-10 standard is not satisfied

I send you clip on pm.

[jpsdr]

Good to see solution is on his way. Just to say also that lowering qcomp to 0.5 doesn't do the trick this time, but it wasn't the solution nevertheless, we know...

[Sagittaire]

I don't, but see numbers, which are very close to limits, so advising not to use them for BD encodes.
Is 40mbit average and 40mbit max difficult for encoder? Some of the encoders advise to use at least 20% difference between avg and max to avoid buffer problems.

9.5.1.3.1 in BD spec describes main restriction for AVC, size, ref frames, CPB, MinRC, macrcoblocks and rows.

Not for strict compliance.

Anyway choose lower bitrate than max bitrate is better for quality because the buffer will be empty and more usefull for high complexity part.

[Sagittaire]

--preset slow --pass 1 --bitrate 19000 --stats "stats" --deblock -4:-4 --profile high --level 4.1 --tune film --bframes 3 --ref 4 --slices 4 --aud --nal-hrd vbr --b-pyramid strict --keyint 24 --min-keyint 2 --vbv-bufsize 30000 --vbv-maxrate 36000 --sar 1:1

Not very good profil for very high bitrate.

--deblock -4:-4 inloop is adaptative. -2:-2 to 0:0 is the best interval quality in all case. If you you want more grain retention it's really better to use SSD with psy command.

--tune film at low quantizer it's IMO better to use --aq-mode 1 --psy-rd 1.0:0.0

and for frame quality flicking you must use --ipratio 1.1 --pbratio 1.1

for better constant quality I use --qcomp 0.75

or --tune grain if you prefer short command

[Sagittaire]

Idealy for BD compressionist there are other usefull command line:

- Chapter Point: fixe Iframe time for perfect chapter selection. Frame must be IDR and GOP closed.

- Choose IDR interval.

- Choose Open or Close GOP. With really short GOP like 1 sec Iframe could be in no scene cut part and PbBbIbBbP is by far more efficient than PbbPIbBbP sequence.

[sneaker_ger]

Idealy for BD compressionist there are other usefull command line:

- Chapter Point: fixe Iframe time for perfect chapter selection. Frame must be IDR and GOP closed.
No? The GOP seeked to just shouldn't reference the old GOP. Shouldn't that be sufficient?

- Choose IDR interval.
Again: Why IDR?

Or am I confusing things here? :confused:

[poisondeathray]

and for frame quality flicking you must use --ipratio 1.1 --pbratio 1.1


sharc pointed out in another thread (and DS confirmed) that pbratio is disabled when mbtree is used

http://forum.doom9.org/showpost.php?p=1382869&postcount=6

[Sagittaire]

sharc pointed out in another thread (and DS confirmed) that pbratio is disabled when mbtree is used

http://forum.doom9.org/showpost.php?p=1382869&postcount=6

then desactive mbtree because encoding without frame quality flicking is really important for compressionist ...

[poisondeathray]

then desactive mbtree because encoding without frame quality flicking is really important for compressionist ...

I would argue flicker free is important for everyone, but some sources are more subject to perceived flickering than others

But I disable it for other reasons (fades)

[Dark Shikari]

then desactive mbtree because encoding without frame quality flicking is really important for compressionist ...How does "pbratio is disabled" have any relation to "quality flicking"?

You don't even know how MB-tree works and you've implicitly assumed that it causes "quality flicking" without even trying it. Furthermore, MB-tree's strength is already affected by qcomp, which you have already raised manually (thus weakening MB-tree).But I disable it for other reasons (fades)MB-tree does fade analysis and intentionally raises quality in fades. Are you disabling it in order to make fades look worse?Idealy for BD compressionist there are other usefull command line:

- Chapter Point: fixed Iframe time for perfect chapter selection. Frame must be IDR and GOP closed.x264 already supports this.

[poisondeathray]

MB-tree does fade analysis and intentionally raises quality in fades. Are you disabling it in order to make fades look worse?

Do you mean weightp or has something changed recently?

And even if you mean weightp , wasn't it recommended to disable it for blu-ray? because of issues with some chips? i.e. the changelog for entry r1480

Early testing showed it significantly worse fades when mbtree was on, even with weightp, but of course you already knew that

[Dark Shikari]

Do you mean weightp or has something changed recently?

And even if you mean weightp , wasn't it recommended to disable it for blu-ray? because of issues with some chips? i.e. the changelog for entry r1480

Early testing showed it significantly worse fades when mbtree was on, even with weightp, but of course you already knew thatIf weightp is off, MB-tree actively works to lowers the quantizer in fades. If you think it's too weak, it's a one-line change to increase the strength of the effect.

[kolak]

then desactive mbtree because encoding without frame quality flicking is really important for compressionist ...

It does not flicker, but I frames are much better than others- with pro encoders difference is smaller (P and B are better quality compared to x264).
x264 uses by default flat matrix- as far as I know it's not very good for small bitrates and grainy source, is it?
Blu-code has predefined matrixes for different source types and this is very strong point of it.

[Atak_Snajpera]

x264 does not need matrixes because it has mb-tree,PSY-RDO,Adaptive Quantization and presets (film,grain and so on)

[Dark Shikari]

It does not flicker, but I frames are much better than othersThen lower --ipratio. x264's psy model tuning actually should make P-frames better than I-frames, all else being equal.x264 does not need matrixes because it has mb-tree,PSY-RDO,Adaptive Quantization.Just because these features are good doesn't mean CQMs are useless.

[kolak]

x264 does not need matrixes because it has mb-tree,PSY-RDO,Adaptive Quantization and presets (film,grain and so on)

Other encoders have the same, but it looks like specific matrixes are still very useful.

[poisondeathray]

If weightp is off, MB-tree actively works to lowers the quantizer in fades. If you think it's too weak, it's a one-line change to increase the strength of the effect.

Just to clarify, do you mean adjusting qcomp?

And what direction does it work in? higher qcomp value weakens mb-tree, but how does that effect mb-tree's effect of lowering the quantizer in fades if weightp is off?

And is it only pbratio that is disabled with mbtree? ipratio adjustment works?

Many of these tidbits and inner workings aren't listed in the mediawiki and oblivous to people who haven't looked at the code (or don't understand it)

Thanks for explaning

[Dark Shikari]

Just to clarify, do you mean adjusting qcomp?

And what direction does it work in? higher qcomp value weakens mb-tree, but how does that effect mb-tree's effect of lowering the quantizer in fades if weightp is off?It weakens MB-tree (lowering quantizer in fades) but also weakens MB-tree's fade compensation (raising quantizer in fades). It should be mostly a wash.And is it only pbratio that is disabled with mbtree? ipratio adjustment works?Yes.
Many of these tidbits and inner workings aren't listed in the mediawiki and oblivous to people who haven't looked at the code (or don't understand it)

Thanks for explaningIf you want to play with things, find weightdelta in encoder/slicetype.c and try making it bigger. Like, multiply it by 2 or something.

[kolak]

Then lower --ipratio. x264's psy model tuning actually should make P-frames better than I-frames, all else being equal.Just because these features are good doesn't mean CQMs are useless.

Not sure why, but I have much better results with x264.
I use slow first pass, longer sample source, highier deblocking, tune grain and for both passes very slow preset (it's very slow :)) P and B frames look much better. Need few more encodes with faster presets.
How much does fast first pass affect quality?

[Dark Shikari]

Not sure why, but I have much better results with x264.
I use slow first pass, longer sample source, highier deblocking, tune grain and for both passes very slow preset (it's very slow :)) P and B frames look much better. Need few more encodes with faster presets.
How much does fast first pass affect quality?Fast first pass has basically no consequence, especially on longer videos.

[deank]

I'll be glad if I can get any help with an issue I'm having. There is this small tool (hddvdmux) which I use to mux raw .264 into HD-DVD .EVO.

I'm having troubles when using the output from r1510 - for some reason hddvdmux won't process the raw files anymore. My tests showed it has to do with the NAL_HRD.

Here is a RAR (3MB) (http://multiavchd.deanbg.com/NAL_HRD_comparison.rar) which contains 2 raw .264 files. One is working, the other is not. Both are encoded with the same encoding options (as much as possible), one with r1510 the other with r1309. I know that the working one is encoded with rather old revision, but I think I tested most of the revisions (when x264.exe was ~1mb big :rolleyes: ) and it was ok. The older x264 is a nal-hrd/interlaced patched one and I'm using --aud --nal-hrd switches.

[WORKING].[NAL-HRD].[1920x1080-23.976].264 (1576KB)
Writing library : x264 core 78 r1309M 4d77de8
Encoding settings : cabac=1 / ref=2 / deblock=1:0:0 / analyse=0x3
:0x12 / me=dia / subme=2 / psy=1 / psy_rd=0.0:0.0 / mixed_ref=0 / me_range=16 /
chroma_me=1 / trellis=0 / 8x8dct=1 / cqm=0 / deadzone=21,11 / chroma_qp_offset=0
/ threads=2 / nr=0 / decimate=1 / mbaff=0 / constrained_intra=0 / bframes=2 / b
_pyramid=0 / b_adapt=1 / b_bias=0 / direct=1 / wpredb=1 / keyint=14 / keyint_min
=4 / scenecut=40 / rc_lookahead=14 / rc=cbr / mbtree=0 / bitrate=2000 / ratetol=
1.0 / qcomp=0.50 / qpmin=10 / qpmax=51 / qpstep=4 / vbv_maxrate=17000 / vbv_bufs
ize=17500 / ip_ratio=1.10 / pb_ratio=1.10 / aq=1:1.00

[NOT_WORKING].[NAL-HRD].[1920x1080-23.976].264 (1569KB)
Writing library : x264 core 92 r1510 33d382a
Encoding settings : cabac=1 / ref=2 / deblock=1:0:0 / analyse=0x3
:0x12 / me=hex / subme=2 / psy=1 / psy_rd=0.00:0.00 / mixed_ref=0 / me_range=16
/ chroma_me=1 / trellis=0 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / c
hroma_qp_offset=0 / threads=2 / sliced_threads=0 / nr=0 / decimate=1 / interlace
d=0 / constrained_intra=0 / bframes=2 / b_pyramid=0 / b_adapt=1 / b_bias=0 / dir
ect=1 / wpredb=1 / wpredp=0 / keyint=14 / keyint_min=4 / scenecut=40 / intra_ref
resh=0 / rc_lookahead=14 / rc=cbr / mbtree=0 / bitrate=2000 / ratetol=1.0 / qcom
p=0.50 / qpmin=10 / qpmax=51 / qpstep=4 / vbv_maxrate=17000 / vbv_bufsize=17500
/ ip_ratio=1.10 / pb_ratio=1.10 / aq=1:1.00 / nal_hrd=vbr

Dean

[Dark Shikari]

Your first encode doesn't even have NAL-HRD, so those definitely don't look the same to me...

[deank]

I think this old patched revision doesn't show the --nal-hrd switch in the meta, but it is used. I just encoded the file. I believe this is JEEB's build. (http://forum.doom9.org/showthread.php?p=1337890#post1337890)

[Dark Shikari]

I think this old patched revision doesn't show the --nal-hrd switch in the meta, but it is used. I just encoded the file.Can you post your actual commandlines then?

[deank]

r1309M:

-preset veryfast --bitrate 2000 --keyint 14 --level 4 --min-keyint 4 --bframes 2 --ref 2 --subme 2 --mvrange 511 --partitions p8x8,i8x8 --ipratio 1.1 --pbratio 1.1 --vbv-bufsize 17500 --vbv-maxrate 17000 --qcomp 0.5 --threads 2 --thread-input --aud --nal-hrd --sar 1:1 --rc-lookahead 14 --output "D:\_TEMP\multiTEMP-20100402\TM(2).[1920x1080-23.976].264" "C:\calcit\tools\20100402-132035-running.avs"


r1510:

-preset veryfast --bitrate 2000 --keyint 14 --level 4 --min-keyint 4 --bframes 2 --ref 2 --subme 2 --mvrange 511 --partitions p8x8,i8x8 --ipratio 1.1 --pbratio 1.1 --vbv-bufsize 17500 --vbv-maxrate 17000 --qcomp 0.5 --threads 2 --thread-input --aud --nal-hrd vbr --sar 1:1 --rc-lookahead 14 --b-pyramid none --slices 0 --weightp 0 --output "D:\_TEMP\multiTEMP-20100402\TM(3).[1920x1080-23.976].264" "C:\calcit\tools\20100402-132238-running.avs"

//

I think the difference is not with the switches but with the patch [x264_hrd_pd_interlace.16_r1301.diff] which is working. I'll have to find the latest x264 revision which works with this hddvdmux and report back.

[kolak]

Fast first pass has basically no consequence, especially on longer videos.

Maybe it was part of my problem- very short source file.
I'm getting very good results with x264 now- I wish someone made a GUI to make x264 more like finish product.

DS, how can I force I frames (for chapters)?
Can I segment re-encode?

Thx

[poisondeathray]

how can I force I frames (for chapters)?
Can I segment re-encode?



You could force I-frame with a qpfile

I don't think you can segment re-encode

[osgZach]

Sorry if this has been asked a million times by now..

But is the pulldown option in current spec supporting hardware devices? i.e would my WDTV Live recognize a pulldown flag in an H264 encode? And is this intended to be used for VFR sources? I.e Anime?
I've never encoded anything other than VFR MKV's so I know little about how pulldown works, etc.. What would be the process of encoding a file with pulldown? How do you specify where to flag pulldown scenes, etc?

If there is some kind of documentation someone could link to.. I might like to read that to see if its of any potential use for me.

Thanks.

[kolak]

Sorry if this has been asked a million times by now..

But is the pulldown option in current spec supporting hardware devices? i.e would my WDTV Live recognize a pulldown flag in an H264 encode? And is this intended to be used for VFR sources? I.e Anime?
I've never encoded anything other than VFR MKV's so I know little about how pulldown works, etc.. What would be the process of encoding a file with pulldown? How do you specify where to flag pulldown scenes, etc?

If there is some kind of documentation someone could link to.. I might like to read that to see if its of any potential use for me.

Thanks.

Use google to learn what pulldown actually means. You need basic understanding to move forward.

[osgZach]

Wow that was awesome, thanks

[Guest]

Sorry if this has been asked a million times by now.. "Sorry if...": one of those weak conditional apologies. :)

But is the pulldown option in current spec supporting hardware devices? i.e would my WDTV Live recognize a pulldown flag in an H264 encode? You mean do the devices support the spec? That would have to be tested on a per-device basis until practices become better established in the AVC world. In the set-top box (STB) world, I know that pulldown is honored properly per spec. I would be very surprised if your WDTV did not do things properly.

And is this intended to be used for VFR sources? I.e Anime? It has several possible applications. In addition to traditional pulldown, for example, you can easily take some 23.976 progressive material and do 3:2 *frame* pulldown on it to get it suitable for broadcast at (say) 1280x720@59.94 progressive.

What would be the process of encoding a file with pulldown? It could be done in the encoder (if it supports that) or you can set the flags with a tool applied to the compressed stream; for example, there is my DGAVCPulldown. I believe some versions of x264 can output 3:2 pulldown.

How do you specify where to flag pulldown scenes, etc? For VFR, I personally am not aware of any toolchains to accomplish that using AVC flagging. It could probably be done by applying irregular pulldown.

[osgZach]

Thanks neuron2, those were the answers I was looking for.

I'll have to check out DGAVC Pulldown. I haven't really used your AVC tools before.

[stax76]

--nal-hrd <string> Signal HRD information (requires vbv-bufsize)
- none, vbr, cbr (cbr not allowed in .mp4)

Does the help lack the default? Why is it a string and not a simple option without the need for quotes?

[Dark Shikari]

--nal-hrd <string> Signal HRD information (requires vbv-bufsize)
- none, vbr, cbr (cbr not allowed in .mp4)

Does the help lack the default? Why is it a string and not a simple option without the need for quotes?Whoever said it requires quotes?

[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,

[digitalvideo]

Hi Dark Shikari,

I can also help with authoring under scenarist if you need. I can also make any audio encoder and graph if you need.

Digitalvideo

[Emulgator]

Sony DVD-A 5.0b Build 180:

Tallship (first version) rejected, scheduled for transcoding as expected.
I removed Tallship.

Then straight project, 2 movies, BigBuckBunny and Elephant's Dream, no audio,
1 motion thumbnail menu, no menu audio (30s)

No transcoding scheduled.
Menu rendering went on, MUI generation went on,
(happy, I never came this far with something H-264 from outside Sony)

00001.m2ts seemed to mux properly
Then abort:

Dateiname: STREAM/00002.m2ts
Status: TSWrapper.dll::CTSWrapper::ProcThreadMain::Video buffer underflows. -

Continue to test.

[Emulgator]

bigbuckbunny alone, no audio:

Dateiname: STREAM/00001.m2ts
Status: TSWrapper.dll::CTSWrapper::ProcThreadMain::Video buffer underflows. -

[Emulgator]

Elephant's Dream alone without audio: Success !

Muxed to the end without transcoding.

DVD-A muxes only into .iso, so I mounted this using VirtualCloneDrive, playing from mounted .iso with PowerDVD7.3
Stuttery play (still have to find why, it worked smooth before with my own blu-ray compilations), but great picture quality.
Congratulations !

Edit: When stepping through the 00001.m2ts using VirtualDub and DGAVCDec, all frames are playable.
So I suspect PowerDVD and my CPU skipping some frames on decoding, although around 40% load.
More tomorrow...

[shon3i]

Status: TSWrapper.dll::CTSWrapper::ProcThreadMain::Video buffer underflows. - Wow, i will try with scenarist. Dark Shikari where i can find source of bigbuckbunny in one piece lossless? we can finaly reconstruct problem and probably find solution for this underflows.

[Dark Shikari]

Wow, i will try with scenarist. Dark Shikari where i can find source of bigbuckbunny in one piece lossless? we can finaly reconstruct problem and probably find solution for this underflows.I'm currently downloading http://blender-mirror.kino3d.org/peach/exr/ to re-encode Big Buck Bunny from 16-bit source (since 8-bit has banding up the ass).

The source I used was http://media.xiph.org/BBB/BBB-1080-png/.

[mp3dom]

Big Buck Bunny (the file on Dark Shikari's web space) + dts-HD MA mux without problem in Scenarist 5

[kolak]

Wow, i will try with scenarist. Dark Shikari where i can find source of bigbuckbunny in one piece lossless? we can finaly reconstruct problem and probably find solution for this underflows.

It was muxed fine in Scenarist, so not sure if there is real problem with this video.

[Emulgator]

Sonic/Roxio DVDitProHD 6.4 Build 641B03A:

All 3 clips (video only, no audio) scheduled for transcoding,
even in single movie project,
no matter if project is NTSC or PAL.
It does not look like there is something like a 24p/23.976p project expected.
Menu rendering can be set to 24.000/23.976fps,though, no success.

But this (DVDit) does not matter too much, I guess.
This piece was a PITA, no support, almost no fixes or updates and is abandoned anyway...

[Emulgator]

Adobe Encore CS3 Build 3.0.1.008:
No 24p projects. Blah.
http://forums.adobe.com/thread/421178?tstart=0

[Emulgator]

Ulead DVD-MF 6+ Build 6.00.0194.0:
Sees only MPEG-2 when to mux to HD-DVD.
Can not even import or read .avc, .264, .h264.

So it looks like Sony DVD-A is the way to go
for (almost) affordable Blu-ray authoring.

Let's hope that maintenance and updates may come in a bit more often than from competition...

[kolak]

Ulead DVD-MF 6+ Build 6.00.0194.0:
Sees only MPEG-2 when to mux to HD-DVD.
Can not even import or read .avc, .264, .h264.

So it looks like Sony DVD-A is the way to go
for (almost) affordable Blu-ray authoring.

Let's hope that maintenance and updates may come in a bit more often than from competition...

There is DVD MovieFactory Pro 7, which should work much better with BDs.

[Emulgator]

True, I picked this older version (MF6+) up intentionally because of its HD-DVD muxing capabilities,
and I thought I should have one before it is withdrawn. (40 USD only)
Good menu renderer by the way, played from HD-DVD folder to check if it would actually work.

[shon3i]

Big Buck Bunny (the file on Dark Shikari's web space) + dts-HD MA mux without problem in Scenarist 5

It was muxed fine in Scenarist, so not sure if there is real problem with this video.
Yes, same here even with LPCM audio. Duh, I guess I'll find some sample that i can send to Sonic Support for investigation

[Dark Shikari]

Here is (http://mirror05.x264.nl/Dark/intro.mkv) my short and simple intro for the Blu-ray disk (not the actual Blu-ray encode, obviously).

[MadMonkey57]

Here is (http://mirror05.x264.nl/Dark/intro.mkv) my short and simple intro for the Blu-ray disk (not the actual Blu-ray encode, obviously).

nice :)

Maybe it'd be a good idea to have 2 different versions of the Blu Ray Disc:

- typical Blu Ray (high video bitrate, DTS or HD audio, ...) e.g "--profile high --level 4.1 --vbv-maxrate 39000 --vbv-bufsize 30000 --b-pyramid strict --slices 4 ..." or similar
- AVCHD compatible version (i.e patched index.bdmv, lower video bitrate, AC3 audio, ...) ready to burn on red laser DVDs, e.g "--profile high --level 4.0 --vbv-maxrate 14000 --vbv-bufsize 14500 --b-pyramid none" or similar

[Dark Shikari]

Actually, that's a good point. I'd like to be able to burn this on a DVD and make it playable in Blu-ray players. What are the extra VBV restrictions required for this?

And what does b-pyramid none have to do with AVCHD?

[MadMonkey57]

If I'm not mistaken, "--b-pyramid none" has to do with level 4.0.

VBV restrictions have been "guessed best" by many people authoring AVCHDs. I used to use 15000 for both VBV settings and it was OK. But deank (author of multiAVCHD) came to the conclusion that "--vbv-maxrate 14000 --vbv-bufsize 14500" is more compatible (feedback from multiAVCHD users).
Other people would probably explain this much better than me, but I believe these VBV restrictions have to do with the limited amount of bits that can be provided by the optical reader to the decoding chip when reading DVDs.

[Fr4nz]

If I'm not mistaken, "--b-pyramid none" has to do with level 4.0.

VBV restrictions have been "guessed best" by many people authoring AVCHDs. I used to use 15000 for both VBV settings and it was OK. But deank (author of multiAVCHD) came to the conclusion that "--vbv-maxrate 14000 --vbv-bufsize 14500" is more compatible (feedback from multiAVCHD users).
Other people would probably explain this much better than me, but I believe these VBV restrictions have to do with the limited amount of bits that can be provided by the optical reader to the decoding chip when reading DVDs.

I've also found that 15000 is a good value for maxrate and bufsize when encoding for BD-5.

[shon3i]

Nothing more than 15000/15000 and level 4.0 are required for BD 5/9 backups/encodings. 14745 value is more common for AVCHD/BD5/BD9 and it's maximum buffer for HDDVD.

I suggest these settings for demo disc:

--level 4 --ref 4 --keyint 24 (48 since max rate is <= 15000) --min-keyint 1 --vbv-maxrate 14745 or 15000 --vbv-bufsize 14745 or 15000 --aud --nal-hrd vbr --sar 1:1 --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --b-pyramid strict --pic-struct

AVCHD version will just only have AC3 audio nothing more.

[MadMonkey57]

I know it's a little off-topic and the answer is probably elsewhere in the forum, but could you please explain --min-keyint 1 (my setting is always 2) and --pic-struct (unset in my own encodes).

Thanks

[mp3dom]

pic-struct is not strictly required for progressive contents but it's used by others pro encoders (personally I always use it for security reason)
min-keyint 1 allow two I frames to be adjacent (I-I-P-..). This 'could' be useful in some situations, maybe if the encoder is forced to put an I frame just before a scene change, so I-<scene change> I). Normally I think is quite difficult and even if it happens, the P frame could cover the scene change anyways. Personally I'm using min-keyint 2 too, just to avoid that continuous luma flashes (quite common in animation contents) could lead to continuos I frames thus lowering/reducing the quality of other frames (but I have red that x264 could recognize this kind of footage, anyway I don't think that the value of 1 or 2 could change the quality significantly)

[MadMonkey57]

pic-struct is not strictly required for progressive contents but it's used by others pro encoders (personally I always use it for security reason)
min-keyint 1 allow two I frames to be adjacent (I-I-P-..). This 'could' be useful in some situations, maybe if the encoder is forced to put an I frame just before a scene change, so I-<scene change> I). Normally I think is quite difficult and even if it happens, the P frame could cover the scene change anyways. Personally I'm using min-keyint 2 too, just to avoid that continuous luma flashes (quite common in animation contents) could lead to continuos I frames thus lowering/reducing the quality of other frames (but I have red that x264 could recognize this kind of footage, anyway I don't think that the value of 1 or 2 could change the quality significantly)
:thanks:

--level 4 --ref 4 --keyint 24 (48 since max rate is <= 15000) --min-keyint 1 --vbv-maxrate 14745 or 15000 --vbv-bufsize 14745 or 15000
--aud --nal-hrd vbr --sar 1:1 --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --b-pyramid strict --pic-struct

I'm wondering about adding "--bframes 3" as well. It's x264 default but changed depending on "--preset" and "--tune". Again, I'm not 100% sure, but I think it's required to be compliant. However, I don't know if --bframes 3 is implied by "--level 4"... (personally I always force --bframes 3 in my encodes).

[sneaker_ger]

"--level" does not change the number of bframes. (only number of ref frames)

[nixo]

This is probably dumb, but if --min-keyint 1 is allowed, what's the point of setting it at all?

--
Nikolaj

[deank]

I had some time today so I put all 3 movies in a Blu-ray disc compilation. Each video comes with DTS and DTS-HD (HR) audio (and Tallship with AC3, too).

http://multiAVCHD.deanbg.com/x264_demo_disc.jpg

http://multiAVCHD.deanbg.com/x264_demo_disc_2.jpg

http://multiAVCHD.deanbg.com/x264_demo_disc_3.jpg

http://multiAVCHD.deanbg.com/x264_demo_disc_4.jpg

Of course all done with multiAVCHD (which uses tsMuxeR). All works just fine in software players and Playstation 3.

+ the intro screen :)

The output is ~ 3.5GB but I can put it as a torrent download on my server for those who want to enjoy the quality of HD :)

[ChronoCross]

I would certainly participate in that download. I'm interested to see how this looks on my 52" connected to my PS3.

[shon3i]

This is probably dumb, but if --min-keyint 1 is allowed, what's the point of setting it at all?

--
Nikolaj
Default is 25, so if you set keyint to 24, you will probably get much i frames, and quality will drop.

[nixo]

Default is 25, so if you set keyint to 24, you will probably get much i frames, and quality will drop.

If I set keyint to 24 then keyint_min drops to 13. Also DS did not include it in his example in the commit message:
http://git.videolan.org/?p=x264.git;a=commit;h=c6de86497cdd7b7f3cce7d8a95d723c7d0c9f505

[shon3i]

If I set keyint to 24 then keyint_min drops to 13. Also DS did not include it in his example in the commit message:
http://git.videolan.org/?p=x264.git;a=commit;h=c6de86497cdd7b7f3cce7d8a95d723c7d0c9f505
But that is still to short GOP, 1-24 is not nothig much better but is probably better for overall quality. And if you use Long GOP (1-48) if you not set min_keyint, you will get short GOP then.

[Dark Shikari]

Min-keyint defaults fixed locally. It now defaults to "auto", which results in keyint_max / 10.

[deank]

I would certainly participate in that download. I'm interested to see how this looks on my 52" connected to my PS3.

Here we go...

Click to get the torrent file (http://multiavchd.deanbg.com/x264_demo_disc.torrent) (3.37GB).

If using with PS3 I'd suggest to transfer it to USB HDD and use AVCHDManager for 8.3 filenames. I'm not sure if these high bitrates will be okay if burning to DVD disc.

Dean

[Dark Shikari]

Awesome. Now I just have to finish downloading these EXR files and re-encode everything with DVD5 buffer sizes.

[C2D]

I'm downloading it as well, thanks mate! :)

[ChronoCross]

Here we go...

Click to get the torrent file (http://multiavchd.deanbg.com/x264_demo_disc.torrent) (3.37GB).

If using with PS3 I'd suggest to transfer it to USB HDD and use AVCHDManager for 8.3 filenames. I'm not sure if these high bitrates will be okay if burning to DVD disc.

Dean

Downloading. Should be interesting.

[Blue_MiSfit]

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

Sorry to take things slightly OT, but I was hoping somebody could chime in on XScaler and give me some more info about this? Kolak mentioned it.

~MiSfit

[MadMonkey57]

If using with PS3 I'd suggest to transfer it to USB HDD and use AVCHDManager for 8.3 filenames. I'm not sure if these high bitrates will be okay if burning to DVD disc.

Dean

Awesome. Now I just have to finish downloading these EXR files and re-encode everything with DVD5 buffer sizes.

DS: make sure to choose a reasonably low bitrate as well to ensure playback on DVD. This site (http://www.avchd-info.org/format/index.html) suggests 18 mbps for the overall system (video+audio+M2TS overhead +/- 7%) bitrate on DVDs. Mulitple audio streams generally work but are out of standard. Same for DTS audio streams, subtitles, and menu. Never tried with HD audio streams but they are also out of standard.

[Biggiesized]

Sorry to take things slightly OT, but I was hoping somebody could chime in on XScaler and give me some more info about this? Kolak mentioned it.

~MiSfit
It's only one of the coolest scaling and dithering algorithm tools. Stacey Spears and Don Munsil wrote it many years ago and it was packaged into PSE as a pre-processing tool.

It accepts lots of input file formats and you can write the output file type in the Registry.

The results are quite amazing, but it comes with two costs:

1) It's really slow. Running Big Buck Bunny through it takes my computer hours and that movie is what, 10 minutes long?

2) The dithering process adds noise to the picture so that'll come at a much higher bit cost than simply rounding to a lower bit depth.

Send me a PM if you want to know more (so this thread can get less off-topic).

[Biggiesized]

DS, I know you can freely access the OpenEXR BBB files, but what are you using for Elephants Dream? I asked Ton from Blender how to get the source files and he told me I'd have to ship him an external hard drive.

[Dark Shikari]

DS, I know you can freely access the OpenEXR BBB files, but what are you using for Elephants Dream? I asked Ton from Blender how to get the source files and he told me I'd have to ship him an external hard drive.I have no idea. They're not online anywhere? What I've read around seems to imply that they are.

If he needs an external drive, I can ship him one.

[Biggiesized]

I looked all over Xiph and other places for the OpenEXR sequence. They only host the 8-bit rounded PNG sequence.

[Biggiesized]

Blue_MiSfit, here is an example of the difference between dithering down using xScaler and rounding:

ROUNDING (like you find in the source PNG sequence)

http://img693.imageshack.us/img693/8716/edround.th.png (http://img693.imageshack.us/img693/8716/edround.png)

DITHERING (OpenEXR --> xScaler --> PNG)

http://img695.imageshack.us/img695/386/eddither.th.png (http://img695.imageshack.us/img695/386/eddither.png)

[Dark Shikari]

Blue_MiSfit, here is an example of the difference between dithering down using xScaler and rounding:

ROUNDING (like you find in the source PNG sequence)

http://img693.imageshack.us/img693/8716/edround.th.png (http://img693.imageshack.us/img693/8716/edround.png)

DITHERING (OpenEXR --> xScaler --> PNG)

http://img695.imageshack.us/img695/386/eddither.th.png (http://img695.imageshack.us/img695/386/eddither.png)Where did you get that EXR?

[kolak]

It's only one of the coolest scaling and dithering algorithm tools. Stacey Spears and Don Munsil wrote it many years ago and it was packaged into PSE as a pre-processing tool.

It accepts lots of input file formats and you can write the output file type in the Registry.

The results are quite amazing, but it comes with two costs:

1) It's really slow. Running Big Buck Bunny through it takes my computer hours and that movie is what, 10 minutes long?

2) The dithering process adds noise to the picture so that'll come at a much higher bit cost than simply rounding to a lower bit depth.

Send me a PM if you want to know more (so this thread can get less off-topic).

There is (was) one more amazing filter- one build into NexCode. It could not only convert 10 to 8 bit, but also remove existing banding from 8bit sources, with very good results.
You can speed up Xscaler on 8 core machine by splitting source file into 8 parts and running them seperately.

What about avisynth methods, eg GradFun2DBmod?

[MadMonkey57]

I happen to own Photomatix Pro (http://www.hdrsoft.com/index.html). Would it help ? (e.g batch tone mapping exr to 8 bit JPEG or 8/16 bit TIFF)

[Biggiesized]

Where did you get that EXR?

I didn't. Stacey Spears created that example in his video pre-processing thread on AVS Forum. I merely re-uploaded the images to imageshack so I didn't leech.

Contact Ton at the Blender Foundation about the ED source files.

There is (was) one more amazing filter- one build into NexCode. It could not only convert 10 to 8 bit, but also remove existing banding from 8bit sources, with very good results.
You can speed up Xscaler on 8 core machine by splitting source file into 8 parts and running them seperately.

What about avisynth methods, eg GradFun2DBmod?

The last build of PSE has a debanding filter for 8-bit sources. It works exceptionally well too.

[rack04]

Min-keyint defaults fixed locally. It now defaults to "auto", which results in keyint_max / 10.

So for Blu-ray compliance it is ok to leave this as default?

[shon3i]

So for Blu-ray compliance it is ok to leave this as default?
no you must set --keyint, and --min-keyint will be automaticly calculated, for example if you use 24, min will be 2. simple math :)

[Dark Shikari]

I've uploaded a new version of Elephant's Dream that's dithered properly and is suitable for use on a DVD5. Tallship is uploading as we speak.

[MadMonkey57]

URLs please ? (for info, i'm currently downloading BBB EXR files to dither through Photomatix Pro)

[shon3i]

URLs please ?
http://mirror05.x264.nl/Dark/bluray/

[MadMonkey57]

:thanks:

[deank]

I've uploaded a new version of Elephant's Dream that's dithered properly and is suitable for use on a DVD5. Tallship is uploading as we speak.

Tallship shows 349MB for the last hour. What is the actual size? I believe the last time I downloaded it might have not downloaded the complete one, because it stopped @ 3min 55sec and now I'd like to download it all :)

Dean

[Dark Shikari]

Tallship shows 349MB for the last hour. What is the actual size? I believe the last time I downloaded it might have not downloaded the complete one, because it stopped @ 3min 55sec and now I'd like to download it all :)

DeanIt's not fully uploaded yet. I'm not at my external drive, so I've paused the upload.

[MadMonkey57]

...(for info, i'm currently downloading BBB EXR files to dither through Photomatix Pro)...

<ot>nah... Taken separatelly, pictures are great, but played consecutively, there are really unpleasant changes in brightness... I was just wondering if this tool could help here but obviously it's not ment to handle movies...</ot>

[Dark Shikari]

You don't need the BBB EXR files. The PNG files are properly dithered.

It's the Elephant's Dream EXR files that would be nice to have, since the PNGs are broken.

[Dark Shikari]

The Blu-ray videos are now fully uploaded, along with the intro. Everything should be DVD5 compatible.

I look forward to the final demo Blu-ray!

[MadMonkey57]

You don't need the BBB EXR files. The PNG files are properly dithered.

It's the Elephant's Dream EXR files that would be nice to have, since the PNGs are broken.

I know, I was simply wondering if a professional photographer's software could further improve the dithering process.

...Everything should be DVD5 compatible...
I assume deank is going to author the BD5. I'll test it on my Panasonic BD35.

[deank]

Well, no one said anything about the previous one (although 40 people downloaded it), so I decided to create it again with the new videos. :rolleyes:

Torrent file (3GB) (http://multiavchd.deanbg.com/x264_demo/AVCHD_ready_x264_demo_disc.torrent)

This one has the intro on first playback, motion menu for all titles + motion video thumbs, simple pop-up menu for each title and a title-list menu.

Intro:
http://multiavchd.deanbg.com/x264_demo/x264_demo_intro.jpg

Title-list:
http://multiavchd.deanbg.com/x264_demo/x264_demo_titlelist.jpg

Main menu:
http://multiavchd.deanbg.com/x264_demo/x264_demo_t1_main.jpg

Main menu / Chapters:
http://multiavchd.deanbg.com/x264_demo/x264_demo_t1_chap.jpg

Main menu:
http://multiavchd.deanbg.com/x264_demo/x264_demo_t2_main.jpg

Main menu:
http://multiavchd.deanbg.com/x264_demo/x264_demo_t3_main.jpg

Main menu / Chapters:
http://multiavchd.deanbg.com/x264_demo/x264_demo_t3_chap.jpg

Main menu / Setup:
http://multiavchd.deanbg.com/x264_demo/x264_demo_t3_setup.jpg

Pop-up menu:
http://multiavchd.deanbg.com/x264_demo/x264_demo_popup.jpg

Dean

p.s. I don't know if it is good idea to have this 25fps Tallship, because some NTSC players may refuse to play it. Also its audio is short by ~1 min.

@MadMonkey: I don't think it will work in your Panasonic... multiAVCHD ver 4.0 motion menus are not supported there for some reason. Of course you can quickly re-author it. If you want just to test it without the movies, download the torrent and untick 00000.m2ts 00001.m2ts and 00003.m2ts. It will work in PS3, Sony, LG, Pioneer players...

[Dark Shikari]

p.s. I don't know if it is good idea to have this 25fps Tallship, because some NTSC players may refuse to play it. Also its audio is short by ~1 min.Wait, what, are you sure?

Does the audio match if it's 29.97fps instead of 25? If so, I probably got the framerate wrong; I can go re-encode.

[deank]

I don't know if it will match, but here is what I have...

Audio:
WAV, 5.1 channels, 0:05:44, 24 bits, 6912kbps, 48khz

Video:
Duration : 6mn 42s

[bob0r]

Dark has made a new intro, where the bottom black bar doesn't appear and grow bigger. He should upload that aswell.

Can you make the 3 video frame-titles clickable?

Also the words in the menu aren't clickable, you need to move your cursor infront of them.

[Dark Shikari]

Heh... it seems that once we get down to DVD buffer sizes and 29.97fps instead of 25, Tallship is actually too hard to encode! It's just such an insanely high detail source that it actually begins to fall apart at these bitrates.

Thoughts on maybe tempgaussMCing it?

Edit: Seems we can't do that either... Blu-ray requires interlaced for 29.97fps.

[G_M_C]

Heh... it seems that once we get down to DVD buffer sizes and 29.97fps instead of 25, Tallship is actually too hard to encode! It's just such an insanely high detail source that it actually begins to fall apart at these bitrates.

Thoughts on maybe tempgaussMCing it?

Edit: Seems we can't do that either... Blu-ray requires interlaced for 29.97fps.

Simplest way is to do a PAL->NTSC slowdown; If you find the different pitch of the audio acceptable that is :/

[G_M_C]

Heh... it seems that once we get down to DVD buffer sizes and 29.97fps instead of 25, Tallship is actually too hard to encode! It's just such an insanely high detail source that it actually begins to fall apart at these bitrates.

Thoughts on maybe tempgaussMCing it?

Edit: Seems we can't do that either... Blu-ray requires interlaced for 29.97fps.

Simplest way is to do a PAL->NTSC slowdown; If you find the different pitch of the audio acceptable.

(personally, as European, i dont mind 25 fps :p )

[Dark Shikari]

Simplest way is to do a PAL->NTSC slowdown; If you find the different pitch of the audio acceptable.

(personally, as European, i dont mind 25 fps :p )24->25 is a bit slower, 29.97->25 is a lot faster.

As a side note, we need a credits section of some sort. It should give credit to the makers of Big Buck Bunny, Elephant's Dream, and the audio sample I used in the intro (linkage (http://www.freesound.org/samplesViewSingle.php?id=60453)) according to their respective licenses. If you're not sure how to do this, just ask before posting yet another Blu-ray. Probably best not to get 17 different torrents going until we're sure that we're done.

[G_M_C]

24->25 is a bit slower, 29.97->25 is a lot faster.

Anyways, I've made my conclusion for now: for now, we'll just use BBB and ED. I've uploaded a new version of Intro.h264 to fix Jarod's issues.

A new Blu-ray with just these two and we should be good.

NB: we need a credits section of some sort. It should give credit to the makers of Big Buck Bunny, Elephant's Dream, and the audio sample I used in the intro (linkage (http://www.freesound.org/samplesViewSingle.php?id=60453)) according to their respective licenses. If you're not sure how to do this, just ask before posting yet another Blu-ray. Probably best not to get 17 different torrents going until we're sure that we're done.

Deanks screenshots say 25 fps ?
What was the original ? 29.97, with pulldown ?

[Dark Shikari]

Deanks screenshots say 25 fps ?
What was the original ? 29.97, with pulldown ?29.97, native interlaced. As I said about twice above, I screwed up the encode.

Hmm, we could instead try deinterlacing Tallship to 720p60. Maybe that would work better.

[Biggiesized]

I thought Tallship had video and film pulldown as the source.

[Dark Shikari]

I thought Tallship had video and film pulldown as the source.Ugh, hybrid content?! :confused:

[deank]

If you're not sure how to do this, just ask before posting yet another Blu-ray. Probably best not to get 17 different torrents going until we're sure that we're done.

Well, I'll remove both, not a big deal... It takes ~10mins to prepare one and I posted the links because you asked for it.

I'll wait for someone to post the final disc authored with a normal/trusted authoring tool.

[Dark Shikari]

Well, I'll remove both, not a big deal... It takes ~10mins to prepare one and I posted the links because you asked for it.Oh, no problem with that, it's fine to have one preview up--I just didn't want you to go through so much effort to make one. If it's only 10 minutes, no issue.
I'll wait for someone to post the final disc authored with a normal/trusted authoring tool.Why can't we use yours for the final version?

[deank]

You can of course... :rolleyes:

I'm working on a problem with some player compatibility issues (like Panasonic and Samsung) but I hope tomorrow I'll get all straightened out!

Just let me know when I can download the final videos + audios and I'll go for it :) It's a pleasure.

Dean

// edit: Plus, all the menus (motion or static) are encoded with the latest r1538 x264. Once you're ready I'll encode all with the version you suggest.

[deank]

Can you make the 3 video frame-titles clickable?

Also the words in the menu aren't clickable, you need to move your cursor infront of them.

I haven't heard of a Blu-ray disc player equipped with a mouse to allow you to click wherever you want. All you usually get is a remote control :) May be there are some players with mouse support (not talking software ones), but multiAVCHD output is for hardware players mostly (or software players and using the arrows < > ^ v)

[kieranrk]

You can of course... :rolleyes:

I'm working on a problem with some player compatibility issues (like Panasonic and Samsung) but I hope tomorrow I'll get all straightened out!


You should ask someone with Sony Verifier or the likes to check it because I'm not sure Tsmuxer will be BDAV-STD compliant.

[deank]

29.97, native interlaced. As I said about twice above, I screwed up the encode.

Hmm, we could instead try deinterlacing Tallship to 720p60. Maybe that would work better.

I can see you're uploading Tallship again... I'll give it a try when you say so.

Dean

[Dark Shikari]

I'll be done when the size reaches 500459024 bytes.

[Dark Shikari]

And it's done. Have fun!

[deank]

I was just starting with it when I noticed NINE ref frames for Tallship?

As far as I know the maximum is 6 (not according to the formula, but for blu-ray compliance)... Do I proceed?

[Dark Shikari]

I was just starting with it when I noticed NINE ref frames for Tallship?

As far as I know the maximum is 6 (not according to the formula, but for blu-ray compliance)... Do I proceed?Nine? Oops... my bad, it seems. I forgot that Blu-ray has more strict level restrictions than the H.264 spec.

Re-encoding.

[Dark Shikari]

New version uploaded.

[Biggiesized]

I thought 720p is 6 reference frames while 1080i is 4 reference frames.

[deank]

New version uploaded.

You said something about 'credits' or some outro video. Are you planning on something? I have all videos+audios now, so I can create a test disc with multiAVCHD.

Dean

[Dark Shikari]

You said something about 'credits' or some outro video. Are you planning on something? I have all videos+audios now, so I can create a test disc with multiAVCHD.

DeanFor credits I just meant some section that gives basic information about the sources of the videos; can be part of the menus, doesn't really have to be a video.

[Emulgator]

Sony DVD-A 5.0b Build 180:

BigBuckBunny 1920x1080x24.000p
(2nd DS version from 2010 04 16):

x264 core93 r1538+1 d1d3d31

MediaInfo: L4.0, 3 ReFrames, x264 embedded CL: ref=4

Success this time !

Muxed without transcoding.
(Simplest project: No menu, no audio.)

[Emulgator]

Sony DVD-A 5.0b Build 180:

Tallship 1280x720x59.94p
(3nd DS version from 2010 04 17):

x264 core93 r1538+1 d1d3d31

MediaInfo: L4.0, 5 ReFrames, x264 embedded CL: ref=6

And another success !

Muxed without transcoding.
(Simplest project: No menu, no audio.)

[Emulgator]

Sony DVD-A 5.0b Build 180:

Tallship 1280x720x59.94p
(2nd DS version from 2010 04 16):

x264 core93 r1538+1 d1d3d31

MediaInfo: L4.0, 8 ReFrames, x264 embedded CL: ref=9

Even this one: Success !

Muxed without transcoding.
(Simplest project: No menu, no audio.)

[deank]

This is the latest one with the proper Tallship video.

x264 demo (http://multiavchd.deanbg.com/x264_demo.torrent)

Just as the previous ones this one has all the stuff. I'm not much of a designer and I didn't add any pages for credits or something. It can be done at any time later with multiAVCHD with a quick reauthoring.


// Due to hard disc failure there is a single 512kb block that is not available for download (00002.m2ts). Click here and download 00002.m2ts (http://multiavchd.deanbg.com/00002.m2ts.torrent) only (your client will recheck the file and will download only 512kb).

[Dark Shikari]

So anyone here who could make an "actual" Blu-ray from this that we can post as the official one?

Or is the AVCHD version good enough? I don't think we can really call it a Blu-ray though, or can we?

[kieranrk]

So anyone here who could make an "actual" Blu-ray from this that we can post as the official one?


If nobody can offer Scenarist/Blu-print or the likes you could try Sony's DVD-Architect trial.

http://www.sonycreativesoftware.com/download/trials/dvdastudio

I would have tried myself but from past experience anything that I try involving an artistic eye will fail miserably. (Having said that I'll quite happily criticise anything artistic until the cows come home...)

[kolak]

So anyone here who could make an "actual" Blu-ray from this that we can post as the official one?

Or is the AVCHD version good enough? I don't think we can really call it a Blu-ray though, or can we?

I'll ask my colleague again- last time he said that he can do it.
I assume we have all assets ready now, yes?

[Dark Shikari]

I'll ask my colleague again- last time he said that he can do it.
I assume we have all assets ready now, yes?Yup, seems that we do.

[kolak]

Yup, seems that we do.

All BD compliant?
I will ask tomorrow.

[shon3i]

you could try Sony's DVD-Architect trialSony's DVD-Architect uses little older muxing engine than Scenarist/Blu-Print, and have big problems with B-pyramid streams, and display wrong picture order, so playback will be jerky. Only condition is stream without pyramids. And it's realy easy to author. If you want make a template with trial and send me i can mux with registred version.

With Scenarist/Blu-Print, to create simple menu you need much more knowlege, photoshop etc.

[kolak]

We will do it, but I can't promise any date. It should be in next few days, but don't want to promise :)

[bob0r]

This is the latest one with the proper Tallship video.

x264 demo (http://multiavchd.deanbg.com/x264_demo.torrent)

Just as the previous ones this one has all the stuff. I'm not much of a designer and I didn't add any pages for credits or something. It can be done at any time later with multiAVCHD with a quick reauthoring.


// Due to hard disc failure there is a single 512kb block that is not available for download (00002.m2ts). Click here and download 00002.m2ts (http://multiavchd.deanbg.com/00002.m2ts.torrent) only (your client will recheck the file and will download only 512kb).

Your 512kb block torrent is 100% already.
So nothing is downloaded.
Old torrent still at 99.9%

[Dark Shikari]

Also I don't think only one block is corrupt: I played through Tallship and had at least 3 different errors in different parts of the video (all lost frames).

[Emulgator]

In 5 days I will be back and can start making a BD-R 25 from Sony DVD-A output.

[LoRd_MuldeR]

This is the latest one with the proper Tallship video.

x264 demo (http://multiavchd.deanbg.com/x264_demo.torrent)

Just as the previous ones this one has all the stuff. I'm not much of a designer and I didn't add any pages for credits or something. It can be done at any time later with multiAVCHD with a quick reauthoring.

Is the original (lossless) source of the "Tallship" sequence publicly available? If so, could anybody point me to it, please?

[nm]

Is the original (lossless) source of the "Tallship" sequence publicly available? If so, could anybody point me to it, please?

I have a copy here. Sent you a link in private message, but others are free to ask it too. I could set up a torrent later if needed.

[kieranrk]

I could set up a torrent later if needed.

That would be nice.

[rack04]

That would be nice.

That would be very nice. :thanks:

[mp3dom]

With latest release I still continue to have the warning "VBV parameters cannot be changed when NAL HRD is in use". What I'm doing is to use the 'zones' parameters to basically change the values of trellis and deblock. Nothing else regarding VBV values (set as BD specs). Thanks!

[SomeJoe]

I can confirm that Dark Shikari's posted versions of Big Buck Bunny, Elephant's Dream, and Tallship are accepted in Adobe Encore CS4 and show as "Don't Transcode", meaning that the H.264 streams are ready for authoring to BD as-is without the need for reencoding.

However, I was unable to actually make a BD from these files because of the following:

BBB and ED: Frame rate for those two files is 24.000, Adobe Encore requires 23.976 (24/1.001) and will not allow 24.000.
Tallship: No audio available at DS's site, so I didn't try it. Although, the frame rate is within Adobe Encore's capabilities (60/1.001).


I will try encoding one of my own HD files and test it in Encore.

[Dark Shikari]

I can confirm that Dark Shikari's posted versions of Big Buck Bunny, Elephant's Dream, and Tallship are accepted in Adobe Encore CS4 and show as "Don't Transcode", meaning that the H.264 streams are ready for authoring to BD as-is without the need for reencoding.

However, I was unable to actually make a BD from these files because of the following:

BBB and ED: Frame rate for those two files is 24.000, Adobe Encore requires 23.976 (24/1.001) and will not allow 24.000.
Tallship: No audio available at DS's site, so I didn't try it. Although, the frame rate is within Adobe Encore's capabilities (60/1.001).


I will try encoding one of my own HD files and test it in Encore.Tallship audio can be found here (http://cid-bee3c9ac9541c85b.skydrive.live.com/browse.aspx/.Public/LadyWashington).

[nm]

I could set up a torrent later if needed. That would be nice.

Here we go: http://video-test-sequences.hexagon.cc/torrents

Could someone that already has the files check that my copies match them? My MD5 checksums are:
TallShip_lag_YUY2_5.1.avi e95920a6eb89b0bcda723b896e77a007
TallShip_1080i_ATSC.ts ec7e0bc1cd86c4ed59850bfc7e9dab9b

[kieranrk]

BBB and ED: Frame rate for those two files is 24.000, Adobe Encore requires 23.976 (24/1.001) and will not allow 24.000.
Tallship: No audio available at DS's site, so I didn't try it. Although, the frame rate is within Adobe Encore's capabilities (60/1.001).

24/1 is definitely allowed so Encore needs fixing.

[SomeJoe]

24/1 is definitely allowed so Encore needs fixing.

Oh, there is no doubt that Encore needs fixing. The list of bugs I've found in Encore could fill many pages.

Yes, 24.000 is definitely allowed on BD, but Encore refuses to make a BD using that. I believe that all assets in the project have to match the base frame rate of the project settings. e.g. If you have told Encore that the project is a BD, H.264, 1920x1080 23.976p project, then all frame rates used in the project have to be NTSC-derived (23.976p, 29.97i, 59.94i). There appears to be no option to select 24.000 or PAL-derived (25.000, 50.000) frame rates.

I did successfully download the audio for Tallship, and I made a simple BD with just the Tallship video/audio ... no menu. This was successful with no reencode of the video.

However, the audio is longer than the video by just over 8 seconds (video is 5:35, audio is 5:43) according to the original files I downloaded. This is a ~2.4 % difference, which is not accountable for by using 0.1% slowdown (for NTSC) nor 4% speedup (for PAL).

As the audio is just music, there are no audible cues that I can use to tell if the audio slowly goes out of sync over the video, or just has silence tacked on to the end.

Nevertheless, the point was to see if the H.264 video was BD-compliant enough to allow no-transcoding authoring by Encore, and it has succeeded. Well done to all the x264 developers. :cool:

[Dark Shikari]

Hi dark,

your message box is fullfixed.

[Emulgator]

BD-RE from x264 r1538+1 authored in Sony DVD-A 5.0b Build 180:

Success !

All 3 movies (BBB,ED,TS) accepted without transcoding.
"x264" Intro, Still Menu for the three movies added, no chapters.
Audio encoded to 5.1 AC-3 (resp 2.0 AC-3 for Tallship)using WavtoAC3Enc (Aften)

Muxed flawlessly in DVD-A, less than 5 minutes.
Burnt from iso to Verbatim BD-RE25 in less than 4 minutes using ImgBurn 2.5.1.0.

Panasonic BD-50 sees this as BD-Video, reports 24p for the first two movies
and throws fluid pictures and sound.

ES Duration mismatches:

Elephant's Dream:
Video duration reported as 00:10:53:19
Audio duration reported as 00:10:58:02
No video/audio offset to be noticed.

Tallship:
Video duration reported as 00:05:35:15
Audio duration reported as 00:05:43:22
No video/audio offset to be noticed,
it is a music overdub only, no original sound recording.

All 3 encodes/muxes have one navigation issue in common.
FFWD is ok. REW tries to rewind for a brief moment, then skips to movie start.

[Dark Shikari]

The x264 Demo Blu-ray image is available in 3 parts (7z) at http://mirror05.x264.nl/Dark/bluray.

We need just a few more things:

1. Tests to see if it works on real players.
2. A place to host the final torrent and people to seed it!

[LoRd_MuldeR]

The x264 Demo Blu-ray image is available in 3 parts (7z) at http://mirror05.x264.nl/Dark/bluray.

Bandwidth Limit Exceeded :rolleyes:

2. A place to host the final torrent and people to seed it!

Maybe it could be added to Derf's collection at Xiph.org?
http://media.xiph.org/video/derf/

They already host a bunch of test sequences, some are up to ~5 GB in size...

[kemuri-_9]

grab the torrent from http://forum.doom9.org/showthread.php?t=154183

[shon3i]

As i read "Announcing the first free software Blu-ray encoder" i notice that

Do keep in mind that you have to export to raw H.264 (not MKV or MP4) or else the buffering information will be slightly incorrect.

I would ask, why buffering is different if different conatiner used. In previous HRD patched this not been problem, that's mean something alredy muxed with MKV, canno't be used for BD Authoring?

[Dark Shikari]

As i read "Announcing the first free software Blu-ray encoder" i notice that



I would ask, why buffering is different if different conatiner used. In previous HRD patched this not been problem, that's mean something alredy muxed with MKV, canno't be used for BD Authoring?Because in MKV/MP4, SPS/PPS aren't counted for buffering purposes (because they're global headers).

[Sharc]

What values have eventually been selected for the demo disk for buffer control ?

[shon3i]

vbv_maxrate=14745 / vbv_bufsize=14745

[Gser]

2. A place to host the final torrent and people to seed it!

Use Piratebay.

[LoRd_MuldeR]

Here we go: http://video-test-sequences.hexagon.cc/torrents

Okay, I got the "Tallship" sequence now. Thanks! Unfortunately I see that the lossless original footage is interlaced :rolleyes:

May I ask how that sequence was deinterlaced and resized to 720p for the x264 demo disc?

In my first attempts (using NNEDI2/NNEDI3 + Spline36Resize) some scenes looked significant worse than the x264 demo disc...

Use Piratebay.

Good joke. (You know that their tracker was forced to go offline, back in Nov 2009 ???)

[Dark Shikari]

Okay, I got the "Tallship" sequence now. Thanks! Unfortunately I see that the lossless original footage is interlaced :rolleyes:

May I ask how that sequence was deinterlaced and resized to create the x264 demo disc?

In my first attempts (using NNEDI2/NNEDI3 + Spline36Resize) some scenes looked significant worse than the x264 demo disc...TempgaussMC + spline36resize.

[LoRd_MuldeR]

TempgaussMC + spline36resize.

Thanks for the info :)

May I also ask which release of TempGaussMC you used (it seems there are several releases floating around) and which parameters you used?

:thanks:

[Dark Shikari]

Thanks for the info :)

May I also ask which release of TempGaussMC you used (it seems there are several releases floating around) and which parameters you used?

:thanks:
AssumeFPS(30000/1001)
AssumeTFF()
TempGaussMC_beta2(edimode="eedi2")

[jpsdr]

Where this TempGaussMC can be found ? I've trouble to get it.

[JEEB]

Where this TempGaussMC can be found ? I've trouble to get it.
Here (http://forum.doom9.org/showpost.php?p=1379638&postcount=4).

Have fun with it :3

Edit: Also, there's the MVT2 version (http://forum.doom9.org/showthread.php?p=1340412#post1340412).

[Audionut]

First hit on google leads to this thread.

http://forum.doom9.org/showthread.php?p=1378526#post1378526

[JEEB]

Oh yes, forgot about that thread as it's where it got officially released IIRC.

So I guess Didée never made a custom topic for it?

[jpsdr]

Thanks for the answers.
However, i thought it was only a de-interlacer, but apparently there is also noise removal, something i don't want...

[JEEB]

Thanks for the answers.
However, i thought it was only a de-interlacer, but apparently there is also noise removal, something i don't want...

It uses very slight denoising in order to get a better deinterlacing result. I think you can somewhat edit the strength of this given feature as well.

[nm]

Thanks for the answers.
However, i thought it was only a de-interlacer, but apparently there is also noise removal, something i don't want...

You can also bypass noise/grain, as Didée suggests here: http://forum.doom9.org/showthread.php?p=1324744#post1324744

[LoRd_MuldeR]

Just in case somebody is interested, here is the properly deinterlaced/bobbed 720p version of the "Tallship" sequence:

TallShip 720p60 lossless HuffYUV
http://video-test-sequences.hexagon.cc/torrents/70618-TallShip_720p60_lossless_HuffYUV

Video: 1280×720 @ 60fps
Format: lossless HuffYUV in AVI
Audio: None
Duration: 5 min 35 s

Size: 13.5 GB (14.588.695.700 bytes)
MD5 sum: 9f17425c3a1322503bfc2a590767c3c5

Author: Ben Waggoner, Copyright 2005 Microsoft Corporation
License: similar to CC Attribution (see end of the credits in video)

[kieranrk]

Just in case somebody is interested, here is the properly deinterlaced/bobbed 720p version of the "Tallship" sequence:


Explain what you mean by "properly"?

[LoRd_MuldeR]

Explain what you mean by "properly"?

http://forum.doom9.org/showpost.php?p=1394744&postcount=622

[kolak]

Just in case somebody is interested, here is the properly deinterlaced/bobbed 720p version of the "Tallship" sequence:

TallShip 720p60 lossless HuffYUV
http://video-test-sequences.hexagon.cc/torrents/70618-TallShip_720p60_lossless_HuffYUV

Video: 1280×720 @ 60fps
Format: lossless HuffYUV in AVI
Audio: None
Duration: 5 min 35 s

Size: 13.5 GB (14.588.695.700 bytes)
MD5 sum: 9f17425c3a1322503bfc2a590767c3c5

Author: Ben Waggoner, Copyright 2005 Microsoft Corporation
License: similar to CC Attribution (see end of the credits in video)

Cool- will test "my encoder" against DS' x264 encode :)

update: or maybe not if download speed is so low :(

[LoRd_MuldeR]

update: or maybe not if download speed is so low :(

Yes, my upstream is SLOW. And I cannot keep the machine running 24/7. Hopefully somebody with a faster connection can join after the initial seed...

[mariush]

Well I'm joining the fun and I'll try to seed it for a couple of weeks - if only I can get it from you cause i see 2 peers but no download from any of them. Mulder check your YM - maybe we can working something out.

[VincAlastor]

can someone explain following to me, please or show me a good thread with offical information, please?
i am a little bit confused, in many doom9 threads i gather information about x264 blu ray compliant settings, but now i am not sure any more. are the following settings compliant for 1080p/24? or 720p/24:

--pass 2 --bitrate 4000-8000 --stats ".stats" --deblock -1:-1 --b-adapt 2 --weightp 0 --rc-lookahead 48 --aq-strength 0.5 --me umh --direct auto --trellis 2 --psy-rd 1.0:0.25 --no-fast-pskip --profile high --level 4.1 --bframes 3 --ref 4 (6 for 720p/24?) --slices 4 --aud --nal-hrd vbr --b-pyramid strict --keyint 48 --min-keyint 2(i think 1 is better, but everyone set "2") --vbv-bufsize 30000 --vbv-maxrate 15000 --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --sar 1:1 --output "output" "input"

[mp3dom]

You can have max keyint every 2 seconds (48 for 24p) only if you stay below 15 Mbps for maxrate. Since you're setting a maxrate to 40 Mbps, your keyint is out of specs. Lower it to 24 (set 24 also to rc-lookahead or simply doesn't set it). Other settings, while in specs, are quite unbalanced for a BD. There's no way to have only a 4/8 Mbps average bitrate until you have very limited space above all the fact that you have plenty of space.

[LoRd_MuldeR]

Well I'm joining the fun and I'll try to seed it for a couple of weeks - if only I can get it from you cause i see 2 peers but no download from any of them. Mulder check your YM - maybe we can working something out.

Sorry, I'm not at home right now and my machine isn't running. Won't return until late this night...

But I can continue seeding tomorrow morning!

[Biggiesized]

I'm seeding the 1080i YUY2 version, but I only have about 35% done.

[LoRd_MuldeR]

Sorry, I'm not at home right now and my machine isn't running. Won't return until late this night...

But I can continue seeding tomorrow morning!

Should be up and running now...

[VincAlastor]

You can have max keyint every 2 seconds (48 for 24p) only if you stay below 15 Mbps for maxrate. Since you're setting a maxrate to 40 Mbps, your keyint is out of specs. Lower it to 24 (set 24 also to rc-lookahead or simply doesn't set it). Other settings, while in specs, are quite unbalanced for a BD. There's no way to have only a 4/8 Mbps average bitrate until you have very limited space above all the fact that you have plenty of space.

thanks i will set vbv-maxrate 15000. i am using strong denoising to compensate the bad compression results by the bd specs.

i want to set weightp 2, but i don't know how many player can't decode it correctly.... what do you mean?

[mp3dom]

The BDs are made for high bitrates. You can always use lower bitrates if you're happy by the output quality, but if you're not happy I prefer to raise the bitrate over strong denoising! BD, to me, doesn't strictly means "high definition" or "sharp images/detail" but "higher fidelity to the master". Regarding weightp, I think its use depends by what you need to do. If you need to replicate a lot of BD, it's probably better to not use it, otherwise you can use it (current players support it, the ps3 support it and the majority of software decoders support it). Also almost all pro-encoders allows to use explicit weightp so it's indeed a 'in-spec' feature.

[VincAlastor]

thank you very much, then i will set weightp again!