Disabling Divx De-interlacing

[Sliztzan]

If I want to use one of Virtualdub's internal deinterlacing filters or plugin such as Smart Deinterlace to deinterlace the video, how do I disable the deinterlace feature of the Divx codec? Presently there are only 3 options, which are Progressive, De-interlace Source, and Preserve Interlace.

If I'm going to be using a internal de-interlacer, I don't want the Divx codec using more encoding time when it's not needed and therefor possibly degrading the video by performing some type of interlacing on the video. Maybe when virtualdub is using a internal de-interlacer it automatically disables the Divx interlacer, but I don't know that answer.

Also would you happen to know if virtualdub's filters process before or after Divx resizing feature or deinterlace (if I decide to use this feature)? I understand that deinterlacing should be the very first step when encoding. Thanks for your help

[jagabo]

After deinterlacing in VirtualDub you will have progressive frames. Use the progressive setting in Divx. All filtering in VirtualDub will happen before output to the compression codec.

[Sliztzan]

Great, just the answer I've been searching for. I kinda thought that might be the answer, but I couldn't find any documentation substantiating my thoughts.
Thanks very much! I was getting real tired of searching the net for answers.

[vhelp]

Presently there are only 3 options, which are Progressive, De-interlace Source, and Preserve Interlace.
...
Maybe when virtualdub is using a internal de-interlacer it automatically disables the Divx interlacer, but I don't know that answer.

I believe that some disabling is going on but am not sure. In any case, it might be a good idea to make sure that you set the divix codec (via its config setup dialog) to either Progressive or Preserve Interlace depending on which of these they actually are prior to feeding into virtualdub else you could risk incorrect decoding of the chroma channels. But read the documentation to see whether it does anything automatically without the need to set anything during proxy (frameserving) mode.

-vhelp 4973

:P *~*!*~*!~* HaPpY HoLiDaY *~*!*~*!~*

[jagabo]

Presently there are only 3 options, which are Progressive, De-interlace Source, and Preserve Interlace.
...
Maybe when virtualdub is using a internal de-interlacer it automatically disables the Divx interlacer, but I don't know that answer.

I believe that some disabling is going on but am not sure.

No. VirtualDub has no idea what Divx is doing and Divx has no idea what VirtualDub is doing. Virtualdub does all its filtering then passes a frame to Divx. Divx then does whatever filtering it is set to do and compresses the frame.

In any case, it might be a good idea to make sure that you set the divix codec (via its config setup dialog) to either Progressive or Preserve Interlace depending on which of these they actually are prior to feeding into virtualdub

If fed interlaced YV12 video VirtualDub is going to screw up the chroma channels anyway! It always converts YV12 to RGB as if it was progressive. It's better to use AviSynth to do any YV12 processing. If you must use VirtualDub, at least use AviSynth to convert YV12 video to YUY2 or RGB. Be sure to add the "interlaced=true" argument:

Mpeg2Source("filename.d2v")
ConvertToRGB(interlaced=true)

[Sliztzan]

what is that YV12 used for when selecting divx compression. I never select that one when choosing compression type. I select the one that says Divx {multi processors} or something like that. I've always seen two selections for Divx in the choices, but never select YV12.

[jagabo]

The YV12 decoder that shows up in VirtualDub's compression dialog is just some helper driver. You don't use it directly when saving with the Divx codec.

[vhelp]

Sliztzan wrote:

If I want to use one of Virtualdub's internal deinterlacing filters or plugin such as Smart Deinterlace to deinterlace the video, how do I disable the deinterlace feature of the Divx codec? Presently there are only 3 options, which are Progressive, De-interlace Source, and Preserve Interlace.

vhelp wrote:

I believe that some disabling is going on but am not sure.

Actually, I was not saying that virtualdub does any disabling to the divx video, but maybe it came out that way, sorry if I confused anyone!

I was saying that maybe divx is doing the [s:e2945712e0]disabling[/s:e2945712e0] or should I say, sending a noncompatible sampling (chroma) format, which ultimately will not get processed correctly, still. Perhaps "disabling" is the wrong word here, but then the OP mentioned this above, that divx offers three options to configure chroma: Progressive; deinterlace; or Preserve Interlace. Ok. I'll be honest here. I did not check this out because I do not have divx installed on my machine. But I would be willing to install it if only to verify this problem still exist. I am now curious!

