DVD2AVI Sourceforge Project

[Nic]

My version isn't that special :) , but its what I wanted... The main problem is its fiddily :)

-Nic

[trbarry]

if you want to do audio better than anyone else (and probably correct for that matter), you'll have to compare the timestamps in the video- and audio streams (PTS) and align them continuously...

Do any of our common utilities even use the time stamps. I thought they all just assumed the video and audio records were evenly spaced in time. And maybe they are. (or not) ???

But I have still never studied any of the audio formats, so maybe there is time info there.

- Tom

[trbarry]

My version isn't that special , but its what I wanted... The main problem is its fiddily :)

Nic -

What is fiddily? Is that a musical/audio term? ;)

I'll bet it's special anyway. But you never release anything that is not already a show piece. It drives me nuts. :mad:

Will your new version do anything more with ac3 (undecoded) audio? Or should I get all crazy and attack this timestamps issue? I'm seriously considering it. But with my tin ear and total aversion to audio programming I'm really about the last person who should be working on it. :rolleyes:

- Tom

[Nic]

Fiddily = a bit sensitive & difficult to use ;)

No im not addressing the AC3 issue....Ive never used AC3 sound directly...(never had a good speaker set up :( )

Cheers,
-Nic

[ShinerSpoon]

All of us are a bit Fiddily, sensitive & difficult so your test build would be perfect for us to play with. Please consider letting us have a look at it. We all know it is just a test in progress.

Come on, Nic, "give it up" for the group and show us your beef! :)

[trbarry]

I have a $190 Pioneer A/V Receiver that I picked up at a local CostCo. It came with inexpensive speakers, but there are 6 of them. ;)

I of course can't tell the difference and my friends probably would lie to me about it since they know that I can't tell.

But it allows me to use only spdif out and offload all audio processing. On a slower computer this made a difference playing DVD's.

But mostly, whenever I process sound from one format to another it seems I increase my HDTV sound sync problems. I'm guessing they result from the various garbage frames in HDTV recepton or maybe that HDTV streams don't start on the same boundaries that DVD2AVI expects.

But I've totally failed at talking anyone else into it so I guess I'll try to finally figure out what is really going on here.

- Tom

[DSPguru]

Originally posted by trbarry
Dg -

Actually I don't mind sticking to ac3 at all but then I can't automatically have DVD2AVI put it into Xvid. And there is something peculiar about my ATSC HDTV captures that seems to often make the audio sync wrong if I add it later using Nandub or Vdub_ac3.

Just using the DVD2AVI Delay parm written into the name doesn't seem to get it sometimes.

Someday I will absolutely force myself to learn how audio works. ;)

- Tom sorry, can't help you with video issues. only audio here.. :).

[vlad59]

I'm currently trying to add some other IDCT function to Save-oe (there was so many program using differents IDCT, I'm trying to find other good one in Xmpeg, Mpeg2avi, dvdx, ...)

