Trying to deinterlace but the field order changes randomly?

[xAlienxx]

Hi, I wanted to include the behind-the-scenes from one of my DVDs on my tablet and it has interlacing so I wanted to deinterlace it and keep the motion by bobbing it.

Tried yadif and bwdif, I don't need extreme high quality for these clips, just want the motion to be correct and save space.

I use ffmpeg to encode, these are my settings:

ffmpeg -i "%%~A" -vf bwdif=1:1,setdar=4/3 -vcodec libx264 -profile:v high -level:v 3.1 -crf 22 -refs 4 -me_method umh -subq 10 -me_range 24 -g 240 -keyint_min 25 -sc_threshold 0 -mixed-refs 1 -rc-lookahead 48 -qcomp 0.50 -qmin 6 -qmax 51 -pix_fmt yuv420p -x264opts "stitchable:vbv-maxrate=14000:vbv-bufsize=14000" -codec:a copy -codec:s copy "%%~A_tab.mkv"

If I play the sample in VLC using the simple bob deinterlacer it works correctly all the way BUT in ffmpeg if I use automatic field order (yadif=1:-1) the first scene has bad motion, and if I force bff the first scene looks smooth but not the last...

So it switches field order? Is what I think, but why does "-1" not work correctly? VLC doesn't seem to have this problem.

Any tips would be greatly appreciated. I fixed this one manually by splitting and stitching them but I don't wanna do a bunch of encodes, transfer them, and then find that some have bad motion. I thought field order was stored on the file?

I used mpg2cut2 for the sample and dvddecrypter to grab the vob files.

[ProWo]

Your sample is progressive encoded, so you have to use the send frame switch, not the send field switch.
Working yadif here: yadif=0:-1:0

[Sharc]

Your source is a mix of interlaced video (interviews) and telecined movie (movie part), progressive scan.

When bobbing:
Frame 0 to 3 there is a field swap or orphaned field (maybe due to a glitch which was caused by your cut?), then it is bottom field first interlaced video up to frame 322. Frame 323 to 818 are telecined, frame 819 to the end are again Bottom Field First interlaced video.

[Sharc]

Your sample is progressive encoded, so you have to use the send frame switch, not the send field switch.
Working yadif here: yadif=0:-1:0

This doesn't keep the motion smoothness as requested by the OP for bobbing. It is (blurry) single rate deinterlacing, and the telecined part is jerky.

[ProWo]

Your sample is progressive encoded, so you have to use the send frame switch, not the send field switch.
Working yadif here: yadif=0:-1:0

This doesn't keep the motion as requested by the OP. It is (blurry) single rate deinterlacing.

The OP: I don't need extreme high quality for these clips, just want the motion to be correct and save space
the motion is absolutely fine for me (controlled step by step with virtualdub2).

[Sharc]

Your sample is progressive encoded, so you have to use the send frame switch, not the send field switch.
Working yadif here: yadif=0:-1:0

This doesn't keep the motion as requested by the OP. It is (blurry) single rate deinterlacing.

The OP: I don't need extreme high quality for these clips, just want the motion to be correct and save space
the motion is absolutely fine for me (controlled step by step with virtualdub2).

OK. Let the OP decide on his conflicting requirements

Edit: I tried this, but it doesn't properly solve the issue either. Something is weird.

ffmpeg.exe -i "%~1" -c:a:0 copy -c:v:0 libx264 -preset slow -crf 22 -filter:v:0 "fieldmatch=order=bff, bwdif=mode=1, format=yuv420p" "%~1_bwdif.mp4"

[jagabo]

Mpeg2Source("rush1samp.d2v") # honor pulldown flags
BWDIF(field=2)

[Sharc]

Yes, in avisynth this worked as well here:

MPEG2Source("D:\Temp\xAlienxx\rush1samp.d2v", cpu=0)
assumeBFF()
BWDIF(field=2)

But I couldn't make it in ffmpeg...... Maybe something weird with the source filter?

[jagabo]

Try:

ffmpeg -i rush1samp.mpg -vf bwdif=mode=1:parity=1:deint=0 output.mkv

[Sharc]

Still the same weird behaviour: part1 is ok, telecined part is ok, 3rd part jumping back and forth. An issue with the source filter/decoder in ffmpeg?

[jagabo]

Oh, you're right. Since it worked in VirtualDub I assumed it would work in ffmpeg. I only examined the first and second parts from ffmpeg before posting. But the third part has the field order backward. I may have time to look into it more later.

[Selur]

No clue how to tackle such mixed content with ffmpeg.

From the looks of it:

• 1st interview is interlaced bff
• movie part is telecined
• 2nd interview is interlaced tff

In Vapoursynth/Avisynth one could:
1st apply TIVTC with TDecminate in mode 7 and rate=29.97 (to handle the field switching)
2nd apply QTGMC with InputType2 (to get rid of residual combing)
and
optionally 3rd use FillDrops (to interpolate the duplicate frames, in case there are some)

Cu Selur

[Sharc]

I think the results of post#7 and post#8 are resonable. Both interviews are correctly bobbed, no field reversal jumps. The telecined part has the 2:3 pattern which is not too annoying as it is played at 59.94fps. NTSC folks are used to it, I think.

[jagabo]

