2011-01-28, 19:55 | Link #61 | |||
気持ち悪い
Join Date: Dec 2005
Location: New Zealand
|
Quote:
Or am I wrong to think of the ASIC as a discrete device, in that it's physically a block on the GPU die but functionally distinct? Quote:
Quote:
__________________
Last edited by Simon; 2011-01-28 at 20:09. Reason: Accuracy doesn't apply to video renderers. duh |
|||
2011-01-28, 21:47 | Link #62 | ||||
Excessively jovial fellow
Join Date: Dec 2005
Location: ISDB-T
Age: 38
|
Quote:
Quote:
Note that when I said these things are small and cheap, I meant it. They usually cost less than $5 USD each when you buy in bulk, they only require a few megabytes of memory (the maximum required decoded picture buffer for h264 level 4.1 is just ~12 megabytes big, IIRC) and they don't require active cooling. Quote:
Quote:
When high bitdepth encoding starts to become popular later this year (x264 can already encode it, and a matching decoder for FFmpeg is under development) I will laugh and laugh and laugh at all the poor fools who built media PC's with slow CPU's and relied on the graphics card to do the job, because suddenly their prized hardware acceleration will be completely unable to help them.
__________________
Last edited by TheFluff; 2011-01-28 at 21:59. |
||||
2011-01-28, 23:23 | Link #63 |
Senior Member
Join Date: Dec 2008
|
Luckily even cheap low power CPUs like the Core i3 have no problem handling HD content. But yeah, I wouldn't rely on any graphic card myself. Even though they can handle all current encodes, you never know what the future will bring. (Like said 10 bit encoding) And you don't have to mess around with buggy drivers and decoders - it simply works.
Last edited by sneaker; 2011-01-28 at 23:36. |
2011-02-04, 13:31 | Link #64 | ||||
Team Spice and Wolf UK
Join Date: Feb 2010
Location: England
Age: 36
|
Quote:
As an example, a HTPC review I read a little while ago flagged up that whilst all current 5*** series could decode 1080p with no issues, with an additional hardware denoise filter on top, whereas with Nvidia, the GT210 wasn't actually strong enough, you needed a GT220 or above. I might be wrong here, as this isn't my 'area', but additionally, a quick flick around Wiki (apologies I know its not a great source) and the web would suggest there are quite a few more than 4-5 various different chip designs out there capable of decoding h.264, and available in ASIC form for integration into larger devices. Quote:
Quote:
Seeing as you seem fairly clued up, I'm actually kinda surprised you had to ask what I meant by HD Audio though, seeing as its one of the more common ways of referring to DTS-MA/DDTHD. An increasing number of people are running MKVs with embedded DTS-MA/THD ripped straight from the bluray, especially as its now so easy to do so, and space is no longer a constraint like it used to be. As an example, people mention some of the issues here whilst discussing other issues: http://www.avsforum.com/avs-vb/showthread.php?t=1247893 Quote:
A HUGE number of people out there have machines, even relatively modern ones (lower Core2 or equivalent X2 as an example), that couldn't handle decent HD rips well, especially not 1080p ones without dropping frames. We're not just talking toys here, but a wide range of otherwise perfectly reasonable desktops and laptops, that simply don't have enough raw grunt to deal with 1080p effectively. If the machine is suitable for the other intended uses (most likely internet and office work), then what makes more sense - overhaul the system for several hundred pounds/dollars, or fitting a cheap video card with a built in decoder that'll do the work for you? Even with limitations, I don't call that a joke, I call it progress. Additionally, a weaker CPU and capable decoding card can be run passive or with low speed fans, in many cases quite successfully, whereas a more powerful machine tends to produce more heat and will usually require more potent cooling. Either way you look at it, there are some real benefits to hardware decoding, and stating they are only useful for mobile devices seems rather shortsighted, people's machines and thier usage patterns or design aims can be as individual as the user. Personally, I tend to use relatively high end PCs or laptops, and even then, being able to decode video with minimal heat and noise generated whilst doing so is still pretty appealing!
__________________
Last edited by tyranuus; 2011-02-04 at 14:13. |
||||
2011-02-05, 04:48 | Link #65 | |||||
Excessively jovial fellow
Join Date: Dec 2005
Location: ISDB-T
Age: 38
|
Quote:
Quote:
A quick look at ATI's UVD documentation hints that the situation is similar there as well; there seem to be three different feature sets (i.e. three different generations of decoder chips). Quote:
Quote:
Quote:
Also, you keep using the word "whilst". Just for your information, using that in a forum post makes you look like a pretentious faggot. Hope this helps.
__________________
|
|||||
2011-02-05, 12:51 | Link #66 | ||||||
Team Spice and Wolf UK
Join Date: Feb 2010
Location: England
Age: 36
|
Quote:
At the end of the day, my personal conviction is that if something does the job in hardware with reduced power consumption and heat, for most purposes acceptably; then it's a step forward. Everything with PCs has always been a trade off between the factors of heat, power and noise (usually in that order). This is simply another step along that road. There's always going to be exceptions where something different is needed, or something a little bit more...flexible, but I'm surprised you don't seem to see benefits from being able to offload decoding and filtering in hardware even using a normal PC. Most people I know want a quiet (and cheap) PC that performs reasonably well for the tasks at hand, regardless of whats going on, hardware decoding works towards that goal, which is why everyone seems to be adding it. It makes a bigger difference on phones/ULV laptops/Netbooks/AIO boxes, but there is still a fair place in a standard PC for it. Quote:
I believe ATI may have undergone a couple of subrevisions on UVD suggesting revisions of the ASICs, but either way that's not really that important. In terms of drivers they're both pretty lol at points now, Nvidia certainly seem to have nosedived a bit. Then again I am a little biased after massive issues with Nvidia driver-caused DPC latency issues on a recent platform I used, which was an absolute nightmare. Quote:
http://blogs.amd.com/play/2010/04/28...E2%80%99s-new/ Multiple players (at the least, I recall it mentioned in release notes for MPC-HC and VLC) support ATI's accelleration. Note also the particular stipulation that they are no longer limited to a hard limit of 2048, but support 4kx2k. Now whether it works properly I don't know, I've already said that, but it does appear to disagree with your statement. Quote:
The difference between file size of a FLAC encode and a DHD encode often actually isn't that big, but FLAC is usually a fair bit more efficient than DTS-MA. Still, with space at a lower premium than it used to be, sometimes time/ease does come up. You're right though, although audio format is still relevant in terms of playback in general terms (especially for thos who want to bitstream), this section all sprung up from the misunderstanding of which section of Haali's you were referring to rather than DXVA, so apologies for sidetracking there! Quote:
You've got more efficient decoders out there like CoreAVC which will run most stuff on just about anything modern, but the most common software decoder is going to be FFDShow, and that does sometimes struggle to decode decent quality rips at 1080p on older CPUs. CoreAVC'll do it, but again, in the scheme of things not many people have that. Most people want to whack a codec pack/ffdshow on and use WMP, or perhaps use MPC-HC and for it to work fine from the go. Most machines will have some background tasks running, be it MSN, AV, whatever meaning that 100% of the CPU usually won't always be available. You could argue that not having an exceptionally clean PC, and the fastest software decoder in this situation is doing it wrong, but it is a reasonable representation of the average PC. If people are doing things like running subs or even karaoke subs increasing CPU usage elsewhere then that's even more apparent. (and given we're talking on an anime forum here, that IS relevant- it's not the video decoding itself but it's part and parcel with the viewing experience). In this sort of 'average joe' situation, with his average pc, offloading the decoding makes perfect sense. Most videos out there will play appropriately, it removes a lot of the dependancy on the host system, and frees up more resources for other tasks the system may or may not be handling. As an example, despite the fact my machines are MORE than capable of software decoding (well bar my download box), I tend to use hardware accelleration for the aforementioned heat and power reasons, and also because it means I can watch a video whilst doing whatever else I want at the time with virtually no impact. Kinda nice to be able to watch a video and file convert or run an encode in the background with virtually no impact on the time taken. Makes waiting a lot more tolerable. Quote:
Heh, not the intention, just trying to have a realistic discussion on the subject. I wouldn't say using the word TWICE is a massive over use though, not like I used it every sentence!
__________________
Last edited by tyranuus; 2011-02-05 at 15:47. |
||||||
2011-02-05, 15:17 | Link #68 |
Team Spice and Wolf UK
Join Date: Feb 2010
Location: England
Age: 36
|
I know FFDShow is multithreaded out the box, but I've got a feeling FFMpeg actually isn't surprisingly (which has a knock on effect). Could be wrong here, but I remember a massive discussion on XBMC and other related forums about increased system requirements during the shift between Camelot and Dharma builds, which the devs highlighted as being down to the fact that they could no longer use a multi-threaded patch that had been used in Camelot with the current version of the decoder. [If I'm wrong there, don't shoot me Fluff ]
Subtitles at higher res with animation also seem to be surpringly CPU heavy sometimes, one of my friends was trying to run 720p on an old single core 3700+ and couldn't work out what was killing the system with CoreAVC in use. Turned out the subs were sapping almost 50% of the CPU at times. I'll actively admit though thats really moving outside the bounds of stuff I know anything about though, as generally I can't stand coding, linux and related.
__________________
Last edited by tyranuus; 2011-02-05 at 15:43. |
2011-02-05, 15:22 | Link #69 |
Senior Member
Join Date: Dec 2008
|
The ffdshow versions I used were pre-configured to single thread only and as far as I know the multi threaded ffmpeg h.264 decoder is still a patch (ffmpeg-mt) and not in the main branch. (Not sure though)
VLC also didn't use multiple threads (or at least not frame based multi-threading) until sometime last year. I don't know when multi-threading was introduced to mpc-hc or if it depends on the one who builds the binary. |
2011-02-05, 22:02 | Link #70 |
Senior Member
Join Date: May 2006
Location: California
|
For a long time now, all builds of FFDshow Tryouts have had both the single-threaded libavcodec and multi-threaded ffmpeg-mt selectable for h.264 decoding. MPC-HC also uses ffmpeg-mt for it's built-in h.264 decoder.
An AMD X2 at 2Ghz+ should be able to decode 1080p h.264 just fine with any multi-threaded decoder. I would know, as I still have a computer using a 2.4Ghz AMD X2 4800+ (939) from 2005. You're looking at around 40-50% CPU during low-motion and 60-70% CPU during high-motion when playing 1080p @20Mbps avg w/ 5.1 audio and basic softsubs using FFDshow with ffmpeg-mt.
__________________
|
2011-02-06, 05:22 | Link #71 | |
Excessively jovial fellow
Join Date: Dec 2005
Location: ISDB-T
Age: 38
|
Quote:
__________________
|
|
2011-02-06, 16:34 | Link #72 |
Senior Member
Fansubber
Join Date: May 2010
Location: Spain
Age: 33
|
Eh... I haven't tried a lot of 1080p (I don't even have a use for anything above 480p since I watch everything at that res anyway) but the few 1080p vids I've watched did struggle with certain scenes. This is on a 1.6GHz Core2Duo with CoreAVC and not much of anything beyond core system processes running on the background and a clean system. Hell, I've seen certain scenes in 720p bringing MPC-HC close to 85% CPU usage already.
|
2011-02-06, 23:42 | Link #73 |
Senior Member
Join Date: May 2006
Location: California
|
Since the AMD X2 desktop processors perform similar to the Core 2 Duo moblie processors, it's the same deal where you would want 2Ghz+. With laptop limitations in general, 2.4Ghz to be really safe. This of course doesn't apply to the Core i3/i5/i7 mobile processors released recently.
PositronCannon, if your laptop doesn't have 1920x1080 screen, there would be no point of watching 1080p anyway. Just limit yourself to 720p, which you seem to be able to playback just fine, and is likely a close match to your screen resolution.
__________________
Last edited by cyberbeing; 2011-02-07 at 00:03. |
2011-02-07, 09:08 | Link #75 | |
Senior Member
Join Date: Dec 2009
Location: Sydney, Australia
|
Quote:
My laptop with a Core 2 Duo L7500 @ 1.6GHz hasn't seen any lag in 1080p video that wasn't related to subtitles (cough DirectVobSub cough), but I don't have/play much that is 1080p. Last edited by namaiki; 2011-02-07 at 09:37. |
|
2011-02-07, 09:44 | Link #76 |
Senior Member
Fansubber
Join Date: May 2010
Location: Spain
Age: 33
|
Yeah, I've always had it at 100% minimum. Still, I think it was probably just some particular encode(s). Generally it stays around 50% with occassional peaks at maybe 70%, certainly more than enough to play anything 720p without an issue. Even before using CoreAVC I still barely had any noticeable frame drops.
|
2011-02-16, 05:15 | Link #80 | |
Junior Member
Join Date: Aug 2009
|
http://www.anandtech.com/show/4181/n...ts-this-year/3
Quote:
The future is so great while so many Luddites are still stuck in the past with CPU decoding wasting power all the time, using 35/65/95 watts of power to decode. |
|
Tags |
guide, h.264, wiki candidate |
|
|