Farok has already made a DVD2AVI with an optimized Athlon 3DNow IDCT (it use the cmov?? instruction so I can't test it on my K6II). Can someone test it for me to check if it's faster than the MMX/SSE one. You can find the program at :
http://profmegot.free.fr/dvd2avi
If it worth it I'll add it in save-oe.

@trbarry : I found that DvdX has also a P4 optimized IDCT, you can find the sources in Doom9 downloads. It may interest you.

[trbarry]

@trbarry : I found that DvdX has also a P4 optimized IDCT, you can find the sources in Doom9 downloads. It may interest you.


vlad59 -

I think that DmitryR's P4 IDCT that I already put in save-oe and mpeg2dec already resulted in a pretty good speedup. I probably won't be testing others unless there are reports they are special somehow. But thanks.

- Tom

[Rauli]

Originally posted by trbarry

But mostly, whenever I process sound from one format to another it seems I increase my HDTV sound sync problems. I'm guessing they result from the various garbage frames in HDTV recepton or maybe that HDTV streams don't start on the same boundaries that DVD2AVI expects.

I have the same problem with DVB recorded mpeg2. I get sync issues when i encode the mpeg2 to divx. The reason as far as I can tell is that there are video frames missing from varios places. DVD2AVI gives a correct delay for the audio but it doesn't help with the frames missing from the midle of the mpeg2 file. I suppose DVD2AVI just ignores the missing frames instead of dublicating last good frame and the result is a shorter video file than the audio file. If I use Instrumento to correct the mpeg2 the sound will be in sync but its done by cutting audio since there are video frames missing. If I use WinDVD to play back the mpeg2 file it plays back fine without sync issues.

[eclipsedvd]

I'm very happy to see how the work progress!

Has anyone looked at the DVD2AVI PFN sources?
- There is IFO Parsing and others good features.

Nic, When will you release your version?

[maven]

windvd correctly uses the timestamps throughout, dvd2avi only aligns audio & video-streams at the start of the stream.
that's the root of the problem.
FairUse tries to do this but more often than not seems to fail (15GB ac3-files etc.).

[trbarry]

I'm somewhat convinced by all the above comments that the solution is to honor the timestamps somehow. But I don't know enough about it to decide whether it is necessary to duplicate video frames or if the problem can be corrected just by interleaving the sound correctly.

For instance, suppose during playback there was only 1 second of video in the file where there was 2 seconds of sound. How do the decoders handle this?

I suppose this is probably described in some documentation for avi files somewhere but it is a process I don't understand.

- Tom

[int 21h]

Originally posted by trbarry
I'm somewhat convinced by all the above comments that the solution is to honor the timestamps somehow. But I don't know enough about it to decide whether it is necessary to duplicate video frames or if the problem can be corrected just by interleaving the sound correctly.

For instance, suppose during playback there was only 1 second of video in the file where there was 2 seconds of sound. How do the decoders handle this?

I suppose this is probably described in some documentation for avi files somewhere but it is a process I don't understand.

- Tom

In AVI files, audio duration and video duration must be the same, or else the file will play out of synch. The reason WinDVD plays Rauli's files correctly, is as Maven said, it aligns timestamps throughout the entire file. Meaning, it automatically skips audio frames that don't have a corresponding video frame.

So, what you need to do, is run through compare video timestamps to audio timestamps, make sure they all match, and if there are any missing, either cut audio, or add a frame with the correct timestamp (to keep synch). This has to be done before converting to AVI, because.. AVI needs to be equal audio and video durations. I think the easiest thing to do would be to compare all of the timestamps, then if you get to a place where an audio timestamp exists with no matching video timestamp, just interpolate between the two frames.

Of course, you have to make cases for more than 1 frame missing too...

This could get very messy :p

Good luck in any event.

[ShinerSpoon]

Can someone test it for me to check if it's faster than the MMX/SSE one.

vlad59,
I don't have any hard data for you guys but I did try several different versions, one of which was the Farok version with its 3d optimized setup. I have a TB 1.4 pushed up a bit.

None of them kept up with the version Tom provided above. On pass 2 of Divx5 it yielded avg 38.1 with a inst of 42.2. In the short tests I did it was clear to me that using the 32 bit sse mmx was my winner. I wonder if trying to find a faster algo is a wild goose chase? I seem to remember that was the consensus a long time ago when many people, including Jakie, tried.

[trbarry]

As far as frameserving to Avisynth I think DVD2AVI is approaching a point of diminishing return on performance. Though individual filters in Avisynth like BicubicResize could still be optimized some.

But I think there still could be an interesting gain for the case of calling Xvid directly from DVD2AVI. It would involve cropping and resizing in the native YV12 color space and passing that directly to Xvid which also uses that, without any unneeded color space conversions.

- Tom

[Selur]

yeah, Yv12 support would be cool :D
(I love Xivd)

Cu Selur

[gizmau]

i just compared mpeg2dec2.dll (idct=2, .d2v-cropping, avisynth/bicubic/addborders) against mpeg2dec.dll 1.05 (idct=2, no cropping, avisynth/bicubic+cropping/addborders).
the new version from tbarry gave me an speed advantage of 8% to 9,2% in average on my athlon 1333C.

i expect another speed increase by implementing the 64bit-athlon-idct.
will there be an implementation soon?

[int 21h]

Originally posted by gizmau
i just compared mpeg2dec2.dll (idct=2, .d2v-cropping, avisynth/bicubic/addborders) against mpeg2dec.dll 1.05 (idct=2, no cropping, avisynth/bicubic+cropping/addborders).
the new version from tbarry gave me an speed advantage of 8% to 9,2% in average on my athlon 1333C.

i expect another speed increase by implementing the 64bit-athlon-idct.
will there be an implementation soon?

Uh, the 64bit IDCT would not yield a higher performance because of the increased precision of the process.

[gizmau]

thanks, just realised the mistake :^(

the differences in quality between 32bit and 64bit are mainly theoretically or at least nearly not visible. (right?)
will the 64bit-athlon code offered in order to get this bit more quality at the same speed?

and whats up with optimizing the bicubic resizer, as stated in one of the posts?

[int 21h]

The difference is imperceptible. The only reason to even leave the original MMX SSE IDCT that we've been using for at least a year now, is the increased speed that can be gained by using prefetch instructions for SSE2.

So.. the difference between 32bit and 64bit, assuming they both are decoding correctly within their specified precision, is entirely not visible.

[vlad59]

I made some modifications on Trbarry's test release to add somme SSE and 3dnow code in the motion compensation function (for K6 (I'm the last one to use this CPU), Athlon, Duron and P3). Tom has already added an optimized one for P4.
I got a 4% increase in speed on my PIII-750 and 7% on my K6II-400.

