High-10 Video Issues

[lachs0r]

cyberbeing:
That’s probably just slightly different margins/aspect ratio due to scaling, and the line break could be caused by how that font scales at smaller sizes.

LLStarks:
Known Gallium/Mesa bug. Free drivers on Linux are still shit, no big news there.

[cyberbeing]

I took a closer look and it seems this is actually a font spacing issue rather than a font size issue. The font rendered at 100% has less spacing than the font rendered at 50%.

When rendered at 720x540 (50%) there seems to be an extra pixel worth of spacing between each character compared to my 1440x1080 screenshot resized to 720x540. Add all those extra spacing pixels up and it must hit the margins that forces the line to wrap.

Are you able to fix libass to compensate for this, or is it out of your control? It seems like it probably should, or everything will end up shifted by a few pixels when resizing the video using the gl renderer. I guess this is a limitation of rendering subs after resizing (similar to the MPC-HC internal subtitle renderer), but optimally you would want everything positioned identically relative to the size of the video frame and be resolution independent.

[MagicaLideaL]

Thank you very much Green². I got visual error and my smplayer crashes whenever i put directx (fast), guess i have to stick with direct3.
Also, it is kinda hard to fast forward video due to the inaccurate seek bar.

[cyberbeing]

Originally Posted by MagicaLideaL

Also, it is kinda hard to fast forward video due to the inaccurate seek bar.

I've noticed this as well. Usually seeking works horribly and jumps all over the place when you click on the timeline, but occasionally if I fiddle with things and reload seeking will suddenly work perfectly, both quickly and accurately. I would scratch this off as a failing of the SMPlayer GUI and its communications with MPlayer2, but it is extremely annoying. Something for the future that will need to be solved either in SMPlayer or a new GUI before MPlayer2 becomes user friendly enough for more widespread use on Windows.

[lachs0r]

Yes, SMPlayer is a complete pile of junk judging by its code.
Communication with MPlayer/mplayer2 over the old MPlayer slave protocol is incredibly awkward though, that’s why a new IPC mechanism is planned. Whenever that will be done, new frontends will have to be written (several people, including me, tried to fix some of SMPlayer’s mess already; it turns out to be easier to just start from scratch).

Also, you could try this SMPlayer build. Maybe it fixes a few issues with the seek bar, but it also displays chapter names in the menu and starts a little faster (static linking ho). Just unpack it somewhere and place mplayer2 as mplayer.exe in its mplayer subdirectory as usual (create if it doesn’t exist).

Note that this build was just a quick experiment to see how it works.

[cyberbeing]

That build works well with 'Absolute seeking' enabled. 'Relative seeking' is still borked.

It seems you somehow broke passing of full pathnames though, so that SMPlayer build doesn't work at all unless you enable 'Pass short filenames (8+3) to MPlayer'.

Back to the subject of libass. It seems to have drastically different spacing and/or font weights compared to VSFilter at times. Is that just the nature of libass?

Spoiler for VSFilter:

Spoiler for MPlayer2:

[lachs0r]

Originally Posted by cyberbeing

That build works well with 'Absolute seeking' enabled. 'Relative seeking' is still borked.

Relative seeking is a hack for old MPlayer versions. Don’t use it.

Originally Posted by cyberbeing

It seems you somehow broke passing of full pathnames though, so that SMPlayer build doesn't work at all unless you enable 'Pass short filenames (8+3) to MPlayer'.

I didn’t break that. You probably just passed a filename that contained Unicode characters.
Most (if not all) other Unicode-compatible operating systems use UTF-8 for everything. Windows however uses UTF-16 (UCS-2 in older versions). That breaks Unicode file names. Using 8.3 names is a workaround.
This will be fixed sometime, probably by an UTF-16<->UTF-8 wrapper.

Originally Posted by cyberbeing

Back to the subject of libass. It seems to have drastically different spacing and/or font weights compared to VSFilter at times. Is that just the nature of libass?

Spoiler for VSFilter:

Spoiler for MPlayer2:

• libass supports true font kerning and other advanced font features. VSFilter does not. It used to be disabled by default (and is still supposed to be), but that’s a “problem” with Harfbuzz.
• That font probably doesn’t even have a Bold variant. Both libass and VSFilter use a “fake bold” form in that case; libass just doesn’t embolden it as much as VSFilter. Blame fagsubbers for always picking bad fonts. Alterntatively, blame Aegisub’s font collector for not getting font families right.

