x264 w/ 3:2 pulldown and hrd [Archive]

Trahald

7th May 2007, 20:57

I put up on my sourceforge page a binary of x264 (its the 04272007 checkout w/ hrdpatch 616 applied and then i coded pulldown support over it) i will post a .patch file later (patch will only include my changes) so would be checkout + hrdpatch + pulldownpatch

its on https://sourceforge.net/projects/batchccews/ h264info package. only place i could think of to put it for now. the command line is --pulldown 32. (with the space) .. its doc'd in --longhelp . it adds tbt bt btb tb pattern, to only be used with 1080p 23.976 source. i havent tested it much tho but passes testing so far.

Newest version x264_669i_pulldown.zip (aq / mp4 / threads / hrd_pulldown compiled in cygwin)

**Note: use min-keyint 4 (or more) and do not use b-pyramid for hddvd.

Guest

8th May 2007, 02:41

Thanks, Trahald! That will help me to get my decoding right by enabling me to create test streams.

Pitou

8th May 2007, 20:39

Could anyone point me to a thread or post a command example, for x264, to encode a 1080p 23.976 with pulldown, for it to be imported in Scenarist and be HD-DVD compliant ?

Thanks.

Pitou!

giandrea

9th May 2007, 00:59

Could anyone point me to a thread or post a command example, for x264, to encode a 1080p 23.976 with pulldown, for it to be imported in Scenarist and be HD-DVD compliant ?

Thanks.

Pitou!

Would you use pulldown to uprate it to 30 fps? Isn't the point of HD DVD and BR that they support the 24 fps framerate? Isn't it better to just encode it at the original framerate or isn't it supported by the standard?

Sagittaire

9th May 2007, 11:52

Could anyone point me to a thread or post a command example, for x264, to encode a 1080p 23.976 with pulldown, for it to be imported in Scenarist and be HD-DVD compliant ?

Thanks.

Pitou!

@REM >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
@REM >> first pass
@REM >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
x264.exe --keyint 14 --min-keyint 1 --vbv-maxrate 28000 --vbv-init 1.0 --vbv-bufsize 14745 --mvrange 511 --level 4.1 --nal-hrd --pulldown 32 --bframe 2 --bime --weightb --ref 1 --mixed-refs --direct auto --deblock -2:-2 --bitrate 7000 --pass 1 --stats "x264_stat.log" --qcomp 0.75 --ipratio 1.10 --pbratio 1.10 --partitions "all" --8x8dct --me "hex" --subme 5 --aud --sar 1:1 --cqmfile Sagittaire.cfg --deadzone-intra 6 --deadzone-inter 6 --progress -o test_1_75.h264 Riddick.avs

@REM >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
@REM >> second pass
@REM >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
x264.exe --keyint 14 --min-keyint 1 --vbv-maxrate 28000 --vbv-init 1.0 --vbv-bufsize 14745 --mvrange 511 --level 4.1 --nal-hrd --pulldown 32 --bframe 2 --b-rdo --bime --weightb --ref 3 --mixed-refs --direct auto --deblock -2:-2 --bitrate 7000 --pass 3 --stats "x264_stat.log" --qcomp 0.75 --ipratio 1.10 --pbratio 1.10 --partitions "all" --8x8dct --me "hex" --subme 6 --no-fast-pskip --no-dct-decimate --trellis 1 --aud --sar 1:1 --cqmfile Sagittaire.cfg --deadzone-intra 6 --deadzone-inter 6 --progress -o test_2_75.h264 Riddick.avs

Source must be 1920*1080*23.976

Would you use pulldown to uprate it to 30 fps? Isn't the point of HD DVD and BR that they support the 24 fps framerate? Isn't it better to just encode it at the original framerate or isn't it supported by the standard?

For HDDVD NTSC you must use 1920*1080*29.97 encoding. 1080i29.970 can be 1080p23.976 progressive encoding with pulldown flag.

Pitou

9th May 2007, 13:49

Sagittaire,

Thanks that's what I needed. This is for NTSC 1080p 23.976 source, right?

Also, x264 doesn't seem to put the end of sequence code and when importing to Scenarist, it crashes. Any idea?

Another question, what combination of graph/decoder you're using?

I tried:

file.vc1 --> Sonic HD demuxer --> Sonic video decoder 4.2

and:

file.evo (Haali media splitter) --> WMV9 Advance decoder DMO

and:

file.evo (Haali media splitter) --> ffdshow video decoder

and my avs script:

DirectShowSource("C:\HDDVD\para.grf",fps=23.976,framecount=312,audio=false)

Which one is best?

One last thing, is it possible for you to post your cqmfile Sagittaire.cfg?

Again, Thank you very much for help!

Pitou!

Trahald

9th May 2007, 16:33

Thanks that's what I needed. This is for NTSC 1080p 23.976 source, right?yepAlso, x264 doesn't seem to put the end of sequence code and when importing to Scenarist, it crashes. Any idea?I can possibly add a sequence end code flag , although lack of sequence end code is only a warning for scenarist and should not cause it to crash.

Pitou

9th May 2007, 16:40

Yes I thought so, since you wrote h264info and the x264 pulldown patch... thanks btw!

Not sure why scenarist crash, but when encoding with "your" x264 HRD and then passing the result file through H264info to apply pulldown, Scenarist doesn't complain anymore.

So, as you wish, maybe I can reinstall scenarist or if you add the end code, I can test it...

Thanks!

Pitou!

Trahald

9th May 2007, 18:14

can you provide me a small sample that still crashes scenarist ? are you using hte same settings as Sagittaire? i couldnt reproduce the problem

Pitou

9th May 2007, 20:17

Finally, it did import it with the warning (normal), but it didn't crash...

Maybe my encoding was bad...

I did test with the latest command line Sag just posted and it seems fine.

Thanks!

Pitou!

Pitou

10th May 2007, 02:52

Now Scenarist complain that my video is shorter than my DD+ audio track.

The error is:
"Warning Multiplex is terminated at 00:00:12:22, but expecting end time is 00:00:12:24. Please check video data file or track "para-t".

Video=00:00:12:24
Audio=00:00:12:29

Any idea?

Pitou!

Trahald

10th May 2007, 06:38

i think i see the issue.. should have a fix out in a day or 2

Pitou

10th May 2007, 15:07

Wow, great!

Do you think Dolby TrueHD will work as well?

Trahald

10th May 2007, 22:28

ok.. give 616b a shot

Trahald

11th May 2007, 15:37

ok.. let me know.. if you can.. gimmie a sample i can replicate the issue with. ive tried different settings and havent been able to duplicate a crash

Toti

18th May 2007, 15:37

I am getting a mux error with Scenarist. I first encode the video at 23.976 fps then apply the pulldown with h264info and the resulting video gets accepted but when is creating the HD-DVD it give me the error.

http://aycu03.webshots.com/image/17762/2004116042809257719_rs.jpg

The funny thing is that it works with small video of 1min. This one hour and thirty mins gives me the error.

I tried Alpha 007 & 006. Any suggestions?

Sagittaire

18th May 2007, 16:17

You use Mainconcept/Elecard H264 stream ... ???

Trahald

18th May 2007, 19:40

