AnimeSuki Forums

Register Forum Rules FAQ Members List Social Groups Search Today's Posts Mark Forums Read

Go Back   AnimeSuki Forum > Anime Related Topics > Fansub Groups

Notices

Reply
 
Thread Tools
Old 2005-12-25, 23:30   Link #61
Sylf
翻訳家わなびぃ
*Fansubber
 
 
Join Date: Nov 2003
Age: 40
Send a message via MSN to Sylf Send a message via Yahoo to Sylf
Simplicity?

I actually fail to see what makes XviD/AVI is simpler than h.264/MKV or, even h.264/MP4. AVI requires AVI splitter, and XviD requires XviD decoder. Of course, same goes with audio decoder - it just happens that MP3 directshow decoders are included in more modern versions of Windows and/or Windows Media Player.

h.264/<whatever container> is absolutely no different. You need a splitter, a video decoder, and an audio decoder. Most of the time, the AVI decoder gets downloaded upon the first time WMP tries to play such file. Otherwise, windows actually lacks AVI splitter by default. We've seen such case before - it happened within a past year, which the thread was lost, but we've seen it. In such case, solving the problem is absolutely no different than supporting people to enable MKV playback.

The only thing that MKV/MP4 camp is losing out is the history - they are both new kids on the block. Many people are still only learning to play with them. But it won't be for long. AVI is a dying container. Even Microsoft has ditched it and moved on to ASF container.

Before this thread was destroyed once, a few people reminded us of those chaos days when the fansub groups started switching from DivX3 to XviD. Some people cried against XviD back then, complaining that the technology was too young. That cry didn't last too long - before too long, we couldn't find a group that still used the old technology. Now is the time for XviD to be left behind as old technology and the community seeks out the new technologies.

And the knowledgebase will quickly be expanded, and people will not feel any pain playing MKV/MP4/AAC/Vorbis/AVC contents. Afterall, it's not hard at all.
Sylf is offline   Reply With Quote
Old 2005-12-26, 07:10   Link #62
LytHka
Banned
 
Join Date: Jan 2004
Quote:
Originally Posted by TheFluff
Now on to something completely different - namely the relative suckage of the evil player known as VLC. LytHka is, as we've seen many times before, talking in his sleep or something. I cannot verify this much lower CPU usage in any way.
Talking in my sleep, eh? Well, you forced me to repeat this test, using task manager, on MPC, Winamp and VLC. The MPC vs. Winamp difference is minimal (while I switched the skin in Winamp a few times to see if the modern ones contribute to higher CPU usage ), possibly in favor of MPC, while the difference in MPC, Winamp vs. VLC is quite apparent.
Spoiler for Winamp:

Spoiler for MPC:

Spoiler for VLC:


Perhaps your computer doesn't like VLC? But that is no reason for such hate against it. Upgrade your computer? One other thing I should note is that my PC is probably *a lot* slower than yours (AMD 2500 Barton, 256 MB DDR400 RAM, Radeon 9500 Pro 128 MB DDR, a dying disc ) so my other playback configuration shouldn't be screwed up (the one that is not VLC). I should also note that I turned off most of background OS processes (even my Firewall) just for this comparison. Otherway, I think it would've been pretty much the same.
Now, about the usage of softsubs, I think you know what I mean when I say that they are not needed with fansubs.

/me dances for the quick Fluffy ownage

Last edited by LytHka; 2005-12-26 at 07:36.
LytHka is offline   Reply With Quote
Old 2005-12-26, 08:53   Link #63
Mentar
Sore wa himitsu desu!
 
 
Join Date: Nov 2003
Location: Hamburg
Age: 44
I've been trying to reproduce these alleged huge savings on several of my systems, and the result is fairly conclusive: The speed advantage of vlc averages around 10%, it very rarely exceeds 20% in peaks. Now add in the fact that most of the gains get lost when the postprocessing default in vlc gets changed from "off" to "5" (the default equivalent of the codec pack you hate so much), and the "advantage" of vlc nearly evaporates.

