HandBrake

I may not be communicating groundbreaking, unknown information, but my experience so far with HandBrake is that the type of content you are encoding is EVERYTHING as far as settings or even encoders.

I have a relatively slow machine, and my x.264 encodes take days. I am encoding episodes of The Simpsons (which I own, BTW).

The animation in The Simpsons is not the most complex and detailed--fairly primitive with lots of solid colors. I gave FFMPEG a try (2-pass) and not only did it encode in about 1/8th the time of x.264, but the results were excellent!

I was able to fill up the Queue and go to bed. (Something I could never do with x.264 encodes.)

I watched the resulting FFMPEG encodes with the lights out, my face trained on the screen at all times (I barely blinked), and I saw NOT ONE instance of combing or interlacing in the FFMPEG encoded material!

I can't help it if people don't believe there was absolutely no combing, it is just what I have to factually report.

I think I may use FFMPEG to encode the rest of the episodes I intend to encode for a "Best Of" Simpsons DVD.

If the content were different, FFMPEG may not have worked as well as it did on The Simpsons episodes.

So I will probably use x.264 for other content.

If there was a downside, it was that the FFMPEG encoded episodes were about 100MB larger than x.264 encoded episodes, so the compression is obviously not as good.

But the FFMPEG encoded material ran like magic when played in Quicktime (actual size). It didn't stutter once and played at full frame rates.

Sometimes the x.264 encodes cause QuickTime to stutter, halt for long periods, or cause the frame rate to drop.

But it looks like I may be using FFMPEG at least for the rest of my The Simpsons encodes, but will probably use x.264 for different material.

I'm glad FFMPEG is available under HandBrake.

defender

Glad you found your encoding settings but please realize that combing/interlacing has nothing to do with your choice of encoder.
Also H.264 isn't about quality, it's about Quality over Size, thus explaining why you can get the same quality in a a larger file with ffmpeg.

realityking wrote:Glad you found your encoding settings but please realize that combing/interlacing has nothing to do with your choice of encoder.
Also H.264 isn't about quality, it's about Quality over Size, thus explaining why you can get the same quality in a a larger file with ffmpeg.

Hmmmm...

I hear what you're saying, but I DID get combing with 264 using the default Decomb settings under "Picture," but did NOT get them using FFMPEG (also with the same default Decomb settings under "Picture.") I have no explanation why.

Not a complaint about HandBrake and 264; just a factual observation.

And you're absolutely right about Quality vs. Size. As I mentioned the FFMPEG encodes were about 100MB fatter than the x.264 encodes.

defender

defender wrote:I hear what you're saying, but I DID get combing with 264 using the default Decomb settings under "Picture," but did NOT get them using FFMPEG (also with the same default Decomb settings under "Picture.") I have no explanation why.

Um, what?

You've been given the explanation over and over. You are using a video encoder with very low quality.

jbrjake wrote:

defender wrote:I hear what you're saying, but I DID get combing with 264 using the default Decomb settings under "Picture," but did NOT get them using FFMPEG (also with the same default Decomb settings under "Picture.") I have no explanation why.

Um, what?

You've been given the explanation over and over. You are using a video encoder with very low quality.

I have not been "giving that explanation over and over"; I think I mentioned something similar one time previously. You exaggerate.

I wrote to give my findings to other HandBrake users in an effort to (possibly) be helpful.

I can't help it that I didn't notice any combing with FFMPEG but did with H.264, it's just the facts as I can report them--not an implicit criticism (as you seem to take any such observation).

I'm sure you're right that FFMPEG is a low quality encoder. That's why I said it all depends on the content, and The Simpsons appears to lend itself to encoding with FFMPEG.

The Simpsons animation is not the most complex; fairly primitive with lots of solid colors. And my observation is that FFMPEG worked great with this particular content. And I'm very glad that it is offered as an option in HandBrake.

I will surely use H.264 with different content.

And BTW, I post and ask questions in these forums to get advice and help, but every time that you respond to my posts you pick them apart and criticize them--sometimes even flame me, like the time you wrote "you are a moron."

These are not the kind of comments that are at all helpful to someone seeking help, and I dare say they don't belong in this forum (if it is to be a quality, mature forum).

As I said, I am seeking help from knowledgeable people, so if you're only going to criticize the way I post but offer no enlightening observations I would rather you not respond to my posts at all. It is not helpful.

defender

defender wrote:I'm sure you're right that FFMPEG is a low quality encoder. That's why I said it all depends on the content, and The Simpsons appears to lend itself to encoding with FFMPEG.

I'm saying it's so low-quality it can't reproduce one-pixel tall details. You're not seeing the combing because the encoder is so bad it can't preserve any detail. It has nothing to do with the content. You're losing a lot more than combing.

That sounds like something to tout as a feature of the encoder: always on deinterlacing without any loss of speed!

jbrjake wrote: I'm saying it's so low-quality it can't reproduce one-pixel tall details. You're not seeing the combing because the encoder is so bad it can't preserve any detail. It has nothing to do with the content. You're losing a lot more than combing.

