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 11th May 2010, 22:19   #2621  |  Link
Mark_A_W
3 eyed CRT supporter
 
Join Date: Jan 2008
Location: Or-strayl-ya
Posts: 563
Directvobsub is working fine for me with madVR.
Mark_A_W is offline   Reply With Quote
Old 12th May 2010, 00:32   #2622  |  Link
cyberbeing
Broadband Junkie
 
Join Date: Oct 2005
Posts: 1,859
Quote:
Originally Posted by Mark_A_W View Post
Directvobsub is working fine for me with madVR.
Directvobsub is working fine for me as well 99.9% of the time, except for odd cases like above. Test a 712x304 video with VSFilter and you should also get a crash.
cyberbeing is offline   Reply With Quote
Old 12th May 2010, 00:44   #2623  |  Link
Mark_A_W
3 eyed CRT supporter
 
Join Date: Jan 2008
Location: Or-strayl-ya
Posts: 563
Ahhh, ok you were being specific, not a general comment about directvobsub.


I only watch 1920x1080, so haven't had that issue.
Mark_A_W is offline   Reply With Quote
Old 12th May 2010, 02:09   #2624  |  Link
leeperry
Kid for Today
 
Join Date: Aug 2004
Posts: 3,477
Quote:
Originally Posted by Jong View Post
Once MadVR is working as madshi intends, it will solve that initial judder problem and will either have slightly greater resilience (which you may not need), or massively greater, depending on whether he manages to pre-render several frames, as he intends.
well, I think there's also a container problem...because a 25fps MKV gives a dead stable jitter in HR, but a 23.976 MKV is one big jitter feast...getting 25fps@48Hz was dead easy, but 23.976@48 felt like rocket science

remux your 23.976 MKV to MP4 or AVI, and HR's jitter is dead stable....apparently MKV doesn't have a fixed framerate by design, so it seems to add even more jitter at the splitting stage....ah well watching 23.976fps MKV@48Hz is hopeless, I'm starting to lose faith.

FWIW, KMP's built-in MKV splitter seems far less jittery than Haali's.

Last edited by leeperry; 12th May 2010 at 03:53.
leeperry is offline   Reply With Quote
Old 12th May 2010, 08:40   #2625  |  Link
djsolidsnake86
Registered User
 
Join Date: Mar 2010
Posts: 139
Quote:
Originally Posted by cyberbeing View Post
Directvobsub is working fine for me as well 99.9% of the time, except for odd cases like above. Test a 712x304 video with VSFilter and you should also get a crash.
but it's a madvr bug, because with other renders there isn't this problem
djsolidsnake86 is offline   Reply With Quote
Old 12th May 2010, 10:25   #2626  |  Link
cyberbeing
Broadband Junkie
 
Join Date: Oct 2005
Posts: 1,859
Quote:
Originally Posted by djsolidsnake86 View Post
but it's a madvr bug, because with other renders there isn't this problem
Correct, madVR is the only renderer which produces a crash when using VSFilter with a 712x304 video. I was implying the use of madVR in my previous posts, but I guess I should have been a bit clearer, sorry.

Last edited by cyberbeing; 12th May 2010 at 10:27.
cyberbeing is offline   Reply With Quote
Old 12th May 2010, 10:31   #2627  |  Link
starla
Registered User
 
Join Date: Jan 2004
Posts: 56
Quote:
Originally Posted by madshi View Post
So will I add a Reclock mode? I'd say: Let's wait and see how well madVR's exclusive mode / Aero solutions will work. And then we can decide whether adding a madVR Reclock rendering mode is worth it.

Just to add some info on this discussion:

1) Jong suggest that Reclock is able to move the ::Present() return point. This is wrong, what reclock is able to do is to move the point that frame is scheduled (reference clock adjustment affects this). Why in some renderers the end position might seem to move is caused by the fact that v-sync is disabled completely (if AERO is on v-sync is always enabled by the OS itself). So when reclock is able to move the end point of presentation it is just moving the start point of presentation on a system where no v-sync is done (tearing is tried to remove by scheduling a sample to be presented on a time when no screen update is done and the newly drawn frame wont update memory while the RAMDAC is "copying the data to screen").

2) Why Reclock (or any other audio renderer that is capable of resampling audio + modifying the reference clock) is required even when you would have perfect video renderer code? Audio and video chips have different time sources (even on latest GPUs that contain audio chip as well). If audio and video clocks drift away more than few ms during the two hour length movie video renderer is required to drop or duplicate a frame since you aren't able to present the video frame on a correct v-sync.

