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

[jeff1385]

I've been trying to use both VirtualDubMod or VirtualDub MPEG-2 to convert several interlaced MPEG-2 files into DV-AVI (using the Panasonic codec, in order to import into AVID), but every time I do there's plenty of strobing when there's any motion at all. I want the files to remain interlaced and look just like before... any advice?

[Guest]

Well, "strobing" is not a commonly understood technical term. Can you please explain it more precisely, perhaps with a stream sample?

[jeff1385]

I just meant general jerkiness and blurriness in the area wherever motion occurs. Just tried creating a low bitrate version to post online, but it doesn't really show what I'm trying to demonstrate like the high-quality version does. Basically what I'm trying to figure out is how to convert an MPEG-2 file to DV-AVI with no processing whatsoever.. just want to convert the file and have it look the same as before if possible.

[Guest]

You're going to need to post a sample if you want good advice.

Just cut out a portion of your source stream and post that.

Otherwise it is guesswork. There are so many variants of MPEG2 that we really need to see your unprocessed source material to advise you properly.

One general approach is to use DGMPGDec to serve the video with honor pulldown flags and serve the AVS script into your DV encoder.

You refer to AVID. What is that?

[bb]

Avid (http://www.avid.com)

jeff1385, do you resize the video while converting to DV (you shouldn't)?

bb

[jeff1385]

I had been resizing it, thanks for the tip. I also added the regular deinterlace filter and now it seems to be looking good. Thanks.

[zambelli]

Jeff, you need to provide us with more info about your MPEG-2 sources. Resolution? Framerate? Interlaced/progressive/telecine/mixed? 4:2:0 or 4:2:2?

[sh0dan]

Your fields are probably swapped. DV is BFF and MPEG 2 is TFF. You need to swap them. I'm no expert on field swapping, but I'd say that adding a line above, and subtracting one at the bottom should do it.

[wonkey_monkey]

and MPEG 2 is TFF

MPEG 2 is usually TFF (probably because broadcasts are), but it can be flagged as either. AIUI some encoders don't give you the option, and will flag BFF as TFF.

David

[rfmmars]

The solution is this script. Capture interlace, this is the same problem with Mini DVDs....see www.100fps.com for the story.

complementparity
separatefields
#AssumeFrameBased
#AssumeFieldBased
#SwapFields
bob()

Richard
photorecall.net

[zambelli]

The solution is this script. Capture interlace, this is the same problem with Mini DVDs....see www.100fps.com for the story.
That script doesn't solve anything. And 100fps.com hasn't been updated since like 2002.

Donald Graft wrote a plugin for reversing fields: http://neuron2.net/reverse/reverse.html

This script would also work for changing TFF to BFF, and is essentially the 2nd method that Donald describes:
AssumeTFF()
SeparateFields()
fc = Framecount
DuplicateFrame(0)
Trim(0,fc)
AssumeBFF()
Weave()
I believe that only switches temporal order and not actual spatial dominance, but that shouldn't matter in a digital domain where it doesn't matter where the line is drawn as it's never actually displayed as interlaced but always as progressive.

[rfmmars]

That script doesn't solve anything. And 100fps.com hasn't been updated since like 2002.



Really...........this is what I use on a weekly bases for my customers.

You think you know it all but you don't..........when the truth is know, it doesn't matter what year it was spoken.

Your know it alls are maybe why the use of this forum has dropped from an adverage of 55 viewers to a average of 28 viewers in just a year.

The reason this script works is that 8mm camcoders & Mini DVD recorders do not use the same interlacing as a standard Vhs recorders.

Pardon me for being so blunt but you are full of it.

Richard

[Mug Funky]

i'd always try either:

doubleweave().selectodd()

to field-shift the content, or simply move the video up or down by 1 pixel if one doesn't want to shift fields between frames (like with mostly progressive content).

FWIW, most DV decks will use the latter method of moving the video up or down a pixel when outputting to SDI (which is TFF only, thankfully. it would be a nightmare if it supported 2 field orders).

however, most DVD players will handle a field-swap within an mpeg-2 stream by duping one field and outputting a phase-shifted signal. which is a good reason for progressive TVs to support 2:2 pulldown detection...

the only time you'll normally see BFF mpeg-2 is if it was encoded via software from a DV source. everything else will likely have passed through SDI cables and hence be TFF.

The reason this script works is that 8mm camcoders & Mini DVD recorders do not use the same interlacing as a standard Vhs recorders.


i don't know what this means. could you elaborate?

[rfmmars]

i don't know what this means. could you elaborate?

I ran into this problem several years where a interlace capture of 8mm camcoder would look ok when there was no motion to the left or right. I thing I remember was a static shot with a lady swinging openi a front screen door, it was like a strobe. The 8mm tape played fine using the camera as a play back device, but not as capture video.

I also found this artifact if I tried to capture a DV tape with a analog board instead of using a firewire or USB direct cable.

Just last month I shot 11 mini DVDs in Alaska and guest what, there it was again, plus very bad almost diaginal lines which look to me as an interlace problem.

Mind you I have five video workstations with various capture cards and different capture software, the results are the same.

Going back to the first time i saw this problem I read in detail what was said about some camcoders and how they capture vs a regular VCR. I had never worked at that time with "Avisynth" but the script looked simple enough. His third picture on his site was identical to my problem. You didn't see this problem on the workstations if you deinterlaced but was always there on the burned DVD.

http://img61.imageshack.us/img61/7233/distortion2cz1.th.jpg (http://img61.imageshack.us/my.php?image=distortion2cz1.jpg)

I open the file in Virtuaildub, framed served to the "posted script"
and open that script in another Vdub and frame served out to my NLE at that time Magix's MEP-2004. Yes it worked

This was his post.

http://img160.imageshack.us/img160/4425/interlace3vw2.th.jpg (http://img160.imageshack.us/my.php?image=interlace3vw2.jpg)

I am not sure if his wording is correct but I put this script together and its works everytime. Also I might say the it doesn't work if it is applied to a second generation copy.

This may not be the best solution but it does the job, maybe you can fill in for me the gaps.

Richard

[zambelli]

Really...........this is what I use on a weekly bases for my customers.

You think you know it all but you don't..........when the truth is know, it doesn't matter what year it was spoken.

Pardon me for being so blunt but you are full of it.
Am I supposed to take your post seriously?

The script that you posted doesn't reverse field order. What it does in fact do is assume the field order opposite of the original one (which in the case of most formats would just default to BFF due to lack of source metadata) and then bobs the video. So the clip starts out as BFF, ComplementParity() flips it to TFF, and then you Bob() it.

This essentially means it will "work" when you give it TFF videos. That's not exactly "reversing" field order - that's merely guessing the correct one.

Think I'm "full of it"? Try this script on your source:

AssumeTFF()
Bob()

Let me know how that works for you. And next time you want to call somebody "full of it", you might want to back it up with something other than just insults.

[Dark Shikari]

Really...........this is what I use on a weekly bases for my customers.

You think you know it all but you don't..........when the truth is know, it doesn't matter what year it was spoken.

Your know it alls are maybe why the use of this forum has dropped from an adverage of 55 viewers to a average of 28 viewers in just a year.

The reason this script works is that 8mm camcoders & Mini DVD recorders do not use the same interlacing as a standard Vhs recorders.

Pardon me for being so blunt but you are full of it.

Richard:rolleyes:

[Guest]

Guys, please refrain from insults and "no-use" posts.

I agree with zambelli on technical grounds, for what it's worth. I still have an open mind, though, so if rfmmars would like to post two samples (unprocessed clips, not JPEGs) showing the "different types of interlacing", I'm sure we will all be very interested to see it, and will give it the critical attention it deserves.

[rfmmars]

Am I supposed to take your post seriously?

The script that you posted doesn't reverse field order. What it does in fact do is assume the field order opposite of the original one (which in the case of most formats would just default to BFF due to lack of source metadata) and then bobs the video. So the clip starts out as BFF, ComplementParity() flips it to TFF, and then you Bob() it.

This essentially means it will "work" when you give it TFF videos. That's not exactly "reversing" field order - that's merely guessing the correct one.

Think I'm "full of it"? Try this script on your source:

AssumeTFF()
Bob()

Let me know how that works for you. And next time you want to call somebody "full of it", you might want to back it up with something other than just insults.

complementparity
separatefields
#AssumeFrameBased
#AssumeFieldBased
#SwapFields
bob()

I will be happy to try what you posted, but to tell the forum that my script, well not mine, doesn't do anything is wrong. The format is Sony's Mini DVD Mpeg2 format.

I will try to post 4 frames or more of the original, and of the script coverted clip. You will not be able to see the problem on a PC, you must burn a DVD. However there may not be enough frames in a small clip to produce the artifact..

Also the Assume *.* is not active in this script.

The last time I posted this solution I got the same warm responce from this forum, it gets old reel fast. Do I want to help another member out?, YES, will I post again, I don't think so.

Richard

[zambelli]

I will be happy to try what you posted, but to tell the forum that my script, well not mine, doesn't do anything is wrong.
Well, the question asked was how to reverse field order. And I explained that your script doesn't reverse field order - it only sets field order and bobs the video. Yes, it does indeed do something - but that something is not reversing field order. If you disagree with my explanation, I am open to hearing your explanation of what your script does.

The last time I posted this solution I got the same warm responce from this forum, it gets old reel fast. Do I want to help another member out?, YES, will I post again, I don't think so.
I apologize if my original response came off as patronizing. But I must point out that Avisynth isn't an abstract art. The script either does what you claim or it doesn't. So if you think you're right and others are wrong, please explain your script and perhaps even include some video samples and the matter will be resolved quickly. We can argue all day whether Pepsi is better than Coke without resolution, but if you claim 2+2=5, then you'd better come prepared to prove it.

[Guest]

The script would reverse field order if it was augmented with a reinterlacing step at the end. For example, this will reverse the field order of a BFF clip:

assumetff()
bob()
separatefields()
selectevery(4,0,3)
weave()

But it's a terrible way to do it because it blurs the video, whereas the conventional line shift and field shift methods do not affect the video.

I'd still like to see the demonstration of the two different types of interlacing.

[rfmmars]

The script would reverse field order if it was augmented with a reinterlacing step at the end. For example, this will reverse the field order of a BFF clip:

assumetff()
bob()
separatefields()
selectevery(4,0,3)
weave()

But it's a terrible way to do it because it blurs the video, whereas the conventional line shift and field shift methods do not affect the video.

I'd still like to see the demonstration of the two different types of interlacing.

The reinterlacing occurs in the NLE at time of editing and burning, thats why its not in the script.

You guys are the master of the theroy of "avisynth", I am not, just a user. When a problem occurs, I look for a solution. When I find that solution, I stop looking.

This is not the only or first problem dealing with Camcoder Mini DVD format. Take a look at my post on another forum for the complete picture.

http://support.magix.net/boards/magix/index.php?showtopic=34417

My wording in the above post is my understanding at the time and the solutions for dealing with these issues.

EDIT: Heres another person with the same problem

http://support.magix.net/boards/magix/index.php?showtopic=34582



Richard

[Guest]

The reinterlacing occurs in the NLE at time of editing Perhaps, but that doesn't change the fact that it is a terrible way to reverse the field order. I'll be happy to demonstrate that for you if you want. Care to comment on that? You want to do the best for your customers, right?

And Richard, have you dropped your claim about two different kinds of interlacing? If not, will you please post some clips to make it clear for us?

[rfmmars]

Richard, have you dropped your claim about two different kinds of interlacing? If not, will you please post some clips to make it clear for us?

No I am not dropping that statment until someone can tell me why this problem can be seen with the capture from most 8mm and Hi-8 camcorders, plus ripps of "Mini DVD Camcorders" but NOT captures of VHS, S-VHS material from standards VCRs,full size camcoders or ripps of regular VOBs from DVDs.

I would like to know and the only info I found was at www.100fps.com

Richard

[Guest]

Do you accept that your method of reversing field dominance is poor compared to the simpler alternatives that do not affect the video? If not, why not? Ignoring the question doesn't make it go away. :)

There are not two different types of interlacing, just two different possible field orders. Apparently your two situations result in different orders, hence the need to reverse one of them.

[rfmmars]

Do you accept that your method of reversing field dominance is poor compared to the simpler alternatives that do not affect the video? If not, why not? Ignoring the question doesn't make it go away. :)

There are not two different types of interlacing, just two different possible field orders. Apparently your two situations result in different orders, hence the need to reverse one of them.

Please wait, I am taking the time to burn two comparason DVDs using your method and the other, posted by another member.

I will get back to you with the results.

Richard

[rfmmars]

Just finished the DVDs for comparasion, neither script solves the problem but my posted script does.

So for all the bashing of my solution, its the one that works. I have applied it to my 11 Mini DVDs and to 56 Mini DVDs of a customer's "Around the World Trip" I'am happy, and so is my customer. All I did was to try to help a fellow member with my first post. By the way these are all Sony Mini DVD camcorders but different models.

There is something going that you and I don't understand, but I got my solution from www.100fps.com

It seems clear that the author has a clue.

So next time, if there is a next time, don't shoot at me, offer the member another choice and see what happens. You don't have the Mini DVD Mpeg2 source video, so you don't know what I am dealing with. I still will try to post the A-B clips in the next day or two.

Richard

[Guest]

Neither script works I didn't give you a script to implement my method. What scripts are you talking about?

Richard, you haven't told us what you did. You could have totally goofed it up. Are you saying that our method of reversing dominance does not work? It's easy to prove that it works. If not, then what did not work for you and what exactly did you do?

If you give us a part of your source, we will be happy to show you how to do it correctly and prove that it works fine. :) But you've been very reluctant to give us the things that can be used to prove you wrong.

I don't understand

Yes, it's clear that you don't. I understand it very well, however.

I'll say no more on this until you produce the clips that support your claims. I suspect you won't ever post those things.

[rfmmars]

I didn't give you a script to implement my method. What scripts are you talking about?




Yes, it's clear that you don't. I understand it very well, however.

I'll say no more on this until you produce the clips that support your claims. I suspect you won't ever post those things.

You can't even read your own post

Originally Posted by neuron2 View Post
The script would reverse field order if it was augmented with a reinterlacing step at the end. For example, this will reverse the field order of a BFF clip:

assumetff()
bob()
separatefields()
selectevery(4,0,3)
weave()

But it's a terrible way to do it because it blurs the video, whereas the conventional line shift and field shift methods do not affect the video.

I'd still like to see the demonstration of the two different types of interlacing.

Your making a fool out of yourself, no wonder this is a dieing forum, you think you know it all, I don't, but I got the job done.

At this point I am not on trial, you are!

Richard

[Guest]

Richard, *that* script is the terrible bobbing way that you have been suggesting. I merely completed it for you. It is neither of the two methods that we have been telling you about. As I said quite clearly, I did not give you a script that implements my non-blurring method.

I didn't give you a script to implement my method.

Here is a concise summary of field order reversal methods:

1. Richard's terrible bobbing method -- blurs the video.

2. Crop a line off the top method -- no effect on the video.

3. Field shift method -- no effect on the video.

Nobody's "on trial". We are just trying to get to an accurate technical conclusion.

And again, stop the insults!

[zambelli]

You can't even read your own post
Your making a fool out of yourself, no wonder this is a dieing forum, you think you know it all, I don't, but I got the job done.
At this point I am not on trial, you are!
Your lack of professionalism is simply astounding. You're making a really poor advertisement for photorecall.net, though I have a feeling you'll fight that advice too.

Neuron and I are not arguing with you because we don't like you - we're arguing with you because we want to make sure the correct solution is found. And we've both presented explanations of what our scripts do - while you've only presented insults and "it works / doesn't work" statements. So you tell me - who's being unreasonable?

No I am not dropping that statment until someone can tell me why this problem can be seen with the capture from most 8mm and Hi-8 camcorders, plus ripps of "Mini DVD Camcorders" but NOT captures of VHS, S-VHS material from standards VCRs,full size camcoders or ripps of regular VOBs from DVDs.
The difference is in the interlaced field order. Digital formats such as DV, for example, use BFF for both NTSC and PAL. Most other formats, both digital and analog, tend to use TFF. The problem, and the reason why this thread started, is when you try encoding TFF sources (i.e. MPEG-2 DVD) to BFF targets (i.e. DV).

[rfmmars]

Richard, *that* script is the terrible bobbing way that you have been suggesting. I merely completed it for you. It is neither of the two methods that we have been telling you about. As I said quite clearly, I did not give you a script that implements my non-blurring method.

Here it is for you again:

1. Richard's terrible bobbing method -- blurs the video.

2. Crop a line off the top method -- no effect on the video.

3. Shift the field phase by one method -- no effect on the video.

Look, with my script, simple three lines, I have watched the original mini DVD played on the DVD player, no problem. Take that VOB and make a new DVD, no editing, serious strobing when panning or horizontal movement just as the person first posted. Take that same vob, apply the script, it now looks the same as the mini DVD, perfect. Nothing is done in the NLE except to burn.
It doesn't matter if you are using Vegas or what ever.

Because the lenth of the clip, the Huff format will yield too big of file to upload, I can give it to you in Leadtools,Morgan, or Mpeg2.

What would be your choice?

Richard

[Guest]

I'd like a fragment of the original stream, not transcoded to anything else. Just cut a piece of the original using DGIndex, perhaps (set range and then 'save project and demux video').

The original poster had MPEG2 and was making DV. So if he ran into an order problem, he had TFF MPEG2. So he needed to reverse the field order to make the BFF DV. Of the three methods of doing that yours is the least desirable. With your source MPEG2 clip I will demonstrate that.

[rfmmars]

I'd like a fragment of the original stream, not transcoded to anything else. Just cut a piece of the original using DGIndex, perhaps (set range and then 'save project and demux video').

The original poster had MPEG2 and was making DV. So if he ran into an order problem, he had TFF MPEG2. So he needed to reverse the field order to make the BFF DV. Of the three methods of doing that yours is the least desirable. With your source MPEG2 clip I will demonstrate that.

OK OK OK!

[rfmmars]

This is the Mini-DVD raw stream edited* These VOBs can not be copied/ripped like standard vobs, they will have most likey one or more CRC errors, so you must use a program that ignores them plus a good DVD drive to do this. Now there is another problem, you can not import these files into a NLE even "Video ReDo" without them being trancuated or wrong index, but they can be imported with Virtualdub(mpeg2) and Avidemux. Avidemux is where is sample was made. Since the the only way to get you the original is by snail mail on a DVD.

[link removed]

This is the VOB file from a good DVD burn made with the above clip and my posted script.

[link removed]

So have at it.

Richard





Still Editing

[Guest]

Richard, you can't use links to upload sites that display naked women!

Also, I never did get a download link after wading through tons of spam popups.

Use megaupload.com or rapidshare.de.

[rfmmars]

Richard, you can't use links to upload sites that display naked women!

Also, I never did get a download link after wading through tons of spam popups.

Use megaupload.com or rapidshare.de.

Sorry, will do. It was my first time using them.

Richard

[rfmmars]

The first is a Raw vob to huff 27 meg

http://www.megaupload.com/?d=UTUH9437

Next is the VOB made in AviDemux 2.7 meg

http://www.megaupload.com/?d=0FO1DQQ7

The last one is my burned VOB 880k

http://www.megaupload.com/?d=Q0BP7DHO

Richard

[SeeMoreDigital]

The first is a Raw vob to huff 27 meg

http://www.megaupload.com/?d=UTUH9437

Next is the VOB made in AviDemux 2.7 meg

http://www.megaupload.com/?d=0FO1DQQ7

The last one is my burned VOB 880k

http://www.megaupload.com/?d=Q0BP7DHO

RichardWhich one is your "camcorders" VOB source (ie: before you've done any processing/conversion)?

[wonkey_monkey]

Richard, how did you make the burned VOB? You used that AVS script as the input to some encoder, right?

David

PS Comparing the same frame from the raw and burned VOB, one field seems to show some vertical shift relative to the other in the burned VOB (in fact both reconstructed fields have been shifted vertically in the burned VOB - one by one [frame] pixel, and the other by two).

[2Bdecided]

If he didn't have 600+ posts already, I'd swear he was doing this to wind you guys up!

I mean, which part of "I'd like a fragment of the original stream, not transcoded to anything else. Just cut a piece of the original using DGIndex..." could be taken to mean "transcode it to another format"!?


Anyway, Richard, if you're sincere (and I'm sure you are), please understand that on an impersonal medium like a web forum, what you're doing could be misread as attempting to wind people up.

This place is full of techies who just like problem solving. If you post the original video, that gives people the problem, which is great. If you post your processed video, that only shows people your solution - but without the original problem to go with it, it's not even showing the full solution!

Cheers,
David.

[Guest]

I mean, which part of "I'd like a fragment of the original stream, not transcoded to anything else. Just cut a piece of the original using DGIndex..." could be taken to mean "transcode it to another format"!?
Richard did give some explanation about it not being a normal VOB, etc. I'd still like to see it, though. In the meantime, I can work with the HUFFY, which is TFF and still properly interlaced.

[bb]

I'm keeping an eye on this thread, and I'd be unhappy if I had to close it.

Please keep cool everybody, concentrate on the problem, and respect the forum rules!

bb

[Guest]

I want to explain theoretically why the bob() method is undesirable.

We start with TFF video (top fields on top line, bottom fields on bottom line):

a c e ...
b d f ...

Now we assume BFF and bob and end up with this (where the ' mark means that the field was created by interpolation during the bob() operation and the . mark means the original field):

b' a. d' c. f' e.
b. a' d. c' f. e'

Picture b is available only as a bottom field in the original stream, so it HAD to be interpolated to appear in a top field.

Now we reinterlace to produce this:

b' d' f'
a' c' e'

So every field has been degraded by interpolation! All of the original data is gone. But the field order has been reversed.

The other two methods we mentioned pass the original video through without interpolation.

Quod Erat Demonstrandum

[rfmmars]

Which one is your "camcorders" VOB source (ie: before you've done any processing/conversion)?

Its all in order,

It is not possible to give you a pure siliver of the original VOB. Video Redo can't handle it, it says use "Stream Fix", it fixes nothing.

The second is a small cut from from the Mini DVD, edited in AviDemux, I can't tell you if that program did a re-compress, ask the author.

The last one is the burned VOB taken from the DVD. It was made from the first or second clip, it doesn't matter. It is runned though that simple three line script and burned.

Richard, how did you make the burned VOB? You used that AVS script as the input to some encoder, right?

David

Here are the steps again.

1. The Mini DVD's .vob file in most cases can not be copied with a standard program, you need one that ignores CRC errors, I used "No Stopping Copy"

2. Now this .vob file can't be imported to most NLE or editors like
Video Redo, but has no problem with VD(mpeg2) or AviDemux.

3. I frameserved the section for test from VD(mpeg2) to that three line AVS script.

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

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

6. The last file listed is the final .vob of the burned DVD taken from that DVD, there is no strobing.

If there is a better script I want it, but all the posted lines of code do not solve the problem.

This place is full of techies who just like problem solving. If you post the original video, that gives people the problem, which is great. If you post your processed video, that only shows people your solution - but without the original problem to go with it, it's not even showing the full solution!

If you read my post, I am also telling you that it is not possible to post a sliver of this vob unless thats what AviDemux did.

I have taken what I have posted and made a corrected burn, thats file three.

Richard did give some explanation about it not being a normal VOB, etc. I'd still like to see it, though. In the meantime, I can work with the HUFFY, which is TFF and still properly interlaced.

The only way I see that possible is to seen you the complete VOB on a DVD

Its not me wound up, its you at this forum.

I don't have a problem, my script works.

richard

[Guest]

After showing in theory why Richard's method is so bad I now show it in practice. The top image is the unmodified original that you get if you use the field shift or line shift method. The one below is the one you get using Richard's method.

Field or line shift method:
http://neuron2.net/misc/good.bmp

Richard's terrible method:
http://neuron2.net/misc/blurred.bmp

I repeat, using Bob() to reverse field dominance is an abomination.

[Guest]

The only way I see that possible is to seen you the complete VOB on a DVD Any binary file splitter can be used. But it's not necessary because I have already proved your method to be an abomination. I was just interested to see this supposedly weird brand of VOB.

but all the posted lines of code do not solve the problem For the lines I posted, that's because they are for the BFF->TFF case and your situation is TFF->BFF. Anyway, as I said, that code is for your terrible method. I wouldn't wish it on my worst enemy.

Anyway, you don't need a script. Just use this filter, which implements the line-shift method:

www.geocities.com/siwalters_uk/reversefielddominance.html

So, do you have any technical comments on my clear and concise theoretical and practical demonstrations that show your bob() method to be an abomination?

[rfmmars]

Any binary file splitter can be used. But it's not necessary because I have already proved your method to be an abomination. I was just interested to see this supposedly weird brand of VOB.

For the lines I posted, that's because they are for the BFF->TFF case and your situation is TFF->BFF.

Anyway, you don't need a script. Just use this filter, which implements the line-shift method:

www.geocities.com/siwalters_uk/reversefielddominance.html

So, do you have any technical comments on my clear and concise theoretical and practical demonstrations that show your bob() method to be an abomination?

The big question, DID YOU BURN A DVD? Did it strobe.

I am done jumping though hoops for you people. Either burn a dvd with the files I posted, do your script, do mine, and compare. Then post the vob clip with your script, I will test it......if it works, I will comfirm, if it does, you are wrong in this matter.

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.

Richard

[scharfis_brain]

If everything fails to demux or split the vob, then you can just do a binary file splitting of the VOB file. (like split archives)

then upload a portion of that splitted vob.

we'll be able to examine it then.

[rfmmars]

If everything fails to demux or split the vob, then you can just do a binary file splitting of the VOB file. (like split archives)

then upload a portion of that splitted vob.

we'll be able to examine it then.

What you fail to understand is the ixdexing is different with this Sony Mpeg2 Mini DVD format, the indexing is the problem, how in the world are you going to find the right 10 frames out of thousands if you can't see them? If I can do the test, you can do the test with the posted files.

Richard

[Guest]

The big question, DID YOU BURN A DVD? 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.