x264, HDDVD compliance and HRD info patch

[bond]

a guy called "Ian Caulfield" has posted a patch on the x264 maillist adding HRD info to x264 bitstreams and changing some other minor things, claiming that this makes the HDDVD authoring software Scenarist swallow the stream and therefore maybe HDDVD compliant?

check it out here:
http://lists.videolan.org/attachs/20070107/x264_hrd.patch

Hi,

I've attached a patch to add the ability to encode NAL HRD parameters into the
output bitstream, allowing the streams produced by x264 to be imported into
Scenarist HD. The patch changes three things:

- encode NAL HRD info in bitstream if b_nal_hrd is set
- move the version info SEI header after the SPS and PPS headers (required for
Scenarist to identify the stream as an H264 ES)
- fix a small bug in bitstream_write (on x86 a right shift of more than 32
bits actually shifts by the shift amount mod 32, rather than returning 0)

The cpb_initial_removal_delay calculation is currently a bit of a fudge - I
wasn't sure of the correct way to work out the value, but using the time it
will take to fill the VBV buffer to vbv_buffer_init at vbv_max_bitrate seems to
produce sane looking figures...

As this is my first patch for x264, I welcome any comments, even critical ones
:)

Thanks,
Ian

[hpn]

for those who can test it: build (http://x264.net/x264_rev616_HRD.7z)

[Sagittaire]

I will test that ...

[chadamir]

It's significantly smaller in size than the last build of x264 if that counts for anything. I'm firing it up now. There is no b_nal_hrd flag according to the build, is it just --nal-hrd?

[hpn]

the switch that should add NAL HRD parameters to bitstream is:
--nal-hrd
(Only visible through x264 --longhelp).

[bob0r]

@Sagittaire

And, are we soon able to encode all our x264 1080p encodes HD-DVD compatible? :D

[chadamir]

I ran it with --nal-hrd and it did not write the hrd or if it did it forgot to set the flag to say that it did so.

[chadamir]

@Sagittaire

And, are we soon able to encode all our x264 1080p encodes HD-DVD compatible? :D

They'll have to be reencoded most likely.

[Sagittaire]

Well it's a really better HDDVD compliant build but:
- Sequence End Code is not here (no fatal error)
- HRD is here but seem not work correctly (no fatal error)
- x264 stream is accepted but don't work correctly with scenarist and seem not compatible with the internal H264 decoder (no fatal error)

Anyway it's a really good work for a first patch: HDDVD's compliancy is really not far ... ;-)

[bond]

ok i can confirm that using --nal-hrd writes

- HRD:
nal_hrd_parameters_present_flag: 1
cpb_cnt_minus1: 0
bit_rate_scale: 0
cpb_size_scale: 2
bit_rate_value_minus1[0]: 7812
cpb_size_value_minus1[0]: 3124
cbr_flag[0]: 0
initial_cpb_removal_delay_length_minus1: 15
cpb_removal_delay_length_minus1: 8
dpb_output_delay_length_minus1: 0
time_offset_length: 0
vcl_hrd_parameters_present_flag: 0
low_delay_hrd_flag: 0- SEIs:
Nal length 16 start code 4 bytes
ref 0 type 6 SEI
payload_type: 0 buffering_period
payload_size: 5 0xbf 0x47 0x80 0x0 0x40
seq_parameter_set_id: 0
initial_cpb_removal_delay[0]: 32399
initial_cpb_removal_delay_offset[0]: 0
payload_type: 1 pic_timing
payload_size: 2 0x0 0x20
cpb_removal_delay: 0
dpb_output_delay: 0Nal length 9 start code 4 bytes
ref 0 type 6 SEI
payload_type: 1 pic_timing
payload_size: 2 0x1 0x20
cpb_removal_delay: 2
dpb_output_delay: 0commandline used was:
x264 --crf 40 --vbv-maxrate 500 --vbv-bufsize 200 --progress --nal-hrd -o raw.264 input.avs

[bond]

Sagittaire can you post your commandline used?

[Sagittaire]

Sagittaire can you post your commandline used?

Yes ...

x264.exe --keyint 15 --min-keyint 1 --vbv-maxrate 20000 --vbv-bufsize 14745 --nal-hrd --mvrange 512 --level 4.1 --bframe 2 --b-rdo --bime --weightb --ref 3 --mixed-refs --direct auto --deblock -1:-1 --crf 20 --qcomp 0.75 --ipratio 1.10 --pbratio 1.30 --partitions "all" --8x8dct --me "hex" --subme 6 --no-fast-pskip --no-dct-decimate --trellis 1 --aud --sar 1:1 --progress -o H264_6Mbps.264 Encodage-HD-25.avs

