DVD2AVIdg/MPEG2DEC3dg Version 1.2.0

[Guest]

I've cut loose version 1.2.0 release candidate:

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

EDIT: I updated this post to point to the latest build.

[zettai]

Great work!

One thing I'm interested in (as you know) is this chroma upsampling issue. I notice you've fixed it for vfapi.

With mpeg2dec, the problem could be similarly fixed if it were possible to ask for YUY2 or RGB footage directly from mpeg2dec. Equally it would be useful to provide an IsCombed-like hint which could be read by conditionalreader or possibly the colourspace covertion filters in future versions of Avisynth.

Are either of these approaches possible?

[Guest]

@zettai

Did you see my posting in Avisynth Usage? I'm mulling that over right now. Of course it is all possible. I want to assess the practical significance before I prioritize my work.

What do you think is the most important next step for DVD2AVIdg/MPEG2DEC3dg?

[zettai]

Yeah, I saw that post after this one.

I don't see a huge benefit at the moment of doing the conversion in mpeg2dec given that you will only be porting to avisynth and the conversion could be done just as easily there.

I'd be perfectly happy with just a conditional hint being sent - that would at least provide a fix for the problem. Anything else could come later, I suppose.

[Guest]

I agree. I will modify the conversion filters included in MPEG2DEC3dg to read the hint, and I will document the hint so that other filters can use it.

[stax76]

it's great you are working on DVD2AVI. I have two request, commas in source file names don't work with the commandline:

-Input-Files -IF ([file1,file2,file3,......])

captures often have commas. Maybe you could change the dll/exe name to the original names to prevent users from duplicates. I would like to send you a patch but I'm not sure I'm far enough with my C++ tutorial:(

[Guest]

Originally posted by Dolemite
I have two request, commas in source file names don't work with the commandline:

-Input-Files -IF ([file1,file2,file3,......])

captures often have commas. I don't want to break the existing clients.

Maybe you could change the dll/exe name to the original names to prevent users from duplicates. I don't understand your request.

[stax76]

let's assume you've two files capture,0.mpg and capture,1.mpg, it's not possible to open it with the cli because comma is used as delimiter instead of checking quotation marks plus comma (regex: " *, *") as delimiter before.

some users might copy MPEG2Dec3dg.dll to the AviSynth plugin directory and forget to remove MPEG2Dec3.dll. Changing it would also make it easier to deploy it with tools like DVX and Gordian Knot and a version like 1.0.0.0 that can be read with the API to ensure it's the proper version but I don't want to bother you with that things

[Guest]

Originally posted by Dolemite
let's assume you've two files capture,0.mpg and capture,1.mpg, it's not possible to open it with the cli because comma is used as delimiter instead of checking quotation marks plus comma (regex: " *, *") as delimiter before. I understand your point but the existing clients use the comma as a file list delimiter. If you can convince them to modify their syntax...

[Dark-Cracker]

some tools use the command line of dvd2avi but i think if u change the command line function in your next dvd2avi v1.2 the authors of these tools will read the changelog and made the necessary changes in their software to assume 100% compatibility with your new command line. i am sure all the people who use dvd2aviCLI will be happy to see this nasty bug have been corrected.

generaly when u release a new version this mean some new functions i think the fact the command line change, will not annoy the developpers who use dvd2avi.

>I understand your point but the existing clients use the comma as a file list delimiter.
the comma is allowed in the foder/file name it's foolish to use it as delimiter.

plz plz plz erase this annoying bug :)

[zettai]

I don't see why you just can't avoid putting a comma in your file...

[stax76]

you could implement it like this: if there are quotation marks use '","' as delimiter otherwise use the current method. Another suggestion would be supporting the windows shell. The windows shell uses a blank as delimiter and quotes only if the path has blanks. Windows shell is things like somebody put a link to DVD2AVI under "Send To" and send file(s!) to it or somebody use a context menu editor ("...DVD2AVI.exe" "%1"), "Open With", D&D etc.

[Guest]

Suggest a delimiter character that is not a valid filename character and not interpreted by the command shell. Thank you.

[stax76]

pipe (|)

[Cyberia]

Why not just require a file list? I realize it breaks compatibility, but it would fix this issue and shorten the command line when more than one file is used.

[Cyberia]

Suggest a delimiter character that is not a valid filename character and not interpreted by the command shell. Thank you.

Maybe a colon ":"

[Guest]

Dolemite, pipe is a shell character.

Cyberia, you mean a text file list?

: is a valid path character, e.g., c:\file

[Cyberia]

Cyberia, you mean a text file list?

Yep. You could generate one easily by using a command like:

dir *.vob /b /od >dvd2avi.lst

or you could even provide a GUI option to generate a list.

[Cyberia]

You could still use a colon by requiring just the filenames. All paths would then be required to reference files in the current folder.

I was going to suggest using local references to the files anyway. I often rename folders and when I do I usually have to re-generate the d2v files because they no longer work.

[stax76]

I would prefer a commandline always over config file, full windows shell support requires commandline anyway

[Guest]

