Unofficial VirtualDub Support Forums [Powered by IB Forums]

Printable Version of Topic
Click here to view this topic in its original format

Unofficial VirtualDub Support Forums > Advanced Video Processing > Pal Capture Interlacing Detection

Posted by: strubi Jan 3 2003, 07:10 PM

Hi experts,

I've been experimenting quite a bit on my P4 with realtime encoding from a video source and run into a problem (I hope it's not a FAQ, at least I couldn't find an in depth answer on that topic on the net):

When encoding a tv-broadcasted movie with 25 fps (PAL, since I'm in europe), it's a 50:50 chance that I get a correct progressive picture or evil comb artefacts, when I press F7 for recording in VirtualDub.
It seems that my stupid video decoder doesn't sync on even/odd frames and just starts capturing immediately on any field (Worse, even if it would sync correctly, I've observed that some TV stations don't consistently broadcast 24 fps movies played back at 25 fps, not to mention desynchronizations with subtitles)

To get more into depth: My video decoder (some Philips SAA711X cheapo)
delivers a 720x576 image at 25 fps, even and odd fields interlaced.
The overlay picture gets deinterlaced nicely (by the video codec), but
I've found no way to capture the overlay.

Say, a movie frame would start on an even PAL frame and the even/odd frames of the video stream would look like:

CODE

010101010101
AA BB

Now, in case A the image would be ok, assuming that the 25 fps movie frames sync on an even frame. In case B, the capture start would be on an odd frame, resulting in an image which contains the last half of frame 'n' and the first half of frame 'n+1', i.e. ugly comb artefacts appear on motion.

Of course I could use a deinterlace filter, but quality would suffer badly.

Does anyone have a solution for this?
I would already be happy if I could make my decoder start capturing only on even frames. Feel free to recommend other decoders (do the BT8XX/connexxant chips take care of this?)

Cheers,

- Strubi

Posted by: fccHandler Jan 3 2003, 08:54 PM

Hi Strubi.

If I understand you correctly, case B can be fixed with an Avisynth script:

CODE

AVISource("CAPTURE.avi")
SeparateFields()
Trim(1,0)
Weave()

BTW, overlay looks better because it's probably bobbed by the video driver. There's no way to capture the overlay image.

Posted by: strubi Jan 5 2003, 05:04 PM

hi fcchandler,

I haven't tried avisynth yet..but I succeeded in deinterlacing a video
recorded as raw YUV frames with VirtualDub + filters. But recording raw
videos fills my HD within seconds..

I would like to make the recording software aware of the proper sync though
just before realtime-encoding a DivX or similar. Thank god for the open source
status of VirtualDub, it should be possible to hack something...but I could
imagine that someone else who has got much more experience than me
about win32 video drivers has done this already.

Another problem: I have almost no documentation about the glue logic
of my SAA711X video card, so I can't solve the sync problem on a driver
level.

Any more hints are very welcome,

- strubi

Posted by: Morsa Jan 5 2003, 05:22 PM

instead of using raw video use Huffyuv codec in YUV mode, it will take a third of the space needed for raw video and it is lossless.

Posted by: minion Jan 7 2003, 05:39 AM

Pal Is interlaced at 50 fields per second so it will be difficult to capture a Progressive picture from an Interlaced source....You I think can Capture at 12.5fps and later use Field Bob Filter to which will turn it into a 25FPs progressive image But I haven"t tried it...

Posted by: strubi Jan 8 2003, 01:55 PM

hi minion,

you're right, but note that the grabber delivers a true progressive
image, WHEN it properly syncs to a movie frame, since the half-frames
of the digitized PAL movie (24fps -> 25fps) are not time shifted (that would
be the described case 'A').

I've just ordered a BT878 based card and hope to have more luck with
that one.

Posted by: begu Jan 27 2003, 09:49 AM

I have exactly the same problem. Card is gf4 with philips sa7108e chip.

Strubi: Did You manage somehow to correct problem with Your 'philips' card?
Or how did the bt-chip based card work?

Anyone else had this kind of problem? Is the only possible way to use huffyuv or mjpeg and then swap fields or something in virtualdub and re-encode the video? Or is the field order swappable in avi without re-encoding?

Posted by: muf Jan 27 2003, 11:11 AM

A good deinterlacer for exactly this situation is being developed!

But, you'd still need to capture to disk first, since processing isn't realtime.
Our idea:
1) Check which fields belong to what progressive frames, by analyzing the level of combing (the evil horizontal stripes) between field combinations. If you have skewed fields, but the video was originally progressive, this should fix it. This part of the filter is currently functional and accurate for 90% of tested cases.
2) Check if the frame is progressive, if so, leave completely untouched. This is one of our highest priorities, since 90% of all deinterlacers on the planet deinterlace progressive frames needlessly. This part still has big problems.
3) Create a transparency mask for the parts that are interlaced (there's a double threshold for safety so that combing accidentally left by the comb check aren't as obvious as with a single hard threshold), and leave the progressive parts again untouched, and seperate the fields of the combed parts of the image (are you still with me ?) into 2 different frames, as those belong to different positions in time (what you describe as time-shifting), and interpolate them to full size, and blend them with the progressive parts of the frame. We now have this situation:

(a pipe | indicates a frame seperation, A means field A and B means field B, AB indicates both field A and B are in the same frame)

Weaved (progressive) parts of the frame:
ABAB
Bobbed (deinterlaced) parts of the frame:
AABB
So what we're doing is overlaying the bobbed frames over the weaved frames.

