An easy way to prevent borked x264-in-mp4 file

[MeteorRain]

The problem has been mentioned in thread x264 mp4 output borked (rev 295)

I just found an easy way to prevent the extremely large dwRate and dwScale:
at the bottom of your avs script, simply addassumefps(2997,125)if your clip is @ 23.976fps (in fact, you can also use 24000,1001 to get @ ~23.976024)

for other fpses, just change both the numbers, and everything will go well, i think ;)

BTW, simply write assumefps(23.976) won't give you any good things...

Discussion welcomed.

Good luck,
MR

[Sirber]

BTW, simply write assumefps(23.976) won't give you any good things...So it's AVISynth that provide extremely large dwRate and dwScale?

[MeteorRain]

So it's AVISynth that provide extremely large dwRate and dwScale?
avisynth reads the information from avifile =. =

[bugsan]

it works !!!
assumefps(2997,100) # for 29.97 contents

i was using assumefps(29.97), it was wrong... ^^
:)

[Sharktooth]

rev300 should fix the FPS issue.

[bugsan]

damn... -1670.82 kb/s -_-
and the line above there is "kb/s:345.6"

D:\GITS>"c:\program files\x264\x264.exe" --progress --pass 1 --stats "\x264.stat
s" --subme 3 --ref 8 --threads 1 --filter 0:0 --keyint 250 --min-keyint 25 --sce
necut 40 --qpmin 10 --qpmax 51 --qpstep 4 --direct temporal --me hex --merange 1
6 --bframes 2 --weightb --b-bias 0 --ipratio 1.40 --pbratio 1.30 --qcomp 0.60 --
analyse p8x8,i8x8,i4x4 --8x8dct -o "D:\GITS\gits_movie.mp4" "D:\GITS\gits_movie.
avs"
avis [info]: 848x464 @ 29.97 fps (35584 frames)
x264 [info]: using cpu capabilities MMX MMXEXT SSE 3DNow!
mp4 [info]: initial delay 100 (scale 2997)
x264 [info]: slice I:330 Avg QP:23.00 Avg size: 21701 PSNR Mean Y:44.63 U:48.66
V:49.44 Avg:45.61 Global:45.17
x264 [info]: slice P:14663 Avg QP:26.00 Avg size: 2472 PSNR Mean Y:42.73 U:47.3
6 V:48.19 Avg:43.81 Global:43.47
x264 [info]: slice B:20591 Avg QP:28.00 Avg size: 383 PSNR Mean Y:42.79 U:47.5
0 V:48.33 Avg:43.89 Global:43.55
x264 [info]: slice I Avg I4x4:33.4% I8x8:31.1% I16x16:35.5%
x264 [info]: slice P Avg I4x4:1.9% I8x8:2.3% I16x16:3.2% P:12.3% P8x8:1.0%
PSKIP:79.3%
x264 [info]: slice B Avg I4x4:0.2% I8x8:0.3% I16x16:0.3% P:8.0% B:0.5% B8
x8:0.0% DIRECT:0.3% BSKIP:90.4%
x264 [info]: 8x8 transform intra:32.1% inter:35.0%
x264 [info]: PSNR Mean Y:42.78 U:47.46 V:48.28 Avg:43.87 Global:43.53 kb/s:345.6


encoded 35584 frames, 9.04 fps, -1670.82 kb/s

[Sirber]

Good work guys on that bug :D

[akupenguin]

rev300 should fix the FPS issue.
How so? If the bug is in GPAC, it wasn't fixed in 0.4x, so updating didn't help. and 295->300 didn't change anything else remotely related.

[Doom9]

adding assumefps(3.142) to a perfectly fine script also creates corrupt mp4 output with revision 300..

[Sharktooth]

How so? If the bug is in GPAC, it wasn't fixed in 0.4x, so updating didn't help. and 295->300 didn't change anything else remotely related.
uhm... i didnt check the code changes but jarod said you fixed the gpac patch before committing it to the SVN, so i assumed you did...

[akupenguin]

I fixed a crash in the version you posted.

[bob0r]

I fixed a crash in the version you posted.

revision 299:
MP4 output: update to GPAC 0.4 API.
patch mostly by Robert Swain.

Just to be clear ( and free of blame :goodpost: )

[Sharktooth]

ok... i thought jarod was referring to the encoder crash due to the overflow generated by the dwscale...
just a misunderstanding:P

[eMotionEstimation]

Hello everyone!

I wrote a little Avisynth Filter that takes care of the too big scale and rate problem.

The filter's function name is "NiceFPS(int x)". x is the maximum new scale (by default 5000) that the function is allowed to use for approximating the original FPS. It chooses the new rate and scale in a way that the resulting rate/scale is as close (or equal) to the original FPS as possible. Do not set x too high - the default value is good enough and the new FPS is most of the time 1/1.000.000 or less away from the original fps. So you WON'T notice any sync issues.

example AVS-Script:
-----------------------
loadplugin("nicefps.dll")
avisource("movie.avi")
...
nicefps()
-----------------------

