Log in

View Full Version : MeGUI Custom x264/AVC video profiles.


Pages : 1 [2] 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

Sirber
3rd November 2005, 00:35
to use a matrice it's only:

--cqmfile mp4_guy's_AVC_Low_Bitrate_matrix.cfg

?

Thanks!

QuadraQ
3rd November 2005, 06:28
...(I think they probably just use MPEG-4 AVC H.264 because it is the 'latest and coolest' codec out there right now)...

I know for me I just like being in on the ground floor of a codec that I think will have a much longer reach than any of the MPEG-4 ASP implementations. DivX/Xvid/Nero are great, but I don't think we'll ever really see the support for these in the broad consumer hardware, like we will for MPEG-4 AVC (eventually - good things are worth waiting for).

(Actually we might in the form of backward compatibility, but if it supports AVC, I'd rather use that than ASP)

I prefer to watch things on my TV so the the xbox is good for testing. As you said the optimization for slower processors like the xbox should improve, so I'll be able to help test that out.

OddbOd77
3rd November 2005, 07:14
Sharktooth, could I also have a copy of the XBMC profile? I've been trying for days to cook up a profile that works properly but despite the videos playing fine, when I skip backwards or forwards XBMC (CVS 2005-10-23) glitches or crashes. It doesn't happen with encodes from Nero so I must be doing something wrong.

Sharktooth
3rd November 2005, 15:00
to use a matrice it's only:

--cqmfile mp4_guy's_AVC_Low_Bitrate_matrix.cfg

?

Thanks!
yes or --cqm "flat"/--cqm "jvt" (presets).

Sharktooth
3rd November 2005, 15:03
Sharktooth, could I also have a copy of the XBMC profile? I've been trying for days to cook up a profile that works properly but despite the videos playing fine, when I skip backwards or forwards XBMC (CVS 2005-10-23) glitches or crashes. It doesn't happen with encodes from Nero so I must be doing something wrong.
well, i've fixed the motherboard of my old Xbox so now i have two of them to test the megui profile. gimme some time and i'll put everything online.

Sharktooth
4th November 2005, 15:20
V2: added Trellis RD to the profiles. Requires MeGUI-x264 0.2.3.0 (included in x264-Full_r362+)

pwh04
4th November 2005, 22:19
Wow - just installed 362 b today and getting almost double fps! with virtually same settings..

hpn
4th November 2005, 22:50
HQ-Insane: Same as HQ-Slowest but performs 3 passes.
Sharktooth, in the current profiles HQ-Insane has --trellis 2 while HQ-Slowest has --trellis 1, so either they are not the same as you say in the description, or HQ-Slowest should also be changed to -t 2. I would also recommend you change the profile names, even if you have to use long names (no problem even with 50 chars or so), because the current names are somewhat nondescript. Each time I start MeGUI I have to look at this thread to remind myself what profile is good for (especially when MeGUI randomizes the profiles name order in the drop-down list - I guess Doom9 should fix it). Or at least include a "readme.txt" with profile descriptions (the same as in your first post) in the .7z file.

A possible bug: when I select HQ-Insane, I see "--analyse none" in the MeGUI commandline, no matter that all macroblocks are supposed to be selected. I don't know if this is a bug in MeGUI or something wrong with the HQ-Insane profile (maybe something related to the 3-pass encode) or maybe not a bug at all.

Doom9
4th November 2005, 23:02
"--analyse none" is turbo involved? that results in analyse none even if all mb options are checked.
MeGUI randomizes the profiles name order in the drop-down listNot true.. I get a directory listing from the filesystem... they'll always be in the same order. The dropdown is sorted alphabetically on top of that, and the settings file saves the profile that was active when you quit.. it's all fully deterministic.

hpn
4th November 2005, 23:20
It's sorted alphabetically in the input tab, but for some reason in the x264 configuration dialog I see this:

http://img487.imageshack.us/img487/3086/order1jz.png

Yes "--analyse none" is only when turbo is checked. I wasn't aware until now. Shouldn't turbo be unchecked authomatically if the user selects a profile explicitly conflicting with the turbo behaviour?

Doom9
5th November 2005, 00:12
I wouldn't call unnoticeable loss of quality and a double digit speed gain conflicting with anything. And it appears the profile comes with turbo checked.
As far as the codec configuration screens go, in fact none of them has the sort flag set for the profile, so yes, they are rather at random, but they should always be in the same order nontheless.. they are in an order.. the order the profile names get when being put in a hashtable but that order is normally not humanly comprehensible unless you know which hashing algorithm is used (which I don't have any doubts could be found out). the next release will have all profile dropdowns sorted alphabetically.

hpn
5th November 2005, 00:29
the next release will have all profile dropdowns sorted alphabetically.It would be nice. Thank you.

And it appears the profile comes with turbo checked.
Now I'm a little confused.

Sharktooth
5th November 2005, 14:53
All profiles have turbo option checked. I fixed the trellis thing for Insane profile on the first post.

Doom9
5th November 2005, 15:21
turbo = --analyse none for the first pass..

Sharktooth
5th November 2005, 15:39
I upgraded the profiles for MeGUI-x264 0.2.3.1.
Profiles now include B-RDO. I also refined some profiles.

Chainmax
5th November 2005, 16:26
All profiles have turbo option checked. I fixed the trellis thing for Insane profile on the first post.

Why do that even on the "insane" and "slowest" profiles? Also, is it safe to assume that x264's AQ isn't completely mature yet since it's not enabled in any profile?

Sharktooth
5th November 2005, 16:42
Coz turbo has a so small influence on final quality it can be safely left enabled.
Also i didnt enable AQ coz its settings depends highly on the source.

redfordxx
5th November 2005, 18:47
Hi,

does anyone have an experience/recommendation which setting in x264 can be tweaked to improve decoding speed with not big quality loss? I don't care encoding speed...
I wanna do some 720p encodes and with my Athlon XP 2600+ (which doesn't seem to be overclocking-friendly) the playback is at some 90-100% processorload without audio.


How about profiles like:
Terribly-slow-encoding-but-normal-playback
Terribly-slow-encoding-but-fast-playback

Doom9
6th November 2005, 15:47
I have a suggestion with regards to the hardware dependant profiles: For hardware playback, audio also matters so it would be good to also have a corresponding audio profile.

Sharktooth
6th November 2005, 16:11
@Doom9: Well, video profiles will be included in my builds once they're all ready. Since audio encoding is not intended to be there (i mean with my x264 binaries) i think audio profiles will be a separate thing.

Hi,

does anyone have an experience/recommendation which setting in x264 can be tweaked to improve decoding speed with not big quality loss? I don't care encoding speed...
I wanna do some 720p encodes and with my Athlon XP 2600+ (which doesn't seem to be overclocking-friendly) the playback is at some 90-100% processorload without audio.


How about profiles like:
Terribly-slow-encoding-but-normal-playback
Terribly-slow-encoding-but-fast-playback
1)Try combinations of those options: Lower the reference frames, lower b-frames, disable mixed refs, disable 8x8dct, disable some Partitions.
2)If it's not enaugh disable inloop deblocking
3)If it's still not enaugh try disabling CABAC (but that will hit compression ratio quite a lot).

For what concerns profiles, i will think about them.

redfordxx
6th November 2005, 16:58
First, as I haven't been able to find any complete and up-to date doc for x264 (may be you'll advice), I don't know what do some features mean.
1)Try combinations of those options: Lower the reference frames, lower b-frames, disable mixed refs, disable 8x8dct, disable some Partitions.Reference frames means, that different motion blocks in one frame can refer to blocks in certain number of other frames, right?
What is mixed refs for?
What is 8x8dct for?
Partifitons mean this qpel search or so? I thought it's encoding time consuming only

