View Full Version : DVD2AVIdg Version 1.3.0 with transport inside! [final]


Guest
12th May 2004, 00:45
Here is DVD2AVIdg/MPEG2DEC3dg Version 1.3.0 final:

http://neuron2.net/fixd2v/decodefix130.zip

Version 1.2.0 will not be formally released.

This version fixes Moitah's seeking bug and Boulder's malformed field picture stream problem, adds *.mpg to the open filter, and provides the latest MPEG2Dec3 help file. It also adds transport stream support for ATSC transport streams. It should have functionality like Nic's version (I borrowed much of his code -- thanks Nic!). There is reliable PID detection and the ability to set the PIDs through the menus, INI file, or CL.

Notes: A file is taken to be a transport stream if its extension is .ts, .tp, or .trp (this may change). PID entry is in hexadecimal.

My intent is to support additional transport formats. But if you want your favorite format supported you have to be willing to help me by pointing me to specs and providing test streams.

Have at it boys and girls!

Guest
12th May 2004, 03:24
Whoops. I forgot to write the PIDs into the D2V so MPEG2DEC3dg can get them. Without that only 0x11/0x14 worked. Here is beta 2, which fixes that:

http://neuron2.net/fixd2v/decodefix130beta2.zip

Moitah
12th May 2004, 03:49
Working good so far, thanks for the seek fix.

Guest
12th May 2004, 04:12
Originally posted by Moitah
Working good so far, thanks for the seek fix. Good to hear it, Moitah. Thank you for all your excellent feedback and suggestions.

Zep
12th May 2004, 06:05
Originally posted by neuron2
Whoops. I forgot to write the PIDs into the D2V so MPEG2DEC3dg can get them. Without that only 0x11/0x14 worked. Here is beta 2, which fixes that:

http://neuron2.net/fixd2v/decodefix130beta2.zip


no go here. Crashes or freezes when trying to read a .tp file

no preview or anything. I have to use task manager to shut it down.

PIDS are correct so that is not it.


yes I will try to make a small clip


Do you have a server i can send clips to directly?

Guest
12th May 2004, 06:10
Originally posted by Zep
Do you have a server i can send clips to directly? I'll PM you.

CruNcher
12th May 2004, 06:45
Ah btw Donald what bugs me since the first dvd2avi could you please change the preview display of Avg.Bitrate to a numerical one i dunno who can interpret this bar ;)

Guest
12th May 2004, 06:53
@Zep

The problem is that the stream type is not set when you drag and drop. Open through the menus. I'll fix it in the next beta.

@Cruncher

Sounds good. Put feature requests in the "Development" thread started by Cyberia. These beta threads are for FEEDBACK on the posted binaries.

THANK YOU!!!!!!!!!!!!!!

Guest
12th May 2004, 07:20
Beta 3 fixes drag and drop open for transport files:

http://neuron2.net/fixd2v/decodefix130beta3.zip

EDIT: Also note that PID entry is in decimal!

Zep
12th May 2004, 08:54
Originally posted by neuron2
Beta 3 fixes drag and drop open for transport files:

http://neuron2.net/fixd2v/decodefix130beta3.zip

EDIT:
Also note that PID entry is in decimal!


It was the PID decimal that bit me in the a$$ :D


I'm not kidding when i say i have done hundreds of .ts .tp
encodes (maybe over a thousand even) and hex PID numbers are 100%
instinct. as an example

FOX 21/24
ABC 11/14
etc...

flies out of my head.



with decimal i have to stop and think about it HAHAHA


of course now i know why 17/20 was in the PID input window
on first launch hehe


Can you make it an option for which way to use?




a huge thanks it is looking real good!

vispgraedde
12th May 2004, 10:24
Have a short clip here that I first do preview on. Coded # 50, Playback # 50.

Without doing anything else in between, I save project, and the Information window changes to Coded # 50, Playback # 51.

Minor issue that is just confusing.

Doing Play after this, the Coded changes to 0, and the Playback increase by one for each time I press Play.

Guest
12th May 2004, 13:34
@Zep

OK. I will do something about the numbering. I just thought Joe Six-Pack doesn't know what hexadecimal is!

@visp

Thanks. I'll correct that.

@all

Regarding speed:

Preview is much slower because I use Windows call for resizing. Stupid. I'll fix that.

Save Project is faster by about 13/8.

Decode in Mpeg2dec3dg is the same.

Boulder
12th May 2004, 15:43
Originally posted by neuron2
Boulder's malformed field picture stream problem

I can confirm this one fixed, thanks!

Guest
13th May 2004, 04:59
Here is beta 4 with these fixes:

http://neuron2.net/fixd2v/decodefix130beta4.zip

1. Preview speed is much faster since Windows resizing is avoided.

2. Now uses hex for PIDs.

3. Strange playback number after Play at end of stream repaired. It now replays the last GOP and gets the numbers right.

My priorities now are:

1. Speed -- Zep is complaining.

2. Upsampling issues.

3. PVA support.

Wilbert
13th May 2004, 10:56
http://forum.doom9.org/showthread.php?s=&postid=491183#post491183

Sorry for posting in the wrong thread :) perhaps not a bug.

len0x
13th May 2004, 11:45
I'm looking at the d2v project (1.3.0) created from CLI and GUI and see that iDCT_Algorithm line differs on my PC. I always get 2 (SSEMMX) from CLI and 5 (SSE2MMX) from GUI. Is CPU detection not the same for both cases?

Dallemon
13th May 2004, 12:29
just wanted to say that the change from 100 to 130b4 the speed has increased (approx 10 secs), except for the files have been b0rked ever since i changed from the original 1.77.3 :/ *goes hunting for possible solution*

i just tried the original 1.77.3 and the d2v works fine again :S
with 130b4 mpc would just say "cannot render the file" and if i put the d2v in an avs it just says "unrecognized error" no matter what i open it with, also the 130b4 version is 515kb where as the 1773 is 335kb

Guest
13th May 2004, 13:47
Here is beta 5:

http://neuron2.net/fixd2v/decodefix130beta5.zip

This one fixes a rather serious bug. The index location was getting truncated at 32 bits, even though I used 64 bit ints. It seems that if you do arithmetic on an _int64 with normal ints, it gets demoted to an int!!! So I had to put a cast in there. The effect would have been that any file bigger than about 2GB would give you grief. Now it is correct.

@Wilbert and len0x

I'll look at these issues.

@Dallemon

The D2V file format is different, so applications that used to be able to open D2Vs now no longer can do so. You'll have to serve through Avisynth or VFAPI. Post your script if you are having Avisynth problems.

Zep
13th May 2004, 15:55
Originally posted by neuron2

My priorities now are:

1. Speed -- Zep is complaining.



problem found


dg version version setup and d2v project on test clip

with just a 1 line script

mpeg2source("d:\336dg.d2v")

i get 41 FPS preview in VDUB (fast recompress)

Now Add SelectEven() to script to cut the 59.94 FPS
down to 29.7 and FPS tanks to 4 FPS. OUCH :)



Now for the nic/trbarry version setup and d2v project on
the same test clip of course

with just a 1 line script

mpeg2source("d:\336.d2v")

i get 41 FPS preview in VDUB (fast recompress)

Now Add SelectEven() to script to cut the 59.94 FPS
down to 29.7 and FPS tanks to 28 FPS. A FPS hit as well
but not as MASSIVE as dg run.


I feel even the 41 FPS to 28 FPS is a hit that should
not happen. SelectEven is very basic stuff and should not
give any speed hit IMHO. (at least not THIS much)


yes SelectOdd() same FPS hits :D


geez decimate works faster than SelectEven. Now that is insane! HAHA

Guest
13th May 2004, 16:02
That is a truly astonishing result, Mr Zep. I'm not going to believe it until I see it. :)

My first reaction is that the SelectEven() must be forcing MPEG2DEC3dg to do random access for each frame, but I can't see why because it follows Mpeg2source()! Even the hit to trbarry/Nic version is surprising. When I get home I will investigate this and get to the bottom of it. I have the capability to step through Avisynth, so it's just a matter of time until we understand this.

EDIT: Actually, thinking about it, SelectEven() will probably force both to do random access, because it will request every other frame. Now I wonder why the hit to me is worse. I bet the trbarry/Nic version will deliver incorrect frames too, due to the seeking issues there (skipping B frames). Anyway, enough speculation. Wait until I get my hands on it.

But wait, Decimate(2) will request every other frame too!!!!!

Zep
13th May 2004, 16:16
Originally posted by neuron2
That is a truly astonishing result, Mr Zep. I'm not going to believe it until I see it. :)


lol yes do not take my word for it. It could always be some
currupt thing on my PC


Originally posted by neuron2
My first reaction is that the SelectEven() must be forcing MPEG2DEC3dg to do random access for each frame, but I can't see why because it follows Mpeg2source()! Even the hit to trbarry/Nic version is surprising.

me too. It also means for a long time now I have been taking
a big FPS hit and didn't realize it since I never did JUST
a selecteven in a script (I always had 4 or 5 other filters too
and thought the speed hit was from them. i.e. smoothers
and scaling etc...)

So it turns out i am getting more of speed hit from Selecteven
than ALL my other filters combined. F@#$!!!


Originally posted by neuron2
When I get home I will investigate this and get to the bottom of it. I have the capability to step through Avisynth, so it's just a matter of time until we understand this.

oh if you can fix this and get selecteven to not take ANY
FPS hit, well... i will dub you a coding god :D


thanks!

Guest
13th May 2004, 16:18
See my edit above.

This is a good one, Zep!

I could detect that the next frame request is 2 frames later and then just go ahead and decode the in-between one and the next one, thereby avoiding random access. That would make me a god. :) I'll try it.

In fact there is probably a threshold number where it would be advisable just to decode straight and return the final one, rather than doing random access. Say maybe one GOP's worth?

Decimate(2) is faster because he doesn't always pick the same frame in the cycle, meaning that some (half) of the requests are linear.

Zep
13th May 2004, 16:35
Originally posted by neuron2
See my edit above.

This is a good one, Zep!

I could detect that the next frame request is 2 frames later and then just go ahead and decode the in-between one and the next one, thereby avoiding random access. That would make me a god. :) I'll try it.

In fact there is probably a threshold number where it would be advisable just to decode straight and return the final one, rather than doing random access. Say maybe one GOP's worth?

Decimate(2) is faster because he doesn't always pick the same frame in the cycle, meaning that some (half) of the requests are linear.


sounds good to me oh coding god :D


yes i just tried Decimate(2) in place of selecteven
for both versions and got 31 FPS on BOTH versions.


4 FPS to 31
and
28 FPS to 31



HOLY S@#! Decimate faster than Selecteven is truly insane IMHO


haha I'm glad we found this problem as i feel it is major stuff.
i just wish i put 2 and 2 together months ago grrrr.....

Guest
13th May 2004, 16:50
Thinking again, Decimate() has to get all the frames so he can do the comparisons. That is why it is so much faster, it never causes random access. It's all falling into place, son.

I'll definitely revise the code as described.

Whoulda thunk it?

Zep
13th May 2004, 17:55
Originally posted by neuron2
Thinking again, Decimate() has to get all the frames so he can do the comparisons. That is why it is so much faster, it never causes random access. It's all falling into place, son.

I'll definitely revise the code as described.

Whoulda thunk it?


ahhh haaa right. Yup since Decimate has to compare all the frames
random access would indeed be silly and it should just load
them sequentially. yes it is all falling into place LOL


how was this problem not seen by anyone for SOOOOOOO long?
Surely i was not the first to use SelectEven with d2v/ts files :D


(however, it took me a few months to spot it so grrrr on me too!)

Guest
13th May 2004, 18:45
I think it is only HD captures that would need the FPS reduction by two and that is perhaps why it hasn't turned up.

