sx264 - qt based x264 gui (Linux&Windows)

[Selur]

Tried mediafire, but only got an upload of about 80kbit/s. Didn't know speedshare blocks some regions of the net, works fine from here.
Here's an alternative Download to current windows package: http://www.fileqube.com/file/xLDRULs158932 hope this works for you.

Cu Selur

[Pitti]

Originally Posted by Selur

This might cause a problem with zone and chapter option, since this might stop sx264 from clearing the chapters and zones.
Checking QT Documentation: "This function was introduced in Qt 4.3."
-> I agree with Merlin7777, it might help of you update your qt version.
iirc qt 4.3 was released around june 2007, 4.4 was released around may 2008, I don't think that I used any options that were introduced with 4.4 but 4.3 seems to be mandatory to run sx264.

Cu Selur

Ok. I have updated to QTv4.4.3 and now it works fine.
The first testings on ripping a DVD running also fine on the video part.
The audio part is not working. maybe neroaac hast trouble with the debian64.

and now i have a feature request
is it possible to add a logfile that includes the history.
jobid|starttime|endtime|fps
or expand the jobcontrol (like megui)

Pitti
PS: i like your tool.

[Selur]

iirc there's a thread in the forum which mentions some problems with NeroAacEnc and 64bit on some systems.

is it possible to add a logfile that includes the history.
jobid|starttime|endtime|fps

Will think about it, it's probably possible, if I add it, I'll probably modify the report output.

Cu Selur

[buzzqw]

i have a sample (too big to upload) of vob where mediainfo or mplayer were unable to determine the frames count

the missing frame count is a stop for encoding in you application

i suggest that ABR encoding and CRF/QP encoding (where users have to specify the values of bitrate/crf/qp), sx264 should not stop encoding, since not knowing the frame count isn't important

BHH

[Selur]

sx264 should not stop encoding, since not knowing the frame count isn't important

FrameCount is used to:
1. calculate remaining time during encoding
2. calculate file size for 2pass Encoding (and 1pass bitrate Encoding to give some sort of a general 'size hint')

What did you do to the vob such that mediainfo and MPlayer both can't get the framecount? (sounds like the file is broken in some way)
If frame rate and video length are identified correctly I could add a workaround to calculate framecount. (not 100% accurate, but should work)
-> Are these identified correctly?

Cu Selur

[buzzqw]