See, Dolemite, I have too little time to spend it rewriting the parsing code for such a minor issue. The only viable option would be to replace the comma with something else. Maybe the + sign?

[Moitah]

Originally posted by neuron2
Maybe the + sign? I believe that is allowed in filenames. How about a question mark ("?")?

[Cyberia]

It's not hard to rename files...

[stax76]

I would love to do some cli research and rewrite it but unfortunately like stated already I'm not that far with my C++ tutorials. I totally skipped any DOS tutorials (does pipe mean Or in DOS?) so I'm also not the best candidate to suggest a better delimiter:(

[Guest]

? is a shell wildcard.

Does anybody ever see + signs in filenames?

EDIT: Umm, "Visual C++". :scared:

[Cyberia]

doesn't + mean concatenate?

[Guest]

No.

[Guest]

Here's a release candidate for Version 1.2.0.

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

It adds these new changes compared to 1.2.0beta1:

* Changed marking to be like VirtualDub. You can always set
a new start or end point.

* Added a test for MPEG1 files. Pop up a warning box and
prevent decoding when an MPEG1 file is loaded.

* Added a new field operation mode: 3 = Raw Encoded Frames.
This mode suppresses pulldown and delivers the raw encoded frames.
It differs from Force Film in that no frames are added or
deleted (to maintain film rate) and the frame rate is
left at its coded value. The RFF flags are also stripped
away in the D2V file.

[Cyberia]

* Added a new field operation mode: 3 = Raw Encoded Frames.

How is this different from field operation (NONE)?

[vispgraedde]

I believe that's a feature for hybrid streams, so that you can get both progressive and interlaced frames from the same d2v. Kinda like a mixed forcefilm/none mode?

[vispgraedde]

I tried this new feature with a hybrid encode I have...
And parsed the d2v with parsed2v...

But... How do I now convert the results to frameranges where the output frames are progressive and interlaced respectively?

Especially with output like the following throughout the whole logfile.

[GOP START]
192: 192,192 -- 0 [vob/cell=0/0] [3:2 pattern break]
193: 193,193 -- 2 [vob/cell=0/0] [3:2 pattern break] [ILLEGAL TRANSITION!]
194: 194,194 -- 2 [vob/cell=0/0] [3:2 pattern break]
195: 195,195 -- 0 [vob/cell=0/0] [3:2 pattern break] [ILLEGAL TRANSITION!]
196: 196,196 -- 0 [vob/cell=0/0] [3:2 pattern break]
197: 197,197 -- 2 [vob/cell=0/0] [3:2 pattern break] [ILLEGAL TRANSITION!]
198: 198,198 -- 2 [vob/cell=0/0] [3:2 pattern break]
199: 199,199 -- 0 [vob/cell=0/0] [3:2 pattern break] [ILLEGAL TRANSITION!]
200: 200,200 -- 0 [vob/cell=0/0] [3:2 pattern break]
201: 201,201 -- 0 [vob/cell=0/0] [3:2 pattern break]
202: 202,202 -- 0 [vob/cell=0/0] [3:2 pattern break]
203: 203,203 -- 0 [vob/cell=0/0] [3:2 pattern break]
[GOP START]
204: 204,204 -- 0 [vob/cell=0/0] [3:2 pattern break]
205: 205,205 -- 0 [vob/cell=0/0] [3:2 pattern break]
206: 206,206 -- 0 [vob/cell=0/0] [3:2 pattern break]
207: 207,207 -- 0 [vob/cell=0/0] [3:2 pattern break]
208: 208,208 -- 0 [vob/cell=0/0] [3:2 pattern break]
209: 209,209 -- 0 [vob/cell=0/0] [3:2 pattern break]
210: 210,210 -- 0 [vob/cell=0/0] [3:2 pattern break]
211: 211,211 -- 0 [vob/cell=0/0] [3:2 pattern break]
212: 212,212 -- 0 [vob/cell=0/0] [3:2 pattern break]
213: 213,213 -- 0 [vob/cell=0/0] [3:2 pattern break]
214: 214,214 -- 0 [vob/cell=0/0] [3:2 pattern break]
215: 215,215 -- 0 [vob/cell=0/0] [3:2 pattern break]
[GOP START]
216: 216,216 -- 2 [vob/cell=0/0] [3:2 pattern break] [ILLEGAL TRANSITION!]
217: 217,217 -- 0 [vob/cell=0/0] [3:2 pattern break] [ILLEGAL TRANSITION!]
218: 218,218 -- 2 [vob/cell=0/0] [3:2 pattern break] [ILLEGAL TRANSITION!]
219: 219,219 -- 0 [vob/cell=0/0] [3:2 pattern break] [ILLEGAL TRANSITION!]
220: 220,220 -- 2 [vob/cell=0/0] [3:2 pattern break] [ILLEGAL TRANSITION!]
221: 221,221 -- 0 [vob/cell=0/0] [3:2 pattern break] [ILLEGAL TRANSITION!]
222: 222,222 -- 2 [vob/cell=0/0] [3:2 pattern break] [ILLEGAL TRANSITION!]
223: 223,223 -- 0 [vob/cell=0/0] [3:2 pattern break] [ILLEGAL TRANSITION!]
224: 224,224 -- 2 [vob/cell=0/0] [3:2 pattern break] [ILLEGAL TRANSITION!]
225: 225,225 -- 0 [vob/cell=0/0] [3:2 pattern break] [ILLEGAL TRANSITION!]
226: 226,226 -- 2 [vob/cell=0/0] [3:2 pattern break] [ILLEGAL TRANSITION!]
227: 227,227 -- 0 [vob/cell=0/0] [3:2 pattern break] [ILLEGAL TRANSITION!]

[Guest]

Originally posted by Cyberia
How is this different from field operation (NONE)? Didn't you read the changes text file?

[Guest]

Originally posted by vispgraedde
But... How do I now convert the results to frameranges where the output frames are progressive and interlaced respectively?

Especially with output like the following throughout the whole logfile.

[GOP START]
192: 192,192 -- 0 [vob/cell=0/0] [3:2 pattern break]
193: 193,193 -- 2 [vob/cell=0/0] [3:2 pattern break] [ILLEGAL TRANSITION!] Choke. :scared:

You see, uh, this is why we have betas, isn't it?

I shouldn't strip the RFFs from the D2V, but rather just have them be ignored.

Thanks friend, I'll fix that. But right now...it's time for Sopranos!

[vispgraedde]

Originally posted by neuron2
Choke. :scared:

:D


You see, uh, this is why we have betas, isn't it?

I shouldn't strip the RFFs from the D2V, but rather just have them be ignored.

Thanks friend, I'll fix that. But right now...it's time for Sopranos!

I figured I should test and report on this feature since I am one of the (few?) people that would find this feature interesting :p

This brings up a little feature addition for ParseD2V... how about an option to it that can output avisynth style ranges so you can see more easily what sequence is supposed to be 24 and what are 30?

[Monamona]

Thank you for the great job Donald!

Well, When I load more than one VOB files at one time, the audio
loses sync after the second VOB. The reason seems to be that, when
DVD2AVI loads VOBs, it calculates audio delay for the first VOB and
applies to each other VOB.

Say, audio of the first VOB has -66ms delay, DVD2AVI loads the
audio of the second VOB with additional -66ms delay, which is not
necessary. For the third VOB, the delay becomes -132ms.

But this audio asynchronization is not big, so it might be hard to
realize.
It happens when I make project file(d2v) and demux mpa(mp2) and AC3
from VOB. But I believe it also happens when I choose the option to
decode to wav. To merge VOBs by some other soft before processing on
DVD2AVI does not solve this problem.

Could you also fix this, Donald?
I am sory fot the bad explanation.

Regards

[Trahald]

Originally posted by vispgraedde
:D

I figured I should test and report on this feature since I am one of the (few?) people that would find this feature interesting :p



Include me in. RB pointed this thread out to me (thanks). Great work dg

I'll play (lack of a better term) with raw mode when i get some time.

[Guest]

>I'll play (lack of a better term) with raw mode when i get some time.

Wait for my next release tonight before you start playing with it. Raw mode has two bugs that need fixing.

[Guest]

Here is RC2: http://neuron2.net/fixd2v/decodefix120RC2.zip

The changes from RC1 are:

11. Added a new field operation mode: 3 = Raw Encoded Frames.
This mode suppresses pulldown and delivers the raw encoded frames.
It differs from Force Film in that no frames are added or
deleted (to maintain film rate) and the frame rate is
left at its coded value. The RFF flags are left intact in
the D2V file but they are ignored during decoding.

12. If the picture size is greater than 1024x768, the display
window is zoomed out by a factor of two (preparing for HDTV
and transport stream support).

13. The Save AVI menu option was deleted.

14. The Local Language menu option was deleted.

15. The Color Space menu option was deleted. Without Save AVI,
it served no purpose. The corresponding -CS command line option
was also removed.

16. The Display and Information menu "options" were removed as
they appeared to serve no useful purpose.

[Cyberia]

What exactly does the 'Process WAV' command do?

[Guest]

Originally posted by Cyberia
What exactly does the 'Process WAV' command do? From jackei's web page:

"This function performs 48->44.1KHz, Normalization, and Delay Compensation at once for multiple WAVs.

Before processing WAV, you must decide the details of 48->44.1KHz and Normalization at first."

(You will be prompted for the delay compensation value.)

EDIT: Cyb, what is your personal next most-wanted enhancement?

[vispgraedde]

No illegal transitions out of ParseD2V this time ;)