This part is also very problematic, as we seem to have a problem in selecting the correct seperated fields for the bobbing process.

4) We have now reconstructed skewed progressive frames, left the progressive frames untouched, and deinterlaced the combed frames while preserving progressive parts of those frames, and while preserving the temporal position of the original fields as well.

To my knowledge, we (spyder482 and me) are the only ones developing such a filter at this moment. Other filters may give similar output, or implement one or two of the filters, but none of them do exactly what is described here. So, I think you're looking for something like this, but sadly it doesn't exist yet (only step 1 is functioning properly), so I advise you to stop looking for it

. Sorry, we're hoping to finish this filter as soon as possible while doing everything carefully, but we're pretty lost as to what causes our horrible output. I'll keep you updated if interested.

Posted by: begu Jan 27 2003, 01:06 PM

Ok, thanks.
But there is one problem: I don't want to deinterlace at all.
I want to keep my field based video as is, because it looks stunning in my TV, if the field order is correct. If I deinterlace, I spoil the motion smoothness. If I get fields ordered properly, there is nothing to edit in my capture. Of course the filesize is big, but I don't archive these captures.
I only use this 'keep interlaced video structure' -method for watching and then deleting file, like VCR. So I want full cuality for these files. Only way to keep quality when viewed through TV, is to keep it interlaced. And if I use xvid compression with bitrate of 6000 kbps for PAL 25fps fullresolution (720x576) video, the result is just like watching live broadcast.

I think that maybe using avisynth or something I can make the video to 50 fps, and correct the field order and then re-construct interlaced frames. But this is more work and hassle to do. So I'm looking for some trick for encoding to keep correct field order.

Posted by: muf Jan 27 2003, 04:40 PM

If you're going to watch it on TV anyway, it doesn't matter if the fields are skewed or not because the TV will display them correctly anyway. The TV just displays 50 interlaced frames per second, and it doesn't group them in progressive frames of 25fps or anything. So then, I don't get what your problem is. Use XviD in interlaced mode for compression, and, well, that's all that's to it. Progressive frames will display fine on TV, skewed progressive too, and real interlaced frames too. What's the problem ?

Posted by: begu Jan 29 2003, 09:09 AM

Hi,

problem is wrong field order together with phase shifted, I suppose.
The movoment in TV is not natural, the field order is broken. I tried the clip in virtual dub, and used filter "separate fields". Then I carefully examined bad capture vs good capture. It seems that in bad capture the pahse is shifted, I mean, that the codec starts encoding and always start from even fields and when it thinks it is even and in reality it is odd, then that causes phase shift. Just like strubi described. The problem lies in drivers or in philips decoder. It should send full frames with correct field order, but depending the time, I start capturing, there is possibility that fields that make frame1 are not correct ones. So the problem may not occur with bt (conexant) chips with proper (tweaked) drivers. Damn the philips and nvidia for crappy hardware and drivers.

It seems only way is somehow try to fix the fields in virtual dub or buy separate capture card.

Posted by: strubi Jan 29 2003, 01:27 PM

QUOTE (begu @ Jan 27 2003, 03:49 AM)

Strubi: Did You manage somehow to correct problem with Your 'philips' card?
Or how did the bt-chip based card work?

Anyone else had this kind of problem? Is the only possible way to use huffyuv or mjpeg and then swap fields or something in virtualdub and re-encode the video? Or is the field order swappable in avi without re-encoding?

Hello,

been away for a while, sorry for the late reply.

begu:

I haven't managed to fix the Philips chip problem. I am quite sure that
the Philips chip is able to detect the correct field phase, but
the driver must have been developed 'lazy'. I wouldn't even bother
to contact Nvidia.. (I've never gotten replies in the past).

I wanted to look at the linux rivatv driver and experiment with some
SAA stuff, but didn't get far yet wity my old kernel - the rule 'Never touch a running system' still applies until I have my harddisks reorganized :-)

The BT878 card works fine (Hauppauge Win-TV Theater). No wonder,
since the chip is well documented, there are quite some nice programs out which allow direct card tweaking.
Drawback: The WDM based drivers don't work well with VirtualDub - I'd have to install the free BT8x8 Vfw-friendly drivers which again make some TV programs cause a complete hangup of my XP box.

About field swapping: The problem is, that you always get two fields in
one image from the low level capture driver. So, the encoding can be pretty messed up on a wrong field phase, depending on the used encoder and
settings. When encoding a progressive 25 fps movie, I usually turn off
the interlacing support - when the field phase is right, this looks fine.

The best current solution I can think of is, to hack some field order detection into VirtualDub, which just tries to sync to the correct field start - like
DScaler does it perfectly on the BT8x8 cards.
But I still hope there is a way to derive a windows driver from the
rivatv project... well, I wish there was more time!

more to come later....
cheers,

- strubi

Posted by: begu Jan 30 2003, 10:42 AM

I'll post here my fix too, It was indeed wrong filed phase in bad captures.
When applied filter "Field delay" (delay bottom field) the videostructure is correct. Filter:
http://www.stud.uni-karlsruhe.de/~usng/virtualdub-filter/

Posted by: muf Feb 1 2003, 10:55 AM

I have an almost-working version of FieldMatch, an AviSynth filter that does step 1 described above. When it's good enough to post here, I'll inform you.

Posted by: Darkfalz Feb 1 2003, 12:08 PM

This field order can often change MID CAPTURE so you'd need an adaptive filter... and detecting that kind of thing in software is a pain, doing it in real time at 25 fps would be even worse.