I'm using TMPGEnc 2.5 and I'm having a wonderful result encoding high quality MPEG 1 files derived from the .vobs on several of my DVDs. My goal is to use the finished MPEG-1s web delivery. (I don;t need to make VCDs, just cut them up into multiple MPEG 1 files) The files I create with teh default settings are NTSC 352 x 240 29.97 frame/sec. with stereo audio and they look great. The only problem is that they are quite large and maybe too high quality. They take up about 10 MB per minute of video, so that a five minute video is almost 50 Mb amd a twenty minute video takes up about 200 Mb. What are the settings that I can change in TMPGEnc 2.5 to wind up with a still decent quality but smaller file size? I'd like to try to get them half the file size if that is possible to do without scrificing too much quality. Thanks for any advice.

For web delivery, most video I've seen is 15 fps (or 14.985 fps) rather than 29.97 fps. I've played around with different codecs and different settings but I always end up there. Yes, the motion is not as smooth, but I think it's the least annoying way to cut down on bandwidth. If you keep it at NTSC framerate but cut down bitrate that much, you end up with more annoying artifacts, in my opinion.

the other way to enable bitrate reduction while minimizing artifacts is to use more aggressive filter settings (spatial filter and temporal filter: under "Advanced/Noise reduction/"still picture" and "time axis". This gets into a tradeoff between a blurry image and a more detailed, but blocky image.

Why don't you just use a VBR method of encoding and reduce the audio bitrate and samplerate.

I have also had great success with modified GOP layers. I.E. more B frames per GOP than standard.

John Beale: First I adjusted only the audio to 44100Hz and 64 kb with all the same variables as in my original question and reduced my resulting 4:45 min MPEG-1 clip from 47.5 Mb to 42.0 Mb in size. So then I tried what you suggested and encoded with the same variables as above including the just mentioned audio change (352 x 240 NTSC MPEG-1, CBR 1150 kps) while reducing the fps to 14.985 fps instead of 29.97 and the file size was STILL 42.0 Mb? Shouldn't it have gotten smaller still?

Ashy: If I try your suggestion and change the rate control mode which setting should I use when I change from CBR to VBR- 2-pass, manual or auto? And what is a reasonable bitrate to try- half of 1150, ie 575?

And you might think about a different streaming Format other than Mpeg1 like Maybe Mpeg-4 or WMV/ASF, with these Formats you can achieve Exelent Quality at much lower Bitrates and Smaller File Sizes.. Just something to think about..

FYI- I tried encoding the same clip with a CBR bitrate of 575 (half of 1150) with the same variables and cut the file size for the 4:45 min clip from 47.5 down to 22.0. It looks pretty good at 352 x 240, although it quickly gets blocky if you try to blow it up to 200%. I guess that must be the best way to trade off quality with file size. The stuff that Ashy was talking about was a bit over my head.

PS- Minion, I may also offer streaming clips alongside the MPEG clips (in which case I'll be trying to figure out what is the best conversion tool to go from MPEG-1 to .wmv soon), but I'm definitely set on MPEG-1 for downloadable clips. So it's just a matter of finding the best trade off for the file size and quality.

Sorry, I made an assumption you were already changing the bitrate. If you encode at CBR (constant-bit-rate) of 1150 kbps (Video-CD rate) or other fixed value, then certainly you will have the same size result no matter what. If your material has periods of fast motion and then relatively little, it is an advantage to use VBR (variable bit rate). In any case, to reduce the file size you have to specify a lower bitrate. (If you started by loading TMPGEnc's VCD preset, it locks most things including bitrate. Load the "Extra/unlock.mcf" file to enable all the settings.)

My comments about filtering and framerate are just ways to reduce the visibiliy of artifacts, making small files look visually better. But to get the small file in the first place, you must specifically reduce the bitrate.

I am sending you a template which uses a VBR method of encoding and modified GOP patterns, bitrates and spoilage settings, seeing as it would take me too long to post all these settings here.

This template will give a file size almost half of standard VCD, yet maintain about the same quality image and much better than simply halving the bitrate of CBR which would give the same file size.

All you need to change is the frame rate. Just make sure it matches your source frame rate. This will prevent framerate conversion artifacts.

Also if you wish to increase the quality, simply raise the max bitrate. For each 500kb/s you raise it, raise the quality 5% also.
If audio is not important to you then you can further reduce the file size with this template by reducing the audio to 64kb/s

Let me know your opinion.

ASHY

Ashy:

I am very appreciative of you sending me that template to try, but unfortunately it only made the resulting file size of the encoded MPEG-1 file BIGGER (50.8 Mb), not smaller (from the original 47.5 Mb file with CBR of 1150)! Any idea why? The only thing that I have tried that lowers the filesize substantially is simply halving the bitrate for the video with CBR to 575 which made the resulting MPEG-1 about half the size (22.0 Mb) I have 20 hours of video to encode and I figure I'd better ask as many people as I can before I spend a lot of time encoding them just to wish I had done it differently later. So thanks to everyone who has responded so far.

Unless the content of your source is non stop extremely high detailed action at full screen then the file shouldn't be any where near that size.

If that is the case then there would be no point in using this template as the average bitrate would then be raised to that of almost the max bitrate setting in the template.

In regular movies, by this I mean movies which are not full screen and have a mixture of low detailed low action and high detailed high action scenes, this template works very well.

I have used and tested this template myself.
In breif what it does is use a VBR method of encoding which means it only uses the bitrate it needs to use whereas with CBR methods bitrate can be wasted in low action,low detailed scenes thus increasing the file size unecessarily.

With the settings I have used the bitrate cannot go over 1500 kb/s or 15mb per min, but the bitrate is allowed to drop to 0. Unlike in standard VCD CBR where the bitrate would be stuck at 1150kb/s.

Also the GOP layer has been altered to contain more B and P frames.
B, P, I frames are what an MPEG is made of. I frames do not compress as well as P and B frames, therefore increasing the amount of B and P frames means less I frames in the MPEG and thus acheiving better compression in the MPEG.

These settings usually produce an MPEG from a regular movie which approximatly has an average bitrate of 575 kb/s. Thats almost half of 1150 at CBR and therefore should accordingly produce a file size which is half that of 1150kb/s at CBR.

The audio has also been reduced to 112kb/s which again is half the standard for VCD, but still maintains reasonable quality.

If your source is full screen and contains high amounts of action then you will find it VERY difficult to compress this source with any kind of reasonable quality and small file size because this would require high bitrates which is why the template produced a larger file size. It attempted to raise the bitrate in an effort to compensate for the scenes.

You could try and play around with the template I sent you by reducing the quality percentage and the max bitrate and then see the result, but my guess is you won't see much benefit over a CBR method because of what seems to be the nature of your source.

My advice is to use another format. MPEG1 is not really a good format for web delivery seeing as much higher compression to file size ratios can be obtained using other formats such as WMV and even MPEG4.
My personal choice would be DIVX/XVID MPEG4 as it is a highly optimized format and produces excellant quality at low file sizes which MPEG1/2 cannot match.


ASHY

Hi all,

I have converted an AVI (captured with Abobe 6.2) to mpeg-2 with standard
DVD (PAL)template.TMPEnc version 2.5. Haven't used any settings in for instance the 'advanced' tab.

Generally, the audio and video are good but whenever there are fast cameramovements there is some flickering/noise during those movements.

Is there anyone out there who has the golden tip how to solve this?

Kind regards from The Netherlands.

Henry

It sounds like you have gotten the Wrong Field Order, this Can happen Quite often if you don"t check it First, Sometimes it can be hard to figure this out by yourself Luckily if you load your File into Tmpgenc useing the "Wizard" it Should analize your File for the Correct Field order then Set it accordingly, and don"t change the output field order different than the Input field order..

Hi,

Thanks for your response. I will try with other fieldorder.
That should solve the problem

Regards

Henry

I am trying to convert home made videos to MPEG2 using TMPGENC.

On most of my files I get a "Read error occured at address 0047F7B1 of module 'TMPGEnc.exe' with 0378E638". Address seems to be always the same whereas 'with' changes everytime. It never occurs twice at the same frame. It can happen during the analysis pass (2 pass VBR) or during the 2nd pass.

Converting my videos to MPEG1 works fine.

I tryed most of the solutions found in this BBS and others:
- defragment HD (and remove some other videos to make so free space)
- set direct show filter to priority 2
- disabling everything except directshow
- disabling every CPU option except 3DNow!
- copy video to a 120Gb brand new HD!
- convert my canopus DV video to MS DV codec on another drive
- frame serve the video to TMPGENC using Virtual Dub 1.5.1
- checked that there was no bad frame in my video file
- tryed to change the 'speed' of the encoding from very slow to slow or even normal and ultra fast...

My config is :
- Amd Athlon XP2000+
- Windows XP SP1 (media player 9 installed)
- destination driver 100Gb free space approx.
- temp drive 4Gb free space approx
- "small video" to encode (3/4 mins) or "long" videos (45 min) same problem

I am trying to create MPEG2 2 pass VBR (avg 6000, max 8000) elementary streams (tryied system but it is the same)

I tryed a windows xp fresh install without SP1, windows media player 9, etc. (just installed canopus and GeForce drivers in fact). Same problem.

HEEEEEELP!!!!

I'm running low on ideas on how to convert those video to MPEG2.

Well it is Widely known that you will NOT Get any Better Quality useing the 2-Pass Method with Tmpgenc as opposed to the "Constant Quality(CQ)" setting accept that 2-pass takes twice as Long..If you have tried everything to fix your Problem then Maybe you should use a Different encoder, There are Better encoders and Much Faster like CCE for instance and MainConcept is Very good also and Much Faster....

2 pass VBR does not improve image quality but should reduce file size. Nevertheless I have the same problem whichever compression mode I try.

Using a very very old version of TmpgEnc (beta 1.2e found on a magazine CD in july/august 2001) I managed to encode my files with the same settings.

Quality is probably not the same, and it might be slower, but I don't mind as long as I can encode my files. The problem will be the 30 days limit but I think I will not buy tmpgenc as long as I have this read error problem.

Thanks for all your help (with this message and all the others where you have already answered).

Yours
Guillaume

I have just noticed you have changed your TEMP drive to a 4GB drive.
*DO NOT* do this as this has been known to cause this problem.

Change your TEMP drive back to the default TEMP folder for your operating system.

Also I would remove that awful crap Media player9 which causes nothing but problems in TMPG and install FFDSHOW.

ASHY

I am getting the same error "Read error occured at address..." too. My setup is very similar. It always happens on the second pass of 2pass vbr.

I don't have media player9
I have the temporary set on the C: drive (boot drive) with 6gig free

Hi

I would like to know if there is any way of converting a xvid file to VCD. I have two problems.

1: Tmpgenc does not show the audio when I go into the settings, advanced, source range.
I have installed the following codec (FFd show, xvid. divx, Nimo pack)


2: I managed to fix the above problem by running a audio decompressor but not sure if this was the right thing to do. My problem now is I keep getting the NT.dll error message or memory errors.


I am running XP Home version with Tmpgenc version 2.54

Any help would be great

How did you manage to do a Double Post 8 hours apart???

Hi

I would like to know if there is any way of converting a xvid file to VCD. I have two problems.

1: Tmpgenc does not show the audio when I go into the settings, advanced, source range.
I have installed the following codec (FFd show, xvid. divx, Nimo pack)


2: I managed to fix the above problem by running a audio decompressor but not sure if this was the right thing to do. My problem now is I keep getting the NT.dll error message or memory errors.


I am running XP Home version with Tmpgenc version 2.54

Any help would be great

Well the Reason why you aren"t getting any audio is because the audio in the XviD File is Probably AC3 which Tmpgenc and Most other encoders Can not Handle, you need to extract the audio to Wav format and Use that as the Audio source, you can do this with Virtual dub or AVI-Mux, for your Other Problem I don"t know exactly what the cause of it is, it could be anything from the File being Corrupted to any number of things, you might try Frame serveing the File to tmpgenc with V-Dub or AVISYnth...

I had some MPG files that i wanted to burn to VCD's but apparently they were not compatable, so i tried converting them to VCD files and on the finished file, there was no audio, picture quality was fine though, but no audio, any help would be greatly appreciated.

You have visited this site enough times to know how to fix this Problem, Just demux the audio from the Source Mpeg file and Mux it with the File with no audio...Why aren"t the Source Files VCD Compatible?? and they the correct resolution and Bitrate?? You might try Just running the Source Mpeg file through the Muxer with the "Video-CD Non-Standard" setting and then try to burn it to disk, this could fix the file so you don"t have to re-encode it and degradeing the Quality, but if not Just demux the audio from the source Mpeg file and Mux it with the VCD File with no audio...

I know i've visted this site alot and asked alot of questions but the truth is i have no idea what alot of the options on this program besides merging and cuting and simply converting files do, i have no idea what "Mux" means, i have no idea why the source files aren't VCD compatable, i use B's Recorder Gold 5 to write VCD's they show up as mpeg-1 files which i thought were compatable but they just won't burn, maybe it's my recording software, i really don't know but when i converted the files, it had video, but no audio, but they were VCD compatable, i downloaded the source files with WinMx so mabey that has something to do with it, if muxing the files will help please let me know what that means, thank you for your help.

hello everybody, there is something wrong with my tmpeg program. after the whole encoding session from avi to mpeg. the finished mpeg shows no video, the only thing it does show is video. i have done countless uninstalls and re-installs on this program. when i had first got it, the program had worked beautifully but now its not working as it should be. i follow all the instructions and do everything right. but it still comes out as a mpeg with no video and just sound. can anybody help me!?

"Options" to "Enviromental Settings" to "Vfapi Plugins" raise "Direct show" to "2"...

I am new to Video Editing. Can the Free version of TMPGENC be used to encode AVI files into MPEG 2? or it can only encode in MPEG 1? I need to encode in MPEG 2 for DVD.. thanks

ks

If you just tried it you would find out really Quick...Yes it encodes to Mpeg2 but for only 30 days.....

I converted a Japanese Anime to MPG file then burnt it onto a VC-D. When I went to watch it though, the bottom half of the text was cut off!

you just have to go to ffdshow (start=>programs=>ffdshow=>configuration) subtitles proprieties and change the font size.

I get this error message when trying to encode the second part of a xvid file (first part went ok, I made a wave file of the sound with virtual dub).
anyone got an idea what the solution is for this error???
Cheers Dennis

This error Pops up here from time to time and the exact cause isn"t exactly known, well not my me anyways, but I suspect it is caused By a Bad frame, or a Frame that has a Different resolution as the others hence the "Scan Line is out of Range" error, and the "304" Probably means the 304th Line in the Frame is longer or shorter than the rest in the Frame, But this is just speculation..You can try to use "Virtual Dub" to scan for errors which will mask the Bad frames and make a Copy of the file and then new file should have the Bad frames removed...

Will tmpgenc allow me to control bitrates to write two hours of video to a CD?

Yes, but that's the Overkill for Picture-Quality.

Setting -> Video
Leftklick on Rate control mode (not the Listbox!) -> Unlock
Now you can use the Listbox to choose an other Mode and other Bitrates.

Setting -> System
Leftklick on Stream type -> Unlock
Now choose MPEG-1 Video-CD (non Standard) from the Listbox.

Putting 2 hours on a CD will look absolutely Terrorable, it might not even be recognizable as the Movie you started with, there will be Major blocks everywere, you will be much better off Increaseing the Bitrate to about 1650kbs and putting it on 2 CD-R"s that way you will get Much better Quality than a standard VCD and not waste any space on your CD-R"s...

I will never understand this compulsion of some people for squeezing everthing on to 1 cd.
How long does it take and how difficult is it to swap a CD over?

The increase in quality on 2 disks far outweighs the convenience factor of using 1 cd.

I am working with a PAL movie. The origin is film material (24 fps) which I have captured from TV (PAL 25 fps) in avi-format with DV compression.
Each frame in the captured video consists of two fields, created from one film frame.

When encoding this material to PAL SVCD or DVD, what settings should I use?

Should I use:

Advanced --> Video Source Setting -->Video Source Type -->: Non-interlace (progressive)
Video --> Encode Mode --> Non-Interlace

Or

Advanced --> Video Source Setting --> Video Source Type -->: Interlace
Video --> Encode Mode -->Interlace

or

Advanced --> Video Source Setting --> Video Source Type -->: Non-Interlace (progressive)
Video --> Encode Mode -->Interlace

I have tested all three methods and can't see any differences when played in a standalone DVD player and viewed on the TV. It's a "regular" DVD player, it doesn't have "progressive scan" as far as I know.

When scanning the Mpeg-file with Bitrate Viewer, I can see that TMPGEnc uses Zig-Zag scanning when I select "non-interlace" in "encode mode" and "alternate scan" when setting "encode mode" to "interlace". I've heard that Zig-Zag is better for film (progressive) material. But which method should I use?
I lean towards the last option (non-interlace/non-interlace) is the correct one, but I want to make sure I am doing the right thing.

What you get from your TV is a Pseudo-Interlaced Video. It is not longer progressive.

There are to ways, to convert 24 to 25 FpS.
The correct way is PALSpeedup. The Film will stay progressive, but runs 4% faster.

The second way (Quick'n Dirty) is a framerateconversion. The Film will run at original speed, but is not longer really progressive.
You have to encode it as interlaced, and the Source is interlaced too.

Your three Tests:

1. This must be somtimes Jerky

2. That's the correct way

3. This works too, but if you do any resizing, you will get problems.

>There are to ways, to convert 24 to 25 FpS.
The correct way is PALSpeedup. The Film will stay progressive, but runs 4% faster.

Yes, I think the movie has been converted using PAL speedup before being broadcast.
The frames in my captured file are progressive-looking (no mice teeth).
On close inspection it is easy to see that it is 25 fps video, with each frame consisting of 2 fields made from one film frame.

>The second way (Quick'n Dirty) is a framerateconversion. The Film will run at original speed, but is not longer really progressive.
How can a movie run on it's original speed when aimed at TV broadcast? The PAL TV system is 25 frames per second. How can something be broadcast at 24 frames per second? This doesn't make sense to me.:-O
Isn't the normal way to convert film (24 fps) to PAL (25 fps) for DVD production or for PAL TV broadcasts speeding the film up to 25 fps and pitching the audio so it matches? I have never heard of the "Quick'n Dirty" method you mention.

Advanced --> Video Source Setting -->Video Source Type -->: Non-interlace (progressive)
Video --> Encode Mode --> Non-Interlace
Does not play back jerky. It's looks absolutely fine. I used "full screen/keep aspect ratio" and made an SVCD out of it.

In what way is resizing affected by the non-interlace/interlace settings?

> Yes, I think the movie has been converted using PAL speedup before being broadcast. The frames in my captured file are progressive-looking (no mice teeth).

Oh, than we had a missunderstanding.

If you are really shure, that there are no "mice teeth", than the Film is progressive and you can encode it as progressive (source and target). So your Methode 1 is the corret one.

> How can a movie run on it's original speed when aimed at TV broadcast? The PAL TV system is 25 frames per second. How can something be broadcast at 24 frames per second? This doesn't make sense to me

It does not make any sense to me too, but that's reality... :(
In the Dirty-Methode, the Converter produces extra-Fields in the Video, so there's no need to speedup the Video. But these Extra-Fields are turning the Video from pure progressive into (pseudo) interlace.
And that is, what we often have in the PAL-World... :(

>I am working with a PAL movie. The origin is film material (24 fps) which I have captured from TV (PAL 25 fps) in avi-format with DV compression.

I don't understand as this doesn't make sense. How can your source be 24 fps progressive if you have captured it from a PAL TV transmission?
If you have somehow managed to capture a 25 fps interlaced PAL source to 24 fps progressive without any frame rate conversion artifacts, what was the point?

If you are encoding this source then it makes sense to capture the source as it is and simply encode it to a 25 fps interlaced PAL movie. Why capture to 24 fps?

In any case if this source really is 24 fps then converting it to 25 fps will exhibit artifacts unless you use the speed up method.

ASHY

@Ashy

So far as i understand Mia right, he (she?) has captured a Movie from PAL-TV using 25 FpS. The Source FOR the Movie was 24 FpS and it was convertet with PALSpeedUp. So the Movie is still progressive.

But maybe there's still a misunderstanding?

@Kika
>So far as i understand Mia right, he (she?) has captured a Movie from PAL-TV >using 25 FpS. The Source FOR the Movie was 24 FpS and it was convertet with >PALSpeedUp. So the Movie is still progressive.
Yes, exactly! Thanks for clarifying, Kika. The source was film (24 fps, but it was converted to 25 fps using speedup when broadcast on TV) and that's also what I captured of course. I added the "24 fps/film source" part to my post so that no one would think I was dealing with video that was interlaced. And that I understand the difference. ;)
The broadcast I captured was 25 fps PAL, a movie converted using the proper speedup from film to PAL. I am a she, btw. :)

>If you are really shure, that there are no "mice teeth", than the Film is >progressive and you can encode it as progressive (source and target). So your >Methode 1 is the corret one.
I am absolutely sure it is 100% progressive. I have looked at the individual fields, as well as the frames carefully and I don't see any "mice teeth" whatsoever. I am used to dealing with interlaced sources, that's why I am so unsure of how to deal with progressive (film) material.

>In the Dirty-Methode, the Converter produces extra-Fields in the Video, so >there's no need to speedup the Video. But these Extra-Fields are turning the >Video from pure progressive into (pseudo) interlace.
I have never seen this, but I guess what they then do is create an extra frame? So that every 25 frame is made up from film frame 24 and film frame 25? So that the film frame 25 becomes frame 26. Or something. :-)
Never have seen it, thank goodness for that. But I have seen a lot of bad NTSC to PAL conversions (blended fields). Not on movies, only on TV-series, sitcoms and so on. Stuff that was shot on film (24 fps), converted to NTSC, then the NTSC converted video was converted to PAL (instead of converting from film to PAL straight away). Maybe that is what you're talking about, Kika?

Ok, so I should go with this?:
Advanced --> Video Source Setting -->Video Source Type -->: Non-interlace (progressive)
Video --> Encode Mode --> Non-Interlace

How does the various non interlace/interlace settings affect resizing?

Is Zig-Zag scan better for encoding progressive film that alternate scan?

Will encoding the progressive film I have as interlaced be a problem when the video is played in a progressive scan DVD player?

Thanks for all your help.

That's impossible.
ALL transmitted sources are transmitted as interlaced at either 25 fps or 29.97 fps depending on your country's system.
True PAL, which is what is broadcast over the air is transmitted at 50 fields per second or 25 fps.

Whether the source was originally 24 fps or not before it was transmitted, which is unlikely anyway, it is a 25 fps interlaced signal once it is transmitted.

Standard T.V.'s only accept interlaced signals simple as that and that is how it must be transmitted by the broadcaster.

Lets not get ourselves confused here how frames are stored on DVD.
Yes, most PAL DVD's have frames stored as 24 fps progressive then are speeded up 4% and may have a form of pulldown added to create two interlaced fields out of one progressive frame, but this is not the case with transmitted sources.

There are no flags transmitted as, in DVD, over the air with these PAL signals that can just simply be removed.
Any transmitted source is a true PAL signal which means it is 25 fps and interlaced simple as that.(There are absolutely no progressive frames in the signal)

Sure you can use your capture software to capture to progressive frames, but all it has done is combined the interlaced fields into one frame and then captured it as a progressive frame. You can even capture it at 24 fps, but this will surely cause frame rate conversion artifacts.


All in all if you are capturing from broadcast signals then you must capture at the transmitted frame rate or you will encounter artifacts.

ASHY

>I am absolutely sure it is 100% progressive. I have looked at the individual fields, as well as the frames carefully and I don't see any "mice teeth" whatsoever. I am used to dealing with interlaced sources, that's why I am so unsure of how to deal with progressive (film) material.

This statement does not make sense either! Do you really know what a progressive frame is?

There are absolutely *NO* fields in a progressive frame. If you can see seperate fields then your source is NOT progressive.
Not seeing any 'Mice teeth' is not a good enough indication that a source is progressive either.

>I have never seen this, but I guess what they then do is create an extra frame? So that every 25 frame is made up from film frame 24 and film frame 25? So that the film frame 25 becomes frame 26. Or something. :-)

FILM material has only 24 frames not 25, or 26. This type of PAL conversion is called 24:1 or 24+1 pulldown and is acheived by duplicating every 12th field to create the extra frame per second to make it 25 fps, so making it complaint with PAL and is the method broadcasters use.

If you don't believe it then do some research on the net.

ASHY

@Ashy
>Whether the source was originally 24 fps or not before it was transmitted, >which is unlikely anyway, it is a 25 fps interlaced signal once it is >transmitted.
Yes, I understand how interlace works.
Most of the stuff I have captured and encoded with TMPGEnc has been TV programs shot with an interlaced video camera, meaning each frame consist of two fields taken at different points in time. So the two fields do not contain the same information.
Since a progressive display, like the computer monitor, displays both fields at the same time (which an interlaced display like a TV set does not), the effect is that one can see "mice teeth" on the computer monitor.

With this movie I captured from TV, this is not the case. Both fields are taken at the same point in time, the two fields are constructed from one film frame.
It is, like you say, interlaced technically for broadcast purposes, but both fields are from one film frame, so it appears to be progressive. Are you OK with that phrase?

How should I set TMPGEnc to encode this in the best way?
It is clear that it uses a different method for encoding depending on the setting I choose. It uses alternate scan when I set it to encode the video as "interlace" and Zig-Zag scanning when I set it to encode the video as "non-interlace".
It is also suggested that changing this setting (and the setting for the video source) affects resizing. I'd love to know how.

TMPGEnc also sets the header in the Mpeg-2 file to "interlaced" or "progressive", depending on what choice I made in "encode mode". I have also seen this on DVDs when making backups of them, that *although the content is from a film source*, the DVD studio has encoded the video as "interlaced" or "progressive".

I am only talking about PAL TV captures of movies (converted using speedup) or PAL DVDs here. Let's keep NTSC out of it for simplicity, please. :)

Once again to clarify:
I am capuring a PAL 25 fps video, via DVB.
The file I have is 25 fps.
Each frame in the video contains 2 fields, originating from one film frame.
Technically it is interlaced because it has fields, just you say, and I don't doubt what you're saying. But each frame appears progressive on the monitor and upon closer inspection. By that I mean, when both fields are displayed at the same time on the computer monitor, I see no interlace artifacts ("mice teeth") and that's because both fields contain the same information, it comes from the exact same point in time. So, even if it technically is interlaced, it does not appear interlaced when watched on a progressive display.
How does the different encoding methods in TMPGEnc affect the final file?

What is the none-interlaced setting for?
Where would one get truly progressive video (no fields at all) from to encode with TMPGEnc?

>If you don't believe it then do some research on the net.
Why wouldn't I believe you? You sound like you know what you're talking about and I came here for some helpful advice.

@Kika
>So far as i understand Mia right, he (she?) has captured a Movie from PAL-TV >using 25 FpS. The Source FOR the Movie was 24 FpS and it was convertet with >PALSpeedUp. So the Movie is still progressive.
Yes, exactly! Thanks for clarifying, Kika. The source was film (24 fps, but it was converted to 25 fps using speedup when broadcast on TV) and that's also what I captured of course. I added the "24 fps/film source" part to my post so that no one would think I was dealing with video that was interlaced. And that I understand the difference. ;)
The broadcast I captured was 25 fps PAL, a movie converted using the proper speedup from film to PAL. I am a she, btw. :)

>If you are really shure, that there are no "mice teeth", than the Film is >progressive and you can encode it as progressive (source and target). So your >Methode 1 is the corret one.
I am absolutely sure it is 100% progressive. I have looked at the individual fields, as well as the frames carefully and I don't see any "mice teeth" whatsoever. I am used to dealing with interlaced sources, that's why I am so unsure of how to deal with progressive (film) material.

>In the Dirty-Methode, the Converter produces extra-Fields in the Video, so >there's no need to speedup the Video. But these Extra-Fields are turning the >Video from pure progressive into (pseudo) interlace.
I have never seen this, but I guess what they then do is create an extra frame? So that every 25 frame is made up from film frame 24 and film frame 25? So that the film frame 25 becomes frame 26. Or something. :-)
Never have seen it, thank goodness for that. But I have seen a lot of bad NTSC to PAL conversions (blended fields). Not on movies, only on TV-series, sitcoms and so on. Stuff that was shot on film (24 fps), converted to NTSC, then the NTSC converted video was converted to PAL (instead of converting from film to PAL straight away). Maybe that is what you're talking about, Kika?

Ok, so I should go with this?:
Advanced --> Video Source Setting -->Video Source Type -->: Non-interlace (progressive)
Video --> Encode Mode --> Non-Interlace

How does the various non interlace/interlace settings affect resizing?

Is Zig-Zag scan better for encoding progressive film that alternate scan?

Will encoding the progressive film I have as interlaced be a problem when the video is played in a progressive scan DVD player?

Thanks for all your help.

>It is, like you say, interlaced technically for broadcast purposes, but both fields are from one film frame, so it appears to be progressive. Are you OK with that phrase?

OK, it seems now we are starting to understand each other.
I am aware of how an interlaced camera works. To produced interlaced video, television cameras actually shoot two separate exposures per frame, to capture the two video fields. The odd numbered scanlines are shot first, then another field is shot to capture all the even numbered scanlines when played back on TV this creates one frame. This is why artifacts can occur.

The difference as you say with FILM content that has been speeded up is that the 2 fields per interlaced frame actually contains all the information in the original progressive frame therefore no artifacts are usually apparant on a progressive display due to the fact no field displacment is taking place.

The fact still remains that no matter how these frames were created whether they be originally from FILM material or camera, these frames are indeed interlaced and should be treated as so.

In most cases field order is important and incorrect field order settings can cause motion artifacts. TMPG needs to know this order hence the source should be set as interlaced.

>How should I set TMPGEnc to encode this in the best way?

Resizing the height in interlaced material can cause artifacts (serious mice teeth on verticals), but again this depends on the material. Resizing down doesn't cause a problem.
If you need to resize I would check the frames first and then decide, if you see artifacts then using a suitable de-interlacing method will help, but this then also introduces a reduction in the overall quality of the image, because of the reduction in the resolution.
This would be up to you to decide which you think produces the best image.

As far the output, Interlaced vs Non interlaced. If your intent is TV and your ouput is MPEG2 SVCD then you should really go for interlaced. This is the requirement for SVCD anyway and what most TV's expect and will produce the best image on an interlaced display. Displaying progressive images on an interlaced display reduces the quality somewhat.

Regarding the encode mode when encoding to interlaced movies. As far as I'm aware TMPG doesn't alow this setting to be altered as it only makes sense to use an alternating scan method, seeing as this is the nature of interlaced video anyway.

>What is the none-interlaced setting for?
>Where would one get truly progressive video (no fields at all) from to encode with TMPGEnc?

This type of video usually comes from Digital tape or DVD sources. Most DVD sources are progressive frames, but are displayed as interlaced. With PAL as you say the frames are simply speeded up and then the frames are split into fields.
The difference between PAL and NTSC interlaced sources is that most PAL sources do not have motion artifacts and from that point of view are in effect the same as progressive frames, so there is no need to de-interlace the material prior to encoding.

NTSC FILM material is different as I'm sure you are aware because of telecine methods which cause fields to be displaced causing motion artifacts.
With this type of material IVTC can be used to remove the interlaced frames to return the movie back to a true 24/23.976 fps progressive source.

To conclude and answer your original question. I would use the following settings.

Source: Interlaced, 25 fps.
Output: Interlaced, 25 fps, Alternate scan

ASHY

OK, to make it clear:

If the Movie is converted bei PAL SpeedUp, then it is progressive!
There are no Extra Fields, there is no interlacing.
OK, PAL works with interlaced Video, that's right, but if the Video is converted correctly, both Fields are from the same Frame. So encode it as progressive, because it IS progressive.

Encoding an progressive transmitted Movie as interlaced Video is absolutly not necessary and - sorry, but that's true - stupid.

In the PAL-World, Movies often converted without inserting any extra fields, they just run faster - that's what PAL SpeedUp means, the Movie runs 4% faster, that's the difference from 24 to 25 FpS -, so there's absolutly no chance to get any real or false interlacing, they are really progressive.

> I have never seen this, but I guess what they then do is create an extra frame? So that every 25 frame is made up from film frame 24 and film frame 25? So that the film frame 25 becomes frame 26. Or something.

This explanation a little bit too simple, but near enough to the truth ;)
It's a little like in the NTSC-World. In NTSC, the Movie is converted by producing extra Fields to get it to 29.97 FpS. This extra Fields can be done by two way's: Converting the Framerate to 29.97 while encoding or converting it while Playing (3:2 Pulldown or 2:3 Pulldown). So NTSC-Users do never see a real progressive Picture.

