#160 libavformat/ffm.c contains bad ring buffer logic
In libavformat/ffm.c, the logic for wrapping-around &
searching in the ring buffer for the beginning of a key
frame is bad, so that very occasionally a new http
request for a stream simply fails. This occurs iff:
1) ffserver has been running so ring buffer wraps around
2) request comes in just after wrapping-around
3) first chunk in ring buffer contains no key-frame.
In this case, the logic does not "back up" around to the
end of the ring buffer, and fails to find a key frame, even
though one may be available.
Also, the "ffm_is_avail_data()" call and "ffm_read_data()"
call produce inconsistent results, and error handling
further confuses things.
I worked around this by chaning these lines in
ffm_read_data():
/* This packet has no frame headers in it
*/
if (url_ftell(pb) >= ffm->packet_size * 3) {
url_fseek(pb, -ffm->packet_size * 2,
SEEK_CUR);
goto retry_read;
}
/* This is bad, we cannot find a valid
frame header */
return 0;
to these lines:
/* This packet has no frame headers in it
*/
retry_limit +=
ffm->packet_size;
if ( retry_limit
>= ffm->file_size - ffm->packet_size ) {
/* This is bad, we cannot
find a valid frame header */
return 0;
}
/* back up one
packet */
if
(url_ftell(pb) >= ffm->packet_size * 3) {
url_fseek(pb, -ffm->packet_size * 2,
SEEK_CUR);
goto retry_read;
}
/* back up
past end of ring buffer */
else {
url_fseek(pb, ffm->file_size-ffm->packet_size *
3, SEEK_CUR);
goto retry_read;
}
and adding "long retry_limit = 0;" as a local variable.
Perhaps someone can implement a fix like this or better
to this code to prevent ffserver from failing on some
requests when multiple requests for streams come in?
This Sourceforge bug tracker here has been abandoned many years ago.
Our new tracker can be found through http://www.ffmpeg.org/bugreports.html