MPEG-4 AVC/H.264 decoder comparison

[bond]

one of the main advantages of open standards, like mpeg-4 avc, is that it leads to competition between various codec producers as the consumer will always tend to use the product with the best price/performance relationship.

while prices are pretty well known for the consumer there is one thing often lying in the dark: the actual performance

while for the encoding side quality comparisons exist, like the one from doom9, decoders are often overlooked. of course, as every decoder should output exactly the same picture and speed also didnt really play a role as existing formats are pretty easy to decode.
but with a format, like avc, which needs a lot of resources while decoding, this might be different for a lot of people who dont own top of the notch pcs.

so as avc is very speed consuming and actually only one free avc decoder is existing (libavcodec) it indeed makes sense to compare the performance of existing decoders, before the user decides what to spend his money on

in this comparison i will compare the following decoders:
- ateme
- elecard
- libavcodec
- mainconcept
- moonlight
- nero
- videosoft

imho the quality of a decoder is defined by four things:
A) price
B) supported features of the format
C) decoding speed
D) postprocessing


A) PRICE

its pretty easy to check out the prices of the available decoders:
- libavcodec (http://www1.mplayerhq.hu/cgi-bin/cvsweb.cgi/ffmpeg/libavcodec/h264.c?cvsroot=FFMpeg): 0 USD as being opensource, but you have to compile it yourself, supported in various players
- videosoft (http://secure.softwarekey.com/solo/products/trigdetail.asp?T=2345): 19.95 USD, available in their "VSS H.264/AVC Codec Baseline" tool
- moonlight (http://www.elecard.net.ru/products/): 20 USD, available in the "Moonlight-Elecard MPEG Player 3.0"
- nero (http://www.nero.com/enu/Nero_Digital_Pro_InfoPage.html): 29.90 USD, available in their "Nero Digital Pro" tool
- elecard (http://www.mainconcept.com/h264_encoder.shtml): 499 USD, available in the mainconcept "H.264 Encoder v2" tool
- mainconcept (http://www.mainconcept.com/h264_encoder.shtml): 499 USD, not available anymore, has been available in their "H.264 Encoder v1" tool (v2 uses the elecard decoder)
- ateme: not publically available


B) SUPPORTED FEATURES

according to my tests the following features are NOT supported by the different decoders (version number described below):

| ateme | elecard | libavcodec | mainconcept | moonlight | nero | videosoft |
------------------------------------------------------------------------------------------------------
BASELINE PROFILE| | | | | | | |
------------------------------------------------------------------------------------------------------
p4x4,b8x8,i4x4 | | | | | | | |
------------------------------------------------------------------------------------------------------
loop | | | | | | | |
------------------------------------------------------------------------------------------------------
multireferences | | | | | | | |
------------------------------------------------------------------------------------------------------
adaptive quant | | | | | | | |
------------------------------------------------------------------------------------------------------

------------------------------------------------------------------------------------------------------
MAIN PROFILE | | | | | | | |
------------------------------------------------------------------------------------------------------
b-frames | | | | | | | |
------------------------------------------------------------------------------------------------------
b-references | | | | | | | x |
------------------------------------------------------------------------------------------------------
wp,wbp | | | | | | | |
------------------------------------------------------------------------------------------------------
cabac | | | | | | | |
------------------------------------------------------------------------------------------------------
fields-only | | | | * | | | |
------------------------------------------------------------------------------------------------------
paff | | | | * | * | | x |
------------------------------------------------------------------------------------------------------
mbaff | | | | * | x | | x |
------------------------------------------------------------------------------------------------------

------------------------------------------------------------------------------------------------------
HIGH PROFILE | | | | x | | | x |
------------------------------------------------------------------------------------------------------
8x8dct | | | | x | | | x |
------------------------------------------------------------------------------------------------------
i8x8 | | | | x | | | x |
------------------------------------------------------------------------------------------------------
cqm | | | | x | | | x |
------------------------------------------------------------------------------------------------------
lossless | | x | | x | x | x | x |
------------------------------------------------------------------------------------------------------so the only decoder which supported everything was the not publically available decoder from ateme
second place goes to libavcodec (not supporting interlacing), elecard and nero (not supporting lossless avc)
the not anymore developed decoders from mainconcept and moonlight had problems with their interlacing support. moonlight shows artefacts with paff. mainconcept shows artefacts with all interlacing modes.
videosoft didnt support b-references/arbitrary frame orders

it also gets interesting when looking at the high profile support, whose tested features were supported more or less by libavcodec, moonlight, elecard and nero but fully only by ateme


C) DECODING SPEED

as all decoders are available as directshow decoders i used this interface for testing the decoders
additionally i also tested libavcodec in mplayer to honor its advantage of being useable also in potentially better and faster interfaces than directshow

my cpu is a pentium3 866mhz

the speed has been measured with elecard's great Chegepuga filter, available here (http://forum.doom9.org/showthread.php?p=703999#post703999). yv12 output has been enforced, which all decoders supported

the graph has been setup as
file parser -> decoder -> chegepuga

as some decoders are limited to or work best with specific file formats, eg mainconcept only works with .mpg, i decided to use the file parsers of the decoder manufacturers too. this also helped avoiding interoperability problems. of course faster parsers can influence the output speed positively, which has to be taken into account when looking at the values described below

the following filter/parser combinations have been used:
ateme: ateme mp4 parser 1.2.5.3 / ateme decoder 2.2.1.0
ateme_old: ateme mp4 parser 1.2.2.0 / ateme decoder 1.1.2.0
elecard: elecard mp4 parser 1.4.0 b50929 / mainconcept decoder 1.01.00.07
libav-ffdshow: haali mp4 parser Sep 03 2005 / ffdshow-libavcodec decoder Oct 13 2005
libav-ffdshow_old: haali mp4 parser Aug 18 2005 / ffdshow-libavcodec decoder Aug 22 2005
libav-mplayer: mplayer mp4 parser cvs aug 12 2005 / mplayer-libavcodec decoder cvs aug 12 2005
mainconcept: mainconcept mpg parser 1.00.01.02 / mainconcept decoder 1.01.00.04
moonlight: elecard mp4 parser 1.3.5 b50823 / moonlight decoder 0.9.0 b50208
nero: nero mp4 parser 2.0.2.49 / nero decoder 2.0.2.46
videosoft: m$ avi parser 6.5.1.902 / videosoft decoder 2.3.1.5
videosoft_old: m$ avi parser 6.5.1.902 / videosoft decoder 2.0.2.3the method for measuring the libavcodec performance with mplayer is described here (http://forum.doom9.org/showthread.php?t=99131)

the source was the typical matrix 1 clip often used for comparisons (smith interrogating morpheus, lobby shootout), ~7000 frames
various resolutions and codec settings have been used (the details can be seen in the raw results attached below), the target bitrate was ~700kbps, which can be seen as the typical 1 CDR DVD backup bitrate

as encoder x264 has been used, because its one of the most complete encoders and easy to configure
also its able to output directly to .mp4, which most decoders supported
.mpg has been muxed from .mp4 with ffmpeg cvs june 24 2005

the following amount of samples have been encoded:
high profile: 9
main profile: 13
baseline profile: 1

Results: (measured in frames per second)

ALL SAMPLES
average of all samples except 1 with cqm

ateme: 58.78
libav-mplayer: 58.22
moonlight: 55.48
libav-ffdshow: 52.15
libav-ffdshow_old: 52.11
nero: 50.74
elecard: 44.04
HIGH PROFILE
average of all samples except 1 with cqm

libav-mplayer: 55.11
ateme: 53.77
moonlight: 49.57
libav-ffdshow: 49.44
libav-ffdshow_old: 48.84
nero: 46.37
elecard: 40.48
ateme_old: high profile not supported
mainconcept: high profile not supported
videosoft: high profile not supportedMAIN PROFILE

ateme: 60.83
libav-mplayer: 59.00
moonlight: 57.59
libav-ffdshow_old: 53.24
libav-ffdshow: 53.08
nero: 52.58
elecard: 45.61
mainconcept: 43.40
videosoft: not all samples tested (b-ref not supported)
ateme_old: not all samples tested (b-ref not supported)BASELINE PROFILE

moonlight: 75.34
libav-mplayer: 72.88
ateme: 72.28
ateme_old: 70.63
videosoft: 64.01
libav-ffdshow_old: 63.47
libav-ffdshow: 61.83
nero: 61.80
elecard: 52.02
mainconcept: 51.16
videosoft_old: 33.46- libavcodec in mplayer and ateme are nearly always the fastest

when looking only at the directshow decoders you see that
- moonlight is faster than ffdshow and nero (but not than mplayer)
- ffdshow is as good as always faster than nero
- videosoft is performing in the middle
- elecard and mainconcept are slow


D) POST PROCESSING

imho post processing doesnt really play a role with avc, as the format itself is already good enough to provide a pretty good picture without the need for enhancing it during playback
as post processing would also require more processor power and the output quality would have to be judged subjectively i left it away in this comparison totally


CONCLUSION

the results show once again that opensource development is very powerful when it comes to providing excellent quality as libavcodec was able to provide great speeds when being used in the opensource mplayer and also supports as good as all tested avc features except interlacing

the not publically available decoder from ateme also provided excellent results outperforming the other decoders on many samples and being the only one which supported all tested coding features

moonlight was a surprise for me as it provided excellent speed results, supported nearly all avc features i tested and is also relatively cheap available. also moonlight offers the possibility to play avc in .mp4 and .mpg
moonlight is bankrupt and selling its tools, including the decoder, atm. i hope someone will buy it and continue developing it, its really worth it

nero was a disappointment imho as it was till now always seen as the benchmark, a role it clearly wasnt able to play, being slower than moonlight and also slightly slower than ffdshow, not to speak of mplayer
it also has to be mentioned that nero uses a very fast mp4 parser, whereas ffdshow and moonlight used slower ones
still nero also supports a lot of avc features

judging from the price mainconcept charges for their avc implementation (499 USD) i had high expectations for both mainconcepts original decoder (available in v1) and the new elecard decoder its uses since v2, which it surely didnt meet, as it performed pretty poorly
i know elecard's decoder is very new and i hope they will continue improving it so it can keep up speedwise with the other decoders and also with the price you have to pay for it. it already supports a lot of avc features

videosoft's decoder was a midperformer, with the downside of not supporting b-references, paff/mbaff and high profile. i know vss is working on high profile, but i wasnt able to test it. i hope the bref thing will get fixed soon so i can rank the decoder speedwise in main profile too

[bond]

i finally found the time to calculate how the different decoders perform on different coding tools, eg which decoder is the fastest on decoding cabac, etc...

the results shown below can give you an idea on how the decoders perform, of course the results are only valid on the specific two clips i compared for deriving the shown value (in fps) telling the decoding speed difference between two clips (one with the specific feature enabled and the other one with the feature disabled)
i ranked the decoders by the % by which the decoding speed decreases when an additional features is enabled

the higher the shown value, the worse the performance of the decoder for the specific feature:

------------------------------------------------------------------------
------------------------------------------------------------------------
blocksizes

p8x8 vs. p4x4

720x288 B2 Ref3 i4x4 cabac

nero: 18,4% 12,00
ateme_old: 9,7% 5,13
ateme: 9,2% 5,62
videosoft: 5,7% 3,24
libav-ffdshow: 1,7% 1,03
libav-mplayer: 1,5% 1,00
elecard: 1,5% 0,74
libav-ffdshow_old: 1,4% 0,84
moonlight: 1,1% 0,68
mainconcept: 0,8% 0,37

------------------------------------------------------------------------
i4x4 vs. i8x8

720x288 B3-Ref Ref5 p4x4 loop-5 WBP cabac

ateme: 4,8% 2,57
elecard: 3,1% 1,20
libav-ffdshow: 1,3% 0,59
libav-ffdshow_old: 0,9% 0,40
libav-mplayer: 0,0% 0,01
moonlight: -0,1% -0,06
nero: -0,7% -0,28


640x256 B3-Ref Ref5 p4x4 loop-5 WBP cabac

libav-ffdshow_old: 4,8% 2,87
elecard: 4,3% 2,12
ateme: 3,0% 1,94
libav-mplayer: 2,0% 1,26
moonlight: 1,3% 0,70
nero: 0,4% 0,21
libav-ffdshow: -5,8% -3,09

------------------------------------------------------------------------
------------------------------------------------------------------------
multiple reference frames

ref1 vs. ref5

720x288 B3-Ref p4x4-i4x4 loop-5 WBP cabac

nero: 10,8% 5,06
libav-mplayer: 10,0% 5,53
elecard: 7,1% 2,95
libav-ffdshow: 7,0% 3,42
ateme: 6,7% 3,85
libav-ffdshow_old: 6,7% 3,22
mainconcept: 5,5% 2,12
moonlight: 5,1% 2,46

------------------------------------------------------------------------
ref1 vs. ref3

720x288 B3-Ref p4x4-i4x4 loop-5 WBP cabac

libav-mplayer: 7,6% 4,59
nero: 7,3% 4,33
ateme: 5,9% 3,97
libav-ffdshow: 5,7% 3,12
elecard: 5,7% 2,69
libav-ffdshow_old: 5,3% 3,02
mainconcept: 4,4% 1,99
moonlight: 2,7% 1,86

------------------------------------------------------------------------
ref3 vs. ref5

720x288 B3-Ref p4x4-i4x4 loop-5 WBP cabac

libav-mplayer: 1,8% 0,94
nero: 1,7% 0,73
moonlight: 1,3% 0,60
elecard: 0,7% 0,26
libav-ffdshow: 0,7% 0,30
libav-ffdshow_old: 0,4% 0,20
mainconcept: 0,4% 0,13
ateme: -0,2% -0,12

------------------------------------------------------------------------
------------------------------------------------------------------------
weighted (bi)prediction

wbp vs. nowbp

720x288 B3-Ref Ref3 p4x4-i4x4 loop-5 cabac

moonlight: 20,0% 11,54
mainconcept: 10,4% 4,27
elecard: 8,4% 3,55
nero: 6,2% 2,80
libav-mplayer: 2,3% 1,22
libav-ffdshow_old: 2,1% 0,96
libav-ffdshow: 1,1% 0,49
ateme: 0,9% 0,46

------------------------------------------------------------------------

wp+wbp vs. nowp+nowbp

640x256 B2 Ref3 p8x8-i4x4 loop-5 cabac

videosoft: 35,6% 19,74
moonlight: 23,6% 16,18
nero: 13,7% 8,16
mainconcept: 12,3% 5,58
elecard: 11,3% 5,37
ateme_old: 9,1% 5,25
libav-mplayer: 4,3% 2,63
libav-ffdshow_old: 2,9% 1,61
ateme: 2,4% 1,65
libav-ffdshow: 0,4% 0,20

------------------------------------------------------------------------
------------------------------------------------------------------------
b-frames

0 B-frames vs. 3 B-frames

720x288 Ref5 p4x4-i8x8 loop-5 WBP cabac

moonlight: 27,7% 17,49
nero: 27,6% 15,52
elecard: 18,3% 8,30
ateme: 16,5% 9,95
libav-mplayer: 14,0% 8,09
libav-ffdshow: 12,5% 6,37
libav-ffdshow_old: 11,8% 5,90

------------------------------------------------------------------------
0 B-frames vs. 2 B-frames

640x256 Ref3 p8x8-i4x4 loop-5 cabac

ateme_old: 20,0% 14,35
mainconcept: 13,6% 7,17
libav-ffdshow: 12,9% 8,08
ateme: 12,7% 9,80
elecard: 12,6% 6,81
nero: 12,4% 8,40
libav-ffdshow_old: 12,3% 7,89
libav-mplayer: 11,4% 7,79
moonlight: 9,5% 7,21
videosoft: 9,0% 5,50

------------------------------------------------------------------------
0 B-frames vs. 1 B-frames

720x288 Ref5 p4x4-i8x8 loop-5 WBP cabac

moonlight: 23,1% 14,55
nero: 21,8% 12,23
elecard: 15,4% 6,97
ateme: 13,6% 8,20
libav-mplayer: 8,4% 4,81
libav-ffdshow: 8,3% 4,25
libav-ffdshow_old: 5,8% 2,92

------------------------------------------------------------------------
1 B-frames vs. 3 B-frames

720x288 Ref5 p4x4-i8x8 loop-5 WBP cabac

nero: 7,5% 3,29
libav-ffdshow_old: 6,3% 2,98
libav-mplayer: 6,2% 3,28
moonlight: 6,1% 2,94
libav-ffdshow: 4,5% 2,12
elecard: 3,5% 1,33
ateme: 3,4% 1,75

------------------------------------------------------------------------
B-ref vs. no B-ref

720x288 B3 Ref5 p4x4-i8x8 loop-5 WBP cabac

nero: 3,4% 1,39
libav-ffdshow: 0,9% 0,38
libav-mplayer: 0,8% 0,41
ateme: 0,7% 0,34
libav-ffdshow_old: 0,4% 0,16
elecard: 0,2% 0,08
moonlight: -0,1% -0,04

------------------------------------------------------------------------
------------------------------------------------------------------------
loop

loop-5 vs. no loop

720x288 B2 Ref3 p8x8-i4x4 cabac

libav-mplayer: 21,0% 14,16
libav-ffdshow: 20,5% 12,28
nero: 19,8% 12,89
libav-ffdshow_old: 18,7% 10,85
elecard: 18,4% 9,34
mainconcept: 15,8% 7,48
videosoft: 14,3% 8,18
moonlight: 6,9% 4,34
ateme: 6,2% 3,80
ateme_old: 4,9% 2,62


720x288 B3-Ref Ref5 p4x4-i8x8 WBP cabac

libav-ffdshow: 20,6% 11,67
libav-mplayer: 19,4% 12,05
libav-ffdshow_old: 17,3% 9,30
elecard: 17,0% 7,62
nero: 16,5% 8,33
ateme: 6,2% 3,37
moonlight: 5,8% 2,80

------------------------------------------------------------------------
loop-5 vs. loop+6

720x288 B3-Ref Ref5 p4x4-i8x8 WBP cabac

ateme: 14,7% 7,45
moonlight: 11,9% 5,44
nero: 7,4% 3,11
libav-ffdshow_old: 5,5% 2,43
libav-mplayer: 5,3% 2,67
libav-ffdshow: 4,4% 2,00
elecard: 4,2% 1,55

------------------------------------------------------------------------
------------------------------------------------------------------------
cabac

cabac vs. no cabac

720x288 B3-Ref Ref5 p4x4-i8x8 loop-5 WBP

libav-mplayer: 16,0% 9,54
libav-ffdshow_old: 15,1% 7,89
libav-ffdshow: 13,8% 7,20
ateme: 10,3% 5,80
moonlight: 9,3% 4,68
nero: 5,2% 2,31
elecard: 4,9% 1,90

------------------------------------------------------------------------
------------------------------------------------------------------------
cabac + noloop vs. loop-5 + nocabac

720x288 B3-Ref Ref5 p4x4-i8x8 WBP

elecard: 12,8% 5,72
nero: 12,0% 6,02
libav-ffdshow: 7,9% 4,47
libav-mplayer: 4,1% 2,51
libav-ffdshow_old: 2,6% 1,41
moonlight: -3,9% -1,88
ateme: -4,5% -2,43

------------------------------------------------------------------------
------------------------------------------------------------------------
resolution

720x288 vs. 640x256

B3-Ref Ref5 p4x4-i8x8 loop-5 WBP cabac

nero: 22,8% 12,43
libav-ffdshow_old: 21,1% 11,87
elecard: 20,4% 9,49
libav-ffdshow: 20,3% 11,48
ateme: 20,2% 12,83
libav-mplayer: 20,1% 12,54
moonlight: 17,2% 9,46

------------------------------------------------------------------------
------------------------------------------------------------------------
custom quant matrix

cqm qmatrix vs. no cqm

720x288 B3-Ref Ref5 p4x4-i8x8 loop-5 WBP cabac

nero: 7,5% 2,68
ateme: 3,5% 1,71
elecard: 3,3% 1,50
moonlight: 1,7% 0,67

------------------------------------------------------------------------
------------------------------------------------------------------------

[bond]

raw results from which all the above values are derived:

high profile:
x264_hp_2pass_640x256_B3-Ref_Ref5_p4x4-i8x8_loop-5_WBP_cabac
ateme: 63.45
libav-mplayer: 62.45
libav-ffdshow: 56.46
libav-ffdshow_old: 56.33
moonlight: 55.02
nero: 54.47
elecard: 46.62
ateme_old: high profile not supported
mainconcept: high profile not supported
videosoft: high profile not supported


x264_hp_2pass_720x288_B0_Ref5_p4x4-i8x8_loop-5_WBP_cabac
moonlight: 63.09
ateme: 60.23
libav-mplayer: 57.59
nero: 56.17
libav-ffdshow: 50.97
libav-ffdshow_old: 50.20
elecard: 45.35
ateme_old: high profile not supported
mainconcept: high profile not supported
videosoft: high profile not supported


x264_hp_2pass_720x288_B1_Ref5_p4x4-i8x8_loop-5_WBP_cabac
libav-mplayer: 52.78
ateme: 52.03
moonlight: 48.54
libav-ffdshow_old: 47.28
libav-ffdshow: 46.72
nero: 43.94
elecard: 38.38
ateme_old: high profile not supported
mainconcept: high profile not supported
videosoft: high profile not supported


x264_hp_2pass_720x288_B3_Ref5_p4x4-i8x8_loop-5_WBP_cabac
ateme: 50.28
libav-mplayer: 49.50
moonlight: 45.60
libav-ffdshow: 44.60
libav-ffdshow_old: 44.30
nero: 40.65
elecard: 37.05
ateme_old: high profile not supported
mainconcept: high profile not supported
videosoft: high profile not supported


x264_hp_2pass_720x288_B3-Ref_Ref5_p4x4-i8x8_loop-5_WBP
libav-mplayer: 59.45
ateme: 56.42
libav-ffdshow_old: 52.35
libav-ffdshow: 52.18
moonlight: 50.24
nero: 44.35
elecard: 39.03
ateme_old: high profile not supported
mainconcept: high profile not supported
videosoft: high profile not supported


x264_hp_2pass_720x288_B3-Ref_Ref5_p4x4-i8x8_loop-5_WBP_cabac
ateme: 50.62
libav-mplayer: 49.91
moonlight: 45.56
libav-ffdshow: 44.98
libav-ffdshow_old: 44.46
nero: 42.04
elecard: 37.13
ateme_old: high profile not supported
mainconcept: high profile not supported
videosoft: high profile not supported


x264_hp_2pass_720x288_B3-Ref_Ref5_p4x4-i8x8_loop-5_WBP_cabac_cqm-qmatrix
ateme: 48.91
moonlight: 44.89
nero: 39.36
elecard: 35.63
libav-ffdshow: cqm not supported
libav-mplayer: cqm not supported
ateme_old: high profile not supported
mainconcept: high profile not supported
videosoft: high profile not supported


x264_hp_2pass_720x288_B3-Ref_Ref5_p4x4-i8x8_loop+6_WBP_cabac
libav-mplayer: 47.24
ateme: 43.17
libav-ffdshow: 42.98
libav-ffdshow_old: 42.03
moonlight: 40.12
nero: 38.93
elecard: 35.58
ateme_old: high profile not supported
mainconcept: high profile not supported
videosoft: high profile not supported


x264_hp_2pass_720x288_B3-Ref_Ref5_p4x4-i8x8_WBP_cabac
libav-mplayer: 61.96
libav-ffdshow: 56.65
ateme: 53.99
libav-ffdshow_old: 53.76
nero: 50.37
moonlight: 48.36
elecard: 44.75
ateme_old: high profile not supported
mainconcept: high profile not supported
videosoft: high profile not supported
main profile:

x264_mp_2pass_640x256_B3-Ref_Ref5_p4x4-i4x4_loop-5_WBP_cabac
ateme: 65.39
libav-mplayer: 63.71
libav-ffdshow_old: 59.20
moonlight: 55.72
nero: 54.68
libav-ffdshow: 53.37
elecard: 48.74
mainconcept: 46.47
ateme_old: b-ref not supported
videosoft: b-ref not supported


x264_mp_2pass_720x288_B2_Ref3_p4x4-i4x4_cabac
libav-mplayer: 66.33
moonlight: 61.99
libav-ffdshow: 58.73
libav-ffdshow_old: 57.31
ateme: 55.33
videosoft: 54.05
nero: 53.08
elecard: 51.58
ateme_old: 47.86
mainconcept: 47.86


x264_mp_2pass_720x288_B2_Ref3_p8x8-i4x4_cabac
libav-mplayer: 67.33
nero: 65.08
moonlight: 62.67
ateme: 60.95
libav-ffdshow: 59.76
libav-ffdshow_old: 58.15
videosoft: 57.29
ateme_old: 52.99
elecard: 50.84
mainconcept: 47.49


x264_mp_2pass_720x288_B2_Ref3_p8x8-i4x4_loop-5_cabac
moonlight: 58.33
ateme: 57.15
libav-mplayer: 53.17
nero: 52.19
ateme_old: 50.37
videosoft: 49.11
libav-ffdshow: 47.48
libav-ffdshow_log: 47.30
elecard: 41.50
mainconcept: 40.01


x264_mp_2pass_720x288_B2-Ref_Ref3_p4x4-i4x4_cabac
libav-mplayer: 65.36
moonlight: 62.09
libav-ffdshow: 59.51
libav-ffdshow_old: 57.33
ateme: 57.29
nero: 55.63
elecard: 52.50
mainconcept: 49.27
ateme_log: b-ref not supported
videosoft: b-ref not supported


x264_mp_2pass_720x288_B3-Ref_Ref1_p4x4-i4x4_loop-5_WBP_cabac
ateme: 57.04
libav-mplayer: 55.45
libav-ffdshow: 48.99
libav-ffdshow_old: 48.08
moonlight: 47.96
nero: 46.82
elecard: 41.28
mainconcept: 38.78
ateme_old: b-ref not supported
videosoft: b-ref not supported


x264_mp_2pass_720x288_B3-Ref_Ref3_p4x4-i4x4_loop-5_WBP_cabac
ateme: 53.07
libav-mplayer: 50.86
moonlight: 46.10
libav-ffdshow: 45.87
libav-ffdshow_old: 45.06
nero: 42.49
elecard: 38.59
mainconcept: 36.79
ateme_old: b-ref not supported
videosoft: b-ref not supported


x264_mp_2pass_720x288_B3-Ref_Ref3_p4x4-i4x4_loop-5_cabac
moonlight: 57.64
ateme: 53.53
libav-mplayer: 52.08
libav-ffdshow: 46.36
libav-ffdshow_old: 46.02
nero: 45.29
elecard: 42.14
mainconcept: 41.06
ateme_old: b-ref not supported
videosoft: b-ref not supported


x264_mp_2pass_720x288_B3-Ref_Ref5_p4x4-i4x4_loop-5_WBP_cabac
ateme: 53.19
libav-mplayer: 49.92
libav-ffdshow: 45.57
moonlight: 45.50
libav-ffdshow_old: 44.86
nero: 41.76
elecard: 38.33
mainconcept: 36.66
ateme_log: b-ref not supported
videosoft: b-ref not supported


x264_mp_2pass_640x256_B0_Ref3_p8x8-i4x4_loop_cabac
ateme: 77.31
moonlight: 75.64
ateme_old: 71.90
libav-mplayer: 68.44
nero: 67.89
libav-ffdshow_old: 64.37
libav-ffdshow: 62.63
videosoft: 60.95
elecard: 54.19
mainconcept: 52.72
videosoft_old: 31.87


x264_mp_2pass_640x256_B2_Ref5_p4x4-i4x4_loop_cabac
ateme: 67.19
libav-mplayer: 55.70
moonlight: 54.29
libav-ffdshow_old: 53.07
libav-ffdshow: 52.87
ateme_log: 49.60
nero: 47.79
elecard: 43.91
mainconcept: 41.60
videosoft: 38.97
videosoft_old: 24.25


nero_2pass-777kbps_Cabac_Deblock-5-adapt_B2_Ref3_noWPred_Qpel_p8x8_cartoon_psy2_extra
moonlight: 68.43
ateme: 67.51
libav-mplayer: 60.65
nero: 59.49
ateme_old: 57.55
libav-ffdshow_old: 56.48
videosoft: 55.45
libav-ffdshow: 54.55
elecard: 47.38
mainconcept: 45.55


nero_2pass-777kbps_Cabac_Deblock-5-adapt_B2_Ref3_WPred+wbp_Qpel_p8x8_cartoon_psy2_extra
ateme: 65.86
libav-mplayer: 58.02
libav-ffdshow_old: 54.87
libav-ffdshow: 54.35
ateme_old: 52.30
moonlight: 52.25
nero: 51.33
elecard: 42.01
mainconcept: 39.97
videosoft: 35.71
baseline profile:

x264_bp_720x288_B0_Ref5_p8x8-i4x4_loop-5_wbp
moonlight: 75.34
libav-mplayer: 72.88
ateme: 72.28
ateme_log: 70.63
videosoft: 64.01
libav-ffdshow_old: 63.47
libav-ffdshow: 61.83
nero: 61.80
elecard: 52.02
mainconcept: 51.16
videosoft_old: 33.46

[Sharktooth]

:eek:
sorry, i need to buy a pair of googles...

[celtic_druid]

@bond, did you use my ffdshow build as is? Because the libavcodec is built with gcc and generic flags. It might be interesting to see the same test with a version compiled with flags specific for your CPU, since as you say ffdshow is not that much slower than moonlight.

[bill_baroud]

Thanks for this usefull test !
I would just say that, for people like me who didn't go read the thread about libavcodec speed measurement, your results numbers mean absolutly nothing... You could write somewhere that you are talking about Frame Per Second (and not cpu occupation or whatelse)... That puzzled me until i decided to read the thread linked in your post.

[alexcyn]

Hi Bond.
It seems you are using very-very old videosoft decoder version 2.0.2.3. New much faster version 2.2 is available for already long time. Free evaluation of VSS h264 DirectShow decoder filter 2.2 is available here:
http://www.vsofts.com/h264/decoders.html
See item "Installation". Or direct link to installer:
http://www.vsofts.com/h264/pub/vssh3dec.exe
The DirectShow decoder should support any format, not only AVI.

Commercial version of the decoder is included into both Base ($20) and Main ($99) codec 2.3 consumer packages, so the price of the decoder is only $20.

The newest VSS H264 decoder 3.0 (currently available only in Professional products) supports all features from Main & Baseline profiles as well as High Profile. Also it has performance ~15% better than version 2.2.

By the way, what hardware (CPU, memory) are you using?

=Alexey Doilnitsyn, VSS Inc.

[Manao]

i didnt know what to expect from the ateme decoder and i also have to say i wasnt really positively surprised as it performed in the middle or slow
i have to note that ateme is working on a new decoder also supporting high profile, which i wasnt able to test, i hope they will also enhance decoding speedfor the main profile that are decoded by ffdshow / moonlight / nero / ateme, the average speeds are respectively 55.93, 61.94, 56.69 and 54.65. So indeed, moonlight is above the others, but the others rank the same.

Also, I wouldn't have used average speeds but, inverse of average of inverse speeds ( hence, the sum of decoding time ).

Finally, including mplayer is great for promotting mplayer ( or vlc, btw ), but serves no purposes in your comparison : you're comparing decoders, not players ( and -vo null is almost cheating if it does what I think :p )

[IgorC]

Here Nero decoder is still faster than ffdshow+haali and mplayer. Maybe it depends of settings. I also use hard settings (high profile, ref 8-16, weight, bframes 2-3, high values for mvrange for x264/H.264 etc.) And probably it depens of CPU. In my case SSE2.

[hpn]

and -vo null is almost cheating if it does what I think :p
"-vo null" means mplayer will output no frame to a video device. I've never tried the Chegepuga filter that Bond has used with the paid decoders, but I guess It does the same thing (plus the fps measuring itself), so unless I'm missing something I don't see any cheating here.

[akupenguin]

baseline profile:
x264_720x288_B0_Ref5_p8x8-i4x4_loop-5_wbp_cabac
cabac isn't baseline. (wpred isn't either, but wbp without B-frames doesn't matter)

Also, how about lossless and interlacing in the feature comparison?

[Manao]

Well, I've got a decoder available both in a ds filter and in a standalone application that can behave like mplayer -vo null. The ds overhead for the filter is roughly a copy of a picture, which hardly matters at the framerate i'm testing. In one case ( standalone ), i get 48 fps, in the second ( ds filter + chegepuga ), i get 42 fps, so it's a 12.5 % speed gain ( or 11% speed loss :p ).

DirectShow itself is responsible for that loss ( which is huge, because I've got a 2800+ with a fairly fast memory ).

So perhaps it's not -vo null that creates the difference, yet comparing ds filters to mplayer isn't that useful when you want to compare decoders.

[SeeMoreDigital]

Great work bond....

It will interesting to see if things change as time rolls by and refinements are made....


Cheers

[hworldjj]

Thanks! Good reading

[bond]

first of all thx for all the responses and the interest! :)

@bond, did you use my ffdshow build as is? Because the libavcodec is built with gcc and generic flags. It might be interesting to see the same test with a version compiled with flags specific for your CPU, since as you say ffdshow is not that much slower than moonlight.yep i used your build as is. if you could make a build compiled for my pentium3 866mhz i would be happy to test it too :)

your results numbers mean absolutly nothing... You could write somewhere that you are talking about Frame Per Second (and not cpu occupation or whatelse)... That puzzled me until i decided to read the thread linked in your post.indeed, i will add this

It seems you are using very-very old videosoft decoder version 2.0.2.3. New much faster version 2.2 is available for already long time. Free evaluation of VSS h264 DirectShow decoder filter 2.2 is available here:i used indeed an old version, and that was mainly done because i did the test to find out what decoder i could use for my encodes, so i used the last version you released which was unlimited

i simply wasnt really interested in testing a decoder which becomes useless for me after 30 days :(

The DirectShow decoder should support any format, not only AVI.hm i think your decoder works with the VSSH and H264 fourcc. actually i dont know a splitter which outputs this (eg from .mp4 or .mpg) your decoder could connect to, so theoretically your decoder can of course work with any format, but practically its not so easy till now

Commercial version of the decoder is included into both Base ($20) and Main ($99) codec 2.3 consumer packages, so the price of the decoder is only $20.so the 20$ baseline version includes a main profile decoder?

The newest VSS H264 decoder 3.0 (currently available only in Professional products) supports all features from Main & Baseline profiles as well as High Profile. Also it has performance ~15% better than version 2.2.sounds indeed very powerful and i would love to test it, its just that the 30days limit makes it pretty useless for me, but if you send me an unlimited copy i will of course test it ;) :)

By the way, what hardware (CPU, memory) are you using?a good old pentium3 866mhz

Alexey Doilnitsyn, VSS Inc. great to have you around on doom9!

Also, I wouldn't have used average speeds but, inverse of average of inverse speeds ( hence, the sum of decodinghm the clips all have the same lenght, in what way would the sum tell us more?

Finally, including mplayer is great for promotting mplayer ( or vlc, btw ), but serves no purposes in your comparison : you're comparing decoders, not players ( and -vo null is almost cheating if it does what I think :p )well the point is you have to see this from a users point of view and the user asks "what player should i play my avc clips with"
for the user it doesnt matter what codec interface stands behind it, be it directshow or whatever

i am actually also planning to add decoding of qt7 to the comparison, but i am simply too lazy to set it up

the thing is if the commercial decoders are limited to directshow, its the commercials decoders problem and not libavcodec's, which is simply available in a form which allows it to be used in superior platforms than directshow, that should be honored

and as you saw i also included ffdshow and it still performed great

"-vo null" means mplayer will output no frame to a video device. I've never tried the Chegepuga filter that Bond has used with the paid decoders, but I guess It does the same thing (plus the fps measuring itself), so unless I'm missing something I don't see any cheating here. chegepuga is also a null renderer with fps measurement, exactly the same as what mplayer does imho

cabac isn't baseline. (wpred isn't either, but wbp without B-frames doesn't matter)my fault, the baseline clip i tested of course didnt use cabac, altough i noted it (must be a copy paste error or so)

actually i noticed that x264 enables the wbp flag in the pps altough it sets the baseline profile in the sps correctly

Also, how about lossless and interlacing in the feature comparison?yep i thought about that too, i was too lazy to do it actually, also i lacked the time to really make some good comparable interlaced clips with the reference
maybe i will simply test the decoders capabilities on the clips i have lying around without speed measurement

[Nil Einne]

I could be wrong but I was under the impression not all decoders are equal quality-wise. Frequently they use estimations etc to improve speed which is fine but when quality can very IMHO a straight out speed test is not so meaningful for many people. I could make a decoder that is very very fast but the output it so crap it isn't worth it. Of course I'm aware quality issues are a problem since it's so subjective so instead, I would recommend you get the reference implementation of h.264 which I assume is completely accurate and then do a mathematical comparison. Of course, this can be a bit misleading since a smart decoder may have higher mathmatical difference but lower noticable difference but it's better then nothing.

[Manao]

No, none of these codecs do such a thing. Not decoding picture as they should leads immediately to errors that are easily spottable.

Only libavcodec got a patch, very recently, that allowed to disable deblocking at very low qps, but it's not enabled by default, and it's highly recommended not to use it.

[Nil Einne]

Okay thanks for clarifying. I was always under the impression that there was some (minor) differences in the output quality of non post-processing decoders due to factors such as estimation, dropping least significant bits in some cases, different interpretations of the algorythm etc. Now I know. So basically you can take any decoder and use it to save an uncompressed raw video files and the file would be exactly the same! That is good :-)

[Sergey A. Sablin]

chegepuga is also a null renderer with fps measurement, exactly the same as what mplayer does imho
Bond, I dunno what exactly does mplayer with "-vo null" option, but I exactly know what does chegepuga - DShow decoder should copy output frame into this renderer. So if mplayer with "-vo null" doesn't require this from decoder, then it is the difference for the test, cause for real playback decoders in mplayer also should do the copy.
In that way real performance can be different from what you have measured.
Does somebody know how mplayer process with this option? with or without the copy?

[bond]

well the mplayer devs recommend when wanting to do benchmarks to use the -vo null and -benchmark options, so i assume the output values are useable!?

[Sergey A. Sablin]

well the mplayer devs recommend when wanting to do benchmarks to use the -vo null and -benchmark options, so i assume the output values are useable!?
Sure it usable. But if mplayer doesn't require output frame copy, then this values are only usable to compare different decoders inside mplayer - not with decoders inside DShow environment, do you agree?
But if mplayer also require to do this copy, then results are also comparable to DS filters.

(I just mean that if devs recommend this way to measure performance than we can't say that it measure like another tools)

[akupenguin]

Does somebody know how mplayer process with this option? with or without the copy?
libavcodec returns a pointer into the same decoded picture buffer used for inter prediction. Then real vos copy it to video memory, and -vo null doesn't. (In some formats (including ASP but not yet implemented for H.264), frames that don't need to be kept (B-frames or Intra-only) can be decoded directly into video memory, or incrementally into a video filter if some filtering is performed.)

You're saying that in DShow, instead the vo passes a pointer to the decoder, and real vos pass a pointer to video memory while chegepuga passes a pointer to some dummy buffer that's never read?

[Sergey A. Sablin]

libavcodec returns a pointer into the same decoded picture buffer used for inter prediction. Then real vos copy it to video memory, and -vo null doesn't. (In some formats (including ASP but not yet implemented for H.264), frames that don't need to be kept (B-frames or Intra-only) can be decoded directly into video memory, or incrementally into a video filter if some filtering is performed.)

