open-gop patch for x264 (committed)

[jpsdr]

!!! Buffer underflow !!!!!!!!!!!!
I'm doomed with this one...
I've been obliged to change the average bitrate from 4529 to 4507 beacause the result was 150MB too big, and now, i've got this...:mad:
Same encoding parameters (except little change in bitrate), same x264 version, why so misery...
I'm realy pissed of...
But, i want to say i'm not angry angainst anyone, all programmers do great job, simply realy begin to... overflow...
This time, the file is "only" 4GB...
Don't know if problem can come from opengop, nal-hrd or anything else.
I'll provide the file, hope it will help. It will be in multi-rar and upload it on rapidshare or megaupload.

The part of the video the problem occurs has a very specific pattern, i'll provide also a small part of the original source.

[shon3i]

Do you get underflow on mux with scenarist/blu-print? or x264 notice you in log?

[mp3dom]

If you have used Scenarist, you can see where the buffer occours simply watching the muxed (incomplete) TS.

[jpsdr]

@shon3i:Underflow with Scenarist.
@mp3dom:That's what i've done, i'll let the PC upload the files on rapidshare during this night, and post the links tomorow morning, for DS can take the file and analyse.
Nevertheless, it occurs on a very specific case in the pictures, but i'll let the experts find out.

[shon3i]

We already talk about this problem, if x264 is not report you in log that underflow is occur, then stream is underflow free, but however there is PTS muxing underflow which can occur (as in you case), and comerical encoders have some tools to avoid them.

[jpsdr]

I don't understand the meaning of your answer. You seem to say (but i may misunderstood) that it's somehow some kind of know problem, and that x246 is not reliable enough to be used with authoring software, and need to use comercial encoder instead.
But isn't the final purpose of x264 to be able to be used for Blu-Ray authoring, and so in final stage to haven't this kind of problem anymore ? And in the process of doing this, report when there is problems, for them to be solved ? (And provide samples when possible and needed).

For the samples... It seems that i unfortunately can't access to rapidshare from work (i clearly understand the reason...), so, i'll not be able to post the links before several hours.

[mp3dom]

Out of curiosity, what's the framerate showed in your x264 log?

[jpsdr]

Command line was :

@echo off

SET E_SRC=%6%1.avs
SET E_DST=%3%1.264
SET STAT_FILE=%1.stats
SET TUNING=%4
SET LOG_FILE_1=%1_log_1.txt
SET LOG_FILE_2=%1_log_2.txt

REM Set of max bitrate (ici le bitrate max)
set MAX_BR=15000

REM Set of Buffer (ici le buffer)
set BUF_BR=30000

REM 1ère passe
x264_x64.exe --profile "high" --preset "placebo" --tune %TUNING% --pass 1 --bitrate %2 --stats %STAT_FILE% --level "4.0" --qpmin 0 --vbv-maxrate %MAX_BR% --vbv-bufsize %BUF_BR% --keyint 48 --min-keyint 2 --mvrange 511 --ref 6 --bframe 3 --b-pyramid "strict" --open-gop --subme 9 --trellis 1 --me "umh" --aq-mode 2 --aud --nal-hrd "vbr" --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --videoformat "ntsc" --sar 1:1 --qpfile %5 --threads 0 --thread-input --output NUL %E_SRC% 2> %LOG_FILE_1%

REM 2ème passe
x264_x64.exe --profile "high" --preset "placebo" --tune %TUNING% --pass 2 --bitrate %2 --stats %STAT_FILE% --level "4.0" --qpmin 0 --vbv-maxrate %MAX_BR% --vbv-bufsize %BUF_BR% --keyint 48 --min-keyint 2 --mvrange 511 --ref 6 --bframe 3 --b-pyramid "strict" --open-gop --aq-mode 2 --aud --nal-hrd "vbr" --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --videoformat "ntsc" --sar 1:1 --qpfile %5 --threads 0 --thread-input --output %E_DST% %E_SRC% 2> %LOG_FILE_2%


bitrate : 4507, tuning : animation
video : 720p lagarith YV12

Log of 1rst pass :

