High-10 Video Issues

[Green²]

Originally Posted by cyberbeing

Advanced->Options for MPlayer

Video Filter: format=yv12 (important, forces 10bit to be dithered, faster, avoids compatibility problems some cards have with 10bit OpenGL output)

This is what corrected the video corruption that I had been observing on the ATI4830. Without that setting, a generic gl configuration would result in something such as , and was why I didn't recommend the use of the gl renderer. The gl renderer performance appears to be around the same as directx renderer I think, but someone with a weaker CPU than mine (AMD X2 7750) will need to test if that is the case.

Edit:
No change in CPU usage from what I had seen of between the directx & gl renderer. Using gl renderer with the tweaked settings would certainly be preferred for the better quality subtitles.

[cyberbeing]

As a recent thing, for anybody still on WinXP (in particular) having issues with VSFilter being too slow and don't like MPlayer, keep your eye on the xy-vsfilter project. The Chinese developer has made some very nice progress making the speed of VSFilter 2.39.5.3 comparable to the threaded-vsfilter fork (which only supports Vista and above unlike xy-vsfilter), even though xy-vsfilter isn't really threaded and had the standard pre-buffer code removed.

Originally Posted by xy-vsfilter dev

What I've done in this mod:

1. Disable pre-buffering. It's to difficult to test.

2. Improve performance.

1) Alpha blending on dirty area only. Instead of using a rectangle to represent dirty area on a subpic as Vsfilter, I using a list of rectangles. Hence in cases like two subtitle lines one on the top and one on the bottom, alpha blending of the subpic and video frame can be done on a relatively small area.

2) No full subpic rgb to yuv conversion. Subpics are drawn in yuv/rgb directly, unlike vsfilter which always draw subpics using rgb and do yuv conversion afterwards (if necessary), so the overhead of rgb to yuv conversion is avoided.

3) Cache of intermediate data. Crucial to speed up rendering of animated effect. But the downside is memory load increased.

4) More efficient blur code (borrowed from libass).

On my system (win7+i5-2410+2G ram), simple test shows that it outperforms both threaded-vsfilter and mpc-hc built-in sub renderer.

3. Speed up when loading big ass file (with tens of thousands of line).

4. BT709 support.

5. Most Recently Used - MRU caching (experimental)

Some may notice a couple of well-known VSFilter issues/limitations people have long said need fixing are in that list. After any bugs are found and worked out [Edit: If you find a regression from VSFilter 2.39 report it here], it will likely turn into a nice option for people who prefer to stick with MPC-HC|vsfilter instead of MPlayer|libass for fast subtitle rendering. He has also stated interest in creating a libass-based directshow filter at some point (wishful thinking?), but seems content with just making VSFilter 2.39.5.3 faster for the time being.

Originally Posted by Green²

This is what corrected the video corruption that I had been observing on the ATI4830...

That seems to be a known issue with 10bit OpenGL output on some ATI/AMD cards. MPlayer only supports and defaults to 10bit output with OpenGL, so you aren't really loosing anything by forcing dithering to 8bit, since it's done by default with all other renderers. One thing nice about the GL renderer and MPlayer in general, are that both are configurable enough to workaround most issues people run into. I will say that anybody unlucky enough to need to use the ati-hack to get acceptable performance of the GL render, is probably better off sticking with directx/direct3d. The direct3d renderer is certainly the most dummy-proof for both users and hardware on Windows, but not necessarily preferable if the gl renderer is working nominally.

[Starks]

Does a coherent trunk repo for vsfilter still exist?

I've long lost track of its development and the relevance of newer versions like 2.40.

[cyberbeing]

VSFilter 2.39.5.x repository is on guliverkli2, and is the version bundled and recommended by Aegisub. Guliverkli2 is no longer developed. This is considered the stable version of VSFilter. Pre-buffering in 2.39.5.x doesn't support animation.

xy-VSFilter is a 2.39.5.x fork for performance. Pre-buffering was removed, but caching and other enhancements were added in its place.

