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. |
12th May 2009, 01:17 | #961 | Link |
Registered User
Join Date: Mar 2004
Posts: 140
|
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.
|
12th May 2009, 04:45 | #962 | Link | |
Registered User
Join Date: Jul 2004
Location: ILLINIOS
Posts: 50
|
Quote:
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. |
|
12th May 2009, 06:26 | #963 | Link | ||
Registered User
Join Date: Feb 2006
Posts: 293
|
Quote:
Quote:
__________________
Spec: Intel Core i5-3570K, 8g ram, Intel HD4000, Samsung U28D590 4k monitor+1080p Projector, Windows 10. |
||
12th May 2009, 08:06 | #964 | Link | ||||
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
I know perfectly well what the term jitter means. I didn't ask for a definition.
Quote:
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. 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:
Haali doesn't reply to my emails. Quote:
Quote:
I don't recall having said that I would stop supporting XP... Fixing showstopper bugs (if any), smooth playback and DVD playback are my current top priorities. |
||||
12th May 2009, 08:58 | #965 | Link | |
ffdshow/AviSynth wrangler
Join Date: Feb 2003
Location: Austria
Posts: 2,441
|
Quote:
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. |
|
12th May 2009, 09:27 | #966 | Link | |
Registered User
Join Date: Apr 2008
Posts: 1,106
|
Quote:
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. |
|
12th May 2009, 09:31 | #967 | Link | ||
Registered User
Join Date: Aug 2008
Posts: 176
|
Quote:
Quote:
|
||
12th May 2009, 11:02 | #968 | Link | |
Guest
Posts: n/a
|
Quote:
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. |
|
12th May 2009, 14:40 | #970 | Link | |
Registered User
Join Date: Mar 2007
Location: London, UK
Posts: 576
|
Quote:
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. |
|
12th May 2009, 14:57 | #971 | Link | ||
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
Quote:
Quote:
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... |
||
12th May 2009, 15:05 | #972 | Link | |
Registered User
Join Date: Mar 2007
Location: London, UK
Posts: 576
|
Quote:
Last edited by Jong; 12th May 2009 at 15:19. |
|
12th May 2009, 16:10 | #973 | Link | |
Kid for Today
Join Date: Aug 2004
Posts: 3,477
|
Quote:
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. |
|
12th May 2009, 16:17 | #974 | Link |
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. |
12th May 2009, 16:43 | #975 | Link |
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. |
12th May 2009, 16:54 | #976 | Link | |
Registered User
Join Date: Mar 2007
Location: London, UK
Posts: 576
|
Quote:
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. |
|
12th May 2009, 17:20 | #977 | Link |
Kid for Today
Join Date: Aug 2004
Posts: 3,477
|
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. |
12th May 2009, 18:12 | #978 | Link |
Registered User
Join Date: Mar 2007
Location: London, UK
Posts: 576
|
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.
|
12th May 2009, 23:17 | #980 | Link |
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. |
Tags |
direct compute, dithering, error diffusion, madvr, ngu, nnedi3, quality, renderer, scaling, uhd upscaling, upsampling |
Thread Tools | Search this Thread |
Display Modes | |
|
|