Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Hardware & Software > Software players

Reply
 
Thread Tools Search this Thread Display Modes
Old 22nd October 2012, 21:10   #15001  |  Link
Asmodian
Registered User
 
Join Date: Feb 2002
Location: San Jose, California
Posts: 3,796
Quote:
Originally Posted by leeperry View Post
1) I've got all my HTPC files on a ramdisk and that'll waste an extra 100MB of my 2 gigs
2) There'll be an uncalled for loading time wait each time I'll open a video file
Hey these two at the same time don't make sense, anyway I never notice a loading time even just using a SSD. Give it a try, it is much easier and faster than it was in the first versions. It seems pointless for madshi to implement different gamut mapping options to me, unless something really is wrong with yCMS.
Asmodian is offline   Reply With Quote
Old 22nd October 2012, 21:24   #15002  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,137
Quote:
Originally Posted by egur View Post
Any more details?
Do you scale using 1 pass in 2D? 2 passes in 1D? 2 passes in 2D?
Does it work well in YCbCr?
Is it any better or worse in linear light?
Linear light scaling doesn't really look good to me, neither with Lanczos nor with Jinc. Scaling with Jinc in YCbCr should work just fine, I don't see any reason why it wouldn't work well. madVR is scaling in R'G'B', though.

Jinc has to be done in 1-pass 2D. It doesn't work any other way, because the true distance "Sqrt(xDist*xDist + yDist*yDist)" is used to calculate the weight of the source pixels around the destination pixel. For Jinc3 you basically use a circle of source pixels with a max distance of 3.0 around the destination pixel.

Here are test results with a very artificial test pattern. It shows quite nicely the key difference between Lanczos and Jinc, IMHO. You can see that the whole "look" (including ringing artifacts) is more rectangular with Lanczos and more round with Jinc:

original image -|- Lanczos4 -|- Jinc4 -|- Jinc4 AR

As you can see, there are still some artifacts in the Jinc4 AR algorithm, so it still needs some improvement.
madshi is offline   Reply With Quote
Old 22nd October 2012, 21:31   #15003  |  Link
NicolasRobidoux
Nicolas Robidoux
 
NicolasRobidoux's Avatar
 
Join Date: Mar 2011
Location: Copenhagen Denmark
Posts: 269
@Eric: What colorspace to use is not fully dependent on the filter. See http://www.imagemagick.org/discourse...p?f=22&t=21804, which unfortunately does not include Y'CbCr, and uses a variant of tensor Lanczos 3 that I like more.

Last edited by NicolasRobidoux; 23rd October 2012 at 02:11.
NicolasRobidoux is offline   Reply With Quote
Old 22nd October 2012, 22:12   #15004  |  Link
pankov
Registered User
 
Join Date: Mar 2002
Location: Sofia, Bulgaria
Posts: 658
Quote:
Originally Posted by madshi View Post
I could "fix" it, but I don't think I should. After all there's a difference between Ctrl+J and Ctrl+Shift+J, and we want to have the option to use these two key combinations for different things, don't we?
I agree
Thanks for your time.

I have one somewhat personal request:
Can you check this ticket
https://sourceforge.net/apps/trac/mpc-hc/ticket/2671
I opened in the MPC bug tracking system and share your opinion on the subject?
In short it's about a problem with VSFilter which "clears" the deinterlace flags in the video and thus cheating madVR into not deinterlacing a perfectly interlaced 1080i50 video captured with a digital camera. Do you think it's possible for madVR's "detection engine" to ignore the value of dwInterlaceFlags that VSFilter sets and read it from the decoder/filter which is before VSFilter in the graph? After all we know that VSFilter can't do deinterlacing so I think it can't be a reliable source for this flags, right?
__________________
Z370M Pro4 | i3-8100 | 16GB RAM | 256GB SSD + 40TB NAS
NVIDIA GTX 1060 6GB (385.28) | LG OLED65B7V
Win 10 64bit 1803 + Zoom Player v14