Can't even produce 1 pixel tall details! I did not know that! Thanx.

Nehalem Mac Pro on the way. Slow H.264 encodes will not be (or be MUCH less) of a problem for me!

defender

belloq wrote:That sounds like something to tout as a feature of the encoder: always on deinterlacing without any loss of speed!

Do you mean the Decombing option under "Picture" or the Deinterlace option under H.264 Advanced Options.

If I understand correctly the Deinterlace H.264 option compares EVERY frame and can cause a loss in sharpness -- not to mention slowing the encode to a crawl.

Please correct me if I'm wrong.

Thanx,

defender

defender wrote:

belloq wrote:That sounds like something to tout as a feature of the encoder: always on deinterlacing without any loss of speed!

Do you mean the Decombing option under "Picture" or the Deinterlace option under H.264 Advanced Options.

If I understand correctly the Deinterlace H.264 option compares EVERY frame and can cause a loss in sharpness -- not to mention slowing the encode to a crawl.

Please correct me if I'm wrong.

Thanx,

defender

ok you have to reread this thread carefully
basically deinterlacing is something to do with the source -- and so is deblocking in the filters tab. both 'filter' the source video to deinterlace or deblock.

the deblocking under the advanced tab is about something called a loop filter that H.264 uses (and afaik is one of the major advancements of x264 over xvid). i wouldn't really mess with that, people who know a *lot* about x264 barely ever touch it even.

refulgentis wrote: ok you have to reread this thread carefully
basically deinterlacing is something to do with the source -- and so is deblocking in the filters tab. both 'filter' the source video to deinterlace or deblock.

the deblocking under the advanced tab is about something called a loop filter that H.264 uses (and afaik is one of the major advancements of x264 over xvid). i wouldn't really mess with that, people who know a *lot* about x264 barely ever touch it even.

OKIC.

Thanks,

defender

P.S. I leave Deblock at 0,0 (which has been explained that it doesn't mean no deblocking is occurring). Can Deblock degrade picture sharpness?

Also, have the facts changed on the use of "psy-rd"? I have read documentation that says you need a Subpixel Motion Estimation setting = to or >6 in order for psy-rd to work at all, and that you need to set Trellis to 1. I have done so and use "psy-rd=0.5,0.3, set Trellis to 1 and Subpixel Motion Estimation to 6.

Is the documentation I got this from obsolete? Has the H.264 codec changed such that I can use Subpixel Motion Estimation=9 and Trellis=2?

Any help is appreciated.

defender wrote:

refulgentis wrote: ok you have to reread this thread carefully
basically deinterlacing is something to do with the source -- and so is deblocking in the filters tab. both 'filter' the source video to deinterlace or deblock.

the deblocking under the advanced tab is about something called a loop filter that H.264 uses (and afaik is one of the major advancements of x264 over xvid). i wouldn't really mess with that, people who know a *lot* about x264 barely ever touch it even.

OKIC.

Thanks,

defender

P.S. I leave Deblock at 0,0 (which has been explained that it doesn't mean no deblocking is occurring). Can Deblock degrade picture sharpness?

Also, have the facts changed on the use of "psy-rd"? I have read documentation that says you need a Subpixel Motion Estimation setting = to or >6 in order for psy-rd to work at all, and that you need to set Trellis to 1. I have done so and use "psy-rd=0.5,0.3, set Trellis to 1 and Subpixel Motion Estimation to 6.

Is the documentation I got this from obsolete? Has the H.264 codec changed such that I can use Subpixel Motion Estimation=9 and Trellis=2?

Any help is appreciated.

Trellis 2 will work with psy-trellis. I don't understand deblock as it relates to H.264, but only a fool would touch it without very good reasoning based on the advice I see given elsewhere. You can use subme > or = to 6, so subme 9 is fine too.

refulgentis wrote:Trellis 2 will work with psy-trellis. I don't understand deblock as it relates to H.264, but only a fool would touch it without very good reasoning based on the advice I see given elsewhere. You can use subme > or = to 6, so subme 9 is fine too.

My bad. I got my mathematical signs mixed up. I read that SubMe has to be equal to or less than 6 for psy-rd to work and that Trellis has to be 0 or 1, but not 2. I hope the documentation I got this stuff from has been superannuated by a newer version of the H.264 codec.

defender

defender wrote:

refulgentis wrote:Trellis 2 will work with psy-trellis. I don't understand deblock as it relates to H.264, but only a fool would touch it without very good reasoning based on the advice I see given elsewhere. You can use subme > or = to 6, so subme 9 is fine too.

My bad. I got my mathematical signs mixed up. I read that SubMe has to be equal to or less than 6 for psy-rd to work and that Trellis has to be 0 or 1, but not 2. I hope the documentation I got this stuff from has been superannuated by a newer version of the H.264 codec.

defender

all these options have really nothing to do with H.264 itself. H.264 is a specification defines a way that a movie document should be 'written', it doesn't define how exactly that writing is done. All these settings are specific to x264, an encoder that happens to produce H.264-compliant streams.