It should be noted that turning off postprocessing in h264 sources comes at a price, because it creates artifacts. I don't know the vlc intrinsics, but it exhibits the very same decoding glitches you get when you choose the strongly discouraged "unsafe" settings of ffdshow, so I'd assume it's the very same and should be changed anyway.

So you want to trade 10% of CPU savings for artifacts in your playback? I'm not so desperate and I'd guess most other anime fans aren't either. If you're REALLY strapped for CPU, you can go back to the "disable deblocking where it's safe" settings in ffdshow. You shouldn't go beyond.

About the subtitles: The majority of modern h264 releases are softsubbed. And during my tests I recently had to find out that not only vlc cannot render soft signs, it doesn't even filter out comments. So unless the release you use it with offers a stripped SRT track, you'll suddenly see editor and TL comments in your playback. Besides, having to manually ACTIVATE subtitle playback isn't very beginner-friendly either.

What remains is the anime fan's choice what kind of solution he is looking for. If he wants a proper playback solution which fully supports all common subtitle formats, embedded fonts and what comes with it, vlc is sorely lacking and completely insufficient. If he wants a reduced solution for pure hardsubs (more or less a subset of what you deem 'appropriate' for him to watch) and doesn't mind playback artifacts, vlc is an option.
Mentar is offline   Reply With Quote
Old 2005-12-26, 09:07   Link #64
LytHka
Banned
 
Join Date: Jan 2004
For the record, I used the default VLC values (the ones I got with the installation).

Also...
Quote:
Originally Posted by Mentar
It should be noted that turning off postprocessing in h264 sources comes at a price, because it creates artifacts. I don't know the vlc intrinsics, but it exhibits the very same decoding glitches you get when you choose the strongly discouraged "unsafe" settings of ffdshow, so I'd assume it's the very same and should be changed anyway.
Laff, tell me, how does "no postprocessing" create artifacts? Postprocessing removes artifacts, but it's the encoder's fault that they are there in the first place or more like it's the decoder's, but that should've been taken into account beforehand. If encoders count on viewers to have postprocessing enabled, they should inform them.
Tell me, do fansub comparison sites use postprocessing when taking screenshots?
LytHka is offline   Reply With Quote
Old 2005-12-26, 09:17   Link #65
SirCanealot
What? I am washed up!
 
 
Join Date: Feb 2003
Location: London, England
Age: 29
Send a message via MSN to SirCanealot
Isn't H.264's postprocessing built in? And isn't it meant to be ran at all times, under normal circemstances?
I mean, that's why the option for deblocking is there in the decoder, isn't it? And it's not like the deblocker running at 0/0 causes that much of a disadvantage either.

I know little about such things, so whatever ^^

And I'm having trouble believing that much of a saving for free using VLC. Magic doesn't exist, and encoding and decoding certainly don't have any magic in them. You get nothing for nothing, as they say...
__________________
SirCanealot
And they shall know no fear....
SirCanealot is offline   Reply With Quote
Old 2005-12-26, 09:54   Link #66
LytHka
Banned
 
Join Date: Jan 2004
@SirCanealot: Read my signature.


I just had to check that Mahoraba episode 12 OP and found out similar results to mine. Note that the Froth-Bite encoder tested this as well, on a much better PC and got similar CPU usage differences appropriate for his machine. These are mine screens. He'll post if he wants to.
Spoiler for MPC:

Spoiler for VLC:

