AmaRecTV and field order

[Mr Chris]

I'm capturing from VHS using a Hauppauge USB-Live 2 in AmaRecTV. Once done, I open the raw .avi file in VLC, hit the 'de-interlace' key, and the fields play back in the wrong order. This also happens in Media Player Classic and Kodi, and I've tried both Lagarith and Ut codecs.

Has anyone else come across this issue? It's not a major problem in the grand scheme of things, but it's a pretty large inconvenience when just wanting to give something a quick check. What can I do to produce captures that play back with the correct field order?

[davexnet]

I'm capturing from VHS using a Hauppauge USB-Live 2 in AmaRecTV. Once done, I open the raw .avi file in VLC, hit the 'de-interlace' key, and the fields play back in the wrong order. This also happens in Media Player Classic and Kodi, and I've tried both Lagarith and Ut codecs.

Has anyone else come across this issue? It's not a major problem in the grand scheme of things, but it's a pretty large inconvenience when just wanting to give something a quick check. What can I do to produce captures that play back with the correct field order?

can you upload a sample, 10 - 15 seconds would be enough, something showing steady movement

[Mr Chris]

Here we are - found something with a bit of movement:

AmaRecTV-UT-field-sample.avi

This is an absolutely raw capture with no filters or ProcAmp settings or anything - just an .avi file, via AmaRecTV with the Ut codec. Open it in VLC, enable Yadif (x2) de-interlacing, and... What do you see? Wrong field order? It's the same with Media Player Classic and Kodi, too. I presume (hope) there's something simple I need to do somewhere in AmaRecTV that will fix future captures, but for the life of me I can't see it.

[davexnet]

Yes I see people complaining about it here
https://forum.videolan.org/viewtopic.php?t=3101

The file is not fllaged as interlaced, nor is any field order indicated (as far as I can see)

[badyu17]

Everything is fine when you encode your file with x264 and keep it interlaced with mbaff. Motion is smooth and there's no wrong field order. It's just that you can't deinterlace this avi file with vlc. These captures are for further processing and encoding and not for previewing in video player. I was never able to deinterlace any of my captured avi files with VLC but they turned out fine every time after encoding.

[jagabo]

AVI has not flags to indicate a video is interlaced or the field order. UT codec has an interlaced setting but it only controls how the codec works internally. That information is not passed to editors/players upon decompression. VLC always assumes bottom-field-first when set to deinterlace. Your video is top-field-first. It's up to you to keep track of the field order and specify it in your later processing.

[TimA-C]

I think the interlace flag in UT video is being/has been phased out isn't it? I'm sure I remember seeing something in the release notes . . . ?

What are your deinterlacing settings in AmarecTV?

Which version of AmarecTV are you using?

[Mr Chris]

Thanks everyone for your replies. To address the points raised...

What are your deinterlacing settings in AmarecTV?
Which version of AmarecTV are you using?

Version 3.10, with no deinterlacing. Some of my captures are headed for DVD or Blu-ray, while others end up as MP4 files - or any combination of the three. As such, I preserve the interlacing unless and until it absolutely has to go.

Everything is fine when you encode your file with x264 and keep it interlaced with mbaff.

It's up to you to keep track of the field order and specify it in your later processing.

Well, yes, that's what I am doing. The final (final) outcome isn't where the problem lies, but rather...

These captures are for further processing and encoding and not for previewing in video player.

I don't believe anyone can honestly say they've never captured something, and then immediately needed to just check that a certain section came out all right. It seems bizarre to say that that simply can't be done. (Current workaround: open it in VirtualDub and set up the deinterlacing filter. It works, but it's not the most elegant of solutions.)

I've previously dealt mostly with DVD-compliant MPEGs and DV-AVIs, and this issue never arose. The Hauppauge/Ut combination was supposed to be an upgrade, and obviously it is in terms of picture quality (though not as much as I was expecting, compared to DV), but losing the straightforward checking process would be a pretty big step backwards in my personal workflow.

The file is not fllaged as interlaced, nor is any field order indicated (as far as I can see)

So is there anything at all that can be done to change this, or...

AVI has not flags to indicate a video is interlaced or the field order.

