unlock the Width & Height
Forum rules
An Activity Log is required for support requests. Please read How-to get an activity log? for details on how and why this should be provided.
An Activity Log is required for support requests. Please read How-to get an activity log? for details on how and why this should be provided.
unlock the Width & Height
Can anyone tell me how to unlock the Width & Height input fields on the Picture Settings menu?
I have a VOB file that was originally set in some strange resolution and want to fix it back to 4:3
I have tried deselecting 'keep aspect ratio' and turning off Anamorphic, but after I input the new values, it reverts back.
MAC OSX 10.9.5 and using Handbrake Version 0.10.3 x86_64 (2016012200)
Thanks.
I have a VOB file that was originally set in some strange resolution and want to fix it back to 4:3
I have tried deselecting 'keep aspect ratio' and turning off Anamorphic, but after I input the new values, it reverts back.
MAC OSX 10.9.5 and using Handbrake Version 0.10.3 x86_64 (2016012200)
Thanks.
-
- Veteran User
- Posts: 4840
- Joined: Wed May 04, 2011 11:06 pm
Re: unlock the Width & Height
You need a golden key (I have a few spares, I can sell you one for 99 bucks), and you also need to find the lock, it's hidden somewhere on the pineapple.
Re: unlock the Width & Height
It seem that you have the same "Problem" I have on some Files. The Handbreak GUI does not allow to scale up so I think you typed in a value bigger than the x or y dimension of the source material.
I asked the same question and got the answer that the command line handbrake can do what I think you want to do. So I see no chance to get the GUI changed in an official Build....
I asked the same question and got the answer that the command line handbrake can do what I think you want to do. So I see no chance to get the GUI changed in an official Build....
Re: unlock the Width & Height
You can use custom anamorphic.
Re: unlock the Width & Height
Yes, you are right. The "problem" is, that some people don´t want an anamorphic output, they want an output of 16:9 that was sent in anamorphic. On some Sat Receiver channels the Source is 544 x 576 pixel anamorphic 16:9 and they want to transcode it for their Collection to 720 x 404 oder 1024 x 576...
The real question is - why is the GUI setting the maxwidth / maxhight to the width / height of the source material? I have patched this behavior "quick and dirty" and it works like a charme... I don´t understand the reason of this user-restriction - handbrake by itself can handle it without a problem.
The real question is - why is the GUI setting the maxwidth / maxhight to the width / height of the source material? I have patched this behavior "quick and dirty" and it works like a charme... I don´t understand the reason of this user-restriction - handbrake by itself can handle it without a problem.
-
- Novice
- Posts: 63
- Joined: Sat Feb 06, 2010 8:00 pm
Re: unlock the Width & Height
As far as I know, the developer team's thinking behind this is:Alfredo wrote:Yes, you are right. The "problem" is, that some people don´t want an anamorphic output, they want an output of 16:9 that was sent in anamorphic. On some Sat Receiver channels the Source is 544 x 576 pixel anamorphic 16:9 and they want to transcode it for their Collection to 720 x 404 oder 1024 x 576...
The real question is - why is the GUI setting the maxwidth / maxhight to the width / height of the source material? I have patched this behavior "quick and dirty" and it works like a charme... I don´t understand the reason of this user-restriction - handbrake by itself can handle it without a problem.
- Upscaling is generally discouraged, as it should be done on playing by the player hardware/software instead
- People who really need to upscale can do it via the CLI version
Easiest, in my opinion, to use the CLI for those few cases. If it's a regular requirement, consider writing a script.
- JohnAStebbins
- HandBrake Team
- Posts: 5712
- Joined: Sat Feb 09, 2008 7:21 pm
Re: unlock the Width & Height
The fact that HandBrake does not allowing upscaling of one dimension during conversion from anamorphic to non-anamorphic has always been a little peeve of mine. During such a conversion, you either have to upscale one dimension, or downscale the other dimension and lose quality. I've always felt we should allow upscaling as long as at least one dimension is <= the source dimension.
Maybe it's time to have that discussion again. Last time I was overridden by jbrjake who is no longer involved with the project.
Maybe it's time to have that discussion again. Last time I was overridden by jbrjake who is no longer involved with the project.
Re: unlock the Width & Height
+1
The conversion to display width must occur somewhere; imposing a penalty for doing so during the encoding stage begs for reasoning.
The correctly defined viewing dimensions for dvd widescreen format in the Americas is 854x480, not 720x404.
Merely extrapolating the data to its intended display width does not constitute upscaling, a term that unfortunately has become a bit politicized.
Sending the message that software uprez is a bad thing is really a matter of ongoing education, not overly restrictive limits.
Anyone who actually edits or delivers this stuff knows what a pita anamorphic can be to work with. It was designed to save bandwidth during tape acquisition, no mystery there. The choice was made to sacrifice some horizontal resolution, because it is less noticeable than sacrificing the more-important vertical resolution, which is currently what Handbrake GUI does.
The philosophy of "if it doesn't make it smaller, we're not going to do it" becomes a bit of a burden when the net effect is to degrade the viewing experience, in this case by dumping over 1,300,000 bits (15%) of perfectly good raw image data per frame.
We have the choice not to crop; should we have a choice not to downscale, as well?
Bottom line is whether anamorphic or 1:1, the Display Height = Storage Height.
If we reverse that and say that display width = storage width, then our NTSC 4:3 DVDs would come out 720x540, which meets anyone's description of upscaling, doesn't it?
The conversion to display width must occur somewhere; imposing a penalty for doing so during the encoding stage begs for reasoning.
The correctly defined viewing dimensions for dvd widescreen format in the Americas is 854x480, not 720x404.
Merely extrapolating the data to its intended display width does not constitute upscaling, a term that unfortunately has become a bit politicized.
Sending the message that software uprez is a bad thing is really a matter of ongoing education, not overly restrictive limits.
Anyone who actually edits or delivers this stuff knows what a pita anamorphic can be to work with. It was designed to save bandwidth during tape acquisition, no mystery there. The choice was made to sacrifice some horizontal resolution, because it is less noticeable than sacrificing the more-important vertical resolution, which is currently what Handbrake GUI does.
The philosophy of "if it doesn't make it smaller, we're not going to do it" becomes a bit of a burden when the net effect is to degrade the viewing experience, in this case by dumping over 1,300,000 bits (15%) of perfectly good raw image data per frame.
We have the choice not to crop; should we have a choice not to downscale, as well?
Bottom line is whether anamorphic or 1:1, the Display Height = Storage Height.
If we reverse that and say that display width = storage width, then our NTSC 4:3 DVDs would come out 720x540, which meets anyone's description of upscaling, doesn't it?
Re: unlock the Width & Height
OK - Upscaling seems to be the wrong terminus.
In my case I only want to get rid of the anamorphic material. As an example - dvb-s sends mpeg-2 in width 720 pix by hight 576 pix 16:9 and I want convert it to square pixels mp4. The best way to achieve this with a minimum of loss is an recoding to 1024 by 576. That is the way the "professional" iSkysoft Video Converter handles it. The handbrake GUI does handle it in a different very lossy way. The best square pixels are 720 x 396 pix because the GUI forbids a "scale up" of the width to 1024 pix.
Handbrake CLI can handle it the "right way" - the GUI does not.
The "problem" is found in the MAC Gui - I have no other Computer. In the two files PictureController.m and Controller.m maxwidth and setMaxValue are set to the width of the source material and so only the hight can be reduced to get an square pixel output.
From my point of view this is an absolut silly behavior with the maximum of quality loss.
In my case I only want to get rid of the anamorphic material. As an example - dvb-s sends mpeg-2 in width 720 pix by hight 576 pix 16:9 and I want convert it to square pixels mp4. The best way to achieve this with a minimum of loss is an recoding to 1024 by 576. That is the way the "professional" iSkysoft Video Converter handles it. The handbrake GUI does handle it in a different very lossy way. The best square pixels are 720 x 396 pix because the GUI forbids a "scale up" of the width to 1024 pix.
Handbrake CLI can handle it the "right way" - the GUI does not.
The "problem" is found in the MAC Gui - I have no other Computer. In the two files PictureController.m and Controller.m maxwidth and setMaxValue are set to the width of the source material and so only the hight can be reduced to get an square pixel output.
From my point of view this is an absolut silly behavior with the maximum of quality loss.
Re: unlock the Width & Height
Yes, we have the same goal; not to upscale, but to render to correct Display Width, and not Storage Width, which is just a red herring. Pixel aspect can be greater than or less than 1.0!
I haven't complained that much because I've had an easy workaround in WinGUI.
Thanks John Stebbins offering to revisit the discussion. [Corrected attribution]
I haven't complained that much because I've had an easy workaround in WinGUI.
Thanks John Stebbins offering to revisit the discussion. [Corrected attribution]
Last edited by Deleted User 13735 on Sun Jan 31, 2016 2:59 pm, edited 6 times in total.
Re: unlock the Width & Height
j45, not s55
We are two different people ...
We are two different people ...