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 12th May 2009, 01:17   #961  |  Link
flanger216
Registered User
 
Join Date: Mar 2004
Posts: 140
Quote:
Originally Posted by Grmpf View Post
And you are going for a "Release Candidate" of an "Operating System" madshi ? I don't know, i wouldn't use something like this even if you would give me money for it... but i guess if you're a software developer you have to live with it.
Dude... they're just words. The Windows 7 RC is vastly more stable over Vista for many users, so who cares if it's called a 'release candidate?' They could call it the 'This Will Crash' version, and I'd still use it if it were functionally more stable than the alternatives.
flanger216 is offline   Reply With Quote
Old 12th May 2009, 04:45   #962  |  Link
racerxnet
Registered User
 
Join Date: Jul 2004
Location: ILLINIOS
Posts: 50
Quote:
Another reason why I don't plan to look into super resolution is that I don't want to spend too much time on scaling, because my main priority is Blu-Ray playback, anyway, and scaling is usually not needed there...

It's is great that you are providing this software to all of us and appreciated, but the majority of us still use SD DVD as the titles are just not out there on BR. This is a fact that should not be overlooked.

As well, the major OS is still XP. We all know Vista was a flop and 7 is still in Beta stage. Slysoft player will dominate the marketplace once it is available as freeware if it will support Xp and Vista. Your product is good, but watch where you tread. The dominant force is XP and Sd DVD. Support what you want at your own risk. It'll be a cold day in hell before I replace 600 DVD's with BR titles. Hopefully you will address the smooth playback and not spend the next several months on perfecting last 2% regarding color fidelity. Other areas need to be focused on as well. Once again, thanks for the software. It has worked well for me on my system as long as I do not use spline 64. Otherwise it tears.

My .02

MAK

Last edited by racerxnet; 12th May 2009 at 04:50.
racerxnet is offline   Reply With Quote
Old 12th May 2009, 06:26   #963  |  Link
Hypernova
Registered User
 
Join Date: Feb 2006
Posts: 293
Quote:
Originally Posted by flanger216 View Post
Dude... they're just words. The Windows 7 RC is vastly more stable over Vista for many users, so who cares if it's called a 'release candidate?' They could call it the 'This Will Crash' version, and I'd still use it if it were functionally more stable than the alternatives.
Easy . Just say "give it a try" and be done with it. Let people decide for themselves if they like it or not.

Quote:
As well, the major OS is still XP. We all know Vista was a flop and 7 is still in Beta stage. Slysoft player will dominate the marketplace once it is available as freeware if it will support Xp and Vista. Your product is good, but watch where you tread. The dominant force is XP and Sd DVD. Support what you want at your own risk. It'll be a cold day in hell before I replace 600 DVD's with BR titles. Hopefully you will address the smooth playback and not spend the next several months on perfecting last 2% regarding color fidelity. Other areas need to be focused on as well. Once again, thanks for the software. It has worked well for me on my system as long as I do not use spline 64. Otherwise it tears.
I won't comment on XP/Vista/7 (you can't tell I like 7>Vista>>>XP? ), but maybe that 2% is the reason madshi start this project in the first place? Now, if it's 0.0002% then maybe he should stop worrying, but 2%? I think he already did better than that
__________________
Spec: Intel Core i5-3570K, 8g ram, Intel HD4000, Samsung U28D590 4k monitor+1080p Projector, Windows 10.
Hypernova is offline   Reply With Quote
Old 12th May 2009, 08:06   #964  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Quote:
Originally Posted by mark0077 View Post
If you need a definition you can look it up for yourself.
I know perfectly well what the term jitter means. I didn't ask for a definition.

Quote:
Originally Posted by mark0077 View Post
don't be so rude when people try to interpret what you could have looked up for yourself.
Maybe I was rude. But you flat out ignored what I wrote. I explicitly asked for expert feedback on jitter only, and I explicitly pledged end users to *NOT* post their guesses and experiences. And you ignored that.

The reason why I've been trying to cut replies to my jitter question down is that I'm doing all this in my free time - which is very limited and very precious to me. Having to read through and reply to posts which I explicitly asked for *not* to happen, is annoying to me because it feels to me like you'd disrespect the value of my time.

