What DVD2AVI Version Should I Baseline From?

[neuron2]

As part of a project to merge various lines of development, I need the DVD2AVI 1.76 source code, but cannot find it on the web. Does anybody have it? Thank you.

EDIT: As the thread has mutated, I have changed the title as appropriate. I have changes for the decoding that fix some longstanding problems and now I am wanting to make a merged version with (at least) transport stream handling, command line support, and my fixes. What is the best DVD2AVI version to start from? The choice appears to be between 1.77.3 and 1.83.6 at this stage. But I am open to other suggestions.

[RB]

I have it here, let me know where to upload or email. Also, the source for the DVD2AVI version with command line support is available at www.dvd2svcd.org.

[neuron2]

Originally posted by RB
I have it here, let me know where to upload or email. Also, the source for the DVD2AVI version with command line support is available at www.dvd2svcd.org. Great! Yes, I have the source for the CL version. I want the base 1.76 to do a diff between them.

Please mail it to me at donald.graft@st.com

Thank you!

[RB]

You've got mail :)

[neuron2]

Much obliged, RB. It has indeed arrived.

Tentatively, my plan is to take my fixes into trbarry's version 1.83.5 and then add command line support. Then we'll have a version with correct decoding, transport/HD support, and command line support.

What do people think of this plan?

[Siku]

Originally posted by neuron2
What do people think of this plan?

That sounds great! Keep up the good work! :)

Regards,
Siku

[Selur]

"What do people think of this plan?"
Sounds cool for me :)

Cu Selur

[KpeX]

Sounds excellent....keep up the great work Mr. Graft :D

[JuanC]

How about taking TBarry's and CLI fixes into 1.77.3? [list=a]
1.77.3 has fixed a DirectDraw problem (with 1.83.6 I have some problems previewing)
1.77.3 the VFAPI plug-in is functional, in 1.83.6 it's unavailable
1.77.3 has DTS treatment (at least demuxing)
1.77.3 has better GUI (simpler: 1.83.6 has some confusing glitches)
[/list=a]

[hakko504]

Originally posted by neuron2
Tentatively, my plan is to take my fixes into trbarry's version 1.83.5 and then add command line support. Then we'll have a version with correct decoding, transport/HD support, and command line support.

What do people think of this plan? Sounds excellent - and quite a lot like what I outlined yesterday (http://forum.doom9.org/showthread.php?s=&threadid=44150)... ;)

@Juan
I believe that Don's fixes were all made in the v1.77.3 codebase so you shouldn't worry about not getting full 1.77.3 compatibility :)

[neuron2]

Originally posted by hakko504
Sounds excellent - and quite a lot like what I outlined yesterdayYes. I have since discovered 1.83.6, which is apparently Nic's change to improve PID handling for transport streams.

I believe that Don's fixes were all made in the v1.77.3 codebase so you shouldn't worry about not getting full 1.77.3 compatibilityBear in mind that the changes I made to 1.77.3 affect only the D2V file generation; the built-in decoder was not touched, so it doesn't yet benefit from the redesign. Only the decoding in MPEG2DEC3 has so far been corrected. I plan to correct it in DVD2AVI as well, but not until the baseline version to use has been decided.

We have (at least) two options:

1. Start from 1.83.6 and fix the issues that JuanC has mentioned. As far as VFAPI is concerned, I don't even know what it is or what it is good for. Doesn't everyone use Avisynth/mpeg2dec3, and if not, why not?

2. Add the transport support and CLI support to 1.77.3.

I need guidance from the user community about which is the right way to go.

[hakko504]

Originally posted by neuron2
Bear in mind that the changes I made to 1.77.3 affect only the D2V file generation; the built-in decoder was not touched, so it doesn't yet benefit from the redesign. Only the decoding in MPEG2DEC3 has so far been corrected. I plan to correct it in DVD2AVI as well, but not until the baseline version to use has been decided.
My bad. Still I assume you are going to use this code as well in your final tool.

We have (at least) two options:

1. Start from 1.83.6 and fix the issues that JuanC has mentioned. As far as VFAPI is concerned, I don't even know what it is or what it is good for. Doesn't everyone use Avisynth/mpeg2dec3, and if not, why not?

2. Add the transport support and CLI support to 1.77.3.
I think you should use 1.77.3 as the base for your project, merging the changes from the various subprojects as needed.

vfApi I believe have a DirectShow wrapper where AviSynth only is VfW if I recall correctly. At least earlier it was a major point for using vfApi that there is more applications that can read vfApi files than there was applications that could read AviSynth. Also some apps would only read files named with *.AVI names and would chokle on *.AVS. I also recall AveryLee writing something in his news column a long time ago that he had to modify VD's AVI reader in order to make it accept AviSynth files properly. I do think that newer versions of AviSynth has solved some of these problems, becuase these days all apps I'm using can handle AviSynth properly.

