[FFmpeg-soc] [soc]: r704 - dirac/libavcodec/dirac.c

Michael Niedermayer michaelni at gmx.at
Sun Aug 12 19:57:43 CEST 2007


Hi

On Sun, Aug 12, 2007 at 12:16:25PM +0200, Marco Gerards wrote:
> Michael Niedermayer <michaelni at gmx.at> writes:
> 
> [...]
> 
> > performing lifting pass X over the whole image and then pass X+1 over the
> > whole image is not very cache friendly
> > it would be better to perform lifting pass X for a line then pass X+1 for
> > whatever line(s) it can be performed with the data which became available
> > and then do pass X for the next line, ...
> >
> > also look at snow.c::lift() maybe something like that could be used to
> > simplify the code
> 
> Yes, I will try to look into this.
> 
> Will it be possible to share code between Dirac, JPEG2000 and Snow
> after SoC?  Dirac uses the (9,7) and (5,3) wavelets by default.

the (5,3) filter should be shareable between j2k, snow and dirac

the (9,7) is not shareable between dirac and snow, both use integer
approximatons of the (9,7) daubechies filter but they use different ones
jpeg does not use an approximation but the exact daubechies filter

for fast low quality decoding of jpeg2k the snow or dirac 9,7 filter
can likely be used but that requires testing, also for the snow filter
the scaling in j2k has to be modified

anyway j2k is in bad shape, mike tries to contact kamil since some time
with no luck, so i wouldnt expect that there will be a j2k decoder this
year at all ...


> 
> Other wavelets it supports are (13,5), Haar (no shift), Haar (shift
> per level), Haar (double shift per level), Fidelity Filter and (9,5).
> I really hope code can be shared after SoC so this can be optimized.

snow only supports 9,7 and 5,3 as ive not found any advantage in supporting
further filters, i dunno about current j2k, but the draft of j2k i read a long
time ago also only supported 9,7 and 5,3


> 
> The same is true for OBMC.  Next week I want to start looking into the
> encoder.  Would it be easy to use your code from Snow, or would it be
> that different that a new implementation is required?

i doubt that anything from the OBMC code can be shared but i didnt look too
carefull at it what maybe can be shared is the iterative motion estimation,
that would be quite nice for dirac quality wise ...


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The greatest way to live with honor in this world is to be what we pretend
to be. -- Socrates
-------------- 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-soc/attachments/20070812/bd94ad03/attachment.pgp>


More information about the FFmpeg-soc mailing list