MeGUI Custom x264/AVC video profiles.

[berrinam]

Ah ... thanks! Works great now.
I've added some handlers which should avoid this crash in version 0.2.3.2020. I've not actually been able to reproduce the crash when Decomb.dll was missing, so when a release comes out, could you see whether this still causes a crash?

Thanks

[The Link]

I've added some handlers which should avoid this crash in version 0.2.3.2020. I've not actually been able to reproduce the crash when Decomb.dll was missing, so when a release comes out, could you see whether this still causes a crash?

Thanks
It doesn't crash now but it would be nice if the decomb.dll warning would pop up before the analyzing process starts imho.

[berrinam]

It doesn't crash now but it would be nice if the decomb.dll warning would pop up before the analyzing process starts imho.
It's AviSynth's fault, though, for not giving any error messages when the dll is missing. As a result, the only indication that anything went wrong is the fact that the output log file has the words "I don't know what "a" means" in it. That's all that AviSynth says.

Anyway, I can see that it's a waste of time, but I would hope that each user would only do this once, so overall it isn't too bad.

[Manao]

It's AviSynth's fault, though, for not giving any error messages when the dll is missingOpen your script with virtualdub, you'll see a nice error message printed on the frame :). It's a wanted feature of frameevaluate, because it can't know, when instanciating the filters graph, what filters will be needed by frameevaluate. So it can only say that something's missing when displaying the first frame.

If you want to check whether IsDecomb exists or not, just add a line "global unused_ = IsCombed(clip, 32)" somewhere in your script.

[berrinam]

If you want to check whether IsDecomb exists or not, just add a line "global unused_ = IsCombed(clip, 32)" somewhere in your script.
Thanks Manao. I presume that also has very little effect on speed, being an unused clip?

[JarrettH]

Well the movie Broken Flowers @104min took approximately:

HQ-SLOW 950kbps 6hrs
HQ-SLOWEST 950kbps 15hrs

Using a P4 2.8GHz w/HT and OCZ 512MBx2 2-2-2
Actually I didn't finish slowest but it was at 57% so I added the remaining time to the elapsed time. I used 950kbps so that I still had room to mux the aac audio after on 1CD. I don't think I'll be using Slowest mode again:sly:
I'll try HQ-SLOWER with 1000kbps and see if I can still fit the aac on with 1CD if it compresses more as you say.:)

[Manao]

Thanks Manao. I presume that also has very little effect on speed, being an unused clip?Indeed, it shouldn't. But as I didn't try, I can't be totally positive :)

[lexor]

hey guys, does any of the profiles (qt compatibility one for example) qualify for streaming video over internet? granted I'll still need to figure out how to use the whole hint track and all that jazz for streaming, but that doesn't belong here.

I want it to be streamable, not necessarily QT compliant (since coreAVC cameout with their browser plugin), but using HQ and such for streaming bitrates isn't exaclty a good idea. So any of the profiles qualify as optimal for this use or do we need to research one more?

[smok3]

lexor, iam just remuxing with hint track using mp4box and seems to work fine for qt (streaming? well i call that progressive download.)

cmd could be simply:

mp4box film.mp4 -hint

[JarrettH]

Update:

Well the movie Broken Flowers @104min took approximately:

HQ-SLOW 950kbps 6hrs
HQ-SLOWER 1000kbps 15hrs
HQ-SLOWEST 950kbps 18hrs

I should have put 18hrs for SLOWEST because I forgot about the first pass!

@Sharktooth...Is there anything I can do using the Slow profile to increase the quality but not drastically increase the encode time? Something like under 10hrs is good.

[JarrettH]

I chose to bump:D

I began customizing the Slow profile after EXHAUSTIVELY reading about the settings. I stuck with Broken Flowers (106min)...

1000kbps
No Fast P-Skip: Checked
Reference Frames: 8 + mixed
ALL B-Frame options: Checked

Ran the above with Multi-Hex on a P4 3.0GHz (Prescott) 2x256MB and Hexagon on a P4 2.8GHz (Northwood) 2x512MB 2-2-2.
In summary, both would have taken too long! 13hrs for Multi-Hex and 13hrs for Hex. Both computers were getting too oversized files anyway for the audio I needed to mux.

Tonight I'll run...

1000kbps
No Fast P-Skip: Checked
Reference Frames: 5 Both Computers
ALL B-Frame options: Checked
Multi-Hex: Both Computers
Soulhunter V2 matrix <3 (on Northwood), None (on Prescott)

