[FFmpeg-devel] [PATCH] mpeg2: fix block_last_index when mismatch control modifies last coeff
Tue Jun 22 01:56:49 CEST 2010
Michael Niedermayer <michaelni at gmx.at> writes:
> On Mon, Jun 21, 2010 at 11:42:01PM +0100, M?ns Rullg?rd wrote:
>> Jason Garrett-Glaser <darkshikari at gmail.com> writes:
>> > On Mon, Jun 21, 2010 at 3:23 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
>> >> I dont understand your problem, nor can i relate your rant to the
>> >> existing code The code as is, is fast, simple and there are no
>> >> special cases in any idct currently You seem to start your
>> >> argumentation on the need of a change.
>> > We are trying to make things a lot faster. You are stopping us
>> > because we may need to make something very marginally slower in order
>> > to get the large speed boost. You're stopping us from adding a larger
>> > engine to a racecar because the bigger exhaust pipe would slightly
>> > increase drag.
>> > I'm trying to merge parts of a local changeset I have that makes the
>> > FLV decoder 30-40% faster overall (many parts may apply to mpegvideo
>> > overall). Some of these parts are unmergable, but others are quite
>> > mergable. And you're stopping us from merging them because we might
>> > strip 2 clocks off one function to improve another by 150.
>> The corrected block_last_index for mpeg2 will have _no effect at all_
>> immediately. When the idct is optimised, it will be faster when a
>> shortcut is possible, unchanged otherwise. It is true that without
>> lots of extra work, mpeg2 will not get the full benefit of such
>> optimisations. However, without the fix, mpeg2 decoding will break
>> with the optimised idct.
> why would it break?
Because it would use invalid shortcuts when coeff 63 has been modified
without updating block_last_index.
> I would have expected that we would have a function pointer to a dc idct
> that could just be made to point to the normal idct for mpeg2
DC is not the only special case to optimise for. Which cases are
possible to shortcut depend on the nature of each optimised idct. For
this reason, my current plan is to pass last index to the idct and let
each implementation do whatever is best based on this. There will
thus be no new function pointer.
> (and keep in mind we talk about changes that ive never seen)
Nor have I, since I have yet to write the code.
mans at mansr.com
More information about the ffmpeg-devel