x262 Development Thread

[Lyris]

Yes, the fact that MPEG-2 can do that is news to me!

[ifb]

I meant this kind of thing
http://data.imagup.com/11/1134819774.png (http://www.imagup.com/data/1134819775.html)


In case that can help, I did upload the files here (http://hotfile.com/dl/133939237/3b5b7d5/x262_all_files.7z.html).

But I maybe did it wrong...Your sample is fixed by this (https://github.com/kierank/x262/commit/a31f7c98af001b20f57621649d284c892960e600) commit.

There are still bugs out there, but that was probably the worst one (aside from --subme 1).

[Gromozeka]

There are still bugs out there, but that was probably the worst one (aside from --subme 1).

Sorry, but where I can give binaries x262?
:( You are not compile this.

[Gromozeka]

Thanks to Bugmaster
binaries there:
http://www.mediafire.com/?35clmyf3qu6h81y
The bugs is fixed - best mpeg2 encoder
I compressing with this option:
x262.exe --crf 6 --aq-mode 2 --mpeg2 --no-mbtree --subme 5 --qcomp 0.6 --keyint 15 --
bframes 2 --qpmin 3 --qpmax 31 --vbv-maxrate 9000 --vbv-bufsize 1835 --colorprim smpte170m --
colormatrix smpte170m --transfer smpte170m -o 1_out.m2v 1.avs

[ifb]

Thanks to Bugmaster
binaries there:
http://www.mediafire.com/?35clmyf3qu6h81y
The bugs is fixed - best mpeg2 encoder
I compressing with this option:
x262.exe --crf 6 --aq-mode 2 --mpeg2 --no-mbtree --subme 5 --qcomp 0.6 --keyint 15 --
bframes 2 --qpmin 3 --qpmax 31 --vbv-maxrate 9000 --vbv-bufsize 1835 --colorprim smpte170m --
colormatrix smpte170m --transfer smpte170m -o 1_out.m2v 1.avsBest? I don't believe that. Analysis hasn't really been touched. There are a bunch of things left to add (real interlacing, CQMs, trellis, slice-max-mbs). Speed hasn't been considered (though I do have a faster quant patch nearly finished). Any encoder that x262 may beat at this stage must be really bad. That or x264 is so awesome that even crippling it for MPEG-2, it still beats everything. I haven't done any comparisons myself.

As for your settings, QP min/max is 1 to 31 so your --qpmax 31 is unnecessary (and I wouldn't change qpmin). You also probably want --open-gop.

[Gromozeka]

Best? I don't believe that.
Sorry, I think that x262 is best, my tests already given surprising results, in particular, I was comparing x262 and CCE. x262 has won on all counts.
Here is a series of screenshots:
http://narod.ru/disk/31168326001/01.rar.html
Thank you very much for the x262.

Analysis hasn't really been touched. There are a bunch of things left to add (real interlacing, CQMs, trellis, slice-max-mbs). Speed hasn't been considered (though I do have a faster quant patch nearly finished). Any encoder that x262 may beat at this stage must be really bad. That or x264 is so awesome that even crippling it for MPEG-2, it still beats everything. I haven't done any comparisons myself.

x262 has a great potential for development

[MatLz]

Your sample is fixed by this (https://github.com/kierank/x262/commit/a31f7c98af001b20f57621649d284c892960e600) commit.

There are still bugs out there, but that was probably the worst one (aside from --subme 1). :thanks:

[mp3dom]

I was comparing x262 and CCE. x262 has won on all counts.

You have probably setup CCE (by the way, which version and settings?) in the worst way.

[Gromozeka]

You have probably setup CCE (by the way, which version and settings?) in the worst way.
I do not speak English
Please do yourself tests)))

[mp3dom]

My god... :rolleyes:

By the way the actual stage of x262 is far from 'good-enough' output (quality wise).

[Lyris]

How did you manage to get results that bad out of CCE?

[Gromozeka]

How did you manage to get results that bad out of CCE?
use bitrate 2000-3000 kbps 2 pass
or crf 6 with this option
x262.exe --crf 6 --aq-mode 2 --mpeg2 --no-mbtree --subme 5 --qcomp 0.6 --keyint 15 --
bframes 2 --qpmin 3 --qpmax 31 --vbv-maxrate 9000 --vbv-bufsize 1835 --colorprim smpte170m --
colormatrix smpte170m --transfer smpte170m -o 1_out.m2v 1.avs
Use the options CCE what you like

[TheSkiller]

For most types of video an average bitrate of just 2000-3000 kbit/s (assuming D1 or cropped D1 resolution) is pretty low and therefore will hardly ever give results that are "visually transparent" (while that doesn't mean it's impossible to have an encoded result that is still acceptable). This is MPEG2, often interlaced at full DVD resolution, not Xvid or x264. The required bitrates for DVD are much higher.

Are the file sizes the of the x262 and CCE output roughly the same? Doesn't --crf 6 produce a pretty good quality and therefore usually a higher average bitrate (sorry I don't know)? What I mean is you cannot compare a high bitrate encode to a low bitrate one, obviously the low bitrate one will always look inferior using any encoder.

[Gromozeka]

For most types of video an average bitrate of just 2000-3000 kbit/s (assuming D1 or cropped D1 resolution) is pretty low and therefore will hardly ever give results that are "visually transparent" (while that doesn't mean it's impossible to have an encoded result that is still acceptable). This is MPEG2, often interlaced at full DVD resolution, not Xvid or x264. The required bitrates for DVD are much higher.

Are the file sizes the of the x262 and CCE output roughly the same? Doesn't --crf 6 produce a pretty good quality and therefore usually a higher average bitrate (sorry I don't know)? What I mean is you cannot compare a high bitrate encode to a low bitrate one, obviously the low bitrate one will always look inferior using any encoder.

