VidCoder: Alternative HandBrake GUI for Windows

[R=G]

My x264 settings are usually just default stuff.....very fast/none for tune/main for profile/automatic for H264 level...if you put it on slow or slower, will that override the other advanced settings and while Im asking, what does Slow do for your encode over fast or very fast?

[flebber]

This explains presets well http://mewiki.project357.com/wiki/X264_Settings

[bigggt]

i figured out what i was doing wrong

[mike20021969]

I've just saved a video recorded off the TV for personal use.
It was shown as 2.35:1 in 16:9 aspect.

Which of these would be the preferred crop or does it not matter about the odd display resolution of the first?

http://i59.photobucket.com/albums/g302/mike20021969/Display989x434-Storage696x434_zpsd59b94a0.jpg

http://i59.photobucket.com/albums/g302/mike20021969/Display984x434-Storage692x434_zps9e044236.jpg

Thanks.

[RandomEngy]

The odd display resolution doesn't matter. The display resolution is just calculated from the storage resolution and aspect ratio to give you an example of how the picture would look. If you're playing it fullscreen or on an HDTV it will display at another resolution entirely (dependent upon the available space, storage resolution and aspect ratio).

[mike20021969]

The odd display resolution doesn't matter.

:thanks:

[RandomEngy]

I'll update those Android presets and fix the "refs" param. Thanks for the heads up.

[RandomEngy]

Apparently it's not just the preset names though. It looks like there are some more errors in the VidCoder 1.4.11 Beta presets.

For example "Android Mid" (A.K.A. "Android") has incorrect Max Width and incorrect Anamorphic settings.

And "Android High" (A.K.A. "Android Tablet") also has incorrect Max Width settings.

Not sure if there are more errors.

So you might want to take a closer look at Changeset 5111 again in it's entirety ;).

I've already updated the contents of the presets (like maxwidth) as well. I wouldn't say that they were errors; they just changed the presets and I've got to update to keep up.

Would be nice if you could update VidCoder to follow all those latest LinGUI changes regarding the new x264 preset/tune/profile/level implementation (Changeset 5110 & 5111) :o:cool:.

I don't want to do parameter unparsing. I don't like the behavior of these two distinct UIs interacting across tabs. The user can't see what's happening. Besides it's only to benefit the Advanced tab which you so desperately want to hide away. And again: I am planning to hide the Advanced panel by default someday, just not now. Please stop asking about it.

[mike20021969]

Why is the official HandBrake WinGUI not using the HandBrake library directly?

Is that not a question you should ask on the HandBrake forums?

[RandomEngy]

Actually it looks like those presets have been posted like that even before Changeset 5111 (both naming wise and settings wise), see:

http://forum.doom9.org/showpost.php?p=1605829&postcount=577

Then the preset change came from an earlier changeset. The Android Mid/High preset names and settings came directly from HandBrake.

Yes, if i were to decide, then the Advanced tab would get removed entirely and never come back.

Not because the Advanced tab scares me (it doesn't scare me at all), but because it might scare other people and might lead to unnecessary suboptimal encodes for people which are not well informed about all this stuff and therefore might use suboptimal settings. And because the Advanced tab simply is redundant now IMHO, now that finally the x264 preset/tune/profile/level support is available natively in the GUIs.

I also wouldn't describe four users on the VidCoder discussion website (http://vidcoder.codeplex.com/discussions/402812), two users on the VidCoder review website (http://vidcoder.codeplex.com/releases/view/97530#ReviewsAnchor) and one user here on the forum (http://forum.doom9.org/showpost.php?p=1606367&postcount=592) complaining about the absence of the Advanced tab in VidCoder Beta 1.4.5 as "popular demand"

;)

Because that's just seven users out of the hundreds that had downloaded 1.4.5 Beta..

How someone can call this "popular demand" is beyond me... . But, who knows, maybe you got more feedback via other channels (E-Mail and so on)..

VidCoder still isn't a hugely popular software project. The feedback asking for the return of the advanced panel is the strongest response I've gotten about any feature in VidCoder's history. And it came from a version not in wide release. If that's not "popular demand" for VidCoder I don't know what is.

Well, anyway, i'm not to decide about that and you and the HandBrake developers seem to have decided to let the Advanced tab stay alive in the foreseeable future (even if you plan to hide the Advanced tab by default it's not the same as removing it from VidCoder).

And although i think the Advanced tab should be removed entirely and never come back (as mentioned above), at the same time i think that IF it will stay (and you and the HandBrake developers seem to want it to stay), then there should be some interaction between the Advanced tab and the Video tab controls.

Because, ultimately, they both affect the encoding settings, so they are not really separate things then.

Not making them interact therefore is a poor design IMHO (no offense though).

Therefore i asked you to make it similar to the LinGUI design (especially the two new checkboxes on the Video tab and in the preferences) / or to have a similar certain degree of interaction.

But this discussion probably isn't getting us anywhere ;). So, never mind ;).

I can see the benefit of it: you'd get to see the effects that different profiles/presets have on the settings. But with that good interaction you get some bad interaction as well, such as resetting or disabling settings you might have made on another tab. And since the main goal of the feature is to help people learn the advanced settings (which is of dubious value to me), I'm not really that motivated to do it. I'll say that if someone gave me a patch that implemented it in a competent manner I might accept it but I have better things to do for now.

Anyway, a very different question:

On the VidCoder website and in the first post here in this thread you mention how VidCoder is using the HandBrake library directly while the official HandBrake WinGUI only is a front-end for the HandBrakeCLI?

Just wondering: why is that?

Why is the official HandBrake WinGUI not using the HandBrake library directly?

