DVD2AVIdg/MPEG2DEC3dg Version 1.2.0

[Zep]

Originally posted by neuron2

Not yet. Version 1.3.0 will have transport streams/HD support and upsampling fixes (and maybe more). I want to get 1.2.0 stable out the door.


oh yes i am truly looking forward to version 1.3.0. lack of ts/HD support is the main
reason i do not use your current version and was the main reason i sent you
.tp streams last week for testing so you could get support going :D


this version I will start using. Consider me a HUGE beta tester when it is released
cause I'm gonna really pound on 1.3.0 lol


thanks for all your hard work DG

[Guest]

I can provide said clip if you want it for testing :devil: ;) Why do you guys have to ask??? :rolleyes: Now I have to wait for you to show up again.

Yes, please provide said VOB. Also look at the output of ParseD2V. It may be that the RFF flags you applied actually do create only 596 frames. And that's consistent with your 98.3% film figure.

I have a new version ready but this holds it up.

Man, I want to get 1.2.0 out because I'm itching to get the transport support in there.

[vispgraedde]

Sorry :p
Next time I'll pm a link to the stuff right away.

And unless I misread the parsed2v output, it should be 600 frames. At least the last line is
479: 598,599,599 -- 1 [vob/cell=5/1]

[Guest]

Originally posted by vispgraedde
Sorry :p
Next time I'll pm a link to the stuff right away.

And unless I misread the parsed2v output, it should be 600 frames. At least the last line is
479: 598,599,599 -- 1 [vob/cell=5/1] Thank you for posting it. I had a look and all is well. :D

Didn't you notice the illegal transitions in the parse output??? When you fix it with FixD2V and then reparse, you'll see where the 596 comes from.

You have to make legal VOBs!

I plan to integrate FixD2V into DVD2AVIdg to be able to pop up a warning on Save Project and give the user an option of fixing it.

So, as Cyberia likes to say "no problem found."

[vispgraedde]

I see it now.
Makes me wonder though, because the individual m2v's used to create the multiangle file have no such problem.

To further my understanding about how multiangle works, I must ask if it is correct to go from
41: 51,51,52 -- 3 [vob/cell=1/1]
to
42: 52,53 -- 2 [vob/cell=2/1] [3:2 pattern break] [ILLEGAL TRANSITION!]

since when you play back a multiangle file, it plays through one angle, and don't jump to the start of another.

Intuitively, it should go from 41 to:
210: 262,263 -- 0 [vob/cell=1/1]

since that is the next logical part that a player plays.

This ties in with other things that I meant to ask for for a future revision of your tools, but before that, please say if the jump from 41 to 42 should really be interpreted the way it is now.

[Guest]

You've concatenated different angles into a single VOB? You have to tell me your process.

Al I can say right now is that your VOB is illegal becauses it switches the field order.

Aren't different angles in different VOBs on a proper DVD?

[zettai]

No, on most proper DVDs I've seen they have multiple angles in the same vob so if you decode the vob as-is you get a second or so of one and then a second or so of the other.

I'm not sure exactly how it works but I presumed it was done by interleaving gops. I could rip some from real dvds if you want me to check how it's done (and if it works in dvd2avi) when authored professionally.

[vispgraedde]

I just used DVD Maestro and added video the way the helpfiles showed how to do it.

These angles belong in the same program chain (as shown by smartripper).

My understanding of multiangle is that they sit in the same vob and are grouped with a few gops from angle1, then same number of gops from angle 2, etc.

[vispgraedde]

The layout in the example vob I sent is

angle 1 gop 1 to x
angle 2 gop 1 to x
angle 3 gop 1 to x
angle 4 gop 1 to x
angle 5 gop 1 to x
angle 1 gop (x+1) to y
angle 2 gop (x+1) to y
angle 3 gop (x+1) to y
angle 4 gop (x+1) to y
angle 5 gop (x+1) to y

[Guest]

Let's leave this to version 1.3.0. Please start a separate thread titled "Multiangle support in DVD2AVIdg."

[Guest]

Here is RC6. I hope this can be it for 1.2.0 so I can get on to the transport support and upsampling support.

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

This version changed the D2V indexing method to be theoretically correct in that the packet starts are indexed for packetized streams. It finally squishes the silly LBA-1 crap in there. End users may not notice any changes, unless they like to output 1.76-style D2Vs. That support is now gone. See the changes file for an explanation.

This version of MPEG2DEC3dg tests the D2V for compatibility and will return a file open failure to VirtualDub if the D2V is an obsolete one.

