x264 bug: slower encoding with mp4 output on avi input with strange framerates

[sasam]

I can encode smaller videos ok.
When I encode videos longer then ~30min x264 starts at 15fps and somewhere in the middle it starts slowing down so when it finishes it is only 2fps and even then I cant play the .mp4 video that it produces.

I encode with x264 cli and megui...

input.avs
A=DirectShowSource("!CMP.avi")
A=ConvertToYV12(A)
A

This is what I use with x264.exe
encode.bat
start /low /b /w x264.exe --progress --pass 1 --bitrate 300 --subme 6 --ref 5 --threads 1 --filter 0:0 --keyint 250 --min-keyint 25 --scenecut 40 --qpmin 10 --qpmax 51 --qpstep 4 --direct temporal --me hex --merange 16 --sar 1:1 --bframes 3 --weightb --b-bias 0 --ipratio 1.40 --pbratio 1.30 --qcomp 0.60 --analyse all --8x8dct -o "x264.mp4" "input.avs"

start /low /b /w x264.exe --progress --pass 3 --bitrate 300 --subme 6 --ref 5 --threads 1 --filter 0:0 --keyint 250 --min-keyint 25 --scenecut 40 --qpmin 10 --qpmax 51 --qpstep 4 --direct temporal --me hex --merange 16 --sar 1:1 --bframes 3 --weightb --b-bias 0 --ipratio 1.40 --pbratio 1.30 --qcomp 0.60 --analyse all --8x8dct -o "x264.mp4" "input.avs"

With megui I use slow profile.

I have Avisynth_256 and newest ffdshow. I also tried older avisynth and ffdshow.
This is not something new. I could never encode large files with x264.
I have this problem on my 3Ghz P4 512Ram and a laptop P M 1.7Ghz 512Ram.
What is going on?

[DryFire]

Have you tried raw or .mkv outputs?

I wonder if .mp4 output is still borked.

[sasam]

Have you tried raw or .mkv outputs?

I wonder if .mp4 output is still borked.


No but I will

[sasam]

It works with .mkv.
encoding long videos in mp4 never worked for me but encoding smaller always works.
Why doesn't it work with mp4?

[Sergejack]

It works with .mkv.
encoding long videos in mp4 never worked for me but encoding smaller always works.
Why doesn't it work with mp4?

Are you using a recent version of X264 ?

[puffpio]

are you overclocked?

[sasam]

I am not overclocked and I am using rev 385.

[bond]

I am not overclocked and I am using rev 385.which compile? try sharktooths

another possible issue:

whats the framerate of the source? try this (http://forum.doom9.org/showthread.php?t=100443)

[bob0r]

If you did not use Sharktooth's version, and used the x264.nl version:

Please try this version: http://files.x264.nl/x264-385-test-install.exe

(My gpac refused to "cvs up", so my gpac lib was out to date)

Please test and let us know!

[sasam]

If you did not use Sharktooth's version, and used the x264.nl version:

Please try this version: http://files.x264.nl/x264-385-test-install.exe

(My gpac refused to "cvs up", so my gpac lib was out to date)

Please test and let us know!
This one works. I used Sharktooth's version, and that didnt work.

[bond]

This one works. I used Sharktooth's version, and that didnt work.interesting, can you try again with sharktooth's latest compile from just a few hours ago too?

and may i ask what framerate the avi has?

[sasam]

sorry i was wrong.
fps is 23.976

Both http://files.x264.nl/x264-385-test-install.exe and Sharktooth's version 385C don't slow down during the second pass but produce 1kb mp4 file???

[bond]

Both http://files.x264.nl/x264-385-test-install.exe and Sharktooth's version 385C don't slow down during the second pass but produce 1kb mp4 file???strange, i tried a small sample with sharktooths and it produced a normal .mp4 file

are you sure your .avs is correct?

[sasam]

It is strange. I use the same script to encode a small file and it works with 384 and doesnt with 385C???

[bond]

It is strange. I use the same script to encode a small file and it works with 384 and doesnt with 385C???no problem here with your exact cmdl

try another source

do you see the video when opening the avs in virtualdub?

[quake74]

I am experiencing the slowdowns during the second pass too. I am encoding a sticom episode and about a third through it slows down a lot. The episode is about 24 mins long, and it's taking (using the psp profile) more than 4 hours. I am attaching two screenshots of the megui window taken on different days with different x264 builds. I will try too different builds and report back.

[bond]

well for sasam, 385C fixed the slowdown

[sasam]

fixed the slowdown but produced 1kb file, but 385F works with big and small files...
I dont know what Sharktooth does to his compiles but rev384 x264.exe was ~800KB, 385C ~700KB and 385F is again ~800KB...

[Sharktooth]

it was caused by GPAC...

[bond]

it was caused by GPAC...in what way? afaik there werent any code changes in gpac?

[Sharktooth]

well, updating GPAC fixed it...

[bond]

well, updating GPAC fixed it...maybe you simply mixed up some sources ;)

[Sharktooth]

never... i always do a fresh checkout:P

[bond]

jaja, still there was no update in the gpac sources between your builds ;)

[Sharktooth]

r384....

[quake74]

I am puzzled, I am trying now the 387 build from sharktooth and it looks like it takes 4.5 hours ("looks like" because I aborted the encoding after 3 hours) to encode the 30min clip I have (about 3.5FPS). I tried with Nero recode (using 2 ref and 3 bframes, but I don't know how to set mixed ref frames or adaptive bframes) and it took just about 1.5hr. Is this normal on a Pentium M 1.83Ghz?

[nm]

And your x264 settings were...?

[quake74]

Sorry, I always forget that because I am only using these settings these days: the PSP profile from Sharktooth ( 2 pass, 2 ref, mixed, 3 bframes, adapt, no pyr).

[nm]

For those settings and a PSP resolution, 3.5 fps sounds a bit too low. Was it faster with some previous x264 build and are you sure there were no other heavy processes taking the CPU time? Comparing to Nero is not very helpful, but comparing to another x264 build would be.

[Shinjite]

I am currently using x264 r387 too, with HQ-Insane, a 1hr 41 minute movie, 1st pass with turbo (6.04fps) take like 7 hours, then 2nd pass now, at 68%(1.02fps), left 12 hours 4x mins more to go (68% took up like more than 12 hours already), then still has 3rd pass to finish. Uber super slow with Insane settings even with my P4 2.4 OCed to 3.24Ghz. But the output is superb so far ;)

[Clown shoes]

(The title has been changed to reflect the subject of the thread) formerly (Big problems with MeGUI and PSP compatibility)


Hi guys,

I am having serious problems making avc MP4s for my PSP. I am producing a .avs file to contain my 23.976 xvid (duration 00.03.07) with the following script;

AviSource("E:\Transporter\Test\Test23.976.avi")
Lanczos4Resize(368,144)
Addborders(0,32,0,32)
ChangeFPS(29.97)

I am then processing the .avs in MeGUI using Sharktooth's psp profile. If I select raw output the log seems fine and displays as follows;

avis [info]: 368x208 @ 29.97 fps (5606 frames)
x264 [info]: using cpu capabilities MMX MMXEXT SSE SSE2
x264 [info]: slice I:23 Avg QP:11.00 size: 15478
x264 [info]: slice P:2467 Avg QP:11.86 size: 8534
x264 [info]: slice B:3116 Avg QP:13.95 size: 2945
x264 [info]: mb I I16..4: 45.4% 0.0% 54.6%
x264 [info]: mb P I16..4: 3.2% 0.0% 10.1% P16..4: 20.3% 12.7% 13.6% 2.7% 2.7% skip:34.8%
x264 [info]: mb B I16..4: 0.3% 0.0% 1.3% B16..8: 31.2% 8.0% 12.7% direct: 2.4% skip:44.1%
x264 [info]: ref P 89.7% 10.3%
x264 [info]: ref B 92.7% 7.3%
x264 [info]: kb/s:1308.0

Actual bitrate after encoding without container overhead: 1308.08
desired video bitrate of this job: 1308 kbit/s - obtained video bitrate: 1308.08250104717 kbit/s

However when I mux the raw .264 file with my 48khz aac .mp4 file produced in belight with YAMB 1.3.3. the resulting log reads;

Adjusting AVC SizeLength to 16 bits
AVC-H264 import - frame size 368 x 208 at 25.000 FPS

IsoMedia import - track ID 1 - Audio (SR 48000 - 2 channels)

Saving to E:\Transporter\Test\Test_1.mp4: 0.500 secs Interleaving


Somehow the file is detected as 25fps!! I tested the file on my PSP just to see if it is being incorrectly detected, but lo and behold it is badly out of sinc.

I then tried producing a .mp4 instead of a raw file in MeGUI but the file that is produced cannot be played by Quick Time as it comes up with an error;

Error -2014: the movie contains an incorrect duration

I tried muxing it in YAMB and got this log;

IsoMedia import - track ID 1 - Video (size 368 x 208)

IsoMedia import - track ID 2 - Audio (SR 48000 - 2 channels)

IsoMedia import - track ID 1 - Audio (SR 48000 - 2 channels)

Saving to E:\Transporter II\Test\Test_1_2.mp4: 0.500 secs Interleaving

It seems to have 2 tracks of audio as well. The file is playable in Quick Time, but guess what?

Movie FPS: 25.00
Duration: 00.03.44.07

I would be hugely grateful if someone could point me in the right direction here. I have spent my entire weekend trying to sort this out and if it takes me much longer to work out, I might well end up breaking my PSP into very small pieces.

Regards

ClownShoes

[quake74]

As far as I know, mp4box (of which yamb is just a gui) muxes by standard at 25 fps. If you want it at 29.97 you have to tell it by adding "-fps 29.97" to the command line (there should be an option somewhere in yamb too). I followed your same route many times (but not using yamb, just plain mp4box) and all the files play on my psp (although I never used such a high bitrate, I usually use 256kbps).

[Doom9]

why not use the muxer in megui? it allows you to set a framerate when muxing, and if you use auto-mode, it's automatically set to the source fps.. so the proper 29.97 you want in this case.
And it isn't done with that.. Sony uses a MP4 perversion so you need to run the atomchanger after creating the MP4 or the PSP will never play your files.

[Clown shoes]

Thanks for the responses guys. Interestingly enough I just tried loading the file I produced using MeGUI outputing .MP4 instead of a raw file. Although it is unplayable in Quick Time and atomchanger detects it as -64.97fps !! It amazingly works on my PSP and is in sync as well!. It did seem a little stuttery and I wonder if that is the normal look of a conversion from 23.976fps on a PSP, or is it my conversion problems?

