@jak.willis

I think to fully understand the problems involved with interleaved video, you first have to understand the limitations of the cathode ray tube and the fact that any interleaved video would always look better played back on such a device rather than a modern digital monitor where the playback of the individual frames and associated motion differences would be in relative sync using CRT compared to playing it back via a digital screen. It would be sharper to the eye for starters and the motion more fluid. There is nothing that can be done when transferring that for digital monitor consumption. That is transferring such material for use in the needed progressive format for a digital screen. Even the BBC can't get that done. Look at any of their commercial DVDs / Blu-ray discs of old black and white programs such as Dr Who.

Ray.

h.264 is a progressive format by default, it is not supposed to be interlaced,

This raises an interesting query which always puzzles me. What is the difference between MPEG-4, H264 and AVC encoding?

I have Handbrake H264 mp4 encoded files which show with MediaInfo as AVC. AVC can be interlaced and frequently is. E.g my 50i AVCHD camera files, AVCHD and Blu-ray. But these are usually mts or m2ts file types.

With mp4 files my experience is as per johnebaker's comments. Players expect mp4 files to be progressive and don't always handle interlaced correctly. My TV or Blu-ray player (I forget which) takes just one field and plays that at 25fps instead of taking both fields to display 50fps.

@ericlnz

Hi Eric.

This is just a guess but if you have a TV that increases the standard screen refresh rate it could be done to reduce flickering or bluring. It may be worth Googling.

Ray.

We're getting off the rails here. Talk of Smart rendering DV, frames verses fields, constant bitrates, MPEG 2 export (Jak's doing an MPEG 4 here), you can't re-interlace a progressive source of course you can; that's how you make a DVD from an MP4, is not the point.

As far as smart rendering goes, I've said it before and I'll say it again: the Main Concept MPEG 2 encoder (If you have it) will often Smart Render MPEG 2s, therefore avoiding quality loss. It will also smart-render a video object that has fades on it: it full-renders the changed parts eg the fade areas but will smart render the unchanged parts in the middle.

With either of the default encoders (MPEG 2 or 4), I have never had MEP smart render anything. Disappointing, especially when other programs do it.

@jak.willis

Jak, just try rendering with the default MEP MPEG 4 encoder, not the Main Concept encoder. On the Export Advanced screen, keep the bitrate up, say 8000kbps with a max of 10,000kbps and see how the motion turns out. Also, set the coding quality to Best. If it works OK, you can experiment with a lower bitrate.

@AAProds

Hi Alwyn.

Who has said you can't re-interlace a progressive source file? Please take the comments in context.

Also I have had the smart render feature work several times in MEP although I never set out with that intention in mind. If I get such an opportunity again I will document and record it.

Whether that would have been slower than using Handbrake or not I would not know as I have never had cause to use such a program and I assume as that would be Handbrakes only job, unlike using a video editor, that would be expected. The smart render in MEP was though faster than other forms of encoding.

Ray.

@AAProds, @jak.willis, @CubeAce

Hi

. . . We're getting off the rails here.  . . .

We are getting cross over from another post by Jak on what is essentially the same topic, however the information is relevant.

Jaks source video is interlaced, he is exporting to MPEG-4 -  which is a standard for a video/audio encoding formats, h.264/AVC being the codec used here.

Motion can be an issue for interlaced to progressive conversion due to, as Ray has correctly described, the time difference between fields, similarly there is a potential issue converting progressive to interlaced. The conversion process would have to re-calculate every single frame/field to take into account the time differential in either conversion direction.

I will add in another issue Jak may see - in the conversion from interlaced to progressive another big issue is combing, again in the same root cause - time differential - more here.

John EB

@CubeAce Ray:

Once you combine those frames to progressive they can't be separated again and you have say 30 frames rather than the original 60. Trying to interlace them after would mean producing more frames to be interlaced. That could be the 'odd movement' you are seeing. Especially if you have downloaded interlaced footage that has already been combined into a progressive file.

That is not correct. Also, there are 60 fields in a 30-frames per second video.

I will add in another issue Jak may see - in the conversion from interlaced to progressive another big issue is combing, again in the same root cause - time differential - more here.

I think you guys are way overthinking this. Interlaced to Progressive is the most basic step for any video. The only issue is whether the top or bottom field is "thrown away" to get rid of the combing, or a smart deinterlacer such as QTGMC combines the two fields (better quality video). The end result is the same: there is only one field, and that is a frame. You cannot have combing (interlacing) artefacts/effects after the video has been encoded into MPEG 4 (unless it is a weird interlaced version). There aren't two fields to view. If there is combing after deinterlacing, it is probably because the original video has issues. You see it sometimes on YT; bad combing because of messed-up deinterlacing before it got to YT.

You will not get interlaced artefacts/combing with MEP unless the source is dud.

Let's wait to see what Jak's video turns out like when he uses the default MPEG 4 encoder.

@AAProds, @jak.willis, @CubeAce

Hi