You're saying that in DShow, instead the vo passes a pointer to the decoder, and real vos pass a pointer to video memory while chegepuga passes a pointer to some dummy buffer that's never read?
I mean that in DShow decoder after frame decoding should copy the output frame into another location which is indicated by pointer passed to decoder by downstream filter (which is in this case chegepuga and in real playback is video renderer), but I don't know whether mplayer requires this too.

[akupenguin]

MPlayer does not require that. Neither -vo null nor the real playback do that copy.

[alexcyn]

To: Bond
> i used indeed an old version, and that was mainly done because i
> did the test to find out what decoder i could use for my encodes,
> so i used the last version you released which was unlimited
unlimited free version may violate h264 patents, thats why we had to limit it by 30 days :-(.

> i simply wasnt really interested in testing a decoder which becomes
> useless for me after 30 days :(
we will think, may be it makes sense to give you unlimited version for testing.

> hm i think your decoder works with the VSSH and H264 fourcc.
> actually i dont know a splitter which outputs this (eg from .mp4 or .mpg)
> your decoder could connect to, so theoretically your decoder can of
> course work with any format, but practically its not so easy till now
Yes, version 2.0 was limited by 2 fourccs, but version 2.2 accepts any fourcc (type=video, subtype=[any]).

> so the 20$ baseline version includes a main profile decoder?
YES
=Alexei, VSS

[bond]

thx for the info! :)

[Haali]

I mean that in DShow decoder after frame decoding should copy the output frame into another location which is indicated by pointer passed to decoder by downstream filter (which is in this case chegepuga and in real playback is video renderer), but I don't know whether mplayer requires this too.
DShow can also act in the same way as mplayer. In dshow buffer management is done in some nontrivial way. First you negotiate an allocator with the downstream filter, obviously in case of video renderer you want to use the renderer's allocator since it knows how to work with video memory. Second you set the allocator parameters like number of buffers, alignment and buffer size. Then during playback you call allocator's GetBuffer() and filter's Receive() after you are done processing. If you specify AM_GBF_NOTASYNCPOINT in GetBuffer() call, then it will return the buffer with unchanged contents from the previous frame. So to avoid extra copying overhead you can request one buffer from the allocator and use AM_GBF_NOTASYNCPOINT. In this case renderers like overlay mixer will return a pointer to the overlay's video memory. Most decoders do it that way, buf ffdshow still performs an extra copy internally afaik.

[TheBashar]

I could be wrong but I was under the impression not all decoders are equal quality-wise.

I concur on this point. After reading your comparison, I tried out the Moonlight-Elecard MPEG Player that Bond linked to. In testing with some of my AVC high-profile encodes, I found it periodically produced dark macroblocks which did not appear when using nero's decoder.

Being fast is great, but not at the cost of decoding artifacts.

Here's a sample of what I'm talking about:

http://img352.imageshack.us.nyud.net:8090/img352/9422/mempeg43dn.png

[stephanV]

This is a bug, not a difference in quality. :)

