Blackmagic Forum

Does anyone know how to render out 50i from 50p footage in resolve?
I added it to a 50i timeline and exported using "field rendering" but it's just 25p with a metadata flag set to "Interlaced". Or maybe it's 25 PsF. Did anyone manage to export 50i??

SamBroggs wrote:Does anyone know how to render out 50i from 50p footage in resolve?
I added it to a 50i timeline and exported using "field rendering" but it's just 25p with a metadata flag set to "Interlaced". Or maybe it's 25 PsF. Did anyone manage to export 50i??

How can you to do real 50i (100 interlaced fields) from 50p (50 progressive frames)?
You can to do 25i (50 interlaced fields) or 50PsF.

SamBroggs wrote:Does anyone know how to render out 50i from 50p footage in resolve?
I added it to a 50i timeline and exported using "field rendering" but it's just 25p with a metadata flag set to "Interlaced". Or maybe it's 25 PsF. Did anyone manage to export 50i??

Should be it. If it didn't work then it means you most likely can't do it in Resolve.
Interlaced handling in Resolve is still not optimal.

Allright, let's call it 25i.
Rendering out true 25i is a very basic function,
and it is an absolute must for all broadcast applications in europe.
If it's not possible then Resolve is definitely not compatible for any broadcast application.
As most workflows tend to record in 50p UHD and then convert to 25i..
Then I definitely have to switch back to another software..
Did anyone manage to export 25i???

Yes, it's very easy for app which is designed to do it (you just take every 2nd line).
I assume you set you project to 25fps+"Enable field processing" and you rendered to codec which supports interlace mode (ProRes, XDCAM HD, GV codecs....)?

I just tried and there is no way to do it (what you asked for) in Resolve. Easily doable in Premiere or Edius.

It's not possible. Resolve can't create interlace and don't support interlace project.

The real issue here is that progressive vs interlace are fundamentally differently time-related.

PsF is indistinguishable in some ways from interlace, but you won't usually encounter any field dominance issues, because the adjacent lines are all geometrically related to a single original frame.

Resolve does NTSC interlace very well -- I have converted many 23.98P projects to 29.97i successfully, and it even does the SMPTE 2:3 field cadence correctly. Which I can't say for a few other prominent NLEs.

Interlace will probably go away at some point. Nearly all displays now are really showing a progressive conversion and once terrestrial broadcast finally dies, the bandwidth limitations will become obsolete.

I think modern broadcasters now realize this and really are only looking for an interlace flag. I am currently exporting a project (hodge-podge of source FPS media) that was edited on a 2997 timeline in FCPX. As long as I check off the "interlaced" flag in the Export page, even if I don't invoke *enable interlacing* it won't make any significant difference. The field sequence will be PsF no matter what I do, because they were either that way to begin with or true Progressive from the get-go and no way to interlace that *in the same sense* that NTSC interlace really meant a 4-field colour frame where each field was time-sequential and 90 degrees out of phase from subcarrier on the half-line.