. . . We're getting off the rails here.  . . .

We are getting cross over from another post by Jak on what is essentially the same topic, however the information is relevant.

Jaks source video is interlaced, he is exporting to MPEG-4 -  which is a standard for a video/audio encoding formats, h.264/AVC being the codec used here.

Motion can be an issue for interlaced to progressive conversion due to, as Ray has correctly described, the time difference between fields, similarly there is a potential issue converting progressive to interlaced. The conversion process would have to re-calculate every single frame/field to take into account the time differential in either conversion direction.

I will add in another issue Jak may see - in the conversion from interlaced to progressive another big issue is combing, again in the same root cause - time differential - more here.

John EB

 

Thanks John.

@CubeAce Ray:

Once you combine those frames to progressive they can't be separated again and you have say 30 frames rather than the original 60. Trying to interlace them after would mean producing more frames to be interlaced. That could be the 'odd movement' you are seeing. Especially if you have downloaded interlaced footage that has already been combined into a progressive file.

That is not correct. Also, there are 60 fields in a 30-frames per second video.

I will add in another issue Jak may see - in the conversion from interlaced to progressive another big issue is combing, again in the same root cause - time differential - more here.

I think you guys are way overthinking this. Interlaced to Progressive is the most basic step for any video. The only issue is whether the top or bottom field is "thrown away" to get rid of the combing, or a smart deinterlacer such as QTGMC combines the two fields (better quality video). The end result is the same: there is only one field, and that is a frame. You cannot have combing (interlacing) artefacts/effects after the video has been encoded into MPEG 4 (unless it is a weird interlaced version). There aren't two fields to view. If there is combing after deinterlacing, it is probably because the original video has issues. You see it sometimes on YT; bad combing because of messed-up deinterlacing before it got to YT.

You will not get interlaced artefacts/combing with MEP unless the source is dud.

Let's wait to see what Jak's video turns out like when he uses the default MPEG 4 encoder.

Hi, yes, I will have the result for you this evening.

@AAProds

Hi Alwyn.

First apologies for the wrong terms I used but sometimes I try to keep to KISS explanations and not mix terms that are almost equal. No offense or dumbing down intended.

So you have two fields making up one frame. There is a difference of time between the recording of the two fields. The amount of movement recorded between record times of the two fields is dependent on the exposure time of each recorded field along with the speed of the objects within the frame over the duration of the exposure. It is always there to some degree whatever method is used to blend the final frame with the exception of recording a still image. If it smoothed / blended, whatever method is used and then converted into one progressive frame, that frame then has baked in information that can no longer be separated. You can duplicate the frame or perhaps predict the needed alterations to produce a new frame but you can not get the original information back into an interleaved format. Whether that is perceptual or not is very source dependent and to a degree dependent on the monitoring equipment.

My only argument is if one is using interlaced material it should be kept interlaced throughout the editing stage.

That any progressive video that was originally interleaved should not be included in such a project unless there is no alternative and it is always better to use the original files where possible.

I do not see any problems with converting original progressive formatted material beyond the obvious loss of quality that could occur transferring to a medium that could be of lesser quality or reduction in resolution.

Ray.

@AAProds

Hi Alwyn

. . . . The only issue is whether the top or bottom field is "thrown away" to get rid of the combing, or a smart deinterlacer such as QTGMC combines the two fields (better quality video).  . . . .

If you 'throw a field away' you have lost half the frame image - the 2 fields must be combined to produce a complete frame - the 'how' is the question - the simple way, using both fields as is, can result in combing.

QTGMC, I could not remember the name, does what I said above about re-calculating every single frame, it interpolates the new frame from the top & bottom field reducing the time offset difference error by 'temporal smoothing' - and then has to 'repair' the image to fix issues.

. . . . You will not get interlaced artefacts/combing with MEP unless the source is dud. . . .

I would disagree - below are 2 screenshots from a MEP export of a good interlaced source video (1920 x 1080) to progressive - note the blurred smoothing/artefacts around the tip of the tail in the right image which is the next adjacent frame to the left image.

John EB

@CubeAce Ray:

Once you combine those frames to progressive they can't be separated again and you have say 30 frames rather than the original 60. Trying to interlace them after would mean producing more frames to be interlaced. That could be the 'odd movement' you are seeing. Especially if you have downloaded interlaced footage that has already been combined into a progressive file.

That is not correct. Also, there are 60 fields in a 30-frames per second video.

I will add in another issue Jak may see - in the conversion from interlaced to progressive another big issue is combing, again in the same root cause - time differential - more here.

I think you guys are way overthinking this. Interlaced to Progressive is the most basic step for any video. The only issue is whether the top or bottom field is "thrown away" to get rid of the combing, or a smart deinterlacer such as QTGMC combines the two fields (better quality video). The end result is the same: there is only one field, and that is a frame. You cannot have combing (interlacing) artefacts/effects after the video has been encoded into MPEG 4 (unless it is a weird interlaced version). There aren't two fields to view. If there is combing after deinterlacing, it is probably because the original video has issues. You see it sometimes on YT; bad combing because of messed-up deinterlacing before it got to YT.