(slightly OT, I read in another post on this site yesterday that PSP software version 2.60 is now able to play back AVCs at 23.976fps. Can anyone confirm this?

Ok update time;

I installed the full version of MeGUI with the intention of using the muxer functions, however it imediately closes after it opens. The status window says done, but the log reads;

Next job job3 is a mux job. mp4box commandline:
"E:\Downloads\mp4muxer\needed\MP4Box.exe" -add "E:\Transporter \Test\Newtest.mp4" -add "E:\Transporter\Test\Test23.976.mp4":lang=eng -new "E:\Transporter\Test\mux.mp4"
successfully set up muxer and callbacks for job job3
-----------------------------------------------------------------------
Log for job job3

Option -new unknown. Please check usage
an exception ocurred when trying to read from stdout: Could not find file "E:\Transporter\Test\mux.mp4".

Another thing I noticed is if I encode the video to a MP4 file, the frame rate drop down box in the muxer is greyed out. It is only selectable if I use a raw file. The muxer closes down in both cases. Is this intentional?

[Clown shoes]

Damn it, I'm now getting the progresively slower encoding with MeGUI problem. This only seems to occur when I encode as .mp4 and not raw .264 files. The problem is it's only the .mp4 files that I can currently get working. When I try to mux the raw files they still come out as 25fps!

My encoding started at about 40fps and is now at 6fps with only 10% of the 90min movie completed. It currently says 7hours remaining, but the last time I tried doing this It slowed so much that I gave up when it said 16hours still to go with only 19% completed.

I'm really not having much luck here, but it would be a real shame if I have to go back to using pspvideo9!

Anyone have any thoughts on possible solutions?

[Shinjite]

What settings did you use that slows down your encoding??
If it is extreme kind of settings, no doubt it will be slow at the cost of quality

[Clown shoes]

No, it seems that the problem only occurs when encoding to large .mp4 files. Raw .264 is fine.

[Doom9]

When I try to mux the raw files they still come out as 25fps!How do you mux? Megui has an mp4 muxer, press Control-4 in the main menu to access it (or it's also accessible via Tools - Muxer - MP4 muxer).. in that muxer you can set the fps that the mp4 is going to signal.
Check your CPU usage while encoding.. x264 should be taking about the same amount of CPU time over time.. if the cpu usage goes back, check if another application is eating it up.

[bond]

mp4box only needs -fps when muxing from raw. when muxing from .mp4 it should use the framerate of the input.mp4

so why didnt you encode directly to .mp4 but to raw in megui?

[Doom9]

so why didnt you encode directly to .mp4 but to raw in megui?Probably because the auto-mode using x264.exe directly spits out an mp4 and just adds audio to that.. it's more efficient than going raw and then to mp4.

[bond]

Probably because the auto-mode using x264.exe directly spits out an mp4 and just adds audio to that.. it's more efficient than going raw and then to mp4.right, but the guy did output to raw

[Doom9]

I'm always getting the feeling people use yamb for raw muxing.. it's a good tool, but the megui muxer forces you to enter an fps for raw streams.. it doesn't let you create a job otherwise and that's the only way to make sure..

[Clown shoes]

How do you mux? Megui has an mp4 muxer, press Control-4 in the main menu to access it (or it's also accessible via Tools - Muxer - MP4 muxer).. in that muxer you can set the fps that the mp4 is going to signal.


As I mentioned in my post above;

I installed the full version of MeGUI with the intention of using the muxer functions, however it imediately closes after it opens. The status window says done, but the log reads;

Next job job3 is a mux job. mp4box commandline:
"E:\Downloads\mp4muxer\needed\MP4Box.exe" -add "E:\Transporter \Test\Newtest.mp4" -add "E:\Transporter\Test\Test23.976.mp4":lang=eng -new "E:\Transporter\Test\mux.mp4"
successfully set up muxer and callbacks for job job3
-----------------------------------------------------------------------
Log for job job3

Option -new unknown. Please check usage
an exception ocurred when trying to read from stdout: Could not find file "E:\Transporter\Test\mux.mp4".


mp4box only needs -fps when muxing from raw. when muxing from .mp4 it should use the framerate of the input.mp4

so why didnt you encode directly to .mp4 but to raw in megui?


again as mentioned in my previous post;

I'm now getting the progresively slower encoding with MeGUI problem. This only seems to occur when I encode as .mp4 and not raw .264 files.


So in summary, MeGui is having problems for me when encoding .mp4 files. Excess of 24hours to encode 90mins of footage on the second pass, compared to only 3hours to encode the raw .264 file! MeGUI is also failing to mux anything I provide it. (Don't get me wrong, I don't think MeGUI is at fault. I know this must be some kind of setting issue or conflict on my part, I just can't work out where.) The work around I have found is to produce a raw .264 and .mp4 audio file in MeGUI and then mux them with psp.bat. It's just a shame I can't get it all working with MeGUI, as that would really simplify things.

Regards

Clown Shoes

[Doom9]

actually, I have to check the latest mp4box to see.. mp4box not recognizing the -new flag concerns me.. perhaps something has changed in mp4box.. I hate it when they change commandline options.

I'd still like to hear about the cpu usage of the various processes when things get slow. And what happens if you use the commandline shown in the log (the one for x264.exe) and run it from a command prompt (start - run, type "cmd", press enter, then paste the commandline and press enter again)

[bond]

Damn it, I'm now getting the progresively slower encoding with MeGUI problem.according to this thread (http://forum.doom9.org/showthread.php?t=103829&page=1&pp=20) this has been fixed with the latest compiles, make sure to upgrade

[Clown shoes]

That's strange. I think I downloaded and installed the latest build yesterday.

[Sharktooth]

uhm... post your commandline and the exact versions of MeGUI and x264 and mp4box.

[Clown shoes]

MeGUI is 0.2.3.1023b

Mp4box is GPAC version 0.4.1 -DEV

Which commandlines are you after Sharktooth?

[Sharktooth]

the x264 commandline used for encoding

[Clown shoes]

Okay, here's the command line for the first pass;

Next job job1-1 is a video job. encoder commandline:
"E:\Downloads\x264-Lite_r387\x264.exe" --pass 1 --bitrate 1067 --stats "I:\Transporter\Test\video.stats" --bframes 3 --subme 1 --analyse none --me dia --zones 145620,157534,q=40 --progress --no-psnr --output NUL "I:\Transporter\Test\video.avs"
successfully set up video encoder and callbacks for job job1-1


I shall post the second pass in about half an hour when it begins again.

[Clown shoes]

This is the final log for pass 1;

Log for job job1-1

avis [info]: 368x208 @ 29.97 fps (157535 frames)
x264 [info]: using cpu capabilities MMX MMXEXT SSE SSE2
x264 [info]: slice I:633 Avg QP:16.65 size: 13707
x264 [info]: slice P:78312 Avg QP:18.57 size: 6317
x264 [info]: slice B:78590 Avg QP:20.69 size: 1866
x264 [info]: mb I I16..4: 38.9% 0.0% 61.1%
x264 [info]: mb P I16..4: 10.4% 0.0% 0.0% P16..4: 55.9% 0.0% 0.0% 0.0% 0.0% skip:33.7%
x264 [info]: mb B I16..4: 0.6% 0.0% 0.0% B16..8: 40.5% 0.0% 0.0% direct:10.2% skip:48.6%
x264 [info]: final ratefactor: 16.76
x264 [info]: kb/s:989.4

Actual bitrate after encoding without container overhead: 989.41


And this is the start of pass 2. I shall not be finishing it as I do not have the rest of my life to spend waiting for it ;)

job job1-1 has been processed. This job is linked to the next job: job1-2
Next job job1-2 is a video job. encoder commandline:
"E:\Downloads\x264-Lite_r387\x264.exe" --pass 2 --bitrate 1067 --stats "I:\Transporter II\Test\video.stats" --ref 2 --mixed-refs --bframes 3 --subme 6 --b-rdo --weightb --trellis 1 --analyse p8x8,b8x8,i4x4,p4x4 --zones 145620,157534,q=40 --progress --no-psnr --output "I:\Transporter II\Test\video.mp4" "I:\Transporter II\Test\video.avs"
successfully set up video encoder and callbacks for job job1-2



Does this tell you anything usefull Sharktooth?

[Sharktooth]

no... :(
everything seems ok.

[bond]

we still dont know the revision of x264 used?

[Sharktooth]

he said the latest... but what one? mine or others?

[Clown shoes]

Ok, I've checked and x264.exe is using 98% cpu resources. The other 2% is idle. Memory usage is approx 193,000k and steady.

But still the frame rate is steadily falling. Less than 7fps with only 10% completed!

[Clown shoes]

Okay let me check the version of x264. It was MeGUI that I installed yesterday.

[Sharktooth]

where did you download your x264 version?

[Clown shoes]

Ok it's x264 r387. It's from Sharktooth's x264 lite package, downloaded about 2am This morning, London time.

[Sharktooth]

ok... thanks...
im going to recompile it with a new gpac lib.

[bond]

btw also try the solutions discussed here (http://forum.doom9.org/showthread.php?t=100443) with .mp4 output and check if that fixes the slowdown

[Sharktooth]

try removing ChangeFPS(29.97) from the avisynth script.
or add NiceFPS() after ChangeFPS...

[Clown shoes]

Ok. Sounds like a plan. I won't get a chance to try it for a couple of hours, until I get in from work. I will report straight back though.

[Sharktooth]

k.. in the meantime i posted rev387D with an up to date gpac... but try those possible fixes first.

[bond]

also tell us your cpu plz

[Clown shoes]

It's my laptop I'm working on. Dell Precision M60. Intel(R) Pentium(R) M processor 1.70GHz. It has 1gb of ram. I'm running service pack 2 and Netframework 2.0. I don't know if any of that would make any difference.

[bond]

My encoding started at about 40fps and is now at 6fps with only 10% of the 90min movie completed. ok i now tried an own encode (~8500 frames) with your .avs script and settings (different source of course) on my pentium3 866mhz 512mb ram and i get for the

1st pass: 16.23fps
2nd pass: 6.05fps

[Clown shoes]

Unfortunatley, the problem only becomes apparent on longer encodes. I have tried many smaller test files with no problems at all. So without trying a feature length encode, I guess there is no comparison.

[Clown shoes]

I am now at home and testing the nicefps plug in. I am currently only on the first pass with 25% done at 54fps and 35 minutes to go. The first good news to report is that for the first time the bitrate calculator detected 29.97fps. It has always said 25fps and I presumed that was just a default setting when the calculator is opened, apparantly not! Could this therefore mean that MeGUI is incorectly reading avisynth files?

[Doom9]

you'll get a 25fps reading when the source is something different if there's something wrong with the DGIndex project.. I don't quote know what exactly, but I've had this a couple of times, and those AviSynth scripts could not be opened.. if opened in a player the player immediately closed.. when opened in MeGUI, the preview never came up, but the source length still seemed to be read for a wicked reason.

[Clown shoes]

Hmm, the strange thing is the .avs is referencing a .avi, not .d2v. Could this still be the same problem? Also the preview is always displayed for me, no matter what.

OK update time; We are 11% in after about 19 minutes and following a steady decline in fps down to 16.2fps it appears to have stablised and now fluctuates between 16.2fps and 16.3fps. This is great news, nicefps seems to have solved the problem.

[Doom9]

hmm.. no then it's not the same thing
When you play the avs script in a media player, what framerate is shown when you go to the source properties? Note that if using DirectShowSource in your AViSynth script, then it's important that the framerate is put into the command.. like DirectShowSource("youravi.avi", 29.97).

[Clown shoes]

Mediaplayer classic displays it correctly and the properties read;

Video: YV12 368x208 29.97fps

My .avs is as follows;

loadplugin("E:\Downloads\NiceFPS\nicefps.dll")
Directshowsource("I:\Transporter\Test\Test23.976.avi",audio=false)
Lanczos4Resize(368,144)
Addborders(0,32,0,32)
ChangeFPS(29.97)
nicefps()
ConvertToYV12()

I updated my last post while you were last posting, so I wil repeat it here;

OK update time; We are 11% in after about 19 minutes and following a steady decline in fps down to 16.2fps it appears to have stablised and now fluctuates between 16.2fps and 16.3fps. This is great news, nicefps seems to have solved the problem

[Sharktooth]

good to know.

[bond]

OK update time; We are 11% in after about 19 minutes and following a steady decline in fps down to 16.2fps it appears to have stablised and now fluctuates between 16.2fps and 16.3fps. This is great news, nicefps seems to have solved the problemok, can you now plz also try sharktooths latest compile without nicefps() and check if that fixes the slowdown

[Clown shoes]

I will try Sharktooth's new build. However I am going to wait out this encode and make sure it goes the distance.

It is currently 30% in, it has taken a small speed drop to 16.01fps and there is 1 hour 55 minutes to go. I'm really hoping we've got it this time.

Ok, I'm not sure if this relevant, but the encode speed took another dive to 15.82fps and then stablised again. I think I'm going to have to watch this carefully.

[Doom9]

your directshowsource worries me.. no fps in there. How reliable is that filter without an fps indication? It used to be absolutely mandatory.

[bond]

It is currently 30% in, it has taken a small speed drop to 16.01fps and there is 1 hour 55 minutes to go. I'm really hoping we've got it this time.

Ok, I'm not sure if this relevant, but the encode speed took another dive to 15.82fps and then stablised again. I think I'm going to have to watch this carefully.these are minor fluctuations, i dont think its something to worry about

your directshowsource worries me.. no fps in there. How reliable is that filter without an fps indication? It used to be absolutely mandatory.there has been just recently a discussion somewhere about directshowsource() without fps always signallig 25fps. i think thats caused by the parsers used? dunno the details
:search: ;)

[Clown shoes]

I actually only changed over to using directsource this morning. I had been using avisource and was having all the same problems. the reason I switched to directsource was that I noticed MeGUI used it when making it's own .avs for .avis. i thought it might help, but it didn't make any difference. Should avisource have fps indication in the script as well? Also we should remember the raw .264 file didn't have any of these problems.

[foxyshadis]

DirectShowSource signals 25 fps if the stream doesn't return a default duration, so certain splitters/decoders will work fine with it, most don't, and a few just give a gonzo rate. (iirc)

[Clown shoes]

How about avisource though. That has reacted in exactly the same way.

[Clown shoes]

This is the script I had been using, up until this morning;

AviSource("E:\Transporter\Test\Test23.976.avi")
Lanczos4Resize(368,144)
Addborders(0,32,0,32)
ChangeFPS(29.97)

Update;

Well it worked

Next job job1-1 is a video job. encoder commandline:
"E:\Downloads\x264-Lite_r387\x264.exe" --pass 1 --bitrate 1593 --stats "I:\Transporter \Test\video.stats" --bframes 3 --subme 1 --analyse none --me dia --progress --no-psnr --output NUL "I:\Transporter\Test\video.avs"
successfully set up video encoder and callbacks for job job1-1
--------------------------------------------------------------------------
Log for job job1-1

avis [info]: 368x208 @ 29.97 fps (157535 frames)
x264 [info]: using cpu capabilities MMX MMXEXT SSE SSE2
x264 [info]: slice I:633 Avg QP:11.68 size: 17774
x264 [info]: slice P:78307 Avg QP:13.75 size: 9493
x264 [info]: slice B:78595 Avg QP:14.95 size: 3510
x264 [info]: mb I I16..4: 37.7% 0.0% 62.3%
x264 [info]: mb P I16..4: 10.3% 0.0% 0.0% P16..4: 57.6% 0.0% 0.0% 0.0% 0.0% skip:32.1%
x264 [info]: mb B I16..4: 0.7% 0.0% 0.0% B16..8: 46.9% 0.0% 0.0% direct:10.9% skip:41.5%
x264 [info]: final ratefactor: 13.08
x264 [info]: kb/s:1568.4

Actual bitrate after encoding without container overhead: 1568.46

------------------------------------------------------------------------
job job1-1 has been processed. This job is linked to the next job: job1-2
Next job job1-2 is a video job. encoder commandline:
"E:\Downloads\x264-Lite_r387\x264.exe" --pass 2 --bitrate 1593 --stats "I:\Transporter \Test\video.stats" --ref 2 --mixed-refs --bframes 3 --subme 6 --b-rdo --weightb --trellis 1 --analyse p8x8,b8x8,i4x4,p4x4 --progress --no-psnr --output "I:\Transporter \Test\video.mp4" "I:\Transporter \Test\video.avs"
successfully set up video encoder and callbacks for job job1-2
-------------------------------------------------------------------------

avis [info]: 368x208 @ 29.97 fps (157535 frames)
x264 [info]: using cpu capabilities MMX MMXEXT SSE SSE2
mp4 [info]: initial delay 100 (scale 2997)
x264 [info]: slice I:633 Avg QP:11.45 size: 17978
x264 [info]: slice P:78307 Avg QP:12.33 size: 9781
x264 [info]: slice B:78595 Avg QP:14.41 size: 3429
x264 [info]: mb I I16..4: 42.6% 0.0% 57.4%
x264 [info]: mb P I16..4: 3.0% 0.0% 13.0% P16..4: 19.1% 12.0% 12.7% 2.5% 2.5% skip:35.3%
x264 [info]: mb B I16..4: 0.3% 0.0% 1.7% B16..8: 33.8% 8.1% 11.6% direct: 1.9% skip:42.6%
x264 [info]: ref P 88.6% 11.4%
x264 [info]: ref B 91.3% 8.7%
x264 [info]: kb/s:1593.2

Actual bitrate after encoding without container overhead: 1593.21
desired video bitrate of this job: 1593 kbit/s - obtained video bitrate: 1595.31106244885 kbit/s

I will try again without nicefps() but using Sharktooth's new build in the morning and report my findings.

Ok, I spoke too soon. The muxer is still not working for me!

Next job job3 is a mux job. mp4box commandline:
"E:\Downloads\mp4muxer\needed\MP4Box.exe" -add "I:\Transporter\Test\video.mp4" -add "I:\Transporter\Test\audio.mp4":lang=eng -new "I:\Transporter\Test\mux.mp4"
successfully set up muxer and callbacks for job job3
-----------------------------------------------------------------

Error setting job priority. Error message: Cannot process request because the process (3224) has exited. stacktrace: at System.Diagnostics.Process.GetProcessHandle(Int32 access, Boolean throwIfExited)
at System.Diagnostics.Process.GetProcessHandle(Int32 access)
at System.Diagnostics.Process.set_PriorityClass(ProcessPriorityClass value)
at MeGUI.Muxer.encode()

[bond]

This is the script I had been using, up until this morning;

AviSource("E:\Transporter\Test\Test23.976.avi")
Lanczos4Resize(368,144)
Addborders(0,32,0,32)
ChangeFPS(29.97)

Update;

Well it worked

Next job job1-1 is a video job. encoder commandline:
"E:\Downloads\x264-Lite_r387\x264.exe" --pass 1 --bitrate 1593 --stats "I:\Transporter \Test\video.stats" --bframes 3 --subme 1 --analyse none --me dia --progress --no-psnr --output NUL "I:\Transporter\Test\video.avs"
successfully set up video encoder and callbacks for job job1-1
--------------------------------------------------------------------------
Log for job job1-1

avis [info]: 368x208 @ 29.97 fps (157535 frames)
x264 [info]: using cpu capabilities MMX MMXEXT SSE SSE2
x264 [info]: slice I:633 Avg QP:11.68 size: 17774
x264 [info]: slice P:78307 Avg QP:13.75 size: 9493
x264 [info]: slice B:78595 Avg QP:14.95 size: 3510
x264 [info]: mb I I16..4: 37.7% 0.0% 62.3%
x264 [info]: mb P I16..4: 10.3% 0.0% 0.0% P16..4: 57.6% 0.0% 0.0% 0.0% 0.0% skip:32.1%
x264 [info]: mb B I16..4: 0.7% 0.0% 0.0% B16..8: 46.9% 0.0% 0.0% direct:10.9% skip:41.5%
x264 [info]: final ratefactor: 13.08
x264 [info]: kb/s:1568.4

Actual bitrate after encoding without container overhead: 1568.46

------------------------------------------------------------------------
job job1-1 has been processed. This job is linked to the next job: job1-2
Next job job1-2 is a video job. encoder commandline:
"E:\Downloads\x264-Lite_r387\x264.exe" --pass 2 --bitrate 1593 --stats "I:\Transporter \Test\video.stats" --ref 2 --mixed-refs --bframes 3 --subme 6 --b-rdo --weightb --trellis 1 --analyse p8x8,b8x8,i4x4,p4x4 --progress --no-psnr --output "I:\Transporter \Test\video.mp4" "I:\Transporter \Test\video.avs"
successfully set up video encoder and callbacks for job job1-2
-------------------------------------------------------------------------

avis [info]: 368x208 @ 29.97 fps (157535 frames)
x264 [info]: using cpu capabilities MMX MMXEXT SSE SSE2
mp4 [info]: initial delay 100 (scale 2997)
x264 [info]: slice I:633 Avg QP:11.45 size: 17978
x264 [info]: slice P:78307 Avg QP:12.33 size: 9781
x264 [info]: slice B:78595 Avg QP:14.41 size: 3429
x264 [info]: mb I I16..4: 42.6% 0.0% 57.4%
x264 [info]: mb P I16..4: 3.0% 0.0% 13.0% P16..4: 19.1% 12.0% 12.7% 2.5% 2.5% skip:35.3%
x264 [info]: mb B I16..4: 0.3% 0.0% 1.7% B16..8: 33.8% 8.1% 11.6% direct: 1.9% skip:42.6%
x264 [info]: ref P 88.6% 11.4%
x264 [info]: ref B 91.3% 8.7%
x264 [info]: kb/s:1593.2

Actual bitrate after encoding without container overhead: 1593.21
desired video bitrate of this job: 1593 kbit/s - obtained video bitrate: 1595.31106244885 kbit/s

I will try again without nicefps() but using Sharktooth's new build in the morning and report my findings.so these results are with nicefps()?
i ask because in the avs script posted its not shown?

cant wait for the results with sharktooths latest build ;)

[Clown shoes]

Sorry, that was my old script. I was just showing Doom9 that it wasn't just my error with directsource that was causing the problem. This is the actual script I am using now;

loadplugin("E:\Downloads\NiceFPS\nicefps.dll")
avisource("I:\Transporter\Test\transporter.avi")
Lanczos4Resize(368,144)
Addborders(0,32,0,32)
ChangeFPS(29.97)
nicefps()
ConvertToYV12()

I can also report that using avisource gave a 10fps increase on the first pass and a 5fps increase on the second pass.

Here is my MeGui log;

Next job job2-1 is a video job. encoder commandline:
"E:\Downloads\x264-Lite_r387\x264.exe" --pass 1 --bitrate 986 --stats "I:\Transporter\Test\video.stats" --bframes 3 --subme 1 --analyse none --me dia --zones 146071,157534,q=40 --progress --no-psnr --output NUL "I:\Transporter\Test\video.avs"
successfully set up video encoder and callbacks for job job2-1
---------------------------------------------------------------------

Log for job job2-1

avis [info]: 368x208 @ 29.97 fps (157535 frames)
x264 [info]: using cpu capabilities MMX MMXEXT SSE SSE2
x264 [info]: slice I:634 Avg QP:17.25 size: 13017
x264 [info]: slice P:78319 Avg QP:19.24 size: 5877
x264 [info]: slice B:78582 Avg QP:21.23 size: 1689
x264 [info]: mb I I16..4: 39.2% 0.0% 60.8%
x264 [info]: mb P I16..4: 10.4% 0.0% 0.0% P16..4: 55.5% 0.0% 0.0% 0.0% 0.0% skip:34.1%
x264 [info]: mb B I16..4: 0.6% 0.0% 0.0% B16..8: 39.3% 0.0% 0.0% direct: 9.9% skip:50.2%
x264 [info]: final ratefactor: 17.51
x264 [info]: kb/s:915.0

Actual bitrate after encoding without container overhead: 915.10

-------------------------------------------------------------------------
job job2-1 has been processed. This job is linked to the next job: job2-2
Next job job2-2 is a video job. encoder commandline:
"E:\Downloads\x264-Lite_r387\x264.exe" --pass 2 --bitrate 986 --stats "I:\Transporter\Test\video.stats" --ref 2 --mixed-refs --bframes 3 --subme 6 --b-rdo --weightb --trellis 1 --analyse p8x8,b8x8,i4x4,p4x4 --zones 146071,157534,q=40 --progress --no-psnr --output "I:\Transporter \Test\video.mp4" "I:\Transporter\Test\video.avs"
successfully set up video encoder and callbacks for job job2-2
------------------------------------------------------------------------

Log for job job2-2

avis [info]: 368x208 @ 29.97 fps (157535 frames)
x264 [info]: using cpu capabilities MMX MMXEXT SSE SSE2
mp4 [info]: initial delay 100 (scale 2997)
x264 [info]: slice I:634 Avg QP:15.92 size: 14315
x264 [info]: slice P:78319 Avg QP:17.30 size: 6321
x264 [info]: slice B:78582 Avg QP:19.97 size: 1829
x264 [info]: mb I I16..4: 42.8% 0.0% 57.2%
x264 [info]: mb P I16..4: 3.8% 0.0% 10.9% P16..4: 21.0% 12.7% 11.0% 2.2% 1.8% skip:36.6%
x264 [info]: mb B I16..4: 0.3% 0.0% 1.1% B16..8: 36.5% 5.9% 7.2% direct: 1.3% skip:47.8%
x264 [info]: ref P 88.0% 12.0%
x264 [info]: ref B 92.0% 8.0%
x264 [info]: kb/s:986.0

Actual bitrate after encoding without container overhead: 986.05
desired video bitrate of this job: 986 kbit/s - obtained video bitrate: 988.144893077983 kbit/s
------------------------------------------------------------------------
Next job job3 is an audio job. besweet commandline:
"C:\Program Files\BeLight\BeSweet.exe" -core( -input "I:\Transporter\Test\audio.wav" -output "I:\Transporter\Test\audio.mp4" -logfile "I:\Transporter\Test\audio.besweet.log" ) -dimzon( -dllname bse_FAAC.dll -b 128 ) -ota( -g max )
successfully set up audio encoder and callbacks for job job3
-------------------------------------------------------------------------
Log for job job3

besweet: "C:\Program Files\BeLight\BeSweet.exe" -core( -input "I:\Transporter\Test\audio.wav" -output "I:\Transporter\Test\audio.mp4" -logfile "I:\Transporter\Test\audio.besweet.log" ) -dimzon( -dllname bse_FAAC.dll -b 128 ) -ota( -g max )

BeSweet v1.5b31 by DSPguru.
--------------------------

[00:00:00:000] Initializing...
[00:00:00:000] -- Initializing...

[01:27:36:456] |


------------------------------------------------------------------------
Next job job1 is a mux job. mp4box commandline:
"E:\Downloads\mp4muxer\needed\MP4Box.exe" -add "I:\Transporter\Test\video.mp4" -add "I:\Transporter\Test\audio.mp4":lang=eng -new "I:\Transporter\Test\Mux.mp4"
successfully set up muxer and callbacks for job job1
------------------------------------------------------------------------
Log for job job1

Error setting job priority. Error message: Cannot process request because the process (2728) has exited. stacktrace: at System.Diagnostics.Process.GetProcessHandle(Int32 access, Boolean throwIfExited)
at System.Diagnostics.Process.GetProcessHandle(Int32 access)
at System.Diagnostics.Process.set_PriorityClass(ProcessPriorityClass value)
at MeGUI.Muxer.encode()
--------------------------------------------------------------------------




As you can see, the mux has failed again! Any ideas as to the problem here? I am just about to try again without nicefps() and with Sharktooth's new build. I will report back when it finishes, in about 3 hours.

[Clown shoes]

What is the sampling rate of your audio? it must be 48khz to work.

OK, I can now confirm Sharktooth's new build 388 is having the same problems! The first pass encoded at around 70fps, the second pass steadily fell for about 30 minutes until it reached about 7.8fps when it abruptly stopped and displayed an error in the log. The entire log is as follows;

Next job job1-1 is a video job. encoder commandline:
"C:\Program Files\megui_0.2.3.1023b\x264-Lite_r388\x264.exe" --pass 1 --bitrate 801 --stats "I:\Transporter\Test\video.stats" --bframes 3 --subme 1 --analyse none --me dia --progress --no-psnr --output NUL "I:\Transporter\Test\video.avs"
successfully set up video encoder and callbacks for job job1-1
-------------------------------------------------------------

avis [info]: 368x208 @ 29.97 fps (157535 frames)
x264 [info]: using cpu capabilities MMX MMXEXT SSE SSE2
x264 [info]: slice I:633 Avg QP:17.68 size: 11742
x264 [info]: slice P:78346 Avg QP:20.10 size: 5062
x264 [info]: slice B:78556 Avg QP:21.16 size: 1520
x264 [info]: mb I I16..4: 40.6% 0.0% 59.4%
x264 [info]: mb P I16..4: 10.5% 0.0% 0.0% P16..4: 54.3% 0.0% 0.0% 0.0% 0.0% skip:35.2%
x264 [info]: mb B I16..4: 0.6% 0.0% 0.0% B16..8: 36.9% 0.0% 0.0% direct: 8.7% skip:53.8%
x264 [info]: final ratefactor: 19.55
x264 [info]: kb/s:796.6

Actual bitrate after encoding without container overhead: 796.60

------------------------------------------------------------------------
job job1-1 has been processed. This job is linked to the next job: job1-2
Next job job1-2 is a video job. encoder commandline:
"C:\Program Files\megui_0.2.3.1023b\x264-Lite_r388\x264.exe" --pass 2 --bitrate 801 --stats "I:\Transporter\Test\video.stats" --ref 2 --mixed-refs --bframes 3 --subme 6 --b-rdo --weightb --trellis 1 --analyse p8x8,b8x8,i4x4,p4x4 --progress --no-psnr --output "I:\Transporter\Test\video.mp4" "I:\Transporter\Test\video.avs"
successfully set up video encoder and callbacks for job job1-2
------------------------------------------------------------------------

Log for job job1-2

avis [info]: 368x208 @ 29.97 fps (157535 frames)
x264 [info]: using cpu capabilities MMX MMXEXT SSE SSE2
mp4 [info]: initial delay 524288 (scale 15712911)

--------------------------------------------------------------------------
The current job contains errors. Skipping chained jobs
Next job job2 is an audio job. besweet commandline:
"C:\Program Files\BeLight\BeSweet.exe" -core( -input "I:\Transporter\Test\audio.wav" -output "I:\Transporter\Test\audio.mp4" -logfile "I:\Transporter\Test\audio.besweet.log" ) -dimzon( -dllname bse_FAAC.dll -b 128 ) -ota( -g max )
successfully set up audio encoder and callbacks for job job2
---------------------------------------------------------------------------

Log for job job2

besweet: "C:\Program Files\BeLight\BeSweet.exe" -core( -input "I:\Transporter\Test\audio.wav" -output "I:\Transporter\Test\audio.mp4" -logfile "I:\Transporter\Test\audio.besweet.log" ) -dimzon( -dllname bse_FAAC.dll -b 128 ) -ota( -g max )

BeSweet v1.5b31 by DSPguru.
--------------------------

[00:00:00:000] Initializing...
[00:00:00:000] -- Initializing...

[01:27:36:456] |


My .avs script was as follows;

avisource("I:\Transporter\Test\transporter.avi")
Lanczos4Resize(368,144)
Addborders(0,32,0,32)
ChangeFPS(29.97)
ConvertToYV12()

So in summary, I guess the only way to get a working .avc right now is to either use nicefps() or export as a raw .264.

[Chris Benoit]

Strange,mine does work even if i select mp4.Although i do encounter the problem that as the encoding gets along way it becomes progrissevly slower.But it finishes and i don't get any error.

[Clown shoes]

What kind of length was the movie you were encoding though?

[quake74]

Ok, I am using Sharktooth 387 build and for the first time I hve been able to complete my usual 30mins encoding in a reasonable time (about 45 mins for 2 passes) by selecting raw output instead of mp4. (I also tried nicefps with mp4 output, but it didn't help.) I will try newer builds.

If I may, maybe the slowing x264 during the second pass needs its own thread instead of being discussed inside this and other threads.

[bond]

ok, so the issue with strange framerates in .avi sources is still not 100% fixed

thx everyone for testing!

[Clown shoes]

That's what the thread is mostly about. I may rename it though.

[Sharktooth]

yeah...

[Clown shoes]

It also appears nicefps() will not work without changefps() in the script. Without it there, MeGUI still sees the files as 25fps whatever there true fps.

[bond]

i finally merged the two threads dealing with the slowdown issue

[Sharktooth]

It also appears nicefps() will not work without changefps() in the script. Without it there, MeGUI still sees the files as 25fps whatever there true fps.
That's normal and that's why avisynth doesnt know the source FPS.
ChangeFPS(x) tells avisynth to use x FPS and everything should be fine but another proble rise: the encoding slowdown.
There were other problems in the past with floating point FPS values, even crashes.
Seems they're not all fixed, so keep NiceFPS() to ensure the dwRate and dwScale are reduced.

[Clown shoes]

According to nrx][Natas in this thread;

http://forum.doom9.org/showthread.php?p=754484#post754484

[Natas]The speed issue is solved. A complete reinstallation of MeGui and x264 was the solution.

I have asked for more confirmation on this, but I am still awaiting a response.

Is there anyone NOT having the same problem on the second pass when encoding to MP4 from a .avi source? (also NOT using nicefps() as this appears to be a temp fix)

[Chris Benoit]

What kind of length was the movie you were encoding though?

20 mins,i encode tv series mostly.

EDIT:What does nicefps do?

[Sharktooth]

:search:

[Clown shoes]

Sorry Chris, I don't think a 20 min encode is long enough to count. If it had been longer, you would have seen it get progressivly slower.

Has anyone else had the second pass actually fail altogether as I did earlier

The first pass encoded at around 70fps, the second pass steadily fell for about 30 minutes until it reached about 7.8fps when it abruptly stopped and displayed an error in the log. The entire log is as follows;

Next job job1-1 is a video job. encoder commandline:
"C:\Program Files\megui_0.2.3.1023b\x264-Lite_r388\x264.exe" --pass 1 --bitrate 801 --stats "I:\Transporter\Test\video.stats" --bframes 3 --subme 1 --analyse none --me dia --progress --no-psnr --output NUL "I:\Transporter\Test\video.avs"
successfully set up video encoder and callbacks for job job1-1
-------------------------------------------------------------

avis [info]: 368x208 @ 29.97 fps (157535 frames)
x264 [info]: using cpu capabilities MMX MMXEXT SSE SSE2
x264 [info]: slice I:633 Avg QP:17.68 size: 11742
x264 [info]: slice P:78346 Avg QP:20.10 size: 5062
x264 [info]: slice B:78556 Avg QP:21.16 size: 1520
x264 [info]: mb I I16..4: 40.6% 0.0% 59.4%
x264 [info]: mb P I16..4: 10.5% 0.0% 0.0% P16..4: 54.3% 0.0% 0.0% 0.0% 0.0% skip:35.2%
x264 [info]: mb B I16..4: 0.6% 0.0% 0.0% B16..8: 36.9% 0.0% 0.0% direct: 8.7% skip:53.8%
x264 [info]: final ratefactor: 19.55
x264 [info]: kb/s:796.6

Actual bitrate after encoding without container overhead: 796.60

------------------------------------------------------------------------
job job1-1 has been processed. This job is linked to the next job: job1-2
Next job job1-2 is a video job. encoder commandline:
"C:\Program Files\megui_0.2.3.1023b\x264-Lite_r388\x264.exe" --pass 2 --bitrate 801 --stats "I:\Transporter\Test\video.stats" --ref 2 --mixed-refs --bframes 3 --subme 6 --b-rdo --weightb --trellis 1 --analyse p8x8,b8x8,i4x4,p4x4 --progress --no-psnr --output "I:\Transporter\Test\video.mp4" "I:\Transporter\Test\video.avs"
successfully set up video encoder and callbacks for job job1-2
------------------------------------------------------------------------

Log for job job1-2

avis [info]: 368x208 @ 29.97 fps (157535 frames)
x264 [info]: using cpu capabilities MMX MMXEXT SSE SSE2
mp4 [info]: initial delay 524288 (scale 15712911)

------------------------------------------------------------
The current job contains errors. Skipping chained jobs


Should I start a new thread about the MeGUI muxer creating errors everytime I use it, or could it be related to the same problem? Has anyone who's having the second pass speed issues succesfully used the MeGUI muxer?

[Sharktooth]

ClownShoes: the problem is ChangeFPS.
It produces wrong dwScale/dwRate values, so nicefps is needed.
since mp4 has 32bit integer for those values it overflows (coz there is a frames*dwscale multiplication) and x264 b0rks.

[bond]

Sorry Chris, I don't think a 20 min encode is long enough to count. If it had been longer, you would have seen it get progressivly slower.

Has anyone else had the second pass actually fail altogether as I did earlier

The first pass encoded at around 70fps, the second pass steadily fell for about 30 minutes until it reached about 7.8fps when it abruptly stopped and displayed an error in the log. The entire log is as follows;

Next job job1-1 is a video job. encoder commandline:
"C:\Program Files\megui_0.2.3.1023b\x264-Lite_r388\x264.exe" --pass 1 --bitrate 801 --stats "I:\Transporter\Test\video.stats" --bframes 3 --subme 1 --analyse none --me dia --progress --no-psnr --output NUL "I:\Transporter\Test\video.avs"
successfully set up video encoder and callbacks for job job1-1
-------------------------------------------------------------

avis [info]: 368x208 @ 29.97 fps (157535 frames)
x264 [info]: using cpu capabilities MMX MMXEXT SSE SSE2
x264 [info]: slice I:633 Avg QP:17.68 size: 11742
x264 [info]: slice P:78346 Avg QP:20.10 size: 5062
x264 [info]: slice B:78556 Avg QP:21.16 size: 1520
x264 [info]: mb I I16..4: 40.6% 0.0% 59.4%
x264 [info]: mb P I16..4: 10.5% 0.0% 0.0% P16..4: 54.3% 0.0% 0.0% 0.0% 0.0% skip:35.2%
x264 [info]: mb B I16..4: 0.6% 0.0% 0.0% B16..8: 36.9% 0.0% 0.0% direct: 8.7% skip:53.8%
x264 [info]: final ratefactor: 19.55
x264 [info]: kb/s:796.6

Actual bitrate after encoding without container overhead: 796.60

------------------------------------------------------------------------
job job1-1 has been processed. This job is linked to the next job: job1-2
Next job job1-2 is a video job. encoder commandline:
"C:\Program Files\megui_0.2.3.1023b\x264-Lite_r388\x264.exe" --pass 2 --bitrate 801 --stats "I:\Transporter\Test\video.stats" --ref 2 --mixed-refs --bframes 3 --subme 6 --b-rdo --weightb --trellis 1 --analyse p8x8,b8x8,i4x4,p4x4 --progress --no-psnr --output "I:\Transporter\Test\video.mp4" "I:\Transporter\Test\video.avs"
successfully set up video encoder and callbacks for job job1-2
------------------------------------------------------------------------

Log for job job1-2

avis [info]: 368x208 @ 29.97 fps (157535 frames)
x264 [info]: using cpu capabilities MMX MMXEXT SSE SSE2
mp4 [info]: initial delay 524288 (scale 15712911)

------------------------------------------------------------
The current job contains errors. Skipping chained jobswhat are the differences to the encodes that didnt crash?

[Clown shoes]

what are the differences to the encodes that didnt crash?

It was my normal script, but without nicefps() The only other difference was using Sharky's new build.

[Chris Benoit]

Sorry Chris, I don't think a 20 min encode is long enough to count. If it had been longer, you would have seen it get progressivly slower.

But i already see that it gets progressively slower even with such small a file,i'm just saying that the encoding doesn't fail,but it does get slower as time goes by...

[Clown shoes]

@Chris

Sorry mate, The crash I was refering to happened for the first time today. I am not yet sure it is 100% related. This thread is more about the same slow down you experienced, but with longer files those encodes slow to times in excess of 24 hours to complete!! Not practical at all.

ClownShoes: the problem is ChangeFPS.
It produces wrong dwScale/dwRate values, so nicefps is needed.
since mp4 has 32bit integer for those values it overflows (coz there is a frames*dwscale multiplication) and x264 b0rks.

So are we saying that nicefps() is no longer just a temporary fix, but more of a permenant solution?

And I also guess that my problem with the muxer must be unrelated then. I will have to start a new thread for that.

[Sirber]

Good thing I kept it in LE :)

[bond]

It was my normal script, but without nicefps() The only other difference was using Sharky's new build.so the old compile didnt crash without nicefps()?
and the new compile now crashes without nicefps()?

[Sharktooth]

try this build: *removed* doesnt work.

[Clown shoes]

so the old compile didnt crash without nicefps()?
and the new compile now crashes without nicefps()?

Yes. However, I have only seen it crash once. Therefore I may try to reproduce it again this evening, just to be sure. I must admit I have never allowed one of the slow second passes to complete as they started heading into silly time. I have probably not left them running for more than 3 or 4 hours with the remaining time window telling me there is about 16 hours to go! When it crashed this morning, it had only been encoding for about 30 minutes.

@Sharktooth

With or without nicefps()

[Sharktooth]

try the new build without NiceFPS() and report back please.
you can do a 1pass encode to test.

[Clown shoes]

Ok that's cool. I think I will do a 2 pass though, as 1 pass has never given me any problems. I'm afraid it won't be for about 4 or 5 hours though. I will report back once it is done.

[Sharktooth]

new build: http://files.x264.nl/Sharktooth/force.php?file=./x264-r388A_mp4patch.1.7z
mirror: http://www.webalice.it/f.corriga/x264/x264-r388A_mp4patch.1.7z
patch: http://www.webalice.it/f.corriga/x264/x264_mp4fix.1.diff

[Clown shoes]

No joy I'm afraid. The second pass only ran for 15 minutes this time before crashing.

Script;

#loadplugin("E:\Downloads\NiceFPS\nicefps.dll")
avisource("I:\Transporter\Test\transporter.avi")
Lanczos4Resize(368,144)
Addborders(0,32,0,32)
Changefps(29.97)
#nicefps()
ConvertToYV12()

Log;

Next job job1-1 is a video job. encoder commandline:
"E:\Downloads\x264-r388A_mp4patch\x264.exe" --pass 1 --bitrate 801 --stats "I:\Transporter\Test\video.stats" --bframes 3 --subme 1 --analyse none --me dia --zones 145620,157534,q=40 --progress --no-psnr --output NUL "I:\Transporter\Test\video.avs"
successfully set up video encoder and callbacks for job job1-1
--------------------------------------------------------------------------

Log for job job1-1

avis [info]: 368x208 @ 29.97 fps (157535 frames)
x264 [info]: using cpu capabilities MMX MMXEXT SSE SSE2

--------------------------------------------------------------------------
job job1-1 has been processed. This job is linked to the next job: job1-2
Next job job1-2 is a video job. encoder commandline:
"E:\Downloads\x264-r388A_mp4patch\x264.exe" --pass 2 --bitrate 801 --stats "I:\Transporter\Test\video.stats" --ref 2 --mixed-refs --bframes 3 --subme 6 --b-rdo --weightb --trellis 1 --analyse p8x8,b8x8,i4x4,p4x4 --zones 145620,157534,q=40 --progress --no-psnr --output "I:\Transporter\Test\video.mp4" "I:\Transporter\Test\video.avs"
successfully set up video encoder and callbacks for job job1-2
--------------------------------------------------------------------------

Log for job job1-2

avis [info]: 368x208 @ 29.97 fps (157535 frames)
x264 [info]: using cpu capabilities MMX MMXEXT SSE SSE2
mp4 [info]: initial delay 524288 (scale 15712911)

---------------------------------------------------------------------------
The current job contains errors. Skipping chained jobs
Next job job2 is an audio job. besweet commandline:
"C:\Program Files\BeLight\BeSweet.exe" -core( -input "I:\Transporter\Test\audio.wav" -output "I:\Transporter\Test\audio.mp4" -logfile "I:\Transporter\Test\audio.besweet.log" ) -dimzon( -dllname bse_FAAC.dll -b 128 ) -ota( -g max )
successfully set up audio encoder and callbacks for job job2
-------------------------------------------------------------

Log for job job2

besweet: "C:\Program Files\BeLight\BeSweet.exe" -core( -input "I:\Transporter\Test\audio.wav" -output "I:\Transporter\Test\audio.mp4" -logfile "I:\Transporter\Test\audio.besweet.log" ) -dimzon( -dllname bse_FAAC.dll -b 128 ) -ota( -g max )

BeSweet v1.5b31 by DSPguru.
--------------------------

[00:00:00:000] Initializing...
[00:00:00:000] -- Initializing...

[01:27:36:456] |



Looks like we're going to have to use nicefps() a little bit longer.

[quake74]

link fixed...
new build: http://files.x264.nl/Sharktooth/force.php?file=./x264-r388A_mp4patch.1.7z
mirror: http://www.webalice.it/f.corriga/x264/x264-r388A_mp4patch.1.7z
patch: http://www.webalice.it/f.corriga/x264/x264_mp4fix.diff

Using this build I completed my usual 30mins encoding with mp4 output in about the same time I did raw output with previus builds (about an hour for 2 pass) so for me the slowdown problem is gone. However, mp4box has problem muxing the mp4 and it's been running for more than 5 mins to mux a 56mb video with a 14mb audio. Weird.

My avs file is
clip1 = mpeg2source("VTS_06_1.d2v")
clip1 = clip1.LanczosResize(368,208)
clip1 = clip1.changefps(29.97)
return clip1
and I'm encoding using the psp profile (just added pyr bframes to see it that works on the psp).

EDIT: Demuxing the mp4 to raw and remuxing the raw with the audio file works.

[Clown shoes]

I thought this problem was with .avi sources? How slow was your .d2v running on 2nd pass before the new build? Is it possible you could test with a longer source?

Did you mux in MeGUI or command line? I cannot get the mux in MeQUI to work at all!

[quake74]

I thought this problem was with .avi sources? How slow was your .d2v running on 2nd pass before the new build? Is it possible you could test with a longer source?

Did you mux in MeGUI or command line? I cannot get the mux in MeQUI to work at all!

I had the slowdown problem with both avi and d2v sources. I will try with a feature length encoding in the next few days, but I'm pretty sure it's gone for me. The source I encoded this time used to take me more than 4 hrs (and then I would abort the encode, not waiting for it to finish).

I use the muxer mp4box from command line, I didn't try the megui muxer.

[Doom9]

@Clown shoes: I'm using the December 17th build from Celticdruid and I have no problem muxing using mp4box and the same commandline you're using:

D:\>"C:\temp\MP4Box.exe" -add "D:\DVDs\THE_MATRIX_REVOLUTIONS_D1\xvid.mp4" -add "D:\DVDs\THE_MATRIX_REVOLUTIONS_D1\audio.mp4":lang=eng -new "D:\DVDs\THE_MATRIX_REVOLUTIONS_D1\review\matrix-xvid.mp4"
IsoMedia import - track ID 1 - Video (size 640 x 272)
IsoMedia import - track ID 1 - HE-AAC (SR 24000 - SBR-SR 48000 - 2 channels)
IsoMedia import - track ID 2 - media type "odsm:mp4s"
IsoMedia import - track ID 3 - media type "sdsm:mp4s"
Saving D:\DVDs\THE_MATRIX_REVOLUTIONS_D1\review\matrix-xvid.mp4: 0.500 secs Interleaving

Consequently, that also works in MeGUI. Can you please run a muxjob that gives you problems from the commandline and post the results? Here's the commandline I'd like you to run:
"E:\Downloads\mp4muxer\needed\MP4Box.exe" -add "I:\Transporter\Test\video.mp4" -add "I:\Transporter\Test\audio.mp4":lang=eng -new "I:\Transporter\Test\mux.mp4"

The error you have in the log is quite clear.. mp4box exits right away so I suspect something wrong with mp4box or the source files.

[Clown shoes]

I've only been working with .avi sources and that definately isn't fixed right now. It actually seems slightly worse for me right now, resulting in the 2nd pass crashing in MeGUI! No one else has confirmed this happening yet though. Could someone else test the same script on the same kind of length footage and post the results?

@Quake74

Could you try out the muxer in MeGUI?

[Clown shoes]

@Doom9

I will try, however command line muxing has not given me any problems so far.

It will be a few hours I'm afraid, as I will have to recreate my .mp4s.

UPDATE

Okay scratch the problem with MeGUI muxing. It turns out there was an issue with the version of MP4Box I was using and my command line was referencing a different version. The second I swapped them over, it worked perfectly. Sorry for any confusion. :o

[Sharktooth]

so what's the status?
@clownshoes: it crashes even with NiceFPS?!?!
also, could you use the CLI instead of MeGUI and post the complete x264 output when it crashes?

[Clown shoes]

No, there's no problems with nicefps() Only without. Will try with the CLI in a few hours, when I get home from work.

I've still had no confirmation that anyone else is having the same problem (The second pass actually crashing). Could someone else try to recreate the same enviroment?

[Sharktooth]

can you confirm you're using this UPDATED build: http://www.webalice.it/f.corriga/x264/x264-r388A_mp4patch.1.7z ?
(mp4patch.1)

[Clown shoes]

try this build: http://files.x264.nl/Sharktooth/force.php?file=./x264-r388A_mp4patch.7z

This is the build I have been working with. Is there any difference between the two?

[Sharktooth]

Yes A Big Difference:)
the first doesnt work... while the last should work!

[Clown shoes]

LOL. whoops. I'll get right on it.

[Sharktooth]

go go go!:)

[Sharktooth]

I had the slowdown problem with both avi and d2v sources. I will try with a feature length encoding in the next few days, but I'm pretty sure it's gone for me. The source I encoded this time used to take me more than 4 hrs (and then I would abort the encode, not waiting for it to finish).

I use the muxer mp4box from command line, I didn't try the megui muxer.
Is you mp4box up to date?
Use the latest celtic druid compile and report back.

[Clown shoes]

Okay, great news! My first test, while only a 20min video, settled into a 31fps encode and did not crash. However I will try with my 90min test video, the second I get home. It's looking good though!

[Sharktooth]

nice. let us know if it works and if there's something wrong with the mp4.

[bond]

Okay, great news! My first test, while only a 20min video, settled into a 31fps encode and did not crash. However I will try with my 90min test video, the second I get home. It's looking good though!would be important that you test the long movie with exactly (!) the same settings and source you used before that showed the slowdown with the old build :)

[Clown shoes]

Will do Bond. I could only get my hands on a 20min file at work, so I thought I would try that first.

[Sharktooth]

x264 r388B in the sticky incorporates the patch.

[quake74]

I have been playing with http://www.webalice.it/f.corriga/x264/x264-r388A_mp4patch.1.7z and I can also encode an avi file using avisource (same avs as clownshoes) in a reasonable amount of time. However I cannot play the output with mplayer and I have the same problem with mp4box: I cannot mux the mp4 file direcly, I have to extract the raw and mux that.

So, to reiterate, the slowdown problem for me is gone and x264 does not crash.

[Sharktooth]

are your mplayer and your mp4box up to date?

[bond]

I have been playing with http://www.webalice.it/f.corriga/x264/x264-r388A_mp4patch.1.7z and I can also encode an avi file using avisource (same avs as clownshoes) in a reasonable amount of time. However I cannot play the output with mplayer and I have the same problem with mp4box: I cannot mux the mp4 file direcly, I have to extract the raw and mux that.

So, to reiterate, the slowdown problem for me is gone and x264 does not crash.hm could be a timestamp problem

does this also happen on small clips? if yes, can you upload a small clip somewhere plz (eg rapidshare)

whats the exact .avs script you use? and whats the framerate of your input .avi?

[quake74]

hm could be a timestamp problem

does this also happen on small clips? if yes, can you upload a small clip somewhere plz (eg rapidshare)

whats the exact .avs script you use? and whats the framerate of your input .avi?

It does not happen with small clips. The avs's I used were

avisource("d:\coupling\coupling.avi")
Lanczos4Resize(368,208)
Changefps(29.97)
ConvertToYV12()

and

clip1 = mpeg2source("VTS_06_1.d2v")
clip1 = clip1.LanczosResize(368,208)
clip1 = clip1.changefps(29.97)
return clip1

and the sources are 25fps. I am using mp4box GPAC 0.4.1-DEV.
Tomorrow I'll try a different version of mp4box.

[bond]

thx, how many frames do the sources have?

and what are your exact encoding settings?

and are the two sources the same movie or different video?

[bond]

bingo :D

i reproduce the mplayer problem and there is indeed a bug in sharktooths mp4patch.1, as the created .mp4 is borked i created that way:

1) a pal dvd vob source, 25fps, 720x576, 7116 frames
2) input.avs:
LoadPlugin("C:\path to\DGDecode.dll")
mpeg2source("d:\path to\input.d2v")
trim(14,7129)
crop(0,82,720,416)
LanczosResize(640,256)
ChangeFPS(29.9)the changefps(29.9) leads to that the 7116 frames input becomes 8511 frames
3) x264 cmdl:
cmd /k x264.exe --bitrate 770 --bframe 3 --b-pyramid --ref 2 --no-cabac --nf --subme 3 --no-psnr --progress -o output.mp4 input.avs
now the timestamps are borked, which you will see when you use the following cmdl:
MP4Box -dts output.mp4there are negative cts and dts timestamps used which is not allowed (the same thing is shown by mplayer as seeable on the screenshot posted above)

