Re: Analogue artifact estimation

> > Reverse 3-2 pulldown looks fairly straightward, but there is the
> > problem of working out which fields go together to make the original
> > frames.

> It is seldom the case that there is "one" correct frame order for 
> inverse telecining. The reason is that most video sequences are spliced 
> together from many sources, often after they have already been converted 
> to ~30 fps. So the frame order changes, and there may be no proper way 
> to compensate for it, since depending on where the change occurs, some 
> fields may be completely missing, etc. Another fun factor is that CG 
> sequences that are originally rendered at ~30 fps are becoming more 
> common. They cannot be ivtc'd at all, and are stuck in the middle of 
> what is otherwise a ~24 fps source.

Good point.

> This is the reason that, to my knowledge, there are no good automatic 
> ivtc filters, though there are certainly a number which will work except 
> for the ugly cases listed above.

I heard of one hardware device that implemented an, (I assume), automatic ivtc, the name escapes me at the moment, but I vaguely remember hearing that it was used to make a progressive scanned version of Star Trek or some other SF series?  (Maybe I am well off course here, it's just something I read about about 12 months ago).

But, maybe a perfect ivtc filter is not necessary.  Even if 1 in 10 scenes could be processed successfully by a simple filter, it would be worth implementing.  The parts that can't are just ignored, and treated as 30 fps video, with the variable framerate solution.

> But, I agree, all these ideas are pre-processing stages, and should be 
> relatively independent of whatever codec is then used to compress the 
> "corrected" video sequence.

In any case, we should absolutely avoid compressing a frame which is made up from two completely separate fields.  It would be better to make two frames by assembling each field with a blank field or a duplicate of the lines from the first field, and compressing those.  That should cause less visible artifacts with practically any codec.  On decompression, you just re-create the single frame with fields from two different sources.

> The only real question, to me, is whether or not the codec can handle a 
> variable framerate. This might provide a simple solution for the CG 
> sequence problem. I doubt that it would be that difficult to make a 
> codec do so, given the proper support from whatever muxer is being used.

Definitely a variable framerate would give us the option of doing this:

* IVTC where possible to reduce datastream from 30 fps to 24 fps
* Where that's not possible, (silly editing, or 30 fps CG sequence), leave it at 30 fps
* Compress the resulting sequence.

Also by implementing variable frame rates you could, for cartoons, drop frames where they're repeated, (I.E. nothing is moving), but that creates a strange visual effect, because even on 'identical' frames, you expect to see some noise changing from frame to frame.  If you just repeat a frame, it looks really odd.

In other words, you might have 10 frames of somebody talking, then 4 or 5 frames that are just the same thing exposed on to 4 or 5 consecutive frames, (happens a lot in Anime, usually just before/after a sweatdrop appears :-) ).  In that case the noise will be different on each frame, and if you just repeat one of them, it just jumps out at you and screams, 'dropped frame!'.

John.
--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to '[email protected]'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.