[bobololo]

For those who are interested in decoding filter benchmarking, Haali was kind enough to write a little dshow application extremely convenient for this purpose.

It's available at the url: http://haali.cs.msu.ru/mkv/timeCodec.exe

It requires the latest version of Haali Media Splitter available here (http://haali.cs.msu.ru/mkv/MatroskaSplitter.exe).

With some decoding filters (like ateme's one), it may requires an additionnal filter you can find here (you have to register it manually): http://haali.cs.msu.ru/mkv/m2r.dll

I did a quick test using a clip posted during ateme hp beta (batman-ateme-3500k-hp.mp4 (ftp://mood.ateme.com/beta/batman-ateme-3500k-hp.mp4)) and I got those figures:

nero (nve 3.1.0.16): 46.4 fps
moonlight (0.9.0 build 50208 beta): 47.6 fps
ffdshow (20050822 - cd build): 48.1 fps
ateme (2.2.1.0): 56.5 fps

The tests were done on a Pentium 4 @ 3.0 GHz (with HT).

For all decoders, timeCodec uses Haali Splitter to parse the file and to feed the decoder filter.

This test used an updated version of ateme decoder filter that be provided in the next beta release.

Many thanks to Haali again for his great work !

ps: I've tried moonlight decoder on other clips, and I had some decoding issues like with this one (ftp://mood.ateme.com/beta/cinderella-ateme-3000k-hp.mp4). Also it doesn't seem to decode mbaff correctly ?

EDIT: I found my problem with ffdshow, the postprocessing was enabled. It's much better now :) and I udpdated all the results with a 3.0 GHz cpu measurements.

[Sergey A. Sablin]

MPlayer does not require that. Neither -vo null nor the real playback do that copy.
Well, just a two questions:
1. Did you mean that decoders use video memory for storing reference pictures? How about reading from video memory?
2. Did you mean that all decoders use YV12 colorspace for rendering? YV12 is slower for rendering than YUY2 and UYVY on all video cards I know.

DShow can also act in the same way as mplayer. In dshow buffer management is done in some nontrivial way. First you negotiate an allocator with the downstream filter, obviously in case of video renderer you want to use the renderer's allocator since it knows how to work with video memory. Second you set the allocator parameters like number of buffers, alignment and buffer size. Then during playback you call allocator's GetBuffer() and filter's Receive() after you are done processing. If you specify AM_GBF_NOTASYNCPOINT in GetBuffer() call, then it will return the buffer with unchanged contents from the previous frame. So to avoid extra copying overhead you can request one buffer from the allocator and use AM_GBF_NOTASYNCPOINT. In this case renderers like overlay mixer will return a pointer to the overlay's video memory. Most decoders do it that way, buf ffdshow still performs an extra copy internally afaik.

Did you mean decoding directly to video memory? If yes - than try to use at least two decoders with such technique. It'll be very interesting.
Reference pictures are also can't be decoded into video memory, so they need a copy anyway.

[Haali]

What I meant is decoders usually request only one buffer from the allocator, I don't know if they do an extra copy or not.

[akupenguin]

Well, just a two questions:
1. Did you mean that decoders use video memory for storing reference pictures? How about reading from video memory?
libavcodec supports:
Store picture in application specified pointer, usually video memory. Used for non-referenced pictures when no filtering is needed. If you use this mode for a referenced picture, it will try to read it back from the buffer.
Callback after each row of macroblocks with a pointer to the decoded slice. Used for referenced pictures or simple filters.
Return a pointer to the decoded frame. Used for MEncoder, -vo null, or complex filters.
The decoder does no copies in any of those. The -vo (other than null) does a copy in (2) and (3), or filters/encoders may use the (read-only) buffer as is.

2. Did you mean that all decoders use YV12 colorspace for rendering? YV12 is slower for rendering than YUY2 and UYVY on all video cards I know.
Yes, all decoders output the same pixel format as the video actually stores (so usually YV12). All video cards I know of are fast enough to do scaling + YV12->RGB for any video resolution they support at all, so you can free a little CPU time by not doing software YV12->YUY2 conversion. If for some reason you or the -vo need another pixel format, then MPlayer will insert a conversion filter (or maybe it's not always automatic; anyway, it's equivalent to "-vf scale").

[Sergey A. Sablin]

libavcodec supports:
[list=1] Store picture in application specified pointer, usually video memory. Used for non-referenced pictures when no filtering is needed. If you use this mode for a referenced picture, it will try to read it back from the buffer.

reading from video memory is very low -> it is very unefficient to use it when postprocessing is used. That means it is very unefficient for H.264 (at least), cause deblocking are used for most cases.

Yes, all decoders output the same pixel format as the video actually stores (so usually YV12). All video cards I know of are fast enough to do scaling + YV12->RGB for any video resolution they support at all, so you can free a little CPU time by not doing software YV12->YUY2 conversion. If for some reason you or the -vo need another pixel format, then MPlayer will insert a conversion filter (or maybe it's not always automatic; anyway, it's equivalent to "-vf scale").
For modern video cards yes. But for old YV12 is much slower.

Also decoding directly to video memory (i.e. in YV12) for some video cards produce many errors - try to use two instances of ffdshow with YV12 output enabled to decode some stream and you will see these artifacts. (I've tried mpeg-2 sequence with matrox parhelia via libavcodec and libmpg2. You can either use two instances in one process or in two different processes - it doesn't matter)

I don't want to say that decoding directly to video memory or rendering in YV12 format is slower everywhere, but in most cases it is still either slower or buggy and comparing decoding methods that doesn't work correctly in all cases is not so correct.

[bond]

updated some values with a new version of ateme:
ateme-new: ateme mp4 parser 1.2.5.3 / ateme decoder 2.2.1.0

HIGH PROFILE

x264_hp_2pass_720x288_B0_Ref5_p4x4-i8x8_loop-5_WBP_cabac.mp4
moonlight: 63.09
ateme-new: 60.23
libav-mplayer: 57.59
nero: 56.17
libav-ffdshow: 50.20


x264_hp_2pass_720x288_B3-Ref_Ref5_p4x4-i8x8_loop-5_WBP.mp4
libav-mplayer: 59.45
ateme-new: 56.42
libav-ffdshow: 52.35
moonlight: 50.24
nero: 44.35


x264_hp_2pass_720x288_B3-Ref_Ref5_p4x4-i8x8_loop-5_WBP_cabac_cqm-qmatrix.mp4
ateme-new: 48.91
moonlight: 44.89
nero: 39.36
libav-ffdshow: cqm not supported
libav-mplayer: cqm not supported


x264_hp_2pass_720x288_B3-Ref_Ref5_p4x4-i8x8_loop+6_WBP_cabac.mp4
libav-mplayer: 47.24
ateme-new: 43.17
libav-ffdshow: 42.03
moonlight: 40.12
nero: 38.93


x264_hp_2pass_720x288_B3-Ref_Ref5_p4x4-i8x8_WBP_cabac.mp4
libav-mplayer: 61.96
ateme-new: 53.99
libav-ffdshow: 53.76
nero: 50.37
moonlight: 48.36MAIN PROFILE

x264_mp_2pass_720x288_B2_Ref3_p8x8-i4x4_cabac.mp4
libav-mplayer: 67.33
nero: 65.08
moonlight: 62.67
ateme-new: 60.95
libav-ffdshow: 58.15
ateme: 52.99
mainconcept: 47.49


x264_mp_2pass_720x288_B2-Ref_Ref3_p4x4-i4x4_cabac.mp4
libav-mplayer: 65.36
moonlight: 62.09
libav-ffdshow: 57.33
ateme-new: 57.29
nero: 55.63
mainconcept: 49.27
ateme: b-ref not supported


nero_2pass-777kbps_Cabac_Deblock-5-adapt_B2_Ref3_WPred+wbp_Qpel_p8x8_cartoon_psy2_extra.mp4
ateme-new: 65.86
libav-mplayer: 58.02
libav-ffdshow: 54.87
ateme: 52.30
moonlight: 52.25
nero: 51.33
mainconcept: 39.97BASELINE PROFILE

x264-r285_bp_720x288_B0_Ref5_p8x8-i4x4_loop-5_wbp_cabac_mp4box.mp4
moonlight: 75.34
libav-mplayer: 72.88
ateme-new: 72.28
ateme: 70.63
libav-ffdshow: 63.47
nero: 61.80
mainconcept: 51.16
videosoft: 33.46very good, but also varying results, often very fast, but also often on par with other good decoders

[Haali]

Also decoding directly to video memory (i.e. in YV12) for some video cards produce many errors
That's because they support only one YV12 overlay, so two instances conflict when using the same hardware resource. AFAIK overlay is the only place where planar YV12 is supported by video hardware, even modern cards don't support YV12 textures.

[bond]

and some more findings with a new videosoft decoder:
videosoft-new: m$ avi parser 6.5.1.902 / videosoft decoder 2.3.1.5

MAIN PROFILE

x264_mp_2pass_720x288_B2_Ref3_p4x4-i4x4_cabac.mp4
libav-mplayer: 66.33
moonlight: 61.99
libav-ffdshow: 57.31
videosoft-new: 54.05
nero: 53.08
ateme: 47.86
mainconcept: 47.86


x264_mp_2pass_720x288_B2_Ref3_p8x8-i4x4_cabac.mp4
libav-mplayer: 67.33
nero: 65.08
moonlight: 62.67
ateme-new: 60.95
libav-ffdshow: 58.15
videosoft-new: 57.29
ateme: 52.99
mainconcept: 47.49


x264_mp_2pass_720x288_B2_Ref3_p8x8-i4x4_loop-5_cabac.mp4
moonlight: 58.33
libav-mplayer: 53.17
nero: 52.19
ateme: 50.37
videosoft-new: 49.11
libav-ffdshow: 47.30
mainconcept: 40.01


x264_mp_2pass_640x256_B0_Ref3_p8x8-i4x4_loop_cabac.mp4
moonlight: 75.64
ateme: 71.90
libav-mplayer: 68.44
nero: 67.89
libav-ffdshow: 64.37
videosoft-new: 60.95
mainconcept: 52.72
videosoft: 31.87


x264_mp_2pass_640x256_B2_Ref5_p4x4-i4x4_loop_cabac.mp4
libav-mplayer: 55.70
moonlight: 54.29
libav-ffdshow: 53.07
ateme: 49.60
nero: 47.79
mainconcept: 41.60
videosoft-new: 38.97
videosoft: 24.25

BASELINE PROFILE

x264-r285_bp_720x288_B0_Ref5_p8x8-i4x4_loop-5_wbp_cabac_mp4box.mp4
moonlight: 75.34
libav-mplayer: 72.88
ateme-new: 72.28
ateme: 70.63
videosoft-new: 64.01
libav-ffdshow: 63.47
nero: 61.80
mainconcept: 51.16
videosoft: 33.46the new vss decoder can definitely keep up in some cases with the others, but is also worse than the others in other cases
its definitely much better than the first version is tested (the last one freely available)

i also found some things:
- it can connect to the nero and haali parser, but doesnt show anything when playing (outputs MPEG2Video)
- it works fine with the avi parser (outputs H264 and VSSH)
- it also works with the ateme mp4 parser (outputs H264)
- b-ref crash the decoder
- high profile is not supported, altough videosoft already has a hp decoder, which i wasnt able to test

[saratoga]

a good old pentium3 866mhz

That CPU lacks SSE2 which is the new standard for floating point calculations on present x86 hardware. Its reasonable to think the SSE2 code is probably better developed and supported as x87 is about to be depreciated. Its possible x87 fp is provided purely as legacy support in some codecs, particularly ones like Nero which are aimed at commerical use.

It would be interesting to see if the relative results change any when you run the same test on an SSE2 capable processor.

[akupenguin]

Codecs have nothing to do with floating-point. There aren't any x87 or SSE2 instructions at all in libav's H.264 decoder.

[Manao]

Indeed.

And, furthermore, only amd64 and P4 have SSE2, and, for most amd64 ( if not all ), SSE2 ops are as slow as their MMX counterparts.

So, basically, SSE2 helps only for P4 and very recent amd64.

[saratoga]

Codecs have nothing to do with floating-point. There aren't any x87 or SSE2 instructions at all in libav's H.264 decoder.

You're correct. Change x87 to MMX and my post will make a little more sense.

And, furthermore, only amd64 and P4 have SSE2, and, for most amd64 ( if not all ), SSE2 ops are as slow as their MMX counterparts.

So you mean they're only fast for the overwhelming majority of machines ;)

I'm still intersted on figures from a newer P4 or A64. While the P3 numbers are relevent, a control would be nice.

[bond]

ok i finally found the time to finalize the comparison

the following additions have been made:
- ateme
- videosoft
- ffdshow with pentium3 specific compile flags (thx celtic_druid!)
- elecard

- values showing how the different decoders perform on specific coding tools (maybe gives devs a hint on what needs tuning)

i hope you guys find it interesting

[Manao]

The way you're computing decoder's efficiency for each tools is flawed : you have to measure the loss of time, not the loss of fps. Because losing 1sec on a 5 sec decoding time at 100 fps means a drop of 16.66 fps, while losing 1 sec on a 5 sec decoding time at 50 fps means a drop of 8.33 fps.

Enabling a feature almost always add a constant time, not a proportionnal fps loss.

Also, do consider that incertitude on fps figures you're giving are at least 2 fps.

Finally, what was the average quantizer of the clip you used ( out of curiosity, i think it might explain why ateme's decoder goes faster when deblocking -5 is enabled... )

[bond]

The way you're computing decoder's efficiency for each tools is flawed : you have to measure the loss of time, not the loss of fps. Because losing 1sec on a 5 sec decoding time at 100 fps means a drop of 16.66 fps, while losing 1 sec on a 5 sec decoding time at 50 fps means a drop of 8.33 fps.

Enabling a feature almost always add a constant time, not a proportionnal fps loss.

Also, do consider that incertitude on fps figures you're giving are at least 2 fps.right, i now ranked the decoders by the % by which the decoding speed decreases when an additional features is enabled

the ranking didnt change much, as most decoders perform in the same range (additionally there is the incertitude you mentioned)

Finally, what was the average quantizer of the clip you used ( out of curiosity, i think it might explain why ateme's decoder goes faster when deblocking -5 is enabled... ) the quants of the files are around 20

[bond]

almost forgot to mention: another interesting thing i found was that ffdshow and/or libavcodec seems to have gotten slower since the last test

and that altough celtic_druid made a pentium3 specific build, which should give faster results than the old ffdshow build i used the first time (without p3 specific stuff)

still the new ffdshow showed on not so few samples worse results than with the old version...

[bond]

ok i now added info about interlacing support of the decoders:

ateme, nero and elecard support fields-only, paff and mbaff (also with i8x8 of the high profile)
mainconcept theoretically does this too, but seems to be very buggy as it shows lots of artefacts with all modes

moonlight supports fields-only and paff (also with i8x8 of the high profile), but shows artefacts with paff too

videosoft supports fields-only

libavcodec doesnt support interlacing at all

[Beave]

Could you be interested in benchmarking some HD content? 720p in High Profile is not playable on my AMD64 3000+. I wonder if there is some filter fast enough for this.

[Manao]

There is. But teasing bond like that is a shame, since he only has a p3 866. But, of course, nothing prevents you from doing the test yourself.

[bond]

yep testing more and higher resolutions (i mainly tested D1) would be very interesting, but i am not the right one to talk to cause a pentium3 866mhz might not be representative at all for this

[Inventive Software]

There is. But teasing bond like that is a shame, since he only has a p3 866. But, of course, nothing prevents you from doing the test yourself.

Hey! I got a Celeron 800. I struggle to play H.264 DVD resolution content, let alone HD resolutions.

But yeah, like Manao said, there's nothing stopping you testing it yourself! :D

[Caroliano]

It's time to update libavcodec table for cqm also.

[Hyper Shinchan]

So there are still some guys with PIII class CPU??? I'm not the only one ? On my PC (PIII 1Ghz) AVC decoding is really a pain, I've noticed a faster playback with vlc and mplayer, but it's not good enough to be watched (it lost audio sync).... I'will try elecard's decoder.
P.S.: maybe I'm really a bad boy, but why don't you include QuickTime 7 too in your tests (maybe because it su##s?)?

[bond]

i will add the cqm test asap

but why don't you include QuickTime 7 too in your tests?because i dont know a method for testing apples decoders speed

[foxyshadis]

So there are still some guys with PIII class CPU??? I'm not the only one ? On my PC (PIII 1Ghz) AVC decoding is really a pain, I've noticed a faster playback with vlc and mplayer, but it's not good enough to be watched (it lost audio sync).... I'will try elecard's decoder.
P.S.: maybe I'm really a bad boy, but why don't you include QuickTime 7 too in your tests (maybe because it su##s?)?
Try muxing into a stricter container (I know mkv/ogm work, mp4 should), this will cause audio skips but at least sync is maintained, which is often more pleasing. Recompression is also a last-ditch solution.

Quicktime is consistently slower, also doesn't support high profile. (At least that's all I need to know. =p)

[Hyper Shinchan]

Try muxing into a stricter container (I know mkv/ogm work, mp4 should), this will cause audio skips but at least sync is maintained, which is often more pleasing. Recompression is also a last-ditch solution.
I use only mp4 for avc tests (avi sucks), actually I'm trying with the Elecard MPEG player.
Using main profile with cabac, 3 reference frame and 3 b-frame (and alpha and beta deblocking +3) it works with a little of audio delay, but without skipping the audio or video frame.
Now I've just made a little test without multiple reference frame and deblocking and 2 b-frame and it seems to work (but it was just 1:30 of video and audio).
Anyone can suggest safe PIII settings (of course I will continue testing tonight)?
Recompression is also a last-ditch solution.

What do you want to say? Recompression of avc video?
Quicktime is consistently slower, also doesn't support high profile. (At least that's all I need to know. =p)
I think that it doesn't support some high profile features, but anyway it's too slow, at least on Windows.

[redfordxx]

I am permanently confused reading here about Ateme vs Nero:
Is it same or different codec?

More over, it's written that it supports High Profile. I don't see any such options in Nero Recode

[Manao]

I'd say once more to use search feature, but that piece of information is a little bit harder to find that the other one. Anyway :
* nero uses ateme's encoder, from december 2004
* nero doesn't use ateme's decoder.
* both decoders support high profile
* ateme's encoder from december 2004 doesn't support high profile ( hence nero's too )

[redfordxx]

:thanks:

[CruNcher]

2 months past now should be time for a update ;)

[bond]

2 months past now should be time for a update ;)well i will redo the test once bigger changes to more than one decoder have been made (eg vss releasing 3.0 + new nero + more libav changes + who knows what else :D )

edit:
of course if some producer sends me an unlimited copy of a tool, i will be so happy about it i will test it right away ;)

[CruNcher]

The Greatest Game Ever Played Trailer
1920x1080p AVG 6 Mbit Max 22 Mbit (Main Profile)
Athlon 64 Venice 3000+ 1.8 GHz @ 2.4 GHz

32.03 ffdshow 21.11.05
31.27 nero 4.2.1.0
30.98 ateme 2.2.1.0

[redfordxx]

1920x1080p AVG 6 Mbit Max 22 Mbit (Main Profile)x264 or what?

[CruNcher]

http://trailer.nerodigital.com/eng/184.html <- this H.264 (AVC) Nero Sample

[ac-chan123]

Why is the MPEG4 Part 2 ASP encoded file always smaller than the H.264 encodec one(and which profile is used in the H.264 encodes)?

[bond]

The Greatest Game Ever Played Trailer
1920x1080p AVG 6 Mbit Max 22 Mbit (Main Profile)
Athlon 64 Venice 3000+ 1.8 GHz @ 2.4 GHz

32.03 ffdshow 21.11.05
31.27 nero 4.2.1.0
30.98 ateme 2.2.1.0wow interesting results! i thought the new nero is sooo fast?

[bobololo]

wow interesting results! i thought the new nero is sooo fast?

On the same clip, using the same filters (except for ffdshow which is 20051124). I got those figures on my P4 3 GHz with HT :

36.9 fps with nero
24.4 fps with ateme
22.7 fps with ffdshow

I did the measurements using Haali timeCodec application. The difference compared to CruNCher's results are due to multi-thread optimization of nero.

[bond]

On the same clip, using the same filters (except for ffdshow which is 20051124). I got those figures on my P4 3 GHz with HT :

36.9 fps with nero
24.4 fps with ateme
22.7 fps with ffdshow

I did the measurements using Haali timeCodec application. The difference compared to CruNCher's results are due to multi-thread optimization of nero.interesting, can you also test it without multithread?

and do you know what nero "multithreads" during decoding?

[Manao]

Well, since the clip in question has only one slice, it's the decoding process itself that is threaded. I would say that one thread decode the cabac and another make the MC / deblocking.

[tomos]

interesting, can you also test it without multithread?

and do you know what nero "multithreads" during decoding?
nero's codec is multithreaded? i'm trying it now to play back a clip i've made (1080p) and one core is maxed out on my 4400+ - i'm getting around 16fps on it. my 3800+ overclocked plays it fine (barely). same with ffdshow and libavcodec :(

[Manao]

Nero 7 is multithreaded, afaik.

[tomos]

thank you :goodpost:
was trying with v6 before. now working properly :)

cant use it in mplayer-c, have to use neros player to get it working for some reason

[bond]

cant use it in mplayer-c, have to use neros player to get it working for some reasonindeed, nero limits their decoder to only work in nero showtime

[tomos]

shame, its not a bad player, but mpC is better.

hopefully libavcodec will be multithreaded some day :) may keep on using x264 from now on, i found it nicer on hdtv material than divx - although a lot slower

[PicardGK]

I got those figures on my P4 3 GHz with HT :
36.9 fps with nero
24.4 fps with ateme
22.7 fps with ffdshow


Just for the record this nero result is probably false (see http://forum.doom9.org/showthread.php?p=764588#post764588 ).

Well, since the clip in question has only one slice, it's the decoding process itself that is threaded. I would say that one thread decode the cabac and another make the MC / deblocking.

Unlikely. Such huge inter communication between threads would be more pain. But non reference b-frames can be decoded in a different thread.

[ChronoReverse]

The Greatest Game Ever Played Trailer
1920x1080p AVG 6 Mbit Max 22 Mbit (Main Profile)


Athlon64 Winchester 3000+ @ 2.25GHz (250x9) ~3500+

VMR9
44.8 CoreAVC 0.0.0.3
28.3 ffdshow 21.12.05 GCC SSE2

[Inventive Software]

@Bond: Perhaps CoreAVC should be added to this, bearing in mind it can be played on your machine now. ;)

[Sagittaire]

First legend : "MPEG4 AVC is slow" ... and at this time MPEG4 AVC is faster than all the other codec with better quality.

Second legend : "MPEG4 AVC is hard to play".

why not general comparison with other codec:

MPEG4 ASP + FFDShow dec PP0 (default) and PP4
MPEG4 ASP + XviD dec PP0 (Default) and PP4
MPEG4 ASP + DivX dec PP0 and PP4 (Default)
VP7 + VP7 dec PP0 and PP2 (default)
VC-1 + DMO dec PP0 and PP4 (default)

IMO MPEG4 AVC + CoreAVC dec is faster than MPEG4 ASP + PP4 dec or VC-1 + PP4 dec

[berrinam]

IMO MPEG4 AVC + CoreAVC dec is fastest than MPEG4 ASP + PP4 dec or VC-1 + PP4 dec
You mean AVC with super-fast options, and ASP with slow options, like your other test? Sounds good.

[Sagittaire]

You mean AVC with super-fast options, and ASP with slow options, like your other test? Sounds good.

... lol

1) My speed encoding test all possible encoding setting for all codec (fastest and slowest setting for all codec) and fast encoding setting for AVC are by far very better for quality and speed than MPEG4 ASP slow setting. "Slow setting" for MPEG4 ASP here are not extreme setting but usual setting for all XviD/DivX user like default setting for XviD (ME6, VHQ1, Chroma, Trelli)

2) Use CoreAVC dec is not an "super-fast options" but just decoder choice and PP4 is default setting for DivX dec for example. Doom9 in this test use PP4 for all MPEG4 ASP dec ...

3)

