easiest way to re-encode MPEG2 to H264

[Tephra]

Hi Guys,

I have been waiting for an "easy" way to do this for ages :)

I have MPEG2 sources (576i, 576p, 720p, 1080i) that I want to convert to H264 with the same quality as the original.

I also want to retain the interlace or not as the case maybe.

Is there a nice program that I can click a few buttons to do this with easy... Rather than worrying about quartizing/matrix/paff/etc/etc parameters?

Essentially I want to re-encode my original sources files with exactly the same parameters just a new codec :)

Anyone? :) ps I will be playing back in mythtv if this makes any difference :)

edit: linux OR windows - whatever is easiest!

Cheers
D.

[foxyshadis]

Easiest? Probably handbrake. There's no GUI for any of the x264 configuration, though, so it's take it or leave it pretty much. (Weighted toward being fastest encoding rather than best quality.) StaxRip is also very simple, though it needs a bit of initial setup and a few more button presses each time, but it does offer full configurability in processing and encoding. Stax is .Net 2, in case you're not on windows.

[buzzqw]

you can also try Automen, that's using mencoder to do all the best

look at sign for link

BHH

[jwhyche]

Nero Recode. A retarded monkey can have it up and working in about 20 mins.

[PuzZLeR]

Easiest? Probably handbrake. There's no GUI for any of the x264 configuration, though, so it's take it or leave it pretty much. (Weighted toward being fastest encoding rather than best quality.)

It's not weighted towards fast encoding. It's built for QuickTime compatibility. And yes, quality too.

There's a special tab in HandBrake called "H.264", which is for exactly that: x264 configuration settings that you can manually enter yourself. Don't confuse the fact that the simplicity of HandBrake may make it lack in features. Yes it's fast and easy, but there's also an extra "back door" option for the "tweakers".

It is in no way a "take it or leave it" situation. The devs never restrict you to this QT compatibility if you don't want it. Yes they segregate these advanced features because, we all know, that they also may limit other decoders too as well as slow down encoding tremendously, and I don't blame them.

But you CAN go there if you want to.

As far as I'm concerned HB already has an optimal feature set in place for high quality, speed and wide compatibility and I don't much find the need for this extra tab anyway.

I'm probably going to get shot for this in this forum, but I'll say it anyway: Alot of the advanced settings in x264, although are well done and provide better quality/compression are not worth it to me. I personally don't find the 1% better quality worth it for tripling the encoding time. One curve is heavily sharper and much more exponential than the other in the tradeoff and there's also the risk that it may not be easily decodable now or even later.

[Dark Shikari]

I'm probably going to get shot for this in this forum, but I'll say it anyway: Alot of the advanced settings in x264, although are well done and provide better quality/compression are not worth it to me. I personally don't find the 1% better quality worth it for tripling the encoding time. One curve is heavily sharper and much more exponential than the other in the tradeoff and there's also the risk that it may not be easily decodable now or even later.
This is not really true at all.

I'll give you an example from the H.264 GUI I help maintain (only the changed commands from each setting to the next are included):

High speed = --trellis 1 --merange 32 --subme 5 --ref 1
Medium speed = --trellis 2 --merange 64 --subme 6 --ref 3

High speed is twice as fast... for 35% higher file size. Yes, that's right, 35% higher file size for the same CRF.

Now lets take Low speed mode (note: medium is the default for good reason):

--trellis 2 --no-fast-pskip --merange 64 --subme 7--ref 6

Twice as slow as medium speed, 2-4% improvement. Waste of time, mostly.

Yes, that last little bit gives almost nothing, but the bit before that gives a whole hell of a lot :cool::p

[Sagittaire]

1) Don't change merange ... default setting is good here.

2) Same size doesn't mean same quality. Same crf doesn't mean same quality too. (Comparison for example between flat16 and flat8 matrix with same crf).Your "high speed" setting make certainely very better quality than your "medium speed setting".

3) If you want compare quality here you must use objective test. For example with the same PSNR/SSIM between --me "hex" --subme 6 --trellis 1 and --me "umh" --subme 7 --trellis 2 there is a difference of ~5% for size at the same quality level.

[Dark Shikari]

1) Don't change merange ... default setting is good here.

2) Same size doesn't mean same quality. Same crf doesn't mean same quality too. (Comparison for example between flat16 and flat8 matrix with same crf).Your "high speed" setting make certainely very better quality than your "medium speed setting".

3) If you want compare quality here you must use objective test. For example with the same PSNR/SSIM between --me "hex" --subme 6 --trellis 1 and --me "umh" --subme 7 --trellis 2 there is a difference of ~5% for size at the same quality level.
I've tested the SSIM between the "low quality" and "medium quality" modes that I listed, difference is basically nil.

I think part of the main reason is that --subme 5 seems to lose a lot over --subme 6 due to the lack of RDO.

[Sagittaire]

I've tested the SSIM between the "low quality" and "medium quality" modes that I listed, difference is basically nil.


1) Quality difference between subme 5 and subme 6 is certainely not 35%.

