repeted framed

[B-Frame]

My first post here, although I do have a few of years experience with vid editing.

I have obtained some footage (xvid in avi container) that runs at 29.97fps. I know the original footage was recorded at 25fps (PAL) as its a British TV show. The fps increase has been achieved simply by replicating every 5th frame, and rewriting the frame timings. The transcoder was lavf52 v13. (I guess it must be an industry standard way of changing the fps!!) I can step through the footage frame-by-frame and frame replication is certainly how the fps was changed.

I can undo the first 18sec of damage by using the ffmpeg vid filter select='mod(n,6)', giving the original 25fps, and with perfect play back. For the next 20secs of footage the damage is fixed with 'mod(n-3,6)'. Every 5th frame is replicated but the reference frame seems to change randomly every 20secs or so. In other words, mod(n-offset,6) works but the value of offset changes randomly every 10-20 seconds.

I have tried the ITCV filter in avidemux (fast and noise=3) but it worked poorly..

Can the footage be fixed?

[Selur]

avisynth with sRestore/restore24/dedup would probably do a better job
(sRestore is also available under Vapoursynth)

[jagabo]

In converting 25 fps to 29.97 fps every 5th frame is duplicated, except every 1000 frames (to account for the difference between 30 fps and 29.97 fps). (There are other ways of converting frame rate but this appears to be what you have.)

TDecimate(Cycle=6, CycleR=1) (removes one duplicate in every six frames and adjusts to change in cadence) in AviSynth will get you 24.975 fps -- you may not notice the missing frame every 1000 frames. You can follow with AssumeFPS(25) to force the rate to 25 fps but the frame will still be missing, and the running time will be 0.1 percent faster. ChangeFPS(25) will get you the same running time but will introduce one duplicate frame every 1000 frames.

TDecimate(mode=2, rate=25) will give exactly 25 fps and may avoid the problem with the missing frame.

[johnmeyer]

Yes, the usual way to deal with this, if it is only repeated frames (or repeated fields, which is more common with interlaced footage), is to use TFM() followed by TDecimate. The process is known as "inverse telecine (IVTC)" or "pulldown removal." It is very straigntforward, and these two AVISynth functions (both part of the TIVTC package) work remarkably well.

If you have blended fields, then you need to look into using SRestore.

[manono]

I guess it must be an industry standard way of changing the fps!!

No. Rarely do the professionals repeat frames for their standards conversions because of the simple fact it makes the result play stuttery/jerky. Of the several thousand such conversions I've seen, maybe only two or three did it by repeating frames.

As mentioned, an AviSynth decimate filter such as TDecimate (or Decimate from the Decomb IVTC) is the (only?) proper way to undo the damage.

[B-Frame]

I guess it must be an industry standard way of changing the fps!!

No. Rarely do the professionals repeat frames...

Yes, any footage with 16% repeated frames is unwatchable. While it wasn't a professional changing the fps, it makes you wonder about the honesty of some software authors.

Thanks for the good answers, and Ill give TDecimate a go first, when I've read up on it. I suspected there was a second modulo operation going on, which updates every 16.666secs. (Read up on modulo arithmetic in Uspensky & Heaslet

The footage is recent from HD TV, and does not appear to be interlaced. Stepping through frames it does seem that 5 and 6 are identical, and no blending has occurred. I could also try using lavf52 (v13) on PAL footage to if that is what it really does.

P.S. Manono is a small atoll in Western Samoa, which I have been to. A bit like the Sicily of polynesia. Do you come from there?

[B-Frame]

I tried a few combinations with TDecimate and got some very acceptable footage.
TDecimate(mode=1, Cycle=6, CycleR=1)
This worked fine and left the fps at 29.97. The deleted frame was replaced by a blended frame, but over 30mins there were 3 or 4 jumps.
TDecimate(mode=1, Cycle=7, CycleR=1)
This worked better still, and I didn't see any jumps at all.

Cycle=7 did seem to fix it. If there are remaining glitches then they are few and far between. There's no doubt that I could make the fps 25, but it's all fixed and my TV plays all PAL and ATSC footage.

Thanks to all contributors.

[B-Frame]

Just using SRestore() without any parameters, as suggested by Selur, without any reference to 25fps to 29.97 does just as good a job as the above.

I can drop the blended frames later to get back to 25fps.

[jagabo]

If you have blended frames use SRestore. SRestore preferentially deletes blended frames, then duplicate frames, then unique frames if you ask for too low a frame rate. TDecimate() deletes duplicate frames, then unique frames if you ask for too low a frame rate -- generally, don't use it for blended material. For telecined NTSC material that's been blend deinterlaced (typically 29.97 fps, with 3 clean frames 2 blended frames, pattern repeating) use FixBlendIVTC().

Also, be careful when evaluating SRestore. It sometimes takes a while for the algorithm to settle down. Don't count on being able to simply seek to a random point in a video and find it working properly. Seek to a few seconds before the section you want to check then step through frame by frame.

With field blending you need to double-frame-rate deinterlace before SRestore. Use Yafid(mode=1) or QTGMC(). Then SRestore.

All all these filters have many settings you can use to fine tune.

[B-Frame]

The last 40s of the problem clip can be found at
https://drive.google.com/open?id=0B-GU6hSMjoTfNjg1aV9LbDVNN1k

I've gotten it to play reasonably well, although the end creds are still a bit jumpy. I rarely deal with 29.97fps, and so I have little experience with avisynth. No need to.
I live in PAL land and all fps changes are done just by changing the replay speed. With h264 in an MKV container it's trivial using mkvmerge. Set the vid speed to 25fps or film, and stretch/shrink the audio by 25025/24000.

With the advent of LCD screens there's no need at all for 29.97fps. All footage should go in exact multiples of 25fps prgressive.