use keyint at 15 for 25 fps and keyint at 18 for 29.970 fps source
max bitrate can be 29400 and I don't know for max cbp (14745 work good)
use 512 max for mvrange (perhaps better to use 511)
level must be a 4.1 for 1080p/i source
max bframe at 2, can be adaptative
use 8x8dct for High Profil
max Pref at 4 and max Bref at 3 (ref must to set at 3 with x264)
use sar 1:1 for compatibility
use aud and nal-hrd for HDDVD stream compliancy

[Golgot13]

Well it's a really better HDDVD compliant build but:
- Sequence End Code is not here (no fatal error)
- HRD is here but seem not work correctly (no fatal error)
- x264 stream is accepted but don't work correctly with scenarist and seem not compatible with the internal H264 decoder (no fatal error)

Anyway it's a really good work for a first patch: HDDVD's compliancy is really not far ... ;-)

Hi all,

Sagitaire, you have got the Scenarist SCA ?

There are lot of professional softwares on the web, now.
I saw Ateme H264 offline encoder version 1.7.0.6 and 1.8.1.0.
This two, old, versions have some problems with HD DVD compliance.
(Same, with x264, problems of header but not same parameter).

I can't say nothing about VC1 (because my company receive a email of MS).
Nobody have the MS tool to test VC1 and say more about quality
or compliance with Scenarist SCA or Ulead/Memorytech software....


Golgot13

[lazyn00b]

After a lot of experimenting, these are the settings I was able to use successfully on a 1080p29.97 clip:

--bitrate 8000 --level 4.1 --keyint 15 --min-keyint 1 --ref 3 --mixed-refs --no-fast-pskip --bframes 2 --b-rdo --bime --weightb --filter -1,-1 --subme 6 --trellis 1 --analyse p8x8,b8x8,i4x4,i8x8 --8x8dct --vbv-bufsize 14745 --vbv-maxrate 16000 --threads 2 --thread-input --progress --no-psnr --no-ssim --output "H:\TEST\transformers_clip.264" "H:\TEST\transformers.avs" --sar 1:1 --aud --nal-hrd

The raw .264 was muxed with Scenarist 4 and then the resulting HDDVD_TS was played with PowerDVD 7.2 Ultra.

Two things I noticed: 3 is the maximum number of references and b-frame pyramid must be turned off, otherwise you get weird artifacts; also, multiple threads do not seem to work on this patched build of x264 for some reason.

[Yong]

...also, multiple threads do not seem to work on this patched build of x264 for some reason.
I could be wrong, but i think hpn didnt compiled this pathced x264 with pthreads enabled.

[ToS_Maverick]

Yes ...

x264.exe --keyint 15 --min-keyint 1 --vbv-maxrate 20000 --vbv-bufsize 14745 --nal-hrd --mvrange 512 --level 4.1 --bframe 2 --b-rdo --bime --weightb --ref 3 --mixed-refs --direct auto --deblock -1:-1 --crf 20 --qcomp 0.75 --ipratio 1.10 --pbratio 1.30 --partitions "all" --8x8dct --me "hex" --subme 6 --no-fast-pskip --no-dct-decimate --trellis 1 --aud --sar 1:1 --progress -o H264_6Mbps.264 Encodage-HD-25.avs

use keyint at 15 for 25 fps and keyint at 18 for 29.970 fps source
max bitrate can be 29400 and I don't know for max cbp (14745 work good)
use 512 max for mvrange (perhaps better to use 511)
level must be a 4.1 for 1080p/i source
max bframe at 2, can be adaptative
use 8x8dct for High Profil
max Pref at 4 and max Bref at 3 (ref must to set at 3 with x264)
use sar 1:1 for compatibility
use aud and nal-hrd for HDDVD stream compliancy

did CRF with VBV-Buffer work?

as i tested it, it was a bit buggy, don't know if it was finally fixed. here's the thread where i posted the problem:
http://forum.doom9.org/showthread.php?p=903556#post903556

[Sagittaire]

did CRF with VBV-Buffer work?

as i tested it, it was a bit buggy, don't know if it was finally fixed. here's the thread where i posted the problem:
http://forum.doom9.org/showthread.php?p=903556#post903556

