2005-12-27, 00:29 | Link #101 |
Panda Herder
Join Date: Dec 2005
Location: A bombed out building in Beruit.
|
that filter makes me think the guy who coded it or concieved it and thought it would be a good idea was on some pretty nice drugs.
As for filtering ffdshow and/or avisynth still seem to work for me. |
2005-12-27, 00:31 | Link #102 |
Mass Dictionary Lookup...
Join Date: Dec 2005
Location: A Japanese Dictionary
|
Could it be that DirectShow on startup goes through EVERY (I mean every) DirectShow filter to get the priority of each filter, whilst ffdshow is decoding. This sort of rampant registry rifling is taxing on the system to say the least. Regmon log here Oh yes I will be hopping onto the ccp irc channel if someone tells me this is abnormal.
|
2005-12-27, 01:52 | Link #103 |
Excessively jovial fellow
Join Date: Dec 2005
Location: ISDB-T
Age: 37
|
That reminds me of something we encountered during our first round of BSPlayer testing, when "advanced graph building" was off - the player would sit around loading and unloading different filters for about 10 seconds before deciding what to use and start decoding.
I'm not sure if this actually is abnormal or not - I need to consult the gurus first. I'll be back.
__________________
Last edited by TheFluff; 2005-12-27 at 02:14. |
2005-12-27, 02:19 | Link #104 | |
Translator, Producer
Join Date: Nov 2003
Location: Tokyo, Japan
Age: 44
|
Quote:
__________________
|
|
2005-12-27, 03:49 | Link #106 | |
Retweet Member
Join Date: Dec 2005
Location: ニュー・オーリンズ、LA
|
Quote:
__________________
|
|
2005-12-27, 05:07 | Link #107 |
Aegisub dev
Join Date: Sep 2004
Location: Stockholm, Sweden
Age: 39
|
Well I can add that I managed to reproduce the magical "extremely low cpu usage" behaviour in VLC 0.8.4a. I'm on a dual Opteron 248 (2.2 ghz; I'm using purely 32 bit software); playback back standard definition H.264 video with a DShow player usually uses about 50-75% of one my of cpu's, leaving the other one alone. When testing with VLC, I did manage to see a little load on the CPU graphs, and it's obvious VLC has found some way to do multithreaded decoding. (The load looks quite balanced.) However, 3% CPU usage playing back H.264 video, that means you should be able to play it back on a Pentium 133 without MMX, which sounds absurd, right?
Another thing I managed to produce in VLC was strange GUI artifacts. Spoiler for Extremely low CPU usage:
Spoiler for Strange GUI artifacts:
__________________
Last edited by jfs; 2005-12-27 at 05:18. |
2005-12-27, 06:15 | Link #108 |
Senior Member
Join Date: Nov 2003
|
I definitively have to say that i also dont believe those benchmarks of vlc.
For simple reasons: there is NO way in hell a h264 video is being decoded with 5-6% cpu time on any current cpu. The simple comparison in post 69 would mean that vlcs decoder is 6 times faster... thats just not possible. i personally never experienced vlc to be much quicker... Maybe a bit less frame drops in borderline situations, but there were never any situations that a video that was unplayable with ffdshow became fluid in vlc... |
2005-12-27, 06:22 | Link #109 |
Mass Dictionary Lookup...
Join Date: Dec 2005
Location: A Japanese Dictionary
|
I ran it again with the same file and a RegMon log (here) and regmon tells me that VLC only checks the audio devices and that's it.
My system specs are: Athlon 2400+ Geforce 4 MX 128Mb AGP4x Asus A7A266-E motherboard Creative Audigy LS sound card BTW: If it's a bug in Dshow you guys might have trouble locating it because there are multiple versions of DirectX floating around under the banner of 9.0c That's right people Microsoft released mutiple DirectX versions under the same name. Through the source says its only D3DX DLL set there could be a slight chance that they did a few bugfixes or interface changes. Source:here |
2005-12-27, 07:25 | Link #110 |
Excessively jovial fellow
Join Date: Dec 2005
Location: ISDB-T
Age: 37
|
Of course VLC doesn't go around checking the DirectShow filters, since it never uses them whatsoever. It has its own builtin decoders.
As for DirectX, tha is indeed a pain. However, we (CCCP playback help people) haven't seen any problems caused by any specific secret version of DirectX 9.0c - yet, at least. wingdarkness: Er, well... sorry? ;P Well, sorry for the excessive evilness in that post. People DO have differening opinions about what looks good and what looks bad - it's just that yours differs from most other people's. Nevertheless, one shouldn't look down on minorities... Again, apologies.
__________________
|
2005-12-27, 08:00 | Link #111 |
Banned
Join Date: Jan 2004
|
First of all, you guys are forgetting that we had a user in this thread claiming his MPlayer beats it all on his 733 MHz. Newest VLC crashed on him while seeking, MPC had a two second audio lag or something and crashed. I've ran into a few users on IRC too that were able to play things with VLC while couldn't with other playback solutions. Heck, I even tried it on the school computers (they're really slow) and got the same results. MPlayer not crashing like VLC is probably the result of its lower memory usage (lack of GUI) and possibly some other stuff I don't know about. This tells us that both VLC and MPlayer have capabilities of playing x264 encodes faster.
Yesterday however, we at F-B wanted to find out if maybe graphics card capabilities were using power to decode video, so we turned off hardware video acceleration. The results showed (from 5 PCs) that all players, MPC (with ffdshow, haali etc.) and VLC and MPlayer were dropping frames all over the place, as expected, and the CPU usage wasn't really different from previous results. So, while this may not be an issue at all, we can exclude the possibility that the graphics card has something to do with VLC decoding. I don't know about their drivers or directx though. We did get one weird result on one of the PCs and that was MPC playback without dropping frames for 20 seconds, then it crashed. |
2005-12-27, 08:27 | Link #112 |
Excessively jovial fellow
Join Date: Dec 2005
Location: ISDB-T
Age: 37
|
I'm not claiming that VLC isn't faster - I'm saying that it's not SIGNIFICANTLY so, at least not for H.264. If the computer is borderline, switching players might help, but the there isn't much gain to be had. I can't explain the values I got for XviD decoding on my own computer, though... As for MPlayer, I've long preferred it to VLC for several reasons, the speed being one.
Still, there IS something wrong with VLC and process accounting. My results for XviD are at least plausible, but some of the other things I've seen in this threads are just physically impossible.
__________________
|
2005-12-27, 16:11 | Link #113 |
Aegisub dev
Join Date: Sep 2004
Location: Stockholm, Sweden
Age: 39
|
I have made a post on the official VLC forum about the unrealistically low CPU usage.
http://forum.videolan.org/viewtopic.php?p=47114#47114
__________________
|
2005-12-28, 01:45 | Link #115 |
Panda Herder
Join Date: Dec 2005
Location: A bombed out building in Beruit.
|
It seems like DB has decided that all future releases will be 75 mb h.264 files. Personally I'd prefer 87mb since it would allow higher quality audio/video and 52 episodes per dvd.
I downloaded the episode and it was watchable. Video quality was as expected as I had played around with an older bleach raw near those bitrates not too long ago. Blocking isn't too bad though a fair amount of detail seems to have been lost; I don't have the raw to look at (maybe it was filtered out?). It looks as good as (better then?) some 175mb xvid releases I've seen, at least in some parts. Though that my just be my sleepyness getting to me. However, the 64kbps audio doesn't sound all that great. |
2005-12-28, 01:54 | Link #116 | |
Translator, Producer
Join Date: Nov 2003
Location: Tokyo, Japan
Age: 44
|
Quote:
They focus on high demand, gimme gimme gimme type shows, with emphasis on speed. (I won't call them a speed subbing group per se, that has too many bad connotations, but their purpose is clear). Just think of the amount of bandwith this saves them... 50,000 downloads*80 MB of savings per file = 4 TB per release less bandwith. Though I do agree about the 64 Kbp/s audio.... I really start getting annoyed at anything less than 96 Kb/s he-AAC (and I prefer 112 or above). But at that filesize, it's appropriate.
__________________
|
|
2005-12-28, 03:17 | Link #117 |
Animesuki's Janitor
|
It's times like these I wish I knew more on this topic...
So that means that we might see a trend on fansubbing groups shifting towards the h264 encoding. Though some groups offer both Xvid and h264, such as, lately, DB as well as Arenei... ________ Hotbox vaporizer Last edited by Itachikun; 2011-02-15 at 07:50. |
2005-12-28, 03:33 | Link #118 | |
Translator, Producer
Join Date: Nov 2003
Location: Tokyo, Japan
Age: 44
|
Quote:
__________________
|
|
2005-12-28, 03:58 | Link #119 | |
Senior Member
Join Date: Dec 2004
Location: Portugal
Age: 44
|
Quote:
Anyway, back again... the mkv with h264 I tested was Starship Operators from **********. With CCCP it simply need too much cpu that I can only watch it with maximazed screen. Full screen chokes almost all the time. You can feel the heaviness just when you do alt+enter to go to full screen. It takes a lot of seconds to go there. And it's not watchable coz the sound is desyncronized. I then downloaded k-lite mega codec pack and installed it with the same configs in the ffdshow as in the CCCP. It doesn't choke anymore... plays just fine. Still eats more cpu than xvid but playable in the athlon xp 2200 + 768 RAM + GF4 MX. Just in case it was something in the OS I used by other XP installed... a clean one where I use it only to watch anime and do encodes. Almost not much installed and it had the same results. Hmmm... should have used that example above? I got other examples I used... but they are hentai... hehehe... Oh BTW, it's not that I hate the codec(in the previous post)... I just hate softsubs and so MKV and other containers.
__________________
Last edited by NoSanninWa; 2005-12-28 at 05:28. |
|
2005-12-28, 04:42 | Link #120 | |
Banned
Join Date: Jan 2004
|
Quote:
|
|
Thread Tools | |
|
|