In the end, there *may* be some decoder issues involved here, however, with my naked eye I could distinguish no difference in the picture during playback and even if those differences are there (I'm not excluding possibilities), they are minimal and not important for an average viewer. Furthermore, I believe this discussion about VLC was raised because there is still a significant part of leechers out there with slow PCs that have systems on the brink of AVC playback, so I think a "10% CPU drop" might be very important to them.

And here we're talking about bringing AVC closer to the "common folk"... *sigh*

Last edited by LytHka; 2005-12-26 at 10:06.
LytHka is offline   Reply With Quote
Old 2005-12-26, 10:07   Link #67
琥珀
Junior Member
 
 
Join Date: Dec 2005
Location: Taipei, Taiwan
Did someone try KMPlayer? It can play almost media files.

I like MKV files, because soft subtitles are my favorites. I usually turn off subtitles, just want to see the "pure" screen.
__________________
- 小さな事でも暖かさを....今この瞬間にも幸せになってください.. -
琥珀 is offline   Reply With Quote
Old 2005-12-26, 11:27   Link #68
TheFluff
Excessively jovial fellow
 
 
Join Date: Dec 2005
Location: ISDB-T
Age: 28
LytHka: what Mentar means by postprocessing isn't really postprocessing - it's the builtin H.264 inloop deblocking. Disabling it is a good way to break decoding, since it creates varying amounts of blocking depending on how much the loopfilter was used. In FFDShow it's on by default - to turn it off, go to Codecs -> H.264 and check "Skip deblocking when safe" and "Skip deblocking always". Then try to watch something loopfilter-intensive like Arienai-Conclave's Ginban Caleidoscope, especially in fade-in's/fade-out's and see the blockfest.
Spoiler for blockfest:

You get the idea? Turning it off for encodes where the encoder turned off the deblocking filter is more or less safe, but those are kind of rare. Both x264 and Nero has it on by default, and the lower the bitrate, the more it gets used. But even for high-bitrate encodes, it's frequently used anyway (x264 automatically disables it for frames with QP > 18, IIRC, and that's quite high - getting a QP higher than 18 on all frames means a RIDICOLOUS bitrate). If you want to I can quote pengvado on this. It's an integral part of the codec, that gets taken into account when encoding, and if you turn it off while decoding, you're basically breaking the codec.


On to the CPU usage of VLC. I don't know what FFDShow build LytHka is using, but from the looks of it, it might be some completely non-optimized build, in which case anything save the reference decoder could beat it. I've asked some people in #CCCP to do some tests, and none of them get this magical ultra-low CPU usage. With VLC 0.8.2, it's the other way around - it usually uses MORE CPU than the DirectShow players. That's not relevant, though. I await SCIENTIFIC TESTS of the CPU usage. This is getting us nowhere.
__________________
| ffmpegsource
17:43:13 <~deculture> Also, TheFluff, you are so fucking slowpoke.jpg that people think we dropped the DVD's.
17:43:16 <~deculture> nice job, fag!

01:04:41 < Plorkyeran> it was annoying to typeset so it should be annoying to read
TheFluff is offline   Reply With Quote
Old 2005-12-26, 12:06   Link #69
LytHka
Banned
 
Join Date: Jan 2004
So, in order to set things straight I downloaded teh famous CCCP and repeated this non-scientifical test. Also, I turned on that VLC postprocessing to the nr. "5", just to please the almighty encoders from CCCP who are in theory always correct yet fail numerous times in mere practice.
Spoiler for CCCP with MPC Itsudatte my Santa same scene as before:

Spoiler for VLC set to postprocessing 5 Itsudatte My Santa same scene as before:

Yep, that VLC CPU power usage did increase a bit but not drastically and it's still way below CCCP decoding. The other MPC result is pretty much similar to the ffdshow in AnimeSuki Playback Help page.

But yes, I'd love to see some *independent* *scientifical* results.

EDIT: Now to get this crap off of my machine *shrugs*

EDIT2: After reading Quarkboy's post I took another look at the graph and the CPU power usage is more or less the same. Stupid peaks.

Last edited by LytHka; 2005-12-26 at 14:03.
LytHka is offline   Reply With Quote
Old 2005-12-26, 12:36   Link #70
Durante
Junior Member
 
 
Join Date: Dec 2005
Age: 30
Quote:
Originally Posted by LytHka
But yes, I'd love to see some *independent* *scientifical* results.
I was quite skeptical of these "H.264 decoding at 3% CPU" results so I wanted to verify them and downloaded VLC.
Spoiler for VLC results:


[edit]I guess I could make some comments now about "crap" that I need to "get off my machine", but I'll refrain from doing that.[/edit]
Durante is offline   Reply With Quote
Old 2005-12-26, 12:44   Link #71
Eeknay
Gendo died for your sins.
*Fansubber
 
 
Join Date: Dec 2005
Going to throw more drama into this thread; CCCP CPU usage while playing back a Pretty Cure episode, around 40-50%. VLC CPU usage with PP turned to 5, around 20%.

(CCCP version is not the latest, the latest November one [I forget the exact date]. Machine is XP2000+, 256MB RAM, GeForce 2).
Eeknay is offline   Reply With Quote
Old 2005-12-26, 13:35   Link #72
Quarkboy
Anime Translator
 
 
Join Date: Nov 2003
Location: Tokyo, Japan
Age: 34
Send a message via AIM to Quarkboy
Hmm, I'm pretty sure that the "postprocessing" in VLC (the one that goes from 0 to 6) has nothing to do with h.264 in loop deblocking filter.
After all, that option is still there when playing xvids, right? So you're saying its function changes depending on the codec used in the playback file?

I think that VLC simply doesn't have the ability to disable the in-loop deblocking filter (unlike ffdshow). Setting the VLC postprocessing to anything higher than 0 will probably simply make the video worse assuming is was competantly encoded.

You'd have to ask the developers to be sure, but that makes sense to me.

Not to mention, the h.264 in loop deblocking filter is NOT advjustable at decode time. You set the strength for encode, and that's fixed. It's possible to skip the filter entirely, but I'm pretty sure it's impossible to modify the strength of the fly. Furthermore the ranges don't add up. h.264 deblocking has 2 paramters that can both range from -6 to 6. VLC has one parameter that ranges from 0 to 6... it just doesn't make sense to say they're connected in any way.
__________________
Yomiuri Television Enterprise
International Media Strategy Chief
Sam Pinansky
Quarkboy is offline   Reply With Quote
Old 2005-12-26, 14:09   Link #73
Mentar
Sore wa himitsu desu!
 
 
Join Date: Nov 2003
Location: Hamburg
Age: 44
Lythka: Just a little sidecomment about your snide remark:

> Also, I turned on that VLC postprocessing to the nr. "5", just to please the
> almighty encoders from CCCP who are in theory always correct yet fail numerous
> times in mere practice.

If you bother to recall the facts correctly, the CCCP guys are the ones who are generally able to solve the problems on the various boards - unlike you. They are the ones who invest hours of their time to help people with rare and obscure playback problems to track them down and solve them in their IRC channel - unlike you. They are the ones whose feedback to the main developers of filters and splitters have resulted in actual bugfixes - unlike you. And they also are the ones who pointed out and corrected the flaws in your various earlier attempts of "playback guides" ... in other words, these are the guys who solve problems _in practice_.

About your data: Let's just say that I'm unable to reproduce your results, but this might certainly be the result of differing files and playback setups. But I find it just amazing that your skilled choice of player manages to reduce the CPU load of a playback of a h.264-encoded file to 5%. I've done my 3-digit numbers of h.264 encodes, but never managed to reach values like these, no matter on which systems I played them back. Heck, not even in the good old DivX/XviD times. But congrats for shaving off CPU usages from 20% to 5%. It seems that these encodes need the CPU savings the most.

Quarkboy: I'm unable to say with certainty what vlc postprocessing actually does in detail (as I wrote), but it occasionally does exhibit exactly the same kind of artifacts I remember from my experimenting times with unsafe deblocking settings in ffdshow (used them on Shana). Maybe some vlc author can shed light on this. These artifacts tended to fade with increased postprocessing in vlc, but on the other hand, this also reduced the CPU advantage.

