using mcdeint in avidemux

[helms]

I have been experimenting with mcdeint in avidemux and have noticed that it is extremely slow. After searching the net I found this document.

http://gentoo-wiki.com/Talk:MEncoder/Rip_DVD

based on my limited understanding it seems to suggest that I can apply the filters first and use Raw RGB to create a file. Then encode with the codec of my choice using the created file as the source and it would speed up the process in some cases.

I haven't tried it yet so I don't know if it actually speeds up the process for my particular file.

My questions are:

1) is Raw RGB the same as the raw mentioned in the document above?

2) is it true that I won't lose any quality doing it the way suggested in the article above rather than the normal way?

[LoRd_MuldeR]

All my tests have shown that mcDeint is sloooooow and the result is not very pleasing.

Why not use TDeint or Yadif ???

[helms]

Actually I am in the testing phase. But testing mcdeint is going so slow. That I'm looking for ways to speed the testing up. I don't mind if mcdeint is slow if it produces good results. But i'm too impatient in waiting for the results of the test. It's been more than 24hrs and its still on the first pass lol.

I was going to test mcdeint 2:top:10 with:
1) yadif - bob temporal and spatial check - top field first
2) and yadif - bob skip spatial temporal check - top field first
3) and probably need to try mcdeint 2:bottom:10 since I'm not quite sure which field it is for mcdeint when you use mcdeint with yadif.


I've tried yadif by itself (1. temporal and spatial check and 2. bob temporal and spatial check) and the result was that it seemed to retain this weird colour problem from the source.

I've tried this filter chain as well
separate fields ---> mplayer delogo -----> resize -----> crop ----> mplayer hqdn3d -----> merge fields.

the filter chain I used with yadif by itself was the same except I replaced separate fields with yadif and dropped merge fields.

I've also tried encoding the video without de-interlacing.

looking at the resulting files both seperate fields and no de-interlacing didn't give me as noticeable weird colour problem as the source. Yadif without bob gave me similar results to the source and yadif with bob came in 2nd in its similarity to the source.

My thoughts on the source is that it is interlaced. The source is Pal 1080i captured with my TV card. Running the source through the megui auto detection thingy also reports it as interlaced. Even though it seems interlaced, encoding without de-interlacing to me didn't make it look bad. In fact in my opinion it looked better than using yadif since for some reason encoding without de-interlacing fixes slightly the weird colour problem of the source.

jpeg of source:
http://img99.imageshack.us/img99/2613/sourcenu2.th.jpg (http://img99.imageshack.us/my.php?image=sourcenu2.jpg)

yadif:
http://img411.imageshack.us/img411/3623/yadiffa8.th.jpg (http://img411.imageshack.us/my.php?image=yadiffa8.jpg)

yadif bob:
http://img213.imageshack.us/img213/2395/yadbtj8.th.jpg (http://img213.imageshack.us/my.php?image=yadbtj8.jpg)

no-deinterlacing:
http://img254.imageshack.us/img254/8240/nodekf5.th.jpg (http://img254.imageshack.us/my.php?image=nodekf5.jpg)

separate fields:
http://img88.imageshack.us/img88/6691/seperateuq5.th.jpg (http://img88.imageshack.us/my.php?image=seperateuq5.jpg)

I guess testing de-interlacing filters to see if they eliminate the weird colour problem of the source isn't the right way to go about it since that's not their purpose. I figure I might get lucky though and maybe mcdeint will fix the weird colour problem slightly in the same manner of no de-interlacing and separate fields.

In researching I've come across some other questions I'd like to ask. MeGUI's Avisynth script creator seems to have a colour correction filter.
http://mewiki.project357.com/wiki/MeGUI/HDTV_Transcoding_Guide
If your source is mpeg2, use colormatrix to correct colors: colormatrix()
Is this filter desirable? and does avidemux have a similar filter?

If I encode to h264 and set it to the avi container in avidemux will all the encoding options be used as specified? Since I read somewhere something about avi not being able to handle b-frames well or something. So maybe if I have in the settings more than 1 max consecutive b-frame or whatever option that clashes with avi's ability, it would fall back to the option that is compatible with avi's capability.

I'm thinking of using mkvtoolnix to change from the avi container to mkv instead of picking mkv directly in avidemux. Since mkv is a recent addition to avidemux I'm worried about how stable it is.

[LoRd_MuldeR]

0. That video is obviously interlaced, but it might be "telecined" as well (cannot say without a sample)
1. Encoding interlaced material as-is (without deinterlace) is okay, as long as you encode it in "interlaced" mode!
2. Nevertheless encoding the video in "interlaced" mode is less efficient than deinterlacing and encoding as progressive.
3. Your filter chain with "hqdn3d" before deinterlace might not be the best choice.
4. If I want to compare different deinterlacers, I would go without any additional denoise filter that might screw up the result
5. I wouldn't care about "slow" deinterlacer either, but "mcDeint" is very slow and doesn't produce good output -- TDeint or Yadif are preferred
6. Your video shows some "Rainbowing" effect: Try "Gauss Smooth" or "Median (5x5)", but on Chroma only (un-check Luma!) and put it after deinterlace
7. If you still have "Rainbowing" then try this chain: "StackFields" -> "Median (5x5)" (Chroma only) -> "Unstack Fields" -> Deinterlacer.
8. You should do Crop + Resize after the deinterlacing -- in case you don't deinterlace you cannot resize at all!
9. Using MKVToolnix to remux from AVI to MKV should work okay...

