[FFmpeg-devel] Parallelized h264 proof-of-concept
Sun Jun 3 12:20:35 CEST 2007
On Sat, Jun 02, 2007 at 06:10:22PM +0200, Andreas ?man wrote:
> Mathieu Monnier wrote:
> >>o deblocking doesn't work correctly.
> >There's a flag (per picture?) indicating whether the deblocking must be
> >done accross slice boudaries or not.
> Yep, h264.c sets "h->deblocking_filter = 2" in this case.
> I have, however, discovered that filter_mb_fast() does not seem to
> comply with this deblocking mode. I assume filter_mb_fast() is supposed
> to be bit-exact to filter_mb(), no?
> Did some tests with md5 sums and replaced the filter_mb_fast()
> with just filter_mb()
> File a has deblocking type 0 and 1 (trailer from apple.com)
> File b has deblocking type 2 (Discovery HD)
> File c has deblocking type 2 (Swedish television HD)
> file a: 62f4b715fe34e890b31f09d994320ee2 with filter_mb_fast
> file b: 59814559192176465f21fa524cf88604 with filter_mb_fast
> file c: 3ea5a957eaa71cfd8d22730af96496e1 with filter_mb_fast
> file a: 62f4b715fe34e890b31f09d994320ee2 with filter_mb
> file b: 64f5b254ead02014b8d0121b38434ce2 with filter_mb
> file c: 7326302eac34979fe9df7f2205790495 with filter_mb
> The attached patch remedies this.
> file a: 62f4b715fe34e890b31f09d994320ee2 with patch
> file b: 64f5b254ead02014b8d0121b38434ce2 with patch
> file c: 7326302eac34979fe9df7f2205790495 with patch
if loren has no comments / objections then iam ok with the patch
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
I know you won't believe me, but the highest form of Human Excellence is
to question oneself and others. -- Socrates
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the ffmpeg-devel