MPEG4 ASP + FFDShow dec PP0 (default) and PP4
MPEG4 ASP + XviD dec PP0 (Default) and PP4
MPEG4 ASP + DivX dec PP0 and PP4 (Default)
VP7 + VP7 dec PP0 and PP2 (default)
VC-1 + DMO dec PP0 and PP4 (default)

MPEG4 ASP + FFDShow dec PP0 are slow options ?
VP7 + VP7 dec PP0 are slow options ?
VC-1 + DMO dec PP0 are slow options ?


For my Sempron MPEG4 AVC + CoreAVC (CABAC, High Profil, 16 ref and bref ... aka hardest setting for AVC decoding) is better for speed decoding than MPEG4 ASP (and without QPel or GMC ... aka not hardest option for ASP decoding) + PP4 ...

[bond]

actually i think i indeed will add an asp sample to the comparison, encoded with slowest settings possible and decoded with the fastest asp decoder (which is ffdshow afaik)

[IgorC]

Core AVC decoder has very high average speed. Faster than average ffdshow Xvid decoding PP4.
But it may be usefull to invistigate speed of the decoders in function of time.

I obtain some result with high-motion video :
1. Xvid ffdshow PP4 - approx. 70% of CPU usage
2. Core AVC decoder decoding x264 HP - average CPU was approx 50-55%.
But for example due to large number of ref. frames there were peaks of CPU usage (100%)

