HD to SD conversion from premiere cs6 have poor quality

[pandy]

"BFF NOT TFF with TFF have flickering when move camera.

I just notice it, after I read your input, in Avisynth script I used BFF and then I told to set TFF in HcEncoder, ....., it has to be same in both instances, sorry.

In fact it can be fixed

AssumeBFF().SeparateFields().SelectEvery(4, 1, 2).Weave().AssumeTFF()

PAL is TFF when NTSC is BFF.

[avid]

"BFF NOT TFF with TFF have flickering when move camera.

I just notice it, after I read your input, in Avisynth script I used BFF and then I told to set TFF in HcEncoder, ....., it has to be same in both instances, sorry.

In fact it can be fixed

AssumeBFF().SeparateFields().SelectEvery(4, 1, 2).Weave().AssumeTFF()

PAL is TFF when NTSC is BFF.

this is the right??? --- AssumeBFF().SeparateFields().SelectEvery(4, 1, 2).Weave().AssumeTFF()

[_Al_]

but DVD could be TFF or BFF, does not matter, ..., and reality confirms that, handling PAL DVD's from Europe, burned DVD's, it is about 50/50

[sanlyn]

AssumeBFF().SeparateFields().SelectEvery(4, 1, 2).Weave().AssumeTFF()

PAL is TFF when NTSC is BFF.

NTSC DVD is usually TFF. NTSC-DV is usually BFF.

Isn't the O.P.'s video source progressive?

[avid]

(1).....AssumeBFF().SeparateFields().SelectEvery(4 , 0, 3).Weave() #this line makes it interlace 50i for DVD from 50p

ONE or TWO for PAL BFF

(2)....AssumeBFF().SeparateFields().SelectEvery(4, 1, 2).Weave().AssumeTFF()

[sanlyn]

wrong thread

[pandy]

I would say that NTSC is BFF and PAL TFF, even Avisynth behave like this assuming BFF when from some reason original dominance is unknown.

This is why i always force BFF at start to avoid mistakes - 4,0,3 pattern seem to be correct for TFF when TFF is known to Avisynth - 4,1,2 reverse BFF . Anyway there is common and frequent mistake and nowadays more and more PAL materials have incorrectly signaled or being signaled as BFF (NTSC) due of defaults in software like FinalCut where BFF is assumed, worse some professional TV (German, Dutch, Polish) with multimillion $ budget frequently make this mistake and you can see material BFF (due of use USA video software defaults) feed to encoder which is set as TFF (and it is without or with turned off features to recognize and correct field order).
Anyway it is good to verify correctness (or not) order by using at the end of script temporary SeparateFields() and visually check time-line for incorrect dominance.
So my advice always check field order before feeding data to encoder and if this is possible restore correct order (TFF for PAL and BFF for NTSC) just for special case (broken devices that blindly assume some order and ignore flag).

[pandy]

(1).....AssumeBFF().SeparateFields().SelectEvery(4 , 0, 3).Weave() #this line makes it interlace 50i for DVD from 50p

ONE or TWO for PAL BFF

(2)....AssumeBFF().SeparateFields().SelectEvery(4, 1, 2).Weave().AssumeTFF()

1 follow source field dominance - BFF remain BFF, TFF remain TFF,

2 is simple reverse i.e. BFF it turned to TFF and TFF to BFF - it is usefull if you trying to follow industry standard i.e. PAL area TFF and NTSC area BFF.

It is up to you - i always prefer to be prepared for worse case scenario and align with industry standards.

[LigH.de]

I would say that NTSC is BFF and PAL TFF...

You are more or less wrong here.

AviSynth assumes BFF if the source filter is not able to detect the field order. This is convenient for AviSource because AVI headers do not offer any flag for the field order, and DV (which is almost certainly BFF, no matter if PAL or NTSC) is usually read via AviSource. This assumption may be wrong for DVD/BD sources, though, if they are at all interlaced, but suitable source filters for such material may be able to detect the field order and report it to AviSynth.

Captured TV broadcasts may often be TFF. But that is less certain than DV recordings being BFF.

[pandy]

I would say that NTSC is BFF and PAL TFF...

You are more or less wrong here.

Perhaps yes, perhaps no.

