23.976 vs. 23.975fps problem

[Stacey Melissa]

Originally posted by opsis81
http://4nykey.nm.ru/misc/gpac.7z

Latest mp4box build,compiled in 10-Apr-2005,supports nero chapters with -chap command and accepts the ogg chapter format.
The 4/10/2005 build from that link (which has since been replaced) improperly sets the -fps value. I specify 23.976, and it gives me 23.975, so by the end of a two hour movie, the video is a third of a second behind the audio. :( On the plus side, it properly muxes Ogg chapters. :)

The 4/13 build from the same link just crashes right away when I try to mux my raw .264 file into .mp4. :(

C:\Program Files\4ceCore>mp4box -add Matrix3.264 -fps 23.976 -new Matrix3.mp4

Assertion failed: bs->nbBits==8, file bitstream.c, line 241

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

[bond]

Originally posted by Stacey Melissa
I specify 23.976, and it gives me 23.975, so by the end of a two hour movie, the video is a third of a second behind the audio. :( On the plus side, it properly muxes Ogg chapters. :)do you really get when playing the stream?

[Stacey Melissa]

@Bond - I don't know the exact rate of playback, since it jumps around and the readout only shows 2 decimal places anyway.

I noticed my latest Matrix 3 test encode started out in sync, but looked like a poorly dubbed kung fu movie by the end. So I did a mp4box -info readout on the video track of the screwy file:

Track # 1 Info - TrackID 1 - TimeScale 23975 - Duration 02:09:08.488
Media Type "vide" - Media Sub Type "avc1" - 185770 samples

Here's what a properly working copy looks like:

Track # 1 Info - TrackID 1 - TimeScale 24000 - Duration 02:09:08.157
Media Type "vide" - Media Sub Type "avc1" - 185770 samples

I did come up with a workaround. I first muxed the raw x264 by itself into .mp4 using the April 5 compile. Then I imported the resulting video track into a new .mp4 along with the audio, subs, and chapters, using the April 10 compile. Not exactly elegant, but it works, and I have my chapters now. :p

The chapters work perfectly in Showtime, but using the same filters, they don't quite work right in WMP6.4. In WMP6.4, the first chapter doesn't show up in the list. I forget now whether files created in Recode do the same thing.

[Stacey Melissa]

The 4/15 build of mp4box doesn't crash when muxing from raw like the 4/13. It still exhibits the framerate issue when muxing from raw, just like the 4/10 build. JoeBG, you might want to check on the multiple audio track issue to see if it's fixed.

[bond]

Originally posted by Stacey Melissa
[B]The 4/15 build of mp4box doesn't crash when muxing from raw like the 4/13. It still exhibits the framerate issue when muxing from raw, just like the 4/10 build. your 23.975 vs 23.976 issue is very likely only a rounding error and nothing more

have a look for a description here (http://sourceforge.net/tracker/index.php?func=detail&aid=1162386&group_id=84101&atid=571738)

[Stacey Melissa]

@ bond - That would be a viable explanation if it only happened on short clips, since the minimal number of frames would amplify whatever rounding error there is. However, the error I'm getting is on 2+ hour movies. There is no question to me that it's an importing problem (not just a calculation problem for the -info readout), because it very noticeably affects a/v sync on long movies, and it only started happening with the builds sometime between April 5 and 10. Unfortunately, this is also the time when the -chap option was added, so I can't get a build that has both chapter functionality and working fps.

Need more evidence? Add a 2-hour raw .264 clip to a new .mp4 using CD's 4/5 build. Then add the same raw clip to a second new .mp4 using the 4/15 build. Run mp4box -info on the video track of both MP4s (using either mp4box build) and note the ~1/3 second difference in the calculated duration. Both will have a little bit of rounding error, but the .mp4 from 4/15 will also have the major import error.

Still need more evidence? Mux in some audio using the two builds, and note the gradual loss of sync with the 4/15 build.

It's a reproducable phenomena for me. If anyone else can reproduce it, I'll send a bug report to Jean.

[bond]

Originally posted by Stacey Melissa
I'll send a bug report to Jean.thats surely the best solution :)

[bond]

splitted as this doesnt belong to the chapters discussion

[planet1]

There really seems to be a problem ...

I used a small XviD clip:

-if imported from the avi no problems (avi->mp4->avi always 23.976 fps)

-if converted to raw first ("-aviraw video filename.avi") and muxed with "-fps 23.976" resultet mp4 shows 23.976 fps (mp4UI), but extracting to avi produces 23.975 fps (extracting with mp4UI on the other hand seems to be fine)


Last but not least - when importing from AVI 23.976 fps should be shown as such and not as 23.98 fps - IMHO :)

[bond]

i already pointed to the bug tracker of mp4box/gpac in this thread, if you think there is a bug make a bug report there :)

[planet1]

just waiting for a confirmation - besides the problem is very minuscule ... ;)

[Stacey Melissa]

I submitted a bug report (http://sourceforge.net/tracker/index.php?func=detail&aid=1185524&group_id=84101&atid=571738).

[bond]

and jeanlf meant this is fixed already in latest cvs :)

[Stacey Melissa]

I can confirm that the issue is fixed in Celtic Druid's latest compile from April 19. :)

[Gendal]

This problem just started popping up for me in cvs (updated today, 11/3/2005) on a gentoo amd64 box. It doesn't happen if I use the GPAC 4.0 version on windows. Unfortunately gpac 4.0 doesn't compile on amd64 in linux or I would just use that.