MPEG-2 to DV-AVI without strobing...

[wonkey_monkey]

4. I open that script with Virtualldub, and here I can either same to a avi format or frame serve out to a NLE.

And the resulting is 59.97fps? Full progressive frames? Because that's what I think your script does...

5. In this test, nothing is done to the file but to burn. The imported file is NTSC 59.94 fps.

But whatever comes out must be 29.97i to burn to a DVD - so does the problem lie with whatever MPEG encoder you're using?

David

[Guest]

But whatever comes out must be 29.97i to burn to a DVD - so does the problem lie with whatever MPEG encoder you're using? Most likely it lies with the user of said encoder, who apparently does not understand what he's actually doing.

[zambelli]

Its not me wound up, its you at this forum.
There are several people on this thread with more years and posts of experience than yourself trying to scientifically explain to you the correct method for reversing field dominance and why your script doesn't actually work for all content. A wise man would've stopped arguing and started paying attention by now in hope of learning something new. Stubborness is not a sign of wisdom, I'll tell you that much.

I don't have a problem, my script works.
It works for YOU - or at least you think it works for you. You're generating 59.94 fps progressive video and feeding it to an MPEG-2 encoder that's either smart enough to re-interlace it back into 29.97i video or dumb enough to decimate it to 29.97p and encode it as interlaced. In both cases the encoded content MPEG-2 VOB will not exhibit interlacing artifacts - but it'll be far from perfect, which is a point we've all been trying to make.

Here's another page that talks about reversing field dominance and links to Neuron's VDub filter and shows a script example very much like the one I posted: http://home.earthlink.net/~tacosalad/video/fldorder.htm

[wonkey_monkey]

and feeding it to an MPEG-2 encoder that's either smart enough to re-interlace it back into 29.97i video

...but stupid enough to shift one field up a pixel, and the other up two...

David

[2Bdecided]

By the way how can you split something in a long clip when you don't where you are?

Last thought, go and borrow a Sony mini DVD camcorder and see for yourself first hand what the problems are.

Why can't you just use a binary editor to extract+keep the first few MB of a sequence with movement at the start?

Or just record a five second test clip with the camcorder?

Cheers,
David.

[rfmmars]

This is the first time in three days that I have visited this forum, so lets see if anybody has done anything with the files I posted. First I will answer some posts in reverse order.

Why can't you just use a binary editor to extract+keep the first few MB of a sequence with movement at the start?

Or just record a five second test clip with the camcorder?

Cheers,
David.


David The VOB files that I have don't show this problem at the start, its someways into each clip making it impossible to locate the problem area without posting a very large file. Also there is personal information of my family and others. Each time you turn the camcorder on, it creates a new menu entry and a new VOB file. Most of the Mini DVDs but not all, will have many CRC errors. I have never been able to make a Mini DVD to Mini DVD copy but have with the posted software made copies to a DVD-r

Yes that a good suggestion doing a second shoot except that it was not my camcorder, it was loaned to me at the last minute, but that sure could be done if we were in a court of law.

Again David you are almost correct its 59.94 fps as I have stated in a post above. I think this is where the correction happens, in the NLE but I don't know what is going on there, and I have use many NLEs.

zambelli There are several people on this thread with more years and posts of experience than yourself trying to scientifically explain to you the correct method for reversing field dominance and why your script doesn't actually work for all content. A wise man would've stopped arguing and started paying attention by now in hope of learning something new. Stubborness is not a sign of wisdom, I'll tell you that much.

I been in the television field for the last 51 years which encludes design and building Low Power UHF TV stations and fringe area repeater sites.
One time I had this cheif engenier of a CBS station, tell a meeting of a TV club who wanting to bring in Phoenix TV station, that it would be possible to rebroadcast only 3 of the channels with just fair quality, but he and the town's people had to walk by my test setup, showing on 5 monitors, good quality pictures from 5 Phoenix channels. He was so upset he call the police to have me and my equipment removed. Doesn't this sound like the additude of some forum members?

Needless to say I got the contract and that system ran 14 years. You see this cheif coverd his eyes convinced he was right with the information he had, but there was something new on the scene, me and my tweaked hand built low noise FET preamps and 114 element super yagis..