You will not get interlaced artefacts/combing with MEP unless the source is dud.

Let's wait to see what Jak's video turns out like when he uses the default MPEG 4 encoder.

Hi, so the results using the default MPEG-4 encoder were pretty much the same as the results I got using the MainConcept encoder. So basically what I would call “poor motion quality.”

@jak.willis

Hi

. . . . so the results using the default MPEG-4 encoder were pretty much the same as the results I got using the MainConcept encoder. So basically what I would call “poor motion quality.” . . . .

Assuming you are referring to the image I posted, not exactly - the poor motion quality is an interlaced artefact created as a result of motion, in a progressive video you would not get this.

You have to remember that the example of artefacts I posted is one frame from the video exported, around it were several frames which did not show this effect. When viewed at normal speed the 'artefacts' are not seen due to visual persistence, the rapidly varying location of the artefacts and the low proportion of sequential frames showing them in one particular place - if you look closely in the left image there are similar artefacts at top of the animals back, this was the fastest moving part, that are not visible in the right frame.

If you are seeing artefacts in a video, then, for the most part, there must be a high enough proportion of sequential frames showing these artefacts for the eye to perceive them or they are very severe, eg different coloured spots or persistent blockiness.

John EB

@jak.willis

Hi

. . . . so the results using the default MPEG-4 encoder were pretty much the same as the results I got using the MainConcept encoder. So basically what I would call “poor motion quality.” . . . .

Assuming you are referring to the image I posted, no.

You have to remember that the example of artefacts I posted is one frame from the video exported, around it were several frames which did not show this effect. When viewed at normal speed the 'artefacts' are not seen due to visual persistence, the rapidly varying location of the artefacts and the low proportion of sequential frames showing them in one particular place - if you look closely in the left image there are similar artefacts at top of the animals back, this was the fastest moving part, that are not visible in the right frame.

If you are seeing artefacts in a video, then, for the most part, there must be a high enough proportion of sequential frames showing these artefacts for the eye to perceive them or they are very severe, eg different coloured spots or persistent blockiness.

John EB

Hi John, sorry for the confusion, I was replying to AAProd's comment about seeing what the results are for when I try encoding the video using the default MPEG-4 encoder.

@jak.willis

Hi Jak

. . . . sorry for the confusion . . .

No problem, I have just checked my reply above and missed the end of a sentence off while moving the text around, now corrected.

John EB

@jak.willis Jak, any chance of uploading your MPEG to Google Drive or Dropbox for us to examine?

@jak.willis Jak, any chance of uploading your MPEG to Google Drive or Dropbox for us to examine?

Sure, I’ll upload the original and the MPEG-4 for you to have a look at.

@jak.willis

Hi Jak

. . . . sorry for the confusion . . .

No problem, I have just checked my reply above and missed the end of a sentence off while moving the text around, now corrected.

John EB

John, regarding what you were telling me about MPEG-4 being a Progressive format, in the H.264 MainConcept encoder there is a drop-down menu with options of Progressive Frame, Interlaced fields, and Interlaced frame. If I were to select one of the interlaced options, would the output file still be Progressive?

@jak.willis Jak, any chance of uploading your MPEG to Google Drive or Dropbox for us to examine?

Where do I upload it to?

@jak.willis

Where do I upload it to?

To either Google Drive or Dropbox (or any other file-sharing site), as @AAProds suggested, and then post the download link here.

Don't try to attach it to a forum post because the forum software will, inevitably, "alter" it, even if it accepts the attachment.

Jeff

@jak.willis

Hi Jak.

The file will be interlaced.

This is possibly the easiest site I have found with full explanations of what is going on with interlaced video and the associated problems of working with it including not compressing the files too much.

The site information can be found here.

Ray.

@jak.willis, @CubeAce

Hi Jak

. . . . with options of Progressive Frame, Interlaced fields, and Interlaced frame. If I were to select one of the interlaced options, would the output file still be Progressive . . . .

No and Yes - it will be interlaced or mixed progressive/interlace depending on which 'interlaced' option is selected ie:.

Interlaced fields is more often referred to as AVC encoded and encodes as separate fields, either Top Field First (TFF) or Bottom Field First (BFF)

Interlaced frame - creates frames which are a mix of progressive and interlaced known as MBAFF - see here for a more detailed description.

In theory the latter should produce better quality video, the testing with a pan shot with high detail level I have done it appears to be worse. I also had to use Software encoding - no Hardware Acceleration, in both cases the MC encoded video is not as good as the Default encoder either using Software encoding or with Hardware Acceleration, nor is the rendering time for the MC encoder, having a 17 second delay before the progress window appears and the progress bar starts to move - it is as if the encoder is analysing the video clip before starting the render - it was set to Single pass for the tests and done using MEP 2021.

John EB