The Dirty-Methode for converting Film -> PAL is doing it a little like that: producing extra Fields to get 50 Fields per Second. So you never have true 25 progressive Frames per Second. That's Pseudo-Interlacing.
PAL SpeedUp can be explained like that: In the Header of the Video-File you can find the Playbackspeed. Is it 24 (23.97 progressive), patch it to 25, that's all. There's no change on the Pictures, so they will stay progressive.
But if you doing that, the Audio-Part will be detuned, so Audio have to pitched.

>If the Movie is converted bei PAL SpeedUp, then it is progressive!
>There are no Extra Fields, there is no interlacing.
OK, PAL works with interlaced Video, that's right, but if the Video is converted correctly, both Fields are from the same Frame. So encode it as progressive, because it IS progressive.

Absolute rubbish!

Most material which is converted using PAL speed also have the progressive frames split into fields to make it into interlaced material. This is done by whoever converts it.

Once the frames are split into fields it is then an interlaced source whether the fields are from the same frame or not.
I will agree that if the material is simply speeded up by 4% and left at that then *YES* it is a true progressive source, no doubt about it, but what you need to understand is that quite often in the conversion these progressive frames are purposely split into fields to make the material interlaced.

Lets me make a short explanation of what a progressive source is.
Progressive: Each scan line of a frame is drawn consecutively from top to bottom for each frame in this pattern, line 1,2,3,4,5,6,7,8,...