Ayway, I tested the idea and it not only works fine but required just 5 lines of code, of which 2 were braces!

You'll get it in the next beta.

Zep
13th May 2004, 18:46
Originally posted by neuron2
I think it is only HD captures that would need the FPS reduction by two and that is perhaps why it hasn't turned up.

Ayway, I tested the idea and it not only works fine but required just 5 lines of code, of which 2 were braces!

You'll get it in the next beta.


AWESOME oh coding god :D

DDogg
13th May 2004, 18:47
you think this would have effected SelectRangeEvery(1200,12) ?

Guest
13th May 2004, 18:55
Originally posted by DDogg
you think this would have affected SelectRangeEvery(1200,12) ? Each bunch of 12 will be decoded fast but you'll have to random access for each jump to the next 1200 point. So this fix will not affect this case, because random accessing forward 1200 frames is faster than linearly playing 1200 frames to get there. That is why I pointed out a threshold point where it become faster to random access.

EDIT: Here's the key bit:


// Decide whether to use random access or linear play to reach the
// requested frame. If the seek is just a few frames forward, it will
// be faster to play linearly to get there. This greatly speeds things up
// when a decimation like SelectEven() follows this filter.
if (frame && frame > BadStartingFrames &&
frame > prev_frame && frame < prev_frame + SEEK_THRESHOLD)
{
// use linear play
}
else
{
// use random access
}

Dallemon
13th May 2004, 19:39
its not the player ;)

test script 1 (using 1.3.0b5)

mpeg2source("C:\Documents and Settings\Daniel Thamdrup\Skrivebord\METALLICA\VIDEO_TS\VTS_01_0dg.d2v",CPU=4,iPP=true)

test script 2 (using 1.77.3)

mpeg2source("C:\Documents and Settings\Daniel Thamdrup\Skrivebord\METALLICA\VIDEO_TS\VTS_01_0.d2v",CPU=4,iPP=true)

the first script produced the same error in both VDM (1.5.10) and MPC (6.4.8.2) "MPEG2Ssource: couldn't open file"
the second scipt produced no errors in neither VDM nor MPC

Zep
13th May 2004, 20:12
Originally posted by neuron2

EDIT: Here's the key bit:


// Decide whether to use random access or linear play to reach the
// requested frame. If the seek is just a few frames forward, it will
// be faster to play linearly to get there. This greatly speeds things up
// when a decimation like SelectEven() follows this filter.
if (frame && frame > BadStartingFrames &&
frame > prev_frame && frame < prev_frame + SEEK_THRESHOLD)
{
// use linear play
}
else
{
// use random access
}

ahh yes but what is the SEEK_THRESHOLD? My guess depending
on your hard drive and perhaps the cache size on it, the size of a frame as well as how much pre fetch you can do to main memory while waiting for say the encoder to do 1 frame will all play a huge part
in what the SEEK_THRESHOLD should be.

are you gonna make it adjustable?



yes I'm just having fun with wishful thinking with the following :D


example:

mpeg2source("c:\test.d2v",SEEK_THRESHOLD=4)

It would be interesting to see FPS rates by adjusting the threshold
on ones system so that you know for sure when random access
is faster than linear to get to next wanted frame.




I so want the next beta LOL

Guest
13th May 2004, 21:08
SEEK_THRESHOLD will have a fixed value, probably in the region of 6-12.

I'll release another beta tonight. Stay up.

vispgraedde
13th May 2004, 21:30
Originally posted by Dallemon

the first script produced the same error in both VDM (1.5.10) and MPC (6.4.8.2) "MPEG2Ssource: couldn't open file"
the second scipt produced no errors in neither VDM nor MPC

Are you sure that avisynth is using the correct plugin for MPEG2Source?
Don't forget that you will need to put mpeg2dec3dg.dll in avisynth's plugin dir (and replace the old mpeg2dec3.dll or whatever the old one is) to open the new d2v's.

Guest
14th May 2004, 01:18
Here is beta 6:

http://neuron2.net/fixd2v/decodefix130beta6.zip

I wanted to get a few more things in there but I know my friend Zep is waiting anxiously for the new seeking strategy. So here it is!

This also fixes what I hope are the last 32-bit truncations of the 64-bit file position indices. If you ever see negative signs for addresses in the D2V, let me know.

EDIT: SEEK_THRESHOLD = 7 (I love prime numbers.)

Guest
14th May 2004, 03:33
After detailed testing I cannot identify any processing hit with SelectEven() against my beta 6. It appears that all of its effects are due to forced seeking. Do you agree, Zep?

Zep
14th May 2004, 04:33
Originally posted by neuron2
After detailed testing I cannot identify any processing hit with SelectEven() against my beta 6. It appears that all of its effects are due to forced seeking. Do you agree, Zep?


UPDATE

oh yeah the forced seeking was the problem.

I re ran save project and made a new d2v (just to make sure)
and i see a jump from the 4 FPS to 31 FPS now with selecteven only
(no other filters/functions) so a huge jump and you caught up to
trbarry/nic version and passed it as theirs is 28 FPS.

so I can finally dump their version for good :D


Now i do wonder why it is 31 FPS, a 10 FPS hit. Decimate()
also gets me 31 FPS and it does more. I'm still surprised
there is such a hit from 41 to 31.

thoughts on that?


anyway a huge thanks as this is now AWESOME for me and
it is getting so much better so quickly!


thanks for all the hard work DG or is that CG :)

Guest
14th May 2004, 05:20
Originally posted by Zep
Now i do wonder why it is 31 FPS, a 10 FPS hit. Decimate()
also gets me 31 FPS and it does more. I'm still surprised
there is such a hit from 41 to 31. So you are saying that SelectEven() causes a hit! Please describe your methodology and results for showing this. Include all scripts EXACTLY as used.

EDIT: Never mind! I know what it is. It is an illusion. Really. Think about it. Your frame rate is ~30. VirtualDub preview is not going to play it faster than that. But without the SelectEven() the fps is ~60 and that can't be sustained. Ha!

My tests use an HD file that plays at much less than 30fps. I play the AVS into BSPlayer and use the Video Info popup to monitor the rendering rate. Then you can clearly see that SelectEven() has no effect on the video rendering rate.

Now I will see if I can help out Wilbert and len0x. Thank you for bringing this interesting aspect of stream navigation to light.

Zep
14th May 2004, 06:46
Originally posted by neuron2
So you are saying that SelectEven() causes a hit! Please describe your methodology and results for showing this. Include all scripts EXACTLY as used.

EDIT: Never mind! I know what it is. It is an illusion. Really. Think about it. Your frame rate is ~30. VirtualDub preview is not going to play it faster than that. But without the SelectEven() the fps is ~60 and that can't be sustained. Ha!

My tests use an HD file that plays at much less than 30fps. I play the AVS into BSPlayer and use the Video Info popup to monitor the rendering rate. Then you can clearly see that SelectEven() has no effect on the video rendering rate.

Now I will see if I can help out Wilbert and len0x. Thank you for bringing this interesting aspect of stream navigation to light.

but VDub should not be throttled in preview mode. It is not
a player but and encode/edit app. grrrr... It sould preview
as fast as it can be fed. (at least there should be an option
for this if that is not the case)

ok so i will have to encode test with and without selecteven
so that preview is not in the loop in case it is throttled.

or figure out a way to trick VDub into thinking it is 60 FPS
with selectEven turned on so VDub does not try and pin it to 30 FPS.
(since I can't think of a way off the top of my head to get avisynth
to pass bogus info i guess i will have to encode. no sleep for me
yet haha)

Guest
14th May 2004, 06:58
Just put AssumeFPS(59.94) at the end of the script!

Guest
14th May 2004, 07:09
Originally posted by Dallemon
its not the player ;)

test script 1 (using 1.3.0b5)

mpeg2source("C:\Documents and Settings\Daniel Thamdrup\Skrivebord\METALLICA\VIDEO_TS\VTS_01_0dg.d2v",CPU=4,iPP=true)

test script 2 (using 1.77.3)

mpeg2source("C:\Documents and Settings\Daniel Thamdrup\Skrivebord\METALLICA\VIDEO_TS\VTS_01_0.d2v",CPU=4,iPP=true)

the first script produced the same error in both VDM (1.5.10) and MPC (6.4.8.2) "MPEG2Ssource: couldn't open file"
the second scipt produced no errors in neither VDM nor MPC You're not showing the complete scripts. Where are the loadplugin lines? Are you autoloading? If so, how do you ensure the right one is used? Post the actual scripts, not extracted edited ones.

Zep
14th May 2004, 07:12
Originally posted by neuron2
Just put AssumeFPS(59.94) at the end of the script!

i will try that next but what i did was this

same test setup as always but instead of fast recompress with preview
i did a direct stream encode which takes the data as fast as it can
be fed from avisynth and saves it to an avi.

Without selecteven 97 FPS
with selecteven 54 FPS


i will now try it with AssumeFPS(59.94) at the end of script.
will post update soon



UPDATE : did the original test with AssumeFPS(59.94) went into
the file-->file info to make sure both tests were 59.94.

Same result.

41 FPS without selecteven
31 FPS with selecteven


so both preview test and direct stream test show a speed hit when
selecteven is used.


ok now what are your thoughts? :D


just for your info the hard drive is a 160gig with 8 meg cache
at 7200rpm and 6ms seek time and it is drive D so no OS
paging to it etc... (I always boot off drive C)




UPDATE #2 I cropped 128 from all four sides to make
sure there was a speed up above 31 FPS.

preview with Selecteven on and AssumeFPS(59.94) ON 46 FPS
preview with Selecteven on and AssumeFPS(59.94) OFF 31 FPS

so yes VDub preview is throttled

Guest
14th May 2004, 07:36
Just for fun, see if there is a difference between

SelectEven

and

SelectEven()

You can test an old rumor for us.

Zep
14th May 2004, 07:47
Originally posted by neuron2
Just for fun, see if there is a difference between

SelectEven

and

SelectEven()

You can test an old rumor for us.

ok will do


and see my UPDATE above :)



UPDATE no change. i did the cropped test above.
46 FPS with and without the ()

so what was the rumor?

Guest
14th May 2004, 08:08
Try select100.zip from http://neuron2.net/misc/select100.zip

The rumor was that things run slower without the ().

Zep
14th May 2004, 09:32
Originally posted by neuron2
Try select100.zip from http://neuron2.net/misc/select100.zip



same speed

1 minute and 22 seconds (46 FPS used above crop test) both with SelectEven() and select(0)


without either

51 seconds at 74 FPS (note it pinned to 60 so i had to go back
and use AssumeFPS(120) and redo all tests so it would go above 60
on the run without either SelectEven() or select(0) )

crazy huh?



maybe it has nothing to do with your code but avisynth
does something strange.


UPDATE: tried nandub and VDM same test. Same speeds.
So whatever it is, it is on avisynth side and its ability to
frame serve.

I'm using version

AVS 2.5.5 alpha 2004-03-19 15:00
AviSynth_200304.exe

Dallemon
14th May 2004, 10:09
i DID post the WHOLE test script since it SHOULD be autoloading, but i'll the the script that im trying to use and it reports the same errors at mentioned before

working script

