Log in

View Full Version : MeGUI: General Questions and Troubleshooting Thread


Pages : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 [129] 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186

LigH
29th November 2011, 11:11
... are there any switches that may be needed (or increase quality) when processing B&W movies ?

x264 is smart enough not to waste bits on empty chrominance components. You might try to enforce their emptiness with filters, though (e.g. Greyscale() would enforce neutral U and V components in a YUV color space, and x264 expects YV12).

JoeH
30th November 2011, 08:39
I will try this, but this will not help Vegas, which takes ages to random access the videos too when editing in the timeline.
I have tried to encode with handbrake, I have no issues for random accessing either in MPC-HC or Vegas. But I cannot use it for two reasons : I make custom avisynth scripts, and I want to encode interlaced.

Etienne

The issue about not being able to seek in MPC-HC is probably due to the mux. I've not tried it with MP4, but with MKV it is necessary to REMUX the file after outputting in MKV format. The reason is that X264 doesn't know how to include the info your video player needs to seek quickly - this is done by the muxer once the file is ready.

For the problem about Vegas timelines painting slowly, here is the solution I use (which works very well). First I index the MeGUI output using the FFMS file indexer. It is very important that you have the option to use the FFMS multithread version!! This makes a huge speed difference. To do so, in your MeGUI options, set the FFMS thread number to 0.

Then follow the instructions here to "mount" your AVS file pointing to the FFMS index. You will input your "mounted" file into Vegas. There are different ways of doing it, I recommend the way I describe because it is extremely stable and works great with Vegas, but feel free to try hello_hello's workflow as well: http://forum.doom9.org/showthread.php?t=162006&highlight=mount+avisynth

Music Fan
30th November 2011, 10:09
with MKV it is necessary to REMUX the file after outputting in MKV format.I don't understand what you mean. You remux the MKV in MKV ?:confused:

LigH
30th November 2011, 10:58
Exactly that: The incomplete MKV from x264 is remultiplexed to a complete MKV, including what was missing because x264 didn't know that before it was finished (a keyframe index etc).

Music Fan
30th November 2011, 11:06
But why would the first MKV be incomplete ? To mux one time th emp4 in MKV should be enough. I'm confused.

LigH
30th November 2011, 11:59
x264 is able to create an MKV file containing only the MPEG4-AVC video it encoded, if it was compiled with MKV support.
x264 is able to create an MP4 file containing only the MPEG4-AVC video it encoded, if it was compiled with MP4 support.
x264 is able to create a raw *.264 file being only the MPEG4-AVC video it encoded; but raw video doesn't contain several details about the video stream, therefore it is preferable to have x264 create its result inside a container format. But x264 creates only basic containers. That's usually no problem because if you want to combine the AVC video with additional audio streams, it has to be remultiplexed, anyway. It is only a problem if you want to open this intermediate result already with tools relying on a complete container.

Music Fan
30th November 2011, 12:32
Ok, thanks ;)

JoeH
1st December 2011, 08:53
I don't understand all the details behind it, but basically there is information that is necessary to quickly seek within a file which X264 cannot know until the file is complete. So X264 simply doesn't include that info. Then, when you remux the file, the muxer adds that seek info to the container.

protoz
24th December 2011, 06:35
I have problem merging several anime part [mp4] because the source is variable framerate, while on my first try using:

AlignedSplice(DirectshowSource("D:\MOVIES\Macross1.mp4"),DirectshowSource("D:\MOVIES\Macross2.mp4"),DirectshowSource("D:\MOVIES\Macross3.mp4"))

the result [mkv] is constant framerate, and the audio is out of snyc. How to make it variable framerate with the audio snyced?

LoRd_MuldeR
24th December 2011, 20:28
I have problem merging several anime part [mp4] because the source is variable framerate, while on my first try using:

AlignedSplice(DirectshowSource("D:\MOVIES\Macross1.mp4"),DirectshowSource("D:\MOVIES\Macross2.mp4"),DirectshowSource("D:\MOVIES\Macross3.mp4"))

the result [mkv] is constant framerate, and the audio is out of snyc. How to make it variable framerate with the audio snyced?

How did you create the source MP4 files?

hello_hello
25th December 2011, 19:34
I have a question regarding "force film". Being in PAL-land I have very little experience with IVTC, but today's NTSC DVD encode..... well hours and hours of messing around with scripts and d2v files trying to get satisfactory results has at least given me a better understanding.

My problem was, I could encode the DVD using AutoGK and as is invariably the case, the result was perfect. MeGUI... not so much in places. Whenever I used MeGUI to analyse the video it stated it was progressive, which looking back now seems somewhat misleading as MeGUI's log file indicates it applied "force film" while indexing, which the way I now understand it alters the d2v file which in turn effects the analysis. It doesn't however change the fact the DVD is actually a hybrid (as reported by AutoGK). It wasn't until I eventually thought to give up on modifying the script and instead used the d2v file AutoGK created that MeGUI's analysis reported it as a hybrid and I could finally encode it correctly. From there I went on to experimenting with DGIndex, discovered the only d2v file which was "incorrect" was the one MeGUI created, and from there to MeGUI's log file which finally led me to understand why.