2)If it's not enaugh disable inloop deblockingI thought this relates to encoding, so at decoding time it won't slow down


When I will test the speed, is it relevant when test in on single pass fixquant only?

Cyberace
7th November 2005, 14:51
First, as I haven't been able to find any complete and up-to date doc for x264 (may be you'll advice), I don't know what do some features mean.
Reference frames means, that different motion blocks in one frame can refer to blocks in certain number of other frames, right?
What is mixed refs for?
What is 8x8dct for?
Partifitons mean this qpel search or so? I thought it's encoding time consuming onlyThis thread answers most those questions => http://forum.doom9.org/showthread.php?t=96059 ;)

[QUOTE=Sharktooth]2)If it's not enaugh disable inloop deblockingI thought this relates to encoding, so at decoding time it won't slow downinloop deblocking signifigantly slows down decoding too

bond
7th November 2005, 15:21
does anyone have an experience/recommendation which setting in x264 can be tweaked to improve decoding speed with not big quality loss? I don't care encoding speed...
I wanna do some 720p encodes and with my Athlon XP 2600+ (which doesn't seem to be overclocking-friendly) the playback is at some 90-100% processorload without audio.

How about profiles like:
Terribly-slow-encoding-but-normal-playback
Terribly-slow-encoding-but-fast-playbackdecoding speed also heavily differs between different decoders even if the same settings are used

check the stickies!

redfordxx
7th November 2005, 15:49
Bond,

I have read your explanation, referenced by Cyberace. It's nice.
I only don't understand 2 things:

Example: Multiple reference frames
when set eg to 10 it means
1) the frame can reference to frame max 10 frames before
2) the macroblocks in one frame can refer to diferrent frames within 1-10 frames before
or is that the mixed parameter?
and for B-frames similar...