It works for YOU - or at least you think it works for you. You're generating 59.94 fps progressive video and feeding it to an MPEG-2 encoder that's either smart enough to re-interlace it back into 29.97i video or dumb enough to decimate it to 29.97p and encode it as interlaced. In both cases the encoded content MPEG-2 VOB will not exhibit interlacing artifacts - but it'll be far from perfect, which is a point we've all been trying to make.

It seems not to matter what NLE I use, it does the job with no artifacts, at least I can't tell which is the original. Do you think I am the only one that would have an NLE that encoded correctly, it must be 59.94fps or it doesn't work.

neuron2 No, because the original poster asked to make a DV file. I don't need to burn a DVD to see if the field order has been reversed. And is it my fault if you don't know how to author DVDs properly?

You're just trying to obfuscate things to avoid addressing the clear technical proof. We are talking about your method of field dominance reversal. You don't need to make a DVD to show that it sucks. I have clearly demonstrated it and I asked you to comment on that and you continue to ignore it.

I'm happy to let the record stand and our readers can decide for themselves what method they would like to use for field dominance reversal. You can keep using your horrible, video-destroying method.

The files that I posted are all you need to test BUT you wont do that, will you? Your trying to say that saving in Huff, Raw RGB, or smart rendered, will change things pertaining to this problem. If this was true then you could not duplicate the problem, and also correct the problem with the posted source clips. You know that a bogus argument. If I sent you the original Mini DVD, you still wouldn't do it. Why, because you have back yourself in a no win situation. If you do it, you will see that I am right, if you can't fix the problem with your scrip,t then you loose face. It would be great if you came up with a better solution.

So after 3 day, nobody on this forum has done nothing with this, not that you can't, you just won't try. So on this end I am sorry to say I have won by defult, and the loosers are the good people on this forum who have bought into everything neuron2 has said, well maybe they may see the light, that would be good since nobody is an expert on everything.

There will be no further post my me on this matter unless someone has done the test or has come up with another solution, then I will respond to them but nobody else.
All this B.S for just trying to help a fellow member.

Richard

photorecall.net

[communist]

As neuron2 said its standard interlaced TFF video. Encoding that straight with QuEnc or HCEnc and setting them to TFF works fine. The resulting DVD is fluid - no strobing whatsoever.
Here is the script:

AviSource("Huff-Raw-of vob.avi")
ConvertToYV12(true)

The only strobing that one may see is due to cheap camcorders changing shutter speeds to compensate for too much light (as they lack ND filters). No need to reverse the field order - but even if you needed to, you can do that just fine - as long as you take care of it in the encoder.

Your NLE/Encoder is not being set up properly or they apparently always assume BFF (likely if its only aware of DV). Anyway there is no special interlacing here.
Here is a zipped DVD, dont know if it'll work - as I've never authored a NTSC DVD before but take a look:
http://download.yousendit.com/883CE43802F2767E

[wonkey_monkey]

I been in the television field for the last 51 years which encludes design and building Low Power UHF TV stations and fringe area repeater sites.

That has no bearing on the fact that your script did not, by itself, reverse field dominance. It seems to have been coincidence that whatever you did after that (which, AFAIUI, was to drop it into an NLE and export as MPEG) re-interlaced the bobbed material with the opposite field dominance (and, in the process, discarded all of the original pixels).

Take a look at the following image. On the left is the result of swapping fields by the method of zambelli et al. On the right is what would be the result of your method.

http://horman.net/badswap.png

I haven't posted the original, because the image on the left is identical due to the method used.

David

PS What NLE did you use to create the final VOB/MPEG?

[bb]

There might be another problem noone has thought of so far:

Apparently rfmmars' video was somehow damaged (CRC errors). Could it be that the video extracted had different field orders segment wise, i.e. partly BFF and partly TFF?

If that was true, neither of the proper field reversal methods would succeed, because you'd have to treat each segment separately, but rfmmars' bobbing script would yield a (more or less) acceptable result.

bb

[wonkey_monkey]