if you used x264, i would make sure you use 12 frames between idrs.. using history and cinevision (which defaults to 12 frames for pulldown) .. at what clock time is your first chapter break.. also.. either way, can you make a peice available?

Toti

18th May 2007, 22:23

Sagittaire

19th May 2007, 09:32

Yes, I am using MainConcept 2.1.0 please note that if I encode a few minutes the pulldown works. If however, I encode the complete movie then it gives me this error. The movie I was encoding is Winged Migration.

H264info don't work correctly with mainconcept/elecard stream because duration for AVC stream will be not good with pulldown flag (audio/video desynchro with scenarist). You must use x264 and anything else.

Sagittaire

20th May 2007, 09:44

@ Trahald

You can make x264 build with the AQ patch ... ?

Terranigma

20th May 2007, 22:14

Aq patch would be great. You can find the aq patch along with other patches at Cef's (http://cef.neuf.fr/x264/) page.

Toti

23rd May 2007, 18:18

H264info don't work correctly with mainconcept/elecard stream because duration for AVC stream will be not good with pulldown flag (audio/video desynchro with scenarist). You must use x264 and anything else.

If is true that it doesn't work with MainConcept streams. How come it works ok with Trailers that are 1~2mins long? They are also from Mainconcept.

Sagittaire

23rd May 2007, 23:05

If is true that it doesn't work with MainConcept streams. How come it works ok with Trailers that are 1~2mins long? They are also from Mainconcept.

Simply because audio/video desynchro is progressive: desynchro at 0.2 sec for 120 sec (not really a big problem here) done 12 sec for 120 Min (really big problem here).

Mainconcept/Elecard + h264info stream done bad duration in Scenarist SCA. x264 + h264info stream done good duration in Scenarist SCA. I don't know why but it's like that. In fact Mainconcept/Elecard stream even without h264info (Cinevision, Mainconcept h264 encoder or Elecard studio converter with pulldown) done always bad duration in scenarist SCA for me. I must make audio reencoding with Time Stretch if I want correct audio/video synchro. I don't know if Mainconcept/Elecard stream work correctly with Scenarist ACA (directly or with h264info).

Sergey A. Sablin

23rd May 2007, 23:38

Simply because audio/video desynchro is progressive: desynchro at 0.2 sec for 120 sec (not really a big problem here) done 12 sec for 120 Min (really big problem here).

Mainconcept/Elecard + h264info stream done bad duration in Scenarist SCA. x264 + h264info stream done good duration in Scenarist SCA. I don't know why but it's like that. In fact Mainconcept/Elecard stream even without h264info (Cinevision, Mainconcept h264 encoder or Elecard studio converter with pulldown) done always bad duration in scenarist SCA for me. I must make audio reencoding with Time Stretch if I want correct audio/video synchro. I don't know if Mainconcept/Elecard stream work correctly with Scenarist ACA (directly or with h264info).

very interesting to hear that SONIC cinevision doesn't work correctly with SONIC scenarist. very interesting...

bobololo

24th May 2007, 00:33

Mainconcept/Elecard + h264info stream done bad duration in Scenarist SCA. x264 + h264info stream done good duration in Scenarist SCA.

Sorry for being completely off topic but I can't bear it anymore :) You're making this mistake for such a long time that you really deserve someone correct you.

Toti

24th May 2007, 03:38

Sergey A. Sablin

24th May 2007, 03:57

Actually, Sonic CineVision 1.2 is the only product I have that seems to encode correctly to HD-DVD. The difficulties I have with CineVision is:

- It only installs on Windows XP Pro 32-bit
- Simply Too SLOW

Other than that, it works flawlessly.

"if you don't like cats, you simply don't know how to cook 'em" ;)
encoding engine is very fast - tweak up the settings to get more.
the only disturbing thing is GUI slowness, but not encoder.

Toti

24th May 2007, 14:28

Sergey A. Sablin

24th May 2007, 21:29

Thanks Sergey, can you give me some tips. I really don't see any way to tweak CineVision since is straight forward. The only filters I see is "Film Grain" to turn it off. I am using AVC to encode.

VC1 I tried it and has problems encoding still video like "Sunrise Earth" or still background. Do I have to tweak VC1 to look good?

Am all ears.

did you looked into encoder settings? there plenty of them - and probably you already know what many of them means.
another slowness come from preview - try to turn it off.
All in all the speed should be comparable to well known encoder.

drelin

30th May 2007, 09:47

Sorry, but what is exactly the "cqmfile Sagittaire.cfg" in the batch ? (corresponding at a Profile ?)

Thanks.

Sagittaire

30th May 2007, 22:30

Sorry, but what is exactly the "cqmfile Sagittaire.cfg" in the batch ? (corresponding at a Profile ?)

Thanks.

Well it's simply a custom quant matrix. You can drop this command if you want.

very interesting to hear that SONIC cinevision doesn't work correctly with SONIC scenarist. very interesting...

Well the "resolved issue" and the "know issue" in "the realese note" are simply impressive for these sonic product (problem for AVC/VC1 pulldown stream, problem with DD+ and TrueHD ... etc etc). I know very well (certainely not like you anyway) all the internal Mainconcept/elecard command for the core encoder and impossible (for me) to produce AVC pulldown audio/video synchro without audio reencoding (with timestretch). Cinevision is a very simple gui ... perhaps a problem with the NTSC source (24000/1001 fps) or other problem ... I don't know. Anyway x264 work perfectly for HDDVD scenario.

Thanks Sergey, can you give me some tips. I really don't see any way to tweak CineVision since is straight forward. The only filters I see is "Film Grain" to turn it off. I am using AVC to encode.

Cinevision, Elecard studio Converter and Mainconcept H264 encoder use the same SDK encoder. The internal command are always the same.

- Grain Optinmisation is not a filter but an encoding way to preserve grain/noise (not FGM here). This setting work really good.

- Adaptative Quantisation is a psy optimistation mode: There are lumi, contrast and complexity mask. For my eyes complexity at strenght -25 done the best result (higher quant for complex texture).

- You can tweak the CineVision Presets.cfg file if you want all the best possible setting.

- There are a little problem with the gui: you can't choose 14 frame for max GOP and 2 brames. The possibles combinaisons are 12/2 or 14/1 for max GOP/Bframe. 14/1 is a very better choice at low bitrate.

Chefkoch_ico

31st May 2007, 10:19

Hi!

I have some 25fps HD footage. Can I use this x264 version too (because of HRD needed for Scenarist, but no pulldown in this case)

Greetings

SealTooGreat

31st May 2007, 11:36

Where can I find x264 build compiled with AQ and HRD patch?

Sagittaire

10th June 2007, 17:42

"if you don't like cats, you simply don't know how to cook 'em" ;)
encoding engine is very fast - tweak up the settings to get more.
the only disturbing thing is GUI slowness, but not encoder.

Well like I say it's very simple to make encoding with Cinevision and mux with scenarist ...

Source is 3097 frame for 2 mn 09 sec

1) Here encoding with Cinevision
Cinevision say 2 mn 09 sec for 29.970 DNF pulldown encoding
x264 say 2 min 09 for 29.970 DNF pulldown encoding

