interlaced encoding in x264 is here

[bond]

Alex Izvorski of Auroras Entertainment (http://www.auroras.tv/) has sent a patch adding initial interlaced encoding support to x264 to the maillist (http://www.via.ecp.fr/via/ml/x264-devel/2006-05/msg00083.html), thanks a lot! :)

Hello,

I am pleased to announce the initial release of interlaced support for
x264. This was written by me with invaluable help from Loren Merritt
for Auroras Entertainment LLC.

Current status:
- fixed interlacing only, no PAFF/MBAFF yet
- all analysis modes and all motion estimation options work
- multiple ref frames work
- CABAC and CAVLC work
- no B-frames
- no trellis
- possibly other options don't work: mixed refs, RDO, B-pyramid

Some more information is in the included README.interlacing file.

The patch is relative to x264 r523 from svn, it may not apply cleanly
to the latest version. The patch is copyright Auroras Entertainment
LLC, 2006 and released under the same terms as x264 (GPL v2 or later).

We would like to support further efforts to develop interlacing, please
get in touch with me if you would like to be involved.

Enjoy!

-Alex Izvorski
enjoy!

edit: hum seems the patch attachement has been removed by the mailserver :/

[ChronoCross]

I don't have much exp with interlaced encoding. I however do support it's enactment into x264. hopefully all advanced features will work soon. Good luck to all testers and developers.

[DarkZell666]

Well, dunno if it's something good to happen, but I guess it'll be useful for someone :)

Thx for the contribution !

[SeeMoreDigital]

Well, dunno if it's something good to happen, but I guess it'll be useful for someone :)

Thx for the contribution !Generating interlaced encodes from interlaced sources is still the preferable method of encoding IMO ;)


Cheers

[SteMa]