import("C:\AviSynth 2.5\scripts\restore24.avs")
import("C:\AviSynth 2.5\scripts\intellibob.avs")
loadplugin("C:\AviSynth 2.5\plugins\masktools.dll")
loadplugin("C:\AviSynth 2.5\plugins\tcombmask.dll")
loadplugin("C:\AviSynth 2.5\plugins\kerneldeint140.dll")
loadplugin("C:\AviSynth 2.5\plugins\tomsmocomp.dll")
loadplugin("C:\AviSynth 2.5\plugins\avisynth_c.dll")
loadcplugin("C:\AviSynth 2.5\plugins\smartdecimate.dll")
loadcplugin("C:\AviSynth 2.5\plugins\ibob.dll")
loadplugin("C:\AviSynth 2.5\plugins\mpeg2dec3.dll")
mpeg2source("C:\Documents and Settings\Daniel Thamdrup\Skrivebord\METALLICA\VIDEO_TS\VTS_01_0.d2v",CPU=4,iPP=true)
assumetff()
converttoyuy2(interlaced=true)
a2=r24kernelbob()
b2=intellibob(athl=0,athc=0,mthl=0,mthc=0)
restore24(a2,b2)
vaguedenoiser(threshold=1,method=1,nsteps=8,chroma=yes)
Crop(8,2,-6,-2)
lanczos4resize(640,480)

evol malfunctioning script

import("C:\AviSynth 2.5\scripts\restore24.avs")
import("C:\AviSynth 2.5\scripts\intellibob.avs")
loadplugin("C:\AviSynth 2.5\plugins\masktools.dll")
loadplugin("C:\AviSynth 2.5\plugins\tcombmask.dll")
loadplugin("C:\AviSynth 2.5\plugins\kerneldeint140.dll")
loadplugin("C:\AviSynth 2.5\plugins\tomsmocomp.dll")
loadplugin("C:\AviSynth 2.5\plugins\avisynth_c.dll")
loadcplugin("C:\AviSynth 2.5\plugins\smartdecimate.dll")
loadcplugin("C:\AviSynth 2.5\plugins\ibob.dll")
loadplugin("C:\AviSynth 2.5\plugins\mpeg2dec3.dll")
mpeg2source("C:\Documents and Settings\Daniel Thamdrup\Skrivebord\METALLICA\VIDEO_TS\VTS_01_0dg.d2v",CPU=4,iPP=true)
assumetff()
converttoyuy2(interlaced=true)
a2=r24kernelbob()
b2=intellibob(athl=0,athc=0,mthl=0,mthc=0)
restore24(a2,b2)
vaguedenoiser(threshold=1,method=1,nsteps=8,chroma=yes)
Crop(8,2,-6,-2)
lanczos4resize(640,480)

vispgraedde
14th May 2004, 11:43
Originally posted by Dallemon

evol malfunctioning script

loadplugin("C:\AviSynth 2.5\plugins\mpeg2dec3.dll")


It looks to me like you are using the old mpeg2dec3.dll when you should be using the new mpeg2dec3dg.dll

Dallemon
14th May 2004, 12:32
thx, it works now ^_^

edit: st00pid me for being n00bish :o

Guest
14th May 2004, 13:35
Originally posted by Dallemon
st00pid me for being n00bish We all suffer brain farts now and again. Please let us know of your results with this version or if you notice anything out of the ordinary.

trbarry
14th May 2004, 13:49
Hi -

I have not been here for awhile and it's also been many months since I've even looked at DVD2AVIx or MPEG2DECx code.

Do Donald's versions now pretty much reliably subsume the functions of mine? I previously didn't use his because of the lack of HDTV support but if the dg versions now reliably do everything then I'd like to stop worrying about mine and just vector my web page to his for those 2 prog's.

I'm in a new job and pretty busy so I don't anticipate making any changes to these in the near future anyway. Any reason not to drop support for mine?

- Tom

Guest
14th May 2004, 14:14
Tom, what an honor to see you here in the DVD2AVI forum.

Yes, your functionality is subsumed and soon will be surpassed with addition of support for PVA and other things I have in mind. But please wait for the release and posting of 1.3.0 on my web site before vectoring there. I'll PM you when that occurs, which shouldn't be long now.

For those that don't know, Tom is a Video and Coding God.

Dallemon
14th May 2004, 15:23
well after swapping the mpeg2dec3.dll to the dg version no problems at all ^_^ and i havent noticed anything out of the ordinary (yet) (using 130b6)

DDogg
14th May 2004, 16:28
D, good to keep the latest in the first post?, or is that one 'semi-stable' (B4) and the later posted version (B6) considered to be bleeding?

Guest
14th May 2004, 22:07
Originally posted by DDogg
D, good to keep the latest in the first post?, or is that one 'semi-stable' (B4) and the later posted version (B6) considered to be bleeding? Just forgot. Actually 6 is the first good version. :)

Guest
15th May 2004, 00:39
Originally posted by len0x
I'm looking at the d2v project (1.3.0) created from CLI and GUI and see that iDCT_Algorithm line differs on my PC. I always get 2 (SSEMMX) from CLI and 5 (SSE2MMX) from GUI. Is CPU detection not the same for both cases? Actually, look at the CommandLine.txt file. The CL was not allowing all 5 choices to be set. I've fixed it and it will be in the next release:

-iDCT-Algorithm -IA (1=MMX 2=SSEMMX 3=SSE2MMX 4=Floating point 5=Reference)

Guest
15th May 2004, 00:52
Wilbert:
There's one problem. If I open the avs script in wmp6.4, I see the following (it's the second video stream):

http://www.geocities.com/wilbertdijkhof/test.jpg

But it loads fine in vdubmod. So, I guess it's some colorspace conversion error? Strangely, the first stream shows up fine. If needed I can upload the clip somewhere. Yes, please. Make the clip available ASAP because I want to release 1.3.0.

Guest
15th May 2004, 01:58
I've reached feature cutoff for 1.3.0 so here is a release candidate:

http://neuron2.net/fixd2v/decodefix130RC1.zip

This versions changes as follows versus beta 6:

1. The bitrate monitor is now numerical (bps).

2. Added start code emulation protection to the transport parser. This makes it more robust.

3. The Info dialog now pops up over the main display instead of beside it. This means there is no need to move it for HD pictures.

4. Fixed the command language -IA option to accept all five supported IDCT algorithms.

5. Added a timeout feature to the transport parser such that if a play, preview, or save project is started with no valid video PID, it will no longer hang DVD2AVIdg.

It would be nice to get this puppy released. :D

zettai
15th May 2004, 02:28
Originally posted by neuron2
3. The Info dialog now pops up over the main display instead of beside it. This means there is no need to move it for HD pictures.

Is there any way to make this a little more flexible?

I like to be able to see the footage when I preview with F5 and with this I have to move the info window every time.

Can you set it as an option or maybe only happen for video over a certian frame size or maybe detect being off screen? I dunno...

Guest
15th May 2004, 04:15
@zettai

Done. It is now based on the picture size. Thanks for the suggestion.

DDogg
15th May 2004, 05:54
DG, I am trying to help dvd2svcd chase a problem. Do you see anything below in this very small d2v that would cause a 100 CPU 'loop' when attempting to open in WMP or VDub? The VOB is only 2 megs created by the preview function of D2S. I have loaded the original D2v as a project in decodefix130RC1, and resaved the d2v below in your new format. I can mail the vob to you if you pm instructions.


LoadPlugin("C:\Program Files\DVD2SVCD\TEMP\MPEG2Dec3dg.dll") #decodefix130RC1 version
MPEG2Source("C:\PROGRA~1\DVD2SVCD\TEMP\preview3.d2v") #created by decodefix130RC1


DVD2AVIProjectFile02
1
42 C:\Program Files\DVD2SVCD\TEMP\preview.vob

Stream_Type=0,0,0
iDCT_Algorithm=2 (1:MMX 2:SSEMMX 3:FPU 4:REF 5:SSE2MMX)
YUVRGB_Scale=1 (0:TVScale 1:PCScale)
Luminance_Filter=0,0 (Gamma, Offset)
Picture_Size=0,0,0,0,0,0 (ClipLeft, ClipRight, ClipTop, ClipBottom)
Aspect_Ratio=16:9
Field_Operation=0 (0:None 1:ForcedFILM 2:SwapOrder 3:RawFrames)
Frame_Rate=29970
Location=0,0,0,3D8

7 0 4295073471 0 0 2 3 10 11 12 13 10 11 12 13 10 11
7 0 4295228094 0 0 2 3 10 11 12 13 10 11 12 12 12 12 12
7 0 4295424968 0 0 12 13 10 11 12 13 10 11 12 13 10 11
7 0 4295608690 0 0 2 3 10 11 12 13 10 11 12 13 10 11
7 0 4295772302 0 0 2 3 10 11 12 13 10 11 12 13 10 11
7 0 4295878972 0 0 2 3 10 11 12 13 10 11 12 13 10 11
7 0 4295987963 0 0 2 3 10 11 12 13 10 11 12 13 10 11
7 0 4296171439 0 0 2 3 10 11 12 13 10 11 12 13 10 11
7 0 4296396571 0 0 2 3 10 11 12 13 10 11 12 13 10 11
7 0 4296618418 0 0 2 3 10 11 12 13 10 11 12 13 10 11
7 0 4296847831 0 0 2 3 10 11 12 13 12 9

FINISHED 95.28% FILM

Guest
15th May 2004, 06:22
Sorry, RC1 was hosed. Try RC2:

http://neuron2.net/fixd2v/decodefix130RC2.zip

These stupid __int64 variables just have a mind of their own. They don't behave like normal ints and you have to really watch out.

This also fixes zettai's info popup thing.

Please give me your results tonight, if possible, so I can go to bed.

DDogg
15th May 2004, 06:42
RC2

1> Will open preview.vob, save and play via standard script, but throws red on black access violation at very end.

No other problems. That fixed the cpu loop. Thanks very much. You are to coding Gods what Walter is to grumpy. Superior in all ways :)

Guest
15th May 2004, 06:47
Violation at end can be due to bad cut leaving incomplete final picture. Trim it away in your script. Please me the VOB fragment with the end intact. That will help me fix the crash at the end issues.

DDogg
15th May 2004, 06:50
Please me the VOB fragment with the end intact. And how do I please you? :) Gimme the address and the header codeword?

Yep, frame 124 was the bad seed. trim (0,123) played without error.

Guest
15th May 2004, 06:58
I've added some crash-at-the-end protection to DVD2AVIdg but haven't gotten to MPEG2DEC3dg to do the same yet. I figure Trim() will get people by for now as long as DVD2AVIdg can save the project OK.

> Gimme the address and the header codeword?

Huh? I just need your end intact.

Guest
15th May 2004, 07:01
I think I'll write my own long long int class that I can trust!

DDogg
15th May 2004, 07:09
Huh? I just need your end intact. Oh, me too, but how do I deliver you the intact end of a vob that is 2megs? Perhaps you mean the end of the d2v I guess. Here is the complete d2v. Well hell, it does not throw the error now, but last frame is blocked up.


DVD2AVIProjectFile02
1
42 C:\Program Files\DVD2SVCD\TEMP\preview.vob

Stream_Type=0,0,0
iDCT_Algorithm=2 (1:MMX 2:SSEMMX 3:FPU 4:REF 5:SSE2MMX)
YUVRGB_Scale=1 (0:TVScale 1:PCScale)
Luminance_Filter=0,0 (Gamma, Offset)
Picture_Size=0,0,0,0,0,0 (ClipLeft, ClipRight, ClipTop, ClipBottom)
Aspect_Ratio=16:9
Field_Operation=1
Frame_Rate=23976
Location=0,0,0,3D8

7 0 28756 0 0 2 3 10 11 12 13 10 11 12 13 10 11
7 0 325483 0 0 2 3 10 11 12 13 10 11 12 13 10 11
7 0 549845 0 0 2 3 10 11 12 13 10 11 12 13 10 11
7 0 748319 0 0 2 3 10 11 12 13 10 11 12 13 10 11
7 0 948925 0 0 2 3 10 11 12 13 10 11 12 13 10 11
7 0 1140695 0 0 2 3 10 11 12 13 10 11 12 13 10 11
7 0 1326749 0 0 2 3 10 11 12 13 10 11 12 13 10 11
7 0 1513844 0 0 2 3 10 11 12 13 10 11 12 13 10 11
7 0 1718927 0 0 2 3 10 11 12 13 10 11 12 13 10 11
7 0 1917102 0 0 2 3 10 13 9

