[FFmpeg-trac] #3204(avcodec:new): VC1 Intensity Compensation is always used once encountered

FFmpeg trac at avcodec.org
Sat Dec 7 06:30:21 CET 2013


#3204: VC1 Intensity Compensation is always used once encountered
-------------------------------------+-------------------------------------
             Reporter:  mcarter      |                     Type:  defect
               Status:  new          |                 Priority:  normal
            Component:  avcodec      |                  Version:  git-
             Keywords:  vc1          |  master
  intensity compensation             |               Blocked By:
             Blocking:               |  Reproduced by developer:  0
Analyzed by developer:  0            |
-------------------------------------+-------------------------------------
 I noticed that VC1 decoding performance dropped after upgrading to the
 latest git code. I profiled it and found that a lot (double-digit %) of
 time was spent in `libavcodec/vc1dec.c:vc1_mc_1mv` under "`if (use_ic)
 ...`".

 I created the attached patch, intcomp.patch (just output from git diff),
 to instrument libavcodec and I ran:

 {{{
 % ffmpeg -t 60 -i BigBuckBunny_1080p24.wmv -an -f null -
 ...
 g_identity_lut_count: 41704276, g_non_identity_lut_count: 154612
 g_vc1_mc_1mv_calls: 10474337, g_use_ic_times: 10464722
 }}}

 The file is from http://bit.ly/bbbwmv which is from
 http://msdn.microsoft.com/en-us/expression/hh553539.aspx.

 The result was that for 60 sec of decoding this VC1 Advanced Profile
 video, vc1_mc_1mv was called 10,474,337 times and of that, it did
 intensity compensation 10,464,722 times (99.9% of the time). It seems
 highly improbable that intensity compensation is needed on every single
 call. Indeed, the instrumentation shows the number of times the intensity
 compensation lookup tables (luty, lutuv) don't do anything (because they
 are the identity mapping) and it is the majority of the time
 (41704276/(41704276+154612)=99.63%). Thus, this suggests a bug in the
 code.

 I looked at the git history and this might be the commit that introduced
 this issue, but I'm not sure:

 http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=782ebd611824c95201123aeccc85809ce1554e6e

 I looked at the source code and it seems that once `v->next_use_ic` and/or
 `v->last_use_ic` are set to 1, they might never go back to 0, perhaps
 causing the issue (once intensity compensation is encountered in the file,
 it is used forever). But I'm not very familiar with this code, so I'm not
 sure. Maybe I'm totally misunderstanding everything and intensity
 compensation is required for the entire file, even though most of the
 times it doesn't do anything?

--
Ticket URL: <https://trac.ffmpeg.org/ticket/3204>
FFmpeg <http://ffmpeg.org>
FFmpeg issue tracker


More information about the FFmpeg-trac mailing list