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 4th June 2011, 16:55   #7861  |  Link
robpdotcom
Registered User
 
Join Date: Jan 2010
Posts: 297
Quote:
Originally Posted by Mikey2 View Post
if you are stuck with SPDIF, I do NOT recommend decoding it to PCM just to re-encode it to ac3 in ReClock. (Unless you are dealing with PAL speedup...I suggest just dealing with the minor offsets. This is especially true if you are bit-streaming something like DTS-MA/TrueHD etc...there you cannot touch it without losing the lossless quality of the bit-stream.
But you cannot bitstream TrueHD or DTS-MA over SPDIF. You can, however, get lossless decoding via LAVAudio. I doubt you could hear the difference between bitstreaming the lossy "core", and letting Reclock encode what was decoded lossless.
__________________
Windows 7 x64
i7 870
16GB RAM
AMD 6870
robpdotcom is offline   Reply With Quote
Old 5th June 2011, 03:58   #7862  |  Link
nightfly
Registered User
 
Join Date: Oct 2009
Posts: 91
I have a issue with MadVR and video levels. Setting MadVR to output 0-255 (and using custom Nvidia resolution) I get black crush in exclusive full screen mode. In windowed mode video levels are correct. Disabled exclusive fullscreen mode and video levels match between fullscreen and windowed mode.

MadVR .61
LavCUVID .7
LAV Splitter/Audio .28
MPC-HC .3018

What do I lose not using exclusive?

Looks like I get tearing..

Regardless, it would seem my problem is due to Nvidia and a using a DVI - HDMI cable. On the straight HDMI to projector, I don't have the video level issue. Using custom resolutions also effect the issue. Oh well.
__________________
nvidia gts 450 (270.61), Asus P7H55-M Pro MB, Denon 988 AVR
MPC-HC v.3456: filters: LAV Audio/CUVID/Splitter .35, MadVR .73

Last edited by nightfly; 5th June 2011 at 08:16.
nightfly is offline   Reply With Quote
Old 5th June 2011, 04:10   #7863  |  Link
mandarinka
Registered User
 
mandarinka's Avatar
 
Join Date: Jan 2007
Posts: 729
Quote:
Originally Posted by nevcairiel View Post
Why use hacks? There are pixel formats for real 16-bit (like the P016 mentioned above), any hack will just result in pain in the long run.

Besides, whatever "hack" people come up with, ffdshow has no developers anymore.
The good thing about this hack is that it can use the existing avisynth infrastructure normaly (with some avs2yuv effort you can even encode it in x264) without causing any new problems, it is purely filter/function-side solution (thus can be dropped later).

Naturaly, real 16bit colorspaces in avisynth would be better, but avisynth developers are busy enough and the development is slow already - 2.6 still isn't done after several years.

So... real 16bit needs rewrite of filters AND avisynth, this hack only needs rewrite of filters. Some of them are already available, and as long as plugin authors are willing, it can take off, because no messing with avisynth core is needed. (And modifying those plugins for non-hacky core 16bit probably won't be hard one day). Imho, for an "ugly hack", this has a beauty of its own.
mandarinka is offline   Reply With Quote
Old 5th June 2011, 08:46   #7864  |  Link
e-t172
Registered User
 
Join Date: Jan 2008
Posts: 589
Quote:
Originally Posted by nightfly View Post
I have a issue with MadVR and video levels. Setting MadVR to output 0-255 (and using custom Nvidia resolution) I get black crush in exclusive full screen mode. In windowed mode video levels are correct. Disabled exclusive fullscreen mode and video levels match between fullscreen and windowed mode.

MadVR .61
LavCUVID .7
LAV Splitter/Audio .28
MPC-HC .3018
Have you tried using a software decoder instead of LAV CUVID?
e-t172 is offline   Reply With Quote
Old 5th June 2011, 10:44   #7865  |  Link
kepke
Registered User
 
Join Date: Apr 2011
Posts: 1
Quote:
Originally Posted by nightfly View Post
I have a issue with MadVR and video levels. Setting MadVR to output 0-255 (and using custom Nvidia resolution) I get black crush in exclusive full screen mode. In windowed mode video levels are correct. Disabled exclusive fullscreen mode and video levels match between fullscreen and windowed mode.

MadVR .61
LavCUVID .7
LAV Splitter/Audio .28
MPC-HC .3018

What do I lose not using exclusive?

Looks like I get tearing..

Regardless, it would seem my problem is due to Nvidia and a using a DVI - HDMI cable. On the straight HDMI to projector, I don't have the video level issue. Using custom resolutions also effect the issue. Oh well.
I had the same issue
Try to change the “Content type reported to the display” on the “NVidia Control Panel” -> “Adjust Desktop Color Settings” -> ” Content type reported to the display” -> “Full-screen videos”
kepke is offline   Reply With Quote
Old 5th June 2011, 12:43   #7866  |  Link
leeperry
Kid for Today
 
Join Date: Aug 2004
Posts: 3,477
Quote:
Originally Posted by mandarinka View Post
The good thing about this hack is that it can use the existing avisynth infrastructure normaly (with some avs2yuv effort you can even encode it in x264) without causing any new problems, it is purely filter/function-side solution (thus can be dropped later).

Naturaly, real 16bit colorspaces in avisynth would be better, but avisynth developers are busy enough and the development is slow already - 2.6 still isn't done after several years.

So... real 16bit needs rewrite of filters AND avisynth, this hack only needs rewrite of filters. Some of them are already available, and as long as plugin authors are willing, it can take off, because no messing with avisynth core is needed. (And modifying those plugins for non-hacky core 16bit probably won't be hard one day). Imho, for an "ugly hack", this has a beauty of its own.
Well said, and it'd only be faster adopted if mVR supported 16bit input too. A full 16bit video pipeline, ouuuuh I like the sound of that

And that'd feed 10bit displays as well, whatever you'd need: sharpening, deinterlacing, etc etc. Minimal quality loss is the key, and I can't think of a better host than mVR for this. Hope it'll be considered

Quite frankly, the latest build of SmoothAdjust() looks pretty darn amazing(it does stunning TV>PC conversions too): http://forum.doom9.org/showpost.php?...&postcount=234
leeperry is offline   Reply With Quote
Old 5th June 2011, 13:24   #7867  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,344
Quote:
Originally Posted by leeperry View Post
Quite frankly, the latest build of SmoothAdjust() looks pretty darn amazing(it does stunning TV>PC conversions too): http://forum.doom9.org/showpost.php?...&postcount=234
Amazing? That looks like crap, the whole image has a pinkish tint, and some areas are over-brighted reducing details.

madVR already supports 16-bit input. If you want this to work, you should teach ffdshow to convert the "hack" into proper 16-bit on output (after its done with avisynth).
Keep the hack inside ffdshow, if you must, but having a "hacked" pixel format go out of ffdshow would be *terrible*. Should also not be that hard to transform it into a proper 16-bit pixel format on output, and madVR wouldnt even need changes.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders

Last edited by nevcairiel; 5th June 2011 at 13:27.
nevcairiel is offline   Reply With Quote
Old 5th June 2011, 13:30   #7868  |  Link
leeperry
Kid for Today
 
Join Date: Aug 2004
Posts: 3,477
Quote:
Originally Posted by nevcairiel View Post
madVR wouldn't even need changes
Have you been appointed by madshi to provide tech support in this thread? Replying to your posts feels like troll feeding tbh.
leeperry is offline   Reply With Quote
Old 5th June 2011, 13:43   #7869  |  Link
CruNcher
Registered User
 
CruNcher's Avatar
 
Join Date: Apr 2002
Location: Germany
Posts: 4,926
Quote:
Originally Posted by leeperry View Post
Well said, and it'd only be faster adopted if mVR supported 16bit input too. A full 16bit video pipeline, ouuuuh I like the sound of that

And that'd feed 10bit displays as well, whatever you'd need: sharpening, deinterlacing, etc etc. Minimal quality loss is the key, and I can't think of a better host than mVR for this. Hope it'll be considered

Quite frankly, the latest build of SmoothAdjust() looks pretty darn amazing(it does stunning TV>PC conversions too): http://forum.doom9.org/showpost.php?...&postcount=234
And the use of this ? it can be done in Realtime these days as a Option in your GPU driver why in hells name invest the energy @ conversion with it and brake broadcast rules ? Sure you could say the broadcasters can do the PC->TV conversion but the Analog Broadcast standards are much older Converting content from it's initial TV scale to PC scale is a bad thing and should be up to the decision of the Decoder part of the System not the Encoder.
__________________
all my compares are riddles so please try to decipher them yourselves :)

It is about Time

Join the Revolution NOW before it is to Late !

http://forum.doom9.org/showthread.php?t=168004

Last edited by CruNcher; 5th June 2011 at 13:51.
CruNcher is offline   Reply With Quote
Old 5th June 2011, 13:47   #7870  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,344
Quote:
Originally Posted by leeperry View Post
Have you been appointed by madshi to provide tech support in this thread? Replying to your posts feels like troll feeding tbh.
Your response right there is the only troll post, all i wrote are technical facts or opinions, not trolling.

All i'm saying is that madVR already supports 16-bit input, and since ffdshow needs changes anyway, just make it output the 16-bit in a "standard" format, that makes it easier on everyone.

Its not like ffdshow can already do this and just madVR needs changes.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders
nevcairiel is offline   Reply With Quote
Old 5th June 2011, 15:13   #7871  |  Link
leeperry
Kid for Today
 
Join Date: Aug 2004
Posts: 3,477
Quote:
Originally Posted by CruNcher View Post
And the use of this ?
Quite simple: provide more levels to play around w/ to Avisynth scripts. LSF and GrainF3 look noticeably better when working on PC than on TV range...and I use PC range displays anyway, so there's no point in clipping my post-processing to TV when it'll expanded to PC afterwards. But this is OT, I was merely asking for madshi's opinion on this hack...as we've all be complaining about processing 16int audio and 8bit video. Can you feel the wind of change?

SmoothLevels() uses a different dithering algorithm from mVR, I find that they look amazing together in combo on a CRT, and I already posted comparisons a while back(the 2.0 beta has been a huge improvement as well). Ppl w/ 6bit dithered LCD displays hated it(TN panels and so), but don't shoot the messenger

Last edited by leeperry; 5th June 2011 at 15:23.
leeperry is offline   Reply With Quote
Old 5th June 2011, 16:46   #7872  |  Link
alph@
Replicant
 
alph@'s Avatar
 
Join Date: Jan 2007
Location: strasbourg
Posts: 49
leepery,you must be the only which use a crt display
alph@ is offline   Reply With Quote
Old 5th June 2011, 17:23   #7873  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Quote:
Originally Posted by pie1394 View Post
Here you are!

My settings.bin is copied from old madVR version.
But I am not sure if it is the reason which gets D3D11 messed up...
Hmmmm... The log says playback was stopped barely 1 second after the windows <-> exclusive switch. madVR was just about to start presenting again. Not sure why the switch took so much time, but judging from the log, if you had had a bit more patience, playback would have (automatically) resumed.

Quote:
Originally Posted by 6233638 View Post
Absolutely.

http://www.mediafire.com/?zdgi6alryd4bncv

1. Neither Option Selected
2. Limit Rendering Times
3. Run Presentation in Separate Thread
4. Both of the above selected.

It seems that my "fix" is an intermittent one, as taking that fourth log for you also resulted in a black screen.

Worked absolutely fine with three films in a row last night however.
Hmmmm... I like short logs. But these logs are so short that there's simply not enough information in them. Did you cut them down? Playback has barely started in these logs.

Quote:
Originally Posted by SSuzaku View Post
i got some problem with MadVR

problem : Blank Screen with sound in MPC -HC ( using High Performance Mode / AMD Radeon 6630 )
my conclusion : seems like MadVR can not detect AMD Radeon , since if i change MPC - HC priority to Power Saving ( using Intel ) the same video play flawlessly except stuttering ( maybe not powerful enough to play my Bluray rip video )

Notebook Sony VPCCA16FG
Specification :
Processor : Intel® Core™ i7-2620M Processor
Chipset : Intel® HM65
Video Card : AMD Radeon HD 6630M / Intel HD Graphics3000 (Hybrid)
Display resolution / Technology : 1600 x 900 / LED Backlight
Audio Type : Intel® High Definition Audio
Hard Drive : 500 GB Serial ATA 7200 RPM
OS : Microsoft Windows 7 Home Premium 64-bit

MadVR Log

http://www.mediafire.com/?irzogh2lb1l4xf4
The log looks just fine!! According to the log madVR is rendering your video and also displaying it. I've no idea why you get a black screen. Try updating your GPU drivers, maybe?

That log was from your Radeon, right?

Quote:
Originally Posted by sneaker_ger View Post
I can't leave FSE mode sometimes (D3D11), log:
https://rapidshare.com/files/4596429...window_fail.7z
Can't see anything wrong in that log on a quick check. What happens exactly in the problem situation? Please describe it in more detail.

Quote:
Originally Posted by Superb View Post
using the d3d11 path, when double clicking out of an exclusive fullscreen mode to windowed mode, the mpc-hc window covers the entire screen (instead of getting back to the original size).
Happens on my secondary tv-monitor.
Doesn't happen on my primary monitor or when using d3d9 path.
Yeah, the fix I implemented to prevent the media player window to cover the entire screen seems to only work on the primary monitor, need to improve that.

Quote:
Originally Posted by Superb View Post
sometimes when right clicking the tray icon, another tray icon menu opens up (the clock's right click menu). I remember eMule had the same issue and one of the developers found the cause. Maybe google will point in the right direction.

EDIT:
after some searching in Google... maybe you catch WM_RBUTTONDOWN instead of the proper WM_RBUTTONUP?
Yes, I've been using BUTTONDOWN. Have changed that to BUTTONUP now.

Quote:
Originally Posted by oddball View Post
BTW is there any way to capture the stats display to a file? Or a logging option I have missed? I think it would be far better if people could post their results in a manner where Madshi can see which options were enabled and what the stats were. Not sure why he has not done this rather than asking us to post spurious details that are less objective.
The madVR debug logs already contain the stats, but reading logs is an extremely time consuming thing, simply because there's so much information in there.

Quote:
Originally Posted by oddball View Post
I'm unable to get the MadVR resolution switching to work correctly. It supposedly overrides MPC-HC's fullscreen modes. I have it set thus.

1080p23, 1080p50, 1080i50, 1080i59, 720p23, 720p50, 720p60

I have 720p60 because I do have a true 60fps video I use to test.

Whenever I playback a 720p 23.976FPS file video it always defaults to 1080p23. However if I play a 720p 29.97FPS video it always defaults to 720p60.

Also when playing back 1080p 25FPS .ts files it plays at 720p60 (even if I use ReClock to PAL speedown).

Am I doing something wrong? I can understand if my HDTV does not support 720p at 24p/Hz but the .ts files are throwing me somewhat.

EDIT: OK changing 720p60 to 720p59 sorts out the .ts problem. But I still have 720p23 ending up as 1080p23. Could that be because my HDTV does not support 23/24 @ 720p?
The key thing is that all the modes you list in the madVR settings dialog must actually exist. If you list a mode that doesn't exist then Direct3D will switch to a "random" mode.

Quote:
Originally Posted by toomyzoom View Post
Can you make it displayer mode changer work with reclock?
I don't know in what way Reclock has a problem with madVR's display mode switching, but I don't think there's much I can do about it. I would rather guess it's a problem with Reclock. But I don't know for sure.

Quote:
Originally Posted by Hprd View Post
Ok Madshi, i have a question reguardling the fps override via renaming, and how the osd interprets that and whatnot. For example if there's a video that's 29.970 fps, and i want to play it back at 60hz (i have a resolution manually set to 60hz in the nvidia console, not the default 59.9) is it better to put 59p in the filename (to preserve the framerate, judging by the osd), or 60p? As if i put 59p, frame repeats happen a bit more often than 60p. And going by eye it looked like the osd wasn't lying, or maybe i was seeing it wrong?

So basically, is there any downside to not having the fps preserved perfectly/does it result in smoother playback, with no side effects? Or is the osd just showing what i'm telling it (and does it mean though that it repeats frames due to this more often?)?
What you write into the filename only affects which display mode madVR switches to. Nothing else. If both 59p and 60p will end up with the same display mode, there should be no difference between how fluidly they play.

Of course you should aim to get the best possible frame rate / refresh rate match. Which means that if the file is 29.970fps then you should try getting your display to do 59.940Hz instead of 60.000Hz.

Quote:
Originally Posted by HTPC-User View Post
Concerning the mouse visibility and the seekbar problems, I have done some tests (all with madvr 0.61 and MPC-HC 1.5.2.3056)
Looks like MPC-HC bugs, not madVR bugs to me. FWIW, the "D3D Fullscreen" option in the MPC-HC "Output" section is not supported by me. Which means that you can use it, but at your own risk.

Quote:
Originally Posted by Budtz View Post
I still get an access violation error when I switch to the next mediafile in the folder. I use PgUp and PgDown to do this often from within the media player - and whenever I do, I get an error.

MPC-HC says: Access violation at adress 4A50F54E in module MVRSETTINGS.DLL Read of adress 06FFFFFC. This has ben happening since v0.59 and changing settings dosn't seem to do anything.
Ouch. Is that 100% reproducable? Are the addresses always the same? This problem started with v0.59? So it does definitely not occur with v0.58?
madshi is offline   Reply With Quote
Old 5th June 2011, 17:28   #7874  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Quote:
Originally Posted by suanm View Post
I think further madvr version had better select most matchable display modes automatically just like reclock while playback,no need to type a series of digital manually in display modes box instead.Because many fans don't know how to type these digital in display modes box,I wonder if author(madshi) of madvr is thinking it over
The current version of the madVR display mode changer is only a first simple and stupid version. I've always said that. If you don't like, don't use it. There'll be an improved version in a future madVR version.

Quote:
Originally Posted by WontonNoodle View Post
so is there a way to get smooth playback on 60hz monitors???
Currently no. But probably yes, with a future madVR version. That will take some time, though.

Quote:
Originally Posted by oddball View Post
Entering 1080p60 in custom display switching in MadVR results in two instances of madHcCtrl in Task Manager.
That isn't a bug, if you're using the automatic refresh rate changer. madVR loads a helper instance of madHcCtrl which has the duty to restore the original display mode after the media player closed down. Since madVR is already gone at that time, madVR can't restore the original display mode. So madVR starts an extra madHcCtrl instance and tells it to restore the original display mode at that moment when the media player is closed. The additional madHcCtrl instance sits idle doing nothing but waiting for the media player to close. So no performance problem.

Quote:
Originally Posted by Andy o View Post
madshi, I have 1080i59, 1080p23, and 1080p50 in that order, in the auto rate change options. When I play a 59/60p video, madVR switches to the 23p option. Is it supposed to work that way? I'd rather have it switch to 1080i59. I don't have 1080p59 in the options cause I'd rather have the 29.97 fps videos play at 1080i59, and if I have 1080p59 there, 1080i gets ignored in its favor.
No, that's not how it's supposed to be. What happens if you only put 1080i59 in the auto rate change option? Does madVR switch to 1080i59 then? I rather guess that for some reason switching to 1080i59 doesn't work. Not sure why. Maybe Windows itself doesn't like it. Are you sure that this mode actually exists in your GPU display mode list?

Quote:
Originally Posted by Peuj View Post
I use the latest version (madVR v0.61) and I have some errors "updating vertex buffer failed" during playback.

Here's the log file: madVR log

I didn't find anything useful in the previous posts, is there something to do on my side?
Weird. How much RAM does your GPU have? Is it possible that you're running out of RAM? Not sure what else it could be...

Quote:
Originally Posted by toomyzoom View Post
Anyway to autoset frequency to 50hz for 24/23p videos in madVR?
Maybe. Depends on what other refresh rates combinations you want with which movie frame rates. Give us a full list, then we can tell you if it's possible to do with the current madVR solution.

Quote:
Originally Posted by piccirilli View Post
Since I've started using MadVR with MPC-HC, I have not been able to get the auto refresh rate changer to work, no matter what I do. My display will support 24HZ, but it stays on 60HZ for all my MKV's. Attempt to force it by renaming a file to "movie" p24.mkv won't work either. I can force 24HZ refresh using the rate changer in MPC-HC, but this creates the famous green bar/color distortions in MPC-HC. Any suggestions how I can troubleshoot the madvr rate changer? I'd love to get this working.
You have to enter the proper modes into the madVR settings dialog. These modes must actually exist. You can't just list modes you'd like to have. You must be able to manually activate those modes via the Windows control panels. Only then madVR can also automatically activate them.

Quote:
Originally Posted by piccirilli View Post
I realized for the refresh rate feature to work, the option "use a separate device for presentation" in the general Madvr settings must be enabled.
No, the "use a separate device for presentation" option has nothing to do with the refresh rate feature.

Quote:
Originally Posted by piccirilli View Post
I'm still getting a green bar and distorted colors in MPC-HC when refresh switches to 24HZ.
Try using a different decoder. Maybe that helps?

Quote:
Originally Posted by DigitalLF View Post
MadShi: i got a homemade 2:35:1 masking system and i use it on the lower part of my 16:9 screen and i would really like to see your seekbar to stay inside of the movie even when i resize 2:35:1 to 16:9 (ffdshow move blackbar to the lower part of the screen) would this be possible?? it would really mean alot to me
Properly supporting special projection setups is on my to do list (I have a CIH projection setup myself). I don't know if I will be able to comfortably support your special setup, though. Maybe yes, maybe no, can't say.

Quote:
Originally Posted by naoan View Post
Hi Madshi could you add hermite scaling (i.e. bicubic with b and c at 0, something like this http://svn.int64.org/viewvc/int64/re...c/kernels.html) to the scaling option of madvr please?
Why? Do you have sample images which show that it works better than the other resamplers in madVR? I'm a bit hesitant adding many more options. Don't want to make the settings dialog too complicated. So there better be a good reason to add a new filter, even if it's easy to implement (like this).

Quote:
Originally Posted by 6233638 View Post
That said, there doesn't seem to be any measure of aliasing, and sharpness is very low.
Exactly. That website doesn't mention/measure aliasing at all, and it's a very important aspect of resampling.

Quote:
Originally Posted by 6233638 View Post
Oh and there is a great example of why scaling should be done in linear light
That mostly applies to DOWNscaling, though. I'm not sure if linear light scaling brings much benefit for UPscaling, which is what most madVR users do.

Quote:
Originally Posted by CruNcher View Post
What do you think about the "Magic Kernel" ?
I've double checked that Lanczos image on that website and found that it was produced with a broken Lanczos implementation. A proper Lanczos implementation (like the one in madVR) easily beats that "Magic Kernel", IMHO.

Quote:
Originally Posted by Trumpetguy View Post
Since 0.61 a horizontal black or coloured (usually green) horizontal line appears after some time. It is about one pixel wide and stretches the entire width of the screen. I have also experienced a similar vertical line, and one time both at the same time. The line is only there in exclusive mode. The line disappears for some time after pausing or toggling between windowed and exclusive modes.
Things like this are often a result of a decoder <-> renderer miscommunication. Which decoder are you using? Try a different one. The MPC-HC internal decoders are especially notorious for making problems, in my experience.

Quote:
Originally Posted by Mikey2 View Post
I always assumed that "hardware decoding" is preferable, if not necessary, to achieve optimum viewing.
Glad you found the way to software decoding. Personally, I prefer it over hardware decoding.

Quote:
Originally Posted by leeperry View Post
anyways, there's one feature that would really rock: YV16/YV24 support
Funny. I've recently added YV16/YV24 support, and support for loads of other FourCC formats, too.

Quote:
Originally Posted by leeperry View Post
What I understood is that LaTo is stacking MSB/LSB 16bit into YV16/YV24...
Huh? YV16/YV24 are both strictly 8bit formats. There are several 16bit FourCC formats available, though, which the next madVR build will support.

Quote:
Originally Posted by leeperry View Post
Anyway, it would be great if we could find a "hack" that everyone would follow, so we could get >8bit post-processing in ffdshow.
Why implementing a hack if there's a proper solution available? Makes no sense to me.

Quote:
Originally Posted by mandarinka View Post
The good thing about this hack is that it can use the existing avisynth infrastructure normaly (with some avs2yuv effort you can even encode it in x264) without causing any new problems, it is purely filter/function-side solution (thus can be dropped later).

Naturaly, real 16bit colorspaces in avisynth would be better, but avisynth developers are busy enough and the development is slow already - 2.6 still isn't done after several years.

So... real 16bit needs rewrite of filters AND avisynth, this hack only needs rewrite of filters. Some of them are already available, and as long as plugin authors are willing, it can take off, because no messing with avisynth core is needed. (And modifying those plugins for non-hacky core 16bit probably won't be hard one day). Imho, for an "ugly hack", this has a beauty of its own.
I understand that this "hack" is a good thing for internal avisynth use. However, avisynth by itself does not output to DirectShow. IMHO, avisynth filters should use this hack (if there's no better way), but at the very end of the avisynth filter chain, before the data is fed into the DirectShow chain, the hacked data format should be converted to a proper 16bit FourCC. DirectShow supports proper 16bit formats, so it would be very easy to implement.

Quote:
Originally Posted by leeperry View Post
A full 16bit video pipeline, ouuuuh I like the sound of that
No problem at all. Just find someone who makes ffdshow accept that hacked YV16/24 data from avisynth and convert it to a proper 16bit format. That solution would work right away with the next madVR version.

I don't really feel like supporting a hacked data format in madVR. And honestly, I see no benefit of doing that. ffdshow does not output YV16/24 now, so you need to find someone to improve ffdshow, anyway. Instead of making your buddy add YV16/24 output support to ffdshow, make him convert the hacked YV16/24 data to a proper 16bit FourCC format. This should be *really* easy to do and then we'd have a proper ffdshow version with a proper and documented 16bit output, which would work perfectly fine with the next madVR version.
madshi is offline   Reply With Quote
Old 5th June 2011, 17:43   #7875  |  Link
SamuriHL
Registered User
 
SamuriHL's Avatar
 
Join Date: May 2004
Posts: 5,351
madshi, are there any commercial decoders out there that support proper 16bit FourCC that will work with the next version of madVR?
__________________
HTPC: Windows 11, AMD 5900X, RTX 3080, Pioneer Elite VSX-LX303, LG G2 77" OLED
SamuriHL is offline   Reply With Quote
Old 5th June 2011, 17:51   #7876  |  Link
Thunderbolt8
Registered User
 
Join Date: Sep 2006
Posts: 2,197
Quote:
Originally Posted by madshi View Post
Currently no. But probably yes, with a future madVR version. That will take some time, though.
that would be awesome, because im also stuck at 60Hz displays.
__________________
Laptop Lenovo Legion 5 17IMH05: i5-10300H, 16 GB Ram, NVIDIA GTX 1650 Ti (+ Intel UHD 630), Windows 10 x64, madVR (x64), MPC-HC (x64), LAV Filter (x64), XySubfilter (x64) (K-lite codec pack)
Thunderbolt8 is offline   Reply With Quote
Old 5th June 2011, 17:52   #7877  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Quote:
Originally Posted by SamuriHL View Post
madshi, are there any commercial decoders out there that support proper 16bit FourCC that will work with the next version of madVR?
I'm not aware of any, unfortunately. There are some high bit professional solutions, though. E.g. Video Editors with DirectShow interfaces or something like that. Also AVI and QuickTime movie files support high bitdepth uncompressed video storage. E.g. the samples from the following thread will play with full 10bit with LAV Splitter and the next madVR version:

http://forum.doom9.org/showthread.php?t=158836

Anyway, I don't like the Hen and Egg problem, so madVR comes first with full 10bit and 16bit support and with 4:2:0, 4:2:2 and 4:4:4 support. Hopefully decoders will follow. But of course for decoders it makes sense only if the encoded video stream is really native > 8bit or > 4:2:0.
madshi is offline   Reply With Quote
Old 5th June 2011, 18:05   #7878  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
madVR v0.62 released

http://madshi.net/madVR.zip

Code:
* added display "properties", "calibration" and "color & gamma" settings pages
* added option to define the native display bitdepth (affects dither strength)
* added options to define how the display was calibrated (gamut + gamma)
* moved "Video/PC levels" option to display "properties" settings page
* added options to define which gamma / transfer function to use
* replaced old "use 3dlut" option with new controls on "calibration" page
* added integrated GUI for yCMS 3dlut creation, no more console hacking needed
* added "please wait" dialog while yCMS is downloaded + installed
* added "please wait" dialog while 3dlut file is created
* added support for 6 and 7 bit 3dlut files (see trade quality for performance)
* added option to choose a manually created external 3dlut file (per display)
* there's only one 3dlut file per display now
* 3dlut is now always yRGB / RGB_Video input and RGB_Video output
* YCbCr -> RGB conversion is now always done by shader math, not by 3dlut
* Video/PC levels conversion is now always done by shader math, not by 3dlut
* rewritten rendering and pixel shader chain
* subsampled YCbCr is now upsampled & converted to RGB first, then scaled
* chroma upsampling got quite a bit faster (because it's now always exactly 2x)
* luma scaling got a tiny bit faster, depending on scaling factor and taps
* Strg+Alt+Shift+C displays & toggles color format (BT.709 -> BT.601 -> PAL)
* Strg+Alt+Shift+G displays and increases the Gamma value (2.20 -> 2.25 -> ...)
* Strg+Alt+Shift+F displays and decreases the Gamma value (2.20 -> 2.15 -> ...)
* Strg+Alt+Shift+T displays and changes the Gamma curve type (pure power / BT)
* dither is using a texture again instead of shader math
* dither is now colored and differs for every video frame
* added support for  8 bit 4:2:0 media types IYUV, I420, NV21, ICM*
* added support for  8 bit 4:2:2 media types YUY2, YVYU, UYVY, YV16, yuv2, ...
* added support for  8 bit 4:4:4 media types AYUV, YV24, I444, v308, v408
* added support for  8 bit RGB   media types RGB32, RGB24, BGRA, ABGR, RGBA
* added support for 10 bit 4:2:2 media types P210, Y210, v210
* added support for 10 bit 4:4:4 media types Y410, v410
* added support for 16 bit 4:2:2 media types P216, Y216, v216
* added support for 16 bit 4:4:4 media types Y416, v416
* added support for 16 bit RGB   media types RGB48, RGB64, b48r, b64a, ...
* added hints to "install.bat" and "readme.txt" to not delete the madVR folder
* fixed: madVR rendering window in GraphEdit didn't have correct size
* changed VSync priority back to "time critical"
* slightly changed tray icon mouse click behaviour
A couple of notes:

(1) Since a lot of stuff has changed internally, expect some new bugs.

(2) Some pixel shaders got a bit faster, but I've added a couple more processing steps. Not sure what the net effect will be. Maybe v0.62 will perform a little bit faster or slower for you, depending on settings.

(3) cyberbeing: Please check whether the 3dlut stuttering you have with out-of-gamut colors is gone when using a 7bit or 6bit 3dlut.

(4) 6233638: It was you who preferred Bicubic for chroma upscaling, correct? Please recheck your preferences with v0.62.

(5) Please note that madVR now accepts 4:2:2 connections. It is now *your* duty to make sure the decoder outputs the optimal format (which is usually 4:2:0).

(6) Below is the full list of FourCCs supported by v0.62. I'm looking for samples of AVI/QuickTime movie files with raw video data in as many of these FourCCs as possible, so I can test that my implementation of these FourCCs is correct. So if you have (or can create) any samples that could help, please upload (small) samples. Thanks!

Code:
// 8bit YCbCr
// 4:2:0
YV12
NV12
yv12
nv12
ICM1
ICM2
ICM3
ICM4
NV21
IYUV
I420
// 4:2:2
YUY2
yuy2
YVYU
UYVY
uyvy
cyuv
UYNV
UYNY
HDYC
uyv1
2Vu1
VDTZ
YUV2
yuv2
2vuy
2Vuy
yuvu
yuvs
YV16
I422
Y422
V422
Y42B
P422
YUNV
VYUY
AVUI
// 4:4:4
AYUV
YV24
I444
v308
v408

// RGB
// 8bit
RGB24
RGB32
24BG
BGRA
ABGR
RGBA
// 16bit
RGB48LE
RGB48BE
b48r
RGBA64LE
RGBA64BE
b64a

// 10bit YCbCr
// 4:2:0
P010
// 4:2:2
P210
Y210
v210
// 4:4:4
Y410
v410

// 16bit YCbCr
// 4:2:0
P016
// 4:2:2
P216
Y216
v216
// 4:4:4
Y416
v416
madshi is offline   Reply With Quote
Old 5th June 2011, 18:12   #7879  |  Link
SamuriHL
Registered User
 
SamuriHL's Avatar
 
Join Date: May 2004
Posts: 5,351
Quote:
Originally Posted by madshi View Post
I'm not aware of any, unfortunately. There are some high bit professional solutions, though. E.g. Video Editors with DirectShow interfaces or something like that. Also AVI and QuickTime movie files support high bitdepth uncompressed video storage. E.g. the samples from the following thread will play with full 10bit with LAV Splitter and the next madVR version:

http://forum.doom9.org/showthread.php?t=158836

Anyway, I don't like the Hen and Egg problem, so madVR comes first with full 10bit and 16bit support and with 4:2:0, 4:2:2 and 4:4:4 support. Hopefully decoders will follow. But of course for decoders it makes sense only if the encoded video stream is really native > 8bit or > 4:2:0.
Fascinating. Well, hopefully someday we'll get a decent, supported video decoder. This is a step in the right direction, though!
__________________
HTPC: Windows 11, AMD 5900X, RTX 3080, Pioneer Elite VSX-LX303, LG G2 77" OLED
SamuriHL is offline   Reply With Quote
Old 5th June 2011, 18:12   #7880  |  Link
Thunderbolt8
Registered User
 
Join Date: Sep 2006
Posts: 2,197
Quote:
Originally Posted by madshi View Post
(5) Please note that madVR now accepts 4:2:2 connections. It is now *your* duty to make sure the decoder outputs the optimal format (which is usually 4:2:0)
so when watching remuxed BDs with coreavc, anything I need to change in coreavc settings now?
__________________
Laptop Lenovo Legion 5 17IMH05: i5-10300H, 16 GB Ram, NVIDIA GTX 1650 Ti (+ Intel UHD 630), Windows 10 x64, madVR (x64), MPC-HC (x64), LAV Filter (x64), XySubfilter (x64) (K-lite codec pack)
Thunderbolt8 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 01:35.


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