Alternate scan for XviD interlace encoding? [Archive]

View Full Version : Alternate scan for XviD interlace encoding?

ronnylov

10th April 2002, 15:52

I have done som encoding in MPEG-2, especially interlaced PAL video source from my miniDV-cam. When encoding interlaced in MPEG2 you should set the encoder to alternate scan order instead of zig-zag scan.

It seems that XviD now have interlaced encoding support. If I choose interlaced encoding, will it automatically switch to alternate scan order or do I have to set it manually somewhere? The reason I ask is that when setting up custom quanticer matrices it is important to know the scan order to get the best possible results. I want to test if I can use my quantizer matrices I use for MPEG2 also when encoding XviD in interlaced mode...

avih

10th April 2002, 16:02

the matrices have nothing to do with interlaced clips. and u don't have control over the zigzag compression.
they just control the quantization process. the interlaced support for xvid gives better quality/bits for interlaced clips since it 'understands' the source is interlaced, and if artifacts are present it encodes them as 2 fields instead of one, on a per-macroblock basis if i understand correctly.

ronnylov

10th April 2002, 19:10

-h

11th April 2002, 00:52

OK, so I wanted to test it. But when trying to save my matix and then open it again I still got the default matrix. It seems impossible to change it! I have selected the MPEG custom quantization type to make it possible but it did not help. Also if I just change the matrix manually and press OK then I still got the default matrices when I edit the matrix again. I guess this must be a bug.

Hehe, sounds like I broke it.

Why wouldn't alternate scan order be better than zig-zag scan for interlaced XVID when it's better for interlaced MPEG2? Aren't all macro blocks encoded in field mode when it is interlaced? How does the encoder know if there are artifacts or not? If I set the encoder to interlaced mode I would like to encode all macro blocks in field mode and with alternate scan order. But I don't know how the encoder works and it is possible that alternate scan order is no benefit for MPEG4?

First of all, what does the alternate scan *do*? There is an MPEG-4 VOP flag that lets us specify top-field-first and alternate-vertical-scan on a per-frame basis. Top-field-first is obvious, but I have found nothing about what alternate-vertical-scan actually does.

Here's what happens at the moment:

If interlacing is enabled, the encoder checks, on a per-macroblock basis, whether there are interlacing artifacts. This is an expensive check (~1400 subtractions per macroblock, yuck), but I'll upload some asm optimizations "soon". If it's interlaced, the encoder deinterlaces the blocks vertically and sends them to the DCT/quantizer in a deinterlaced state - same as MPEG2. From then on it's the same as MPEG4 - the different prediction modes (normal zig-zag, vertical scan, horizontal scan) are all attempted, and whichever is smallest is used.

I'll add a checkbox to force all macroblocks to use the field-based DCT, bypassing the expensive choice. I suppose you could force a zig-zag direction, but it wouldn't make much sense - the existing prediction routines only use ~1% of encoding time, and will compress files much better than forcing the flag.

-h

ronnylov

11th April 2002, 16:29

