[FFmpeg-trac] #764(avcodec:new): Increasing robustness of runlength decoding for scantable access in mpeg12.c

[FFmpeg]

#764: Increasing robustness of runlength decoding for scantable access in
mpeg12.c
-------------------------------------+-------------------------------------
             Reporter:  erik         |                    Owner:
                 Type:  defect       |                   Status:  new
             Priority:  normal       |                Component:  avcodec
              Version:  unspecified  |               Resolution:
             Keywords:  mpeg         |               Blocked By:
  robustness                         |  Reproduced by developer:  0
             Blocking:               |
Analyzed by developer:  0            |
-------------------------------------+-------------------------------------

Comment (by reimar):

 Do you have any numbers on how much "fast" helps? MPEG-2 decoding should
 be really cheap by today's standards and I wouldn't expect it to really
 help much.
 Worse, with errors as in your case it will even process a large amount of
 data for no purpose.
 My recommendation would be
 1) try without fast flag. You get error concealment and it might not have
 a relevant cost. (note: only for decoding, if you are also encoding you
 should keep it for that part).
 2) Should it be relevantly slower, try leaving the fast flag in but use
 the non-fast functions for this case.
 3) Add the > 63 check as in the other cases instead. It should be only
 little to not at all slower than your change for the normal decoding case
 and it should be _much_ faster for the error case (if you reached values
 like 7000 that would indicate that you looped around that loop about 100
 times more than necessary).

 And I don't want you to apologize, and I don't want you to give up because
 I sometimes get a bit annoyed. But it is a really good idea for you to be
 aware of any non-default configuration you have chosen and to mention it
 in bug reports. And also to make sure you have a solid justification for
 it, since they might cause you a significant maintenance cost in the long
 term. Apart from that there clearly is a lack of documentation we are to
 blame for.

-- 
Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/764#comment:15>
FFmpeg <http://ffmpeg.org>
FFmpeg issue tracker