AssumeTFF/BFF doesn't change field order

[LilWiz]

Hi everyone

I'm attempting to use QTGMC to deinterlace a 1080i 25fps mkv file for me. Here was my initial script:

LWLibavVideoSource("x:\20161210-WAT-EVE-EPL_1-1080.mkv")
a = LWLibavAudioSource("x:\20161210-WAT-EVE-EPL_1-1080.mkv")
AssumeTFF()
QTGMC(Preset="Slow")
AudioDub(last, a)

Opening in VirtualDub shows that it managed to only process 20 frames. As a result I used tsMuxer to convert to ts. Both of these files play flawlessly in VLC so there is nothing wrong with the clip itself.

Here's some info on the video:

Video
ID : 4113 (0x1011)
Menu ID : 1 (0x1)
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4
Format settings, CABAC : Yes
Format settings, ReFrames : 2 frames
Format settings, GOP : M=2, N=12
Codec ID : 27
Duration : 52 min
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate : 25.000 FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Interlaced
Scan type, store method : Separated fields
Scan order : Top Field First
Color range : Limited
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709

When I attempt to open this clip in VirtualDub using the same script (with ts instead of mkv to open the new file) the whole video stream is processed and deinterlaced but the frames are out of order. If the deinterlaced 50fps video should have frames a b c d e f ... then the VirtualDub preview shows b a d c f e ...

Normally I run into this issue and I can simply change AssumeTFF() to AssumeBFF() in my script, but in this case it has no affect.

Hopefully I've explained my situation well; I'm still a beginner. Does anyone have some suggestions as to how I might manually adjust field/frame order? I've tried a few things that I've found online (SwapFields() and various VirtualDub plugins) but I either haven't implemented them correctly or they aren't appropriate for what I'm trying to achieve. Thank you!

[ndjamena]

Separated fields

Have you tried trimming the first field off?... I know having an extra field hanging around can cause something that looks like the wrong parity when really changing parity has no effect.

[LilWiz]

I tried

LWLibavVideoSource("x:\20161210-WAT-EVE-EPL_1-1080.ts")
a = LWLibavAudioSource("x:\20161210-WAT-EVE-EPL_1-1080.ts")
Trim(1, 0)
AssumeTFF()
QTGMC(Preset="Slow")
AudioDub(last, a)

with no change in result.

[ndjamena]

separatefields
trim(1,0)
assumetff
weave

Although if I think about it, that won't work.

Assuming that's the problem you'd have to figure out where each of the fields are and where they should be without wanting to bash your head against a wall until something gives, and that's beyond me at the moment.

[ndjamena]

How's the framerate by the way, are you sure it's coming out as 25fps and not 50fps?

I had that problem with OTA h.264 in a .TS.

[LilWiz]

Hmm, no luck unfortunately :(

LWLibavVideoSource("x:\20161210-WAT-EVE-EPL_1-1080.ts")
a = LWLibavAudioSource("x:\20161210-WAT-EVE-EPL_1-1080.ts")
Trim(1000, 0)
SeparateFields()
Trim(1, 0)
AssumeBFF()
Weave()
QTGMC(Preset="Slow")
AudioDub(last, a)

The initial trim was in case there was something strange at the start of the video that was screwing it up.

I'm aiming for a 50fps final product if that's what you mean. I generally have no issues converting interlaced 25fps ts files to 50fps using my normal method, but this and similar streams occasionally cause issues. Before I have reencoded when I have this issue and it works after that but I don't really want to do that because it sacrifices some quality.

[ndjamena]

Video
ID : 48 (0x30)
Menu ID : 137 (0x89)
Format : AVC
Format/Info : Advanced Video Codec
Format version : Version 2
Format profile : High@L4
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Codec ID : 27
Duration : 1 h 10 min
Bit rate : 5 402 kb/s
Maximum bit rate : 6 001 kb/s
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate : 25.000 FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Interlaced
Scan type, store method : Separated fields
Scan order : Top Field First
Bits/(Pixel*Frame) : 0.104
Stream size : 2.67 GiB (88%)
Color range : Limited
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709


If I load this video into virtualdub using a script containing nothing but LWLibavVideoSource and look at the file information, it tells me the frame rate is 50fps.

Are you sure it's not doing the same to you? It would explain the problem and would have a fairly simple solution (ie setting the framerate in LWLibavVideoSource or just selecteven/changefps)

[LilWiz]

VirtualDub tells me it is 25fps

[ndjamena]

I think it's sample time.

The great thing about .ts streams is that you can cut it however you like. A simple byte split will do and no program should care.

[LilWiz]

Sorry, I don't quite get what you mean by sample time. Could you explain your thoughts?

Thanks for all your help thus far by the way :)

