NTSC <---> PAL conversion during encoding?

[Titanium48]

I had a (possibly very silly) idea that an MPEG encoder might be able to do NTSC <--> PAL framerate conversions during encoding. Consider the same event recorded in NTSC and PAL. Every 6th NTSC frame will represent the same instant in time as every 5th PAL frame.
NTSC - F F F F F F F
PAL - F F F F F F
-An ideal standards converter would pass the aligned frames (black) through unchanged, while interpolating the others (blue) in a way that preserves detail while maintaining smooth motion.
-An MPEG encoder calculates motion vectors to help predict the contents of non I-frames to reduce the amount of data that must be stored.

The idea is to use these motion vectors to help predict the "blue" frames. For moving objects, the process would be much like changing the sample rate of an audio stream - The input frames (samples) are used to construct motion vectors (analog waveform) which are then sampled at a different rate, generating output frames (samples) representing different points in time than the input frames. Detail would be preserved for stationary and slow moving objects, while motion would still appear fluid.

The encoder would analyse the input in the usual fashion, encoding every second or third aligned frame as an I-frame and the remainder of the aligned frames as P-frames. The remaining (non-aligned) frames could then be encoded as B-frames.

Is this a very silly idea or might it work?

[video]

please look in the topic "Pulldown of 25 fps to NTSC". DGPulldown may exactly does what you are looking for.

[Titanium48]

DGpulldown is probably the best method of converting a progressive PAL source to NTSC, however interlaced PAL must first be deinterlaced, and pulldown methods can only increase the framerate, not reduce it. An encoder based interpolation/"resampling" method would be able to do the conversion in either direction, progressive or interlaced. Results may even be better for framerate reductions as there is more information in the source.

Interlaced conversions would still contain some slightly uneven motion as fields encoded in the same frame would still represent the same time point relative to each other (1/60 seconds apart for NTSC source, 1/50 for PAL) and timing adjustments would be made between sucessive fields in different frames. The unevenness would however be much smaller in magnitude and higher in frequency than that produced by the field decimation or duplication used in conversion methods beginning with a (smart)bob filter.

Basically, I thought this was an interesting idea but I don't know enough about the inner workings of MPEG encoders to know if the internally generated motion vectors can be used in this fashion.

[scharfis_brain]

With avisynth it is possible to do standards conversions 'during' encoding.

with mvbob() & mvfpsscd() they are becoming of very high quality at the cost of exessive CPU usage.

for interlaced stuff, deinterlacing is ALWAYS required.
No way around this!

Canopus Procoder includes an internal standards conversion.
But I don't like it, because it is simple blending :rolleyes:

I prefer motion compensated framerate changes, or speedchanges.
But blending is evil...

[Titanium48]

Originally posted by scharfis_brain

with mvbob() & mvfpsscd() they are becoming of very high quality at the cost of exessive CPU usage.

Exactly. mvbob() and mvfpsscd() use motion vectors to interpolate frames, then the encoder calculates motion vectors again during compression. If these two processes could be integrated, significant time savings (and perhaps quality improvements) could result.

[scharfis_brain]

No. this won't be possible.

The motion vectors from mvbob & mvfps are 60 fps vectors, while the vectors needed for MPEG must be calculated from the converted 50 fps. (NTSC -> PAL)

recalculating motionvectors between 60<->50 fps would be a big pain I assume, because the blocks to match on won't be valid anymore.
The vectors need to be calculated again for MPEG encoding.

also MPEG-vectors are different from mvtools-vectors!
MPEG-vectors are calculated to achieve best possible compression.

mvtolls vectors are calculated to achieve most 'peasant' images.

[video]

Titanium48 sorry i supposed progressive.