[cyberbeing]

Originally Posted by lachs0r

I didn’t break that. You probably just passed a filename that contained Unicode characters.

Heh, for some reason I've never run into that was a problem before, but that was indeed the issue. A side-effect of this being one of the few seasons that has a show with a unicode character in the english title (Fate／Zero).

Originally Posted by lachs0r

• libass supports true font kerning and other advanced font features. VSFilter does not. It used to be disabled by default (and is still supposed to be), but that’s a “problem” with Harfbuzz.
• That font probably doesn’t even have a Bold variant. Both libass and VSFilter use a “fake bold” form in that case; libass just doesn’t embolden it as much as VSFilter. Blame fagsubbers for always picking bad fonts. Alterntatively, blame Aegisub’s font collector for not getting font families right.

Bold actually isn't specified in the script at all. In this case it actually seems to be two incorrectly named fonts in a font family used by both UTW and Commie, Profile-Regular & Profile-Medium, and scripts which just specify 'Profile'.

The offending fonts: http://www.mediafire.com/?zpvr698cu7m87lc

Font Name: Profile-Regular
Font Family: Profile
Font Sub-Family: Regular

Font Name: Profile-Medium
Font Family: Profile
Font Sub-Family: Regular

I think you can see the problem, when only 'Profile', the font family which is shared by both fonts, is specified in the script and both are 'Regular'. The two fonts would be seen as duplicates.

[mkv] Attachment: Profile-Medium.otf, application/x-truetype-font, 36580 bytes
[mkv] Attachment: Profile-Regular.otf, application/x-truetype-font, 36388 bytes

VSFilter is using Profile-Medium and Libass is doing the opposite and using Profile-Regular. In this case, Profile-Medium was obviously the font intended to be used, but with no way of knowing that from the script alone, I would have to side with libass for using Profile-Regular since 'Bold' wasn't specified. Maybe yet another switch should be added to MPlayer2 to make it mimic VSFilter behavior with duplicate fonts which aren't actually duplicates...

All in all this is just stupidity by Commie, and even greater stupidity by UTW for copying Commie's stupidity when using this font. Only one of the two fonts needed to be muxed into the mkv, since they are not linked to each other, and both have a full set of glyphs. If I remove Profile-Regular.otf and leave only Profile-Medium.otf muxed, it works correctly in both VSFilter and Libass. Same font, same problem in both screenshots.

Originally Posted by lachs0r

Blame fagsubbers for always picking bad fonts.

QFT

[lachs0r]

Maybe yet another switch should be added to MPlayer2 to make it mimic VSFilter behavior with duplicate fonts which aren't actually duplicates...

That is not trivial but might change in the future when libass can work properly on Windows without fontconfig. Out of curiosity, does it do the same thing with my -nofontconfig builds?

[cyberbeing]

The -nofontconfig builds do the same thing as the regular builds.

[Kallen4life]