The biggest trouble I had was with a bunch of "DVCPro" that had been digitized from tape to ProRes at 30.00 fps (I don't know why) but the fix was to establish a field dominance and de-interlace it. Then the producer stopped complaining about how "blurry" it was.

PAL is 25 interlaced 50 fields, but our concept of PAL is also out-moded because Phase Alternate Line also no longer exists in the real world.

jPo, CSI

JPOwens wrote:Resolve does NTSC interlace very well -- I have converted many 23.98P projects to 29.97i successfully, and it even does the SMPTE 2:3 field cadence correctly. Which I can't say for a few other prominent NLEs.

No, you didn't convert, you only put progressive source in interlace container.

JPOwens wrote:I think modern broadcasters now realize this and really are only looking for an interlace flag.

It's not true. Most TV programs are broadcast interlaced (true interlaced, not psf)

Vit Reiter wrote:

SamBroggs wrote:Does anyone know how to render out 50i from 50p footage in resolve?
I added it to a 50i timeline and exported using "field rendering" but it's just 25p with a metadata flag set to "Interlaced". Or maybe it's 25 PsF. Did anyone manage to export 50i??

How can you to do real 50i (100 interlaced fields) from 50p (50 progressive frames)?
You can to do 25i (50 interlaced fields) or 50PsF.

You are arguing semantics, both 25i and 50i can be used and mean the same thing.

Interlacing 50p to 50i or 25i (the first means 50 fields, the seconds means 25 frames) means to take the even lines from one frame and the odd lines from the following frame (either in a BFF or TFF format).

This operation cannot be done in Resolve.

Interlace and Progressive in my mind are not different time related. Certainly for NTSC 60P ( 59.94fps ) and 60i ( 59.94 fields per sec) have exactly the same temporal motion. They both sample the image at the same rate, 59.94 times a second. The only real difference is one has half the vertical resolution of the other, a field instead of a full frame. Getting 60i from 60p is a matter of extracting a field from each progressive frame alternating between odd and even and then setting the interlace flag. It is my understanding that PAL is exactly the same. I have not done this with Resolve but do this all the time with EDIUS. I shoot everything at 60P, do my editing in a 60P project ( sometimes going between EDIUS, RESOLVE and VEGAS ) then place the final file in an EDIUS interlace project and create a 1920x1080 59.94i fps interlace Bluray file for disc authoring.

It can be done via Fusion page. Here is the node tree to do it:

Code: Select all

{
   Tools = ordered() {
      TimeSpeed1 = TimeSpeed {
         Inputs = {
            Delay = Input { Value = -1, },
            InterpolateBetweenFrames = Input { Value = 0, },
            SampleSpread = Input { Disabled = true, },
            Input = Input {
               SourceOp = "MediaIn1",
               Source = "Output",
            },
         },
         ViewInfo = OperatorInfo { Pos = { 159.333, -32.0303 } },
      },
      MediaIn1 = MediaIn {
         ExtentSet = true,
         CustomData = { MediaProps = {
               MEDIA_FORMAT_TYPE = "QuickTime",
               MEDIA_HEIGHT = 1080,
               MEDIA_MARK_IN = 0,
               MEDIA_MARK_OUT = 1006,
               MEDIA_NAME = "C0017.MP4",
               MEDIA_NUM_FRAMES = 1008,
               MEDIA_NUM_LAYERS = 1,
               MEDIA_PAR = 1,
               MEDIA_PATH = "Z:\\Projekti\\COLONELO\\MEDIA\\PRIVATE\\M4ROOT\\CLIP\\C0017.MP4",
               MEDIA_SRC_FRAME_RATE = 25,
               MEDIA_START_FRAME = 0,
               MEDIA_WIDTH = 1920
            }, },
         Inputs = {
            GlobalOut = Input { Value = 1006, },
            Layer = Input { Value = "0", },
            ClipTimeEnd = Input { Value = 1006, },
            ["Gamut.SLogVersion"] = Input { Value = FuID { "SLog2" }, },
         },
         ViewInfo = OperatorInfo { Pos = { 38.3333, 34.3485 } },
      },
      Resize1 = BetterResize {
         Inputs = {
            Width = Input { Value = 1920, },
            Height = Input { Value = 540, },
            HiQOnly = Input { Value = 0, },
            PixelAspect = Input { Value = { 1, 1 }, },
            Input = Input {
               SourceOp = "MediaIn1",
               Source = "Output",
            },
         },
         ViewInfo = OperatorInfo { Pos = { 310.334, 31.9242 } },
      },
      Instance_Resize1 = BetterResize {
         CtrlWZoom = false,
         SourceOp = "Resize1",
         Inputs = {
            SettingsNest = Input { },
            ResetSize = Input { },
            Input = Input {
               SourceOp = "TimeSpeed1",
               Source = "Output",
            },
            CommentsNest = Input { },
            FrameRenderScriptNest = Input { },
            StartRenderScripts = Input { },
            EndRenderScripts = Input { },
         },
         ViewInfo = OperatorInfo { Pos = { 342, -29.6061 } },
      },
      Fields2 = Fields {
         Inputs = {
            Operation = Input { Value = FuID { "Interlace" }, },
            Stream1 = Input {
               SourceOp = "Instance_Resize1",
               Source = "Output",
            },
            Stream2 = Input {
               SourceOp = "Resize1",
               Source = "Output",
            },
         },
         ViewInfo = OperatorInfo { Pos = { 493.667, 34.3485 } },
      },
      MediaOut1 = MediaOut {
         Inputs = {
            Index = Input { Value = "0", },
            Input = Input {
               SourceOp = "Fields2",
               Source = "Output",
            },
         },
         ViewInfo = OperatorInfo { Pos = { 729, 41.6212 } },
      }
   }
}

The timeline should be 25 fps, "enable video processing" should be off...I tried only with exporting to XAVC in MXF so far, field rendering "on".

Did this stuff way back in my time, while Fusion was still Eyeon's...

JPOwens wrote:PsF is indistinguishable in some ways from interlace, but you won't usually encounter any field dominance issues, because the adjacent lines are all geometrically related to a single original frame.

Resolve does NTSC interlace very well -- I have converted many 23.98P projects to 29.97i successfully, and it even does the SMPTE 2:3 field cadence correctly. Which I can't say for a few other prominent NLEs.

Interlace will probably go away at some point. Nearly all displays now are really showing a progressive conversion and once terrestrial broadcast finally dies, the bandwidth limitations will become obsolete.

I think modern broadcasters now realize this and really are only looking for an interlace flag.

PsF is purely SDI term and has no real place outside it.
Reality is that broadcast is outdated and in 80% or more (at least in Europe) still uses interlaced signalling.
BBC for example broadcasts movies as 25p (finally), but all other content as 50i regardless of its real nature.

Resolve is FAAAR from having good interlace support. Does it really need it is a another question- for some it's a must for others meaningless. As you said- I hope interlaced dies soon as it's very problematic and not necessarily needed these days.

Thanks for all your help!
Maybe some day interlaces will die - I hope so.
But until then no editing will be relevant for broadcast that is not able to output true 25i.

Resolve handles interlaced footage ok but it will not create interlaced output from progressive footage. This is common with most editing software. Smoke and Flame have re-interlacing options but I'm not sure any regular editing software can do this.

That's a big problem. For example I am not able to capture in UHD 50p if I have to render out 25i in the end. So I am not able to use any higher resolutions in newer cameras at all..

SamBroggs wrote:That's a big problem. For example I am not able to capture in UHD 50p if I have to render out 25i in the end. So I am not able to use any higher resolutions in newer cameras at all..

My fusion node example is not working for you? Make empty 1080 25fps timeline and put yor main UHD timeline (compound clip of it) inside, then apply my example to it in fusion page.

Or are we just theoreticising?

Sent from my GM 5 Plus d using Tapatalk

Peter Cave wrote: Smoke and Flame have re-interlacing options but I'm not sure any regular editing software can do this.

About every NLE does it as it's quite trivial process.

Peter Cave wrote:Resolve handles interlaced footage ok but it will not create interlaced output from progressive footage. This is common with most editing software. Smoke and Flame have re-interlacing options but I'm not sure any regular editing software can do this.

Like Andrew Kolakowski said most NLE can do this with no problem - Avid, Premiere, FCPX, Sony Vegas even Magix. Yes you can do it with Fusion but its only workaround.

Resolve can handle interlaced footage but very simply, only simple cut and color grading. All effects (transform, zoom, retime, transition) and titles are processed as progressive and not per field.
So now is useless for broadcasting editor, and interlace don't died soon because for most people have no differences between 50p and 50i while for broadcasters it is 2x chepaer satelite stream.

However, isn't it something trivial and default for a play-out system do format the input to the required broadcast settings? You keep the master as 1080 or 2160p50 (as is universally recommended anyway), and it gets converted to interlace and/or downscaled in real-time as it's being aired?

To me it seems that Resolve as an NLE is consciously positioned in the non-broadcast market (youtubers, indie cinema etc), the NLE part being there primarily to avoid round-tripping.

Mario Kalogjera wrote:
To me it seems that Resolve as an NLE is consciously positioned in the non-broadcast market (youtubers, indie cinema etc), the NLE part being there primarily to avoid round-tripping.

It seems that way. The one NLE clearly pitched at broadcast is EDIUS because of the integration with the rest of the Grass Valley product line.

No all the broadcast environment only works in one codec. For example xdcam HD 25i. There is no reformatting during playout.

Strange that they are excluding a very big market just buy holding back one small function. Maybe you are right and resolve is still not a professional tool.

Mario Kalogjera wrote:However, isn't it something trivial and default for a play-out system do format the input to the required broadcast settings? You keep the master as 1080 or 2160p50 (as is universally recommended anyway), and it gets converted to interlace and/or downscaled in real-time as it's being aired?

To me it seems that Resolve as an NLE is consciously positioned in the non-broadcast market (youtubers, indie cinema etc), the NLE part being there primarily to avoid round-tripping.

SamBroggs wrote:No all the broadcast environment only works in one codec. For example xdcam HD 25i. There is no reformatting during playout.

Strange that they are excluding a very big market just buy holding back one small function. Maybe you are right and resolve is still not a professional tool.

It is a professional tool for film and TV series environment. Other tools that are interlace broadcast-friendlier are less powerful for film color-grading. All those well-known edit tools were created in the times when interlace was everything, they're just carrying the feature over to the new versions. Resolve bacame an NLE just recently.

The broadcast market is more or less taken by other companies and not that big unless you supply turn-key systems. But home-based edit studios for online delivery are plentiful... they just need to fix the VFR problem for game streamers

As per play-out thing, yeah, I talked to workflow supervisor at a nation-wide channel here and was told that they indeed use XDCAM HD 50 mbps interlaced for both aquisition and playout (no need to re-compress the cuts), but that was like 5 years ago, but I figured the systems would be powerful or modular enough to reformat for needed output. I for one don't see why that wouldn't be possible...or just stick a converter on the output...

Converting from 50 fps progressive to 25 fps intelaced is not a normal process, but rather a specific requirement. When you record content intended for televisions, you shoot on television cameras that can record interlaced video. In other cases, for example, if you are shooting a TV series on film cameras, you shoot the project 25 fps progressive and export the video as a PsF to be accepted by the televisions.

If, however, for some reason you need to make 25 fps interlaced from 50 fps progressive and you're not close to the script that Mario Kalogjera sent:

1. In Project Settings, check "Enable Video Field Processing" and select "None" inside General / Mixed Frame Rate Format.
2. Create a 25 fps timeline and insert a 50 fps progressive footage.
3. Go to Fusion tab, insert tools Fields and Resize.
4. Inside tool Fields set "Interlaced and PAL/HD (Reversed)".
5. Go to Deliver tab, check "Field Rendering" and export your 25 fps interlaced footage.

It's a standard feature ( or rather behaviour, not even a feature) of about every NLE. No idea why you say it's something special.

Andrew Kolakowski wrote:About every NLE does it as it's quite trivial process.

unfortunatly most common applications implement this feature in a rather insufficient manner!

it isn't anymore trivial, if you want handle it in broadcast adequate quality -- just as scaling by nearest-neighbor pixel picking or skipping sensor lines also doesn't produce convincing results.

see e.g.:
http://downloads.bbc.co.uk/rd/pubs/whp/ ... WHP315.pdf
http://downloads.bbc.co.uk/rd/pubs/whp/ ... WHP230.pdf

i really prefer the fact, that some of this legacy broadcast conventions are not supported in resolve, instead of accepting an insufficient implementation, as we are used to find it in BMD products in many similar cases already...

It isn't complicated at all. A full progressive frame can be considered as two scan fields, odd and even stacked together. It must be a simple task of splitting the progressive frame into these two fields and just using either the odd or even field from each of the sequential progressive frames. This of course will only work to get 60i from 60P or 50i from 50p. As the temporal motion is the same just half the vertical resolution. This of course is a much more difficult task if the source is 25P or 30P ( 29.97P ) Then interpolated fields will have to be created to get the smoother motion of 50i or 60i .

Martin Schitter wrote:unfortunatly most common applications implement this feature in a rather insufficient manner!

Please write specifically which applications, Avid or maybe FCPX?
Otherwise i can writing, most applications implemented this feature very well.

SkierEvans wrote:It isn't complicated at all. A full progressive frame can be considered as two scan fields, odd and even stacked together. It must be a simple task of splitting the progressive frame into these two fields and just using either the odd or even field from each of the sequential progressive frames.

sure, that's the common understanding of this process, but it's in fact an oversimplification -- at least, if you want to minimize the resulting artefacts.

just take a look at the two already linked BBC research papers. one of the abstracts gives the explanation:

"The interlacing process is a form of downsampling, and hence requires an anti-alias filter. For best results the anti-alias filter should be matched to the reconstruction filter, which is comprised of the display and the human visual system. Additionally, it must meet the technical requirements of the downsampling process. In this paper we present a novel method of measuring the combined response to interlacing artefacts that is simple and powerful."

Yes, but in real world in most cases those side effect are small. It mainly happens if you have very detailed and over-sharpened source. It's also way less relevant today when basically all displays are progressive so at the end your interlaced signal is converted to progressive anyway.
You can always put bit of low pass filtering (Edius may actually do it) if you want to follow academic approach. Real world is always a big simplification of academic approach.

BBC is an institution which has way too much public money- they like spending it on research which in many cases is purely theoretical and brings nothing REAL to the "problem".

yes -- it's just as significant as a proper scaling algorithm on rendering the deliveries or the side effects of sensor line skipping in some less professional video cameras. sure, it's only a minor issue and hardly recognizable by most recipients, nevertheless it's still this subtle gap, which often differentiates serious high end solutions from mediocre consumer crap.

Martin Schitter wrote:unfortunatly most common applications implement this feature in a rather insufficient manner!

it isn't anymore trivial, if you want handle it in broadcast adequate quality --...

Which is today crap as hell. You call broadcast quality a reference one? This was maybe true 30 years ago. Today broadcast is so outdated and all about saving bandwidth and squeezing more channels.
Even fact that it' still all interlaced is just best example how crap it's.

Andrew Kolakowski wrote:You call broadcast quality a reference one?
...
Even fact that it' still all interlaced is just best example how crap it's.

i personaly agree with you on this statement, but that's not the point!

My understanding of the papers is addressing how best to convert a progressive source to interlace and then displaying on a progressive display after transmission. Exactly what the BBC would be interested in doing. They get both interlaced and progressive source file to broadcast as interlaced, most of the time,and then viewed on a progressive display.

This thread is purely the act of getting an interlaced file from a progressive file in the first place and I think taking fields from the progressive source will result in a file no worse than a source file of interlace video from a camera. How that is dealt with for transmission to be viewed on a progressive display is totally different. It is a similar situation to viewing interlace DVD or Bluray discs from an upscaling Bluray player over HDMI to a high refresh rate display. They can look great or not.

progressive displays aren't an exotic corner case anymore. to the contrary, they are nowadays the common kind of display realization, since cathode ray tubes and their physical capabilities to realize interlaced image rendition in a more natural way by phosphor particle afterglow are more or less gone. so it's indeed a very natural question, how to handle the conversion into legacy interlaced video in the most suitable manner for use on nowadays real world displays. and the suggested filtering is a very common and usually accepted requirement in case of similar image processing tasks (e.g. color subsampling, image scaling) as well.

Martin Schitter wrote:progressive displays aren't an exotic corner case anymore. to the contrary, they are nowadays the common kind of display realization, since cathode ray tubes and their physical capabilities to realize interlaced image rendition in a more natural way by phosphor particle afterglow are more or less gone. so it's indeed a very natural question, how to handle the conversion into legacy interlaced video in the most suitable manner for use on nowadays real world displays. and the suggested filtering is a very common and usually accepted requirement in case of similar image processing tasks (e.g. color subsampling, image scaling) as well.

Yes but that was not the questioned posed. It was how to get an interlaced file from a progressive file. How that interlaced file is dealt with in transmission or viewed on a progressive display is a totally different topic.

Two issues. The world has pretty much gone progressive ( all my cameras and displays are progressive ) but both disc formats and broadcast are mainly still interlaced. So how to prepare an interlaced file for the broadcaster and then how to display this interlaced file on what most people have today, a progressive display. I am sure the BBC reports were addressing their task of preparing the file for the best result for their customers. They are trying to get a better file for transmission rather than a simplistic conversion to interlace. Do they still have the same issue with an interlace file from an ENG camera.

However both disc players and TV's also address this issue when faced with playback of interlaced source. Does what they do enhance the BBC filtering or make it worse ? I can verify that interlaced source plays back differently on my Panasonic plasma TV than on my 240Hz Sony LCD and DVD or Bluray also are different depending on the player I use which in my mind is the core source of good interlaced playback on my systems for DVD or Bluray. The latest Sony Bluray upscaling player produces very acceptable images from DVD and is very close to the Bluray disc I produced of the same source. Yes I can tell the difference but need to point it out to my wife. The source file 1920x1080 60P and the Bluray image are almost indistinguishable. Clearly the player and display are processing the input.

SkierEvans wrote:Yes but that was not the questioned posed. It was how to get an interlaced file from a progressive file. How that interlaced file is dealt with in transmission or viewed on a progressive display is a totally different topic.

i don't think, this papers are so much transmission or rendition focused. they main point, which you can learn from them, concerns the requirements of downsampling tasks, and that progressive-to-interlaced-conversion should be understood as one special case of this category.

the suggested filtering has to be done before downsampling resp. as one of the early steps during this conversion. it can't be postponed to a latter stage in the processing pipeline or capabilities on the recipients side, because the necessary information isn't available anymore after the downsampling -- just nasty artifacts, if it wasn't done very well.

it's a challenge, which has to be handled properly during the progressive-to-interlaced-conversion by your application or within your ENG camera [which nowadays will most likely do very similar image refinements based on a progressive sensor readout], nothing else.

and i wouldn't overestimate the deinterlace capabilities and quality of most consumer equipment. in this respect i share andrew kolakowskis point of view and can't work up any enthusiasm for interlaced video at all. legacy broadcast traditions often look like a pure anachronism and a horrible waste of image quality.

I was hoping that a professional color correction tool like resol could just do such a simple task as interlacing my footage..
I will try the fusion tab although I have never used it.
Thanks again!

@Sam: for pure color grading operations/purposes i.e getting interlaced source in, grading it then exporting it as interlace, Resolve is performing it's primary function professionally IMHO...

SamBroggs wrote:I was hoping that a professional color correction tool like resol could just do such a simple task as interlacing my footage..
I will try the fusion tab although I have never used it.
Thanks again!

What you are asking for has never been a standard part of most editing applications. They all handle interlaced footage properly but very few apps can split a progressive frame into two fields and then combine field one from frame one and field two from frame two into a new two-field frame thus creating a true 25fps 50i output which has motion between fields.

Flame and Smoke can de-interlace/re-interlace but I don't know of other apps that can do this.

As far as I can remember Vegas and EDIUS have always been able to do this. Before all my cameras were progressive I mixed progressive and interlace files in a multicam edit on the same interlaced timeline for years. Output was for DVD and BLuray which look just fine. This goes back to HDV interlaced 1920x1080 60i with AVCHD progressive 1920x1080 60P. TMPGenc will also take a progressive HD file and create an interlaced encode for DVD or BLuray. They may not be perfect for all subject matter but one has to consider that real people are going to see the output not test equipment.

Interlace generated from 60p (or 50p) split into fields will be perfect for all purposes where you'd normally shoot interlaced at half the rate. All the needed information is there.

Peter Cave wrote:

SamBroggs wrote:I was hoping that a professional color correction tool like resol could just do such a simple task as interlacing my footage..
I will try the fusion tab although I have never used it.
Thanks again!

What you are asking for has never been a standard part of most editing applications. They all handle interlaced footage properly but very few apps can split a progressive frame into two fields and then combine field one from frame one and field two from frame two into a new two-field frame thus creating a true 25fps 50i output which has motion between fields.

Flame and Smoke can de-interlace/re-interlace but I don't know of other apps that can do this.

Sam starts with 50p, not 25p and in this case it's easy process and about every NLE does it (actually I don't know any "bigger" NLE which can't do it).

Peter Cave wrote:very few apps can split a progressive frame into two fields and then combine field one from frame one and field two from frame two into a new two-field frame thus creating a true 25fps 50i output which has motion between fields.
Flame and Smoke can de-interlace/re-interlace but I don't know of other apps that can do this.

You wrote this nonsense for the second time, please, do not mislead people.
Almost every NLE can do this!

At my broadcast station they recommended to just buy an old avid or final cut licence. So I guess almost every other editing software is capable of rendering out 25i from 50p..

Kenzo wrote:

Peter Cave wrote:very few apps can split a progressive frame into two fields and then combine field one from frame one and field two from frame two into a new two-field frame thus creating a true 25fps 50i output which has motion between fields.
Flame and Smoke can de-interlace/re-interlace but I don't know of other apps that can do this.

You wrote this nonsense for the second time, please, do not mislead people.
Almost every NLE can do this!

Why nonsense?
I know adobe premiere now has this feature but can you explain how to do it in Avid or FCP or FCPX?
Nobody seems to have a solution for these apps.
Avid outputs progressive 50P source as 25P in the final interlaced output. I would be keen to learn how to do a true interlaced output.

Keep in mind I am NOT talking about progressive footage being rendered in an interlaced codec format but actually creating fields from the progressive source frames so 50P becomes a true 25fps 50i format with motion between fields.

I am beginning to feel that you do not understand interlace video. The timecode for interlaced video for NTSC and PAl increments every two fields coincident with the interlace sync pulse that tells interlace equipment to start the field sequence. So for PAL 25fps interlace or 29.97fps NTSC indicates a sequence of pairs of fields one odd and one even. These fields have exactly the same temporal motion as the full progressive formats 50P and 60P ( 59.94P ). Taking a field ( either odd or even ) from the progressive video should not be a difficult task for any NLE. There is NO motion to interpolate between fields you seem to be confused with the fact that 50i is 25fps timecode but actually 50 fields and 29.97fps NTSC is actually 59.94 fields a second exactly the same temporal motion as the progressive formats in both cases. There is NO motion to interpolate just take one field from each progressive frame alternating odd and even field.

SkierEvans wrote:I am beginning to feel that you do not understand interlace video. The timecode for interlaced video for NTSC and PAl increments every two fields coincident with the interlace sync pulse that tells interlace equipment to start the field sequence. So for PAL 25fps interlace or 29.97fps NTSC indicates a sequence of pairs of fields one odd and one even. These fields have exactly the same temporal motion as the full progressive formats 50P and 60P ( 59.94P ). Taking a field ( either odd or even ) from the progressive video should not be a difficult task for any NLE. There is NO motion to interpolate between fields you seem to be confused with the fact that 50i is 25fps timecode but actually 50 fields and 29.97fps NTSC is actually 59.94 fields a second exactly the same temporal motion as the progressive formats in both cases. There is NO motion to interpolate just take one field from each progressive frame alternating odd and even field.

I understand fields as I came from the world of analog broadcast transmission and studied electronics. My issue is that in this topic people have made claims about converting 50fps progressive footage to a true interlaced output on a 50i (25fps) interlaced timeline being easy on nearly all editing apps. My experience is different. I have tried on Avid, FCPX, FCP7, Resolve, Premiere, After Effects etc. Adobe can do it but I've had no success with the other apps. Until someone can DEMONSTRATE the workflow I regard all comments as theoretical only.

No disrespect for anyone here.

I suggest you try EDIUS or Vegas on a PC. I have done this for many years and works fine.

Peter Cave wrote:I know adobe premiere now has this feature but can you explain how to do it
Nobody seems to have a solution for these apps.
Avid outputs progressive 50P source as 25P in the final interlaced output. I would be keen to learn how to do a true interlaced output.

Keep in mind I am NOT talking about progressive footage being rendered in an interlaced codec format but actually creating fields from the progressive source frames so 50P becomes a true 25fps 50i format with motion between fields.

In Avid you must create 50i project and put your 50p footage on timeline, that's all. You get true motion between fields. Same Premiere (in Premiere sequence must be 50i).

You basically drop 50p source into 50i project. That's it. Maybe your source was 25p not 50p.