2) Delta at 0.01 for SSIM is a big difference for the quality.

[foxyshadis]

It's not weighted towards fast encoding. It's built for QuickTime compatibility. And yes, quality too.
Not necessarily, there are numerous options that have no impact on QT compatibility that aren't used. I think it's a great gui, but using 1 ref and no b-frames is not a particularly good speed/quality tradeoff for most people. 2-3 refs and a b-frame nets you substantially better compression for little cost; me and subme do have quickly diminishing returns though. I already outlined potential fast/medium/slow QT-compatible profiles in some other thread. (QT is somewhat more capable than it used to be, as well, as the ipod capabilities have advanced.)

There's a special tab in HandBrake called "H.264", which is for exactly that: x264 configuration settings that you can manually enter yourself. Don't confuse the fact that the simplicity of HandBrake may make it lack in features. Yes it's fast and easy, but there's also an extra "back door" option for the "tweakers".
That's why I said no gui, a command line entry form isn't a gui. It is a take it or leave it for the vast majority of people who'd use a gui like handbrake.

[Terranigma]

I've tested the SSIM between the "low quality" and "medium quality" modes that I listed, difference is basically nil.

I think part of the main reason is that --subme 5 seems to lose a lot over --subme 6 due to the lack of RDO.
That's true according to akupenguin's reply (http://forum.doom9.org/showpost.php?p=1020503&postcount=4). I was blind at first to believe the there was no quality difference between subme 5 to 7; there's a huge difference to my eyes. I could'nt really tell at first because my source was so grainy, but after cleaning it, i've noticed a change easily. :)

[akupenguin]

The only difference between subme 5 and subme 6 is RDO, so that kinda has to be the main reason for any change :)
But no, RDO doesn't reduce bitrate by 35%.

[Dark Shikari]

1) Quality difference between subme 5 and subme 6 is certainely not 35%.

2) Delta at 0.01 for SSIM is a big difference for the quality.
Obviously Trellis and other things matter also, plus the use of 3 reference frames instead of one seems to have a considerable effect.

This was a very large-resolution video at a very low relative bitrate (--crf 30, 1680x1050), and trellis/RDO seem to have a higher effect at lower bitrates from my experience. Additionally, my source footage is FRAPS, which means it has zero noise, while MPEG-2 source might act very differently due to its inherent noisiness and lossiness.

Also, I'm not stupid about SSIM; by tiny difference I mean between like 0.9817 and 0.9821.

MErange might help also as sometimes the FRAPS footage stutters and the motion is more pixels than usual, so the normal motion search radius might not catch it.

I personally would never use lower than --subme 6 though when possible, and its always good to have a few --refs.

[Tephra]

mmm well I have looked @ handbrake in the past but it doesn't support raw mpg files, only DVD or ISO :(

ill give staxrip another go :)

[Sagittaire]

Obviously Trellis and other things matter also, plus the use of 3 reference frames instead of one seems to have a considerable effect.

This was a very large-resolution video at a very low relative bitrate (--crf 30, 1680x1050), and trellis/RDO seem to have a higher effect at lower bitrates from my experience. Additionally, my source footage is FRAPS, which means it has zero noise, while MPEG-2 source might act very differently due to its inherent noisiness and lossiness.

Also, I'm not stupid about SSIM; by tiny difference I mean between like 0.9817 and 0.9821.

MErange might help also as sometimes the FRAPS footage stutters and the motion is more pixels than usual, so the normal motion search radius might not catch it.

I personally would never use lower than --subme 6 though when possible, and its always good to have a few --refs.

Well you can always choose particulary short example. Wpred can save more than 50% of bitrate with fade scene ... etc etc

Anyway in general case (for complete movie) between your "high speed" and "medium speed" setting there are never 35%.

[Dark Shikari]

Well you can always choose particulary short example. Wpred can save more than 50% of bitrate with fade scene ... etc etc

Anyway in general case (for complete movie) between your "high speed" and "medium speed" setting there are never 35%.
What's wpred?

[mitsubishi]

What's wpred?

Maybe he means --weightb (Weighted B Frame prediction)

[PuzZLeR]

Not necessarily, there are numerous options that have no impact on QT compatibility that aren't used. I think it's a great gui, but using 1 ref and no b-frames is not a particularly good speed/quality tradeoff for most people. 2-3 refs and a b-frame nets you substantially better compression for little cost; me and subme do have quickly diminishing returns though. I already outlined potential fast/medium/slow QT-compatible profiles in some other thread. (QT is somewhat more capable than it used to be, as well, as the ipod capabilities have advanced.)Hey Foxyshadis. Yes, QT compatibility is expanding, even the iPod specs should be better by the next G6 (hopefully Main Profile, CABAC, anamorphic, higher bitrates….sign me up!). Can you direct me to a link to that QT thread? I’d love to read up on it. Thanks in advance.