But wouldn't each segment have to be bobbed separately too? You'd have sections with adjacent bobbed frames in the wrong order, and presumably the NLE would weave them incorrectly too.

David

[communist]

Apparently rfmmars' video was somehow damaged (CRC errors). Could it be that the video extracted had different field orders segment wise, i.e. partly BFF and partly TFF?

If that was true, neither of the proper field reversal methods would succeed, because you'd have to treat each segment separately, but rfmmars' bobbing script would yield a (more or less) acceptable result.

His script wouldn give (more or less) acceptable results either. It would only give fluid output on one field order - as soon as the field order changes this script fails. Also this kind of damage is highly unlikely ;)

Also the post Richard links to earlier is most confusing.
http://support.magix.net/boards/magix/index.php?showtopic=34417
The Mpeg2 format of these disk is not the same as a regular DVD plus the camera only records every other field. The look is ok when played back with the camera or some DVD players but most of these MINI dvds can not be ripped by regular means.
(...)
You can playback the DVD and do an analog capture but it will not have fluid playback, and will show strong interlace artifacts.
(...)
Now after you have copied the Mini DVD your work is not over since you need to replace the missing fields.
If the camera only recorded every other field it would strobe all the time you had any panning/motion.
The analog capture is supposed to have these 'interlace artifacts' - because its an interlaced signal being displayed on a progressive display, both fields at the same time on your PC monitor.
If these fields were missing you just wouldn get smooth or non-strobing motion with a simple bob. The strobing is a result of wrong field order its simple as that :)

[Guest]

if you can't fix the problem with your script then you loose face The original problem posted was about how to reverse field dominance to go from TFF MPEG2 to BFF DV:
I've been trying to use both VirtualDubMod or VirtualDub MPEG-2 to convert several interlaced MPEG-2 files into DV-AVI The solutions I mentioned are tried and true and for you to deny that they work is laughable.

You have a different problem, however. You get strobing when trying to author your DVD. I don't see a fix for that other than for you to learn how to properly author a DVD. Unfortunately, you've been singularly resistant to learning.

[bb]

Well, I downloaded the first of the three files (which took me hours due to the very slow servers), because I wanted to know how rfmmars' method would compete to the established methods of field parity reversal.

I used the following scripts to feed my encoder (MainConcept MPEG Encoder):

Script 1:
AviSource("C:\Test\Huff-Raw-of vob.avi")
ComplementParity()
Script 2:
AviSource("C:\Test\Huff-Raw-of vob.avi")
complementparity
separatefields
bob()
Then I encoded both scripts using the following settings:
top field first, frame rate 29.97 (NTSC), deinterlacing: none, resolution: 720x480, 4:3 display, bitrate: 2500 kbps min, 6000 kbps avg, 8000 kbps max, 15 I-frames, 3 P-Frames (BBIBBPBBPBBPBBP...)

Finally I authored two NTSC DVDs using DVDlab.

I watched the final DVDs on my TV set, which is - that I must admit - a PAL device, as is my DVD player.

Both DVDs played smoothly (as smoothly as NTSC DVDs can play on a PAL setup); there was no visible difference. So I compared the files in VirtualDub using the following script:
v=AviSource("C:\Test\Huff-Raw-of vob.avi").complementparity().separatefields()
v1=v.bob()
v2=v.bilinearResize(720,480)
v1.StackVertical(v2)
The difference was still barely visible in the test video, but there was a difference (of course), as the difference script revealed:
v=AviSource("C:\Test\Huff-Raw-of vob.avi").complementparity().separatefields()
v1=v.bob()
v2=v.bilinearResize(720,480)
subtract(v1, v2)

Conclusion:
If you ask me, rfmmars' method (script 2) eats up more computing time, and it alters the video unnecessarily. The difference is not that striking, though, most of the time it we be unrecognised by Joe Average, and it is a working solution. As a video enthusiast, I would clearly prefer one of the common ways of field order reversal (i.e. drop the first field or shift lines).

bb

[SeeMoreDigital]

Well I just fed rfmmars "Huff-Raw-of vob.avi" source into VirtualDub and using FFdshow's MPEG-2 encoder managed to generate a "pure interlaced" MPEG-2 TFF stream.

