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. |
8th June 2013, 09:42 | #19101 | Link | |||||||||
Broadband Junkie
Join Date: Oct 2005
Posts: 1,859
|
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Yeah, I'm actually surprised the cost is as large as it is. It's not possible to generate a hard-code 1D LUT or something to speed up these conversions, instead of doing them dynamically in shaders? |
|||||||||
8th June 2013, 10:06 | #19102 | Link | |
Broadband Junkie
Join Date: Oct 2005
Posts: 1,859
|
Quote:
Those level range tags are just for informative purposes, and not immediately relevant to the subtitle interface. They only define intended level range to use for YCbCr output by xy-VSFilter and similar transform filter renderers. At the time, you were quite insistent on it being included in the subtitle interface, because you wanted to mimic incorrect xy-VSFilter behavior in those cases where the subtitle and video were not using the same YCbCr level range. Issues like xy-VSFilter outputting TV-range YCbCr subtitles on a PC-range YCbCr video and vice versa. |
|
8th June 2013, 10:19 | #19103 | Link | |
Registered User
Join Date: Jul 2011
Posts: 57
|
Quote:
|
|
8th June 2013, 10:50 | #19104 | Link | ||||||||||
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
Quote:
Have you tried different decoders? Maybe some are running at ABOVE_NORMAL and some at NORMAL? Quote:
Quote:
Quote:
Quote:
Quote:
Ok, if I went with floating point, people could compromise by using 16bit float instead of 32bit (trade quality for performance). They'd probably get identical performance to the current madVR logic, but with slightly faster subtitle rendering. On the negative side, they'd get less accuracy at the same speed as the current madVR logic. I think that's a bad compromise. Furthermore, if you look at the high quality option, I'd have to use float32 instead of int16, which costs twice the memory bandwidth. So the memory bandwidth cost of doing Jinc3 AR for a "no compromise" setup would double. All of that just to get a small boost in subtitle rendering performance? Sounds like a bad idea to me... Quote:
Furthermore, ArgyllCMS could make TV levels 3dluts behave identical to PC levels 3dluts by simply clipping BTB/WTW away. From a technical/scientific point of view, using a TV levels 3dlut with clipped BTB/WTW is identical to using a PC levels 3dlut. From what I've read the recent problems with ArgyllCMS with BTB information suddenly becoming visible with weird colors was due to Graeme trying to add xvYCC support. And the same problem also occurred with the eeColor. I'm not sure if that is the problem with elevated BTB that you're talking about, though. Quote:
Now let's compare a UHD TV <-> PC conversion to that: Such a conversion needs 8 million input pixels and 8 million output pixels, with no 1dlut access and barely any shader math to speak of. Furthermore, having each input pixel position match exactly the output pixel also means that the GPU texture caches work much more effectively compared to the upscaling shaders. Can you see how doing a TV <-> PC conversion is not even remotely in the same cost category as an upscaling algorithm? Quote:
Quote:
From where I stand right now, I'm not sure what madVR should do if XySubFilter reports TV vs PC. And I'm also not sure what XySubFilter should do if madVR reports TV vs PC. I don't think we should leave the interface like this. We at least need to clarify the intended behaviour. And while we're at it, we could consider adding support for 16-256 subtitles to avoid performance problems in the video renderer? |
||||||||||
8th June 2013, 11:07 | #19105 | Link | |
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
Quote:
https://code.google.com/p/xy-vsfilter/issues/detail?id=91#c224 |
|
8th June 2013, 12:11 | #19107 | Link | |
Registered Developer
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,346
|
Quote:
In any case, the splitter has absolutely zero interaction with D3D or the GPU, so its not really possible for it to cause any problem with madVRs vsync detection.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders Last edited by nevcairiel; 8th June 2013 at 12:17. |
|
8th June 2013, 12:17 | #19108 | Link | |||||||
Broadband Junkie
Join Date: Oct 2005
Posts: 1,859
|
Quote:
Quote:
Quote:
He must be misunderstanding something then, because when I asked him he said that clipping BTB & WTW wasn't possible with a TV range in/out 3DLUT, and that it was something madVR should be doing, which you obviously aren't since it becomes visible. The xvYCC support thing is something else, these problems were from way before then. Quote:
Quote:
Quote:
As far as actual changes, at the moment I'd rather just focus on getting the first XySubFilter beta released before we consider changing anything. Quote:
Last edited by cyberbeing; 8th June 2013 at 12:57. |
|||||||
8th June 2013, 12:55 | #19109 | Link | |
Registered User
Join Date: Sep 2009
Posts: 43
|
madVR - high quality video renderer (GPU assisted)
Quote:
|
|
8th June 2013, 13:05 | #19110 | Link |
Broadband Junkie
Join Date: Oct 2005
Posts: 1,859
|
If the eeColor box doesn't do levels expansion or clip BTB/WTW, then I guess that the difference is that madVR doesn't clip BTB before performing TV -> PC range output or something. Most TVs clip BTB by default when performing TV range YCbCr input -> PC range. Otherwise, only madshi would know why a 3DLUT with 16-235 input/output was making BTB in the 0-15 range visible. It still doesn't make much sense to me.
Last edited by cyberbeing; 8th June 2013 at 13:10. |
8th June 2013, 13:14 | #19111 | Link | |
Registered User
Join Date: Sep 2009
Posts: 43
|
Quote:
|
|
8th June 2013, 13:26 | #19112 | Link | |
Broadband Junkie
Join Date: Oct 2005
Posts: 1,859
|
Quote:
|
|
8th June 2013, 13:28 | #19113 | Link | |||
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
Quote:
Quote:
No, I'm not, we were just talking past each other (once again). Quote:
|
|||
8th June 2013, 13:46 | #19114 | Link | |
Broadband Junkie
Join Date: Oct 2005
Posts: 1,859
|
Quote:
[Edit: The 6-7-2013 collink build still only supports -r255 , not -r256, did he provide you with a special build?] Last edited by cyberbeing; 8th June 2013 at 14:04. |
|
8th June 2013, 14:04 | #19116 | Link |
Registered User
Join Date: May 2013
Posts: 77
|
I have a problem with atleast all madVR versions above 0.84 . If i update to a newer one this happens:
Here is Ctrl+J: http://img15.imageshack.us/img15/2088/67045988.png If I downgrade to my previous version (84.7) it all comes back to normal. Is there any way to fix it? |
8th June 2013, 14:16 | #19117 | Link | ||
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
Quote:
Yes, creating a 3dlut like that will take a loooooong time. You could try whether maybe -r128 or -r64 will make an acceptable compromise and still fix the BTB elevation problem. I've not yet had a chance to play with all this myself, so I'm only throwing wild guesses around here... Quote:
Does this happen with all videos? Or only with some? Maybe only with one specific codec (e.g. h264 or MPEG2)? Which decoder are you using? Can you try using a different decoder? |
||
8th June 2013, 14:38 | #19119 | Link | |
Broadband Junkie
Join Date: Oct 2005
Posts: 1,859
|
Quote:
Code:
collink -v -3m -et -Et -IB -r256 -G -ila Rec709.icm TV.icm HD.icm |
|
Tags |
direct compute, dithering, error diffusion, madvr, ngu, nnedi3, quality, renderer, scaling, uhd upscaling, upsampling |
Thread Tools | Search this Thread |
Display Modes | |
|
|