Encoding bug in x264 r1732?

[Dal]

Hi.

I'm not sure if this is the right place to report a potential bug, or even how to explain it, but here goes:

I use MeGui to encode various recorded tv episodes. But after running an update that updates x264 to r1732, I have experienced errors with the (mp4)-output I make with x264.
First time I run the output in a player, it seems to play correctly. If I stop and start the file, the beginning of the playback (at 0:00 time), is suddenly several minutes into the file.
When I mux the mp4 file into a mkv file, this problem is present all the time: the start time says 0:00, but the playback starts several minutes into the file.
It's kinda hard to explain, so I uploaded the file here (gaasdal.net/web-pics/x264-error.mp4), so you can see for yourselves.
I always make two ouputs of my recordings, one mp4 file, and one avi file. The avi file seems completely OK.
I also make several files every week, so the error must have started occuring with r1732.

The MeGui presets I use looks like this:
x264: program --level 3.1 --preset slow --pass 2 --bitrate 1514 --stats ".stats" --vbv-bufsize 14000 --vbv-maxrate 17500 --output "output" "input"
XVid: XVid: 2pass HQ (no Qpel)

Any ideas?

Thank you.

[Alf Bundy]

Same problem here since r1732. Output in .mp4 plays fine (latest Kurtnoise's mp4box build), but once muxed with mkvmerge 4.3.0 the video starts with a frozen frame (but not frame 1).

With a 5 min video, first frozen frame displayed is from about 10 sec into the video.
With a 1h30 video, first frozen frame displayed is from about 3min into the video.

The frame remains frozen until it reaches its normal timecode (so 10 sec or 3 min)
The audio track is cutted accordingly (it matches the frame from 10 sec or 3 min into the video), but plays normally from the beginning. So when the video finally unfreeze, there is a huge audio-video delay.


mkvmerge throws a warning for the x264 video track:
Warning: 'E:\F1GP\F1GP - 2010-10-10 - Suzuka.mp4': This file contains at least one frame with a negative timecode. All timecodes will be adjusted by 00:00:00.040 so that none is negative anymore.(this is the video with the frozen frame from 3 min into the file. And the problem is way more than the indicated 40ms negative timecode)


I know it sounds like a problem from mkvmerge, but I don't know where to report this to mkvmerge's author.
And it would be easier to report anyway if someone could spot a cause for this in r1732.

Sorry for my english, I did the best I could. :o

[Dal]

I know it sounds like a problem from mkvmerge, <snip>
It is not, at least not for me.
I have the same problem in the mp4 file alone, it just that the behaviour is a little different when muxed.
Just download the file I linked to, and see for yourself.

[Dal]

Update: tried r1745, same problem.
Going back to the latest version MeGui had, v1724, to double check.

[Alf Bundy]

Which version of MP4box is used in your MeGUI ?
Mine is the latest build from Kurtnoise (2010-09-30) and the problem does not occur in .mp4, only when muxed with mkvmerge 4.3.0 (also from 2010-09-30).

I tried with latest r1745, same problem : fine in .mp4 but wrong in .mkv

I don't have previous x264 build used by MeGUI anymore (r.172x something), but if someone could point me to where I can download older builds,
I would be glad to test which build introduced incompatibility with mkvmerge and older builds of mp4box.

[Dal]

mp4box is 2010.09.30.
But it seems our problems are not entirely similar, since I have the problem with the mp4 file too.
Have you tried to stop the file in the player, and the press play again. When I do that the video starts a few minutes into the file. It is always the same place, though.

You can download older versions from here: http://megui.org/auto/

[Dal]

Did an encoding now with r1724, and the problem seems to be completely gone..
But of course, this could just as much have something to do with the MeGui x264 presets as with x264 itself.

Some input from the people in charge is appreciated :)

[Alf Bundy]

mp4box is 2010.09.30.
But it seems our problems are not entirely similar, since I have the problem with the mp4 file too.
Have you tried to stop the file in the player, and the press play again. When I do that the video starts a few minutes into the file. It is always the same place, though.

You can download older versions from here: http://megui.org/auto/
That's exactly what I get. But only in .mkv ?!?? :confused:

Anyway, thanks for the link to older builds.
r1724 works for me too. :)

