Adobe Premiere - MainConcept's H.264 vs x264 open source encoder

[rallymax]

Hi all,
hopefully this belongs in Editing vs somewhere else.

Can someone comment on how MainConcept's H.264 encoder stacks up against the x264 project's implementation.

Main Concept:
( http://www.mainconcept.com/site/prosumer-products-4/mpeg-pro-hd-4-22464/information-22492.html )

x264 project:
( http://www.videolan.org/developers/x264.html )

Is the Main Concept H.264 and MPEG2 output bundled in CS4 the same as the above offering or did they dumb down the features to have a lower IQ?

- I was thinking of putting the x264vfw project on my PC to try it as an encoder. (it uses the x264 project's encoder). Failing that working I was going to do the little work to make a Premiere CompilerX264.prm plugin to support the encoder directly in Premiere.

thanks

[jagabo]

Read later in this thread. Many samples.
https://forum.videohelp.com/topic371339.html

[rallymax]

it took 2 hours to get my head around that thread but I think I'm up to speed. I definitely learnt a lot about the components that go into the MPEG4 AVC compression.

Ok, so I think I want to try using x264 instead of Main Concept's dumbed down bundled software for Premiere.

From what I can tell the only way to add x264 as an encoder is via "Export to Movie" and in the Video tab use the x264vfw VfW encoder.

But the config screen is WAY too advanced for me. Any pointers on what I should do to make a high quality bluray @ 720p/30 legal output? Should I simply set it to "VBRxNpass", 20Mbs and let the auto settings take care of most of the parameters, including the AQ?
thx

[poisondeathray]

720p30 is technically not legal for blu-ray (although it should play in most players). 720p60 is legal. What is your source content format? (1080i30? or something else?)

several reasons NOT to use x264vfw:

1) not officially supported by the devs, and updates are less frequent, and no official support

2) h.264 in avi container not fully supported, b-frames can cause decoding errors and lag, some programs don't like h.264 in avi

3) you need nal-hrd patch for blu-ray compliance, I'm unsure if that vfw version was compiled with that

I would export as lossless from AME, then encode with x264cli or a x264cli GUI. e.g. MEGUI has a blu-ray preset to start from, you just have to tweak it a bit, like bitrate etc... export it as rawavc (not in container)

Are you using Encore to author or something else? Encore only supports true BD25/50 , not the BD5/9 or "AVCHD" variants (on DVD5/9 media). A freeware way to author is using multiavchd

[rallymax]

thanks for the heads up.
some of my source is 720p30 so and I didn't check the BluRay spec so that's how I made that mistake. thanks for the bringing it to my attention before it blew up in my face.

I'm going to have a look at the libx264 interface and see how easy it will be to make a Premiere compiler (that's what they call their encoder stage).
'fortunately it seems that the voice of the x264 developers is here on this forum so I know that I can ask stuff here and I assume there is a x264-forum mailing list etc too.
If it's all too much I'll export to a lossless intermediate and drop into MEGUI etc.
As for authoring: I only have a single layer DVD burner so I was planning on continuing with Encore for SD DVD5 authoring. I'm planning on using multiAVCHD for DVD5-AVCHD disks. Eventually I'll get a BluRay burner and move back to Encore. DVD5-AVCHD is pretty short anyhow so I'm going to hit that wall pretty quick.
once again, thx for the heads up.

[poisondeathray]

The x264 developers and all the "hard core" coders can be found at Doom9 forums. If you need help with libx264, or compiling for a modded build that would be the place for more info. There is a few day waiting list before you get approved, so it wouldn't hurt to register now before you have questions

[creamyhorror]

That thread ought to be renamed the x264 comparisons thread


edit: There's an x264 Quicktime component at

http://www003.upp.so-net.ne.jp/mycometg3/

It's a bit out of date (doesn't have the major improvements of Aug 09) but you might want to give it a try, since the maintainer appears to be still alive.

[rallymax]

darn - it's Mac only.

[rallymax]

is this where I would post libx264 questions on doom9?

Doom9's Forum > Video Encoding -> MPEG-4 AVC / H.264

[poisondeathray]

is this where I would post libx264 questions on doom9?

Doom9's Forum > Video Encoding -> MPEG-4 AVC / H.264

Yes.

"Lord Mulder" hosts precompiled libx264 builds in the avidemux thread, he would be one (of the many) good resource people to ask questions
http://forum.doom9.org/showthread.php?t=108784&page=63

[creamyhorror]

I should mention that, while a libx264 Premiere exporter would no doubt be useful to a lot of folks, a major reason to export to an intermediate format is the superior processing capabilities of Avisynth. Some folks export edited footage from Premiere, then use Avisynth's superior filters to deinterlace and resize it, then finally encode it with x264. If you're looking for max quality, you might want to look into this method.