not sure if this is the right place to ask, but .. am I correct in understanding that currently 10-bit video playback does not support DXVA (hw GPU accel for video playback - for .mkv's) at all ? Because all my 10-bit files are playing w/o DXVA (and with a higher CPU usage)


I use CCCP if it matters .. would I be able to get DXVA for 10-bit using something else atm ?

[sneaker]

Correct, there is currently no solution (including DXVA) for hardware acceleration of 10bit video. The decoders on the current hardware do not support it, and with anime being a niche market don't hold your breath for upcoming solutions.

[Claymore_Obsessed]

on Mac OS, how, the situation?

MP OSX Extended and Perian aren't working with 10bit videos..

[pigoz]

Originally Posted by Claymore_Obsessed

on Mac OS, how, the situation?

MP OSX Extended and Perian aren't working with 10bit videos..

http://coalgirls.wakku.to/?page_id=4635

[lachs0r]

Originally Posted by cyberbeing

It seems you somehow broke passing of full pathnames though, so that SMPlayer build doesn't work at all unless you enable 'Pass short filenames (8+3) to MPlayer'.

My builds now have Unicode support.
I also recommend using SMplayer2 instead of SMPlayer. I forked it, dropped support for ancient MPlayer versions and fixed/added a few other things (list of changes is here).

Here's an installer that downloads the most recent Windows builds of SMPlayer2 and mplayer2. It installs them in your user directory (it’s pretty similar to Chromium’s mini_installer.exe) and places a shortcut to itself in the start menu (it also works as updater) on first run. No uninstall routine yet (I was lazy), but it only requires deleting a folder and three shortcuts anyway.

[cyberbeing]

Yeah I saw that, and I've been using SMPlayer2 for a few days already. My main gripe with SMPlayer is that the subtitle sections in particular are designed around MPlayer defaults and doesn't mingle well with MPlayer2 defaults.

Requests:

Add an Auto setting for 'Threads for Decoding' to let MPlayer2 set -lavdopts threads on its own, and make '1' actually set threads to 1.

Add 'Use MPlayer2 subtitle defaults' option to the Subtitle section to prevent SMPlayer from passing subtitle or libass related parameters from that section to MPlayer2.

Add keyboard shortcut entry for --ass-vsfilter-aspect-compat (defaults to 'V' in MPlayer2).

Add an option to always dither 10-bit to YV12 with the GL renderer (-vf format=YV12)

Fix the DSound device detection in the Audio Output drop-down box so it matches SMPlayer behavior

Bundle an up-to-date set of *.conf files for MPlayer2 and place them in the ./mplayer directory.

Bundle an up-to-date fontconfig configuration files (similar to these) for MPlayer2 to ./fonts (without it MPlayer2's font choices are horrible)

Bundle a readable version of the MPlayer2 manual, either an HTML version of this or TXT version of this from tmp_manpage.

[lachs0r]

Originally Posted by cyberbeing

Add an option to always dither 10-bit to YV12 (-vf format=YV12)

Why? I see no reason for doing that other than broken graphics drivers, and that should be worked around elsewhere.

Originally Posted by cyberbeing

(without it MPlayer2's font choices are horrible)

Care to elaborate? If anything, I’d rather want to fix fontconfig’s default behavior than bundle tons of XML files with mplayer2.

I’ll take care of the rest soon though, thanks for the suggestions.

[cyberbeing]

Originally Posted by lachs0r

Why? I see no reason for doing that other than broken graphics drivers, and that should be worked around elsewhere.

Quality: I as far as I can tell 99% GPUs today don't dither 10-bit OpenGL output and probably never will, and they can't output 10-bit to capable displays either. With an 8-bit display, you really want the final output dithered for maximum quality.

Speed: Dithered 10-bit to 8-bit output uses less CPU time and renders faster than outputting 10-bit directly.

In many ways I don't think MPlayer2 should even be outputting 10-bit OpenGL by default (at least on Windows), as it just doesn't offer any advantages at present.
The more sensible way to do it is just to defaulting to 8-bit OpenGL output, and adding an option to enable 10-bit or 16-bit output.

Originally Posted by lachs0r

Care to elaborate? If anything, I’d rather want to fix fontconfig’s default behavior than bundle tons of XML files with mplayer2.

When a Glyph is missing, it doesn't use a sensible replacement font. Even with the config files, the fallback behavior doesn't match VSFilter exactly, but at least it picked a standard English font.

Spoiler for comparison:

Missing apostrophe glyph
_____

VSFilter
Fallback font = ???
_____

With fontconfig files
Fallback font = Verdana
_____

Without fontconfig files
Fallback font = 細明體_HKSCS-ExtB <-- seems like it just picked a random completely impractical font
MPlayer2 complains: [ass] No usable fontconfig configuration file found, using fallback.

Note: For the record, your nofontconfig builds behave better without font config files than the normal builds (with this sample)
_____

The other good reason to ship *.conf files for everything, is in case someone actually wanted to modify MPlayer2 behavior in some advanced way.

[lachs0r]

Originally Posted by cyberbeing

Quality: I as far as I can tell 99% GPUs today don't dither 10-bit OpenGL output and probably never will, and they can't output 10-bit to capable displays either. With an 8-bit display, you really want the final output dithered for maximum quality.

NVIDIA drivers do, at least on Linux. Didn’t have a chance to check Windows drivers yet.

Originally Posted by cyberbeing

Speed: Dithered 10-bit to 8-bit output uses less CPU time and renders faster than outputting 10-bit directly.

I call bullshit. With proper drivers, it’s much faster to do on the GPU. For example, it’s impossible to even play 1080p 444p10 at reasonable frame rates without swscale stalling everything else, while with gl it works (and looks) fine and consumes considerably less CPU time.

Originally Posted by cyberbeing

In many ways I don't think MPlayer2 should even be outputting 10-bit OpenGL by default (at least on Windows), as it just doesn't offer any advantages at present.
The more sensible way to do it is just to defaulting to 8-bit OpenGL output, and adding an option to enable 10-bit or 16-bit output.

Again, a driver issue. If your drivers are broken, it’s not mplayer2’s fault. It already has several workarounds for the ever broken ATI drivers in place, but I don’t want to add even more hacks. Just adding that filter or yuv=0 to the gl options yourself can’t be that hard, can it?
Besides, there’s some effort in writing a new OpenGL-based driver from scratch that will probably do better than the existing one. Don’t hold your breath yet though.


Regarding the font issue, fuck fagsubbers forever. I’ll see to it however.

[cyberbeing]

Originally Posted by lachs0r

I call bullshit. With proper drivers, it’s much faster to do on the GPU. For example, it’s impossible to even play 1080p 444p10 at reasonable frame rates without swscale stalling everything else, while with gl it works (and looks) fine and consumes considerably less CPU time.

Its the truth. With 10-bit 4:2:0, dithering to 8-bit is significantly faster, at least on all computers I've tested. The same holds true for directshow decoders as well. Outputting 10-bit 4:2:0 has a larger overhead than dithering to 8-bit 4:2:0.

Now I could easily believe that 10bit 4:4:4 to 444p10 is a massive improvement though, since swscale 10-bit conversions with anything but 4:2:0 are unusably slow. How often do I watch 10-bit 4:4:4 videos? Never. How often do I watch 10-bit 4:2:0 videos? Often. That would hold true for most everybody.

Originally Posted by lachs0r

Again, a driver issue. If your drivers are broken, it’s not mplayer2’s fault.
Besides, there’s some effort in writing a new OpenGL-based driver from scratch that will probably do better than the existing one. Don’t hold your breath yet though.

MPlayer2 defaulting to something which doesn't offer an overall advantage on Windows with any driver is MPlayer2's fault. It's half Microsoft fault for crappy high bitdepth support in Windows, and the other half that of GPU vendors who only support 10-bit output on professional Quadro & FirePro cards. If you have an 8-bit display there are zero reasons to output 10-bit 4:2:0 when dithering in software is faster and higher quality. I've yet to see hear or see proof from anybody using Windows that their GPU's actually was dithering, or that OpenGL 1.0 GL_Dither which MPlayer2 uses isn't horrible as far as dithering goes. I've also yet to hear of anybody successfully outputting 10-bit from MPlayer to a compatible 10-bit display over displayport on Windows either.

OpenGL 420p10
Stability: ++++
Quality: ++
Speed: +++

OpenGL 420p10->YV12
Stability: +++++
Quality: ++++
Speed: ++++

Direct3D 420p10->YV12
Stability: ++++
Quality: ++++
Speed: ++

Just because OpenGL 420p10 is relatively fast and stable with most drivers including my own NVIDIA and ATI cards, doesn't mean it has any advantages on Windows with common 10-bit 4:2:0 video.

Originally Posted by lachs0r

NVIDIA drivers do, at least on Linux. Didn’t have a chance to check Windows drivers yet.

I'd love to be proven wrong, and maybe that new OpenGL output driver you speak of would be the solution. As far as I can tell, everything on Windows has horrible support for 10-bit output. And from what I've heard, GPUs used on *nix have night and day better support for 10-bit output and high bitdepth textures in general, so that's a bad way to judge overall support. Please do test on Windows when you have a chance.

Originally Posted by lachs0r

Just adding that filter or yuv=0 to the gl options yourself can’t be that hard, can it?

How would setting YUV=0 (software YUV->RGB conversion) help me at all when my GPUs have no compatibility issues with 420p10 OpenGL? I think you are misunderstanding something.

You making any change in this area doesn't really affect my use of MPlayer2 at all, and that's not why I'm asking. It's extremely simple to add format=yv12 in SMPlayer under Video Filters to fit my needs perfectly. What's annoying is needing to tell everybody else to change all these settings and teach them what they do because MPlayer2 has less than optimal default settings for the GL renderer. In many ways I'm thankful you are defaulting to the D3D renderer in your builds, as it makes MPlayer2 easier to recommend.