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

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