Encoding Interlaced Content

[Lorek]

I noticed there was an option to encode interlaced content using x264 in megui. Does anyone know exactly how that works. Deinterlacing is too destructive for quality i'd like to preserve it without losing too much while keeping the size low.
Also is it just me or does the audio always get screwed up when you deinterlace?

[dattrax]

you need to get my patch which adds the SEI block for field order. Its quite simple, just specify --tff or --bff depending on whether its top or bottom field first.

You can find it in the HD-DVD encoding thread (I think its possibly called 2:3 pulldown)

[Guest]

Can you please give us a link to your patch? Thank you.

[dattrax]

neron2 -->

http://forum.doom9.org/showthread.php?p=1047919#post1047919

and its been tested on stb7109 :-)

[Guest]

and its been tested on stb7109 :-) Ha ha, that's just what I was going to do. :)

[Guest]

Do we still have to turn off trellis and B frames when encoding interlaced?

[akupenguin]

Do we still have to turn off trellis and B frames when encoding interlaced?
No, that restriction applied only to one of the patches. It was fixed by the time interlacing first hit svn.

[Lorek]

Ok back to the topic of encoding interlaced content. Now is this feature specifically only for content that is interlaced throughout its entirety or does it also support partially interlaced content? If it doesn't support partially interlaced content, how exactly should I go about encoding it so I have minimal quality loss. Everything I've read so far has said its best to stay away from deinterlacing as it has a very negative effect on the quality especially if its going to be viewed on a TV.

[Guest]

It doesn't matter whether the content is interlaced or not. You can happily encode progressive content as interlaced.

[akupenguin]

But encoding progressive content as interlaced is less efficient that encoding progressive content as progressive (reduced objective quality, and combing artifacts, and interlaced yuv 4:2:0 is just different than progressive yuv 4:2:0 so using the wrong one will introduce distortion even aside from compression). x264's interlacing isn't adaptive, and even optimal MBAFF has a slight penalty.
So: encode each segment separately with the appropriate setting, then concatenate them.

[nm]

Everything I've read so far has said its best to stay away from deinterlacing as it has a very negative effect on the quality especially if its going to be viewed on a TV.
Depending on the video player, you may have a hard time getting the interlaced content to the screen without deinterlacing. It is actually impossible with modern displays (flat panels, projectors) because they apply built-in deinterlacers to interlaced inputs. Also, most PC software and hardware don't support properly synchronized interlaced output.

The only way to avoid deinterlacing H.264 video on playback is to use a Blu-ray or HD-DVD standalone player with a CRT TV or CRT projector. In other cases, the same quality can be achieved both by deinterlacing on playback and by deinterlacing before encoding. The latter may require more space though, so interlaced encoding is certainly worth considering.

[fields_g]

Since many devices are going to deinterlace your content anyway, one might decide to use a high quality deinterlacer while encoding and avoid the sometimes sketchy deinterlacers in these devices. This is what I've chosen to do. However, keeping interlaced footage (original or re-encoded) could be beneficial if better deinterlacing techniques are developed.

[Lorek]

Aku: Ok, cutting and concatenating isn't that hard, but the difficulty I'm running into is figuring out which sections of the film are interlaced and seperating them into segments. Up to the present i've simply been playing my mpegsource in a software dvd player, pausing at some point and reading the stream info that it displays under the configuration tab. I'm sure there's a better way but most of the information i've read so far has been disjointed and it's been very difficult for me trying to piece together the proper ways of doing these things to get optimal quality without waiting 36 hours per 2 hour encode.

Also, it seems like there's quite a bit of contradictory information around these forums, interlaced content just as an example. Of all the sources that I have read almost all of them say deinterlacing before encoding is the worst possible thing you can do for quality as you lose half of the video data right off the bat. I have also noticed that deinterlacing causes audio sync headaches which I've never fully been able to resolve. Yet I have seen quite a few people say deinterlacing is the best option for preserving quality.

Fields_G: Many newer devices are coming out that natively play progressive, however, I don't want to permanently lose so much quality and everything up to now that i've read says deinterlacing is an extremely lossy conversion.

I don't intend to encode anything interlaced that isn't already interlaced as interlacing really is a relic and its being phased out, however older video typically comes interlaced and I don't want to lose quality.

oh... just realized this turned into a much longer post than I originally intended. Ok so wrapping it up, the questions I have are, Is it really better to encode interlaced content as interlaced or is there a way to losslessly convert it to progressive that I don't know about? and [Edit] How would one go about fixing audio sync problems with deinterlaced content.

For Partially interlaced content, aku suggested I segment the progressive parts and the interlaced parts encode them seperately then concatenate..

Are there any tools you can suggest that would allow me to more easily figure out which parts of mpeg source are interlaced vs progressive. ATM i'm thinking of checking out the mkv toolkit, but if theres a better one please let me know.

[Guest]

everything up to now that i've read says deinterlacing is an extremely lossy conversion.
...
is there a way to losslessly convert [interlaced] to progressive? Um, don't you see the contradiction?

Of course interlaced -> progressive conversion can't be lossless, unless you have a fully static clip. But then it is not video. :)


and what's the best way for solving audio sync problems. You're not allowed to ask that, per forum rule 12. Anyway, it's such a broad question that there is no way to answer it.

[Lorek]

Eh didn't realize that slipped out, my bad.I was typing rather fast and miscommunicated, what I had meant to say was, how would one go about fixing audio sync problems caused by deinterlacing. I'm sure there's a plethora of ways, but audio sync problems have been the bane of my existence since I first started tinkering with deinterlacing a couple years back, hence i've stayed away from interlaced video and only messed with progressive sources. I would however like to remedy my ignorance of the subject sometime in the near future.

[nm]