But if you create a libx264 Premiere exporter, I'm sure lots of people will thank you for it - remember to post it on the Adobe forums.

[poisondeathray]

I should mention that, while a libx264 Premiere exporter would no doubt be useful to a lot of folks, a major reason to export to an intermediate format is the superior processing capabilities of Avisynth. Some folks export edited footage from Premiere, then use Avisynth's superior filters to deinterlace and resize it, then finally encode it with x264. If you're looking for max quality, you might want to look into this method.

But if you create a libx264 Premiere exporter, I'm sure lots of people will thank you for it - remember to post it on the Adobe forums.

There is already an Premiere AVS Import plugin, so most people do the avisynth processing before (especially deinterlacing)

Debugmode frameserver works for Vegas Pro 7/8/9 and older versions of PP (unfortunately not CS4), that would have been a great way to integrate x264CLI for export . I use it often for my Vegas projects

rallymax - I'm one of the many who would thank you if you developed libx264 for PP CS4

[creamyhorror]

Oh, deinterlacing before import does make more sense. I've actually done that before, come to think of it.

Too bad about debugmode not working on PP CS4; I've used it on CS3 and it works great.

[rallymax]

ok... so it begs the question.
It's my understanding that x264 doesn't support slices (ie frame is parallel processed by slicing into 2x2 blocks). It's my understanding that slices is a a AVC High Profile 4.1 requirement.
From the glossary BluRay standard is... (w.r.t AVC)
AVC/H264 - MPEG-4 AVC: HP@4.1/4.0 and MP@4.1/4.0/3.2/3.1/3.0

So, if x264 doesn't have HP@4.1 does that matter making legal BluRay output?
My goal here is 720p. Does that have to be HP@4.1? Or can it be HP@4.0, which I read somewhere doesn't require slice processing support.

I ask because if I can't make BluRay legal output I'm not going to spend the 100+ initial hours and then commit to ongoing support of a x264Compiler.prm.

Secondly, my first goal would be to drive x264 with a few basic choices.
Can you all comment on what generic settings would be smart to use in this version 0.0.1?
The good news is, I have got the framework in place and am starting to drop in the libx264 as the encoder.

thanks for any pointers, 'coz I don't know how to drive x264. I'm borrowing from the x264cli code for how to drive the library but that'll only get me so far (ie what it defaults)

[poisondeathray]

ok... so it begs the question.
It's my understanding that x264 doesn't support slices (ie frame is parallel processed by slicing into 2x2 blocks). It's my understanding that slices is a a AVC High Profile 4.1 requirement.
From the glossary BluRay standard is... (w.r.t AVC)
AVC/H264 - MPEG-4 AVC: HP@4.1/4.0 and MP@4.1/4.0/3.2/3.1/3.0

So, if x264 doesn't have HP@4.1 does that matter making legal BluRay output?
My goal here is 720p. Does that have to be HP@4.1? Or can it be HP@4.0, which I read somewhere doesn't require slice processing support.

I ask because if I can't make BluRay legal output I'm not going to spend the 100+ initial hours and then commit to ongoing support of a x264Compiler.prm.

Secondly, my first goal would be to drive x264 with a few basic choices.
Can you all comment on what generic settings would be smart to use in this version 0.0.1?
The good news is, I have got the framework in place and am starting to drop in the libx264 as the encoder.

thanks for any pointers, 'coz I don't know how to drive x264. I'm borrowing from the x264cli code for how to drive the library but that'll only get me so far (ie what it defaults)

Correct, x264 used to support slices, then that patch was taken out because it was thought to degrade quality too much

AVC L4.0 doesn't require slices for blu-ray

The majority of SAP's will play x264 encoded material fine @ L4.1 . This includes media boxes like Tvix, WDTV, popcorn hour and conventional blu-ray players.

I seriously doubt you would need >L4.0 for 720p60 output (20Mb/s), unless you have a very very nice camcorder

If you want 100% L4.1 compliance for replication purposes, you should use an encoder that supports slices like cinevision ($$), and mainconcept reference can be configured to comply as well

This thread contains a lot of useful info, including complaint settings. I'm not too familiar with the coding side, but there are many who are at Doom9:
http://forum.doom9.org/showthread.php?t=148826

Cheers, and keep us updated!

[rallymax]

lookslike the downside to 4.0 is the max datarate for Main and High Profiles

http://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Levels

Ver___MP____HP
4____20000_25000
4.1__50000__62500

Is 20Mbps enough for great looking 720p or 1080p for that matter?