other things:
- when using changefps(23.976) instead of changefps(29.9) there was no problem, but thats maybe also caused by the lower framenumber in that case
- i can mux aac audio from another .mp4 into that borked .mp4 with mp4box, but this doesnt fix the bad timestamps
- demuxing the avc stream to raw .264 and remuxing to .mp4 with mp4box fixes the timestamps
- when using the plain r388 compile made from svn without sharktooths patch, the cts/pts timestamps are also borked, but slightly differently then when using the patch
- i didnt notice any crash here in x264

[Sharktooth]

uhm... the problem is in the signed/unsigned stuff as haali said in #x264...
did you ask JLF if PTS is defined as a 64bit int? (im not at home and i cant check the sources).

[Clown shoes]

OK, I can now confirm the same. No crashes and no slowdown, however as Quake74 reported, files are unmuxable as .mp4 and unplayable in Media Player Classic. VLC player has no problems however.

Nearly there guys. Good work.

[Revgen]

This kind of reminds me of occasional issues that I have with Haali Media Splitter and FFDShow. Occasionaly my H264 .mp4's or .mkv's will play very slowly in WMP and I have to reboot my comp for the videos to play smoothly again. The issue never happens in VLC player.

In fact I just had it happen to me today.

It could just be a DirectShow issue.