Quote:
Originally Posted by mark0077 View Post
Everyones trying to help you out but you make it difficult.
You can't help out except if you have behind the scenes knowledge that I do not have. Actually you're doing the opposite of helping out right now: I've now spent 30 minutes on replying to your jitter posts, which are lost for madVR development. Every minute I spend on posting in the forums is lost on madVR development!

You do can help out if you report bugs like this:

Quote:
Originally Posted by mark0077 View Post
This happens with various decoders, ffsdhow libavcodec, ffdshow libmpeg2. Let me know if I can test any other decoders / settings to find the source of the offsets I am seeing.
It doesn't seem to happen for me. Could you please post one exact example where the problem occurs with the following information: (1) source resolution (2) source codec (3) decoder used (4) display resolution? Thanks.

Quote:
Originally Posted by leeperry View Post
an email to Haali you should drop then.
Haali doesn't reply to my emails.

Quote:
Originally Posted by honai View Post
Here's what happens when switching chroma upsampling to Lanczos8: Basically the first block stays the same, the second:

max gpu rendering time ... fluctuates between 15ms and 22ms
resample textures ... fluctuates between 9.5ms and 13ms

The rest stays almost the same.

When also selecting Lanczos8 for luma, max gpu rendering time fluctuates between 22ms and 24ms, and resample textures is almost fixed at 17ms.
"Resample textures is almost fixed at 17ms". Is that average or max gpu? Generally I'm mostly interested in average gpu rendering times. How do they compare between using the default madVR options (SoftCubic50/100) and using Lanczos8/Lanczos8? Thanks...

Quote:
Originally Posted by racerxnet View Post
It's is great that you are providing this software to all of us and appreciated, but the majority of us still use SD DVD as the titles are just not out there on BR. This is a fact that should not be overlooked.
AFAIK madVR already provides the best quality scaling you can get in the HTPC world right now. With some more tweaks to come, some of which even current top quality hardware (like Gennum VXP and HQV Realta) doesn't offer. What more do you expect!?

Quote:
Originally Posted by racerxnet View Post
As well, the major OS is still XP.
I don't recall having said that I would stop supporting XP...

Quote:
Originally Posted by racerxnet View Post
Hopefully you will address the smooth playback
Fixing showstopper bugs (if any), smooth playback and DVD playback are my current top priorities.
madshi is offline   Reply With Quote
Old 12th May 2009, 08:58   #965  |  Link
Leak
ffdshow/AviSynth wrangler
 
Leak's Avatar
 
Join Date: Feb 2003
Location: Austria
Posts: 2,441
Quote:
Originally Posted by mark0077 View Post
I think is where alot of users want to see the renderer taking responsibility for these tiny adjustments, ie 23.976fps -> 24fps conversions to bring jitter to 0.
And how exactly is the (video!) renderer supposed to keep audio and video in sync in that case?

Sure, it can just display 24 instead of 23.976 frames per second, but I'm pretty sure everyone and their dog will whine that the audio starts lagging behind more and more over time - and even if there was an accompanying audio renderer that resampled the audio accordingly (why hello there, Reclock) some other audiophile nut-group would start whining about the playback not being "bit-perfect" (meh) anymore.

It's a lose-lose situation where no side can win unless (some) people finally grasp that you'll have to sacrifice a small bit of audio quality for your playback to be totally smooth.

Adjusting the audio to match the video speed is easy, adjusting the video to match the audio speed is hard, CPU-intensive and prone to much more noticeable artifacts than just a slight pitch variation.
__________________
now playing: [artist] - [track] ([album])

Last edited by Leak; 12th May 2009 at 09:02.
Leak is offline   Reply With Quote
Old 12th May 2009, 09:27   #966  |  Link
mark0077
Registered User
 
Join Date: Apr 2008
Posts: 1,106
Quote:
Originally Posted by Leak View Post
And how exactly is the (video!) renderer supposed to keep audio and video in sync in that case?

Sure, it can just display 24 instead of 23.976 frames per second, but I'm pretty sure everyone and their dog will whine that the audio starts lagging behind more and more over time - and even if there was an accompanying audio renderer that resampled the audio accordingly (why hello there, Reclock) some other audiophile nut-group would start whining about the playback not being "bit-perfect" (meh) anymore.

It's a lose-lose situation where no side can win unless (some) people finally grasp that you'll have to sacrifice a small bit of audio quality for your playback to be totally smooth.