My question is (and while I still only have a vague understanding of when "force film" should be used), is force film normally applied by encoding programs by altering the d2v file to making the video appear to be purely progressive, or can it be applied after the analysis? Or can it at least be applied in such a way the user might be more likely to be aware of it, such as a pop-up prompt etc?

Maybe being in PAL-land maybe I'm missing something here, and I guess from now on I'll know to check the log file or index the DVD manually, but in my case at least I didn't have any reason to suspect MeGUI's d2v file would be any different to AutoGK's d2v file so I couldn't understand why the hours I spent trying to apply various IVTC methods (including simply using parts of AutoGK's script with MeGUI) wouldn't result in a satisfactory encode.

forum king
28th December 2011, 21:08
First of all Greetings and
Merry Xmas and Happy holidays mates :)

I have been busy so in these holidays just decided to do some refined ripping ( LOL )
just starting everything a fresh got upto 2069 ( development build )
but strangely there there are no x264 presets , as far as i remember there were like 20 or 30 profiles before.

i was planning to tryout some standard and some high definition presets with recommended default settings.

could you great guyz plz enlighten me where to find the recommended x264 profiles for a 2 pass bit rate based conversion for DVDs and blurays, and if there are none anymore then could i be advised how to go about making few profiles which can give optimum quality in the encodes.

I am aware of preset slider and settings thereby but there were a lot of tweaks which were suggested to me by the GURUS here on various ocassions to get better results than what i used to get.

regards and apologies upfront if my queries in any way violate any of the rulez of our forum.

hello_hello
28th December 2011, 22:41
The presets are gone. There's now a target device setting in x264's configuration options instead. If you tick the "show advanced settings" box and change the presets you can check the x264 settings under the other tabs and watch the appropriate ones change accordingly, but not being a guru I don't know of any special tweaks beyond that.

For optimum quality I wouldn't be using 2 pass encoding though, I'd use (in fact I do) constant quality encoding instead.
The former lets you pick the file size which determines the quality without knowing what it'll be, while the latter lets you pick the quality while the file size will be a mystery, and it's way faster than 2 pass encoding. For optimum quality the second option is probably the better one.

szabi
30th December 2011, 21:10
Hi

I have 3 avs file.
First (muk.avs):
AVISource("E:\my movie.avi").Trim(1550,1960).ConvertToYV12()
Second has same video as first, with slow motion effect (slow.avs):
a=AVISource("E:\my movie.avi").Trim(1676,1682).ConvertToYV12()
super = a.MSuper(pel=4)
backward_vec = MAnalyse(super, isb = true, search=5)
forward_vec = MAnalyse(super, isb = false, search=5)
a.MFlowFps(super, backward_vec, forward_vec, num=400, den=1, ml=400)
AssumeFPS(25,sync_audio=true)
SSRC(48000)


Now they are mixed in third script (mix.avs):
x=DirectShowSource("muk.avs",25).FadeIn(25).FadeOut(15)
y=DirectShowSource("slow.avs",25).FadeIn(15).FadeOut(25)
z=BlankClip(x,length=15)
z+x+z+y

It can be opened with VirtualDub, which is used to check and the script is correct.

Now my problem, the megui get crash with opening mix.avs script.
I do not understand why.
Could anyone give me help?

bye
szabi

Zathor
31st December 2011, 00:10
What kind of error message do you get? :logfile:

szabi
31st December 2011, 07:44
Hi

General windows error message, application is stopped check a solution on internet
Anyway MeGui can open the muk.avs and the slow.avs without problem.
Problem comes by mix.avs.
I modified it to even simple one:
x=DirectShowSource("muk.avs",25)
y=DirectShowSource("slow.avs",25)
x+z
But it still crashes megui.

Whether, can megui handle script in script?

bye
szabi

TakuSkan
2nd January 2012, 09:29
Hi... I'm not all that savvy when it comes to a lot of video processing and anything but very basic use of MeGUI from simple guides I've read. Recently I've been recording a TV show in Windows Media Center that I've been editing to MPEG-2 files, and then compressing to h264 mkv files with MeGUI.

But while watching a few of the mkv files, I noticed a lot of distortion that I think was due to MeGUI finding the source to be 'hybrid film/interlaced mostly film' and setting the deinterlace filter as TIVTC. In the resulting mkv I could see horizontal lines of distortion not visible in the MPEG-2 source that look like the results of poor deinterlacing.

So I switched the filter to 'Decomb IVTC', and the processed mkv files now look much better, and I don't see the problem of what seemed to be poor deinterlacing artifacts anymore.

In the process of tracking down the problem, I noticed that MeGUI is converting the source NTSC framerate of 29.97 down to 23.976. I was wondering if the loss of frames might be a cause of concern. But from what I've read in Doom9 threads about AutoMKV, it seems this is due to the process of detinterlacing and conversion to a progressive format, and shouldn't result in any major loss of quality.

Does this all sound right? I've come to like using MeGUI to compress video to h264 encoded video in matroska containers for a number of reasons. But I almost gave up on it during this whole process when I found TMPGEnc Xpress produced sharp mp4 files 'out-of-the-box' from the same source MPEG-2 files without running into the problems I ran into with MeGUI.

