x264 w/ 3:2 pulldown and hrd

[Sagittaire]

@ALL
Could you please check if this test master 1440x1080p (Max=9000,AVG=7500,Min=6000) (16:9) 25 fps PAL is running on current standalones (Toshiba,Xbox 360) it does in PowerDVD (Source Copyleft CruNcher 2007) :)
http://rapidshare.com/files/45817002/HVDVD_TS.rar

HDDVD PAL don't work on toshiba SAP but work on xbox addon.

[foxyshadis]

Work perhaps on your hda2 but I can play mpeg2 file with long gop (60) on my SAP and anyway long gop is not DVD compliant and don't work with all SAP.

Hate to distract, but which SAP and have you found out how long it'll accept? I'd prefer to get one that lets me break specs for better quality (esp since I'll have to use dvd-9 or even dvd-5 for a while).

[Trahald]

exact same problem here with the 720p stuff. also i found i get corrupted 1080p 29.97fps playback if using just x264 build.weird... in a few hours I'll going to put up a test version that eliminates some stuff that h264info doesnt carry over to see if that works better.

[quantum]

FYI: This is a detailed list of what I'm doing in case it will help troubleshoot:
http://forum.doom9.org/showthread.php?t=128409

[woah!]

Well not for HDDVD guru ...
http://forum.doom9.org/showthread.php?p=893337#post893337

Work perhaps on your hda2 but I can play mpeg2 file with long gop (60) on my SAP and anyway long gop is not DVD compliant and don't work with all SAP.

HDDVD guru from MS say that compliant buffer is 14745 Kbits for H264 and VC1. Professional encoder like Cinevision say that compliant buffer is 14745 Kbits for H264 and VC1. Moreover if your average bitrate is not close to your max bitrate (always the case for HDDVD9 authoring) then buffer influence on quality is potentialy not high. Large buffer is really important only if your average bitrate is close to your max bitrate.

lets be honest here, hecant tell us if that number is correct from the specs as he would probably be braking an NDA of sorts. also he isnt going to let the competition while in a test thread to help an edge with allowing a bigger size now is he. i heard different and havent had any issues. i agree with the second part about tho :)

[Trahald]

the test version is up... in h264info i standardize some of the length params. (sort of have to since i only do one pass) this x264 version does the same. also it does not write the command line text sei to mirror h264info.. there are a couple params i left alone, but they shouldn't matter.

[Trahald]

I found the issue. I only tested the patch with bframes =2 or less. (According to anything ive found 2 bframes are max for hddvd). Sagittaire is doing the test at 7 bframes so i started working on bframes up to 16 (actually just for the dppoutputdelay calc) but found hi b counts caused problems with cpb_removal_delay. so until fixed (hopefully today) only 2 or less will give proper cpb_removal_delay. I think that was the issue sagittaire was seeing.

[Trahald]

hrd_patch669h is up. fixes the > 2 b's problem with the patch. i'll put up a binary tomorrow

[Trahald]

x264_669h_pulldown.zip is up.. i compiled in mingw32 .. alot easier to do pthread and gpac there.. so binary has mp4/pthread/aq/pulldown in it.

[burfadel]

x264_669h_pulldown.zip is up.. i compiled in mingw32 .. alot easier to do pthread and gpac there.. so binary has mp4/pthread/aq/pulldown in it.

Hi,
I noticed there is a new AQ patch on Cef's site (although he doesn't have a new build up). Its rev 669 of the AQ patch (only the .diff file):

http://mirror05.x264.nl/Cef/?dir=./patches

Is this able to be included in a new build on your website? Thanks!

There is also this patch:
http://akuvian.org/src/x264/x264_aq_cssim.0.diff

And this patch helps with multiple cores (when using the thread queue option):
http://akuvian.org/src/x264/x264_thread_pool.03.diff

[Sharktooth]

the "new" aq patch is simply what was used in the 667b build.
no need to build r669 coz it is really identical to 667...

[burfadel]

the "new" aq patch is simply what was used in the 667b build.
no need to build r669 coz it is really identical to 667...

Ah ok! what about the thread pool patch and this one?:
http://akuvian.org/src/x264/x264_aq_cssim.0.diff

[Sharktooth]

the thread pool patch could be useful with multiple multicore CPUs (when a significative number of worker threads are being used). for what concerns the ssim aq i know absolutely nothing about it:)

[Trahald]

x264_thread_pool patch has fallen behind the revisions a bit. well.. specifically common.h is significantly changed. i'll put out a binary with aq_cssim and newest aq however.

[Trahald]

i put up a version x264_669h_2_pulldown .. it has those patches aq_simm and newest cefs aq.

[Sharktooth]

http://www.benswebs.com/x264_thread_pool.04a.r670.diff

[plane]

http://forum.doom9.org/showthread.php?p=928478#post928478

Can someone confirm the min. bitrate of HD-DVD? Is that really 2500?

[Trahald]

i havent found anything that says so. the spec isnt out, however the dvd-forum has a few basic docs out and they only mention maximums.

[akupenguin]

