madshi
5th January 2014, 18:03
How much does a renderer access a disk?
Not at all, except indirectly by loading dlls or things like that. Or, of course if you enable logging... :D
Any "image quality comparison" based solely on PSNR (in one channel no less) is likely to be less than informative unless the "experiment" is very carefully put together.
Yeah, seems like that.
When i start a movie it runs fine but as soon as i right click the screen or go to windowed mode the screen goes black/blank but i can hear that the content is still running 'normal'. when i crtl+alt+del and exit the ctrl+alt+del menu the content is visible again.
Shouldn't have anything to do with the SSD. Not sure what the problem is. Try updating Direct3D9, if you haven't already. Also try reinstalling the GPU drivers.
i have an idea to improve ivtc a lot.
the real idea of ivtc is to get smaller encodes and judder free/correct motion.
but with adding a bob filter for cadence breaks, smoothmotion and timestamps fixes with ivtc we can theoretical watch all telecine content or all broadcast with one new mode.
a 60 hz smoothmotion, ivtc(~30i look ahead) with bob for cadence breaks and 1:1 content like soccer and co. smoothmotion can handle VFR content perfectly i tested it with a self created VFR video game recording with 16-120 fps.
i'm not a profi with 1:1 content i normally don't watch things like that but bob should be the best way to treat this content or am i wrong about that? at the moment ivtc is run on the cpu (i like that a lot!) and madvr can't handle in stream resolution changes in time but this shouldn't matter if simple bob resize is run on the cpu (not the aim of madvr i know).
in worst case we get 3:2 bobed judder thanks to the bob filter with hard to render 60 fps on 3:2 content with 2:2 or 1:1 moving captions but this should be still better than cadence breaks with visible weave.
sound like hell to program... and it's an feature request X-)
As you (probably) know I don't accept feature requests at the moment. Deinterlacing/IVTC in madVR is a work in progress. There are many things I'd like to do, but I can only do so many things at a time.
MadVR wont go to FSE on a 1080p50 TV. In FS, it stays in windowed mode and says that target rectangle is 1280x720:(
The target rect doesn't matter. The only thing that matters is that the madVR rendering window must cover the full screen and no other window may be on top of the madVR rendering window. If you think the requirements are met in your case, but FSE mode still doesn't work, you can create and upload a (zipped) debug log for me to look at.
How does the quality of madVR compare to that of a cheap hardware blu ray player? What about compared to an expensive hardware blu ray player? Do these typically use good rendering algorithms, or are they typically made to be cheap and simple?
Oh, that is a rather complicated topic. FWIW, there's one general difference between hardware Blu-Ray players and HTPCs: Hardware Blu-Ray players usually by default output YCbCr, while PCs usually think (and render) in RGB. Most Blu-Ray players have an option to output RGB, but it's just an option. GPU drivers often have an option to output YCbCr, but that just means that the RGB rendered content gets converted to YCbCr by the GPU behind Windows' back. It's not a good quality option.
So hardware Blu-Ray players output either RGB or YCbCr. But pretty much every digital display out there is RGB. So somebody somewhere has to convert YCbCr to RGB. Displays can do the conversion. Blu-Ray players can do that, too. And HTPCs of course can do that, too. So who can do that best? I would say madVR can do it best. However, it's not as simple as that, because madVR's output is currently limited to 8bit RGB. While displays might internally use a higher bitdepth for YCbCr -> RGB conversion. Furthermore some displays convert RGB input back to YCbCr, even often down to 4:2:2 and then back to RGB. But every display behaves differently. So your question is not easy to answer.
From the feedback I received so far, the majority of users comparing hardware Blu-Ray players to (properly configured) HTPCs running madVR seemed to either prefer madVR quality or didn't see a difference.
Also, does anyone have a link to an explanation or a paper on the Jinc algorithm? I'm the most interested in this because it seems to be the highest quality, at least for chroma subsampling and image upscaling, but I can't find any documentation on what the algorithm is. I don't mind math-heavy sources.
You can find discussions on the ImageMagick forum about this. They call the algorithm "EWA Lanczos", IIRC, and not "Jinc", though. "EWA" stands for "elliptical weighted average", I think. Basically "Jinc" calculates weights by using a true distance to a circle of neighbor pixels. The other algorithms (e.g. Bicubic or Lanczos) instead use a simple X/Y distance for two separate X/Y scaling passes, which results in a rectangular neighborhood access pattern, instead of Jinc's circle pattern.
Here's an AviSynth implementation of the Jinc filter, with full source code (IIRC):
http://forum.doom9.org/showthread.php?p=1655421
for chroma subsampling. Is this purely an operation performed RGB -> RGB after the conversion from YUV -> RGB, or is the YUV -> RGB conversion part of chroma subsampling?
YUV is usually named YCbCr in digital data and consists of the Luma "Y" channel and the two Chroma "Cb" and "Cr" channels. The conversion from YCbCr to RGB requires one Luma and two Chroma values for every pixel. So before you can do YCbCr -> RGB conversion, you first have to upscale the Chroma channels to Luma resolution.
Can anyone explain to me how LAV Video Filter and MadVR Deinterlacing interact?
LAV doesn't deinterlace with default settings. It only deinterlaces if you manually activate CUVID decoding/deinterlacing or YADIF deinterlacing. The default workflow is that LAV Video Decoder just passes all frames/fields to the renderer as they are, and it's then the renderer's job to deinterlace them, if necessary. The renderer usually uses DXVA deinterlacing for that. DXVA deinterlacing can handle all kinds of material (film, video, mixed). However, for film content DXVA deinterlacing is limited to inverse telecine. DXVA deinterlacing can *not* decimate film content (30p -> 24p).
Is MadVR deinterlacer is needed only in IVTC when Film Mode is active?
madVR's normally uses DXVA for deinterlacing, which is an algorithm provided by the GPU hardware/driver. If you force madVR into film mode, madVR will use a self-written algorithm (which currently runs on the CPU) instead of DXVA deinterlacing. The self written-algorithm will perform IVTC + decimation, so that you get e.g. 24p out of a 60i stream. madVR's forced film mode should strictly only be used for film content. For video and mixed content you should stick to standard DXVA deinterlacing (for now).
MadVR fails to automatically detect between Film (29.97 telecined from 23.976) and Video (true 29.97).
It always plays the DVD's as "Video" even if its 23.976p telecined "Film".
Are you talking about forced film mode or about DXVA deinterlacing? DXVA doesn't report back to madVR whether the content was detected as film, video or mixed. So madVR has no way to know, when using DXVA deinterlacing.
When forced to "Film Mode" with IVCT (right for this DVD), Smooth Motion fails to engage on a 60Hz display.
I think this was already reported to the madVR bug tracker? If not, please report it there.
Moreover, when I play a true 29.97 Video DVD (documentary) and switch to Film mode I see combing and the cadenses go crazy
Documentaries are usually either video mode or mixed content. You should not force madVR into film mode for content which is not purely film content.
Why not just stay at 3:2 the first time its detected?
Because you would get loads of combing that way.
I've been doing some more reading, and from my understanding YUV -> RGB is a lossless conversion
Yes and no. It's a lossless conversion as long as you use store the RGB data in floating point. However, HDMI doesn't support floating point pixels. So at some point you have to convert the floating point RGB data back to integer. At that moment the conversion becomes lossy.
4:4:4 YCrCb would require no subsampling
4:4:4 means that chroma and luma channels have the same resolution. So there is no chroma subsampling.
Also, does the interpolation occur in the YUV colorspace before conversion back to RGB, or does it occur after conversion to RGB?
Chroma channels have to be at the same resolution as the Luma channel before you can convert to RGB.
I also had a question about the exact function of MadVR. I guess I don't have a clear idea of the pipeline of how media gets decoded and displayed. Does MadVR handle the actual processing of the h264 video, or does it only take over after the h264 has been decoded into the raw YUV values?
I guess my current mental model for the video pipeline is something like this:
h264/AVC Media file -> extract out h264 video -> decode the h264 -> present MadVR with the full YUV values for the entire screen (or whatever was stored given the subsampling) -> MadVR performs chroma subsampling -> MadVR performs scaling up or down -> MadVR converts from YUV to RGB -> present the raw pixel data to the media player.
madVR can optionally perform the h264 decoding. But most users today probably prefer letting LAV Video Decoder do the job. So usually madVR will get the decoded YCbCr data (usually 4:2:0) from an external decoder filter. The final rendered RGB data is not presented to the media player, but directly rendered to the screen. The media player got nothing to do with the actual rendering or presentation of the video. The media player only tells the renderer into which window with which size to render the video. The rest is done by the video renderer, e.g. using Direct3D or some other graphics API.
madVR scales in RGB (so after YCbCr -> RGB conversion), but that doesn't matter too much. Whether you scale the image in RGB or YCbCr doesn't make a big difference to image quality. There are a few more steps madVR is (sometimes) doing which aren't listed in your pipeline. E.g. at some point madVR might convert the video levels between PC <-> TV (if required), and in the final step the floating point rendered data is dithered down to 8bit integer RGB. Optionally there are many more possible steps like deinterlacing, gamut correction, gamma processing, smooth motion FRC etc etc...
Edit: Cross-post with vivan. Some answers may overlap...
Not at all, except indirectly by loading dlls or things like that. Or, of course if you enable logging... :D
Any "image quality comparison" based solely on PSNR (in one channel no less) is likely to be less than informative unless the "experiment" is very carefully put together.
Yeah, seems like that.
When i start a movie it runs fine but as soon as i right click the screen or go to windowed mode the screen goes black/blank but i can hear that the content is still running 'normal'. when i crtl+alt+del and exit the ctrl+alt+del menu the content is visible again.
Shouldn't have anything to do with the SSD. Not sure what the problem is. Try updating Direct3D9, if you haven't already. Also try reinstalling the GPU drivers.
i have an idea to improve ivtc a lot.
the real idea of ivtc is to get smaller encodes and judder free/correct motion.
but with adding a bob filter for cadence breaks, smoothmotion and timestamps fixes with ivtc we can theoretical watch all telecine content or all broadcast with one new mode.
a 60 hz smoothmotion, ivtc(~30i look ahead) with bob for cadence breaks and 1:1 content like soccer and co. smoothmotion can handle VFR content perfectly i tested it with a self created VFR video game recording with 16-120 fps.
i'm not a profi with 1:1 content i normally don't watch things like that but bob should be the best way to treat this content or am i wrong about that? at the moment ivtc is run on the cpu (i like that a lot!) and madvr can't handle in stream resolution changes in time but this shouldn't matter if simple bob resize is run on the cpu (not the aim of madvr i know).
in worst case we get 3:2 bobed judder thanks to the bob filter with hard to render 60 fps on 3:2 content with 2:2 or 1:1 moving captions but this should be still better than cadence breaks with visible weave.
sound like hell to program... and it's an feature request X-)
As you (probably) know I don't accept feature requests at the moment. Deinterlacing/IVTC in madVR is a work in progress. There are many things I'd like to do, but I can only do so many things at a time.
MadVR wont go to FSE on a 1080p50 TV. In FS, it stays in windowed mode and says that target rectangle is 1280x720:(
The target rect doesn't matter. The only thing that matters is that the madVR rendering window must cover the full screen and no other window may be on top of the madVR rendering window. If you think the requirements are met in your case, but FSE mode still doesn't work, you can create and upload a (zipped) debug log for me to look at.
How does the quality of madVR compare to that of a cheap hardware blu ray player? What about compared to an expensive hardware blu ray player? Do these typically use good rendering algorithms, or are they typically made to be cheap and simple?
Oh, that is a rather complicated topic. FWIW, there's one general difference between hardware Blu-Ray players and HTPCs: Hardware Blu-Ray players usually by default output YCbCr, while PCs usually think (and render) in RGB. Most Blu-Ray players have an option to output RGB, but it's just an option. GPU drivers often have an option to output YCbCr, but that just means that the RGB rendered content gets converted to YCbCr by the GPU behind Windows' back. It's not a good quality option.
So hardware Blu-Ray players output either RGB or YCbCr. But pretty much every digital display out there is RGB. So somebody somewhere has to convert YCbCr to RGB. Displays can do the conversion. Blu-Ray players can do that, too. And HTPCs of course can do that, too. So who can do that best? I would say madVR can do it best. However, it's not as simple as that, because madVR's output is currently limited to 8bit RGB. While displays might internally use a higher bitdepth for YCbCr -> RGB conversion. Furthermore some displays convert RGB input back to YCbCr, even often down to 4:2:2 and then back to RGB. But every display behaves differently. So your question is not easy to answer.
From the feedback I received so far, the majority of users comparing hardware Blu-Ray players to (properly configured) HTPCs running madVR seemed to either prefer madVR quality or didn't see a difference.
Also, does anyone have a link to an explanation or a paper on the Jinc algorithm? I'm the most interested in this because it seems to be the highest quality, at least for chroma subsampling and image upscaling, but I can't find any documentation on what the algorithm is. I don't mind math-heavy sources.
You can find discussions on the ImageMagick forum about this. They call the algorithm "EWA Lanczos", IIRC, and not "Jinc", though. "EWA" stands for "elliptical weighted average", I think. Basically "Jinc" calculates weights by using a true distance to a circle of neighbor pixels. The other algorithms (e.g. Bicubic or Lanczos) instead use a simple X/Y distance for two separate X/Y scaling passes, which results in a rectangular neighborhood access pattern, instead of Jinc's circle pattern.
Here's an AviSynth implementation of the Jinc filter, with full source code (IIRC):
http://forum.doom9.org/showthread.php?p=1655421
for chroma subsampling. Is this purely an operation performed RGB -> RGB after the conversion from YUV -> RGB, or is the YUV -> RGB conversion part of chroma subsampling?
YUV is usually named YCbCr in digital data and consists of the Luma "Y" channel and the two Chroma "Cb" and "Cr" channels. The conversion from YCbCr to RGB requires one Luma and two Chroma values for every pixel. So before you can do YCbCr -> RGB conversion, you first have to upscale the Chroma channels to Luma resolution.
Can anyone explain to me how LAV Video Filter and MadVR Deinterlacing interact?
LAV doesn't deinterlace with default settings. It only deinterlaces if you manually activate CUVID decoding/deinterlacing or YADIF deinterlacing. The default workflow is that LAV Video Decoder just passes all frames/fields to the renderer as they are, and it's then the renderer's job to deinterlace them, if necessary. The renderer usually uses DXVA deinterlacing for that. DXVA deinterlacing can handle all kinds of material (film, video, mixed). However, for film content DXVA deinterlacing is limited to inverse telecine. DXVA deinterlacing can *not* decimate film content (30p -> 24p).
Is MadVR deinterlacer is needed only in IVTC when Film Mode is active?
madVR's normally uses DXVA for deinterlacing, which is an algorithm provided by the GPU hardware/driver. If you force madVR into film mode, madVR will use a self-written algorithm (which currently runs on the CPU) instead of DXVA deinterlacing. The self written-algorithm will perform IVTC + decimation, so that you get e.g. 24p out of a 60i stream. madVR's forced film mode should strictly only be used for film content. For video and mixed content you should stick to standard DXVA deinterlacing (for now).
MadVR fails to automatically detect between Film (29.97 telecined from 23.976) and Video (true 29.97).
It always plays the DVD's as "Video" even if its 23.976p telecined "Film".
Are you talking about forced film mode or about DXVA deinterlacing? DXVA doesn't report back to madVR whether the content was detected as film, video or mixed. So madVR has no way to know, when using DXVA deinterlacing.
When forced to "Film Mode" with IVCT (right for this DVD), Smooth Motion fails to engage on a 60Hz display.
I think this was already reported to the madVR bug tracker? If not, please report it there.
Moreover, when I play a true 29.97 Video DVD (documentary) and switch to Film mode I see combing and the cadenses go crazy
Documentaries are usually either video mode or mixed content. You should not force madVR into film mode for content which is not purely film content.
Why not just stay at 3:2 the first time its detected?
Because you would get loads of combing that way.
I've been doing some more reading, and from my understanding YUV -> RGB is a lossless conversion
Yes and no. It's a lossless conversion as long as you use store the RGB data in floating point. However, HDMI doesn't support floating point pixels. So at some point you have to convert the floating point RGB data back to integer. At that moment the conversion becomes lossy.
4:4:4 YCrCb would require no subsampling
4:4:4 means that chroma and luma channels have the same resolution. So there is no chroma subsampling.
Also, does the interpolation occur in the YUV colorspace before conversion back to RGB, or does it occur after conversion to RGB?
Chroma channels have to be at the same resolution as the Luma channel before you can convert to RGB.
I also had a question about the exact function of MadVR. I guess I don't have a clear idea of the pipeline of how media gets decoded and displayed. Does MadVR handle the actual processing of the h264 video, or does it only take over after the h264 has been decoded into the raw YUV values?
I guess my current mental model for the video pipeline is something like this:
h264/AVC Media file -> extract out h264 video -> decode the h264 -> present MadVR with the full YUV values for the entire screen (or whatever was stored given the subsampling) -> MadVR performs chroma subsampling -> MadVR performs scaling up or down -> MadVR converts from YUV to RGB -> present the raw pixel data to the media player.
madVR can optionally perform the h264 decoding. But most users today probably prefer letting LAV Video Decoder do the job. So usually madVR will get the decoded YCbCr data (usually 4:2:0) from an external decoder filter. The final rendered RGB data is not presented to the media player, but directly rendered to the screen. The media player got nothing to do with the actual rendering or presentation of the video. The media player only tells the renderer into which window with which size to render the video. The rest is done by the video renderer, e.g. using Direct3D or some other graphics API.
madVR scales in RGB (so after YCbCr -> RGB conversion), but that doesn't matter too much. Whether you scale the image in RGB or YCbCr doesn't make a big difference to image quality. There are a few more steps madVR is (sometimes) doing which aren't listed in your pipeline. E.g. at some point madVR might convert the video levels between PC <-> TV (if required), and in the final step the floating point rendered data is dithered down to 8bit integer RGB. Optionally there are many more possible steps like deinterlacing, gamut correction, gamma processing, smooth motion FRC etc etc...
Edit: Cross-post with vivan. Some answers may overlap...