2) Here Mux with Scenarist SCA
Scenarist SCA say 2 min 09 sec for x264 in DNF mode
Scenarist SCA say 2 min 07 sec for cinevision in DNF mode
Scenarist SCA say 2 min 09 sec for original ac3 in DNF mode

Mux with cinevision will done make audio/video desynchro and not x264 for complete movie (something like 40 sec for 120 min)

3) Here Mux with Scenarist ACA
http://jfl1974.free.fr/HDDVD/Scenarist_ACA_1.JPGhttp://jfl1974.free.fr/HDDVD/Scenarist_ACA_2.JPGhttp://jfl1974.free.fr/HDDVD/Scenarist_ACA_3.JPG

Scenarist ACA say 2 min 09 sec for x264 in DNF mode
Scenarist ACA say 2 min 07 sec for cinevision in DNF mode
Scenarist ACA say 2 min 09 sec for original ac3 in DNF mode

Mux with cinevision will make large audio/video desynchro and not x264 for complete movie (something like 40 sec for 120 min). I don't understand the problem. Anyway x264 and cinevision don't use the same way. If I want correct audio/video synchro with cinevision and with all the Mainconcept/Elecard encoder I must reencode audio with "good duration".

woah!

19th June 2007, 04:23

hmmm why do you need to use the nal-hrd cmd for again???

i just found out i can do a complete author using a encode without that option, i just ran it through h264info to add the pulldown to it and it dropped into ACA and SCA.

bonus is i can run all 4 cores instead of 1 when nal-hrd is used.

Sagittaire

19th June 2007, 14:47

woah!

20th June 2007, 03:57

I use special x264 build (nal_hrd, aq patch, thread patch). With nal_hdr i can scan the buffer compliancy.

well come on then dont be shy with it :)

Trahald

21st June 2007, 16:45

i made a compile with nal+hrd,pulldown, and aq... where is the thread patch... i can add that too.

uteotw

22nd June 2007, 21:17

It would be great if you could make a build (nal+hrd, pulldown, aq, and thread) with an updated rev661.
I got SVN and sync'ed the current build but my skills are too limited diff and include any patch.

About pthread, the x264 main page http://www.x264.nl/ links to this thread http://forum.doom9.org/showthread.php?t=95097

Thanks in advance.

SealTooGreat

22nd June 2007, 22:38

Trahald, if you have the will to that, it would very appreciated. Thanks

Trahald

23rd June 2007, 17:39

The diff link on that thread gives an error message. couldnt get get the patch file

Also.. I just use diff/patch from zlib . this works, although it produces slightly different looking patch files (although they work). what svn app are you using?

uteotw

27th June 2007, 12:28

... what svn app are you using?

Errr... if you were asking me, I use Tortoise.
the whole thing is new to me. It's easy to select to diff and patch files but applying is confusing because source files have changed since the patch were created. So at that point I'm not too sure what to do.

Trahald

30th June 2007, 22:03

i should have out a threaded version with aq/hrd/pulldown for 663 by tomorrow. svn command line seems to work the best for me thanks

Trahald

1st July 2007, 19:07

ok.. check the sourceforge page. 663 checkout with aq hrd pulldown and pthread-w32 .
will put up a combined hrdpulldown patch in a day or so

quantum

1st July 2007, 19:46

When using --threads 2 I see:
x264 [warning]: not compiled with pthread support!

And it's not using both cores.

uteotw

1st July 2007, 22:19

ok.. check the sourceforge page. 663 checkout with aq hrd pulldown and pthread-w32 .
will put up a combined hrdpulldown patch in a day or so

You da man! :D
Will give it a try this week and report back
Thanks a million

Trahald

2nd July 2007, 01:29

:o !

663b up! I compiled and tested it properly in debug mode.. then when i switched to release i missed a step. sorry. This one works.

SealTooGreat

2nd July 2007, 04:28

Trahald, your 663b doesn't support mp4 output. It's 632kb in size, while official r663 is 935kb.

Sagittaire

2nd July 2007, 05:14

Trahald, your 663b doesn't support mp4 output. It's 632kb in size, while official r663 is 935kb.

mp4 and mkv output is completely useless here. This build produce HDDVD/BD compliant stream and these stream must be ES.

SealTooGreat

2nd July 2007, 05:50

^Yes, I know that, but you don't always make HDDVD/BD complaint, ;) there are common x264 encodes as well. Little versatility would be appreciated.

Trahald

2nd July 2007, 07:16

i'll think about it.. since pulldown isnt needed in those containers i didnt make it a priority.

woah!

2nd July 2007, 08:22

how do you tell it to do a 59.94 pulldown, --pulldown 32 i assume does 23.976 to 29.97 yes? can 59.94 be done from 23.976 ?

woah!

2nd July 2007, 11:28

if your interested i have another head scratcher for you:

i am finding the timecodes of the hrd build 663 arent adding up to what i see as the correct timecode output from cinevision.

to test that theory i put the resulting .264 through your h264info app and applied 29.97fps to it. now that shouldnt have really changed anything right as it should have been pulldown 29.97 to begin with.

but after processing it into cinevision it gave the exact same timecode as the cinevision result which i believe is correct.

heres a screenie of what i mean below, the properties you see shows the .264 file is 29.97 but the time is out by about 11 frames.

http://img266.imageshack.us/img266/7028/weird1dh3.jpg

quantum

3rd July 2007, 00:17

663b up! I compiled and tested it properly in debug mode.. then when i switched to release i missed a step. sorry. This one works.

Thanks. Threads are working. Now for some testing.

Trahald

6th July 2007, 20:51

663d is available. fixes the duration issue. should match h264info exactly.

quantum

7th July 2007, 04:13

It appears you left several dependencies for this build. It works on my machine with Visual Studio installed, but it fails on another. The other machine runs all previous versions.

quantum

7th July 2007, 16:50

There's something else going on since the thread support was added. There is an audio sync issue with builds after 616c. The audio falls out of sync half way through the movie. It's in sync for the first half, then out of sync by about a second for the entire second half.

Using the same command line with 616c the audio is fine. I'm starting another encode with 663c without threads to see if it's the threads or something else with the new builds.

I see the timing is different for both streams using Streameye. At frame 100,000, the old version is 1:09:30 while the new (out of sync) version is 1:09:49.

I haven't tested 663d yet because it won't run on the PC I use for encodes.

Trahald

7th July 2007, 20:50

i built 663e now w/out gpac so give that a whirl. (i tested it on a virtual pc window that wouldnt run 663d but does run 663e)

quantum

7th July 2007, 20:56

Using 663b without --threads 2 results in OK audio, so it appears to be a threads problem. With threads, the problem starts approximately halfway through my 206,000 frame test movie.

Nice work so far. This is already one of the few ways to reliably get video into scenarist. If we can have threads, I'd prefer it over Cinevision.

quantum

7th July 2007, 21:02

663e starts up okay. I'll start a test encode and see how threads and audio are working.

Thanks for your efforts.

Trahald

7th July 2007, 21:45

quantum

7th July 2007, 23:02

I'll do some more tests and try to narrow it down. I have a reasonably speedy dual core. My ongoing test is to verify that 663e still has the problem. If so, I'll try to duplicate using a smaller test or provide a sample clip at the crossover point if that would help.

quantum