So now I look at the output and try to understand how to read it to create the ranges that I am interested in.

At first I thought f: a,b -- q [blabla] meant that it was interlaced if a=b, but then I saw [3:2 pattern break]'s


0: 0,0 -- 2 [vob/cell=0/0]
1: 1,1 -- 2 [vob/cell=0/0] [3:2 pattern break]
2: 2,2 -- 2 [vob/cell=0/0] [3:2 pattern break]
3: 3,3 -- 2 [vob/cell=0/0] [3:2 pattern break]


so I guess I was wrong...

I did not see anything in the included docs about how to interpret the output for the purpose of figuring out what framerange is progressive and which are interlaced, based on the output from ParseD2V (or maybe the d2v directly).
Since the thing I am working on currently have a ****load of transitions between progressive and interlace, I was going to write a program or script to help me, but for that I would need to know exactly how to interpret the data.

Can anyone point me to the "missing" documentation?

[Cyberia]

Oh I don't know. Most of them don't seem too hard. Audio might be nice.

I do have a question though. Would people mind removing the Downsampling/DRC/Normalization completely?

Enhancement 4 refers to replacing this code with the BeSweet equivalent, but why not just use BeSweet itself. I'd say offer ONLY demuxing options.

BTW: now that the SaveAVI is gone, we really need a new name!

