sx264 - qt based x264 gui (Linux&Windows)

[Riki]

Thanks for the detailed answer. I have a feeling you are anticipating my next question, but I have a feeling I will need to research it well to get an understanding.

How do I find out what values I need to manually put for vbv? :)

[Riki]

Dont answer that, I found the perfect thread. :D

http://forum.doom9.org/showthread.php?t=147153

[Selur]

I would suspect that:
VBV Max Bitrate should be set to the average bit rate you are aiming for
and
VBV Buffersize should be set to e.g. 2*max Bitrate. (probably depends on what you are streaming and what the player supports; last project I worked on in this department I choose 5 as factor)
But, I'm really no expert in streaming so better ask Dark Shikari and check out the thread I linked to above. (there might also be some other threads related to streaming :))

Dont answer that, I found the perfect thread.
too late ;) btw. that's the thread I linked to ;)

Cu Selur

[Riki]

Doh, you beat me to it, haha.

I went ahead and asked a vbv specific question there. It all makes sense now but I just need to figure out what to put for the buffer size. Im using a dual buffer on the streaming client so i wonder if I go with the maximum buffer or not, I also wonder what the harm in setting this value to being too large. Since my large buffer is 10, maybe I can just go *10

[Selur]

don't know if this is only a server-sided question or if it might be a good idea to investigate if the used flash player has any internal defaults ;)

[Riki]

Here is one thing that seems odd to me. If I am setting the max bitrate, what does that do to the CRF? So for example if I set a CRF of 18 and a max bitrate of 500, will it conflict with the quality? Sounds like its almost the same as specifying a bitrate.

[Selur]

http://handbrake.dynaflashtech.net/cgi-bin/vbv_calculator.cgi might be interesting other than that I would have to test too, not sure what will have a higher priority the crf or the vbv values. ;)

[Riki]

thanks, this is a paradigm shift for me in many ways. I always figured smaller filesize was all that was needed to make a fast stream, but thats just not true with streaming, its a whole different transmission.

I did at test at max 500 and it did a great job!

[Selur]

Nice :)

[Riki]

in sx264 when I drag in multiple videos it resets the VBV, is there any way to type in a value there and have it remember like with other settings?

[Selur]

not atm. ;) iirc sx264 will reset the values to the maximum allowed by the level, but I'll try to make a quick fix to disable this behavior and send you a test version

[Riki]

Yeah, I was thinking something like you have with the resizing "Keep for new source"

Thanks man!

[Selur]

Isn't that easy since vbv values are adjusted for all kinds of reasons (level change, encoding type change, compatibility settings) will add an option that will disable this updating partially, which means it should disable setting a new value unless the value comes in conflict with the allowed maximum.

---

btw. just saw:
--b-pyramid <string> Keep some B-frames as references [none]
- none: Disabled
- strict: Strictly heirarchical pyramid
- normal: Non-strict (not Blu-ray compatible)
-> will update sx264 tomorrow

Cu Selur

[Selur]

rev561

*added*
- support for new bPyramid syntax:
--b-pyramid <string> Keep some B-frames as references [none]
- none: Disabled
- strict: Strictly heirarchical pyramid
- normal: Non-strict (not Blu-ray compatible)
- keep vbv values option under misc->encoding settings which is needed when vbv values should not be

resettet on source change (e.g. during batch encodes); If value conflicts with max/min values, they will

still be changed.

*cosmetics*
- minimized size of Console Output inside Job Manager

*fixed*
- mp4 multiplexing
- x264 command line updates

Important:
- Requires x264 rev 1301+
- Reset Defaults



-> updated links in 1st post

Cu Selur

Ps.: *silent update*
- fixed small typo
- removed lower refs for b-pyramid option; better use "strict"

[Alex_080]

Hi Selur can you give link for x264 rev 1301+ which is comfortable with sx264 because i downloaded one but it shows error

[Pitti]

http://x264.nl

[Selur]

x264.nl's build are non-modified builds and normally I compile x264 myself of use the builds of JEEB (last one is here: http://forum.doom9.org/showthread.php?p=1336131#post1336131) since sx264 wants the option provided through the x264_hrd_pd_interlace patch. :)

