View Full Version : x264 w/ 3:2 pulldown and hrd
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
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.
hmmm.. my pc is so slow i dont test long files... i'll give it a go, hopefully i'll be able to duplicate even w/the single core.
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:
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.
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
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?
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
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 ?
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.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.