Progressive vs Interlaced questions

[Banner58]

Consider interlaced vs progressive video, in particular video files.

Here are my questions:

1) Do files of the two formats generally use the same frame rate?

For example, 24 frames per second?


2) Since a frame is a "snapshot" picture, would a 24 FPS 720p video file be roughly the same size as a 24 FPS 720i file of the "same" content?

[
That is to say, whether a frame consists of a single field as in p, or two fields ("odd" and "even") as in i, the same amount of "picture data" seems to exist.

I say "roughly", because the file would contain "metadata" in addition to "pixel data".

I'm also assuming that i vs p has no impact on compression efficiency (I can't see how it would).
]

3) Assuming that #1 and #2 above are correct, it is possible to convert i to p, placing the content into a "frame buffer".

Surely this could be done very cheaply and in real-time with hardware support (by a computer's video circuitry, within a TV, or by a "black box").

Would not such video (interlaced converted to progressive) have exactly the same quality as if the video source was progressive?

That is, wouldn't a 720i file have the same size as a 720p file, and wouldn't the two be indistinguishable if such a frame buffering technique were used?

If not, why?

Furthermore, could a 720i file simply be converted to a 720p file of the same (approximate) size?

If not, why not?

Is a p file somehow larger? What am I missing?

Also, my question applies to broadcast bandwidth.

For example, does a 1080p broadcast require more bandwidth than a 1080i broadcast? If so, why?

Whether the lines are sequential or interlaced, it's the same amount of data - unless frame rates are not the same.

Again, what am I missing?


Thanks

[jagabo]

1) Not necessarily.
2) Not necessarily.
3) In decompressed digital form they're almost always placed into a frame buffer.

In short, your questions don't really make sense because you have insufficient understanding what's going on.

In a true interlaced signal each field (one in all the even scanlines, one in all the odd scanlines) comes from a unique point in time. So a 29.97 fps interlaced frame contains 59.94 different fields (half-pictures), intended to be viewed separately and sequentially. When packaged in digital form pairs of fields are woven together into frames.

Movies are shot at 24 frames per second. They are slowed to 23.976 fps and go through 3:2 pulldown to create 59.94 fields per second for broadcast. On NTSC DVD they can be stored at 23.976 fps progressive or they can go through 3:2 pulldown, and combined into frames at 29.97 interlaced frames per second. The latter being less effiecint and creating more artifacts. In PAL countries the film is usually sped up to 25 fps. For broadcast it goes through 2:2 pulldown. On DVD the frames may be compressed in either progressive or interlaced mode, the latter being less efficient and creating more artifacts.

There are also many other variations and fine details.

[pandy]

For example, does a 1080p broadcast require more bandwidth than a 1080i broadcast? If so, why?

Estimated compression for interlace is usually 10 - 30% worse than for progressive.

So 1080p24 coded as 1080i24 can require up to 30% (especially for MPEG-2) higher bitrate than 1080p24 coded as 1080p24.

[Cornucopia]

BTW, there is no such thing (at least from professional or consumer equipment sources) as 720i!

"P" is always preferable to "I" in terms of data compression & efficiency & calculation simplicity, but "I" saves more bandwidth (1/2) than "P". That's why it exists at all. They serve different purposes. That's also the reason "I" hasn't died out with the advance of technology.

A 1080p file isn't giving you all the info, it is more accurately a 1080p30 or a 1080p60 file. BTW, a 1080i30 means the same as a 1080i60.
So which one's are you trying to combine/convert? An "I" signal that ISN'T unique in time (where the odd & the even come from the SAME time), isn't referred to as such by the pro community - they call it PsF. That's a "p" signal inside an "i"-flagged container. THOSE are easy to fix/convert. But like jagabo mentioned, you would NOT want to combine true "i" fields into a standard "p" frame, because you would have visible mice-teeth problems. You would also have just LOST half of your temporal resolution (e.g. going 1080i30 -> 1080p30), making the motion more stilted.

You need to get a better understanding about fields & frames (and the difference between how they work in analog vs. digital)...

Scott

[jagabo]

"I" saves more bandwidth (1/2) than "P"

This should be clarified. For compressed (MPEG family codecs) digital video 1080i30 requires more bandwidth than 1080p30. 1080i30 may require less than 1080p60 depending on the content. 24 fps movies telecined and broadcast at 1080i30 may require more bitrate than when frame duplicated to 1080p60 (exact duplicate frames require very little bitrate). But in the USA there are only two HD broadcast types: 1080i30 and 720p60.

