Chroma subsampling in PsF, progressive or interlaced?

[roozhou]

Many consumer camcorders and DSLRs can capture progressive frames and store in interlaced AVCHD. This is called "Progressive segmented frame" (PsF).

Well, I wonder which kind of chroma subsampling does such streams use, p or i? Is it safe to just weave top and bottom fields and upsample chroma in progressive mode?

[kieranrk]

PsF is the same as interlaced except the two fields represent the same point in time instead of two different points in time. After weave, you can treat the picture as progressive.

[roozhou]

Do you mean that 1st chroma line is subsampled from 1st and 2nd original RGB line? AFAIK in interlaced 4:2:0, 1st chroma line is subsampled from 1st and 3rd RGB line.

[2Bdecided]

They use interlaced chroma. There's nothing clever you can do about this afterwards. You have to blur the chroma down to 1/4 resolution vertically to remove the problems.

It sounds like you've read this, but if not, here it is...
http://www.hometheaterhifi.com/the-dvd-benchmark/179-the-chroma-upsampling-error-and-the-420-interlaced-chroma-problem.html


Some camcorders even feed the video to the MPEG encoder as if it was pure interlaced - meaning the encoder is free to make encoding decisions which are entirely inappropriate for the progressive content. This means you can get what look like slight interlace artefacts in the luma of progressive footage, because the encoder did something slightly different for the two fields which should make up a single progressive frame. It's subtle, but I've examples from a few different sources. IIRC both HDV and AVCHD.

Hope this helps.

Cheers,
David.

[Manao]

They use interlaced chroma. There's nothing clever you can do about this afterwards. You have to blur the chroma down to 1/4 resolution vertically to remove the problems.I don't think you have to do that. Firstly, PSF is a way to encode the video, it doesn't say anything about how the video was created, and especially how any subsampling was performed. It might vary from one camcorder to the other. The actual subsampling ought to be indicated by the ct_type field of pic_timing SEI (though how many camcorder fill that properly, I don't know)

Secondly, even if the subsampling was interlaced, you shouldn't do anything special. And if you need to resample the chroma (for a resize or a 422 conversion), imho you're better off resizing it as a progressive video.

[2Bdecided]

Manao,

You raise an interesting possibility - I'll see if it's that simple.

I've confirmed in the past that decent bobbers like TGMC do manage to reconstruct progressive-like quality chroma from true interlaced video, but I wouldn't use those on progressive-encoded-as-interlaced video, and "just treating it as progressive" didn't seem to solve the chroma woes last time I tried it.

Cheers,
David.

[roozhou]

@2Bdecided

Thanks. I read the article last year. Your conclusion should be true for HDV and AVCHD camcorders, but what about cameras like Sony NEX-5? The video is shot on a APS-C 14 megapixel CMOS first and downsampled to 1920x1080 4:2:0. Do you think Sony is still using interlaced subsampling on this?

[Mug Funky]

PsF was developed (hacked) for 4:2:2 systems, hence vertical subsampling wasn't really an issue.

i would think that if PsF were to be used in 4:2:0 consumer formats, the subsampling would depend on the codecs and hardware used. AVC could conceivably just carry an interlaced flag with progressive encoded blocks (is that how it works?). however with off-the-shelf codec chips, they could be expecting an interlaced picture and getting a progressive one off the imaging sensor. with HDV i'd think this is the case most of the time.

most (all?) professional formats that are 4:2:0 tend to have a true progressive mode which they can use to get around the ridiculous PsF kludge.

[2Bdecided]

Manao, you're right - just treating the interlaced chroma as if it's progressive seems to work fine for progressive sources encoded as interlaced. Far better than decoding as interlaced and then blurring to 1/4 resolution vertically!

If the chroma was originally sub-sampled progressively, you've lost nothing compared with true progressive yv12. If the chroma was originally sub-sampled using the interlaced sample points, you've lost half the resolution, but decoding progressively loses nothing more.

I think! Tested in AVIsynth. Would love someone else to confirm or deny this though.


I remember on a previous thread that someone suggested, even for true interlaced sources, adaptively switching between interlaced and progressive chroma decoding (and encoding, if that was under your control!) to keep maximum chroma resolution in still scenes. mcbob seems to achieve something like this, though I don't know if its programmed explicitly in there.

Cheers,
David.

[partyrabbit]

Maybe somebody know how work subsampling in Canon HV20\HV30 when it's in PsF mode? Thx.

[2Bdecided]

