BakaBT > Announcements
Hi10P and 8-bit encodes
OnDeed:
It's not about cpu at all. Madvr needs gaming GPU, period. It like, does stuff with shaders you know, meaning that if you run it on a slow card, you simply won't hit realtime playback. And people sort of expect video renderer to always work, whatever the input resolution and framerate is...
In this regard, madvr has the downsides of haali renderer of years ago, only 20x worse (since the average gpu power has risen, :P)
Aadieu:
--- Quote from: RedSuisei on January 02, 2012, 09:35:28 PM ---
--- Quote from: Aadieu on January 02, 2012, 09:26:29 PM ---If you're looking for red circles and yellow text - that part was added by me.
Otherwise, your screenshot appears to be the same. With loads of banding.
--- End quote ---
It seems you have a problem with your display (or maybe your eyes). I certainly don't see any banding in cyberbeing's shots. Even if there are any, it certainly doesn't look like your screenshot, which suggests you have a problem with both your player and your display (or eyes, maybe)
--- End quote ---
[/quote]
Looked at it again, side by side, yep, less banding in his. Still some there (less on the thighs, but there; still some on the bag), but not as bad.
Filter? Different decoder?
Different frames? Cause I will freely admit that I scrolled through that scene frame by frame and went with the worst-offending banding I could find. And I didn't use any anti-banding filters or GPU-intensive decoders, just whatever Pot Player's default was.
But if it is the very same frame... See what I mean about the standard's software side not being very mature? Different software is producing significantly different results. And, chances are, neither of us knows exactly what he's doing right/wrong/differently to get where he is.
DmonHiro:
--- Quote from: OnDeed on January 02, 2012, 10:27:43 PM ---It's not about cpu at all. Madvr needs gaming GPU, period.
--- End quote ---
Perhaps I'm confusing something, but weren't current GPUs unable to process 10bit videos correctly, and as such everything fell on the CPU? Isn't that why DXVA cannot be used with 10bit and why people bitch that 10bit decoding is software only?
OnDeed:
Ummm...
You seem to be completely mixing two things: video decoding and video rendering.
1) video decoding takes in h.264 from the demuxer and decodes it to uncompressed yuv frames.
2 video rendering takes in uncompressed yuv frames (in case of 10-bit, optionally downconverting them to plain 8-bit yuv), scales them to desired resolution and finally converts them to rgb colourspace. Then it tells the vga to put it on display at some timestamps.
DXVA does strictly 1).
Madvr does strictly 2). Madvr's goal is to do everything in step 2) using high-quality algorithms on the gpu, with shaders.
What 10-bit breaks about DXVA is stuff strictly belonging to 1) - decoding. DXVA can only do 8bit, because it is more or less fixed function hardware. Thus with 10bit, everything needs to be done on cpu in step 1).
Renderers don't just use gpu for doing step 2), they usually need some cpu power too, like games. It's probably just overlay renderer that can have negligible cpu usage. Without gpu acceleration though, they would be orders of magnitude slower. Software rendering of video wasn't even viable in the past. You can try it: have ffdshow use its scaler filter to get into fullscreen and force rgb output (there will still be some gpu work with drawing and refreshing, but...)
The only issue that 10-bit causes for step 2) is that most renderers aren't ready for input of 10-bit uncompressed frames (exceptions are MPlayer's -vo gl and madvr afaik). This is easily solved by inserting a downconversion filter at the end of step 1), which most decoders do, eliminating this problem. Alternativelly, you can push conversion to rgb from step 2 here, doing it at end of step 1) on cpu (example: lav video or ffdshow with rgb32 output forced).
TL;DR
For doing its stuff (step 2), MadVR needs lots of gpu shader power (because it does it in a high-end uncompromising way).
Note that madvr has optional decoders to do step 1, but that is irrelevant, it is simply as if it bundled its own small personal ffdshow along. Nothing changes about the process.
DmonHiro:
--- Quote from: OnDeed on January 02, 2012, 11:17:48 PM ---TL;DR
For doing its stuff (step 2), MadVR needs lots of gpu shader power (because it does it in a high-end uncompromising way).
Note that madvr has optional decoders to do step 1, but that is irrelevant, it is simply as if it bundled its own small personal ffdshow along. Nothing changes about the process.
--- End quote ---
Aha.... thanks, now I get it. So are you saying that one does not need to use madvr to display 10bit properly, because that's what I was let do believe.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version