What steps will reproduce the problem? MP4v2 library version 1.9.1. On highly stressed machine attepmpt to close file with MP4Close() results in "Division by zero" exception in MP4Track::GetMaxBitrate():

WinDbg output:

(1364.b98): Integer divide-by-zero - code c0000094 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. MP4Writer!_aulldiv+0x14: 0066ec84 f7f1 div eax,ecx

0:011:x86> kv 029af7f0 005b4c71 00000000 029afa80 029af8f4 MP4Writer!_aulldiv+0x14 [f:\dd\vctools\crt_bld\SELF_X86\crt\src\INTEL\ulldiv.asm @ 87] 029af8ec 0058ef23 ba035cfb 029afb88 029afcd8 MP4Writer!mp4v2::impl::MP4Track::FinishWrite+0xe1 [d:\projects\mp4v2-1.9.1\src\mp4track.cpp @ 522] 029afa8c 0058f3ee 029afcac 029afcd8 00000000 MP4Writer!mp4v2::impl::MP4File::FinishWrite+0x123 [d:\projects\mp4v2-1.9.1\src\mp4file.cpp @ 469] 029afb88 00570b71 ba035acb 029afdb4 029afcd8 MP4Writer!mp4v2::impl::MP4File::Close+0x4e [d:\projects\mp4v2-1.9.1\src\mp4file.cpp @ 520] 029afcbc 0051aad8 007d3f28 029afcd8 007de108 MP4Writer!MP4Close+0x61 [d:\projects\mp4v2-1.9.1\src\mp4.cpp @ 162]

MP4v2 code throwing the exception:

005b4c6c e82fbcf4ff call MP4Writer!ILT+30875(?GetMaxBitrateMP4Trackimplmp4v2QAEIXZ) (005008a0)

0:011:x86> u 005008a0 MP4Writer!ILT+30875(?GetMaxBitrateMP4Trackimplmp4v2QAEIXZ): 005008a0 e95b540b00 jmp MP4Writer!mp4v2::impl::MP4Track::GetMaxBitrate (005b5d00)

0:011:x86> ln 005b5d00 d:\projects\mp4v2-1.9.1\src\mp4track.cpp(767) (005b5d00) MP4Writer!mp4v2::impl::MP4Track::GetMaxBitrate | (005b6020) MP4Writer!mp4v2::impl::MP4Track::GetSampleStscIndex Exact matches: MP4Writer!mp4v2::impl::MP4Track::GetMaxBitrate (void)

Thus, it is MP4Writer!mp4v2::impl::MP4Track::GetMaxBitrate that throws division-by-zero exception.

Do you know if this issue is still present in trunk?

I don't know

I do see where it could get a divide by zero issue in GetBitRate:

        // now, calculate the number of bytes we overflowed.  Round up.
        overflow_bytes =
            ((lastSampleSize * overflow_dur) + (lastSampleDur - 1)) / lastSampleDur;

...what I don't understand is why you'd hit this code, or why it's somehow related to a "highly stressed machine." What sort of locking are you using around mp4v2?

I can certainly band-aid it to check lastSampleDur for zero in that code, but it might be nice to get a better idea of how such a condition cropped up in the first place.

Process receives multiple H264/AAC encoded streams over network. For each stream a file gets created with MP4Create() with Video and Audio tracks. MP4WriteSample() is called for every sample received for corresponding stream. No more than one MP4WriteSample() call per MP4 file is done simultaniously. However multiple simultanious calls targeted to different files are possible. The problem occurs when machine stressed to the point where considerable delays between received from network subsequent samples are possible. File I/O also takes longer than ussual time.

Added a check to prevent the division by zero. Not completely sure about this code (it's strange), but should be fixed in r473. Not sure when we'll have another release, I need to manage to find a weekend and that probably won't happen before July. :-/