[Cyberia]

@Neuron2: Don how about starting two threads on this forum starting with 1.3....

One thread would be for "1.3 Bugs Only" and the other would be for "Enhancements to 1.3"

I'm guilty of it too, but it's just in the course testing the current release, I notice things that I'd like improved. They usually aren't bugs, but they have room for improvement. 99% of the time they could easily wait for the next release, but I post them to the current thread because it seems like the best place to post them.

I am literally testing RC6 sitting on a beach with my feet in the water and with a mai-tai. I won't even mention the girls.....

[Guest]

Originally posted by Cyberia
@Neuron2: Don how about starting two threads on this forum starting with 1.3....

One thread would be for "1.3 Bugs Only" and the other would be for "Enhancements to 1.3" I thought we were using your Development thread for that.

I am literally testing RC6 sitting on a beach with my feet in the water and with a mai-tai. I won't even mention the girls..... Well, I'd be busy with the girls. :p

[Trahald]

angles arent layed in the vob with intent for the vob to be read sequentially (so there would generally be pattern breaks at every angle switch [except for some possible dumb luck] - the longer the clip the worse it would get). there would have to be true angle support added. anywho, normally angles are demuxed separately before processing in dvd2avi by most apps out there. not to say angle support wouldnt come in handy ;)

[DDogg]

Is "load project" supposed to work on the latest versions? I attempt to load and nothing seems to happen. Also I noticed the audio streams now have ".d2v" in the file name, like Gothica.d2v AC3 T03 2_0ch 192Kbps DELAY -16ms.ac3. In the previous version the name was, Gothica AC3 T03 2_0ch 192Kbps DELAY -16ms.ac3

[Guest]

Oops. I "improved" the filename handling and wasn't my usual thorough self. Thanks for pointing it out.

[Guest]

Here are the fixes:

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

BTW, I have transport support working. It's just tidying up and adding PID detection now.

[Zep]

Originally posted by neuron2
Here are the fixes:

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

BTW, I have transport support working. It's just tidying up and adding PID detection now.

actual WORKING auto PID detection?


YEAH!!!!!!


but be warned and I MAY have to send you a .ts or .tp on this...

HDTV broadcasts try to be tricky recently to stop cappers so as
an example my local WB HDTV stream sends the video on
PID 21 but alternates the audio between PID 24 and PID 25
throughout the broadcast. I am NOT sure how my MYhd card
knows when that happens and knows when to pull the correct
audio to play out but when using the current HDTV dvdtoavi version
from nic and tbarry it always fails to detect the pid changes and
thus i get silence in the audio AC3 demux (or to wav file etc..)

so you will need to figure out how to detect this and in the mean
time leave the ability to manually select the PIDs so we can run
the save project twice, then merge the two AC3 files (the only
work around i have been able to get to work great but it is
a pain in the arse and time consuming)

looking at the streams i see you could detect silence
and when that happens change the PID on the fly then look
to see if there is audio in the other stream and if so use
that until next silence then jump back etc...

i would leave it an option though as sometimes you WANT
the audio cuts as FOX does the same thing but only on ad breaks
so it makes it super easy to auto detect ads and cut them out.


and you thought 1.3.0 was gonna be easy :D

[Guest]

You'll have to send the stream because I don't believe you. :D

How can a receiver know when to change PIDs? It just makes no sense. Maybe the code from Nic/trbarry is just not parsing the stream fully correctly.

Even if it were true, the PID filter could accept both 0x24 and 0x25, unless they send garbage on the second one.

In any case, if there is enough information in the stream to decide which PID to use, then we can also grab it.

Of course, alternate audio is often sent on different PIDs, but it doesn't change dynamically.

[Guest]

Originally posted by Zep
oh yes i am truly looking forward to version 1.3.0. lack of ts/HD support is the main reason i do not use your current version and was the main reason i sent you .tp streams last week for testing so you could get support going That 1088i stream is a b*tch. Not because it's hard to decode, that's easy. The problem with it is the final picture is not complete and the file runs out. That crashes the decoder. This exposes an interesting flaw in the design. The decode process just blindly does Get_Bits() calls and has no way to know that there aren't any more!

I'm still thinking about what to do about that. This is the second such file I've seen in a week so it isn't rare. And Cyberia will be very unhappy with any crashes. :scared:

[vispgraedde]

I have to ask... is the position part of the GOP lines in the d2v's used for anything other than random navigation?

In a (newly created with RC7) d2v, I removed a number of lines from the middle of the d2v. The result was not what I expected.