Interlaced: Each frame is composed of odd and even fields. Each line in a field is drawn alternately in this pattern, odd lines: 1,3,5,7,9 and so on, even: 2,4,6,8,10 and so on which means first a line from the odd field is drawn and then a line from the even field is drawn. Each line is placed in between the previous and the next.

It doesn't matter if the fields come from the same frame or not. If the frames have the above pattern then the material is interlaced.

Usually using PAL sources which have just been speeded up it is not usually too important as to whether the frames are left as progressive or are split into fields when just simply encoding.
Where this difference does become important is when resizing the height. Resizing interlaced material can cause artifacts therefore it would need to be de-interlaced therefore you need to know whether this material really is interlaced or not.
Trying to de-interlace non interlaced material causes it's own problems because it can affect the quality of the image.

This is my point you CANNOT just automatically assume a PAL source is simply progressive just because it has been speeded up and the fields come from the same frame.
Any material which is split into fields is interlaced (no matter how it was created) and should be treated as so.

Do not get yourself confused with the way NTSC material is interlaced when using telecining methods and pulldown.
These methods of interlacing DO differ from the way PAL material is interlaced as the fields become displaced whereas in PAL material the fields do not, but never the less PAL material is still interlaced if each frame is composed of 2 fields.

There is a filter to use with AVIsynth which is capable of displaying each field in a frame individually. You can use this filter with PAL sources which have been interlaced. If you use it with a PAL progressive source it will simply show the whole frame. If, as you say that, PAL material which has been speeded up and has fields from the same frame is actually progressive then AVisynth wouldn't be able to display each field individually, but indeed it can.

