max_analyze_duration 5000000 reached

[dinkypumpkin]

On 28/04/2012 18:11, Rob Dixon wrote:
> max_analyze_duration 5000000 reached at 5014000
> Estimating duration from bitrate, this may be inaccurate

For anyone else curious about this warning message, a fairly succinct 
explanation here:

http://ffmpeg.org/pipermail/ffmpeg-user/2012-February/005064.html

> appear in log files a few times on this list, but no one seems to have
> raised it as a problem. I'm aware that it probably makes no significant
> difference to the reencoded files, but I don't like warning messages and
> I would like to learn more about it.

I have to say I've never a seen a problem related to this.  FFmpeg's 
estimation of file duration shouldn't have any effect on playback of the 
files produced from get_iplayer.

Once correction: get_iplayer doesn't re-encode files by default, it 
re-muxes streams into a new container.  Even if FFmpeg's  duration 
estimate is slightly off, no stream data is altered.

> After a few web searches I have found nothing really relevant except
> that it relates to an ffmpeg option -analyzeduration. That brings up the
> question of whether it is possible to adjust the ffmpeg default
> configuation settings used by get_iplayer.

No, but you could add options to get_iplayer that pass parameters to 
ffmpeg, as is already done for rtmpdump.  For an edge case like this, a 
better solution would be to just re-mux the output file while adjusting 
-analyzeduration to suit.  You'll lose a few of the metadata tags in the 
process, but those can be recovered.