avs [info]: 1280x720p 1:1 @ 24000/1001 fps (cfr)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2
x264 [info]: profile High, level 4.0
x264 [info]: frame I:4135 Avg QP:12.12 size:110872
x264 [info]: frame P:49770 Avg QP:15.13 size: 44741
x264 [info]: frame B:103559 Avg QP:17.34 size: 9943
x264 [info]: consecutive B-frames: 6.3% 10.1% 15.7% 68.0%
x264 [info]: mb I I16..4: 32.9% 49.4% 17.7%
x264 [info]: mb P I16..4: 7.1% 12.2% 2.9% P16..4: 26.6% 16.2% 5.5% 0.5% 0.6% skip:28.4%
x264 [info]: mb B I16..4: 0.5% 0.9% 0.3% B16..8: 26.2% 6.8% 1.8% direct: 5.8% skip:57.8% L0:34.8% L1:47.5% BI:17.7%
x264 [info]: final ratefactor: 12.94
x264 [info]: 8x8 transform intra:53.2% inter:65.8%
x264 [info]: direct mvs spatial:100.0% temporal:0.0%
x264 [info]: coded y,uvDC,uvAC intra: 62.0% 68.0% 53.0% inter: 23.6% 25.5% 7.4%
x264 [info]: i16 v,h,dc,p: 55% 13% 13% 19%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 16% 13% 17% 8% 8% 9% 8% 10% 11%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 17% 13% 12% 8% 12% 11% 9% 9% 9%
x264 [info]: i8c dc,h,v,p: 47% 21% 21% 12%
x264 [info]: Weighted P-Frames: Y:5.1%
x264 [info]: ref P L0: 65.0% 11.9% 11.4% 5.9% 4.4% 1.2% 0.1%
x264 [info]: ref B L0: 93.6% 3.9% 1.8% 0.8%
x264 [info]: ref B L1: 97.0% 3.0%
x264 [info]: kb/s:4525.15

encoded 157464 frames, 34.64 fps, 4525.15 kb/s


Log of 2nd pass :

avs [info]: 1280x720p 1:1 @ 24000/1001 fps (cfr)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2
x264 [info]: profile High, level 4.0
x264 [info]: frame I:4135 Avg QP:13.21 size: 96220
x264 [info]: frame P:49770 Avg QP:14.83 size: 46058
x264 [info]: frame B:103559 Avg QP:18.30 size: 9697
x264 [info]: consecutive B-frames: 6.3% 10.1% 15.7% 68.0%
x264 [info]: mb I I16..4: 29.7% 48.3% 22.0%
x264 [info]: mb P I16..4: 5.6% 13.6% 3.3% P16..4: 26.5% 18.5% 4.0% 0.4% 0.3% skip:27.8%
x264 [info]: mb B I16..4: 0.5% 0.8% 0.3% B16..8: 25.8% 7.3% 1.7% direct: 6.6% skip:57.1% L0:35.3% L1:46.7% BI:18.0%
x264 [info]: 8x8 transform intra:56.9% inter:55.0%
x264 [info]: direct mvs spatial:99.5% temporal:0.5%
x264 [info]: coded y,uvDC,uvAC intra: 58.7% 64.4% 49.2% inter: 20.1% 22.0% 8.1%
x264 [info]: i16 v,h,dc,p: 60% 12% 12% 17%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 16% 14% 18% 8% 8% 9% 7% 10% 10%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 17% 12% 17% 8% 11% 10% 8% 8% 8%
x264 [info]: i8c dc,h,v,p: 47% 21% 21% 11%
x264 [info]: Weighted P-Frames: Y:5.4%
x264 [info]: ref P L0: 68.6% 11.2% 11.0% 5.4% 3.0% 0.7% 0.0%
x264 [info]: ref B L0: 93.6% 4.3% 1.6% 0.5%
x264 [info]: ref B L1: 97.2% 2.8%
x264 [info]: kb/s:4500.14

encoded 157464 frames, 10.23 fps, 4500.14 kb/s

[mp3dom]

The curiosity was only on the framerate. Sometimes after IVTC (if someone performed it) the framerate is not perfectly 24000/1001 but 2997/125 which could create some buffer under/overflow. Yours is correctly 24000/1001 so no problem here :)

[jpsdr]

The file is the result of IVTC via avisynth script (doubleweave + pulldown) from a 29.97fps DVD source.
But problem occurs on a very specific scene, were video becomes pure noise, with only black and white points, but not brutaly, "slowly", but brutaly comes back to normal. Problem seems to occurs during the frames were there is this brutal transition of pure black and white noise (so high bandwith i think), to a standard anime scene, were bandwith is probably realy lower.
The thing is that the same video encoded with bitrate at 4529 hasn't trig the error ! It must be realy on the edge.
I hope DS and/or Trahald who worked on the nal_hrd part will be able to get the files i'll post, and find out the source of the problem, and find a solution.