FINISHED 99.10% FILM

/Add: Ok, this one throws the violation at the end. I'll keep the matching vob fragment, if you need it let me know.

DVD2AVIProjectFile02
1
42 C:\Program Files\DVD2SVCD\TEMP\preview.vob

Stream_Type=0,0,0
iDCT_Algorithm=2 (1:MMX 2:SSEMMX 3:FPU 4:REF 5:SSE2MMX)
YUVRGB_Scale=1 (0:TVScale 1:PCScale)
Luminance_Filter=0,0 (Gamma, Offset)
Picture_Size=0,0,0,0,0,0 (ClipLeft, ClipRight, ClipTop, ClipBottom)
Aspect_Ratio=16:9
Field_Operation=1
Frame_Rate=23976
Location=0,0,0,3D8

7 0 106175 0 0 2 3 10 11 12 13 10 11 12 13 10 11
7 0 260798 0 0 2 3 10 11 12 13 10 11 12 12 12 12 12
7 0 457672 0 0 12 13 10 11 12 13 10 11 12 13 10 11
7 0 641394 0 0 2 3 10 11 12 13 10 11 12 13 10 11
7 0 805006 0 0 2 3 10 11 12 13 10 11 12 13 10 11
7 0 911676 0 0 2 3 10 11 12 13 10 11 12 13 10 11
7 0 1020667 0 0 2 3 10 11 12 13 10 11 12 13 10 11
7 0 1204143 0 0 2 3 10 11 12 13 10 11 12 13 10 11
7 0 1429275 0 0 2 3 10 11 12 13 10 11 12 13 10 11
7 0 1651122 0 0 2 3 10 11 12 13 10 11 12 13 10 11
7 0 1880535 0 0 2 3 10 11 12 13 12 9

FINISHED 95.28% FILM


I gotta go to bed, night.

Zep
15th May 2004, 08:23
Originally posted by neuron2
I've reached feature cutoff for 1.3.0 so here is a release candidate:

http://neuron2.net/fixd2v/decodefix130RC1.zip



5. Added a timeout feature to the transport parser such that if a play, preview, or save project is started with no valid video PID, it will no longer hang DVD2AVIdg.


YEAH #5 got me a few times

oh incase you missed my update edit above here it is again


UPDATE: tried nandub and VDM same test. Same speeds.
So whatever it is, it is on avisynth side and its ability to
frame serve.

I'm using version

AVS 2.5.5 alpha 2004-03-19 15:00
AviSynth_200304.exe

Zep
15th May 2004, 08:27
Originally posted by neuron2
Violation at end can be due to bad cut leaving incomplete final picture. Trim it away in your script. Please me the VOB fragment with the end intact. That will help me fix the crash at the end issues.

MPEG2DEC3dg side.

i saw this crash last night on both frist and second pass
when the LAST frame was read it.


VDub just closed with an abort. it was a .ts so it makes me
wonder what was wrong with the very last frame.

Zep
15th May 2004, 08:29
Originally posted by neuron2
I've added some crash-at-the-end protection to DVD2AVIdg but haven't gotten to MPEG2DEC3dg to do the same yet. I figure Trim() will get people by for now as long as DVD2AVIdg can save the project OK.

> Gimme the address and the header codeword?

Huh? I just need your end intact.



yeah MPEG2DEC3dg is where i am seeing the problem
and thus a crash in VDub on last frame on each pass.


I will try a trim next chance I get

Wilbert
15th May 2004, 10:15
Yes, please. Make the clip available ASAP because I want to release 1.3.0.

http://www.geocities.com/wilbertdijkhof/FaithHill10.ts

a bit more info:

http://forum.doom9.org/showthread.php?s=&postid=491183#post491183

zettai
15th May 2004, 11:01
Strange little bug:

If you try and make a d2v file on a hard drive which is *almost* full and there isnt enough space for a d2v, instead of throwing an error the file will be partially written instead!

len0x
15th May 2004, 11:43
Originally posted by neuron2
Actually, look at the CommandLine.txt file. The CL was not allowing all 5 choices to be set. I've fixed it and it will be in the next release:

-iDCT-Algorithm -IA (1=MMX 2=SSEMMX 3=SSE2MMX 4=Floating point 5=Reference)

works great now, thanks!
why not add this to the GUI menu as well ?

Guest
15th May 2004, 12:32
Originally posted by DDogg
Oh, me too, but how do I deliver you the intact end of a vob that is 2megs? Perhaps you mean the end of the d2v I guess. Here is the complete d2v. If it's only 2Meg, please give me a link to the whole thing! I need to be able to duplicate the crashes to fix them.

Guest
15th May 2004, 12:41
Originally posted by len0x
works great now, thanks!
why not add this to the GUI menu as well ? The IDCT menu presents only the options that your processor is capable of supporting.

len0x
15th May 2004, 12:51
Originally posted by neuron2
The IDCT menu presents only the options that your processor is capable of supporting.

you mean maximum option? if SSE2 is supported then surely SEE and MMX are supported as well... (but you only see SSE2)

Guest
15th May 2004, 12:53
Originally posted by len0x
you mean maximum option? if SSE2 is supported then surely SEE and MMX are supported as well... (but you only see SSE2) See, I haven't an SSE2 so I never could notice that! I'll fix that.

Guest
15th May 2004, 12:53
Originally posted by Wilbert
http://www.geocities.com/wilbertdijkhof/FaithHill10.ts

a bit more info:

http://forum.doom9.org/showthread.php?s=&postid=491183#post491183 Wilbert, everything works fine for me with Media Player 6.4 and both streams using RC2. I don't know where to go with this.

Wilbert
15th May 2004, 14:50
I followed the advice of Moitah, changing my display to 16 bit works fine. Strange that the main video stream didn't have this problem.

Guest
15th May 2004, 15:12
Originally posted by Wilbert
I followed the advice of Moitah, changing my display to 16 bit works fine. Strange that the main video stream didn't have this problem. Maybe you have a bad video card.

DDogg
15th May 2004, 18:06
If it's only 2Meg, please give me a link to the whole thing! OK, check your PM

lineman
15th May 2004, 18:44
Nice work on Dvd2avidg "neuron2" , I just have a couple of questions.
Will it support DVB-S 4.2.0.transport streams, and also is there a way to have it support DVB-S 4.2.2. mpg transport streams. Nics dvd2avi will work on the 4.2.2. streams but when opened in virtualdub they lack color, and are mostly green. I use VFAPI reader codec to convert the d2v to an false avi and then the image is correct in vitualdub. I will post some sample when I find an suitable site. Thanks for all you hours of hard work...

Lineman

Moitah
15th May 2004, 23:10
A friend sent me a small .pva for testing (recorded with ProgDVB), it isn't decoded correctly with RC2 (weird colored and misplaced blocks). It works fine if I use pva2mpg2.exe. It's up on my FTP server.

Guest
16th May 2004, 00:56
@lineman

I don't know. Can you make available some test clips.

@Moitah

PVA is not expected to work. I have to add support for it. I have the spec and a sample from CruNcher. I'll get yours too. Maybe I'll start on it tomorrow.

Guest
16th May 2004, 01:56
Originally posted by DDogg
OK, check your PM It doesn't crash for me with RC2. What say you?

DDogg
16th May 2004, 03:42
Same one I sent you crashes on last frame as mentioned. That really doesn't concern me as this preview.vob is always used with a trim statement to create stills. Since it does not crash for you, it is not a replicatable. That makes it not worth your time, IMO.

Guest
16th May 2004, 06:31
I got bored today and decided to write a PID detector. It's a command line utility with the following usage:

>table filename

Obviously, use it on transport streams that carry PAT/PMT.

The zip file includes source code, from which you can see that PID detection is no trivial matter. This will be integrated into DVD2AVIdg.

http://neuron2.net/fixd2v/table101.zip

Feedback will be appreciated.

Here is sample output:

G:\tmp\Zep>table abc.3.video.3.audio.streams.tp
------------------------------------------------
Table 1.0.1 -- PAT/PMT Parser by Donald A. Graft
------------------------------------------------

Program 1
PCR on PID 0x11
Video on PID 0x11
AC3 Audio on PID 0x14
Other on PID 0x1a
Program 2
PCR on PID 0x21
Video on PID 0x21
AC3 Audio on PID 0x24
Program 3
PCR on PID 0x31
Video on PID 0x31
AC3 Audio on PID 0x34

Guest
16th May 2004, 09:41
Here is version 1.3.0 RC3:

http://neuron2.net/fixd2v/decodefix130RC3.zip

This version adds integrated PID detection, cleans up the IDCT algorithm and CPU detection menu support, and removes the resize and LB menu items (they were not used by MPEG2DEC3dg).

OK, now we have really reached feature cut-off. :)

dvd2svcd
16th May 2004, 11:52
Hi Donald,

For some reason I get an Avisynth Error when trying to use this D2V file:DVD2AVIProjectFile03
1
19 C:\test\preview.vob

Stream_Type=0,0,0
iDCT_Algorithm=2 (1:MMX 2:SSEMMX 3:FPU 4:REF 5:SSE2MMX)
YUVRGB_Scale=1 (0:TVScale 1:PCScale)
Luminance_Filter=0,0 (Gamma, Offset)
Picture_Size=0,0,0,0 (ClipLeft, ClipRight, ClipTop, ClipBottom)
Aspect_Ratio=16:9
Field_Operation=0 (0:None 1:ForcedFILM 2:SwapOrder 3:RawFrames)
Frame_Rate=29970
Location=0,0,0,3DA

7 0 156092 0 0 13 10 11 12 13
7 0 344656 0 0 0 1 12 13 10 11 12 13 10 11 12 13
7 0 601580 0 0 0 1 12 13 10 11 12 13 10 11 12 13
7 0 863760 0 0 0 1 12 13 10 11 12 13 10 11 12 13
7 0 1117468 0 0 0 1 12 13 10 11 12 13 10 11 12 13
7 0 1378036 0 0 0 1 12 13 10 11 12 13 10 11 12 13 10
7 0 1651732 0 0 11 12 13 10 11 12 13 10 11 12 13
7 0 1938552 0 0 12 9

FINISHED 98.70% FILM
My Avisynth file is very simpleLoadPlugin("C:\PROGRAMMER\DVD2SVCD\DVD2AVidg\MPEG2dec3dg.DLL")
MPEG2Source("C:\TEST\preview.d2v")My dvd2avi.ini looks like thisDVD2AVI_Version=DVD2AVIdg 1.3.0 RC3
Window_Position=100,100
iDCT_Algorithm=2
YUVRGB_Scale=1
Field_Operation=0
Output_Method=3
Track_Number=0
DR_Control=2
DS_Downmix=0
SRC_Precision=0
Norm_Ratio=100
Process_Priority=2
Transport_PIDs=11,14
If I use ParseD2V the end lines is65: 81,82 -- 0 [vob/cell=0/0]
[GOP START]
66: 82,83,83 -- 1 [vob/cell=0/0]
67: 84,84 -- 2 [vob/cell=0/0]
68: 85,85,86 -- 3 [vob/cell=0/0]
69: 86,87 -- 0 [vob/cell=0/0]
70: 87,88,88 -- 1 [vob/cell=0/0]
71: 89,89 -- 2 [vob/cell=0/0]
72: 90,90,91 -- 3 [vob/cell=0/0]
73: 91,92 -- 0 [vob/cell=0/0]
74: 92,93,93 -- 1 [vob/cell=0/0]
75: 94,94 -- 2 [vob/cell=0/0]
76: 95,95,96 -- 3 [vob/cell=0/0]
[GOP START]
77: 96,97 -- 2 [vob/cell=0/0] [3:2 pattern break] [ILLEGAL TRANSITION!]
[EOF]
I'm using Avisynth 2.54. I have reproduced this error on 2 computers, both Intel one is P3 and the other a P4. I'll make a PM to you where you can download my test data.
Any other info you need just let me know.