Thanks for any feedback
TS

MrVideo
2nd January 2012, 10:59
Hi... I'm not all that savvy when it comes to a lot of video processing and anything but very basic use of MeGUI from simple guides I've read.

From reading your query, you also need to understand a few things.

First off, HD video is not NTSC or PAL. Technically, no digital video is NTSC or PAL. NTSC and PAL are technical specifications for analog video. Once analog video is converted to digital, it is no longer NTSC or PAL. It is either 480i29.97 or 576i25. Digital video is described by its vertical size, interlace or progressive (i or p) and the frame rate. But that has nothing to do with your issues.

In the states, video that is sent to the consumers for viewing is done so at a frame rate of 29.97 (not 30 because of having to deal with old 4:3 analog color/B&W video at 29.97). But, all scripted dramas are produced at 23.976 fps, either shot on film and converted to digital or shot using digital video cameras (hardly anyone uses film anymore). This allows for easier conversion to 25 fps for overseas sales, just like movies.

In the U.S., the 23.976 frame rate is converted to 29.97 using what is known as 2:3 pulldown (incorrectly described as 3:2 pulldown). That results in what can look like three frames of progressive video and two frames of interlaced video (for 1080i). But it is all 100% interlaced video. For those broadcasting in 720p, there is no interlacing. You appear to be dealing with 1080i content, so that is what I'll deal with here.

For sports content, the source is 100% interlaced video. While there are those that can't stand interlaced video, deinterlacing reduces time spatial information and vertical resolution (beyond the topic at hand). I hate deinterlacing.

So, it seems that you are dealing with a scripted drama, which means that the source was 23.976 and it was converted to 29.97 using 2:3 pulldown (google it to learn more).

You do not want to deinterlace programs that came from 23.976 source video. You want to IVTC, which will convert your 1080i29.97 video to 1080p23.976.

I personally do not use MeGUI. I use to, until I wrote my own scripts to do my work. I have cygwin installed on my XP computer, which gives me Unix scripting capability that is many times better than what Windblows has. It also gives me finer control than what MeGUI produces. This way I build my own AVIsynth scripts that are used to IVTC the video and feed it to the x264 encoder. As it has been a long time since I've used MeGUI, things have probably changed. Even so, there is a setting wrong somewhere that is not resulting in correct IVTC,

A simple IVTC AVISynth script contains the following:

LoadPlugin("C:\Program Files\DGAVCDecNV\DGDecodeNV.dll")
dgsource("=DRIVE=\=FILENAME=.dgi")
assumetff()
telecide(post=0,y0=750,y1=1079)
decimate()

The y0 and y1 values tell the telecide filter to ignore lines 750 thru 1079 (line numbering starts at 0, not 1), so that those damn snipes do not affect 2:3 pulldown detection. That number may not cover enough area these days, as the A-holes are covering more of the screen with those stupid snipes.

The first two lines deal with the program to decode the MPEG-2, or H.264, video. Go to http://www.neuron2.net/dgdecnv/dgdecnv.html for details. You'll need a Nvidia graphics card.

As a final note, 'hybrid film/interlaced mostly film' does not exist for U.S. scripted programming. Shows that review movies, or even scripted TV shows, will have the talent shot at 100% interlaced video, with the video from a movie or TV show containing 2:3 pulldown. For those shows, do not deinterlace or IVTC, leave it alone, keeping the 1080i29.97 frame rate intact.

Interlacing is not distortion.

TakuSkan
2nd January 2012, 14:46
Wow... that's a lot to digest right now in a moment when I'm a bit short of time. Thanks so very much for your insight here. I'll read through it more carefully later today.

Meanwhile I thought I ought to mention that the program I'm recording is an old B&W show that was broadcast in the 50s & 60s here in the US. So I was guessing that there may have been remnants of interlacing in the digital source file that was introduced somewhere between the original 50s film and the digital file being broadcast. Does that make any sense?

Zathor
2nd January 2012, 16:16
General windows error message, application is stopped check a solution on internet
Anyway MeGui can open the muk.avs and the slow.avs without problem.
Problem comes by mix.avs.
I modified it to even simple one:
x=DirectShowSource("muk.avs",25)
y=DirectShowSource("slow.avs",25)
x+z
But it still crashes megui.
Thanks for the report. Your script is not seekable and crashes the video player when jumping to the middle of the video. I added an error handler (so no crash anymore) and changed the default start position of the video player to the beginning (so your video can be displayed - but you can not jump around / move backwards). The fix will be in the next development release (2076+).

Zathor
2nd January 2012, 16:18
Meanwhile I thought I ought to mention that the program I'm recording is an old B&W show that was broadcast in the 50s & 60s here in the US. So I was guessing that there may have been remnants of interlacing in the digital source file that was introduced somewhere between the original 50s film and the digital file being broadcast. Does that make any sense?

Please post a short sample file if possible.

Betsy25
2nd January 2012, 18:11
Is it normal, after the File Indexer has finished indexing the file, the Avisynth Script Creator window opens, which has "Clever anamorphic encoding" ticked by default. However this does nothing unless you first uncheck it then check "Resize" & "Suggest resolution mod16" & then check "Clever anamorphic encoding" again. ?