ATSC adopted the old 29.97fps to allow DTV transmissions to be viewed in jet aircraft. It allowed the DTV carrier frequency to be increased just enough so that the Doppler shift did not exceed the q-modulation error limits ... so the story goes. DTV in Europe will tolerate a Doppler shift caused by speeds only up to 300 km/hr.

[johnmeyer]

I really don't think Cycle=7 is the right thing for this clip, but then again I don't have the entire movie. On your clip, this very standard script worked perfectly:

tfm(display=false) 
tdecimate(display=false,mode=0,cycleR=1,cycle=6)
AssumeFPS(23.976)

[jagabo]

In theory, TDecimate(Cycle=1001, CycleR=166) is probably right for the clip -- it delivers exactly 25 fps. But TDecimate() will not work well with such long segments, especially since parts of it contain still frames. Ie, TDecimate can't differentiate duplicates in a still shot and those from the frame rate conversion.

[johnmeyer]

In theory, TDecimate(Cycle=1001, CycleR=166) is probably right for the clip -- it delivers exactly 25 fps. But TDecimate() will not work well with such long segments, especially since parts of it contain still frames. Ie, TDecimate can't differentiate duplicates in a still shot and those from the frame rate conversion.

It should work, but it will be slow, and it will be extremely sluggish if you attempt to do any random access while examining the results in Virtualdub (or other AVISynth script reader).

I just checked all my old scripts, and the largest cycle I ever used was 68, and that did make things pretty slow. I would expect that 1001 would take at least a minute for the script to generate the first frame, and that amount of time again, should you try to jump ahead. However, once the script is running, it might not be too bad.

[manono]

I live in PAL land and all fps changes are done just by changing the replay speed.

Some are done that way. The majority, even, but by no means all.

With the advent of LCD screens there's no need at all for 29.97fps. All footage should go in exact multiples of 25fps prgressive.

All footage should be shown at the intended original framerate. If 25fps, then 25fps. If 24fps, then 24fps.

TDecimate can do that sample perfectly to 24.975fps following the TDecimate line in johnmeyer's script. You can achieve a perfect 25fps for the sample using:

TDecimate(Mode=2,Rate=25,m2pa=true)

[jagabo]

TDecimate can do that sample perfectly to 24.975fps following the TDecimate line in johnmeyer's script.

I get one missing frame between frames 769 and 770. Those are frame numbers in the resulting file, not the source.

[B-Frame]

After some more experimenting I find there are some transmission glitches (not in the 40s sample) that upset the TDecimate and Srestore processing. If you try srestore() with not settings on the 40s sample and output to mpg at 25fps it works fine. There are no blended frames that I can see, or they may be few and far between. My older version of avidemux had some bugs in the m4v2 container processing, too. Now I find that avisynth 2.5 may also have had a bug in the srestore function. After update everything the srestore() now works well.

My problem is solved. There are still glitches after TDecimate/Srestore but these are transmission glitches; about 3 per 30mins.

============================
I can very easily live with slightly altered playback speeds. Converting to 29.97fps always involves some kind of interlacing and blending butchery that makes images fuzzier. Going from NTSC to PAL does not usually give good results, but in my case it was easy.

Thanks To All.

[manono]

I get one missing frame between frames 769 and 770.

Oh yeah, you're right. I must not have checked it far enough and shouldn't have claimed a 'perfect' IVTC. Maybe that's evidence of the one dropped frame in every 1001 if it's really supposed to be 25fps.

The other script seems to work okay (unless you find another abnormality).

[jagabo]

The other script seems to work okay (unless you find another abnormality).

You mean TDecimate(Mode=2,Rate=25,m2pa=true)? I didn't notice any problems in that one.

[jagabo]

TDecimate(mode=1, Cycle=6, CycleR=1)
This worked fine and left the fps at 29.97. The deleted frame was replaced by a blended frame

That would leave you with 24.975 fps and since your source has no blended frames netiher can the output. If you are getting 29.97 fps and blended frames it's from something else you are doing.

TDecimate(mode=1, Cycle=7, CycleR=1)
This worked better still, and I didn't see any jumps at all.

This is not possible. The output will be 25.689 fps and there will be duplicate frames left in the video. About every 36 frames.

[manono]

You mean TDecimate(Mode=2,Rate=25,m2pa=true)?

Yes, that one. I thought your script should work as well, but it didn't. Even after I added the M2pa=true and a maxndl setting, it still didn't work out just right although on the complete video or a much longer sample, maybe it would have performed better. Back during my silent movie days with sometimes very long and complex cycles, I used cycles of several hundred frames and the scripts worked fine.

This is not possible. The output will be 25.689 fps...

I didn't know what to make of those statements either, so I ignored them. Let's hope he didn't use the Cycle=7 one for the final encode.

[B-Frame]

That would leave you with 24.975 fps and since your source has no blended frames netiher can the output. If you are getting 29.97 fps and blended frames it's from something else you are doing.

Yep , I was. I had forgotten to clear a previous ffmpeg script in Avanti-gui, which was getting at the footage first. SRestore() was actually doing nothing at all. I tried ffmpeg with the the video filter "-vf mpdecimate" and set the out fps to 25.0 Worked fine. In the entire footage, the increased fps change (25.00 to 29.97) was always effected by copying one frame in succession. mpdecimate simply kills the second of identical successive frames but only so much as to get the desired out frame rate. Long sequences of the same frame do no all get deleted, ie. the 2secs of "WHITES" in the end credits.

[B-Frame]

PS: the ffmpeg filter -vf mpdecimate fixed all 3 hours of this show. It may not be frame perfect to the original footage, but it's pretty damn close.

If you want the original broken footage; it's the *only* 'WHITES 2010' on a certain proxy-bay.