Oh, this also depends on whether we're talking analog or digital. I was talking compressed digital above. With uncompressed digital and analog video 1080i30 is half the bandwidth of 1080p60. 1080i30 is the same bandwidth as 1080p30. This is why the broadcast industry wanted 1080i30 instead of 1080p60.

[pandy]

BTW, there is no such thing (at least from professional or consumer equipment sources) as 720i!

From technical point of view 720i30 is perfectly valid as also 720i60 i.e. 120 fields per second.

[Cornucopia]

@pandy, from a technical point of view, a hypothetical monochrome file of 143 x 999 @ 32.457 FPS is perfectly valid also, however most non-smart players would not be able to play it.

The point I was trying to make is that there are standards, and the standards are there for a reason: to alleviate the technical complexity & increase general compatibility. With standards, such as ATSC, even non-techie people can create various kinds of content and be relatively assured of it successfully playing error-free nearly anywhere.

That's why I included the parenthetical - so that the non-standard (and hopefully rare) exceptions wouldn't factor into this discussion.

@jagobo, yeah that's what I meant. I'm sure it needed clarification, as I wrote it quickly.

Scott

[pandy]

@pandy, from a technical point of view, a hypothetical monochrome file of 143 x 999 @ 32.457 FPS is perfectly valid also, however most non-smart players would not be able to play it.

The point I was trying to make is that there are standards, and the standards are there for a reason: to alleviate the technical complexity & increase general compatibility. With standards, such as ATSC, even non-techie people can create various kinds of content and be relatively assured of it successfully playing error-free nearly anywhere.

That's why I included the parenthetical - so that the non-standard (and hopefully rare) exceptions wouldn't factor into this discussion.

@jagobo, yeah that's what I meant. I'm sure it needed clarification, as I wrote it quickly.

Scott

Sorry but standard is MPEG-2, H.264 etc, resolutions are only recommendations - my understanding for term standard means some combination can be preferred but everything valid must be supported. Same rule for errors - if there any errors - device must be capable to deal with them. So anything valid form codec syntax point of view shall be supported.
Creating content... this is something else and this why for such people presets or preconfigured setups exist.

btw as You know amount of the framerates in MPEG-2 is quite limited thus "32.457 fps" is directly not possible and this is standard.

[Cornucopia]

I guess you and I will have to agree to disagree about what the meaning of "standard" is, then. I say: MPEG2, h.264 are big, encompassing standards. I also say ATSC & DVB are more strict standards (that rely on the former).
And the "32.457" didn't specify an encoding format. Could have been AVI, etc. If we're being more "large umbrella" in our understanding of standards as you suggest, then that ought to be allowed under your definition.

Scott

[pandy]

I guess you and I will have to agree to disagree about what the meaning of "standard" is, then. I say: MPEG2, h.264 are big, encompassing standards. I also say ATSC & DVB are more strict standards (that rely on the former).
And the "32.457" didn't specify an encoding format. Could have been AVI, etc. If we're being more "large umbrella" in our understanding of standards as you suggest, then that ought to be allowed under your definition.

Scott

Sarcasm understood but i don't want to start holly war - as a European i can say - DVB is not a standard per se - some things proposed by DVB are standard and are widely accepted, some DVB standards are seen as a recommendations and some broadcasters follow those recommendations some not (some broadcasters sometimes violate some DVB standards like PSI/SI structure but this is completely different discussion) - many things proposed by DVB was never accepted as standard in Europe.

I can say also - as topic was related to video not weather forecast or umbrella industry that 720p it is just recommendation but it is not mandatory as some broadcasters already violate rule that 720p should be 720p50/60 and they broadcasting for example 720p25 which is also against "standard" (for example Canal+Group sometimes transmit 720p25).

Unless it fit in video coding syntax then it is valid but perhaps not recommended as for example 480 or 640 which is not recommended resolution in Europe but can happen in real life and nowadays as many STB video decoders are at least "multimedia ready" they need to deal with various non common resolutions.

To conclude, i just saying that 720 can be interlaced to - probability is low as this is not recommended but technically feasible.

[Cornucopia]

Because some entities violate a standard doesn't make it NOT a standard, IMO (unless it was the vast majority). But I see where you're coming from.

Scott

[pandy]

Because some entities violate a standard doesn't make it NOT a standard, IMO (unless it was the vast majority). But I see where you're coming from.

Scott

I just see standard in a different way than You - recommendations are not a standard but just recommendations - follow them and your life will be easier. Standard is for me purely technical thing and product equipped with MPEG-2, H.264, VC-1 etc must follow MPEG-2, H.264, VC-1 etc where recommendations are mostly how to reduce number of combination's provided by standard.

Can't add nothing over that for me recommendation is not a standard - is more like pseudo standard because it is made based on some standard.