[mp3dom]

Maybe you could lower the bufsize a bit but:
- It's not granted to work
- You need to do an encode which could take up a lot of time (depending by your settings/video length)

It's in these circumstances that segment encoding is the manna from heaven :)

[shon3i]

I don't understand the meaning of your answer. You seem to say (but i may misunderstood) that it's somehow some kind of know problem, and that x264 is not reliable enough to be used with authoring software, and need to use comercial encoder instead.x264 is good enough for authoring apps, but sometimes can produce streams that can cause muxing underflows, while i newer seen that with any comercial encoder before, they have some buffer fullness control, which used for prevention, however comercial encoders recommend to keep VBV buffer size and Maxrate tied as possible (for example --vbv-maxrate 15000 --vbv-bufsize 15000), to keep 1 sec buffer period, which is recommend in most cases.

So this is known issue with x264, and is already discussed in NAL-HRD forum.

But problem occurs on a very specific scene, were video becomes pure noise, with only black and white points, but not brutaly, "slowly", but brutaly comes back to normal. Problem seems to occurs during the frames were there is this brutal transition of pure black and white noise (so high bandwith i think), to a standard anime scene, were bandwith is probably realy lower.I notice same, and mp3dom aslo faced with same behavior, with same scenario (black background).

Since i faced with this problem earlier, before official blu-ray support is commited, i can't remember what source i had. if you can provide source that can always make this behavior i think will finaly x264 devs can do something about this.

btw. try with mp3dom suggestions, i aslo suggest to keep buffer tied to maxrate, iirc mp3dom soloved his problem with --qpcomp 0.5, which change ratecontrol decisions on that frames.

[jpsdr]

If i understand, you suggest for buffer the following : if (maxrate<=30000) buffer=maxrate; else buffer=30000;
and it's what commercial encoders recommend, i am correct ? If yes, maybe you can add this recommendation on the 1rst post of the encoding for Blu-Ray thread you've created.
I can try this for buffer.
As DS doesn't recommend to change qpcomp, i prefer not touch it. I will this evening provide the rapidshare links for the datas, and redo the encode of the video, and test if it works. But, with the non determinist part of x264, who know if simply redoing the exact same thing it will not pass ? As difference was only average bitrate going from 4529 to 4507. But, as it's a little long, i'll try the "sure way" : buffer=maxrate, this will allow me to try redo my authoring tomorrow evening.

[mp3dom]

however comercial encoders recommend to keep VBV buffer size and Maxrate tied as possible (for example --vbv-maxrate 15000 --vbv-bufsize 15000), to keep 1 sec buffer period, which is recommend in most cases.
Uhmm, I've never seen that kind of raccomandation. The only thing that I've noticed with commercial encoders is that if you set a too lower bitrate, the encoder warns you to raise at least to <value> to avoid buffer problems. For example CineVision for L4.1 with 30Mbps buffer, allow you to have a minimum average bitrate of 17 Mbps on 40Mbps (max). Also suggest to have an average bitrate at least 30% less than maxrate.

[shon3i]

If i understand, you suggest for buffer the following : if (maxrate<=30000) buffer=maxrate; else buffer=30000;No just use buffer=maxrate in all cases (15000,15000 in your case), aslo higher maxrate than 30000 can make same scenario or even worse, it's not recommend to use max possible max rate which is 40000.

however this will not guarantee soultion for your problem. But solove in my case, while qpcomp solove in mp3dom case. So solution exist, but a matter of time and nerves ;)

[shon3i]

Also suggest to have an average bitrate at least 30% less than maxrate. I saw that, i think i saw this recommendation in sony knowlege base, they are recommend keep avg bitrate closer to maxrate, and recommend 1 sec buffer, which basicly means keep buffer close to maxrate.

[jpsdr]

No just use buffer=maxrate in all cases (15000,15000 in your case),
So solution exist, but a matter of time and nerves
This case is not my only case, this is why i've said that...
In fact, i've the following cases :
FHD : 40000,30000 level 4.1
HD-1 : 40000,30000 level 4.1
HD-2 : 24000,30000 level 4.0 (change to 24000,24000 so)
HD-3 : 15000,30000 level 4.0 (change to 15000,15000 so)
(2 sec GOP)
SD : 15000,30000 level 4.0 (change to 15000,15000 so)
(2 sec GOP).