[Sharktooth]

DS is another issue. The fact is the dts variable is defined as UNSIGNED 64bit integer in x264.
x264 produces the right DTS but dont know what happens after it's passed to gpac.
i checked isomedia.h and DTS is defined as unsigned 64bit int as well.
let's try with this new patch: http://www.webalice.it/f.corriga/x264/x264_mp4fix.2.diff
get r388C from the sticky and retry.

TRY IT AS SOON AS POSSIBLE, THANKS.

EDIT: however in libavformat both pts and dts are defined as int64 (signed)... it could lead to negative values...

[akupenguin]

however in libavformat both pts and dts are defined as int64 (signed)... it could lead to negative values...
Only if the value overflows 63 bits. And if that happens, then a 2x longer movie will overflow 64 bits, and unsigned won't help.
Also, while negative timestamps are forbidden in mp4, I don't see anything wrong with them in the abstract, and libavformat supports other containers that might allow them.

[bond]

uhm... the problem is in the signed/unsigned stuff as haali said in #x264...
did you ask JLF if PTS is defined as a 64bit int? (im not at home and i cant check the sources).http://sourceforge.net/tracker/index.php?func=detail&aid=1228921&group_id=84101&atid=571738

Only if the value overflows 63 bits. And if that happens, then a 2x longer movie will overflow 64 bits, and unsigned won't help.
Also, while negative timestamps are forbidden in mp4, I don't see anything wrong with them in the abstract, and libavformat supports other containers that might allow them.the values i got are not simply negative but are simply wrong
these are from the files i created as described above (~9000 frames)