VSFilter 2.40.x repository is on MPC-HC but isn't actually stock VSFilter but rather VSFilter Mod + slight changes and bug fixes. Even though the MPC-HC project is active, VSFilter has no devs working on it (except for the occasional minor bug-fix). Pre-buffering in 2.40.x supports animation, but it sometimes causes flickering. Use of VSFilter Mod features in Aegisub should be avoided whenever possible for legacy compatibility when softsubbing. As of 2010, CCCP started bundling this version.

threaded-VSFilter is a 2.40.x fork for performance focused on multi-threading and pre-buffering. Only supports Vista and newer.

[sa547]

Okay, I have a suggestion: is it okay if this thread be pinned (or a Q&A thread made) so that anyone can know how to play High-10 encoded videos?

[dorn]

Seems a lot of groups are switching to 10-bit so I went to update stuff. I installed the newest ffdshow tryouts and made sure MPC-HC was using it. There are a lot of crazy artifacts though that are clearly from the 10 bit not working.

So I went and downloaded the latest VLC to see if for some odd reason it worked and of course no luck (didn't expect much since it's also ffdshow).

So I'm stumped? I hear CCCP works but no way can I install a codec package to screw over all my other carefully set filters. Where is the actual codec CCCP is supposedly using? Googling is failing me hard.

[NoSanninWa]

Originally Posted by dorn

I hear CCCP works but no way can I install a codec package to screw over all my other carefully set filters. Where is the actual codec CCCP is supposedly using?

What CCCP installs and why it installs that. You can customize the installation to install only the components you desire if you really don't want to believe that CCCP is designed for maximum compatibility of all components.

[Luurah]

I tried experimenting with hi10p with my Daltanious subs for kicks. I managed to get it encoded with hi10p, but I think I'm doing something wrong. The original file (no audio) had approximately 179MB. When I finally encoded the video, the file size was 185MB.

Is this normal? I thought it would compress the video file to a smaller size compared to the H.264 video profile I've been using thus far. This is what i used in the batch file I made that was supposed to compress the video from to hi10p:

x264-10bit -o dalt01-hi10p.avi dalt01.avi --crf 20

I wish I could do this in AVIDemux, but I haven't found any documentation on how to encode hi10p video files in that program. (I'm not sure if AVIDemux can work with hi10p yet, but I heard it does.)

Anyway... point is... am I doing something wrong? If so, what can I do to make it right? (Or did I misread something in the first place?)

[Starks]

Originally Posted by cyberbeing

VSFilter 2.39.5.x repository is on guliverkli2, and is the version bundled and recommended by Aegisub. Guliverkli2 is no longer developed. This is considered the stable version of VSFilter. Pre-buffering in 2.39.5.x doesn't support animation.

xy-VSFilter is a 2.39.5.x fork for performance. Pre-buffering was removed, but caching and other enhancements were added in its place.

VSFilter 2.40.x repository is on MPC-HC but isn't actually stock VSFilter but rather VSFilter Mod + slight changes and bug fixes. Even though the MPC-HC project is active, VSFilter has no devs working on it (except for the occasional minor bug-fix). Pre-buffering in 2.40.x supports animation, but it sometimes causes flickering. Use of VSFilter Mod features in Aegisub should be avoided whenever possible for legacy compatibility when softsubbing. As of 2010, CCCP started bundling this version.

threaded-VSFilter is a 2.40.x fork for performance focused on multi-threading and pre-buffering. Only supports Vista and newer.

If VSFilter is a dead path and has a shrinking list of advantages over libass, why hasn't there been a migration?

From a multiplatform perspective it makes sense and would unify sub rendering behaviors. Heck, a new ASS spec and tags not exclusive to hardsubbing may come out of it.

It'd be less of a gamble than transitioning to 10-bit during the rise of DXVA/VDPAU with no roadmap for GPU decoding.

[creb]

Originally Posted by Luurah

I tried experimenting with hi10p with my Daltanious subs for kicks. I managed to get it encoded with hi10p, but I think I'm doing something wrong. The original file (no audio) had approximately 179MB. When I finally encoded the video, the file size was 185MB.

