[MPlayer-users] Transcoding from one aspect ratio to another
rolf.ernst at silverlightning.org
Thu Nov 4 22:50:43 CET 2010
On Thu, Nov 4, 2010 at 4:33 PM, Nix <niks1024 at gmail.com> wrote:
> On 2010.11.04. 03:24, Rolf Ernst wrote:
>> On 11/3/2010 7:56 PM, JD wrote:
>>> On 11/03/2010 05:44 PM, Rolf Ernst wrote:
>>> Hey guys - let us not belabor this enquiry.
>>> I accept that what I want cannot be done without one of
>>> 1. Black bars on top and bottom
>>> 2. Zoomed in until each frame fills 800 vertical pixels of the screen,
>>> and then cropped so that only 1280 horizontal pixesl of the zoomed
>>> frames remain.
>>> Neither of these is what I want, so let's not continue to beat a dead
>>> horse :)
>> This is simply not so but by all means, I shall not force you to accept
>> the facts.
> Since my weekend started this evening you are welcome to prove it. No
> seriously, take a square (for sake of example you can assume that it has an
> image mapped on it) that's being displayed with ratio of 2:1 (in other words
> the image mapped on it is in fact stored in an vertically stretched state
> for improved vertical resolution). Now, if you crop away, say, 20% from
> right side, do you really think that it should be still be displayed with
> DAR of 2:1? Obviously, if you retained PAR, then all is fine but DAR would
> still be different. I don't know about mencoder but generally for muxing you
> need to specify either DAR or the intended viewing resolution which more or
> less obviously same thing.
> P.S. I just found this cute little line in mkvmerge manpage:
> "Matroska™ files contain two values that set the display properties that a
> player should scale the image on playback to: display width and display
> P.P.S. Regarding your other post about anamorphic being non-square pixels,
> I'm not so sure about your definition. Mostly because anamorphic video was
> invented like before 1930's when digital computers didn't even exist,
> therefore at the very least your definition that ties anamorphic with PAR is
> at the very least badly defined, in my humble and worthless opinion
Ok, I'd say you would probably be best served just using YAMF but I looked
at the code and here is what it does when multiplexing to matroska:
It passes the --aspect-ratio parameter to Matrosdka and here is how it
calculates it (sorry for confusing you beforehand but I hadn't looked at the
code in a long time):
double origAspect = (double) cropData.getTotalWidth() /
(double) cropData.getTotalHeight() / runDef.getTechInfo().getVideoAspect();
double newAspect = (double) cropData.getCroppedWidth() /
double aspectRatio = (newAspect / origAspect);
Let me explain:
I calculates origAspect by taking the the total pixel size of the source
video: Width/Height/(whatever aspect ratio mplayer initially reported). You
get this by running mplayer with the -identify parameter.
It then calculates newAspect as the aspect ratio what remains after cropping
The value that you then pass to mkvmerge as --aspect-ratio is
newAspect/origAspect and everything will be peachy.
Again, if you use x264 video you are best served by just using the software
and let it calculate it for you. Otherwise, just use my formula above.
Let me know if this is not clear.
This is America. Huge multinationals choose our political officials here.
More information about the MPlayer-users