I dont know what happened between r1724 and r1732 that could cause mkvmerge to throw a warning about a negative timecode.
And I don't know why our mp4box behave differently.
But I'll stick with r1724 until someone spots what went wrong.

[Dal]

r1724 works for me too. :)

Do you use MeGui x264 presets when encoding, or do you do it in some other way?

[Alf Bundy]

Well, for Bluray transcodes to 720p, I use Preset Slower (subme 8) & Tune Film in 2-pass mode to achieve the desired filesize.
For TV captures transcode to 480p, I use Preset Slower and no tunings (default).

But for this problem, I even tried pressing the "load default" button on the x264's config dialog, with the same faulty muxing.

[Dal]

This error is still present in r1766.
Anyone?

[sneaker_ger]

Can you try a version with L-SMASH muxer? I know there were problems with GPAC, but I don't know if that is your problem. Would be good if one of the devs could take a look at it.
Here are the L-SMASH versions: 32bit (http://x264.fushizen.eu/files/1766/x264_1766_32.7z) 64bit (http://x264.fushizen.eu/files/1766/x264_1766_64.7z) (these have audio patch built in, so you may need to specify "--acodec none").

[Dal]

Can you try a version with L-SMASH muxer? I know there were problems with GPAC, but I don't know if that is your problem. Would be good if one of the devs could take a look at it.
Here are the L-SMASH versions: 32bit (http://x264.fushizen.eu/files/1766/x264_1766_32.7z) 64bit (http://x264.fushizen.eu/files/1766/x264_1766_64.7z) (these have audio patch built in, so you may need to specify "--acodec none").

Thank you for answering.
And I'm happy to report that this build seems to work fine.
To be sure that it really was this build that was used, I checked with Mediainfo, and it reports: x264 core 108 r1766+332 1be361f
That is the right version/build, right?

The question is, what now?

Thanks again.

[sneaker_ger]

Yes, that should be the correct build.
What now? Sadly, nothing I guess. We have to be careful when using x264's mp4 output - best seems to rely on L-SMASH or output raw and mux later until these problems are completely sorted out (or rather every build uses updated GPAC?). I don't know which GPAC version is used by MeGUI's build. Maybe it's time for the x264 devs to switch to L-SMASH once and for all, given all the problems people have experienced with GPAC recently.
Can any x264 dev comment on this?

[kemuri-_9]

talk to the L-SMASH devs for making the transition to using it easier, that's been the primary problem with having x264 use it instead of GPAC.

[sneaker_ger]

I didn't know there were any problems with it, as even audio output seems to work fine. Also I thought you were one of the L-SMASH devs...

[kemuri-_9]

I didn't know there were any problems with it, as even audio output seems to work fine. Also I thought you were one of the L-SMASH devs...

no, i'm not one of the developers. I've never claimed to be one and I wouldn't know who told you I was one.

the issue is not the fact that it doesn't work,
it's how the developers have been working on it
rather than making a library and a patch to apply against x264's repository for using the library,
they directly add the entire L-SMASH codebase into x264's repository.

this is the problem.

[sneaker_ger]

No one told me you were, I just got you mixed up, that's all.

I see. Hope someone will write a patch that meets the requirements for getting into the git.

[zambelli]

I don't know if it's related, but I'm having encoding issues with b1772 too. It's generating illegal bitstreams that can't be processed with neither MP4Box nor FFmpeg.

Here's my x264 command line:
x264.exe --pass 2 --bitrate 5000 --preset slower --tune grain --keyint 240 --ssim -o "output.264" input.avs

I've tried encoding to both raw .264 and muxed .mp4 - same result.

MP4Box complains "Bitstream not compliant". FFMpeg recognizes the .264 elementary stream but not the x264 .mp4 file. When I tried muxing the .264 stream with FFmpeg into an MP4 file the resulting file refuses to play back with MPC, though (lo and behold!) plays back fine with WMP12.

I don't know if it'll be useful, but here's my x264 stats file in case anybody from the x264 dev team wants to take a look: http://alexzambelli.com/download/x264_2pass.7z

[zambelli]

I've just confirmed that I can repro the same issue with b1724.

[Dal]

Just a quick update: This problem seems to be gone with x264 r1802 and upwards.
I'm not entirely sure why, if something was fixed in x264 or if it was new versions of the x264 scripts in MeGui.