If fed interlaced YV12 video VirtualDub is going to screw up the chroma channels anyway! It always converts YV12 to RGB as if it was progressive. It's better to use AviSynth to do any YV12 processing. If you must use VirtualDub, at least use AviSynth to convert YV12 video to YUY2 or RGB. Be sure to add the "interlaced=true" argument:

Hmm.. I did not realize that the divx was still plauged by this problem. Again, I thought they long fixed that issue by now.

@ Sliztzan, what divx version are you using ? I'd like to verify if this issue still exist.

@ jagabo, do you have any examples of this issue, so we can duplicate it, noting which ver used ?

* note, I think that quotes are getting screwed up here

Thanks everyone.

-vhelp 4976

[jagabo]

Divx has three settings for handling progressive/interlaced video:

1) Progressive Source. Use this if your video is progressive (interlaced video that has been deinterlaced by VirtualDub is progressive when handed to Divx for compression).

2) De-interlace Source. Use this if your source is still interlaced after VirtualDub filtering and you want Divx to deinterlace to progressive frames and encode as progressive.

3) Preserve Interlace. Use this if your source is still interlaced after VirtualDub filtering and you want Divx to encode it as interlaced frames.

If fed interlaced YV12 video VirtualDub is going to screw up the chroma channels anyway! It always converts YV12 to RGB as if it was progressive. It's better to use AviSynth to do any YV12 processing. If you must use VirtualDub, at least use AviSynth to convert YV12 video to YUY2 or RGB. Be sure to add the "interlaced=true" argument:

Hmm.. I did not realize that the divx was still plauged by this problem. Again, I thought they long fixed that issue by now.

This is not Divx's fault. It's VirtualDub's.

[vhelp]

If fed interlaced YV12 video VirtualDub is going to screw up the chroma channels anyway! It always converts YV12 to RGB as if it was progressive.

Thank you. I missed this point earlier, which I knew about also, but got confused with other aspects.

Even still, this problem should have been fixed by now. Virtualdub is now at version 1.9.x something, and it still can't decode the chroma channels correct. I mean, it processes video always as progressive. I read various passages from time to time on this matter, but I would of thought that they included an option for Interalce or Progressive, if anything.

Is it certain that this problem still exists ?

-vhelp 4977

[jagabo]

If fed interlaced YV12 video VirtualDub is going to screw up the chroma channels anyway! It always converts YV12 to RGB as if it was progressive.

this problem should have been fixed by now. Virtualdub is now at version 1.9.x something

I'm using 1.8.2. The problem is in that version.

[vhelp]

I just finished running a number of decoding/encoding/decoding tests using divx as the codec and vob mpeg-2 sources. And, I did not see any of the problems mentioned in this discussion. Therefore..

I believe that this problem is no longer an issue (with the latest version(s) of virtualdub) and that there is no need to suggest avisynth as the final solution every time someone wants to work with a given codec, unless the source or codec is truely problematic, or, the person wants to apply a particular filtering that is beneficially better in a certain color space, or the editing tool is based on a previous version with known problems.

Many people work with virtualdub and its filters, and are plenty happy with it, and it is usually enough for most basic video processing work.

I am not discounting avisynth by any means. I use it more than ever, even though at one time, I used to be a virtualdub-only user. Today, I am a AVIsynth/VirtualDub user.

Look it the time.. I'm exhausted with debugging and research on this issue. Have a good night everyone, yawn..

-vhelp 4978

[jagabo]

I just checked version 1.9.0 and it has the same problem decoding YV12. I'll post samples and images tomorrow when I get time.

[vhelp]

I'll do the same, tomorrow I'll post a few frames, and maybe will get to the bottom of all this. I'm sure there's an explanation for the differences. I'll post from a scene with some RED areas since this usually brings out the issue more pronouced. The I will be using is from the dvd movie, "The Fifth Element" and the scene I will be using in that demonstartion is the McDonolds scenes, where the women is handing the police his fries..in case anyone wants to have a go at it on their computer/codec setup.

Until then, this time, its bedie-bye for me..

-vhelp 4979

[vhelp]

As it turns out, I was incorrect. The issue with virtualdub decoding YUV->RGB sources is still unresolved.
I was too quick and selective in my image scenes that I overlooked one important area, the vertical access.
Most scenes are ok. Its only when two colors (RED is more defining) cross paths that the problem is seen.

The test scenes I used..
In the scene where you see the car's blue top and red meet, (and when magnified) the issue is revealed. It is at edge of two crossing (red/blue) colors that you can see the yuv->rgb decoding problem.