[JuanC]

Could the use of 1.77.3 as baseline encourage Jackei himself to collaborate, in a similar way as Avery Lee does with VirtualDubMod? :cool:

It would be great to know Tom Barry’s opinion

I think VFAPI plugin should be preserved as it is a great interoperability mechanism with other great applications like TMPGenc and AVIutil. It can also be used in AVIsynth (it’s about 30% slower than MPEG2DEC3)

[neuron2]

@JuanC

Help a newb out. Give me a quick summary of how I would use VFAPI with DVD2AVI 1.77.3. Thank you.

I'm sure Tom will want the transport support, but I wonder if there is anything else in 1.83.5/6 that he would want to have included.

[Wilbert]

Help a newb out. Give me a quick summary of how I would use VFAPI with DVD2AVI 1.77.3. Thank you.
After installing readavs.dll, vfapi can read avs and d2v files.

Thus instead of

dvd2avi -> avisynth -> encoder

you can use

dvd2avi -> vfapi -> encoder

I never use it though ...

[neuron2]

Originally posted by hakko504
Still I assume you are going to use this code as well in your final tool.Yes. The timeline navigation would probably still have GOP granularity, but Preview and Save AVI would use the new approach.

[neuron2]

Originally posted by Wilbert
After installing readavs.dll, vfapi can read avs and d2v files.

Thus instead of

dvd2avi -> avisynth -> encoder

you can use

dvd2avi -> vfapi -> encoder

I never use it though ... OK but what code support is needed (if any) in DVD2AVI for this to work? If that reader DLL can read a D2V file why would JuanC have complained that it doesn't work with 1.83.5?

[trbarry]

I'm sure Tom will want the transport support, but I wonder if there is anything else in 1.8.5/6 that he would want to have included.

I think it's mostly transport stream support but save-oe originally started out being mostly P4 optimizations. I don't know the state of that in 1.77 but it's less important to me because I only frameserve to MPEG2DEC3 myself, so that's where all the heavy lifting is usually done.

I've never used VFAPI and know little about it.

- Tom

[neuron2]

Thank you, Tom. Can you please give a feel for how extensive the transport changes are and how I might go about isolating them for retrofitting to 1.77.3? Can I for example diff the initial versions of all files at save-oe against your release, or did the first source installed there already incude the transport support?

Regarding VFAPI and DVD2AVI, never mind. I figured out that you have to make a DVD2AVI.vfp plugin for the reader. The project for that is in 1.77.3 but not in 1.83.5.

[JuanC]

@neuron2: I’m just an occasional user of AviUtl and TMPGenc, but they benefit from the VFAPI codec, and in particular of the DVD2AVI VFAPI plugin. Personally, I would like to understand and master those tools (lots of filters for AviUtl for example that you can get but I don't understand anything in the included docs). I think we, at the western hemisphere, are missing great tools born at the eastern hemisphere, because of our language limitations, and vice versa. Anyway, the VFAPI plugin will allow those VFAPI codec aware programs to read MPEG2 video clips based on the d2v project. It is very easy (I can do it :)) to use it: you create a d2v project. When you open DVD2AVI it automatically registers the plugin, so that any VFAPI aware program would read the d2v project without any problem.

I’m just curious: (I have no idea) If you chose 1.83.6 as the baseline, would it be very difficult to reconstruct the project to build the plugin?

Also, about 1.83.6, taking in account what trbarry said, besides the transport stream support code, the modifications to the original DVD2AVI were mostly P4 optimizations, which I think are already included in 1.77.3, and would only be relevant to the VFAPI plugin users, not for the MPEG2DEC3 users.

So again, my vote is for 1.77.3 as baseline.

Thanks for your Great work. JuanC

[trbarry]

Thank you, Tom. Can you please give a feel for how extensive the transport changes are and how I might go about isolating them for retrofitting to 1.77.3?

Donald -

The change audit trail is mostly in CVS, with ATSC stuff added first in March 2002. The ATSC code is mostly in getbit.c which strips out the extra transport stream info and passes a regular MPEG-2 program stream to DVD2AVI main code. There is also handling of the ini file to read and store the PID numbers. Nic's version has even more advanced code for this plus some other enhancement IIRC.

There also have been a few ATSC fixes along the way and I'm not sure all have gotten into CVS. But a comparison of the version on my site (or Nic's, made from mine) vs an early save-oe CVS would surely show all of them.

I haven't worked on it for awhile and I'm afraid it's a bit hazy to me now. ;)

- Tom