I don't know if vbv work always very well in crf mode. But now we can test vbv compliancy with HRD ... ;-)

[chadamir]

yayyyyyyyyyyyyyyyyyyyyyyyyyy :) :) :) :)

Now we just need to figure out how to get it to do 480/576p.

[lazyn00b]

yayyyyyyyyyyyyyyyyyyyyyyyyyy :) :) :) :)

Now we just need to figure out how to get it to do 480/576p.

It works, but you have to make --sar 40:33 if your source is 16:9 at 720x480. --sar 32:27 will NOT work, unfortunately :(

Also, since x264 can not apply pulldown (yet?), you must use ChangeFPS(29.97) in your avisynth script if your source is 23.976 fps film.

[Sagittaire]

It works, but you have to make --sar 40:33 if your source is 16:9 at 720x480. --sar 32:27 will NOT work, unfortunately :(

Also, since x264 can not apply pulldown (yet?), you must use ChangeFPS(29.97) in your avisynth script if your source is 23.976 fps film.

1) changeFPS don't make pulldown 3:2 I think.
You must make telecine script with 23.976 fps source:

result=SeparateFields(result)
result=SelectEvery(result,8,0,1,0,3,2,5,4,5,6,7)
result=Weave(result)
return result

And make interlaced encoding with x264 ...

2) You can make PalSpeed convertion if tou want progressive encoding

3) Best way is to make progressive encoding at 23.976 fps and include pulldown 3:2 at playback: perhaps a futur patch ... ;-)

[lazyn00b]

1) changeFPS don't make pulldown 3:2 I think.


I'm pretty sure you are right. I think ChangeFPS() simply doubles some frames to make 23.976->29.970, not a real pulldown. It doesn't seem to matter, though - Scenarist doesn't complain and PowerDVD plays the progressive 29.97 fps just fine. I have no idea if this is OK with the official HD DVD spec, though...

On a related subject, I noticed that Mainconcept Encoder 2.1 also does not seem to do a proper 3:2 pulldown using flags when encoding 23.976 sources. Try it yourself, and count the frames from the output file - there are too many, and the playback time is stretched by ~20%! I hope Mainconcept will fix this.

[Sagittaire]

On a related subject, I noticed that Mainconcept Encoder 2.1 also does not seem to do a proper 3:2 pulldown using flags when encoding 23.976 sources. Try it yourself, and count the frames from the output file - there are too many, and the playback time is stretched by ~20%! I hope Mainconcept will fix this.


Be carefull you must use compatible H264 decoder.
H264 encoding (Mainconcept Encoder 2.1 with pulldown 3:2 at playback) seem work very well with HDDVD SAP.

[chadamir]

I thought that h264 doesn't have pulldown and only supports 29.97 real frames. By the way has anyone done a hardware test yet?

[vsv]

For already encoded 23,976 fps need add metadata 2:3 pulldown how it did MS PEP's tool for ES VC1 to be compliant with HD-DVD.

[chadamir]

OOh you have MS Pep? Lucky you! Want to be friends :)

[vsv]

OOh you have MS Pep? Lucky you! Want to be friends :)

I only have information from Ben Waggoner:)
This info already a few months on doom9 and avs forums.
Its a small tool for patching header.

[hpn]

I could be wrong, but i think hpn didnt compiled this pathced x264 with pthreads enabled.
Fixed, use the same link (built with pthreads-w32-2-8-0). I don't have a dual core and can't test if it works as expected, but hopefully it's ok.

[chadamir]

Hrmm I wonder if SD-dvd ifo can be converted to hd-dvd ifo.

[lazyn00b]

Fixed, use the same link (built with pthreads-w32-2-8-0). I don't have a dual core and can't test if it works as expected, but hopefully it's ok.

Hi, I can confirm that the new version works properly on my dual core Pentium D. Thank you for your efforts.

[lazyn00b]

BTW, does anybody know what it would take to add a "--pulldown" functionality to x264? This is the final obstacle to x264 becoming the perfect HD DVD encoder!

[Trahald]

there are flags in the slice part of the header that *possibly* address field dominance and picture order..and hopefully can be used to that end.. need to find a reference hddvd h264 video file that is 23.976 fps as a reference.

[akupenguin]