Now don't get me wrong, it's not my goal to diss vlc, I think it's a fine player which plays back a big chunk of modern media files nicely. I only maintain that the percentage of properly played back files is shrinking and maybe 75% nowadays. And when I see self-appointed playback gurus advocate incomplete solutions where full solutions are available (especially with patronizing reasons like "these files you can't play back with it are the ones you shouldn't watch in the first place"), I find this worth mentioning
Mentar is offline   Reply With Quote
Old 2005-12-26, 14:38   Link #74
TheFluff
Excessively jovial fellow
 
 
Join Date: Dec 2005
Location: ISDB-T
Age: 28
@LytHka: did you go back on that "VLC uses 100% less CPU" or not? I'm not sure which of the edits to read...

In any case, doesn't someone else find it a bit... WEIRD that a file that plays at about 12-18% CPU usage on my A64 X2, NO MATTER WHAT PLAYER I USE (I tested it with MPlayer-dev-CVS-050928, and while that is one or a few percent faster than DShow or VLC, it's still nowhere near LytHka's results), plays with almost NO CPU usage on LytHka's Barton (I'm referring to Mahoraba 12)? Either something's weird with the testing, LytHka is lying, or there's magic about.

Just some funny anecdotes to lighten up the drama: I accidentally discovered that MPlayer apparently uses the exact same color for its overlay surface as Windows does for the Task Manager statistics, which means that if you put the Task Manager on top of MPlayer, you can see the video through the CPU/memory usage measurement bars... :P
Another funny thing you can try at home: set the postprocessing in VLC to negative, and the next time you open a video, it will instantly crash. You'd think that the programmers would do sanity checking on those inputs, but nooooo, VLC users are too clever to do something like that (or, more like, it's so damn hard to find the setting that noone would ever find it, much less change it).
__________________
| ffmpegsource
17:43:13 <~deculture> Also, TheFluff, you are so fucking slowpoke.jpg that people think we dropped the DVD's.
17:43:16 <~deculture> nice job, fag!

01:04:41 < Plorkyeran> it was annoying to typeset so it should be annoying to read
TheFluff is offline   Reply With Quote
Old 2005-12-26, 15:09   Link #75
subcool
Arienai Co-Founder
 
 
Join Date: Feb 2004
Location: Holland
Age: 30
Send a message via ICQ to subcool Send a message via AIM to subcool
Quote:
Originally Posted by Quarkboy
Setting the VLC postprocessing to anything higher than 0 will probably simply make the video worse assuming is was competantly encoded.
Using VLC's PP on H.264 causes annoying macroblocks on totally random times and occasions.
Any postprocessing does, even FFDshow's does :P

@TheFluff:
no _sane_ person would set a negative PP value, how would that work? makes the image worse?
And i believe you can not use the GUI to set it to negative values

@LytHka:
CPU usage of the decoder depends A LOT on what options are used in the encode.
I encoded some BoA video clips, the ones on wich i used insane settings (6hrs encoding for just 4 mins video) the cpu usage is pretty high.
But on ones where i used a lot less insane settings cpu usage is around 5~20% (using VLC).

Clip: 38.99.129.29/~subcool/Boa - The Love Bug.mp4 - Size: 30 MB
(Dont whine about the black bars, i did not clip anything nor use any (smoothing/sharpening) filters :P )
i used mildly insane settings on this one, this one tops at around 50% cpu usage for me. (1.83 GHz)

Hopefully decoders will get more effecient at decoding H.264 in the future
__________________
subcool is offline   Reply With Quote
Old 2005-12-26, 15:56   Link #76
iluid
Member
 
Join Date: Feb 2004
Fist, Quarkboy is right about VLC post-processing, itís not the same as the h.264 deblocking. I know how bad most h.264 encodes look when you turn off deblocking in ffdshow, this is certainly not the same as VLC post-processing at 0 since VLC does not display a blocky mess.

On to the CPU usage. I have to say I think the VLC stats are bull. Like SirCanealot said, magic doesnít exist, at least not in encoding/decoding. On my system I can reproduce the same results (actually better) as LytHka. Iím too lazy to take screenshots, so Iíll just list my results.