Is this normal? I thought it would compress the video file to a smaller size compared to the H.264 video profile I've been using thus far. This is what i used in the batch file I made that was supposed to compress the video from to hi10p:



I wish I could do this in AVIDemux, but I haven't found any documentation on how to encode hi10p video files in that program. (I'm not sure if AVIDemux can work with hi10p yet, but I heard it does.)

Anyway... point is... am I doing something wrong? If so, what can I do to make it right? (Or did I misread something in the first place?)

I haven't done it myself, but I have noticed that the person taking fansubber's 10bit releases on nyaatorrents and re-releasing them as 8bit is releasing slightly smaller files. We're talking about a decrease of roughly 25 MiB for UTW's Fate/Zero (431.9 MiB to 405.7 MiB), and a decrease of about 16 MiB for gg's Working'!! (261.9 to 244.6).

So, those 8 bit files are smaller than their corresponding 10 bit files. So your 10 bit encodes being a larger file size seems to fit that trend.

My own take is that only the videophiles really notice banding improvements from 10 bit, but even if the improvements are going to go largely un-noticed by most casual viewers, small-step advancements are ultimately a good thing, as many of them put together are why we see things in the quality we currently do.

[Guardian Enzo]

Just from my personal experience... I pretty much have to use MPC-HC for blogging purposes. I converted my netbook using the CCCP pack, and while it worked, it took a lot of tweaking and adjusting to get everything working the way I needed it to in terms of subs, screencaps, etc.

OTOH, on my main system - which I'd been avoiding converting because I didn't want to deal with all that again - I just uploaded the LAV codecs. Literally in 2 minutes I was playing 10-bit on my old MPC after clicking two boxes in the MPC options menu. Didn't have to uninstall anything or make any other tweaks. So far - knock wood - it's playing flawlessly. Far, far easier than any other method I've seen so far.

[0utf0xZer0]

Originally Posted by creb

I haven't done it myself, but I have noticed that the person taking fansubber's 10bit releases on nyaatorrents and re-releasing them as 8bit is releasing slightly smaller files. We're talking about a decrease of roughly 25 MiB for UTW's Fate/Zero (431.9 MiB to 405.7 MiB), and a decrease of about 16 MiB for gg's Working'!! (261.9 to 244.6).

So, those 8 bit files are smaller than their corresponding 10 bit files. So your 10 bit encodes being a larger file size seems to fit that trend.

Most groups that put out both 8 and 10 bit versions tend to end up with smaller file sizes for the 10 bit from what I've seen. Reencodes are different matter since there may be other variables betwen the encodes - 8 vs. 10 bit is not the only setting that effects file size in H.264.

Originally Posted by Starks

If VSFilter is a dead path and has a shrinking list of advantages over libass, why hasn't there been a migration?

There's currently no DirectShow version of libass so you can't use it with MPC-HC or CCCP.

Originally Posted by Guardian Enzo

Just from my personal experience... I pretty much have to use MPC-HC for blogging purposes. I converted my netbook using the CCCP pack, and while it worked, it took a lot of tweaking and adjusting to get everything working the way I needed it to in terms of subs, screencaps, etc.

OTOH, on my main system - which I'd been avoiding converting because I didn't want to deal with all that again - I just uploaded the LAV codecs. Literally in 2 minutes I was playing 10-bit on my old MPC after clicking two boxes in the MPC options menu. Didn't have to uninstall anything or make any other tweaks. So far - knock wood - it's playing flawlessly. Far, far easier than any other method I've seen so far.

So you're using MPC-HC's own subtitle renderer, I take it? And which output mode?

If my experience with the X120e is any indication, I wouldn't count on 10 bit playing on a netbook due to performance issues.

[Guardian Enzo]

Yes, the internal renderer with EVR Custom. So far, so good. Also using LAV's hardware accelerated decoding.

My netbook is actually doing fine with the 10 bit using CCCP - it was just a lot of trial and error to get there. It's not an Atom, though, which I'm sure helps.