8th July 2007, 02:44

I did a test with 663e using threads. The good news is the encode works. The bad news is I lose audio sync if --threads 2 is used.

I'll try to figure out if it happens with all sources or just this one. If there's anything I can provide that will help, please let me know.

woah!

8th July 2007, 04:00

i have had np problems with 663d using a quadcore with --threads auto which gives me 4 threads. i dont use --thread-input as i dont see any speed increase so why bother.

i get about 17fps encoding 1920x1080, and i have done about 10 movies now with perfect results authoring in ACA.

thx for all your hard work on this build Trahald it seems to have made my quadcore very happy :)

oh and yes 663d does give me the correct timecodes now, as it would using h264info.

quantum

8th July 2007, 13:30

woah!

8th July 2007, 21:31

@woah:
Can you post your command line and your filter graph?

Are your encodes at least 2 hours and did you check the audio in the second half? My audio sync issue is not gradual, and it doesn't start until about halfway. Then it loses about a second and stays that way till the end.

graph:

File Source (Async) ---> Haali Media Splitter (AR) ---> WMVideo Decoder DMO

cmd line playable on HD-A2 with no issues:

"663D.x264.exe" --pass 1 --bitrate 8000 --stats "1.stats" --ratetol 6 --aq-strength 0.25 --aq-sensitivity 5 --keyint 12 --min-keyint 4 --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 "all" --me hex --subme 5 --threads auto --no-fast-pskip --aud --sar 1:1 --deadzone-intra 6 --deadzone-inter 6 --non-deterministic --progress --output NUL

"663D.x264.exe" --pass 2 --bitrate 8000 --stats "1.stats" --aq-strength 0.25 --aq-sensitivity 5 --keyint 12 --min-keyint 4 --nal-hrd --pulldown 32 --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 "all" --me hex --subme 5 --threads auto --no-fast-pskip --aud --sar 1:1 --deadzone-intra 6 --deadzone-inter 6 --non-deterministic --progress --output

i use evodemux to rebuild the evo's first and then graphedit that file. make sure to check the info in evodemux to see if the audio has a delay (most do). i adjust the audio file in ACA, 1 frame movement in ACA is about 33ms.

yes all the movies i have done play perfect on the A2 sync wise, and at least 5 of them were longer than 2 hrs.

quantum

8th July 2007, 22:19

Thanks for the info. I'm making more tests to narrow down the trouble. I'm downsizing to 1280x720 and running pulldown after with h264info.

The fact to remember is it all works for me without --threads. It also works with Cinevision. However it could be just this one source or something else easy to tweak.

quantum

8th July 2007, 23:55

Trahald

9th July 2007, 13:16

sca's documentation says only 1280x720x5994 is valid. if aca takes it thats good (i dont have the official hddvd specs so i rely on scenarist.) 29.97 on h264 should be the same as pulldown on x264. but i'll look into it.. with 59.94 you have to watch the resolution. i found '1' works but '1:1' doesnt. what error message do you get with 720px59.94
i dont have access to aca so i cant try it.

uteotw

9th July 2007, 20:25

fyi: I did a 2h15 long encode, 190000 frames, with 663b using but the resulting 264 file crashed Scenarist when importing it at 99%.

Anyways, I'm giving 663e a go.

@woah! : I'm not sure to understand your process here.
i use evodemux to rebuild the evo's first

Why do you rebuild the Evos first before feeding it to Graphedit? I just Demux the Evos then feed the video stream to Graphedit.

woah!

9th July 2007, 23:22

i had alot of issues when using a demuxed vc1 file as a source. audio sync problems etc.. but keeping it as a evo file and feeding it to graphedit has given me repeatable working backups.

woah!

9th July 2007, 23:49

My second source works fine with threads, so it appears to be something specific with the first source and threads.

@Trahald: I'm able to use your h264info tool to add pulldown to 1280x720 23.976 to 29.97. Even though that's considered non standard, scenarist takes it and will build it. It can be played on my HD-DVD standalone. h264info 23.976 to 59.97 fails in scenarist. Pulldown 32 in your x264 command line also fails.

Any thoughts on getting 1280x720 pulldown working in your x264?

i have no issues adding a 1280x720 59.94fps encode into ACA.

http://img413.imageshack.us/img413/818/11111111111111111111111lz3.jpg

you seem to be having a lot of weird issues that i am not... thankfully..

i encoded with the same settings as i posted above, then put the result into h264info and only changed the framerate to 59.94. the result dropped into ACA in the screenie.

quantum

10th July 2007, 04:18

I had been using --keyint 14 and --ref 4

I lowered these to --keyint 12 and --ref 3 to match woah's command and now --pulldown 32 works for me at 1280x720 and I can import it into Scenarist ACA without running pulldown afterwards using h264info.

The interesting thing is I could get scenarist to take the higher values, but only if I ran pulldown afterwards.

I don't know if --keyint 12 and --ref 3 are part of the hd-dvd h264 spec.

Trahald

10th July 2007, 14:20

i did a full encode threads 2 and 160k frames. syncs all the way until the end. (29.97).

quantum

11th July 2007, 00:15

I'm wondering if my aggressive x264 parameters also caused the audio sync problem. I'm doing more tests.

quantum

11th July 2007, 03:58

Success! My clip that previously had audio sync trouble now builds fine, even when adding pulldown during the encode.

It seems the following are important:

--keyint 12
--min-keyint 4
--ref 3

Of course plenty of other switches must be set correctly, but these 3 go against some other posts I've seen.

The problems that come up when these are adjusted are non intuitive. For example, when I set min-keyint 1, scenarist would accept and build small clips, but then crash on larger clips, only if pulldown was added during encode.

I could do this:
--keyint 14
--min-keyint 1
--ref 4
If pulldown was applied after the encode using h264info. This would then build fine in scenarist.

I'll be sticking with the settings that allow pulldown to work during the encode.

Everything I've mentioned applies to 1280x720 encodes. I don't do anything larger as my projector is native 720p.

Big thanks to Trahald for his excellent work with pulldown and providing the patched binaries. And thanks to woah for sharing the command line that helped to pinpoint my trouble.

I've collected a lot of info during these tests and I'll share it once I'm satisfied it's working smoothly.

Now to try the AQ patch settings...

drelin

11th July 2007, 13:15

@ quamtum

Can you post yours command lines for x264 encoding for 720p project, please ?

Your process is :
1- encode in 720p with x264 provided by Trahald,
2- pulldown with h264info (fps at 59.94, scale at 1, profile 4.1)
3- Build with scenarist (SCA or ACA ?)
Is it correct ?

THX

quantum

15th July 2007, 04:38

@ quamtum
Can you post yours command lines for x264 encoding for 720p project, please ?
I will, once I have it working %100. It's very close.

Has anyone who added pulldown via Trahalds x264 build actually tried to play it in a Toshiba standalone? While I can bring it into scenarist, build it, and play it in PowerDVD, it will not play correctly on my standalone. It shows distorted, jerky, and pixelated video.

The same stream plays fine on my standalone if I run it through Trahalds h264info and add pulldown after the encode.

drelin

16th July 2007, 14:45

@ Quatum

