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 14th May 2009, 19:58   #1021  |  Link
Egh
Registered User
 
Join Date: Jun 2005
Posts: 630
Regarding these 601/709 colormatrices, I have already suggested an option to override the matrix chosen over automatic detection. The reason is that the resolution-based condition is not always correct (I think one such sample from Apple has been posted here already, and there are some other cases as well, let's say there are plenty of encoders in the world and not all of them adjust colourmatrix as required :P)

Last edited by Egh; 15th May 2009 at 03:52.
Egh is offline   Reply With Quote
Old 15th May 2009, 02:01   #1022  |  Link
pie1394
Registered User
 
Join Date: May 2009
Posts: 212
The stream demuxer or the video decoder often knows the video output's color space. (Of course, only if appropriately encoded)

To make it more accurate to handle the decoded video frame's "color space", there are two methods:

1. If there is such MetaData embedded in the decoded video frame, the video post-processor / renderer can handle this by itself.

2. If it is not embedded in the decoded video frame, this relies on the player program to grab video stream's color space info from stream demuxer or video decoder, and instruct the video post-processor/renderer to do the right conversion. Of course the video processor needs to provide an API for the player to adjust the setting dynamically.
pie1394 is offline   Reply With Quote
Old 15th May 2009, 11:30   #1023  |  Link
AJ73
Registered User
 
Join Date: Jun 2008
Posts: 8
I invested a lot of time to undderstand pros and contras of all the colorapaces (in the PC area not in the TV area).
I do not understand why YV12 (as a 4:2:0 color subsampling) is better in quality than YUY2 (or UYVY) that has twice as much color information from the original source than YV12 (or NV12).
Is generally more information from the source not better than less?

MPEG-4 and H.264 (not the studio and high quality profiles) use 4:2:0 internally so the information in the source (file, RTP stream) is already lost. But there are also formats like MJPEG that use higher quality color subsampling internally (4:2:2) and some formats also use 4:4:4 color subsampling. My attemt was alwas to avoid any color conversion if possible. That is the reason why YUY2 would have been nice.

You are right that FFDSHOW raw filter can be used for conversion (that is in most cases lossy). But in a multiinstance application the use of an additional filter is bad for the performance.
AJ73 is offline   Reply With Quote
Old 15th May 2009, 11:47   #1024  |  Link
FoLLgoTT
And so it begins...
 
FoLLgoTT's Avatar
 
Join Date: Nov 2005
Location: Hannover, Germany
Posts: 64
Quote:
Originally Posted by AJ73 View Post
I do not understand why YV12 (as a 4:2:0 color subsampling) is better in quality than YUY2 (or UYVY) that has twice as much color information from the original source than YV12 (or NV12).
Is generally more information from the source not better than less?
There is no more information. The source (DVD/Blu-ray) is subsampled in 4:2:0. When outputting YUY2 the decoder itself does the upsampling to 4:2:2 which is usually much worse than the upsampling madVR does. YV12 ensures that the decoder outputs the data as decoded. This is the reason why YV12 is better in this case.
FoLLgoTT is offline   Reply With Quote
Old 15th May 2009, 11:50   #1025  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Quote:
Originally Posted by pie1394 View Post
The stream demuxer or the video decoder often knows the video output's color space. (Of course, only if appropriately encoded)

To make it more accurate to handle the decoded video frame's "color space", there are two methods:

1. If there is such MetaData embedded in the decoded video frame, the video post-processor / renderer can handle this by itself.
True.

Quote:
Originally Posted by AJ73 View Post
I do not understand why YV12 (as a 4:2:0 color subsampling) is better in quality than YUY2 (or UYVY) that has twice as much color information from the original source than YV12 (or NV12).
Is generally more information from the source not better than less?
Yes, but only if the source actually contains that much information. And that is exactly the key point. By far most sources do not contain more than 4:2:0.

Quote:
Originally Posted by AJ73 View Post
MPEG-4 and H.264 (not the studio and high quality profiles) use 4:2:0 internally so the information in the source (file, RTP stream) is already lost.
It's not only MPEG4 and h264. MPEG1, MPEG2, MPEG4, h264, DviX, Xvid, VC-1 all usually use 4:2:0. There are some rare exceptions where 4:2:2 or 4:4:4 is encoded, but 4:2:0 is by far the most common used format for encoding. Still, many decoders insist on outputting YUY2, if you let them, even for 4:2:0 sources. Which means that the decoder is internally doing chroma upsampling in inferior quality. And that is what I want to avoid.

Edit: Seems I was too slow in replying...
madshi is offline   Reply With Quote
Old 15th May 2009, 13:00   #1026  |  Link
Thunderbolt8
Registered User
 
Join Date: Sep 2006
Posts: 2,197
got my new HD 4770 (only have a PCIe 1.0 slot though), this is for the US sin city BD:

display 1 estimate: 62.XXXXXHz
display 2 estimate: 60.0XXXXHz
display 3 estimate: 60.0XXXXHz
display 60.03804Hz
movie 23.976 fps
frame queue 16/16
movie res 1920, 1080
target rectangle 0, 152, 1280, 872
movie frame interval 41.71ms
avrg gpu rendering time 6-14ms (depending on scene)
max gpu rendering time 8-20 I'd say
arg present wait 'till 14ms


seems like the HD 4770 is not yet listed under the cards to choose new drivers for at ati/amd.com?

btw. is installing that avivo video thing good for anything?
Thunderbolt8 is offline   Reply With Quote
Old 15th May 2009, 14:34   #1027  |  Link
Mark_A_W
3 eyed CRT supporter
 
Join Date: Jan 2008
Location: Or-strayl-ya
Posts: 563
Quote:
Originally Posted by madshi View Post
In my experience, interlaced output doesn't work well with HTPCs, though, so my plans do not include interlaced output or interlaced graphics modes...



As someone who uses an Interlaced resolution, very successfully (1080i 95.904hz, which is 47.952hz in Powerstrip with the interlaced box ticked)...

I'm obviously freaking out at that statement.

Does it really make that much difference to the renderer? How does it know if the 96hz it is detecting is 96 progressive or 48 interlaced?

I assure you, interlaced resolutions work very, very well. Currently I have very smooth playback with Haali + Reclock, or MPC EVR custom.

All I'm asking is that interlaced resolutions are not precluded from smooth playback. I, at least, can live without fancy refresh rate changes.
Mark_A_W is offline   Reply With Quote
Old 15th May 2009, 14:45   #1028  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Quote:
Originally Posted by Mark_A_W View Post
All I'm asking is that interlaced resolutions are not precluded from smooth playback.
I don't have any code that specifically excludes interlaced output modes from working - and I don't have any plans to add any such code.
madshi is offline   Reply With Quote
Old 15th May 2009, 16:04   #1029  |  Link
pie1394
Registered User
 
Join Date: May 2009
Posts: 212
Although madshi does not plan to support "deinterlace" capability, I still would like to explain some rules to deal with the interlaced contents here.

For interlaced contents to be "vertically" scaled, it needs to be deinterlaced first no matter the output device is progressive-scan (most LCD, regular PDP) or interlaced-scan one (regular CRT, Hitachi ALIS PDP, special LCD monitor for broadcasting 1080i content inspection).

For interlaced-scan output device, it can be chosen to do the separate vertical field-scaling on interlaced contents to avoid the deinterlacing process. But the good motion-adaptive deinterlacing + frame scaling mode still produce better video quality, especially in the static scenes.

For progressive-scan output device, there is no choice. "deinterlacing" process must be done for interlaced contents before the horizontal + "required" vertical scaling processes.
pie1394 is offline   Reply With Quote
Old 15th May 2009, 18:51   #1030  |  Link
73ChargerFan
Registered User
 
73ChargerFan's Avatar
 
Join Date: Dec 2006
Posts: 523
Quote:
Originally Posted by madshi View Post
In my experience, interlaced output doesn't work well with HTPCs, though, so my plans do not include interlaced output or interlaced graphics modes...
The first two or three generations of DLP rear projection TVs were 1080i only. That's a lot of early adopters.

I'm lucky, in that I purchased the first 1080p DLP produced. My set works equally well with 1080i/1080p output from my HD-DVD players.
73ChargerFan is offline   Reply With Quote
Old 16th May 2009, 00:06   #1031  |  Link
Wilbert
Moderator
 
Join Date: Nov 2001
Location: Netherlands
Posts: 6,364
@madshi
Quote:
Quote:
Originally Posted by Wilbert
In a few days i will post a story about those splines! Stay tuned
Looking forward to it...
Please have a look at: http://forum.doom9.org/showthread.ph...08#post1286008
Wilbert is offline   Reply With Quote
Old 16th May 2009, 00:46   #1032  |  Link
Mark_A_W
3 eyed CRT supporter
 
Join Date: Jan 2008
Location: Or-strayl-ya
Posts: 563
Quote:
Originally Posted by madshi View Post
I don't have any code that specifically excludes interlaced output modes from working - and I don't have any plans to add any such code.
Thank you. That's all I ask.


Did you get my uploaded vysnc.dat file? I think I'm the only one who did it - and it was pages and pages ago now.
Mark_A_W is offline   Reply With Quote
Old 16th May 2009, 02:16   #1033  |  Link
Hypernova
Registered User
 
Join Date: Feb 2006
Posts: 293
Quote:
Originally Posted by Mark_A_W View Post
Thank you. That's all I ask.


Did you get my uploaded vysnc.dat file? I think I'm the only one who did it - and it was pages and pages ago now.
I did too, and a couple others, so you're not the only one
__________________
Spec: Intel Core i5-3570K, 8g ram, Intel HD4000, Samsung U28D590 4k monitor+1080p Projector, Windows 10.
Hypernova is offline   Reply With Quote
Old 16th May 2009, 22:21   #1034  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Quote:
Originally Posted by Mark_A_W View Post
Did you get my uploaded vysnc.dat file?
Those vsync.dat files I got indicated that sometimes your graphics cards report flat out incorrect scanline information. That confused madVR's display refresh rate calculation formulas. That should be worked around in the next madVR build.
madshi is offline   Reply With Quote
Old 16th May 2009, 22:49   #1035  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
madVR 0.10 released

http://madshi.net/madVR.zip

Code:
* added first (buggy) version of smooth motion rendering
* added uploading queue (up to 8 frames)
* added rendering queue (up to 8 frames)
* added information about dropped and delayed frames to OSD
* removed GPU rendering times from OSD
* added (buggy) frame stepping support
* modified DVD / macrovision handling slightly
* display refresh rate detection should no longer produce incorrect results
* added separate controls for luma upscaling and downscaling
* fixed: image was sometimes offset in 1:1 mode in ZoomPlayer
Hurray, first smooth motion version out!

Unfortunately I've found that it's next to impossible to get things *perfectly* smooth in windowed mode (at least on my PC). So perfection will have to wait until madVR is able to do fullscreen exclusive mode. However, my current development PC is not the fastest/best, so maybe you can get good enough results with madVR even in windowed mode, if your PC works better than mine. At least madVR 0.10 should be a lot smoother than older versions (I hope).

Technically the problem is that whenever you tell the GPU to display a rendered frame during the next vsync blank, the GPU stalls and stops doing anything else until the next vsync blank finally occurs. That means that if madVR asks the GPU very early to display a rendered frame during the next vblank, there's not enough GPU time left to do the actual rendering, cause the GPU is stalled most of the time waiting for the next vblank. On the other hand, if madVR tries to display the rendered frame as late as possible (in order to gain more GPU processing time), the danger of missing the target vblank period grows. A missed target vblank means judder or tearing or both. Argh, isn't that fun? AFAIK, these problems should go away in fullscreen exclusive mode, fortunately.

madVR 0.10 now uploads the video data to the GPU in a separate thread. Also rendering and displaying the images is also done in separate threads. That all means that retrieving correct and meaningful GPU rendering times is more difficult. So I've simply removed GPU rendering time information from the OSD now. However, I've added information about uploading and rendering queues. Generally, if the upload and rendering queues stay over at least 4/8, your GPU seems to be fast enough to handle the madVR settings you've activated.

Also I've added information about dropped and delayed frames to the OSD. During startup of movie playback it's acceptable to get a few dropped or delayed frames. But 3-5 seconds after the movie starts the number of dropped/delayed frames should not increase, anymore. Every time you see motion judder on screen, probably either the dropped or delayed frame count increases. If the number of dropped/delayed frames does not increase for you after 3-5 seconds of runtime, you should get perfect playback quality. Well, I mean: As perfect as the ratio of display refresh rate and movie frame rate permits, of course.

Display refresh rate calculation should work correctly now. If it doesn't, you will probably not get smooth motion playback. So make sure you double check (especially those of you for which display refresh rate calculation failed to work with older madVR versions).

I've also slightly worked on DVD playback ("macrovision failure"). For me it works. However, I've noticed that the DScaler decoder doesn't always work with madVR when playing back DVDs while the Cyberlink MPEG2 decoder always works.

Frame stepping is now implemented, but buggy. Generally madVR has gone a bit buggy/unstable due to the many deep changes. As long as you don't pause/stop/resize etc, things should be stable. If you do anything madVR has to react to you might get funny results, or maybe it will work just fine. If you run into problem that is reliably reproducable please let me know.
madshi is offline   Reply With Quote
Old 16th May 2009, 23:21   #1036  |  Link
wayland
Registered User
 
Join Date: May 2009
Posts: 23
how do you open the detailed osd in 0.10? ctrl+j twice doesnt seem to do it any more.

also going a bit off topic but how should the dynamic range be set on nvidia hardware full(0-255) or limited (16-235)? either seems to result in a differant image with madvr and HR compared to evr custom

Last edited by wayland; 16th May 2009 at 23:26.
wayland is offline   Reply With Quote
Old 17th May 2009, 00:15   #1037  |  Link
honai
Guest
 
Posts: n/a
madshi, awesome work, thanks! Tested it again on the Iron Man BD w/ the 4770, refresh rate was correctly detected at 60.00071 Hz (and stayed there for the whole 250s I tested), decoder queue 16/16 fixed, upload queue 4/8 fixed, render queue 8/8 fixed, 10 dropped frames, 2 delayed, all during first few seconds. Playback "feels" almost perfectly smooth, the very tiny stuttering could also be the effect of 23.976@60Hz playback. Feels definitely as smooth as the best iteration of Beliyaal's EVR CP.

One tiny request: Could you make the OSD position toggle between the top and bottom? Might come in handy for us plasma users.
  Reply With Quote
Old 17th May 2009, 00:28   #1038  |  Link
Mark_A_W
3 eyed CRT supporter
 
Join Date: Jan 2008
Location: Or-strayl-ya
Posts: 563
Madshi, this new version, well...


YEA HAR!!


display 95.90368Hz (397s) perfect, time just keeps growing
movie fps 23.976fps (says source filter)
decoder queue 16/16
upload queue 4/8
render queue 8/8
movie res 1920,1080
target rectangle 0,0,1920,1080
v sync interval 10.43ms
movie frame interval 41.71ms
dropped frames 3 Just from startup, stable after that
delayed frames 3 Just from startup, stable after that



Playback is smooth, so far. I need to watch a whole movie to be certain.

I am using Reclock, but disabled (original speed locked, slaved).

The HD2600XT seems capable for watching 1080p material at 1080i 96hz.

Was it the interlaced res that causes the scanline reporting issue? Because an interlaced res has a half scanline at the bottom, or somesuch, to form the offset between fields (it has an early V-sync once per frame).


A small feature request: A tearing/smoothness test. Using Zoomplayer, with Reclock "bypassed", I have no tearing bar test, which is very handy for checking issues.

And that raises the Reclock issue...are you using Reclock? If so, what settings? Active or bypassed? If not, will Reclock bypassed, just a WASAPI renderer, cause any issues? It doesn't seem to.


I'm slightly concerned about the need for Fullscreen Exclusive for "perfect" playback. I understand why (I think), but it's a bit clunky - and there goes the UI on Zoomplayer. Oh well, smooth playback and gamma are my number one priorities.


Once this renderer has subtitles, it will replace Haali Renderer on my system for all material.

The GPU rendering stats in the OSD are missed.

Thank you very much Madshi, honai is right, it "feels" smooth. With Haali Renderer it always "feels" like it is about to throw a little stutter party. Beliyaal EVR custom has this smooth feel too, but I get a glitch after an hour.

I will test a full movie tonight.

Last edited by Mark_A_W; 17th May 2009 at 01:07.
Mark_A_W is offline   Reply With Quote
Old 17th May 2009, 00:38   #1039  |  Link
Thunderbolt8
Registered User
 
Join Date: Sep 2006
Posts: 2,197
just to nitpick, does it have to be 0.10 or 1.0? 10 comes after 9, yes, but just from the looks after 0.9 I'd expect to get 1.0. I'd rather say that 0.10 follows after 0.09 :P

for the same movie as a bit above, with 0.10 & HD 4770:

display estimate: 60.037XXHz
movie 23.976 fps
decoder queue 16/16
upload queue 4-5/16
renderer queue 8/8
movie res 1920, 1080
target rectangle 0, 152, 1280, 872
vsync intervall 16.66ms
movie frame interval: 41.71ms
dropped frames: usually none, ~3 when skipping through
delay frames: usually none, 1-2 when skipping through

whats a bit anyong is that flicker when you hover over the playback bar with the mouse in fullscreen mode, then there is a flickering each time. but I guess thats still part of the buggy phase.

Last edited by Thunderbolt8; 17th May 2009 at 00:40.
Thunderbolt8 is offline   Reply With Quote
Old 17th May 2009, 01:10   #1040  |  Link
Mark_A_W
3 eyed CRT supporter
 
Join Date: Jan 2008
Location: Or-strayl-ya
Posts: 563
Quote:
Originally Posted by Thunderbolt8 View Post
whats a bit anyong is that flicker when you hover over the playback bar with the mouse in fullscreen mode, then there is a flickering each time. but I guess thats still part of the buggy phase.
What player Thunderbolt?
Mark_A_W 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 15:06.


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