I changed a part in my d2v from

7 0 165888 1 1 10 11 12 13 10 11 12 13 10 11 12 13 10 11
7 0 399360 1 1 12 13 10 11 12 13 10 11 12 13 10 11 12 13
...
7 0 3096576 1 1 10 11 12 13 10 11 12 13 10 11 12 13 10 11
7 0 3317760 1 1 12 13 10 11 12 13 10 11 12 13 10 11 12 13
7 0 3538944 1 1 10 11 12 13 10 11 12 13 10 11 12 13 10 11

to
7 0 165888 1 1 10 11 12 13 10 11 12 13 10 11 12 13 10 11
7 0 3317760 1 1 12 13 10 11 12 13 10 11 12 13 10 11 12 13
7 0 3538944 1 1 10 11 12 13 10 11 12 13 10 11 12 13 10 11

and instead of trying to skip from 165888 line to 3317760 (treating the possible illegal transition in some good manner), it goes on to decode the 399360 line... with what flags? I don't know...

How should it be handled? Dunno...
How about inserting blank frames for the part where the d2v have been deleted?

PS.
Don't let this hold up 1.2.0... It was just yet another thing I noticed :p

(I should stop playing around with this... I find new things to note every time I use it it seems :o )

[RB]

Originally posted by neuron2
Look at the first two and the last two GOP lines in your post. They both have illegal transitions! E.g., in the last two lines it transitions from 2 to 0. That changes the field order.
Although I think it's unusual, it is legal for MPEG2 to mix frame and field coded pictures. So I think this transition is legal, what could have happened is that the stream switches from a TFF frame picture to TOP_FIELD field picture. You know, for field coded pictures, the TFF flag is never used and always set to 0...

[Guest]

Originally posted by vispgraedde
I have to ask... is the position part of the GOP lines in the d2v's used for anything other than random navigation? No. If you play linearly the decoder just decodes the pictures in order from the stream.

In a (newly created with RC7) d2v, I removed a number of lines from the middle of the d2v. The result was not what I expected. That is not a valid or supported manipulation. Use Trim() in Avisynth to remove frames.

How should it be handled? Dunno... How about inserting blank frames for the part where the d2v have been deleted? For speed during encoding, we don't want to have to do indexed frame location for every frame. It is very slow. That is why the frames are just decoded in order when playing linearly.

Are you just playing or are you trying to accomplish something useful?

[Guest]

Originally posted by RB
Although I think it's unusual, it is legal for MPEG2 to mix frame and field coded pictures. So I think this transition is legal, what could have happened is that the stream switches from a TFF frame picture to TOP_FIELD field picture. You know, for field coded pictures, the TFF flag is never used and always set to 0... Good point, RB! It didn't occur to me. When I expand the indexing to include these flags, FixD2V will be able to distinguish that case. Thanks for pointing this out.

[vispgraedde]

Originally posted by neuron2

Are you just playing or are you trying to accomplish something useful?

This time I'm just trying to better my understanding of how these things work and I feel the best way to do that is to play around with the tools.

I want to understand the tools fully, and be certain that the output I get is predictable and correct.

[Moitah]

Another seeking problem, both VirtualDubs have the same .avs open (it has only 1 line, which is MPEG2Source). The frame in the top was reached by holding the right arrow key on my keyboard (no seeking), the bottom was reached by using "Go to" (Ctrl+G). Though the frame numbers are the same, the frame on the bottom is actually 13 frames ahead of the one on the top. This is reproducable every time (RC6/RC7, I didn't test older versions).

http://members.cox.net/moitah/jojovobseek.jpg

NOTE: This is a different file than the one you already downloaded, this one's from a DVD. Send me a PM if you would like to download this (it's 209 MB but you can probably just download the first 1/3 of it if you want).

[Guest]

C'mon guys, please just post or PM the links. Don't ask me every time!!!! We can save a lot of time that way.

I can't duplicate this with the jojo you already sent me.

Also post the top of your D2V file so I can see your settings.

[Moitah]

Originally posted by neuron2
C'mon guys, just post or PM the links. Don't ask me every time!!!!

I can't duplicate this with the jojo you already sent me.

Also post the top of your D2V file so I can see your settings.
It's up now, same place as last time, I'll PM you the link to make sure you still have it. Here's the top of the D2V:

DVD2AVIProjectFile02
1
49 H:\DCC\Jojo-Leave_(Get_Out)_(LPCM-NTSC-Promo).vob

