ffmpeg adding white flash frame at end of .mov output file

[Mark Burton]

I have now tested doing an open and resave of the encoded file in MPEG Streamclip (which retains the fast start header I need) and the resaved file does not display the white frame!

Interestingly, looking the length of the file in our streaming player, the original encode shows its 1 frame longer than the resaved version. This all points to the fact the audio is being encoded a few milliseconds longer than the video and a ‘false’ frame is being created by the player to allow the audio to finish playing.

I need my files to be saved with the faststart header and obviously it would be great to avoid using MPEG Streamclip each time on top of the encode process.

Still keen to properly test the -shortest flag, as so far I’m not finding thats helping but may not be using it in the correct place.

Any other thoughts? I can’t use another aac library as the other high quality libraries are not included in the binaries due to licensing restrictions I believe.

[Len Hugh]

These are not solutions, but might help confirm some things.

If you run your ffmpeg code without the fast start flag does it fix the white flash fault?
If so, if you run ffmpeg over the output and only add the fast start does the fault remain gone?
eg
ffmpeg -i outputFile.mov -movflags +faststart outputFile_with_faststart.mov

Is the Mpegstreamclip output the correct number of frames and the FFMPEG output is one frame longer then your avid sequence?

If you use -ss and specify the same start and end code as you have in avid does that effect the result?

[Mark Burton]

[len hugh]
If you run your ffmpeg code without the fast start flag does it fix the white flash fault?
Thanks for the ideas L, really appreciate having your help. I still see the white flash on files encoded without the fast start flag in the command.

If so, if you run ffmpeg over the output and only add the fast start does the fault remain gone?
eg
ffmpeg -i outputFile.mov -movflags +faststart outputFile_with_faststart.mov
Although removing the fast start flag didn’t work, I did try this and it actually makes the problem worse.

Looking at these files in iMediaHUD, the original Avid source file has a duration of 00:01:11.042, this is shown the same for both the video and audio tracks.

Encoding with ffmpeg (with or without fast start flag) shows a duration of 00:01:11:042 for the video track and 00:01:11:063 for the audio track.

Doing the fast start only command on the output file from above makes it even worse; now the video track has changed to 00:01:11.084 and the audio track has changed to 00:01:11.116.

Both of the above files show white frame at the end of the clip.

Is the Mpegstreamclip output the correct number of frames and the FFMPEG output is one frame longer then your avid sequence?
Exactly, MPEG Streamclip fixes the discrepancy between the video and audio tracks.

I have also tested doing the original ffmpeg command with the a:c set to copy and this produces a perfect file, albeit with uncompressed audio which is not much help to me. So we know its an AAC issue.

Looking at the available AAC encoders, I would have to compile ffmpeg myself in order to use alternate AAC (non free) encoders and I’m not sure they would make any difference (see link below).

If you use -ss and specify the same start and end code as you have in avid does that effect the result?”
Good idea. Although not sure -ss is the right one to use is it? I tried adding -t to the command and entering 00:01:11.042, but the audio track is still longer.

Reading this post, it seems like this has been an issue for a very long time and almost considered the correct behaviour. Very strange. Surely creating H264 AAC files is one of the most popular uses for ffmpeg, can’t believe this is an acceptable output.

Do you not see this on your AAC files?

[Reuben Martin]

I have never encountered this issue, but then again, I generally use the libfdk_aac encoder.

[Mark Burton]

Have now tested libfdk_aac and libfaac and found the same problem. It seems likely this is more a decoder issue with a specific playback engine we use.

Having looked into how compressed aac audio is actually stored in the container (in this case a .mov), it does look like there is an incompatibility with the way ffmpeg does it and our decoder. Thats likely the reason the ffmpeg ‘bug’ reports around this issue always end with the developer stating its as expected, which is right. The emphasis is on the decoder to understand whats called the aac priming I believe.

This is all well above my pay grade, could well be on completely the wrong track, but as far as I can see, there is nothing ‘wrong’ with the files in and of themselves, its just that the layout is not as widely understood as Quicktime .mov’s.

Thanks for all your ideas and help. The short of it is that there is nothing I can do in ffmpeg to change this behaviour. I need to either change the .mov container structure post encode (MPEG Streamclip ‘fixes’ the issue) or the decoder needs to be updated to handle ffmpeg files with aac audio better.

[Reuben Martin]

You might try to see if it works better in an mp4 container. I don’t know if that causes conflict in your workflow, but since you seem to indicate quicktime is being used I’ve found that it handles mp4 files easily enough.

The mp4 format is loosely based on mov, but it is an official standard, so it is documented quite extensively. mov format on the other hand is apple’s proprietary format, and while some documentation for it can be found, there are lots of things that are vague and open to interpretation, other things totally undocumented, and places where the implementation quirks diverge from the documentation.

It may not fix your problem, but if the content is being encoded to h264 + aac there’s no reason not to try it out.

[Mark Burton]

Unfortunately the mp4 route does not work for either. The platform we play on only accepts .mov files. I tried to see if making first as mp4 and then re-wrapping to .mov with ffmpeg worked, but no luck.

I may have found another workaround solution which is at least scriptable and can be included with the ffmpeg command. Using the QTCoffee toolkit (modmovie) to re-wrap the output into a new self contained .mov produces a file which is essentially the same as those that Quicktime creates. It does not have the ‘offset’ on the aac track and as a result plays without the white flash frame. Its doing the same as MPEG Streamclip, but since its command line based, its much more suited to our scripted workflows.

Still testing it to make sure there are no sync issues as a result, but I think this is probably the best workaround for now. Thanks for all the help everyone, much appreciated.

[Blake Sloan]

Here’s a solution to the trailing white flash that seems to work for me when converting DnXHD to x264:

ffprobe

The result will have a line like:
> Duration:00:00:08.75 …

When encoding x264 (or other format)
Subtract 0.04 from this time code when passing the -t arg to ffmpeg.

ffmpeg -i -ss 00:00:00.0 -t 00:00:08.71

[Mark Burton]

I’ve tested that before and its not 100% reliable unfortunately, you will end up losing a frame of picture in some instances. The issue is a structural issue with the container rather than there actually being an extra frame I believe.

[Blake Sloan]

Doh. Yes. It may be possible (trying as I write this) to find the “sweet spot” duration parameter by iteratively encoding, reading the output duration with ffprobe and reducing the requested duration by some small number (trying with 1/100) until the output duration is less than the input, then using the previous iteration’s encoding. It is no longer fun. 🙂