theora dev - Mar 2011 - theora-dev Digest, Vol 80, Issue 6

Thank, Timothy!
I add this stages.
About RLE:
I have one more unresolved stage. Mike Melanson wrote in "VP3 Bitstream
Format..." about RLE using:
"* Zigzag Ordering: After transforming and quantizing a block of samples,
the samples are not in an optimal order for run length encoding. Zigzag
ordering rearranges the samples to put more zeros between non-zero
samples."

If we pass zigzaged DCT coeffs of 1 block throw RLE, how after this stage i
can separately write different AC for its AC-plane? For example after
zig-zag we have this:
AC0 =1 AC(1..61) =0  AC62 =1
after RLE we have:
(0,1)(61,1)
How add zero-ACs coeff to AC(1..61) planes? Or i skip them in this planes
and add store only non-zero coeff to plabes?
Thanks
P.S. please give me more critique. More critique - better implementation

On 22 March 2011 22:00, <theora-dev-request at xiph.org> wrote:
> Send theora-dev mailing list submissions to
>        theora-dev at xiph.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        http://lists.xiph.org/mailman/listinfo/theora-dev
> or, via email, send a message with subject or body 'help' to
>        theora-dev-request at xiph.org
>
> You can reach the person managing the list at
>        theora-dev-owner at xiph.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of theora-dev digest..."
>
>
> Today's Topics:
>
>   1. FPGA encode stages flow diagram (digital design)
>   2. Re: FPGA encode stages flow diagram (Timothy B. Terriberry)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 22 Mar 2011 20:42:59 +0300
> From: digital design <developer.fpga at gmail.com>
> Subject: [theora-dev] FPGA encode stages flow diagram
> To: theora-dev at xiph.org
> Message-ID:
>        <AANLkTi=AcCqPOS7U_sWHVw49c=1qvbsbM7BWM+gJuuyn at
mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Good day!
> I create diagram of encoder process. Using it i create implementation of
> encoder in FPGA (Xilinx/Altera). Please critique it. Is there missing
> stages?
> Here is blog http://developer-fpga.blogspot.com/
> Here is picture of encoding stage 1
>
>
https://lh4.googleusercontent.com/-NV8o9DG3jvE/TYjYXr-dYGI/AAAAAAAAAos/U06O-YvhSI0/s1600/stage1.jpg
> Here is picture of encoding stage 2
>
>
https://lh5.googleusercontent.com/--1U5TaiVAEU/TYjYhW4n2OI/AAAAAAAAAow/vRFbzObFhww/s1600/stage2.jpg
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
>
http://lists.xiph.org/pipermail/theora-dev/attachments/20110322/188f7542/attachment-0001.htm
>
> ------------------------------
>
> Message: 2
> Date: Tue, 22 Mar 2011 10:51:55 -0700
> From: "Timothy B. Terriberry" <tterribe at xiph.org>
> Subject: Re: [theora-dev] FPGA encode stages flow diagram
> Cc: theora-dev at xiph.org
> Message-ID: <4D88E1BB.40102 at xiph.org>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> > I create diagram of encoder process. Using it i create implementation
of
> > encoder in FPGA (Xilinx/Altera). Please critique it. Is there missing
> > stages?
>
> So, you're missing motion estimation/motion compensation/macro block
> mode decision/skip decision. These are not required for an encoder, of
> course, but are pretty important for getting compression that is at all
> reasonable. Even just the "NOMV" modes (where the motion vector
is
> always (0,0)) are already a big improvement over all-INTRA. IIRC, this
> is the route the Elphel 333 FPGA encoder took. You're also missing the
> loop filter, though I guess if there's no motion compensation at all
> (not even NOMV), this isn't actually required, either.
>
>
> ------------------------------
>
> _______________________________________________
> theora-dev mailing list
> theora-dev at xiph.org
> http://lists.xiph.org/mailman/listinfo/theora-dev
>
>
> End of theora-dev Digest, Vol 80, Issue 6
> *****************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.xiph.org/pipermail/theora-dev/attachments/20110322/269b47ad/attachment.htm

> How add zero-ACs coeff to AC(1..61) planes? Or i skip them in this
> planes and add store only non-zero coeff to plabes?
I recommend looking at how libtheora does this. The encoder translates 
things into the "tokens" which represent various combinations of 
coefficient values, zero runs, and "End Of Block" (EOB) markers. See
the
Theora specification for details. It stores these values to an 
intermediate buffer (for the purposes of re-ordering them) before 
translating them into Huffman codes. You won't have a token for every 
coefficient, but the token value (along with some amount of "extra 
bits", which varies depending on the token value) encodes all the 
information you need about whether or not there is a zero run at a given 
position, how long it is, etc.

libtheora has to go through some trickery to handle the DC values, 
because DC prediction occurs in raster order, not coded order. Since 
you're generating tokens in raster order, this shouldn't be an issue for
you, as you can do DC prediction before tokenization.

However, you won't be able to use runs of EOBs, because these operate 
across blocks in coded order (as opposed to runs of zero coefficients 
operate within a single block). You may be able to fix this up in a 
separate post-processing stage (e.g., as part of the translation to 
Huffman codes). I.e., instead of writing out an EOB token immediately, 
buffer it and if the next token is also an EOB token, then extend the 
previous one into a longer run of EOBs, otherwise write out the buffered 
EOB token, if any.

On 03/22/2011 03:55 PM, Timothy B. Terriberry wrote:
>> How add zero-ACs coeff to AC(1..61) planes? Or i skip them in this
>> planes and add store only non-zero coeff to plabes?
> 
> I recommend looking at how libtheora does this. The encoder translates 
> things into the "tokens" which represent various combinations of 
> coefficient values, zero runs, and "End Of Block" (EOB) markers.
See the
> Theora specification for details.
Pages 21-22 of

http://www.lca2010.org.nz/slides/50119.pdf

may also be helpful.

--Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
Url :
http://lists.xiph.org/pipermail/theora-dev/attachments/20110322/4a22b562/attachment-0001.pgp