Sound sync with Baseline profile and r1666+

[Lyle_JP]

I am seeing strange behaviors in the latest builds of x264 when I attempt to create baseline profile encodes at level 3. I cannot mux sound on any streams created with r1666 or r1677 without it being horribly out of sync. Oddly enough, if the encode is high profile (level 4 or greater), the problem isn't there. Also, when I revert to r1659, the problem completely goes away at all profile levels.

This happens whether I use MeGUI's muxer or yamb (I believe both use mp4box). I have not upgraded mp4box or yamb in months. Also, I am using all 64 bit builds of x264. This bug ocurs with both the Komissar build of 1666 and the x264.nl build of r1677. As it stands, I can not use any current builds for ipod file generation. While this is not a serious problem now (r1659 is quite good), I hope someone can shed light on it so that I may use future builds.

Is anyone else using 64-bit x264 having this problem with baseline videos? Can anyone else replicate this?

[Audionut]

I've got the same funky issue occurring. It's only happening with mp4 for me. At first I just put the problem in the too hard bin. But I tried some things yesterday and found that, the same streams (both video and audio) in mkv work fine.

It's been happening for awhile though for me.
Have you been using patched builds or clean builds?

I'm going to go way out on a unfounded claim, and say it's an open-gop related issue.

[Dark Shikari]

I'm going to go way out on a unfounded claim, and say it's an open-gop related issue.Open-GOP isn't on by default, nor is it used in baseline profile.

Are you sure the problem isn't an updated gpac build breaking things, as opposed to x264?

[Lyle_JP]

Open-GOP isn't on by default, nor is it used in baseline profile.

Are you sure the problem isn't an updated gpac build breaking things, as opposed to x264?

Not sure what GPAC is, but as I've said, I've made no changes to my muxing software. As for playback, the sound sync issues manifest in hardware players as well. I test all of my ipod rips first on the PS3, and it's where I first noticed the problem. But I see the problem with MPC as well.

Finally, if it is some other software's fault, reverting to r1659 shouldn't have fixed the problem completely, but it did.

[Dark Shikari]

Not sure what GPAC is, but as I've said, I've made no changes to my muxing software.Yes you did. You updated x264. The new x264 might have been compiled against a new (and buggy) gpac.

[Lyle_JP]

post retracted

[nurbs]

Your first post says you downloaded from Komissar and Bobor. x264.nl is not Dark Shikari's website.

[Lyle_JP]

x264.nl is not Dark Shikari's website.

Ah, then in that case I apologize. For some reason I thought x264.nl was indeed Dark Shikari's. But really, this is splitting hairs. I'm reporting a bug in the most commonly available and distributed compiles of x264. As an end user, it's all the same to me. Regardless, I thought someone might want to look into it. If I'm wrong, then I'm genuinely sorry I ever brought it up. :rolleyes:

[JEEB]

