Is x264 the best?

[sophisticles]

Isn't CRF without AQ pretty much the definition of CQ? And isn't CQ by definition a MB-Tree free zone? Maybe that's not quite right (I'd have to check) but I'm just trying to work out what constitutes the "non CRF with a reduced need for AQ and MB-Tree" encoding method you're referring to.

CRF is an average quantizer mode while cq is a constant quantizer mode; with CRF the quantizer varies among frames but it will average out over the course of the video to whatever value you picked while with cq the quantizer is held constant for every frame.

MB-Tree is basically a localized qcomp, it basically tries to vary the strength of the quantizer on a per macroblock basis; it's impossible to use MB-Tree with a constant quantizer mode because they are diametrically opposed modes.

Consider this, a common suggestion for improving quality of encodes is to set qcomp to 0.9, if you set qcomp to 1 you have constant quantizer mode, even if you're using CRF and you have disabled MB-Tree.

If you set qcomp to 0.1 MB-Tree is at it's strongest and at qcomp 0.0 you now have cbr mode.

So what conclusions do you draw from this?

[Mephesto]

MB-tree still vastly improves the quality at high qcomps.

[sophisticles]

MB-tree still vastly improves the quality at high qcomps.

With certain sources, but it requires AQ enabled to work so now you are left with AQ's baggage and I still think you're better off using a constant quantizer than a localized variable quantizer.

[poisondeathray]

MB-tree still vastly improves the quality at high qcomps.

With certain sources, but it requires AQ enabled to work so now you are left with AQ's baggage and I still think you're better off using a constant quantizer than a localized variable quantizer.

It's going to depend on the specific scenario, but it's usually the opposite in my experience. More often than not, AQ will be beneficial. ie. The pros outweigh the cons.

There are going to be a lot fewer situations, where encoding with --qp vs. --crf (or even 1 pass or 2 pass) with equivalent settings (and doing serial encodes until they have equivalent sizes), where the --qp encode will result in "better" results, at least visually.

AQ is one of the strongest points about x264. IMO it's the strongest feature if I had to pick one. If you've followed along development in the past, against other encoders, against xvid, rmvb etc... This is the turning point that put over the top.

[sophisticles]

AQ is one of the strongest points about x264. IMO it's the strongest feature if I had to pick one. If you've followed along development in the past, against other encoders, against xvid, rmvb etc... This is the turning point that put over the top.

I see, now for the obvious follow up question, main concept's AVC and VC-1 encoders have 3 separate independent AQ modes and AQ has been ported over to xvid (in fact xvid now has Trellis as well); x265 has AQ, and VP9 has AQ.

So now that the competition also has AQ, do you consider all these encoders on equal footing as x264? Why or why not?

[poisondeathray]

AQ is one of the strongest points about x264. IMO it's the strongest feature if I had to pick one. If you've followed along development in the past, against other encoders, against xvid, rmvb etc... This is the turning point that put over the top.

I see, now for the obvious follow up question, main concept's AVC and VC-1 encoders have 3 separate independent AQ modes and AQ has been ported over to xvid (in fact xvid now has Trellis as well); x265 has AQ, and VP9 has AQ.

So now that the competition also has AQ, do you consider all these encoders on equal footing as x264? Why or why not?

AQ has been around for a long time, and AQ is not specific to x264. Haali wrote an AQ patch long before submitting to to x264. However, there is something special about x264's AQ implementation, at least in terms of testing and results

The AQ implementations are not the same. They are not equivalent - for whatever reason the others don't work as well. When you test on AQ sensitive test sequences and test varying AQ values, the effect is dramatically different. So between those encoders , in terms of the effect of AQ - no they are not on equal footing

x265 should eventually work ok, but the early AQ implementation wasn't working very well. I notice the last few weeks a bunch of patches were submitted

[johnsonchang]

Currently x.264 is the best, it can support many device and get high quality video and audio. But in future, H.265 shall be the best to load 4K videos and even higher resolution videos. It saves space and make the video smaller with high quality.

