That’s really up to your taste. Trellis on the final MB is good enough in most cases. Trellis ran on all MBs can kill detail in some cases but when you watch the movie (as in frames constantly moving) you’ll probably not notice it. But if you take two screenshots of the exact same frame, one shot of Trellis only on final MB and one shot of Trellis on all MBs, you’ll find that there’s a bit of loss of detail in the Trellis on all MBs screenshot. But like I said, you don’t watch a movie frame-by-frame so it’ll probably doesn’t matter as you wouldn’t notice it, unless you have alien eyes. Also, Trellis on all MBs (aka trellis=2) increases compression more than Trellis only on final MBs (aka trellis=1)
Which values are to set in “Deblocking” under Tab “Miscellaneus” if DECOMB is already enabled in the picture settings?
Deblock != Decomb filter of HB. Decomb looks at each frame individually and deinterlaces it if needed. So it is an adaptive deinterlacer, resembling the kernel deinterlacer by Donald Graft present in MPlayer. Decomb can be set on by default since it’ll always skip progressive frames
Deblock is an x264 in-loop deblocker which eliminates MB blocking artifacts when needed. Higher values will deblock stronger but also blur the content. Lower values will deblock less but also increase visability of blocking. The default values of 0:0 should be used in most cases, unless you really need to change them. In general, these values should be no lower than -3 and no higher than 3, with optimal for most cases being for both 0
Is there even a difference between “Deblock” in the picture settings and “Deblocking” in x264?
Yes, “deblock in the picture”, as you wrote it, is a postprocessing filter. This means that if you already have a file with strong blocking artifacts, this filter will deblock it before passing it over to x264 for encoding. The in-loop deblocker works on the encode itself (and decode), as in it deblocks artifacts produced by x264 itself, though it can also eliminate those present in the input file but generally it’s good practice to use a postprocessor deblocker if oyu have blocks in the content before passing it over to x264
Enable Mixer Refs and weighted prediction in B-Frames and Pyramidal B-Frames
Set B-Frames decision to “optimal”
Set direct prediction to Auto
Disable both fast P-frame skipping and DCT decimation
Set Psy-RD to 0.8 and Psy-trellis to 0.2
Use Uneven Multihexagon motion search and set motion range to 24
Set Subpixel refinement to 9 or 10
Nota that this overflows DPB (decoded picture buffer) and will not be compatible with stand-alone hardware players, especially if you intend to create BD compliant H.264 streams
Thanks microchip for providing these settings. One part is still unclear for me: You’ve recommended to…
Maximum of Multihexagon motion search is 64. So why exactly use 24 and not a smaller value or even all range?
Another thing I’m still coping with is the encoding procedure in general. I know that 2-pass is generally a better method for encoding as the source material will be analyzed much more throughly.
On the HandBrake forum as well as in some threads on doom9.org I’ve read that one is able to accomplish a much better quality encoding with running a 1-pass encoding with the preset that should be applied to the ripping, afterwards taking a note of the outcoming bitrate and then plug this bitrate for a full 2-pass encoding.
Is this still a recommended common practice?
Wouldn’t it make much more sense to take the bitrate of the original DVD movie and use that directly for a 2-pass encoding?
There’s no clipping inside the motion search range. You can use 256, 512 or even 10000 if you want. The question here is, does it make sense to use such high value? For DVD content it certainly doesn’t and 24 is optimal, though if you wish you could set it to 32 but you won’t see any difference between 24 and 32 - I always use 24. Smaller search range values decrease the range the motion search looks for best candidate motion vectors, ie it “decreases” quality a bit… The value is expressed in pixels… For HD content it makes sense to use higher values dueo to its higher resolution. Also keep in mind that the higher the value, the more it’ll considerably slow down the encoding
Another thing I’m still coping with is the encoding procedure in general. I know that 2-pass is generally a better method for encoding as the source material will be analyzed much more throughly.
On the HandBrake forum as well as in some threads on doom9.org I’ve read that one is able to accomplish a much better quality encoding with running a 1-pass encoding with the preset that should be applied to the ripping, afterwards taking a note of the outcoming bitrate and then plug this bitrate for a full 2-pass encoding.
Is this still a recommended common practice?
I personally don’t do 2-pass encoding. I use 1-pass CRF constant rate factor mode which is just as good as 2-pass with the benefit that it saves you time. I “standardized” on a CRF value of 20 and HE-AACv1 @ 55 kbps for audio. That way I have across all my encodes the same quality level and don’t have to mess/care about which bitrate to use for each DVD I encode as DVDs differ and one may do just fine with say 800 kbps while another may require more or less. CRF automatically allocates bits needed using intelligent decision. Lower CRF values give more bits but increase file size while higher values use less bits and lower file size. Of course, with CRF there’s no way to predict what the final file size will be so if you’re concerned with that or you want to obtain a specific file size, then go for 2-pass. You can even do 3-pass (which h264enc supports) but the benefits are non-existent
Also the general public over at doom9 prefers using CRF instead of 2-pass
Wouldn’t it make much more sense to take the bitrate of the original DVD movie and use that directly for a 2-pass encoding?
Why? H.264 is designed to be 3x-4x more efficient than MPEG2 used on DVDs. The reason DVDs use such a high bitrate is due to MPEG2 being crap and needing it in order not to block or create other artifacts like banding or ringing. If you’re going to take the bitrate of the DVD and use that to feed x264 with, why are you encoding then? You might just as well copy the DVD 1:1 into a mpeg file and use that.
Mh… I personally don’t really “trust” this feature. When encoding with RF 0 (hey, that was just a test) then the filesize gets HUGE. It’s even bigger than the original file. Looks like RF 20 is recommended ( as this is the default for “High Profile”), I certainly want to keep the quality as close as possible to the original video. back when I used Gordian Knot (not sure you’ve ever used it) my files usually got around 1.8 to 2 GB in size. To squeeze the most out of the DVDs I’m encoding I’d even let it get larger. So two more questions arise for me:
With which CRF value am I as close as possible to the source while still using compression (otherwise I could just rip the VOBs)?
Which valuewould be recommended to use for HD content?
So you don’t trust the extensive tests done by me an many others on doom9 which conclude each time that 2-pass often does not offer any more benefit than CRF? Also, in x264, CRF of 0 is a special thing. It means to encode in lossless. Of course you’ll end up with a huge file size. That should be pretty obvious, no?. Like I said, CRF is intelligent algo and is capable of calculating/deciding how much bits a frame needs (or MBs need if you’re talk from this way)
With which CRF value am I as close as possible to the source while still using compression (otherwise I could just rip the VOBs)?
Which valuewould be recommended to use for HD content?
There’s no general rule on which CRF value will give you that. You need to test yourself, check with your eyes and see which CRF value gives the quality you like the most. Personally, I’d never go below 17. For me, 20 is enough. Some use 21 and even 24.
Also, and I write this in bold so once and for all you learn it, encoding inherently reduces quality no matter which options you use. The important question here is: can you notice this reduction of quality or not?
if you’re that obsessed with retaining the “perfect” quality, like I said many times, don’t encode and just copy 1:1 to an mpeg file
Hey, great! That was just what I was asking for. No more, no less. By the way: Should the number of Reference Frames always be equal to the number of B-Frames?
Just so you know, and I don’t like giving away too much the secrets part of The Art Of Encoding, there’s a general law or rather a rule: the trick is to find a balance which for you gives acceptable quality while at the same time for you gives also acceptable file size
No way. Are you reading secret books about this, hm? hehehe…
I still don’t know if the number of Reference Frames should be equal to the number of B-Frames.
No secret books, The Art Of Encoding is a known public “secret” which you’ll learn the more you learn about encoding itself
No. Frame references don’t depend on how many B-Frames you use or don’t use. For live footage (ie, live action/film content) 4 or 5 is a good value. Beyond it, the benefit drops considerably while at the same time it decreases encoding speed hugely. If however you’re encoding anime (ie, not CGI, live action/film, but cartoon/anime content), then even up to 16 can benefit a lot.
To answer your PM question, which you should really post here …
Should the number of Reference Frames be equal to the number of B-Frames?
No, see post above
Is it recommended to turn Deblock On in picture settings for high quality encoding? If so, which value is recommended there?
Not unless the original content is blocky, which most DVDs aren’t. Value? Depends on how strong it blocks. Too high a value can smear or blur too much
And my last question for today: Does high quality encoding need Denoise? I don’t think so.
Depends again. If you prefer to keep as much as possible or as close as possible to the original footage, then don’t denoise but keep in mind that more noise in content = more bits needed to retain/keep the noise. Also in most cases a tiny bit of noise can be beneficial as it acts as artificial dither which reduces banding artifacts.
If on the other hand you like clean pictures without any noise or grain, then denoise it. But keep in mind that there’s no perfect noise algo and even the best denoisers around will at some point mistake what is not noise to be noise and throw it away, thus killing detail/quality. Also, depending on the denoiser and values used, it can bring in banding, especially if the Chroma denoise value is set too high
Mh… right now I’m encoding a DVD with Reference Frames set to 5 and B-Frames set to 6. Shouldn’t be any problem then. I’ve been asking a lot and might have streched your nerves a bit. Again, thanks for your tremendous help today. If I could submit a vote somewhere, I’d vote for you to get entitled as MOD. You really earn a price for your patience and your contributions to this community. Have a good nights sleep now.
No problem, I can talk about encoding all day long. I’m kinda addicted to it
Also, I don’t wanna be a mod here on this forum for various reasons, but a reputation point is more than welcome
Indeed. While I don’t mind providing better defaults and/or better integration into openSUSE by patching upstream code, in this case I won’t. The HandBrake developers are very, very touchy on that subject, and it’s not necessarily wrong: if there is a problem/bug that someone reports to them, then they wouldn’t know whether it comes from my patches or not. Hence they would probably deny supporting those HandBrake openSUSE packages.
By the way, this is also why it ships with an outdated x264 library, in-tree, instead of using the latest x264 library package as provided by Packman: they know that it works with that particular version of x264 and have implemented the rest of HandBrake according to its features as well as working around its issues.
So if you want a newer x264 in there, poke the developers.
Yes, please poke the HandBrake developers about it. I’ll then happily build new snapshots and releases
If you want to get in touch with me regarding that package, or anything else, please contact me by email or on IRC (my nick there is “yaloki”), as unfortunately I don’t have the time to follow our forums
>
>Thanks for your reply microchip, I knew I’d receive a post from you. The
>following is the reply of the packman team regarding my request to
>include Handbrake in their repository:
>
>>
>> …
>> I’ve been working on HandBrake 0.9.3 for two days now, and finally
>> managed to package it locally.
>> I’m now submitting it to our Build Service instance and expecting a lot
>> of warnings from rpmlint, which I’ll fix before pushing it to the
>> Packman repository.
>> SO STAY TUNED, THE PACKAGES SHOULD BE AVAILABLE BY MONDAY.
>> The reason we didn’t package HandBrake before now is that it is a
>> major pain in the bottom to package. It uses a bizarre build system
>> with lots of in-tree libraries. It already took me 3 or 4 hours of work
>> so far.
>>
>> Why should we do weekly snapshot builds ?
>
>And why should they do weekly snapshot builds of HandBrake? Certainly
>because users of their repository prefer to be able to always use the
>“bleeding edge” of HandBrake.
>As this appears to be a rather stressy work I’ve offered to assist
>(which I would love to do by the way).
I’ve been using mencoder for a couple of years, but recently switched to Avidemux because of various problems with mencoder (poor b-frame A/V sync handling, bad A/V sync when using double-fps deinterlacer (yadif=1), complete inability to answer even the simple questions on the mailing list, general hostility of the developers, no supported stable release (what kind of 12-year old suggests always using the SVN version?), etc…).
Ever since I moved to Avidemux, I’ve been really happy with it. It has lots of plugins (ports from mencoder, virtualdub, avisynth, …). Sure, there are some things I’m still missing (nice audio filters, video noise (as opposed to denoise) plugin), but these are minor issues.
Avidemux has been suggested in another thread he started but he didn’t like it. Also, I don’t know about these “bad AV sync when using B-frames” and in all my years of using MEncoder always with b-frames, I’ve never experienced such things. Further, you shouldn’t do bobbing unless needed to but should deinterlace at normal FPS. When doing bobbing, both -fps and -ofps must be set at double frame rate values and the content should be pure interlaced, not a mixture of field-blending and interlacing or some other combination. Never had problems with that either. The mailing list is just fine and questions get answered (when people know the answer) but it may not be very quick. Avidemux itself has problems with b-frames. Ever tried to open a file in it which was encoded with pyramidal b-frames? See the warning it gives you
SVN is recommended because MPlayer’s codebase is kept stable at all times, which shows you don’t know how MPlayer does development at all in all those years and it’s been doing just fine
Ever since I moved to Avidemux, I’ve been really happy with it. It has lots of plugins (ports from mencoder, virtualdub, avisynth, …). Sure, there are some things I’m still missing (nice audio filters, video noise (as opposed to denoise) plugin), but these are minor issues.
Well, it’s “somewhat” documented that when using B-frames with avi files, mplayer delays the audio by 1 or 2 frames (depending on settings; b_pyramid causes 2). That’s 40 or 80ms for 25fps, which is quite annoying with music videos. Recent versions compensate that by setting the video delay to the same value at container level, which I think is a wrong way to fix that - it may cause problems with future use of that file (like merging, remuxing to other containers, etc…).
I asked at the mplayer mailing lists about the need to keep the delay when remuxing the avi file to mkv, but got no answer. Googling around did no good either. Since mencoder’s support for non-avi containers is, well, bad (read: not working), the constant remuxing without any guarantee that the result will be ok is really annoying.
In case you need to know why I want to use mkv instead of avi, there are mainly two reasons: 1. avi has no native support for VBR audio, and since mencoder’s only working output is avi, one has to wonder if that avi is actually valid. 2. I want chapters in my files.
Note that Avidemux supports mkv (and plenty of other formats) natively, so there is no need to make artificial delays or incorrect avi files.
Of course, I used it with correct pure interlaced source. I wanted to store the result in 50 fps file, because that gives the “best” results visually (IMHO, of course). I have yet to find a good same-fps deinterlacer (I really don’t like yadif=0, it gives lots of artifacts).
I always got ~150ms audio delay when using yadif=1 with mencoder. Yes, I asked them (twice), and the only answer I got was from another user who confirmed the problem.
This thing looked like a broken mencoder A/V auto-sync issue (and no, -mc 0 wasn’t an option). As an open-source programmer (:)), I tried fixing it myself. I was shocked when I opened the mencoder.c file. It looked like it was written by a man who compiled his first hello world just the day before. (Examples: lots of global variable names (I mean like 50 or more), almost no functions (the ones that exist have side effects on globals), almost no indentation, lots of spaghetti code, etc…). Needless to say, I just didn’t want to do anything with that code, ever.
Out of ~6 questions I asked, the only one I got the answer for was the crash I reported with smartblur. I asked these questions several months ago, so plenty of time to answer there.
It seems that the mplayer developers just don’t read the support mailing list, at all.
And yes, the questions were with full outputs, with latest SVN, etc etc…
Since I only use Avidemux to encode mpeg2-sourced videos, there are no pyramidal b-frames there. Also, Avidemux may have problems opening such files (although I remember reading something about them fixing it, but I may be mistaken), mencoder has problems writing them, which is a lot worse. Most of the time people are doing the bloated codec -> compact codec conversion, and the b-frames are usually present in the latter.
So you obviously never checked out SVN version of mplayer and got a compilation error? I have.
And no, forcing everyone to use SVN is not OK. And I, for one, shouldn’t live in constant fear that when I upgrade MPlayer, it might just have a problem which makes all my encoded files unreadable in some other player. Yes, it’s been known to happen (I remember reading about it). Even if this problem was there for a couple of hours, everyone who downloaded it is affected.
Having a stable, tested release every now and then doesn’t hurt, and is a million times better than that silly “we don’t believe in releases” excuse.
So, yes, I was a happy mplayer user when I was using lavc mpeg4, same fps avi output, no b-frames.
Then I decided to update my encoding habits by using x264, double-fps mkv output with b-frames, and all hell broke loose.
Avidemux at least works (I even sent them a couple of patches - at least their code is readable).
You can always set audio delay manually if you don’t like the predefined one
I asked at the mplayer mailing lists about the need to keep the delay when remuxing the avi file to mkv, but got no answer. Googling around did no good either. Since mencoder’s support for non-avi containers is, well, bad (read: not working), the constant remuxing without any guarantee that the result will be ok is really annoying.
In case you need to know why I want to use mkv instead of avi, there are mainly two reasons: 1. avi has no native support for VBR audio, and since mencoder’s only working output is avi, one has to wonder if that avi is actually valid. 2. I want chapters in my files.
That’s a blatant lie. VBR is supported in AVI official specs. The problem is how some frontends implement it (I’m looking at you, VirtualDub & friends). Maybe you should read this: AVI-Mux GUI
Yes, mencoder is broken with libav muxers but you can’t really blame it itself. No one has ever stepped in to fix this or just wholly rewrite MEncoder and bring it into the 21st century. All moan and b|tch about how bad it is, yet none want to fix/rewrite it. That’s hypocrisy If I had the skills, I’d do it, but I don’t (well, not enough)
Yes, AVI output of mencoder is valid, I don’t know why you think otherwise. If it wasn’t, none of my DivX HW players here would play it
Also, maybe you should check my h264enc script (google it) and see how I remux AVis to MP4/MKV/OGM/TS containers without having any sync issues (and non of my users so far have reported any)
Of course, I used it with correct pure interlaced source. I wanted to store the result in 50 fps file, because that gives the “best” results visually (IMHO, of course). I have yet to find a good same-fps deinterlacer (I really don’t like yadif=0, it gives lots of artifacts).
I always got ~150ms audio delay when using yadif=1 with mencoder. Yes, I asked them (twice), and the only answer I got was from another user who confirmed the problem.
This thing looked like a broken mencoder A/V auto-sync issue (and no, -mc 0 wasn’t an option). As an open-source programmer (:)), I tried fixing it myself. I was shocked when I opened the mencoder.c file. It looked like it was written by a man who compiled his first hello world just the day before. (Examples: lots of global variable names (I mean like 50 or more), almost no functions (the ones that exist have side effects on globals), almost no indentation, lots of spaghetti code, etc…). Needless to say, I just didn’t want to do anything with that code, ever.
Ever used yadif=1,mcdeint=0:0:10,framestep=2 ? It’s slow but gives the best results. Also you can up mcdeint from 0 up to 3 but that’ll be pretty slow
Out of ~6 questions I asked, the only one I got the answer for was the crash I reported with smartblur. I asked these questions several months ago, so plenty of time to answer there.
It seems that the mplayer developers just don’t read the support mailing list, at all.
And yes, the questions were with full outputs, with latest SVN, etc etc…
I must have completely missed those, when did you made them?
Since I only use Avidemux to encode mpeg2-sourced videos, there are no pyramidal b-frames there. Also, Avidemux may have problems opening such files (although I remember reading something about them fixing it, but I may be mistaken), mencoder has problems writing them, which is a lot worse. Most of the time people are doing the bloated codec -> compact codec conversion, and the b-frames are usually present in the latter.
Huh? I also use referenced b-frames (aka pyramidal b-frames) in mine H.264 encodes and so far I have yet to see mencoder not being able to handle those, let alone write them. Of course, putting H.264 video in AVI is not really the way to go and no HW player will play it, but it can be used as intermediate solution. There’s nothing really preventing you (from the AVI point of view) to stuff H.264 video in this container, except b-frames which AVI doesn’t officially support but there are workarounds for this. Besides, no one is moaning about MPEG4 ASP with b-frames stuffed in AVI, even though it requires the same hacks and worse if one uses packed b-frames
So you obviously never checked out SVN version of mplayer and got a compilation error? I have.
And no, forcing everyone to use SVN is not OK. And I, for one, shouldn’t live in constant fear that when I upgrade MPlayer, it might just have a problem which makes all my encoded files unreadable in some other player. Yes, it’s been known to happen (I remember reading about it). Even if this problem was there for a couple of hours, everyone who downloaded it is affected.
Having a stable, tested release every now and then doesn’t hurt, and is a million times better than that silly “we don’t believe in releases” excuse.
Dude, I’m a video developer myself and pull weekly from SVN for years now. I have yet to see not being able to compile it. Of course, if it happens, report to mplayer-dev mailing list
So, yes, I was a happy mplayer user when I was using lavc mpeg4, same fps avi output, no b-frames.
Then I decided to update my encoding habits by using x264, double-fps mkv output with b-frames, and all hell broke loose.
Avidemux at least works (I even sent them a couple of patches - at least their code is readable).
Obviously, you’re doing something VERY wrong. I have no problems accomplishing this with h264enc
That’s what I’ve been trying to do. You need to set a delay double of what’s mencoder’s setting, in the other direction (yes, it’s a hack, and mencoder sucks for not allowing to disable it’s “smart” automatic delay). The result is, you still get a file where audio and video don’t start at the same time. Not good. Of course, supporting mkv natively would make these unsafe hacks unnecessary.
Whoah, a but touchy on the subject, are we?
I read that, and that behavior is not intended by the original specs. Also, check the doom9 forum, there’s lots of controversy on the subject.
The thing is, it’s not 100% defined. Which means, there are multiple ways to implement it. Which means I’m not going to use it because the tools may reject my file, or interpret it in a slightly different way, and they will be right.
Also, like you said, the other widely popular open-source program, VirtualDUB, does it differently. So, I’m not taking chances.
Plus, it doesn’t have chapters, and I like chapters. So, mkv it is. At least it’s 100% defined, and not extended by third-party people in slightly different ways.
So, one moment you’re saying mencoder is the mother of all encoders, and then - that it’s bad?
Well, yes, it is bad. No, I’m not going to fix it. I have better things to do than fixing broken (beyond repair) programs. Like contributing to Avidemux, for example. You know, the encoder that already is in the 21st century.
The program cannot be good in the future, what matters is how good it is now. Saying you can’t blame a program for not having something (because someone need to fix/rewrite it) is just silly.
So, are they playing the VBR mp3 audio interleaved in the avi file? Without any sync issues, proper seeking, etc…? If they don’t, I can’t blame them at all, since you can correctly implement the AVI specs and still not be able to deal with VBR audio.
So, do you use any special recipes not mentioned anywhere? Or is it just a straightforward mkvmerge command? Sorry, I don’t have enough time to read 288K shell scripts.
As for the sync issues, try this on some music video (the easiest way to check is to watch the drums with mplayer’s slowdown):
The command has been vastly simplified for demonstration purposes, of course.
Notice the ~150ms delay? That’s it.
Yep, used it, didn’t like it. Apart from being dog slow (like, unusably slow), it didn’t have any real perceived quality improvement compared to yadif=0.
Anyway, now that I’ve been doing yadif=1, I’m never going back.
March-April 2009. One more in August 2009.
Of course mencoder handles them. It just does that incorrectly.
The question is, does the
source -> mencoder’s “cleverly fixed” avi -> mkv
chain produce mkv with A/V sync? I’ve yet to get a definitive answer.
Of course it happens, I’ve seen it. Are you sure that every time you download it, it’s going to produce correct files? I sure as hell am not.
Anyway, advocating a releaseless development isn’t going to get you anywhere. One has to make releases for the users to rely upon, otherwise it’s a support nightmare for both the users and the developers (in this case, the developers choose to ignore it), and I’m not talking about the code quality either (you know, feature freezing, testing, critical bug fixing, etc… phases).
Basically, every commit introduces a possibility of breaking everything in a slight way, because there is no mandatory separation of bugfixes / feature improvements. Having a proper release cycle mostly avoids that.
Sure, blame the users
Check the command posted above and tell me what is it that I’m doing so VERY wrong.
Anyway, my Avidemux has just finished encoding a file, time to start another one.
One part is still unclear for me: You’ve recommended to…
