STSZ entry becoming zero for one particular sample for a particular AAC Audio track while muxing 1 H.264 video Track with 4 AAC Audio Tracks.

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Use mp4v2 library for muxing 1 H.264 video track and 4 AAC audio tracks to 
create QT compatible MP4/MOV file.
2. Continue muxing for more than 8 hours. Print the entries in the function 
UpdateSampleSizes() present in mp4track.cpp file.
3. Check the finally written MP4/MOV file in atomic browser or MP4 Explorer.

What is the expected output? What do you see instead?
1. Expected output should be that all the values of "STSZ" property in the 
final "MOOV" box should be updated correctly for all the AAC audio tracks with 
same values at that instant of time. 
2. But however observed behavior is that after 2000 samples or so one value of 
"STSZ" value for one of the AAC audio track is entered zero while other entries 
are correct for that audio track and when that sample size is entered 
incorrectly for that track, the other tracks have correct entries of "STSZ" for 
that particular sample.
3. When checked in UpdateSampleSizes() function the size which has gone zero in 
the final "MOOV" created has also been updated correctly. 
4. This problem only occurs for "SOUN"(audio) track and not for "VIDE"(video) 
track.
5. Also any one sample size entry of any of the audio tracks can go zero which 
means it happens randomly. 
5. Please find attachment of such a file opened in MP4Explorer where size is 
zero.
6. "Sample size expected to be written in 171 but is shown as zero."

What version of the product are you using? On what operating system?
This bug is observed with all versions of mp4v2 library ie mp4v2 library 
present in mpeg4ip library version 1.5 to the latest mp4v2 library version 2.0.

Operating System is Fedora 6(Linux).

Please provide any additional information below.
When we check for "MDAT" when that sample size is entered as zero, that "MDAT" 
is present. This can be seen if the file is opened in Atomic Browser.  

Original issue reported on code.google.com by [email protected] on 27 Apr 2013 at 7:24

Attachments:

• Screenshot.png

[GoogleCodeExporter]

1)I changed the logic of "realloc" of "MOOV" buffer in MP4File::WriteBytes() 
function   present in mp4file_io.cpp file and this issue got fixed. 

2)Instead of dynamically reallocing "MOOV" when a new sample is received, as I  
already know the size of the "MOOV" buffer, I statically allocated size of 
"MOOV" buffer(~ 1 MB). 

3)"Now this issue is not reproducible." 

But I have a few questions:

a)I found out that in MP4File::WriteBytes() function of mp4file_io.cpp, the 
realloc is done for twice the required size:

   if( m_memoryBufferPosition + bufsiz > m_memoryBufferSize ) 
    {

            m_memoryBufferSize = 2 * (m_memoryBufferSize + bufsiz);

     m_memoryBuffer = (uint8_t*)MP4Realloc( m_memoryBuffer, m_memoryBufferSize );


My question is that when just “m_memoryBufferSize + bufsiz” size of memory 
is required, why is memory allocated  for  “2 * (m_memoryBufferSize + 
bufsiz)” size?

b)If  "realloc" of MP4Realloc() was a problem, why was it only affecting 
"SOUN"(audio) track "STSZ" property values and not affecting "VIDE"(video) 
track "STSZ" property values?

Please Help. 

Original comment by [email protected] on 1 May 2013 at 5:48

[GoogleCodeExporter]

Could you post the specific changes you made in WriteBytes()?

Regarding your questions,

A) the reason realloc is done at twice the size is if you just did it for 
bufsize, it is very likely the very next WriteBytes call would simply have to 
realloc again, and you'd spend most of your time in this routine reallocating a 
buffer.  So the strategy is to allocate a bit more than is needed.

B) I suspect it might have something to do with multiple audio tracks?  But 
really not sure.  Good question.  I wouldn't think changing 
MP4File::WriteBytes() would be the fix here.

Original comment by [email protected] on 13 May 2013 at 3:04

[GoogleCodeExporter]

Hi,
Thank you for your reply.

>>Could you post the specific changes you made in WriteBytes()?

a)These are the changes done in the function WriteBytes which will reproduce 
the issue:

  if(writeHeader == TRUE )
 {
    header=(char *)realloc(header,header_size+numBytes);
          memcpy(header+header_size,pBytes,numBytes);  
          header_size += numBytes;
 }
writeHeader is a flag which gets set for updating the "MOOV" buffer. Then we 
can realloc and update the "MOOV" buffer with the required size.

b)These are the changes done in WriteBytes which fixed the issue:

#define STATIC_MOOV 1024*1024
 if(writeHeader == TRUE )
 {
     header=(char *)malloc(STATIC_MOOV);
     if(NULL == header)
        return;
     memcpy(header+header_size,pBytes,numBytes);
     header_size += numBytes;
 }
In this case the actual size of "MOOV" buffer for the entire session will only 
be 512 KB (actual scenario), but "MALLOC" has been done for 1MB just to keep 
some extra space in case the "MOOV" buffer becomes greater than 512 KB.

But even with the changes done in b) the answer to my earlier question is still 
not found:
>>b)If  "realloc" was a problem, why was it only affecting "SOUN"(audio) track 
"STSZ" property values and not affecting "VIDE"(video) track "STSZ" property 
values?

However when "MOOV" buffer size was statically allocated to 1 MB, this issue 
got fixed. 

But for another case, "MOOV" size becomes ~12 MB for the entire session and 
statically allocating 12 MB is not a good idea because the amount of available 
memory is less(only 28 MB in my case - real time embedded system). 

Is there an alternate way to fix the issue?

Please help. Thank You.

Original comment by [email protected] on 18 May 2013 at 7:10