I am philosophically opposed to min bitrates, so x264 won't ever support them if I can help it.

[Trahald]

well.. Im hoping he is referring to a minimum avg which imho is up to the user (even when using 1-pass).

Having said that... While i suppose its possible the spec says 2500 kbps min avg . I wouldnt think any set top or even authoring software would have a problem with it (1000kbs scenarist hd compiles without complaint) . as long as the vbv buffer is kept in check, all is well.

[Sharktooth]

Trahald, in case you didnt notice, the threadpool patch (by morph166955) i linked in my previous post should apply correctly to the actual x264 revision.

[Trahald]

thank you.. actually i did see your post. just havent gotten around to patching it yet ...

[Trahald]

ok 669h_3 is up.. includes all aforementioned patches.

[DanielCardenas]

I am philosophically opposed to min bitrates, so x264 won't ever support them if I can help it.I'm thinking this means the minimum maximum or average bit rate. In other words if the content is lower than this bit rate then the hardware is not guaranteed to work. Is that what you understand it to mean? If so what is the problem with it?

[Sagittaire]

There are not min bitrate for HDDVD/BD profil.

[foxyshadis]

The only time buffer overflow could ever be a problem is if such an extreme overflow that the drive actually spins down, which takes 15-60 seconds, and can't spin back up in time. (Aside from completely using up the buffer in the time it takes to make one revolution, which would be pretty hard to do.) Normally it just slows down or speeds up to roughly match the reading needs.

[dattrax]

I've followed this thread and it doesn't seem to produce a valid file for use in the HD-E1. I've tested both 663f and 669 with exactly the same results. The video imports in SCA fine and authors OK, but on playback on the standalone there is bad corruption. The video is OK in mplayer, so I'm guessing that I have included some mode that is outside HD-DVD spec.

$ ./x264.exe --pass 1 --bitrate 14000 --stats "1.stats" --ratetol 6 --aq-strength 0.25 --aq-sensitivity 5 --keyint 12 --min-keyint 3 --nal-hrd --vbv-maxrate 29400 --vbv-bufsize 14811 --level 4.1 --bframe 2 --weightb --ref 3 --mixed-refs --deblock -2:-1 --qcomp 0.75 --ipratio 1.10 --pbratio 1.10 --partitions "p8x8,b8x8,i4x4,i8x8" --8x8dct --me hex --subme 5 --threads 1 --no-fast-pskip --aud --sar 4:3 --deadzone-intra 6 --deadzone-inter 6 --non-deterministic --progress --
output NUL "F:\HD Streams\bbchdTS-sample.avs"

I am just testing with bframes set to 0 atm. to see if this is the issue. I changed the partition set from all to p8x8,b8x8,i4x4,i8x8 as b4x4 is apparently not supported in level 4.1 profile.

Encodes from cinevision work fine, so the rest of my workflow is ok. I would like to replace cinevision with opensource.

Anyone else spot anything wrong which would not produce a dvd compatible file?


OK, so I've just checked cinevision and it is set for b4x4, so "all" should be OK. one thing is different and that is the number of reference pictures is 4, but that shouldn't make any difference. I've also noticed that the deblocking strength is -1:-1 so I'll test this also.



Jim

[Trahald]

whats the framerate and resolution of that file?

[dattrax]

23.976fps

When you watch on the standalone its as if the reference pictures are incorrect. The IDR frames are OK and then the motion breaks up from there.

Jim

[Trahald]

are you leaving --pulldown xx out when you pasted the command line here? also.. what resolution file is it?

[dattrax]

sorry, this is the first pass, the second has the --pulldown in it

$ ./x264.exe --pass 2 --bitrate 14000 --stats "1.stats" --aq-strength 0.25 --aq-sensitivity 5 --keyint 12 --min-keyint 3 --nal-hrd --pulldown 32 --vbv-maxrate 29400 --vbv-bufsize 14811 --level 4.1 --weightb --ref 4 --mixed-refs --deblock
-1:-1 --qcomp 0.75 --ipratio 1.10 --pbratio 1.10 --partitions "all" --8x8dct --me hex --subme 5 --mvrange 511 --threads auto --no-fast-pskip --aud --sar 4:3 --deadzone-intra 6 --deadzone-inter 6 --non-deterministic --progress --output bbc.h264 "F:\HD Streams\bbchdTS-sample.avs"

I did notice one issue by looking at the stream output, the --bframe 2 is adding another reference picture, so it thought it had 5 (HDDVD spec only supports 4). I am just trying a pass with this removed.

The source material is 1440x1080p at 16:9 which explains the SAR parameter.

Jim

[woah!]

try this:

x264.exe --pass 1 --crf 10 --stats "1.stats" --aq-strength 0.25 --aq-sensitivity 5 --keyint 14 --min-keyint 2 --vbv-maxrate 29400 --vbv-bufsize 14811 --level 4.1 -b 2 --weightb -r 3 --mixed-refs -f -2:-1 --qcomp 0 --ipratio 1.10 --pbratio 1.10 -A "all" --8x8dct --me hex -m 5 --threads 1 --no-fast-pskip --aud --sar 1:1 --deadzone-intra 6 --deadzone-inter 6 --progress -o NUL "F:\HD Streams\bbchdTS-sample.avs"

