mpeg2 1080i to h264 1080i

[fenomeno83]

hello, what tool and settings can I use to reencode an hdtv 1080i mpeg2 movie (bitrate 22000Kbps) in 1080i h264 without loss quality?
thanks

[nurbs]

You can use x264. You can use it directly or via avisynth
x264 --qp 0 -o output.mp4 input.avs

It's not really a good idea though. The resulting files will be huge.

[fenomeno83]

I know that with crf 18 quality is identical to original, or very very very similar

[poisondeathray]

you would need to add --tff to the above commandline to encode interlaced

[fenomeno83]

thanks, but Must I add it also if my original source is interlaced?

[LoRd_MuldeR]

thanks, but Must I add it also if my original source is interlaced?

Yes, if your source is interlaced and if you don't apply a Deinterlace filter on it, then you MUST encode as interlaced. Otherwise you'll get garbage ;)

The other way around, encoding a progressive source as interlaced, is possible. But it hurts compression efficiency for zero benefit, so you better don't do that either.

However with your interlaced source you should consider using a (good) deinterlacer rather than doing an interlaced encode...

[fenomeno83]

Yes, if your source is interlaced and if you don't apply a Deinterlace filter on it, then you MUST encode as interlaced. Otherwise you'll get garbage ;)

The other way around, encoding a progressive source as interlaced, is possible. But it hurts compression efficiency for zero benefit, so you better don't do that either.

However with your interlaced source you should consider using a (good) deinterlacer rather than doing an interlaced encode...

consider that it is a football match...
http://img827.imageshack.us/img827/1443/10683.jpg

vlc realtime bob deinterlacer works good, but if you say that in the same time that I encode from mpeg2 to h264 is better use a good deinterlacer to get a 1080p output, what can I use?

at last, use a crf 18 x264 encoding is good to preserve quality and give a good compression?

[LoRd_MuldeR]

vlc realtime bob deinterlacer works good, but if you say that in the same time that I encode from mpeg2 to h264 is better use a good deinterlacer to get a 1080p output, what can I use?

Yadif produces fairly well results (should be much better than VLC's bob filter at least!) and it is pretty fast.

Really good results can be achieved with TempGaussMC, but it is very slow. Well, it can be tweaked to not be THAT slow.

Just to name two. There many many more options...


at last, use a crf 18 x264 encoding is good to preserve quality and give a good compression?

CRF 18 should be good starting point. However 18 might be overkill for your source.

You should increase the CRF in steps of 1 and find out at which point the quality gets too bad for your eyes.

In my experience CRF 20 often is sufficient and should save quite a few bits compared to 18 ;)

[fenomeno83]

Yadif produces fairly well results (should be much better than VLC's bob filter at least!) and it is pretty fast.

Really good results can be achieved with TempGaussMC, but it is very slow. Well, it can be tweaked to not be THAT slow.

Just to name two. There many many more options...

I haven't "time problems"..also if my pc (intel i5 4 core) encode for a week this isn't a problem..
So I prefer use tempgaussmc..
so, this avisynth filter has good default paramethers, or is better use specific? I don't want encode for many time and at last don't have expected result




CRF 18 should be good starting point. However 18 might even be overkill.

You should increase the CRF in steps of 1 and find out at which point quality gets to bad for your eyes.

In my experience CRF 20 often is sufficient ;)
as before, no time problem for me..I will use 18 :)

so, what can be final avisynth script to encode my 1080i mpeg2 to a very good and deinterlaced 1080p h264 (Audio is not important..I will mux after) ?
thanks

[poisondeathray]

so, what can be final avisynth script to encode my 1080i mpeg2 to a very good and deinterlaced 1080p h264 (Audio is not important..I will mux after) ?
thanks

e.g. use DGIndex

MPEG2Source("video.d2v")
QTGMC()


This will produce 1080p60 output . I find QTGMC current version produces oversharpened results, so you should preview the script and adjust the parameters to your tastes

[LoRd_MuldeR]

I haven't "time problems"..also if my pc (intel i5 4 core) encode for a week this isn't a problem..
So I prefer use tempgaussmc..
so, this avisynth filter has good default paramethers, or is better use specific? I don't want encode for many time and at last don't have expected result

:search:


as before, no time problem for me..I will use 18 :)

so, what can be final avisynth script to encode my 1080i mpeg2 to a very good and deinterlaced 1080p h264 (Audio is not important..I will mux after) ?
thanks