I suspect mixed was slowing them down. A few more (10-20) kbps in the video isn't worth an hour of encoding time to me :) So I'll find out tonight how large a time difference there is between 5 and 8 ref frames, and if 5 frames ends up being <10hrs I think it's a keeper!
950kbps is the highest I got to encoding the movie with space for the audio. I'm trying 1000kbps again to see if any of the settings + matrix help with compression.

Edit* Got some ridiculous oversize (47mb file) at 5% into the 2nd pass using 8 ref frames. Now both comps have the same settings different matrix in use. I don't know what made the original HQ-Slow profile great for file sizes, the settings will be identical soon enough. LOL
Is there something in x264 between 950kbps and 1000kbps that would cause this?

Help me!

[quake74]

Hi Sharktooth, the profiles in your latest standard x264 package and the v20 on the first page of this thread are different (I looked at the psp one). Which are the newest?

[bob0r]

About xbox profile (i tried to post this like 4x, but 4x something messed up and it never came here)
So here it is:
http://forum.doom9.org/showthread.php?p=784123#post784123

[Sharktooth]

Profiles are a bit outdated. I'll update them as soon as i get back from the hostpital.

[aichan]

i would to encode CG dvd movies like ice age, finding nemo....

which profile should i take, HQ slow or AE-goodquality? is it CG movies an anime/toon source??

thx :)

[Sharktooth]

cg is something in "between"... you can effectively use both profiles (until i update them).

[Sharktooth]

v21: big update. updated many profiles with speed ups expecially for CQ-Lossless.

[jackiehcs]

cg is something in "between"... you can effectively use both profiles (until i update them).
In fact, there is always "CG" in anime.
Should I use 0,0 for deblocking in order to get better picture quality?

[Sharktooth]

well, it depends on the sharpness/smoothness you want to obtain.
try different settings on small clips and choose the values you prefer.
keep in mind anime profiles have deblocking set to 1,1 while movie profiles have deblocking set to -2,-1.

[quake74]

Hi Shark, about the psp profile, did you see this message http://forum.doom9.org/showthread.php?p=755401#post755401 ? I myself canot confirm it because I have a 2.0, but maybe we could revert back to 2 ref and nobframes. Moreover the psp has very little storage, so it's more likely that people go down into the very low bitrates (200kbps and lower) and in those cases bframes could actually decrease the quality of the movie...

[max-holz]

Ciao Sharktooth
I noticed that in the Rev. 21 you have changed the B-frame mode of the HQ profiles from temporal to spatial, why that?

[Sharktooth]

IMHO spatial give better quality and helps a bit with blocking in dark areas.

[Sharktooth]

Hi Shark, about the psp profile, did you see this message http://forum.doom9.org/showthread.php?p=755401#post755401 ? I myself canot confirm it because I have a 2.0, but maybe we could revert back to 2 ref and nobframes. Moreover the psp has very little storage, so it's more likely that people go down into the very low bitrates (200kbps and lower) and in those cases bframes could actually decrease the quality of the movie...
b-frames do not decrease quality at lower bitrates... theoretically it should be exactly the other way.
however i'll see what i can do.

[fight2win]

[QUOTE=Sharktooth]
Download link: MeGUI-x264 Custom Video Profiles V21. (http://www.webalice.it/f.corriga/megui/MeGUI-x264_generic_profiles_v21.7z)

Dude, are these profiles supported by chronocross x264 rev 445 builds?

[Sharktooth]

445 is buggy

[quake74]

b-frames do not decrease quality at lower bitrates... theoretically it should be exactly the other way.

Not to get started again on "The Coolness of B-Frames" but yesterday I encoded video at 128kbps and the one with 3bframes was worse than the one without (both by SSIM, and just by looking at the frames). (Out of curiosity, at 192kbps they were essentially the same, and at 256kbps the bframes win.)

[fight2win]

445 is buggy
ok, can it be used with bobor's rev 449?

[Sharktooth]

yes, but it does not support subme 7 (it will automatically use 6 when needed)

[Chainmax]

But it does work with ChronoCross's v438 (which is supposed to include all your patches), right?

By the way, does the XBOX lowres profile allow for custom matrices? I'd like to try mp4_guy's_AVC_Low_Bitrate_matrix_V2.cfg on an encode.

[Sharktooth]

yes and no

[Chainmax]

I see, time to make a suggestion to the XBMC devs then :).

[Sharktooth]

I see, time to make a suggestion to the XBMC devs then :).
xbox has it's own CPU limits... stick with default quantization.

[Chainmax]

I didn't think a custom quant matrix would put much extra decoding strain.