Second, what is 8x8 intra prediction?

....You wanted suggestions, I post it here.

fiorettoe
8th November 2005, 09:39
When is planning the constant quality profiles?

Thank you

smok3
8th November 2005, 11:02
slightly offtopic, but when i try to construct the command line for x264, how and where can i check what profile will/did happen? (baseline, main, high?)

also how that sharktooths baseline profile looks like in command line? (can somebody using the gui copy/paste the cli please?)

(so far i have random results with x264/mp4box -> qt7 compatibility, no idea whats going on.)

Doom9
8th November 2005, 11:06
@smok3: there's no list, but you can either look at the sourcecode of MeGUI - it contains the entire logic of profile and level mapping to x264 options, or just run the software and enable commandline preview.

smok3
8th November 2005, 11:09
Doom9: ic, i kinda thought that profile will show directly on cli somehow B)

---

another slightly offtopic question: why is vfw version of x264 even made if the mp4 is to be the one?

Doom9
8th November 2005, 11:20
i kinda thought that profile will show directly on cli somehow B)No, it's a complex set of rules.. there are many ways you can screw up by writing your own commandlines because there's so much interdependency between certain options.. it goes far beyond just profiles. To the best of my knowledge, MeGUI is the only software at this point that fully implements this logic.

Sharktooth
9th November 2005, 13:18
Due to a bug in MeGUI-x264 almost 1 pass and main/baseline profiles were b0rked.
A new archive is up with fixed profiles and Portable Devices/Consoles profiles.

@doom9: the bugreport is in the main megui thread.

@all the xbox fans: please test the xbox profile and report back, thanks:)

Sharktooth
9th November 2005, 14:31
Mooo... replaced 3 passes with 2 since MeGUI-x264 Automated-3-pass in conjunction with "turbo" is buggy and produces suboptimal quality...
If you prefer i can restore 3 passes... but without "fast first pass" (aka turbo).

leowai
9th November 2005, 15:32
@Sharktooth,
Just a small matter. The title doesn't reflex the correct date of update. It should be "2005-11-9" rather than "2005-1-9", right?

Sharktooth
9th November 2005, 15:41
@Sharktooth,
Just a small matter. The title doesn't reflex the correct date of update. It should be "2005-11-9" rather than "2005-1-9", right?
right... :)

