This forum is for users to exchange information and discuss with other users about a TMPGEnc product.
In case you need official support, please contact TMPG Inc.
Pegasys Products BBS [ Sorted by thread creation date ]
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...
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.
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.
@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?
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.
>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
>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?
>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.
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.
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.
> 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.
>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."
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.
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.
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, 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.
>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.
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
>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.
>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.
i am currently trying to convert a xviD .avi file. TMPGEnc works fine with other movies encoded in DivX. Every time I try to start encoding to VCD for the xvid, a write error at ntdll.dll occurs, and then i cannot continue encoding. any help?
also, i'm not too sure how to use fddshow as a decoder as some people have suggested i do. if anyone would be so helpful as to give me a complete tutorial on how to use fddshow, i'd be really grateful
When using the wizard for encoding to MPEG in TMPGEnc it selects ES
(video+audio) and give me two files, the audio file in WAV format. The audio
bitrate is set to something like 1,500 kbit/s. The problem with the WAV file
is that the MPEG tool for merging files doesn't accept the format. I've
tried to just change file name but that doesn't help.
When I leave the wizard and instead load the DVD PAL settings I'm free to
chose System (video+audio) which gives me just one file for audio and video.
However, the bit rate seems to be maxed at something like 300+ kbit/s. When
playing the DVD it seems like the sound has higher quality with the 1,500
kbit/s setting (which it should)
I need to solve at least one of these two problems, hopefully someone can help me to sove both.
Well You must be very new to this...Your DVD Authoring Program is supposed to Join the Wav file with the Video file, you load them seperately into your DVD Authoring Program.You can not Mux WAV audio and Mpeg video in a Multiplexor...You can choose a different audio format which will give you audio and Video in the Same file..What you have to do is exit the Wizard, the choose your DVD Template then load the "Unlock.mcf" Template from the "Extra" Folder, this will unlock the settings so you can change them, go to "Settings" to "audio" and choose "Mpeg audio" as your Audio format and then choose your Bitrate (the higher the better Quality), then when you are finnished encodeing you will have a single file with audio and video But the wav audio will allways have better Quality, you can also get an AC3 encoder and encode the Wav to "Dolby Digital" which would give you exelent Quality with a much smaller file size than Wav but this is a bit of extra work...
Thanks for respond. Yes, I am kind of new to this, hence my questions. The reason I wanted to merge the MPEG2 files is that I'm using MyDVD as authoring software and it gives me one "chapter" for each file I'm importing. My editing software is kind of old and cut the exported avi files in 2GB sizes (don't want to spend the additonal $$ to get a new editing software now). I've converted these edited, exported avi files to MPEG2 files and wanted to merge them with the MPEG tools in TMPGEnc before importing them to MyDVD so that I can get the "chapters" I want on my DVD. To be able merge them I thought that I had to mux the audio video files together (I might be wrong here).
Anyway, if there's a workaround the default lower bit rate in a combined Video Audio file, that will take care of my problem.
Any other thoughts or suggestions around this subject, please let me know.
I have problem opening a frameserved avi file from VirtulaDub with TMPGEnc this display the followin error message "File not compatible cannot open the file" o something like that, how can i make it top work, I use virtualDub because I need the subtitles.
In VFAPI environment settings, try unchecking the Directshow File Reader. This solved a problem for me yesterday where reading a .vdr file hung the program.
I need import several mpg2 (720x486 D1 aspect, with fields) + wav (48khz stereo) to make mpg1 files (320x240 square aspect 3000 bitrate, 44khz stereo 160 bitrate)
Problem: Some times video stops somewhere at middle to end of the file; audio runs ok.
The original files comes from DPS Velocity, a professional non-linear video editing system. It exports mpg2+wav files and I join this files into a smaller mpg1 with audio. This files are send to clients to be aproved, so they must go with no errors.
Any Idea?
(please, sorry my poor english. This is the reason of my "spartan" frase, but I'm really desesperated)
You will probably have better results if you used DVD2AVI to frame serve the Mpeg2 files to Tmpgenc, It is a Faster method and it usually is a More trouble Free method of encodeing Mpeg2 files...