However I'm happy with a new Core AVC decoder :)

As a conclusion. Xvid had 70% of CPU usage but without 100% peaks.
Core AVC had higher decoding speed than FFdshow-Xvid speed but has some peaks on high motion due to long prediction (ref, weightb etc.).

As a result Core AVC has drop frame and/or not smooth playback.

[Manao]

Drop frame / speed low peaks are due to bitrate surge, and only to that. The decoding time spent in the picture processing ( interpolation, deblocking, weighted, mref ) is *roughly* constant, while decoding time for cabac is *totally* proportionnal to the bitrate, and the bitrate can vary a lot.

[IgorC]

ups. I had my doubt about it when thought about buffering in the RAM to avoid high bitrate peaks.

[Sharktooth]

CABAC eats CPU cycles almost proportionally to the bitrate...

[IgorC]

Yes. But in this case CABAC's performance depends more on fastness,size of RAM and BUS speed than on CPU.

[BetaBoy]

actually i think i indeed will add an asp sample to the comparison, encoded with slowest settings possible and decoded with the fastest asp decoder (which is ffdshow afaik)

bond.... i'll see once Toff has time for him to do a CoreASP DS port (I changed it from CoreMP4, as per your suggestion)... But we still need to add QPEL and GMC. You will find (like we have) that our ASP decoder is faster then any other ASP decoder atm. But its not fair outside of TCPMP till we get a DS filter so everyone can compare it.

[iceloki]

my cpu is a pentium3 866mhz

I think in nowadays most of the commercial codecs are optimized for Pentium4 (SSE2 enabled), SSE2 does improve the perfomance in a degree... So I think benchmark on a pentium4 is relative 'fair' ... ;)

[bond]

:search: devs have stated that sse2 is hardly useable for avc decoding (eg libavcodec doesnt use sse2 at all for avc decoding)

[IgorC]

Not sse2. But maybe isse. On Ateme HP encoder turned off isse CPU-instructions slowed down speed twice. Yes encoder and decoder are different things, but who knows...

[akupenguin]

isse = mmx2 = mmxext. And yes, ffmpeg and x264 make much use of it. Most dsp functions have only an mmx2 implementation, not mmx1. Because it's such a pain to write mmx without pavgb and pshufw...

[Hans Ohlo]

has anyone got the intervideo h264 decoder working?

i tried it in windvd and as an directshow filter, but i couldn't get a picture from it.

(plus is tried the new nvida drivers with h264 acceleration, but also nothing)

[bond]

the intervideo decoder is an old version of the videosoft decoder i have in my comparison already