As i wrote previously, Avisynth seem to follow US area rule and use BFF when source field dominance is unknown which is common in non European video processing software. (and seem to be contradictory to industry recommendations to use TFF as default).

AviSynth assumes BFF if the source filter is not able to detect the field order. This is convenient for AviSource because AVI headers do not offer any flag for the field order, and DV (which is almost certainly BFF, no matter if PAL or NTSC) is usually read via AviSource. This assumption may be wrong for DVD/BD sources, though, if they are at all interlaced, but suitable source filters for such material may be able to detect the field order and report it to AviSynth.

Captured TV broadcasts may often be TFF. But that is less certain than DV recordings being BFF.

"A complete video frame in the 525-line system consists of an even-line field followed by an odd-line field. In the 625-line system, a complete video frame consists of an odd line field followed by an even line field."

http://en.wikipedia.org/wiki/Field_dominance

http://lurkertech.com/lg/fields/#dominance_defn

I can be wrong but seem not only me...

[LigH.de]

TV broadcasting is one topic. Storing video in digital form is another...

This could turn into another epic battle, similar to Generic vs. ITU-R BT.601 aspect ratio on DVD. If you really insist. I won't: "errare humanum est".

[pandy]

TV broadcasting is one topic. Storing video in digital form is another...

This could turn into another epic battle, similar to Generic vs. ITU-R BT.601 aspect ratio on DVD. If you really insist. I won't: "errare humanum est".

No worry - I'm not interested in any dispute, also i was quite clear - this is my personal experience with various materials, I've learned never trust, always check and for many years this kind of attitude work quite well thus my advise.
And don't worry i know that You are "a Man with video knowledge".

And as this is great opportunity please allow me to say Thank You for Your work!

[sanlyn]

In this case the O.P. is working with progressive source.

LigH.de is correct. The interlaced field order for NTSC and PAL DVD is almost always TFF, whether via broadcast, commercial DVD and tape, consumer cameras that shoot interlaced MPEG video or interlaced "non-DV" HD video such as AVCHD, and telecined/pulldown video. I say "almost", because there is often that situation where BFF is used for one reason or another, or someone has modified the video in some way and implemented a different field order, or the camera is recording BFF. The remedy is to test first if you are going to modify the source. PAL and NTSC "DV" are almost always BFF.

To be certain, test first. Modify scripts accordingly and specify the field order where necessary.

[2Bdecided]

HD is always TFF.

Digital SD can be either. SDI can only carry TFF, which is why most professional content is TFF. For both broadcast and DVD either is perfectly fine, as long as it's flagged correctly.


The AVIsynth line for (re-)interlacing a progressive source is always SeparateFields().SelectEvery(4,0,3).Weave()

Put assumetff() before it if you want TFF; put assumebff() before it if you want BFF. You don't need to put anything after it.

You can use other combinations of those commands to give the same result, but it's needlessly confusing IMO.

Something like blur(0,1).sharpen(0,0.5) applied to the downscaled progressive content first will avoid nasty twittering and jaggies, as previously mentioned.

There are whole doom9 threads about this, e.g. ...
http://forum.doom9.org/showthread.php?t=139102 - most possibilities
http://forum.doom9.org/showthread.php?t=142682 - sharpest I've ever seen (but hopelessly slow - I've only used it for image resizing)
etc etc

Cheers,
David.

[pandy]

In this case the O.P. is working with progressive source.

Yes but he will turn progressive to interlaced one... as i said previously it is not important what we think or what we see on PC screen but important is video produced by decoding device, we need to follow ITU-R BT.1700 in case of Europe and RS-170A (SMPTE 170M) in case of USA.

LigH.de is correct. The interlaced field order for NTSC and PAL DVD is almost always TFF, whether via broadcast, commercial DVD and tape, consumer cameras that shoot interlaced MPEG video or interlaced "non-DV" HD video such as AVCHD, and telecined/pulldown video. I say "almost", because there is often that situation where BFF is used for one reason or another, or someone has modified the video in some way and implemented a different field order, or the camera is recording BFF. The remedy is to test first if you are going to modify the source. PAL and NTSC "DV" are almost always BFF.

To be certain, test first. Modify scripts accordingly and specify the field order where necessary.