To preserve time and nerve, is to be fixed in x264. Back home very soon, will post the links.

[jpsdr]

Ok.
DS and Trahal : I've PM'ed you Christmas presents:D
Notify me when you've finished to get them.:thanks:
You've the encoding parameters in post #208 http://forum.doom9.org/showthread.php?p=1409240#post1409240
Forget : x264 version used is the 1643M x64 version of rack04.

[shon3i]

This case is not my only caseYou tried all of this combinations and always face with problem?

i hope x264 devs will conclude something from your source, and put this issue to bed :)

[jpsdr]

You tried all of this combinations and always face with problem?
Noooo...
What i was saying it's that i'm having different encoding configurations, so according to your advise, i may change buffer to maxrate in the configurations where maxrate<30000.

i hope x264 devs will conclude something from your source, and put this issue to bed :)
hummm........... DS asked me what he was supposed to fix as there is no buffer underflow in the log.....:confused:
There was problems before, with dark parts, but they were clearly identified, and solved since.
But maybe the true answer of my case is doing what you said, according commercial encoders suggestion => buffer=maxrate if maxrate<=30000.

[jpsdr]

@shon3i : I've PM'ed you the links for my file. If i remember correctly (and not mix with mp3dom...), you have tools to check Blu-Ray compliancy, so, if it's possible, if you could get the file and check it.
I've also had the small original sample, and if eventualy you want to play with it and see if you can reproduce something...

[mp3dom]

I've the verifier too, but shon3i has more updated version (so, more reliable) :)
Regarding the commercial encoders, it could be a suggestion to have bufsize=maxrate but anyway they don't force you to do so (personally I don't like it)

[jpsdr]

First, re-encoding the video with buffer=maxbr=15000 mux pass without buffer underflow error.
I've decided, just curious, to install and test bitrateviewer 2.1.1.
......... What was my surprise when i saw the results !!!!
The viewer reported average and peak, i must say in first, that average were always perfectly adequate with the average reported in the log file. So, i consider the information provided by the bitrate viewer reliable.

Here are the peaks values (in kpbs) for encoded files with maxbr=15000 and maxbuff=30000 :
17643, 18226, 18507, 18748, 17913, 16061,14696, 19224, 17180, 22257.
Wohh... !!!! Except for one, that's a way higher than the max bitrate set... Is it normal ??????? Or is there a big problem ???
With a GOP setting of 2s, i don't think these files stay Blu-Ray compliant !
Here are the peaks values (in kpbs) for encoded files with maxbr=15000 and maxbuff=15000 :
15338(*), 14962.
(*) : This was the file wich previously created buffer underflow.
The peak for the (*) file encoded with maxbr=15000 and maxbuff=30000 is 21490.
This is this file i've given the links to DS and kieranrk.
I've restart the encoding of the 10 file encoded with maxbr=15000 and maxbuff=30000 now with maxbr=15000 and maxbuff=15000.
Results not before monday...

[mp3dom]