If you are outputting to mp4 from x264 (via the GPAC library), try outputting to raw H.264 streams (.264) and muxing to mp4 from that.
Mux it all with, say, VFR Maniac's mp4box builds (http://vfrmaniac.fushizen.eu/MP4Box/) (December's build as well if the newest doesn't work).
Try out a build with the L-SMASH mp4 muxer patch (linky (http://x264.fushizen.eu/?p=220), for example. IIRC Komisar started adding it to his builds lately as well).

After this you've tried enough things and have enough information to get some kind of an answer on what's going wrong and where.

[Lyle_JP]

If you are outputting to mp4 from x264 (via the GPAC library), try outputting to raw H.264 streams (.264) and muxing to mp4 from that.
I already do that with every encode. Mp4 files created directly by x264 never play on my PS3, so encoding to raw is my SOP.

Mux it all with, say, VFR Maniac's mp4box builds (http://vfrmaniac.fushizen.eu/MP4Box/) (December's build as well if the newest doesn't work).
The Kurtnoise build was already working fine with all previous builds of x264. What will that prove?
Try out a build with the L-SMASH mp4 muxer patch (linky (http://x264.fushizen.eu/?p=220), for example. IIRC Komisar started adding it to his builds lately as well).
Alreay tried Komisar's builds. Problem is present.
After this you've tried enough things and have enough information to get some kind of an answer on what's going wrong and where.
I'm not an x264 dev, so I'm not sure why tracking down the source of this bug falls to my shoulders.

[Audionut]

I really wanted to get a movie onto my phone so I just reverted to asp and mp3. :eek:

When I get home from work tomorrow, I'll put some effort into nailing down the problem.

Could take awhile though. I don't remember which build/revision it broke at. It certainly wasn't recently. I've been using rack04 builds for awhile now with open-gop patch. Hence the quick claim for open-gop, as it was committed recently and now someone else has the same issue.

edit: oh and for the record. All my encodes at baseline are to raw. To be muxed with aac into mp4. If corecodec ever gets round to releasing coreplayer 2 mobile I'll be able to stick with mkv and do away with baseline.

[menlvd]

builds after 1659 broke audio sync when mux to mp4 via mp4box. when mux to mkv sync is ok
x264 x64 raw out, muxed with MP4Box-0.4.6-dev_x64_20100612

[nurbs]

I'm not an x264 dev, so I'm not sure why tracking down the source of this bug falls to my shoulders.

This is a great attitude. You want the bug fixed now, but don't want to do anything that narrows it down for the developers so they can fix it easier.

[LoRd_MuldeR]

I'm not an x264 dev, so I'm not sure why tracking down the source of this bug falls to my shoulders.

You complain about a problem in a software that was kindly given to you for free, but then you refuse to do anything for getting that problem fixed :rolleyes:

I suggest you purchase a support contract then...

[Selur]

Trying to reproduce this problem, I took a small avi (see files.zip)
and used the following calls:
1. to extract the audio:
mencoder -lavdopts threads=8 -mc 0 -noskip -aid 1 -ovc frameno -oac copy "test.avi" -of rawaudio -o "test_und_aid_1__15_02_10_541_01.mp3"
2. to reencode the video:
x264 --demuxer auto --preset ultrafast --crf 18 --profile baseline --level 3 --scenecut 40 --partitions i4x4,i8x8,p8x8,b8x8 --subme 1 --sync-lookahead 15 --vbv-maxrate 10000 --vbv-bufsize 10000 --deblock 0:0 --fps 25 --output "test_15_02_10_541_02.264" "test.avi"
3. to mux audio&video
MP4Box -fps 25 -add "test_15_04_16_711_02.264"#video:par=1:1 -brand avc1 -add "test_und_aid_1__15_04_16_711_01.mp3"#audio -new "test.mp4"

mencoder version used: http://sourceforge.net/projects/mplayer-win32/files/MPlayer%20and%20MEncoder/revision%2031372/MPlayer-rtm-svn-31372.7z/download
x264 version used: http://mirror01.x264.nl/x264/revision1677/x264.exe
mp4box version used: http://kurtnoise.free.fr/mp4tools/MP4Box-0.4.6-dev_20100612.zip
files used: http://www.multiupload.com/PLJBLOIRGB

Result: No problem, everything is sync.

Then I switched a x64 build x264_x64_r1677M (http://www.mediafire.com/?6qwhe8e513cqzjo) from rack04 (http://forum.doom9.org/showthread.php?p=1418380#post1418380)) but still no problem: everything is still sync.
I also uploaded the files used during the x64 processing to: http://www.multiupload.com/LXMI9ZOXE9

=> you both might want to check your workflow and tools (maybe you applied some 'br0ken' patches to x264) you used. Doesn't look to me that this is a x264 bug you are encountering

Cu Selur

[Lyle_JP]

This is a great attitude. You want the bug fixed now, but don't want to do anything that narrows it down for the developers so they can fix it easier.

Good Lord, I already narrowed the problem down to the recent x264 executables, and gave every detail I possibly could to help someone replicate the issue. How am I supposed to tell if the problem is the source code or a compiler problem? It's not like I'm making my own brew of x264 here. I really don't know what more you want from me.

Edit: Small avi won't cut it. The audio sync gets worse as the clip goes on, so I doubt anything too short will even show the error well enough. I used the following command line on feature films:
--profile baseline --level 3 --preset slow --tune film --crf 18.5 --vbv-bufsize 10000 --vbv-maxrate 10000 --partitions p8x8,b8x8,i4x4,p4x4

[Lyle_JP]

You complain about a problem in a software that was kindly given to you for free, but then you refuse to do anything for getting that problem fixed :rolleyes:

I suggest you purchase a support contract then...

Fine. The first x264 dev who identifies and fixes the issue has $30 coming via Paypal to the email address of their choosing. Fair enough?

[LoRd_MuldeR]

Fine. The first x264 dev who identifies and fixes the issue has $30 coming via Paypal to the email address of their choosing. Fair enough?

I guess you'll have to append a few zeros to that number :D

[Lyle_JP]

I guess you'll have to append a few zeros to that number :D

Sorry, that's already as much as I've ever paid for in-development software from the web. And it's what I've got to spare right now.

[JEEB]

Just to mention, I'm not a dev either -- I have just been trying to help you for eff's sake. Your attitude is just great, the greatest I've ever seen, yet I'm still trying to make stuff work for you.

I already do that with every encode. Mp4 files created directly by x264 never play on my PS3, so encoding to raw is my SOP.
OK, that removes at least one possible problematic part in the chain (GPAC in x264).

But do try VFR Maniac's and felidlabo's mp4 output for the video, thank you (via my patched builds or Komisar's newest -- which IIRC had the L-SMASH mp4 muxer in it as well). It will make us a sample from an alternative muxer, so we can compare their results.

The Kurtnoise build was already working fine with all previous builds of x264. What will that prove?
Never thought about, well, that new features get added and removed in GPAC? I remember, when making an encode for a certain Japanese game maker, I wanted to make the thing compatible with all kinds of weird stuff like WMP12 of Win7. VFR Maniac's March build showed up as 2x length, while the December version showed up as the correct one (both played back absolutely fine though). Since both work fine with free splitters, I bet GPAC just had a feature added after December, and that broke the player. Not to mention that VFR Maniac's builds usually have some fixes patched in :P (see the diff folder for diffs).

I'm not an x264 dev, so I'm not sure why tracking down the source of this bug falls to my shoulders.
...maybe because you're handling stuff that makes it happen at the moment? And I'd be inclined to say that it's not x264's bug, but something going wrong on muxing if matroska plays back fine on standalones etc. But, of course, if all ways are always blocked, we'll take a look at x264 itself.

[Lyle_JP]

Jeeb,

I will test the scenarios you suggest, but it will take several hours. I'll post back when I have more.

[Selur]

Small avi won't cut it. The audio sync gets worse as the clip goes on, so I doubt anything too short will even show the error well enough. I used the following command line on feature films:
If you don't post more detailed information so that people can reproduce the problem.

Since I got some free time and wanted to do some stress tests today anyway I did the following encoding of a full movie (length 02:26:07):
1. extract the audio of the dvd[/url] (used the mplayer version that comes with the mencoder version I linked before)
mplayer -v -mc 0 -vc dummy -nocorrect-pts -aid 128 dvd://1 -dvd-device "D:\TestDVD" -dumpaudio -dumpfile "test DELAY -80ms_en_aid_128__16_49_15_951_01.ac3"
[u]2. encode the video: (used the mencoder version and the x64 version I linked before)
mencoder -dvd-device "D:\TestDVD" dvd://1 -ovc raw -noskip -vc mpeg12 -field-dominance -1 -vf scale,format=i420,yadif=0 -forcedsubsonly -noautosub -nosound -mc 0 -lavdopts threads=8 -really-quiet -fps 25 -aspect 1.7775:1 -of rawvideo -o - | x264 --preset slow --crf 18.5 --profile baseline --level 3 --partitions i4x4,p4x4,p8x8,b8x8 --vbv-maxrate 10000 --vbv-bufsize 10000 --sar 1422:1000 --fps 25 --input-res 720x576 --output "test_16_49_15_951_02.264" -
3. muxing audio & video with: (used the mp4box version I linked before)
MP4Box -fps 25 -add "test_16_49_15_951_02.264"#video:par=1422:1000:delay=80 -brand avc1 -add "test DELAY -80ms_en_aid_128__16_49_15_951_01.ac3"#audio -new "test.mp4"
Result:AV async ;)
(using mplayer and mpc-hc for playback)

When feeding output test.mp4 to mkvmerge (mmg.exe) it complains about missing 'CTTS'-elements in the avc stream resulting in a async mkv file. (no surprise there I know :))
If I mux the raw streams with mkvmerge everything is fine.

-> testing muxing with mp4box call from above an different mp4box versions
- MP4Box_0.4.6-DEV-rev.5(2010-07-07) (http://vfrmaniac.fushizen.eu/MP4Box/MP4Box_0.4.6-DEV-rev.5(2010-07-07).rar) -> asynch
- MP4Box-0.4.5 (http://kurtnoise.free.fr/mp4tools/MP4Box-0.4.5.zip) -> asynch
- MP4Box-0.4.4 (http://kurtnoise.free.fr/mp4tools/MP4Box-0.4.4.zip) -> too old for ac3 audio
also tried muxing with mp4creator -> synch output

=> if this is a mp4box bug it's older,... and triggered by something changed after r1659 (last one reported by Lyle_JP to work without the problem)

Cu Selur

[MasterNobody]

I have a hunch that the problem can be absent of CTTS atom because baseline profile doesn't allow B-frames.
[15 jun 10 00:30] * BlackFlower * VFR_maniac: I get "The AVC video track is missing the 'CTTS' atom for frame timecode offsets." when muxing. Dark_Shikari wants me to bug you for some reason.
[15 jun 10 00:31] * Dark_Shikari * he's the local mp4 guy
[15 jun 10 00:33] * VFR_maniac * BlackFlower: if you encoded without b-frames, that is normal. otherwise abnormal
And as VFR_maniac say that this normal then probably the problem is not in muxing but in demuxer. Try to update your MP4 demuxer/splitter (what do you use?).

[Selur]

in mplayer: what ever MPlayer decides
in mpc-hc: I tried current Haalis Media Splitter and mpc-hcs internal Splitter

[Lyle_JP]

Test results:

First, the baselines:
Megui standard distributions (x264.nl r1677 x64, both muxed with Kurtnoise 4-10-2010 mp4box)

raw output, high @ L4.1 result: In Sync
raw output, baseline @ L3.0 result: Out of Sync

Okay, these we already knew. Now Jeeb's suggested tests:
raw stream created above, muxed with VFRManiac's latest mp4box: Out of Sync
raw stream created above, muxed with VFRManiac's Dec 04 2009 mp4box: Out of Sync
encoded to raw with Komisar's latest fully patched monster: Out of Sync
encoded to mp4 with Komisar's latest fully patched monster: In Sync :eek:*

* The better news? It plays back flawlessly on the PS3!

Here's another curiosity. All of the bad final mp4 files have a different image on their windows thumbnail than the two files that do play back properly. Now correct me if I'm wrong, but thumbnail generation is done by selecting a frame a certain distance into the file. Could it be that raw output is dropping some frames, leading to the sync issue?

[Trahald]

Here's another curiosity. All of the bad final mp4 files have a different image on their windows thumbnail than the two files that do play back properly. Now correct me if I'm wrong, but thumbnail generation is done by selecting a frame a certain distance into the file. Could it be that raw output is dropping some frames, leading to the sync issue?Im sure windows goes by time and not frames.

Im curious.. as a quick test.. try demuxing the working one (the last one) and then remuxing it. (watch your filenames with yamb)

[Atak_Snajpera]

x264 r1677 x64 from 264.nl
encoded jay leno show (iphone profile) to .264 and muxed with mp4box 0.4.6-dev 2010-04-10 = in sync

[Lyle_JP]

Im sure windows goes by time and not frames.

Im curious.. as a quick test.. try demuxing the working one (the last one) and then remuxing it. (watch your filenames with yamb)

Okay, I used yamb to extract all raw streams, then used both yamb and Megui to remux. Both remuxes produced Out of Sync files again. :mad:

[Atak_Snajpera]

Another sugestion:
1) Download Ripbot
2) update x264 to latest r1677 from 264.nl
3) encode to BASE 3.0

ripbot will also show you number of frames so you can easly compare with encoded mp4.
http://img840.imageshack.us/img840/6121/43662448.png

[JEEB]

encoded to mp4 with Komisar's latest fully patched monster: In Sync :eek:*
Hahahaha. I kind of wondered, but this kind of proves it. I guess L-SMASH really just works better at some things. The first victory for this small mp4 toolkit project 8)

Could it be that raw output is dropping some frames, leading to the sync issue?
Nope, as Windows seems to make its preview pictures by time, it's most probably the timestamps in the resulted mp4 file that are different, thus making frames go to different times from the meant ones. Seems like L-SMASH (and maybe the April build of GPAC?) work correctly, while other versions fail? Not sure, but having working files is great already.

[Lyle_JP]

Hahahaha. I kind of wondered, but this kind of proves it. I guess L-SMASH really just works better at some things. The first victory for this small mp4 toolkit project 8)


Nope, as Windows seems to make its preview pictures by time, it's most probably the timestamps in the resulted mp4 file that are different, thus making frames go to different times from the meant ones. Seems like L-SMASH (and maybe the April build of GPAC?) work correctly, while other versions fail? Not sure, but having working files is great already.

Yes, but there's still something funky about the stream, since once I extract it raw, I can't re-sync the sound again. Anything I've encoded with 1659 or before I can tear apart and put back together all day long, and it doesn't lose sync (and just to prove to myself that I'm not crazy, I did just that with 5 of my older files).

Addendum: After I performed Trahalds experiment, I decided to use media info on both files. SInce both contain the same video stream, I expected identical values. And all of them were but one, which I did not expect. The good file says "Maximum bit rate: 11.0 Mbps", the bad one says "Maximum bit rate: 11.9 Mbps". Just a little more weirdness.

[Selur]

I'm a bit confused now. Is there a mp4box version that can be used without running into the async problem or is there just a patch for x264s mp4box integration?

[kypec]

I'm a bit confused now. Is there a mp4box version that can be used without running into the async problem or is there just a patch for x264s mp4box integration?
Seems to me that for the moment there's only Komisar's patched build of x264 that can output in-sync MP4 files. I'm also very concerned about all this stuff and sync issues because MP4 is the container for all my encodes :eek: Hopefully the cause of the problem will be nailed soon...

[Lyle_JP]

Seems to me that for the moment there's only Komisar's patched build of x264 that can output in-sync MP4 files. I'm also very concerned about all this stuff and sync issues because MP4 is the container for all my encodes :eek: Hopefully the cause of the problem will be nailed soon...

Thankfully, this does only seem to affect baseline encodes, and I'm not even sure if the problem is present in the 32-bit MeGUI (it's too much trouble to downgrade everything to 32 bit, so I haven't tested that).

[JEEB]

Seems to me that for the moment there's only Komisar's patched build of x264 that can output in-sync MP4 files.
Mine and VFR Maniac's patched builds contain this given patch (http://vfrmaniac.fushizen.eu/OtherStuff/L-SMASH/mp4muxer.diff) as well.

Original repository is here (http://repo.or.cz/w/L-SMASH.git). Work is done under a very permissive license.

I'm a bit confused now. Is there a mp4box version that can be used without running into the async problem or is there just a patch for x264s mp4box integration?
It's a new mp4 toolkit designed to follow the spec to the letter on the features it supports. There's an in-development patch for x264 available from VFR Maniac that uses the L-SMASH muxer instead of GPAC. Originally started because people got tired of GPAC being huge, buggy and just a PITA to build at times (if not always).

Yes, but there's still something funky about the stream, since once I extract it raw, I can't re-sync the sound again.
I guess the same GPAC routine is used to mux the stream that also outputs the out-of-sync stream in x264, so I'd guess it's a type of stream that GPAC just doesn't handle well at the moment (not sure if we had any changes that would warrant this, but it's the most likely culprit). I guess this could be taken to the GPAC devs, but they don't move much usually.

The good file says "Maximum bit rate: 11.0 Mbps", the bad one says "Maximum bit rate: 11.9 Mbps". Just a little more weirdness.
Quite normal since bitrate is bits over time. If timestamps in the output MP4 are wrong, you will get wrong (or should I say, "different") results. In this case the video just seems to go faster than intended at certain points.

[Selur]

okay, so this 'L-Smash' is ment to be a new restricted/limited muxer alternative (is there a stand alone command line tool somewhere?) which can be integrated through the patch.
So the main questions are, since mp4box didn't really change since r1666+ and outputting to raw .264 with x264 shouldn't need the gpac part:
1. What changed in x264 to trigger the problem ?
2. If it does everything right now and mp4box is at fault, are all the older x264 baseline streams muxed with mp4box some how broken?
Using a patched x264 to create a mp4 file is nice, but no real alternative to mp4box which allows tagging, muxing audio&subtitles and mpeg-4 asp.

Cu Selur

Ps.: playing around with mp4creator (1.6.1e-pre) I noticed when muxing r1666+ baseline raw streams mp4creator mentions: 'Error decoding sei message' (and this doesn't appear when high profile is used) -> does this mean mp4creator is broken too?

[JEEB]

okay, so this 'L-Smash' is ment to be a new restricted/limited muxer alternative (is there a stand alone command line tool somewhere?) which can be integrated through the patch.

I think L-SMASH already supports more stuff on certain features than GPAC, to be honest. But yeah, it's still somewhat limited on what it deals with, which is mainly H.264 (audio is closing in at high speed). Subtitles (srt) are a Nero hack, so...

Don't remember about tags / chapters, but most probably the spec's / QT's way of doing those will get through if any (hurf durf at MP4 basing on QT's MOV).

Will ask the devs for the possibility of a command-line muxing tool.

1. What changed in x264 to trigger the problem ?
2. If it does everything right now and mp4box is at fault, are all the older x264 baseline streams muxed with mp4box some how broken?

Not sure, but since L-SMASH deals with the streams nicely, it leads me to believe that it's A) GPAC's fault and B) x264 just switched something that lead it to fail (unsupported/improperly supported feature in GPAC?).

Ps.: playing around with mp4creator (1.6.1e-pre) I noticed when muxing r1666+ baseline raw streams mp4creator mentions: 'Error decoding sei message' (and this doesn't appear when high profile is used) -> does this mean mp4creator is broken too?
Not sure, I'll have to ask D_S on the correctness of SEI with baseline, but... as I said earlier, since L-SMASH supports it nicely, it doesn't seem like the actual H.264 stream is broken. I will look into this, though.

[Selur]

Thanks :)

[b66pak]

Will ask the devs for the possibility of a command-line muxing tool.

any result?
_

[RBO]

Hi guys,

I'm a GPAC maintainer. We're happy to see GPAC is used :) and we are receptive to your remarks/bug reports/build failures/suggestions/whatever. However we cannot watch the whole web for that. Please post on our forums (https://sourceforge.net/projects/gpac/forums), and don't forget to give us sample files to reproduce your behaviour.

Romain

PS: https://sourceforge.net/projects/gpac/forums/forum/287547/topic/3339873

[Trahald]

Thanks romain

[Selur]

Just reencoded the samples from my posts before with the newest x264 from x264.nl and now they mux fine, so which ever was changed in x264 fixed my problem. Thanks. :)

[meatwad]

Just reencoded the samples from my posts before with the newest x264 from x264.nl and now they mux fine, so which ever was changed in x264 fixed my problem. Thanks. :)