I've tested 720p encoding with x264 but, if I encode and use h264info for pulldown (23.976 to 59.94) the during time is divised by 2 (1 hour original come 30min in scenarist import).

Trahald

16th July 2007, 20:45

is that in sca? 59.94 support seems to be broken. (it has problems even with cinevision 59.94 output) .. these guys are using aca

woah!

16th July 2007, 22:44

I will, once I have it working %100. It's very close.

Has anyone who added pulldown via Trahalds x264 build actually tried to play it in a Toshiba standalone? While I can bring it into scenarist, build it, and play it in PowerDVD, it will not play correctly on my standalone. It shows distorted, jerky, and pixelated video.

The same stream plays fine on my standalone if I run it through Trahalds h264info and add pulldown after the encode.

are you saying you pulldown to 59.94 or 29.97?

i had some issues with stuttering/pixelation etc.. when using just the x264 cmd's. so i have found just encoding first and then using h264info afterwards gives me consistant results which play perfect on my a2 .

i am looking at 720p to see what i can do to get a working result at 59.94, but at the moment i can only get a 29.97 result to work. if i go with 59.94, i get a green screen output in powerdvd, with the same encode at 29.97 it looks great in powerdvd.

fun and games with this stuff it seems...

Trahald

23rd July 2007, 18:39

Ok.. 663f is up.. I added 23.976->59.94 support (use pulldown 64 .) Output time matches to the frame my tests with cinevision. I Also tweaked regular 23.976->29.97 pulldown (pulldown 32) to match output of times of cinevision.

NOTE: I have found that consecutive i-frames cause time discrepancies. I am able to duplicate this with cinevision by setting min key frame interval to 1 (with source that has some fastmoving scenes). Consecutive i-frames with pulldown causes a frame to be lost in duration time. i had a 10 min source that read 9:59:27 with x264pulldown and cinevision had 10:00:00 ( correct ). I then set min interval to 1 in cinevision and had the same 09:59:27 confirming the issue ( also a 2 day session of scanning the frames by hand to find culprits ). By taking the key frame interval setting in x264 from 1 to 4 , the output became 10:00:00

So... I recommend key frame interval min equal to 4 (cinevision default). Its probably safe to go with 2 or 3 also, but I didn't test those values.

This changes calcs a bit for both methods so careful testing.

fernando6

24th July 2007, 11:28

woah!

25th July 2007, 06:25

well it works with 59.94 pulldown into ACA with correct timecodes.