Stream_Type=1,0,0
iDCT_Algorithm=5 (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=4:3
Field_Operation=0 (0:None 1:ForcedFILM 2:SwapOrder 3:RawFrames)
Frame_Rate=29970
Location=0,0,0,1A309

7 0 2048 12 1 12 12 12 12 12 12 12 12 12 12 12 12 12
7 0 372736 12 1 12 12 12 12 12 12 12 12 12 12 12 12 12
7 0 882688 12 1 12 12 12 12 12 12 12 12 12 12 12 12 12

[therealjoeblow]

A (hopefully) simple request - dvd2avi is a useful to determine encoding zones like credits, or others. I developed a *very* simple tool that len0x uses as a plugin for AutoGK, that lets you calculate the frame number to set end credit compression based on timestamp and source type (NTSC vs. PAL). To use the calculator, you need to know the timestamp that the credits start.

To get this from .vob files, the fastest tool to load them and scroll through is dvd2avi, except when there is a split in the vob cell structure, the timestamp restarts at 0:00 - to get the proper time stamp where the credits start, you need to scroll through the video to find where the time counter resets to 0, write that down, then scroll to the next split, etc, etc, and do some 'time-math'. It would be nice if dvd2avi could display the actual real-time of where you have navigated to as well as the vob cell time that it currently does.

[Zep]

Originally posted by neuron2
You'll have to send the stream because I don't believe you. :D

How can a receiver know when to change PIDs? It just makes no sense. Maybe the code from Nic/trbarry is just not parsing the stream fully correctly.

Even if it were true, the PID filter could accept both 0x24 and 0x25, unless they send garbage on the second one.

In any case, if there is enough information in the stream to decide which PID to use, then we can also grab it.

Of course, alternate audio is often sent on different PIDs, but it doesn't change dynamically.

hate to break it to you but yes it changes dynamically and yes my 120 card
sees the change and always plays the sound. dvdtoavi never sees the change
but dvdtoavi is OLD and my drivers for my card are dated 4/19/2004
and one of the fixes was exactly for this problem.

well I will send one tonight. I am raw capping everwood right now
and IIRC it switches from PID 24 to PID 25 and back again about half dozen
times during the hour and my MYHD120 card dectects it and and I hear the audio
correctly.

when using HDTVtompeg You can see the 3 streams in the .ts

I also exported the PID 24 and PID 25 audio streams and looked at them in cooledit
audio app and sure enough wherever there is silence in one stream there is
sound in the other and vice versa and WHY an AC3 merge works.


This may be a tuff clip to send as to get a jump back and forth the clip
would be HUGE. so I will send the very end of a PID 24 then jump to PID 25
even so it will be about 25 megs so I may have dump the video.

HDTVtoMPEG is great for this.

[Zep]

Originally posted by neuron2
That 1088i stream is a b*tch. Not because it's hard to decode, that's easy. The problem with it is the final picture is not complete and the file runs out. That crashes the decoder. This exposes an interesting flaw in the design. The decode process just blindly does Get_Bits() calls and has no way to know that there aren't any more!

I'm still thinking about what to do about that. This is the second such file I've seen in a week so it isn't rare. And Cyberia will be very unhappy with any crashes. :scared:


ahhh good i see you noticed it was 1088i and not 1080i

oh yeah at the end of each pass VDub would crash and after reading
what you said above my guess that is why. My work around was to ALWAYS
run the raw cap long then delete the last few frames in VDub so that there was
always some data to pull in and the decoder wouldn't choke on whatever garbage
it was being fed.

shouldn't getbits() exit gracefully if no data is returned? What is it doing
sending random garbage to the decoder?

this bug has really bitten my bum over and over. I hope you can fix it.

[Trahald]

Originally posted by neuron2
Good point, RB! It didn't occur to me. When I expand the indexing to include these flags, FixD2V will be able to distinguish that case. Thanks for pointing this out.

nice.. more info would come in handy :D

[Guest]

moitah's bug is a real b*tch. Random access is the key to the kingdom so I have to concentrate on that right now. Please don't make new feature requests in release threads. Use the Development thread. Thank you.

[Zep]

Originally posted by neuron2


How can a receiver know when to change PIDs? It just makes no sense. Maybe the code from Nic/trbarry is just not parsing the stream fully correctly.


HAHA you know that COULD be a possibly :D


the only reason I tend not to assume that is because when audio
cuts in one stream it starts in the other perfectly lined up and the fact
it does it at commercials only on some feeds. I mean what are the odds
that the commercials are the only place we get a switch?


Now i did a quick scan of everwood (first time with the new drivers I looked into
this) and PID 24 has all the sound. PID 25 has the same drops
as always. The docs with the new drivers said that they addressed this issue
so recording would get all sound into the standard stream.

It appears they merged the streams on the fly into to PID 24 which is the
standard pid i.e. 11/14 & 21/24 is the norm for everyone.

I have a clip to send you but it is late so i will PM you tomorrow
the link once I UL it

[Guest]

I've found and fixed moitah's bug. It was quite obscure but made sense given the parsing architecture. The fix is a true fix and not a kludge. :)