updated the profiles archive. V6 adds megui default settings profile.

QuadraQ
11th November 2005, 03:15
Hi Sharktooth,

I downloaded v6 of the profile pack and used the Xbox video profile in MeGUI 2.3.1b using Finding Nemo as my test. Used Low Complexity constant bitrate (128) for my AAC audio using the Nero AAC encoder.

Loaded it on to my Xbox hard drive and tried it using the 10-9-05 build of Xbox Media Center. Was unable to play the video because after the Disney and Pixar introductions (which played smooth as silk) the actual movie stuttered so bad it was unplayable. Any suggestions?

Sharktooth
11th November 2005, 03:26
yeah... i have to update the xbox profile coz not everyone will tweak their xbmc settings to have a smoother playback.

EDIT: what resolution and bitrate did you set? also, did you disable any kind of postprocessing or any other video filters?

Chainmax
11th November 2005, 03:32
Mooo... replaced 3 passes with 2 since MeGUI-x264 Automated-3-pass in conjunction with "turbo" is buggy and produces suboptimal quality...
If you prefer i can restore 3 passes... but without "fast first pass" (aka turbo).

Would configuring each of the three passes, manually queueing(sp?) them one by one and still using "turbo" produce suboptimal results too?

Sharktooth
11th November 2005, 03:39
didnt test it.

Chainmax
11th November 2005, 12:43
I just encoded a sample from Trigun this way with deblocking 0/0 and it turned out perfect, whereas using automated 3 passes it needed deblockign 2/2 to look good. I should probably conduct more tests, but I'd say that setting each pass manually avoids the issue.

Sharktooth
11th November 2005, 13:17
Ok, thanks :)
However i should wait until doom9 fixes megui.

Doom9
11th November 2005, 13:55
Would configuring each of the three passes, manually queueing(sp?) them one by one and still using "turbo" produce suboptimal results too?No.. if you configure manually, you see what you get right away.. if turbo still mucks up, just disable it before going from 3 pass first pass to 3 pass second/third pass. That way, nothing can go wrong.

BTW, you can just load the 2nd and 3rd job created by automated 3 pass, go into the x264 configuration, and make it so that turbo is disabled.. then update the job.

vendol21
15th November 2005, 10:48
Hi all.
@XBOX users
I made some tests using x264 VFW with all the nice stuff (CABAC, Deblocking Filter 16 refs, 2 bframes, 500-700 bitrate and 576, 640 res) with mp3 audio .avi format. My XBOX (recent CVS XBMC) can handle this avi with no problems at all. When i use the CLI (not Sharkstooths XBOX profile) with the same options but .mp4 and aac format XMBC freeze after 10 mins of normal playback and also cant go ff and rew.

Sharktooth
15th November 2005, 13:32
I (and the xbmc devs) dont think xbox is able to keep up with cabac and deblocking.
Even if you use 576*xxx the xbox CPU has simply not enaugh horse power. So, something went "wrong" with your VFW encode.

Sharktooth
15th November 2005, 14:09
Profiles updated.

PD-Xbox: removed weighted prediction and lowered the max b-frames from 3 to 2. Ensure you use 640*xxx resolutions and one of the latest XBMC CVS builds.

HQ-Slower: rised reference frames from 8 to 10.

helix
16th November 2005, 09:41
I keep getting over sized encodes for some reason that I've failed to find. I tried using several different profiles to see if that was the souce, and changed the bitrate, but they all seem to come out around 10Mb over each time. Here's the setup -

http://tinypic.com/ftdh5u.jpg

And here's the final encode, not at the correct size.

http://tinypic.com/ftdh88.jpg

There's no audio at all involved with this.
Just for the record, video res is: 704x400 23.976fps.

The log: As far as I can see, the bitrate is right where is should be, so it's not that. Is the container overhead factored in here, or am I missing something completly?