[TheFluff]

Originally Posted by Starks

If VSFilter is a dead path and has a shrinking list of advantages over libass, why hasn't there been a migration?

From a multiplatform perspective it makes sense and would unify sub rendering behaviors. Heck, a new ASS spec and tags not exclusive to hardsubbing may come out of it.

It'd be less of a gamble than transitioning to 10-bit during the rise of DXVA/VDPAU with no roadmap for GPU decoding.

there is no libass directshow filter and nobody wants to write one
transitioning to 10-bit is not a "gamble" as it does not break anything important (even if it did break something important it still would not be a "gamble" because we are not actually risking anything). also, it does not break old encodes, like switching subtitle renderers would do (because libass is not fully bug-for-bug compatible with vsfilter).

furthermore, you're sounding like the pointy-haired boss from Dilbert, and this is not a good thing

[lachs0r]

Originally Posted by TheFluff

there is no libass directshow filter and nobody wants to write one

Someone called delamoo might still have his POC filter. IIRC he had VSFilter’s creepy dshow merit/whatever hackery in place, and he claimed it was basically working except for Matroska embedded fonts. The font issue is being worked on from libass’ side, though I’m not sure at all whether getting actual font data rather than just the font metadata from Windows’ GDI or DirectWrite API would work.

Regardless, I’d say it would be much easier to fix mplayer2 for non-Linux platforms (i.e. write better video output drivers and a decent IPC implementation + accompanying GUI frontend for it) than attempting to actually fix anything dshow related.

[cyberbeing]

lachs0r, do you think there is any chance of Uoti or someone else implementing automatic YUV->RGB matrix switching for the gl renderer, based on video resolution and overridden by stream headers? I see Uoti recently fixed the problem with YUV->RGB matrix chroma scaling I was affected by, but it'd be nice if I didn't need to manually add/remove colorspace=2 from the gl options every time I switch between HD content (REC.709) and SD content (REC.601).

[lachs0r]

http://git.mplayer2.org/mplayer2/com...44bea1ab90b87d

[cyberbeing]

That's what I get for only bookmarking and checking changes on the master branch log.

Shouldn't:

{"BT.601", MP_CSP_BT_601}, {"sd", MP_CSP_BT_601}, {"1", MP_CSP_BT_601},
{"BT.709", MP_CSP_BT_709}, {"sd", MP_CSP_BT_709}, {"2", MP_CSP_BT_709},

Instead be:

{"BT.601", MP_CSP_BT_601}, {"sd", MP_CSP_BT_601}, {"1", MP_CSP_BT_601},
{"BT.709", MP_CSP_BT_709}, {"hd", MP_CSP_BT_709}, {"2", MP_CSP_BT_709},

I assume this means it hasn't landed on the master branch since the patch still needs to be reviewed and refined? Or is there something else preventing it from being merged into master? Since I've yet to figure out how to setup a correct environment for building libav/ffmpeg based programs, I hope this change lands on master and is included in your mplayer2 builds in the near future.

By the way, there appears to be a subtitle font scaling(?) issue resulting in different line-wrapping with long lines, when a video is resized to 50% with the gl renderer in your latest mplayer2 builds.

Spoiler for 100%:

Note: The Japanese is part of the video and not softsubbed

Spoiler for 50%:

Note: The Japanese is part of the video and not softsubbed

[flying ^]

Will Hi10P run smoothly with my ultra portable?

specs:

- 1.2 ghz Intel Core Duo (U2500)
- Intel 945 GM graphics
- aftermarket Brodcom Crystal HD video accelerator

[Starks]

For mplayer2, I'm finding that Intel and Nouveau (but not Nvidia) need -vf format=yv12 for Hi10P to render properly with gl output on Linux. Haven't tested Windows.

Could it be a problem with Mesa/Gallium or is it on the end of mplayer2/libav?

Here's an example of output without yv12:

Spoiler for 10bit art:

Thankfully, VDPAU+ffh264 is fine.