[FFmpeg-devel] [PATCH] Re: Color corruption and seeking errors with H264 disc sources
Fri Jun 29 00:25:40 CEST 2007
On Wed, Jun 27, 2007 at 11:20:28AM +0200, Andreas ?man wrote:
> Hi (again)
> Andreas ?man wrote:
> >I no one else does it, i might take a look at this tomorrow if i can
> >find some time. But please, since i'm no h264 expert, if someone with
> >more expertise takes a look at it, drop me a mail or something so
> >i dont wast my time.
> The following patch fixes the issue (at least it looks much better,
> but i have no reference decoder to make a binary verification)
> Can you please try it?
> There is a slight slowdown though, (see qp-timings.txt)
> I'll look if some parts can be rewritten or optimized in some way.
> Comments welcome..
well as its a bugfix its needed evem if it slows the code down, but of
course applying a bugfix which slows the code down is a last resort
id suggest to always assume that the qp is the same for the
fast/simple paths and add a check or flag which prevents these paths
from being taken if qp does differ
try to merge the av_clip() into the chroma_qp table, this should
make get_chroma_qp faster, if its slower check if anything changed in what
functions get inlined with nm h264.o
(the chroma_qp change belongs into a seperate patch) but it should decrese
the impact of running get_chroma_qp twice
it might be possible to put some of the chroma qp calculation under
if(qp_diff) so that they are limited to macroblocks where the qp changes
also it might be advantaneous to store the 2 chroma qp and luma qp for
each MB to prevent the chroma qp recalculation which is done a few
times i think (this too belongs in a seperate patch)
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Republics decline into democracies and democracies degenerate into
despotisms. -- Aristotle
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the ffmpeg-devel