[Didée]

Did you already convert the source into an RGB-file on your disk, and are working from that one? Those "color problems" pretty much look like incorrect conversion from YV12(interlaced) --> RGB.

In case of doubt, we'll need a small sample of the original source file to be sure.

[helms]

Thanks, I'll try gauss smooth and median and see what I get.



separate fields ---> mplayer delogo -----> resize -----> crop ----> mplayer hqdn3d -----> merge fields.

From my limited knowledge I thought separate fields was deinterlacing and then I put hqdn3d and finally merge fields reinterlaced it. So I thought I was putting hqdn3d after the deinterlacing. But I guess it doesn't work that way.


I don't really understand the interlacing thing. I used this filter chain: mplayer delogo -----> resize -----> crop ----> mplayer hqdn3d as is without any deinterlacing or separate/merge fields and without checking interlaced mode in the h264 encoder and this is the result I got:
http://www.megaupload.com/?d=VKPFO80F
To my untrained/inexperienced eye this video looks fine compared to the source. I can't really understand why resizing without deinterlacing is bad since this sample looks fine to me.


Didee, nope I didn't convert the source to an RGB file yet. I was hoping for a reply to my first post before trying it. Since I might not try the method if you lose quality using that method or if Raw RGB under avidemux is different in someway to the raw mentioned in the document.

Here is a sample of the source video:
http://www.megaupload.com/?d=V2GE5X2K

[LoRd_MuldeR]

separate fields ---> mplayer delogo -----> resize -----> crop ----> mplayer hqdn3d -----> merge fields.

From my limited knowledge I thought separate fields was deinterlacing and then I put hqdn3d and finally merge fields reinterlaced it. So I thought I was putting hqdn3d after the deinterlacing. But I guess it doesn't work that way.

In fact you only separate the fields, apply the denoise filter on the individual fields and finally you weave the fields again.
That's a legitimate way to apply filters before doing the actual deinterlacing, but you should consider applying those filters after deinterlace.
Also this method ("SeparateFields" -> *Filter* -> "MergeFields") is not deinterlacing, it is operating on individual fields!
Especially Crop + Resize should be done after deinterlacing...


The basic chain should be:
Source -> Deinterlace (e.g. TDeint) -> Crop -> Resize -> Output

The denoise filter, if really needed, could be added this way:
Source -> Deinterlace (e.g. TDeint) -> Denoise -> Crop -> Resize -> Output

Optionally you could try like this, but I doubt it's a good idea:
Source -> StackFields -> Denoise -> UnstackFields -> Deinterlace (e.g. TDeint) -> Crop -> Resize -> Output

Fighting the "Rainbowing" effect can be achieved like this:
Source -> StackFields -> Median (Chroma only!) -> UnstackFields -> Deinterlace (e.g. TDeint) -> Crop -> Resize -> Output


Some basic info on interlacing can be found here: http://www.100fps.com/

[LoRd_MuldeR]

Here is a sample of the source video:
http://www.megaupload.com/?d=V2GE5X2K

uhmm, this looks like a bad format conversion! If you look at the individual fields, you'll notice blending in many (but not all) fields!
Also this looks like a bad analog capture that was upscaled heavily to me. Thus the strong "Rainbowing" effect. Really bad quality source for sure.
Some Avisynth script might be able to remove the blending, but I don't know if that source is worth it...


[EDIT]

Here is my attempt:
http://www.mediafire.com/?0onurtwbby4

StackFields -> Median 5x5 -> UnstackFields -> Yadif (Bob) -> hqdn3d -> Crop -> Resize

[helms]

After trying these Avisynth scripts with various parameters through Avisynth Proxy GUI and outputting YV12 (raw) in Avidemux:

Bifrost
Guavacomb
LutDeRainbow
Mfrainbow
Ssiq
Tcomb

to try and get rid of the rainbows in the hair and shirt:
jpg from your attempt:
http://img214.imageshack.us/img214/5927/finalsl9.th.jpg (http://img214.imageshack.us/my.php?image=finalsl9.jpg)

I have finally given up. I think I'm best off sticking with the method you used in your attempt. Thanks for your help and sorry for the late reply.


[start edit]
Maybe I should capture from the Standard Definition channel instead of the HD channel since the HD channel is such bad quality. But then again the SD channel probably has the same problems and I can't be bothered messing with the resizing when dealing with the Standard definitions non-square pixels. On the other hand I probably wouldn't want to resize SD captures.
[end edit]

[LoRd_MuldeR]

Well, capturing from HD channels has absolutely no sens when the original source was not SD ;)

You would only get a (poorly) upscaled version of the original video...