[Guest]

Originally posted by Cyberia
BTW: now that the SaveAVI is gone, we really need a new name! Yeah, I've been thinking about it. Here's my proposal.

Using "TMPGEnc" as a template, I will have the entire package named as DGMPGDec. I don't put a 2 in there because it will support MPEG1 eventually. DGMPEGDec will consist of several components:

DGParse.exe (was DVD2AVIdg)
DGDecode.dll (was MPEG2DEC3dg)
DGVFAPI.vfp (was VFAPIdg)

ParseD2V and FixD2V will be integrated into
DGParse and invokable through the menus.

I'm thinking of dropping legacy 1.76 D2V support. Who needs it and why? Then the index file format may change dramatically.

[Guest]

Originally posted by vispgraedde
I did not see anything in the included docs about how to interpret the output for the purpose of figuring out what framerange is progressive and which are interlaced, based on the output from ParseD2V (or maybe the d2v directly).
Since the thing I am working on currently have a ****load of transitions between progressive and interlace, I was going to write a program or script to help me, but for that I would need to know exactly how to interpret the data.

Can anyone point me to the "missing" documentation? Let's define some terms first as you are not clear on your requirements: A frame can be "really" interlaced or progressive. Then it can be MPEG encoded as interlaced or progressive. It makes sense to have the two match but they don't always match due to bad encoding. Also you can have hard telecining such that there are interlaced frames but they can be field matched back to progressive.

Then there are sequences of frames that use pulldown and those that do not. We might call them film and video but that would not be strictly correct because you can have non-film patterns of pulldown (RFFs can be arbitrarily set as long as the display fields continue to alternate top and bottom).

I won't try to guess what you are after but please post again and explain given this explanatory framework.

I can say that the best we can do is to extract from the stream the relevant flags and make them available in the D2V. Those flags are the progressive/interlaced flag and the TFF/RFF. The TFF/RFF is currently there. We could add the progressive/interlaced flag. But remember it is not always reliable.

My primary goal with this feature was to assist analysis of video by enabling inspection of the actual encoded pictures. It may be that we can use it for your purposes as well.

[Cyberia]

Hey I was thinking about the drag-n-drop ordering issue, and realized this: They are almost certainly chronologically ordered already. The ripping programs creates them sequentially, so you really don't need to parse the filename, just check the timestamp. It's a hack but it will work 95%+.

Another alternative would be to put a "Move Up" and "Move Down" button on the open dialog, to manually reorder the files.

[Trahald]

Thanx for the updated release.

What I'm looking at doing is trying to recreate hybrid material exactly as the origional. this will require a special pulldown but should be doable.

obviously it may not be the best thing to do in some situations (where there is lots of encoded telecine) but for automations sake and to not sacrifice the pure video around the hard telecine, it would make life easier.

[vispgraedde]

Ok. Here is the thing I'm working with.

The source contains both 24fps FILM with pulldown flags, as well as 24->30fps "hard telecined" Video, possibly some "clean" 30fps parts as well, but it's an old movie so I doubt it.

What I want is to get the FILM frames clean w/o the pulldown, and the rest as they are encoded so that I can do manual ivtc on only them. Not having to bother ivtcing the FILM parts.

Knowing what output frameranges are FILM and which are encoded as Video would make this possible (I think).

I'm here assuming that the flags are correctly set throughout.

My reason for not just using decomb is that I can't find any single setting that work good throughout, and using overrides is (for me) supoptimal since I then have to go through the whole source and look at all frames to figure out where I need overrides. And if I have to look at all frames, I might as well do this in a manner that I find easier (using TMPGEnc).

I hope that explains better what it is I ask for.

[Guest]

Originally posted by vispgraedde
I hope that explains better what it is I ask for. Perfectly. And that makes things easy. All you have to do is look for the pattern break indication. A film sequence is a sequence of frames without the pattern break indication. E.g.:

0
1
2
3
4 [break]
5 [break]
6 [break]
7
8
9
10

Here, 0-3 and 7-10 are film and 4-6 are non-film (using your definition). In practice you might like to enforce something like this: a sequence of more than 5 frames without any breaks is film.