[sophisticles]

AQ has been around for a long time, and AQ is not specific to x264. Haali wrote an AQ patch long before submitting to to x264. However, there is something special about x264's AQ implementation, at least in terms of testing and results

The AQ implementations are not the same. They are not equivalent - for whatever reason the others don't work as well. When you test on AQ sensitive test sequences and test varying AQ values, the effect is dramatically different. So between those encoders , in terms of the effect of AQ - no they are not on equal footing

x265 should eventually work ok, but the early AQ implementation wasn't working very well. I notice the last few weeks a bunch of patches were submitted

This smacks of looking at x264's AQ through rose colored glasses. As far as I know xvid's Trellis and AQ were ported to xvid by the x264 developers, is this not the case. If it is then why wouldn't they work as well as the exact same code found in x264? Same with x265, near as I can tell the x265 developers basically copied most of the code straight from x264, they admit to lifting the code for Trellis, CABAC, AQ, much of the frame work straight from x264, so why shouldn't it work just as good.

Theora now also has AQ, even though it supported the feature for years, no encoder used it but now they will, so will Theora now become as good as x264 as far as you're concerned.

For me, it seems like the single feature that most affects encoding quality is sub me, Trellis I'm not too crazy about, at times Trellis 2 seems to blur the picture a bit.

[Mephesto]

MB-tree still vastly improves the quality at high qcomps.

With certain sources, but it requires AQ enabled to work so now you are left with AQ's baggage and I still think you're better off using a constant quantizer than a localized variable quantizer.

MB-tree improves the quality anywhere from 2-80% depending on the video, not on the qcomp.

For me, it seems like the single feature that most affects encoding quality is sub me, Trellis I'm not too crazy about, at times Trellis 2 seems to blur the picture a bit.

No, number of refs and ME are the most important, the subme is a bonus to the ME method and not that important for higher resolution videos.

[poisondeathray]

AQ has been around for a long time, and AQ is not specific to x264. Haali wrote an AQ patch long before submitting to to x264. However, there is something special about x264's AQ implementation, at least in terms of testing and results

The AQ implementations are not the same. They are not equivalent - for whatever reason the others don't work as well. When you test on AQ sensitive test sequences and test varying AQ values, the effect is dramatically different. So between those encoders , in terms of the effect of AQ - no they are not on equal footing

x265 should eventually work ok, but the early AQ implementation wasn't working very well. I notice the last few weeks a bunch of patches were submitted

This smacks of looking at x264's AQ through rose colored glasses. As far as I know xvid's Trellis and AQ were ported to xvid by the x264 developers, is this not the case. If it is then why wouldn't they work as well as the exact same code found in x264? Same with x265, near as I can tell the x265 developers basically copied most of the code straight from x264, they admit to lifting the code for Trellis, CABAC, AQ, much of the frame work straight from x264, so why shouldn't it work just as good.

Without a doubt, it doesn't work as well. 100% certain.

Xvid for certain. Mainconcept for certain (it's closest mode to x264's AQ is luminance mode, not complexity or contrast). x265 for certain (at least regarding builds a few months old, the AQ problem was well documented back then).

I've posted AQ testing examples for the 1st two either here or on doom9, but you have to look 4-5 years back

Yes, Fiona ported the AQ patch to xvid years ago, but there a checkbox, not a strength control. It has an effect , but it's tiny compared to the dramatic effect that you see with x264

Theora now also has AQ, even though it supported the feature for years, no encoder used it but now they will, so will Theora now become as good as x264 as far as you're concerned.

For me, it seems like the single feature that most affects encoding quality is sub me, Trellis I'm not too crazy about, at times Trellis 2 seems to blur the picture a bit.

So now you're putting words in my mouth. I said nothing about theora .

