Wanted: Any Whitepapers on NTSC-PAL converter boxes?

[Didée]

Help!

I tried to find any documentation about converter boxes that are used to convert NTSC streams to PAL, but couldn't find anything.
Does anyone know useful links? Would be appreciated VERY much, really!

Background:

I'm still not yet done (!) with my Restore24 (http://forum.doom9.org/showthread.php?s=&threadid=61792&highlight=Restore24) script.
I got stuck when I started implementing sort of a pattern guidance into it.
I figured what kind kind of pattern _should_ occur during/after the conversion - that's not too hard. But I found that the patterns I find in real-world streams actually are "jittering" around what should _mathematically_ be there. And that's not good for the restoration process, no no ...

So, if there is any documentation out there, I'd be very curious to get my fingers on them ;)

- Didée

[scharfis_brain]

I cannot help with a whitepaper but maybe with the pattern.

As you maybe have seen, I've made a function called unblendpattern ( http://forum.doom9.org/showthread.php?s=&threadid=66093& ).
It works on every Fieldblended Stream until the pattern-offset changes (due to cuts etc.). This function works blind, meaning it does not look at the frames.

The pattern is mathematically everytime the same!
No matter what framerate is blended into our 50half-fps-Stream.
It is always
T [...] T B [...] B T [...] T B [...] B T [...] T B [...] B

T = Topfield
B = Bottomfield
[...] = x times repoeated depending on framerate of original-stream

btw. the amount of blending is different from converter to converter.

The new ET-Episodes were made using a converter that only blends the fields, if the temporal difference between PAL and NTSC - fields are too high. (PAL-field is in the middle of two NTSC-fields) otherwise, the PAL-field is not blended (nearest NTSC-field is chosen)

Other convertes does no have a blending threshold like the ET-converter... There every PAL-field is blended out of two NTSC-fields even if it is only a 1:10 blend.

[Didée]

Originally posted by scharfis_brain
I cannot help with a whitepaper but maybe with the pattern.

Oh, that would be so great

As you maybe have seen, I've made a function called unblendpattern

Of course, I have seen that.

It works on every Fieldblended Stream until the pattern-offset changes (due to cuts etc.). This function works blind, meaning it does not look at the frames.

The pattern is mathematically everytime the same!
No matter what framerate is blended into our 50half-fps-Stream.
It is always
T [...] T B [...] B T [...] T B [...] B T [...] T B [...] B

T = Topfield
B = Bottomfield
[...] = x times repoeated depending on framerate of original-stream

Here the problems begin. Let's start with the post ;)

Fact is, that the blending alternates in sequences of top-fields, bottom-fields, top ... etc.
Now generally, in 1 second of PAL video the pattern changes 4 times: 12-13 blends in T, 12-13 blends in B, 12-13 in T, 12-13 in B.
At every 2nd change, there is an marquant point which can be detected. That means, this point occurs mostly after each 25 fields.
But this very "point" sometimes occurs already after 21 fields. This is OK, since that is part of the framerate reduction process.

Now, to the "pattern":
It _should_ be something like [6*25] [21] [6*25] [21] [5*25] [21] [6*25] [21]
(these are the 'distances' between the 'short sequences')

The above is actually not completely correct (I'm a little out of the game for a few weeks now, and must look up my notices), but it gives the idea.
But, generally, the needed reduction should be achieved with only [6*25] distances (mostly), and [5*25] distances (a few).

Now, what actually is to be found (in those new Enterprise ep's), is all kind of distances:

- sometimes the mentioned [6*25] + [5*25] distances
- quite often also [8*25] + [3*25] distances
- sometimes [7*25] + [??*25] distances

Plus, to make things even harder, the following happens throughout the whole stream:

In places where a sequence of plain [25] distances should occur, this sequence is disturbed by [29] [21] or [21] [29] or [29] [25] [21] or ... :devil:

That is the hard part: these 'replacements' of [25] [25] with [29] [21] are *not predictable* - at least I fail to do so.
But, it is important to reckognize them: if a [21] distance of such a 'replacement' is taken for a 'real' [21] distance (one that actually shifts the fieldcount), the algorithm goes goofy very fast ...

(It's really not that easy for me to explain that with only words!)
Hence my search for more information.


Scharfi, let me put it this way, through a question:

Did you try to convert one of those Enterprise episodes with your script?

- If yes, did you succeed? Honestly, I cannot imagine that your script & method works on that particular stuff - it's too irregular. (But I would be AMAZED if it should work!)

- If no: today is another good time to grab an episode ;)


- Didée