#160 libavformat/ffm.c contains bad ring buffer logic

open
nobody
None
5
2004-01-26
2004-01-26
Anonymous
No

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?

Discussion

  • This Sourceforge bug tracker here has been abandoned many years ago.

    Our new tracker can be found through http://www.ffmpeg.org/bugreports.html