View Full Version : mpc-hc, renderers problems!
ramicio
24th May 2010, 16:44
- mpc-hc 1.3.1249.0 (x86)
- win7 x64
- geforce 8600gt
- core i7-920
- 3gb ram
just recently i started to use coreavc to offload h.264 to the gpu. i was curios and went into the render pin info, and it is sizing 1080p videos to 2048 wide, and 720p to 1536 wide. all my renderers do this, except madvr, and i can't get video to play worth crap on that renderer. just wondering what is up with these renderers. it doesn it on evr, vmr7 and 9, and i think the system defaults and overlay mixer. i am just sticking to evr custom.
EDIT: forgot to mention, on pin infos, the input video is correct (say for example 1920x1040) and it's the output that's getting horizontally upscaled in the rendering filter to say 2048x1040.
ramicio
27th May 2010, 17:35
no one would know why these renderers are upscaling the video horizontally?
burfadel
27th May 2010, 19:31
Try a later build of MPC-HC, that build you're using is quite ancient, relatively speaking (700+ revisions old).
Download the latest x86 mpc-hc from:
http://www.xvidvideo.ru/
That is the proper link to find new builds, as link to in the first post of the MPC thread here:
http://forum.doom9.org/showthread.php?t=123537&highlight=xvidvideo
If you click on the heading it will take you to the download page, where the file you need is under the 'Media Player Classic HomeCinema x86 (Only EXE file):' down the page.
The download is in English so its ok!
There's a new build out every couple of day, based on the latest revision. In your case, I think the problem may be related to a setting somewhere which has been set incorrectly, although I'd not sure where it would be!
ramicio
27th May 2010, 19:56
those are just source codes aren't they? there is no setting incorrect. the renderer receives the correct size video and resizes it. madvr doesn't change the res, but that renderer is right on the edge of skipping frames on my machine even with settings low as can be. i already have the program being a stable build crash randomly. i can't imagine an unstable build.
ramicio
27th May 2010, 20:15
on a totally different machine with the newest version of mpc-hc i go to play a video that is 394x296 with evr-custom and it the renderer pin says the header info is 394x296 but the video being served to it is 448x296. this is with ffdshow. if i use the internal xvid filter in mpc-hc it will all be correct.
at home i am using corecodec for avc and ffdshow for everything else. i do not wish to part with corecodec because i'm using cuda acceleration, but ffdshow i can do without.
burfadel
27th May 2010, 20:54
Its a fully compiled executable, as is the ffdshow and x264 codec they have listed there. The term 'stable' build is used very loosely, you're still much better off trying out the latest! A stable build really doesn't mean that much in the case of ffdshow, mpc-hc, x264 etc!
Even for normal programmes, 'stable build' doesn't really mean much. A big example is Windows, when they finalised Windows 7 RTM, they already knew of several bugs and issues! If you look at the readme's etc of many programmes they have 'known issues', the programmes that don't just don't want to be that honest. Those known issues means that the programme isn't really as stable as they want you to believe, but you have to wait for the next realease to get the fixes. A lot of the time they have to release minor fixes along the way!
With mpc-hc, ffdshow, x264 etc, they have shyed away from 'stable build' designation, especially x264. Why? because each revision is an improvement on the last, and any problems found are fixed ASAP and you can get them instantly. In the 'stable' programme world if you're lucky enough that they release a fix for it, you still have to wait for the one or two people to test it and for the person being paid to programme it to look in to that issue. At the same time they're doing this they're worrying about meeting the deadline for adding new features etc to the programme, something bug fixing pulls them away from.
(it is a bit of an over simplification, but it does get the general idea across)
I can safely guarantee that the latest version on the website is stable and safe to use, and is a much better choice than a build 710+ revisions out of date. They label it as unstable as its difficult to test in all situations etc, but mostly because that build hasn't gone through the its worked pretty well for a couple of weeks test :). If you are worried about it, just make a copy of the current version in a backup folder, and each time you download a new version just move the version you are replacing over the older one in the backup folder. Of course, if there is ever an issue you discover with the latest revision, just use the backup and see if the issue is already reported (if not, report it)! :)
ramicio
27th May 2010, 21:07
i found the compiled executables now. i will be sure to get it on my home pc. as for my work computer, it still has messed up sizes haha.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.