Last edited by pankov; 22nd October 2012 at 22:59.
pankov is offline   Reply With Quote
Old 22nd October 2012, 22:17   #15005  |  Link
egur
QuickSync Decoder author
 
Join Date: Apr 2011
Location: Atlit, Israel
Posts: 916
@Nicolas
Thank a lot.
__________________
Eric Gur,
Processor Application Engineer for Overclocking and CPU technologies
Intel QuickSync Decoder author
Intel Corp.
egur is offline   Reply With Quote
Old 22nd October 2012, 22:27   #15006  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,137
@pankov, please use xy-vsfilter and if that has the same problem, report it there. The xy-vsfilter developer actually does fix bugs, so you have a pretty good chance to getting it fixed there. Of course it would be possible to work around the problem in madVR, but it would cost me extra time, so I'm reluctant. Soon, madVR + xy-vsfilter will be the best subtitle solution, anyway, and will totally bypass the normal DirectShow connection chain.
madshi is offline   Reply With Quote
Old 22nd October 2012, 23:05   #15007  |  Link
pankov
Registered User
 
Join Date: Mar 2002
Location: Sofia, Bulgaria
Posts: 658
madshi,
I was actually using xy-vsfilter and it has the exact same problem. I was advised (by cyberbeing) to report it to the MPC team because the xy-vsfilter developer is alone and doesn't have much experience with such interlaced files.
I guess I'll wait for the real solution (the one that bypasses the DirectShow chain) and use the new keyboard shortcuts that I'm now able to control via Girder (thanks again) till then.
I just wanted your expert opinion on the matter.
Thanks again.
__________________
Z370M Pro4 | i3-8100 | 16GB RAM | 256GB SSD + 40TB NAS
NVIDIA GTX 1060 6GB (385.28) | LG OLED65B7V
Win 10 64bit 1803 + Zoom Player v14
pankov is offline   Reply With Quote
Old 23rd October 2012, 04:45   #15008  |  Link
NicolasRobidoux
Nicolas Robidoux
 
NicolasRobidoux's Avatar
 