As a reward for finding this, when I release the fix tonight I will include the transport stream support as well. It's ready, why wait? :D

[Boulder]

RC5 and RC7 don't seem to work on my system, I tried three different DVDs and one captured MPEG-2 file. When loaded with a simple MPEG2Source line in the AVS script, VirtualDubMod just hangs and so does Gordian Knot (I use it for automatic cropping). Version 1.1.0 works fine and IIRC RC4 worked too.

Any ideas for hunting this one?

[Guest]

@Boulder

I could try waving my magic wand or I could examine the stream after you make it available for downloading. Which do you think is likely to be more effective? :)

[Boulder]

Originally posted by neuron2
Which do you think is likely to be more effective? :)

:D

Actually I'm not sure if it's sample related.

I reinstalled RC7 after using v1.1.0, created a project, and it worked! Then I did another project without closing DVD2AVI, using DEL ALL and the ADD ALL buttons. I did two projects this way. These last two projects hang up VDubMod and the first one, created after a fresh DVD2AVI restart, does work.

Hope this clears things a bit up. :)

[Guest]

Please compare the D2Vs for when it works and doesn't work and report the results.

[Moitah]

Why is MPEG2Dec3.html from version 1.04? MPEG2Dec3dg is based on version 1.10, right?

[Guest]

Originally posted by Moitah
Why is MPEG2Dec3.html from version 1.04? MPEG2Dec3dg is based on version 1.10, right? That was MarcFD's original document. Nobody updated it yet. I'll fix it up.

[Moitah]

Originally posted by neuron2
That was MarcFD's original document. Nobody updated it yet. I'll fix it up.
It was updated, the one that came with 1.10 has an updated changelog, more IDCT options, warning about the colorspace conversion routines, maybe other stuff. Here's a copy (http://members.cox.net/moitah/MPEG2Dec3v110.html) if you need it.

[CruNcher]

@neuron2

i have a DVB HDTV Clip here that runs 9.4 fps in preview mode with the old dvd2avidg but only 5.4 fps with the new one both crash @ the same position

ok the crash isue is also with other Decoders so the stream must be corupt @ that position but why is the preview got so slow now, could that be the resize function ?

with normal res clips preview is 5 fps faster with the new dvd2avidg :)

[Guest]

Originally posted by Boulder
Hope this clears things a bit up. :) What really cleared things up was the VOB you sent me. I totally forgot about field pictures when I rewrote the indexing. :scared:

Don't worry, it's an easy fix. I'll put it out tonight with the preliminary transport support.

@Cruncher

Yes, it's the resizing. Most people complain the preview runs too fast! Isn't it the Save Project speed that is important?

[CruNcher]

@neuron2

ofcourse you right :)
do you think you can achive the same rendering speed with DGmpgdec like with libmpeg2 ?

[Guest]

Originally posted by neuron2
I totally forgot about field pictures when I rewrote the indexing. Actually, I didn't forget. It's fine. But your stream is illegal. It has field pictures but the first two fields of each GOP are I P when they should be I I. I can work around it for you by paying attention only to the first one, but where did you get this silly VOB???

[Guest]

Hakko, please close this thread as 1.3.0 beta 1 is coming tonight. Version 1.2.0 will not be released. All of its functionality will be in 1.3.0 beta 1 plus more. :)

[Boulder]

Originally posted by neuron2
Actually, I didn't forget. It's fine. But your stream is illegal. It has field pictures but the first two fields of each GOP are I P when they should be I I. I can work around it for you by paying attention only to the first one, but where did you get this silly VOB???

The movie's part of the recently released Chaplin collection. In this particular package there's "A Woman of Paris" and "A King in New York" and both of them refused to work with v1.2.0RC7. I've also got "The Kid" which is part of the collection as well and it gives no problems whatsoever. Maybe this is just one of those bad NTSC->PAL thingies?

[Guest]

Thank you for the information. It's not a ->PAL thing. Their MPEG2 encoder is doing stupid things.

I assume that my workaround is working for you.