Hi there! One more little thing: When we rip a movie, black bars are often removed from the top and the bottom of the original picture. This is OK, but it means that the aspect ratio of the movie is changed. ON the other side, when we dump a VOBsub subtitle, no cropping takes place, so it's aspect rate will match the original (un-cropped) movie's. So, when we display a subtitle with the cropped movie, and rescale the vobsub's frame to match the movie's sizes, we are distorting the subtitle's aspect ratio. (Typically, we get shorter letters.) This makes reading the text harder. * * * So, I added the option "-spu-keep-aspect". If it is switched on, the VOBsub's original aspect ratio is used to display it. If it's off (default), the aspect ratio of the movie is applied to the subtitles. See the attached patch. (I updated the man page, too.) (Note: this patch depends on the following two pending patches of mine: a0_positioning-fix-and-cleanup.patch, a1_scaling.patch) I uploaded a sample file here: http://rht.bme.hu/~lunkwill/computer/mplayer/aspect-demo.mkv The default "mplayer -slang eng aspect-demo.mkv" gives this: http://rht.bme.hu/~lunkwill/computer/mplayer/without-keep-aspect.png "mplayer -slang eng aspect-demo.mkv -spu-keep-aspect" gives this: http://rht.bme.hu/~lunkwill/computer/mplayer/with-keep-aspect.png * * * What do you think? IMHO the subtitles look much better this way. Shouldn't this be the default behavior? -- Csillag Kristof <fenwick@freemail.hu>
Hi, On Sat, 22 Jan 2005 06:39:01 +0100, Csillag Kristof <fenwick@freemail.hu> wrote:
What do you think? IMHO the subtitles look much better this way. Shouldn't this be the default behavior?
You're probably right... but what happens if you use -vf expand to get for instance a 4:3 aspect ratio, which was what I used it the past to prevent vobsub distortion? (I must admit I haven't tested your patch yet). Regards, Guillaume
Hi! 2005-01-22, szo keltezéssel 11.54-kor Guillaume Poirier ezt írta:
Hi,
On Sat, 22 Jan 2005 06:39:01 +0100, Csillag Kristof <fenwick@freemail.hu> wrote:
What do you think? IMHO the subtitles look much better this way. Shouldn't this be the default behavior?
You're probably right... but what happens if you use -vf expand to get for instance a 4:3 aspect ratio, which was what I used it the past to prevent vobsub distortion? (I must admit I haven't tested your patch yet). The -vf expand thing also works, but there are several drawbacks: - You usually don't want to give back that large black stripes, just a little so that the subtitles can be put on them. So you won't have the original aspect ratio, just something less distorted. - Using a video filter takes more CPU time
However, subtitles under the movie are nice, so you might want to use the -vf expand anyway. But these things are not mutually exlusive: you can use -vf expand to get a black bar under the movie to render the subtitles at, and -spu-keep-aspect to set them to the correct aspect ratio. (Probably the best is to use both aproaces.) For a comparison, "mplayer aspect-demo.mkv -slang eng -vf expand=0:-100:0:0" gives this: http://rht.bme.hu/~lunkwill/computer/mplayer/expand-without-keep-aspect.png ...and the same, with -spu-keep-aspect added, gives this: http://rht.bme.hu/~lunkwill/computer/mplayer/expand-with-keep-aspect.png -- Csillag Kristof <fenwick@freemail.hu>
On Sat, Jan 22, 2005 at 11:54:26AM +0100, Guillaume Poirier wrote:
Hi,
On Sat, 22 Jan 2005 06:39:01 +0100, Csillag Kristof <fenwick@freemail.hu> wrote:
What do you think? IMHO the subtitles look much better this way. Shouldn't this be the default behavior?
You're probably right... but what happens if you use -vf expand to get for instance a 4:3 aspect ratio, which was what I used it the past to prevent vobsub distortion? (I must admit I haven't tested your patch yet).
If the patch uses width/height/d_width/d_heigh at the point where subtitles are rendered, it will always do the correct thing whether or not expand is used. If the patch uses the original movie aspect from the file, it's horribly broken. Rich
2005-01-22, szo keltezéssel 12.18-kor D Richard Felker III ezt írta:
On Sat, Jan 22, 2005 at 11:54:26AM +0100, Guillaume Poirier wrote:
Hi,
On Sat, 22 Jan 2005 06:39:01 +0100, Csillag Kristof <fenwick@freemail.hu> wrote:
What do you think? IMHO the subtitles look much better this way. Shouldn't this be the default behavior?
You're probably right... but what happens if you use -vf expand to get for instance a 4:3 aspect ratio, which was what I used it the past to prevent vobsub distortion? (I must admit I haven't tested your patch yet).
If the patch uses width/height/d_width/d_heigh at the point where subtitles are rendered, it will always do the correct thing whether or not expand is used. If the patch uses the original movie aspect from the file, it's horribly broken. If course the patch doesn't care about the movie aspect from the file; actually, mplayer's design architect is way smarter than that.
When subtitles are rendered, we are given two params, dxs and dys, which describe the size of the area we have now, _after_ all filtering & other operations. And we have the original frame size of the vobsub... So it would be really hard to get it wrong. Anyway, see my screenshots posted earlier thie afternoon. -- Csillag Kristof <fenwick@freemail.hu>
On Sat, Jan 22, 2005 at 06:23:32PM +0100, Csillag Kristof wrote:
2005-01-22, szo keltezéssel 12.18-kor D Richard Felker III ezt írta:
On Sat, Jan 22, 2005 at 11:54:26AM +0100, Guillaume Poirier wrote:
Hi,
On Sat, 22 Jan 2005 06:39:01 +0100, Csillag Kristof <fenwick@freemail.hu> wrote:
What do you think? IMHO the subtitles look much better this way. Shouldn't this be the default behavior?
You're probably right... but what happens if you use -vf expand to get for instance a 4:3 aspect ratio, which was what I used it the past to prevent vobsub distortion? (I must admit I haven't tested your patch yet).
If the patch uses width/height/d_width/d_heigh at the point where subtitles are rendered, it will always do the correct thing whether or not expand is used. If the patch uses the original movie aspect from the file, it's horribly broken. If course the patch doesn't care about the movie aspect from the file; actually, mplayer's design architect is way smarter than that.
When subtitles are rendered, we are given two params, dxs and dys, which describe the size of the area we have now, _after_ all filtering & other operations. And we have the original frame size of the vobsub... So it would be really hard to get it wrong.
Anyway, see my screenshots posted earlier thie afternoon.
Great! BTW could you make the same changes for rendering text subs? I wanted to do that over a year ago but never figured out how. Right now, text subs are rendered horribly wrong in any movie without square pixels. Rich
2005-01-22, szo keltezéssel 13.08-kor D Richard Felker III ezt írta:
When subtitles are rendered, we are given two params, dxs and dys, which describe the size of the area we have now, _after_ all filtering & other operations. And we have the original frame size of the vobsub... So it would be really hard to get it wrong.
Anyway, see my screenshots posted earlier thie afternoon.
Great! Well, not so great, since it still does not restore the proper aspect rate.
When using the default method, the distortion factor will be x_crop_factor * x_expand_factor ------------------------------- y_crop_factor * y_expand_factor and when using the new method (-spu-keep-aspect), the distortion factor will be x_scale_factor -------------- y_scale_factor (The cropping/expanding/scaling can happen either during encoding, either during playback time.) * * * So, in other words, the old method is distorted by cropping/expanding, and my new method is distorted by scaling. There should be a proper way; I will look at it again tomorrow. * * *
BTW could you make the same changes for rendering text subs? I wanted to do that over a year ago but never figured out how. Right now, text subs are rendered horribly wrong in any movie without square pixels. Well... really important exams are coming on tuesday (probably that's why I'm doing this, anyway;), so I will not have much free time in the coming few days... but I will look at it after I passed (or failed) my exams.
Kristof -- Csillag Kristof <fenwick@freemail.hu>
2005-01-22, szo keltezéssel 13.08-kor D Richard Felker III ezt írta:
[...] Great! Well, not so great, since it still does not restore the proper aspect rate. [...] the old method is distorted by cropping/expanding, and my new method is distorted by scaling.
There should be a proper way; I will look at it again tomorrow. The problem is that we render the subtitles _before_ the scaling up at
2005-01-23, v keltezéssel 06.56-kor Csillag Kristof ezt írta: playback time, and we have no idea about what size (or more importantly) aspect will it be scaled to. Of course the information is available somewhere in mplayer's dataspace, but the vobsub rendering module is obviously not aware of it. * * * Can someone quickly pinpoint me the right place to fetch this information from? (I can look for it, and eventually I will fint it without help, but a quick tip would make it less painful...)
* * *
BTW could you make the same changes for rendering text subs? I wanted to do that over a year ago but never figured out how. Right now, text subs are rendered horribly wrong in any movie without square pixels. Probably the same thing here: the aspect ratio if the comint scale-up is unknown by the sub rendering module. If I can find the solution for the SPU module, I will also adopt it to the SUB module.
Kristof -- Csillag Kristof <fenwick@freemail.hu>
2005-01-23, v keltezéssel 14.36-kor Csillag Kristof ezt írta:
The problem is that we render the subtitles _before_ the scaling up at playback time, and we have no idea about what size (or more importantly) aspect will it be scaled to. Of course the information is available somewhere in mplayer's dataspace, but the vobsub rendering module is obviously not aware of it. So.
Basically, the problem is that aspect ratio is not passed to the OSD level by the VO drivers; every function call exported from the OSD level only takes two parameters, width and height, and because the VO drivers can do rescaling (like Xv), we can not calculate the aspect from this. * * * If we want to render OSD elements (both text subtitles and VOBsub subtitles) with correct aspect rate, we must get the necessary information from the VO drivers. So, we have to opinions: 1. To modify every OSD call in every VO driver, to include this one extra parameter besides the width and the height. (~70 lines.) 2. To save this aspect rate (as displayed on the monitor) somewhere when we set up the VO driver in vf_vo, and later use this value from the OSD layer. (2) would require much less work, but is ugly, because until now, all information from vf_vo level to the OSD level was flowing via the actual VO drivers (like X11, xv, etc.), so smugling this information directly to the OSD layer (bypassing the VO drivers) would go agains the design principles... but this would not stop it from working. (And the codebase already looks like a haystack, anyway.:) * * * Someone with authority should tell me: which opinion should I take? Kristof -- Csillag Kristof <fenwick@freemail.hu>
On Sun, Jan 23, 2005 at 05:33:57PM +0100, Csillag Kristof wrote:
2005-01-23, v keltezéssel 14.36-kor Csillag Kristof ezt írta:
The problem is that we render the subtitles _before_ the scaling up at playback time, and we have no idea about what size (or more importantly) aspect will it be scaled to. Of course the information is available somewhere in mplayer's dataspace, but the vobsub rendering module is obviously not aware of it. So.
Basically, the problem is that aspect ratio is not passed to the OSD level by the VO drivers; every function call exported from the OSD level only takes two parameters, width and height, and because the VO drivers can do rescaling (like Xv), we can not calculate the aspect from this.
* * *
If we want to render OSD elements (both text subtitles and VOBsub subtitles) with correct aspect rate, we must get the necessary information from the VO drivers.
So, we have to opinions:
1. To modify every OSD call in every VO driver, to include this one extra parameter besides the width and the height. (~70 lines.)
2. To save this aspect rate (as displayed on the monitor) somewhere when we set up the VO driver in vf_vo, and later use this value from the OSD layer.
(2) would require much less work, but is ugly, because until now, all information from vf_vo level to the OSD level was flowing via the actual VO drivers (like X11, xv, etc.), so smugling this information directly to the OSD layer (bypassing the VO drivers) would go agains the design principles... but this would not stop it from working. (And the codebase already looks like a haystack, anyway.:)
* * *
Someone with authority should tell me: which opinion should I take?
I vote for option 1. MPlayer already has too many bad hacks with global vars. Rich
On Sunday, 23 January 2005 at 18:06, D Richard Felker III wrote:
On Sun, Jan 23, 2005 at 05:33:57PM +0100, Csillag Kristof wrote: [...]
Basically, the problem is that aspect ratio is not passed to the OSD level by the VO drivers; every function call exported from the OSD level only takes two parameters, width and height, and because the VO drivers can do rescaling (like Xv), we can not calculate the aspect from this.
* * *
If we want to render OSD elements (both text subtitles and VOBsub subtitles) with correct aspect rate, we must get the necessary information from the VO drivers.
So, we have to opinions:
1. To modify every OSD call in every VO driver, to include this one extra parameter besides the width and the height. (~70 lines.) [...] I vote for option 1. MPlayer already has too many bad hacks with global vars.
Does this mean that after that, we can have a working -vf autoexpand=aspect=4/3 that will add black borders to fit the movie within the specified AR without the VO rescaling it to whatever it sees fit? R. -- MPlayer RPMs maintainer: http://greysector.rangers.eu.org/mplayer/ "I am Grey. I stand between the candle and the star. We are Grey. We stand between the darkness ... and the light." -- Delenn in Grey Council in Babylon 5:"Babylon Squared"
2005-01-24, h keltezéssel 02.12-kor Dominik 'Rathann' Mierzejewski ezt írta:
Does this mean that after that, we can have a working -vf autoexpand=aspect=4/3 that will add black borders to fit the movie within the specified AR without the VO rescaling it to whatever it sees fit? No; this means that after that, whatever filters do whatever to your video, either during encoding, either during playback time, the OSD elements (like subtitles) can have correct aspect ratios. (As long as the VO tells the OSD module it's aspect rate, as it should.)
-- Csillag Kristof <fenwick@freemail.hu>
2005-01-23, v keltezéssel 12.06-kor D Richard Felker III ezt írta:
I vote for option 1. MPlayer already has too many bad hacks with global vars. OK.
So, here we go. The modifications have to be made on three different stages. 1. The VO drivers have to pass the aspect ratio parameter 2. The OSD layer has to reveive it, and pass it on 3. The various OSD elements have to use it. * * * Here come the patches: I. o0_aspect_framework.patch - This the generic framework. Here is what I did: - I took the 3 relevant interface functions (vo_draw_text, vo_remove_text and vo_update_osd), and added and aspect ration parameter to them. - I added the necessary code to the OSD layer. (About storing and passing on aspect data.) - I created wrapper macros for each of theese functions named whatever_noaspect, which have the original parameter list, and call the modified functions with 0 as aspect rate, and replaced all references to the changed functions with these wrappers. So, the situation after applying this patch is the following: - The OSD level can handle the aspect rate information, but - none of the VO drivers actually passes it; they all call the (now deprecated) whatever_noaspect wrappers, without the aspect parameter. To make them pass on the information, one has to add the aspect param, and remove the _noaspect tag. - The OSD level passes on the aspect data internally, but none of the OSD elements use it yet. The important bit is this: with this patch, everything keeps working as it worked so far; applying this does _not_ require to fix every VO driver, it just makes it possible. * * * II. o1_aspect_libvo_x11_xv.patch - vo_x11 and vo_xv support (depends on the o0 patch, doesn't make sense without the o2 patch) This patch adds aspect support to the x11 and the xv vo drivers. (Or, at least, it tries to.) <helpless moaning> *********************** *I just don't get it. * *********************** Can someone please explain me the following: Take a look at this: http://rht.bme.hu/~lunkwill/computer/mplayer/clip-2.mkv mplayer -v clip-2.mkv -vo x11 -zoom ... says this: VO Config (720x552->1024x552,flags=4,'MPlayer',0x32315659) VO: [x11] 720x552 => 1024x552 Planar YV12 [zoom] ... and sets the vo_dwidth and vo_dheight variables to 1024 and 552. VO Config (720x552->1024x552,flags=0,'MPlayer',0x32315659) VO: [xv] 720x552 => 1024x552 Planar YV12 [...] [xv] dx: 0 dy: 0 dw: 1024 dh: 588 ...and sets vo_dwidth and vo_dheight to 1024 and 588 Where does this 588 come from? I really don't feel like analyzing vo_xv's internals any more. Now, what will the aspect on the monitor be? 1024/552 or 1024/588? If the former, than why is vo_dheight set to a different value? If the later, than why to vo_xv and vo_x11 produce different results? * * * Someone who is familiar with vo_x11's internals should tell me about this. </helpless moaning> I only use the xv and the x11 drivers, so I guess I should not touch the others, should I? III. o2_aspect_spu_subs.patch - aspect rate support for VobSubs (depends on the o0 patch, doesn't make sense without the o1 patch) This patch makes the VobSub renderer module use the aspect rate information passed down by the OSD layer, if available. (This made some of the assertations of the code false, so I had to touch it here and there.) Adds the -spu-noaspect option to switch this feature off; if this (negative) option is switched on, or if aspect data is not available, falls back the mplayer's original behavior. (Stretches the SPU frame all over the movie.) This o2 patch depends my a0 (positioning cleanup & bugfixes) and a1 (scaling) patches, which I also attached for simplicity. * * * ... and ... Da-Dam: the VobSub subtitles are now shown correctly! To have some fun, run mplayer with -vo xv and -nokeepaspect, and change size & shape while running; you can see that the subtitle's aspect doesn't change. Kristof ps0. It's a real pain to try to work on a codebase, and put my changes into seperate patches, when they depend on other two pending patches of mine.. ps1. My pending packages now (*: included here) * a0_positioning-fix-and-cleanup.patch * a1_scaling.patch a2_horizontal_alignment.patch b0_crop_horizontally_too.patch b1_black_box_bg.patch d_calculate_alpha_efficiently.patch * o0_aspect_framework.patch * o1_aspect_libvo_x11_xv.patch * o2_aspect_spu_subs
Csillag Kristof writes:
ps0. It's a real pain to try to work on a codebase, and put my changes into seperate patches, when they depend on other two pending patches of mine..
The problem is that all of the subtitle code is rather unmaintained, so it's hard to find someone to review your patches and apply them. If you intend to stick around for the long run you may be a good candidate for maintaining the subtitle code yourself. You should come to #mplayerdev one of these days and try to coax some of the devs you find there into commenting on and eventually applying your patches. Diego
On Mon, Jan 24, 2005 at 09:37:30AM +0100, Diego Biurrun wrote:
Csillag Kristof writes:
ps0. It's a real pain to try to work on a codebase, and put my changes into seperate patches, when they depend on other two pending patches of mine..
The problem is that all of the subtitle code is rather unmaintained, so it's hard to find someone to review your patches and apply them. If you intend to stick around for the long run you may be a good candidate for maintaining the subtitle code yourself.
You should come to #mplayerdev one of these days and try to coax some of the devs you find there into commenting on and eventually applying your patches.
From my perspective he seems to be making really good patches, but I'm not familiar with the code they modify. Perhaps one of us who uses vobsubs should just apply them and test and see if everything works ok. (I almost never use vobsubs though..)
Rich
2005-01-24, h keltezéssel 10.29-kor D Richard Felker III ezt írta: > From my perspective he seems to be making really good patches, but I'm > not familiar with the code they modify. Perhaps one of us who uses > vobsubs should just apply them and test and see if everything works > ok. That would be nice. * * * Would it make your task more difficult if I united some of my patches? It would be much more easy for me to maintain them (keep them compatible with each other) then. > (I almost never use vobsubs though..) 1. Don't you have any DVD-s lying around? :) 2. The latest thing, the OSD aspect-ratio work, once I finish it for text subtitles and possibly other OSD elements, will be much easier to test. Kristof
Hi, On Tue, Jan 25, 2005 at 01:29:58AM +0100, Csillag Kristof wrote:
2005-01-24, h keltezéssel 10.29-kor D Richard Felker III ezt írta:
From my perspective he seems to be making really good patches, but I'm not familiar with the code they modify. Perhaps one of us who uses vobsubs should just apply them and test and see if everything works ok.
2. The latest thing, the OSD aspect-ratio work, once I finish it for text subtitles and possibly other OSD elements, will be much easier to test.
Could you test with -vo gl, too? it uses a very different OSD code that did not have these problems from the beginning... I designed it like that, though you can switch the behaviour with the scaled-osd suboption. Greetings, Reimar Döffinger
2005-01-25, k keltezéssel 10.29-kor Reimar =?UTF8?Q?D=F6ffinger?= ezt írta:
Hi, On Tue, Jan 25, 2005 at 01:29:58AM +0100, Csillag Kristof wrote:
2005-01-24, h keltezéssel 10.29-kor D Richard Felker III ezt írta:
From my perspective he seems to be making really good patches, but I'm not familiar with the code they modify. Perhaps one of us who uses vobsubs should just apply them and test and see if everything works ok.
2. The latest thing, the OSD aspect-ratio work, once I finish it for text subtitles and possibly other OSD elements, will be much easier to test.
Could you test with -vo gl, too? it uses a very different OSD code that did not have these problems from the beginning... I designed it like that, though you can switch the behaviour with the scaled-osd suboption. Could you please clarify what's the relationship between -vo gl and -vo gl2?
Anyway, I will look at it this night. (Right now I must to my best trying to avoid failing my computer graphics exam, starting about one hour from new. Kind of funny, isn't it? :) Kristof
_______________________________________________ MPlayer-dev-eng mailing list MPlayer-dev-eng@mplayerhq.hu http://mplayerhq.hu/mailman/listinfo/mplayer-dev-eng
-- Csillag Kristof <fenwick@freemail.hu>
Hi,
Could you test with -vo gl, too? it uses a very different OSD code that did not have these problems from the beginning... I designed it like that, though you can switch the behaviour with the scaled-osd suboption. Could you please clarify what's the relationship between -vo gl and -vo gl2?
gl2 can use multiple textures to display the image (in case your GPU doesn't support large textures) and had aspect and OSD support since quite a long time. But it is a lot of code and quite a mess, so when I wanted to add some new features I added them to gl - so at the moment gl2 is only supposed to be used when gl doesn't work (old hardware or windows). Greetings, Reimar D?ffinger
2005-01-24, h keltezéssel 09.37-kor Diego Biurrun ezt írta: > Csillag Kristof writes: > > ps0. It's a real pain to try to work on a codebase, and put my changes > > into seperate patches, when they depend on other two pending patches of > > mine.. > > The problem is that all of the subtitle code is rather unmaintained, > so it's hard to find someone to review your patches and apply them. > If you intend to stick around for the long run you may be a good > candidate for maintaining the subtitle code yourself. Well, I'm not goint to either - stop using computers (...but who known, when "Trusted Computing" makes it way to me, I might consider it.) - stop using GNU/Linux - stop using MPlayer - stop contributing to projects that I find useful ...so, i guess one can say that I intend to stich around for the long run. But, the amount of time I can devote to MPlayer may vary; it depends on many other factors in my life. > You should come to #mplayerdev one of these days and try to coax some > of the devs you find there into commenting on and eventually applying > your patches. I will probably do so after I finished my exams. (2 more weeks at maximum.) Kristof -- Csillag Kristof <fenwick@freemail.hu>
2005-01-24, h keltezéssel 05.45-kor Csillag Kristof ezt írta:
2005-01-23, v keltezéssel 12.06-kor D Richard Felker III ezt írta:
I vote for option 1. MPlayer already has too many bad hacks with global vars. OK.
So, here we go. [...] Here come the patches: ...and more patches. :)
o3_aspect_text_subs_and_osd.patch - aspect rate support for OSD elements and TEXT SUBTITLES. Depends on the o0 patch, doesn't make sense without the o1 patch. (I have sent them yesterday.) This patch makes text subtitls and OSD elements use the aspect rate information, if available. Notes: 1. It only works with fonts handled by FreeType. (The aspect rate information is used to calculate the dimensions of the fonts we ask freetype to prepare for us.). 2. Since until so far I'v only modified vo_x11 and vo_xv to support the new aspect rate framework (that is, to pass the aspect rate information to the OSD layer), currently only this two VO drivers support this feature. (See the o1 patch; it's about one line for VO drivers to fix this.) You can test it with mplayer -vo xv -nokeepaspect -font <whatever.ttf> -osdlevel 3 <movie> ...and play around your window; the osd counter's aspect rate won't be demaged. The same goes for the subtitles. * * * 2005-01-22, szo keltezéssel 13.08-kor D Richard Felker III ezt írta:
BTW could you make the same changes for rendering text subs? I wanted to do that over a year ago but never figured out how. Right now, text subs are rendered horribly wrong in any movie without square pixels.
Rich, is this what you wanted? Kristof -- Csillag Kristof <fenwick@freemail.hu>
On Sun, Jan 23, 2005 at 02:36:20PM +0100, Csillag Kristof wrote:
2005-01-22, szo keltezéssel 13.08-kor D Richard Felker III ezt írta:
[...] Great! Well, not so great, since it still does not restore the proper aspect rate. [...] the old method is distorted by cropping/expanding, and my new method is distorted by scaling.
There should be a proper way; I will look at it again tomorrow. The problem is that we render the subtitles _before_ the scaling up at
2005-01-23, v keltezéssel 06.56-kor Csillag Kristof ezt írta: playback time, and we have no idea about what size (or more importantly) aspect will it be scaled to. Of course the information is available somewhere in mplayer's dataspace, but the vobsub rendering module is obviously not aware of it.
Yes it is. The stage at which subs are renderred (either vf_expand or the vo) knows the aspect from d_width/d_height. It just has to pass the aspect info along to the sub rendering modules. Rich
Upon od15 request, here's a resent of a patch that got some attention a while ago, but didn't get committed ---------- Forwarded message ---------- From: Csillag Kristof <fenwick@freemail.hu> Date: Jan 22, 2005 7:39 AM Subject: [MPlayer-dev-eng] [PATCH] vobsub: keep aspect ratio To: mplayer-dev-eng@mplayerhq.hu Hi there! One more little thing: When we rip a movie, black bars are often removed from the top and the bottom of the original picture. This is OK, but it means that the aspect ratio of the movie is changed. ON the other side, when we dump a VOBsub subtitle, no cropping takes place, so it's aspect rate will match the original (un-cropped) movie's. So, when we display a subtitle with the cropped movie, and rescale the vobsub's frame to match the movie's sizes, we are distorting the subtitle's aspect ratio. (Typically, we get shorter letters.) This makes reading the text harder. * * * So, I added the option "-spu-keep-aspect". If it is switched on, the VOBsub's original aspect ratio is used to display it. If it's off (default), the aspect ratio of the movie is applied to the subtitles. See the attached patch. (I updated the man page, too.) (Note: this patch depends on the following two pending patches of mine: a0_positioning-fix-and-cleanup.patch, a1_scaling.patch) I uploaded a sample file here: http://rht.bme.hu/~lunkwill/computer/mplayer/aspect-demo.mkv The default "mplayer -slang eng aspect-demo.mkv" gives this: http://rht.bme.hu/~lunkwill/computer/mplayer/without-keep-aspect.png "mplayer -slang eng aspect-demo.mkv -spu-keep-aspect" gives this: http://rht.bme.hu/~lunkwill/computer/mplayer/with-keep-aspect.png * * * What do you think? IMHO the subtitles look much better this way. Shouldn't this be the default behavior? -- Csillag Kristof <fenwick@freemail.hu> _______________________________________________ MPlayer-dev-eng mailing list MPlayer-dev-eng@mplayerhq.hu http://mplayerhq.hu/mailman/listinfo/mplayer-dev-eng -- Reading doesn't hurt, really! -- Dominik 'Rathann' Mierzejewski
participants (6)
-
Csillag Kristof -
D Richard Felker III -
Diego Biurrun -
Dominik 'Rathann' Mierzejewski -
Guillaume Poirier -
Reimar D�ffinger