Wav probing is behaving badly over HTTP

[sds]

This is reproducible in latest git, but was not broken in git 9763420 (05/16/2011). Problem was initially discovered via direct interaction with FFmpeg API's but is reproducible in FFplay in identical fashion.

When starting playback of WAV streams via HTTP, I observe 1000's of seeks past the end of the stream, resulting in server properly responding 416 Request Range Not Satisfiable. Eventually normal playback does happen, so presumably this is happening within the probing functions. In FFplay you'll see:

[http @ 03B41F60] HTTP error 416 Request range not satisfiable

Last message repeated 5625 times

[wav @ 01EDB760] max_analyze_duration 5000000 reached at 5015510
Input #0, wav, from '​http://url.to.stream.'

Duration: 00:03:04.21, bitrate: 1411 kb/s

etc.

No analysis was done for wav files stored on disk. This behavior is observed on each and every of a wide variety of WAV streams.

Here are the stream offsets (captured from HTTP server logfile) the decoder is seeking out for a sample wav stream of length 32495276 bytes. This is notable because the first request for a nonzero offset is exactly 1 byte past the end of the stream. It goes haywire from there.

Range: bytes=0-
Range: bytes=32495276-
Range: bytes=4289986657-
Range: bytes=4290641986-
Range: bytes=4292935779-
Range: bytes=4294049943-
Range: bytes=4290642071-

[Stefano Sabatini]

Should be fixed in commit:

commit f86d260df305ebde41093cb6de6de03e0d076356
Author: Tomas Härdin <tomas.hardin@codemill.se>
Date:   Fri May 27 22:01:32 2011 +0200

    wav: Don't avio_seek() if we know we'll run into EOF
    
    Since we want to break the loop the 'if (data_ofs < 0)' block is moved after the loop.
    This fixes ticket #250.