i attached a file showing the dts/cts for sharktooths patch and svn

[akupenguin]

the values i got are not simply negative but are simply wrong
these are from the files i created as described above (~9000 frames)
Is it wrong when dts is int64, but correct when dts is uint64?

[quake74]

get r388C from the sticky and retry.


I did retry and I still have the same problem. Mplayer won't play it (same screenshot as before) and mp4box won't mux it. (I still have to update mp4box and mplayer to the latest releases though.)

EDIT: Tried with the 17/12/2005 18.03.34 mp4box from aziendeassociate and I have no mux problems anymore. Congrats to all!

[Sharktooth]

ok... lets get it right...
now dts and pts are written as unsigned 64bit int into the mp4.
any tool used to read them must support that format or it will display the wrong value.
im not sure mplayer gets this thing in the right way... maybe the devs should be informed of this "change".

[Sharktooth]

there could be another problem too...
static int set_eop_mp4( hnd_t handle, x264_picture_t *p_picture )
{
mp4_t *p_mp4 = (mp4_t *)handle;
uint64_t dts = (uint64_t)p_mp4->i_numframe * p_mp4->i_time_inc;
uint64_t pts = (uint64_t)p_picture->i_pts;
int offset = p_mp4->i_init_delay + pts - dts;

p_mp4->p_sample->IsRAP = p_picture->i_type == X264_TYPE_IDR ? 1 : 0;
p_mp4->p_sample->DTS = dts;
p_mp4->p_sample->CTS_Offset = offset;
gf_isom_add_sample(p_mp4->p_file, p_mp4->i_track, p_mp4->i_descidx, p_mp4->p_sample);

p_mp4->p_sample->dataLength = 0;
p_mp4->i_numframe++;

return 0;
}
code in red...
offset is defined as int and is the result of an operation between 64bit ints...
it can be overflowed as well... so it must be a 64bit int as well.
i'll patch that asap... but have to check the gpac source first.