Works and plays without strobing in my hardware player....

[Guest]

@bb

Sure, if you start with crappy video the degradation may not be as striking, but David and I both used clean test patterns and the degradation is very striking to me.

[Guest]

Just to remove Richard's last objection, I too made a DVD out of his source clip. I repeated copies of it because a 2-second DVD is not that satisfying. I did not have to reverse the field order; I just instructed my MPEG2 encoder to use the TFF of the original AVI clip.

The DVD plays without "strobing" on my standalones and when I rip it and step through the fields, the field order is correct TFF as flagged. The ISO of the DVD is here (83MB):

http://neuron2.net/misc/rfmmars.zip

I conclude as follows:

1. Authoring an interlaced TFF AVI to a DVD is trivial; field order reversal is not necessary (unless, of course, you use a retarded MPEG2 encoder that insists on receiving BFF.)

2. But authoring an interlaced TFF MPEG2 to DV AVI requires field order reversal. This can be done without degrading the video using the well-known line shift or field shift methods.

3. Reversing field order by bobbing, as Richard proposes, is an abomination.

[Guest]

Now, reading between the lines, I have another thought. Perhaps Richard's flaky rips (which he claims are fraught with CRC errors) are infected with field order transitions throughout the stream. Now this is a case where a bobbing solution would fix that, because in effect all frames are converted to progressive by bobbing prior to reinterlacing. The standard methods would not address this pathology.

Unfortunately, we can't assess this possibility because Richard has not posted any source clips that contain field order transitions, nor has he stated that they do.

My reaction to such a problem would be to solve the ripping problem and avoid such transitions in the first place, but if that is not possible then the bobbing method would be a quick and dirty way to fix it. The alternative of segmenting the source into segments and treating the segments independently with the traditional methods would allow one to retain full video quality, but would be more time consuming. If Richard would indulge us by posting an original VOB, we could see if the Fix D2V function of DGIndex could fix things up.

If this is correct, I think we can understand better Richard's adamant position. It would have helped if he told us he was encountering field order reversals within the stream. For now I am guessing that, since it is the only theory that makes sense of this whole mess.

EDIT: bb pointed this out above but I missed seeing it before writing this.

[bb]

Now, reading between the lines, I have another thought. Perhaps Richard's flaky rips (which he claims are fraught with CRC errors) are infected with field order transitions throughout the stream. Now this is a case where a bobbing solution would fix that, because in effect all frames are converted to progressive by bobbing prior to reinterlacing. The standard methods would not address this pathology.
That's what I suspected a few posts above (maybe I did not express myself clearly enough).

bb

[SeeMoreDigital]

Anyway... Here's my effort: -

http://www.mytempdir.com/2034632

Original clip x5 (10secs/300frames). Stored as DVD.ISO file. Compressed using 7-Zip.


Cheers

[Guest]

That's what I suspected a few posts above (maybe I did not express myself clearly enough).
No, you did express it very clearly! I just missed seeing that post. Sorry.

[Guest]

But wouldn't each segment have to be bobbed separately too? You'd have sections with adjacent bobbed frames in the wrong order, and presumably the NLE would weave them incorrectly too.

I forgot to address your point, David. You'd be right if the encoder was actually re-interlacing. But I think it is just decimating frames. Has anyone heard of an encoder that re-interlaces? I haven't. They just toss frames. So it seems to me that this theory is plausible: Richard's stream has field order transitions. By bobbing it and then decimating by two, it gets fixed. It pays a big price by degrading the video and throwing out half the temporal resolution, but as he says "it works". I'd like to see the VOB, though, to confirm the theory and to determine if it can be fixed without having to bob.

[wonkey_monkey]

Richard's third attachment, which I understood to be the encoded result, was certainly interlaced...

David

[Guest]

I looked only at the Huffy. If so, then it's still a mystery. If only Richard would give us a decent VOB fragment (instead of excuses; it's not rocket science). Anyway, we have answered the original poster's question quite satisfactorily, I think. :)

Do you know of any NLE or encoder that re-interlaces?