(tl;dr We have a problem with certain mp4 files which always stream with a 0.5 second audio delay from beginning to end.)
We have a substantial archive (about 1.2 million files) of video files consisting of h.264 video + mp3 audio in a .flv
container. We currently stream these on-demand using rtmp. We would like to remux these files to mp4 for streaming via http (cupertino).
We have carried out a number of tests using
- various demuxers/remuxers (ffmpeg and MP4Box), and various muxing parameters
- various input samples
In each case we find exactly the same behaviour
- the mp4 file plays fine on a local vlc
- when streamed via wowza (v4.0.3) the sound is delayed by 0.5 seconds. The delay appears to be very close to exactly 0.5 seconds, for all files tested, and throughout the whole file (which may be more than an hour long). There is no drifting [NOTE: now upgraded to 4.4.1 with the same results.].
- If we download one of the chunk .ts-files and play that locally then the audio is already delayed by 0.5 seconds in the chunk.
So it looks as if the part of wowza that chunks the files is introducing the audio delay. Any ideas? Here are
links to an mp4 file which plays fine locally but streams with the audio delay, and a chunk.ts file (downloaded from wowza by curl'ing) which shows the delay.
State And University Library