CRF mainly is a "bitrate/filesize -vs- quality" option rather than a "speed -vs- quality" option.

[fenomeno83]

thanks all!

[benwaggoner]

e.g. use DGIndex

MPEG2Source("video.d2v")


I'd add CPU=4 to that. Deblocking can make broadcast MPEG-2 look a lot better, since it's common to get a lot of blocking artifacts. Better to deblock in the decoder, since it knows what the QPs are, and thus can do a much better job of figuring out what's artifact and what's detail. Done right, you can wind up with output that looks better than the source.

A little cropping would be appropriate with this source as well. However, that'll mess up block alignment, making deblocking all the more important, so you don't wind up having x264 spending bits to preserve mid-block sharp edges that are really just artifacts.

There are different opinions on this, but I've often found that CPU=6 (turning on deringing) to be helpful as well. It will reduce detail some, but generally it's bad detail. And anything that reduces detail makes for an easier encode; best that it be bad detail that gets removed.

[Didée]

Better to deblock in the decoder, since it knows what the QPs are, and thus can do a much better job of figuring out what's artifact and what's detail.
Knowing the frame QP is only a small part of the big picture. The most important part is a good deblocking algorithm. And frankly, the algorithm used in mpeg2source is nothing but ... old, very old.

The only argument is that the available AVC-deblocking algorithm (implemented in the deblock() filter) wasn't implemented interlacing-aware, it's only for progressive frames.
Transmogrify it to work interlaced, and you have a winner.

[Boulder]

Knowing the frame QP is only a small part of the big picture. The most important part is a good deblocking algorithm. And frankly, the algorithm used in mpeg2source is nothing but ... old, very old.

The only argument is that the available AVC-deblocking algorithm (implemented in the deblock() filter) wasn't implemented interlacing-aware, it's only for progressive frames.
Transmogrify it to work interlaced, and you have a winner.

I wonder if anyone would like to work on DGDecode to change the algo to something better, such as Deblock_QED or similar. As the proof of concept already exists, a lot of required work is already done.

[benwaggoner]

Knowing the frame QP is only a small part of the big picture. The most important part is a good deblocking algorithm. And frankly, the algorithm used in mpeg2source is nothing but ... old, very old.

The only argument is that the available AVC-deblocking algorithm (implemented in the deblock() filter) wasn't implemented interlacing-aware, it's only for progressive frames.
Transmogrify it to work interlaced, and you have a winner.
I don't know that a good in-loop deblocking filter would make an optimal postprocessing filter. In-loop is all about not propogating errors forward, while postprocessing is all about removing artifacts while preserving actual detail. There's a lot of statistical stuff that can be done with pure postprocessing that's not useful with in-loop.

While there are certainly opportunties to further tune the current MPEG2 one, I think integrating it into the decoder so it can be QP and block-alignment aware is very useful. A horizontal line at the edge of a block should be very differently treated than one in the middle of a block, and knowing QP is critical to know whether or not an edge between blocks is signal or noise.

You can think of QP as determining the standard deviation of potential decoded values for each pixel, and so is a great guide to the strength of any filtering, and for determining whether any given detail is inside or outside the range of values possible for an encoding artifact.

Another area I'd be interested in seeing for in-decoder postprocessing would be for 30i to 60p conversion. The bitstream already knows whether each block is encoded as progressive or interlaced, which can be a very useful first-order heuristic to tune from.

[Didée]

Of course it is advantageous to have knowledge about the block quantizers. I'm not arguing against that!

My point is that mpeg2source HAS that information, but nonetheless can't stand a chance against more-state-of-the-art deblockers, even if those have to work "blind".

See:
http://img43.imageshack.us/img43/3937/sourcez.th.png (http://img43.imageshack.us/i/sourcez.png/)

http://img816.imageshack.us/img816/8589/sourcedb1.th.png (http://img816.imageshack.us/i/sourcedb1.png/) http://img18.imageshack.us/img18/3649/sourcedb2.th.png (http://img18.imageshack.us/i/sourcedb2.png/) http://img809.imageshack.us/img809/3237/sourcedb3.th.png (http://img809.imageshack.us/i/sourcedb3.png/)


mpeg2source's deblocker has the most information at hand, yet it does the worst job. Period.

[Blue_MiSfit]

Wow yeah, it's pretty amazing how much detail gets nuked out by mpeg2source's deblocker, versus deblock(30) or deblock_qed().

Now, if it could pass block quantizer information INTO said filters.... ;)