szabi
2nd January 2012, 19:50
Thanks for the report. Your script is not seekable and crashes the video player when jumping to the middle of the video. I added an error handler (so no crash anymore) and changed the default start position of the video player to the beginning (so your video can be displayed - but you can not jump around / move backwards). The fix will be in the next development release (2076+).

Hi

Thanks for this quick react on it. :cool:
I can say nothing else but maximal respect on your work. :thanks:

bye
szabi

Zathor
3rd January 2012, 00:45
Is it normal, after the File Indexer has finished indexing the file, the Avisynth Script Creator window opens, which has "Clever anamorphic encoding" ticked by default. However this does nothing unless you first uncheck it then check "Resize" & "Suggest resolution mod16" & then check "Clever anamorphic encoding" again. ?

No, I do not have this problem. Are you using 2076? Which type of input file?

MrVideo
3rd January 2012, 05:53
Meanwhile I thought I ought to mention that the program I'm recording is an old B&W show that was broadcast in the 50s & 60s here in the US. So I was guessing that there may have been remnants of interlacing in the digital source file that was introduced somewhere between the original 50s film and the digital file being broadcast. Does that make any sense?

This can't be replied to with a simple answer. The request by Zathor for a sample is the only way in which an answer will be forthcoming.

Here's why. The programs could have been live, or shot on film. If live, they were kinescope film recorded (film camera pointed at a TV screen). The film will have interlaced artifacts from the TV screen as well as interlace artifacts when later transferred to video tape, when tape became the norm.

If shot on film, then it would have the 2:3 pulldown done when eventually transferred to NTSC analog tape.

What is the TV show? I might know the source.

In any event, we still need a sample.

TakuSkan
3rd January 2012, 09:11
Please post a short sample file if possible.
Here's a download link (http://www.mediafire.com/?92ufd29r9n4rfs2) for a short clip from the source MPEG-2 video. The show is 'The Rifleman.'

Here's a VDub anamorphic screenshot from the source MPEG-2 video. MeGui analysis reports it as being 'hybrid film/interlaced mostly film,' and you can see what seems to be partial interlacing from the OTA broadcast:

http://i515.photobucket.com/albums/t352/pequickit/TR-Clips/mpg_Frame_32804_0-18-14-560.jpg

Here's the same shot from an h264 mkv video file MeGUI compressed from the MPEG-2 source cropped & resized 4:3 :

http://i515.photobucket.com/albums/t352/pequickit/TR-Clips/mkv_Frame_26254_0-18-15-010.jpg

Here's the same shot from an h264 mp4 video file TMPGEnc Xpress compressed from the MPEG-2 source cropped & resized 4:3. Notice how much better it is:

http://i515.photobucket.com/albums/t352/pequickit/TR-Clips/mp4_Frame_32805_0-18-14-557.jpg

Here's the only things I set in MeGUI:

Input DAR: 4:3
Crop: Autocrop 8,4,-4,0
Resize: 720,480 < I changed this to 704,528 in the avs script
Source type: 'hybrid film/interlaced mostly film,'
Field order: Top Field First
Deinterlace: Decomb IVTC < Also tried 'TIVTC' and 'TIVTC + TDeint(EDT) -- slow'

For the life of me I can't figure out how I set MeGUI for processing that sample clip that gave pretty good results. Were the good results because of small size of the clip for some reason? Here's the same shot made from the clip (download link above):

http://i515.photobucket.com/albums/t352/pequickit/TR-Clips/mkv_clip_Frame_601_0-00-25-067.jpg

I thought the only thing I set different in MeGUI to compress that sample to an h264 mkv file was to set deinterlacing to 'Decomb IVTC.' But I've tried running the full MPEG-2 source through MeGUI with the same settings (screenshot 2nd from the top above), and I can't seem to reproduce the results I got in that sample clip.

Would MeGUI converting the framerate from 29.97 down to 23.976 have affected things?

'Tis a puzzlement.

TakuSkan
3rd January 2012, 09:24
Here's the avisynth script MeGUI is producing when I process the MPEG-2 source using 'Decomb IVTC':

LoadPlugin("C:\<path>\DGDecode.dll")
DGDecode_mpeg2source("C:\<path>\<filename>.d2v", info=3)
LoadPlugin("C:\<path>\MEgui\tools\avisynth_plugin\ColorMatrix.dll")
ColorMatrix(hints=true, interlaced=true, threads=0)
LoadPlugin("C:\<path>\MEgui\tools\avisynth_plugin\Decomb.dll")
AssumeTFF().Telecide(guide=1).Decimate(mode=3,threshold=2.0)
crop( 8, 4, -4, 0)

LanczosResize(704,528) # Lanczos (Sharp)
#denoise

LigH
3rd January 2012, 09:39
The interlacing analysis by MeGUI is a suggestion, but hardly foolproof. It is not even sane in all cases (I have a TV news report with a lot of almost static closeups, which is plain interlaced PAL, but MeGUI detects it as "hybrid film/interlaced, mostly interlaced" and suggests "TIVTC" as Deinterlacer, which is clearly wrong, because PAL is never telecined). The interlace pattern detection HDConvertToX uses seems to be more reliable.

