Fieldorder- Problems

[lpn1160]

I have done a capture recently, with picvideo mjpeg @19.
Wanting to IVTC, I used this method to check field order. (decomb ver 5 b8):
AssumeBFF().SeparateFields()
I always use this method,without fail. The problem this time, (& I never saw this before) certain parts of the capture seem to be TFF & others (of the same file) are BFF!!
How the hell does one deal with such a problem???

Any info would be appreciated!!!

[Guest]

I would very much like to see that clip. Can you make it available?

Until we get to the bottom of it, you can use Decomb 4, which does not care about field order.

[lpn1160]

I isolated a scene where the "change" takes place. I divxed it for space saving, the only way I can think to send it is E-mail.
Is there an address that I can send it to???

[Guest]

Sure. My email is neuron2@comcast.net. How big is it? If it's bigger than 10M, we'll have to do it in pieces.

[lpn1160]

File size is 6 MB compressed using Divx 5.05 audio MP3
file is 54 sec long. I notice the shift about halfway thru, you'll see a security guard leaning on a file cabinet,as he walks away you'll notice the shift in fields. If not than my eyes are going and i better get glasses!! (LOL)

[Guest]

Shocking!

Please tell me every possible detail about your capture. The source, the hardware, the connection type, everything.

[lpn1160]

your mailbox was "over quota" will send again with pertinent info

[McQuaid]

Might be off topic but I've been capturing the new ren & stimpy on the new network for men. With each ep they've aired when it comes back from the last commerical to the last bit of the episode, it looks like half the resolution is gone.

At first I thought the field order changed and did a field swap but it only made it worse. I then noticed it seems to happen on a lot of shows, noticed on star trek tng the other day, and again at the end of the episode.

I'll post a screenshot when I'm at my box.

And btw neuron, regarding your ernest in wanting his specs, were you amazed by the quality?

[Guest]

Originally posted by McQuaid
And btw neuron, regarding your ernest in wanting his specs, were you amazed by the quality? No, I was and still am amazed to see that his capture setup generated an AVI with a field order reversal. It could not have been transmitted that way, so I conclude that there's something fishy with the capturing. I'm still cogitating about it and its implications for Decomb.

[McQuaid]

Well, here are a couple of screens showing this problem, I don't think there is a way to fix this, but it's really annoying at the end of their shows.

Errr, I thought you could still post attachments in doom9 forum. Anyways I emailed them to you neuron, just to see if you can make sense of it.

Oh, and I wanted to mention that notice in the first good pic there are a couple of black lines at the bottom, then in the bad picture the black lines double. TNN used to squish shows to show their logo crap at the bottom and they seem to have dropped that practice, but I thought maybe this had something to do with it.

[Guest]

Originally posted by McQuaid
Well, here are a couple of screens showing this problem, I don't think there is a way to fix this, but it's really annoying at the end of their shows. I believe this is a capture card/codec problem. The field order cannot change in the broadcast Svideo signal, because it would be obvious when watching the broadcast on the television. There is a way to fix it, however. You can use Decomb 4 or Uncomb(), both of which automatically adapt to field order changes. As for Decomb 5, I'm still thinking about whether it should be altered to cater for pathologic captures such as these.

Oh, and I wanted to mention that notice in the first good pic there are a couple of black lines at the bottom, then in the bad picture the black lines double. TNN used to squish shows to show their logo crap at the bottom and they seem to have dropped that practice, but I thought maybe this had something to do with it. That is a pertinent and valuable observation. If the picture has shifted by an odd number of lines, that would produce a field order reversal! I explain this in the help file for my VirtualDub Reverse Field Dominance filter. Also see Simon Walters' equivalent filter for Avisynth.

My working hypothesis for the observed *invalid* field order change in the AVIs is that it is due to an error of the capture hardware/codec, such that the picture is shifted by an odd number of lines. I have captured many gigabytes using the DC10+ and have never observed this symptom. It would be useful for us to document the capture card/codec combinations that experience this problem.

[lpn1160]

well if this helps for future reference, this field order "change" also occurs with a Wintv2000 PCI PVR card using both huffyuv & picvideo mjpeg codecs.
I'll be stickin with decomb 4 & uncomb & also checkin out Reverse Field Dominance filters