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. |
1st October 2011, 18:59 | #9921 | Link |
Registered User
Join Date: Aug 2008
Location: the Netherlands
Posts: 851
|
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. |
1st October 2011, 20:01 | #9922 | Link | |||
( ≖‿≖)
Join Date: Jul 2011
Location: BW, Germany
Posts: 380
|
Quote:
Quote:
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:
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? I don't downscale luma.
__________________
Forget about my old .3dlut stuff, just use mpv if you want accurate color management |
|||
1st October 2011, 20:07 | #9924 | Link |
Registered User
Join Date: Oct 2009
Posts: 151
|
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. |
1st October 2011, 21:00 | #9927 | Link | |||
( ≖‿≖)
Join Date: Jul 2011
Location: BW, Germany
Posts: 380
|
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:
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:
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, 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? 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 |
|||
1st October 2011, 21:19 | #9928 | Link |
Registered User
Join Date: Aug 2008
Location: the Netherlands
Posts: 851
|
[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? |
1st October 2011, 21:30 | #9930 | Link |
Registered User
Join Date: Oct 2009
Posts: 151
|
@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? |
1st October 2011, 21:42 | #9931 | Link | ||||
( ≖‿≖)
Join Date: Jul 2011
Location: BW, Germany
Posts: 380
|
Quote:
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:
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:
Quote:
__________________
Forget about my old .3dlut stuff, just use mpv if you want accurate color management |
||||
1st October 2011, 21:51 | #9932 | Link | |
Registered User
Join Date: Feb 2004
Posts: 399
|
Quote:
For 8-bit, CoreAVC w/CUDA is actually faster than LAV w/CUDA.
__________________
XP SP3 / Geforce 8500 / Zoom Player |
|
1st October 2011, 22:04 | #9933 | Link | ||||
Registered User
Join Date: Oct 2009
Posts: 151
|
Quote:
Quote:
Quote:
Quote:
|
||||
1st October 2011, 22:12 | #9934 | Link | |
Registered Developer
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,346
|
Quote:
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 |
|
1st October 2011, 22:23 | #9935 | Link | ||
Registered User
Join Date: Feb 2004
Posts: 399
|
Quote:
Quote:
__________________
XP SP3 / Geforce 8500 / Zoom Player |
||
1st October 2011, 22:25 | #9936 | Link | |
Registered Developer
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,346
|
Quote:
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. |
|
1st October 2011, 22:43 | #9937 | Link | ||
Registered User
Join Date: Feb 2004
Posts: 399
|
Quote:
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:
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. |
||
1st October 2011, 22:44 | #9938 | Link | ||
( ≖‿≖)
Join Date: Jul 2011
Location: BW, Germany
Posts: 380
|
Quote:
It's written in C, not avisynth script. (And even if it were, it's trivial to just translate it) Quote:
__________________
Forget about my old .3dlut stuff, just use mpv if you want accurate color management |
||
1st October 2011, 23:45 | #9939 | Link |
Registered User
Join Date: Oct 2009
Posts: 151
|
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. |
1st October 2011, 23:56 | #9940 | Link |
Registered Developer
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,346
|
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. |
Tags |
direct compute, dithering, error diffusion, madvr, ngu, nnedi3, quality, renderer, scaling, uhd upscaling, upsampling |
Thread Tools | Search this Thread |
Display Modes | |
|
|