At the time, x264 was mediocre. It's AQ implementation is largely the reason why it propelled ahead. That's what put it over the top. If you disable AQ - on most testing scenarios, the encodes suffer and suffer greatly. x264 still has other features theora doesn't have, I never said AQ is the only reason. You always seem to take these logical jumps that lead you to the wrong place. Bad track record for you in this thread in that regard. Even AQ if gets ported to theora it doesn't mean that implementation will work as well. If xvid, or Hcenc (yes, mpeg2 has it too) are of any indication, it won't work as well

Yes, definitely subme 0 is going to negatively affect quality dramatically too. I was mentioning AQ as an added feature or patch. If you say something like the added subme 10 patch - that's basically worthless : huge diminishing returns over something like 7,8 or 9. Negligible.

[poisondeathray]

@sophisticles -

For someone who claims they've used x264 more than casually... I really begin to question that judging from some of the comments you've made. This stuff has been established, years ago. You seem to be aware of some of the common x264 weakness , and yet you advocate qp encoding, and not using AQ ? You claim 2pass is much better than CRF and avoids those problems. Sorry it just doesn't make any sense to people who actually use the encoder. It might feel like you're getting "ganged up" on but that's not anybody's intention here. Either you haven't really looked at your encodes closely, or you haven't done the testing in a scientific fashion, controlled and properly.

Enough "armchair quarterbacking," or theoretical reasoning . It's easy to demonstrate these findings. And don't take some of my old examples , or my word for it, or someone else's. I urge you to go do some actual controlled tests to see for your own eyes. That's how you learn. And if you find different results, please share them. That's how everybody learns. I always on the lookout for cases that act "differently" , and see what might be causing it