And do you know if the official HandBrake LinGUI and MacGUI are using the HandBrake library directly, just like VidCoder? Or are they only front-ends for the HandBrakeCLI as well, just like the WinGUI?

There's a bit of history behind this. When the windows GUI was written, there was no hb.dll like there is today. They just had the CLI to play with so that's what they used.

Also, interacting with hb.dll is really hard. It's not just like another C++ program bringing in the headers and making a few method calls. The GUI is in C# so you have to use P-Invokes. Normally this isn't too much of a problem if the API you are calling has this in mind. But in HandBrake it's really rather difficult. It will do things like give you a pointer to an object and expect you to modify fields on that object, but the only way to do that is by knowing the exact memory offset of the field on the object. I ended up kind of working around it by passing in a fresh struct and making it work. Even then with the structs you're passing around you have to keep them in perfect sync with the ones in HandBrake. This is a problem because first off many of the structs you're passing around contain a bunch of private data used internally by HandBrake. So you've got to either include them or add in a "padding" byte array that passes through the data for a bunch of fields. Second, they change a lot so you have to made the exact corresponding change every time you update hb.dll or it will blow up horribly. It gets even more tricky when you have to figure out how to marshal unions and end up calculating alignment differences between x64 and x86. I've got a spreadsheet for that.

Most of the time when you make a mistake you get an AccessViolationException with no indication of what blew up. You can attach gdb to it and find out what function threw the exception but it doesn't give you the full call stack or where in the function it blew up or why.

And the HandBrake API needed some additional work to make it P-invoke friendly. It needed some logic to redirect standard output in a way that I could read it and some wrapper functions to expose some global variables (which cannot be accessed in P-invoke).

Anyhow I finally got the wrapper going and working smoothly: it's checked as the HandBrakeInterop project in the HandBrake codebase. The Windows GUI actually has an experimental feature you can enable to use it. I imagine some day in the future HB will switch over to it by default.

The Mac and Linux GUIs use the library directly; they get to call the API without having to do any marshaling P-invoke chicanery.

And another question:

Would the following thread over there (and the links in that thread) help you with this (found via search engine):

http://stackoverflow.com/questions/344205/recommendations-on-a-wpf-docking-library

?

I did play around with AvalonDock when investigating this. The ActiPro one looks pretty cool. I could see making the queue, log and preview dockable windows. Maybe the encoding settings as well, though I'd need to remove the minimum size requirement and give it a scrollviewer. I may give this another look when I have a weekend to burn.

PS :o:D:

Coincidentally just came across an earlier post from another user on another forum where he basically also "complained" about the lack of interaction between the Video tab controls and Advanced tab controls in VidCoder, see:

;)

Hey, that basically makes it at least two users already :D. Does this qualify to make it a "popular demand" now :p:D;)?

It wasn't really a request. More like commenting on the suitability of VidCoder for teaching someone about x264 advanced settings. The only person who has asked me to do this feature is you.

[RandomEngy]

Yeah I like having the x264 preset/profile/tune on the same page as the framerate/quality. I don't want to compromise that for some other advanced settings.

[RandomEngy]

Released VidCoder 1.4.12 Beta (http://vidcoder.codeplex.com/releases/view/99756):

* Overhauled the Options dialog: Made it cleaner and better organized.
* Added an Updates tab with more detailed status and the ability to manually check for updates.
* Added a menu option and button to close the current video source and get the initial "pick source" UI back.
* Disc folders can now be batch-added with drag and drop in the same way that ISOs can be.
* Added a menu item under Help to get to the Updates section of Options.
* Added a hotkey for Options (F4).
* Updated Android presets to bring them in line with HB presets.
* Removed checkbox for Zero Latency tune as it does not help on these encodes.
* Updated HandBrake core to SVN 5125.

* Made changes to help diagnose reported encode proxy issues:
** Increased worker ping timeout.
** Added exception logging on ping timeouts.
** Increased worker process priority. The worker threads themselves already have lower priority.
* Fixed memory leak from scan instances.
* Fixed issue where only lowercase extensions would be recognized when queuing up folders of files.
* Fixed typo in AppleTV preset.
* Fixed some common string resources not showing up for Hungarian.

The updated Options dialog:

http://i.imgur.com/3zMqn.png

s55 had a nice concept in the HandBrake GUI nightlies so I went with it and made a few more tweaks.

[mike20021969]

VidCoder 1.4.12 Beta

Keep up the good work and have a great New Year.

:thanks:

[RandomEngy]

Me too ;).



If you are going to fiddle with the size of the Encoding Settings window, like you mentioned there:




then maybe you could fit everything on one tab, so that there wouldn't be any compromise. But well, up to you of course ;).

I still don't think it would be a good idea. Having the controls corralled off in a clearly marked "Advanced" tab is helpful for most users who don't need to be distracted by them.

Question:

When encoding with VidCoder 1.4.12 Beta x64 for example, then the resulting files show the following in MediaInfo:




Would there be any chance you could change it, so that MediaInfo will show:


or:



for example?

There is no entry point in the HandBrake API to change the "writing application" string. And I'm not about to make custom builds of HandBrake again just to do that.

[MOS-Marauder]

Yep that Strings in the Headers done by HB are sometimes a bit Weird.

They even doesnt show what x264 rev is used. (Actual in HB is r2216)

VidCoder is imho the Best WinGui that uses HB!

The only thing i use the Orignal WinGui is if i want to know some CLI Commands on special Settings when writing my Scripts *G*

The ADVANCED Tab is for me one of the most important Tabs ever....

Mara

[RandomEngy]

Hey it's Marauder! Weren't you going to do a German translation? :P

[Hobbe]

RandomEngy: Could you build a own hb.dll with libavcodec/libfdk-aac enabled?

[RandomEngy]