My experience shows rule that NTSC sources is in 99% cases BFF and 99% cases for PAL are TFF - sorry but i can't share your point of view. This practice correspond to both mentioned video standards.
As i wrote previously - i'm not interested in starting any endless discussion about what kind order is expected to be and what kind of order is most common, all i can say it is one more time repeat, there are a country standards, industry standards and recommended practices, besides to this there are some habits (good or wrong this is irrelevant for this thread). I always checking field dominance (order) and i always trying to follow real life situations.

[2Bdecided]

we need to follow ITU-R BT.1700 in case of Europe and RS-170A (SMPTE 170M) in case of USA.

Devices which convert our digital video into SD analogue video need to follow aspects of those standards, but they're not that relevant to the digital video we deal with.

The field dominance described wrt analogue video is merely a convention. SD interlaced analogue video is always a sequence of fields - whether a top or bottom one arrives "first" depends on when you start looking. Which pair of fields makes a frame is merely a convention - there's nothing in the signal to tell you.

Whereas with most compressed digital video, the concept of frames is very real and part of the signal; knowing which field in a frame should be displayed first is vital.

Cheers,
David.

[pandy]

Something like blur(0,1).sharpen(0,0.5) applied to the downscaled progressive content first will avoid nasty twittering and jaggies, as previously mentioned.

But it can introduce flutter on edges due sinc side lobes... also it means that resizer was not sufficiently suppress aliasing...

[pandy]

Which pair of fields makes a frame is merely a convention - there's nothing in the signal to tell you.

I need to disagree - phase of chrominance sub-carrier burst is exact definition for field/frame relation and it precisely defined in current standards.

As i can agree that digital compression world doesn't need to follow analog video standard it also doesn't mean it should be different.

All those thing are set deep in history, i have nothing against to have everywhere TFF - however believe there no more annoying thing to observe incorrect field order in real life broadcast and sadly i must say this happen so regular nowadays - for example commercials for Battlefield 4 in Europe was frequently broadcast with incorrect field dominance...

[2Bdecided]

Which pair of fields makes a frame is merely a convention - there's nothing in the signal to tell you.

I need to disagree - phase of chrominance sub-carrier burst is exact definition for field/frame relation and it precisely defined in current standards.

Yes, the standard tells you the conventional numbering.

In the analogue signal itself, there is nothing to say that field n should be paired with field n-1 or n+1 when calling it a "frame".

All those thing are set deep in history, i have nothing against to have everywhere TFF - however believe there no more annoying thing to observe incorrect field order in real life broadcast and sadly i must say this happen so regular nowadays - for example commercials for Battlefield 4 in Europe was frequently broadcast with incorrect field dominance...

TFF and BFF are fully compliant for both "PAL" 625 50Hz and "NTSC" 525 60/1.001Hz SD interlaced video standards in DVB and DVD.

If it looks wrong, it's flagged wrong or converted wrong. But if it's flagged correctly (i.e. the flags match the actual content), neither is wrong for DVB or DVD.

You know DVD even allows for a change in field dominance in the middle of a video sequence? Players are (understandably) allowed a 1-field glitch, and it's a perverse thing to author to disc, but it is allowed.

Cheers,
David.

[2Bdecided]

Something like blur(0,1).sharpen(0,0.5) applied to the downscaled progressive content first will avoid nasty twittering and jaggies, as previously mentioned.

But it can introduce flutter on edges due sinc side lobes... also it means that resizer was not sufficiently suppress aliasing...

What do you mean? The resizer is targetting 576-lines, but in some senses the output is only 288 lines. The resizer is doing the job you ask of it just fine - it's just that you have to take further precautions to avoid line twitter on interlaced (or poorly deinterlaced) displays.

Cheers,
David.

[_Al_]

Sure in PAL land you should do DVD with TFF, but reality could be different, and basically it does not matter, as long it is flagged properly, but anyway I wanted op to make TFF DVD, that BFF in the script was mistake, as I tried to explain, but anyway, if he makes BFF nothing will happen also.

As soon as TV broadcast is being brought to discussions in "make DVD" topic, nothing will start to make sense, ....., because burned DVD's are not broadcast.

