Log in

View Full Version : Can Avisynth read the contents of DVD's?


ericfree
4th April 2006, 05:11
Is there an Avisynth script that can be written to frameserve the contents of DVD's?

I'm not concerned about reading the menus, just the video & audio itself.

I tried something simple:

DirectShowSource("V:\Eric\DiscImage\0\VIDEO_TS\VTS_01_2.VOB")

but I got the Avisynth error message:

"Evaluate: System exception - Access Violation
(F:\Eric\DVD.avs, line 1)"

Any way to make this work?

foxyshadis
4th April 2006, 06:00
DGDecode (http://neuron2.net/dgmpgdec/dgmpgdec.html)

tedkunich
4th April 2006, 15:49
Is there an Avisynth script that can be written to frameserve the contents of DVD's?

I'm not concerned about reading the menus, just the video & audio itself.

I tried something simple:

DirectShowSource("V:\Eric\DiscImage\0\VIDEO_TS\VTS_01_2.VOB")

but I got the Avisynth error message:

"Evaluate: System exception - Access Violation
(F:\Eric\DVD.avs, line 1)"

Any way to make this work?


If the disc is encripted (all comercial ones are), you will need to rip the disk to your HD first...

ericfree
13th April 2006, 07:06
I tried DGDecode. Interesting.

But you first have to take the time to run DGIndex and then store a pretty large audio file on your hard drive.

Then, with AviSynth, it works, playing back directly from the DVD disc inserted into the DVD-ROM drive.

But I was hoping for a way to avoid the step of having to run DGIndex, and especially avoid the step of storing a large audio file on the hard drive. I am writing a MediaPlayer app. that I would like to be able to read DVD discs (well at least non-encrypted ones) directly, and wouldn't want the user to go through all of these steps.

I want the decoded video to have full seeking capability -- which, using the DGDecode filter in AviSynth, works quite well.

Any ideas?

Mug Funky
13th April 2006, 08:50
for whatever reason (i don't fully understand it myself), mpeg files need to be parsed (quite slowly) in order to be frame accurate seekable.

however, if you invoke DGindex via CLI, you don't get the audio demuxed. you can also make it transparent to the user this way (however, that doesn't stop the ~8 minute wait before the disc plays...)

if you're making a player app, and want avisynth support, your best bet is directshow plus ffdshow's raw filter, which allows you to run simple avisynth commands on the fly (even on live video which is extremely cool. sadly you can't mix several video inputs this way, because that would rock really hard). only limitations to using avisynth within ffdshow is you can't change the output size, can't change the framerate, and can't (i don't think, anyway) use the conditional environment. think of it as working as a passive filter.

ericfree
14th April 2006, 03:00
Mug Funky says, "however, if you invoke DGindex via CLI, you don't get the audio demuxed. you can also make it transparent to the user this way (however, that doesn't stop the ~8 minute wait before the disc plays...)"

OK, so then where is the audio? I still need the audio to play along with the video of the DVD disc.

Mug Funky also said, "if you're making a player app, and want avisynth support, your best bet is directshow plus ffdshow's raw filter, which allows you to run simple avisynth commands on the fly"

So could I use this to playback the contents of DVD discs with complete seeking ability?

Ebobtron
14th April 2006, 05:26
Hank315 or neuron2 can explain this much better but the simple answer is Mpeg2 files are not always encoded in the order they are played, now I do not think you will find frame 200 near frame 2000 but they might be encoded 200, 202, 204, 201, 203. I am sure this example is poor but the decoder needs the frames before and after to create a given frame. In very simple terms, the decoder needs a chunk of data to create any given frame and determine its playback order.

DGIndex makes a file full of the needed navigation data and DGDecode.dll reads the d2v file. So if a seek is called for, the decoder knows where any given frames are and which chunk of data it needs to decode them.

The audio may be a history issue or maybe still, a speed issue, in order to play the file the two components of the file or possibly four or more components of the vob must be separated. Video, audio one, audio two, maybe audio three and subtitles are separate streams of data multiplexed into one file. Decoding the audio file out and saving as a wav(uncompressed / unencoded data) file , speeds thing up big time.

I added history above because I can assume that if DGIndex was started from scratch, today, the modern CPU speeds may have some influence that might alter the current makeup some, but that is an assumption not based upon a lot of fact.