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. --Loren Merritt
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4