I'm personally currently experimenting with the MPC-HC audio render code base and turning it into open source reclock replacement (no guarantees that it will ever be ready ). If that wont work we would need to ask James from Slysoft to allow video renreder to advice the reclock on few things to make the video renderers actually compatible with reclock.

--
tourettes / MediaPortal dev

Last edited by starla; 12th May 2010 at 10:36.
starla is offline   Reply With Quote
Old 12th May 2010, 10:49   #2628  |  Link
Grmpf
Registered User
 
Join Date: Apr 2009
Posts: 37
Quote:
Originally Posted by starla View Post
2) Why Reclock (or any other audio renderer that is capable of resampling audio + modifying the reference clock) is required even when you would have perfect video renderer code? Audio and video chips have different time sources (even on latest GPUs that contain audio chip as well). If audio and video clocks drift away more than few ms during the two hour length movie video renderer is required to drop or duplicate a frame since you aren't able to present the video frame on a correct v-sync.
You can eleminate this by having very tight timings, sure thats not very convenient for 99% of the userbase, but there is for example a script out there (www.d65.de - be aware its german ! - from the author of eventghost), that lets you optimize your timings (ATi hardware + Powerstrip recommended), so you reduce the drift to get no drops/repeats anymore for many hours straight playing. I optimized my timings to get not a single drop/repeat for over 13h playing 23.976/24.000/50.000/59.940hz content.
Grmpf is offline   Reply With Quote
Old 12th May 2010, 11:03   #2629  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Quote:
Originally Posted by starla View Post
1) Jong suggest that Reclock is able to move the ::Present() return point. This is wrong, what reclock is able to do is to move the point that frame is scheduled (reference clock adjustment affects this). Why in some renderers the end position might seem to move is caused by the fact that v-sync is disabled completely (if AERO is on v-sync is always enabled by the OS itself). So when reclock is able to move the end point of presentation it is just moving the start point of presentation on a system where no v-sync is done (tearing is tried to remove by scheduling a sample to be presented on a time when no screen update is done and the newly drawn frame wont update memory while the RAMDAC is "copying the data to screen").
Thanks, that makes sense.

Quote:
Originally Posted by starla View Post
2) Why Reclock (or any other audio renderer that is capable of resampling audio + modifying the reference clock) is required even when you would have perfect video renderer code? Audio and video chips have different time sources (even on latest GPUs that contain audio chip as well). If audio and video clocks drift away more than few ms during the two hour length movie video renderer is required to drop or duplicate a frame since you aren't able to present the video frame on a correct v-sync.
Yes, I'm aware of this problem. I do have some ideas on how to work around the problem in madVR alone, without needing audio manipulation. But I'm not sure yet how well it will work, and I also don't know how long it will take for me to find the time to actually implement my ideas.

Quote:
Originally Posted by starla View Post
I'm personally currently experimenting with the MPC-HC audio render code base and turning it into open source reclock replacement (no guarantees that it will ever be ready ).
Well, that's *great* news! I was kind of wishing for someone to start investing time into creating a high quality audio renderer. So I'm happy to hear about your plans.

If you don't mind, I'd like to make a suggestion: Maybe you could start by making the MPC-HC audio renderer work as well or better than any other renderer, before starting to add Reclock like logic to it? As far as I've read, currently some audio renderers are better than others, depending on some specific circumstances. If you could make the MPC-HC audio renderer best in all circumstances, that would be a great start!

Let me point you to a problem with Reclock. This is a quote from an email yesgrey sent me. I think (hope) yesgrey won't mind me posting it here:

