search

sw55555 / mp4v2

Automatically exported from code.google.com/p/mp4v2
Other
1 stars 0 forks source link

"Division by zero" exception in MP4Track::GetMaxBitrate() #84

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
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.

Original issue reported on code.google.com by ada...@gmail.com on 2 Mar 2011 at 12:55

GoogleCodeExporter commented 9 years ago 
Do you know if this issue is still present in trunk?

Original comment by kid...@gmail.com on 2 Mar 2011 at 6:58

GoogleCodeExporter commented 9 years ago 
I don't know

Original comment by ada...@gmail.com on 5 Mar 2011 at 1:49

GoogleCodeExporter commented 9 years ago 
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.

Original comment by kid...@gmail.com on 17 Mar 2011 at 11:15

GoogleCodeExporter commented 9 years ago 
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.

Original comment by ada...@gmail.com on 22 Mar 2011 at 6:21

GoogleCodeExporter commented 9 years ago 
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. :-/

Original comment by kid...@gmail.com on 14 Jun 2011 at 4:28