Maybe you live in an NTSC world and have limited knowledge of PAL material. Here in my PAL world I have been dealing with both interlaced and progressive sources for years in every way I can think possible, so I'm sure I know which is which.

Here is a link to verify everything I have said. Please pay particular attention to the parts about PAL and 2:2 pulldown (AKA PAL speed up)
http://www.divx.com/support/guides/guide.php?gid=11

ASHY

@Ashy

I'm living in PAL-World, and i'm working as a professional with Video.

> Most material which is converted using PAL speed also have the progressive frames split into fields to make it into interlaced material. This is done by whoever converts it.

That's what i wrote in my first Posting. Please read it again.

>Once the frames are split into fields it is then an interlaced source whether the fields are from the same frame or not.

Right, that's too what i wrote.

>I will agree that if the material is simply speeded up by 4% and left at that then *YES* it is a true progressive source, no doubt about it

Yeah, i have a lot of SVCDs and DVDs, captured from TV with progressive (not deinterlaced, i never do deinterlacing) Video.
But, unfortunatly, often the Movies are partialy progressive and partialy pseudo-interlaced. :(
And some are only pseudo-interlaced, using field blending Formatconversion.

>Lets me make a short explanation of what a progressive source is.

--- snip ---
Good explanation.

>It doesn't matter if the fields come from the same frame or not. If the frames have the above pattern then the material is interlaced.

Um, that's not correct. What you get is the Frame, the progressive Frame(!) splittet into two Fields. But there's not time-difference between the Fields, so they can be combined to a true progressive frame.

>Where this difference does become important is when resizing the height. Resizing interlaced material can cause artifacts therefore it would need to be de-interlaced therefore you need to know whether this material really is interlaced or not.

Absolutly right. Risizing and cropping interlaced Video can cause many problems.

>Trying to de-interlace non interlaced material causes it's own problems because it can affect the quality of the image.

That's true...

>This is my point you CANNOT just automatically assume a PAL source is simply progressive just because it has been speeded up and the fields come from the same frame.

That's why i asked Mia about that. If there are realy no Mice teeht, than it's progressiv. But, and that's the danger, some scenes of the Movie can be interlaced. That happens often if the TV-Station is doing some cuts.

>Any material which is split into fields is interlaced (no matter how it was created) and should be treated as so.

You can't say that, because it's not true. There ARE PAL-Movies which are fully progressive. I have some of them. :)
Material, which is spitted into fields must not be interlaced, because the source can be from 25 FpS progressive Video.
But, is a Film (24 FpS) coverted by using frameratecomversion, it IS interlaced.
See, PAL has a Resolution of 2x25x704x288 (similar to 704x576i). So you can have Video with 50 different Fields per Second with a Resolution of 704x288.
Progressive Video has 1x25x704x576 (704x576p). 25 different Frames per Second with a Resolution of 704x576.
Splittet into Fields, you get 2 Fields from every Frame, so, where's your Problem? If you combine the right Fields, you get the original Frame. And that's not interlaced, that's progressive. Did you never see a progressive PAL-DVD?