I couldn't see any quality issue.

I've uploaded a 3Dnow release wich should work on K6, Duron, Athlon and a SSE release wich should work on PIII, Duron, Athlon.
I hope somebody with an AMD CPU could test both release to tell me if there is any differences between them.

As soon as I receive confirmation for that increase, I'll add my changes to mpeg2dec.dll as well and publish the sources.
And If Tom agree with that i will upload the DVD2avi sources in CVS (as soon as I understand how I can upload some files), but I still don't know what to do with mpeg2dec.dll sources.

I hope it won't crash your computer ;)

PS : I've also added to my test release a 16bits MMX IDCT : it's actually slower than the 32Bit MMX IDCT. I'm still trying to optimize it. I won't merge it in CVS.

EDIT : Attachment removed because the code wasn't accurate enought.

[trekminal]

Originally posted by vlad59
I made some modifications on Trbarry's test release to add somme SSE and 3dnow code in the motion compensation function (for K6 (I'm the last one to use this CPU)

You're not alone. I'm using a K6-2/500 CPU to make my divx movies (two nights-two passes) :sly:

[vlad59]

@trekminal
I made my first rip on this K6II, three years ago !! I remember it was Devil's advocate and it takes me a week to understand how to use mpeg2avi, it was fun.

Have you tried my Dvd2avi3d.exe ???
You can only try it with the Save Avi option. Mpeg2dec.dll (to use avisynth and vdub) will follow as soon as I get some feedback.

[trbarry]

vlad -

Nice going. I guess if nobody else objects we should just make a mpeg2dec folder and VS6 project inside save-oe and check the newest version into there. But that way we could add features like yours to both mpeg2dec and dvd2avi at the same time in a more syncronized fashion.

But I don't know if it takes a save-oe admin to be able to do that. I'm not one myself.

But my own current source for mpeg2dec.dll is still at www.trbarry.com/mpeg2dec2.zip and the dvd2avi source is in Sourceforge.

Anybody else have any opinions on how to proceed in this?

- Tom

edit: Yes, by all means, check in the dvd2avi changes, unless they would set a 'save project' idct code that no current mpeg2dec.dll could handle yet.

[dividee]

You're right, mpeg2dec should be merged in the save-oe tree. Tom, I see you're working with a version that include my filters. They probably should be removed before merging.
The fact that I included them in the mpeg2dec dll has caused some confusion. It was probably not a good idea in the first place.

I tested your version on my Athlon XP (IDCT=2, of course). No gain. Are you optimizations exclusively for P4 ?

[Antimon]

OK....Talk to me in lamen terms here hehe :-)