Quote:
The problem with reclock, and the only thing that still bothers me and could make me switch for another audio renderer in the future, is that it cannot use the soundcard's clock as the reference clock.
Reclock creates its own reference clock from the System clock, and then the video is synchronized with it and the audio is resampled to keep the sync with video.
When we bypass the resampling, the audio clock is not synchronized with the video clock, so, it will only be in sync with video if the soundcard clock does not deviate too much from the video clock.
That's not the ideal solution, but there is not any better option available.
The Microsoft Audio Renderer, works exactly like I want, using the soundcard clock as the reference, but it doesn't use Kernel Streaming nor WASAPI Exclusive, like Reclock does, so it cannot bypass kmixer, and to have audio resampled, I prefer Reclock.;-)
With my current method, I might get one or two audio glitches while watching a movie, when reclock has to drop a few audio samples to resync the audio with the video, but it's not an issue.
I'm still waiting for the perfect Audio Renderer. If I knew how, I would write it myself exactly like I have described above...
Now MPC-HC also has its Audio Renderer and uses WASAPI, but it seems to not be working like I want to.
Would be great if you could make sure that the MPC-HC audio renderer properly uses the audio hardware's clock (in "non-Reclock mode"). Not sure which clock the MPC-HC audio renderer currently uses. Of course for a Reclock clone you'd need to use your own clock instead of the audio hardware clock, but for people who don't want audio to be resampled (I'm one of them), it would be great if "your" new audio renderer could be switched to a "non-Reclock" mode, which should then behave as normal renderers do (using the audio hardware clock).
madshi is offline   Reply With Quote
Old 12th May 2010, 11:50   #2630  |  Link
yesgrey
Registered User
 