Your 2nd and 3rd screenshot reveal that the suggested solution does not match your case. The video source is probably still combed (means: containing visually different fields in one frame), but was encoded in progressive mode, which means an obviously bad result for the DCT based MPEG2, and a slightly less annoying but still bad result for MPEG4-AVC which hammers the artefacts flat by its inloop deblocking.

The possibly only certain way to analyze a movie for interlacing/telecine/fieldshift patterns is to bob it (= separate the fields; once TFF, once BFF), watch it field-by-field and look for movement patterns. Manually. Looking at the woven frames will not tell you certainly which temporal progress its fields have.

Music Fan
3rd January 2012, 10:20
Resize: 720,480 < I changed this to 704,528 in the avs script
Why don't you keep it in 720,480 (if this is the original resolution of your video) ?
You can change the PAR to get a 4/3 DAR (whatever the codec).

About the 3:2 pulldown, I recall something not enough known : when your mpeg-2 file comes from a soft pull-downed Ntsc dvd (video encoded in 23.976 fps with a 3:2 pulldown flag), you don't have to use complex avisynth filters to de-interlace it, you can simply remove the pulldown flag with TS Muxer (check "remove pulldown") and you'll get a mpeg-2 video in 23.976 fps rid of its flag.
Then you open it in Avisynth or Megui and you won't have to worry about the de-interlacing method.

LigH
3rd January 2012, 10:31
Or possibly even easier: DGIndex has several options to handle telecine already while indexing, so DGDecode.dll can handle it while serving the video into AviSynth. Provided the pattern order detection is reliable.

Music Fan
3rd January 2012, 11:01
I don't find it easier, it's more complex (not a lot but a little bit) because the flag is still there and DGIndex has to remove it, and as it has several options, one may not choose the good one. And even when one has well chosen, it inverts a process made by the flag, it has no sense if one can simply remove it.

It could be really useful for those who need to play this mpeg-2 video in 23.976 fps without needing to convert it in another codec. Because I believe some multimedia players can play 720.480 in 23.976 fps (and upscale it in 1080p with the player because they output 24 hz only in 1080p). And it could maybe work on an AVCHD (or kind of) made with MultiAVCHD.
Some players can send 24 hz (23.976) from a soft pull-downed Ntsc dvd (making reverse 3:2 pulldown), but they are rare.

LigH
3rd January 2012, 11:30
@ szabi:

It is probably in general not recommendable to load AviSynth scripts via DirectShow. That may work via ffdshow, but AviSynth is an AviFile extension, related to the VfW API. Furthermore, AviSynth supports external sources via the Import() function.

Untested - but I believe it should possibly work best like that:

Import("muk.avs")
x = last.FadeIn(25).FadeOut(15)
Import("slow.avs")
y = last.FadeIn(15).FadeOut(25)
z = BlankClip(x,length=15)
z+x+z+y

MrVideo
3rd January 2012, 11:40
Here's a VDub anamorphic screenshot from the source MPEG-2 video. MeGui analysis reports it as being 'hybrid film/interlaced mostly film,' and you can see what seems to be partial interlacing from the OTA broadcast

The MeGUI analysis is incorrect. Scripted U.S. TV shows are not, nor ever will be, 'hybrid film/interlaced mostly film.' Believing that analysis will lead you down the wrong path. There is no partial interlacing in the program. The source is 480i29.97, which is 100% interlaced. You get fooled into thinking there isn't any interlacing when a single film frame is scanned into a video frame. Don't forget the 2:3 pulldown I was telling you about.

Here's the same shot from an h264 mkv video file MeGUI compressed from the MPEG-2 source cropped & resized 4:3

Ouch, that is horrible.

Here's the same shot from an h264 mp4 video file TMPGEnc Xpress compressed from the MPEG-2 source cropped & resized 4:3. Notice how much better it is

IMHO, it is not any better.

Here's the only things I set in MeGUI:

Input DAR: 4:3
Crop: Autocrop 8,4,-4,0
Resize: 720,480 < I changed this to 704,528 in the avs script
Source type: 'hybrid film/interlaced mostly film,'
Field order: Top Field First
Deinterlace: Decomb IVTC < Also tried 'TIVTC' and 'TIVTC + TDeint(EDT) -- slow'

Your cropping and resize are 100% incorrect. Your settings show something else you do not know about digital video.

When analog NTSC video is converted to digital (720x480), the black vertical bars indicate, in simple terms, a safety conversion, The center 704 pixels contain the 4:3 aspect ratio area. When converted back to NTSC analog, the safety overscan of the analog active image portion of the line, is restored. But, for digital only displays, the 8 pixels on each side should be removed and scaled to 720 pixels. No scans lines should be cropped, i.e, all 480 lines must be left intact, or you will distort the image and mess up the interlacing.