I have an AMD athalon 1.2 clocked to 1.26 *200 fsb* 512 meg ddr, curentl;y using nics version of dvd2avi and always usign the ieee 1180 refrence idtc cus it has nto failed me and if fast...but it seems no one else uses it and always says to use the 32 or 54 bit mmx ones sooo,

whats wrogn with iee and which one shoudl i be using, also are any pof the numersoue optimisations out there worth switching too....? is it possible to use other idtc patces whiel mantaining the function of nic's dvd2avi *automated 2 pass rocks!*

my current reults *pre nic's version using the latest official 1.86*

Are they on par.....or am i missing out on somthing

Thsi is savign right out of dvd2avi no filters.

this si a native dvd vob sorce and i was saving at 720x304 soft bicubic resize to corect AR

| | No Luma adj | Luma Gain +50 |
| | Pass 1 | Pass2 | Pass1 | Pass2 |
| | fps | Time | fps | Time | fps | Time | fps | Time |

| Divx 5 | 15-17 | 4:21 | 20-23 | 3:19 | 14-17 | 4:36 | 20-22 | 3:26 |

| Divx 5.01 | 16-19 | 4:10 | 23-25 | 2:57 | 15-18 | 4:23 | 22-24 | 3:09 |


Is the use of the pre command such a bad thing.....:-)

[gizmau]

i compared dvd2avit3 (by tbarry) against t4 (by vlad59).
dvdsource with 704x576 (div32...) 3650frames, divx501 1pass 2500kbit, huffyuff 2.11, no resize.

divx501 huff
1.83 (tbarry T3) 32bit 3:25 2:22
1.83 (vlad T4 SSE) 32bit 3:24 2:21
1.83 (vlad T4 SSE) 16bit 3:26 2:22
1.83 (vlad T4 3Dnow) 32bit 3:24 2:21
1.83 (vlad T4 3Dnow) 16bit 3:26 2:22

as to be seen, on my athlon1333c the t4-version with 32bit is fastest, no matter if sse or 3dnow was used.

i hope this will soon beeing inplemented in mpeg2dec.dll :D

btw: whats up with resized frameserving via mpeg2dec.dll, which 'will still ignore resize parms' as stated by tbarry on page10? propably this could give a major speedup, i think.

[trekminal]

To vlad 59:

Have you tried my Dvd2avi3d.exe ???
You can only try it with the Save Avi option. Mpeg2dec.dll (to use avisynth and vdub) will follow as soon as I get some feedback.

Yes I don't use Avisynth, only the dvd2avi "Save Avi" feature. ;-)

Benchmarks (1500 frames 640x288, 900 bitrate, bilinear MMX first pass, bicubic second pass, divx 5.01, no audio, yuv color space. iDCT 32 bit MMX):

1.82 OGO version:
first pass: 11:12 min
second pass: 7:59 min

your 3dnow version:
first pass: 11:01 min
secons pass: 7:52 min

:cool:

[-h]

Just noticed this thread.

From memory, DVD2AVI doesn't use mmx dequantization or memory transfers - is there any movement in this regard? Certainly the iDCT uses a fair chunk of decode time, but dequantization can benefit greatly from being parallelized. I believe ffmpeg has some mpeg2 dequantization mmx routines already written that shouldn't be too hard to graft on.

Also, avoiding the YV12 -> YUYV -> YV12 conversion would speed things up too, however the codec (say.. XviD ;)) would have to support this. If it doesn't already? I haven't checked..

-h

[trbarry]

-h

For awhile I was running a free trial version of the Intel vTune utility. IIRC, the form predictions, IDCT and color space conversions were the worst offenders (and resize when used) but at the time I still didn't know what dequant was. I've never looked at (or recognized) the code in DVD2AVI that does this. But when I get back on DVD2AVI again I'll go look for it.

So far, the form_prediction and IDCT have been optimized and Dr. Frankenstein has offered some P4 color space conversion code. And it was looking at the DVD2AVI (from Avisynth) resize code that caused me to create SimpleResize. I tend to skip around like that.

If you happen to notice ( ;) ) whether Xvid could accept an input file that was in YV12 format it would be useful. The real trick to optimizing color space conversions is of course to not do them.

- Tom

[philippas]