Is there a possibility that the decoder would play an interlaced source as powerdvd6 does (try it with interlaced source, it's very impressing imo)? I mean:fields2frames, than doubling vertical resolution, and pushing every frame that was converted from top field 1 pixel down? So progressive display wouldn't need deinterlacing, which eats up cpu power, isn't as smooth, and it could have artifacts.

[nm]

What decoder? If you mean libavcodec (in ffdshow), you should probably ask in some other thread or make a new one. Anyway, what you described PowerDVD is doing, is deinterlacing, most likely close to bobbing. The same technique can be used on all interlaced sources, no matter the decoder. AFAIK ffdshow includes some deinterlacing filters that do just that. Greedy2frame and TomsMoComp from DScaler/AVISynth are better, but they'll require more CPU time.

[Kurtnoise]

here is (http://kurtnoise.free.fr/x264.zip) a win32 generic build and the patch (http://kurtnoise.free.fr/x264_patch_interlacing support) for interlacing support.

Use --interlaced switch to enable this mode.

[SeeMoreDigital]

I guess all we need now is an AVC decoder with native interlaced support ;)

[Kurtnoise]

If I remember correctly, the avc ateme decoder from the last beta tests supports interlacing. Not available for a large public though...and CoreAVC Pro Edition supports already PAFF (but not yet included in this patch).

[SeeMoreDigital]

Sadly I don't posses either of those decoders... So that's me out of the testing :(


Cheers

[Kostarum Rex Persia]

What about libavcodec x264 decoder in FFDSHOW? Can Milan integrate interlaced support in it?

[Revgen]

here is (http://kurtnoise.free.fr/x264.zip) a win32 generic build and the patch (http://kurtnoise.free.fr/x264_patch_interlacing support) for interlacing support.

Use --interlaced switch to enable this mode.

It crashed when using the --interlaced command.

Are you sure it's been patched?

[Manao]

What about libavcodec x264 decoder in FFDSHOW? Can Milan integrate interlaced support in it?No, ffmpeg doesn't support field only / paff. Loren just created a patch in order to decode mbaff, but that doesn't work with the current x264's implementation of interlacing.

[Kurtnoise]

It crashed when using the --interlaced command.

Are you sure it's been patched?
yep...coz it works fine here.

keep in mind these things :
Current status:
- fixed interlacing only, no PAFF/MBAFF yet
- all analysis modes and all motion estimation options work
- multiple ref frames work
- CABAC and CAVLC work
- no B-frames
- no trellis
- possibly other options don't work: mixed refs, RDO, B-pyramid

Otherwise post your command line...

[Jay Bee]

Nice, I've been waiting for interlaced AVC. Is there a decoder that can handle this properly? And will this update make it into GUIs like Avidemux or Vdub? (since I don't use command lines to encode.)

[Revgen]

Okay I've got a problem.

Whenver I try to do a 2nd pass x264.exe gives me an error stating that file I'm trying to encode is shorter than the one I tried on the first pass. It tells me that the first pass was 4178 frames long and the 2nd was 2089 frames long.

First pass:

H:\x264.exe --pass 1 --bitrate 1000 --stats ".stats" --interlaced --nf --no-chroma-me --analyse all --8x8dct --direct none --progress --no-psnr --output NUL "H:\KOBE\tnt.avs"

Second pass:

H:\x264.exe --pass 2 --bitrate 1000 --stats ".stats" --interlaced --nf --no-chroma-me --analyse all --8x8dct --direct none --progress --no-psnr --output "H:\KOBE\tnt.mp4" "H:\KOBE\tnt.avs"

EDIT
Also I tried encoding to ABR and got a green mess.

[Kurtnoise]

mmh, right. There is a problem with multipass. Don't know why...

[DarkZell666]

I dare believe you all noticed that 4178 = 2089 * 2 ;)

[Revgen]

Here's the green mess I talked about earlier.

http://img219.imageshack.us/img219/6245/tnt2ne.jpg (http://imageshack.us)



Also my orginal video is 2089 frames.

EDIT:

I'm viewing the video with CoreAVC Pro.

Here's my ABR script:

H:\x264.exe --bitrate 1000 --interlaced --nf --no-chroma-me --analyse all --8x8dct --direct none --progress --no-psnr --output "H:\KOBE\tnt.mp4" "H:\KOBE\tnt.avs"

[bond]

x264 --interlaced --bitrate 770 --bframe 0 --ref 5 --filter -6:-6 --subme 5 --8x8dct --analyse all --progress --no-psnr --no-fast-pskip -o interlaced.mp4 input.avsafter a quick one pass test it seems nero, ateme and cyberlink decode the stream fine, good job!

still i get strange "fref0 = 16.L 18.U 14.L 16.U 12.L 14.U 10.L 12.U 10.U" messages when encoding with kurt's compile

[Revgen]

L and U may be for Luma and Chroma. I guess we'll never know.

[Revgen]

@bond

I tried your settings and I still had problems with my Cyberlink and CoreAVC decoders, inluding the green mess.

H:\x264.exe --interlaced --bitrate 770 --bframe 0 --ref 5 --filter -6:-6 --subme 5 --8x8dct --analyse all --progress --no-psnr --no-fast-pskip --output "H:\KOBE\tnt.mp4" "H:\KOBE\tnt.avs"

[bond]

i guess the problem might be your source

my avisynth script created an interlaced stream from a progressive source and looked that way:

LoadPlugin("C:\...\DGDecode.dll")
mpeg2source("...\matrix1.d2v")
trim(14,313)
crop(2,82,716,416)
LanczosResize(720,288)
assumetff.separatefields.selectevery(4,0,3).weave

[Revgen]

Okay I got ahold of one of my 720p HDTV caps and I resized it to 720x480 and interlaced it to TFF. The new file still displays green stuff in CoreAVC, but not as badly as it did the last time. Cyberlink now plays it fine.

The sources that I used previously encode fine in interlaced mode with Quenc, HCEnc, and Mencoder and play back on my DVD standalone without a hitch. Apparently, this interlacing function is pretty sensitive.

[bond]

i also get the green picture with coreavc. this might be a coreavc bug?

[SeeMoreDigital]

I did not think CoreAVC fully supported pure interlaced sources yet!

[ChronoCross]

I did not think CoreAVC fully supported pure interlaced sources yet!

It doesn't IIRC.

[Revgen]

Actually it does.

I decoded a 1080i sample from a .ts file here (http://www.corecodec.com/index.php?option=com_smf&Itemid=28&expv=0&topic=2751.msg16669#msg16669).

EDIT

Did you pure intelaced as in non-telicined? If so then the sample I tested above doesn't count since it was a telecined movie trailer.

[SeeMoreDigital]

There's a world of difference between "pure" interlaced sources and IVTC sources that contain progressively flagged frames!

[bond]

Actually it does.

I decoded a 1080i sample from a .ts file here (http://www.corecodec.com/index.php?option=com_smf&Itemid=28&expv=0&topic=2751.msg16669#msg16669).the hdtv samples are most of the time progressive, so they arent really useable for testing interlaced decoding

[SeeMoreDigital]

the hdtv samples are most of the time progressive, so they arent really useable for testing interlaced decodingIndeed...

Here's a real pure interlaced MPEG-2 source (http://www.one.seemoredigital.net/Temp_Files/Pure_Interlaced_HDTV_MPEG-2_Source.zip) you guys can use ;)


Cheers

[bond]

thanks a lot! :)

[SeeMoreDigital]

thanks a lot! :)Thanks...

It was the best source I could find to test the interlaced playback capabilities of my hardware player.

There were quite a few of us over on the AVS forum who used this source to generate suitable MPEG-4 Part2 and WMV9 encodes at 29.970FPS in our hardware players ;)