[Sharktooth]

custom quant matrix require High-Profile...

[foxyshadis]

You can actually decode flat-16 matrix much faster than any cq, because it's just a shift-by-4 for each coefficient, plus you have to guard against low coefficients overflowing in uber-high matrices. That's why it's part of High Profile. With an optimized decoder it probably wouldn't make a big difference overall though.

[Chainmax]

custom quant matrix require High-Profile...
But profiles are just a tag, what matters are the actual features used. foxyshadis's argument seems logical though (not that I know anything about the subject), do you agree with it?

[Zep]

yes, it "should"... but some features are broken. baseline will work with no doubts :P

Quicktime's latest h.264 encoder and h.264 decoder handle different levels. The decoder handles everything in main profile except B-Pyramid which will cause stuttering and then a buffer overflow.

Qt 7.0.5 should fix that with the new version of the decoder. (well that is what was said on the QT dev list anyway)

I use your main profile with B-Pyramid off and have never had a problem. In fact the QT decoder plays smoother and with less CPU demand than ffdshow for me.

[bond]

Quicktime's latest h.264 encoder and h.264 decoder handle different levels. The decoder handles everything in main profile except B-Pyramid which will cause stuttering and then a buffer overflow.the decoder doesnt handle (correctly)
- mixed references (baseline profile)
- more than 1 b-frames (main profile)
- b-references/pyramid (main profile)
- interlacing (main profile)
- 8x8dct (high profile)
- i8x8 (high profile)
- cqm (high profile)
- lossless (high profile)

and surely much more i now forgot :D

I use your main profile with B-Pyramid off and have never had a problem. In fact the QT decoder plays smoother and with less CPU demand than ffdshow for me. troll?

[Zep]

the decoder doesnt handle (correctly)
- mixed references (baseline profile)
- more than 1 b-frames (main profile)
- b-references/pyramid (main profile)
- interlacing (main profile)
- 8x8dct (high profile)
- i8x8 (high profile)
- cqm (high profile)
- lossless (high profile)

and surely much more i now forgot :D

troll?

You better read my post again because i said QT handles the options. I never said how or to what you consider
"(correctly)". In fact 7.0.4 on mixed references just hands off to an empty stub and play back works fine and that is
the point i was making in my post about the options. That the decoder will play back fine so to expand on that
you do not need to make 2 target encodes or 1 encode that has options turned off since only 1 main profile option
messes up play back with the current release decoder.

next you listed high profile stuff. we are talking about main profile. Are YOU trolling? You appear to be by
making your list bigger than it should be lol

As for b-frames are you kidding me? i use more than 1 b-frame ALL the time and the 7.0.4+ decoders play my encodes
back PERFECTLY and ALL b-frames are shown perfectly. This makes me think you have never even tried 2+ b-frames
in QT play back. Are using the old specs on apples site?

Anyway, If Apple sticks to the plan 7.1 will address ALL the remaining issues AND now that OSX and QT are x86 native
the performance of QT on the windows side is MUCH better and going to improve even more since the QT dev team coders
have gotten better at x86 coding and it shows already in 7.0.4+ and the current beta is very nice. PPC is history and
all efforts are going into mactel now.

Me a troll? nope. I simply stated what happens on my dev box. I'm sorry it is not what you like to hear but get used
to it since Apple is mactel now and intel has made one sweet compiler tool set for apple :)

[Sharktooth]

Dude, are you kidding?
QT = CRAP and is severely limited in playback capabilities.
Bond is perfectly right on the unsupported features, i personally tested (and bond too) EVERY single option and came to his same conclusions. And dude... i dont know how the hell you MISCONFIGURED ffdshow but there's no way it's slower than QT.
Next time :serch: before posting.

[foxyshadis]

Look, have you guys even installed 7.0.4 to find out?


11 January, 2006
QuickTime 7.0.4 is an important release that delivers numerous bug fixes, support for iLife '06, and H.264 performance improvements. This update is highly recommended for all QuickTime 7 users.


Whether it's all that and a bag of chips or not (ffdshow and any DS player is probably still better), it still sounds like a definite improvement over QT 7.0. There's also been a definite drop-off in "OMG QUICKTIME CAN'T PLAY MY MOVIES" threads since January.

[Sharktooth]

i tried 7.05.

[Zep]

Dude, are you kidding?
QT = CRAP and is severely limited in playback capabilities.
Bond is perfectly right on the unsupported features, i personally tested (and bond too) EVERY single option and came to his same conclusions. And dude... i dont know how the hell you MISCONFIGURED ffdshow but there's no way it's slower than QT.
Next time :serch: before posting.