len0x
16th May 2004, 13:52
I also have issues with RC3. RC2 worked fine but with RC3 I get "MPEG2Source: couldn't open file".

Guest
16th May 2004, 13:54
Originally posted by len0x
I also have issues with RC3. RC2 worked fine but with RC3 I get "MPEG2Source: couldn't open file". It has a new D2V version format; you have to remake your project with the new DVD2AVIdg.

len0x
16th May 2004, 14:03
Originally posted by neuron2
It has a new D2V version format; you have to remake your project with the new DVD2AVIdg.

of course I did - now that I'm looking at the dates of DVD2AVI and mpeg2dec3 I see that RC3 archive includes mpeg2dec3dg.dll from RC2!

Guest
16th May 2004, 14:09
@Dvd2scvd

As a workaround, you can trim away the last picture in your script. But I agree it would be better to not crash.

Guest
16th May 2004, 14:10
Originally posted by len0x
of course I did - now that I'm looking at the dates of DVD2AVI and mpeg2dec3 I see that RC3 archive includes mpeg2dec3dg.dll from RC2! Oh, duh!!! I'll replace it immediately.

EDIT: The archive has been corrected. Please advise if it is OK now for you. The perils of working at 4:00 in the morning. The caffeine level is dangerously low.

Guest
16th May 2004, 14:28
Originally posted by dvd2svcd
[GOP START]
77: 96,97 -- 2 [vob/cell=0/0] [3:2 pattern break] [ILLEGAL TRANSITION!]
[EOF] What happens if you use Fixd2v on the D2V and then serve the fixed D2V?

len0x
16th May 2004, 14:51
Originally posted by neuron2
EDIT: The archive has been corrected. Please advise if it is OK now for you.


works like a charm now :) thanks!
Another question about archive - some txt/html files there have read only attribute on them. Is that intentional?

Originally posted by neuron2

The perils of working at 4:00 in the morning. The caffeine level is dangerously low.

Wow! I can never program at this time :) Considering that its weekend you'll probably be sleeping all Sunday long :D

dvd2svcd
16th May 2004, 14:54
Originally posted by neuron2
What happens if you use Fixd2v on the D2V and then serve the fixed D2V? Seems to be the same problem. I rename preview.d2v.fixed to preview.d2v and tried again, same VirtualDUB error: http://www.dvd2dvd.org/vduberror.jpg

EDIT: Sorry, didn't see the above posts. I'll try with the new mpeg2dec3dg.dll.

Guest
16th May 2004, 14:55
Originally posted by len0x
works like a charm now :) thanks!
Another question about archive - some txt/html files there have read only attribute on them. Is that intentional? Nah. They probably spent some time on a CD-ROM before being copied to their current location. If they were write only, that would be a problem. :)

Guest
16th May 2004, 14:58
Originally posted by dvd2svcd
EDIT: Sorry, didn't see the above posts. I'll try with the new mpeg2dec3dg.dll. Oh, goodie, less work for me. See you just said Avisynth error, so I assumed you meant a crash.

dvd2svcd
16th May 2004, 14:58
Yes, that did it. All works fine again :) Thanks for the speedy fix :)


Originally posted by neuron2
Oh, goodie, less work for me. See you just said Avisynth error, so I assumed you meant a crash. I know, my bad, sorry. I meant to have posted that VirtualDUB error JPG in my first post, but I forgot it seems.

Guest
16th May 2004, 15:05
@dvd2svcd

Great! Sorry for the hassle with the bad archive.

@Zep

Any feedback on my wonderful, reliable PID detection? :D

len0x
16th May 2004, 15:12
Originally posted by neuron2

Great! Sorry for the hassle with the bad archive.


It was really lucky of me to spot the error that quickly, otherwise we could've continued tracking the problem in totally different environments :)

Guest
16th May 2004, 15:22
Not lucky, len0x. The word is perspicacious, observant, alert, perceptive, diligent...

len0x
16th May 2004, 15:34
True. But the luck I was referring to is more about "how quick" it was found. I have no doubts that it would've been solved anyway. You know how I found it? I was testing AutoGK with new DVD2AVI combo and it just happens that DVD2AVI and mpeg2dec3 are placed in a different directories in AutoGK folder. So after you mentioned that d2v structure was changed I was checking if I forgot to unpack mpeg2dec3dg in second folder and I quickly saw that they are the same but didn't notice that date was three days old at first. But it just happens that I don't use Explorer for file navigation but other file manager where the date of current file is shown in a very distinct way, so after a couple of minutes of jusr staring at the screen I noticed difference in dates betweet DVD2AVI and mpeg2dec3. The rest was easy :)

Trahald
16th May 2004, 16:31
penicillin was found by 'accident' too. hehe.

Moitah
16th May 2004, 17:16
Wilbert: I found a way to fix YV12 playback. DivX was handling YV12, and apparently not working so well :). If you use XviD instead, it should work. You can do this by adding a new string value (or change it if it's already there) in "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Drivers32" with the name "vidc.YV12" and the data "xvidvfw.dll". This assumes you have XviD installed. I'm running Windows 2000 but it should work in XP as well.

Guest
16th May 2004, 20:10
Just some info. I have PVA format video decoding working now. I have to demux the audio and then we have PVA support.

Zep
16th May 2004, 20:15
Originally posted by neuron2


@Zep

Any feedback on my wonderful, reliable PID detection? :D

yes i just tested it and it works AWESOME :D


in a 7 stream .ts file it was able to detect them all correctly


Group 1
PCR on PID 11
Video on PID 11
AC3 on PID 14
Other on PID 1A

Group 2
PCR on PID 21
Video on PID 21
AC3 on PID 24

Group 3
PCR on PID 31
Video on PID 31
AC3 on PID 34


i call them groups, you call them programs. I have no idea
if there is an offical title. I have always called them PID groups.

Guest
16th May 2004, 20:40
:D :D :D :D :D

[They're officially called programs.]

Zep
16th May 2004, 20:51
Originally posted by neuron2
:D :D :D :D :D

[They're officially called programs.]


bahhhh that is aweful!!! who came up with that! grrr..... :D


PID Group much better describes what they are lol



like we don't have enough "programs" already for 50
other things haha

Guest
16th May 2004, 21:16
Program in the sense of watching a TV program!

Zep
17th May 2004, 01:31
Originally posted by neuron2
Program in the sense of watching a TV program!

yup another reason why it is not good IMHO

what you are listing in the app is not really a TV program
but grouped streams of data that may or not be a TV program.
Stream "Other" in my above post is not Video or Audio (as far
as i can tell) and thus not a TV program :D

and "program" 3 is not a tv program either per se' but a live
computer feed of dobbler radar.

other streams have all sorts of stuff and more and more
streams are coming online that send software and not TV at all.
You can already download 15 gigs an hour over HDTV. It doesn't
have to be a TV program it can be anything.

HarryM
17th May 2004, 21:11
Hi,

I have problems with DVD2AVIdg 1.3.
DVD-RB refused AVS script with version 1.3 (1.2 too). :mad:
I get only 10 seconds of obligate error messages (error at line 6 of script).

With version 1.1 final is all O.K.

Guest
17th May 2004, 21:25
Originally posted by HarryM
I have problems with DVD2AVIdg 1.3.
DVD-RB refused AVS script with version 1.3 (1.2 too). :mad:
Actually, you have problems with DVD-RB! I assume it needs to be revised for the new D2V file format. Please contact its authors for support.

vispgraedde
17th May 2004, 23:32
Originally posted by HarryM
Hi,

I have problems with DVD2AVIdg 1.3.
DVD-RB refused AVS script with version 1.3 (1.2 too). :mad:
I get only 10 seconds of obligate error messages (error at line 6 of script).

With version 1.1 final is all O.K.

Since it is the avs script it refuse... did you check that you updated the version of mpeg2dec3dg.dll that avisynth use to the one in 1.3?

Zeul
17th May 2004, 23:57
@neuron2

I appear to have found a problem, which is hopefully not due to me being an idiot :D
In the latest build of NuMenu4u i am now running dvd2avi (dg) on the demuxed m2v file from dvd decrypter, instead of the VOB file. I am getting a different frame count compared to dvd2avi run against the VOB file.
Example:
Pal project. Coded # = 363, which also corresponds to RB's build (outputs log file). All dg builds report the same. Avifileinfo also reports 363 frames. I load up the VOB and now have 365 frames. This corresponds exactly to the IFO (00:00:14;15). Dropping the demuxed m2v file into Scenarist gives a data end time (00:00:14;14 ie duration = 00:00:14;15) thereby removing a problem with the demuxed file. It would seem that 2 frames have been dropped when using the m2v file. I have tried using a variety of different mpeg2dec3dg.dll all with the same result. Is this plausible? It is sporadic but obviously for menus we must be exact to the frame. From what I can tell the offending files do start with an 'I' frame.

Zeul

Guest
18th May 2004, 02:26
Please make the VOB and M2V files available for download. Thank you.

If you can do it quick I'd be grateful as I was hoping to release RC3 tonight.

vispgraedde
18th May 2004, 08:14
Originally posted by neuron2
Please make the VOB and M2V files available for download. Thank you.

If you can do it quick I'd be grateful as I was hoping to release RC3 tonight.

I could have sworn RC3 was out already... :p or did you maybe mean marking RC3 as final for this version?

Guest
18th May 2004, 12:44
Originally posted by vispgraedde
did you maybe mean marking RC3 as final for this version? Correct. I will try to be more precise in the future.

BoNz1
18th May 2004, 21:16
Hi neuron2, I have a bug report for you. The two NTSC DVDs in question are Matrix Revolutions and Master and Commander. What happens is that the audio is totally out of sync with the video. From what I can see the reason is that there are simply too many frames. I will put up links to the vobs and m2v. Unfortunately, they will have to be small hopefully they will be large enough so that you can find the problem.
EDIT: You can get the samples here, http://www.geocities.com/bonzi5252/ it the the samples.zip file, unfortunately the problem is hard to see with these very small samples. The audio gets progressively more out of sync as the video plays. This beta had more frames than dvd2avi 1.76 and dvd2avidg 1.0.

Guest
18th May 2004, 22:30
@BoNz1

I don't care about 1.76. But you are saying that with your VOB I will get a different number of frames if I Save Project for 1.3.0 RC3 versus 1.0.0?

Please state exactly how I am to duplicate a problem with the VOBs you are providing.

What is the m2v and why is it relevant?

EDIT: I can detect no difference in handling of your VOB between versions 1.0.0 and 1.3.0. Can you please explain exactly how I am to reproduce your problem? Thank you.

BoNz1
19th May 2004, 09:05
I don't care about 1.76. But you are saying that with your VOB I will get a different number of frames if I Save Project for 1.3.0 RC3 versus 1.0.0?

neuron2, sorry I was in a rush to get the vobs up BTW like I said earlier I think it may be difficult to duplicate the problem with such small vobs. I shouldn't have uploaded w/o checking closer. BTW there is a difference in the number of frames between the two dvd2avidg versions for the entire movie but it isn't as big as I thought it was, 187154 frames for 1.3.0 RC3 and 187144 for 1.1.0. For both however the audio is completely out of sync. As for the m2v, I have no clue why I uploaded that I think it probably was because you asked for it from someone else :confused:. Anyway, there is a bug somewhere here. The audio shouldn't be out by 30 seconds or more.

loni_blues
19th May 2004, 12:11
@neuron2 and len0x

Hi,
I would like to report a difference, probably not a bug. I use Robot4rip with GKnot. Since Dvd2avidg 1.1.0 the program fails to detect the correct "FILM" percentage (i.e.: for a film that is 99% FILM I get 13% FILM and so, no forced film is applied by R4r). Version 1.0.0 detects the percentage correctly. I am calling this a "difference" because I think it has to do with the d2v estructure analysis Robot4rip does. I think there may be problems with AutoGK as well, though I have not tested it.

Regards and thanks for any help,
loni_blues

len0x
19th May 2004, 12:22
Originally posted by loni_blues
I am calling this a "difference" because I think it has to do with the d2v estructure analysis Robot4rip does. I think there may be problems with AutoGK as well, though I have not tested it.


It very well may be that R4R cannot work with new DVD2AVIdg, but nothing we can do about it since R4R is not being developed anymore.

P.S. latest AutoGK is shipped with latest DVD2AVIdg and has no problems with it.

Guest
19th May 2004, 12:50
I have just confirmed problems in RC3.

I ran the complete process on Matrix Reloaded. It had 7 VOBs. The first problem is that DVD2AVIdg 1.3.0 dropped the last GOP of the last file, losing 3 frames. But worse, MPEG2DEC3dg 1.3.0 miscounted the number of frames in the D2V and generated a video that was too long.

Obviously, I will fix these immediately and make an RC4.

Thanks Zeul, BoNz1, and loni_blues, for bringing it to light.

len0x, better to wait for formal releases, I suppose. ;)

len0x
19th May 2004, 13:30
Originally posted by neuron2
len0x, better to wait for formal releases, I suppose. ;)

I have not released a stable version fo AutoGK yet, but just beta, so that is supposed to have potential problems by definition :)