>Here in my PAL world I have been dealing with both interlaced and progressive sources for years in every way I can think possible, so I'm sure I know which is which.

Me too, me too. As a Moderator of a Big German Webboard about Videoencoding, i shall know that. :)

But again: A well done PAL SpeedUp NEVER produces interlaced Video, that's absolutly impossible.

Did you actually pay any attention to anything I said? Did you even visit the link I posted which confirms everthing I have said?

>Um, that's not correct. What you get is the Frame, the progressive Frame(!) splittet into two Fields. But there's not time-difference between the Fields, so they can be combined to a true progressive frame.

Right, here goes again...

Putting 2 fields together does *NOT* technically make this frame progressive.
If you combine 2 fields from the same frame then tell the encoder to encode this frame as progressive or patch the headers to progressive then *YES* this material is going to be displayed as progressive.
But simply combining 2 fields from the same frame does NOT automatically make the material progressive.
Progressive means that each line in a frame is scanned from left to right one line after the next. True progressive.


PLEASE READ THIS CAREFULLY:
Interlaced means that each line is scanned from left to right but every other line.
First, all odd lines are drawn (this is the first half of a frame) then all the even lines are drawn in between the odd lines (the second half of a frame) and Bam! you get one whole frame.
That is what the term interlaced means!
Not whether the fields are from the same frame or not. Progressive material does ***NOT*** contain any fields whatsoever.


