2011-09-23, 01:50 | Link #41 | |
It's bacon!
Join Date: Nov 2003
Location: Up and to the Left
Age: 43
|
Quote:
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. Last edited by Green²; 2011-09-23 at 02:32. |
|
2011-09-23, 05:01 | Link #42 | |
Senior Member
Join Date: May 2006
Location: California
|
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.
Quote:
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.
__________________
Last edited by cyberbeing; 2011-10-01 at 22:04. |
|
2011-09-23, 16:26 | Link #44 |
Senior Member
Join Date: May 2006
Location: California
|
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.
__________________
Last edited by cyberbeing; 2011-09-23 at 16:52. |
2011-10-03, 01:36 | Link #46 |
Junior Member
Join Date: Oct 2011
|
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. |
2011-10-03, 03:32 | Link #47 | |
Weapon of Mass Discussion
Fansubber
Join Date: Feb 2003
Location: New York, USA
|
Quote:
__________________
|
|
2011-10-03, 10:42 | Link #48 | |
CROSS IN!!
|
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: Quote:
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?) |
|
2011-10-03, 13:28 | Link #49 | |
I see what you did there!
Scanlator
|
Quote:
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.
__________________
|
|
2011-10-03, 13:32 | Link #50 | |
Hiding Under Your Bed
Join Date: May 2008
|
Quote:
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.
__________________
|
|
2011-10-03, 14:53 | Link #51 |
Seishu's Ace
Author
Join Date: Dec 2005
Location: Kobe, Japan
|
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.
__________________
|
2011-10-03, 16:14 | Link #52 | |||
Pretentious moe scholar
Join Date: Oct 2006
Location: Vancouver, Canada
Age: 37
|
Quote:
Quote:
Quote:
If my experience with the X120e is any indication, I wouldn't count on 10 bit playing on a netbook due to performance issues.
__________________
|
|||
2011-10-03, 16:41 | Link #53 |
Seishu's Ace
Author
Join Date: Dec 2005
Location: Kobe, Japan
|
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.
__________________
|
2011-10-04, 07:09 | Link #54 | |
Excessively jovial fellow
Join Date: Dec 2005
Location: ISDB-T
Age: 37
|
Quote:
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
__________________
|
|
2011-10-04, 07:52 | Link #55 | |
not fansubbing 24/7
Join Date: Nov 2009
Location: Germany
|
Quote:
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. |
|
2011-10-04, 13:22 | Link #56 |
Senior Member
Join Date: May 2006
Location: California
|
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).
__________________
|
2011-10-05, 20:21 | Link #58 |
Senior Member
Join Date: May 2006
Location: California
|
That's what I get for only bookmarking and checking changes on the master branch log.
Shouldn't: Code:
{"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}, Code:
{"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}, 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%:
Spoiler for 50%:
__________________
|
2011-10-06, 03:31 | Link #60 |
I see what you did there!
Scanlator
|
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.
__________________
Last edited by Starks; 2011-10-06 at 04:03. |
|
|