[Sharktooth]

checked isomedia.h...
typedef struct
{
/*data size*/
u32 dataLength;
/*data with padding if requested*/
char *data;
/*decoding time*/
u64 DTS;
/*relative offset for composition if needed*/
u32 CTS_Offset;
/*Random Access Point flag - 1 is regular RAP (read/write) , 2 is SyncShadow (read mode only)*/
u8 IsRAP;
} GF_ISOSample;
so... CTS_offset must be a uint32_t in x264.c...
any ideas?

[akupenguin]

So make CTS_offset a uint32. What's the problem? CTS_offset is never more than about 2 frames, so for it to overflow 32 bits, you'd need fps_denom > 30 bits.

[bond]

when i look at the values in the 7z i attached its obvious that they are not correct, or am i wrong?

[Manao]

The soft you used to get them is bugged, the values are correct. You can't enter negative DTS in gpac, so if a negative value is printed, it means it's in fact a positive one that has overflowed because the soft doesn't support 64 bits timestamp.

Mplayer most probably suffers the same fate, while VLC doesn't.

Making CTS_Offset * 2 overflow is possible with a tweaked avs script. However, I still don't know whether the MP4 standard allows for offsets greater than 2^32.

[bond]

quake74 and clown shoes can you try to check if the audio muxing to the video .mp4 works with mpeg4ip's mp4creator?