Guest
19th May 2004, 14:09
Oh goodie. I'm home today and I've already fixed MPEG2DEC3dg. Now I'm fixing that lost last GOP. There'll be a good version very soon. ;)

Zeul
19th May 2004, 18:18
@neuron2

excellent news. I spend so much time coding and tinkering with NuMenu4u, i thought i was going insane. Apologies again for not being able to upload the offending files.

Zeul

Zep
19th May 2004, 18:53
Originally posted by neuron2
I got bored today and decided to write a PID detector.



Here is sample output:

G:\tmp\Zep>table abc.3.video.3.audio.streams.tp
------------------------------------------------
Table 1.0.1 -- PAT/PMT Parser by Donald A. Graft
------------------------------------------------

Program 1
PCR on PID 0x11
Video on PID 0x11
AC3 Audio on PID 0x14
Other on PID 0x1a
Program 2
PCR on PID 0x21
Video on PID 0x21
AC3 Audio on PID 0x24
Program 3
PCR on PID 0x31
Video on PID 0x31
AC3 Audio on PID 0x34


oh S@#$ i just noticed that was done on MY ABC clip :D


wow I can't believe i didn't spot that first time around lol

Zep
19th May 2004, 18:57
Originally posted by neuron2
I have just confirmed problems in RC3.

I ran the complete process on Matrix Reloaded. It had 7 VOBs. The first problem is that DVD2AVIdg 1.3.0 dropped the last GOP of the last file, losing 3 frames. But worse, MPEG2DEC3dg 1.3.0 miscounted the number of frames in the D2V and generated a video that was too long.

Obviously, I will fix these immediately and make an RC4.

Thanks Zeul, BoNz1, and loni_blues, for bringing it to light.

len0x, better to wait for formal releases, I suppose. ;)

has anyone mentioned problems with decode + normalize at 100%?


none of my wavs are normalized to 100%. I will have to check
and see to what they were normalized to first chance i get.
(sounds about oh 70% maybe less)

UPDATE: yup I loaded into cooledit and doubled checked
and instead of 100% it is only doing about 50% to 60%

loni_blues
19th May 2004, 20:16
@len0x

Sorry for my complete ignorance -I am one of those who sticks to Gknot- but I thought AutoGknot was using R4r as well.
Regards,
loni_blues

jimmy basushi
19th May 2004, 23:24
loni, you should download autogk and have a look yourself, its an interesting program to look at but not for anyone who likes tinkering with thier avs files.

neuron2, until i looked at this thread i was about to update.. is version 1.2.0 considered stable by you? last i looked it was still marked as a rc.

Guest
19th May 2004, 23:54
Well, folks, here is 1.3.0 RC4:

http://neuron2.net/fixd2v/decodefix130RC4.zip

I was tempted to go back to beta on it because a substantial rewrite was required. The code that handled running out of bits at the end of the last file was a total kludge (that 'Dry' business). Now it is more rational. I hope I didn't break too much but it was really needed. The problems I was able to duplicate are fixed. I'd appreciate it if the people having the problems can report back with their results.

@Jimmy

The last guaranteed version is 1.1.0. Try 1.3.0 RC4. I need the testing. :)

EDIT: One known bug found in RC4. Play and Preview do not work after Save Project. I'll fix this in the next version. I'd like to get feedback on whether this version fixes the frame count issues that were reported.

Guest
20th May 2004, 00:21
Originally posted by Zep
has anyone mentioned problems with decode + normalize at 100%? I'm not too bothered because all that audio stuff is going to be replaced (or removed). But thank you for pointing it out.

Guest
20th May 2004, 02:17
Here's the fix:

http://neuron2.net/fixd2v/decodefix130RC5.zip

Sorry for all the versions. I will wait for feedback on this one. I can't find anything wrong with it.

Cyberia
20th May 2004, 04:34
I can't find anything wrong with it.

ditto

Zep
20th May 2004, 05:28
Originally posted by neuron2
Well, folks, here is 1.3.0 RC4:

http://neuron2.net/fixd2v/decodefix130RC4.zip

I was tempted to go back to beta on it because a substantial rewrite was required. The code that handled running out of bits at the end of the last file was a total kludge (that 'Dry' business). Now it is more rational. I hope I didn't break too much but it was really needed. The problems I was able to duplicate are fixed. I'd appreciate it if the people having the problems can report back with their results.



I noticed it changed because first time ever I saw all green frames at end of file.
No big deal as the last few frames are trim() out but I'm hoping it fixes my crash
on each pass also in VDub. For some reason avisynth was feeding VDub/Xvid
data it choked on, on the very last frame (even with a trim)

find out in 20 minutes as pass one with RC5 does its thing (I missed RC4)

Zep
20th May 2004, 05:31
Originally posted by neuron2
I'm not too bothered because all that audio stuff is going to be replaced (or removed). But thank you for pointing it out.

NP I try to spot them :)


woah really? I hope you leave it in. if I have to use dvdtoavi (i.e. step 1)
I would rather the normalize be done there on my wavs instead of in avisynth.

Hmmm...

Zep
20th May 2004, 05:33
Originally posted by neuron2
Here's the fix:

http://neuron2.net/fixd2v/decodefix130RC5.zip

Sorry for all the versions. I will wait for feedback on this one. I can't find anything wrong with it.

doing my first cap now with this version. might take a few days to really put
it through its paces :D so far so good though I did notice the green frames
in last GOP unlike prior versions. trimmed out like always since I go a few minutes
long when raw capping.

thanks for the update. I really wanted this one :)

Guest
20th May 2004, 05:54
The green frame (sometimes pink) is fixed in my latest for release. Actually, it appears only at the end of Save Project sometimes, and never appears in MPEG2DEC3dg output. Stuff like that is always a big deal for me. :)

The problem is that at the end of the Save Project the last frame is displayed but the previous frames were not decoded, so it may not have its reference frame. Now at the end of a Save Project I don't display the last frame, but just write the coded frame count into the info dialog instead. Then I raise a popup for the user to dismiss, after which I navigate back to frame 0. This avoids ever positioning on a frame without its reference frame having been decoded.

Lord_KiRon
20th May 2004, 08:22
Sorry for being a bit off topic and newbie , however I have a question directly related to DVD2AVIdg and you looks to the kind of people that can help :

I made a rip of DVD (NTSC 16:9 anamorphic 3 movies on disk) using roborip , the "problem" is that when I run DVD2AVIdg (any version) from roborip the 1st and 3rd movie (it's ~40min series) all the time "jump" NTSC/FILM , while it looks like 2nd movie is set to FILM (forced ?) all the time and this causes different field operation descission in the resulting .D2V file - "None" for 1st and 3rd and "Force FILM" for the 2nd.
Also somehow the system detects FPS as 29.7...fps while DVD is NTSC , shouldn't it be 30 fps?

It wouldn't get me worry but the 2nd movie is compresses WAY better then first and 3rd , I set 900 bitrate for all 3 movies (XviD,Fast recompress to remain in same color space,2 passes,.AVS created with GK) and 1st and 3rd I got 800+ bitrate as it was supposed to in resulting AVIs while with this 2nd movie the resulting bitrate is 670 no matter what bitrate I set even up to 3000.
Can some one explain me that ?

Also does anyone know a good guide for newbies like me explaining use and meaning of DVD2AVIdg options/parameters , I was using roborip before but I a outgrown it now and it's no longer updates , while AutoGK is too automatic for my taste so I need to lurn to control DVD2AVI manually.

Zeul
20th May 2004, 10:56
@neurnon2

Is there any chance of you adding another commandline switch which would output a log file similar to the RB build. The information provided by this log file has proven to be very useful in determining field order / scanning order, and is now extensively used by NuMenu4u.

Thanks
Zeul

len0x
20th May 2004, 10:59
Originally posted by Lord_KiRon
Also does anyone know a good guide for newbies like me explaining use and meaning of DVD2AVIdg options/parameters

essential reading:
http://www.doom9.org/ivtc-tut.htm

Lord_KiRon
20th May 2004, 12:04
Ops missed this one :( , and also the "essential reading" stycky thread here :( , sorry guys next time I will put more attention .

EDITED:
OK , now after reading all the guids I am a smarter person now ;) , so this brings me to the next question : if I have a series and some episodes detected as 100% film and some not (percentage is high but bellow 95%) should I force "Force FILM" option on them ?

Zeul
20th May 2004, 13:38
@neuron2
As an update dvd2avidg (RC5) now reports the same number of frames for the offending VOBs and M2V, when run through avs script. The main window (coded #) still shows a difference in preview mode. So thanks for your hard work on this.

@Lord_KiRon
Only use force film if >95% film. anything less use no force film and apply telecide to your avs script.

Zeul

Guest
20th May 2004, 13:40
Originally posted by Zeul
Is there any chance of you adding another commandline switch which would output a log file similar to the RB build. The information provided by this log file has proven to be very useful in determining field order / scanning order, and is now extensively used by NuMenu4u. I've answered this several times. It's on my work list.

Now you please tell me specifically what information you want to see in there. But please do it in Cyberia's "development" thread.

Guest
20th May 2004, 13:46
@Zeul

The DVD2AVI GUI and navigation is a mess. A slight inaccuracy on frame counts in Preview is a consequence of it. I plan to redo all that stuff so it's not worth bothering with right now. The main thing is to get a correct D2V file written. Thanks for reporting your results.

@Lord

You can consider encoding the movies separately, so that you can apply FF to the parts that are all film.

I plan to write a tutorial after the formal release.

Lord_KiRon
20th May 2004, 13:59
Originally posted by neuron2

@Lord

You can consider encoding the movies separately, so that you can apply FF to the parts that are all film.

The "problem" is that it "looks" like the whole episode is a film , the only thing I can think of is that episodes that are not detected as film were edited after telecine ...

Zep
20th May 2004, 14:17
Originally posted by neuron2
The green frame (sometimes pink) is fixed in my latest for release. Actually, it appears only at the end of Save Project sometimes, and never appears in MPEG2DEC3dg output. Stuff like that is always a big deal for me. :)

The problem is that at the end of the Save Project the last frame is displayed but the previous frames were not decoded, so it may not have its reference frame. Now at the end of a Save Project I don't display the last frame, but just write the coded frame count into the info dialog instead. Then I raise a popup for the user to dismiss, after which I navigate back to frame 0. This avoids ever positioning on a frame without its reference frame having been decoded.


hmmmm... I saw at the end of MPEG2DEC3dg output feed to avisynth--->VDub.
The good news NO crashes on last frame on either pass.
That is a first with the 1.3.0 versions.


ahhh yeah that seems like a good way to do it. But what
MPEG2DEC3dg output? I am getting green frames at end.
I will double check it all later when i get back from work
and try to give more details and maybe UL a clip for you
if i can get it to re produce on a small .ts.

Guest
20th May 2004, 14:27
@Zep

If you pass a stream to MPEG2DEC3dg with incomplete or corrupted final pictures, you will get what you deserve. The only thing I can do is not crash.

EDIT: It is *possible* to suppress the last picture but I think it runs against my general philosophy of delivering all pictures in the stream. If there is a picture header, as far as I am concerned, there is a picture. :p

BoNz1
21st May 2004, 02:57
neuron2, I retested with RC5 and everything works as it should. Thanks :).

Guest
21st May 2004, 03:01
Great, and thank you! Then, unless there are objections, I will release 1.3.0 final. Going...going...

Guest
21st May 2004, 04:33
.....GONE!

Version 1.3.0 final and source code is available here:

http://neuron2.net/fixd2v/decodefix.html

I'd like to sincerely thank the people in this forum for suggestions and feedback on the betas/RCs. You can't believe what an incredible resource you are to a developer! I simply stand in awe.

Look for a new thread about version 1.4.0 feature definition. The train's still chuggin'. Y'all stay on board, ya heah?

Guest
21st May 2004, 04:41
Originally posted by Lord_KiRon
The "problem" is that it "looks" like the whole episode is a film , the only thing I can think of is that episodes that are not detected as film were edited after telecine ... The film detection is based solely on the RFF flags in the stream. It is possible that the problematic episode was "hard telecined", that is, 3:2 pulldown was applied prior to MPEG encoding and RFF flags were not used. Or, it's possible that they had hybrid or CG scenes and didn't apply RFF to those, thereby lowering the film percentage.

CruNcher
21st May 2004, 10:12
@neuron2
congrats for the release :)
at which version number pva support will be introduced ?