Be careful to properly distinguish encoded frame numbers from display frame numbers.

(For hard telecining, you can use Telecide's debug output log to see which frames are considered "in-pattern".)

ADDENDUM: A film sequence will have the flag bytes repeating this pattern 0 1 2 3 0 1 2 3 ... When you see [3:2 pattern break] it just means that the frame doesn't follow this pattern compared to the previous frame. So if you have 1 and then a 3 it's a break because it should have been a 2.

[vispgraedde]

Thanks. That makes things a little easier for me :)
Keep up the good work.

[Moitah]

I have a video where seeking is terribly broken (in 1.2.0RC2 and 1.1.0). It was captured with a DVB card. Let me know if you need me to upload it somewhere. Here's a screenshot:

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

Again, this is only when seeking, regular playback works fine.

EDIT: I get the "Opening GOP is not closed" warning, but seeking anywhere throughout the video doesn't work properly.

[SILICON]

I ignore if are one stupid request.

I see that the memory bandwid cut down speed in avisynth.
If you can pass the crop values to DVD2AVI, the MPEG2DEC3 decode less data and send less data to avisynth.

Less data more speed, isn't it?

Request:
If above not are stupid, pass the crop values in command line.

[Guest]

Originally posted by Moitah
Let me know if you need me to upload it somewhere.Yes, please upload it and notify me where I can get it.

Do it quick so I can look at it this evening. Thanks.

[Trahald]

is it possible for more information to be included. can field dominance be derived from the d2v? the 3:2 break is reported during pure video when its not a suprise that would be the case.

[Guest]

@trahald

ParseD2V tells you the dominance. If the first flags digit of the clip is 2 or 3 or 12 or 13 (TFF set) it is top field first, else it is bottom field first.

I didn't get your second point. It's true but so what?

@Moitah

I love you, man. That clip is exposing hidden little nooks and crannies of the code and will finally expose the reason for the strange LBA-1 address kludge. I'm getting close but it is very complicated.

[Trahald]

Originally posted by neuron2
@trahald

ParseD2V tells you the dominance. If the first flags digit of the clip is 2 or 3 or 12 or 13 (TFF set) it is top field first, else it is bottom field first.

I didn't get your second point. It's true but so what?



I was at work and didnt finish my thought. I guess I was just saying instead of that message something else can go there. Maybe the field dominance or something. At least that what I was thinking. However since you provided how to determine dominance that doesnt seem to be necessary. ...beyond that it is harmless and is just fine. :)

And thank you for the info.

[Cyberia]

@neuron2 - Actually, the VOB slicing enhancement might be a good one to get, because, really it's a debugging option for you.

[Guest]

Here is a "fix" for Moitah's issue. Well, it works with his clip anyway. :)

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

Now, permit me to make a few remarks.

This clip of Moitah has exposed an ugly underbelly of DVD2AVI/MPEG2DEC3. Notice I omitted the "dg" part because this underbelly is in the basic stream parsing code, which I have not touched. I have touched only the MPEG2 elementary stream decoding. It is now clear that the layered stream parsing is a giant kludge and not provably correct. It may work for most streams but as Moitah showed, a given clip with slightly unusual pack allocations can cause difficulties. ES can be arbitrarily packed in PES but the code does not allow for this, instead making some assumptions that are usually true for DVDs. But throw an arbitrary program stream at it and...good luck!

So I have added yet another kludge on top of the existing kludges to address Moitah's issue. That is what DVD2AVI is! But it cannot go on. It's time for a major departure. Therefore, I will start a totally new development, with the goal of having provably correct decoding at every layer: elementary, PES, program, transport, etc. Furthermore, DVD2AVI did not begin from the ground up with a view to random navigation (and especially via Avisynth). That should be a starting premise of the new development.

So, I will start a new thread for this development. Does it belong in this forum? Please advise.

[fccHandler]

Originally posted by neuron2
But it cannot go on.
Sorry to hear about the ugly underbelly. I've been silently waiting in the wings for a long time for DVD2AVIdg's development to stabilize, because I wanted to try the code in VirtualDub-MPEG2. My idea was to replace the parser with a built-in DVD2AVI (minus its decoder), so the "parsing" stage would build something like a D2V in memory. (Actually it does something very similar already.) Then I could replace the decoder with Mpeg2Dec code, only changing the interface to be compatible with VirtualDub's classes.

Right now the MPEG parser is a mess of spaghetti, but all it really lacks in functionality is rff/tff support. I've tried many times to implement that without much luck. One time I thought I almost had it working, then somehow it fell apart again.

You seem to have a lot of time on your hands right now (more than me, anyway), and I think you are the only MPEG-2 developer I know who could save this code, if you're interested.

Thoughts?

[Cyberia]

Are you just going to rip out the parsing mess and replace it with better code? Or start entirely over from the ground up? If the latter, then that would be a good time to implement the new DGMPGDec/DGParse/etc naming convention and versioning.

[RB]

