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

MeteorRain · 24th September 2005, 17:37

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 add assumefps(2997,125) if your clip is @ 23.976fps (in fact, you can also use 24000,1001 to get @ ~23.976024)

EDIT:

If you are going to fix the fps, please use one of the following:

Code:

assumefps(30000,1001) #29.970
assumefps(24000,1001) #23.976

The original code above will produce non-standard fps rate and thus is not recommended. Use the new code instead.

(Although it has been 8 years since I wrote this post, I still want to correct this error because this post is linked from the x264 FAQ post.)

Sirber · 24th September 2005, 18:52

Quote:

Originally Posted by MeteorRain

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 · 25th September 2005, 00:21

Quote:

Originally Posted by Sirber

So it's AVISynth that provide extremely large dwRate and dwScale?

avisynth reads the information from avifile =. =

bugsan · 25th September 2005, 04:03

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

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

Sharktooth · 25th September 2005, 13:47

rev300 should fix the FPS issue.

akupenguin · 25th September 2005, 21:51

Quote:

Originally Posted by Sharktooth

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.

Sharktooth · 26th September 2005, 12:51

Quote:

Originally Posted by akupenguin

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...

bugsan · 25th September 2005, 14:44

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

Code:

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 · 25th September 2005, 15:11

Good work guys on that bug

Doom9 · 25th September 2005, 22:29

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

akupenguin · 26th September 2005, 17:15

I fixed a crash in the version you posted.

bob0r · 26th September 2005, 17:31

Quote:

Originally Posted by akupenguin

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

)

Sharktooth · 26th September 2005, 18:05

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

eMotionEstimation · 28th September 2005, 12:42

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 · 28th September 2005, 12:45

n1

MeteorRain · 29th September 2005, 02:47

Quote:

Originally Posted by eMotionEstimation

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

But i think statements in a x264-gui would be more convenient

(eg. a check routine in MeGUI

)

eMotionEstimation · 29th September 2005, 07:31

Quote:

Originally Posted by MeteorRain

...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 · 29th September 2005, 12:39

Quote:

Originally Posted by eMotionEstimation

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 · 28th September 2005, 12:51

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

bob0r · 28th September 2005, 13:05

@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!

24th September 2005, 17:37	#1 \| Link
MeteorRain 結城有紀 Join Date: Dec 2003 Location: NJ; OR; Shanghai Posts: 894	An easy way to prevent borked x264-in-mp4 file 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 add assumefps(2997,125) if your clip is @ 23.976fps (in fact, you can also use 24000,1001 to get @ ~23.976024) EDIT: If you are going to fix the fps, please use one of the following: Code: assumefps(30000,1001) #29.970 assumefps(24000,1001) #23.976 The original code above will produce non-standard fps rate and thus is not recommended. Use the new code instead. (Although it has been 8 years since I wrote this post, I still want to correct this error because this post is linked from the x264 FAQ post.) Last edited by MeteorRain; 5th August 2013 at 19:49. Reason: Fix an error on assumefps code

25th September 2005, 13:47	#5 \| Link
Sharktooth Mr. Sandman Join Date: Sep 2003 Location: Haddonfield, IL Posts: 11,768	rev300 should fix the FPS issue. __________________ MPEG-4 ASP Custom Matrices: EQM V1(old), EQM AutoGK Sharpmatrix (aka EQM V2), EQM V3HR (updated 01/10/2004), EQM V3LR, EQM V3ULR (updated 04/02/2005), EQM V3UHR (updated 17/12/2004) and EQM V3EHR (updated 05/10/2004) Info about my ASP matrices. MPEG-4 AVC Custom Matrices: EQM AVC-HR Info about my AVC matrices My x264 builds. Mooo!!!

25th September 2005, 15:11	#9 \| Link
Sirber retired developer Join Date: Oct 2002 Location: Canada Posts: 8,978	Good work guys on that bug __________________ Detritus Software

25th September 2005, 22:29	#10 \| Link
Doom9 clueless n00b Join Date: Oct 2001 Location: somewhere over the rainbow Posts: 10,579	adding assumefps(3.142) to a perfectly fine script also creates corrupt mp4 output with revision 300.. __________________ For the web's most comprehensive collection of DVD backup guides go to www.doom9.org

26th September 2005, 18:05	#13 \| Link
Sharktooth Mr. Sandman Join Date: Sep 2003 Location: Haddonfield, IL Posts: 11,768	ok... i thought jarod was referring to the encoder crash due to the overflow generated by the dwscale... just a misunderstanding:P __________________ MPEG-4 ASP Custom Matrices: EQM V1(old), EQM AutoGK Sharpmatrix (aka EQM V2), EQM V3HR (updated 01/10/2004), EQM V3LR, EQM V3ULR (updated 04/02/2005), EQM V3UHR (updated 17/12/2004) and EQM V3EHR (updated 05/10/2004) Info about my ASP matrices. MPEG-4 AVC Custom Matrices: EQM AVC-HR Info about my AVC matrices My x264 builds. Mooo!!!

25th September 2005, 04:03	#4 \| Link
bugsan Registered User Join Date: Apr 2003 Posts: 24	it works !!! assumefps(2997,100) # for 29.97 contents i was using assumefps(29.97), it was wrong... ^^

26th September 2005, 17:15	#11 \| Link
akupenguin x264 developer Join Date: Sep 2004 Posts: 2,392	I fixed a crash in the version you posted.

28th September 2005, 12:45	#15 \| Link
Sharktooth Mr. Sandman Join Date: Sep 2003 Location: Haddonfield, IL Posts: 11,768	n1 __________________ MPEG-4 ASP Custom Matrices: EQM V1(old), EQM AutoGK Sharpmatrix (aka EQM V2), EQM V3HR (updated 01/10/2004), EQM V3LR, EQM V3ULR (updated 04/02/2005), EQM V3UHR (updated 17/12/2004) and EQM V3EHR (updated 05/10/2004) Info about my ASP matrices. MPEG-4 AVC Custom Matrices: EQM AVC-HR Info about my AVC matrices My x264 builds. Mooo!!!

28th September 2005, 12:51	#19 \| Link
Sirber retired developer Join Date: Oct 2002 Location: Canada Posts: 8,978	Gonna add it to my softs once it's approved. Nice work! __________________ Detritus Software

28th September 2005, 13:05	#20 \| Link
bob0r Pain and suffering Join Date: Jul 2002 Posts: 1,337	@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!

Thread Tools	Search this Thread
Show Printable Version Email this Page	Search this Thread: Advanced Search
Display Modes
Switch to Linear Mode Hybrid Mode Switch to Threaded Mode