[rallymax]

According to here http://en.wikipedia.org/wiki/Blu-ray_Disc the 1x read speed is 36Mbit/s. I'm assuming that most BluRay players only support 1x for regular film playback. That would then suggest that ~30Mbit video is the average max right?

[creamyhorror]

lookslike the downside to 4.0 is the max datarate for Main and High Profiles

http://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Levels

Ver___MP____HP
4____20000_25000
4.1__50000__62500

Is 20Mbps enough for great looking 720p or 1080p for that matter?

Lyris on Doom9 attests to the fact that x264@4.0 still looks better than MCR@4.1 despite having around half the bit rate. Also see this post where he compares x264, MCR, Dostudio and CodecSys. I'm not sure what resolution he was using, though.

By the way, x264 CLI generally requires the NAL HRD patch to produce BD-compliant streams. You should look into whether libx264 includes it, else you might not be able to produce BD-player-playable results.

[rallymax]

poison' posted while I was typing. based on the comment that 20mbps is plenty I'll move forward aiming for a HP@4.0 as my max supported output.
now all I need is some good parameters

[rallymax]

By the way, x264 CLI generally requires the NAL HRD patch to produce BD-compliant streams. You should look into whether libx264 includes it, else you might not be able to produce BD-player-playable results.

where do I get that patch?
should I be asking this on Doom9 or is it still ok here?

[poisondeathray]

It will depend on your source (e.g. complexity, etc..) but 20Mbps using x264 is enough for most in my experience. Not enough using Mainconcept.

There's some head to head examples in that thread
x264 @ 19Mbps L4.0 is looking about the same as MCR at 35Mbps @ L4.1
EDIT: too slow, creamyhorror faster typer!

For average bitrate, I've personally never have gone above 30Mbps. I've never had the need to for my blu-rays. Some people have , however.

Unless you have an extremely high quality source (like 10bit 4:2:2 AVC-Intra ), (or crappy shaky non tripod shot video) x264 is efficient enough not to use those high bitrates in my experience

[poisondeathray]

By the way, x264 CLI generally requires the NAL HRD patch to produce BD-compliant streams. You should look into whether libx264 includes it, else you might not be able to produce BD-player-playable results.

where do I get that patch?
should I be asking this on Doom9 or is it still ok here?

I honestly don't know. I use precompiled builds that are hosted. They will know for sure at D9

[creamyhorror]

I honestly don't know. I use precompiled builds that are hosted. They will know for sure at D9

Yeah, rallymax, ask Lord Mulder on Doom9. You might want to post a thread in the MPEG4/AVC forum announcing your intention to build a Premiere exporter using libx264, which might garner some good suggestions. You can also ask about BD compliance in that thread, if you don't feel like PMing Lord Mulder.

edit: Crap, forgot that new signups can't post on Doom9 immediately. Need us to ask him for you?

edit2: I forgot to mention that the majority of settings for x264 should probably be handled by the presets and tuning system. In the past people would specify every option that they wanted to change from the defaults; now you can simply specify a preset (e.g. "ultrafast" or "slowest") to indicate a group of settings. I'll link you the relevant thread if/when you need it.

[rallymax]

creamyhorror - yes those presets would help
i joined D9 a few days ago so I might be able to post by now.
Got a long way today with the PRM.
ready to pull in the lib

[creamyhorror]

The presets are listed in this thread, which is slightly outdated. They are (as of this posting):

ultrafast (fastest / lowest quality)
veryfast
faster
fast
medium
slow
slower
veryslow (as slow as you should go / best quality)
placebo (pointlessly slow / bestest quality)

To use them in x264 CLI, you use the --preset switch, e.g. --preset slower. I assume there's an analogous way to call libx264.

There are also the --tune and --profile switches, which will probably be important to include:

--tune name where name = film, animation, grain, and a few other possibilities.

--tune film should be used for movies and other film sources, and may also work well for video sources. --tune animation is self-explanatory. --tune grain maximizes grain retention on source that have a lot of it.

--profile name where name = baseline, main or high.

This allows users to ensure compliance with H.264 profiles, and overrides everything else. It's generally only necessary when you're targeting playback on specific devices or less capable decoders (e.g. when streaming HD maybe).

The priority of these settings is:

Presets < Tunings < User settings < Profiles

This means that any clashing options will take precedence in that order. User settings will override any conflicting options from presets and tunings, while profiles override all the rest.

For playback on devices, it's important to have the VBV switches, which limit bitrate to ensure the device doesn't choke. In future, a --device switch may be created to make things even simpler.

You can find a reference to all of these options on this page at the MeGUI wiki.