[ndjamena]

We need a sample to work with, so we can look at the file ourselves.

A full HD recording would be a bit much to transfer over the internet but .ts files are easy to split (they're designed to be that way because of the vagaries of transmission.)

[LilWiz]

https://openload.co/f/JfZYyzBDSjw/okaka.ts

Ironically, after getting this snippet of video using tsMuxer I wasn't actually able to load it in VirtualDub... but have a go

[LilWiz]

Ahh I think I've got it. If I split the ts file, and then Trim the first frame in my script I can AssumeBFF() and it seems to work!

Thanks for all your help ndjamena!

[ndjamena]

DGSourceIM decodes it properly, and it says it's all TFF.

LWLibavVideoSource is another matter.

It looks like it's a bug in the source filter and I don't think there's much you can do about it.

[ndjamena]

You're right.

It's just the first nine frames that are the problem. DGSourceIM just skips them.

[ndjamena]

Both FFVideoSource and LWLibavVideoSource can't do anything sensible with the source.

If I load the file with DGSourceIM and manually set TFF QTGMC will process the file properly.

If I use AssumeTFF with FFVideoSource it, other than some nonsense in the beginning it also processes properly.

if BFF works for you then it would seem to be part of the bug.

Using Trim accomplishes nothing, no matter how many frames I trim there's always crap in the beginning. if you need to use the FFMPEG based decoders physically cutting the first frames from the file would seem to be the best option, although if BFF actually works after you've done that then there's still something wrong there.

[hello_hello]

The first section of your sample seems to upset L-Smash & FFMS2 (I'm using on older, XP compatible version of L-Smash), and they're getting the frame rate wrong, but once I get past about frame #40 they seem to be okay for me, once the frame rate is corrected.

LoadPlugin("C:\Program Files\MeGUI\tools\lsmash\LSMASHSource.dll")
LWLibavVideoSource("D:\okaka.mkv.lwi")
AssumeFPS(25,1)
AssumeBFF()
QTGMC()
Info() # To see WTF is going on.

FFM2 was getting the frame rate wrong in a different way, repeating every frame, so you need to tell it not to. Apparently it also sees the field order differently.

LoadPlugin("C:\Program Files\MeGUI\tools\ffms\ffms2.dll")
FFVideoSource("E:\okaka.mkv", fpsnum=25, fpsden=1, threads=1)
AssumeTFF()
QTGMC()
Info() # To see WTF is going on.

[LilWiz]

Interesting. If I run into more issues I'll look at DGSourceIM.

[ndjamena]

DGSourceIM is what you get when you have an Intel CPU with onboard graphics but no NVidia GPU.

If you have a NVidia GPU, get DGSourceNV.

If you have neither then you're on your own.

(they also cost 15USD... you get access to both of them for that, plus whatever other programs DG decides to write.)

[johnmeyer]

I've had too many problems with the input filters for various modern video formats, so I usually use ffmpeg to convert to either lossless or HuffYUV, and then import that. It is admittedly an extra step and requires more disk space, but it has been, for me, fairly bulletproof. It might be worth trying, the next time something like this happens.