Once you've generated your encode, when you play it back fix your eyes on the railings of the train as it passes by. If they are blurred your encode is not correct (ie: unlike the MPEG-2 source which should look perfect).

Personally speaking, I've not had much success playing back the MPEG-2 source or MPEG-4 part2 encode correctly in a software media player. Even though the railings look perfectly sharp in my hardware player ;)


Cheers

[AlexI]

Kurtnoise13 - *thank you* for making the binary available!

Everone - Thank you for testing this patch, it is good to get feedback.

Revgen - are you sure CoreAVC and Cyberlink can play back any interlaced footage correctly? Please try to play back with Nero or Moonlight for example, or even better try decoding with the JM reference decoder. Also, please try encoding with all default settings. I think this is a problem to refer to the CoreAVC developers - in theory any decoder should be able to handle any stream that the reference decoder can handle.

Also, two-pass is definitely not supported at this time - thank you for finding that, I hever even thought of testing it actually.

--Alex

[AlexI]

Important note: non-interlaced encoding definitely does not work with this patch. It may work if you use --no-cabac, but I wouldn't bet on it. Fixing that is pretty high on the TODO list, obviously.

Threads do not work either.

--Alex

[Revgen]

@Alex

I've reinterlaced a 60p video using assumetff().separatefields().selectevery(4,0,3).weave()
and fed it to this version of X264.exe using these settings:

H:\x264.exe --interlaced --bitrate 2500 --bframe 0 --ref 5 --filter -6:-6 --subme 5 --8x8dct --analyse all --progress --no-psnr --no-fast-pskip --output "H:\KOBE\tnt.mp4" "H:\KOBE\tntfirst.avs"

The video plays back fine using the latest version of CoreAVC Pro 1.1 . Hopefully, b-frames, 2-pass, and other stuff can be added.


EDIT

I also tested BFF interlacing using this AVS script assumebff().separatefields().selectevery(4,1,2).weave()

And it also played fine in CoreAVC Pro 1.1 .

[Kurtnoise]

Some new stuff from Loïc le Loarer concerning x264 interlacing content :

Here my first interlace patch. This patch adds all the necessary
parameters for interlace support (PAFF, MBAFF and fields). The
parameters are :
- b_frame_mbs_only: 0 -> interlaced, 1 -> progressive
- b_mb_adaptive_frame_field: when !b_frame_mbs_only, 0->PAFF, 1->MBAFF
- b_top_field_first: necessary to know the fields order
- analyse.i_fields: 0-> don't create fields,
1-> automatically create fields or frame, which one
is the best
2-> create only fields

The x264 command line parameters are a bit different, to enable
interlace, ones should use either --paff, --mbaff or --fields n option
(where n is 0, 1 or 2). The first two are exclusive, --fields is 0 by
default and can be set to 1 or 2 to enable fields creation (but this is
not supported yet). --bottom-field-first set b_top_field_first to 0, the
default is 1.

For the moment, this patch allows only frames in a PAFF sequences and no
fields, and as PAFF frames are identical to progressive frame, there is
no compression improvement from progressive (default) setting.
Nonetheless, this patch sets the POCs differently for top and bottom
fields so that a decoder using the POCs will be able to display the
interlaced content correctly on an interlaced display (with the fields
in the correct order). For this only reason, it is a good idea to use
--paff and --bottom-field-first option if necessary to encode interlaced
content.

But I'm working on MBAFF implementation which will gives much better
result and the patch from Alex Izvorski from Auroras can be merge with
this as it covers the "--fields 2" options (fields forced).

Hope this can be included to be used a basis for futur improvements.

This applies on top of revision 532 patched with my previous patch
x264_fixes_1.diff sent a few minutes earlier.

http://www.via.ecp.fr/via/ml/x264-devel/2006-06/msg00018.html

