AnimeSuki Forums

ArchMageZeratuL · 2005-12-31, 20:39

Quote:

Originally Posted by subcool

Just bout every H.264 hardware player wich supports high profile video will be able to play our encodes :P (and is Mpeg-4 compliant)

Many of them may support MKV too, you don't know. Also, you can't say for sure that they will support data discs, besides HD-DVD and Blu-Ray (Are blu-ray drives even compatible with CDs/DVDs? I've read otherwise long ago, but that might have changed by now). At this point, it's all just speculation.

Quote:

Originally Posted by subcool

Also, owners of ATI Radeon X1000+ series will be able to decode it fine (but thats not container specific i think... not sure)

It's not container specific.
And ATI has history of broken hardware video acceleration (see WMV9 and its LSD trip artifacts), but hopefully they'll get it right this time.

Mentar · 2005-12-31, 21:02

Quote:

Originally Posted by subcool

Just bout every H.264 hardware player wich supports high profile video will be able to play our encodes :P (and is Mpeg-4 compliant)

In other words, no such thing right now. You're rather just celebrating announcements of the industry. Yay. I hope the standalones will be more reliable than those who promise avi playback nowadays (where 50% of the encodes fail).

Will the standalones more likely be able to play mp4 hardsubs rather than mkv vfr softsubs? Yes. More likely enough to seriously limit your choice of container like this? I dunno. Those standalones which will eventually be able to play everything reliable will most likely support open-sourced matroska aswell.

Quote:

Also, owners of ATI Radeon X1000+ series will be able to decode it fine (but thats not container specific i think... not sure)

Again you're celebrating announcementware. If it does apply, it will be for both MP4 and mkv simultaneously. But so far, hardware acceleration was always a "find and disable" issue if you wanted reliable playback. So I remain sceptical here too.

deathbygirl · 2005-12-31, 21:02

I've got to raise a flag on this "evil" extension argument, 'cause I'm pretty convinced that is moot (like DryFire and Mentar before me). So what if these so-called "evil" individuals use .mkv and it's known as such? I'm pretty sure that not many people argue that same point with .mp3's, but I do know that there are a lot of more malicious acts done with that format than with .mkv from what I've seen. Yet .mp3 still stands as one of the most popular formats around, and not many people have qualms about it representing an underlying "evil".

In terms of familarity, I think recent actions by fansubbing groups have made .mkv more familiar than .mp4 for the time being. Such groups are helping others become more familiar with the .mkv extension (and more importantly, how to play them properly) and are making a stronger argument (and exposing the community to it) than those who have decided upon the latter. Perhaps groups who support .mp4 might make a strong case in the near future, but I think .mkv has already gotten a significant push and will make it difficult for .mp4 to gain further recognition.

As for priorities, I don't think there's less emphasis on any aspect of the entire process for fansubbing groups. Each element is crucial for a quality release. I don't think any group aims to release a bad quality encode of an episode; rather, they aim to achieve the best quality in all aspects. When I have a release in mind, I don't aim to compromise any aspect with the mindset of "Oh, the other aspects will redeem it" in mind. Like Mentar says, compromising one aspect (even if it's considered the "least" important) for another doesn't suggest that the said aspect makes up for it. And I also disagree on the "very few skills" needed to encode (you may have an argument for typesetting, since all it really comes down to is manipulating a list of pre-defined commands into displaying what you want; then again, programming in general can be simplified in the same way, save creating another entire language) because I've learned a couple tidbits about the encoding process, and it's not such an easy road. The choices and implimentations of filters alone are enough to intimidate someone out of the work, and I don't think many people are able to work with the tools available to them and create successful encodes without experience and dedication.

movax · 2005-12-31, 22:09

Just want to mention that using something other than AVI does not kill download amounts. My AVC encode of FF7:AC and LO for Shinsen still got more than 10k torrent downloads, and we had even more for the AVI version. There's no technical reason not to use MKV, other than these laughable ethics. Decoding AVI requires: AVI splitter, Video Decoder, Audio Decoder. MKV requires: MKV splitter, video decoder, audio decoder. Haali's MKV splitter handles AVI superbly compared to stock MS AVI splitter. Conclusion? "Playback of MKV is difficult" arguement is null and dead.

Sylf · 2006-01-01, 00:07

Quote:

Originally Posted by movax

"Playback of MKV is difficult" arguement is null and dead.

Thanks for repeating my point.

movax · 2006-01-01, 00:35

/me salutes
Now just get more people to agree. =/

DryFire · 2006-01-01, 02:31

Quote:

Originally Posted by Sylf

Thanks for repeating my point.

Alot of this has been repeated, many times, but it seems some people need the repitition.

As far as getting people to agree... they could be forced.

Sylf · 2006-01-01, 03:13

Hai, sou desune!
/me whips out a chalkboard
+----------------------------------------------------------------------------+
MKV is simple MKV is simple MKV is simple MKV is simple
MKV is simple MKV is simple MKV is simple MKV is simple
MKV is simple MKV is simple MKV is simple MKV is simple
MKV is simple MKV is simple MKV is simple MKV is simple....

sorry. (mods, delete at will)

xris · 2006-01-01, 12:42

Please keep the discussion on-topic, otherwise posts will continue to be deleted.

Please read our forum rules, if anyone else posts a retort image, they are going to be banned.

Jekyll · 2006-01-01, 19:52

I did some H.264 playback performance testing with various players. Here are my results:

General

Candidates
I used the following playback solutions for this test (alphabetical order):

Spoiler for Unreliable results because of windows process accounting:

Notes

As TCPMP does not seem to support soft subs, no soft subs were enabled in any tests
TCPMP does not seem to support anamorphic
MPlayer soft sub support might be uncomfortable to configure for some people (inserting sid=0 or slang=en etc. in the config)
In each test, the players should have played about the same amount of video data, although it might be off for 1 or 2 seconds (human reaction time)
Windows process accounting seems to inaccurate, please take these results with a few spoons full of salt

System
The tests were conducted on a Pentium M 1.6GHz with 512MiB RAM and WinXP.

H.264/AVC

Sample
The sample for this test was 672x576 (AR corrected to 716x576) high profile with 3 b-frames, b-pyramid, weighted prediction, 8 reference frames and cabac at 25fps in Matroska. Subtitles were disabled. Audio was AC3. Total bitrate was 1142kbps.

CCCP with MPC (2005-12-21)
While playing, I observed a maximum CPU load of 55%, and estimated a mean load of 33%. Data calculated from the graph:

Minimum: 21
Maximum: 54
Median:  35
Mean:    34

MPlayer-CVS-20051119 by KK
While playing, I observed a maximum CPU load of 27%, and estimated a mean load of about 4%. This seems a bit fishy as on Linux MPlayer decodes H.264 slower than TCPMP via Wine (video output disabled for both). Data calculated from the graph:

Minimum:  0
Maximum: 28
Median:   3
Mean:     4

TCPMP for Win32 0.71g with AVC plugin 0.71e
While playing, I observed a maximum CPU load of 43% (peak at the beginning, while starting the task manager), and estimated a mean load of 15%, which might be a bit off. As TCPMP does not seem to be able to get AR information from the Matroska file, I set it to use 4:3 AR correction, which is the best I could get. Data calculated from the graph:

Minimum:  2
Maximum: 26
Median:  11
Mean:    13

VLC 0.8.4a for Win32
While playing, I observed a maximum CPU load of 25%, and estimated a mean load of 22%, which might be a bit off. Data calculated from the graph:

Minimum:  7
Maximum: 34
Median:  20
Mean:    20

ASP
For the sake of completeness, I decided to include a comparison of ASP decoding performance

Sample
The sample for this test was 720x486 at 30fps with a total bitrate of about 1192kbps.

CCCP with MPC (2005-12-21)
While playing, I observed a maximum CPU load of 15%, and estimated a mean load of 7%. Data calculated from the graph:

Minimum:  0
Maximum: 15
Median:  14
Mean:     6

MPlayer-CVS-20051119 by KK
While playing, I observed a maximum CPU load of 7%, and estimated a mean load of 0%. Data calculated from the graph:

Minimum: 0
Maximum: 7
Median:  0
Mean:    1

TCPMP for Win32 0.71g with AVC plugin 0.71e
While playing, I observed a maximum CPU load of 7%, and estimated a mean load of 0%. Data calculated from the graph:

Minimum: 0
Maximum: 8
Median:  0
Mean:    1

VLC 0.8.4a for Win32
While playing, I observed a maximum CPU load of 8%, and estimated a mean load of 0%. Data calculated from the graph:

Minimum: 0
Maximum: 8
Median:  0
Mean:    1

For more accurate results, follow the link in jfs' post to this comparison.

IMSabbel · 2006-01-01, 20:15

arg
Come on, please stop that nonsense.
Do you SERIOUSLY believe a pentium M can decode ASP with ZERO PERCENT mean cpu load?
Or that mplayer has 12(!) times lesser mean load for h264 than ffdshow for h264, even though it uses the same source... (plus the fact that 3-4% mean load on a 1.6Ghz P-M would mean fluid h264 playback on a pentium 60...)
Hint: theres an occams razor here, and its big as a barn...

movax · 2006-01-01, 20:26

Jekyll, to put it nicely: your graphs are nothing but eye candy. Task Manager is NOT an accurate measure of CPU usage!

jfs · 2006-01-01, 20:29

I think the conclusion from those tests will be "Windows NT process accounting can not be trusted."
Am I right?

Jekyll · 2006-01-01, 20:31

Quote:

Originally Posted by IMSabbel

Come on, please stop that nonsense.

Do you by any chance know of a better measurement method? I'd really like to hear it, as my goal is not to convince anybody that one solution is faster than another, but to do a correct benchmark.

Quote:

Do you SERIOUSLY believe a pentium M can decode ASP with ZERO PERCENT mean cpu load?

Zero seems a bit low, but please note that whatever zeroed the measurement values did effect three of the tested players.

Quote:

Or that mplayer has 12(!) times lesser mean load for h264 than ffdshow for h264, even though it uses the same source...

Please note that I did note that most certainly something is fishy there.

Eeknay · 2006-01-01, 20:35

The way to test this is with low end hardware, not task manager. Get someone with a 800Mhz (or around that) CPU, and get them to do a test with all the avaliable options with a h264 fansub (or multiple fansubs, not like there's a shortage).

Jekyll · 2006-01-01, 20:42

Quote:

Originally Posted by Eeknay

The way to test this is with low end hardware, not task manager. Get someone with a 800Mhz (or around that) CPU, and get them to do a test with all the avaliable options with a h264 fansub (or multiple fansubs, not like there's a shortage).

This seems reasonable. I will try it later.

jfs · 2006-01-01, 20:45

Ideally, find some way to get each player to render the video to a null output, so it'll decode as fast as possible, just throwing the results away. The resulting frames decoded per second will then be a measure for speed.
bond on doom9 already did that though, so it might be a bit moot.

LytHka · 2006-01-01, 20:46

Quote:

Originally Posted by Eeknay

The way to test this is with low end hardware, not task manager. Get someone with a 800Mhz (or around that) CPU, and get them to do a test with all the avaliable options with a h264 fansub (or multiple fansubs, not like there's a shortage).

http://forums.animesuki.com/showpost...4&postcount=83

Draneor · 2006-01-01, 22:41

Quote:

Originally Posted by Eeknay

The way to test this is with low end hardware, not task manager. Get someone with a 800Mhz (or around that) CPU, and get them to do a test with all the avaliable options with a h264 fansub (or multiple fansubs, not like there's a shortage).

I have a 733. I already ran a few tests, which Lyth just linked to. As far as I know, the only players that will play h264 on my system are the latest VLC and the latest mplayer. If you'd like, I can test it on a slower system.

Eeknay · 2006-01-02, 07:51

Can you do that test again with the same software as Jekyll? i.e. latest CCCP, latest VLC, latest build of mplayer? Same hardware would be great.

2006-01-01, 12:42	Link #169
xris Just call me Ojisan Join Date: Jan 2003 Location: U.K. Hampshire	Please keep the discussion on-topic, otherwise posts will continue to be deleted. Please read our forum rules, if anyone else posts a retort image, they are going to be banned. Last edited by xris; 2006-01-01 at 13:14.

2006-01-01, 19:52	Link #170
Jekyll Rozen Detective Join Date: Dec 2005 Location: Germany Age: 40	I did some H.264 playback performance testing with various players. Here are my results: General Candidates I used the following playback solutions for this test (alphabetical order): CCCP with MPC (2005-12-21) MPlayer CVS build from 2005-11-19 by KK TCPMP for Win32 0.71g with AVC plugin 0.71e (more) VLC 0.8.4a for Win32 Spoiler for Unreliable results because of windows process accounting: Notes As TCPMP does not seem to support soft subs, no soft subs were enabled in any tests TCPMP does not seem to support anamorphic MPlayer soft sub support might be uncomfortable to configure for some people (inserting sid=0 or slang=en etc. in the config) In each test, the players should have played about the same amount of video data, although it might be off for 1 or 2 seconds (human reaction time) Windows process accounting seems to inaccurate, please take these results with a few spoons full of salt System The tests were conducted on a Pentium M 1.6GHz with 512MiB RAM and WinXP. H.264/AVC Sample The sample for this test was 672x576 (AR corrected to 716x576) high profile with 3 b-frames, b-pyramid, weighted prediction, 8 reference frames and cabac at 25fps in Matroska. Subtitles were disabled. Audio was AC3. Total bitrate was 1142kbps. CCCP with MPC (2005-12-21) While playing, I observed a maximum CPU load of 55%, and estimated a mean load of 33%. Data calculated from the graph: Minimum: 21 Maximum: 54 Median: 35 Mean: 34 MPlayer-CVS-20051119 by KK While playing, I observed a maximum CPU load of 27%, and estimated a mean load of about 4%. This seems a bit fishy as on Linux MPlayer decodes H.264 slower than TCPMP via Wine (video output disabled for both). Data calculated from the graph: Minimum: 0 Maximum: 28 Median: 3 Mean: 4 TCPMP for Win32 0.71g with AVC plugin 0.71e While playing, I observed a maximum CPU load of 43% (peak at the beginning, while starting the task manager), and estimated a mean load of 15%, which might be a bit off. As TCPMP does not seem to be able to get AR information from the Matroska file, I set it to use 4:3 AR correction, which is the best I could get. Data calculated from the graph: Minimum: 2 Maximum: 26 Median: 11 Mean: 13 VLC 0.8.4a for Win32 While playing, I observed a maximum CPU load of 25%, and estimated a mean load of 22%, which might be a bit off. Data calculated from the graph: Minimum: 7 Maximum: 34 Median: 20 Mean: 20 ASP For the sake of completeness, I decided to include a comparison of ASP decoding performance Sample The sample for this test was 720x486 at 30fps with a total bitrate of about 1192kbps. CCCP with MPC (2005-12-21) While playing, I observed a maximum CPU load of 15%, and estimated a mean load of 7%. Data calculated from the graph: Minimum: 0 Maximum: 15 Median: 14 Mean: 6 MPlayer-CVS-20051119 by KK While playing, I observed a maximum CPU load of 7%, and estimated a mean load of 0%. Data calculated from the graph: Minimum: 0 Maximum: 7 Median: 0 Mean: 1 TCPMP for Win32 0.71g with AVC plugin 0.71e While playing, I observed a maximum CPU load of 7%, and estimated a mean load of 0%. Data calculated from the graph: Minimum: 0 Maximum: 8 Median: 0 Mean: 1 VLC 0.8.4a for Win32 While playing, I observed a maximum CPU load of 8%, and estimated a mean load of 0%. Data calculated from the graph: Minimum: 0 Maximum: 8 Median: 0 Mean: 1 For more accurate results, follow the link in jfs' post to this comparison. Last edited by Jekyll; 2006-01-02 at 10:21.

2006-01-01, 20:29	Link #173
jfs Aegisub dev Join Date: Sep 2004 Location: Stockholm, Sweden Age: 39	I think the conclusion from those tests will be "Windows NT process accounting can not be trusted." Am I right? __________________ Aegisub developer [ Forum \| Manual \| Feature requests \| Bug reports \| IRC ] Don't ask for: More VSFilter changes (I won't), karaoke effects, help in PM's

2006-01-01, 20:45	Link #177
jfs Aegisub dev Join Date: Sep 2004 Location: Stockholm, Sweden Age: 39	Ideally, find some way to get each player to render the video to a null output, so it'll decode as fast as possible, just throwing the results away. The resulting frames decoded per second will then be a measure for speed. bond on doom9 already did that though, so it might be a bit moot. __________________ Aegisub developer [ Forum \| Manual \| Feature requests \| Bug reports \| IRC ] Don't ask for: More VSFilter changes (I won't), karaoke effects, help in PM's

2005-12-31, 21:02	Link #163
deathbygirl Senior Member Join Date: Dec 2005	I've got to raise a flag on this "evil" extension argument, 'cause I'm pretty convinced that is moot (like DryFire and Mentar before me). So what if these so-called "evil" individuals use .mkv and it's known as such? I'm pretty sure that not many people argue that same point with .mp3's, but I do know that there are a lot of more malicious acts done with that format than with .mkv from what I've seen. Yet .mp3 still stands as one of the most popular formats around, and not many people have qualms about it representing an underlying "evil". In terms of familarity, I think recent actions by fansubbing groups have made .mkv more familiar than .mp4 for the time being. Such groups are helping others become more familiar with the .mkv extension (and more importantly, how to play them properly) and are making a stronger argument (and exposing the community to it) than those who have decided upon the latter. Perhaps groups who support .mp4 might make a strong case in the near future, but I think .mkv has already gotten a significant push and will make it difficult for .mp4 to gain further recognition. As for priorities, I don't think there's less emphasis on any aspect of the entire process for fansubbing groups. Each element is crucial for a quality release. I don't think any group aims to release a bad quality encode of an episode; rather, they aim to achieve the best quality in all aspects. When I have a release in mind, I don't aim to compromise any aspect with the mindset of "Oh, the other aspects will redeem it" in mind. Like Mentar says, compromising one aspect (even if it's considered the "least" important) for another doesn't suggest that the said aspect makes up for it. And I also disagree on the "very few skills" needed to encode (you may have an argument for typesetting, since all it really comes down to is manipulating a list of pre-defined commands into displaying what you want; then again, programming in general can be simplified in the same way, save creating another entire language) because I've learned a couple tidbits about the encoding process, and it's not such an easy road. The choices and implimentations of filters alone are enough to intimidate someone out of the work, and I don't think many people are able to work with the tools available to them and create successful encodes without experience and dedication.

2005-12-31, 22:09	Link #164
movax Hosar Sub-God Join Date: Dec 2005 Location: Michigan, USA	Just want to mention that using something other than AVI does not kill download amounts. My AVC encode of FF7:AC and LO for Shinsen still got more than 10k torrent downloads, and we had even more for the AVI version. There's no technical reason not to use MKV, other than these laughable ethics. Decoding AVI requires: AVI splitter, Video Decoder, Audio Decoder. MKV requires: MKV splitter, video decoder, audio decoder. Haali's MKV splitter handles AVI superbly compared to stock MS AVI splitter. Conclusion? "Playback of MKV is difficult" arguement is null and dead.

2006-01-01, 00:35	Link #166
movax Hosar Sub-God Join Date: Dec 2005 Location: Michigan, USA	/me salutes Now just get more people to agree. =/

2006-01-01, 03:13	Link #168
Sylf 翻訳家わなびぃ Fansubber Join Date: Nov 2003 Age: 50	Hai, sou desune! /me whips out a chalkboard +----------------------------------------------------------------------------+ MKV is simple MKV is simple MKV is simple MKV is simple MKV is simple MKV is simple MKV is simple MKV is simple MKV is simple MKV is simple MKV is simple MKV is simple MKV is simple MKV is simple MKV is simple MKV is simple.... sorry. (mods, delete at will)

2006-01-01, 20:15	Link #171
IMSabbel Senior Member Join Date: Nov 2003	arg Come on, please stop that nonsense. Do you SERIOUSLY believe a pentium M can decode ASP with ZERO PERCENT mean cpu load? Or that mplayer has 12(!) times lesser mean load for h264 than ffdshow for h264, even though it uses the same source... (plus the fact that 3-4% mean load on a 1.6Ghz P-M would mean fluid h264 playback on a pentium 60...) Hint: theres an occams razor here, and its big as a barn...

2006-01-01, 20:26	Link #172
movax Hosar Sub-God Join Date: Dec 2005 Location: Michigan, USA	Jekyll, to put it nicely: your graphs are nothing but eye candy. Task Manager is NOT an accurate measure of CPU usage!

2006-01-01, 20:35	Link #175
Eeknay Gendo died for your sins. Fansubber Join Date: Dec 2005	The way to test this is with low end hardware, not task manager. Get someone with a 800Mhz (or around that) CPU, and get them to do a test with all the avaliable options with a h264 fansub (or multiple fansubs, not like there's a shortage).

2006-01-02, 07:51	Link #180
Eeknay Gendo died for your sins. Fansubber Join Date: Dec 2005	Can you do that test again with the same software as Jekyll? i.e. latest CCCP, latest VLC, latest build of mplayer? Same hardware would be great.