Are you going to add this:

to VidCoder?

Calling it "FLAC 16-bit (Libav)" and "FLAC 24-bit (Libav)" in the Audio drop-down would probably be more accurate and more straightforwarded though, wouldn't it?

PS:

While you're at it:

The term "Passthru" in the Audio drop-down probably could be renamed to "Passthrough", couldn't it ;)?

Yeah it will get added. VidCoder automatically pulls in new encoders. I've always thought the "Passthru" was a bit silly as well but never bothered to change it.

About the FLAC naming, seems to make sense. Though I may end up calling them FLAC (Libav) and FLAC 24-bit (Libav) to offer a clear safe default and let the user know which one was the FLAC they were choosing before.

PPS:

The latest HandBrake WinGUI Nightly Build has the following checkbox:

under:

Is this something new?

It looks like it enables the user to configure Auto-Passthrough?

VidCoder doesn't seem to have such an option / such a checkbox?

It's been there for a little while but I haven't heard any demand to add it.

RandomEngy: Could you build a own hb.dll with libavcodec/libfdk-aac enabled?

Well I have a couple questions about it: How and why? What does it supply, and what would I need to do to add it? And why shouldn't this just be in the official HandBrake build?

[RandomEngy]

Oh and an update on the docking investigation: ActiPro docking is very cool and does everything I would need but it would make it so anyone who wanted to build VidCoder would need to shell out at least $200 for the license. A no-go for an open source project. AvalonDock looks mostly functional but I can't figure out how to just have regular content in the middle instead of the unneeded multi-document tab control. The docking redesign will be on hold until I can work that out.

[Hobbe]

Well I have a couple questions about it: How and why? What does it supply, and what would I need to do to add it? And why shouldn't this just be in the official HandBrake build?
It's a much better aac encoder than faac or libav..
You can read this thread why it's not in the official hb..
https://forum.handbrake.fr/viewtopic.php?f=26&t=24773

[RandomEngy]

Hmm, it looks like they rejected it because its license is incompatible with the GPL. VidCoder also uses that license so it would have the same problem.

[ZoNi]

It should look different, like all other programs in XP (with nice buttons etc).

I have now installed VidCoder on Win7 Ultimate 32bit:

http://i.imgur.com/9gDsP.png

Again something wrong with GUI :(

Unistaled VidCoder. Installed latest beta - still same problem with GUI. Like there is something that block modern look of VidCoder :(

UPDATE: everything is OK with Win7 default Aero theme. With others, GUI is weird...

[mike20021969]

Sorry if this seems like an obvious question:

If I have a have a 720x576 video, drop it into VidCoder and the auto crop is T=0, L=12, R=4, B=8, to avoid losing resolution, should I resize it to 700x572?

If not, what is the correct thing to do?

Thanks.

http://i59.photobucket.com/albums/g302/mike20021969/20130106_14h56m12s_002_Preset-640x480_zpscf851c87.jpg

[RandomEngy]

The resolution would be 684x568, but you can just leave the width and height empty and it will figure that out by itself.

[mike20021969]

The resolution would be 684x568, but you can just leave the width and height empty and it will figure that out by itself.

I see where you're going, but in my other post, I'd added up the wrong crop figures and I can see now that if I'd added them up correctly, they'd have shown 704x568 as in the image below.

(i.e. 0+8 off the height, 12+4 off the width).

Thanks:)

http://i59.photobucket.com/albums/g302/mike20021969/20130106_19h30m13s_001_Preset-Normal_zpsa69fe29c.jpg

[R=G]

Hmm, it looks like they rejected it because its license is incompatible with the GPL. VidCoder also uses that license so it would have the same problem.

The one thing about Vidcoder that has always been consistent since the day I first discovered it the spring of 2011 is that, unlike other encoders, the audio always come out in synch. I think it didn't one time but that was because the rip of the VOBs I did was for some reason out of synch. Unheard of to me but other than that one thing, it's been the easiest audio conversation of ANY ENCODER I know of. Thanks.:cool:

[mike20021969]

I think I've found a bug:

I drop a file into VidCoder...

http://i59.photobucket.com/albums/g302/mike20021969/20130107_13h29m24s_001_VidCoder_zpsee593438.jpg

Check the settings...

http://i59.photobucket.com/albums/g302/mike20021969/20130107_13h29m46s_002_Preset-Normal_zps084b68f8.jpg

Encode...

http://i59.photobucket.com/albums/g302/mike20021969/20130107_13h30m11s_003_VidCoder-7-4-_zps180e1828.jpg

The resulting file DOES include audio, but 0 kbps is shown in the window.
It's shows 0 kbps for the other built-in profiles aswell except Android and Windows Phone 7.

[RandomEngy]

Ahh. I store the bitrate as an int and "0" is the special value for "Auto". I must just be using the profile bitrate directly when getting the value to display on the queue. Thanks for the report.

[hello_hello]

Coincidentally just came across an earlier post from another user on another forum where he basically also "complained" about the lack of interaction between the Video tab controls and Advanced tab controls in VidCoder, see:

Well given I was perusing this thread to discover I'd been taking part in the discussion here, I thought I'd add my 2 cents worth. So "in my opinion"....

An encoder GUI should always show you what it's doing where applicable. Even if it can't do that, it should never, ever, ever, ever, show you what it's not doing. If I select the veryslow preset and it's therefore using 16 ref frames, if the GUI has a ref frame setting in it's options, then it should default to 16. If a speed preset automatically changed the CRF value used and the change wasn't reflected in the GUI there'd be an outcry from users. I don't see why the same principle shouldn't also apply to any other x264 setting.

Off the top of my head, I know MeGUI, ffcoder and StaxRip all behave in the way jq963152 is suggesting. Change a speed preset or tuning and the appropriate advanced settings are changed accordingly. VidCoder/HandBrake are probably exceptions to the rule.
Is this a "bad" interaction? The reality of it is, x264's default settings are only the defaults when using the default preset/tuning. Change the preset/tuning and some of x264s settings now have new defaults and the GUI should reflect that. If a GUI has a "master" reset, it is expected behaviour for it to reset everything, or should it only reset the settings you didn't manually change? I don't see the speed presets as being any different, only they just reset specific settings.

If you're forced to apply a speed preset before tweaking individual settings in order not to reset your "tweaks".... well as it turns out, that's the same order in which the encoder applies them too. And of course how do you tweak a setting if you don't know what the real starting point is?
Then there's the argument nothing should be added to the command line by a GUI unless it's telling the encoder to do something it wouldn't otherwise be doing or there's a specific reason for doing so. Why would it add --ref 8 to the command line if the chosen speed preset already uses that value?

My preference would be to keep the basic and advanced x264 settings separate, but it really doesn't matter how. Make the advanced settings appear on the same page if the user selects on option to show them, put them on another window/tab or do some combination of the two, hide them by default or don't, but done correctly it should be pretty obvious "these are the settings for mere mortals", "these are the ones you probably shouldn't touch unless you want to make a mess of it". Currently the problem with HandBrake, is if anything it's teaching users to do it the other way around.
If it was up to me I'd never dump the advanced options completely. There's always going to be a demand for the ability to experiment and make mistakes etc. Nothing wrong with that..... if while you're experimenting the GUI isn't giving you the impression it's doing one thing while in reality it's doing something else. ;)

