x264 CLI vs. commercial speeds

[Anakunda]

HI !
I have done test run of x264 commerial implemented in TMPGenc Authoring Works(TAW) with GPU versions, to find if they perform same way both for speed and quality. To my surprise TAW did encode the same video in about a half time as the GPU version :confused:, while I used the same settings for both tests, as for speed preset. As for tune, this is not possible to set in TAW so may be this could do the difference?
Anyway I would be interested in more detailed comparison of both x264 implementations, among others if absence of tune presets and other advanced settings in TAW can harm the resulting video quality.

[nm]

To my surprise TAW did encode the same video in about a half time as the GPU version :confused:

If you used x264 for encoding in both versions, I guess it used the GPU for decoding and filtering, thus giving x264 a higher share of CPU time. The x264 implementation itself should be exactly the same in both versions.

There may also be artificial limits and bugs that reduce the overall speed more than one would expect in the non-GPU version.

[Anakunda]

If you used x264 for encoding in both versions, I guess it used the GPU for decoding and filtering, thus giving x264 a higher share of CPU time. The x264 implementation itself should be exactly the same in both versions.

There may also be artificial limits and bugs that reduce the overall speed more than one would expect in the non-GPU version.

In short the commercial version without any fine tuning gives at higher speed at least as good results as GPL version?

[nm]

In short the commercial version without any fine tuning gives at higher speed at least as good results as GPL version?

So you were comparing x264 CLI against x264 in TMPGEnc? I got the impression that it was TMPGEnc GPU against TMPGEnc CPU. However, my point applies to this case too. I doubt they have made any changes to x264 core, so it should give results similar to the GPL version. Any speed difference in favor to TMPGEnc is either due to different encoding settings or GPU decoding/filtering.

You need to check the output file for the settings that TMPGEnc is using and then use the same settings with x264 CLI. Use Mediainfo to read the settings SEI message from the video.

[Anakunda]

So you were comparing x264 CLI against x264 in TMPGEnc?

Yes I mistyped, the GPL version was CLI from x264.nl

[nm]

Yes I mistyped, the GPL version was CLI from x264.nl

You should edit the thread title and the first post so that other people won't get confused.

[mp3dom]

In theory both version should give the same output quality at the same speed. In practical terms it was already noted that the implementation inside TAW is slower compared to CLI probably due to internal filtering or processing-chain.

[Dark Shikari]

The x264 implementation in TAW is slow for some reason, supposedly filters.

The x264 library itself is functionally identical between TAW and the free version.

[Anakunda]

The x264 implementation in TAW is slow for some reason, supposedly filters.

The x264 library itself is functionally identical between TAW and the free version.

This is arguing with my findings.
I have encoded a DVD using x264-CLI and using TMPGenc's engine:
picture size in both runs the same, preset veryslow, x264-CLI tune film, crf mode@21. But resulting video is different in both cases:


x264-CLI
Overall bit rate : 1 148 Kbps
Writing library : x264 core 114 r1924 08d04a4
Encoding settings : cabac=1 / ref=16 / deblock=1:-1:-1 / analyse=0x3:0x133 / me=umh / subme=10 / psy=1 / psy_rd=1.00:0.15 / mixed_ref=1 / me_range=24 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-3 / threads=3 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / constrained_intra=0 / bframes=8 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=60 / rc=crf / mbtree=1 / crf=21.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00

TMPGenc
Overall bit rate : 1 410 Kbps
Writing library : x264 core 112
Encoding settings : cabac=1 / ref=3 / deblock=1:0:0 / analyse=0x3:0x133 / me=umh / subme=9 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=24 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=2 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=3 / sliced_threads=0 / slices=1 / nr=0 / decimate=1 / interlaced=0 / constrained_intra=0 / bframes=3 / b_pyramid=0 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=60 / rc=crf / mbtree=1 / crf=20.5 / qcomp=0.60 / qpmin=3 / qpmax=51 / qpstep=4 / vbv_maxrate=8000 / vbv_bufsize=7995 / crf_max=51.0 / nal_hrd=vbr / frame-packing=0 / ip_ratio=1.40 / aq=1:1.00
Color primaries : BT.470-6 System B, BT.470-6 System G, BT.601-6 625, BT.1358 625, BT.1700 625 PAL, BT.1700 625 SECAM
Transfer characteristics : BT.470-6 System B, BT.470-6 System G
Matrix coefficients : BT.470-6 System B, BT.470-6 System G, BT.601-6 625, BT.1358 625, BT.1700 625 PAL, BT.1700 625 SECAM, IEC 61966-2-4 601

It looks like TMPGenc ignores totally custom Performance profile
http://img88.imageshack.us/img88/9743/57346923.png

[Dark Shikari]

They're likely forcing a reference frame cap. If you want to complain about it, complain to them so they can change it.

[CruNcher]

Which makes sense todo in a average customer application scenario, even if the resolution is so low it could allow more reference frames on most hardware though i find the VBR restriction strange for the Res and Profile ?

720x560 @ 25 fps High Profile Level 3.? = vbv_maxrate=8000 ??
http://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Levels

[Anakunda]

Which makes sense todo in a average customer application scenario, even if the resolution is so low it could allow more reference frames on most hardware though i find the VBR restriction strange for the Res and Profile ?

720x560 @ 25 fps High Profile Level 3.? = vbv_maxrate=8000 ??
http://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Levels

no I don`t know. Those values are defaults passed by TAW. I don`t know why they set maxrate 8000 for SD sources, the same I don't know why Level3 is default when L4 is default by x264 CLI.

Okay I think the mytery is disclosed, thanks for all opinions.

[kolak]

Poor implementations of x264 should not be allowed- but looks like DS does not give a xxxx at all how x264 is implemented in commercial applications. Bit sad.

Andrew

[Dark Shikari]

Poor implementations of x264 should not be allowed- but looks like DS does not give a xxxx at all how x264 is implemented in commercial applications. Bit sad.

AndrewI have already complained to them about it; I think more weight will be given if their customers complain as well.

I can't magically make them change things, sadly.

[Chikuzen]

yeah, several Japanese who were joining in #x264@freenode reported on this problem to Dark Shikari LAST DECEMBER.
(It was the first day when the trial version was distributed in Japan.)

anyway, it is only their customer that has the right to complain to Pegasys.
and, DS is not their customer but a seller.

[kolak]

I have already complained to them about it; I think more weight will be given if their customers complain as well.

I can't magically make them change things, sadly.

Good to know.
Can you take back their license, based on the fact that their implementation is not correct?


Andrew

[Dark Shikari]

Good to know.
Can you take back their license, based on the fact that their implementation is not correct?"Correct" is very vague, if we made such insane restrictions on customer usage of x264 that any screwup would be illegal, nobody would want to use x264.

[shon3i]

I think they target very strict hw settings, to cover more devices.

[kolak]

"Correct" is very vague, if we made such insane restrictions on customer usage of x264 that any screwup would be illegal, nobody would want to use x264.

Makes sense- but 2.5x slower is not good.
There were also some color shifts in x264 exporter, when source was uncompressed, but it looks like they have fixed it.

Andrew