The scaling to 720x528 is incorrect because you appear not to know that 720x480 does not use square pixels. 704x480 is 4:3. Your attempt to convert the image to 4:3 using square pixels, by changing the vertical scaling, distorted the image. 480 interlaced lines to 528 interlaced lines just makes matters worse. If you wanted square pixels, the correct scaling is 640x480. But, that throws away horizontal resolution. It needs to be left alone at 704x480. Data placed into the MPEG file tells the displaying program to show it at 4:3. The terms are DAR (Display Aspect Ratio) and SAR (Source Aspect Ratio) [sometimes called PAR, pixel aspect ratio]. Google them to learn more, though there are sources that get it wrong.

Would MeGUI converting the framerate from 29.97 down to 23.976 have affected things?

In this case probably. Why? Because in order for MeTV to not edit the program and show all of the episode, it sped up the source video. There were more program minutes way back then. The source video is from the original 24 fps film (no color yet for analog TV, which was really 30 fps). The film was transferred to NTSC 29.97 using 2:3 pulldown. I could see that the video was sped up, because as you step through the video, frame by frame, the 2:3 pulldown cadence is lost. That means conversion back to 23.976 will be extremely difficult, if not impossible. While there might be AVISynth filters that can do it, the audio, which has been sped up as well, will need to also be corrected.

As much as you might not like interlaced video, in this case, leave well enough alone. Crop 8 pixels off each side if you must (none vertically), but do not deinterlace and leave the frame rate at 29.97.

Conversion of 29.97 interlaced video back to 23.976 progressive video can only be done if the source video has 2:3 pulldown video, with the 2:3 pulldown cadence intact (every five video frames is the required sequence). In this case, the sped up video results in sequences that are only 4 frames long, at a minimum. The cadence is broken.

MrVideo
3rd January 2012, 11:47
About the 3:2 pulldown, I recall something not enough known : when your mpeg-2 file comes from a soft pull-downed Ntsc dvd (video encoded in 23.976 fps with a 3:2 pulldown flag), you don't have to use complex avisynth filters to de-interlace it, you can simply remove the pulldown flag with TS Muxer (check "remove pulldown") and you'll get a mpeg-2 video in 23.976 fps rid of its flag.
Then you open it in Avisynth or Megui and you won't have to worry about the de-interlacing method.

While that may indeed be true for source video that comes from a DVD, the source video in this case is from an OTA subchannel. Notice the MeTV bug in the corner? Plus, as I noted, MeTV sped up their source to get it to fit in their "more commercials" hour. It cannot be converted to 23.976.

Music Fan
3rd January 2012, 12:19
Yes, I know this method can't work in this case, but this problem made me think to the TSMuxer method that I wanted to recall.;)

TakuSkan
3rd January 2012, 15:29
Why don't you keep it in 720,480 (if this is the original resolution of your video) ?
You can change the PAR to get a 4/3 DAR (whatever the codec).
The source file is: SAR: 3:2 - PAR: 8:9 - DAR: 4:3
Where would I set the PAR? Manually in the .avs?

you can simply remove the pulldown flag with TS Muxer (check "remove pulldown") and you'll get a mpeg-2 video in 23.976 fps rid of its flag.
Then you open it in Avisynth or Megui and you won't have to worry about the de-interlacing method.
I ran tsMuxeR GUI from MeGUI's \tools\tsmuxer folder and loaded the MPEG-2 clip. I would demux that to a 23.976 fps mpv file, but the '[]Remove pulldown' option is disabled. Am I missing something?

And if I do manage to do that, would I just go ahead and use any of the deinterlacing options in MeGUI. Maybe TIVTC. I'm not clear on what removing the pulldown accomplishes.

Or possibly even easier: DGIndex has several options to handle telecine already while indexing, so DGDecode.dll can handle it while serving the video into AviSynth. Provided the pattern order detection is reliable.
I tried loading the source clip in DGIndex and setting Video > Field Operation > Ignore Pulldown Flags, saving the project and then processing with MeGUI. But I got the same poor the results. And as MrVideo suggested, the video may have been sped up for broadcast. I'm still digesting 3:2 pulldown video on Wikipedia (http://en.wikipedia.org/wiki/Telecine#2:3_pulldown), so it's not all that clear to me yet.

The scaling to 720x528 is incorrect because you appear not to know that 720x480 does not use square pixels.
Thanks so very much for your detailed explanations of all this MrVideo.

I actually resized to 704x528. That resulted in square pixels for both SAR and DAR (see below about SAR, DAR, PAR and my problems with MeGUI and anamorphic video).

Your attempt to convert the image to 4:3 using square pixels, by changing the vertical scaling, distorted the image
That was intentional. By doing so MeGUI took the anamorphic 720x480 source frame that had black bars 8 pixels left, 4 pixels top and 4 pixels right, and produced a progressive h264 video with both SAR and DAR values of 704x528 (4:3). Playing that video in MPC produces a display AR that matches the AR of the source MPEG-2 video played in MPC.

When I 1st tried to get MeGUI to output a file with the same AR as the source, I just experimented with setting different resizing values, and then played the resulting files in MPC and compared the AR to the source file loaded into a 2nd copy of MPC. When I hit 704x528 for an h264 encoded file, I could move the copy of MPC with the h264 next to the copy of MPC with the MPEG-2 and compare the top/bottom edges and side edges of the 2 and see that they matched. A bit unorthodox maybe, but it got me files that displayed the same AR as the source.