i completed a full author and burned to disc, but it doesnt play in my hd-a2 player :(

same process / same settings / with 30fps encode plays fine.

probably the players side to be honest tho, maybe it doesnt do 720p60

JK1974

25th July 2007, 10:03

Hi,

EDIT: Sorry, my question about missing sequence end code and crashing Scenarist SCA has been asked before. So I deleted this part.
But: As I can now set the pulldown flag with x264 directly, it would be great if I would not have to use h264info to set the sequence end code flag. Any chance to get this with the next version of x264?

Furthermore, testing this x264 build additionally on an Athlon XP system gave me the error message
Compiler did not align stack variables. Libavcodec has been miscompiled and may be very slow or crash. This is not a bug in libavcodec, but in the compiler. Do not report crashed to FFmpeg developers.
However, the encoded files seem to be okay apart from the SequenceEnd Code warning message mentioned above.

Trahald

25th July 2007, 14:32

i am using x264_663e_ptw32_hrd_pulldown_aq.zip
and i try several encodes but everytime i import to scenarist ,i have this message that the file have a maximim bitrate of 29400 , but i encode with this option --vbv-maxrate 27500 , so how come this max rate is not the same ?
this option is not working on this version of x264 ?

the rate control isnt touched. i do change the fps but that would only tend to lower the real bitrate, not raise it. The bitrate must be peaking outside the range.. no other application (that im aware of) is so picky checking as scenarist. you will have to use a more conservative bitrate ( i use 19400 although i think its only because that was megui's default on the hd profile )

Trahald

26th July 2007, 23:35

.diff patch file available now. its both the hrd and pulldown in one

JK1974

27th July 2007, 09:47

Hi,

during my tests I encountered problems with the bitrate.

This is my source-AVS-Script using the Elephants Dream PNGs as source (so everyone can check this):

ImageSource("d:\elephants dream\%05d.png", start=620, end=5114, fps=23.976)
ConvertToYV12()

The encoding settings:
x264.exe --keyint 14 --min-keyint 4 --vbv-maxrate 20000
--vbv-init 1.0 --vbv-bufsize 14745 --mvrange 511
--level 4.1 --nal-hrd --bframe 2 --bime --weightb --ref 1
--mixed-refs --direct auto --deblock -2:-2 --bitrate 14000
--pass 1 --stats "x264_stat.log" --qcomp 0.75 --ipratio 1.10
--pbratio 1.10 --partitions "all" --8x8dct --me "hex" --subme 5
--aud --sar 1:1 --deadzone-intra 6 --deadzone-inter 6
--progress --threads auto -o d:\ED_14000_pass1.h264
"d:\Elephants Dream\Elephants Dream.avs"

x264.exe --keyint 14 --min-keyint 4 --vbv-maxrate 20000
--vbv-init 1.0 --vbv-bufsize 14745 --mvrange 511 --level 4.1
--nal-hrd --bframe 2 --b-rdo --bime --weightb --ref 3
--mixed-refs --direct auto --deblock -2:-2 --bitrate 14000
--pass 3 --stats "x264_stat.log" --qcomp 0.75 --ipratio 1.10
--pbratio 1.10 --partitions "all" --8x8dct --me "hex" --subme 6
--no-fast-pskip --no-dct-decimate --trellis 1 --aud --sar 1:1
--deadzone-intra 6 --deadzone-inter 6 --progress --threads auto
-o d:\ED_14000_pass2.h264 "d:\Elephants Dream\Elephants Dream.avs"

This is the output from Scenarist SCA:
Error Video or Audio Buffer underflow: (Dts: 7750474, SCR 7750500)
Error dvd_mux : DoMux Multiplexing Error
Error Terminated Multiplexing (ED-ED_14000_pass2_pulldown-t_t.evo).
Error Total bitrate is too HIGH. Please reduce the stream bitrate or the number of stream.
Error Multiplex is failed.
Error Multiplexing failed, Track "ED_14000_pass2_pulldown-t"

As you can see, I have set vbv-maxrate even to 20000, but it still does not work.
On another source material, it works even with a vbv-maxrate of 27000, but with ED it does not seem to work.

Where do you think do I have to tune the settings? Do I really have to lower the vbv-maxrate any further? Does anybody know a free bitrate viewer for x264 encodes?

And once again concerning sequence end code:
Loading the encoded file after using h264info for applying the pulldown flag indeed does not show the sequence end code warning in Scenarist SCA, but reimporting the file once after the vif file has been generated, I get this warning again - fortunately this time without a crash.

Sagittaire

27th July 2007, 10:23

It's not a Trahald patch problem here. In fact vbv compliancy for x264 work only at 100% with CBR mode (qcomp at 0). In fact the problem here is that your average bitrate is really close to your max bitrate. If you want have vbv compliancy you must reduce the bitrate variability and reduce qcomp setting. I know very well the ED movie and this setting with x264_663f_ptw32_hrd_pulldown_aq build will work correctly:

x264.exe --threads 3 --thread-input --keyint 14 --min-keyint 2 --vbv-maxrate 20000 --vbv-init 1.0 --vbv-bufsize 14745 --mvrange 511 --level 4.1 --nal-hrd --pulldown 32 --bframe 2 --bime --weightb --ref 1 --mixed-refs --direct auto --deblock -1:-1 --qpmin 1 --bitrate 14000 --pass 1 --stats "x264_stat.log" --qcomp 0.1 --ipratio 1.10 --pbratio 1.10 --partitions "all" --8x8dct --me "hex" --subme 5 --aud --sar 1:1 --progress -o NUL HDDVD-ntsc.avs

x264.exe --threads 3 --thread-input --keyint 14 --min-keyint 2 --vbv-maxrate 20000 --vbv-init 1.0 --vbv-bufsize 14745 --mvrange 511 --level 4.1 --nal-hrd --pulldown 32 --bframe 2 --b-rdo --bime --weightb --ref 3 --mixed-refs --direct auto --deblock -1:-1 --qpmin 1 --bitrate 14000 --pass 3 --stats "x264_stat.log" --qcomp 0.1 --ipratio 1.10 --pbratio 1.10 --partitions "all" --8x8dct --me "hex" --subme 6 --no-fast-pskip --no-dct-decimate --trellis 1 --aud --sar 1:1 --progress -o 6000.h264 HDDVD-ntsc.avs

x264.exe --threads 3 --thread-input --keyint 14 --min-keyint 2 --vbv-maxrate 20000 --vbv-init 1.0 --vbv-bufsize 14745 --mvrange 511 --level 4.1 --nal-hrd --pulldown 32 --bframe 2 --b-rdo --bime --weightb --ref 3 --mixed-refs --direct auto --deblock -1:-1 --qpmin 1 --bitrate 14000 --pass 3 --stats "x264_stat.log" --qcomp 0.1 --ipratio 1.10 --pbratio 1.10 --partitions "all" --8x8dct --me "umh" --subme 7 --no-fast-pskip --no-dct-decimate --trellis 2 --aud --sar 1:1 --progress -o 6000.h264 HDDVD-ntsc.avs

This setting work well even with very hard source (ED movie is very hard source for vbv) and if average bitrate is really close to max bitrate. In fact if you want vbv compliancy with x264 you must use qcomp < 1 - avg_bitrate/max_bitrate in most case. For example for this movie vbv is compliant in these case:

- average at 6 Mbps and max at 20 Mbps -> qcomp = 0.75
- average at 12 Mbps and max at 24 Mbps -> qcomp = 0.50
- average at 18 Mbps and max at 28 Mbps -> qcomp = 0.25

quantum

27th July 2007, 22:19

Ok.. 663f is up.. I added 23.976->59.94 support (use pulldown 64 .) Output time matches to the frame my tests with cinevision. I Also tweaked regular 23.976->29.97 pulldown (pulldown 32) to match output of times of cinevision. 23.976 to 29.97 (using pulldown 32) with 1280x720 imports and builds in scenarist but is corrupted when playing on standalone. The same video run through again with h264info adding pulldown to 29.97 builds in scenarist and plays okay in my standalone. I didn't try yet 59.97. I'm using scenarist ACA.

@JK1974
I believe your bitrate messages are not due to bitrate. I had the same error when trying to directly import audio from a blu-ray source. I needed to reencode the audio before it would build. I also don't recall ever getting it to work with SCA, but ACA works.

Sagittaire

28th July 2007, 00:11

I believe your bitrate messages are not due to bitrate. I had the same error when trying to directly import audio from a blu-ray source. I needed to reencode the audio before it would build. I also don't recall ever getting it to work with SCA, but ACA works.

No ... I know very well the ED movie and the vbv for x264 doesn't work correctly with average=14000, max=20000 and qcomp=0.75. I can make mux with SCA at these bitrates with lower qcomp setting. Moreover sonic SCA check the vbv compliancy but perhaps not the case for sonic ACA.

JK1974

28th July 2007, 12:11

@quantum:
As far as I remember 720p with 29.97 is not allowed on HD-DVD, just 720 with 60 (or 59.9xy), or am I wrong?

quantum

28th July 2007, 12:54

I thought that way too, however it works on my Toshiba standalone and I can't get 59.97 to work. I haven't tried Trahald's latest build at 59.97 yet.

JK1974

28th July 2007, 13:15

We would have to check if 29.97 has been added to the standard in the meantime or if it works by accident. Otherwise we would have something like those M(S)VCD things: Formats that work on some players while they don´t work on others - not future proof and a mess if you want to lend e.g. your authored private HDV records to somebody else etc.

woah!

29th July 2007, 08:24

23.976 to 29.97 (using pulldown 32) with 1280x720 imports and builds in scenarist but is corrupted when playing on standalone. The same video run through again with h264info adding pulldown to 29.97 builds in scenarist and plays okay in my standalone. I didn't try yet 59.97. I'm using scenarist ACA.

exact same problem here with the 720p stuff. also i found i get corrupted 1080p 29.97fps playback if using just x264 build. i only get perfect results using h264info to add pulldown which doesnt do 59.94fps sadly..

@ JK1974

--qcomp 0 will sort out that issue for you and gives a nice result i did one at 18000 bitrate.

i also use --vbv-maxrate 29400 --vbv-bufsize 30000 and have no issues with playback on my HD_A2. i used those on ED at 18000 bitrate and it plays perfect after authoring to a dvd.

Sagittaire

29th July 2007, 10:44

i also use --vbv-maxrate 29400 --vbv-bufsize 30000 and have no issues with playback on my HD_A2. i used those on ED at 18000 bitrate and it plays perfect after authoring to a dvd.

MS say that the official buffer for HDDVD must be 14745 Kbits for the Main Video Stream. 30000 Kbits is perhaps not HDDVD compliant here. Maxbitrate for HDDVD can be at 29400 Kbps.

woah!

29th July 2007, 20:30

MS say that the official buffer for HDDVD must be 14745 Kbits for the Main Video Stream. 30000 Kbits is perhaps not HDDVD compliant here. Maxbitrate for HDDVD can be at 29400 Kbps.

for vc1 maybe but i have heard h264 can be upto 30000. and as x264 is more like h264 than vc1 codec so i just used that. like i said it plays ED flawless on my hda2 at 18000 bitrate using those settings. as there isnt a spec available i can only go by what works with no issues on my player as thats what my backups are going to be used on.

CruNcher

29th July 2007, 22:45

@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

Sagittaire

29th July 2007, 22:59

for vc1 maybe but i have heard h264 can be upto 30000. and as x264 is more like h264 than vc1 codec so i just used that. like i said it plays ED flawless on my hda2 at 18000 bitrate using those settings. as there isnt a spec available i can only go by what works with no issues on my player as thats what my backups are going to be used on.

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.

Sagittaire

29th July 2007, 23:00

foxyshadis

29th July 2007, 23:51

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

30th July 2007, 00:08

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

30th July 2007, 00:26

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!

30th July 2007, 02:32

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

30th July 2007, 19:07

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

13th August 2007, 17:01

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

13th August 2007, 22:10

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

Trahald

14th August 2007, 14:36

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

17th August 2007, 15:09

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

17th August 2007, 15:19

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

17th August 2007, 16:40

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

17th August 2007, 16:51

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

17th August 2007, 20:12

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

18th August 2007, 06:37

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

Sharktooth

18th August 2007, 15:16

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

plane

19th August 2007, 08:34

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

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

Trahald

20th August 2007, 16:56

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

20th August 2007, 17:47

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

Trahald

20th August 2007, 21:49

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

21st August 2007, 00:40

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

21st August 2007, 06:13

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

Trahald

21st August 2007, 16:52

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

DanielCardenas

22nd August 2007, 00:44

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

22nd August 2007, 19:47

There are not min bitrate for HDDVD/BD profil.

foxyshadis

22nd August 2007, 21:21

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

8th September 2007, 16:35

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

8th September 2007, 19:52

whats the framerate and resolution of that file?

dattrax

8th September 2007, 20:02

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

8th September 2007, 21:06

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

dattrax

8th September 2007, 22:10

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!

8th September 2007, 22:16

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

8th September 2007, 23:51

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

9th September 2007, 05:34

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

10th September 2007, 20:32

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

10th September 2007, 20:36

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

Trahald

10th September 2007, 21:09

Trahald

10th September 2007, 21:11

$%*#@!!! 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

10th September 2007, 21:58

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

11th September 2007, 05:48

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

11th September 2007, 14:15

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

11th September 2007, 14:22

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

Sagittaire

11th September 2007, 15:25

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

12th September 2007, 06:37

x264_669i_pulldown has been verified as working on HD-E1

Sagittaire

12th September 2007, 07:55

x264_669i_pulldown has been verified as working on HD-E1

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

Sharktooth

12th September 2007, 14:21

why not using r675?!?

Sagittaire

12th September 2007, 14:27

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

12th September 2007, 16:25

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

Trahald

12th September 2007, 17:28

Sharktooth

12th September 2007, 17:37

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

Sagittaire

12th September 2007, 17:55

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 :)

I fact like I say the current Rate Control work very bad with vbv compliancy if average bitrate is close to max bitrate in multipass mode. x264_2pass_vbv.diff produce a very improved Rate Control in multipass mode.

Trahald

12th September 2007, 19:12

Ok 675a_pulldown is available.. pulldown patch wise it is the same as 669i. only difference is its up to date on x264 changes and has a bunch of patches. including 2pass vbv update.

Trahald

18th September 2007, 22:08

Just an fyi.. i think this is known but just in case... B-pyramid is NOT available for HDDVD standard content. b-pyramid is only usable for bluray with 3 b-frames where pulldown isnt required. (h264info intended only for hddvd pulldown)

3-b-frame/b-pyramid with hddvd may be an option on advanced content. havent been able to check that.

dattrax

19th September 2007, 22:44

Is the patch source still valid on the web site? I've used it to fix the problem that interlaced coding never worked properly as the SEI block was missing for tff/bff. I want to post my slight mods back, but if there is a newer version then it will be out of sync.

Jim

Trahald

20th September 2007, 21:04

i just put up the diff (4) that is used for 675. the only difference between it and the patch that was up prior to today is the trailing bits fix.

lemme shoot you another pm.

dattrax

21st September 2007, 23:32

Thanks for that. I've tested my patch to your patch on the HD-E1 and interlace coding works perfectly now. basically if you select --interlace you get --nal-hrd + the correct pic_struct to support the field order --interlace gives you tff which is also supported by an alias (--tff) and if you say --bff then you get the opposite.

Thanks for your hard work... We can now do pulldown and interlace on HD-DVD standard

dattrax

23rd September 2007, 17:27

morph166955

23rd September 2007, 17:31

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

Thread pool patch was updated to r678 and moved to http://www.benswebs.com/public/x264/x264_thread_pool.04b.r678.diff

stevencday

14th November 2007, 00:19

Can I do pulldown using x264 for a 23.976 720p stream? I am trying to get away from using h264info for the pulldown and I am intending on making an HD-DVD compliant 720p stream... Help!

lazyn00b

14th November 2007, 03:35

Hi, I'm also having problems with 720p. Here is my (2nd pass) command line:

"C:\Program Files\x264_675a_pulldown\x264.exe" --pass 2 --bitrate 4000 --stats "D:\Projects\Trailers\ial720p.stats" --level 4.1 --keyint 12 --min-keyint 2 --ref 2 --mixed-refs --no-fast-pskip --bframes 2 --bime --weightb --filter -1,-1 --trellis 1 --analyse p8x8,b8x8,i4x4,i8x8 --8x8dct --vbv-bufsize 14745 --vbv-maxrate 12000 --threads auto --thread-input --sar 1:1 --progress --no-psnr --no-ssim --output "D:\Projects\Trailers\ial720p.264" "D:\Projects\Trailers\ial720p.avs" --sar 1:1 --aud --nal-hrd --pulldown 64

Notice I used --pulldown 64 to get 59.94 from a 23.976 stream; this is necessary because Scenarist only seems to accept 720p59.94. Disturbingly, Scenarist reports the time length of the stream as half what it should be. Also, when I author it and play it on my Toshiba, there is severe stuttering and audio dropouts. On the other hand, when I use a similar command line (except using --pulldown 32) for 480p or 1080p, I get perfectly smooth playback and audio sync.

Anybody have any suggestions?

dattrax

14th November 2007, 10:19

All the 59.94fps content I have (and not that much I may add) is truly 59.94 with no pulldown applied. Have you tested a 'real' 59.94fps file?

In the h264 spec the only values of pic_struct which would be valid on a progressive image are frame doubling and frame tripling. I am guessing that this patch only works for interlaced content. so to go 23.976 to 59.976 would use a combination of a value of 3/4/5/6 in the pic_struct whereas to work in progressive you would need to use 7/8 and specify an additional parameter flag at the command line to allow it to do something different.

you can't obviously get from 23.976 -> 59.94 from a multiply of 2 or 3. You would need to use ~30fps with frame doubling or 20fps with tripling.

hope this helps

Jim

lazyn00b

14th November 2007, 13:06

dattrax, I'm fairly certain that the purpose of the --pulldown 64 option is to apply pulldown to 23.976 to bring it up to 29.97 and then double the frames to bring it up further to 59.94.

My guess is that either Scenarist has some bug in dealing with such a stream or that there is something a little off in Trahald's implementation that creates some kind of timing error. I have also witnessed PowerDVD 7.3 play back these streams at double speed as some other poster has mentioned.

To answer your question, though, I have not tried authoring a "pure" 720p59.94 stream - that's a good idea.

dattrax

14th November 2007, 14:22

Like I mentioned, In the h264 spec you can use a pic_struct of 5/6 which means top,bot,top,top,bot,top,

If you are going back to basics though then with pulldown 23 you are going from 23.976 to 29.976 and, heres the key, from progressive to interlaced. The 720P mode is a progressive mode, so if you tried to do a pic_struct of 5/6 then you would receive a 720i file with effective 360 lines per field. I'm not sure if HDDVD was ever designed to run like that.

I'll have a look at the patch when I get home from work as I am fairly familiar with it to see what pic_struct it is using in the case of 64.

From the h264 spec

NOTE - Frame doubling can facilitate the display, for example, of 25p video on a 50p display and 29.97p video on a 59.94p display. Using frame doubling and frame tripling in combination on every other frame can facilitate the display of 23.98p video on a 59.94p display.

I guess I need to check what it does.

Jim

Trahald

19th November 2007, 03:04

pulldown 64 does doubling / tripling (using it for 59.94 pulldown is in the avc spec sheet). problem is scenarist sc doesnt do well with it. i havent produced a good stream with that setting... but then i havent produced a stream with cinevision @ 59.94 using its own trip/doub pulldown that works with scenarist either. im inclined to thing scenarist sc's support for that mode is broken. or it could be cinevision is broken and i shouldnt be mimicking it. only reason i think its scenarist b/c different versions of cinevision output (59.94 internal pulldown) fed to scenarist sc fail (produce skippy streams or fail to mux completely)

Trahald

19th November 2007, 03:10

BTW... Real world keeping me from coding... will try to get to the promised changes soon

Vivo

19th November 2007, 20:56

Excuse me for being a newbie on this subject.
but can i use MEgui for this process? or how exactly do i go from having a avi/mpeg/etc.. to create a HD-dvd or BD-dvd compliant file with this x264?
we are not all Encode gurus soo any help is appriciated
maby a small tutorial if anyone would like to create one.
would be really greatfull.
thanks for any help on this!

Chefkoch_ico

23rd November 2007, 13:17

Hi!

I am planning to upgrade my system from dual core to quad core.

I think I read somewhere here, that the "HD-DVD"-x264 versions don´t work properly in some way.

Is there a workaround (i.e. use less threads [how much?]), or was this already fixed?

Greetings

dattrax

24th November 2007, 15:50

I've not had any problem with making HD-DVD compatible files.

As long as you stick to the constraints of HD-DVD you should be OK.

Jim

bob0r

3rd February 2008, 16:19

Here's your patch back with the interlace modes fixed. x264 always created frame pictures even when --interlace was selected, so didn't ever work in a standalone decoder.

As I mentioned --tff on the command line causes --nal-hrd + --interlace + the correct signalling in the SEI block. --bff has the same effect but with different field order.

I have tested on my HD-E1. works flawlessly

Jim

x264.736.modified.02.exe (http://files.x264.nl/x264.736.modified.02.exe)

General thread:
http://forum.doom9.org/showthread.php?t=130364

x264_aq_var.48.diff
http://forum.doom9.org/showthread.php?t=132760
x264.gaussian.cplxblur.01.diff
Dark Shikari: - gaussian cplxblur: gives a tiny improvement in 2pass ratecontrol
x264_me-prepass_DeathTheSheep.01.diff
http://forum.doom9.org/showthread.php?p=1093523
x264_2pass_vbv.4.MatMaul.diff
http://mailman.videolan.org/pipermail/x264-devel/2008-January/004015.html
x264_hrd_pulldown.04_interlace.diff
- HRD and pulldown for HD compatibility, updated patch for interlacing
http://forum.doom9.org/showthread.php?p=1047919#post1047919

woah!

5th February 2008, 09:31

x264.736.modified.02.exe (http://files.x264.nl/x264.736.modified.02.exe)

General thread:
http://forum.doom9.org/showthread.php?t=130364

x264_aq_var.48.diff
http://forum.doom9.org/showthread.php?t=132760
x264.gaussian.cplxblur.01.diff
Dark Shikari: - gaussian cplxblur: gives a tiny improvement in 2pass ratecontrol
x264_me-prepass_DeathTheSheep.01.diff
http://forum.doom9.org/showthread.php?p=1093523
x264_2pass_vbv.4.MatMaul.diff
http://mailman.videolan.org/pipermail/x264-devel/2008-January/004015.html
x264_hrd_pulldown.04_interlace.diff
- HRD and pulldown for HD compatibility, updated patch for interlacing
http://forum.doom9.org/showthread.php?p=1047919#post1047919

thx for this build, but i am having some weird issue with it :(

seems as soon as i use your build i get this error:

avis [error]: unsupported input format (DIB )
x264 [error]: could not open input file 'Y:\VC1.avs'

all i have is a avs script with this in it:

DirectShowSource("X:\rock.mkv" ,fps=23.976 ,audio=false)

this encodes works with only changing to an old build 682 that cef made with aq enabled, but the exact same path/settings??

any clue why that is :(

Dark Shikari

5th February 2008, 09:32

thx for this build, but i am having some weird issue with it :(

seems as soon as i use your build i get this error:

avis [error]: unsupported input format (DIB )
x264 [error]: could not open input file 'Y:\VC1.avs'

all i have is a avs script with this in it:

DirectShowSource("X:\rock.mkv" ,fps=23.976 ,audio=false)

this encodes works with only changing to an old build 682 that cef made with aq enabled, but the exact same path/settings??

any clue why that is :(It means you need to add a ConvertToYV12() onto the end of that...

woah!

5th February 2008, 09:42

thx but that didnt do it either, and i actually had that in the script aswell but didnt copy it here, my fault.

ConvertToYV12()

also the script runs fine in virtualdub so i cant debug that way either..

Dark Shikari

5th February 2008, 09:49

thx but that didnt do it either, and i actually had that in the script aswell but didnt copy it here, my fault.

ConvertToYV12()"DIB" means there's an error in the script, or its not outputting YV12 (the former implies the latter). Open it in Virtualdub or a media player to see the error.

woah!

6th February 2008, 01:20

"DIB" means there's an error in the script, or its not outputting YV12 (the former implies the latter). Open it in Virtualdub or a media player to see the error.

sorry i had to hit the sack after i wrote my reply.

so heres my issue in a somewhat more in depth post:

i have been using a cef build which uses --me-prepass and a few other patches for months now with no issues at all with anything i threw at it.

i used the same avs script which is completed below:

DirectShowSource("x:\rock.mkv" ,fps=23.976 ,audio=false).ConvertToYV12()
#Lanczos4Resize(1920,1080)
#trim(41000,43000)

now the script opens fine in mpc and virtualdub but with bob0r new build i get that error:

avis [error]: unsupported input format (DIB )
x264 [error]: could not open input file 'Y:\VC1.avs'

not changing anything except going to my old cef build it encodes perfectly? it seems i must have a bugged system by the looks of it then which could have been there for ages :(

all very weird tho as i tell it to convert to yv12 in my script, virtualdub log shows it as yv12, mpc plays it fine, but this build wont run it...

thx anyways..

woah!

6th February 2008, 03:14

ok i removed pretty much everything i had installed avisynth/ffdshow etc.. rebooted and installed the latest ffdshow from x264.nl and its now working with all versions :)

Inventive Software

6th February 2008, 03:46

The other thing to double-check is that the file name is spot-on. I've done that more times than I care to mention. ;)

LUCi5R

6th February 2008, 16:54

Which version of Scenarist exactly are you guys using?
I'm also attempting to take MKV (x264) to author an HD-DVD. So far the only commercial software I know capable of this is Scenarist.

Are there any guides/tutorials for this anywhere?

bob0r

23rd May 2008, 03:30