When encoding with pulldown, the video itself is progressive, so using the field order flags is wrong. And anyway it wouldn't help, nothing in the slice header can possibly turn 24 coded pictures into 30 displayed pictures.
Either your decoder does pulldown automatically when you play a 24p stream on a 30i crt, or you need to add pic_timing sei packets.
pic_timing really shouldn't matter, because it's just a hint "you might want to display this stream as 30i". But I guess some decoders aren't smart enough to activate pulldown without such a hint.

[Sagittaire]

When encoding with pulldown, the video itself is progressive, so using the field order flags is wrong. And anyway it wouldn't help, nothing in the slice header can possibly turn 24 coded pictures into 30 displayed pictures.
Either your decoder does pulldown automatically when you play a 24p stream on a 30i crt, or you need to add pic_timing sei packets.
pic_timing really shouldn't matter, because it's just a hint "you might want to display this stream as 30i". But I guess some decoders aren't smart enough to activate pulldown without such a hint.

Yes but Sonic Scenarist HD want these pulldown flags with progressive 23.976 fps source for example ...

[hpn]

Ian posted an updated version of the patch (http://www.via.ecp.fr/via/ml/x264-devel/2007-01/binRlJ78jLbDT.bin), here is a build (http://x264.net/x264_rev618_HRD.7z).

EDIT: the older 616 patch (build (http://x264.net/x264_rev616_HRD.7z)) is may be better as suggested by Trahald

[Trahald]

the patch is 'bad'. not really bad but one thing scenarist wants (may or may not be in the spec... but likely if scenarist is forcing it) is that the nal order be aud-sps-pps-sei-slice

ian states since it is unconfirmed that that order is needed in the spec, he undoes that part of the first patch. probably better would be another switch '--order_nals ' or something.. bond, could you suggest that to him?
my tool will reorder the nals back but its preferable to be able to do it outright.

he also changes the way long ue values are handled (lengths over 32 bits -- gave me some trouble too) .. this would have no impact on scenarist as the output is the same.

unless there are other changes he didnt mention, i would recommend sticking with the '616' patch

[SeeMoreDigital]

Does anybody know where we can obtain .EVO samples containing different "audio" and "video" formats?


Cheers

[desta]

You must make telecine script with 23.976 fps source:

result=SeparateFields(result)
result=SelectEvery(result,8,0,1,0,3,2,5,4,5,6,7)
result=Weave(result)
return result

And make interlaced encoding with x264 ...
But then the result wouldn't be 100% progressive(?), which these HD DVD are, even at 29.970fps. Sorry, I might be completely off the mark.

[akupenguin]

But then the result wouldn't be 100% progressive(?), which these HD DVD are, even at 29.970fps.
Right. That's why he gave as an alternative

3) Best way is to make progressive encoding at 23.976 fps and include pulldown 3:2 at playback

[Sagittaire]

Ian posted an updated version of the patch (http://www.via.ecp.fr/via/ml/x264-devel/2007-01/binRlJ78jLbDT.bin), here is a build (http://x264.net/x264_rev618_HRD.7z).

EDIT: the older 616 patch (build (http://x264.net/x264_rev616_HRD.7z)) is may be better as suggested by Trahald

Yes the new patch don't work now ... ;-(


3) Best way is to make progressive encoding at 23.976 fps and include pulldown 3:2 at playback

It's compliant with ISO 14496-10 ... ???
If yes perhaps a good idea for futur implementation.

[desta]

Right. That's why he gave as an alternative
Yeah, sorry, I overlooked that.

[bond]

akupenguin, any reason why not to place the userdata SEI after SPS and PPS by default?

[akupenguin]

1) Aesthetics. SPS-PPS-IDR is a keyframe (when using a format that stores SPS & PPS in-band). The SEI is global info not part of that frame.
2) Principle. I don't workaround bugs in other programs, even if it would be easy.

[Trahald]

When encoding with pulldown, the video itself is progressive, so using the field order flags is wrong. And anyway it wouldn't help, nothing in the slice header can possibly turn 24 coded pictures into 30 displayed pictures.
Either your decoder does pulldown automatically when you play a 24p stream on a 30i crt, or you need to add pic_timing sei packets.
pic_timing really shouldn't matter, because it's just a hint "you might want to display this stream as 30i". But I guess some decoders aren't smart enough to activate pulldown without such a hint.

Since mpeg2 alternates field dominance and uses rff to pulldown, i assumed it would be the same/similar here. can you provide more info into using the pic_timing to that end? im looking at the data within one and not sure what would accomplish this.

[Trahald]

“ A sequence parameter set NAL Unit shall precede in syntax order all NAL Units that refer to that sequence parameter set unless the sequence parameter set NAL unit contains a duplicate copy of the previous parameter set RBSP with the same value of seq_parameter_set_id. The syntax order of these repeated sequence parameter set NAL Units, if present, shall precede the order of slices and data partitions of the primary coded picture as well as any SEI NAL Units and repeated picture parameter sets.”
http://209.85.165.104/search?q=cache:3M7YmS0yqiUJ:ftp3.itu.ch/av-arch/jvt-site/2003_03_Pattaya/JVT-G039.doc+nal+sequence+parameter+%22shall+precede%22&hl=en&gl=us&ct=clnk&cd=1&client=firefox-a

the buffering_period type sei refers to the same sps id (in all cases ive seen) which imo means it should follow the sps. at that point including hte type 5 user data being placed in the same sei nal seems logical avoiding multiple sei nals in the same sequence. sei type 1 also relies on data from the sps(hrd section). making it logical for it to follow the sps

[akupenguin]

Since mpeg2 alternates field dominance and uses rff to pulldown, i assumed it would be the same/similar here. can you provide more info into using the pic_timing to that end? im looking at the data within one and not sure what would accomplish this.
See H.264 (http://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-H.264-200503-I!!PDF-E&type=items) section D.2.2 table D-1.
If 4 consecutive pictures are coded progressively and have pic_struct values of TB,TBT,BT,BTB (table entries 3,5,4,6 respectively), that is a normal 3:2 pulldown.

at that point including the type 5 user data being placed in the same sei nal seems logical avoiding multiple sei nals in the same sequence.
I don't buy it being logical, but it is required.
"When an SEI NAL unit containing a buffering period SEI message is present, the buffering period SEI message shall be the first SEI message payload of the first SEI NAL unit in the access unit."

So the reordering of the x264 userdata SEI will be granted, as part of the patch to add buffering period SEI.

[Trahald]

After a lot of experimenting, these are the settings I was able to use successfully on a 1080p29.97 clip:

--bitrate 8000 --level 4.1 --keyint 15 --min-keyint 1 --ref 3 --mixed-refs --no-fast-pskip --bframes 2 --b-rdo --bime --weightb --filter -1,-1 --subme 6 --trellis 1 --analyse p8x8,b8x8,i4x4,i8x8 --8x8dct --vbv-bufsize 14745 --vbv-maxrate 16000 --threads 2 --thread-input --progress --no-psnr --no-ssim --output "H:\TEST\transformers_clip.264" "H:\TEST\transformers.avs" --sar 1:1 --aud --nal-hrd

The raw .264 was muxed with Scenarist 4 and then the resulting HDDVD_TS was played with PowerDVD 7.2 Ultra.

Two things I noticed: 3 is the maximum number of references and b-frame pyramid must be turned off, otherwise you get weird artifacts; also, multiple threads do not seem to work on this patched build of x264 for some reason.

does the thumbnail in scenarist show black for you for the h264 data file? or do you see the actual first frame . (to test you need video that doesnt start with a black frame) or even look at your track.. do the thumbnails at the chapter points show black? i cant really test the final output because powerdvd complains about my ancient video card.

[cakuhnen]

akupenguin maybe you can add the pulldown for 23.976 source? 3:2 and 2:3?

[blubberbirne]

Yes ...

x264.exe --keyint 15 --min-keyint 1 --vbv-maxrate 20000 --vbv-bufsize 14745 --nal-hrd --mvrange 512 --level 4.1 --bframe 2 --b-rdo --bime --weightb --ref 3 --mixed-refs --direct auto --deblock -1:-1 --crf 20 --qcomp 0.75 --ipratio 1.10 --pbratio 1.30 --partitions "all" --8x8dct --me "hex" --subme 6 --no-fast-pskip --no-dct-decimate --trellis 1 --aud --sar 1:1 --progress -o H264_6Mbps.264 Encodage-HD-25.avs



I test this settings, and my XBOX360 played the result without any Problems :D

[akupenguin]

@cakuhnen
No. And just for asking, I bumped it one notch farther down on my todo list. Got any other features you don't want implemented soon?

[bobololo]

@cakuhnen
No. And just for asking, I bumped it one notch farther down on my todo list. Got any other features you don't want implemented soon?

I'd like x264 to be better and faster :D