[JohnAStebbins]

Correct me If I'm wrong, but it's not really using the built in speed presets as such, instead it's duplicating the advanced settings which a speed preset would otherwise use, only doing so "behind the scenes"? On face value this seems like a reasonable idea, except for the fact the encoder doesn't behave as expected. You should be able to select any preset and Profile/Level you desire, confident the encoder won't let the preset use settings which exceed the chosen level, ie the number of reference frames according to resolution.

I can't speak for VidCoder, but HandBrake does not do this and libhb allows you to set preset/tune/profile/level directly. It is certainly not necessary for VidCoder to expand these to advanced settings before passing to libhb.

[hello_hello]

For the record, I thought I'd admit to editing a paragraph out of my previous post. I referred to x264's ability to limit the number of ref frames according to the specified profile/level and the fact it doesn't seem to work using the x264 presets as they've been implemented in VidCoder.
Due to a recent discussion on the topic in another thread however, I've since learned it's probably due to the version of x264 which HandBrake/Vidcoder uses not having the same ability to do so as the command line version, and therefore it isn't VidCoder's fault. Given my little rant on the subject was only a few hours old I thought I'd remove it in case sometime in the future others read it and assumed I knew what I was talking about. :(


Thanks JohnAStebbins..... it looks like I was a little slow to remove the evidence. ;)

[Zerondar]

really great (and fast) encoding
only minor annoying is the automatic renaming of batch files... i wish i could make them keep the same name as source
and no use of avisynth profiles to add watermark to my encodes
ah well :-)
still thank you for making this great program

[planet123]

@RandomEngy

Please add color adjustments filter like contrast, brightness and saturation in the future version because the colour washed out on output video. (Not getting the same color and contrast of the original video). Please fix this problem as soon as possible except this bug everything works fine.

[fantasmanegro]

Is this:

http://vidcoder.codeplex.com/SourceControl/changeset/view/c2f4f3af0723#VidCoder/ViewModel/DataModels/AdvancedChoices.cs

what would need to be altered?

Is there any non-developer friendly graphical editor or something like that available which would allow to alter it without the need for programming skills?

Or would this require programming skills and would all have to be done via programming language :eek:?

:devil:...it requires a lot of programming skills...:devil: :script:

[RandomEngy]

really great (and fast) encoding
only minor annoying is the automatic renaming of batch files... i wish i could make them keep the same name as source
and no use of avisynth profiles to add watermark to my encodes
ah well :-)
still thank you for making this great program

Not sure what you mean by the automatic renaming. It only gives them a different name when there's already a file with that name there, and even then you can configure it. But yeah anyway it should be keeping the same name as the source file.

About avisynth, that's not something I can add in VidCoder, it would need to be added to HandBrake (and I don't think they are interested in it).

Is this:

http://vidcoder.codeplex.com/SourceControl/changeset/view/c2f4f3af0723#VidCoder/ViewModel/DataModels/AdvancedChoices.cs

what would need to be altered?

Is there any non-developer friendly graphical editor or something like that available which would allow to alter it without the need for programming skills?

Or would this require programming skills and would all have to be done via programming language :eek:?

Well Visual Studio has a designer that lets you drag around controls to edit the XAML, but it's not very good at getting good markup that's flexible enough to work with other languages. I'm pretty sure you'd need to edit some XAML and C# in order to get this working.

I can't seem to access CodePlex right now but I think that file plus the AdvancedPanel.xaml and AdvancedPanelViewModel.cs would be the files to edit.

@RandomEngy

Please add color adjustments filter like contrast, brightness and saturation in the future version because the colour washed out on output video. (Not getting the same color and contrast of the original video). Please fix this problem as soon as possible except this bug everything works fine.

Not sure what your problem is. If the colors are getting washed out then something is probably going wrong in the HandBrake core. Bring that problem to their attention after making sure it repros in HandBrake. Also I can't add filters because I don't have access to that part of the encoding pipeline.

[RandomEngy]

I still don't want abbreviations. And you could do a lot of the rearranging just by editing AdvancedPanel.xaml . If you applied half the effort to learning it as you do to these mockups, you could be very good at it.