Even digital camcorders, DV camcorders, when they were introduced, used 720x576 and any time if there was a topic how to make a DVD, somebody showed up with BT regulations, broadcast this and that, and started to explain 704x ..., cropping pictures, making black bars ...

It goes hand in hand with interlace problem, when defenders of interlace started to always talk about broadcast and TV standards.

In any case , processing DVD, one has to check if it is bottom or top first does not matter where the DVD comes from.

[pandy]

In the analogue signal itself, there is nothing to say that field n should be paired with field n-1 or n+1 when calling it a "frame".

After 4 field sequence for NTSC and after 8 field sequence for PAL you can easily describe relation between frame and fields.
Of course this is something else than content as in interlace 2:1 only 2 field sequence is important to have correct time sequence.

If it looks wrong, it's flagged wrong or converted wrong. But if it's flagged correctly (i.e. the flags match the actual content), neither is wrong for DVB or DVD.

Yes, i agree however this happen - currently this discussion is completely out of main topic as usable field order can be established by checking and correct flagging and compressed video flagged correctly should work every however seem that analog video signal convention is accepted by video software thus errors that can be visible if person is not aware of this (and i assume material is prepared not by video guy but by some reporter and this person have no clue that there is something like interlace or progressive as it sit before nice LCD Macintosh with FinalCut doing some edit work and later this is sent over SDI to encoder).

You know DVD even allows for a change in field dominance in the middle of a video sequence? Players are (understandably) allowed a 1-field glitch, and it's a perverse thing to author to disc, but it is allowed.

Yes but this not change anything - lot of people not even realize that they watching video with incorrect field order (stutter is not an issue for them) but i doesn't mean that this is correct.

What do you mean? The resizer is targetting 576-lines, but in some senses the output is only 288 lines. The resizer is doing the job you ask of it just fine - it's just that you have to take further precautions to avoid line twitter on interlaced (or poorly deinterlaced) displays.

Where indeed it will suppress flicker there is also high chance that it will introduce flutter on some areas - this is why i don't think that Sharpen after Blur is a good idea. With some limitations Sharpen especially smart one (with edge detection perhaps) can be introduced before Blur but overall Blur should be applied last in chain to smoothly limit energy before Nyquist/2 - video signal feed to signal processing path shall be band limited to avoid problems. Sharpen after Blur artificially add some energy.
There is lot papers describing why video signal must be band limited, even separate chapters in worldwide standards.

Sure in PAL land you should do DVD with TFF, but reality could be different, and basically it does not matter, as long it is flagged properly, but anyway I wanted op to make TFF DVD, that BFF in the script was mistake, as I tried to explain, but anyway, if he makes BFF nothing will happen also.

As soon as TV broadcast is being brought to discussions in "make DVD" topic, nothing will start to make sense, ....., because burned DVD's are not broadcast.

Yes, i agree but good rules deserve to follow - why reinvent wheel when it is perfect?

Even digital camcorders, DV camcorders, when they were introduced, used 720x576 and any time if there was a topic how to make a DVD, somebody showed up with BT regulations, broadcast this and that, and started to explain 704x ..., cropping pictures, making black bars ...

No need for black bars as most of the digital encoders (NTSC/PAL/SECAM) can produce analog line timing and accept perfectly 704, real life signal can be long as 706.05 pixel or short as 702 pixel, as 706.05 is not nice for codec, closest number is 704 and it is almost perfectly in the middle between 706 and 702, good compromise and why bother about those 2 pixels?

It goes hand in hand with interlace problem, when defenders of interlace started to always talk about broadcast and TV standards.

Interlace is very good example how simple thing can works efficiently for a long time - it provide reduce bandwidth by half, it is very well matched with human perception model (exchange resolution for motion where motion is fast) - this is probably why it so long present and why just UHD was able to cancel of the interlace usage.

[2Bdecided]

In the analogue signal itself, there is nothing to say that field n should be paired with field n-1 or n+1 when calling it a "frame".

After 4 field sequence for NTSC and after 8 field sequence for PAL you can easily describe relation between frame and fields.

I think a language barrier must be getting in the way here. I am not saying anything controversial. There is nothing in the analogue video signal to tell you which two fields must be considered as a single frame. Analogue interlaced video does not contain any whole frames.