Cu Selur

[Riki]

Good to know, Ive been using the x264.nl builds.

If you arent doing interlacing, perhaps the builds of JEEB arent needed? Are there any other benefits to using this, or the sharktooth builds?

[Selur]

Depends on the patches applied, since the nal-hrd patch is the only one that seemed interesting to me, since it is needed for blu-ray compatibility, it's the only one directly supported via sx264, any additional new options have to be used via custom command line additions. :) Personally I prefer to stick as closely as possible to the unpatched sources to limit the trouble with compatibility issues caused through the patches. (can't wait till the hrd patch will be a permanent part of x264 ;))

[Riki]

So Ive done some tests and as promised Ill just post something I found out. To achieve a lower bitrate you need to use both vbv and the CRF quality together.

For example I had a quality of 26 and a vbv of 100/1000 and I tried taking the vbv lower but it wouldnt seem to do anything if I went lower, it was as if the CRF was forcing it to stay at a certain level. If I changed CRF to 30 and left VBV alone, the bitrate would go down, so my conclusion is these work together somehow.

After my testing and many posts here I learned a lot and now Im much more confident with encoding for streaming :)

[Selur]

I tried taking the vbv lower but it wouldnt seem to do anything if I went lower, it was as if the CRF was forcing it to stay at a certain level.
good to know :)
Never tried it but, changing: 'Max quantizer difference' and 'Quantizer max' also have something to do with it. ;)
For those wondering what this is about: The question was how vbv limits and crf interact. :)

[Selur]

Since I'm working on the sx264 successor, from time to time, I compiled a small preview for the windows users. (handling in general is similar to sx264) ;)
The preview allows extracting, job creation, etc. the main thing that's not working is job handling (working of the created jobs, since I'm thinking about how to design it and I'm out of free time atm. -> so no encoding is not possible with this version).
So for the interested windows users: http://www.megaupload.com/?d=L9WBM7UD (contains a 32bit and 64bit windows binary, mediaInfo, mkvextract, mp4box, avsInfo and mplayer to allow preview, analysis and some extractions)
For those who actually check it out, would be nice if you see a bug or if you see a missing feature: mention it here.

Cu Selur

[CpT]

I like the gui ;)

I also dig the Target Mode option and how it saves the setting for the next encode. That was the only thing I had to change per encode.

The audio tab is a little hard to find. But I'm guessing your planning on adding labels next to x264 and the audio drop down on the Main tab.

I've done simple test with windows 7 32 and 64 bit and the gui loads up and saves/remembers all my settings on re-open for both versions.

Can't wait for a working alpha ;) :thanks:

[Selur]

Thanks for the feedback. :)

The audio tab is a little hard to find. But I'm guessing your planning on adding labels next to x264 and the audio drop down on the Main tab.
Maybe, not totally sure about this and some other small GUI related things, which is one of the reasons I published this preview -> there's always things one misses and if you design the frontend you know it to well to see some things. ;)

Cu Selur

[microchip8]

so are you phasing out sx264 and "replacing" it by this new one, or are you going to simultaneously develop both at same time? will the new one be available for linux too?

[Selur]

Yes, Hybrid will be available on Linux too. :)
I will fix bugs in sx264 and mainly develop Hybrid (<- better code, since it contains everything I learned with sx264 ;)). sx264 will be discontinued, when Hybrid is as stable as sx264 atm and Hybrid covers all features sx264 does.
Hybrid is mainly a rewrite of sx264, which was needed to support multiaudio/video, audio/video passthrough and some other stuff. sx264's code really is 'ugly' since it's mainly a 'testing platform'. One thing I'm thinking about atm. is how to design the job handling system, to support encoding on different systems. (One 'server' which mainly handles the queue and multiple workers which each get X jobs (and the corresponding sub-jobs), the idea is to be able to add/remove workers/pcs while a job-Queue is processed.)

But before really thinking about job handling I wanted to check if I missed a feature, screwed up the general handling, etc.

Cu Selur