The soft you used to get them is bugged, the values are correct. You can't enter negative DTS in gpac, so if a negative value is printed, it means it's in fact a positive one that has overflowed because the soft doesn't support 64 bits timestamp.interesting, i now tried reading out the timestamps with a tool from ateme and the values were shown correctly

ateme still shows the wrong dts/cts for the current svn compile, so svn is borked

i attached the new values derived with ateme

Mplayer most probably suffers the same fate, while VLC doesn't.quicktime7 also doesnt want to open such a file

is there a way to fix this without borking players and without this external nicefps() aso...?
not that i care about qt7 (mplayer can surely be fixed), but if there is an easy alternative...

[Clown shoes]

No probs Bond. I'll give it a try tonight.

[Sharktooth]

Wait a few minutes. New build with a new patch is coming.

new patch is here: http://www.webalice.it/f.corriga/x264/x264_mp4fix.3.diff

[Sharktooth]

quake74 and clown shoes can you try to check if the audio muxing to the video .mp4 works with mpeg4ip's mp4creator?

interesting, i now tried reading out the timestamps with a tool from ateme and the values were shown correctly

ateme still shows the wrong dts/cts for the current svn compile, so svn is borked

i attached the new values derived with ateme

quicktime7 also doesnt want to open such a file

is there a way to fix this without borking players and without this external nicefps() aso...?
not that i care about qt7 (mplayer can surely be fixed), but if there is an easy alternative...
this could be a problem...

[Sharktooth]

New builds are up. Please test them and report back.

[Sharktooth]

ok... 388F should contain the final patch.
everything is in respect of the MP4 specs.
So if it doesnt work with a particular app or parser, it's not x264 fault but the app/parser/whatever that is not compliant with the MP4 FF specs.

[bond]

so what has been changed in the latest patch?

[Sharktooth]

dts and pts are 64bit unsigned integers. cts offset is 32bit unsigned integer.
even if it's possible to still overflow the cts offset, the probability it happens is much lower than the previous dts overflow (tha's now fixed).
mplayer devs should be informed of those changes because the seem to have a bad mp4 implementation (i checked with bobololo the mp4 ff specs and they says dts and pts are infact 64bits).

edit: the final patch is here: http://www.webalice.it/f.corriga/x264/x264_mp4fix.4.diff

[Sharktooth]

ok, i tested an encoded mp4 (with qt profile and the latest mp4fix patch) in quicktime 7.03 and it works :)

edit: works with gpac, mpc mp4 splitter, ateme splitter, haali splitter, vlc, any other DirectShow player but not with mplayer.

edit2: it turned out my mplayer compile was broken. i just updated it and it works like a charme:)

[Doom9]

mplayer needs to be fixed (b0rked mp4 support).Hmm, I wonder how much such feedback is appreciated by developers who consider mp4 the worst container on the planet ;)

[Sharktooth]

nono..it was my mplayer compile that was broken...
it works :)
edit2: it turned out my mplayer compile was broken. i just updated it and it works like a charme:)
i couldnt test 29.97 fps stuff though.

[Sharktooth]

ok, further investigations leaded to the fact QT and Mplayer are effectively complaining for those encodes made with some particular and rare (not all) 29.97 FPS sources (the ones that made x264 crash or slowdown) but not for the rest of the encodes.

So the first impressions were true, QT and Mplayer could have problems playing that stuff coz they do not support 64bit dts and pts, but they play the rest of the stuff correctly even if it was generated with the patched x264.
The problem of those players can still be fixed by adding the nicefps() filter before encoding.

So the mp4fix.4 patch seems to be pretty safe.

EDIT: didnt test PSPs and iPods, and dont know if they support 64bit dts/pts but if there willl be problems they will happen only on some rare 29.97 fps sources and can be fixed with nicefps() as well.

[Clown shoes]

encodes made with some particular and rare (not all) 29.97 FPS sources (the ones that made x264 crash or slowdown)

It appeared to be everything that I encoded slowed down or crashed. 29.97fps and 23.976fps. So would it be best for me to always use nicefps()? Or is there a way I might be able to tell what will or won't work?

Is it at all relevant that all my encodes are for the PSP?

[bond]

It appeared to be everything that I encoded slowed down or crashed. 29.97fps and 23.976fps. So would it be best for me to always use nicefps()? Or is there a way I might be able to tell what will or won't work?no, generally you dont need nicefps(), this whole discussion was done for fixing the issues :)
best would be if you could try encoding again with the settings and sources you know for sure crashed/sloweddown before and test if its now fixed (including the audio muxing problem)

Is it at all relevant that all my encodes are for the PSP? after you did the encode you can try if it works on the psp. obviously it will work, unless there is a bug in the psp (which i now dont assume, till prooven otherwise)

all it takes is someone testing it :)

[Sharktooth]

It appeared to be everything that I encoded slowed down or crashed. 29.97fps and 23.976fps. So would it be best for me to always use nicefps()? Or is there a way I might be able to tell what will or won't work?

Is it at all relevant that all my encodes are for the PSP?
It happens coz you use ChangeFPS() filter. Avisynth imposes high dwscale/dwrate values when using floating point values for FPS...
The issue in x264 IS fixed in my last build and rev 389 but some players (mplayer & quicktime) are not perfectly compliant with the latest mp4 file format specs and may refuse to play those mp4s (only those which have been problematic in the previous builds).
If you want to "restore" compatibility with those player, you can add NiceFPS() to your script. It will approximate those dwscale/dwrate to a lower value but the desynch will be almost unnoticeable for standard movie lenght (1.30/2 hours) encodes.

[bond]

The issue IS fixes with my last build but some players (mplayer & quicktime) are not perfectly compliant with the latest mp4 file format specs and can refuse to play those mp4s.indeed, i now checked it more closely in quicktime and mplayer:

my finding was that there are two components influencing qt and one for mplayer:

1) its allowed to use 64bit for the duration and creation/modificationtime in the mdhd atom (storing the timescale and duration) in mp4. when using 64bit that way, its indicated by setting the "version" flag to 1 (opposed to 0) and x264 does this correctly

qt doesnt seem to handle files having version = 1 set and shows the "error -2002" message on those files not wanting to open them. when changing the version flag to 0 with a hexeditor qt opens the file without errormessage but doesnt play it (see 2) )
mplayer doesnt care about that flag it seems