Originally posted by neuron2
So, I will start a new thread for this development. Does it belong in this forum? Please advise.
Yes, I think it's best kept here. And good luck, I think a complete rewrite was long overdue, thanks for taking the challenge! Are you going to rewrite it in a more object oriented way?

[vispgraedde]

Good luck with the rewrite as it seems to be needed...

And I just found some bug with RC2 that is there with RC3 as well...

When I open the d2v in tmpg (making sure that it use the correct vfp version just in case), I often have to click on options like inverse telecine and source range twice before I get the video...
And when I was about to encode, I got some error messages:

Read error occured at address 00F2B7D3 of module 'mpeg2dec3dg.dll' with 04B2E000. (RC2 Raw Frames)
Read error occured at address 00FB3E42 of module 'mpeg2dec3dg.dll' with 049DE0E8. (RC3 Raw Frames)
Read error occured at address 00FB3E42 of module 'mpeg2dec3dg.dll' with 05715D00. (RC3 None)

[Guest]

Actually, on further analysis it appears that the parsing layer is fine. The problem is purely with random navigation. I'll start a new thread on this and my plans. This thread will continue with version 1.2.0 development.

Here's one case where random access fails for program streams: You want frame 17 and the D2V file gives you the LBA that contains the I frame for the GOP that frame 17 is in. The LBA indexes are based off the location of the I frame so that means that the packet header could be in the previous LBA. If we miss the packet header we can't pick up the I frame and we parse forward to the next packet which gives us the wrong frame.

This is what I meant when I said that the design was not made from the ground up for random frame access. When you lay a higher layer over the elementary stream indexing, you have to change to indexing at the higher layer, in other words the packets should be indexed and not the I frames.

Whether the existing code can be rescued for fully reliable random access remains to be seen.

[Guest]

Originally posted by vispgraedde
When I open the d2v in tmpg (making sure that it use the correct vfp version just in case), I often have to click on options like inverse telecine and source range twice before I get the video...
And when I was about to encode, I got some error messages:
You are making a 1.76 style D2V and then using VFAPIdg to serve to TMPGEnc. Is that correct?

[vispgraedde]

This is using dg style d2v's in all cases. Not 1.76. And using VFAPIdg (DVD2AVIdg.vfp) for the frameserving.

Edit:
I also remade the d2v's with RC3 just in case.
If it matters, the original m2v is >4GB on NTFS partition in WinXP.

[Guest]

What happens if you serve it into VirtualDub?

[vispgraedde]

In vdub, I get the same artifacts as I can see in tmpg for the first two frames, the first time they are shown.
All around the video there is supposed to be a black border.
Instead of the black border for the first two frames, I have a green border that seems to consist of 16x16 pixel blocks, and in some places in the border, it's only 8x8 pixel blocks of green.
This is only for the first two frames that I step through.
The video does not load every time either. Sometimes I only get black through the whole thing, but video is back after I reload the pseudoavi.

[vispgraedde]

The beginning of the d2v itself:

DVD2AVIProjectFile1
1
82 E:\DYRL\VTS_01_1 - 0xE0 - Video - MPEG-2 - 720x480 (NTSC) - 16~9 - Letterboxed.M2V

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,2DD1E0

7 0 0 0 0 12 12 12 12 12 12 12 12 12 12 13 10
7 0 D6 0 0 1 2 13 10 11 12 13 10 11 12 13 10
7 0 1E7 0 0 1 2 13 10 11 12 13 10 11 12 13 10



--
The mpeg2 is hybrid encoded (part film, part ntsc).

[vispgraedde]

To eliminate VFAPI as the problem, I just tried through avisynth as well, with the same artifacts. Green border for the first two frames but this time, the green border is always present for those frames instead of disappearing after stepping back.

[Guest]

I need your clip that fails. Try to cut it to a decent size and post a link where I can download it. Thank you.

EDIT: Forgot to ask... This clip does play in Media Player, for example, i.e., it's a known good stream?

[Guest]

Here is RC4 which fixes the issue with postprocessing settings not being individually settable for multiple instances of MPEG2DEC3 in a script, and fixes a stupid memory overwrite that may be the reason for vispgraedde's problem. Do not use RC3!

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

[vispgraedde]

RC4 fixed the green border problem, but not the other problem I experience.

And now when I open the d2v in tmpg, or sometimes when I try to encode, I get error messages like:

Write error occured at address 00FAB5E7 of module 'mpeg2dec3dg.dll' with 0200E080. (emphasis mine)

I will pm the URL to where I stored a small clip for which I experience this problem.

I have used this stream through avisynth without any visible problems before.

[Guest]

What do you mean by opening D2Vs in TMPGEnc? I thought you were using VFAPI?

If you want to read a D2V with existing apps, you need to use 1.76 style.

[Cyberia]

Basic file stuff:

Please prompt if the new project will erase an existing one.

Please popup a reason why a file save would fail. (eg: try to save a project that will overwrite an existing READ-ONLY file.)

FYI: I am leaving tonight for a ten day vacation in Maui. I will try to read the forum, I will have a laptop, but I will certainly not be at full strength for the duration. I will drink a mai-tai for each of you, and two for Don. Aloha.