Sorry if this is confusing; just ask whenever you have doubts.

[deadrats]

Lyris on Doom9 attests to the fact that x264@4.0 still looks better than MCR@4.1 despite having around half the bit rate. Also see this post where he compares x264, MCR, Dostudio and CodecSys. I'm not sure what resolution he was using, though.

from the post you site:

1. X264: best quality, even at Level 4, but I can't get it to play (perhaps I have the wrong settings).

my response: who cares if it's the best quality if you can't produce a blu-ray disc that actually plays, maybe this answers my question as to why blu-ray authoring houses don't use x264 in their commercial blu-rays (or HD DVD's for that matter).

Looking at MCR's output and judging it on its own merits, it looks fantastic. Only when you compare it to the source (and indeed to x264) do I start seeing minor flaws.

if it looks fantastic, then what is the problem?

as i said in the other thread, i do admit that after doing a number of extensive encodes over the past few days it does seem like x264 requires much lower bit rates than other h264 encoders to achieve great quality, but if the output is not blu-ray compliant then all it's really good for is creating content to be viewed on a pc.

[creamyhorror]

1. X264: best quality, even at Level 4, but I can't get it to play (perhaps I have the wrong settings).

my response: who cares if it's the best quality if you can't produce a blu-ray disc that actually plays, maybe this answers my question as to why blu-ray authoring houses don't use x264 in their commercial blu-rays (or HD DVD's for that matter).

Of course you can produce a Blu-ray stream. That guy just hadn't used a NAL HRD build, required for Blu-ray compliance. Other people are individually authoring Blu-ray or AVCHD discs just fine.

It's fair to criticise x264 for not including Blu-ray compliance by default, but it's a simple matter of downloading a build that includes the compliance patch.

Looking at MCR's output and judging it on its own merits, it looks fantastic. Only when you compare it to the source (and indeed to x264) do I start seeing minor flaws.

if it looks fantastic, then what is the problem?

No problem at all, feel free to continue using it. No one was trying to get you to switch.

That other thread only got so long because you and Puzzler were claiming that even MPEG2 looked better than x264, which was a preposterous claim for such an advanced encoder.

[jagabo]

I don't care about blu-ray compliance.

[poisondeathray]

1. X264: best quality, even at Level 4, but I can't get it to play (perhaps I have the wrong settings).

my response: who cares if it's the best quality if you can't produce a blu-ray disc that actually plays, maybe this answers my question as to why blu-ray authoring houses don't use x264 in their commercial blu-rays (or HD DVD's for that matter).

As creamyhorry said, it was basically user error. He didn't use a nal-hrd patched build. x264 encodes play fine, even L4.1 play in the majority of players. L4.0 doesn't even require slices

Looking at MCR's output and judging it on its own merits, it looks fantastic. Only when you compare it to the source (and indeed to x264) do I start seeing minor flaws.

if it looks fantastic, then what is the problem?

The problem is you need a lot more bitrate when using other encoders. In his limited comparison, x264@19Mbps looked the similar to MC@35Mbps. You do the math. In my own comparisons, the difference isn't this big. On high quality material I'm only seeing about 1.4-1.5x size required (but still very significant). This often pushes you into BD50 territory instead of using BD25. Which means more $. Everything looks great if you throw bitrate at it, even MPEG2 can look good at 100Mbps. But this means your videos will be very short in duration to fit the fixed capacity limit

as i said in the other thread, i do admit that after doing a number of extensive encodes over the past few days it does seem like x264 requires much lower bit rates than other h264 encoders to achieve great quality, but if the output is not blu-ray compliant then all it's really good for is creating content to be viewed on a pc.

There is a difference between sufficiently compliant for playback (which I assume you are doing) and 100% conform to specifications for replication (ie. mass producing in lots of >10,000 at a replication house). My own personal experience L4.1 encodes have worked flawlessly in 4 different blu ray player models. There is a database at doom9 which collects this data. So I do care about compliance, but only as it pertains to viewing in a blu-ray SAP.

[rallymax]

hi all
I've made somre great progress.
I am concerned out BluRay compliance so can someone point me to the NAL HRD code patch? - Now would be a great time to drop it into the code.

Slightly different question...
Premiere _requires_ that you can understand RGBA (8888) and optionally accept other formats.
x264 expects YUV 420 and seems to have no RGBA input handler.
If the source footage is YUV420 and is unmodified it'll be passed through in YUV but the majority of the time it'll be RGBA.

Does someone have a code snippet or the math to do a proper RGBA to YUV conversion? - This is determined by the color space right? - Which'll mean I need to have a BT409 etc radio button to decide the color range????