MPC xvid/mp3/avi Ė CPU usage varies between the extreme low of 2% and an extreme spike of 20%. Average CPU usage is about 13%.

VLC xvid/mp3/avi Ė CPU usage is not measurable. The highest peak was 2%, but average is clearly close to 0%.

MPC h.264/aac/mp4 Ė CPU usage varies between the extreme low of 10% and an extreme spike of 34%. Average CPU usage is about 24%.

VLC h.264/aac/mp4 Ė CPU usage varies between the extreme low of 0% and an extreme spike of 10%. Average CPU usage is about 2%.

System is an AthlonXP 3200+ with a Radeon 9600 pro and 512MB of RAM running Windows XP Pro SP2. XviD test file was anbu SnSIII, h.264 test file was F-B My Santa and duplicated with subcoolís Boa clip (Boa averages were about 30% on MPC and still 2% on VLC though it spent a bit less time at 0%).

Iím sorry, but Iím having trouble buying that. Even if you assume a significant difference in the test files, thereís just no way VLC should be playing h.264 far faster than ffdshow/MPC can do XviD. Iím inclined to think the VLC stats are wrong for some reason. It might be possible that VLC is able to make the video card do all the work in certain systems, but having not heard anything about such technology being present in VLC, it seems like a pretty far fetched theory. So until someone can explain how VLC is able to play back h.264 with little to no CPU power needed (apparently only on some systems), Iíd say all these results are just bad data. VLC may indeed be faster, but I doubt the difference is anything like my stats suggest.
iluid is offline   Reply With Quote
Old 2005-12-26, 16:19   Link #77
LytHka
Banned
 
Join Date: Jan 2004
Quote:
Originally Posted by TheFluff
@LytHka: did you go back on that "VLC uses 100% less CPU" or not? I'm not sure which of the edits to read...

Either something's weird with the testing, LytHka is lying, or there's magic about.
I have no reason to start a discussion about VLC with made-up data. This "data" (as we can call it now) about VLC being able to play fast came to me two days or so ago and I used it now because you blatantly spit over such a great player as it is. It's GREAT for hardcoded fansubs. Hardcoded subtitles are 99% of the time the focus of this community, not softsubs. I don't want to start a discussion about that again, but for now I can say that VLC is the easiest/fastest solution for hardsubs. But I will agree with iluid here; there probably is more to it than just the CPU data readings.
LytHka is offline   Reply With Quote
Old 2005-12-26, 16:44   Link #78
TheFluff
Excessively jovial fellow
 
 
Join Date: Dec 2005
Location: ISDB-T
Age: 28
Some pseudo-scientific tests (more scientific than looking at jpg's of graphs anyway)... This time I'm measuring CPU time. See below for test details.
MPC - first 120 seconds of F-B Mahoraba 12 (five tests):
1. 30 seconds
2. 29 seconds
3. 28 seconds
4. 29 seconds
5. 29 seconds
Average CPU time: 29 seconds
Software: MPC 6.4.8.7, ffdshow 2005-12-20 CCCP build (for both video and audio), Microsoft's builtin AVI splitter.

VLC - First 120 seconds of F-B Mahoraba 12 (five tests)
1. 20 seconds
2. 19 seconds
3. 20 seconds
4. 21 seconds
5. 20 seconds
Average CPU time: 20 seconds
Software: VLC 0.8.4a.

Zoom Player - first 90 seconds of ZX Starship Operators 09 - five tests
1. 53 seconds
2. 53 seconds
3. 52 seconds
4. 52 seconds
5. 51 seconds
Average CPU time: 52.2 seconds
Software: ffdshow 2005-12-20 CCCP build, ZoomPlayer 4.51 standard, Haali Media Splitter 2005-11-25.2, VSFilter 2.37.

VLC - first 90 seconds of ZX Starship Operators 09 - five tests
1. 51 seconds
2. 49 seconds
3. 51 seconds
4. 50 seconds
5. 51 seconds
Average CPU time: 50.4 seconds
Software: VLC 0.8.4a.

The test was conducted with a fresh, reset-all-settings install of CCCP. Some stupid ZoomPlayer defaults were changed (hide the control bar, autosize interface to fit video size, space bar == pause video), but otherwise all defaults. Task Manager was kept running in the background. The player was started with the video and left alone for the duration of the test. When the end point was reached, the player was paused and the CPU time for its process noted. The player was then closed and the process began anew. The H.264 test file had softsubs, but they were not visible during OP, since it was hardsubbed. Hence, VSFilter was loaded but not doing anything.

Speculations: It's weird that VLC is that much faster on XviD. After all, the decoders are the same... In the H264 case, I'm putting the difference off as a result of Zoom's slower loading time (since the player start time is included in the test) and fancier GUI, plus the extra effort to create the DirectShow graph.

Incidentally, some casual testing with ZoomPlayer indicates that it actually uses slightly less CPU time than MPC for the Xvid test. For the H.264 test, there's no noticeable difference between Zoom and MPC.

I also tested MPlayer a bit, and found that it's about as fast as VLC, but with HALF the RAM usage, and this is despite not using any SSE/SSE2 optimizations (my CPU has them, but MPlayer doesn't want to detect them, it seems).