Also, it seems like there's quite a bit of contradictory information around these forums, interlaced content just as an example. Of all the sources that I have read almost all of them say deinterlacing before encoding is the worst possible thing you can do for quality as you lose half of the video data right off the bat. I have also noticed that deinterlacing causes audio sync headaches which I've never fully been able to resolve. Yet I have seen quite a few people say deinterlacing is the best option for preserving quality.
The first set of people refer to half-rate deinterlacing (for example 30i -> 30p) where temporal resolution suffers. However, most of the good deinterlacers give you full-rate video (30i -> 60p) that has almost all the information contained in the interlaced source. Actually there will be 50% more data generated by the deinterlacer and therefore you'll need to use a somewhat higher bitrate than when encoding as interlaced. On the other hand, as fields_g already said, deinterlacing with a good algorithm before encoding preserves quality better if the playback device has a poor deinterlacer.

The sync problems are caused by your encoding tools, not by deinterlacing as such. Personally I haven't had any issues.

[Lorek]

Ok, I had always connected deinterlacing with horrid sound problems from hell. I'll retake a look at my tools and see if I can find where exactly its messing up. Thanks.

I'll give 60p a tryout and see what it looks like, with 60p that's essentially 60fps, are there any issues with playing 60fps video on older tv's that don't natively play progressive?

[nm]

I'll give 60p a tryout and see what it looks like, with 60p that's essentially 60fps, are there any issues with playing 60fps video on older tv's that don't natively play progressive?
That depends completely on the video player software and hardware. I can interlace 50 fps video properly to 25i PAL (output through a self-built RGB Scart adapter) with my NVIDIA graphics card on Linux, but on most PC-based systems you will probably lose half of the temporal resolution. But as I said in my first post, getting originally interlaced video from a PC to an interlaced display is not easy either (I can't do it on my setup--I need to deinterlace to 50p as an intermediate step because the hardware can't sync the fields in interlaced video properly).

[akupenguin]

Re: audio sync:
Demux audio, encode audio and video separately, remux. This is guaranteed to work unless you're cutting out scenes, or some other manipulation that intentionally changes the length of the video.

Of course interlaced -> progressive conversion can't be lossless, unless you have a fully static clip. But then it is not video.
Full-fieldrate deinterlacing can be lossless. Many deinterlacing algorithms leave the original fields untouched, and only add pixels. Then if you display it on a 50i/60i tv you just drop the interpolated samples and get exactly the same picture as if it had stayed interlaced, and if you display it on a computer or lcd tv you get the deinterlaced picture. (ignoring the lossy compression of course)

[Guest]

Full-fieldrate deinterlacing can be lossless. I don't call that deinterlacing, I call that bobbing. :)

[Jan Marijniszoon]

you need to get my patch which adds the SEI block for field order. Its quite simple, just specify --tff or --bff depending on whether its top or bottom field first.

You can find it in the HD-DVD encoding thread (I think its possibly called 2:3 pulldown)

Do we still need this patch?

I encoded an interlaced video (720 x 576 with TFF) with the latest x264 build and there where jumpy artifacts all over the place with the latest libav decoder from ffdshow tryouts.

[dattrax]

As far as I know you do.

Jim

[Jan Marijniszoon]

Then why can you enable interlaced encoding in MeGui if it ain't working with the 'standard' build of x264 without your patch?

[dattrax]

because it encodes interlaced, but fails to add the TFF or BFF information. The file that is produced is effectively counted as progressive by any decoder, and hence you need the patch.

Jim

[Jan Marijniszoon]

Then forgive me for perhaps another stupid question...

Why haven't the 'main' developers put in your patch in the latest builds that MeGui downloads?

I know how to compile but only in my Linux days, so in Windows I cannot apply your patch (meaning I am too lazy in finding out how compiling works in Windows).

[csy]

@dattrax

Your "interlacing tff/bff" fix which you incorporated into a special x264_hrd_pulldown.04_interlace.diff patch works very well and I really appreciate it for my interlaced encoding.

I am keen to see this interlacing fix incorporated into the x264 SVN releases, however I realise the HRD option in the patch is not deemed acceptable and therefore the current patch will not be incorporated into SVN releases.

I would appreciate if you could create a patch containing only the interlacing fix, and submit it for inclusion into future SVN releases?

[leoenc]

@dattrax
I would appreciate if you could create a patch containing only the interlacing fix, and submit it for inclusion into future SVN releases?

I second that request.
BTW, is there a patched x264.exe with dattrax's fix somewhere?

[leoenc]

Tried patching myself, but failed..
Dattrax, can you help?

$ patch < x264_hrd_pulldown.04_interlace.diff -p0
can't find file to patch at input line 5
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|Index: x264/encoder/set.h
|===================================================================
|--- x264/encoder/set.h (revision 675)
|+++ x264/encoder/set.h (working copy)
--------------------------
File to patch:

[J_Darnley]

patch -p0 < patch.diff
or
patch -p0 -i patch.diff
-p is an argument for patch and must go before the redirect character if you use one.

[leoenc]

Tried it- same error.
BTW the error comes up 9 times, each time for a different file.

[J_Darnley]

Where are your running patch from? The root x264 source folder or one folder up? The patch seems to tell you that you need to use -p1

[leoenc]

Where are your running patch from? The root x264 source folder or one folder up? The patch seems to tell you that you need to use -p1

-p1 did it! I was running it from c/x264..

Thanks a lot, J_Darnley!

[Inventive Software]

Updated libavcodec.
H.264 decoding now supports interlaced + spacial direct mode.

Since libavcodec now got this update, is there any chance x264 will see a similar update? :)

[akupenguin]

What would count as similar? x264 has supported interlaced + spatial direct for a long time.

[Inventive Software]

My bad. It seems it don't yet support interlaced + temporal direct. :o