[FFmpeg-user] ProRes Quicktimes with audio not playing back reliably

[Bob Maple]

More tests today including FCP (more on that later) but I think we might 
have a winner!

Last month when I originally brought all this up Roger Pack suggested 
using the 'asetnsamples' filter to get ffmpeg to do a longer mux 
sequence, and I just sort of missed it while we chased other things.

Well, today I went back through the whole thread and caught his message 
and did some more playing.  Indeed, asetnsamples does the trick in 
allowing me to make a much longer mux sequence.

Of my "complex visual" test source file, I made two ProRes encodes from 
ffmpeg:

ffmpeg -i Source.mov -codec:v prores -profile:v 2 -codec:a pcm_s16le 
ProResTest_Normal.mov

   and

ffmpeg -i Source.mov -codec:v prores -profile:v 2 -codec:a pcm_s16le 
-filter_complex asetnsamples=n=16384 ProResTest_Normal.mov

The first one still plays miserably as expected, but the second seems to 
play perfectly.  Even though the alignment and video packet lengths are 
still mostly odd, the longer sequences of video and audio packets in the 
mux seems to make Quicktime happier performance-wise, so the alignment 
is not as big an issue.  The 16k sample sizes gives me more of a 
sequence of:

aaaaaaaaaaaaaaaaVVVVVVVVVVVaaaaaaaaaaaaaaaaVVVVVVVVVVaaaaaaaaaaaaaaaaVVVVVVVVVV

etc.

So thanks again Roger for the suggestion, and sorry I didn't see it to 
try it sooner!

I'll continue to play with this and make a bunch more test files see 
what happens.

> Will still try to get on the Mac tomorrow to feed these to FCP and
> hopefully narrow down exactly what property (packet length, alignment,
> or mux rate) causes it to throw the optimization warnings.

Unfortunately, I haven't been able to figure out what it is about 
certain ProRes files that causes FCP to throw up the optimization 
warning on import.

Both my aligned AND unaligned tighly-muxed test files imported with no 
warnings... yet a different unaligned one DID throw the warning, and I 
don't really see what the big difference is.  The one that threw the 
warning actually had, as a percentage, fewer unaligned/uneven-sized 
packets than the other one that didn't, both files were an even number 
of bytes total... so, still not really sure what FCP scans for to 
complain about.  Oh well.