High peaks doesn't create problem as long as the buffer is filled with data that either don't overflow or underflow. With maxrate=bufsize the 'excursions' of the peaks is more limited over time (hence I don't like it very much).

[jpsdr]

Well, when i limit the bitrate at 15000, i'm a little surprise to see peaks higher than 20000... But if it's normal...

[mp3dom]

It depends by what's the occupancy of the VBV. A high peak could be fully allowed for a short period if the VBV can manage it. I've seen some BD that sometimes have spikes over 60 Mbps (the max allowed is 40 Mbps)

[Trahald]

@jpsdr
I didnt see if you had already done this, but can you make the same encode exact same settings but without open-gop and use a totally unpatched x264 then see if it passes.

Attached is a newer version of the patch. it has changed a little.. the option is " --open-gop coded " if you are doing bluray and " --open-gop display " if you are doing anything else. It does not address the buffer issue (we are still determining if there is one)

[Trahald]

Well, when i limit the bitrate at 15000, i'm a little surprise to see peaks higher than 20000... But if it's normal...

Yes.. it can peak to 25k and still be valid. its not the same as say clipping a audio stream. peaks are ok as long as the buffer can recover.

[shon3i]

It does not address the buffer issue (we are still determining if there is one) Open gop have nothing with underflows here, it's alredy known with unpached bulids and before officialy Blu-Ray commit, even with your HRD patch.

There is probably some undocumented rule, that apply when is muxing to TS. Since all comercial encoders handle this.

[Dark Shikari]

Open gop have nothing with underflows here, it's alredy known with unpached bulids and before officialy Blu-Ray commit, even with your HRD patch.

There is probably some undocumented rule, that apply when is muxing to TS. Since all comercial encoders handle this.Or your muxer is broken. :rolleyes:

Stop spreading FUD about "underflows" that don't exist.

07:18 <kierank> lol his file muxes fine

[shon3i]

Stop spreading FUD about "underflows" that don't exist.An you stop FUD about broken muxers because muxers are just fine and newer have problem with other encoders, and always only with x264. All muxers fail at same place, some little restrictive like tsmuxer will mux stream, but clearly show after that BDAV-STD Model model is completly broken

[Dark Shikari]

All muxers fail at same place, some little restrictive like tsmuxer will mux stream, but clearly show after that BDAV-STD Model model is completly brokenThen where is the proof? Show me where x264 violates the NAL-HRD model, and I will fix it. Whining endlessly without showing proof serves no purpose whatsoever.

Nobody has been able to give me a stream produced by a recent x264 that fails validation in any stream analyzer that I own.

[kieranrk]

Open gop have nothing with underflows here, it's alredy known with unpached bulids and before officialy Blu-Ray commit, even with your HRD patch.

There is probably some undocumented rule, that apply when is muxing to TS. Since all comercial encoders handle this.

I have tested the stream jpsdr sent me and it worked fine with muigenerator.

[jpsdr]

I have tested the stream jpsdr sent me and it worked fine with muigenerator.
Fortunately, otherwise, i'll not even be able to import it in my Blu-Ray project, and so start a mux.

[jpsdr]

@jpsdr
I didnt see if you had already done this, but can you make the same encode exact same settings but without open-gop and use a totally unpatched x264 then see if it passes.

I will, but it will take a little while.
As i said, as problem seems realy on the edge, i don't even know, because of the non-determinist part of x264, if redoing the same thing will not produce a file wich will pass. Indeed, i will also try it, doing a second time the "same" file, to see if it still produces the problem, or magicaly disapered.

[Dark Shikari]

I just spent the past 4 hours rewriting HRD. It's now almost sunrise. So before I completely conk out, try this build (http://x264.nl/developers/Dark_Shikari/x264.exe). It's extraordinarily beta; I'd be shocked if I didn't break at least something horribly. It's almost surely not correct... but we might as well try it. And it's going to be necessary if we intend to fix it.

Includes opengop, threadpool, and various other things that I've locally committed. The relevant patch (http://pastebin.org/343062).

(Thanks to Manao for help understanding a bit of the batshit insanity behind the HRD math.)

[jpsdr]

Thanks, i'll try, results at best in 8 hours, but most probably tomorrow. Good night...

[shon3i]

(Thanks to Manao for help understanding a bit of the batshit insanity behind the HRD math.) Many thanks. I hope it's right thing and solution for mux underflow problem. So i been partialy right?

[jpsdr]

Includes opengop, threadpool, and various other things that I've locally committed.

Are you sure ? Because when i've tried it, it said "unrecognise option" on "--open-gop".

.... "unrecognisze option" on "--nal-hrd".
Doing things at down are not always good...:D
Better take a second look after a good sleep...

[shon3i]

@jpsdr,
both hrd and open gop have sub option

--nal-hrd vbr
--open-gop coded

"coded" is mandatory for blu-ray.

[sneaker_ger]

I can't get them to work either, so jpsdr is probably right. (x264 reports as "core:85 r1416+2 3a4ddc5")

[Dark Shikari]

I can't get them to work either, so jpsdr is probably right. (x264 reports as "core:85 r1416+2 3a4ddc5")$ ./x264 --version
x264 0.99.1649+9 38e7992

Erm... what in the world x264 did you download? I've reuploaded it again just to make sure, but FTP told me I was replacing an identical file, so...

Edit: Replaced it with a new one anyways to fix the stupid bug I introduced. Try it now.

[Dark Shikari]

03:42 < kemuri-_9> Dark_Shikari: go yell at jarod, the link you gave for the
x264 in the open gop thread is giving diff builds of x264
depending on how i download it, e.g. in chrome it's the old
ass build people are bitching about, in wget it's the right
one


Mediafire link (http://www.mediafire.com/?njynu3mnlqy) because jarod's servers are a broken pile of crap.

[jpsdr]

@jpsdr,
--open-gop coded
"coded" is mandatory for blu-ray.
Not yet apparently, or at least, with the version posted by DS.
Beside, i feed x264 with an avs file, but i've an error message saying that raw yuv needs resolution :confused:
First time i see that... Is it normal ?
............ Humm... Ok...It try to open the file 'coded'... Well, ,removing it, and.......... :eek:


avs [info]: avisynth 2.6+ detected, forcing conversion to YV12
avs [info]: 1280x720p 1:1 @ 24000/1001 fps (cfr)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2
x264 [warning]: HRD with (maxrate*timescale*bufsize) > 2^63 not supported
x264 [error]: x264_encoder_open failed


Command line :

@echo off

SET E_SRC=%6%1.avs
SET E_DST=%3%1.264
SET STAT_FILE=%1.stats
SET TUNING=%4
SET LOG_FILE_1=%1_log_1.txt
SET LOG_FILE_2=%1_log_2.txt

REM Set of max bitrate (ici le bitrate max)
set MAX_BR=15000

REM Set of Buffer (ici le buffer)
set BUF_BR=30000

REM 1ère passe
x264_x86v2.exe --profile "high" --preset "placebo" --tune %TUNING% --pass 1 --bitrate %2 --stats %STAT_FILE% --level "4.0" --qpmin 0 --vbv-maxrate %MAX_BR% --vbv-bufsize %BUF_BR% --keyint 48 --min-keyint 2 --mvrange 511 --ref 6 --bframe 3 --b-pyramid "strict" --open-gop --subme 9 --trellis 1 --me "umh" --aq-mode 2 --aud --nal-hrd "vbr" --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --videoformat "ntsc" --sar 1:1 --qpfile %5 --threads 0 --thread-input --output NUL %E_SRC% 2> %LOG_FILE_1%

REM 2ème passe
x264_x86v2.exe --profile "high" --preset "placebo" --tune %TUNING% --pass 2 --bitrate %2 --stats %STAT_FILE% --level "4.0" --qpmin 0 --vbv-maxrate %MAX_BR% --vbv-bufsize %BUF_BR% --keyint 48 --min-keyint 2 --mvrange 511 --ref 6 --bframe 3 --b-pyramid "strict" --open-gop --aq-mode 2 --aud --nal-hrd "vbr" --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --videoformat "ntsc" --sar 1:1 --qpfile %5 --threads 0 --thread-input --output %E_DST% %E_SRC% 2> %LOG_FILE_2%

bitrate = 4507, tuning = animation.
Wanted to let it run during the night, but it'll be postpone...
See you maybe tomorrow.

[sneaker_ger]

$ ./x264 --version
x264 0.99.1649+9 38e7992

Erm... what in the world x264 did you download? I've reuploaded it again just to make sure, but FTP told me I was replacing an identical file, so...

Edit: Replaced it with a new one anyways to fix the stupid bug I introduced. Try it now.

Well, I guess either both jpsdr and I messed up big time or you should spend the next night rewriting your ftp server. :rolleyes:

[Dark Shikari]

Well, I guess either both jpsdr and I messed up big time or you should spend the next night rewriting your ftp server. :rolleyes:jarod runs the FTP server, not me. As mentioned above, it is in fact horribly broken.

We've (almost surely) fixed the HRD problems locally; just a couple more bugfixes were necessary. Now we have to add in support for larger timebase*maxrate*bufsize.

[Dark Shikari]

OK, HRD rewrite/modifications finished, try this build (http://www.mediafire.com/?m0yntzkbxdz). It should pass mux.

[shon3i]

OK, HRD rewrite/modifications finished, try this build (http://www.mediafire.com/?m0yntzkbxdz). It should pass mux.
Thanks. So what is the difference between old and new HRD modeling?

[Dark Shikari]

Thanks. So what is the difference between old and new HRD modeling?The new one has infinite precision.

[Midzuki]

The new one has infinite precision.

:eek: :cool:
:thanks: