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 1st October 2011, 18:59   #9921  |  Link
THX-UltraII
Registered User
 
Join Date: Aug 2008
Location: the Netherlands
Posts: 850
And another strange thing that I just noticed:

When I choose RGB Full in the ATI ccc my computer (ATI ccc) is switching back automatically to YCbCr 4:4:4 Pixel Format after 30 seconds or so......

EDIT: Switches back to 4:2:2 and not 4:4:4

Last edited by THX-UltraII; 1st October 2011 at 19:19.
THX-UltraII is offline   Reply With Quote
Old 1st October 2011, 20:01   #9922  |  Link
nand chan
( ≖‿≖)
 
Join Date: Jul 2011
Location: BW, Germany
Posts: 380
Quote:
Originally Posted by THX-UltraII View Post
I don t have that option listed in LAV. I can only choose TV, PC or Untouched
PC = Full range

Quote:
Originally Posted by naoan View Post
I actually usually do this before for 8 bit video, but used coreavc to take care of the decoding since it is faster than ffdshow. But thanks for the info about the wrong dithering on ffdshow, I'd be oblivious otherwise.
Well, CoreAVC only decodes 8-bit either way so there's no issue here :P

And for 10-bit, LAV Video is *faster* than CoreAVC. In fact, LAV is faster than CoreAVC for 8-bit as well if you have a CUDA graphics card.

Quote:
Now if madvr has avisynth support my dream media setup is complete, but that's asking a bit too much I guess.
Instead of adding avisynth support to madVR, it's better to just create a separate DirectShow filter for avisynth. Like, y'know, the ffdshow raw video host.

There's no point either way until the next version of avisynth comes out which will support higher-than-8-bit textures. For now, ffdshow raw is no different than what you'd get from adding it to madVR.

I don't exactly see the point in that suggestion, maybe I'm missing something?

Quote:
Originally Posted by THX-UltraII View Post
And what do you use for Luma DOWNscaling?
I don't downscale luma.
__________________
Forget about my old .3dlut stuff, just use mpv if you want accurate color management
nand chan is offline   Reply With Quote
Old 1st October 2011, 20:05   #9923  |  Link
pirlouy
_
 
Join Date: May 2008
Location: France
Posts: 628
Quote:
Originally Posted by nand chan View Post
As for the RGB output, just use full range.
From what Madshi said in this thread, if you use MadVR, you can choose "untouched" (in LAV video 0.36+) and let MadVR deals with it.
__________________
Windows 10 x64; 1080p 60" TV, GTX 750; mpv or madVR+LAV Filters+MPC-BE
pirlouy is offline   Reply With Quote
Old 1st October 2011, 20:07   #9924  |  Link
naoan
Registered User
 
Join Date: Oct 2009
Posts: 152
Coreavc 3.0 does support proper 10 bit afaik (madvr report so at least).

I just like to have fewer filter chain and decrease the risk of something screwing up along the line (and hopefully, speed thing up). Also, isn't 10 bit support depend entirely on avisynth plugins and there are some that support higher than 8-bit (up to 16 bit).

CMIIW.
naoan is offline   Reply With Quote
Old 1st October 2011, 20:12   #9925  |  Link
THX-UltraII
Registered User
 
Join Date: Aug 2008
Location: the Netherlands
Posts: 850
Quote:
Originally Posted by nand chan View Post
I don't downscale luma.
but I have to choose SOMETHING in madVR for this right?
THX-UltraII is offline   Reply With Quote
Old 1st October 2011, 20:13   #9926  |  Link
THX-UltraII
Registered User
 
Join Date: Aug 2008
Location: the Netherlands
Posts: 850
Quote:
Originally Posted by THX-UltraII View Post
And another strange thing that I just noticed:

When I choose RGB Full in the ATI ccc my computer (ATI ccc) is switching back automatically to YCbCr 4:4:4 Pixel Format after 30 seconds or so......

EDIT: Switches back to 4:2:2 and not 4:4:4
you guys have any idea about this problem? What are the downsides of having 4:2:2 yCbCr Pixel Format?
THX-UltraII is offline   Reply With Quote
Old 1st October 2011, 21:00   #9927  |  Link
nand chan
( ≖‿≖)
 
Join Date: Jul 2011
Location: BW, Germany
Posts: 380
Quote:
Originally Posted by THX-UltraII View Post
but I have to choose SOMETHING in madVR for this right?
Set it to nearest neighbor if you really want to. It doesn't matter one bit if your monitor is 1080p (or higher). The only people that need to care about luma downscaling are those on 720p monitors or lower.

I personally have it set to Bicubic.

Quote:
Originally Posted by naoan View Post
Coreavc 3.0 does support proper 10 bit afaik (madvr report so at least).
Yes, it supports 10-bit software decoding. However, it's a lot slower than LAV Video (and still slower than ffdshow). It also artifacts on very high bitrates.

The only good software decoder in CoreAVC is that of version 2, for 8-bit video - which is still slightly faster than LAV Video.

Quote:
I just like to have fewer filter chain and decrease the risk of something screwing up along the line (and hopefully, speed thing up).
A raw video filter set to “prefer” will always have something to connect to. The only exception is when you're using the madVR internal decoders.

If you're planning on doing that then I can see why you'd want native avisynth support. However, I don't see a situation in which you'd *want* to use the internals either way.

Quote:
Also, isn't 10 bit support depend entirely on avisynth plugins and there are some that support higher than 8-bit (up to 16 bit).
The avisynth filter itself only supports 8-bit pixel format inputs / outputs, so even if some plugins support higher bit depths they always need to go back down to 8-bit at some point. This is why, if you want to go with avisynth, you need to go all the way (do all color conversions and dither back down to 8-bit in RGB32 space at the very end in avisynth).

Also, flash3kyuu itself only supports YV12 input which is 8-bit only, so the point is moot. It does 8 -> 16 bit debanding.

And don't the custom “16-bit” avisynth formats just do some hacking where they save the low bits and high bits side by side?

Quote:
Originally Posted by THX-UltraII View Post
you guys have any idea about this problem? What are the downsides of having 4:2:2 yCbCr Pixel Format?
If you really had 4:2:0 YCbCr pixel format (and your monitor accepted RGB) you probably wouldn't even be able to read this, all colors would be ridiculously messed up.
__________________
Forget about my old .3dlut stuff, just use mpv if you want accurate color management
nand chan is offline   Reply With Quote
Old 1st October 2011, 21:19   #9928  |  Link
THX-UltraII
Registered User
 
