MP4Close( ) takes a very long time to complete

[Ken Dunne]

Hello everyone;

After calling "MP4WriteSample( )" to write video and audio
frames into a file, I find that the call to "MP4Close( )" takes a very
long time to complete, up to 30 seconds for a very large file (1 GB).
The MP4 file plays fine.

Is this normal?

Is there any API function that i can call to change this behavior?

thanks very much for your consideration;

Ken

[Jeremy Noring]

On Thu, Jan 5, 2012 at 2:21 PM, Ken Dunne <dunn...@gmail.com> wrote:

Hello everyone;

         After calling "MP4WriteSample( )" to write video and audio
frames into a file, I find that the call to "MP4Close( )" takes a very
long time to complete, up to 30 seconds for a very large file (1 GB).
The MP4 file plays fine.

Is this normal?

Is there any API function that i can call to change this behavior?

That's odd; admittedly I don't write any files that are larger than 5-10 MB, so not clear to me what the issue is.  Have you profiled it to see where it's taking time?  And what version of mp4v2 are you using, and on what platform?

[Ken Dunne]

I've compiled for an ARM9 Linux envrionment, using version 1.9.1 of
MP4v2
I've not profiled; I don't have the tools to do so in this environment


On Jan 5, 5:58 pm, Jeremy Noring <kid...@gmail.com> wrote:

[Ken Dunne]

Using printfs, the elapsed time for the MP4Close() on a 144MB (1256
seconds of video+audio) is 397 seconds.
The hardware may be somewhat limiting me, as well as the linux 2.6.10
kernel, but I'm going to dig into the MP4Track::FinishWrite().

I am guessing that the disk IO is mostly happening in the
'FinishWrite', and not the 'MP4WriteSample'. Can i change this by
somehow changing how big the 'chunk-buffer' is? In our past
experience of this hardware, 64K is a good write-size. Is there any
API to change MP4v2's buffering?

thanks

Ken

[Ken Dunne]

I am now using the r479 sources, and have added the flag
"MP4_CLOSE_DO_NOT_COMPUTE_BITRATE" to the MP4Close() call.
When profiling the MP4V2 sources, i found that the audio track was
taking a great deal of time between lines 544-558 of mp4track.cpp
(inside "FinishWrite()")
The two m_trakAtom.FindProperty( xxx ) look innocuous, but caused a 30
minute delay for a 200MB file...

/K

On Jan 5, 5:58 pm, Jeremy Noring <kid...@gmail.com> wrote:

[Jeremy Noring]

On Mon, Jan 16, 2012 at 8:29 AM, Ken Dunne <dunn...@gmail.com> wrote:

I am now using the r479 sources, and have added the flag
"MP4_CLOSE_DO_NOT_COMPUTE_BITRATE" to the MP4Close() call.
When profiling the MP4V2 sources, i found that the audio track was
taking a great deal of time between lines 544-558 of mp4track.cpp
(inside "FinishWrite()")
The two m_trakAtom.FindProperty( xxx ) look innocuous, but caused a 30
minute delay for a 200MB file...

Nice find.  So does that completely resolve your performance issues, or is it just an improvement?

[Ken Dunne]

> Nice find.  So does that completely resolve your performance issues, or is
> it just an improvement?

this completely resolves the performance issue. the MP4Close() takes
about a second for a 200MB file, as opposed to 30 minutes.
Interestingly, only the audio track was causing the performance issue.

/K

[Jeremy Noring]

Cool--so I guess my next question is whether or not there's some way to compute the bitrate but not incur the performance penalty?    I suspect not, but it'd be interesting to know if we can fix some performance issue in MP4Close(). 

I also wonder if a similar issue exists in MP4Optimize(), although I can't remember if that recomputes bitrate or not.