...do I find myself in a like-it-or-lump-it situation?

VLC always assumes bottom-field-first when set to deinterlace.

(I presume you mean when there's no flag present - for instance, PAL DVD video is top field first, and VLC handles that correctly.)

What I'm really struggling to get my head around is that this isn't an issue exclusive to VLC. Add in Media Player Classic and Kodi - that's three different media players - and they all detect that the video is interlaced, but all three guess the field order incorrectly. All three. Is there really no way to correct this seemingly simple issue at any stage of the capturing process?

A further question springs to mind: What's actually deciding the field order in my chain - the Hauppauge, AmarecTV, or the Ut codec?

[jagabo]

MPCBE has an internal decoder for UT Video Codec. It can be set to assume TFF.

View -> Options -> Internal Filters -> Video Decoders -> UT Video -> Video Decoder Configuration -> Deinterlacing -> Top Field First

If you use that setting all UT videos will be deinterlaced, even if they're progressive.

The capture device or its drivers determine the field order you get. The device can start with a top field then add the next field to complete the frame creating a TFF video, or it can start with a bottom field then add the next field to complete the frame creating a BFF video.

[Mr Chris]

MPCBE has an internal decoder for UT Video Codec. It can be set to assume TFF.

View -> Options -> Internal Filters -> Video Decoders -> UT Video -> Video Decoder Configuration -> Deinterlacing -> Top Field First

Ah, thank you very much indeed - that's definitely better than my VirtualDub workaround.

The capture device or its drivers determine the field order you get.

Interesting. And presumably that can't be changed in the capturing process? (Or can it?) Because the way I see it, if everything's going to automatically assume that the videos captured through the device are BFF, the ideal solution would be to make sure the captured videos are BFF.

I have to confess, this is all leaving me rather nonplussed. I mean, isn't this a pretty major flaw? Of all the questions I asked when researching which USB capture device to go for, for some reason, "Does it produce AVI files with a field order that everything will automatically play incorrectly?" didn't occur to me. Years of being spoilt by the otherwise inferior DV, I suppose. Are all such devices like this, or have I picked a dud in going for the Hauppauge USB-Live 2?

[poisondeathray]

What about x264vfw ? Can you use that with your device instead of UT ? You have options for speed/quality/compression or lossless , I frame or short GOP's .

You can use --tff and the aspect ratio --sar 12:11 in the extra command line box . It plays correctly in VLC

[jagabo]

I've never seen a capture device that lets you select the field order. Of course you can always swap the field order after capture.

[JVRaines]

I suppose. Are all such devices like this, or have I picked a dud in going for the Hauppauge USB-Live 2?

Maybe. Or maybe you have bad karma from a previous lifetime. Be thankful your punishment is so slight. TFF is pretty much the default for A/D conversion. As noted, if you leave your video in AVI files, players will have no clue about the field order and have to make assumptions. You know what happens when you assume.

[Mr Chris]

TFF is pretty much the default for A/D conversion. As noted, if you leave your video in AVI files, players will have no clue about the field order and have to make assumptions.

I've never seen a capture device that lets you select the field order.

Well, I suppose if that's the way it is, that's the way it is, but those statements only making it all the more confusing to me why three different media players are guessing BFF if it's the less common option of the two. So all these years, have all you Ut/Lagarith/Huffyuv capturers been unable to quickly and easily test your captures? I feel like I'm stumbling into some strictly-kept dark secret!

What about x264vfw ? Can you use that with your device instead of UT ? You have options for speed/quality/compression or lossless , I frame or short GOP's .

You can use --tff and the aspect ratio --sar 12:11 in the extra command line box . It plays correctly in VLC

Thank you very much (especially for the extra commands, which I wouldn't have thought of) - that's something to bear in mind. Would you recommend it? I've always been wary because I've heard horror stories about x264vfw's handling of interlaced material. Also, can it be forced to work in 4:2:2 from start to finish? Because if there's a 4:2:0 conversion anywhere before the final (final) encode, then the improvement over DV gets smaller still.

[jagabo]

Yes, x264vfw can be set to encode incoming interlaced TFF YUV 4:2:2 as such, no conversion to YV12. Recommend you use short GOPs, no b-frames, and enable Zero Latency for best compatibility and editablity.

[poisondeathray]

Would you recommend it? I've always been wary because I've heard horror stories about x264vfw's handling of interlaced material. Also, can it be forced to work in 4:2:2 from start to finish? Because if there's a 4:2:0 conversion anywhere before the final (final) encode, then the improvement over DV gets smaller still.

For your case it seems to be the only valid working option...

If your device and capture software work ok - it should be full 4:2:2 chain . The codec certainly supports it

Since the field order is part of the codec data, it's container independent. If you remux it into a MP4 or MKV , it will still be identified as TFF . (or BFF if you choose --bff)


What were the horror stories about x264 VFW interlace handling? Just encoding your sample with it - works ok , checked in multiple program, metadata is ok

(Note that x264 encodes MBAFF , not PAFF. But that should be ok for 99.99% situations.)

Some editing programs might not like AVC in AVI container , but you can remux to MP4 and it should be ok


If anything, the most common complaint is that it's too resource hungry . A slower system might drop frames. But it's unlikely with SD material, and a semi modern computer within the last 10 years . You can use I-frame and low latency settings , faster presets to farther reduce resource usage

[Mr Chris]

What were the horror stories about x264 VFW interlace handling?

I honestly can't remember! A quick Google threw up something about the possibility of the chroma fields getting essentially deinterlaced and blended each frame, so maybe it was that. All I know is that I made a mental note at some point to avoid, and can't for the life of me remember why.

Some editing programs might not like AVC in AVI container , but you can remux to MP4 and it should be ok

Minor side-issue, but what's the easiest way to remux (not transcode) an .avi to .mp4?

If anything, the most common complaint is that it's too resource hungry . A slower system might drop frames. But it's unlikely with SD material, and a semi modern computer within the last 10 years . You can use I-frame and low latency settings , faster presets to farther reduce resource usage

Yes, x264vfw can be set to encode incoming interlaced TFF YUV 4:2:2 as such, no conversion to YV12. Recommend you use short GOPs, no b-frames, and enable Zero Latency for best compatibility and editablity.

Thanks again for all that - I'm going to do some experimenting over the weekend to see if my setup can get decent I-frame only captures in x264vfw, and whether they play nicely in my usual tools (VLC, Media Player Classic, Kodi, VirtualDub, old version of Premiere, etc.).

[jagabo]

I'm going to do some experimenting over the weekend to see if my setup can get decent I-frame only captures in x264vfw, and whether they play nicely in my usual tools (VLC, Media Player Classic, Kodi, VirtualDub, old version of Premiere, etc.).

x264vfw vs huffyuv (one of the fastest lossless encoders):
https://forum.videohelp.com/threads/393998-VHS-capturing-without-VirtualDub-under-Linux#post2557687

[poisondeathray]

Minor side-issue, but what's the easiest way to remux (not transcode) an .avi to .mp4?

I'm going to do some experimenting over the weekend to see if my setup can get decent I-frame only captures in x264vfw, and whether they play nicely in my usual tools (VLC, Media Player Classic, Kodi, VirtualDub, old version of Premiere, etc.).

Easiest is probably a GUI for mp4box such as yamb, mymp4boxgui

But another side issue is if you are using uncompresssed audio with your captures, it's unsupported in MP4 container by open source muxers . You'd need to use another container like .mov or transport stream like .ts, m2ts

I prefer ffmpeg to batch remux, but you can do it with mp4box, or lsmash muxer. I think there might be some batch ffmpeg GUI's now

Most commercial NLE's do not treat lossless YUV codecs (lagarith, huffyuv , ut, magicyuv , etc...) as YUV. They get RGB treatment, thus are not lossless. Also potential clipping problems from that. The exception is newer versions of PP. I think around CC2015 or CC2017 x264 lossless is accepted, and also treated as YUV, thus truly lossless.

[TimA-C]

I tend to use AviDemux for quick & dirty edits and remux of my x264vfw captures from my USB-Live2. If it's something I want to keep - although I'd usually capture to Lagarith if I was going to keep it - then I tend to use VideoRedo V5.