Join Date: Aug 2008
Location: the Netherlands
Posts: 850
[QUOTE

If you really had 4:2:0 YCbCr pixel format (and your monitor accepted RGB) you probably wouldn't even be able to read this, all colors would be ridiculously messed up.[/QUOTE]
I don t understand what you mean here
You told me to use 4:4:4 Full RGB but my ATI CCC keeps reverting to 4:2:2 Pixel Format. This is not what is supposed to happen and not good right?
THX-UltraII is offline   Reply With Quote
Old 1st October 2011, 21:30   #9929  |  Link
SamuriHL
Registered User
 
SamuriHL's Avatar
 
Join Date: May 2004
Posts: 4,198
It possibly means your AVR and/or TV don't support RGB.
__________________
HTPC: Windows 10, I9 9900k, RTX 2070 Founder's Edition, Pioneer Elite VSX-LX303, LG C8 65" OLED
SamuriHL is offline   Reply With Quote
Old 1st October 2011, 21:30   #9930  |  Link
naoan
Registered User
 
Join Date: Oct 2009
Posts: 152
@nand-chan
I'm working with coreavc on 720p lossless h.264 videos (one of them being 58MB/s 60FPS) and see no artifact at all. I can't comment on the speed (not sure how to do proper benchmark for 10 bit), but the cpu consumption seems about the same. Actually, seeking seems to be faster on coreavc.

By screwing up I mean something like that dither problem on ffdshow you explained earlier, though yeah, maybe the decoder like ffdshow is a better place for it to be.

I dunno about the detail but flash3kyuu readme specify that it could feed 16 bit output to x264 (to be dithered there to 10 bit), haven't tried it yet though.

btw, do you have another alternative for debanding 10 bit video without first converting it to 8 bit?
naoan is offline   Reply With Quote
Old 1st October 2011, 21:42   #9931  |  Link
nand chan
( ≖‿≖)
 
Join Date: Jul 2011
Location: BW, Germany
Posts: 380
Quote:
Originally Posted by naoan View Post
@nand-chan
I'm working with coreavc on 720p lossless h.264 videos (one of them being 58MB/s 60FPS) and see no artifact at all. I can't comment on the speed (not sure how to do proper benchmark for 10 bit), but the cpu consumption seems about the same. Actually, seeking seems to be faster on coreavc.
http://img683.imageshack.us/img683/7264/faildwz.png

I'm not sure at what bitrate the issue occurred but multiple people have been experiencing it. I think it was like 30 Mbps for 24 Hz.

Either way, maybe it's fixed already?

Quote:
By screwing up I mean something like that dither problem on ffdshow you explained earlier, though yeah, maybe the decoder like ffdshow is a better place for it to be.
The decoder shouldn't touch video at all, imo - video processing should be in a processing filter. Otherwise you're gonna get issues later on. (eg. what if you view a video file that doesn't get decoded by ffdshow, how do you get avisynth scripts for that?)

That's why it's important to distinguish between the ffdshow /decoder/ and the ffdshow /filter/. The decoder should never do anything, and you should never enable any post-processing in the decoder either.

All post processing should be done in the raw filter, including avisynth, because it works for everything.

Quote:
I dunno about the detail but flash3kyuu readme specify that it could feed 16 bit output to x264 (to be dithered there to 10 bit), haven't tried it yet though.
Oh, neat. I guess you could use the standalone version of flash3kyuu independently of avisynth as well (it's open source after all).

Quote:
btw, do you have another alternative for debanding 10 bit video without first converting it to 8 bit?
I'm not really a video encoder, so no.
__________________
Forget about my old .3dlut stuff, just use mpv if you want accurate color management
nand chan is offline   Reply With Quote
Old 1st October 2011, 21:51   #9932  |  Link
TheShadowRunner
Registered User
 
TheShadowRunner's Avatar
 
Join Date: Feb 2004
Posts: 399
Quote:
Originally Posted by nand chan View Post
In fact, LAV is faster than CoreAVC for 8-bit as well if you have a CUDA graphics card.
It's not the case.
For 8-bit, CoreAVC w/CUDA is actually faster than LAV w/CUDA.
__________________
XP SP3 / Geforce 8500 / Zoom Player
TheShadowRunner is offline   Reply With Quote
Old 1st October 2011, 22:04   #9933  |  Link
naoan
Registered User
 
Join Date: Oct 2009
Posts: 152
Quote:
Originally Posted by nand chan View Post
http://img683.imageshack.us/img683/7264/faildwz.png

I'm not sure at what bitrate the issue occurred but multiple people have been experiencing it. I think it was like 30 Mbps for 24 Hz.

Either way, maybe it's fixed already?
Seems so, they're quick to release 3.0.1.

Quote:

The decoder shouldn't touch video at all, imo - video processing should be in a processing filter. Otherwise you're gonna get issues later on. (eg. what if you view a video file that doesn't get decoded by ffdshow, how do you get avisynth scripts for that?)

That's why it's important to distinguish between the ffdshow /decoder/ and the ffdshow /filter/. The decoder should never do anything, and you should never enable any post-processing in the decoder either.

All post processing should be done in the raw filter, including avisynth, because it works for everything.
The problem is, there really is no raw filter that could avisynth post processing beside ffdshow and I'd like more option beside it. But ideally, if a decoder is able to do compressed video it should be able to do post processing on raw video too, though then we'd just get another ffdshow.

Quote:


Oh, neat. I guess you could use the standalone version of flash3kyuu independently of avisynth as well (it's open source after all).
Uh no, flash3kyuu exclusively avisynth filter, to my knowledge there is no way to call it without going through avisynth. Doesn't this mean that avisynth is able to output 16 bit video?

Quote:
I'm not really a video encoder, so no.
Then the ideal solution should be for the madvr to have flash3kyuu_deband or other high profile debanding filter built in imho .
naoan is offline   Reply With Quote
Old 1st October 2011, 22:12   #9934  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 9,759
Quote:
Originally Posted by TheShadowRunner View Post
It's not the case.
For 8-bit, CoreAVC w/CUDA is actually faster than LAV w/CUDA.
I suppose that may depend on the samples used, but i have a full set of h264 and vc1 tests that put lav video in cuvid mode about 1-2% above CoreAVC.

Its never a really big difference, i would be fine with calling them equally fast, as its really the hardware doing the decoding.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders
nevcairiel is offline   Reply With Quote
Old 1st October 2011, 22:23   #9935  |  Link
TheShadowRunner
Registered User
 
TheShadowRunner's Avatar
 
Join Date: Feb 2004
Posts: 399
Quote:
Originally Posted by nevcairiel View Post
I suppose that may depend on the samples used, but i have a full set of h264 and vc1 tests that put lav video in cuvid mode about 1-2% above CoreAVC.
I guess it must depend on the sample used, indeed ^^;

Quote:
i would be fine with calling them equally fast, as its really the hardware doing the decoding.
That would make sense to me too! but..
__________________
XP SP3 / Geforce 8500 / Zoom Player
TheShadowRunner is offline   Reply With Quote
Old 1st October 2011, 22:25   #9936  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 9,759
Quote:
Originally Posted by TheShadowRunner View Post
I guess it must depend on the sample used, indeed ^^;
You realize that the rendering time madVR shows has absolutely nothing to do with the performance of the decoder, right?
BTW, LAV is still faster on that sample for me.

Benchmark your sample with GraphStudio, that will get you the actual performance of the video decoder. (I dont remember if you tried that already)
If there is a big difference, then thats another thing.

Since i cannot reproduce your problem, thats rather problematic.
If you want, head over to the LAV thread and post your exact madVR settings, maybe its a combination of special settings that causes this weird interaction. No reason to keep spamming this in here.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders

Last edited by nevcairiel; 1st October 2011 at 22:35.
nevcairiel is offline   Reply With Quote
Old 1st October 2011, 22:43   #9937  |  Link
TheShadowRunner
Registered User
 
TheShadowRunner's Avatar
 
Join Date: Feb 2004
Posts: 399
Quote:
Originally Posted by nevcairiel View Post
You realize that the rendering time madVR shows has absolutely nothing to do with the performance of the decoder, right?
True, what I don't get really is why madVR seem to be struggling almost twice more with LAV's output versus Core's.
Since they both go through CUDA, I'd expect exactly similar outputs to madVR.
If this is the case and madVR receives the same, the difference has to be due to the decoder. (since it's the only change in the graph)

But yes, I took for granted that madVR gets the same output, am I wrong on this?

Quote:
Originally Posted by nevcairiel View Post
Benchmark your sample with GraphStudio, that will get you the actual performance of the video decoder. (I dont remember if you tried that already)
If there is a big difference, then thats another thing.
GraphStudio crashes all the time in haali's splitter.ax.
I have to postpone the test, thanks for the suggestion
__________________
XP SP3 / Geforce 8500 / Zoom Player

Last edited by TheShadowRunner; 1st October 2011 at 22:47.
TheShadowRunner is offline   Reply With Quote
Old 1st October 2011, 22:44   #9938  |  Link
nand chan
( ≖‿≖)
 
Join Date: Jul 2011
Location: BW, Germany
Posts: 380
Quote:
Originally Posted by naoan View Post
Uh no, flash3kyuu exclusively avisynth filter, to my knowledge there is no way to call it without going through avisynth. Doesn't this mean that avisynth is able to output 16 bit video?
No, what I mean is take the actual algorithm out of the source code and wrap it inside your own directshow filter / shader / renderer / decoder / whatever.

It's written in C, not avisynth script. (And even if it were, it's trivial to just translate it)

Quote:
Then the ideal solution should be for the madvr to have flash3kyuu_deband or other high profile debanding filter built in imho .
This would probably be the best solution, yeah.
__________________
Forget about my old .3dlut stuff, just use mpv if you want accurate color management
nand chan is offline   Reply With Quote
Old 1st October 2011, 23:45   #9939  |  Link
naoan
Registered User
 
Join Date: Oct 2009
Posts: 152
Ah sorry for the misunderstanding, Can we agree for debanding filter on madvr as a feature request?

Though at this point I'd consider it a bonus as madvr is already goddamn awesome as it is.

@nevcairiel
I remember about graphstudio after you mentioned it, and for the heck of it benchmarked lavfilter against coreavc with the lossless h.264. Surprisingly (for me) Lav is actually about 14 FPS faster (98 vs 112) than coreavc, strangely though it is noticeably slower at seeking the video when you're actually playing it via media player (used mpc-hc).

Last edited by naoan; 2nd October 2011 at 00:30.
naoan is offline   Reply With Quote
Old 1st October 2011, 23:56   #9940  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 9,759
Seeking performance greatly depends on where you actually seek. If you manage to seek directly on a keyframe (or shortly after it), seeking will be fast. If you seek in the middle between two keyframes, it'll probably take a while to recover. Due to that behaviour, truely objective comparisons are really hard, unless you use fixed time seek points, and not random clicking in the movie.

From my own tests, i can't really say that CoreAVC is faster, and from what i know about DirectShow, its not really in the decoders power to influence seeking speed all that much. If the seek request is at a bad position, and the file is encoded with very few key frames, it will just take a while to recover.
I still think people are far too obsessed with seeking, though. Watch the movie already!
__________________
LAV Filters - open source ffmpeg based media splitter and decoders

Last edited by nevcairiel; 2nd October 2011 at 00:07.
nevcairiel 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 04:11.


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