With the 64bit version (unpatched build 1683) they're still off a tad. If I use 1649 they sync fine.

[JEEB]

any result?
_

I did ask, but the answer was "No, such application doesn't exist yet.", but talk did begin on the IRC channel and I hope a basic L-SMASH muxer will get done sooner than later for testing.

[Trahald]

The issue with opengop and mp4box are seperate from the timing issue in this thread. I will move them to the open gop thread.

[Trahald]

for someone who is still getting the sync issue. source files that can reproduce the issue would be nice. even if you have to compress your source with something else to make it smaller. just make sure if you do compress that the compressed files are in sync, and the issue is still reproducible from this compressed file with x264. and your command line.

[Selur]

The issue with opengop and mp4box are seperate from the timing issue in this thread.
Ah, okay,.. thanks for clearing that up. :)

[Lyle_JP]

It looks like Trahald found the commit that caused all of this in another thread:

http://forum.doom9.org/showpost.php?p=1425800&postcount=13

I assume that this commit is fully h.264 compliant so the problem likely lies with GPAC. Still, anyone having sync problems with iPod should stay on r1659 until someone on either side blinks.

[meatwad]

It looks like Trahald found the commit that caused all of this in another thread:

http://forum.doom9.org/showpost.php?p=1425800&postcount=13

I assume that this commit is fully h.264 compliant so the problem likely lies with GPAC. Still, anyone having sync problems with iPod should stay on r1659 until someone on either side blinks.

Thanks for the update.

[Trahald]

http://forum.doom9.org/showthread.php?p=1430733#post1430733

Try the binary i compiled/patched in the above thread. it uses revision 1988 gpac (Aug 26 2010) so hopefully its stable enough.. ill patch an older one if need be. This mp4box should hopefully fix the desync.