x264.exe --pass 2 -B 14000 --stats "1.stats" --aq-strength 0.25 --aq-sensitivity 5 --keyint 14 --min-keyint 2 --vbv-maxrate 29400 --vbv-bufsize 14811 --level 4.1 -b 2 --weightb -r 3 --mixed-refs -f -2:-1 --qcomp 0 --ipratio 1.10 --pbratio 1.10 -A "all" --8x8dct --me hex -m 5 --threads 1 --no-fast-pskip --aud --sar 1:1 --deadzone-intra 6 --deadzone-inter 6 --progress -o "" "F:\HD Streams\bbchdTS-sample.avs"


i still find using h264info to add the pulldown afterwards is more reliable for me.

[dattrax]

By doing it in two stages (not having --nal-hrd --pulldown 32 in the command line fixed it!)

I did make a slight alteration in that I clamped the MV to 511 (which is in the spec)

Other than that my sample works great in the player. I need to investigate what --nal-hrd --pulldown 32 does differently to using h264info.

Thanks for your help

Jim

[Trahald]

Other than that my sample works great in the player. I need to investigate what --nal-hrd --pulldown 32 does differently to using h264info.

Thanks for your help

Jim

weird considering i made h264info and the patch... hehe.. I'll look into it. i should have more time coming up as the usopen is over tomorrow.

[Trahald]

Ive found it. bs_rbsp_trailing() was missing from the origional hrd patch in relation to the buffer and pictiming sei. didnt notice when i added pulldown to it. my h264info app writes this so thats why running the .264 file through h264info seemed to fix the issue.

so fixed in next version. out maybe today or tomorrow

[Sharktooth]

$%*#@!!! i have to re-encode quite some stuff...

[Trahald]

I compiled a quick version filename 'x264_669i_pulldown.zip' (same patches as 669h_3 except added the trailing bits fix). ive been requested a version with some extra patches. that will be out by tomorrow.

[Trahald]

$%*#@!!! i have to re-encode quite some stuff...
Nah... you dont have to reencode it.. just have to run it through h264info.

since scenarist accepted it all seemed well..( i triple checked my code in h264info against the avc spec, i assumed the author of the hrd_patch had done so as well) . my fault for assuming tho. anywho.... i was pointed to some software that is a bit more picky than scenarist. helped alot in isolating the issue

[Sagittaire]

I compiled a quick version filename 'x264_669i_pulldown.zip' (same patches as 669h_3 except added the trailing bits fix). ive been requested a version with some extra patches. that will be out by tomorrow.

With these patch your build will be the more advanced in the area:

http://mailman.videolan.org/pipermail/x264-devel/2007-August/003516.html

http://mailman.videolan.org/pipermail/x264-devel/2007-August/003559.html

http://mailman.videolan.org/pipermail/x264-devel/2007-August/003345.html

http://mailman.videolan.org/pipermail/x264-devel/2007-June/003280.html

And other patch for quality improvement from Dark Shikari

[Trahald]

http://mailman.videolan.org/pipermail/x264-devel/2007-June/003280.html
That is an updated hrd patch.. but has the same problem i had to fix.. missing trailing bits call(s)

[Sagittaire]

That is an updated hrd patch.. but has the same problem i had to fix.. missing trailing bits call(s)

The most important patch is x264_2pass_vbv.diff
http://jfl1974.free.fr/HDDVD/Patch.rar

This patch active really vbv control (not perfect anyway) in multipass mode. There are patch from Gabriel Bouvigne for Bframe improvement. There are patch from Dark Shikari for quality improvement. There are interessing patch for fgm.

[Sharktooth]

the fgm patch is a bit useless...
there's no grain analysis at all :(

[Sagittaire]

the fgm patch is a bit useless...
there's no grain analysis at all :(

It's just here for multiplexing test ... anyway it's true useless for quality at this time

[Trahald]

x264_669i_pulldown has been verified as working on HD-E1

[Sagittaire]

x264_669i_pulldown has been verified as working on HD-E1

This build have the new 2 pass patch ... ?

[Sharktooth]

why not using r675?!?

[Sagittaire]

why not using r675?!?

You can make expirimental build with these interessing patch ... ?
http://jfl1974.free.fr/HDDVD/Patch.rar

PS: your PM box is full

[Sharktooth]

yeah i know, my PM box is full on purpouse:)
however i cant make builds here.

[Trahald]

ugh.. cause patching is a pain. have to do alot by hand (patch.exe didnt like the new motion search patches.. some patches edit the same info.. etc) . Besides, the only real changes were in 674/675 and those were vbv related where the current vbv options are sufficient for hd . I'll redo them w/latest 675 later..

i'll diff out the differences of 675 from 669 and patch my patched file :)

[Sharktooth]

may be interesting.
http://forum.doom9.org/showthread.php?t=129842