With PAL speedup interlaced material appears as progressive on a monitor because there is no field shift because as you so rightly put it each field is from the same frame, so there are no interlacing artifacts to speak of.

Yes agreed, these fields are simply put together to form one frame and then can be encoded as progressive, but what determines whether this material is interlaced or progressive is the way in which the scan lines are drawn.
If the material is flagged as progressive the lines will be drawn one after the other, but if the material is flagged as as interlaced the lines are drawn alternately, odd lines then even lines.
If this wasn't the case you wouldn't be able to patch a source from progressive to interlaced. But you can. This just simply puts a flag in the header to draw the lines alternately rather than consecutively.

Having said this both will appear as progressive on a monitor because as I already have agreed *ALL* the lines belong to the same frame.

I have encoded many PAL DVD's and the majority are interlaced using the 2:2 pulldown 4% speed up method and that is fact.
Bitrate viewer and DVD2AVI will both confirm this.
Some PAL DVD's are indeed true progressive agreed, but the majority are interlaced. Neither cause interlacing artifacts on a progressive display.

************************************************************************


So just to be crystal clear what determines whther a source is interlaced or progressive:

It is not the type of interlacing or how it was acheived or whether the fields are from the same frame or not.

IT IS HOW THE LINES ARE DRAWN IN EACH FRAME.

Interlaced - Lines are drawn odd first then even.
Progressive - Lines are drawn one after the other.

In material with PAL speed up which is flagged as interlaced. The lines will be drawn in an alternate fashion and this is what is known the whole world over as the term 'Interlacing'... Look it up in a dictionary.


ASHY

@Ashy

OK, here wo go. :)

> If you combine 2 fields from the same frame then tell the encoder to encode this frame as progressive or patch the headers to progressive then *YES* this material is going to be displayed as progressive.

Did i ever say anything different?

>PLEASE READ THIS CAREFULLY:

--- snip ---

> That is what the term interlaced means!

Nice, but it does not make any sense in this discussion. That's how interlaced Video is displayd.

>Not whether the fields are from the same frame or not. Progressive material does ***NOT*** contain any fields whatsoever.

But it is displayed as two Fields, that's how Television works.

>If the material is flagged as progressive the lines will be drawn one after the other, but if the material is flagged as as interlaced the lines are drawn alternately, odd lines then even lines.

That's right. But, to be correct. It's more than only a flag. It tells the Encoder, how to work with the Video (Fields and Scanorder). So you can encode progressive Video in interlaced Mode and in progressive Mode. Both will be played correct.

>Interlaced - Lines are drawn odd first then even.
>Progressive - Lines are drawn one after the other.

Yeah, that's right. But, where is the problem? We where starting at a Captured Video, right? Capture-Codecs are combining both fields, no matter if they are from progressive or interlaced source.
If it is progressive, you will get the odd lines first, OK. After that, you get the even lines. OK?
You have:
Field 1 of Frame 1 and Field 2 of Frame 1. OK?
Let's combine them the right way, like capture-codecs do. You get? Right, all the Lines you need for a progressive picture.

Progressive via Television:
The frame is scanned as 2 Fields. The Capture-Device will get 2 Fields and combine them. The result is the original Frame - and that frame IS progressive.

> In material with PAL speed up which is flagged as interlaced.

Wrong... Some of my DVDs don't have a interlaced Flag and they ARE progressive, and they ARE converted bei PAL-SpeedUp.

Correction...

I'v made a mistake.

>If the material is flagged as progressive the lines will be drawn one after the other, but if the material is flagged as as interlaced the lines are drawn alternately, odd lines then even lines.

That's NOT right.
The Lines will be displayd at the TV at the same order. No matter if the Video is progressive or interlaced. That's because TV MUST BE interlaced. All DVD-Players are producing an interlaced Picture EVEN progressive scan Player! TVs can't change the order, the Lines are displayed.

The Encoder does read Frames which include both Fields. In interlace mode, he reads line 1,3,5,7 .... then 0,2,4,6 ....
In progressive mode, he reads 0,1,2,3,4...
But, is the Video is progressive and you encode it as interlaced, nothing special will happen. (you can NOT encode interlaced as progressive).

Part 1/3 of my post:
I am 100% sure that the movie I have has been converted for television the "proper" way using PAL Speedup. Meaning, the film was originally shot with a progressive camera, taking whole 24 images per second, I am absolutely sure of that.
Then, in order to broadcast the film on a PAL television system, the film was speeded (sped?) up to 25 frames per second and the audio was pitched to match.
There are no extra frames.

Each film frame was split into two fields (because PAL TV is an interlaced system, it can not display a whole film frame). Each frame in the TV broadcast of the movie contains two fields, an upper and one lower, and these contain the exact same information, namely what was in one, single film frame.
The TV broadcast of the movie is technically interlaced (otherwise it would not be possible to broadcast it) but the information in each frame is not of interlaced nature. Interlaced video, shot with an interlaced camera, does not have the same information in the two fields that make up one frame.

This what all three of us agree on (Ashy, Kika and myself). Right?
Now, this is what I believe and I would really like to hear what your thoughts are of the following. I am not an expert, but I am eager to learn, so please don't be harsh if I make some wrong assumptions or come to wrong conclusions. I just want to get to the bottom of this and I'm sure others will find this helpful too, when they get to this stage of exploring Mpeg-2 and TMPGEnc.

Here are my conclusions and thoughts:
To encode the movie I have discussed above as "interlaced" in TMPGEnc (setting it as "interlaced" under Video Source and selecting "interlaced" in the Video tab) affects how TMPGEnc encodes the video; what "algorithm" it uses for finding temporal (inter-coding) and spatial (intra-coding) redundancy, which is at the heart of Mpeg-2 encoding.
Temporal means the encoder (TMPGEnc) looks for redundancy between pictures and spatial redundancy means it looks for redundancy within a picture.

When I use "non-interlace" under "encode mode" TMPGEnc not only sets the flag in the Mpeg-2 header to "progressive", it also uses a different algorithm for finding and being the most efficient at exploiting the spatial and temporal redundancy in the material. I know of two such methods. One method is called "zig-zag scan" and is what TMPGEnc uses when "non-interlace" is set under "encode mode".
When I set it to "interlace" it marks the video as "interlaced" and uses a different method which is known as "alternate scan" to Bitrate Viewer.
I believe it is also known as "Yeltsin Walk".
(continued below)

Part 2/3
After reading in "The Mpeg Handbook" by John Watkinson, I find a lot that go way over my head. But also interesting things, such as
"It is an advantage to scan in a sequence where the largest coefficient values are scanned first. Then the next coefficient is more likely to be zero than the previous one. With progressively scanned material, a regular zig-zag scan begins in the top-left corner and ends in the bottom-right corner as shown in figure 3:32. "
I don't understand all of that but to me it sounds like zig-zag scan is linked to progressive material.
Later on, under the headline "handling interlaced pictures" I read the following:
"Using the 45 degree zig-zag scan with this different coefficient distribution would not have the required effect of putting all the significant coefficients at the beginning of the scan. To achieve this requires a different zig-zag scan, which is shown in picture 5.38. This scan, sometimes known as the Yeltsin walk, attempts to match the elliptical probability of interlaced coefficients with a scan slanted at 67.5 degrees to the vertical,. Motion estimation is more difficult in an interlaced system. Vertical detail can result in differences between fields and this reduces the quality of the match."