For win32 users, here is a build (http://kurtnoise.free.fr/x264_rev352+interlaced.zip). Not tested yet personally...

[Mug Funky]

dang! to think i missed this thread for a long weekend...

will test this first opportunity i get, and i'll follow the development very closely :)

hopefully this means all those PAL land people trying to back up their anime will be able to use X264 and get the same bitrates that one would get from progressive xvid (or better).

also makes DVB backup a lot easier - adaptive interlace detection means interlace can be left on at all times without any quality or bitrate hits on progressive stuff (i assume chroma subsampling is taken care of per-block for MBAFF?)

[Manao]

The codec doesn't care about chroma subsampling. And at the moment, x264 doesn't handle anything adaptively when it comes to interlacing.

[Revgen]

I used my same interlaced sample I used in post #36 and encoded a sample using this new version.

Here's the script.

H:\x264.exe --paff --bitrate 5000 --bframe 0 --ref 5 --filter 0:0 --subme 5 --8x8dct --analyse all --progress --no-psnr --no-fast-pskip --output "H:\KOBE\kobe.mp4" "H:\KOBE\tntfirst.avs"

It played back fine with latest version of CoreAVC and I was even able to deinterlace it with CoreAVC's built in deinterlacer.

Good Job Guys.:thanks:

I'm going to try 2-pass, b-frames, and the other options next.



EDIT

Bad News. 2-pass doesn't work. :(

Good News. --threads, --subme 6, --trellis, --mixed refs, and all b-frame parameters work fine and play back fine in CoreAVC and in the latest VLC Player.

Thanks Again! :thanks:

Here's the script I used:

H:\x264.exe --paff --bitrate 5000 --bframe 2 --b-pyramid --b-rdo --bime --weightb --ref 5 --mixed-refs --filter 0:0 --subme 6 --8x8dct --me hex --trellis 1 --analyse all --threads 2 --thread-input --progress --no-psnr --output "H:\KOBE\kobe.mp4" "H:\KOBE\tntfirst.avs"

[Revgen]

Are there any plans for a 2-pass enabled build?

I know it's summer, so I'm not expecting miracles, but it would be nice to know if it's on the radar.

Thanks

[hpn]

Just did a short 400 frames test with interlaced DV footage + rev.574 and enabling the new option --interlaced (introduced in rev570)

x264.exe -p 1 -B 1000 -r 5 --mixed-refs --no-fast-pskip -b 3 --b-pyramid -w --bime --weightb -m 6 -t 1 -A none -8 --me umh --progress --interlaced -o NUL b.avs

Looks promising and Mplayer plays it almost fine, but with one frame (No 40) completely borked, plus when I switch to the mplayer's output I see every second frame (or field?) it keeps repeating the message:
[h264 @ 00AE6660]MBAFF + spatial direct mode is not implemented

Neither MPC nor even VLC media player (??) was able to play the interlaced encode out of the box (playing a grey screen). Guess I have to change some of the players options or/and reinstall some broken software.
The same encode without --interlaced is perfect as usual. Obviously we'll also have perfect interlaced support soon :)

[Manao]

hpn : the error message you get is explicit : libavcodec doesn't support all mbaff does, and particularly it doesn't the --direct spatial option. So use --direct temporal in your commandline ( or don't use bframes ).

[akupenguin]

The error message is misleading. libavcodec does support the subset of MBAFF that x264 currently generates, but it can't know just from looking at the headers that the file uses that subset.
And x264 does not support temporal direct w/ MBAFF.
(Because the MBAFF samples that I had when writing lavc were temporal, but when when I get to choose the method spatial is better and easier)

[hpn]

or don't use bframes

Correct. Without bframes the small glitch at frame 40 dissapeared and the mplayer error message is gone.

x264.exe -p 1 -B 1000 -r 5 --mixed-refs --no-fast-pskip -w -m 6 -t 1 -A none -8 --me umh --interlaced --progress -o NUL b.avs

[Jay Bee]

I did some testing using hpn's command lines. The problem is I couldn't get CoreAVC to do any deinterlacing on the resulting file. This should usually happen automatically and does with other interlaced AVC files that I've tried. Any ideas what the problem may be?

[fields_g]

First off, I realize how interlaced support is in its infancy. Knowing that, I was wondering if anyone would be willing to comment about x264 taking VFR input and keeping the progressive and interlaced frames the same as the source.

Would this ever be a possibility?
What still needs to be accomplished before this could happen (both x264 and MeGUI sides)?

Thanks for the interlaced support so far. I work with lots of DV footage and this will instantly be useful.

[akupenguin]

For now, x264 doesn't support interlaced and progressive frames in the same encode. Enabling interlaced mode will penalize the compression of any progressive parts. But for whenever adaption is finished:

First, make sure your VFR content is really part interlaced. If it's mixed 30p and telecine, then interlaced encoding is not the answer.
Then, run your favourite ivtc filter to recover the progressive parts while not touching the interlaced parts. Pass the filtered video to some future version of x264 --interlaced. Remux the output file to include VFR timestamps (which were generated by the ivtc).
MeGUI would need to add timestamp remuxing part.

[dattrax]

I had a quick look at the patch, but I couldn't see whether it coded as top or bottom field first. Anyone have any idea?

Jim

[akupenguin]

Neither. Field order is not specified, as it makes no difference to MBAFF compression. Yes, I'll add it sometime for the benefit of media players without auto-detection.