Also, inside the car, where you see the red and black meet inside the car, again, the yuv->rgb decoding problem is noticable.

The problem exhist in virtualdub because of the way it handles the yuv->rgb conversion. The subsampling is the problem. In AVIsynth, when this problem was discovered, it was realized that the subsampling was part of the problem, and its algorithm was modified and fixed. I believe the modification had something to do with averaging and interpolation, basing from my memory.

When I tested with some scenes last night I thought that same algo was applied to virtualdub. I was wrong.

I will be back with pics..

-vhelp 4980

[jagabo]

Here is an MPG file that shows the problem unambiguously:

720x480.zip

One frame correctly decoded and displayed:



Notice how the red/green and black/white horizontal lines are exactly one pixel thick.

When viewed field by field you should see a green box that bounces from side to side in the red area. Directly below it is a black box that bounces from side to side in the white area.

Mpeg2Source("720x480.d2v")
AssumeTFF()
Bob()

Crops of the two fields:


When viewed on an interlaced TV you would see the green and black boxes bounce side to side 60 times a second. Of course, this is very fast so it just appears as a flicker. Here is what it looks like slowed down to 2 frames per second:



If you open the MPG file directly in VirtualDub (with MPEG2 source plugin) you will see this:



Notice how the red and green scanlines have blurred together. The colors of the two fields have blended together. If you bob this the green/red section of the two fields will look almost identical -- no bouncing green box. The black box will continue to bounce because the luma channel isn't subsampled the way chroma samples are. The green and red colors were chosen so the the luma in YUV space is nearly identical. I believe the slight horizontal striping you can see the the red/green patch is due to the luma not being exactly identical.

Using DgIndex to decode to YV12, VirtualDub does this:

Mpeg2Source("720x480.d2v")

You can see red and green horizontal lines but they are now two pixels thick and not as pure as they originally were. This will not bob correctly like the earlier example:



Notice how the black box is still clean but the green box is messed up.

Converting the YV12 to RGB in AviSynth with:

Mpeg2Source("720x480.d2v")
ConvertToRGB(interlaced=true)

Gives the correct image, the first image above.

The effects are much more subtle on the photo realistic part of the frame (provided as a sanity check). And, in fact, incorrect handling actually looks smoother at times (this is why I use test patterns for this type of test). But keep in mind that moving parts of the picture will be messed up, even if the static parts of the frame look a little better.

Beware of drawing any conclusions when viewing the MPG file on a computer monitor. Media players and display drivers are likely to screw up with interlaced video.

[Sliztzan]

vhelp wrote:

Hmm.. I did not realize that the divx was still plauged by this problem. Again, I thought they long fixed that issue by now.

@ Sliztzan, what divx version are you using ? I'd like to verify if this issue still exist.


Thanks everyone.

-vhelp 4976

I'm using Divx codec version 6.8.5

[jagabo]

Once again, the chroma subsampling bug we were discussing is in VirtualDub, not Divx.

I just verified that Divx (when it receives properly interlaced video to begin with) handles interlaced video properly.

[Sliztzan]

I tested that mpeg file in VirtualDub and had the same results as you. Has anyone passed on this issue to Avery Lee?
He is now working on the software again at 1.90 beta

[jagabo]

I never have.

<edit>

I just sent him an email.

[Sliztzan]

oops... I just did too. Well, maybe one of them will get read.

[Sliztzan]

I didn't expect a reply at all, but I got one very quickly from Avery Lee. I'm just passing along the information, so don't kill the messenger. I don't even understand this subject. Here is his reply:

"Sorry, but this isn't a bug in VirtualDub. There is no such thing as "interlaced YV12" because the YV12 FOURCC only denotes progressive chroma and there is no way to indicate that it is interlaced. This problem occurs because people have started overloading and misusing the YV12 FOURCC without thinking about the compatibility problems."

[jagabo]

LOL. Avery Lee has a penchant for doing what's technically correct rather than what works. He may be right that there should be a separate fourcc for interlaced YV12 but I think he is in the minority. He finally gave in on his insistence that everybody was doing VBR MP3 wrong earlier this year and finally accommodated what other programs were doing. So maybe in 5 years he'll take care of the YV12 issue. At least AviSynth gives us a way around this problem.

[nymph4444]

I am trying Virtualdub and you may have seen my other post on this website about interlace.

If I bring a video that is interlace into Virtualdub's can I convert it to another file but have Virtualdub's not de interlace it?
Can I turn off de interlace in Virtualdub's and have my output file be interlace?