Jeff Downs <[email protected]> added the comment:
File is corrupted such that an mb_y (slice number) equal to the mb_height is
encountered.
The computation and comparison that is allocating thread contexts to roughly
equal fractions of the image to decode depends on mb_y being strictly less than
mb_height.
With mb_y >= mb_height, the check deciding to allocate a thread or not will be
true even after all threads are already allocated.
Attached fixes by giving out thread contexts only when mb_y is valid.
When the invalid slice is at the middle or end of a coded picture, it won't
matter at all -- the last thread assigned will just encounter the bad slice,
catch the bad y address, and error the slice. For invalid slices at the start,
they will be skipped.
----------
substatus: reproduced -> analyzed
_____________________________________________________
FFmpeg issue tracker <[email protected]>
<https://roundup.ffmpeg.org/roundup/ffmpeg/issue1277>
_____________________________________________________
Index: libavcodec/mpeg12.c
===================================================================
--- libavcodec/mpeg12.c (revision 19505)
+++ libavcodec/mpeg12.c (working copy)
@@ -2418,7 +2418,7 @@
if(avctx->thread_count > 1){
int threshold= (s2->mb_height*s->slice_count +
avctx->thread_count/2) / avctx->thread_count;
- if(threshold <= mb_y){
+ if(threshold <= mb_y && mb_y < s2->mb_height){
MpegEncContext *thread_context=
s2->thread_context[s->slice_count];
thread_context->start_mb_y= mb_y;
