I've found one potential issue with crf and possibly other RC modes which i think relates to ratecontrol overcompensating when the max bitrate is hit. I've been rolling my own compiles and following closely (i've got google reader pointed at github). colorprim smpte170m -colormatrix smpte170m -transfer smpte170m keyint 12 -bframes 2 -vbv-maxrate 9400 -vbv-bufsize 1835 -crf 1 -fake-interlaced -sar 16:9 X262 parkjoy_paldvd-lossless.mkv -o parkjoy_paldvd-new.m2v -mpeg2 -preset placebo -tune film -open-gop Intra probably needs some tweaking, but encoding is about 20% faster overall (depending on preset). I've only tested on foreman and parkjoy, but it seems better. Recents commits now use use the same deadzone quant algorithm as x264. this has really come a long way in a short time! about right for something that's crippled with fullpel. I just tried it with the mpeg matrix and it looks a lot better. i'm testing more out of curiosity than anything serious. I wont release my compile for this reason - i can't be sure i didn't do anything wrong in the compile (it's my first time), and if unofficial binaries start floating around at this early stage, the encoder might get an undeserved reputation before it gets a chance to be finished. Tl dr: this is not ready for general consumption yet. no interlace as yet, but there is alternate scan. by "surprisingly good", i was expecting something like the screenshot at the start of this thread. the encoder seems to bias toward making grainy noise rather than flat blocks, which is good news for film lovers, especially when hpel gets implemented. quality is surprisingly good, with the occasional blocky glitch on movement. output streams are not compatible with DVD authoring programs (spruce gives me a "temporal references out of order" error). crf values are comlpetely unrelated to those that x264 uses - try much lower values i imagine this is a largish undertaking on account of h.264 having different filtering etc for qpel than mpeg-2's hpel. fullpel only for now (set subme to 0), as x264's qpel seems to get mapped to hpel and thus the blocks are moved twice as far as they should be. avs, raw and y4m support only (unless i'm doing it wrong). Here's a rundown of what i can see so far: i'm a complete newb at this, but it all worked smashingly in windows. I followed an x264 compiling guide and git'ed from x262's repo.
#GV CANOPUS PROCODER 3 FULL UPDATE#
In case anyone's after an update of sorts.įirst up, this is a fantastic project - just thought i'd add some encouragement to kierank and ifb's efforts on this.