Sorry,I can hardly speak English, but I can tell - crf 6 gave me the bitrate in the range 2500-3000 kbps with those settings

[ifb]

Recents commits now use use the same deadzone quant algorithm as x264. I've only tested on foreman and parkjoy, but it seems better. Intra probably needs some tweaking, but encoding is about 20% faster overall (depending on preset).

x262 a7c540166a
Binary (http://dl.dropbox.com/u/53163598/x262.rar)

Source (lossless)
Download (http://dl.dropbox.com/u/53163598/parkjoy_paldvd-lossless.mkv)

Old Quant (x262 89f8657800 (http://github.com/kierank/x262/commit/89f8657800132ab8467e55dd0c00dbbc56039053))
Download (http://dl.dropbox.com/u/53163598/parkjoy_paldvd.m2v)

New Quant (x262 a7c540166a (http://github.com/kierank/x262/commit/a7c540166a7e16ca4ef61a6a48e52fcc6c2db157))
Download (http://dl.dropbox.com/u/53163598/parkjoy_paldvd-new.m2v)

x262 parkjoy_paldvd-lossless.mkv -o parkjoy_paldvd-new.m2v --mpeg2 --preset placebo --tune film --open-gop
--keyint 12 --bframes 2 --vbv-maxrate 9400 --vbv-bufsize 1835 --crf 1 --fake-interlaced --sar 16:9
--colorprim smpte170m --colormatrix smpte170m --transfer smpte170m

[Gromozeka]

hm, new patch size gives 20% more in the mode crf 6, but the quality is not better
AQ can not work?

[ifb]

hm, new patch size gives 20% more in the mode crf 6, but the quality is not better
AQ can not work?CRF probably changed, so use a higher value until you get the bitrate you want. Then you can compare.

I think the parkjoy clip is better at the same bitrate. If you don't agree, find better settings. The defaults for --deadzone-intra and --deadzone-inter may need to change. I haven't spent a lot of time on this.

[Gromozeka]

I build be testing over the weekend in mode 2 pass.
but my visual assessment shows that the new algorithm is worse. Maybe it has to be set up, but now the speed is not the most important thing, I'd love to coded old algorithm but with a working Trellis))
Thank you for your work

[Mug Funky]

i've been rolling my own compiles and following closely (i've got google reader pointed at github).

the quality is becoming quite amazing.

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 haven't the maths to fix this myself without making a fool of the bitrate of course. one day.

basically, i've set qcomp to 1.0 and crf to 2 and set the max quite high (25000). bitrate scans show the quantizers steady until the bitrate hits the roof, then the quants shoot up until the bitrate sits at about half of the max, rather than just sitting on the max. i figure it's something to do with the difference in MPEG-2's quants compared to h.264's. looking at the code i can only see one part that could be altered, but i'm not convinced the problem lies there (qp2qscale and qscale2qp).

[edit]

looks like setting qcomp to 0.0 or something low changes the behaviour somewhat, so that might be a better place to look.

[alexins]

x262 mpeg-2 Video Encoder rev. 2314 x86/x64 (git-af1fd71) (http://www.xvidvideo.ru/x262-video-encoder-mpeg-2/x262-mpeg-2-video-encoder-rev-2314-x86-x64.html)

[kieranrk]

x262 mpeg-2 Video Encoder rev. 2314 x86/x64 (git-af1fd71) (http://www.xvidvideo.ru/x262-video-encoder-mpeg-2/x262-mpeg-2-video-encoder-rev-2314-x86-x64.html)

Oh please don't make builds. That implies x262 is remotely usable.

[ifb]

Oh please don't make builds. That implies x262 is remotely usable.Agreed. At the very least it should be labeled as highly experimental.

[Cyber-Mav]

has this project reached the quality levels of CCE yet?

[Selur]

"highly experimental" -> no

[amtm]

has this project reached the quality levels of CCE yet?

Yes, in 15 days it went from the developers stating "That implies x262 is remotely usable" and "At the very least it should be labeled as highly experimental" to being as good as CCE.

[Gromozeka]

has this project reached the quality levels of CCE yet?
Yes, at low bit rates is particularly well seen, but on the test video (park joy) x262 is not better. Probably CCE has been tested on these videos.
On the DVD, and TV shows source x262 better result
P.S: Excuse me for my bad English

[Manaka]

Really? At 1700kbps x262 has worse PQ compare to HCE for me

[Cyber-Mav]

how well is the multithreadding on this comming along?

[marius87]

I downloaded the encoder from XvidVideo.RU and compressed a video but the mpchc (dowloaded from the same site) and mplayer2 not playing this video. Were fin a decoder?

[ifb]

There is experimental interlaced (MBAFF) support if anyone wants to test.

Download x264 0.125.0+2415M e5ae539 (https://dl.dropbox.com/u/53163598/x262-mbaff.zip)

Patch (https://dl.dropbox.com/u/53163598/x262_mbaff_v1.diff) against e5ae539 (https://github.com/kierank/x262/commit/e5ae5392bea99c2b6b565ceb9e6c66b547653e1e)

[ifb]

After all that excellent feedback, I thought I'd post another build. </sarc>

Download x264 0.125.0+2415M 814a5fe (https://dl.dropbox.com/u/53163598/x262-mbaff-v2.zip)

On VQEG sources (ftp://vqeg.its.bldrdoc.gov/SDTV/VQEG_PhaseI/TestSequences/Reference/) 13-22 concatenated:
--tune psnr
tff: x262 [info]: PSNR Mean Y:36.683 U:39.618 V:39.962 Avg:37.414 Global:36.178 kb/s:4429.03
fake-interlaced: x262 [info]: PSNR Mean Y:36.445 U:39.719 V:40.040 Avg:37.238 Global:36.016 kb/s:4415.31

--tune ssim
tff: x262 [info]: SSIM Mean Y:0.9505212 (13.056db)
fake-interlaced: x262 [info]: SSIM Mean Y:0.9477635 (12.820db)

4:2:2 is known to be broken with interlaced, but that's the only super major issue outstanding.

[pandy]

After all that excellent feedback, I thought I'd post another build. </sarc>

:p:thanks::thanks:

[Emulgator]

What would the recent commandline syntax be like ?

[ifb]

What would the recent commandline syntax be like ?
If you're trying out interlaced encoding, the only addition is --tff (or --bff). You will also probably want to use --altscan.
NTSC DVD:
x262 input.avs -o output.m2v --preset veryslow --tune film --open-gop --colorprim smpte170m --colormatrix smpte170m --transfer smpte170m --bframes 2 --vbv-maxrate 9800 --vbv-bufsize 1835 --keyint 15 --fps 30000/1001 --sar 16:9 --crf 1 --altscan --tff

PAL DVD:
x262 input.avs -o output.m2v --preset veryslow --tune film --open-gop --colorprim bt470bg --colormatrix bt470bg --transfer bt470bg --bframes 2 --vbv-maxrate 9800 --vbv-bufsize 1835 --keyint 12 --fps 25 --sar 16:9 --crf 1 --altscan --tff

Note that if the binary is named "x262", you no longer have to add --mpeg2 to you commandline. You can switch to H.264 by using --no-mpeg2 or renaming the binary.

[Emulgator]

Wow, that's versatile !
So just one compile does both, H.264 and H.262 ?
Picture looks good so far, just tried some 1000 frames of grainy interlaced SD and compared roughly to HC.
With a bitrate of 9200 kbit/s and the given vbv-bufsize of 1835 kbit ~ 229 kByte x262's bitrate did overshoot into 10300 Mbps
where HC stayed below 9144kbps (Konran's bitrate viewer, Mode: GOP enhanced).
Too much for DVD I guessed, I just lowered vbv-bufsize to the well known 224 kB = 1792 kbit.
The resulting 9900 kbit/s peak bitrate were more decent.
More to come...

[Emulgator]

Finally got --fullhelp to display completely,
my cmd.exe seems to cut off the beginning up to --ref, leaving only the last 300 lines to be read.
Mulders Simple launcher 2.05 will list --fullhelp of x262.exe completely,
when x262.exe is brought into \toolset and renamed to x264_8bit_x86.exe.

[kieranrk]

(Konran's bitrate viewer, Mode: GOP enhanced).

Use a proper VBV analyser. Elecard might work OK.

[Emulgator]

Hm, the $$ keep me off from Elecard a bit...

Now with a given bitrate of 8500 kbit/s, vbv_maxrate 9000 kbit/s and removed crf=1 parameter
peaks come out around 9500kbit/s.

This is ok to handle for me, I just keep a bit of distance to the limits for now.

Picture quality:
Well detailed.
The --tune film works beautifully with sources that already contain some DCT blocking (like DV).

Some behaviours indeed seem to be inherited from x264.
There are regions that are treated differently:

The "wet patches" (from some x264 revisions back then) still seem to be there:
Within black mattes containing a bit almost homogenous noise after encoding
there might be some wet patches occurring, these come out smoother
while the surrounding parts behave the other way around.

And around sharp borders (white Serif Letters on black) it does look a bit more mosquitoing.
Maybe related.


After scenecuts from film content to black (or colour) matte I found some residual DCT block patterns in the black
(or colour) for the first and a few, maybe 3 to 4 following frames.

This was one of my commandlines:

"C:\_PROG\x262\x262.exe" --demuxer avs "C:\_PROG\x262\x262.avs" --output "C:\_PROG\x262\PAL-DVD.m2v" --preset veryslow --tune film --open-gop --colorprim bt470bg --colormatrix bt470bg --transfer bt470bg --bframes 2 --bitrate 8500 --vbv-maxrate 9000 --vbv-bufsize 1792 --keyint 15 --dc 10 --sar 4:3 --altscan --bff

When aiming for DVD resolutions/bitrates:
With good bitrates (6000-8500kbps) for PAL-SD details are good,
some occasional blocks might come up in parts with strong motion.

With starving bitrates (2500kbps) for PAL-SD blocks may come up heavy,
other encoders seem to help by lowpassing there if they see bitrate starving.

Good work ! Many thanks to you.

[Emulgator]

Some two months later :
Is there a chance to get a more recent build of x262 ?

[the_weirdo]

Some two months later :
Is there a chance to get a more recent build of x262 ?

I think you can find one here:
http://www.xvidvideo.ru/x262-video-encoder-mpeg-2/

[Emulgator]

Many thanks !

[Emulgator]

A brief result:
Unfortunately x262 r2433 stalls after 2frames where r2421 encoded the whole 1140 frames testclip. Same commandline.
Source: 1140 frames SD PAL-DV-avi 720x576x25i BFF.

[ifb]

A brief result:
Unfortunately x262 r2433 stalls after 2frames where r2421 encoded the whole 1140 frames testclip. Same commandline.
Source: 1140 frames SD PAL-DV-avi 720x576x25i BFF.Link to source?

[Emulgator]

FTP upload coming.

Servername: (deleted)
Username: (deleted)
Password: (deleted)

Source file: Werbung 01.avi
Encode r2421: PAL-DVD_r2421.m2v
Encode r2433: PAL-DVD_r2433.m2v

Source Script x262r2433.avs:
AviSource("D:\_VID\Testfiles\Werbung\Werbung 01.avi")
Encode Batch Script
"C:\_PROG\x262\r2433\x262.exe" --demuxer avs "C:\_PROG\x262\x262r2433.avs" --output "C:\_PROG\x262\PAL-DVD_r2433nofkdb.m2v" --preset veryslow --tune film --open-gop --colorprim bt470bg --colormatrix bt470bg --transfer bt470bg --bframes 2 --bitrate 8500 --vbv-maxrate 9000 --vbv-bufsize 1792 --keyint 15 --dc 10 --sar 4:3 --altscan --bff

Should be completely up in 1 hour.

When you successfully downloaded these files, please let me know
so that I can free up the space again.

[ifb]

FTP upload coming.

Servername: ftp.hidrive.strato.com
Username: mulgi
Password: discman

Source file: Werbung 01.avi
Encode r2421: PAL-DVD_r2421.m2v
Encode r2433: PAL-DVD_r2433.m2v

Source Script x262r2433.avs:
AviSource("D:\_VID\Testfiles\Werbung\Werbung 01.avi")
Encode Batch Script
"C:\_PROG\x262\r2433\x262.exe" --demuxer avs "C:\_PROG\x262\x262r2433.avs" --output "C:\_PROG\x262\PAL-DVD_r2433nofkdb.m2v"
--preset veryslow --tune film --open-gop --colorprim bt470bg --colormatrix bt470bg --transfer bt470bg
--bframes 2 --bitrate 8500 --vbv-maxrate 9000
--vbv-bufsize 1792 --keyint 15 --dc 10 --sar 4:3 --altscan --bff

Should be completely up in 1 hour.

When you successfully downloaded these files, please let me know
so that I can free up the space again.
Works for me. It's probably a decoder problem. Why are you even using Avisynth? Just open it directly if you aren't going to process it further. lavf and ffms2 should open a DV AVI file just fine.

--demuxer avs foo.avi
That's the same as having a one-line AVS script with AviSource("foo.avi") in it.

[Emulgator]

Hm, leaving Avisynth out of the chain does not change the picture.
DV-AVI direct into x262: Same source, same commandline: r2421 works, r2433 fails.

WinXPPro32 SP3, CPU T7600G

P.S.
Ah, here it is:

--preset veryslow broke it. If I delete the --preset parameter, r2433 works.
--preset slow works.
--preset slower fails.
--preset veryslow fails.
--preset placebo fails.

[ifb]

Try this debug build (http://www.mediafire.com/download.php?8b17m0f9o069edz). Until I can reproduce or you at least get a backtrace, there isn't much I can do.

To rule out a decoder problem, dump the input to y4m with ffmpeg/avconv and encode that instead.

ffmpeg -i foo.avi out.y4m

[ifb]

Hm, leaving Avisynth out of the chain does not change the picture.So you used "--demuxer lavf" and/or "--demuxer ffms"?

[Emulgator]

Edit: The following is not about the debug build. Still about r2433

I followed your suggestion:
--demuxer avs <filename>.avi

Just tried lavf and ffms. Fails with --preset veryslow as well.

For a brief moment I could spot "MPEG2 + VFR is not allowed" in x262 cmd window before aborting.
Hope this helps tracing the bug.

ifb, if I may ask: Is there a way to read such error messages somewhere after cmd aborts ?

[Emulgator]

Now the x262 r2433_debug build: It fails the same way for any preset slower than "slow", so starting with --preset slower.
For lavf and ffms the x262 warning "MPEG2 + VFR is not allowed" is still in x262 cmd window before aborting.
But this does not seem to be significant, because the same warning is given when encode is successful.

There seems to be no dependency on demuxers.
The chain does work for faster presets than --preset slower.

1. With --demuxer lavf -> lavf frontend reports 720x576i 16:15 @ 25/1 fps <vfr> ...(?)
x262 warns: "MPEG2 + VFR is not allowed", also for the working presets
2. With --demuxer ffms, -> ffms frontend reports 720x576i 16:15 @ 25/1 fps <vfr> ...(?)
x262 warns: "MPEG2 + VFR is not allowed", also for the working presets
3. With --demuxer avs, -> avisynth frontend reports 720x576i 4:3 @ 25/1 fps <cfr>
x262: no warnings.

Now the ffmpeg way...