"Dude" i just played an encode i did last night and it played great with 3 b-frame runs and b-pyramid off. That right there proves you wrong on the current release if you also claim 1 b-frame only. Sure you were correct back when you tested old versions but i never claimed otherswise.

"Dude" i do not know how the hell you MISCONFIGURED QT.
(see i can play that game also)

To make you happy today i did a clean install of milan's current version of ffdshow and then i went and made sure the only thing on was the H.264 option in the video decoder and i turned only the acc option on in the audio decoder JUST to make sure nothing else was conflicting from the defaults after you first install which played the same as i claimed for me in my first post. Still plays worse and still stutters now and then unlike QT or Elecard decoders. This may point to the encode having a combo of settings that ffdshow does not like that i use to make QT on Macs and PCs play fine and one variation(s) you never tried on many. I tested many many variations.

And speaking of testing you never said what version of QT you tested. At least in my posts i told you what version of QT. Also this is a QT thing. Not JUST a Windows QT thing. I test on both my G5 and my AMD dev boxes. You just saying you tested then making this global claim that "QT = CRAP" is in itself crap when you don't even bother to post the basics like what version of QT you tested. Anyway, you can't just turn one option on then another and another without turning others OFF else you never see how they all interact with each other. Furthermore, based on your post you give the impression you threw bond's name around without having any idea HOW he tested and what version of QT and if he even tested on both platforms etc...

NOTE: i have always claimed FOR ME. (read my first post again because YOU missed that) I never said it ran better as some global fact for everyone. Did you take note of that? NO you did NOT all you did was shoot from the hip with an attack and you did make global claim that "QT = CRAP" ( windows version is not as good as mac version but duh... ever use WMP on OSX? it works both ways if you know what i mean lol)

ffdshow and QT currently are moot to me anyway since I went back to using elecard decoder since it plays better than both by wide margin. On my Mac i use QT (though mplayer and VLC work fine too for most h.264 encodes)

[Zep]

Look, have you guys even installed 7.0.4 to find out?



Whether it's all that and a bag of chips or not (ffdshow and any DS player is probably still better), it still sounds like a definite improvement over QT 7.0. There's also been a definite drop-off in "OMG QUICKTIME CAN'T PLAY MY MOVIES" threads since January.

foxyshadis i admit 7.0 IMHO sucked arse LOL in fact IMHO 7.01 and 7.0.2 suck also. QT fans boys disagree with me but that is fine cause everyone has different needs and set ups. it wasn't until 7.0.3 that i think Apple should have released it as 7.0 but as always that is just my opinion.

yes i noticed the drop off in the "OMG QUICKTIME CAN'T PLAY MY MOVIES" threads also and not just on doom9. My guess is that 7.0.4.11 finally got most of h.264 major playback issues fixed (well not all since b-pyramid on is brutal and crashes both mac QT and Windows QT most of the time but that is what 7.0.5 is for haha)

[Sharktooth]

hey... read all the posts and you'll see i wrote "i tried QT 7.05" (http://forum.doom9.org/showthread.php?p=798210#post798210).
Also if you bother searching the forums you can find all the tests we did (yes, me and bond and maybe others)...
also milan's latest (compiled) version of FFDSHOW is OUTDATED. Install celtic druid's or bobors's latest builds...
also, it has been proven in multiple tests that the QT AVC decoder is seriously crippled...
also if you used x264 for encoding ensure you unchecked "adaptive b-frames" before yelling QT can decode more than 1 b-frame correctly...
also, i re-tested QT 7.05 on 3 different PCs and it still owns the crown of the slowest and most crippled pseudo-AVC decoder.

EDIT: also read the AVC decoders comparison: http://forum.doom9.org/showthread.php?t=99402 coz your beloved elecard decoder is one of the slowest and ffdshow outperforms it by far... but if you want the fastest avc decoder for win just look for CoreAVC...

[Sharktooth]

v22:
- removed subme 7 so profiles can be used with MeGUI-svn.
- updated b.frames mode to spatial for single pass profiles and auto to 2 passes profiles.
- some adjustments here and there :)

[poiuy]

v22:
- removed subme 7 so profiles can be used with MeGUI-svn.

Thanks.

[smok3]

anything new in CE quicktime ? (no, iam not trolling :D)

[Sharktooth]

uhm... --direct auto ?

[jackiehcs]

I find that encoding with "CQ-ASP_Q2_eq(crf)" shows better result than encoding with "AE-Maxquality" even with a bitrate 100kbps higher...