UI Feedback

Archive of historical development discussions
Discussions / Development has moved to GitHub
Forum rules
*******************************
Please be aware we are now using GitHub for issue tracking and feature requests.
- This section of the forum is now closed to new topics.

*******************************
Post Reply
framespereon
Posts: 2
Joined: Wed Jan 09, 2013 10:14 am

UI Feedback

Post by framespereon »

Hi,

I recently started using handbrake to solve the common annoyance of .wmv audio sync problems which I discovered were due to the source being (foolishly) encoded using a variable frame rate (VFR) MeGUI/Avisynth could not convert to CFR without audio sync problems, et voila! Handbrake apparently can, so I like.

  • [Aside: For the love of all mankind, video sharers please STOP using variable frame rate for normal video! The advantages do not outweigh the disadvantages unless your video is mostly a cartoon or a slide show, modern codecs can deal with duplicate frames very efficiently. It's also best to avoid proprietary Microsoft wmv codecs and containers when possible, period, for many reasons.]



So I'd like to help. I'm a software engineer (Assembly/C/C++/C# mostly), and like most the guys here my time is limited, but I'm sure I can contribute. I'm using the latest Win32 (x86) build, but my thinking is cross-platform here. I quickly realized one of the strengths -- and weaknesses -- of Handbrake is its UI. While fairly robust, it has some areas of confusion which would be really easy to address with fairly little code.

Near as I can tell the UI design is an attempt to simplify the many complex options involved in video transcoding. Unfortunately, the effort is mostly ineffective because the user must constantly second-guess the UI and there are so many basic options unavailable, supplanted by ones made unnecessarily complex by Handbrake's particular interpretation of what's important and what isn't.


  • :idea: "Picture settings" inclusion in saved profile. This is a rather confusing label, I'd suggest instead "Crop/Resizing" or "Dimensions" something similar, but more importantly there appears to be no option to simply disable it. In the query string, there's always -w -h and related options. I tried putting both zero and -1 in for options in the GUI, but that didn't work.

    Solution: Re-label and add an enable/disable checkbox that greys out the entire tab.


    :idea: Missing or confusing x264 options + advanced string section This could solve a lot of confusion problems, as many new Handbrake users are going to be familiar with x264 options but not Handbrake's new way of viewing them (fortunately the Tooltips are some of the best I've seen).

    Solutions:
    a. Framerate: Include an additional option to convert to a specified CFR that is the same as the source.
    b. Quantizer: It took me an hour to figure out there's no way to specify quantizer mode vs. quality mode
    c. deblock: Add an enable/disable checkbox. Setting both to -6 seems to be a workaround. Took me awhile on this one, too.
    d. Cropping: Add an enable/disable checkbox. Only because automatic cropping is an inherently unreliable function, would suggest disabled by default.
    e. Filters: Add an enable/disable checkbox, suggest disabled by default (I think deint was enabled by default (???))
    f. Advanced: Many options missing, I'd suggest megui's x264 multi-tab dialog box for a model here, duplicating it, ideally. Codecs should probably have their own dialog box popped by pressing an "advanced" option.
    g. Custom x264 options textbox: This was discussed some here: viewtopic.php?f=6&t=19426 , but this is a workaround, not a solution. Other apps (including megui) will generate a custom x264 command line string, users should be able to just simply paste it, and not have to reconstruct the string to meet Handbrake's peculiarities. The textbox is also not labeled (in ver 0.98 at least).
    h. Motion Estimation Range: Curiously seems unavailable unless Uneven-Multi-Hexagon or a higher search method is chosen. It's missing for Diamond and [simple] Hexagon.


    :idea: Audio tab: Is it just me, or does the audio want to mix to 6 channels by default, even with auto set?

    Solution: (Generally) It seems there's a lot that could be done better with this tab, including clarification on what passthrough ("passthru") does and does not, more codec configuration options.


    :idea: Queue: Excellent. One minor fix (above issues are obviously MUCH higher priority) Move up/down is excruciatingly slow, and there does not appear a way to simply move multiple slots or drag and drop.

    Solution: Add drag-and-drop moving of selected queue items, including ones which are not a sequence (i.e. 1, 3, 4-7 vs. 2-6). Lower priority. Another useful option would be to display the command line and allow editing either in text or in the GUI.


    :idea: Add Folder function: Users must "physically" browse to the folder, and only the entire folder and no subfolders are processed

    Solution: Use a multi-file-select open dialog box which has a checkbox to include subfolders. The starting point path can simply be pasted in that way. Obviously lower priority than the crop/resize + x264 options discussed above.


    :idea: Settings tied to source video files (More generally) It should not be necessary to specify a source file in order to configure encoding options and save a preset

    Solution: (Generally) De-couple the dependency, set anything source-dependent with some "undetermined" designator, settings to be populated for each file at enqueue-time.
[/color]


Hope this helps. I realize like most open-source projects, Handbrake is a team effort which has evolved over years, and was not designed initially as a robust x264 GUI from the get-go. Evolution is, of course, hardly a new problem in app dev. It's a good app, and it's nice to see something not tied to the now archaic avi container like VirtualDub and MeGUI.

Lastly, a trivial, but nagging qeustion... why is it called "Handbrake?" How does the pineapple drink a relate? I couldn't find anything after a few minutes of searching a couple weeks ago.


Best,
-FramesPerEon
mduell
Veteran User
Posts: 8198
Joined: Sat Apr 21, 2007 8:54 pm

Re: New Icons

Post by mduell »

framespereon wrote:
  • [Aside: For the love of all mankind, video sharers please STOP using variable frame rate for normal video! The advantages do not outweigh the disadvantages unless your video is mostly a cartoon or a slide show, modern codecs can deal with duplicate frames very efficiently. It's also best to avoid proprietary Microsoft wmv codecs and containers when possible, period, for many reasons.]
Reducing frames (like you can with a cartoon or slideshow) is not the primary use of VFR encoding. It's mostly for mixed content like 24fps film scenes and 30fps CGI or commercials. Tools that don't support VFR are broken.
nikpawlak
Posts: 23
Joined: Tue Sep 29, 2009 7:14 am

Re: New Icons

Post by nikpawlak »

This should be separated into its own thread. It does not relate to new icons. And the story of the pineapple was discussed earlier in the thread so if you would like to take the time to read through the thread you will find the link.
User avatar
s55
HandBrake Team
Posts: 10357
Joined: Sun Dec 24, 2006 1:05 pm

Re: UI Feedback

Post by s55 »

Agreed. Topic is now split off.
GregiBoy
Veteran User
Posts: 908
Joined: Sat Feb 12, 2011 9:23 pm

Re: UI Feedback

Post by GregiBoy »

And the Handbrake logo is devised from a HandBrake cocktail, not just a pineapple!! :D

Here's one recipe!! http://www.cocktailmaking.co.uk/display ... -Handbrake
framespereon
Posts: 2
Joined: Wed Jan 09, 2013 10:14 am

Re: UI Feedback

Post by framespereon »

Noted on the topic split and the pineapple drink. I like it, I just didn't get it or the reference to a hand brake - I'll do some more digging, it's trivial, what's more important is functionality.

Tools that don't support VFR are not necessarily broken

I see the point on mixed content, but that's a separate debate anyways ("aside") Personally I find the best solution is to just convert up to a higher CFR standard (i.e. 30fps or sometimes 60fps for anything under that... 15fps, 23.976fps, 24fps, 25fps, 29.97fps, 30fps). With some content there are choppiness issues, yes, but those are usually trivial, and one has a consistent CFR clip. I recommend VBR video over CBR significant quality improvement, but definitely CBR audio with rare exception. The bitrate improvement for the same quality is usually tiny compared to the combined video and audio bitrate, and with CBR video, there are no audio-sync woes unless the source itself is fubbed-duck.

Either way, an option to convert to CFR appears to be missing... and especially that checkbox to DISABLE resizing/cropping/anamorph (SAR/DAR)... plus a pass-through option for direct x264 commands.

I may just end up WRITING a similar app that solves all these problems that seem to elude many and generate hundreds of forum questions and comments.... nothing time can't solve...

thanks for the replies, I'd be interested in hearing more, or a referral to another thread by those more familiar with the various discussions as they related to HB.

Cheers,
FPE
User avatar
JohnAStebbins
HandBrake Team
Posts: 5725
Joined: Sat Feb 09, 2008 7:21 pm

Re: UI Feedback

Post by JohnAStebbins »

Picture settings: If I understand your meaning (your writing style and my language parser seem to be somewhat incompatible), I agree with these points. The label could be better, but what covers resolution, cropping, aspect ratio, and the range of assorted filters that are all under "Picture Settings"? The linux gui determines how these settings are saved in presets a little differently. Picture settings are always saved in the preset. But I have a checkbox in the picture settings window to "use the best resolution for the source" and to "disable cropping". All the other picture settings already have options that can be used to disable them individually.

CFR: Are you using the nightly builds? AFAIK, all 3 gui's have a "Same as source" CFR option already. But be warned, the framerate of the source is sometimes misdetected and will result in incorrect output if you use this option. Detecting the framerate of variable framerate sources is tricky business (and many sources just have broken framerate information).

x264 missing options: I'll assume you mean we don't have a widget for every x264 option. HandBrake is not a swiss army knife (read https://trac.handbrake.fr/wiki/IsIsnt). And there are a butt-load-full of x264 options (see http://mewiki.project357.com/wiki/X264_Settings). We put what we deem to be the most frequently used option in widgets. Then we provide the edit box for users to fill in anything the desire. In addition, the nightly builds support widgets for x264 preset/tune/profile/level. These are far more useful to the majority of casual users.

x264 confusing options: HandBrake doesn't use x264. It uses libx264. The option string is the native format accepted by libx264. HandBrake didn't invent this format, the x264 developers did (again, the format of these options is defined here http://mewiki.project357.com/wiki/X264_Settings) . An x264 command line string is meaningless in this context.

x264 quantizer: CRF is more useful to the majority of people, so this is what HandBrake chooses to put in the gui. If you need QP, you need to learn libx264 options and use the advanced option string

x264 deblock: disabling deblocking is another little used feature. If you need it, "no-deblock" in the advanced option string. Setting to -6,-6 is not the same as disabling. If you are doing this for fastdecode support, you must use no-deblock. The x264 tunes feature a "fastdecode" tune that enables no-deblock for you.

x264 merange: this is simply a bug. It works properly in the linux gui. For dia and hex, valid merange values should be 4-16. For all other me types a much wider range is allowed, but >64 is ludicrous (>24 is just plain silly), so lingui limits these to 4-64.

Filters: each filter already has an option to disable it. Cluttering the interface with a global "disable" isn't necessary.

Audio: Yes, audio needs a rethink. Each of the HandBrake gui's behaves a little different with regard to audio. Linux gui mixes to the highest mix that isn't larger than the source mix for example when "auto passthru" is selected and it is forced to fallback to encoding. The direction our thoughts are going regarding audio
(courtesy of s55, the windows developer)
Image

Queue: I agree that drag-n-drop is nice (lingui does this, but doesn't allow multi-row drag).

Regarding command line editing, the windows gui is the only one that is a front-end to the CLI, and this is changing. Soon, it will use libhb directly just like all the other gui's. So there is no command line to edit.

Folder function: This isn't just a gui change. libhb currently accepts *one* source path. If that path is a folder, it will scan it's contents. I don't like the idea of recursively descending subfolders. But adding the ability for libhb to accept a list of paths instead of a single path is on my (extremely ling) TODO list. Patches welcome :wink:

Settings tied to source video: You could have worded this better. I had to read it several times before it sank in. The ability to modify settings and save those settings to a preset *before* loading any source is a good idea imo. Why didn't I think of that? Oh, that's right, I did :mrgreen: Lingui lets you do this.

The drink is called "Devil's Handbrake". Thus the name HandBrake.
Post Reply