the last windvd build i checked (7.0.27.172, i think from this feb) still had that old build from 2004, which surely doesnt support the nvidia gpu

so unless there is a new windvd version out with new decoder you cant use it with nvidia

[robU*4]

Bond, did you get a version of CoreAVC to test ? How does it compare to the rest of the test ?

[bond]

Bond, did you get a version of CoreAVC to test ? How does it compare to the rest of the test ?i havent found the time to do the comparison till now :B

also i am waiting for elecard, so i guess it will take some time till i update the comparison

[BetaBoy]

bond.... i'll see once Toff has time for him to do a CoreASP DS port (I changed it from CoreMP4, as per your suggestion)... But we still need to add QPEL and GMC. You will find (like we have) that our ASP decoder is faster then any other ASP decoder atm. But its not fair outside of TCPMP till we get a DS filter so everyone can compare it.
Not sure if I posted a followup... but QPEL and GMC were added to CoreASP in the TCPMP RC1 release... we however need to add Post Processing.

[SeeMoreDigital]

but QPEL and GMC were added to CoreASP in the TCPMP RC1 release... we however need to add Post Processing.May I test this please?


Cheers

[BetaBoy]

http://picard.exceed.hu/tcpmp/test/tcpmp.win32.0.72RC1.zip

[ChronoCross]

http://picard.exceed.hu/tcpmp/test/tcpmp.win32.0.72RC1.zip

Ihaveabugreport.thisversionseemstodisablethespacebarwhileitisopen

In case you couldn't read it: This version disables the spacebar while the program is open. Windows XP pro SP2.

[siddharthagandhi]

I have a relatively high end system what benefits would I see with a good decoder?

I have watched a lot of AVC content, and the decoder is probably Nero AVC or something like that (because I have Nero suite installed), and I haven't had any problems with playback.

Would there be a really good quality benefit, so good that I should go out and purchase CoreAVC? Because decoding speed isn't a problem, even at high bitrates (I have encoded at 16 mbps and played it back just fine).

[Avish]

Ihaveabugreport.thisversionseemstodisablethespacebarwhileitisopen

In case you couldn't read it: This version disables the spacebar while the program is open. Windows XP pro SP2.Its was there in previous version also, I reported this almost 2 weeks back http://forum.doom9.org/showthread.php?p=810623#post810623

[BetaBoy]

yeah... its in the bug tracker... thx

[siddharthagandhi]

Could someone answer my question about what benefits I would recieve from getting a specialized decoder on my high-end system?

[Caroliano]

A faster decoder use less CPU cycles. Then, if you want to run another process that needs a lot of CPU, you will have more cycles left to it, then it can be faster/better. Like if you want to encode while viewing a 1080p movie.

You will have no quality gain in the decoding, as all AVC decoders that are spec compilant produce the same quality. Of course, you can use the spare cycles to run Lanczos Resize instead of Bilinear, and other things like that, for improve quality in playback.

[siddharthagandhi]

Then that basically means I don't need it. I'm not just going to give out money unless I don't need to. I don't encode a lot. When encoding AVC at a bitrate of 16 mbps in Nero Recode I can watch the WMV HD 1080p trailers with no lag. So I doubt that an AVC file would overload my system.

[CruNcher]

And offcourse you will save energy on laptops and mobile devices for example longer battery life :)
and then Energy saving means less Temperature so your CPU will also last longer ;)

[siddharthagandhi]

I've got a good fan so I don't have to worry about that.

[IgorC]

Average CPU speed isn't that fast. And only with new CoreAVC decoder thousands of people were enable to play their H.264 DVD/HD videos.
Before even 3.2 ghz CPU wasn't enable to decode in real time HD 1080p. Today it's possible with CoreAVC.
And not everybody has 3.2 CPU.

Thousands people said their "Thank you" to CoreAVC devs.

[shon3i]

I have new Cyberlink H264 decoder from PowerDVD 7 but seems to be very slow decoder.

[Shinjite]

Yup, so far CoreAVC is still the fastest video decoder out there for h264

[Nick [D]vB]

If only it had MBAFF support.... :D

[BetaBoy]

Not sure if I stated our schedule... but unlike what I had stated earlier we are adding HE/LC/SBR support to CoreAAC v.2.0 now rather then later. This has effected our schedule somewhat but we are still on track to add MBAFF to CoreAVC Professional and Enterprise Editions soon after CorePlayer Mobile 1.0 and BetaPlayer GPL are released next month.

[Nick [D]vB]

Hello again,

Sorry to keep on about this but I’m going to give it one last shot. I appreciate you have set an internal development schedule according to your available resources and perceived demands of the marketplace but I just won’t to make sure you are fully aware of the current situation in the UK as I feel there is a potentially huge and, as of yet, untapped market for you here.

I’m sure you are aware the BBC have just started an HD trail across all platforms, it will show a wide range of programming but without question the biggest attraction will be the football World Cup which starts in just under a month. There has been a lot of media coverage of the trail and specifically the fact the major providers have massively underestimated demand for equipment that can receive it. Watch the short national News segments here for the background:

http://news.bbc.co.uk/1/hi/programmes/breakfast/4752017.stm

Basically the only cable provider offering the service, called TeleWest, is currently only available to a small number of homes in the UK. The other major player is $ky satellite, it has enough kit but is having trouble training enough installers in time, and now can not install any systems until after the World Cup has finished. :mad:

If I’m boarding you just bear with me a minute this next bit is crucially important. The BBC had also started a DVB-T trail which would let a large part of London receive the same HD programs through a normal TV aerial. BUT the BBC has chosen to run this as a closed trail [due to bandwidth limitations and other “political issues” with the regulator OfCom] and so has only supplied 500 set-top decoders! The service is FTA and unencrypted but there are no other commercially available AVC DVB-T decoders that can be used to watch the service. :confused:

Because of this a PC based solution seems to be the ONLY option for many people wanting to watch the World Cup in HD this summer, and there are plenty of them! In fact it would be hard to over-estimate the demand here at the moment, I know hundreds of people currently looking for a real-time MBAFF decoding solution in time for the World Cup. According to tests I’ve done with the Elecard and Cyberlink decoders they are just not able to provide acceptable performance even on ultra high-end dual core A64FX based system with ATI X1900’s [using GPU acceleration]. I don’t know about NVIDIA’s acceleration performance but most report it is not working with most products in the latest drivers.

I am sure if you are able to provide a solution in time for the Worlds Cup [even a fuctioning beta release] you would have a massive number of customers, but the timing is critical, with your current development schedule MBAFF support would not be available until well after the World Cup has stated, I don’t want to jinks the team but should England be knocked out of the tournament in the early stages a large part of this potential market would just evaporate over–night. Let’s just hope they are still hanging in there by the time you’ve got something ready! Well I’ve said my piece. I am not trying to tell you how to run your business; I just wanted to make sure you were fully aware of this opportunity. Keep up the good work guys – just go a bit faster… :D

Thanks,
Nick

[f@chance]

I add my penny/nickels worth of opinion. What makes it even worst is, that the Germans started broadcasting in HD since November and the Worldcup is being filmend and aired in Germany in HD. Now if you know even a bit about Brits and Germans than you know that there must not be a HD gap between them.

There is enough disposible cash in the UK that in the event of a semi final replay of the 1990 game between Germany and England, that they will go through any lenth to watch that in HD format, regardless of the cost. Businesses are heavily advertising for new Worldcup gear and the buzz is contagious.

In the last worldcup during the England, Argentina game business came to a grinding halt and traffic congested roads looked deserted.

Just my bit as a German, reared in the US and having lived for the last 10 years in London. For the UK there is no other important event then the Worldcup, esecially since it has been 40 years since they won it and every 4 years the press reports, this time we have a chance to win it.

[Doom9]

kick BBC where it hurts and demand a progressive signal. Interlacing is beyond outdated technology and there should be laws against producing such crap.
And we can consider ourselves lucky that they'll broadcast the whole thing in widescreen this time.. it has only been like half a decade since widescreen TVs started outselling 4:3 models.

[Sulik]

I disagree.
At the same bitrate, interlacing will produce better quality than progressive (assuming proper deinterlacing). It inherently has full vertical resolution when there is no motion, and half-resolution but double the frame rate with fast motion.

I do agree that things would be much simpler if everything was progressive, though.

[SeeMoreDigital]

kick BBC where it hurts and demand a progressive signal. Interlacing is beyond outdated technology and there should be laws against producing such crap.
And we can consider ourselves lucky that they'll broadcast the whole thing in widescreen this time.. it has only been like half a decade since widescreen TVs started outselling 4:3 models.At the present time, there's only a handful of TV channels being broadcast in HD via Sky-HD. All of which are encrypted. All of which appear to be favouring 1080i50 transmission protocol - So no 720p50 yet :scared:

If the BBC ever get around to broadcasting an full-time HDTV service via DVB-S2 (as apposed to their useless DVB-T trial service in London) they'll still be the only UK TV provider broadcasting in the clear.