Join Date: Mar 2011
Location: Copenhagen Denmark
Posts: 269
Eric:
Here is an example of EWA LanczosSharp (a.k.a. Jinc 3) used with an alternate method, namely sigmoidization, that reduces halos and that Mathias found does not work well in some circumnstances. (And I'm going to have to double check on this, because it's worrisome. I'm actually not sure at all it would work well with Y'CbCr. And, after Mathias comments, I'm not even sure it always works well with sRGB pngs.)
http://web.cs.laurentian.ca/nrobidou...sSharp.7p5.png

Last edited by NicolasRobidoux; 23rd October 2012 at 04:51.
NicolasRobidoux is offline   Reply With Quote
Old 23rd October 2012, 05:38   #15009  |  Link
leeperry
Kid for Today
 
Join Date: Aug 2004
Posts: 3,475
Quote:
Originally Posted by madshi View Post
A great GPU would be the 660, if you can swing it.
Quite frankly what I hate with new computer parts is that they lose 50% of their value in 1 year, and 2 years later they can only be sold as paper weights...there's also a large number of ppl who constantly upgrade being desperate to sell their 1yo board for cheap , but the 650Ti seems to provide a much higher bang for bucks ratio -even brand new- so buying used doesn't seem to make much sense.

So anyone's got an advice on a good nvidia board for 720p to 1080p Jinc3 AR chroma+luma upscale please? How about a $150 1GB GTX650Ti? I've got no idea how much crunching power this monster of an algorithm might require for 720p to 1080p....really the +1K SP's of the 660

But it's good to see that the 650Ti is a very power efficient GPU and that my 400W Corsair PSU will do nicely: http://www.tomshardware.com/reviews/...6,3318-18.html

BTW, I advised Kazuya to try Jinc3 AR upscale and he's hooked! He ditched his ffdshow Spline upscale profile in a split second, figures

Quote:
Originally Posted by Asmodian View Post
I never notice a loading time even just using a SSD. Give it a try, it is much easier and faster than it was in the first versions.
OK, sounds good! I'll be running gamut mapping comparisons then

Last edited by leeperry; 23rd October 2012 at 07:52.
leeperry is offline   Reply With Quote
Old 23rd October 2012, 06:29   #15010  |  Link
cyberbeing
Broadband Junkie
 
Join Date: Oct 2005
Posts: 1,859
Quote:
Originally Posted by pankov View Post
Quote:
Originally Posted by madshi View Post
@pankov, please use xy-vsfilter and if that has the same problem, report it there. The xy-vsfilter developer actually does fix bugs, so you have a pretty good chance to getting it fixed there. Of course it would be possible to work around the problem in madVR, but it would cost me extra time, so I'm reluctant.
I was actually using xy-vsfilter and it has the exact same problem. I was advised (by cyberbeing) to report it to the MPC team because the xy-vsfilter developer is alone and doesn't have much experience with such interlaced files.
@madshi

Since this was brought up here, what would you consider the 'correct' way VSFilter should handle interlaced video flags, considering it likely 'weaves' interlaced video to progressive (combing artifacts), alphablends progressive subtitles on top, and then outputs to a video renderer like madVR? Can such video actually be properly deinterlaced after VSFilter has had its way with it? If so, how should it be flagged?
cyberbeing is offline   Reply With Quote
Old 23rd October 2012, 08:05   #15011  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 9,899
Video is already "weaved" when you get it. DirectShow doesn't really do single interlaced fields, what you get is one image with both fields weaved together. As long as you don't modify the video itself (scaling or conversion to another pixel format unsupported by GPU deinterlacing), you should just output it as-is with the same flags as from the source (dwInterlaceFlags is usually 0x81, AMINTERLACE_IsInterlaced|AMINTERLACE_DisplayModeBobOrWeave, on many video decoders), and of course the per-frame flags should stay as well (they indicate field order, and which frames to deinterlace). In short, just pass-through the dwInterlaceFlags value and the per-frame flags.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders
nevcairiel is offline   Reply With Quote
Old 23rd October 2012, 09:33   #15012  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,137
Quote:
Originally Posted by leeperry View Post
So anyone's got an advice on a good nvidia board for 720p to 1080p Jinc3 AR chroma+luma upscale please? How about a $150 1GB GTX650Ti?
I expect the 650Ti will probably be able to do Jinc3 AR for chroma+luma. But what happens if I add more funny algorithms to madVR? The 660 would give you a bit more breathing room for things like de-banding, de-ringing, sharpening, error diffusion, whenever that might come (not too soon, if at all). But then, probably these algorithms will not consume as much power as Jinc3 AR does. But I don't really know that yet. Of course if the 650Ti will run out of steam by then, you could upgrade again. Maybe not even the 660 will be fast enough then? No idea right now...

Quote:
Originally Posted by leeperry View Post
BTW, I advised Kazuya to try Jinc3 AR upscale and he's hooked! He ditched his ffdshow Spline upscale profile in a split second, figures
Who's Kazuya?

Quote:
Originally Posted by nevcairiel View Post
Video is already "weaved" when you get it. DirectShow doesn't really do single interlaced fields, what you get is one image with both fields weaved together. As long as you don't modify the video itself (scaling or conversion to another pixel format unsupported by GPU deinterlacing), you should just output it as-is with the same flags as from the source (dwInterlaceFlags is usually 0x81, AMINTERLACE_IsInterlaced|AMINTERLACE_DisplayModeBobOrWeave, on many video decoders), and of course the per-frame flags should stay as well (they indicate field order, and which frames to deinterlace). In short, just pass-through the dwInterlaceFlags value and the per-frame flags.
Agreed.
madshi is offline   Reply With Quote
Old 23rd October 2012, 11:43   #15013  |  Link
Pat357
Registered User
 
Join Date: Jun 2006
Posts: 441
Quote:
Originally Posted by madshi View Post
GPU usage should not change much with different video files or scenes.
Except for FPS from videofile, you mean.
The FPS can obviously change the GPU usage a lot.
Pat357 is offline   Reply With Quote
Old 23rd October 2012, 11:51   #15014  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,137
Yes, of course. FPS makes one hell of a difference. Twice as much FPS means roughly twice as much work for every part of madVR. What I was trying to say is that GPU consumption does not depend on whether you're watching a soft and slow motion landscape or whether you're watching a sharp and high motion action movie.
madshi is offline   Reply With Quote
Old 23rd October 2012, 13:10   #15015  |  Link
cyberbeing
Broadband Junkie
 
Join Date: Oct 2005
Posts: 1,859
Quote:
Originally Posted by madshi View Post
What I was trying to say is that GPU consumption does not depend on whether you're watching a soft and slow motion landscape or whether you're watching a sharp and high motion action movie.
If you use an 8-bit 3DLUT, NVIDIA GPU usage can potentially spike quite a bit depending on scene motion and color complexity.

On my GT440, certain colorful high motions scene will cause a temporary +5-15% increase in GPU usage (i.e. 25%->30-40%), without any queue drops. The more powerful the GPU, the less change there is. Nothing new, as it's the same problem we discussed extensively in the past mostly related to my 7800GTX and that GTX460 I briefly tested. Still it's noteworthy for users of lower powered NVIDIA GPUs, as I know Fermi and prior generations suffered from this. No idea about Kepler.
cyberbeing is offline   Reply With Quote
Old 23rd October 2012, 13:32   #15016  |  Link
leeperry
Kid for Today
 
Join Date: Aug 2004
Posts: 3,475
Quote:
Originally Posted by madshi View Post
I expect the 650Ti will probably be able to do Jinc3 AR for chroma+luma. But what happens if I add more funny algorithms to madVR? The 660 would give you a bit more breathing room for things like de-banding, de-ringing, sharpening, error diffusion, whenever that might come (not too soon, if at all). But then, probably these algorithms will not consume as much power as Jinc3 AR does. But I don't really know that yet. Of course if the 650Ti will run out of steam by then, you could upgrade again. Maybe not even the 660 will be fast enough then? No idea right now...
Ahhhh, but buying gear based on potential future needs is usually not too wise in the computer world. Jinc3 AR for chroma+luma works fine when going SD>1080p on my 96SP 8800GS, so I would guess that the 768SP 650Ti will be a hell more powerful! And possibly bring enough headroom for additional processing, and by then ATi will lower their prices, nvidia will be forced to follow etc etc....6 months from now, the 660 will be old news and my $250 investment would be merely worth $120 on the used market.

I'm not a fan of debanding or sharpening, but diffusion/floyd-steinberg dithering would indeed kill

IIRC, each pixel in games like Crysis 2 goes through like a thousand PS scripts, and simple video PS scripts in MPC barely require any GPU cycles.

CUDA optimization would also be most welcome, but I can understand that this would be a waste of your time, considering that ATi provide better bang for bucks if you're willing to live without CUDA & CUVID.

It's about time you cash-in on mVR and hire a bunch of ppl to assist you

Quote:
Originally Posted by madshi View Post
Who's Kazuya?
A major A/V nutcase who's given the taste of endless HTPC setup nitpicking to many ppl on HCFR. Apart from the red test pattern you used in the OP(that I cut from the end credits of "Les BronzÚs font du ski"), he's the one who provided all the other video test patterns I use. I very much trust his judgment
leeperry is offline   Reply With Quote
Old 23rd October 2012, 14:50   #15017  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,137
Quote:
Originally Posted by cyberbeing View Post
If you use an 8-bit 3DLUT, NVIDIA GPU usage can potentially spike quite a bit depending on scene motion and color complexity.
Ok, using 3dluts may be an exception to what I said, but it should be the only exception, and not every GPU might show similar behaviour with 3dluts.

Quote:
Originally Posted by leeperry View Post
Ahhhh, but buying gear based on potential future needs is usually not too wise in the computer world. Jinc3 AR for chroma+luma works fine when going SD>1080p on my 96SP 8800GS, so I would guess that the 768SP 650Ti will be a hell more powerful! And possibly bring enough headroom for additional processing, and by then ATi will lower their prices, nvidia will be forced to follow etc etc....
True. So get a 650Ti then.
madshi is offline   Reply With Quote
Old 23rd October 2012, 17:05   #15018  |  Link
nautilus7
Registered User
 
nautilus7's Avatar
 
Join Date: Jan 2006
Location: Athens, Greece
Posts: 1,517
Hi, since it's the first time I post in madVR thread, I would like to state how worderful this software is and what a great and methodical job madshi has done in developing it! Thanks a lot!

Now, I am trying to calibrate a friend's lcd tv using some test patterns. While playing arround, I decided to create some paterns of my own using photoshop. So, the question is, which color profile should I choose for the images in Photoshop? Forgive my ignorance in such matters, but apart my pc monitor, I haven't calibrate any other digital display. The available ones are below:



Should I choose sRGB, Rec.709 or something else? The calibration will be performed using a laptop (win7 and ati card, if that's important) connected via hdmi. I am keen on testing madVR's image displaying when support (through lav filters) is ready, as well.
nautilus7 is offline   Reply With Quote
Old 23rd October 2012, 17:05   #15019  |  Link
NicolasRobidoux
Nicolas Robidoux
 
NicolasRobidoux's Avatar
 
Join Date: Mar 2011
Location: Copenhagen Denmark
Posts: 269
Mathias:
The http://madshi.net/housetop.png test image is a pain in the *ss.
Enlarging through Lab, which has always looked slightly better in my tests than using straight sRGB, gives a result that is also more jaggy on the roof line (like the sigmoidized result at contrast=7.5).
I'm reasonably sure that what is going on is that you want something which is "maximally good with dark halo" because the original has significant light halo next to sharp dark features, and in a sense you want to minimize the halo of this light halo. And, among the common options, it's sRGB, not sigmoidizing, not linear RGB, not Lab.
I'm very tempted to chalk it up to "exception", just like the "cabins" image has dark letters which happen to be friendly to ... linear RGB.
If you some time at some point, and you happen to know, please point me to other test images where sigmoidization "fails".
At this point, I suspect that originals with haloing may not always be sigmoidization's friend.

Last edited by NicolasRobidoux; 23rd October 2012 at 17:19.
NicolasRobidoux is offline   Reply With Quote
Old 23rd October 2012, 17:12   #15020  |  Link
NicolasRobidoux
Nicolas Robidoux
 
NicolasRobidoux's Avatar
 
Join Date: Mar 2011
Location: Copenhagen Denmark
Posts: 269
Ah ah! I think I see what's going on:
The original housetop.png has a very pronounced asymmetrical dark straicase on that roof line. It's actually in the original.
Enlarging straight through sRGB happens to "paper over" this oscillation found in the original.
I feel better now.
(Not that sigmoidization is necessary safe from challenge. Far from it. But it's nice to see that actually sigmoidization and Lab are more faithful to a feature found in the original.)
P.S. That is, the "antialiasing" of the roof line is only effective on the "light" end, right in the original.
NicolasRobidoux is offline   Reply With Quote
Reply

Tags
direct compute, dithering, error diffusion, madvr, ngu, nnedi3, quality, renderer, scaling, uhd upscaling, upsampling

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 14:09.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, vBulletin Solutions Inc.