[FFmpeg-devel] [RFC] simplify interplayvideo.c
Sat Mar 28 18:44:21 CET 2009
On Sat, Mar 28, 2009 at 10:00:31AM -0700, Mike Melanson wrote:
> Reimar D?ffinger wrote:
> > On Wed, Mar 04, 2009 at 06:06:01PM -0800, Mike Melanson wrote:
> >> Reimar D?ffinger wrote:
> >>> On Wed, Mar 04, 2009 at 08:02:20AM -0800, Mike Melanson wrote:
> >>>> Reimar D?ffinger wrote:
> >>>>> reportedly this decoder has some issue on big-endian systems.
> >>>> Can you repro the bug on PPC64?
> >>> Fixed. You can use this commandline for FATE (possibly adding bitexact,
> >>> just in case):
> >>> ffmpeg -i baldursgate-logo.mve -pix_fmt bgr24 -f framecrc -
> >>> Note that you can not use framecrc directly, since the pal8 format
> >>> includes a palette which is stored in machine-endian format, thus you
> >>> have to convert it.
> >> Yes, that's necessarily how FATE has to structure its tests for PAL8
> >> decoders.
> >> Success! Thanks for finding that. I will get a FATE test staged soon.
> > Any news? The decoder is in a pitiful state, and people already seem
> > interested in implementing the 16-bit decoding which should be much
> > easier if the existing code wasn't so pointlessly complex...
> How do you suggest simplifying the code? I have never found that the
> ipmve video decoder was very complicated, just tedious (16 different
> coding modes).
Well, as in the patch at the start of the thread.
Most important: replace many loops by memcpy/memset, use ?: where
appropriate, and also nonsense like the COPY_FROM_* macros that
1) could be made much nicer (inline?) functions
2) triplicate _exactly_ the same code except for one single pointer
I also suspect that those magic P/B splitting and bit-twiddling in
ipvideo_decode_block_opcode_0x8 could be greatly simplified, at least it
should not be necessary to duplicate almost identical code in four
More information about the ffmpeg-devel