Hi

On Fri, Aug 17, 2007 at 12:21:03PM +0200, Marco Gerards wrote:
> Hi,
> 
> At the moment I am working on the Dirac encoder.  This is the first
> time I write a video encoder and I am not yet familiar with which
> other encoders have similar issues.  I hope some of you can give me a
> push in the right direction, a good approach from the beginning can
> save a lot of time.
> 
> The main issue I encountered is writing out subbands encoded using
> arithmetic coding.  They have to be prefixed with their length,
> encoded using exp. Golomb (so variable length).

more good dirac design ;)


> 
> At the moment I have a PutBitContext, but of course I can not write
> this data in sequence.  What would be the right approach?  Creating a
> new PutBitContext, use it to do the arithmetic coding, write the
> golomb code to the first PutBitContext.
> 
> After that I have to skip_put_bytes for the first PutBitContext,
> memcpy the data and continue from there.
> 
> As for the buffer to use for arithmetic coding, how much memory do I
> have to reserve for this?  For my feeling it has to be about the size
> of the frame to fit within any safety margin (for both band coding and
> MC data coding).  I assume I just have to do this at encoder
> initialization time.

you could also use the normal output buffer, leave some space for the
exp golomb code and use memmove()


> 
> So hopefully I am on the right track.  I rather hear "your ideas are
> silly" than "your code sucks" after finishing this code :-).  Are
> there any other issues regarding encoding I could encounter and have
> to take care of?  Any help on this can save me lots of time :-).

choosing optimal motion vectors, block sizes, quantization factors, actually
quantizing wavelet coefficients optimally ...

the normal way to find optimal choices in the encoder is to make choices so that
distortion + number of bits needed to store it * constant is at its mimimum

distorion here normally is the sum of the squared differences
constant can be contant for the whole movie and set based on AVCodecContext.
global_quality
with (non orthogonal) wavelets and adaptive arithmetic coding things like
distortion and number of bits can generally not be found exactly without
considering too many other variables
yes high quality encoding is not fun nor fast ...

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

Thouse who are best at talking, realize last or never when they are wrong.

Attachment: signature.asc
Description: Digital signature

_______________________________________________
FFmpeg-soc mailing list
[email protected]
http://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc

Reply via email to