Concerning the weird VLC stats of some people: I think the measurement has gotten lost somewhere in some thread. I have no idea why it behaves like it does, but I'm not believing those results until I can reproduce them myself (which I can't).

BTW, @subcool: yes, you can set that value negative with the GUI. Try it for yourself. Just press the down arrow button and watch it happily go from 0 to -1...
__________________
| ffmpegsource
17:43:13 <~deculture> Also, TheFluff, you are so fucking slowpoke.jpg that people think we dropped the DVD's.
17:43:16 <~deculture> nice job, fag!

01:04:41 < Plorkyeran> it was annoying to typeset so it should be annoying to read

Last edited by TheFluff; 2005-12-26 at 17:18.
TheFluff is offline   Reply With Quote
Old 2005-12-26, 18:23   Link #79
Durante
Junior Member
 
 
Join Date: Dec 2005
Age: 30
I still couldn't believe that difference so I got VLC to run and tested on a 2 minute sample. (Note: CPU time includes startup cost)

VLC:
8-26%
15% avg.
17s

MPC (w/ CCCP):
18-36%
27% avg.
37s

I also searched for any ways in which VLC may "hide" its CPU usage, but didn't find any secondary threads etc. So I believe it is fair to say that VLC is actually nearly twice as fast as the alternative.

However, there are a few facts that need to be mentioned to qualify that statement:
  • VLC did not show the softsubs correctly
  • Even in the short sample I tested it bugged out in one instance (totally)
  • Most importantly, why would I care if playing a clip uses 15% or 27% CPU? And my system isn't even fast by todays standards (2200 Barton)

My conclusion (note that I have no particular stake in this "war"): If you have a very slow system, only watch hardsubs and get lucky with the encodes VLC is a good choice.
(That is, if you can stand the interface which is quite horrible IMHO)
Durante is offline   Reply With Quote
Old 2005-12-26, 18:31   Link #80
wingdarkness
Retweet Member
 
 
Join Date: Dec 2005
Location: ニュー・オーリンズ、LA
I truley don't understand the whole H.264 craze that's going on right now...Perhaps it makes encoder's jobs easier, but as a veiwer I much rather xvid/divx decodable projects...Let me be the one to choose if I want to use ffdshow all the time(which I don't hate, but I'm not a huge fan of ffdshow)...Higher quality 230+mbs DVD rips look pretty good with it, but 200 and under fansubs look superior in divx format IMO...I just don't see the HUGE advantage...Lower sized fansubs should stick with divx I think...and don't get me started on CCCP that would be kissing ffdshow's ring if it was the "God-father"...
__________________
Fly since ...
wingdarkness is offline   Reply With Quote
Reply

Thread Tools

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 -5. The time now is 23:41.


Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2014, vBulletin Solutions, Inc.
We use Silk.