[Ffmpeg-devel] H.264 decoding bug

Diego Biurrun diego
Fri Jan 12 17:56:48 CET 2007

On Thu, Jan 11, 2007 at 03:38:38PM -0700, Loren Merritt wrote:
> On Sun, 7 Jan 2007, Diego Biurrun wrote:
> >On Fri, Jan 05, 2007 at 05:27:56PM -0800, Nicholas Schell wrote:
> >>http://lists.mplayerhq.hu/pipermail/ffmpeg-user/2007-January/006054.html
> >>I previously responded to ffmpeg-user with the above linked report,
> >>but did not know much about the problem at the time.
> >>
> >>However now I have much more information which may be of help in
> >>solving the bug. Thanks to nk215 asking about my thread on the mplayer
> >>IRC channel, I know at least that other individuals on linux can
> >>confirm the blocking in the samples with current ffmpeg builds. Just
> >>as well he also found exactly which ffmpeg revision seems to cause the
> >>problem, r6578.
> >>
> >>I compiled ffplay myself with mingw to confirm his results. Revision
> >>6577 shows none of the blocking, but 6578 does. It appears exactly the
> >>same as the blocking in current in builds. Also if there were some
> >>qualms about whether the files could in fact be the problem because of
> >>an error on part of the H.264 encoder used, I tested each file with
> >>the JVT reference H.264 decoder. All three files were decoded
> >>flawlessly with no blocking at all. Not that it would matter but
> >>CoreAVC also has no issues with these files.
> >>
> >>The sample files are now located here
> >>http://samples.mplayerhq.hu/V-codecs/H264/
> >
> >I can confirm the blocking artifacts.
> Calling it "blocking artifacts" is misleading. It's a bitstream parsing 
> error, as expected since that the revision in question modified cabac. 
> Given that the codec failed to parse the bitstream, the blocking is 
> intentional error concealment.

I called it "blocking artifacts" for lack of a better term to describe
the visual glitches.  In any case I can confirm the decoding problem,
which appears to be a regression, so it's serious.


More information about the ffmpeg-devel mailing list