That's why I said no gui, a command line entry form isn't a gui. It is a take it or leave it for the vast majority of people who'd use a gui like handbrake.I still say the "take it or leave it" is rather harsh when the option to tweak still exists, albiet in a "back door". Yes, it probably would be that way for most people, but not for all. And the definition of GUI can be arguable here, especially when it's a CLI simplified within the environment of a GUI. But that is up to subjective definition in some ways. :confused: At any rate, if there's more to QT compatibility with advanced tweaking and little trade-off, I'd love to see that link... :)

[PuzZLeR]

mmm well I have looked @ handbrake in the past but it doesn't support raw mpg files, only DVD or ISO :(

ill give staxrip another go :)

True. Only DvD source. However, for raw MPEG-2 files all you need do is convert them into a VIDEO_TS folder on your hard drive with a DvD author package like TMPGEnc that does it losslessly. No menus or burning necessary and only takes a couple of minutes for a full movie..

But if it’s something other than MPEG-2 then HandBrake would not be your best choice. You can though, but it would be, at least a bit, lossy to do this. You can encode to MPEG-2->VOB->VIDEO_TS at very high bitrates (which you’re going to compress and delete anyway after).

If this is unacceptable, then you can use something like Nero Recode for this (my second “easiest” choice).

[PuzZLeR]

Yes, that last little bit gives almost nothing, but the bit before that gives a whole hell of a lot :cool::pHey DS,

I didn’t say “all” the x264 features, I said “a lot” of them slow down encoding tremendously for little quality. Otherwise I would just go only Baseline, kill B frames entirely, subme, even CABAC, etc., heck, I may even just do DivX then…:p

But there are some features I could certainly do without. For example, encoding with 16 MRFs, the max the H.264 standard allows you, will produce a bit of quality, however is it worth it when your encoding slows down from 10fps down to 1fps? For what? CRF tells me I gain about a percent, or three, of compression. Big deal.

Ok, it’s my opinion. But the way storage is ever expanding I would rather just add those couple of percentage points in bitrate, not tie up my PCs for days encoding anything over one hour, and make sure that this video will play in any H.264 decoder around without choking it…

Second reason why I may get shot in this forum:

Most of us here are encoding from an MPEG-2 source. Another reason why some of these advanced x264 features are a waste of time. For all that mega-encoding time and decoder difficulty later on, all you’re really doing, or ever going to do, is re-create something similar to MPEG-2 at the very best (+ maybe an enhanced filter or two). What’s the point in all this trouble? Keep the original instead then, otherwise just compress it to a nicer, lighter, smaller size with a quality hit and move on. The real power of H.264, particularly of x264 and its features, is the zone where CRF<10, way, way beyond the capabilities of the aging MPEG-2 format. However, this is absolutely pointless when encoding to H.264 from an MPEG-2 source since the law of diminishing returns applies to the older standard in this area. Real uncompressed video is 65 GB per hour – six times more for true HD. The real benefit you get from H.264, and these amazing features of x264 is really when encoding DIRECTLY FROM this source (Source -> H.264) NOT from Source - > MPEG-2 -> H.264.

Ok, I’m done with this thread… ducking from the gunfire now…

[R3Z]

Hey DS,

I didn’t say “all” the x264 features, I said “a lot” of them slow down encoding tremendously for little quality. Otherwise I would just go only Baseline, kill B frames entirely, subme, even CABAC, etc., heck, I may even just do DivX then…:p

But there are some features I could certainly do without. For example, encoding with 16 MRFs, the max the H.264 standard allows you, will produce a bit of quality, however is it worth it when your encoding slows down from 10fps down to 1fps? For what? CRF tells me I gain about a percent, or three, of compression. Big deal.

Ok, it’s my opinion. But the way storage is ever expanding I would rather just add those couple of percentage points in bitrate, not tie up my PCs for days encoding anything over one hour, and make sure that this video will play in any H.264 decoder around without choking it…

Second reason why I may get shot in this forum:

Most of us here are encoding from an MPEG-2 source. Another reason why some of these advanced x264 features are a waste of time. For all that mega-encoding time and decoder difficulty later on, all you’re really doing, or ever going to do, is re-create something similar to MPEG-2 at the very best (+ maybe an enhanced filter or two). What’s the point in all this trouble? Keep the original instead then, otherwise just compress it to a nicer, lighter, smaller size with a quality hit and move on. The real power of H.264, particularly of x264 and its features, is the zone where CRF<10, way, way beyond the capabilities of the aging MPEG-2 format. However, this is absolutely pointless when encoding to H.264 from an MPEG-2 source since the law of diminishing returns applies to the older standard in this area. Real uncompressed video is 65 GB per hour – six times more for true HD. The real benefit you get from H.264, and these amazing features of x264 is really when encoding DIRECTLY FROM this source (Source -> H.264) NOT from Source - > MPEG-2 -> H.264.

Ok, I’m done with this thread… ducking from the gunfire now…

Noone should be on your case mate, you provide yet another opinion on what is optimal for your needs for others. Whilst i dont agree about the mpeg2 > x264 comment, thats just me. I only encode things that are important to me and worth keeping.