Adjusting the audio to match the video speed is easy, adjusting the video to match the audio speed is hard, CPU-intensive and prone to much more noticeable artifacts than just a slight pitch variation.
Yep exactly, I suppose its a matter of preference in this case. Where in my case at 60hz its impossible to ever get perfect output, I decide to settle for the 23.976 @ 24hz approach which apparantly plays the audio at the original pitch....

So are you suggesting ... well what I said earlier, that things like rate changes should be handled externally, ie not by the renderers.

Last edited by mark0077; 12th May 2009 at 09:43.
mark0077 is offline   Reply With Quote
Old 12th May 2009, 09:31   #967  |  Link
nlnl
Registered User
 
Join Date: Aug 2008
Posts: 176
Quote:
Originally Posted by nlnl View Post
Nvidia 9400 IGP, MPC-НC 1095, Directx 10.0(6.0.6000.16386)
Vista 32

MadVR can not detect correctly display refresh rate with new driver Nvidia 185.85 (By the way driver properties in control panel say "compatible Windows 7 display driver", so can it output 30/36 bit RGB? Is there any card supporting deep color?).
Using 182.08 everything was OK.

Nvidia 182.08
display estimate 1: 24.97Hz
display estimate 2: 23.976Hz
display estimate 3: 23.976Hz (absolutly stable)
display 23.976 (absolutly stable)

Nvidia 185.85
Aero ON
display estimate 1: 24.97Hz
display estimate 2: 23.976Hz
display estimate 3: 26.976Hz (unstable)
display 27.976 (1s) (unstable)
Aero OFF
display estimate 1: 24.97Hz
display estimate 2: 0.0Hz
display estimate 3: 0.0Hz
display 55.9 (1s)
madshi
Quote:
Gigabyte microATX board with NVidia 9300 chipset + Q9650 + ATI 4770. That will allow me to test both NVidia + ATI.
Can your detect correct display refresh rate with new driver Nvidia 185.85 + Win 7 ( 182.08 + Vista32 was OK for my config)?
nlnl is offline   Reply With Quote
Old 12th May 2009, 11:02   #968  |  Link
honai
Guest
 
Posts: n/a
Quote:
Originally Posted by madshi
"Resample textures is almost fixed at 17ms". Is that average or max gpu? Generally I'm mostly interested in average gpu rendering times. How do they compare between using the default madVR options (SoftCubic50/100) and using Lanczos8/Lanczos8? Thanks...
It's max GPU. The average fluctuates a lot, but I'd say from SoftCubic to Lanczos8 it's, surprisingly, within the margin of error.

Another observation with the 4770, which in the past I also had with a 3450: It seems the card does automatic over-/underclocking, and depending on the load of the 3D-circuitry increases or decreases GPU clock. In the past this had severe consequences for video playback. While the idea of saving power when not playing 3D games might be nice, for HTPC it's not practical because the load produced by e.g. madVR's postprocessing seems to confuse that logic and make it fluctuate between the two states, i.e. no load and full load.

I'll post the averages tonight.
  Reply With Quote
Old 12th May 2009, 14:25   #969  |  Link
racerxnet
Registered User
 
Join Date: Jul 2004
Location: ILLINIOS
Posts: 50
Madshi,

Thank you for the response. I'll not waste your time anymore..

MAK
racerxnet is offline   Reply With Quote
Old 12th May 2009, 14:40   #970  |  Link
Jong
Registered User
 
Join Date: Mar 2007
Location: London, UK
Posts: 576
Quote:
Originally Posted by leeperry View Post
it's dependent on the VSYNC fliptime too, coz if the video renderer doesn't catch it spot-on to begin with....it will worsen and worsen overtime and it'll be so late after 45/60' that it will drop frames constantly to catch up...which is exactly what happens w/ each and every video renderer on XP(yours/VRM/EVR/HR/all of them really).
Dangerous even to step into this , but this isn't what happens (I firmly believe!). What happens is eventually the "end present" time gets so close to the flip time that the small differences in arrival time from frame to frame (say ~2ms) are sometimes on one side of the flip and sometimes on the other. And if the frame rate and refresh rate are almost exact multiples of each other and the presenter is a good one this situation can go on and on and on. On my PC it can easily take >45mins to get out of this state once in it.

Madshi, I do not know if you have seen this article: http://software.intel.com/en-us/arti...nchronization/.