I also found a very interesting page, which I will read tonight:
http://www.hometheaterhifi.com/volume_7_4/dvd-benchmark-part-5-progressive-10-2000.html

Can it be like this:
When I encode the captured film I have as non-interlace and set the source to non-interlace (progressive) as I initially suggested (and still believe in and which Kika also supported as the correct settings), the following happens when I play the encoded SVCD (or DVD) in my non-progressive scan DVD player:
The DVD player reads the header, sees "progressive" and outputs each frame (consisting of two fields with the exact same information) as two fields to the TV, one field after another, just like it does with material that is shot with interlaced equipment.
Can it not be the case that it is up to the DVD player to output an interlaced signal to the TV, when it encounters Mpeg-2 video that is marked as progressive by the encoder (TMPGEnc)?
I had no problems outputting the (progressive) non-interlaced version (SVCD) I encoded of the movie to my interlaced TV from my "interlace DVD player".
Also, the non-interlaced encoded version had slightly less blocking (!).

Can it not be the case that it is actually bad to encode the captured movie I have as interlaced when later on I buy a progressive scan DVD player that understands and can output progressively (outputting the two fields at the same time, as opposed to field 1, then field 2, as a "regular" interlace-outputting DVD player does)?
(Continued blow)

Part 3/3
As a side note I can tell you that the field order in the captured file I have is Bottom Field First, as I have a DV capturing device. But the field order does not matter in this case.
Because both fields are exactly the same (contain the same information).
I didn't touch that setting in TMPGEnc anyway, because it auto detected it as Bottom Field First and I just let it stay that way. But it doesn't matter which field comes first, I see that on the TV-out when I pause the video (Matrox G450).
The video pauses without any "shaking" in action scenes which is not the case with genuinely interlaced material (the fields contain information from different points in time).

Kika, is PAL 2:2 Pulldown the "bad way" of converting film (24 fps) to PAL TV/DVD (25 fps)? I don't understand how the method on http://www.divx.com/support/guides/guide.php?gid=11 which Ashy provided can create 25 frames per second. Unless it "makes up" every 25th frame.
"A telecine machine will use what is sometimes called 2:2 Pulldown. This turns every frame into two fields so they can be played on a standard PAL television. This makes 25 frames into 50 fields which when played on a TV set at 50Hz will produce 25 whole frames per second.

As I said before, I have seen many PAL DVDs with a "progressive" marker in the header.
Ashy, are you saying that on a PAL DVD, there are only 24 frames stored on the disc, and the DVD player speeds the film up to 25 fps, creates two fields from one film frame (stored on the DVD) and pitches the audio on the fly?
Or, is the material on a PAL film DVD 25 fps (speeded up from film's 24 fps), two fields per frame (created from one film frame) and the audio is already pitched in the encoding process by the DVD producers? I tend to think the later is correct, but I am not sure. If so, it is the exact same nature on the material as what I captured from TV. And if so, I shouldn't I tell TMPGEnc that my source is non-interlaced (progressive) and that I want it to encode "non-interlaced" too.

>There are no extra frames.

Correction: There are no interlaced frames and no blended fields.

Part1/2:

Mia I almost agree with you entirely. Everything you have said makes sense and more or less sums up what I was getting at.

In agreeance with Kika most codecs do capture to progressive frames, no matter if the source is Interlaced or progressive.

What I need you to understand from me is what an interlaced frame is.
If you take one progressive frame and then split it into 2 fields what you get is a set of odd lines and a set of even lines. When these two sets of lines are recombined into one frame they are interlaced. This means the even lines sit in between the odd lines.
Now these lines when combined make up a perfect frame, but this frame is still classed as an interlaced frame because of the scan order. This means the decoder will scan the lines in an alternate fashion, the odd lines first and then the even lines. OK?

Because this frame is made up of two perfect fields from the same frame
all that needs to be done to make this non interlaced is to tell the decoder to scan the lines in a progressive fashion, one line after another. This is done by telling the encoder to either encode the two fields as a progressive frame or by simply patching the headers in an interlaced source to progressive. The decoder is then insructed by this information in the headers to scan the lines in the frame one after the other, progessively.

This frame is then truly progressive.

Before Kika jumps done my throat again. This only works with fields made from the same original progressive frame.

Ok, now even though the decoder has instruction by the information contained in the MPEG to scan the lines either alternately or consecutively, it will never the less output the frames as interlaced to the T.V. unless the DVD player has progressive output capabilities, but this would require a TV capable of receiving progressive output.

It seems to me that you and Kika are assuming that an interlaced frame means that the fields are made up from neighboring frames. This is indeed how interlaced cameras work, but is not the only method which is called interlacing.

Any frame which is composed of two fields even if it's from the same frame which was originally progressive is called an interlaced frame.
Progressive frames DO NOT contain any fields in any shape or form. There is no such thing as a field in a progressive frame.

In brief again:
1 frame consisting of 2 fields from a frame which was *originally* progressive is called interlaced.
1 frame consisting of 2 fields which is recombined from the same frame which is then flagged or encoded as progressive to change the scan order to one line after the other is truly called a progressive frame.

*****************************************************************************

Part2/2:

As for 2:2 pulldown this is the method used for most interlaced DVD's. It is just a simple method of speeding up the frame rate from the 24 fps to 25 fps and also splits the progressive frames into 2 fields to create an interlaced output.
The audio is pitch corrected by the person converting it. This is what is known as the PAL speed up method.

Some DVD's are just simply speeded up only and no other conversion takes place such as splitting the frames into fields. This DVD is then a 25 fps progressive DVD.

Both are practically progressive, it's just the scan order which has changed and both are still in reality 24 fps DVD's.


Finally as for your source. If it is composed of 2 fields from the smae frame or not then it is classed as an interlaced frame, but to be honest this isn't really going to make a damn bit of difference to your encoder with either setting, interlaced or progressive, because all the lines are from exactly the same frame and will produce exactly the same image no matter how they are scanned by the encoder.

It is your choice you can encode these frames as progressive no problem or as interlaced. I would personally like to keep to SVCD standards and encode the frames as interlaced, but this is your choice.
I'm sure there must be some reason why MPEG2 supports interlaced frames even though any DVD player can deal with either type and still output it as interlaced.

As for you query about what will a progressive output player do with an interlaced source. Well it should just simply combine the fields and output it as progressive.

ASHY

@Kika,
>All DVD-Players are producing an interlaced Picture EVEN progressive scan Player! TVs can't change the order, the Lines are displayed.

Very wrong!

The term progressive scan on a DVD player refers to the output not how the source will be read.

A progressive scan output DVD player will output the display as progressive to a progressive scan TV or to a projector.

Have a read:
http://www.bestbuy.com/HomeAudioVideo/DVDPlayers/hr/ProgressiveScan11_17.asp

ASHY

Ashy, to prevent Mistakes: I talked about CRT-TVs, not Projectors or Plasma-TVs.

Guess we are talking about the same things, but we don't understand each other right... Maybe it's because of my terrible english (can read it, but writing... um...)

OK, last try:

> This only works with fields made from the same original progressive frame.

Absolutly clear. I never wrote something else.

>It seems to me that you and Kika are assuming that an interlaced frame means that the fields are made up from neighboring frames. This is indeed how interlaced cameras work, but is not the only method which is called interlacing.

Not at all. The way, interlaced cameras work is that, i call "True Interlace".
The way, a bad conversation works is what i called "Pseudo-Interlaced" in the early Postings. It's if 24 FpS Source is converted to 25 FpS by inserting extra fields.
I know and i have them both on DVDs and in MPEG-Files made from TV or VHS.
The third kind of Videos i talked about is converted from 24 FpS Source by using a clean and true SpeedUp. That Material is progressive and can (and have to be) be treated as non-interlaced in TMPGEnc. That's all i tried to say.

> 1 frame consisting of 2 fields from a frame which was *originally* progressive is called interlaced.

That's the bone of contention. Why should that be an interlaced Frame? There's no Time-Shift between the Fields, no blending or something else. There's only a little risc that a capture-Device will handle it not correctly (some TV-Cards are producing Field Shifts).
Only if you mean the term, than that's called an interlaced Frame, that's right. But you CAN encode Material like that as an progressive Video.

> 1 frame consisting of 2 fields which is recombined from the same frame which is then flagged or encoded as progressive to change the scan order to one line after the other is truly called a progressive frame.

Sounds a little complicated but true... ;)

