Open GoogleCodeExporter opened 8 years ago
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 vijayg23...@gmail.com
on 1 May 2013 at 5:48
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 kid...@gmail.com
on 13 May 2013 at 3:04
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 vijayg23...@gmail.com
on 18 May 2013 at 7:10
Original issue reported on code.google.com by
vijayg23...@gmail.com
on 27 Apr 2013 at 7:24Attachments: