Implement 'expand-to-fit-display-resolution/aspect-auto-detection' option in "expand" filter

[v-fox]

Expand filter is extremely useful to draw subtitles on borders in movies with shitty, super-wide aspect (most movies nowadays) on both 16/9 and 4/3 displays. But to do so one has to manually configure the aspect (like 'expand=::::16/9:') of display for filter, which creates this problem. In SMplayer they use some kind of internal calculation with command substitution and mpv/mplayer restart ON EVERY fullscreen in/out change which is very slow and ugly.
Real solution would be for mpv to have an option to always expand drawable black borders instead of just black borders. This also will help with #346

[ghost]

No. Use --ass-use-margins, which does exactly what you want. (And doing it in the expand filter won't help with #346 either, as far as I understand.

[v-fox]

No, it doesn't do what i want. I want to draw on black borders that are already there because of aspect differences (on 4/3 display with 16/9 video, for example), i DON'T want to add any more borders. --ass-use-margins doesn't change anything by itself and with sub filter it adds even more useless black. Only expand helps.

[ghost]

Don't use the sub filter, then. It's not needed. I don't understand your problem; it works out of the box here. The only things that could break it are if you use bitmap subs, or if you use --vo=xv.

[v-fox]

I use SMplayer GUI that recently decided to use mpv by default. For example, if i take a video with 2.4 aspect and open it on 16/9(1.7) screen, remove the manually added expand filter, command option for mpv, made by smplayer will be like this:

mpv --no-config --no-quiet --terminal --no-msg-color --slave-broken --no-fs --vd-lavc-threads=7 --hwdec=no --sub-auto=fuzzy --vo=opengl-hq:fbo-format=rgba32f,icc-profile-auto --ao=jack:std-channel-layout=waveext,port=jamin --autosync=1 --mc=0.1 --no-input-default-bindings --input-x11-keyboard=no --no-input-cursor --cursor-autohide=no --no-keepaspect --wid=90177557 --monitorpixelaspect=1 --osd-scale=1 --sub-ass --embeddedfonts --ass-line-spacing=0 --sub-scale=1 --ass-styles=/home/fox/.config/smplayer/styles.ass --sub-codepage=enca:ru:UTF-8 --vid=1 --aid=3 --sub-pos=100 --volume=100 --cache=5120 --osd-level=0 --index=default --vf-add=pp=[ac],hqdn3d --screenshot-template=cap_%F_%p_%02n --audio-channels=2 --af-add=drc=1 --af-add=scaletempo --ytdl --stop-screensaver --ass-use-margins

But subtitles are drawn on the picture and not borders. Only with --vf-add=expand=::::16/9:,pp=[ac],hqdn3d instead of --vf-add=pp=[ac],hqdn3d it draws on borders.

[ghost]

--no-keepaspect

Found your problem. This will stretch the video to the window size (completely ignoring anything about aspect ratios), which in no way can be what you want.

[v-fox]

Hm, i just tried without the SMplayer GUI and it indeed does work... maybe i should try it that way since smplayer puts a lot of unnecessary and obsolete options but distribution's users might not appreciate that.
SMplayer likes mpv, it forces it as hard dependency in newest version, but mpv doesn't answer with reciprocity.

[ghost]

since smplayer puts a lot of unnecessary and obsolete options

That is definitely true. Lots of MPlayer-cargo-culting here (and also unnecessarily touching defaults).

SMplayer likes mpv, it forces it as hard dependency in newest version, but mpv doesn't answer with reciprocity.

Really feels the other way around here. For example, smplayer doesn't use the preferred way how mpv is supposed to be used (either via libmpv, or at least via the IPC protocol). Instead, it goes out of the way to make mpv work like mplayer.

[v-fox]

Found your problem. This will stretch the video to the window size (completely ignoring anything about aspect ratios), which in no way can be what you want.

Yes, indeed. I tried to add --keepaspect but it does not seem to overide it and SMplayer seems to be forcing --no-keepaspect without an option to disable it.

Really feels the other way around here. For example, smplayer doesn't use the preferred way how mpv is supposed to be used.

It does look that way but:

1. https://build.opensuse.org/package/view_file/KDE:Extra/smplayer/smplayer.spec?expand=1
   Requires: mpv >= 0.6.2
   http://smplayer.sourceforge.net/en/mpv
2. There are quite a few options in menus that "require mplayer2". Author seem to be very insistant on using mplayer2 when it came out and now mpv.

SMplayer should be more closely tied to mpv but as of now i don't know what to do then. It's either further abuse of expand filter or ditching of smplayer, both are not solutions. And there is no better mpv GUI, is there ?

[ghost]

It's either further abuse of expand filter or ditching of smplayer, both are not solutions.

Why not make smplayer fix it?

[v-fox]

Why not make smplayer fix it?

I think it will be a lot of work for its developer, potentially with writing many things from scratch and losing compatibility with Mplayer. Even i thinking about just permanently going for Bomi... but even it uses its own build of mpv instead of libmpv.

[ghost]

Using the expand filter for this is a deadend. I don't know why smplayer insist on doing things this way (though I don't know what exactly smplayer is doing), but it really shouldn't be hard to do the right thing. As I see it, smplayer tries tons of tricky things that are not the "proper" way, which of course breaks certain things.

[v-fox]

Using the expand filter for this is a deadend. I don't know why smplayer insist on doing things this way (though I don't know what exactly smplayer is doing), but it really shouldn't be hard to do the right thing. As I see it, smplayer tries tons of tricky things that are not the "proper" way, which of course breaks certain things.