I think because divx4 worked with xmpeg with YUV12 colorspace, xvid should work too.

[Selur]

hmm,.. Xvid works fine if u use Xmpeg in Yv12 mode

Did some speed tests a while back with Xmpeg and different settings:
(maybe they help and I'm not just blowing up the post ;))

(dual Athlon MP 1800+, Win2kpro, 512MB RAM)
Settings:
720*576
Input :16:9
Output: 1:1
keep aspect ratio: on
(kein audio)
gecroppt auf:704*400
(Display Output: off)

Codec: Xvid (2pass 1st pass)
(Nic's build vom 20.03.02)

RGB:
Bressenham ca.35.5, CPU-Last: 100%
Nearest Neighbour, ca.35fps, CPU-Last: ca.95-100%
Bilinear, ca.23fps, CPU-Last: ca.80-85%
MMX Bilinear, ca.26fps, CPU-Last: ca.80-85%
BiCubic, ca.9.4fps, CPU-Last: 65-70%
SSEBiCubic, ca.21fps, CPU-Last: 75-80%
Pseudo BiCubic, ca.24fps, CPU-Last: ca.80-85%

YUY2:
Bressenham ca.44.7fps, CPU-Last: 100%
Nearest Neighbour, ca.44fps, CPU-Last: ca.90-95%
Bilinear, ca.27fps, CPU-Last: ca.75-80%
MMX Bilinear, ca.31fps, CPU-Last: ca.70-75%
BiCubic, ca.10fps, CPU-Last: 60-65%
SSEBiCubic, ca.26fps, CPU-Last: 75-80%
Pseudo BiCubic, ca.24.7fps, CPU-Last: ca.77-85%

Format: YV12
Bressenham, ca.47fps, CPU-Last: ca.90-100%
Nearest Neighbour, ca.46fps, CPU-Last: ca.100%
Bilinear, ca.28fps, CPU-Last: ca.80-85%
MMX Bilinear, ca.30fps, CPU-Last: ca.70-75%
BiCubic, ca.10fps, CPU-Last: 60-65%
SSEBiCubic, ca.26fps, CPU-Last: 70-80%
Pseudo BiCubic, ca.29fps, CPU-Last: ca.77-85%


As u can see it didn't gave me allways such a BIG improvement to go for Yv12, but normally a 8%+ speedup was there,...

Cu Selur

Ps.:
with DVD2AVI 1.86 I normally get something about 22-31fps depending on the resize precission and iDCT options,.. (never made some real tests there, atm I'm mainly using v1.76+avisynth for frameserving)

[-h]

For awhile I was running a free trial version of the Intel vTune utility. IIRC, the form predictions, IDCT and color space conversions were the worst offenders (and resize when used) but at the time I still didn't know what dequant was. I've never looked at (or recognized) the code in DVD2AVI that does this. But when I get back on DVD2AVI again I'll go look for it.

The bitstream stuff would also be having a large impact on speed (not sure if vTune would pick that up), decoding would be faster if a bitstream lookup table was used for the coefficients (ala XviD ;)). I think ffmpeg is already doing this in its MPEG2 decoding code. This should definitely aid decoding speed since we're looking at a *lot* of bitstream hits due to the high bitrates you see in DVD video.

So far, the form_prediction and IDCT have been optimized and Dr. Frankenstein has offered some P4 color space conversion code. And it was looking at the DVD2AVI (from Avisynth) resize code that caused me to create SimpleResize. I tend to skip around like that.

Yep, sounds like all that needs doing is bitstream and dequant then.

If you happen to notice ( ;) ) whether Xvid could accept an input file that was in YV12 format it would be useful. The real trick to optimizing color space conversions is of course to not do them.

It does indeed, but it assumes the input resolution is a multiple of 16 (horizontally anyway).

-h

[trbarry]

Selur -

Useful results, probably not far from what I'd expect. Maybe even a bit better than I would have thought. But at least some of the resize's are slower and awkward in YUY2.

-h -

The bitstream stuff would also be having a large impact on speed (not sure if vTune would pick that up), decoding would be faster if a bitstream lookup table was used for the coefficients (ala XviD ). I think ffmpeg is already doing this in its MPEG2 decoding code. This should definitely aid decoding speed since we're looking at a *lot* of bitstream hits due to the high bitrates you see in DVD video.

If you mean the various GetBits functions that parse the mpeg2 stream I don't remember them showing up as a problem. But they are mostly inlined and I did not turn off inlining for at least some of my testing. I can't remember now.

It does indeed, but it assumes the input resolution is a multiple of 16 (horizontally anyway).

I seem to remember promising on the Xvid forum that I'd fix that part myself if nobody else did, at least for the input color space conversion.

- Tom

[A_Pleite]

Originally posted by Selur
...
Bressenham ca.35.5, CPU-Last: 100%
...
MMX Bilinear, ca.26fps, CPU-Last: ca.80-85%

...

Bressenham ca.44.7fps, CPU-Last: 100%
...
MMX Bilinear, ca.31fps, CPU-Last: ca.70-75%

...

Bressenham, ca.47fps, CPU-Last: ca.90-100%
...
MMX Bilinear, ca.30fps, CPU-Last: ca.70-75%
...


I never thought Bressenham is so much faster than bilinear-resizing. What about including that to DVD2AVI?

A_Pleite

[Selur]

The funny thing is that Xmpeg's Bressenham popup message sais:

"Bressenham: Resizer of DVD2AVI.Fast, very good quality, but don't upscale."

Cu Selur

[A_Pleite]

don't upscale - I never upscale, but
:confused: :confused: :confused:

[Chibi Jasmin]

Originally posted by vlad59
I made some modifications on Trbarry's test release to add somme SSE and 3dnow code in the motion compensation function (for K6 (I'm the last one to use this CPU), Athlon, Duron and P3). Tom has already added an optimized one for P4.
I got a 4% increase in speed on my PIII-750 and 7% on my K6II-400.

