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

[Tim Nicholson]

On 24/09/12 13:31, Tim Nicholson wrote:
> [...]
> 
> OK I've done some more investigation on this.
> 
> Copied a sample file locally, and it still exhibits the issue.
> 
> Created a test file with the same coding parameters as was used by the
> sample file as above using the following command line:-
> 
> ffmpeg -f lavfi -i "testsrc=duration=600.0:size=720x576:rate=25" \
> -f lavfi -i "aevalsrc=0::d=600.0" -f lavfi -i "aevalsrc=0::d=600.0" \
> -f lavfi -i "aevalsrc=0::d=600.0" -f lavfi -i "aevalsrc=0::d=600.0" -map
> 0:v -map 1:a -map 2:a -map 3:a -map 4:a \
> -vf "drawtext=fontfile=/usr/share/fonts/truetype/DroidSans.ttf: \
> timecode='00\:00\:00\:00': r=25: x=(w-tw)/2: y=(1*lh): \
> fontcolor=white: fontsize=60: box=1: boxcolor=0x00000000 at 1" \
> -c:v prores -profile:v 3 \
> -c:a pcm_s24be -ar 48000 \
> -y Prores_test_A.mov
> 
> This file does not show any of the problems (as evidenced by QTPlayer
> <apple I> info box showing the rate stuttering or any visible stutter of
> the timecode, or scrolling rainbow).
> 
> I note that my original file, duration 11 mins 03 secs is 4.8G in size,
> and the lavfi version, duration 10 mins is only 1.7G. A recoded version
> of the original to the same codec and level (done in QT Pro) is just
> over 5G (but the audios have been merged into a 4 channel stream from
> the 4 discrete streams). This has no issues.
> 
> I therefore wonder if the problem is buffer related, with the more
> complex material coded by ffmpeg exceeding a limit momentarily, with the
> Apple coded material being within the limits, and simple material coded
> by ffmeg just fortuitously staying within limits.
> 

Following up on the file size difference I recoded a video only version
of the above lavfi testsrc using QT Pro.

For this the file size grew from 1.5G to 2.7G which is a whopping change.

As I understand it ProRes is a variable bit rate codec, with the
variable range quite constrained. I am wondering if the ffmpeg
implementation is allowing too great a spread in this variable range,
which in the case of simple material can go too low, and for complex
material to high?


-- 
Tim