By the way, Madshi, I agree with you provided the changes in arrival time are not sufficient to pass backwards and forwards over the flip time they are irrelevant. It is important though to make sure the "end present" time is away from the flip time when playback starts and is kept away from it throughout playback. Most renderers/presenters make no effort at all to define this "end present" time, it is essential random after each seek. the time till a problem occurs then depends on how tightly the frame rate and refresh rate match and how accurately they are maintained.

Last edited by Jong; 12th May 2009 at 14:45.
Jong is offline   Reply With Quote
Old 12th May 2009, 14:57   #971  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Quote:
Originally Posted by nlnl View Post
Can your detect correct display refresh rate with new driver Nvidia 185.85 + Win 7 ( 182.08 + Vista32 was OK for my config)?
I've no idea, I have an ATI card. Please wait for the next version and then retry...

Quote:
Originally Posted by honai View Post
I'd say from SoftCubic to Lanczos8 it's, surprisingly, within the margin of error.
Good!

Quote:
Originally Posted by Jong View Post
What happens is eventually the "end present" time gets so close to the flip time that the small differences in arrival time from frame to frame (say ~2ms) are sometimes on one side of the flip and sometimes on the other.
Ok, that makes sense. I plan to use two totally different presentation logics in madVR: One for situations where source frame rate and display refresh rate don't match. And one for situations where they do match (1:1 or 2:1 etc). In the latter case I plan to strictly show one frame per VSync (or every other VSync), regardless of timestamps. Only if timestamps stray away too much madVR will drop or repeat a frame in that mode. So the problem you described should not occur in madVR's 1:1 mode. Please note that it might take a while until I actually get around implementing all this...
madshi is offline   Reply With Quote
Old 12th May 2009, 15:05   #972  |  Link
Jong
Registered User
 
Join Date: Mar 2007
Location: London, UK
Posts: 576
Quote:
Originally Posted by madshi View Post
Ok, that makes sense. I plan to use two totally different presentation logics in madVR: One for situations where source frame rate and display refresh rate don't match. And one for situations where they do match (1:1 or 2:1 etc). In the latter case I plan to strictly show one frame per VSync (or every other VSync), regardless of timestamps. Only if timestamps stray away too much madVR will drop or repeat a frame in that mode. So the problem you described should not occur in madVR's 1:1 mode. Please note that it might take a while until I actually get around implementing all this...
You may know better! If so, I apologize! But, from experience with other renderers I am not sure they know anything is wrong. Maybe it is just that they are not looking, but they might be very strictly delivering one frame per vsync but if sometimes, due to small variances, that actually arrives one side of the flip or other (see figure 5 in the Intel document) the result is horrible judder - frames repeated for two vsync intervals then frames being missed altogether (because one arrived just after vsync and the next just before the next). There is still one frame per vsync on average over a couple of frames and within, say, 2ms, but still anything but smooth playback! VMR9 stats certainly do not record any dropped frames when the judder is absolutely ghastly because of this issue. I think the only solution is to keep the "end present" time well away from the flip time. I think Beliyaal is trying to keep it to around line 200 on a 1080p screen with his EVR CP enhancements. The Intel document may have another way involving some kind of predictive logic that I never spent enough time to get my head around!

Last edited by Jong; 12th May 2009 at 15:19.
Jong is offline   Reply With Quote
Old 12th May 2009, 16:10   #973  |  Link
leeperry
Kid for Today
 