I couldn't see any quality issue.

I've uploaded a 3Dnow release wich should work on K6, Duron, Athlon and a SSE release wich should work on PIII, Duron, Athlon.
I hope somebody with an AMD CPU could test both release to tell me if there is any differences between them.

As soon as I receive confirmation for that increase, I'll add my changes to mpeg2dec.dll as well and publish the sources.
And If Tom agree with that i will upload the DVD2avi sources in CVS (as soon as I understand how I can upload some files), but I still don't know what to do with mpeg2dec.dll sources.

I hope it won't crash your computer ;)

PS : I've also added to my test release a 16bits MMX IDCT : it's actually slower than the 32Bit MMX IDCT. I'm still trying to optimize it. I won't merge it in CVS.

I didn't get to do any testing myself with your version, but the few others that tested seemed to confirm an improvement...May I kindly ask for the MPEG2DEC.DLL out of it?

[vlad59]

@Selur
I think that the bressenham resize of Xmpeg comes from mpeg2avi and not from Dvd2avi.

@trekminal and Gizmau
Thanks for the bench you've made.

@Chibi Jasmin
In fact, when I first tried to add cleanly my optimized form_component_prediction, I lost my speed improvement. So I've been obliged to play a little more with the sources to keep this speed. Now I got a faster and cleaner Dvd2avi than my former T4 release (2 exe files).
I'll try to add it to mpeg2dec.dll (I never even read those sources at all) as soon as I can. Friday, I hope that everything can be on CVS.
Be sure that I won't go away with my modifications ;)

[Chibi Jasmin]

Thanx a lot, can't wait for your T5-Version including mpeg2dec.dll :-)

But as I am myself not into programming, I don't have any CVS-stuff installed, hope you will provide some binaries to download...

Thanx in advance!

I am glad, people are working on DVD2AVI and MPEG2DEC...although I have nothing to contribute...

[gizmau]

> Friday, I hope that everything can be on CVS.

:) it's like xmas - even more faster encoding...

[Chibi Jasmin]

There are some mpeg2dec.dll versions from Steady around...dated later than dividee's...anyone knows about the changes in these ones and which version they are based on?

[A_Pleite]