Also I believe I heard a reason why the P-frames was a checkbox but I don't recall the details. And the spinners are fine but they don't tell you what the default is. About the "Reset" button, whether or not you have it is going to depend on exactly what interaction the options box has with the advanced options string. Right now in VidCoder they are one in the same so no "reset" is needed.

[JohnAStebbins]

Also I believe I heard a reason why the P-frames was a checkbox but I don't recall the details.
The checkbox selects "off" or "smart" weightp option. The third option is "simple" and isn't generally recommended or used. Weightp used to be a binary option. When a 3rd state was added in libx264, the other HandBrake gui developers decided not to waste time implementing another option that nobody needed.

[fantasmanegro]

:eek:



Hmm :(.

If it would not be too much work for you and if you would like to, then it would be appreciated if you could change the Advanced tab to look like this new "mock-up":

Advanced tab

Frame-type options
Number of B-Frames: [3 ↕] CABAC: [On (Default) ↓]
Adaptive B-Frames: [Fast (Defaul ↓] Number of Reference Frames: [3 ↕]
B-Pyramid: [Normal (Defa ↓] Deblocking: [0 ↕][0 ↕]

Ratecontrol
VBV Maximum Bitrate (kbit/s): [(not set) ↕] Adaptive Quantization Strength: [1.0 ↓]
VBV Buffer Size (kbit): [(not set) ↕]

Analysis
Partitions: [Most (Defaul ↓] Subpixel Motion Estimation: [7: RD in all ↓]
Direct MV Prediction Mode: [Spatial (Def ↓] Psy RD / Psy Trellis: [1.0 ↕][0.00 ↕]
Weighted P-Frames: [Smart (Defau ↓] 8x8 Transform: [On (Default) ↓]
Motion Estimation Method: [Hexagon (Def ↓] Trellis: [Encode Only ↓]
Motion Estimation Range: [16 ↕] No DCT Decimation: [Off (Default ↓]

[Reset]

Options String
[Textbox here]


Or alternatively with some exemplary abbreviations (if you need to save some space):

Advanced tab

Frame-type options
Number of B-Frames: [3 ↕] CABAC: [On (Default) ↓]
Adaptive B-Frames: [Fast (Defaul ↓] Number of Ref. Frames: [3 ↕]
B-Pyramid: [Normal (Defa ↓] Deblocking: [0 ↕][0 ↕]

Ratecontrol
VBV Maxrate (kbit/s): [(not set) ↕] Adapt. Quant. Strength: [1.0 ↓]
VBV Bufsize (kbit): [(not set) ↕]

Analysis
Partitions: [Most (Defaul ↓] Subpixel Motion Est.: [7: RD in all ↓]
Direct MV Predict. Mode: [Spatial (Def ↓] Psy RD / Psy Trellis: [1.0 ↕][0.00 ↕]
Weighted P-Frames: [Smart (Defau ↓] 8x8 Transform: [On (Default) ↓]
Motion Est. Method: [Hexagon (Def ↓] Trellis: [Encode Only ↓]
Motion Est. Range: [16 ↕] No DCT Decimation: [Off (Defaul ↓]

[Reset]

Options String
[Textbox here]


Not just asking because of the VBV controls, but also because, IMHO, the current VidCoder advanced tab looks a bit messy (especially the arrangement of the controls).

And, IMHO, the mock-up above locks a lot tidier and makes more sense regarding the order of the controls (see below).

Some notes about that "mock-up":

All the controls are drop-down lists and textboxes with spinners (http://en.wikipedia.org/wiki/Spinner_%28computing%29). There are no checkboxes and no sliders.

Drop-down lists:

"Adaptive B-Frames", "B-Pyramid", "CABAC", "Partitions", "Direct MV Prediction Mode", "Weighted P-Frames", "Motion Estimation Method", "Subpixel Mostion Estimation", "8x8 Transform", "Trellis", "No DCT Decimation"

Textboxes with spinners (http://en.wikipedia.org/wiki/Spinner_%28computing%29):

"Number of B-Frames", "Number of Reference Frames", "Deblocking" (two textboxes with spinners next to each other, just like in the LinGUI), "VBV Maximum Bitrate (kbit/s)", "VBV Buffer Size (kbit)", "Adaptive Quantization Strength", "Motion Estimation Range", "Psy RD / Psy Trellis" (two textboxes with spinners next to each other)

The mock-up has all the controls which currently reside on the Advanced tab plus the two VBV controls and plus the "Motion Estimation Range" control, which is available in the official HandBrake Linux GUI, see the following picture for example (The picture is a little bit older, but couldn't find another one. The Linux GUI Advanced tab still looks like that though.):





Also, the current VidCoder Advanced tab and HandBrake Windows GUI Advanced tab have a checkbox for "Weighted P-Frames". But "Weighted P-Frames" is not just an on/off option, so the mock-up also has a drop-down list for "Weighted P-Frames" wich shows the available settings for that option, just like the HandBrake Linux GUI (see picture above).

The textboxes with spinners for the two VBV controls are supposed to be behaving the same way as the the width and height textboxes with spinners on the Picture tab.

The width and height textboxes on the Picture tab do show "(none)" or "(auto)" in grey font when no width or height has been specified. The VBV textboxes in the mock-up are supposed to do it the same way. But it might be better if they would show something like "not set" or "unspecified" instead of "none" or "auto".

Not sure though what would be the best way to handle this:



in the GUI. Any ideas ;)?

The drop-down lists and textboxes with spinners in the mock-up are all supposed to be the same (fixed) width to make them line up nicely, even if that means that a bit of the text gets cut off in the drop-down lists. It would mostly just be the "(Default)" label that would be cut off anyway. Of course, when clicking on the drop-down lists, then the full text should be shown in the drop-down. The official HandBrake Windows GUI also is doing it like that. The width of the drop-down lists and textboxes with spinners in the mock-up is just exemplary though. It would depend on the space which is available on the Advanced tab when the Encoding settings window is set to the default size.

And:

The descriptions and the sorting of the controls are based on the x264.exe --fulhelp and the following website:

http://mewiki.project357.com/wiki/X264_Settings

All the controls in that mock-up are sorted in the exact same order as they are listed in x264.exe --fullhelp (Frame-type options ---> Ratecontrol ---> Analysis) ;).

And last but not least, the mock-up also has a "Reset" button between the advanced controls and the options string textbox.

The official HandBrake Windows GUI used to have such a "Reset" button on the Advanced tab until it was switched to WPF. The new WPF GUI does not have such a button anymore. Not sure why that is.

In the mock-up the "Reset" button is aligned to the center. But probably could as well be aligned to the left or right. Couldn't really decide about that ;).

Well, yeah, so much about the notes :D.

Again, because there do not exist any programming skills here :(:D, it would be appreciated if you could do it, if you'd like to.

And maybe some users who are in favour of the Advanced tab, like "mike20021969" etc. :p, could also give a little bit of feedback about how they like this "mock-up" ;)?

some people never learn... :devil:

i guess RandomEnegy is doing his best effort and you dont stop asking and asking and asking... mmm...

i really like VidCoder... remember that this is RandomEnergy GUI!... and he is giving us for FREE!!!...

let him choose what and what not... please...;)

[hello_hello]

@RandomEngy
Please add color adjustments filter like contrast, brightness and saturation in the future version because the colour washed out on output video. (Not getting the same color and contrast of the original video). Please fix this problem as soon as possible except this bug everything works fine.

planet123,
I'd be willing to bet your washed out problem is nothing to do with Vidcoder. Video played on a PC needs to have it's levels expanded from TV levels to PC levels on playback or it'll look washed out. Your video player /render /video card may be correcting the levels when playing DVD video but not when playing the encodes. Try a conversion using a program other than Vidcoder to see if the result is any different. If it's not, the problem is not the encoding.
The encoded video should look fine played on a standalone player and a TV as they all no doubt use TV levels by default. Have you tried comparing the original to the encode using something other than a PC?

[fantasmanegro]

It was just a suggestion and of course he is free to reject it. Nobody ever said anything else.

So, not sure what your problem is ;).



The current VidCoder Advanced tab is not necessarily "RandomEnergy GUI" *. It's rather more or less just a copy of the Advanced tab of the official HandBrake WinGUI.

And it looks a bit messy IMHO (it at least could be better IMHO).

Therefore the suggestion of that "mock-up", which, IMHO, looks a lot tidier and makes more sense regarding the order of the controls. That's all.

So, no reason to panic ;).

* It's "RandomEngy" and not "RandomEnergy", just in case you shouldn't have noticed :p.

sorry it was the spell check or maybe keyboard playing with my feelings...

about "It's rather more or less just a copy of the Advanced tab of the official HandBrake WinGUI." ... it was developed by RandomEngy so... it is RandomEngy GUI... :devil:

anyway... suggestion : suggest less ;)

[RandomEngy]

That's why there are two versions of the mock-up. One without abbreviations and one with some exemplary abbreviations if there would be the need to save some space.

Yes, the one without abbreviations actually has two abbreviations, namely: "Direct MV Prediction Mode" and "Psy RD / Psy Trellis".

But if you would use "Direct Motion Vector Prediction Mode" and "Psychovisual Rate Distortion / Psychovisual Trellis" then that would waste a lot of space ;).

Also, it's actually called "Direct MV prediction mode" and "RD" in x264.exe --fullhelp as well.

Also, there are tooltips for every control on the Advanced tab (when hovering over them with the mouse cursor) which feature descriptions of the options the controls are resembling. And the names of the options could and should always be repeated without abbreviations in those tooltips IMHO.

There are a couple of reasons I don't like abbreviations. The first you already know is that it look unprofessional. The second is that the need to abbreviate and save space indicates the lack of a flexible interface. One that might break if it's translated to another language that needs longer strings.

Any recommendation to some documentation/tutorial or something like that which would explain it :p?

Anyway, you probably would be faster at it because you already know how to do all this stuff and because it basically is your application... :p;)

This should get you started: http://msdn.microsoft.com/en-us/library/ms742119.aspx

You can edit with Visual Studio Express: http://www.microsoft.com/visualstudio/eng/products/visual-studio-express-products

And it is kind of "my application" but it really is open source. Anyone can contribute in theory. I'm just saying that I have other things to do in VidCoder and it may get done faster if you do it rather than beg me to do it repeatedly.

The defaults could be shown in the tooltips. MeGUI for example shows the defaults for all options in the tooltips as well (it shows the default settings and recommended settings in the tooltips for every option).

I guess so. You wouldn't get to see if an option was on a default setting at a glance anymore. And you don't get to see the possible range simply by opening the dropdown. And I don't see a major usability upside of the number box... you get to save a click when you want to change the number by 1, sure... mostly a wash it seems.

What do you mean with "options box"? Do you mean the "More Settings" box on the Video tab?

Yes.

PS:

Bug report:

Not sure if this can be considered a bug, but while examining the width and height textboxes with spinners on the Picture tab noticed the following:

As mentioned in the earlier post, the width and height textboxes on the Picture tab do show "(none)" or "(auto)" in grey font when no width or height has been specified.

Now when clicking the up arrow of the spinner, then the value in textboxes changes from "(none)"/"(auto)" to "46".

But when you then click the down arrow of the spinner, the value remains at "46".

Shouldn't the value actually change back to "(none)"/"(auto)" instead of remaining at "46"?

At least this would make more sense / would be more intuitive IMHO.

You don't need to quote me every time you make a bug report!

Anyway that sounds reasonable. I'll see what I can do.

[CommonMortal]

Hello, i tried the beta12 after using the stable version for a long time. Could someone please tell me, what the "Fast decode" setting is doing in CRF mode? What does it mean and does it have bad effects on quality or something?

Thank you.

[fantasmanegro]

Hello, i tried the beta12 after using the stable version for a long time. Could someone please tell me, what the "Fast decode" setting is doing in CRF mode? What does it mean and does it have bad effects on quality or something?

Thank you.

from fast to very slow... faster is "worst" and very slow is "better"... about image quality

from fast to very slow... faster is "bigger" and very slow is "smaller" about file size

medium or slow give good image quality to my eyes...

-fastdecode: --no-cabac --no-deblock --no-weightb --weightp 0

[mike20021969]

Interesting discovery with the x264 preset slider.
Using a CQ of 25:
Original file - 9.67MB

Placebo - 1.53MB
Very Slow - 1.56MB
Slower - 1.60MB
Slow - 1.60MB
Medium (Default) - 1.71MB
Fast - 1.71MB
Faster - 1.60MB
Very Fast - 1.54MB
Super fast - 2.32MB
Ultra Fast - 4.63MB

Why is Very Fast better (file size wise) than Very Slow for file size?

[CommonMortal]

f
-fastdecode: --no-cabac --no-deblock --no-weightb --weightp 0

Thank you very much. Definitely not something i would want to use :D

[mike20021969]

So you finally have started to use the x264 preset/tune/profile/level settings on the Video tab :p;)?

I prefer to tinker with Advanced settings usually - not a little slider :)

Someone correct me if I'm wrong, but you're supposed to get a smaller file size whilst retaining picture quality using the slider (i.e. moving slider from the left to the right).

So why can I use Very Fast and get a better file size and retain the same picture quality than using Very Slow?

I've tried numerous files now and Very Fast is always giving me smaller file sizes and encodes are happening in double-quick time :D

[mike20021969]

See the following threads for example:


I see. I've learned some more :)

[fantasmanegro]

I prefer to tinker with Advanced settings usually - not a little slider :)

Someone correct me if I'm wrong, but you're supposed to get a smaller file size whilst retaining picture quality using the slider (i.e. moving slider from the left to the right).

So why can I use Very Fast and get a better file size and retain the same picture quality than using Very Slow?

I've tried numerous files now and Very Fast is always giving me smaller file sizes and encodes are happening in double-quick time :D

can you post mediainfo ?
remember image quality is different for everyone

[mike20021969]

can you post mediainfo ?

Here's the ones for Placebo, Medium, Very Fast & Ultra Fast (I noticed Ultra Fast also has an additional entry: Duration_FirstFrame).
It appears that when you adjust the slider, other settings may be altered too.

Placebo:

Format : MPEG-4
Format profile : Base Media / Version 2
Codec ID : mp42
File size : 1.54 MiB
Duration : 12s 64ms
Overall bit rate mode : Variable
Overall bit rate : 1 069 Kbps
Encoded date : UTC 2013-01-11 15:13:17
Tagged date : UTC 2013-01-11 15:17:28
Writing application : HandBrake 5125svn 2013010101

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : Main@L4.0
Format settings, CABAC : Yes
Format settings, ReFrames : 16 frames
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 12s 64ms
Bit rate mode : Variable
Bit rate : 910 Kbps
Width : 696 pixels
Height : 556 pixels
Display aspect ratio : 16:9
Frame rate mode : Variable
Frame rate : 23.873 fps
Minimum frame rate : 3.206 fps
Maximum frame rate : 25.000 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.098
Stream size : 1.31 MiB (85%)
Writing library : x264 core 128
Encoding settings : cabac=1 / ref=16 / deblock=1:0:0 / analyse=0x1:0x131 / me=tesa / subme=9 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=0 / me_range=24 / chroma_me=1 / trellis=0 / 8x8dct=0 / cqm=0 / deadzone=21,11 / fast_pskip=0 / chroma_qp_offset=-2 / threads=3 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=16 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=0 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=60 / rc=crf / mbtree=1 / crf=25.0 / qcomp=0.60 / qpmin=4 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00
Encoded date : UTC 2013-01-11 15:13:17
Tagged date : UTC 2013-01-11 15:17:28
Color primaries : BT.601 PAL
Transfer characteristics : BT.709
Matrix coefficients : BT.601

Audio
ID : 2
Format : AAC
Format/Info : Advanced Audio Codec
Format profile : LC
Codec ID : 40
Duration : 11s 669ms
Bit rate mode : Variable
Bit rate : 160 Kbps
Maximum bit rate : 169 Kbps
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 KHz
Compression mode : Lossy
Delay relative to video : 352ms
Stream size : 227 KiB (14%)
Encoded date : UTC 2013-01-11 15:13:17
Tagged date : UTC 2013-01-11 15:17:28


Medium:

Format : MPEG-4
Format profile : Base Media / Version 2
Codec ID : mp42
File size : 1.72 MiB
Duration : 12s 64ms
Overall bit rate mode : Variable
Overall bit rate : 1 194 Kbps
Encoded date : UTC 2013-01-11 15:03:26
Tagged date : UTC 2013-01-11 15:03:44
Writing application : HandBrake 5125svn 2013010101

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : Main@L3.0
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 12s 64ms
Bit rate mode : Variable
Bit rate : 1 034 Kbps
Width : 696 pixels
Height : 556 pixels
Display aspect ratio : 16:9
Frame rate mode : Variable
Frame rate : 23.873 fps
Minimum frame rate : 3.206 fps
Maximum frame rate : 25.000 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.112
Stream size : 1.49 MiB (87%)
Writing library : x264 core 128
Encoding settings : cabac=1 / ref=3 / deblock=1:0:0 / analyse=0x1:0x111 / me=hex / subme=7 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=0 / me_range=16 / chroma_me=1 / trellis=0 / 8x8dct=0 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=3 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=0 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=crf / mbtree=1 / crf=25.0 / qcomp=0.60 / qpmin=4 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00
Encoded date : UTC 2013-01-11 15:03:26
Tagged date : UTC 2013-01-11 15:03:44
Color primaries : BT.601 PAL
Transfer characteristics : BT.709
Matrix coefficients : BT.601

Audio
ID : 2
Format : AAC
Format/Info : Advanced Audio Codec
Format profile : LC
Codec ID : 40
Duration : 11s 669ms
Bit rate mode : Variable
Bit rate : 160 Kbps
Maximum bit rate : 169 Kbps
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 KHz
Compression mode : Lossy
Delay relative to video : 352ms
Stream size : 227 KiB (13%)
Encoded date : UTC 2013-01-11 15:03:26
Tagged date : UTC 2013-01-11 15:03:43

Very Fast:

Format : MPEG-4
Format profile : Base Media / Version 2
Codec ID : mp42
File size : 1.55 MiB
Duration : 12s 64ms
Overall bit rate mode : Variable
Overall bit rate : 1 078 Kbps
Encoded date : UTC 2013-01-11 15:19:36
Tagged date : UTC 2013-01-11 15:19:44
Writing application : HandBrake 5125svn 2013010101

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : Main@L3.0
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 12s 64ms
Bit rate mode : Variable
Bit rate : 918 Kbps
Width : 696 pixels
Height : 556 pixels
Display aspect ratio : 16:9
Frame rate mode : Variable
Frame rate : 23.873 fps
Minimum frame rate : 3.206 fps
Maximum frame rate : 25.000 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.099
Stream size : 1.32 MiB (85%)
Writing library : x264 core 128
Encoding settings : cabac=1 / ref=1 / deblock=1:0:0 / analyse=0x1:0x111 / me=hex / subme=2 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=0 / me_range=16 / chroma_me=1 / trellis=0 / 8x8dct=0 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=0 / threads=3 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=0 / open_gop=0 / weightp=1 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=10 / rc=crf / mbtree=1 / crf=25.0 / qcomp=0.60 / qpmin=4 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00
Encoded date : UTC 2013-01-11 15:19:36
Tagged date : UTC 2013-01-11 15:19:44
Color primaries : BT.601 PAL
Transfer characteristics : BT.709
Matrix coefficients : BT.601

Audio
ID : 2
Format : AAC
Format/Info : Advanced Audio Codec
Format profile : LC
Codec ID : 40
Duration : 11s 669ms
Bit rate mode : Variable
Bit rate : 160 Kbps
Maximum bit rate : 169 Kbps
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 KHz
Compression mode : Lossy
Delay relative to video : 352ms
Stream size : 227 KiB (14%)
Encoded date : UTC 2013-01-11 15:19:36
Tagged date : UTC 2013-01-11 15:19:44

Ultra Fast:
Format : MPEG-4
Format profile : Base Media / Version 2
Codec ID : mp42
File size : 4.63 MiB
Duration : 11s 792ms
Overall bit rate mode : Variable
Overall bit rate : 3 295 Kbps
Encoded date : UTC 2013-01-11 15:11:43
Tagged date : UTC 2013-01-11 15:11:47
Writing application : HandBrake 5125svn 2013010101

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : Baseline@L3.0
Format settings, CABAC : No
Format settings, ReFrames : 1 frame
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 11s 792ms
Duration_FirstFrame : 272ms
Bit rate mode : Variable
Bit rate : 3 207 Kbps
Width : 696 pixels
Height : 556 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 25.000 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.331
Stream size : 4.40 MiB (95%)
Writing library : x264 core 128
Encoding settings : cabac=0 / ref=1 / deblock=0:0:0 / analyse=0:0 / me=dia / subme=0 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=0 / me_range=16 / chroma_me=1 / trellis=0 / 8x8dct=0 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=0 / threads=3 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=0 / weightp=0 / keyint=250 / keyint_min=25 / scenecut=0 / intra_refresh=0 / rc=crf / mbtree=0 / crf=25.0 / qcomp=0.60 / qpmin=4 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=0
Encoded date : UTC 2013-01-11 15:11:43
Tagged date : UTC 2013-01-11 15:11:47
Color primaries : BT.601 PAL
Transfer characteristics : BT.709
Matrix coefficients : BT.601

Audio
ID : 2
Format : AAC
Format/Info : Advanced Audio Codec
Format profile : LC
Codec ID : 40
Duration : 11s 669ms
Bit rate mode : Variable
Bit rate : 160 Kbps
Maximum bit rate : 169 Kbps
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 KHz
Compression mode : Lossy
Stream size : 227 KiB (5%)
Encoded date : UTC 2013-01-11 15:11:43
Tagged date : UTC 2013-01-11 15:11:47

[Zerondar]

Not sure what you mean by the automatic renaming. It only gives them a different name when there's already a file with that name there, and even then you can configure it. But yeah anyway it should be keeping the same name as the source file.


for me it automaticly applies {source}-{title} when batch encoding if set on default
(single file encodes work name stays as it should, batch file encodes filenames get automaticly renamed to {source}-{title})
or custom name ofcourse