Proper cadence terminology for progressive-only rate downconversion?

[joema]

Cadence terminology typically envisions a rate upconversion, e.g, 24p to 30p. In that case it's denoted as 1:1:1:2, where each number represents the # of times a given 24p frame is shown in the converted 30p output.

What is the correct terminology for the opposite conversion, where frames are dropped, not duplicated? E.g, for 30p to 24p, would that be 1:1:1:1:0 ?

I'm investigating an NLE rate conforming problem and I just want to ensure I use the technically correct term.

[manono]

would that be 1:1:1:1:0 ?

Removing one duplicate frame in 5 will leave you with 1:1:1:1.

To do this (remove duplicate frames) you'd be better off using a decimate filter in AviSynth.

[joema]

Removing one duplicate frame in 5 will leave you with 1:1:1:1.

I thought 1:1:1:1 indicated each progressive frame was unique and not duplicated or dropped. In the Grass Valley documented "Understanding Cadence", on page 37 it says 1:1 cadence on progressive material signifies each frame is unique temporal event (no repeats). The example given on the next page was a 1:1 scan of 24 fps film to 24p video, which would also mean no drops: https://wwwapps.grassvalley.com/docs/Application_Notes/media_processing_conversion/alc...ng_Cadence.pdf

My question was if a 2 indicates a duplicate frame for the all-progressive case, what then signifies a dropped frame using similar cadence nomenclature?

...To do this (remove duplicate frames) you'd be better off using a decimate filter in AviSynth.

Yes, I understand that but in this case it's apparently a rate conforming bug in an existing NLE and as part of building various test cases I wanted to use the proper terminology.

[manono]

I thought 1:1:1:1 indicated each progressive frame was unique and not duplicated or dropped.

Once the dupe frame is removed, it's no longer 'duplicated or dropped'. I know nothing and care even less about what Grass Valley has to say about it.

[jagabo]

Your source is 1:1:1:2. You decimate back to 1:1:1:1 by discarding one frame (the duplicate) out of every five. The frame rate is reduced to 4/5 the source frame rate, e.g. 30p to 24p.

[Skiller]

As a side note, 24p to 30p cannot be done without creating either severe stuttering or motion interpolation artefacts. Going to 30i or 60p instead (using duplication) provides acceptable output.

[Selur]

As a side note, 24p to 30p cannot be done without creating either severe stuttering or motion interpolation artefacts. Going to 30i or 60p instead (using duplication) provides acceptable output.

I don't get that.
Wouldn't your use some bob deintelacer to go from 30i to 60p? Why would one ue some sort of duplication?
Also if duplication of frames doesn't bother you could also do frame duplication when going from 24p to 30p,....

[poisondeathray]

As a side note, 24p to 30p cannot be done without creating either severe stuttering or motion interpolation artefacts. Going to 30i or 60p instead (using duplication) provides acceptable output.

I don't get that.
Wouldn't your use some bob deintelacer to go from 30i to 60p? Why would one ue some sort of duplication?
Also if duplication of frames doesn't bother you could also do frame duplication when going from 24p to 30p,....

He's referring to the severity of the "jerkiness" in the cadence:

24p to 30i (or 60p) via repeats is just "regular" North American "Judder" cadence (3:2) eg. 24p on an old 60Hz display - It's "less jerky" than 24p to 30p via repeats





The OP is asking about 30p source to 24p notation via decimation. I don't think there is an "official" one. 1:1:1:1:0 would make sense, but I've never seen it written like that. I've seen it written as ABCDF before.

[joema]

...The OP is asking about 30p source to 24p notation via decimation. I don't think there is an "official" one. 1:1:1:1:0 would make sense, but I've never seen it written like that. I've seen it written as ABCDF before.

Thanks that is exactly what I was looking for. I agree it's less confusing for each test case to use alphabetic input/output notation, e.g, 30p to 24p would be ABCDE to ABCE and 24p to 30p would be ABCDE to ABCDD. Software that performs incorrect rate conversions can be unambiguously described that way. In hindsight that is obvious but I thought maybe there was some cadence nomenclature I wasn't aware of. You helped me to see there isn't.

I'm working on various test cases for a widely-deployed NLE that in some narrow conditions doesn't handle progressive-to-progressive rate conforming correctly. There are already established ingest and transcoding workflows at many sites, so they can't just use some other software. My task is is to define the problem boundaries, workarounds, test cases and the actual vs expected behavior of each problematic rate conversion. Using the ABCDE notation seems the best way to describe those.

[Cornucopia]

Letter notation is also helpful if you work with interlaced material (either input or output), as you can use uppercase vs lowercase. E.g. AaBbBcCdDd (std 2:3 pulldown for Film to NTSC telecine).


Scott

[jagabo]

AaBbBcCdDd

And that's usually the source of the 1-in-5 repeat sequence because when it's deinterlaced you're left with ABBCD.

[Cornucopia]

AaBbBcCdDd

And that's usually the source of the 1-in-5 repeat sequence because when it's deinterlaced you're left with ABBCD.

Yes, but one shouldn't do simple deinterlace on that anyway. An IVTC is what's appropriate - then you'd be left with the original ABCD (or AABBCCDD?) if progressive, or AaBbCcDd if wanting to retain interlacing (but who would?).


Scott

[jagabo]

AaBbBcCdDd

And that's usually the source of the 1-in-5 repeat sequence because when it's deinterlaced you're left with ABBCD.

Yes, but one shouldn't do simple deinterlace on that anyway.

Of course not. But it's done quite often. Especially in streaming video settings.