the vob is a split from a bigger vob, so.. could be broken (and don't blame mediainfo or mplayer)

and yes, both lenght and fps are correctly indentified

just add a warning, and compute the frame count on videolenght/fps (or.. as i have said.. a panel with media proprierties.. editable by users)

thanks

BHH

[Selur]

don't like the panel idea, since missing properties mos times imply a problem with the source that might cause other problems, e.g. decoder/encoder crashing.
Modifying ReportInfos and thinking about adding a little history like Pitti wanted, with lines like:
#### StartTime: 11:05:02 #### D:\sx264\test.mp4 #### Average speed: 220.85fps #### Endtime: 11:05:04 ####
for each finished encode.
Will add a warning and calculate frameCount in MediaInfo-Analyser and MPlayer-Analyser after that.

Cu Selur

[Selur]

and yes, both lenght and fps are correctly indentified

Please recheck this for MPlayer since, MPlayer-Analyser always calculates FrameCount anyway.
So something really went wrong, or length and/or fps are missing or zero.

Cu Selur

[microchip8]

Tip: When using --pulldown in x264, --nal-hrd is required. Also looking at console output, no matter if one selects 3:2 or 6:4 pulldown, the program always passes --pulldown 32 to x264

nice GUI anyways, but definitely not something I will be using.

[Selur]

When using --pulldown in x264, --nal-hrd is required. Also looking at console output, no matter if one selects 3:2 or 6:4 pulldown, the program always passes --pulldown 32 to x264

thanks for the info, will fix

nice GUI anyways, but definitely not something I will be using.

can't win them all

Cu Selur

[microchip8]

Originally Posted by Selur

thanks for the info, will fix


can't win them all

Cu Selur

you're welcome. And it's not about winning. I just don't like GUIs when it comes to encoding. I have nothing against it if others use it, but for me I stick to CLI stuff since I spend a great deal of time working on the CLI and are kinda addicted to it The only GUI I would consider using is Ripbot264 due to its superior combination of simplicity and usability. GUIs that offer a gazillion of options are, IMHO, not only overloaded but also user unfriendly in regards to the not-so experienced/noob users. I for example, will need less time to write the MEncoder parameters on the command line, than to click checkboxes spread over multiple tabs which hold a considerable amount of options. I think that when Atak_Snajpera started developing Ripbot264, he not only looked at it from the perspective of the developer, but also from the perspective of the (noob) user. In the end, you get a program like Ripbot264, which as I said earlier is unbeatable when it comes to combining simplicity with usability and power.

Again, this is just how I see things and by all means it is not an attack or similar to what you're doing. In fact, I think you're doing a great job, and since this is early alpha release, who knows how this program will develop in the future? It can drastically change or then maybe not.

[Selur]

About simplicity: When starting to write the gui I thought about writing a simple wizard with questions&Co similiar to your h264enc, but then I realized I wouldn't really fresh up my c++ skill doing so, since most of the logic could be copied from h264Enc and combined with QWizard it would be a rather short project. So I started to write the gui mainly to write a gui for my needs, but since I showed it to some buddies and they liked it I decided to tune it and release it to the public. I too like RipBot264 for it's simplicity but since I personally like to have a lot of options to play with whatever I do it's not my usual tool to use. But who knows maybe I'll add a Wizard view in a later stage.

----

rev417
*added*
- Job History (Misc->Logging->Show job history)
- to MediaInfo Analyser: if no framecount was found calculate framecount if fps and length are present

*fixed*
- typo when selecting x264->pulldown
- making sure x264->pulldown can only be used when BluRay support is enabled

*cosmetics*
- changed some debug messages

-> updated 1st post

Cu Selur

[microchip8]

A wizard will be a good idea, however I don't think it will be the best option here. The biggest thing that will reduce the amount of options and thus bring a lot of simplicity to sx264, is if you design a robust presets system. A presets system that not only allows you to choose from different built-in presets, but for the more experienced user, also allows to write your own presets and load them into the program (just like h264enc allows that). If you develop a presets system, this will not only give you a great deal of simplicity on the user side, but also in the codebase side, since you will not have to deal with all the checkboxes/tabs/whatever in the code. I think the best thing to do here, is somehow find equilibrium (balance) between simplicity and the amount of code. The more code you have in the program, the buggier it can get due to too much variables/functions/etc that have to be considered which also requires a lot of time spend in debugging/reading code and fixing it

[Selur]

Yup, a preset system is a nice thing, though I don't think I'll implement a more complex one in the near future.

If you develop a presets system, this will not only give you a great deal of simplicity on the user side, but also in the codebase side, since you will not have to deal with all the checkboxes/tabs/whatever in the code.

Don't think so, since one would still require to have those checkboxes/tabs/whatever to allow to generate those presets. (if one wants to keep as much freedom as possible)

Cu Selur

Ps.: I like the filtering options/presets you present in h264enc

[microchip8]

Originally Posted by Selur

Don't think so, since one would still require to have those checkboxes/tabs/whatever to allow to generate those presets. (if one wants to keep as much freedom as possible)

Cu Selur

yes, this is true, but it will reduce some amount of them. If you implement a presets system, all the checkboxes for things like 8x8dct, level, partitions, motion estimation, deadzones, etc will be gone. That is if you get rid of them and don't keep them for "as much freedom as possible" reasons. The only difference between using a presets system which allows you to write and load your own presets, and the currently used checkbox system, is that instead of the user clicking on various checkboxes, the user writes the x264 settings in a file. Personally, I find the last option more appealing and again, I speak only for me here

[Selur]

I too like the idea of presets , that's why one can save&load a profile and save general default settings.
But we will see, may be I'll implement a preset system in the future.

Cu Selur

[flebber]

Selur have you tested flv input. I am trying to use flv with ffmpeg and mencoder decoder. However I cannot get a log or info as sx264 is crashing immediately after I select the file, I have checked the create report and enable debug boxes checked but I am not getting any output.

The flv appears okay as automen is encoding it fine and the flv player plays it without error.

This is my file format read with mediainfo

General
Complete name : C:\Documents and Settings\flebber\My Documents\My Recordings\Slipknot_Dead Memories final1.flv
Format : Flash Video
File size : 17.6 MiB
Duration : 4mn 27s
Overall bit rate : 552 Kbps

Video
Format : VP6
Duration : 4mn 27s
Bit rate : 400 Kbps
Width : 640 pixels
Height : 360 pixels
Display aspect ratio : 16/9
Frame rate : 23.980 fps
Bits/(Pixel*Frame) : 0.072

Audio
Format : MPEG Audio
Format version : Version 1
Format profile : Layer 3
Duration : 4mn 27s
Bit rate mode : Constant
Bit rate : 96.0 Kbps
Channel(s) : 2 channels
Sampling rate : 44.1 KHz
Resolution : 16 bits

[Selur]

Tested some flv. Try ffmpeg as Decoder not mencoder, since mencoder&mplayer are not so good at handling flv files.
Create Report and Debug will both create a file.
report during and after encoding and debug should create a sx264Debug.txt file.
I'll recheck the flv files I got here. (thought that I forced ffmpeg as Decoder wen input is .flv, but I might be wrong there )

Cu Selur

[Selur]

rev418

*fixed*
- flv/swf handling -> enforcing ffmpeg as decoder again

-> updated 1st post

[Pitti]

Originally Posted by Selur

rev417
*added*
- Job History (Misc->Logging->Show job history)

You're a treasure
I try it out immediately