Zep
21st May 2004, 11:02
Originally posted by neuron2
@Zep

If you pass a stream to MPEG2DEC3dg with incomplete or corrupted final pictures, you will get what you deserve. The only thing I can do is not crash.

EDIT: It is *possible* to suppress the last picture but I think it runs against my general philosophy of delivering all pictures in the stream. If there is a picture header, as far as I am concerned, there is a picture. :p

oh I totally agree. That MPEG2DEC3dg should pass all frames
BUT IMHO dvdtoavi should NOT index currupted frames if it spots
one.

Hmmm... ok that may be TOO extreme so

better yet at least throw an error to a log so the user knows
what frame to trim and doesn't go to encoding thinking all is
fine and can run fix and parse which may help and/or may help the
user decide if doing a trim on a bad frame in the middle of a
scene is worth it.


Anyway, there is no messed green frames when i play the file
in the HDTV player that comes with the card. now the HDTV app
COULD have code that fixes it since it created the file. who
knows.

like i said i really do not care since i always cap a few minutes
long anyway and trim it out. For me the big issue was CRASHING on
the last ***GOOD*** frame of what was there after a trim.

That appears to be fixed. I was never able to figure out WHY
it did it. I have a hunch though. when scanning for editing,
VDub via MPEG2DEC3dg/avisynth feed always chooses the same
frames on a quick slide of the preview slider. To get to frame
level editing I have to use left and right arrow keys. When I
leave the edit at a quick slide (perhaps GOP level? or even bigger
VDub/avusynth decide on the jump amount?) it never crashes.
When I edit at frame level it is a crap shoot.

Zep
21st May 2004, 11:04
Originally posted by neuron2
.....GONE!

Version 1.3.0 final and source code is available here:

http://neuron2.net/fixd2v/decodefix.html

I'd like to sincerely thank the people in this forum for suggestions and feedback on the betas/RCs. You can't believe what an incredible resource you are to a developer! I simply stand in awe.

Look for a new thread about version 1.4.0 feature definition. The train's still chuggin'. Y'all stay on board, ya heah?

haha i barely had time to test RC5 :D


cool I will DL it now and jump over to the new thread.

Guest
21st May 2004, 13:14
Originally posted by CruNcher
at which version number pva support will be introduced? It will be introduced in the first revision at which it is fully functional. Currently video is working fine but the audio is not cooperating. It should be easy and the code is short and sweet for the audio. But when I pull out the audio it has chirps on top of the real audio. I took the audio out using other tools and compared the resulting ES streams. Mine has extra audio frames that really are in the stream and I can see nothing in the spec that tells me to exclude these frames. So I'm still scratching my head about that. Any ideas?

I do have some source code for Project X and plan to look at it to see if there is anything in there that will explain this.

Guest
21st May 2004, 13:21
Originally posted by Zep
That appears to be fixed. I was never able to figure out WHY
it did it. It's very simple. The decoder started decoding the last incomplete picture and while processing a slice the valid bits ran out and it just started grabbing random stuff from the bit buffer and crashed.

I'm considering ignoring the last frame if it is incomplete. I think it's important to be robust in that regard.

Nebob
21st May 2004, 19:22
How is mpeg2dec3dg.dll built? Is there any sense in attempting further optimizations with ICL and so on? I will try it and report my results if it hasn't been done before.

Guest
21st May 2004, 19:27
Originally posted by Nebob
How is mpeg2dec3dg.dll built? Is there any sense in attempting further optimizations with ICL and so on? I will try it and report my results if it hasn't been done before. It's built using VC++ 6 with sp5 and processor pack. Any speed improvement ideas will be gratefully received.

Nebob
21st May 2004, 19:33
Originally posted by neuron2
It's built using VC++ 6 with sp5 and processor pack. Any speed improvement ideas will be gratefully received.

Ok, I'll test some builds and see what I get. You may also be interested to know that SP6 was released back in march. I know, it snuck up on me too. ;)

edit: I did some tests with ICL and observed no practical difference.

Zep
21st May 2004, 22:26
Originally posted by neuron2
It's very simple. The decoder started decoding the last incomplete picture and while processing a slice the valid bits ran out and it just started grabbing random stuff from the bit buffer and crashed.

I'm considering ignoring the last frame if it is incomplete. I think it's important to be robust in that regard.

please do. if it can't be encoded it should never be sent.


nothing worse than doing a 2 pass you start it,
leave for work, get home and it crashed on the last frame of
pass one and all the time you had to encode was lost.

one of those things that makes me go grrr.........


i wonder why VDub crashes AND closes. I can see it crashing
and throwing up a "do you want to send a crash bug report" but
VDub closes cleanly and even saves the video.pass file
(cache is flushed and file is complete so it seems as if
VDub/Xvid did do a close() on that pass file)

very head scratching LOL

Guest
21st May 2004, 22:33
Originally posted by Nebob

edit: I did some tests with ICL and observed no practical difference. That was my experience, too.

Cyberia
21st May 2004, 23:51
edit: I did some tests with ICL and observed no practical difference.

The actual decoder and idct algorithms have been repeatedly optimized by many fine programmers here. Now maybe some guru will come along and fix a bug no one noticed that speeds things up, or will think of a revolutionary way to speed the process up, but... I'd say it's about as fast as it's going to get (within +/-5%)

You probably won't be able to get any significant performance improvements unless you manually walk through the compiler and hand tune each function, and even then I'd be surprised if it was a quantum leap.

Guest
22nd May 2004, 00:21
Sure, but let's not foreclose the possibility! Who knows what a guy with fresh thinking can come up with?!

TEB
22nd May 2004, 11:07
Nuron; Ive tested it now with my SPTS testsuite and it crashes on most of my streams. PM me and ill give ya an account on the ftp so we can check this out.
We're talking DVB SPTS, PAL world SD AND HD.

best regards
teb

Guest
22nd May 2004, 13:23
Originally posted by TEB
Neuron; Ive tested it now with my SPTS testsuite and it crashes on most of my streams. PM me and ill give ya an account on the ftp so we can check this out. We're talking DVB SPTS, PAL world SD AND HD.
Please just PM me with the account details. I have to ask for everything? :)

Thank you.

TEB
22nd May 2004, 15:40
1.3.0

OK. PM'ed u with the details.. Heres some observations:

*I tried to get the detect pids on a 18gb 4:2:0 50mbit Iframe only PS and it crashed after a while. (just to check!! i know there arent any pids in a PS!)
*Is it possible to add speed making the code more Hyperthreading aware? And make it multithreaded/tasked so a full SMP system could be used better?

Keep up the good work!!

teb

malkion
22nd May 2004, 16:23
Thank you Donald. I am most appreciative of your efforts.

Best wishes.

Guest
22nd May 2004, 16:27
You're welcome, malkion. I'm happy that you find my work useful. Speak up if you have any ideas to improve things!

Guest
22nd May 2004, 17:40
@TEB

Let's get the basic stuff going first and then discuss the rest.

Regarding the streams provided to me that cause crashes...

1. You probably know this but you have to rename the extensions to ones that DGIndex interprets as transport streams. Currently it does not include 'm2t'. I am adding that, however. Any more you care to suggest?

2. If you have the PIDs set right before opening the file (and correcting issue 1 above), the files I tried open fine. I didn't try them all yet but will do so. I found a bug in DGIndex that causes the crash when the PIDs are wrong. I fixed it and it is fine. I'll make a point release of DGMPGDec 1.0.1 later today with that fix.

3. The files I opened had MPEG audio, not AC3. I haven't yet added support for that, but it won't crash. How do you want me to handle your audio. Do you want a demuxed transport stream, a PES, or an ES?

seewen
22nd May 2004, 20:14
It seems that there's sometimes a problem in DVD2AVI 1.1.0/1.3.0 and/or in MPEG2Dec3dg.dll, when used with CCE or TMPGEnc.

I wanted to backup "187" (an old movie with Samuel l. Jackson). It's a french edition ("TF1" edition).

Like usually, I created the *.d2v, then the *.avs, then I launched CCE.
The movie is 1h54 long. The first 1h10 minutes are perfect, but the last 30-40 minutes are "blocky". Every part of the movie which is moving (a man, a hand, a car, mouth, etc.. ) is only composed of big blocks.

I thought the problem comes from the bitrate (4350). So I changed to 1/2 DVD resolution (352x576), and launched CBR encodes.

The result was identical. And it's strange beccause when I parse the *.avs, this problem doesn't appears.

I try CCE SP 2.67.0.27, 2.50, TMPGEnc 2.5, and it was always the same. I tried with Decodefix 1.1.0 and 1.3.0, and it was always the same.
I tried to add "TomsMoComp" to the *.avs, even if the movie wasn't interlaced, but big bloks were always here.


