mirror of
https://github.com/FFmpeg/FFmpeg.git
synced 2025-02-14 22:22:59 +02:00
Clarify comment block and rewrite in better English.
Originally committed as revision 10837 to svn://svn.ffmpeg.org/ffmpeg/trunk
This commit is contained in:
parent
8622613d9f
commit
3a994ca43b
@ -843,17 +843,17 @@ int ff_find_unused_picture(MpegEncContext *s, int shared){
|
||||
}
|
||||
|
||||
av_log(s->avctx, AV_LOG_FATAL, "Internal error, picture buffer overflow\n");
|
||||
/*we could return -1 but the codec would crash anyway, trying to draw
|
||||
into, a non existing frame, this is safer than waiting for a random crash
|
||||
also the return of this is never usefull, a encoder must only allocate
|
||||
as many as allowed in the spec which has no relation to how many lavc
|
||||
could allocate (and MAX_PICTURE_COUNT is always large enough for such
|
||||
valid streams)
|
||||
and a decoder has to check stream validity and remove frames if too many
|
||||
reference frames are around. waiting for "OOM" is not correct at all, it
|
||||
similarely has to replace missing reference frames by (interpolated/MC)
|
||||
frames anything else is a bug in the codec ...
|
||||
*/
|
||||
/* We could return -1, but the codec would crash trying to draw into a
|
||||
* non-existing frame anyway. This is safer than waiting for a random crash.
|
||||
* Also the return of this is never useful, an encoder must only allocate
|
||||
* as much as allowed in the specification. This has no relationship to how
|
||||
* much libavcodec could allocate (and MAX_PICTURE_COUNT is always large
|
||||
* enough for such valid streams).
|
||||
* Plus, a decoder has to check stream validity and remove frames if too
|
||||
* many reference frames are around. Waiting for "OOM" is not correct at
|
||||
* all. Similarly, missing reference frames have to be replaced by
|
||||
* interpolated/MC frames, anything else is a bug in the codec ...
|
||||
*/
|
||||
abort();
|
||||
return -1;
|
||||
}
|
||||
|
Loading…
x
Reference in New Issue
Block a user