2) the useage of 64bit seems to lead to that the creation/modification time written into the mdhd atom before the timescale gets bigger (64bit). now this leads to that, for a 32bit-only player, the info seems to be moved and the language and duration flags have a wrong info stored and the timescale is identified as being 0 in tools not handling 64bit (this is seeable in apple's dumpster tool which also doesnt seem to handle 64bit)

the timescale being identified as 0 leads to that mplayer cant calculate a fps and therefore displays the "missing fps" message and doesnt display any video. i guess the wrong duration also causes this "warning length=-..." message
in qt it leads to that simply nothing is displayed ("whitescreen of death"), after the version flag has been set to 0
editing the timescale in dumpster to something non-0, makes mplayer and qt play the file


so these are issues caused by mplayer and qt7. x264's files seem to be correct regarding this

[bond]

there is another bug in qt7:

it doesnt seem to handle high duration values. it doesnt seem to be a lack of 64bit support as it also happens with 32bit durations

[Sharktooth]

CrapTime...

[Clown shoes]

Good work guys. True professionals.

Merry xmas, one and all.

[quake74]

Merry Christmas to all!

I can indeed confirm that (using the 389 sharktooth build) I can seek in the files using vlc and mpc. I cannot read them using mplayer unless I'm using the nicefps in the avs. I don't have my psp with me these days, I'll report back when I can.

[bond]

is this audio muxing thingie now also fixed?

[Clown shoes]

Hmm, crap. Problems not solved for me at all!!

I just encoded a two hour feature with this script;

avisource("E:\Serenity.avi")
Lanczos4Resize(368,144)
Addborders(0,32,0,32)
Changefps(23.976)


The film encoded to .mp4 with no problem or major slowdown on the second pass (interestingly though the first pass was about 30fps, about half it's normal speed) The MeGUI log was as follows;

Log for job job1-1

avis [info]: 368x208 @ 23.98 fps (171252 frames)
x264 [info]: using cpu capabilities MMX MMXEXT SSE SSE2
x264 [info]: slice I:687 Avg QP:14.15 size: 12183
x264 [info]: slice P:170565 Avg QP:16.96 size: 3596
x264 [info]: mb I I16..4: 42.6% 0.0% 57.4%
x264 [info]: mb P I16..4: 6.4% 0.0% 0.0% P16..4: 56.5% 0.0% 0.0% 0.0% 0.0% skip:37.1%
x264 [info]: final ratefactor: 17.95
x264 [info]: kb/s:696.4

Actual bitrate after encoding without container overhead: 696.39

-------------------------------------------------------------------------
job job1-1 has been processed. This job is linked to the next job: job1-2
Next job job1-2 is a video job. encoder commandline:
"E:\Downloads\x264-Lite_r389\x264.exe" --pass 2 --bitrate 727 --stats "I:\MP4 output\video.stats" --ref 3 --subme 6 --trellis 1 --analyse p8x8,b8x8,i4x4,p4x4 --direct none --zones 163576,171251,q=40 --progress --no-psnr --output "I:\MP4 output\video.mp4" "I:\MP4 output\video.avs"
successfully set up video encoder and callbacks for job job1-2
-------------------------------------------------------------------------
Log for job job1-2

avis [info]: 368x208 @ 23.98 fps (171252 frames)
x264 [info]: using cpu capabilities MMX MMXEXT SSE SSE2
mp4 [info]: initial delay 0 (scale 12570329)
x264 [info]: slice I:687 Avg QP:14.66 size: 11613
x264 [info]: slice P:170565 Avg QP:16.10 size: 3759
x264 [info]: mb I I16..4: 48.7% 0.0% 51.3%
x264 [info]: mb P I16..4: 2.8% 0.0% 4.0% P16..4: 33.6% 11.1% 9.1% 1.4% 1.1% skip:37.0%
x264 [info]: ref P 81.2% 13.0% 5.7%
x264 [info]: kb/s:727.0

Actual bitrate after encoding without container overhead: 726.99
desired video bitrate of this job: 727 kbit/s - obtained video bitrate: 727.808653420765 kbit/s
------------------------------------------------------------------
Next job job2 is an audio job. besweet commandline:
"C:\Program Files\BeLight\BeSweet.exe" -core( -input "E:\audio.wav" -output "I:\MP4 output\audio.mp4" -logfile "I:\MP4 output\audio.besweet.log" ) -dimzon( -dllname bse_FAAC.dll -q 128 ) -ota( -g max )
successfully set up audio encoder and callbacks for job job2
---------------------------------------------------------------
Log for job job2

besweet: "C:\Program Files\BeLight\BeSweet.exe" -core( -input "E:\audio.wav" -output "I:\MP4 output\audio.mp4" -logfile "I:\MP4 output\audio.besweet.log" ) -dimzon( -dllname bse_FAAC.dll -q 128 ) -ota( -g max )

BeSweet v1.5b31 by DSPguru.
--------------------------

[00:00:00:000] Initializing...
[00:00:00:000] -- Initializing...

[01:59:02:560] |

[01:59:02:560] Finalizing...
[01:59:02:560] Conversion Completed !

Visit DSPguru's Homepage at :
http://DSPguru.doom9.net/

---------------------------------------------------------


The video was only playable in VLC player. Neither Mplayer classic or QT were able to play it.

The real problem though was when it came to muxing. MeGUI froze at 6% with the time remaining counter stuck at 1.28 minutes. I then tried muxing with Mp4Box in command line, but that froze at 6% and to add insult to injury caused a blue screen of death!!

So in summary, the last few builds of x264 do not have the slowdown or crash
problem for me, but they are unmuxable.

[bond]

The video was only playable in VLC player. Neither Mplayer classic or QT were able to play it.yes, thats the discussed problem in mplayer and qt

the files are spec compliant (its allowed to use 64bit timestamps, its just that qt and mplayer dont handle them)

The real problem though was when it came to muxing. MeGUI froze at 6% with the time remaining counter stuck at 1.28 minutes. I then tried muxing with Mp4Box in command line, but that froze at 6% and to add insult to injury caused a blue screen of death!!this might be a bug in mp4box, make sure you use the new compile from celtic_druid

plz also try muxing the audio with mp4creator and report if that works

[Clown shoes]

Hmm, not sure what relevance this may have, but I repeated the same process. The only difference being that I removed the changefps() line from my .avs script and everything worked perfectly. Mpalyer classic, QT and the muxing. The encoding in MeGUI was back to it's normal speed as well.

[raymod2]

the files are spec compliant (its allowed to use 64bit timestamps, its just that qt and mplayer dont handle them)


If some players have problems with 64-bit timestamps then why not give the user the option of using 32-bit timestamps? Who needs 64-bit precision anyways?

[bond]

If some players have problems with 64-bit timestamps then why not give the user the option of using 32-bit timestamps? Who needs 64-bit precision anyways?Hmm, not sure what relevance this may have, but I repeated the same process. The only difference being that I removed the changefps() line from my .avs script and everything worked perfectly. Mpalyer classic, QT and the muxing. The encoding in MeGUI was back to it's normal speed as well.the problem here is that avisynths changefps(23.976) or changefps(29.97) uses values that simply need 64bit precision on long files, therefore there is no choice to offer the user 32bit

nicefps() simply modifies the output of changefps(23.976) so the avs script doesnt output values needing 64bit anymore
another way would be to use changefps(24000,1001) for 23.976 or changefps(30000,1001) for 29.97, as this also outputs not 64bit needing values
all this has been discussed already

the same goes for assumefps()

so to say the problem is avisynth's change/assumefps() function outputting too big values when used directly with a framerate like 23.976.
if someone would change this behaviour of the function in avisynth things would work also in players not fully supporting the mp4 specs (qt and mplayer)

edit: made a feature request to the avs devs here (http://forum.doom9.org/showthread.php?t=104681), lets hope they will listen :)

[Sharktooth]

the problem here is that avisynths changefps(23.976) or changefps(29.97) uses values that simply need 64bit precision on long files, therefore there is no choice to offer the user 32bit

nicefps() simply modifies the output of changefps(23.976) so the avs script doesnt output values needing 64bit anymore
another way would be to use changefps(24000,1001) for 23.976 or changefps(30000,1001) for 29.97, as this also outputs not 64bit needing values
all this has been discussed already
Yes it does!! to not get high dwscale/rate the correct ones are (29970,1000) and (23976,1000). but that's an approximation as well.
the same goes for assumefps()

so to say the problem is avisynth's change/assumefps() function outputting too big values when used directly with a framerate like 23.976.
if someone would change this behaviour of the function in avisynth things would work also in players not fully supporting the mp4 specs (qt and mplayer)

edit: made a feature request to the avs devs here (http://forum.doom9.org/showthread.php?t=104681), lets hope they will listen :)
If some players have problems with 64-bit timestamps then why not give the user the option of using 32-bit timestamps? Who needs 64-bit precision anyways?
However you can always add NiceFPS() to your avisynth script and the encode will work on players that doesnt support this new format (mplayer, quicktime).

[Doom9]

if someone would change this behaviour of the function in avisynth things would work also in players not fully supporting the mp4 specs (qt and mplayer)
so in order to fix a problem that derives from a broken implementation you break another piece of software? That's broken logic. This is just another example of which player you should not use.

[Sharktooth]

Doom9: no... i fixed x264 to be compilant with the mp4 FF.
players like QT and mplayer does not handle the latest mp4 FF, so it's not a x264 problem.
however the compatibility with those players can be "restored" if avisynth generates lower precision FPS values (still enaugh to not desynch though) or by adding the famous NiceFPS().
I repeat, the problem with those players happens only when FPS are generated thru the 24000/1001 or 30000/1001 formula and not approximated to 23.976 or 29.97 (avisynth uses full precision that's close to the periodic 23.976023976023976023976... and 29.97002997002997002997...).

[Doom9]

I never said x264 was broken.. mplayer and QT are.. so they should be fixed, instead of changing AviSynth.

[Sharktooth]

sorry, i did not understood what you meant.
However the new mp4 ff may create problems to all the mplayer based solutions such as XBMC, GeexBox, MediaPortal, etc.
Mplayer devs should be informed.

[Doom9]

Mplayer devs should be informed.The people who *know" mp4 is the worst container on the planet? Expect a warm welcome ;)

[raymod2]

@bond: I don't think that changing avisynth will solve the problem of players that do not like 64-bit time stamps. I have a script that does not use changefps() or assumefps(). It simply passes the fps from the original AVI file (a 29.97 fps DV capture). The resulting output file plays fine but I can't seek past 7 minutes using BSPlayer v1.37 or Media Player Classic v6.4.8.4. If I try to seek past 7 minutes the player just locks up or jumps back to the beginning of the clip.

The problem goes away if I do either:

1) Play the file using VLC media player 0.8.4.a.
2) Remux the file as follows:
mp4box video.mp4 -raw 1
mp4box -add video_track1.h264 -fps 29.97 fixed.mp4

I noticed that the TimeScale reported by mp4box was originally 10000000. When I remux using the commands above I get a TimeScale of 30000.

[foxyshadis]

Yes, but at least this way avisynth wouldn't be contributing to the problem, especially since some players/NLEs/encoders are simply dead and can't be fixed. It should make life easier for people, not disruptive; in the meantime you can push more developers to support it. :p

[bond]

@bond: I don't think that changing avisynth will solve the problem of players that do not like 64-bit time stamps. I have a script that does not use changefps() or assumefps(). It simply passes the fps from the original AVI file (a 29.97 fps DV capture). The resulting output file plays fine but I can't seek past 7 minutes using BSPlayer v1.37 or Media Player Classic v6.4.8.4. If I try to seek past 7 minutes the player just locks up or jumps back to the beginning of the clip.

The problem goes away if I do either:

1) Play the file using VLC media player 0.8.4.a.
2) Remux the file as follows:
mp4box video.mp4 -raw 1
mp4box -add video_track1.h264 -fps 29.97 fixed.mp4

I noticed that the TimeScale reported by mp4box was originally 10000000. When I remux using the commands above I get a TimeScale of 30000.can your run mp4dump from mpeg4ip over the .mp4 that shows this seeking problem and attached the output plz

[raymod2]

can your run mp4dump from mpeg4ip over the .mp4 that shows this seeking problem and attached the output plz

@bond: Since the seeking problem is different from the encoder slowdown problem I started a new thread for it. I have posted the info you requested there:

http://forum.doom9.org/showthread.php?p=762412#post762412