Sadly, their AVC samples are just that, offering no clear indication as to whether 720p or 1080i will be used in the long term :(

[Wilbert]

And we can consider ourselves lucky that they'll broadcast the whole thing in widescreen this time.. it has only been like half a decade since widescreen TVs started outselling 4:3 models.
Over here they are morons. On one hand they broadcast it in HD, but on the other hand the analog broadcasting is not even in widescreen. The official reason is that people with normal TVs don't like the horizontal black bars nor a distorted image.

It's funny though. 9 out of every 10 people I know with a widescreen TV, prefer a distorted image over vertical black bars when watching fullscreen broadcasts :)

[Nick [D]vB]

Now if you know even a bit about Brits and Germans than you know that there must not be a HD gap between them.
LOL, leave me out it, I'm from Holland so me and Willbert are netural! :D

(as apposed to their useless DVB-T trial service in London)
Not that useless if you don't live in a cable area and can't put a dish up. I know lots of people in the area looking for a way to get the DVB-T trial. Remember Channel 4 / Flim4 and Channel 5 will be adding streams to the HD trial soon, they will be FTA on DVB-T but I'm pretty sure they'll have to be NDS encrytped on satellite?



BTW, have you noticed they are using 1440 X 1088 resolution? What's that all about? Any ideas why they're not using standard 1920 X 1088 [especially @20Mbps] ???

It's funny though. 9 out of every 10 people I know with a widescreen TV, prefer a distorted image over vertical black bars when watching fullscreen broadcasts

I'm not sure what that says about the Dutch, maybe if you have paid for the whole screen you should use it all! :D

[f@chance]

Just to add some additional information. Today was the first day of Sky HD installation and some users were pleasantly surprised others had a rude awakening.

http://news.bbc.co.uk/2/hi/entertainment/5003728.stm

Sky has delayed the installation of high-definition TV (HDTV) in 17,000 homes because it's supplier has failed to deliver enough set-top boxes.

Anyone requesting installation on Monday, launch day, will be told that they must wait until early August, meaning they will miss the World Cup - which begins on 9 June - in HD.

What can I say there are a host of Londoners that have their eyes peeled on CoreAVC with MBAFF. For some it will be let the games begin for others it will be lets head to the pub.

[dimzon]

Just suggestion
Why CoreAVC doesn't included in test? Maybe it's time to update
I strongly prefer to vie results graph first (before preparation/explanation)

[Nil Einne]

Am I right that CoreAVC is faster then with Nvidia's PureVideo or any other codecs which support Nvidia's hardware acceleration (if there are any other codecs)? I've seem some reports but they weren't particularly clear. And this is also true for ATI's AVIVO?

If so, it'll be interesting to see how CoreAVC Pro performs when it has support for GPU acceleration.

[Ice =A=]

@Nil Einne:
Have a look here (http://www.behardware.com/news/8117/coreavc-stronger-than-avivo-purevideo.html)! (This has allready been posted somewhere in this forum by the way.)
Short summary: CoreAVC is very fast, fastest software decoder by far, however at the moment (!) there is one combination which is a little faster, nameley PowerDVD with an nVidia card.

[Nil Einne]

Actually, although I didn't search, I did come across this independently although I just skimmed through it. It was why I thought CoreAVC was better then the rest even with hardware acceleration. However even the article itself admits that it isn't that good a test. Specificially "To finish, we need to emphasize that it is a just a preview based on trailers". Also no clear mention of the methodology for measuing CPU utilisation and for that matter whether they repeated their results. I admit, I'm always very skeptical when I see tests that don't (to me) explain how whatever they were measuing was measured and whether they attempts to account for variation due to other factors.

It would be interesting to see a mode detailed test akin to what was done by bond. Also, it would be good to see a test with any released & easily available versions of codecs, even if these are designed for Nvidia or ATI.

But actually now that I look more carefully, I realised in fact you're right. With the Cyberlink codec and 7900GTX (and therefore, probably the 6600GT which I have since I believe the difference between the H.264 acceleration part is minimal, or am I wrong?) is better then the CoreAVC, although this is not with CoreAVC 1.1 of course. Cyberlink's acceleration engine is clearly done much better then the Nero one and of course CoreAVC beats them hands down in pure software. So I guess I reach the same conclusion. It'll be interesting to see what they can do with GPU acceleration and for that matter what the others can do to catch up. Especially the open source guys...

[foxyshadis]

The AVC decoding speed strongly depends on the overall speed of the card as well, both cpu and memory. (6800 is broken, but 6600 is not.) 7900GTX gives a large boost in decoding speeds, or rather, how high a resolution and how much extra you can make it do. So someone else's benchmarks aren't of much use to you unless you have the same card and processor.

Of course, benchmarks are always welcome if you can come up with a good one.

[Revgen]

@Nil Einne:
Have a look here (http://www.behardware.com/news/8117/coreavc-stronger-than-avivo-purevideo.html)! (This has allready been posted somewhere in this forum by the way.)
Short summary: CoreAVC is very fast, fastest software decoder by far, however at the moment (!) there is one combination which is a little faster, nameley PowerDVD with an nVidia card.

CoreAVC will have GPU acceleration in the future and I'm pretty sure it'll beat whatever Cyberlink has.

[Ice =A=]

Very little doubt about that! :)

@foxyshadis:
I'm also very sceptical about someone elses benchmarks (in Germany we have a saying: Only believe in a statistics if you have faked it yourself...), but it seems that's all we've got at the moment.

[CruNcher]

cheating would bring them nothing Ice =A= everyone can check those results and if they were faked, we would allready knew it (and the whole internet) :)

[Nil Einne]

It's not so much cheating, but sloppy benchmarking. For example, so often benchmarkers don't bother to run any repetitions and only test one or two things. Then they say, we have proven XYZ and I say bullshit you haven't shown shit.

From my own benchmarking I've seen sometimes results can be fairly variable. Whenever I'm actually comparing something I always take averages and do standard deviation. It's stupid to claim there is a difference if the difference is well within normal variation.

It's also a bit of a fallacy to assume that cheating or sloppy benchmarking will always be detected. So far, I haven't seen any other public benchmarks comparing with and without GPU. Of course, I'm not saying others haven't run private benchmarks which concured with the published results so they didn't say anything however we have to reason to assume people have. (Looking at science should give you a clue. The standards here are a lot higher then with benchmarking and benchmarkers but people still get away with cheating and sloppy work. Of course, it is usually a lot hard to repeat a scientific experiment of some kind then a benchmark and there is possibly a smaller base doing it but it does show the fallacy of assuming something will be detected. Eternal vigilance and caution is always in order especially when only one site has published a result)

I'm aware Core are developing hardware acceleration support and I'm sure it'll beat the hell out of what others have used however this still doesn't answer the question of whether GPU accelerated Cyberlink or whatever is faster then non-GPU accelerated CoreAVC. Obviously it'll depend on what your precise specifications are and what file your using and indeed that was one of the points I was making.

But with quality benchmarking which IMHO should include multiple variables (different GPUs, different CPUs etc) you can get a very good idea even without benchmarking yourself. BTW, there are actually 3 issues here. One is which one uses less CPU. Another one is which one is faster (this is not the same thing as less CPU when the GPU is involved). Finally power usage is also another issue which many will be interested in. Generally speaking the first one matters most. If your decoding something for realtime playback, provided your decoder can keep up you usually don't care how fast your decoder can decode. Lower CPU usage however might matter if you have background tasks that will either use or might use your CPU (e.g. on a PVR). GPU usage is generally not so important although with ATI's stream for folding@home I guess some people will care. However CPU usage is very tricky to properly benchmark (whereas decoding time is generally a lot easier).

Power usage is the dark horse here. Some people will care a lot, some not at all and some in between. However power usage is one thing that has so many variables that IMHO it is very difficult to reliably benchmark unless there is a large difference.

N.B. I'm not intending to offend any benchmarkers. I'm just airing my POV. Also, I primarily rant about benchmarks published on websites and I'm mainly talking about comparing CPUs, GPUs, fans and all that kind of stuff rather then comparing codecs although the same principles apply.

P.S. To be honest I don't really care that much either way. It was just something that I was wondering at one stage so decided to check it out. My PVR has a Radeon 9000 so no GPU acceleration and my 6600GT is on my A64 2.4ghz which is fast enough for my needs that it doesn't really matter. I don't use HD and in fact I've only ever looked at 1 or 2 h.264 videos (with VLC...). In fact I'm more interested whether the open source guys can respond to this challenge then anything else but thats a different issue.

[Hans Ohlo]

one thought i have at the moment: shouldn't every h264 decoder output a bitperfect identical picture as requested by the spec? it seems not so, because every decoder i tested shows other characteristics: cyberlink is a bit unsharp, coreavc has big problems decoding 1080paff streams (restless picture, broken horizontal lines, color level bug), mainconcept seems ok but seems unsharp against ffdshow...

how comes all this? and what decoder is nearest to the spec?

[KoD]

Well, you have the h264 reference decoder (JM (http://iphome.hhi.de/suehring/tml/)). Compare the frames with what that one outputs. It's an app that you have to compile yourself and it's obviously not meant for real-time playback.

[BetaBoy]

coreavc has big problems decoding 1080paff streams (restless picture, broken horizontal lines, color level bug)The next release fixes all of the known issue such as you describe. As far as being compliant... outside of the JM reference I would say CoreAVC and the Ateme decoders are the most precise... but take that with a grain of salt.

[ViRGE]

So I've been reading through this thread and it seems rather dated, so I hope someone doesn't mind my noobish questions.

I have a Radeon X1900XTX and I'm looking to find a nice H.264 decoder to use with it that supports GPU-accelerated decoding. I've noticed that there's a specific combination that seems to be recommended for GeForce users, but I haven't seen such a thing for Radeon users. Is there any 1 setup that's better than all others? I'm not aware of any codecs besides those from Cyberlink and Intervideo supporting GPU-acceleration at this time(am I missing anything?), so this seems to be a one-or-the-other thing.

Also, how well do the above support non-commercial content? I'm asking mainly so I can play stuff encoded with x264, which seems to be the popular choice for non-commercial stuff. I suppose in the same vein, do both work as DirectShow codecs so that I can use them with Media Player Classic?

[Atak_Snajpera]

I would be very happy if libavcodec started to use multi-cores to decode h264. Even my overclocked C2D E6300@2,8ghz is too slow to decode 1080p@25fps (15mbit/s). Friend of mine has C2D@3,6ghz so we will check if is fast enough... :)

[Theliel]

umm you are sure?? with latest ffdshow I can play h264 1080p perfectly with my old P4 3.4 HT, and the CPU load are about 70% max 40% min.

[Atak_Snajpera]

Your cpu maybe old but still has higher clock (21% faster). libavcodec is optimized (I assume) for vector units like SSE and SSE2. SSE unit is able to add 4 single precision floating-point numbers (32bit) using only one clock (SSE2 - 2 double precision ). This simple example shows that if you have higher clock you can have higher MFLOP rating. BTW check my screenshot

http://img359.imageshack.us/img359/7876/xmen3ji6.th.jpg (http://img359.imageshack.us/my.php?image=xmen3ji6.jpg)

[foxyshadis]

Bitrate is more important than resolution. 1080p @ 1.5Mbps is vastly much easier to decode than 1080p @ 15Mbps. Try a little of the latter and see if your P4 chokes.

btw, mflop doesn't matter for video, integer performance is what constrains it (when memory speed etc is ignored). Even if it did, it still depends on what you're talking about; a single Conroe core has a lower mflop rating for x87, but higher for floating-point SSE2, which executes twice the speed per clock of P4.

[KornX]

has sb tested nvidia purevideo HD?

KornX

[CruNcher]

intensively on the Geforce 7 yes for Mpeg-2, H.264 and not so intense for VC-1 Playback, also in terms of Visual Quality of the Motion (Pixel) Adaptive Deinterlacer by Nvidia (not every Driver release gives good performance here) but the Architecture of the new Forceware 100 series driver is not the same anymore then the old 95/96/97 releases internaly it has changed for the Geforce 8 you can use it for 3D on the Geforce 7 but Video (PureVideo SD/HD) quality is not as good as with the Geforce 7 Driver (at least under XP maybe that changes in July when Purevideo is gonna work for XP on the Geforce 8 then) for Geforce 7 based cards (Motion Adaptive Deinterlacing doesn't work anymore with the Forceware 100 series Driver on Geforce 7 cards currently under XP not tested under Vista, so beaware).

[SoreGums]

So does the CoreAVC codec work under Vista?

I've paid for it but since upgrading to Vista I haven't been able to install it due to it being activated... They don't reply to emails either which sucks since you have to pay real money for this thing...

I've installed the Vista codec (v444) pack and ffdhow is installed and taking care of x264 but the playback is not very smooth at all.
Turned PostProcessing off and that helped but its still not smooth when lots is happening in the frame.

Should I just buy PowerDVD?

[BetaBoy]

Visit http://support.corecodec.com and submit a support ticket and the staff will reset your account to allow the upgrade.

[SoreGums]

Visit http://support.corecodec.com and submit a support ticket and the staff will reset your account to allow the upgrade.
I've tried doing that - but it just says invalid login/password . . . . - So I went back to the email and never got a response.
Same username as here

[cyberloner]

does anyone here can really use hardware to decode with dxva to play video such as (h264 / vc1/ qt mov) or bluray / hddvd
powerdvd ultra or what ever codec maybe?
i try all failure.. even with latest powerdvd ultra patch....

[BetaBoy]

I've tried doing that - but it just says invalid login/password . . . . - So I went back to the email and never got a response.
Same username as here

Your support account is diff then the registered account, so you need to register to submit a ticket. We are migrating to OpenID later this year for all our sites/services. Till then its a seperate process for each service (purchase, support, etc.).

[land]

Hi, I think it will so interesting a new test with the new versions of the h264 decoders.
One similar to the firt post in this thread.
The decoders could be Ateme, livacodec, elecard, moonlight, mainconcept, VSS H264 and maybe quicktime.
I would like to know the sopported options of each one and its speed.
I don't know how to do the test, that's why I write this post.
Is someone interested in do it?

[Dark Shikari]

Hi, I think it will so interesting a new test with the new versions of the h264 decoders.
One similar to the firt post in this thread.
The decoders could be Ateme, livacodec, elecard, moonlight, mainconcept, VSS H264 and maybe quicktime.
I would like to know the sopported options of each one and its speed.
I don't know how to do the test, that's why I write this post.
Is someone interested in do it?
Use TimeCodec. And make sure you get the latest FFDShow-Tryouts--I hear someone got some multithreaded decoding support for H.264 in it.

[Sagekilla]

Use TimeCodec. And make sure you get the latest FFDShow-Tryouts--I hear someone got some multithreaded decoding support for H.264 in it.

IIRC, Aku said it worked on a per-slice basis and not per-frame, and since x264 doesn't encode videos on a per slice basis it receives no benefits. It was something like that, I'm a bit fuzzy on details but Aku basically said ffdshow won't offer multithreaded acceleration for the newer x264 videos.

[Dark Shikari]

IIRC, Aku said it worked on a per-slice basis and not per-frame, and since x264 doesn't encode videos on a per slice basis it receives no benefits. It was something like that, I'm a bit fuzzy on details but Aku basically said ffdshow won't offer multithreaded acceleration for the newer x264 videos.I also heard (IIRC) there was some work after the slice-based parallelism that added some non-slice-based support--its all experimental of course.

[Manao]

Its all experimental of course.It was a patch allowing the threading of the bitstream decoding in parallel of frame reconstruction & deblocking. It was working only for non-mbaff videos, and I don't think the patch can be cleanly applied now that PAff has been implemented.

But there seems to be some work on frame level parallelism.

[COOL-GOOD]

:goodpost:Ateme MPEG-4 AVC H.264 Encoder PC Suite

i believed that a program "Ateme MPEG-4 AVC H.264 Encoder PC Suite" is good nothing like for Video Converter after the experiment of many of other programs...

> MPEG-4 AVC / H.264 Baseline, Main, High Profile
> From QCIF to Full HD 1080i
> Advanced audio codecs
> Up to 7 audio tracks encoding
> DVB subtitles and DVB Teletext
> Professional pre-processing
> Batch processing and job manager
> Both SD and HD full support in the same product
> Reduce bitrate up to 50% compared to MPEG-2 and preserve the same high quality
> Optimized architecture for multi-processor platforms to achieve real-time encoding
> Easy automation to run 24/7 processes
> Fully interoperable with major Set Top Boxes and VOD platforms
--------------------------
VIDEO ENCODERS

> H.264 BP and MP
> MPEG-4 SP
> JPEG/MJPEG

VIDEO DECODERS

> H.264 BP & MP
> MPEG-4 SP & ASP
> Xvid & similar codecs
> MPEG-2 MP@ML
> WMV/ VC1
> JPEG/MJPEG
> Enhanced JPEG for Consumer Electronics aaplications
AUDIO COMPRESSION

AUDIO ENCODERS

> MP3
> AAC
> MPEG-1 Layer 2
> ADPMC

AUDIO DECODERS

> AAC LC & HE
> AC3
> MP3
> WMA
> ADPMC
PRE-/POST-PROCESSING

> Resizer
> De-interlacer
> Dithering
> RGB/YUV conversion
TOOLS

> Streaming protocols
> File reader/writer
> A/V Sync
For more informations:
http://www.ateme.com/TEC_codecs.php

@edit by admin: Pirated tools have no place on this board.

[Sagekilla]

I also heard (IIRC) there was some work after the slice-based parallelism that added some non-slice-based support--its all experimental of course.

Shame.. I'd (And I imagine quite a lot of people) love to see a multithreaded decoder that could take advantage of my dual core processor. Until then, CoreAVC is doing a magnificent job at decoding even 1080p video.

[Fraeon Lux]

Shame.. I'd (And I imagine quite a lot of people) love to see a multithreaded decoder that could take advantage of my dual core processor. Until then, CoreAVC is doing a magnificent job at decoding even 1080p video.

Isn't CoreAVC Pro capable of using your dual core processors? Or is that just marketing BS they profess on their home page?

[Dark Shikari]

Isn't CoreAVC Pro capable of using your dual core processors?Yes, CoreAVC has frame-level parallelism.

[Sagekilla]

When was frame level parallelism added? I guess that explains why I can decode 1080p without a problem.

[foxyshadis]

Between the first public release and the next non-public beta release, before 1.0. Or if you mean ffdshow, the patch for cabac parallelism was applied a week or two ago, but it's not full decoding threading.

[iwod]

Any update to the decoder comparison?

Would be nice to see how everything new stack up including new libav and corecodec.

[shita]

I'm looking for some H.264 Decoder Open Source.
Can you help me some address ?
Thanks so much.

[_xxl]

http://ffmpeg.mplayerhq.hu/
http://forum.doom9.org/showthread.php?t=120465

[iwod]

Does anyone know of any site where they have information on which part of the decoding in H.264 takes how many percentage of time.

Example, Like during the decoding pipeline, How many % of time is used to decode CABAC ?

[Dark Shikari]

Does anyone know of any site where they have information on which part of the decoding in H.264 takes how many percentage of time.

Example, Like during the decoding pipeline, How many % of time is used to decode CABAC ?Outdated (http://akuvian.org/src/x264/ffh264_oprofile.txt), but still somewhat accurate. MC cost is lower now.

It also depends heavily on bitrate; CABAC decoding cost, for example, is linearly proportional to bitrate.

[Caroliano]

Another one, also probably outdated, but in an form easier to understand for dummies: http://forum.doom9.org/showthread.php?t=99131

[Dark Shikari]

Another one, also probably outdated, but in an form easier to understand for dummies: http://forum.doom9.org/showthread.php?t=99131A lot of that seems really misleading--you can't enable p4x4 without p8x8 for example, so his p4x4 was actually a test with p8x8 off period.

[Mr VacBob]

CABAC is much faster in libavcodec with the assembly/CMOV reader enabled, which is newer than either of those profiles. I'm not sure if ffdshow uses it or not, but it might not.

[schweinsz]

When was frame level parallelism added? I guess that explains why I can decode 1080p without a problem.
frame level parallelism is useless if all frames are referenced.

[Dark Shikari]

frame level parallelism is useless if all frames are referenced.Incorrect.

[schweinsz]

Incorrect.
Could you explain it? If the current-decoding frame is referenced by the next-decode frame always, is frame-level parallelism useless?

[Dark Shikari]

Could you explain it? If the current-decoding frame is referenced by the next-decode frame always, is frame-level parallelism useless?sliceless threads (http://akuvian.org/src/x264/sliceless_threads.txt)

[P.J]

Please test Cyberlink H.264 Decoder and integrated ATI/NVIDIA DxVA decoder !

[refulgentis]

what happened to multithreaded decoding in ffmpeg for H.264? I haven't seen any mention of it in commits or the developers list for the past couple months, but it looks like astrange has been steadily making commits to the ffmpeg-soc repository

[Cyber-Mav]

new divx h264 decoder is now considered to be the fastest software based decoder for h264 content. it is around 5-7% faster than coreavc.

[nm]

Though CoreAVC is faster on old CPUs with slow/no SSE2 units.

[BetaBoy]

new divx h264 decoder is now considered to be the fastest software based decoder for h264 content. it is around 5-7% faster than coreavc.

Cyber-Mav... you know better... Post facts not opinions..... we have already discussed this on D9 that the DivX decoder is ONLY faster when utilizing instructions sets for certain CPU's. Otherwise CoreAVC is still the fastest. Go to both the CoreAVC and DivX threads if you want more details.

[Cyber-Mav]

yea i forgot to mention that. the tests i saw were done on a e8400 so it has sse4 which could have helped out divx.

[RonaldoSan]

I wanted to compare CoreAVC to the build-in decoder in Windows 7, to see which is best used for encoding (quality).

Exact same 1001 frames and x264 settings (crf18, faster preset, film tune).

CoreAVC Graph

http://i25.tinypic.com/33m1y88.jpg

CoreAVC Encode

avis [info]: 1920x1080 @ 23.98 fps (1001 frames)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2
x264 [info]: profile High, level 4.1
mp4 [info]: initial delay 104271 (scale 2500000)
x264 [info]: frame I:8 Avg QP:14.40 size:251091
x264 [info]: frame P:257 Avg QP:19.28 size: 69794
x264 [info]: frame B:736 Avg QP:20.05 size: 42684
x264 [info]: consecutive B-frames: 0.6% 1.2% 1.5% 96.7%
x264 [info]: mb I I16..4: 21.4% 43.8% 34.8%
x264 [info]: mb P I16..4: 0.6% 2.9% 1.2% P16..4: 33.2% 19.2% 14.7% 0.0% 0.0% skip:28.1%
x264 [info]: mb B I16..4: 6.4% 12.3% 0.5% B16..8: 18.5% 1.6% 1.2% direct:16.1% skip:43.3% L0:39.3% L1:29.1% BI:31.6%
x264 [info]: 8x8 transform intra:62.9% inter:45.0%
x264 [info]: coded y,uvDC,uvAC intra:81.9% 90.8% 53.6% inter:28.8% 34.9% 4.3%
x264 [info]: ref P L0 66.2% 19.5% 14.2%
x264 [info]: ref B L0 79.8% 20.2%
x264 [info]: kb/s:9841.6

encoded 1001 frames, 12.60 fps, 9842.43 kb/s

Windows 7 Graph

http://i27.tinypic.com/2uel1qc.jpg

Windows 7 Encode

avis [info]: 1920x1080 @ 23.98 fps (1001 frames)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2
x264 [info]: profile High, level 4.1
mp4 [info]: initial delay 104271 (scale 2500000)
x264 [info]: frame I:8 Avg QP:14.40 size:257389
x264 [info]: frame P:257 Avg QP:19.30 size: 71213
x264 [info]: frame B:736 Avg QP:20.08 size: 43335
x264 [info]: consecutive B-frames: 0.6% 1.2% 1.5% 96.7%
x264 [info]: mb I I16..4: 22.6% 45.2% 32.1%
x264 [info]: mb P I16..4: 0.6% 3.1% 1.3% P16..4: 33.4% 19.4% 14.8% 0.0% 0.0% skip:27.3%
x264 [info]: mb B I16..4: 6.5% 12.4% 0.5% B16..8: 18.8% 1.6% 1.3% direct:16.3% skip:42.7% L0:39.3% L1:29.2% BI:31.5%
x264 [info]: 8x8 transform intra:62.9% inter:45.0%
x264 [info]: coded y,uvDC,uvAC intra:82.1% 90.8% 54.0% inter:29.2% 35.4% 4.4%
x264 [info]: ref P L0 66.4% 19.5% 14.1%
x264 [info]: ref B L0 79.9% 20.1%
x264 [info]: kb/s:10013.0

encoded 1001 frames, 12.00 fps, 10013.75 kb/s

x264 uses more bitrate for the Windows 7 encode, so would it be fair to conclude that it decodes with superior detail?

[Dark Shikari]

All H.264 decoders give identical output.

[RonaldoSan]

All H.264 decoders give identical output.
Okay, but would it not be possible for the decoders to give a different output if filters are applied or levels are changed?

Either way, unless I made a mistake, the Microsoft decoder would be slightly preferable given the slightly higher bitrate?

[Dark Shikari]

Okay, but would it not be possible for the decoders to give a different output if filters are applied or levels are changed?

Either way, unless I made a mistakeSince all decoders must give identical output, you clearly must have made a mistake.

[RonaldoSan]

Since all decoders must give identical output, you clearly must have made a mistake.
Okay. Thank you for your help.

[BetaBoy]

Wow and a Thank you!

[Cyber-Mav]

Cyber-Mav... you know better... Post facts not opinions..... we have already discussed this on D9 that the DivX decoder is ONLY faster when utilizing instructions sets for certain CPU's. Otherwise CoreAVC is still the fastest. Go to both the CoreAVC and DivX threads if you want more details.

new version of divx seems to be even more faster now for me and it also has 64bit support. dixv runs faster for me on my q9550 cpu when decoding 1080p h264 content. i will test later on the new version of divx and see if its any quicker on my laptop. i have a feeling that this new divx is gonna be quicker on my dothan processor too.

[dimitrik]

All H.264 decoders give identical output.

Jumping in late with a question here. As I understand it, since all decoders give bit identical output, they must all be equal in "image quality" (however that is defined) but may differ in efficiency i.e. resource usage, speed etc.

My questions stems from the fact that when I experimented with ffdshow using libavcodec and ffmpeg-mt, I noticed that ffmpeg-mt gave slightly inferior image quality to libavcodec (certainly there was a visible difference).

The difference was not huge but it was too clear to be a subjective impression. This was about 3-4 months ago, so obviously ffdshow has changed several versions since, so it may no longer be the case.

Did you ever experience anything similar in your tests, or are you aware of some difference that may explain this? Could it be that ffmpeg-mt, being experimental is not fully compliant and hence does not give bit identical output?

[Dark Shikari]

Jumping in late with a question here. As I understand it, since all decoders give bit identical output, they must all be equal in "image quality" (however that is defined) but may differ in efficiency i.e. resource usage, speed etc.

My questions stems from the fact that when I experimented with ffdshow using libavcodec and ffmpeg-mt, I noticed that ffmpeg-mt gave slightly inferior image quality to libavcodec (certainly there was a visible difference).

The difference was not huge but it was too clear to be a subjective impression. This was about 3-4 months ago, so obviously ffdshow has changed several versions since, so it may no longer be the case.

Did you ever experience anything similar in your tests, or are you aware of some difference that may explain this? Could it be that ffmpeg-mt, being experimental is not fully compliant and hence does not give bit identical output?ffmpeg-mt is libavcodec. If there was a bug that resulted in non-compliance, it would generally be rather obvious (e.g. tons of blocking).

[dimitrik]

ffmpeg-mt is libavcodec. If there was a bug that resulted in non-compliance, it would generally be rather obvious (e.g. tons of blocking).

OK, pardon my ignorance here, but ffdshow allows me to choose using either libavcodec or ffmpeg-mt, meaning they cannot be the same.

In fact the difference is CPU use, and IIRC, this difference in image output I noticed (which was definitely not bad as tons of blocking, but was clear enough to the naked eye, mostly grainyness I think).

I suspect when you say they are the same you mean they are the same codec, differently implemented, but from a user perspective, you can choose one or the other and from what I saw the difference in picture reproduction was clear. I'm not keen to re-install the old version to try it again though:p

[JEEB]

OK, pardon my ignorance here, but ffdshow allows me to choose using either libavcodec or ffmpeg-mt, meaning they cannot be the same.

Same codebase is used, just that "ffmpeg-mt" means multithreaded decoding, which means that not only one of your cores gets used in decoding.

Also, using ffmpeg-mt here on several things (Kovensky's mplayer builds and CCCP's ffdshow), but still have yet to have seen any "grainyness".

[nm]

I suspect when you say they are the same you mean they are the same codec, differently implemented, but from a user perspective, you can choose one or the other and from what I saw the difference in picture reproduction was clear. I'm not keen to re-install the old version to try it again though:p
I don't use ffdshow, but can't you switch between "ffmpeg-mt" and libavcodec on the fly?

Anyway, you'll need to post screenshots and a sample video that exhibits this to make us believe. I suspect that you had in-loop deblocking disabled or you used different post-processing filters if there really was such a difference.

[dimitrik]

I don't use ffdshow, but can't you switch between "ffmpeg-mt" and libavcodec on the fly?

Anyway, you'll need to post screenshots and a sample video that exhibits this to make us believe. I suspect that you had in-loop deblocking disabled or you used different post-processing filters if there really was such a difference.

You can't switch deocders on the fly, you have to unload and reload the filters, i.e. terminate and restart the application.

I did some tests this week and I found no difference in image quality. I'm pretty sure when I tested them las time I did not use postprocessing filters. It it possible that I had inloop deblocking enabled but it would have been the same for both decoders.
I can't explain it except to say that it was several versions ago and that I would swear there was a visible difference. Since its no longer the case though, it's a moot point. Call me crazy, I don't mind:)


Same codebase is used, just that "ffmpeg-mt" means multithreaded decoding, which means that not only one of your cores gets used in decoding.

Also, using ffmpeg-mt here on several things (Kovensky's mplayer builds and CCCP's ffdshow), but still have yet to have seen any "grainyness".

You can set ffdshow to run several decoding threads from "decoder options" so it uses all the cores. Not quite as evenly balanced as with ffmpeg-mt but the difference is actualy pretty small in terms of multicore decoding.

Slightly OT, but for anyone interested in the difference in performance, using libavcodec with 4 decoding threads on my brief test, tended to load one core slightly more than the mt decoder (I left ffdshow configured for 4 threads).
The difference was about 10% i.e. 3 cores had ~35% CPU use, while one had ~45%. With the mt, they all had about ~40%.

It made no visible difference, except when I created an unusually heavy load: upscaling 720p to 1080p with lanzocs, RGB32 coversion, postprocessing enabled with fast spp deblocking. With the x64 version of libavcodec, there was video delay on an Intel Quad 2.26GHz while ffmpeg-mt was fine. The x86 decoders had no problem either way.

So from now on I'm using ffmpeg-mt on my HTPC.

[nurbs]

It it possible that I had inloop deblocking enabled but it would have been the same for both decoders.
You should never disable inloop deblocking in the decoder. That can get very ugly (http://forum.doom9.org/showthread.php?p=1184258#post1184258).

[nm]

You can set ffdshow to run several decoding threads from "decoder options" so it uses all the cores. Not quite as evenly balanced as with ffmpeg-mt but the difference is actualy pretty small in terms of multicore decoding.
The difference can be large depending on the decoded stream and number of CPU cores. Libavcodec's slice-based parallelization doesn't work on H.264 streams that only have one slice.

[dimitrik]

That's useful info, thank you both.

[tal.aloni]

ffmpeg-mt is libavcodec. If there was a bug that resulted in non-compliance, it would generally be rather obvious (e.g. tons of blocking).

just to clear dimitrik's name:
there was such a bug with one of the old ffmpeg-mt releases, it has been fixed long time ago.

[dimitrik]

Hey, thanks. See? I was innocent all along your honor!

[xv]

Hi,
also this thread is sticky, it´s information is completly outdated. It would be nice if the comparison in the first post could be updated, new fields added (yuv 4:2:2, 4:4:4 decoding, 9/10 Bit..., old lossless supported, new lossless supported) and new decoders added (CoreAVC, DiAVC, Microsoft, DivX, Nvidia VPx)
Thanks

[CeeJay.dk]

Blue_misfit did some testing back in July last year and found that ffmpeg-mt is the fastest decoder now (http://forum.doom9.org/showthread.php?t=155441).

I did my own tests back then, as I needed to find a way to get two old P4 2.0 and 2.2 ghz systems to play 720P and 1080P, and came to the same conclusion.
ffmpeg-mt was the fastest decoder for me for most files but on a few CoreAVC seemed slightly faster.

On my cpu limited systems though, the fastest (usable) option was to use VLC and setting "Skip H.264 in-loop deblocking filter" to Non-key.
This was always faster than CoreAVCs "Deblocking : Skip when safe" option.
Of course the fastest option was to disable all deblocking, but that absolutely destroys the quality, and is unwatchable, so I chose VLC and skipping the deblocking of the Non-key frames, as I couldn't really tell the difference in quality between that and deblocking all the frames.

[crouserali]

Hello to every one
I need help in finding the new developments made to the H.264, can any onehelp me?
and what is the referance software used for such development?
best regards.

pleas send me an email to:
mohammed.ali.82@gmail.com

[PCU]

Where I can find the latest comparison?