Again, GSpot reports the source as: SAR: 3:2 - PAR: 8:9 - DAR: 4:3

I use MatroskaProp to report Matroska file properties in a Windows Explorer context menu, and check to see that MeGUI has produced a 4:3 SAR and 4:3 DAR.

I have totally failed to get MeGUI to produce an anamorphic 720x480 or 704x480 progressive video file that will display as 4:3 in MPC.

As much as you might not like interlaced video, in this case, leave well enough alone. Crop 8 pixels off each side if you must (none vertically), but do not deinterlace and leave the frame rate at 29.97.

MeGUI doesn't give me any option for encoding to a specific frame rate. The files configured as I've detailed have automatically been encoded to 23.976 fps. When I change the source type to 'Interlaced' as you suggest, MeGUI does then encode to 29.27. But if I crop the sides and resize to 704x480 as you suggest, MeGUI then goes ahead and encodes to an h264 video in a mkv container with a SAR: 4:3 - DAR: 4:3, and not SAR: 3:2 - PAR: 8:9 - DAR: 4:3 anamorphic. That results in a file that's too wide when played in MPC.

Here's a Windows screenshot of MPC playing a video MeGUI produced with the settings you proposed:

http://i515.photobucket.com/albums/t352/pequickit/TR-Clips/MPCh264PrnScrn.jpg

Here's a Windows screenshot of MPC playing the original MPEG-2 displayed as it should be:

http://i515.photobucket.com/albums/t352/pequickit/TR-Clips/MPCMPEG-2PrnScrn.jpg

I had to capture the screenshot of MPC displaying the MPEG-2 source file with the 'Print Scrn' keyboard key. When I had MPC create the screenshot, the AR of the resulting jpg was that of the 3:2 stored anamorphic frame.

LigH
3rd January 2012, 17:14
Where would I set the PAR? Manually in the .avs?

AviSynth has no relation to aspect ratios. It delivers an uncompressed video to the encoder.

Only the encoder can store flags about an aspect ratio. If not in the video stream inside, then in the container around it. If the video format does not provide own aspect ratio flags (MPEG2 does, about MPEG4-AVC I am not so certain), this may require a video-only encoder to output a contained result (in the case of x264: e.g. *.mp4 or *.mkv), not a raw video file (in the case of x264: not *.264), or you may have to add a flag manually to a multiplexer if you want to add audio streams etc. afterwards.

The output of movie players is hardly relevant, unless you can guarantee that the used decoder did not deinterlace on its own; and media player internal or decoder internal deinterlacers sometimes have a quite low quality (e.g. stupid field blending).

Music Fan
3rd January 2012, 17:22
The source file is: SAR: 3:2 - PAR: 8:9 - DAR: 4:3
Where would I set the PAR?
You can do that after the encoding, with Yamb for a mp4 file or with MKVMerge for a MKV file.
But I didn't download your file, I don't know its characteristics.


I ran tsMuxeR GUI from MeGUI's \tools\tsmuxer folder and loaded the MPEG-2 clip. I would demux that to a 23.976 fps mpv file, but the '[]Remove pulldown' option is disabled. Am I missing something?
Because one find soft pull-downed videos only on Ntsc dvd, there's no flag in your video if you recorded it on tv. So you need Avisynth to encode it correctly.