job job1-1 has been processed. This job is linked to the next job: job1-2
Next job job1-2 is a video job. encoder commandline:
"x264.exe" --pass 2 --bitrate 931 --stats "E:\Documents and Settings\Phil\Desktop\Script.stats" --ref 3 --bframes 3 --weightb --analyse all --8x8dct --progress --no-psnr --output "D:\Video Encoding\Test - 300Mb aim.mkv" "E:\Documents and Settings\Phil\Desktop\Script.avs"
successfully set up video encoder and callbacks for job job1-2
----------------------------------------------------------------------------------------------------------

Log for job job1-2

avis [info]: 704x400 @ 23.98 fps (67362 frames)
x264 [info]: using cpu capabilities MMX MMXEXT SSE 3DNow!
x264 [info]: slice I:626 Avg QP:21.32 size: 29991
x264 [info]: slice P:24500 Avg QP:24.21 size: 8652
x264 [info]: slice B:42236 Avg QP:25.48 size: 2280
x264 [info]: mb I I16..4: 13.4% 31.2% 55.4%
x264 [info]: mb P I16..4: 4.2% 8.5% 4.5% P16..4: 36.2% 11.3% 5.5% 1.3% 0.9% skip:27.7%
x264 [info]: mb B I16..4: 0.4% 0.7% 0.4% B16..8: 31.0% 1.4% 2.3% direct: 2.6% skip:61.3%
x264 [info]: 8x8 transform intra:47.2% inter:34.7%
x264 [info]: ref P 84.9% 9.7% 5.4%
x264 [info]: ref B 92.6% 5.0% 2.3%
x264 [info]: kb/s:931.2

Actual bitrate after encoding without container overhead: 931.26
desired video bitrate of this job: 931 kbit/s - obtained video bitrate: 933.749626594739 kbit/s
----------------------------------------------------------------------------------------------------------

berrinam
16th November 2005, 10:53
I keep getting over sized encodes for some reason that I've failed to find. I tried using several different profiles to see if that was the souce, and changed the bitrate, but they all seem to come out around 10Mb over each time. Here's the setup -

http://tinypic.com/ftdh5u.jpg
Just for the record, video res is: 704x400 23.976fps.
...
avis [info]: 704x400 @ 23.98 fps (67362 frames)
There seems to be some mismatch here: x264 claims the number of frames is 67362, whereas the bitrate calculator claims there are 64591. Doing some maths with this gives some interesting results:

1) 67362 / 64591 * 300MB = 312MB, which is almost exactly the filesize you got. This, to me, shows that this framecount mismatch is probably responsible.

2) 67362 frames / 2694 seconds = 25fps, almost exactly. I don't know how you are inputting this information (automatically, or manually), but perhaps the source is not 23.976fps, as you say.

helix
16th November 2005, 12:26
Well it seems the final encode is actually 46:46, while MeGUI had it at 44:54? That explains the frame discrepancy, but why the wrong time?

Sharktooth
16th November 2005, 14:10
uhm... corrupted stats file?

smok3
16th November 2005, 15:14
whats the inloop filter range? i thought it is between -2 to 6 (megui seems to allow -6 to 6)

Sharktooth: whats the difference between 100% compatibility and compatibility? (talking about dogmatic quicktime)

Sharktooth
16th November 2005, 15:20
the difference is "100% compatible" is tested and works OK, while "compatible" means it's made to comply with the quicktime decoding capabilities but it is not assured to work 100% of the times.
Blame apple for that...

smok3
16th November 2005, 15:30
tnx,
another question, what is --b-rdo (used in 1P-goodquality)?
doesn't seem to work with my x264 (core:40 svn-367).

(full command line seems to be:
"x264.exe" --bitrate 1000 --ref 3 --bframes 3 --no-b-adapt --filter -2,-2 --subme 6 --b-rdo --weightb --trellis 1 --analyse p8x8,b8x8,i4x4,p4x4 --progress --no-psnr --output "" "" )