What do you mean? The resizer is targetting 576-lines, but in some senses the output is only 288 lines. The resizer is doing the job you ask of it just fine - it's just that you have to take further precautions to avoid line twitter on interlaced (or poorly deinterlaced) displays.

Where indeed it will suppress flicker there is also high chance that it will introduce flutter on some areas - this is why i don't think that Sharpen after Blur is a good idea. With some limitations Sharpen especially smart one (with edge detection perhaps) can be introduced before Blur but overall Blur should be applied last in chain to smoothly limit energy before Nyquist/2 - video signal feed to signal processing path shall be band limited to avoid problems. Sharpen after Blur artificially add some energy.
There is lot papers describing why video signal must be band limited, even separate chapters in worldwide standards.

But no one agrees what vertical nyquist/2 is for an interlaced signal. If you make it only 288-lines (hence 144 cycles per picture height), you might as well have no interlacing and use 720x288p50 - and the system, quite intentionally, is NOT this.

It is wise to make use of the system as it stands and squeeze through a little extra vertical resolution. How much more? That is subjective.

FWIW an accurate 144 cycles per picture height limit filter is included in one of the threads I linked to above - the result is not pretty IMO. AVIsynth's blur(1.0) command is just a (1/4, 1/2, 1/4) filter. In the frequency domain this isn't a very sharp or accurate filter, so doesn't do what you think you want anyway - it's certainly not giving you a good nyquist/2 cut-off.

Cheers,
David.

[_Al_]

Interlace is very good example how simple thing can works efficiently for a long time - it provide reduce bandwidth by half, it is very well matched with human perception model (exchange resolution for motion where motion is fast) - this is probably why it so long present and why just UHD was able to cancel of the interlace usage.

again and again, regular user does not give a damn about bandwidth ... , I understand broadcast point of view, but this has nothing to do with user cycle, shoot, edtit, store footage in best shape (frame rate) there is

with interlace you also need smart device on the other end

[2Bdecided]

with interlace you also need smart device on the other end

In what way was a CRT TV "smart"?

Anyway, if you want fluid motion on a DVD you have to interlace, so there's no point wishing it wasn't so.

Cheers,
David.

[pandy]

I think a language barrier must be getting in the way here. I am not saying anything controversial. There is nothing in the analogue video signal to tell you which two fields must be considered as a single frame. Analogue interlaced video does not contain any whole frames.

Perhaps it is language, perhaps way how i think about problem - as i wrote previously, based on analog video signal you can easily recognize sequence of fields and frames and all information is embedded to signal then i also agree that video content doesn't carry such information that provide unique identification - of course there are some (limited) methods to analyze video signal and to recognize field sequence.

What do you mean? The resizer is targetting 576-lines, but in some senses the output is only 288 lines. The resizer is doing the job you ask of it just fine - it's just that you have to take further precautions to avoid line twitter on interlaced (or poorly deinterlaced) displays.

But no one agrees what vertical nyquist/2 is for an interlaced signal. If you make it only 288-lines (hence 144 cycles per picture height), you might as well have no interlacing and use 720x288p50 - and the system, quite intentionally, is NOT this.

It is wise to make use of the system as it stands and squeeze through a little extra vertical resolution. How much more? That is subjective.

Yes - i agree this is dynamic and highly related to nature of content. Thus probably antialiasing cant be removed completely without sacrificing overall video resolution and quality, but it can be at least subjectively evaluated thus it is up to personal preferences to choose this or this way.

FWIW an accurate 144 cycles per picture height limit filter is included in one of the threads I linked to above - the result is not pretty IMO. AVIsynth's blur(1.0) command is just a (1/4, 1/2, 1/4) filter. In the frequency domain this isn't a very sharp or accurate filter, so doesn't do what you think you want anyway - it's certainly not giving you a good nyquist/2 cut-off.

I know, i don't even expect to have brickwall filter as i know implication, instead of this i've rather prefer smooth and soft energy decay - but of course this is purely subjective - IMHO optimal filtering shall involve motion analyze and adaptive way to deal/trade between vertical resolution/motion as this is a natural way how interlace act but i'm not aware of existence for such filter.