Using ffVideoSource() in AviSynth results in the same change of field order as when using ffmpeg CLI. But LWlibavVideoSource() results in the the whole clip being BFF, like Mpeg2Source(). So I think there's just something odd about the way ffmpeg deals with the source.

Is there a way to force ffmpeg to use a different source filter internally?

[poisondeathray]

Using ffVideoSource() in AviSynth results in the same change of field order as when using ffmpeg CLI. But LWlibavVideoSource() results in the the whole clip being BFF, like Mpeg2Source(). So I think there's just something odd about the way ffmpeg deals with the source.

Is there a way to force ffmpeg to use a different source filter internally?

Yes, -c:v as an input option ; eg. for nvidia cuvid hw decode it would be -c:v mpeg2_cuvid . But it results in same problem at the end of the sample clip.

eg.

ffmpeg -c:v mpeg2_cuvid -i rush1samp.MPG  ...

qsv mpeg2 decode also has the issue in ffmpeg

ffmpeg -c:v mpeg2_qsv -i rush1samp.MPG  ...

Yet, cuvid for DGDecNV, or cuvid for LWLibavVideoSource works ok in avisynth, so that suggests it's not strictly a decoder issue , but maybe some implementation issue of a specific decoder, or something else is wrong in ffmpeg land

Forcing field order with -vf setfield=bff does not work either for the end of the clip

[Selur]

Sounds like an issue with the headers, maybe remuxing helps,...

[Sharc]

This seems to work here, using Nvidia cuvid mpeg2 decoding:

ffmpeg.exe -c:v mpeg2_cuvid -i "%~1" -c:a:0 copy -c:v:0 libx264 -preset fast -crf 22 -vf bwdif=mode=1 "%~1_bwdif.mkv"

With the .mkv container the telecined part is decoded as a 2:2 pattern though.


With the .mp4 container, the telecined parts is a 3:2 pattern

ffmpeg.exe -c:v mpeg2_cuvid -i "%~1" -c:a:0 copy -c:v:0 libx264 -preset fast -crf 22 -vf bwdif=mode=1 "%~1_bwdif.mp4"

[Selur]

Here's an example of tivtc+qtgmc+vinverse2+filldrops

Cu Selur

[poisondeathray]

This seems to work here, using Nvidia cuvid mpeg2 decoding:

In my earlier test, I forced "bff" using bwdif=1:1 , and that caused issue with end section. Looks like using default bwdif settings(send field with auto parity is default setting) works with cuvid decoding in ffmpeg

but "forcing" bff in bwdif avisynth , with cuvid decoding works ok bwdif (field=2)

[Sharc]

The issue can also be solved by changing the Picture Coding Extension flag of the rush1samp.mpg source from progressive to interlaced. This can be done with the ReStream for example (maybe it can be done with ffmpeg as well?). MediaInfo then reports the Scan type as Interlaced rather than Progressive, and everything behaves as expected.

Edit: Not quite ..... Both interlaced interviews are ok, but it fails with the telecined section which becomes 2:2 instead of 2:3 (-> audio desync)

[xAlienxx]

Wow, lots of info here, thank you all! I like the idea of using mpeg2_cuvid in order to keep the ffmpeg setup, but my work PC doesn't support it.

I wanted to avoid Avisynth because it's like starting over but posts 7th and 8th do provide the result I want, so if I still can't get it working with ffmpeg I'll go this route.

[Sharc]

I like the idea of using mpeg2_cuvid in order to keep the ffmpeg setup, but my work PC doesn't support it.

You would need a Nvidia graphics card for -c:v mpeg2_cuvid to work.
For Intel graphics the decoder would be -c:v mpeg2_qsv, but unfortunately this doesn't solve the problem here.

[jagabo]

I wanted to avoid Avisynth because it's like starting over but posts 7th and 8th do provide the result I want, so if I still can't get it working with ffmpeg I'll go this route.

Mpeg2Source() requires that you first use DgIndex to build an index file, then the MPEG2 video is accessed via that file. You'll need to add the DGDecode package for those filters. I have a batch file that builds the index and creates a basic AVS script for me. I put it in my SendTo folder -- so I can right click on an MPG file and select Send To -> AVS_Mpeg2source.bat.

As I mentioned earlier, LWlibavVideoSource() was also able to deal with the sample. It builds an index file when you call it so you don't need the extra step. You'll need to add the LSMASH source package to the basic AviSynth install.

And ffmpeg accepts AviSynth scripts as input so you can continue to do the rest of your processing there if you want.

[Sharc]

As I mentioned earlier, LWlibavVideoSource() was also able to deal with the sample. It builds an index file when you call it so you don't need the extra step. You'll need to add the LSMASH source package to the basic AviSynth install.

LWLibavVideoSource works here with yadif(mode=1) but fails with BWDif(field=2) - unless I am missing something.
Btw I noticed that there is a pattern glitch in the telecined section.

[jagabo]

LWLibavVideoSource...fails with BWDif(field=2)

I just checked again. It works fine here.

LWLibavVideoSource("rush1samp.MPG", cache=false)
BWDIF(field=2)

[Sharc]

LWLibavVideoSource...fails with BWDif(field=2)

I just checked again. It works fine here.

LWLibavVideoSource("rush1samp.MPG", cache=false)
BWDIF(field=2)

Thanks. Updating the LSMASH package helped.