[Guest]

Originally posted by Cyberia
Please prompt if the new project will erase an existing one.

Please popup a reason why a file save would fail. (eg: try to save a project that will overwrite an existing READ-ONLY file.) Done! Thanks for the suggestions.

FYI: I am leaving tonight for a ten day vacation in Maui. I will try to read the forum, I will have a laptop, but I will certainly not be at full strength for the duration. I will drink a mai-tai for each of you, and two for Don. Aloha. Thanks and have a great time!

[vispgraedde]

Originally posted by neuron2
What do you mean by opening D2Vs in TMPGEnc? I thought you were using VFAPI?

If you want to read a D2V with existing apps, you need to use 1.76 style.

I thought the whole point of VFAPI was that the apps does not need to have a native d2v parser if it goes through the vfp that dvd2avi registers.
And therefore you don't need to keep track of what file version you use, as long as the vfapi plugin matches the file you want to read.

[Guest]

Originally posted by vispgraedde
I thought the whole point of VFAPI was that the apps does not need to have a native d2v parser if it goes through the vfp that dvd2avi registers.
Yeah, I knew that. :p

So, I found and fixed the problem and PMed you a link to the fixed DLL. When you give the thumbs up I'll make the next release. I'm sensing 1.2.0 is nearing release.

[vispgraedde]

While you are at it, can you change the version string that is reported through vfapi as well? (For the 1.20 release)
The one that shows up in Options->Environmental setting->VFAPI plug-in list in tmpg.

[Guest]

Change it to what?

EDIT: I changed it to "DVD2AVIdg 1.2.0 D2V Reader".

[vispgraedde]

Edit:
nm, I see you edited your post :p

[zettai]

Hey neuron2,

I don't mean to be a pest but I was wondering if you are going to work on the Progressive/Interlaced hints before starting on the new parser. I guess this goes for any of the worklist items - are they to be addressed before trying to write a new parser code?

I'm all for a better parser, of course, but I'd really love theupsampling in avisynth to be easier too :)I'd rather not have to use vfapi for it :P

[Guest]

OK, here is RC5. Five is my lucky number so maybe this one will be the ticket.

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

This one adds the file checking that Cyberia suggested and fixes the VFAPI problem with TMPGEnc that vispgraedde reported.

[zettai]

One thing I just thought of (when thinking of these upsampling issues) is the post processing options of mpeg2dec3.

Surely the option ipp=true/false isn't necessary... can't the post-processing base it on the current frame type?

Just a suggestion - I'm not the only one who uses hybrid footage, honest :P

[RB]

Donald, did you implement anything in terms of Mpeg2Dec3dg internal upsampling to YUY2 depending on progressive_frame flag?

[Guest]

@zettai

Yes.

@RB

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.

[jimmy basushi]

wow neuron2, you have pushed out so many new versions of dvd2avi lately i just wanted to thank you for spending your time working on such a necessary dvd tool.

[Guest]

Thanks. But you ain't seen nothing yet. :cool:

[JohnMK]

Donald Graft rocks my world. :thanks:

[Cyberia]

Aloha from Maui! I just wanted to thank Don for the hard work.

Thanks. Time for a mai-tai.
Cyb

[Cyberia]

OK, I have no vobs here at all, so I tried to open a Word doc with RC5. Well, bad things happened when I saved the project.

You may want to fail more gracefully if its at all posible. This could wait for 1.3 however.

[Guest]

Originally posted by Cyberia
This could wait for 1.3 however. Oh, thanks, Cyb. That's very considerate of you.

I've just totally rewriitten the indexing support. This LBA-1 crap just doesn't cut it, ya know. Drink a mai tai or two in my honor, dude. Then you won't care if you can't decode a Word doc.

Tomorrow I'm going to rewrite all the trackbar navigation stuff. It sucks.

[DDogg]

Donald, perhaps not appropriate for this thread. Delete/move if needed to keep order.

I'm a little confused / more than normal.
Source "GoodFences", Showtime made for TV movie on DVD. RC5 Shows BFF and from the D2V below seems 100% USDA interlaced.

So, I thought I would check the BFF just to be sure and used the 'AssumeTFF().SeparateFields()trick in VDub. It showed TFF motion. Seems like I remember you saying not to depend upon D2V correctly identifying field precedence but I thought I would mention it since you are down in the guts of the beast now.

Dvd2avi shows this as an 100 interlaced source, yet it shows the 3 good, 2 combed pattern when viewed in VDub. Is this as you would expect from the pattern below? The rest of the file is just like the snip shown.


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