Join Date: Sep 2004
Posts: 1,295
Quote:
Originally Posted by madshi View Post
Let me point you to a problem with Reclock. This is a quote from an email yesgrey sent me. I think (hope) yesgrey won't mind me posting it here:
No problem.
I just want to add that I still think reclock is a great audio renderer, and essential for people who wants smooth video.
There are two kind of users: those who prefer small glitches in audio and none in video (reclock users), and those who prefer small glitches in video and none in audio, and for this last group (where I'm included), there isn't any solution available, yet.

Last edited by yesgrey; 12th May 2010 at 11:55.
yesgrey is offline   Reply With Quote
Old 12th May 2010, 13:04   #2631  |  Link
Jong
Registered User
 
Join Date: Mar 2007
Location: London, UK
Posts: 576
Quote:
Originally Posted by starla View Post
Just to add some info on this discussion:
Hi tourettes, good to see you here.
Quote:
Originally Posted by starla View Post
....Jong suggest that Reclock is able to move the ::Present() return point. This is wrong, what reclock is able to do is to move the point that frame is scheduled (reference clock adjustment affects this). Why in some renderers the end position might seem to move is caused by the fact that v-sync is disabled completely (if AERO is on v-sync is always enabled by the OS itself). So when reclock is able to move the end point of presentation it is just moving the start point of presentation on a system where no v-sync is done
If this is what you took from my posts it is a misunderstanding. I believe what you and I are saying is the same. Specifically I said:
Quote:
Originally Posted by Jong View Post
By default all such renderers appear to do as I suggested a few days ago. The first frame appears ASAP after it is 'ready' and frames follow an appropriate period later, with no regard to vsync.

As a consequence of both the above "end present" also bears no regard to vsync and, without help, all such renderers are vulnerable to synchronised judder if using a front and back buffer.

By varying the reference clock ever so slightly (say 0.1%, actually the adjustment is greater the further from the target the current measured position is) Reclock is able to move the point frames are ready/due, hence "Present()", hence the point this returns. Once the measured position is inside the Reclock target correction is turned off and the frame rate returns to normal.
I believe that is the same as what you are saying. If you can point to a post that says Reclock explicitly defines the point "Present()" returns, or implies it, I will happily change it. However, what is definitely true is the way it decides it needs to make a correction is by measuring "end of presentation" and if this point is pinned, eg. to vsync, as in windowed mode, Reclock vsync correction cannot work.
Quote:
Originally Posted by starla View Post
.....So when reclock is able to move the end point of presentation it is just moving the start point of presentation on a system where no v-sync is done (tearing is tried to remove by scheduling a sample to be presented on a time when no screen update is done and the newly drawn frame wont update memory while the RAMDAC is "copying the data to screen").
If I am reading this right then this is wrong.

The confusion comes because there are two things people mean when they talk of "controlling vsync".

To some this means avoiding tearing e.g. by use of a back buffer and flipping front and back buffers during vsync. This is typically what is meant by the "vsync" setting in GPU drivers. Whilst, normally, eliminating tearing this directly causes the problem of synchronised frame rate/refresh rate judder for video (http://software.intel.com/en-us/arti...nchronization/). When Reclock talks of controlling vsync, and what we are mostly discussing here, is ensuring presentation is not so close to this flip that synchronised judder can occur.

Reclock vsync correction is incompatible with renderers that either always return from"Present()" after vsync (i.e. normal windowed mode) or, if not, if they themselves attempt to position "Present()" and thus themselves pin its return a fairly fixed duration afterwards. However, if "Present()" returns immediately after it is complete as in exclusive or Aero modes it is perfectly fine that a back buffer and hardware flip is also used to avoid tearing.

So, using Reclock vsync correction does not require that presentation occurs during vBlank. In fact specifically it requires that it occurs a safe distance away from vBlank. This safe position is much more tolerant and carries a much lower risk of tearing. The "Present()" call can basically occur anywhere from about -18ms to -6ms @50Hz, or ~-14ms to -6ms @60Hz, with current compatible renderers and their workload (MadVR may need a little more margin at the lower end?)

Last edited by Jong; 12th May 2010 at 15:51. Reason: punctuation!
Jong is offline   Reply With Quote
Old 13th May 2010, 00:25   #2632  |  Link
bozydar
Registered User
 
Join Date: Jan 2008
Posts: 8
Quote:
Originally Posted by madshi View Post
From what I've read in the projector forums, more projectors are having problems with YCbCr than with RGB.
I cannot comment on projectors, but all tv-sets that I tested (Pioneer’s Kuros, two Panasonic plasmas, couple of LG and Samsung LCDs) process pictures in YCbCr space. I am not sure about Panasonic, but rest of them are using YCbCr 4:2:2 or even 4:2:0 by default. There is much easier to do things like contrast, hue, saturation or basic CMS in YCbCr space. Also all the normal sources (DVD, Blu-ray, satellite tv, etc.) are using at best YCbCr 4:2:2, so there is no need to waste silicon on full processing in 4:4:4. Kuros and some Samsungs can be switched to 4:4:4 mode, but this disables almost all controls on tv (like CMS). I am not sure if this disables conversion from RGB to YCbCr…

RGB to YCbCr (4:2:2 or 4:2:0) conversion can be easily confirmed by playing FULL-HD full resolution color test patterns on any FULL-HD TV in 1:1 pixel mapping mode.
bozydar is offline   Reply With Quote
Old 13th May 2010, 03:54   #2633  |  Link
Hypernova
Registered User
 
Join Date: Feb 2006
Posts: 293
With 0.12 I can play 1080p on my monitor (2560x1600) using spline64 "smoothly" (not smooth as in what others are talking about, just no obvious skipping frames) using my 3870. This is super awesome. Thank you madshi!

Now I only have to wait for subtitle (pin) support and I'll be a happy panda.
__________________
Spec: Intel Core i5-3570K, 8g ram, Intel HD4000, Samsung U28D590 4k monitor+1080p Projector, Windows 10.
Hypernova is offline   Reply With Quote
Old 13th May 2010, 04:58   #2634  |  Link
leeperry
Kid for Today
 
Join Date: Aug 2004
Posts: 3,477
yes, 0.12 is really solid here...no freezing on seek, no more error msg in the event viewer...just pure bliss, the smoothness is really extraordinary...and did I mention the colorimetry

my CRT has almost a perfect SMPTE-C gamut, so I don't even bother w/ a LUT..96Hz in Reclock/KS and the PQ/SQ are just astounding

I'm forced to use this on upscaled SD, but I guess that's fine?
Code:
ColorMatrix(mode="Rec.601->Rec.709",clamp=0,opt=0)

Last edited by leeperry; 13th May 2010 at 05:01.
leeperry is offline   Reply With Quote
Old 13th May 2010, 08:06   #2635  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Quote:
Originally Posted by bozydar View Post
I cannot comment on projectors, but all tv-sets that I tested (Pioneer’s Kuros, two Panasonic plasmas, couple of LG and Samsung LCDs) process pictures in YCbCr space. I am not sure about Panasonic, but rest of them are using YCbCr 4:2:2 or even 4:2:0 by default. There is much easier to do things like contrast, hue, saturation or basic CMS in YCbCr space.
True. But do these displays convert RGB input back to YCbCr? Or do they disable brightness/contrast/CMS controls with RGB input? Even if they do convert RGB back to YCbCr and then back to RGB, at least they will probably use the same matrix for both conversions, so the colors should stay correct.

Quote:
Originally Posted by bozydar View Post
Also all the normal sources (DVD, Blu-ray, satellite tv, etc.) are using at best YCbCr 4:2:2, so there is no need to waste silicon on full processing in 4:4:4. Kuros and some Samsungs can be switched to 4:4:4 mode, but this disables almost all controls on tv (like CMS). I am not sure if this disables conversion from RGB to YCbCr…
If they are converting from RGB back to YCbCr 4:2:2, that means that some part of madVR's chroma upsampling quality is lost. That would be really sad. I do think that newer processing chips (future versions of Gennum VXP and HQV Realta chips etc) are likely to go 4:4:4, probably even 16bit. So I think in the long run downconverting to YCbCr 4:2:2 in the display should be a thing of the past. If you think about it, it should be considered a display "bug", if it converts 4:4:4 input to 4:2:2. After all, if a computer is connected to the display, the computer sends 4:4:4. If an XBox or PS3 is connected, they also usually send 4:4:4, too. So basically a display which internally downconverts all input data to 4:2:2 should be considered faulty, cause it definitely loses quality for computer and game input content.

Quote:
Originally Posted by Hypernova View Post
Now I only have to wait for subtitle (pin) support and I'll be a happy panda.
Well, I've asked in this thread and in the MPC-HC thread about information about how a subtitle pin is supposed to work, but nobody bothered to provide me with *any* information. So right now I've no idea what madVR needs to do, technically, to provide that subtitle pin.

Quote:
Originally Posted by leeperry View Post
I'm forced to use this on upscaled SD, but I guess that's fine?
Code:
ColorMatrix(mode="Rec.601->Rec.709",clamp=0,opt=0)
I don't know what ColorMatrix does exactly, so I can't comment on that.
madshi is offline   Reply With Quote
Old 13th May 2010, 08:36   #2636  |  Link
Hypernova
Registered User
 
Join Date: Feb 2006
Posts: 293
Quote:
Originally Posted by madshi View Post
Well, I've asked in this thread and in the MPC-HC thread about information about how a subtitle pin is supposed to work, but nobody bothered to provide me with *any* information. So right now I've no idea what madVR needs to do, technically, to provide that subtitle pin.
Yes, I've seen them and worried about this getting lost in all other technicals discussiong, that's half the reason why I post my result with 0.12.

Hopefully someone can help you with that soon. (maybe tetsuo55?)
__________________
Spec: Intel Core i5-3570K, 8g ram, Intel HD4000, Samsung U28D590 4k monitor+1080p Projector, Windows 10.
Hypernova is offline   Reply With Quote
Old 13th May 2010, 12:37   #2637  |  Link
XhmikosR
Registered User
 
Join Date: Mar 2007
Location: Hellas (Greece)
Posts: 543
Quote:
Originally Posted by madshi View Post
Well, I've asked in this thread and in the MPC-HC thread about information about how a subtitle pin is supposed to work, but nobody bothered to provide me with *any* information. So right now I've no idea what madVR needs to do, technically, to provide that subtitle pin.
Sorry about that, but the people who can provide you this kind of info are very few. You can try contacting Casimir or ar-jar.
__________________
My Specs
XhmikosR is offline   Reply With Quote
Old 13th May 2010, 14:26   #2638  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Quote:
Originally Posted by XhmikosR View Post
Sorry about that, but the people who can provide you this kind of info are very few. You can try contacting Casimir or ar-jar.
Thank you! I'll do that...
madshi is offline   Reply With Quote
Old 13th May 2010, 17:27   #2639  |  Link
Keiyakusha
契約者
 
Keiyakusha's Avatar
 
Join Date: Jun 2008
Posts: 1,576
Quote:
Originally Posted by leeperry View Post
I'm forced to use this on upscaled SD, but I guess that's fine?
Code:
ColorMatrix(mode="Rec.601->Rec.709",clamp=0,opt=0)
Yes. The same thing with EVR. Renderer doesn't know if stream upscaled or not...
Keiyakusha is offline   Reply With Quote
Old 13th May 2010, 20:11   #2640  |  Link
pirlouy
_
 
Join Date: May 2008
Location: France
Posts: 692
Quote:
Originally Posted by XhmikosR View Post
Sorry about that, but the people who can provide you this kind of info are very few. You can try contacting Casimir or ar-jar.
I don't think ar-jar deals with subtitles. He just uses default subtitles integration for EVR.

The truth is there is not really someone who works on subtitles. Tetsuo55 or clsid already explains that even the actual system is buggy, even if it works. Maybe MPC-HC changelog can help Madshi, but I'm not sure.

There's this project which can help: http://blog.aegisub.org/2009/02/kuma...28634171132037
pirlouy 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 04:48.


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