OK, to your Posting 2/2:
That's exactly what i meant, i was not talking about Terms, only about the way, the Video can be handled.

Oh, and there's one reason, why Mia should encode the Video as progressive: The Scan Order after DCT and quantisation. Progressive uses ZigZag which is better for progressive Video.

Hooray at last!

We finally got it all clear and we agree.
We just simply misunderstod each other.

Oh, and there is nothing wrong with your English. It is a damn sight better than some of the English speaking people who use this bbs.

ASHY

Pt 1/2
@Ashy

>As for 2:2 pulldown this is the method used for most interlaced DVD's. It is just a >simple method of speeding up the frame rate from the 24 fps to 25 fps and also >splits the progressive frames into 2 fields to create an interlaced output.
>The audio is pitch corrected by the person converting it. This is what is known as >the PAL speed up method.

OK, but there was no mentioning of anything but a 2:2 Pulldown in the link you mentioned. I mean, if one has a progressive film of 24 fps, just "pulling down" i.e. creating two fields out of every film frame isn't enough to convert the film to something that can be broadcast in a PAL TV system or put on a PAL DVD.
The speed must be fixed as well, bringing the frames per second rate up to 25, and also, the audio must be fixed to match. Just the Pulldown isn't all that's needed for a film to PAL-conversion, so that's why the term confuses me. Does "2:2 Pulldown" encompass a speedup and audio pitching operation or does the term only mean "to create 2 fields from one progressive frame"?

>Now these lines when combined make up a perfect frame, but this frame is still >classed as an interlaced frame because of the scan order. This means the decoder >will scan the lines in an alternate fashion, the odd lines first and then the even.

Yes, I am with you and have been all along. ;-)
There seems to be a need for new words here.
How about:
Genuinely interlaced (material shot with interlaced video camera, where each frame contains two fields, taken at different points in time).
and
Technically interlaced (material shot with progressive film camera, but for PAL broadcast purposes each frame has been divided into two fields, containing the same information. Combining the two fields therefore produces a progressive-looking image. Because the material contains fields, it is no longer correct to call it progressive, as progressive footage has no fields. Still, Technically interlaced video, is not the same as Genuinely interlaced video.

I have now gathered more evidence that points to Zig-Zag being better for Technically Interlaced material. :-)
I downloaded a demo of CCE, and in it one can set whether to use Zig-Zag or Alternate Scan (it is user-selectable) and it is also suggested in the help file that Zig-Zag is better for progressive material.
In CCE, one can encode with Zig-Zag scan and set the output flagged as "Progressive" or as "Interlaced", as well.

I don't think it is wrong to call Technically Interlaced material "Progressive".
And I've been thinking about why it would be perhaps better to encode Technically Interlaced (Progressive) material using the "non-interlace" setting in TMPGEnc and letting it set the Mpeg-2 header to "Progressive".
And it's not just for the Zig-Zag scan.
(continued)

Part 2/2
For now, with a standard (interlace outputting) DVD player, setting "Progressive" in the header does not seem to hurt. The player probably reads the flag, but outputs each frame as two fields, one after the other (first the Bottom field, then the Top field in this case, as I have encoded from DV material).
But, by setting the header to "Interlaced", I think, may lead to problems if one has a progressive scan DVD player and a progressive display, like a plasma TV or projector.
Why? Because I think that when a progressive DVD player reads "interlaced" it will do all sorts of things to convert the "interlaced video" (which really is progressive/technically interlaced material) to progressive.
And the player will do so by deinterlacing, for example it may use field-adaptive deinterlacing or motion-predictive deinterlacing. Deinterlacing is not what one wants, right? What we want is that the DVD Player outputs the movie on the disc, both fields at once: that it combines the two fields into one complete frame and outputs it like one frame.
I've never seen a progressive DVD player, but I have read about how they work when they encounter Genuinely Interlaced video.

So, can we conclude that what I have is the same type of material as on a PAL (film, made from progressive film material) DVD?
It is Technically Interlaced material on both the DVD and on PAL broadcasts.
My captured file can be encoded as Progressive, and in fact, for DVD purposes, it is probably even best to encode it as Progressive?
Do we agree on this?

For SVCD, I have not seen any specifications that says it must be labeled as interlaced. Where have you read this, Ashy? Id' be interested to read up on SVCD.

Thank you both for your advice.

/Mia

Mia I agree with all your conclusions.

Here is the clip about 2:2 pulldown from the link I posted. Notice it does actually say the the video is speeded up to 25 fps also:


2:2 Pulldown PAL

PAL movies also get telecined, but not in the same way NTSC movies do. A telecine machine will use what is sometimes called 2:2 Pulldown. This turns every frame into two fields so they can be played on a standard PAL television. This makes 25 frames into 50 fields which when played on a TV set at 50Hz will produce 25 whole frames per second. So instead of going 3, 2, 3, 2, 3, 2 it will go 2, 2, 2, 2, 2, 2. This produces the fields:

At AB / Bt Bb / CT CB / DT dB

Or just:

AA BB CC DD

Again, a PAL movie will contain all the frames from a 24fps film with no additional ones, but it will still play those frames back faster at 25 fps. In a manner of speaking, it is just as correct (or incorrect!) to say a PAL movie is 24 fps because no frames have been added and they're just played back faster


Here is a link you may be interested in regarding SVCD:
http://www.geocities.com/bug2kbug/svcd/svcd.htm

You can also download the SVCD specs here.
http://www.licensing.philips.com/information/cd/video/documents575.html

>Mia I agree with all your conclusions.

Great, we finally understand each other! :)

>PAL movies also get telecined, but not in the same way NTSC movies do. A >telecine machine will use what is sometimes called 2:2 Pulldown. This turns

OK! I can dig it. :)
But, there's still one thing I feel unsure about..
When speaking of DVD, can the 2:2 pulldown, the pitching of the audio and speedup of the video be done by the DVD player?

Is the material on a film-source(from genuinely progressive source) PAL DVD 24 fps and the player does the 2:2 pulldown?
Are there 2:2 Pulldown flags in the Mpeg-2 header, just like there are such flags for NTSC 2-3 pulldown?

Thanks a bunch for the URLs, Ashy. I've been searching for that pdf from Philips, but have not been able to find it.

/Mia

>When speaking of DVD, can the 2:2 pulldown, the pitching of the audio and speedup of the video be done by the DVD player?

No not likely. The audio to be done seperately and the length would have to be shrunk, pitch adjusted and then remuxed with the video.

>Is the material on a film-source(from genuinely progressive source) PAL DVD 24 fps and the player does the 2:2 pulldown?
>Are there 2:2 Pulldown flags in the Mpeg-2 header, just like there are such flags for NTSC 2-3 pulldown


Yes PAL Film material is genuine progressive at 24 fps/23.976. I suppose the player does do the 2:2 pulldown seeing as these flags can simply be removed and the headers patched to progressive even though I would think it differs slightly to NTSC 2:3 pulldown which inserts flags to instruct the player to pulldown extra fields whereas with 2:2 pulldown the player is simply instructed to pull down 2 fields for each frame.