7 0 1 1 1 10 10 10 10 10 10 10 10 10 10 10 10 10
7 0 27 1 1 12 12 12 12 12 12 12 12 12 12 12 12 12
7 0 ED 1 1 12 12 12 12 12 12 12 12 12 12 12 12 12
7 0 1AE 1 1 12 12 12 12 12 12 12 12 12 12 12 12 12
7 0 278 1 1 12 12 12 12 12 12 12 12 12 12 12 12 12
7 0 35B 1 1 12 12 12 12 12 12 12 12 12 12 12 12 12
7 0 422 1 1 12 12 12 12 12 12 12 12 12 12 12 12 12
7 0 4D0 1 1 12 12 12 12 12 12 12 12 12 12 12 12 12
7 0 58E 1 1 12 12 12 12 12 12 12 12 12 12 12 12 12
7 0 65B 1 1 12 12 12 12 12 12 12 12 12 12 12 12 12
7 0 71C 1 1 12 12 12 12 12 12 12 12 12 12 12 12 12
7 0 7DD 1 1 12 12 12 12 12 12 12 12 12 12 12 12 12
7 0 8A4 1 1 12 12 12 12 12 12 12 12 12 12 12 12 12
7 0 968 1 1 12 12 12 12 12 12 12 12 12 12 12 12 12
<snip>
7 6 17E4B 2 7 12 12 12 12 12 12 12 12 12 12 12 12 12
7 6 17F0C 2 7 12 12 12 12 12 12 12 12 12 12 12 12 12
7 6 17FD6 2 7 12 12 12 12 12 12 12 12 12 12 12 12 12
7 6 18097 2 7 12 12 12 12 12 12 12 12 12 12 12 12 12
7 6 18161 2 7 12 12 12 12 12 12
7 6 181C2 2 8 10 10 10 10 10 10 10 10 10 10 10 10 10 9

FINISHED 0.00% FILM

[Cyberia]

Oh, thanks, Cyb. That's very considerate of you.

Not sure if I detect sarcasm there or not. Part of my job (tech support) is to imagine how morons could break things. I realize you shouldn't open a Word doc with DVD2AVI, but... the same could happen with a corrupted d2v file.

I so piss off the developers at work by thinking of things you shouldn't do anyway, but the program should never ever GPF...

Another mai-tai...check!

ps: I am so clever... I rented Kill Bill and downloaded Smartripper, so I have a VOB now!

[len0x]

I seem to have missed all the new development of DVD2AVI recently, but having looked through the change log I haven't found that one old bug is fixed: basically it seems that on old dual (say P2-P3) systems when started from CLI DVD2AVIdg 1.0.0 crashes (only from CLI). Any ideas ?

Thanks.

[zettai]

Have you tried setting the processor tag in CLI?

[len0x]

Originally posted by zettai
Have you tried setting the processor tag in CLI?

IDCT you mean ? It's always set to SSE MMX... Probably there are still some threads which are not launched the same way from GUI and CLI...

[Guest]

Originally posted by DDogg
I'm a little confused / more than normal.
Source "GoodFences", Showtime made for TV movie on DVD. RC5 Shows BFF and from the D2V below seems 100% USDA interlaced.

So, I thought I would check the BFF just to be sure and used the 'AssumeTFF().SeparateFields()trick in VDub. It showed TFF motion. 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. Try running Fixd2v on it and things should become coherent again.

You can't change the field order like that. The display device has to receive a strictly alternate sequence of top followed by bottom fields. 2 followed by 0 specifies: show a top field of A, show a bottom field of A, show a bottom field of B, show a top field of B. That's not an appropriate thing to be doing. The poor widdle display will get seriously disturbed.

Dvd2avi shows this as an 100 interlaced source, yet it shows the 3 good, 2 combed pattern when viewed in VDub. Is this as you would expect from the pattern below? The rest of the file is just like the snip shown. Then it's what we call hard telecining. The pulldown is applied prior to MPEG encoding and RFF flags are not used.

[Guest]

Originally posted by Cyberia
the program should never ever GPF... Right on. I have to agree with that.

[Guest]

Originally posted by len0x
I seem to have missed all the new development of DVD2AVI recently, but having looked through the change log I haven't found that one old bug is fixed: basically it seems that on old dual (say P2-P3) systems when started from CLI DVD2AVIdg 1.0.0 crashes (only from CLI). Any ideas ? Do you have the setup to duplicate this? If so, I can work with you by sending you debug loads.

[len0x]

Originally posted by neuron2
Do you have the setup to duplicate this? If so, I can work with you by sending you debug loads.

I don't, but lemme search the forum - may be ppl who had this problem are still around.

[vispgraedde]

I was bored and kinda grew horns here :devil: so I decided to see how dvd2avi handles a multiangle clip.

I produced 5 clips of 96 progressive frames, with pulldown flags, and produced a multiangle vob in Maestro from that.

My first find maybe isn't a bug per se, because I don't know too much about how multiangle work, but instead of getting 100% FILM, I only get 98.33% FILM (in this example).

Further, when I use forcefilm and go through avisynth, I get the correct 480 frames from this clip, but if I use none, I get 596 frames instead of the expected 600 frames. Maybe it's not a bug, but still :p (Encoding the clips with hard pulldown and using none produce the expected 600 frames)

Selecting what angle(s) you want in the output from the input, I have some ideas for that I haven't had time to think through fully yet, so I leave any talk about that alone for now...

I can provide said clip if you want it for testing :devil: ;)

[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.