Check out this explanation. It's automatically translated from German language so it is not very well translated:
Link (http://www.teletranslator.com:8080/gastbeitraege/kika001_dct.htm?AlisTargetHost=http://www.edv-tipp.de&AlisUI=none&AlisTargetLang=en&AlisUILang=en)

Here it's in original language:
http://www.edv-tipp.de/gastbeitraege/kika001_dct.htm

If you scroll down on the page you will find pictures of the the scan order, zig-zag versus alternate scan. This is for MPEG-2.

I did a test encoding yesterday. The quality was roughly about the same as MPEG-2 using the same frame size and bitrate. The problem is how to playback the interlaced video. I used the TVtool software to configure my TV-out to view fullscreen interlaced mode at 768x576 pixels (needed a modified NVidia-driver to do that) and together with zoomplayer set to 4:3 aspect ratio, full screen I could view 480x576 pixel resolution interlaced mode XVID on my TV. I live in Sweden so I must keep the vertical resolution to 576 pixels.

I had problems to get the correct field order. It seemed to randomly change between top field first and bottom field first when pressing stop and start again. But I guess there is no way for the player to synch the field order with the TV-out so it plays bottom field first all the time. I guess the interlaced mode would be best if it was used in a hardware encoder. I have an AthlonXP1800+ and still got some choppy playback (and sometimes the framedrops caused a change of the field order at playback). The hardware encoder must know how to play it with top or bottom field first so I think this flag should be used and possible to change when encoding. I did not found where to change the field order setting. Will the interlace mode work in the MPEG4-decoder used in future standalone players?

One way to compare the quality with MPEG-2 could be to convert the interlaced XVID to DV-format end export it to tape and view it from the camcorder connected to the TV. Then I could do the same with the MPEG-2 file and see what gives best results. I'll see if I get some time to do some tests...

TheBashar

11th April 2002, 18:54

You can also find a little information on alt scan in this document:
http://bmrc.berkeley.edu/research/mpeg/faq/mpeg2-v38/faq_v38.html#tag15

The only advantage may be its already in English.

-h

12th April 2002, 00:32

Check out this explanation.

Oh ok, it's just the zig-zag scan that changes. That's very confusing. MPEG-4 does this check on a per-macroblock basis, and if the alternate (in this case alternate-vertical) scan compresses better, it uses it, else it uses normal or horizontal zig-zagging. So this is already being done.

With that in mind, I have no idea whatsoever as to what the alternate-vertical-scan bit does in the frame's VOP header, as we already select the scan direction on a per-macroblock basis.....

I did a test encoding yesterday. The quality was roughly about the same as MPEG-2 using the same frame size and bitrate. The problem is how to playback the interlaced video. I used the TVtool software to configure my TV-out to view fullscreen interlaced mode at 768x576 pixels (needed a modified NVidia-driver to do that) and together with zoomplayer set to 4:3 aspect ratio, full screen I could view 480x576 pixel resolution interlaced mode XVID on my TV. I live in Sweden so I must keep the vertical resolution to 576 pixels.

Yeah it'll probably be about the same at the moment (well my TMPGEnc tests showed XviD to be marginally better at equivalent bitrates), but that's because XviD doesn't yet have field-based motion estimation, which is a big advantage.

I want to add this, however a lot of things are changing in XviD's motion estimation at the moment, so I'm not sure when it will be done.

I had problems to get the correct field order. It seemed to randomly change between top field first and bottom field first when pressing stop and start again.

Can't explain that. *Every* frame is encoded as top-field-first, so if it's wrong on the TV, it's wrong in the source.

I have an AthlonXP1800+ and still got some choppy playback (and sometimes the framedrops caused a change of the field order at playback). The hardware encoder must know how to play it with top or bottom field first so I think this flag should be used and possible to change when encoding. I did not found where to change the field order setting. Will the interlace mode work in the MPEG4-decoder used in future standalone players?

Well, if you feed XviD an interlaced stream, it stores fields *exactly* as they were fed into it - it doesn't flip fields, skip them, change them at scene changes, or any such munging. The fields that go in are the same as the fields that go out. Any problem with field order is the responsibility of the player getting it wrong, as I can guarantee that XviD doesn't change anything in that regard.

I'm a bit worried about the playback performance though, interlaced decoding is as fast as progressive decoding. Perhaps your drivers are a big iffy?

One way to compare the quality with MPEG-2 could be to convert the interlaced XVID to DV-format end export it to tape and view it from the camcorder connected to the TV. Then I could do the same with the MPEG-2 file and see what gives best results. I'll see if I get some time to do some tests...

The MPEG-2 will most likely look better, the quantization system of MPEG-4 doesn't like extremely dark areas (it subtracts too much). That's the most immediate thing I'd notice when watched on a TV.

-h

ronnylov

12th April 2002, 15:37

Thank You -h!

Now I understand a little bit more of how it works. The playback problem is probably caused by the player which don't know what field is outputted by the TV-out at the moment it starts the playback. The TV-out is just alternating between top and bottom field and don't know what kind of picture it's fed with. Mini-DV source is always with bottom field first so the player should tell the TV-out generator that this frame is encoded as bottom field first so don't start the playback of this frame if the TV-out is wieving the top field, wait until bottom field is generated. And the other way around for top field first video.

So if there is a flag in the video header it could be used by the playback device to get it right on the TV. Otherwise it must analyse the field order before starting playback. I don't think my software player in my computer can communicate with the TV-out of my graphics card. Perhaps this is a driver issue, I don't know. But if this was done by a hardware decoder card with integrated TV-out it could make it easier for the decoder to just choose the correct field order according to the flag setting instead of analyzing the video. When the field order is wrong the picture movement on the TV will jump back and forward during playback and this is very annoying.

But now I know that the field order is always top field first in the XviD encoder so I could change the field order in the pre-processing before encoding. This can be done in virtualdub and the smart deinterlacer set to phase shift and field swap before phase shift (or after phase shift depending if changing Low-top or top-low). The deinterlacing is switched off by "no motion search" in the smart deinterlacer filter. So if it is a rule that XviD encoded interlaced frames always must be encoded with top field first then the playback device don't need to know the field order, it can assume top field first always. But it still need to synch the TV-signal generator with the frames to ensure that the top field always is displayed first.

So I have a 50 % change to get the right field order if the player is not synched with the TV-generator. By pressing pause and then start again it may start the playback in synch with the TV-generator on my graphics card. When my CPU-power is not good enough to output all frames in real time (if the frame size is too big or if any background program is disturbing playback) then it may randomly become unsynched and the field order is wrong again. This problem is probably not as visible when playing progressive video, you can't see if there is a short half-frame pause in the playback once and a while.

But still it's nice that XviD can be used as backup for interlaced video. If the quality is good enough I could store backups on CD-ROM which don't take as much space as original DV-AVI. And even better if we could get methods for proper playback in standalone players or hardware decoder cards. It's a little bit tricky to do the rezising correctly without destroying the interlaced playback but I think that as long as I'm not rezising vertically it will work. I have done some interlaced SVCD so I just tested this with the same rezising methods. Perhaps 384x576 is a good resolution that could get VHS-like quality for PAL video encoded XviD. Thats half the resolution of my TV-out.

Maybe somebody have good guides about how to output interlaced XVID
from the PC to the TV?

-h

13th April 2002, 00:44

So if there is a flag in the video header it could be used by the playback device to get it right on the TV. Otherwise it must analyse the field order before starting playback. I don't think my software player in my computer can communicate with the TV-out of my graphics card. Perhaps this is a driver issue, I don't know. But if this was done by a hardware decoder card with integrated TV-out it could make it easier for the decoder to just choose the correct field order according to the flag setting instead of analyzing the video. When the field order is wrong the picture movement on the TV will jump back and forward during playback and this is very annoying.

Yeah the problem is, how does the codec know which field is first? The switch is only there (AFAIK) so someone can specify the field order manually, it's not meant to be auto-detected or anything, as that would be a conceptual nightmare.

The other thing is, XviD isn't returning fields 1 at a time or anything, but the entire frame, so the idea of one of them coming first is a misnomer.

So I have a 50 % change to get the right field order if the player is not synched with the TV-generator. By pressing pause and then start again it may start the playback in synch with the TV-generator on my graphics card. When my CPU-power is not good enough to output all frames in real time (if the frame size is too big or if any background program is disturbing playback) then it may randomly become unsynched and the field order is wrong again. This problem is probably not as visible when playing progressive video, you can't see if there is a short half-frame pause in the playback once and a while.

Ah ok, it's definitely your drivers doing odd things to you.

But still it's nice that XviD can be used as backup for interlaced video. If the quality is good enough I could store backups on CD-ROM which don't take as much space as original DV-AVI. And even better if we could get methods for proper playback in standalone players or hardware decoder cards. It's a little bit tricky to do the rezising correctly without destroying the interlaced playback but I think that as long as I'm not rezising vertically it will work. I have done some interlaced SVCD so I just tested this with the same rezising methods. Perhaps 384x576 is a good resolution that could get VHS-like quality for PAL video encoded XviD. Thats half the resolution of my TV-out.

Yeah eventually you'll be able to select in XviD whether you want top- or bottom-field-first, but it'll still assume that the field order stays continuous through the entire stream (which I'd hope would be the case anyway).

Also I should mention that, the field-first flag in MPEG-4 does absolutely nothing to the codec's internal decoding system - it's purely informational, and I guess meant for directing a specialist software/hardware MPEG-4 player as to which field should have been displayed first given an interlacing output device.

Oh and as for resizing, I know trbarry has written a SmartResize filter for avisynth (can't remember the exact name :)) that can perform resizing of interlaced content. An ugly way to do the same is:

# resize DV avi from 720x576 to 640x480, preserving fields
AVISource("foo.avi")
SeparateFields()
BilinearResize(640,240)
# temporal filter should be applied here - works better on fields than frames
Weave()
# end avs script

Maybe somebody have good guides about how to output interlaced XVID
from the PC to the TV?

Couldn't help you there :)

-h

avih

13th April 2002, 01:07

vdub resize supports interlaced resize.
top/bottom 1st is used at least with mpeg2.

my card captures the opposite, and changing this bit (in tmpegenc) causes my svcd to play interlaced right on a stand alone dvd player (needless to say, leaving the flag at the original position causes jumpy playback)

avi.

trbarry

13th April 2002, 03:24

The SimpleResize filter supports an optional InterlacedResize() command that treats the even and odd lines as offset sample points and doesn't blend them. Not to be confused by the SimpleResize of the Elecard dshow filter, which is just a nearest neighbor funtion. I picked a stupid name.

...

As far as the TopFieldFirst info ... if you have a deinterlace or IVTC filter than you likely want to know which way it is. For instance GreedyHMA using top first will match that top field with either the current or previous bottom field, depending upon which makes the lowest comb/weave factor.

But if it was processing bottom first than it would match the bottom field (or individual pixels for video source) with those from either the current or previous top field. It's possible to compare tops to bottom both ways and get a good idea which is first but I've never coded that and it would be slower than if the info was just nicely passed along. All this for info that arives in frames of 2 fields each. For GreedyHMA in Avisynth I make the user specify it as a parm but it has greatly added to the confusion of using a filter with too many parms anyway.

For Greedy/HM in DScaler we get the fields one at a time from the capture card with a hardware register flag saying whether they are even or odd, so there is no problem.

But it is info you really have to have for some processing.

- Tom