NAL HRD has been committed!

[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?