Just as I described above. I have an HV20.

Cheers,
David.

[WorBry]

Sorry to revive an old thread, but......

I have need to mix-edit some HDV 25 psf footage recorded on a Canon HV20 with some 'pseudo-progressive' 25p (Frame-mode a.k.a 'Procinema') DV footage that was recorded on an older Panasonic GS400 DV camcorder.

I had always decoded the 'frame mode' DV material (using Cedocida's codec) with the source YV12 chroma sub-sampling set to 'progressive', despite the fact that the camcorders CCD sensors are 'interlaced'. That advice came from quite a lengthy forum discussion on the subject some years back, although I still wonder if it is correct.

Now I need to convert the HDV 25 psf to PAL DV (25p576 anamorphic 16:9) for co-editing and am facing a similar consideration when it comes to configuring the Cedocida DV encoder. Do I set the source YV12 chroma sub-sampling as being 'progressive' or 'interlaced'?

Was the conclusion of this thread then to take David's advice and treat the chroma of the HDV psf as if it is progressive?

Manao, you're right - just treating the interlaced chroma as if it's progressive seems to work fine for progressive sources encoded as interlaced. Far better than decoding as interlaced and then blurring to 1/4 resolution vertically!

If the chroma was originally sub-sampled progressively, you've lost nothing compared with true progressive yv12. If the chroma was originally sub-sampled using the interlaced sample points, you've lost half the resolution, but decoding progressively loses nothing more.

I think! Tested in AVIsynth. Would love someone else to confirm or deny this though.


What's got me befuddled is that on decoding the HDV 25 psf, DGDecode reports it (from DGIndex) as interlaced (as flagged) and since Color Matrix (for Rec709 to 601 conversion) takes it's hints from that info, what will the YV12 chroma sampling output be? If it has any bearing, DGDecode reports the Colorimetry as ITU-R BT.709 (1) - does the (1) have significance in this context?

[Warperus]

WorBry
Do I set the source YV12 chroma sub-sampling as being 'progressive' or 'interlaced'?
I don't believe in treating as progressive is correct, but I do believe sometimes correct presentation doesn't give most appropriate result for the case. You'll resize picture, so I don't think it will be significant (if for interlaced you convert to YUY2 or otherwise create progressive-friendly chroma before resize). Either way your chroma resolution will be reduced, but resize probably should be done in progressive mode to not end up 576i after resize.
If I were you, I would load it as interlaced, convert to YUY2 (interlaced=true), then apply color matrix BT709->BT601, and then resize to 576p. But again, it's just my opinion.

Simple color matrix conversion can be done individually for each pixel. If you don't use dithering here, it doesn't matter if clip is progressive or interlaced.

ITU-R BT.709 (1) - does the (1) have significance in this context?
I don't think so. I suppose (1) refers specification ITU-R BT.709-1 published in 1993. Current published version available at their site is ITU-R BT.709-5. AFAIK colorimetry did not change. You can check it here youself:
http://www.itu.int/rec/R-REC-BT.709/en

[sneaker_ger]

I think the (1) might refer to the value in the MPEG2 headers. See the table at the bottom:
http://avisynth.nl/index.php/Colorimetry#DVD.2FMPEG-2

[TheSkiller]

In my experience and opinion it is absolutely correct always to treat the chroma of a "progressive segmented frame" the progressive way for upsampling. It doesn't seem to matter whether the chroma of a psf was originally downsampled to 4:2:0 the interlaced or progressive way (except for the fact, of course, the chroma definition would be better if it was downsampled in progressive fashion).

[WorBry]

Thanks for your replies.

Well, I can see the logic of converting to, and downsizing in, YUY2 if it is certain that the source HDV 25 PsF is/was recorded in an 'interlaced' 4:2:0 YV12 chroma format.

Assuming the Cedodida DV encoder converts MPEG2 YV12 to DV YV12 in the same manner as the decoder does the reverse.......

http://forum.doom9.org/showthread.php?p=860905#post860905
http://forum.doom9.org/showthread.php?t=103564

......this would involve sampling off a YUY2 intermediate. So, if YUY2 conversion is inevitable, in this context, it would seem logical to apply that before down-sizing. Does ColorMatrix also perform the YV12 Rec.709 to Rec.601 transformation at the RGB level via a YUY2 intermediate? I'm not sure. Anyone?

That said, if the original 25 PsF was recorded with 'progressive' YV12 sampling, that initial ConverttoYUY2 (interlaced = true) conversion would replace half of the 'actual' recorded chroma data with interpolated chroma, which can't be a good thing.

Granted, from what little information I've been able to glean, it does seem likely that Canon took an 'interlaced' chroma sampling approach to PsF in those earlier pro-consumer level HD cams:

Review of Canon HF11:

http://provideocoalition.com/awilt/story/review_canon_vixia_hf11_avchd_camcorder/P2

Quote: "In progressive...... Part of the problem with AVCHD, at least as recorded on the HF11, is that it's always recorded as interlaced, and thus shows interlaced 4:2:0 chroma"

Whether that has since changed in the current models, I'm not sure.

Based on Manao's earlier comment "The actual sub-sampling ought to be indicated by the ct_type field of pic_timing SEI", I've looked on-line for an MPEG/stream analyzer that might be able to reveal this information, but without luck. Elecard StreamEye (Trial version of course) doesn't do it.

Does anyone know of one?

Sorry, I know this is all 'old-hat' stuff for many.

BTW:

I think the (1) might refer to the value in the MPEG2 headers. See the table at the bottom:
http://avisynth.nl/index.php/Colorimetry#DVD.2FMPEG-2

Yes, I think you are right.

[2Bdecided]

I can shed no more light on this, other than to agree that I'd be amazed if you can see any difference after you've down-converted.

I'm surprised you're working in DV. I'd work in HDV and upscale the DV, but I know you're very clued up so I'm sure you have a good reason for working in DV.

Cheers,
David.

[poisondeathray]

Granted, from what little information I've been able to glean, it does seem likely that Canon took an 'interlaced' chroma sampling approach to PsF in those earlier pro-consumer level HD cams:

Review of Canon HF11:

http://provideocoalition.com/awilt/story/review_canon_vixia_hf11_avchd_camcorder/P2

Quote: "In progressive...... Part of the problem with AVCHD, at least as recorded on the HF11, is that it's always recorded as interlaced, and thus shows interlaced 4:2:0 chroma"

Whether that has since changed in the current models, I'm not sure.


Be careful about extrapolating that information ; HF11 was a CMOS sensor (progressive scan), but recordings were not native progressive (there was a "flag" that caused many software to upsample as interlaced, thus the artifacts)

Back then it was eventually determined that this was an issue with FCP (Adam Wilt used FCP for that review) using interlaced chroma upsampling on progressive samples (Premiere was known to have that issue at the time as well too) i.e. chroma upsampling error .

It has changed with newer AVCHD models that have native progressive CMOS sensors, and record to native progressive PN formats .

I agree with TheSkiller - It's better to treat "progressive" HDV as progressive . I've never seen the reverse producing better results . It's easy to test and confirm; Just do some quick tests on your footage, should only take few minutes . I'd be VERY surprised if you see anything contrary

[WorBry]

@2BDecided. Well I would agree - having tried both routes (as progressive and as interlaced via YUY2) I can't see any obvious difference in the DV encodes.

Only got the HV20 a couple of weeks back (local bargain on a used PAL model in good nick that I couldn't resist - a rare find here in Canada). So most of the accumulated 25p footage I have to edit is frame-mode DV from my old GS400, which, obviously, is more easily edited as DV. Plus the old folks at home (UK) still expect the obligatory DVD.

As for my being clued up. Perhaps more accurate to say "relentless in pursuit of tricks to make consumer level SD video look better" or used to be. HD is still new for me -only 5 years behind the times - story of my life. ;)

[WorBry]

I agree with TheSkiller - It's better to treat "progressive" HDV as progressive . I've never seen the reverse producing better results . It's easy to test and confirm; Just do some quick tests on your footage, should only take few minutes . I'd be VERY surprised if you see anything contrary

Thanks. I'll will be doing more tests at native HD resolution. Interesting about the explanation of the HF11 AVCHD artifacts.

[WorBry]

Actually, thinking about it, conversion to YUY2 is not a bad idea all round for mixed editing (on the same time-line) of the 25p DV and down-scaled HDV 25 PsF. The Cedodida decoder anyway gives the option to output as YUY2.

Edit the project in YUY2, as frame-based, and (smart) render out to HuffYuv-YUY2 (FFDShow vfw) or, for economy in file size, DVCPro50 (Cedodida's vfw implementation), the 4:2:2 DV variant. And use that as the master for conversion and encoding to MPEG2 (DVD), x264 or whatever.

I quite like that idea.