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.htm
> 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.
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/812098a9/attachment.htm
Good day! in Theora spec wrote (page 18, paragraph "DCT Coe cients"): "...Tokens are grouped in the stream by token index, not by the block they originate from. This means that for each zig-zag index in turn, the tokens with that index from all the coded blocks are coded in coded block order. When decoding, a current token index is maintained for each coded block. This index is advanced by the number of coe cients that are added to the block as each token is decoded. After fully decoding all the tokens with token index ti , the current token index of every coded block will be ti or greater...." ok. for example, my encoder produce only two blocks: 1) in first block (after DCT) i have AC0=1; AC(1..62)=0; AC63=1; so, after zig-zag + RLE have tokens for AC0=(0,1); AC63=(62,1) 1) in first block (after DCT) i have AC0=1; AC1=1; AC(2..62)=0; AC63=1; so, after zig-zag + RLE have tokens for AC0=(0,1); AC1=(0,1); AC63=(61,1) Acording to paragraph "DCT Coe cients", encoder must pack coefficients by token index (index = zig-zag number of coeff), ok i pack: for index=0: (0,1);(0,1); ... .. for index=63: (62,1);(61,1) what about tokens for index 1-61? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/theora-dev/attachments/20110324/3cc84431/attachment.htm
>>* is advanced by the number of coe cients that are added to the block as each*>>* token is decoded. After fully decoding all the tokens with token index*>>* ti , the*>>* current token index of every coded block will be ti or greater...."* >You need to read Section 7.7 of the spec thoroughly. I don't think you >understand what a "token" represents yet.>>* ok.*>>* for example, my encoder produce only two blocks:*>>* 1) in first block (after DCT) i have*>>* AC0=1;* >I assume you mean DC, not AC0.>>* AC(1..62)=0;*>>* AC63=1;*>>* so, after zig-zag + RLE have tokens for*>>* AC0=(0,1);*>>* AC63=(62,1)* >What you _actually_ have is (token,extra bits) pairs like so >DC=(9, no extra bits) (i.e., value token, value==1) >AC1=(8,111110) (i.e., zero run token, run-length==62) >AC63=(9, no extra bits) (i.e., value token, value==1)>*>** 1) in first block (after DCT) i have*>I assume you meant in the second block.>*>** AC0=1;*>*>** AC1=1;*>*>** AC(2..62)=0;*>*>** AC63=1;*>*>** so, after zig-zag + RLE have tokens for*>*>** AC0=(0,1);*>*>** AC1=(0,1);*>*>** AC63=(61,1)*>Again, the _actual_ tokens you would use are: >DC=(9, no extra bits) (i.e., value token, value==1) >AC1=(9, no extra bits) (i.e., value token, value==1) >AC2=(8,111101) (i.e., zero run token, run-length==61) >AC63=(9, no extra bits) (i.e., value token, value==1)>*>** what about tokens for index 1-61?*>The first block only has tokens for indexes 0, 1, and 63, which generate >1 coefficient value, 62 coefficient values, and 1 coefficient value, >respectively (for a total of 64).>The second block has tokens for indexes 0, 1, 2, and 63, which generate >1, 1, 61, and 1 coefficient, respectively, again for a total of 64.>As an aside, actually having 64 coefficients in a block is unusual. It >happens, but it is much more common to end with a long zero run. It is >important not to actually code these as zero runs, but using an "End Of >Block" (EOB) token (token values 0...6). EOBs are much, much cheaper >than using an explicit zero run to end the block, in terms of bits.Thank you Timothy! Now i undestand how tokens are made from zig-zaged block. I redraw stage-I in my blog http://developer-fpga.blogspot.com/, see diagram https://lh4.googleusercontent.com/-wDLGljOWTCs/TY3ofIhqNzI/AAAAAAAAAp8/nvdCht-qjbc/s1600/stage1.a.jpg But i'm litle confused seen table 7.38 of Theora spec. How i understand we use only 8 bit values in coder (for quantized coefficient of block), but in table 7.38 is (for example token value 22) i see tokenization of values more than 255? How it's possible? Extrabits for token value=22 is 10 bits. This mean we can present -512..+512 magnitude values for coeffs..... How it's possible? Ok. May be this is why when DCTed our 8-bits values we at result have 16-bits value out. Ok this is understand, but why realy thear are tokens fo 10-bits value? (Is it because we use quantization ?) * * -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/theora-dev/attachments/20110326/0ba3cd3c/attachment.htm
Thank you Timothy! Now i undestand how tokens are made from zig-zaged block. I redraw stage-I in my blog http://developer-fpga.blogspot.com/, see diagram https://lh4.googleusercontent.com/-wDLGljOWTCs/TY3ofIhqNzI/AAAAAAAAAp8/nvdCht-qjbc/s1600/stage1.a.jpg But i'm litle confused seen table 7.38 of Theora spec. How i understand we use only 8 bit values in coder (for quantized coefficient of block), but in table 7.38 is (for example token value 22) i see tokenization of values more than 255? How it's possible? Extrabits for token value=22 is 10 bits. This mean we can present -512..+512 magnitude values for coeffs..... How it's possible? Ok. May be this is why when DCTed our 8-bits values we at result have 16-bits value out. Ok this is understand, but why realy thear are tokens fo 10-bits value? (Is it because we use quantization ?) * * -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/theora-dev/attachments/20110326/3bfd18b7/attachment.htm
Reasonably Related Threads
- FPGA implementation
- theora-dev Digest, Vol 80, Issue 6
- [LLVMdev] Req-sequence, partial defs
- alghorithm of working encoder in libtheora
- theora encoder reordering, order of puting data from DCT 8x8 blocks to huffman compressor, and puting result of huffman compressor to buffer bitstream memory