Encoding progressive video

[12monkeys]

Hello
I have a digital TV card in my pc and I've captured a TV program.
It's PAL progressive, but it's flagged as interlaced, top field first.

When I use HC to encode the video, should I encode as progressive ?
Or should I encode as interlaced, top field first ?

I ask this because most of the video that I've seen in PAL land
is progressive, but it has been encoded as interlaced, top field first.

What are the advantages/disadvantages of encoding progressive as progressive ?
And what are the advantages/disadvantages of encoding progressive as interlaced, top field first ?

[MrTroy]

They are flagged as interlaced because broadcasting only allows 576i, not 576p. When encoding yourself, just do progressive. There's no advantage to encoding as interlaced.

[drcl]

Doesn't encoding an interlaced MPEG2 source as progressive force the chroma to be interpolated?

I would choose interlaced to preserve it's original structure.

I am assuming the source is chroma subsampled at 4:2:0 interlaced.

there is a sticky http://forum.doom9.org/showthread.php?t=70225

[Mug Funky]

think of it this way:

if an operator had to manually set interlaced mode on the TV station's encoder every time an ad break came on, just so the show could get a 10% (or less) efficiency gain, it wouldn't be worth it.

so interlaced, top-first is left on by default (SDI is top-first only, as all other formats should be but sadly aren't).

encode progressive if it looks pregressive. just make sure to check the credits and captions in the show, as these often are interlaced, but can be encoded progressive with the rest of it if it doesn't look like it'll be a problem (ie white credits on black can be done this way, though i wouldn't recommend it. perhaps splitting your source into feature and credits would be better in this case).

[12monkeys]

They are flagged as interlaced because broadcasting only allows 576i, not 576p. When encoding yourself, just do progressive. There's no advantage to encoding as interlaced.
think of it this way:

if an operator had to manually set interlaced mode on the TV station's encoder every time an ad break came on, just so the show could get a 10% (or less) efficiency gain, it wouldn't be worth it.
Everything that I have read supports these 2 statements. The broadcasters encode everything as interlaced because it's easier for them to do so.
so interlaced, top-first is left on by default (SDI is top-first only, as all other formats should be but sadly aren't).

encode progressive if it looks pregressive. just make sure to check the credits and captions in the show, as these often are interlaced, but can be encoded progressive with the rest of it if it doesn't look like it'll be a problem (ie white credits on black can be done this way, though i wouldn't recommend it. perhaps splitting your source into feature and credits would be better in this case).
As it happens this all of this footage is progressive, including the openning and closing credits.
Reading between the lines, I think that what you are saying is-
If the credits are interlaced then deinterlace them, then join them to the feature (using avisynth) and encode as progressive so that you can take advantage of the 10% (or less) efficiency gain.
Doesn't encoding an interlaced MPEG2 source as progressive force the chroma to be interpolated?

I would choose interlaced to preserve it's original structure.

I am assuming the source is chroma subsampled at 4:2:0 interlaced.

there is a sticky http://forum.doom9.org/showthread.php?t=70225
That sticky left me very confused.
I don't think that there is anything wrong with converting colour spaces as long as it is both necessary and done correctly.
I'm using the PeachSmoother in my script and in order to use it I have to ConvertToYUY2().PeachSmoother().ConvertToYv12()

There are 4 ways of doing this -
ConvertToYUY2().PeachSmoother().ConvertToYv12()

ConvertToYUY2(interlaced=true).PeachSmoother().ConvertToYv12(interlaced=true)

separatefields()
ConvertToYUY2().PeachSmoother().ConvertToYv12()
weave()

separatefields()
ConvertToYUY2(interlaced=true).PeachSmoother().ConvertToYv12(interlaced=true)
weave()

To my eyes 3 and 4 give the most pleasing results.
But which method is the most correct ?

[drcl]

I would say 2 and 3 both preserve the original chroma fields.

I didnt say there was anything wrong with converting colourspaces, but in forcing the encoder to encode progressively it would need to average the vertically adjacent chroma pixels.

ie. if you had a frame with one field all blue and one field all red, it would become completely blurred to purple.

That is my understanding of how YV12 works anyway.

this should illustrate

try with alternate converttoyv12() commands



a=BlankClip(length=500, width=720, height=288, pixel_type="YUY2", fps=25, fps_denominator=1, audio_rate=48000, stereo=false, sixteen_bit=true, color=$FF0000)
b=BlankClip(length=500, width=720, height=288, pixel_type="YUY2", fps=25, fps_denominator=1, audio_rate=48000, stereo=false, sixteen_bit=true, color=$0000FF)
interleave(a,b)
assumefieldbased()
weave()
converttoyv12(interlaced=true)
#converttoyv12()




The original format for TV would be YUY or similar so 4:2:2 then when digitized for broadcast would become YV12 interlaced 4:2:0 or if its high profile, 4:2:2.

if its high profile its safe to encode progressive otherwise I would use interlaced.

[colinb]

There was a thread sometime last year where this was discussed at length. The conclusion appeared to be that if the YV12 footage CONTENT was progressive then it should be MPEG encoded as progressive even though the source was flagged as interlaced.

This is counter-intuitive as you would expect that the chroma samples would have to be interpolated, but there was a very good argument as to why this was not the case.

See this thread and the "must read" link that neuron2 mentions in it.

http://neuron2.net/board/viewtopic.php?t=840

[drcl]

is my script not appropriate? am i imissing the point?

none of this makes sense.

why does mpeg-2 interlaced require a 16x32 pixel macroblock?

I wasn't really sure what was being suggested in that thread.

That interlaced flagged encodes have chroma encoded progressively??????

The no motion argument makes no sense either. The sample script i provided had no motion. but there was total loss of colour separation. On a TV the chroma would look purple anyway with preserved fields. In the end isnt it better to keep things as close to the original capture as possible?

[12monkeys]

There was a thread sometime last year where this was discussed at length. The conclusion appeared to be that if the YV12 footage CONTENT was progressive then it should be MPEG encoded as progressive even though the source was flagged as interlaced.

This is counter-intuitive as you would expect that the chroma samples would have to be interpolated, but there was a very good argument as to why this was not the case.

See this thread and the "must read" link that neuron2 mentions in it.

http://neuron2.net/board/viewtopic.php?t=840

Thanks for the link :)
I'm reading the thread(s) now.
I may be some time :eek:

[drcl]

i took a sample from an interlaced encoded PAL movie.
i stripped out the 2 fields that supposedly share the same chroma(4 and 6)

anyone care to explain why this doesnt give a gray (no colour) output and gives an output on the chroma graph in histogram?


loadplugin("D:\Program Files\GordianKnot\DGMPGDec\dgdecode.dll")
mpeg2source("D:\Documents and settings\DRCL\Desktop\cannonball.d2v")

assumeframebased()
x=converttoyuy2(interlaced=true)
a=crop(x,0,4,720,1)
b=crop(x,0,6,720,1)
r=subtract(a,b)
stackvertical(r,r,r,r,r,r,r,r).pointresize(720,576).converttoyv12()
histogram(mode="levels")

[drcl]

i modified my script from earlier.....


a=BlankClip(length=500, width=720, height=288, pixel_type="YUY2", fps=25, fps_denominator=1, audio_rate=48000, stereo=false, sixteen_bit=true, color=$FF0000)
b=BlankClip(length=500, width=720, height=288, pixel_type="YUY2", fps=25, fps_denominator=1, audio_rate=48000, stereo=false, sixteen_bit=true, color=$00fF00)
interleave(a,b)
assumefieldbased()
weave()

#1
converttoyv12(interlaced=true)

#2
#converttoyuy2(interlaced=true)



viewing the output alternately; with no colorspace conversion, with #1 and then with #1 and #2

both yuy2 outputs look the same

the yuy2 and yv12 outputs look different. they should look the exactly the same.

this would lead me to believe the YV12 codec is not working correctly.

Or is this correct behaviour?

I started a new thread on this but i think it might be appropriate here too.