Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
|
|
Thread Tools | Search this Thread | Display Modes |
25th December 2008, 16:48 | #44 | Link | |
Registered User
Join Date: Mar 2006
Posts: 272
|
Quote:
will you infact be including these essential MBAFF and PAFF decoder options in your base code/app. http://en.wikipedia.org/wiki/H.264 "Flexible interlaced-scan video coding features, including: Macroblock-adaptive frame-field (MBAFF) coding, using a macroblock pair structure for pictures coded as frames, allowing 16×16 macroblocks in field mode (compared with 16×8 half-macroblocks in MPEG-2). Picture-adaptive frame-field coding (PAFF or PicAFF) allowing a freely-selected mixture of pictures coded as MBAFF frames with pictures coded as individual single fields (half frames) of interlaced video. " Last edited by popper; 25th December 2008 at 16:58. |
|
25th December 2008, 20:39 | #45 | Link |
Registered User
Join Date: Feb 2005
Posts: 140
|
I'm not surprised you can make a fast and simple decoder by not supporting interlacing, but it gets harder afterwards.
(didn't you post complaining about "redundant operations" in libavcodec? what part of the decoder was that referring to?) |
27th December 2008, 07:57 | #46 | Link | |
Registered User
Join Date: Nov 2005
Posts: 497
|
Quote:
|
|
27th December 2008, 08:08 | #47 | Link | |
Registered User
Join Date: Nov 2005
Posts: 497
|
Quote:
Regarding to the "redundant operations" in liavcodec, for example, the zerosleft decoding can be merged with the dequantization instead of two loop, take another example, the algorithm of cabac decoding and context computation is very un-efficient. |
|
27th December 2008, 13:33 | #48 | Link | ||
x264 developer
Join Date: Sep 2005
Posts: 8,666
|
Quote:
Quote:
Any suggestion for improved context calculation performance will probably allow me to make x264's RDO faster as well. Same with the actual CABAC decoding--are you suggesting that there is a better way to organize LUTs/similar that results in better faster arithmetic decoding than what LAVC already has?
__________________
Follow x264 development progress | akupenguin quotes | x264 git status ffmpeg and x264-related consulting/coding contracts | Doom10 Last edited by Dark Shikari; 27th December 2008 at 13:47. |
||
27th December 2008, 14:49 | #49 | Link | |
Registered User
Join Date: Nov 2005
Posts: 497
|
Quote:
Regarding to the context calculation, take the coded block flag decoding as a example, const unsigned int iCabac4x4CnxtAdd[8] = {0x9, 0x18, 0x801, 0x810, 0x9, 0x100008, 0x801, 0x100800}; unsigned int contxt = contxt1+contxt2; for(int i=0; i<16; i++) { int contextcurr = contxt&3; contxt >>= 2; if(cbp[i>>2]) { cbf = cabac_dec_symbol(..., contextcurr); if(cbf) { contxt += iCabac4x4CnxtAdd[i&7]; ...... } } } update the contxt1 and contxt2 using the contxt; Yes, I have a faster arithmetic decoding and I have written part of it into the DiAVC. |
|
27th December 2008, 14:54 | #50 | Link | |
x264 developer
Join Date: Sep 2005
Posts: 8,666
|
Quote:
|
|
27th December 2008, 14:56 | #51 | Link | |
Registered User
Join Date: Nov 2005
Posts: 497
|
Quote:
Last edited by schweinsz; 27th December 2008 at 15:02. |
|
27th December 2008, 15:12 | #53 | Link | |
x264 developer
Join Date: Sep 2005
Posts: 8,666
|
Quote:
__________________
Follow x264 development progress | akupenguin quotes | x264 git status ffmpeg and x264-related consulting/coding contracts | Doom10 Last edited by Dark Shikari; 27th December 2008 at 15:28. |
|
29th December 2008, 17:23 | #56 | Link | |
Registered User
Join Date: Nov 2005
Posts: 497
|
Quote:
|
|
29th December 2008, 17:29 | #57 | Link | |
x264 developer
Join Date: Sep 2005
Posts: 8,666
|
Quote:
The reason it isn't useful is: 1. iDCT is really fast. 2. Psy-RD requires iDCT to be done anyways. It isn't really worth optimizing too much for the case of no psy-opts. 3. It would make the code much messier. 4. SSD in transform domain is not *exactly* the same because of rounding. 5. SSD in transform domain would require a new asm function to multiply by the correct DCT weighting values for each coefficient. (By the way, this is the proper approach: suggest ideas before implementing them so that you don't waste time on something that has been concluded to be a bad idea, or so that we can suggest even better ways of doing it.)
__________________
Follow x264 development progress | akupenguin quotes | x264 git status ffmpeg and x264-related consulting/coding contracts | Doom10 Last edited by Dark Shikari; 29th December 2008 at 17:33. |
|
5th October 2009, 23:29 | #58 | Link |
Registered User
Join Date: Nov 2005
Posts: 497
|
I am happy that DiAVC alpha version is released. The diavc.ax and a setting tool is included.
It supports the interlace coding and frame-level parallel. I have tested the DiAVC and compared to other decoders and found that the DiAVC is faster than the coreavc and divx h.264 decoder on my computer (intel core duo T2350 1.86G, ram 1G, FSB 533MHz, harddisk, 80G, ati mobility radeon x1450). |
6th October 2009, 01:21 | #59 | Link |
x264aholic
Join Date: Jul 2007
Location: New York
Posts: 1,752
|
@Dark: Regarding the change that would bork interlacing: Would it really be that bad if you created two code paths, one designed solely for progressive video, and another for field based?
I'm sure there's a very good reason why not to, and the only reasons I could think of where because of massive code duplication and messy code.
__________________
You can't call your encoding speed slow until you start measuring in seconds per frame. |
6th October 2009, 01:23 | #60 | Link | |
x264 developer
Join Date: Sep 2005
Posts: 8,666
|
Quote:
|
|
Tags |
avc, diavc, fastest decoder, h.264, software |
Thread Tools | Search this Thread |
Display Modes | |
|
|