Join Date: Aug 2004
Posts: 3,477
Quote:
Originally Posted by Jong View Post
from experience with other renderers I am not sure they know anything is wrong.
yep! either Aero or exclusive mode on XP make sure that the hardware layer(that knows) watches over the software video renderers(well HR knows what's going on, but doesn't care...Haali didn't use Reclock at all)

anyway, I'm also talking from experience...so I'll simply shut it, and hope some software engineers will offer technical clues

Last edited by leeperry; 12th May 2009 at 16:15.
leeperry is offline   Reply With Quote
Old 12th May 2009, 16:17   #974  |  Link
tetsuo55
MPC-HC Project Manager
 
Join Date: Mar 2007
Posts: 2,317
From what i read about jitter, if madVR buffers as many frames as logical and then presents them at the exact right moment there should be near 0 video jitter. (and currently madVR already does this to the best of its current ability). What the right moment is depends on a lot of things (most of which madVR already seems to have covered), i however cannot list them.

This however does nothing for audio jitter or a-v sync jitter.

Fixing audio jitter requires an audio renderer that presents the samples at exactly the right moment so there is near 0 audio jitter.

To get A-V sync perfect both should work together intensively.
Timing not only their individual perfect presentation moment but also how the 2 relate to each other.

I don't think madshi is interested in that last part at all.
tetsuo55 is offline   Reply With Quote
Old 12th May 2009, 16:43   #975  |  Link
honai
Guest
 
Posts: n/a
From memory, Beliyaal once explained that, actually, jitter is the only way to achieve smooth playback as long as the jitter (=deviation of display time from presentation time in the stream) oscillates within a margin such that, statistically, the average achieved fps is very close to the desired fps, and the display time deviates below the perception threshold of omitted/duplicated frames. Which means that when playing a 24000/1001 video on a 59.xyz refresh rate display, it's actually necessary to alternate between 59.x1 and 60.x2 to achieve the perception of smooth playback.

I think the basic algorithm is close to what eac3to does when repacking VC-1 streams in MKV and therefore calculating timestamps.

Last edited by honai; 12th May 2009 at 17:14.
  Reply With Quote
Old 12th May 2009, 16:54   #976  |  Link
Jong
Registered User
 
Join Date: Mar 2007
Location: London, UK
Posts: 576
Quote:
Originally Posted by leeperry View Post
yep! either Aero or exclusive mode on XP make sure that the hardware layer(that knows) watches over the software video renderers(well HR knows what's going on, but doesn't care...Haali didn't use Reclock at all)

anyway, I'm also talking from experience...so I'll simply shut it, and hope some software engineers will offer technical clues
What I mean is you can have horrible judder definitely due to frame rate/refresh rate synchronisation yet VMR9 reports no dropped frames. It's experience for sure, but measurable and reproducable.

Understanding what frame rate/refresh rate synchronisation is, it seems to me this is because it is still delivering the exact number of frames required at almost exactly (sic) the right time, but +/- 1ms or 2ms could mean the difference between a frame getting displayed once, twice or never. What I do not know is whether it is possible for the renderer to know to sub-1ms accuracy whether the frame it wrote to the back buffer arrived just after flip time or before and, anyway, then it is too late. Best to avoid it.
Jong is offline   Reply With Quote
Old 12th May 2009, 17:20   #977  |  Link
leeperry
Kid for Today
 
Join Date: Aug 2004
Posts: 3,477
Quote:
Originally Posted by Jong View Post
you can have horrible judder definitely due to frame rate/refresh rate synchronisation yet VMR9 reports no dropped frames.
yep, they send frames and hope for the best! prolly the video renderers cannot "know" about the VSYNC fliptime position...which would explain why Beliyaal enforces buffering in his presenter to catch it "spot on", he takes the problem the other way around

Last edited by leeperry; 12th May 2009 at 17:29.
leeperry is offline   Reply With Quote
Old 12th May 2009, 18:12   #978  |  Link
Jong
Registered User
 
Join Date: Mar 2007
Location: London, UK
Posts: 576
Quote:
Originally Posted by leeperry View Post
yep, they send frames and hope for the best! prolly the video renderers cannot "know" about the VSYNC fliptime position...which would explain why Beliyaal enforces buffering in his presenter to catch it "spot on", he takes the problem the other way around
That's why I thought I would warn Madshi. It may not be a problem, he may be able to do a better job, but it is possible that just "strictly show(ing) one frame per VSync" may, surprisingly, not be enough.
Jong is offline   Reply With Quote
Old 12th May 2009, 20:00   #979  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Guys, enough talk about jitter now, thanks. As I already said, in madVR's 1:1 mode there should be no problem.
madshi is offline   Reply With Quote
Old 12th May 2009, 23:17   #980  |  Link
Egh
Registered User
 
Join Date: Jun 2005
Posts: 630
Madshi: yeah, it is confirmed -- no one knows how to derive these spline coefficients Even avisynth has a disclaimer about that. Trouble is that they may not be ideal, although they do surprisingly good job. And seems "spline256" is what some people call "sinc256" in the original PanoTools (where all these coefficients were taken). So far even proficient in math don't have a clue what conditions were used for these splines.

However we may try to find out if there are any better splines than existing ones.

Very keen on trying your adaptive rescaling algorithm as well.
Egh 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 11:45.


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