SMplayer also uses 'expand' in a worse way possible: restarting mplayer completely with different settings on each windowed/fullscreen status change ! So i had to disable its 'expand' handling and put my own options. I used it pretty much only as quick subtitle/audio selector & easy seeking menu with most of command line options customized.
This is why I think that SMplayer's author is really bend on having Mplayer compatibility. But mplayer is developed pretty badly and doesn't have proper releases. So, that leaves only bomi/mpv, VLC/ffmpeg (poor UI with tons of inconsequential, incomplete or misused options) and GStreamer (no complete player yet) as user options.

However... mpv recently got 'blend-subtitles' option but its effect is restricted on drawing subtitles only directly on video. Surely, 'expand' would help to avoid that deficiency, no ?

[ghost]

However... mpv recently got 'blend-subtitles' option but its effect is restricted on drawing subtitles only directly on video. Surely, 'expand' would help to avoid that deficiency, no ?

It's like you didn't read any of my posts. Doesn't --ass-use-margins (and in newer releases, --sub-use-margins for normal text subtitles) do exactly what you want?

The only exception I can think of are image subtitles, or ASS subtitles that use explicit positioning even for normal text.

[v-fox]

It's like you didn't read any of my posts. Doesn't --ass-use-margins (and in newer releases, --sub-use-margins for normal text subtitles) do exactly what you want?

And what it has to do with 'blend-subtitles' ? man mpv:
"The downside of enabling this is that it restricts subtitles to the visible portion of the video, so you can't have subtitles exist in the black margins below a video (for example)."

[ghost]

Nothing. You brought it up. The blend-subtitles suboption (which is not default) merely breaks that feature.

[v-fox]

Nothing. You brought it up. The blend-subtitles suboption (which is not default) merely breaks that feature.

Exactly. First 'keep-aspect', then 'blend-subtitles'. Too much "breaks that feature" while doesn't break 'expand'. So, it's a "pick your poison choice": 'expand' doesn't have aspect ratio detection logic and '???-use-margins' is easily broken (and it seems you also may need '--ass-force-margins').

[ghost]

No, smplayer breaks it. Simple as that. Complain to smplayer.

[haasn]

Incidentally, it would be possible in principle to fix blend-subtitles + sub-use-margins. It would require allocating the intermediate video textures at the output size instead and clearing them with black first + drawing only the portions we need.

It's extra logic and makes the code more complicated, though, so I figured I wouldn't bother implementing it unless somebody really complained.

[v-fox]

No, smplayer breaks it. Simple as that. Complain to smplayer.

Still I hardly see how the "right thing" can be so much easily broken than the "deadend".

Incidentally, it would be possible in principle to fix blend-subtitles + sub-use-margins. It would require allocating the intermediate video textures at the output size instead and clearing them with black first + drawing only the portions we need.

It's extra logic and makes the code more complicated, though, so I figured I wouldn't bother implementing it unless somebody really complained.

Cool ! Because drawing letters over graphic not only just hard to read but also is wasteful, since you can't see part of the video thus should be avoided at all costs. I assume it tricky because of the need to avoid inadvertently modifying the black space along with subtitles too ? I will not complain much about that, but still this feature feels incomplete if there is a trade involved: no margins versus no blending.

[ghost]

Still I hardly see how the "right thing" can be so much easily broken than the "deadend".

What? Where is it easily broken? What are you even talking about?

It's not our fault that smplayer goes out of the way to break mpv by default.

[ghost]

Cool ! Because drawing letters over graphic not only just hard to read but also is wasteful, since you can't see part of the video thus should be avoided at all costs. I assume it tricky because of the need to avoid inadvertently modifying the black space along with subtitles too ? I will not complain much about that, but still this feature feels incomplete if there is a trade involved: no margins versus no blending.

Also, what you seem to refuse to understand... blend-subtitles is NOT THE DEFAULT. THERE IS NO FUCKING PROBLEM AT ALL BY DEFAULT. I hope this was loud enough. Now please go on complaining to smplayer for breaking our stuff big time.

[v-fox]

What? Where is it easily broken? What are you even talking about?
It's not our fault that smplayer goes out of the way to break mpv by default.

It seems that you trying to reinforce your own belief than to communicate something.

Also, what you seem to refuse to understand... blend-subtitles is NOT THE DEFAULT. THERE IS NO FUCKING PROBLEM AT ALL BY DEFAULT. I hope this was loud enough. Now please go on complaining to smplayer for breaking our stuff big time.

U-huh. And now we come to the idea that all the countless features of mpv are meaningless because they are not default. With the complete breakdown no less. You know when there is truly no problems with software ? When no one using it. So why bother ? Remove all options !
What else ? Maybe anything that does not concern you personally doesn't exist ?

And here I thought that mpv is an advanced mplayer fork (that doesn't have its deficiencies but surpasses its possibilities) and the world's champion of media playback.

[ghost]

Well, you haven't made any sense yet (other than you're complaining about smplayer's bad support?), so I guess I don't have a good answer.

If you want something that works well in smplayer, use mplayer. Because smplayer was written for it.

[v-fox]

Yeah, you don't have a good answer.
I want something that works great, especially in rendering subtitles. Let's leave it at that.

And, as I've mentioned, I'll be getting rid of smplayer for bomi, for now.
But OSD in pure mpv is quite nice, actually. Hard to use thought. If all its controls would be more accessible (personally, I like the concept of GUI controls that program called FastStone Image Viewer uses in fullscreen. bomi has a taste of that: different elements pop up on mouse proximity to different parts of the screen) and all options are exposed, there wouldn't be a need for third-party GUIs at all.

[ghost]

Yeah, you don't have a good answer.

Can't help it if you are too stupid to read.

[v-fox]

Can't help it if you are too stupid to read.

Now, just go kindly fuck yourself.

[ghost]

Excuse me?

My statement was quite neutral and objective. Let me remind you that this is the mpv bug tracker,. not the smplayer one.