Issue 157 in mp4v2: 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.

[mp...@googlecode.com]

Status: New
Owner: ----
Labels: Type-Defect Priority-Medium

New issue 157 by vijayg23...@gmail.com: 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.
http://code.google.com/p/mp4v2/issues/detail?id=157

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.

Attachments:
Screenshot.png 1.4 MB

--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

[mp...@googlecode.com]

Comment #1 on issue 157 by vijayg23...@gmail.com: 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.
http://code.google.com/p/mp4v2/issues/detail?id=157

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.

[mp...@googlecode.com]

Comment #2 on issue 157 by kid...@gmail.com: 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.
http://code.google.com/p/mp4v2/issues/detail?id=157

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.

[mp...@googlecode.com]

Comment #3 on issue 157 by vijayg23...@gmail.com: 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.
http://code.google.com/p/mp4v2/issues/detail?id=157

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.