Music Fan
3rd January 2012, 17:38
I believe some multimedia players can play 720.480 in 23.976 fps (and upscale it in 1080p with the player because they output 24 hz only in 1080p). And it could maybe work on an AVCHD (or kind of) made with MultiAVCHD.
Actually it doesn't work on my player (Sony 370), I just finished to test it.
The file is played but converted in 60 hz by the player (and I'm sure MultiAVCHD didn't transcode it in 60 hz, I analyzed the mts file it has created, it's still in mpeg-2 720.480 @ 23.976 fps).

But it works with 720p files ; the 24 hz stays in 24 hz only if 1080p is chosen as resolution in the player's setup.
If 720p or "original signal" is chosen in the setup, the 24 hz of the 720p video is converted in 60 hz (it's logical because 24 hz on Hdmi only works with 1080p signals).
The AVCHD folder was on a USB key but I guess the result would be the same if burned on dvd.

But it could maybe work on other players.

Sorry to be off-topic but I wanted to be complete on this issue.

Betsy25
3rd January 2012, 18:37
No, I do not have this problem. Are you using 2076? Which type of input file?

using the latest version as of today, the input files are *every* VOB file for all my DVD's i encoded lately, which is quite a bunch.

The script source window doesn't show anything added as long as i didn't first uncheck it, and then recheck.

EDIT: sorry it was the version before your last update, so must be 2070 or something.

Zathor
3rd January 2012, 19:26
Ok, in that case please describe a little bit more in detail what you are expecting and what you get. Also please check if your default avisynth profile is altered e.g. if the "Clever anamorphic encoding" is enabled there. I would like to reproduce the problem.

Betsy25
4th January 2012, 01:19
Ok, in that case please describe a little bit more in detail what you are expecting and what you get. Also please check if your default avisynth profile is altered e.g. if the "Clever anamorphic encoding" is enabled there. I would like to reproduce the problem.

Well, here is the default script (when i have just indexed the .vob file, and the window that opens right after that :

Content copy/pasted from the "Script" tab :
# Set DAR in encoder to 93 : 68. The following line is for automatic signalling
global MeGUI_darx = 93
global MeGUI_dary = 68
LoadPlugin("C:\Program Files\MeGUI\tools\dgindex\DGDecode.dll")
DGDecode_mpeg2source("E:\My DVD's\Fernandel Don Camillo en Peppone BOX - DVD2 - De Terugkeer van Don Camillo (1953) DVDShrink\VIDEO_TS\VTS_01_1.d2v", info=3)
LoadPlugin("C:\Program Files\MeGUI\tools\avisynth_plugin\ColorMatrix.dll")
ColorMatrix(hints=true, threads=0)
#deinterlace
#crop
#resize
#denoise

... simple unchecking the prechecked "Clever anamorphic encoding (Resize to mod16)" and then rechecking results in this:
# Set DAR in encoder to 93 : 68. The following line is for automatic signalling
global MeGUI_darx = 93
global MeGUI_dary = 68
LoadPlugin("C:\Program Files\MeGUI\tools\dgindex\DGDecode.dll")
DGDecode_mpeg2source("E:\My DVD's\Fernandel Don Camillo en Peppone BOX - DVD2 - De Terugkeer van Don Camillo (1953) DVDShrink\VIDEO_TS\VTS_01_1.d2v", info=3)
LoadPlugin("C:\Program Files\MeGUI\tools\avisynth_plugin\ColorMatrix.dll")
ColorMatrix(hints=true, threads=0)
#deinterlace
#crop
LanczosResize(720,576) # Lanczos (Sharp)
#denoise

...so a resize operation is added which is not so when you don't uncheck & recheck the anamorphic option in the I/O tab.

* This is also the case with the latest version (2080)

Zathor
4th January 2012, 19:05
...so a resize operation is added which is not so when you don't uncheck & recheck the anamorphic option in the I/O tab.
Thanks, should be fixed with 2087.

Clever anamorphic DAR error over 0,5%.
Calculeted SAR wrong in some cases.
With non standard input DAR 2.341 (1920x820 I Robot Bluray) aproximate the value to 2,35 and uses
global MEGUI_darx = 47
global MEGUI_dary = 20
The resulting sar is 1269:1280 (par 0.993) but, with 1920x820 it should be --sar 81:82 (par 0.988) istead.
Can you test that please once again with 2087? Also please post more details - where do you get these wrong values?

meshaun
5th January 2012, 01:11
I want to encode a video which is widely supported by many devices such as WDTV / XBox / and with DXVA . I have the sharktooth's preset's and i use the DXVA HD Extra Quality. How to get the compatiblity with all devices ?

protoz
5th January 2012, 07:58
How did you create the source MP4 files?

I downloaded them from youtube ;)

Zathor
5th January 2012, 10:51
I want to encode a video which is widely supported by many devices such as WDTV / XBox / and with DXVA . I have the sharktooth's preset's and i use the DXVA HD Extra Quality. How to get the compatiblity with all devices ?

For maximum compatibility I recommend to use the bluray target playback device (do not use one of the old presets). Depending on the real playback devices you then need to select an appropriate container (e.g. M2TS and burn it on a BR or MKV/MP4 but those containers are not supported directly by all standalone players).

forum king
9th January 2012, 09:22
hey !!
I know its kinna off topic here but wanted u folks's advise on which avisynth filter to use to improve the brightness and contrast of darker videos
I have been using Tweak but it increases the white as well to a torturing limit ,
is there any other filter or anything which increase the overall illumination of a video without drastically increasing the white

would appreciate any help

regards

fK

LigH
9th January 2012, 09:38
Levels(gamma) (http://avisynth.org/mediawiki/Levels) (useful values are around 1.0 .. 1.5)

But be careful about min/max levels for YUV clips, they often use the limited "TV" range. Use Histogram(mode="levels") (http://avisynth.org/mediawiki/Histogram) to compare before and after using Levels() to avoid range violations. Also try to understand the parameter "coring" well!

If you use AviSynth 2.60, the parameter "dither" may help avoiding some banding, but in any case, expect dark areas to reveal more compression and quantization artefacts. Deblock() and GradFun2db() may be useful to filter those, but I won't promise satisfying results.

forum king
9th January 2012, 10:49
Thanks a lot mate ,
i hope the gamma levels wont make things too on the rediish side :P

tried it and it works :)
will bother you again if you dont mind
regards

Music Fan
9th January 2012, 11:31
Levels(gamma) (http://avisynth.org/mediawiki/Levels) (useful values are around 1.0 .. 1.5)

But be careful about min/max levels for YUV clips, they often use the limited "TV" range. Use Histogram(mode="levels") (http://avisynth.org/mediawiki/Histogram) to compare before and after using Levels() to avoid range violations.
I can't access http://avisynth.org for months, is there a problem with this website ?