Compare --qp encodes (where AQ is disabled) with AQ 0, 0.5, 1, 1.5, 2 . Obviously do the qp encode first, then use bitrate encodes to match (or if you want incremental crf encodes, but it's more work to find the equivalent bitrate) . Do this on "AQ sensitive" material, like blue skies, gradients, shadowy areas etc..., and use higher qp's or lower bitrate ranges (compared to content complexity) to begin with - so you can see the differences and trends easily if your eye isn't trained for it . Once you get a feeling for what is going on, then start to move to other source materials and bitrate ranges. When you do incremental tests like this changing 1 setting at a time on various source materials, you will get an understanding of how the settings work for that particular encoder and in different situations . Then repeat the tests for xvid etc... with the AQ patch and without, then mainconcept from -100 to +100 for each or all of the complexity settings (obviously not single values, but maybe -100, -50, 0, 50, 100). x265 is in a big state of flux ,, so I would hesitate to do a battery of tests right now. I typically take a snapshot every few month and check progress

So no more theoretical reasoning crap, but real proof of how an encoder behaves in certain situations.

[hello_hello]

Consider this, a common suggestion for improving quality of encodes is to set qcomp to 0.9, if you set qcomp to 1 you have constant quantizer mode, even if you're using CRF and you have disabled MB-Tree.

If you set qcomp to 0.1 MB-Tree is at it's strongest and at qcomp 0.0 you now have cbr mode.

So what conclusions do you draw from this?

The higher the bitrate, the better the quality?
CBR is wasteful?
I'm not really sure.

There's no conclusion to be drawn until you're comparing settings at the same bitrate. You didn't answer my previous CRF vs CQ quality question, but the same question applies to CRF vs CBR at the same average bitrate, although I'm not sure I understand the point you're trying to make.

Couldn't you settle everything with a few samples? CRF with default x264 settings vs your preferred x264 settings at the same average bitrate? Any bitrate of your choosing. Or even CRF vs an entirely different encoder if you like (as long as settings result in a similar encoding speed). Something that shows CRF is not as good as "insert preferred alternative here" at a given bitrate.
I image you should be able to run a CRF encode showing CRF's weaknesses, then use the resulting bitrate for a 2 pass encode with "insert preferred alternative here" fairly easily.

[Detmek]

What?! That does not make any sence. If you encode clean video with crappy encoder output will be crap. But if you encode a clean video with good encoder it will look transparent.

I can conclusively prove you 100% wrong on this point and quite easily at that. Are you familiar with the movie Tears of Steel? download the mp4 version encoded with x264 and compare it with the webm version encoded with vp8, I defy anyone to find any differences between the two encodes. In fact the x264 version was encoded at a higher bit rate, check it out for yourself:

http://ftp.nluug.nl/pub/graphics/blender/demo/movies/ToS/

Quality of video is influenced primarily by how it's shot, the quality of the camera, quality of lens, settings used, lighting, film stock (if shot on film), scanning procedure (for film transfers), proper framing and grading, filters used and quality of intermediate codec used, often a lossless or high quality mezzanine codec, usually ProRes or Avid's offerings.

At this point we have the "master" which is used as source for creating the distribution format, that's where codecs like x264 come into play.

If we have a crisp, clear master, it doesn't matter what codec you use, divx, xvid, vp8, x264, x265, whatever, you will get a clean encode.


The two biggest factors in a high quality encode is quality of the master and bit rate used. this is well known in production circles, garbage in garbage out, just because you use encoder "x" does not mean that somehow your encode will magically be improved.

I downloaded all three 1080p versions, VP8, x264 and Theora.

Well, I would say "master in - crap out". Did you actually compare any of these encodes with original?


And I can tell you, there is a difference among codecs. Lets start from the worst - Theora.

Compete loss of grain from original, complete detail loss, blurry, macroblocks everywhere. Very bad compared to original. It reminds me on old Divx/Xvid encoded movies.

A bit better is VP8.

It lost all of the grain from original, color blocks in dark areas and on some parts of the flat areas, texture of the shirt is not very well preserved (loss of fine details) and small problems on edges. Better then Theora but not good.

x264:

Some of the original grain is there but not all, loss of details in dark areas, some of the texture is preserved, a bit sharper edges compared to VP8. Anyway, the best version among these tree but not really that good compared to original.

Now about codec settings. I don't know what they used for Theora and VP8 as MediaInfo does not show but I can see x264 settings. OMG!

[QUOTE]cabac=0 / ref=2 / deblock=1:0:0 / analyse=0x1:0x111 / me=dia / subme=6 / psy=0 / mixed_ref=0 / me_range=16 / chroma_me=1 / trellis=0 / 8x8dct=0 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=0 / threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=0 / b_adapt=1 / b_bias=0 / direct=3 / weightb=0 / open_gop=0 / weightp=2 / keyint=18 / keyint_min=10 / scenecut=40 / intra_refresh=0 / rc_lookahead=18 / rc=cbr / mbtree=0 / bitrate=6500 / ratetol=1.0 / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / vbv_maxrate=6500 / vbv_bufsize=1835 / nal_hrd=none / ip_ratio=1.40 / pb_ratio=1.30 / aq=1:1.00[/QUOTE]

Why would anyone disable CABAC? It is a free, lossless filesize reduction. And up to 20%.

They could use something more that me dia, at least default hex. And in some situations me umh makes visible difference compared to hex (I noticed when I encoded Warcraft 3 TFT).

More partitions would help, too.

Why no B-pyramid? It helps with bitrate based encoding as it allows more B-frames compared to less efficient P frames and thus some bits can be used to increase a quality of I and P frames. And B-frames too.

Why so short keyint? Only 18. Even Blu-Ray spec uses 24-48 keyframes. Unnecessary large number of I frames with limited bitrate does not help, it hurts quality.

VBV-maxrate=6500 and VBV-buffsize=1835?!?! Why, on earth would one use such a low constrains? This kills quality a lot, especially such a low buffer size.

And finally - 1-pass CBR mode?! Whoever encoded this video did not have quality in mind.

One more thing. Earlier in discussion you said that videos on torrent are very low quality. If you find this videos of very high quality then.... I really don't know what to say.

Oh, and this:

So no more theoretical reasoning crap, but real proof of how an encoder behaves in certain situations.

We did a lot of test and showed you the results. I think it is your turn to do some tests and show us your results that back up your statements.

[hello_hello]

Why would anyone disable CABAC? It is a free, lossless filesize reduction. And up to 20%.

iTunes video at 720p seems to always be without CABAC. I assume it's something to do with compatibility with old AppleTV players. Maybe they only support the Baseline profile. The frame rate also seems to max out at 24fps. Anything higher and they go anamorphic (960x720, 16:9).
Not that it probably has anything to do with why CABAC is disabled here. Very odd x264 settings indeed.

I'd pretty much agree with your assessment of the encodes based on the pics you posted. None of them are "high quality". There's also a slight colour difference between the original and the encodes. I'm not sure why. Maybe some sort of colorimetry problem but at least it's consistent for all three encodes.

The claim:
"If we have a crisp, clear master, it doesn't matter what codec you use, divx, xvid, vp8, x264, x265, whatever, you will get a clean encode."
is odd because if you take it to it's logical conclusion, it means if you have a crisp clear master, it shouldn't matter what encoder settings you use. Obviously it does.

The "doesn't matter" claim might start to apply at very high bitrates, but even then...... I've resized HD to SD and encoded with both Xvid (maximum quality) and x264 (CRF18) to compare the result and without any resizing on playback there's usually obvious differences while it's chalk and cheese when you upscale the encodes back to 1080p (default Xvid and x264 settings).

[Detmek]

It might not be Apple TV compliant but it looks like settings are inspired by that preset.
About color problem. It might be on my end as I used Avisynth with ffvideosource to decode files and MPC-BE to capture screenshots (Save image captures before render, right?).

[hello_hello]

About color problem. It might be on my end as I used Avisynth with ffvideosource to decode files and MPC-BE to capture screenshots (Save image captures before render, right?).

I might try not thinking about that one.

I don't use the File/SaveImage menu all that much so I'm really not sure what to expect. MPC-BE mightn't always do things the way MPC-HC does anyway (I use the latter). It's not important in respect to this topic....I just thought I'd mention it.

[sophisticles]

It might not be Apple TV compliant but it looks like settings are inspired by that preset.
About color problem. It might be on my end as I used Avisynth with ffvideosource to decode files and MPC-BE to capture screenshots (Save image captures before render, right?).

Congratulations, you just admitted that you don't know what you're doing.

You decoded the files with Avisynth with ffvideosource and then used MPC-BE to capture the screen shots?

How about you uninstall that garbage from your system, simply use MPC-HC to view the files and assess quality and then export screenshot without all that decoding crap in between.

In 2 short sentences you just explained how people arrive at the conclusion that x264 is so much better than everything else, because they have no idea how to properly play back content.

[_Al_]

whoa , man, there is no end to this thread, if you are going to come up with stuff like that

[Detmek]

It might not be Apple TV compliant but it looks like settings are inspired by that preset.
About color problem. It might be on my end as I used Avisynth with ffvideosource to decode files and MPC-BE to capture screenshots (Save image captures before render, right?).

Congratulations, you just admitted that you don't know what you're doing.

You decoded the files with Avisynth with ffvideosource and then used MPC-BE to capture the screen shots?

How about you uninstall that garbage from your system, simply use MPC-HC to view the files and assess quality and then export screenshot without all that decoding crap in between.

In 2 short sentences you just explained how people arrive at the conclusion that x264 is so much better than everything else, because they have no idea how to properly play back content.

OK. Decoded directlly with MPC-HC x86 1.7.7.183 using internal LAV Filters and madVR. Captured with Save Image.

Theora:


VP8:


x264:


Any smart comments now?

The only crap on this forum is your writing. You know nothing and you have no proof to back up any of your claims. As far as I can see, any discussion with you is a waste of time. For everyone else participating in this thread, thank you. I learned a few new things and got reminded of some things I forgot.

[sophisticles]

Any smart comments now?

Just this, cherry picking one screenshot from each encode proves that you can't be trusted to offer an objective opinion.

For some reason the forum is having problems at the moment and I am unable to upload the test samples I encoded but as soon as the forum is responding again, I will upload the samples.

In the meantime, feel free to keep misleading those following this thread.

[hello_hello]

Congratulations, you just admitted that you don't know what you're doing.

You decoded the files with Avisynth with ffvideosource and then used MPC-BE to capture the screen shots?

How about you uninstall that garbage from your system, simply use MPC-HC to view the files and assess quality and then export screenshot without all that decoding crap in between.

In 2 short sentences you just explained how people arrive at the conclusion that x264 is so much better than everything else, because they have no idea how to properly play back content.

Lets not over-react. There's no garbage to uninstall.
I'll confess I wondered "why do it that way" myself, but I figured maybe he had a reason and I didn't bother asking as it shouldn't make a difference anyway. The video's being decoded. AVIsynth is frameserving the uncompressed version. MPC-BE is displaying it. Viewing video with the AVISynth/MPC-BE combination should look identical to opening it directly with MPC-BE.

I do the same thing regularly to compare scripts before the video is encoded. Assuming the video was opened the same way each time it couldn't bias the result in x264's favour. Claiming it proved why people think x264 is better seems fairly illogical to me.

[hello_hello]

About color problem. It might be on my end as I used Avisynth with ffvideosource to decode files and MPC-BE to capture screenshots (Save image captures before render, right?).

I was messing around with something else today so I checked and yes, for 1080p Rec.709 video decoded via L-Smash (ffms2 kept freaking out), AVISynth and MPC-HC, the video displayed with Rec.601 colorimetry.
I'm not sure why. According to MPC-HC the video from AVISynth is YV12, so obviously it's not converted to RGB before it gets to MPC-HC. Maybe it's just a Windows renderer oddness that stops it from picking a colorimetry as it normally would because the video isn't compressed.

It's not something I'd paid much attention to. Not unless the encoded video ends up displaying with a different colorimetry for some reason.
I've compared script with script using MPC-HC lots of times, but maybe not script and source quite as often, or when I have it's been a standard definition one. Anyway, I assume it's normal behaviour but I'm not really sure why.

Edit: A quick test indicates MeGUI's preview uses the wrong colorimatry for the video in question, as does VirtualDub's preview. Odd.

[Detmek]

Ffms2 through avisynth does not send color matrix information even if video stream contains one. In that situation every single render (didn't test Haali as I don't have it installed) except madVR uses BT.601, no matter what is resolution of video file. VirtualDub and MeGUI preview windows use some of the system renders so those will always display video with BT.601 colorimetry. You didn't noticed that with SD video because SD video always uses BT.601 for conversion to RGB.

Oh, and I initially used avisynth + ffms2 because I use VirtualDub to framestep through video. But, because I couldn't take screenshots with VirtualDub I just opened that avs script with MPC-BE.

[hello_hello]

So where is the colorimetry decided if not by the renderer? I've never really understood.

As you know, if you encode a HD video while resizing to standard definition the colours will look different on playback.
You can even simulate it with ffdshow (outputting YUV). Open a HD video with MPC-HC and ffdshow decoding and enable ffdshow's resize filter. Resize it down to standard definition. Run MPC-HC maximised. While the video's playing, enable and disable ffdshow's resize filter. That makes it fairly easy to see the colour difference as with the player maximised the picture size doesn't change. It's how I discovered the formula used by Windows, or the Windows renderers, or wherever the "use this colorimetry" decision is made, is a bit dumb and some HD video displays as rec.601. I can't remember the exact cut-off, but anything with a height less than roughly 688 is displayed as rec.601, which means lots of cropped 720p encodes with resolutions such as 1280x544 don't display with the correct colours.

Anyway, I digress.... if AVIsynth is providing MPC-HC with uncompressed YUV and ffdshow does the same (I assume), why doesn't the latter use rec.601 all the time too?

[hello_hello]

For some reason the forum is having problems at the moment and I am unable to upload the test samples I encoded but as soon as the forum is responding again, I will upload the samples.

Any forecast regarding ETA?

I'm still interested in some "CRF with default x264 settings" vs "sophisticles preferred x264 settings" at the same bitrate samples. Any chance of that happening?

[hello_hello]

For some reason the forum is having problems at the moment and I am unable to upload the test samples I encoded but as soon as the forum is responding again, I will upload the samples.

Any forecast regarding ETA?

I'm still interested in some "CRF with default x264 settings" vs "sophisticles preferred x264 settings" at the same bitrate samples. Any chance of that happening?

It looks like the "show us some samples" stage of the discussion has once again resulted in a thread-stopper.

[sophisticles]

For some reason the forum is having problems at the moment and I am unable to upload the test samples I encoded but as soon as the forum is responding again, I will upload the samples.

Any forecast regarding ETA?

I'm still interested in some "CRF with default x264 settings" vs "sophisticles preferred x264 settings" at the same bitrate samples. Any chance of that happening?

It looks like the "show us some samples" stage of the discussion has once again resulted in a thread-stopper.

The reasons for the thread stopper are numerous:

My tests with some y4m sources available to me resulted in some really odd results, namely the Sintel trailer proved to be very easy to encode with extremely high quality, regardless of codec or settings used. Elephant's Dream proved to be extremely hard to encode with high quality, especially one portion of it that looked like garbage no matter what settings I used, unless I used a very high bit rate. With that test, CRF did in fact result in the best encode, both subjectively and as measured by PSNR and SSIM, though the Divx Hevc encoder would beat x264.

I also did a number of tests with Tears of Steel and a few other y4m sources, though I wanted to hold off until Selur fixed the broken x265 support in hybrid so that I could include some x265 tests.

Lastly, there was the slight issue of that blizzard that hit the North East, which buried us under about 2 feet of snow and as a result I ended up driving nearly 24 hours in a 36 hour window because the company I work for needed thousands of emergency labs picked up and I volunteered to do it.

But don't fret, I will be posting some test encodes soon, maybe on Sat or Sun before the SB.

[El Heggunte]

Is x264 the best?

Nope, Kisarah Westfield is the best

https://forum.videohelp.com/attachments/29704-1421195267/kisarah-the-best.png

OK, now you can go back to the topic

[SameSelf]

I feel a little sheepish for having asked what I thought was a simple question and floored by the pages and pages of discussion it generated. However, I don't regret it because I learned some valuable things. Keep on trucking

[BrianBD]

To give you an example, one of the largest adult sites in the world, Brazzers, uses the x264pro plugin for Adobe Premiere for their content with the "slow" preset. On the other hand Digital Playground, which is widely considered to have the crispest, cleanest videos available uses the excellent Sirius Pixels encoder:

http://www.siriuspixels.com/customers.php

http://www.siriuspixels.com/imagegallery.php

The list of Blu-Rays created with this encoder is impressive and among the highest quality I have ever seen. This encoder is based on the "old" CCe HD AVC encoder and if you can afford it you won't find a better product.

It's not cheap though, this similar product, not sure if it's made by the same people but has a similar name and is based on the same code base costs comparable to what Main Concept's offering do

I have used Cinemacraft HDe AVC encoder in the past at our Studio and have recently done a Trade-In/Upgrade to the Sirius Pixels HDe AVC Encoder. I can assure you the code for the Sirius Pixels HDe AVC encoder has a completely newly developed encoding engine which was developed from the ground floor up and the picture quality is superior with Sirius Pixels. It is not the same code as Cinemacraft.
The Sirius Pixels HDe AVC encoder also supports Native Ingest of “ALL” the Apple ProRes family of codecs. And, on my Sandy Bridge Workstation, I can get over 2 times faster than real time encoding speed.
Here is their website: http://www.siriuspixels.com/Sirius-Pixels-HDe-AVC.php
BTW, since Cinemacraft several years ago went belly-up, the same CORE TEAM that developed their products for over 11 years are at Sirius Pixels developing new Advanced Products along with the upcoming Ultra HD Blu-ray encoder.