NAL HRD has been committed!

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

Originally Posted by Dark Shikari

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]

Originally Posted by kolak

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]

Originally Posted by 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.

Use google to learn what pulldown actually means. You need basic understanding to move forward.

[osgZach]

Wow that was awesome, thanks

[Guest]

Originally Posted by osgZach

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]

Originally Posted by 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?

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]

Originally Posted by stax76

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.

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!

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

Originally Posted by Dark Shikari

x264 build with (hopefully) HRD fixed.

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!

Here is the .264 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]

Originally Posted by deank

Here is the .264 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]

Originally Posted by deank

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.