I hope you'll find this little filter useful. Feedback is welcome.

Wishes, Chris

[Sharktooth]

n1 :)

[Sirber]

Gonna add it to my softs once it's approved. Nice work! :D

[bob0r]

@eMotionEstimation

Can you email me the file to eMotionEstimation [at] x264 .nl ?
I'll host it online.

Then lets encode some 29.97 x264 .mp4! :)

[eMotionEstimation]

@bob0r

You got mail, hopefully! damn yahoo...

[bob0r]

@bob0r

You got mail, hopefully! damn yahoo...

:D

http://mirror05.x264.nl/eMotionEstimation/nicefps.zip

[eMotionEstimation]

edit: Too slow...I'm getting old. :D

[MeteorRain]

Hello everyone!

I wrote a little Avisynth Filter that takes care of the too big scale and rate problem.
I hope you'll find this little filter useful. Feedback is welcome.

Wishes, Chris
Good job :D

But i think statements in a x264-gui would be more convenient ;) (eg. a check routine in MeGUI ;))

[eMotionEstimation]

...But i think statements in a x264-gui would be more convenient (eg. a check routine in MeGUI )
I don't think it would be better to adjust a specific GUI (btw. which could be a lot more work than writing a little avisynth filter). From my understanding it's like that.

Say you've got a file which has (250.000.000/10.000.001=) 24.9999975 FPS which is somehow "borked" but plays back perfectly fine - the file itself even IS perfectly fine. There's nothing wrong with that scale and rate. But x264 CLI has problems with scale/rates that big. My Avisynth-filter would've automatically changed the FPS to be exactly 25/1 FPS (or something else depending on the max scale you allow it) and x264 would've encoded fine. If the FPS aren't patholigic the filter doesn't change anything. So you can just "throw" the filter at every file and you don't have to care for scale/rate anymore which I think is a good thing (the filter just passes frames thorugh -> no speed loss).

If you change a specific GUI then a "borked" input file would encode perfectly fine in it. But if you just use another GUI that hasn't been changed the encode would be broken again.

The best thing is to fix x264 CLI - works with every GUI. My filter is just a temporary solution until x264 CLI has been fixed.

wishes, Chris

[MeteorRain]

The best thing is to fix x264 CLI - works with every GUI. My filter is just a temporary solution until x264 CLI has been fixed.

wishes, Chris
Let's wait for an x264 patch ;)

[Sirber]

Can someone approve the ZIP? Thanks!

[eMotionEstimation]

Let's wait for an x264 patchIf you don't want to use the filter you'll have to wait or set the FPS manually. ;)

Can someone approve the ZIP? Thanks!Why don't you just download the file from Bob0r's link a few posts above? ;)

Has anybody tested the filter on pathological files? Does it work for you, too?

bye, Chris

[MeteorRain]

If you don't want to use the filter you'll have to wait or set the FPS manually. ;)
Well, IMHO, add 2 lines in an avs file is more inconvenient than simply add an assumefps().
The simplest way is to solve the problem in x264, or append the function automatically by x264-guis

[eMotionEstimation]

But you'll have to adjust assumefps manually for every single movie - at least if they all don't have the same frame rate. x264 CLI has problems with all (not only ~29.97fps) files that have a too big scale (and there's no x with x|scale and x|rate). The filter "fixes" all those files automatically. This is handy if you're coding a automated GUI - like I do. You don't want to bother the user with questions, "this file's encode may turn out to be broken - to be sure it isn't please enter a nice framerate"! I had this problem so I wrote the filter to automate that process. (I still don't get why manually setting FPS is more convenient than automatically, but... *sigh*)

chris

[Doom9]

I have validated the filter.. hope it works for you. I'm reluctant to incorporate this, or any workaround for that matter to fix problems others should take care of. Widespread problems with AVI input may actually help speed up the bugfixing process ;)
The fact remains while those files are valid and playable, and x264 should get a fix to handle them, they are nontheless weird and likely you have done something you shouldn't have to get such files (playing with the framerate is just one, unnecessary container conversions (keep in mind mp4 importing can drop nvops, just as an example) is another possible cause for this).

[MeteorRain]

(I still don't get why manually setting FPS is more convenient than automatically, but... *sigh*)
chris
because i only compress anime @ 23.976fps:o

[Sirber]

NiceFPS will has been added to RealAnime LE. Thanks! :D

[bond]

anyone tried remuxing such an input .avi causing problems with .mp4 output in x264 with mp4box to .mp4?
does it work? if yes, the bug might be in x264 and not in gpac (afaik its still not known what really causes the problem!?)

[stephanV]

the problem is an overflow as Haali stated here (http://forum.doom9.org/showpost.php?p=713675&postcount=119)
So eventually this will happen for all scale values, given that the files have enough frames.

As leowai reported (http://forum.doom9.org/showpost.php?p=714894&postcount=141) that muxing from raw does work, the bug is most likely in x264's gpac support code.

[Sharktooth]

GPAC had similar problems in earlier versions but AFAIK it has been already fixed.