I think it should be possible to do the yuv-yv12 and resizing in one algorithm.
If I remember right, yuv has 8 bits for each pixel each colorpipeline (or however you call it), while yv12 has 8 bits for each luma-pixel but just 8 bits for 4 chroma pixels (so you have 8bit + 2bit + 2bit = 12Bit).

I think it should be possible to resize the lumapipeline to the resolution you want, but the chromapipelines to the half resolution (x/2 and y/2). I think it even should be possible to resize the lumapipeline with bilinear,softbicubic or bicubic, while the chroampipeline is resized with bressenham (or however).

Just a Suggestion ;)

A_Pleite

Edit:
and I remember right, yuv is 1:1:1, while yv12 is planar 1:2:2
-> see http://www.webartz.com/fourcc/fccyuv.htm

So, the chroma (saturation and hue) could be resized to the the half resolution of the resized luma in one algorithm, even with different resizing methods, right?

[Jubijub]

Dunno if this has been posted yet on the topic (too long to be readed to now)...

I use DVD2AVI like this :

Rip with wathever you want ;)
Creation of a dvd2avi project (no changes, just creation of the project)...
Ac3-->Mp3 lame with besweet or the other one, I'm testing ;)
Using AVIsynth 1.05 from videotools as a frame server
Setting up my divx using Gknot 0.23
encoding with Vdub

and it works well

so

I would like you to keep enabled the ability to export .d2v files...

I've read in the topic that you would like to make a all-in-one...
I'm not fond of that idea, because vdub/nandub are very advanced tools, very optimized...it'll take too much time to reach the same quality, and I'm not sure it worth the try.

But if possible, I think that would be interresting :
- making dvd2avi to be able to be the last operation before lauching vdub...which means being able to make the avisynth script, the bitrate calculation, quality, in fact, all the "bitrate" and "resolution" pages of gknot do...
- no need to improve sound features...with softs ables to make AC3-->[format that you want], you no longer need normalized wav...
- no need to include subtitles fonctions...subrip and other tools make all you need...

the fact is I prefer a tool that do only a few things, but is the best at doing them rather that a tools that is able to do the complete process and which is a complete shit...

[Nic]

Well one thing...Dont swear.

Secondly, if your happy with what you do then do it that way.

& my program, can be used for any part of the process. If you just want to convert your vobs to MP3/AC3/WAV/MP2 then thats fine. If you just want the AVS file & D2V file created, thats fine too.

& the quality & speed is exactly the same (actually slightly faster on 1 cpu systems) than avisynth->vdub. So I hope you like what ill try to achieve....& if you dont, dont use it :)

Cheers,
-Nic

[Chibi Jasmin]

Well, for me the reason not to use DVD2AVI for everything until now has been that there's no free resizing/cropping...it's always restricted to mod 8 or mod 2 etc. Of course you have to respect mod 2 horizontally for yuv2 colorspace, but apart from that I'd prefer to be free...

[Chibi Jasmin]

Originally posted by vlad59

Now I got a faster and cleaner Dvd2avi than my former T4 release (2 exe files).
I'll try to add it to mpeg2dec.dll (I never even read those sources at all) as soon as I can. Friday, I hope that everything can be on CVS.
Be sure that I won't go away with my modifications ;)

It's Friday :-) ...

[Nic]

Thank god its friday....
(My version uses a minimum of mod2 on all sizes(cropping & resize)(you can set the h-mod, v-mod))
(no mod1..the resize filters in avisynth can crash out on that)

So hopefully you'll like it Jasmin :)

Cheers,
-Nic

[vlad59]

@Chibi Jasmin
Yes it's friday, I'll try to merge my Dvd2avi sources on CVS tonight (I never done that before).
I'll upload a Dvd2avi.exe in the forum too. :D

But I've had no time to modify Mpec2dec.dll (it's written in C++, so it's not just a copy paste of getpic.c as I first thought), so this will be done later (ASAP). :rolleyes:

Next week I'll be on holiday, but my wife won't appreciate if I go away again with my laptop ....... :devil:

So I'm sorry but no new Mpeg2dec build from me till next week. :(

@Nic
Have you already added Tom's SimpleResize in your Dvd2avi ?
Have you done a simple changelog, just to make usefull changes ?

PS : Weekend is coming : it's smiley time