Ps.: Before I start to implement the job handling I also have to buy a new keyboard, since current keyboard sometimes misses a keypress, if the key wasn't pressed hard enough,.. (which is probably my fault since this happens after I dis- and reassembled it for cleaning ;)) (going to by a Microsoft Ergonomic Keyboard 4000 again since I got used to it and my current one did perform well until I cleaned it :) *aaaargh*)

[Alex_080]

Hi Selur
when i m encoding any *.mkv file the encoding process done successfully but the audio and video don't match in output file ..help!

[Selur]

can reproduce this with input files which have an a/v delay since the muxing call got a bug, but since you said this happens with any file and I can't reproduce this with input files that have no a/v input delay it might be helpful if you could check if all your file you got a problem with do have an input a/v delay.

Cu Selur

[microchip8]

Selur, thx for the info on the new Hybrid... any info or ETA when first "public" release of Hybrid is due?

[Selur]

Nope, will wait for some input regarding current layout&Co, then update my Linux systems and after that start implementint the jobHandling part. ;) (looking at my free time plans I aim to release at the end of this year :))

[Selur]

rev562

*fixed*
- mkv multiplexing with a/v delay

-> updated links in 1st post

[Alex_080]

Hi Selur
i still face audio-video synchronization problem in *.mkv file.
For e.g when i am encoding a .mkv file which has 3235ms delay , the encoding done perfectly but the output file is not perfect.

[Selur]

If you upload a small sample video where this happens on reencoding I can look into it.

[Riki]

Hybrid looks amazing, but it crashes everytime for me with both the 64bit and 32bit versions , Im on windows 7 pro 64bit

Edit* It crashes when I hit start/add

[CpT]

-> so no encoding is not possible with this version).
Cu Selur


It's not finished.

[Riki]

Oh I see, I thought it would do something because he made a full package with all the encoding stuff. So far its great!!

[CpT]

Yea its really slick for sure.

@Selur:
I think I just found a bug btw.

When turning on enable resizing -> setting target resolution @ 720 width for example -> then choose auto adjust height @ mod 16 and keep for new source -> hitting save defaults @ Misc page -> then restart hybrid.

On restart it wont save those settings. It defaults back to 1280x720 @ mod 2. Save for new source seems broke.

[Selur]

@CpT: Yup, there's a bug somewhere, will fix it. Thanks for the input. :)
@Riki: Found the problem, will fix it. Thanks for the input. :)

[Riki]

Thanks.

btw, is there any way to do a specific filesize/bitrate (1-pass)? Ive been testing for a way to get something more of a CBR. I was reading a long thread about it and they were mentioning just doing 1 pass instead of 2.

[Selur]

Best way to archive something similiar to cbr would be:
1. adjust vbv values, see: http://forum.doom9.org/showthread.php?t=102893
2. set qcomp to 0

[Riki]

thanks Ill try that, Took me a while to see that its called Curve Compression in sx264 :)

[Selur]

He,he happy you found it :)

[Riki]

Ive noticed a few changes in sx264, now Macroblock Tree has a lookahead (frames) cap of 100 (I think it used to be 250. Also under Misc there is an Input lookahead value there that goes up to 250. What is different about the Input lookahead under Misc?

[Selur]

Input Lookahead <> --sync-lookahead <integer> Number of buffer frames for threaded lookahead
--sync-lookahead is limited to [threads+bframes, 250]

Lookahead under RateControl <> --rc-lookahead <integer> Number of frames for frametype lookahead [40]
rc-lookahead is limited to [1, min(keyint,250)]

see thread: http://forum.doom9.org/showthread.php?p=1321220

Cu Selur

[Riki]

thanks, the sync-lookahead is new to me. Since I have a fast computer I will set these both to as high as possible :p

[Selur]

keep an eye on the RAM usage these settings will cause x264 to hock a huge amount of RAM and x264 will crash/stop when it runs out of RAM. ;)

[Riki]

Ok Ill keep an eye on it, right now I have 16GB which is a lot but Im surprised to see some 64bit apps just eat it like candy :p

[Selur]

btw. fixed the Hybrid bugs -> http://www.selur.info/test/HybridTest.zip cotnains fixed .exe files. :)

[Riki]

Thats great news, I cant wait to test it!

[CpT]

So does this one actually encode? Or another gui test?