Then I tried MPEGDecoder.dll (from Nic. I let it create the *.d2v too), and it was perfect with TMPGenc CBR (didn't try with CCE yet, but I assume it will be perfect too).

I tried other movie (Shawshank Redemption. Same "TF1" edition) with Decodefix 1.3.0 and CCE 2.67, and many more movies with 1.1.0, but this problem only occurs with "187".

It's the first time since I use CCE/TMPGEnc (for CVD/DVD) that I see such a thing.

I don't know if you can do something with what I said.. ;)

bye

Lord_KiRon
22nd May 2004, 21:22
Have sadly to report that this version (1.3.0) runned from robot4rip does not detect "FILM" mode even when during the work percentage was 98-99% it still creats .d2v file with 29.97fps and Field_Operation=0 , also .d2v file name does not contain word "FILM" any more :(
Rechecked few times by running 1.1.0 - averything OK there ...

ExarKun634
23rd May 2004, 05:34
I have looked through the change logs (change_*.txt) and the readme files (Readme.html). I have searched for "raw encoded frames" in this forum. I have looked through the development thread for DVD2AVIdg 1.20. I found documentation on the difference between the Field Operations "Raw Encoded Frames" and "Forced FILM", but I found no documentation on the difference between setting Field Operation to "None" and setting Field Operation to "Raw Encoded Frames". Could someone enlighten me?

TEB
23rd May 2004, 08:37
Neuron2

Hi. Thx for testing my streams. I will not claim to be any kind of expert in anything of this but ill try to explain in my kinda way :)

Some of these streams are dumped on a linux box from a given Satellite's transponders in SPTS format (i split out the given services i need (SPTS) from the MPTS in a hardware box before hitting the linux box)
In my experience Northern European DVB SPTS Services typically contain the following pids; Video Pid, Audio Pic1,2,3 and so on, AC3 pid 1,2,3,
DVB subtitling (similar to dvd-subs),DVB Teletext, and a ton of controllstreams for various satellite boxes (i filter these out).
I would luve to get DVD2AVI to eat all of these formats by reading the PAT/PMT get the PID's automatically like Videolan does, parse the stream and give the option on what u can demux and make a .d2v file outa.
.m2t, .ts, .spts, .mpg, are typical endings on transportstreams.
The timestamps can either be read from the PTS, gop-timestamp or skipped and base it off the complete file during the .d2v generation. Since the 2 former often are erronous, just used for sync.

The other streams there are HD-mpeg2 found on the net (and this forum).

keep up the good work!

teb

loni_blues
23rd May 2004, 16:14
@Lord_KiRon

I´ve found the same thing myself. It is due to a change in d2v structure in new Dvd2avidg versions. I believe we now have to use F5, check the film percentage and apply force film manually, since -as len0x pointed out- R4r is not going to be developed anymore.

Kind regards,
loni_blues

Guest
23rd May 2004, 16:51
Originally posted by seewen
It seems that there's sometimes a problem in DVD2AVI 1.1.0/1.3.0 and/or in MPEG2Dec3dg.dll, when used with CCE or TMPGEnc.
[...]
I don't know if you can do something with what I said.. I can do something if you can make a small VOB fragment available that I can use to recreate the problem. Please do so.

Guest
23rd May 2004, 16:55
Originally posted by Lord_KiRon
Have sadly to report that this version (1.3.0) runned from robot4rip does not detect "FILM" mode even when during the work percentage was 98-99% it still creats .d2v file with 29.97fps and Field_Operation=0 , also .d2v file name does not contain word "FILM" any more :(
Rechecked few times by running 1.1.0 - averything OK there ... Yes, the D2V file format changed, as loni_blues pointed out.

Guest
23rd May 2004, 16:59
Originally posted by ExarKun634
I have looked through the change logs (change_*.txt) and the readme files (Readme.html). I have searched for "raw encoded frames" in this forum. I have looked through the development thread for DVD2AVIdg 1.20. I found documentation on the difference between the Field Operations "Raw Encoded Frames" and "Forced FILM", but I found no documentation on the difference between setting Field Operation to "None" and setting Field Operation to "Raw Encoded Frames". Could someone enlighten me? I can help you with that one. :)

When you do FF, DGIndex will add or insert frames to keep the film rate. Let's suppose you have a hybrid VOB that is mostly 3:2 pulldown but with some sections of 30fps (no RFFs there). DGIndex has to remove frames from the 30fps sections so that when the frame rate is set to 24fps, those sections don't play too slow. Other situations may require frames to be added. It all results from DGIndex wanting to output a 24fps result.

When you do raw, DGIndex does everything the same but never adds or removes frames. This lets you see exactly what the stream has in terms of encoded pictures, hence the term raw.

Guest
23rd May 2004, 17:04
Originally posted by TEB
Some of these streams are dumped on a linux box from a given Satellite's transponders in SPTS format (i split out the given services i need (SPTS) from the MPTS in a hardware box before hitting the linux box)
In my experience Northern European DVB SPTS Services typically contain the following pids; Video Pid, Audio Pic1,2,3 and so on, AC3 pid 1,2,3,
DVB subtitling (similar to dvd-subs),DVB Teletext, and a ton of controllstreams for various satellite boxes (i filter these out).
I would luve to get DVD2AVI to eat all of these formats by reading the PAT/PMT get the PID's automatically like Videolan does, parse the stream and give the option on what u can demux and make a .d2v file outa.
.m2t, .ts, .spts, .mpg, are typical endings on transportstreams.
The timestamps can either be read from the PTS, gop-timestamp or skipped and base it off the complete file during the .d2v generation. Since the 2 former often are erronous, just used for sync.
Thank you for the information. But you didn't answer my question about the audio. How do you want to receive the MPEG audio? Demuxed transport, PES, or ES? What is your process for handling audio?

Within minutes I will release DGMPGDec 1.0.1 that fixes your crashes problem and retrieves the video from all your streams. But I need to know how to handle the audio.

EDIT: DGMPGDec 1.0.1 released at my web site. It fixes the crashing with your streams. Please advise about the audio.

Wilbert
23rd May 2004, 17:42
Thank you for the information. But you didn't answer my question about the audio. How do you want to receive the MPEG audio? Demuxed transport, PES, or ES? What is your process for handling audio?
I guess this question holds also for other audio stream AC3 and later hopefully AAC :) I'm not sure what the difference is between PES and ES (googled around, but it's too technical for me). I would like to have the audio as a dts, ac3, aac or mpa file (and not in an empty transport file).

Guest
23rd May 2004, 18:39
DGMPGDec already gets the AC3 audio out of transport streams into an ES. So I suppose we should do the same for the other audio types. You've pointed me to the code for AAC. Straight MPEG audio should not be any problem either.

Guest
23rd May 2004, 18:43
Originally posted by Wilbert
I'm not sure what the difference is between PES and ES (googled around, but it's too technical for me). ES is just the plain simple compressed audio data.

If you take the ES and break it into little chunks, called packets, and you add a header to each packet, and you put useful stuff in those headers, like presentation time stamps (PTS), then you have a packetized elementary stream (PES).

If you take the PES and break *that* up into 188-byte packets, and add useful headers to those packets, including things like packet IDs (PIDs), then you have a transport stream.

This is called layering.

TEB
24th May 2004, 19:47
Hi. Handle mpeg audio like u do in normal program streams. Or maybe i misunderstood ure question?
I just want it to be robust and handle all kinds of transport streams and be able to read em with one chosen audio format in avisynth! :)

best regards

teb

Guest
24th May 2004, 20:21
Originally posted by TEB
Handle mpeg audio like u do in normal program streams. ES it is then! Thank you for your feedback.

Fox Mulder
31st May 2004, 08:17
Originally posted by ExarKun634
I have looked through the change logs (change_*.txt) and the readme files (Readme.html). I have searched for "raw encoded frames" in this forum. I have looked through the development thread for DVD2AVIdg 1.20. I found documentation on the difference between the Field Operations "Raw Encoded Frames" and "Forced FILM", but I found no documentation on the difference between setting Field Operation to "None" and setting Field Operation to "Raw Encoded Frames". Could someone enlighten me?
Originally posted by neuron2
I can help you with that one. :)

When you do FF, DGIndex will add or insert frames to keep the film rate. Let's suppose you have a hybrid VOB that is mostly 3:2 pulldown but with some sections of 30fps (no RFFs there). DGIndex has to remove frames from the 30fps sections so that when the frame rate is set to 24fps, those sections don't play too slow. Other situations may require frames to be added. It all results from DGIndex wanting to output a 24fps result.

When you do raw, DGIndex does everything the same but never adds or removes frames. This lets you see exactly what the stream has in terms of encoded pictures, hence the term raw.

It seems to me that ExarKun634 wanted to know if the output of Field operation set to NONE is the same as RAW ENCODED FRAMES or not; and not the difference between Forced FILM and Raw Encoded Frames.

BTW, thank you for your work in DGMPGDec, it rocks. :D

Guest
31st May 2004, 13:19
Oh, OK, I misread it.

The difference is that with NONE, RFF flags are honored, i.e., pulldown is performed, while with RAW, RFF flags are ignored, i.e., pulldown is not performed. So as I said, RAW is the same as FF but with no frame decimation/duplication to keep the film rate.

Cyberia
31st May 2004, 18:31
Don, I wondered about that myself. We need to VERY clearly spell out the differences between the Field Operations in the manual and in the FAQ. Would you like the first shot at that paragraph? or do you want me to try and you correct it?

Guest
31st May 2004, 21:16
Go ahead, Cyberia! The user perspective is often the preferable one.

jarthel
4th June 2004, 05:30
is the d2v output still compatible with 1.76? cause I can't open the output d2v in gknot or vdubmod (through avs script). Thanks

jayel

Guest
4th June 2004, 12:12
The D2V file format is now much different from that of 1.76.

But that doesn't mean you can't use the new versions in VirtualDubMod and GKnot. You just have to ensure that you use both DGIndex.exe and DGDecode.dll, and that you don't accidently pick up earlier versions. Usually the problem people run into is they inadvertently use an earlier version of mpeg2dec3. In your AVS script, remove the loadplugin call for mpeg2dec3.dll and replace it with a load of DGDecode.dll.

jarthel
5th June 2004, 14:28
thanks neuron2. :)

jayel

edit:

Just an additional question. What version of vdubmod and gknot supports the latest d2v format? I have vdubmod 1.5.10.1 build 2424 and gknot 0.28.8 both doesn't seem to work. thanks again

LigH
5th June 2004, 14:50
Furthermore, it seems that you have to make a copy of DGDecode.dll, rename it to "mpeg2dec3.dll", and put this renamed DLL into the GordianKnot folder, if you want to make GordianKnot open a d2v file created with DGIndex.exe - it seems that the filename "mpeg2dec3.dll" is hardcoded into GordianKnot, it does not use the filename written into the edit line on the "Options" tab.

At least, I was not able to make GordianKnot 0.28.8 use the DGDecode.dll for loading d2v files into GordianKnot just by writing "DGDecode.dll" into that edit line (and placing the file into the folder where the "GordianKnot.exe" is, of course). GordianKnot would then write

LoadPlugin("DGDecode.dll")

into the created AviSynth skript; but for its own preview window, it seems to always use an "mpeg2dec3.dll" if the checkbox "use alternative DLL" is checked.
__

VirtualDubMod is not interested at all in any version of DGEncode.dll, if you open an AviSynth skript. If the d2v project file was made with DGIndex.exe, use

LoadPlugin("DGDecode.dll")
MPEG2Source("*.d2v")

then AviSynth skripts work well.

jarthel
5th June 2004, 15:11
thanks for the clarification. :)

Guest
5th June 2004, 16:19
Yes, thank you, LigH.

freelock7
9th June 2004, 06:55
Sometimes, DVD2AVIv1.76 create a bad .d2v (the beginning of the movie with 2 introduction tracks).
Sometimes, delay is not correct even corrected by a DELAY CORRECTOR.
I tried the decoder fix with AVISYNTH2.5 but the problem remain...
Ex: star wars 1&2 with DVD2AVIdg/MPEG2DECdg Decoding Fix create a bad ac3 file with many desynchro.
Is there an update to fix these errors?

Guest
9th June 2004, 13:40
Version 1.3.0 is about 12 revisions old and this thread is dead now. Please make a new thread describing your problem and we will try to help you.