[FFmpeg-devel] [PATCH] H.264 predictive lossless: again

Michael Niedermayer michaelni
Sat Nov 29 16:12:36 CET 2008

On Sat, Nov 29, 2008 at 03:58:05AM -0800, Jason Garrett-Glaser wrote:
> > i cannot see any sense in this change, nor in the similar ones for other
> > block sizes. It should be well possible to leave the prediction alone
> > add the residual and modify the result in the special cases
> I'll deal with the trivial points later; this appears to be the main
> substantive issue here.
> The easiest, fastest, and least-code way to do predictive lossless is
> as follows:
> Zero fdec
> Add residual to fdec, *without saturation*, so negative numbers get
> stored as wrapped-around positive values/etc.  This works because the
> standard specifies that overflow shall not occur with
> transform_bypass, and so saturation never has to be handled with real
> bitstreams.
> Do prediction
> Are you saying that we should instead make a new residual_add function
> that *sets* the pixel values equal to the residual instead of
> *adding*, so that zero isn't necessary?

what i actually had in mind was that the new prediction function would just
do 1 subtract more and thus revert the effect of the existing prediction.
This actually should be less code.
the extra subtract should be pretty fast with SIMD and it avoids some of
the new code ...
It also limits the special cases to non zero residuals, dunno how common
that is with lossless though.


Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

When you are offended at any man's fault, turn to yourself and study your
own failings. Then you will forget your anger. -- Epictetus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20081129/c62a3c1f/attachment.pgp>

More information about the ffmpeg-devel mailing list