does dvd2avi chop off frames?

[D3s7]

I'll vouch that it does work however if you encounter any Open GOP's at the start you'll have to click the "OK" message box for DVD2AVI.

I've ripped/encoded with it however haven't authored any back yet so I can't tell you if there's any problems there..... Tonight I will :D

[Eyes`Only]

Originally posted by len0x
You should be fine as long as you have Output Method set to Demux by default in DVD2AVI.ini file (coz this is new option in 1.77.3 and hence is not implemented in the tools using 1.76 CLI)

For regular ISO demux in DoItFast4U!, audio is not demuxed using dvd2avi, so it shouldn't be an issue. ;)

[len0x]

Originally posted by D3s7
however if you encounter any Open GOP's at the start you'll have to click the "OK" message box for DVD2AVI.


@Neuron2: I forgot about this feature. Will it be possible to disable message box via command line? Or it makes no sense to proceed as there will other problems on the way? (I'm talking from fully automated tools point of view...)

[D3s7]

AHEM :)

Originally posted by D3s7
I'd like to put in a request for next beta..

would it be possible that if run from CLI (command line) that the GOP closed warning not pop up.....

running on 60+ VOBID's and having to sit here to click that "OK" on 20+ kinda sucks :)

Thanks

- D3s7

[len0x]

Originally posted by Eyes`Only
For regular ISO demux in DoItFast4U!, audio is not demuxed using dvd2avi, so it shouldn't be an issue. ;)

You can see that I'm not really familiar with your tool :)
So my answer should be refined to if you're using audio demux then make sure... :cool:

[Eyes`Only]

Originally posted by neuron2
Sure, I can do that. But why do 20+ of your VOBs have open initial GOPs? When demuxing by vobid with DVD Decrypter, m2vs are basically written starting from the exact frame that they start on.

[DDogg]

Will it be possible to disable message box via command line? len0x, funny, I woke up this morning with the same thing in my mind. The word suppress and/or re-divert (to text file) came into mind as I guess you, dvd2svcd and eyes' only might want a record of this without it completely stopping your automated processes. That would be kinda ugly indeed

[Eyes`Only]

DDogg: Good suggestion. I could live with that. Or if the app returned an error that we could recognize when calling dvd2avidg with a function such as ShellExecuteEx() that would work too. At the very least, we need it suppressed. Error reporting would be an optional plus.

[len0x]

Originally posted by Eyes`Only
DDogg: Good suggestion. I could live with that. Or if the app returned an error that we could recognize when calling dvd2avidg with a function such as ShellExecuteEx() that would work too. At the very least, we need it suppressed. Error reporting would be an optional plus.

Yep, suppressing is good. Error reporting is not really neccessary for me, but if it is there it would be nice not to depend on how the process is called (I, for instance, use CreateProcess())

[Guest]

The beta I will release tonight will fix force film and suppress the GOP warning when running from the command line.

This weekend I will make a decision about CruNcher's issue (I'm not convinced about it yet), and also address Zeul's request. I'd like to get a first non-beta release out ASAP.

[DDogg]

...will fix force film A lot of potential in those few words. Do you mean you have reworked the FF process to deal with hybrid source, or that you fixed some issue in the existing implementation of FF?

[Guest]

The latter; it's the fix for Jeffster's green frame. Functional improvements will come later.

[Zeul]

thanks for considering my request. If a chapter list is to be created, there would need to be someway of differentiating between different vob id's. possibly something along the lines of:

vobid/cellid: total frames in cell

thanks again for this request

zeul

[Guest]

Beta 19 is available and includes these fixes:

1. Force Film mode is now correct for skipping and repeating frames (fix for Jeffster's green frame).

2. In some circumstances bad starting frame(s) due to an open GOP was not replaced with the first decodable frame and macroblocks were shown; this is repaired.

3. There is now no GOP warning popup from the command line when -OF is included (automatic mode).

4. If the -OF file cannot be opened for writing, it will now not crash.

5. If -OF is specified but no input file is specified it will no longer hang.

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

[Guest]

Originally posted by Jeffster
I can see the 3131 where you said, but wouldn't want to wade through a D2V for the complete movie to find it. Nor would I, although ParseD2V would help. I went backwards of course. I debugged the code to inspect the FrameList table at frame 97. I saw two successive entries asking for frame 96 to be used. That is a frame repeat and a big light bulb went off in my head. I theorized about what could call for repeats and came up with the 3131 idea. Then I went to frame 97 in your D2V and...lo!

I'm glad it wasn't a false lead, and may have helped to improve the great work you are doing. Sorry if it means more work for you though. I'm only happy when working, and drinking fine Merlots (not cheap red wine). Your incisive trouble analysis and reporting skills are greatly appreciated.

[JuanC]

Originally posted by neuron2
...I'm only happy when working, and drinking fine Merlots (not cheap red wine). Your incisive trouble analysis and reporting skills are greatly appreciated.
But the cheap-red-wine thing was a fun idea ;)

[Zeul]

@ neuron2

can the new dvd2vaidg be used with avisynth 2.07/8 if the old mpeg2dec3 is used, to remove the frame loss from dvd2avi (i know the loss from mpeg2dec3 will still be there)

zeul

[Guest]

I don't recommend that, because the flags will be misaligned to frames.

[Guest]

After doing some analysis, I concluded that CruNcher is correct. When B frames are delivered before the first I frame in display order, the VideoPTS needs to be moved back by the time length of the B frames. Beta 20 does this. The adjustment is made only when the initial GOP is of the form IBBP..., and is required even for a closed GOP of that form. This adjustment allows for the extra B frames delivered at the beginning of the video; the I frame is not the first frame in display order for such GOPs. GOPs of the form IPBB... are not adjusted.

The GOP warning now pops up when the file is loaded.

Please advise if your AV sync is OK with this beta. That is all I want to do before making a first non-beta release. That doesn't mean that I have forgotten other requests! Since this beta is the release candidate, please beat it to death.

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

[Cyberia]

EDIT: This is all with Beta 20.

Issue #1)
I have a vob that VdubMod 1.5.4.1 says has 5347 frames, but the latest DVD2AVIdg/MPEG2DEC3dg reports as having 6283 frames (which I believe is correct).

EDIT: DVD2AVIdg reports 5349 frames coded and 6283 frames for playback.

Issue #2)
The Sparklies issue has been moved to a new thread... (http://forum.doom9.org/showthread.php?s=&threadid=62794)

[Guest]

Originally posted by exorcism
a) you should report when a new version is up (preferably on your page) and what's new
b) you should keep a log of what you change in each release, so some of us who care don't have to read this thread to try to figure it out :)
just some requests :p Yes, I agree the handling has been a little casual, but I had planned to transition to proper version documentation after the first non-beta is released. I also plan to produce a complete list of changes versus 1.77.3 original when I release the first non-beta version.

[Guest]

Originally posted by Cyberia
I have a vob that VdubMod 1.5.4.1 says has 5347 frames, but the latest DVD2AVIdg/MPEG2DEC3dg reports as having 6283 frames (which I believe is correct).

EDIT: DVD2AVIdg reports 5349 frames coded and 6283 frames for playback. So what is the issue? VDubMod is wrong. The difference between coded and displayed is a result of RFFs.

The Sparklies issue has been moved to a new thread. (http://forum.doom9.org/showthread.php?s=&threadid=62794)

[Guest]

DVD2AVIdg/MPEG2DEC3dg/DVD2AVIdg.vfp Functional Changes
(versus DVD2AVI 1.77.3 [original] and MPEG2DEC3 1.10 [Nic])
----------------------------------------------------------------

1. Frames are no longer lost at the beginning and end of the
delivered video. If the first frames in display order are B frames
they are now delivered, whereas previously they were discarded.
If initial B frames are decodable (closed_gop = true), they are
displayed as decoded; if they are not decodable (closed_gop = false),
they are replaced with copies of the first decodable frame.

This is the most important fix and is the real motivation for this
entire development. The frame loss causes serious problems in some
authoring applications.

2. To compensate for the delivery of the initial B frames when IBBP...
GOPs are decoded (see 1 above), the audio delay is adjusted
appropriately.

3. Random access using MPEG2DEC3dg is now fully correct. Previously,
if you navigated to a frame that corresponded to an initial displayable
B frame in a GOP, you would actually get the first subsequent I frame,
which is typically several frames later.

4. If the first GOP has non-decodable B frames first in display order,
DVD2AVIdg pops up a warning message box to alert the user. This popup
is suppressed when DVD2AVIdg is used in automatic mode from the command
line.

5. Command line support was added to enable other applications to
invoke DVD2AVIdg without user involvement.

6. DVD2AVIdg adds the capability to read either 1.76-style or 1.77.3-style
D2V files. It also adds the capability of saving the project in either
format.

7. Auto increment on file names now works in a more general fashion. The
rule is now that the file name is scanned from the end toward the beginning
until an _ character is found. Then the (possibly multidigit) number
following the _ character is incremented. This allows for proper auto
increment for file names such as:

VTS_02_1 - 0xE0 - Video - MPEG-2 - 720x576 (PAL) - 16~9 - Letterboxed.M2V

8. The command line -IF and -AIF options no longer require full path names.
If the specifier does not include a path, the current directory is used.

9. If the command line -OF file cannot be opened for writing, DVD2AVIdg
does not crash. If a valid -OF file is given without an -IF or -AIF file,
DVD2AVIdg does not hang.

10. A VFAPI plugin is provided that supports these fixes. Note that these
fixes do not fully apply when DVD2AVI's Save AVI and Preview features are used.
That may be corrected in a future version but don't hold your breath
while waiting for it.

[hakko504]

WTG man :D

That is one impressive feature list you've managed to create. I'll change the whole FAQ to reflect these changes ASAP, but I will not post it until you have released your v1.0. It is already hinted in the FAQ that your version has a few useful changes and that anyone with problems should test your version.

[Guest]

I decided to make one more beta to support VFAPI. Please read the VFAPI.txt file in the distribution for instructions. As intended, it invokes the MPEG2DEC3.dll for decoding. I've updated the functional changes list already posted.

I was going to blow off doing VFAPI, but DDogg PM'ed me with a devastatingly persuasive argument against that. Woof!

http://neuron2.net/fixd2v/decodefix.html [Release candidate 1]

[DDogg]

Add another big WTG! :) Vfapi checked and working beautifully in Vegas :)

/Add: Don, would it be possible for vfapi to honor the clip and resize settings? I applied a slight crop so that final size was 704x480 and created the d2v. I then opened the d2v with avisynth and verified the size as 704x480. Then I used vfapi-convert to convert the d2v to pseudo-avi without avisynth being involved. I notice the size was 720x480.

[len0x]

I was playing around with beta 20 and trying to demux AC3 soundtracks from VOBs and observed strange (to me) behaviour (I havn't done any demuxing with previous betas, so I can't say if it's always been like this). Anyway:

First case. Delay in the vob -80ms (or when demuxing with ripper). Delay in the resulting ac3 file from dvd2avidg -56ms. Well I thought that if it added some frames then delay indeed should be less, but 24ms didn't make much sense to me since 1 frame is 40ms (PAL). Another case. Delay in the vob 0ms, but demuxed -48ms. This is really odd to me... Or I don't get something?

P.S. it's really difficult to test which delay is right, since anything less than 50ms is not noticable when playing video...

[Guest]

@len0x

24ms is a typical audio frame delay. It could be that the two applications are using different ways to determine the delay. I am not really interested in comparisons to other apps, as I don't have the time or their source code, which I would need to determine why they differ. If you present me with differences between DVD2AVIdg and DVD2AVI original, then I will be happy to have a look at any discrepancies.

In my DirecTV work, we use special test streams that have a video flash frame simultaneous to an audio pop. We measure with an oscilloscope at the video and audio outputs to assess the sync. It would be interesting to contemplate doing something similar to create an objective method for our work here.

@DDogg

I'll have a look at the VFAPI clipping issue.

[len0x]

Originally posted by neuron2
@len0x
24ms is a typical audio frame delay. It could be that the two applications are using different ways to determine the delay. I am not really interested in comparisons to other apps, as I don't have the time or their source code, which I would need to determine why they differ. If you present me with differences between DVD2AVIdg and DVD2AVI original, then I will be happy to have a look at any discrepancies.


Sorry for not making this clear from the start: 1.77.3 is behaving exactly like all other riping software I used. So what I meant to say is: delay from 1.77.3 is not the same as in beta 20 for instance...

So what I said about delays in my previos post is valid for the case 1.77.3 vs DG version :)

*EDIT* moreover demuxed AC3 files are different in size and in length... (42:15.680 for DG(-48ms) and 42:16.192(0ms) for 1.77.3)

[DDogg]

OK, this may get me a spanking, but I would like to request something they may be out of the scope you intended for this project. As you tie the ribbon on the final package, whenever that is, I wonder if you (or somebody else) would consider doing a installation package that includes all of your parts plus vfapi codec/conversion plus the readavs.dll.

Rational: Many people that use DVD2AVI like video editors don't even know what Avisynth is, or are confused by a script based editing language and the fact is many don't need it. Also, many are artistically oriented rather than technical. However, besides dvd2avi, many do use VDub and TMPG. VFAPI and Readavs.dll are extremely unique in that together they will serve VDub VDR signposts and TMPG TPR files as well as D2V files. The fact that it is done in RGB24 is actually a plus instead of the minus it is for fairuse methods.

Over the last few years I have tried to help some of these folks get the vfapi codec and readavs installed. It is always a major pain in the backside because they have to be hand installed and in the case of readavs, a registry entry must be edited and made.

If all these parts were integrated into one package, the user would not really have to understand that vfapi in dvd2avi is about serving D2V files. Rather they would have one integrated app that would serve clipped/cropped mpeg2 files, whether VOB, MPV, or MPG based, as well as VDub and TMPG signposts. By "integrated", I don't mean any special work. Rather it would seem integrated via the vfapi conversion tool that would convert D2V, VDR, TPR, and AVS if avisynth is installed. Since DVD2AVI can provide a d2v file for VOB, mpv, mpg, etc., it becomes quite powerful, especially if the clipping/cropping functions in dvd2avi are supported via vfapi. <= that last stinker may well get me in trouble :)

[Guest]

@DDogg

You *are* very naughty. I'll leave all that to the integrator guys, like GKnot, DoEverythingForYouWithOneClick, etc. :)

@len0x

I am not surprised to see a difference between DVD2AVI original and DVD2AVIdg for clips with initial GOPs of the form IBBP... The original would flush the stream between the I and P pictures, including any audio frames in that part of the stream. The new version retains the stream, so if there are any audio frames in there they are now included and may affect the calculated delay.

But you are saying you see the DG version deliver a shorter audio file? I'll run some experiments to see if everything is as it should be.

[DDogg]

I'll have a look at the VFAPI clipping issue. Thanks for checking into that.

(Now running away with tail 'tween legs yelping :) )

[Guest]

@len0x

I did a few spot tests and everything looked just fine. But you said this:

*EDIT* moreover demuxed AC3 files are different in size and in length... (42:15.680 for DG(-48ms) and 42:16.192(0ms) for 1.77.3)

That says the DG version LOST over half a second of audio! If that is truly the case, then I urgently need to get that VOB from you, as something very strange is going on. Can you make it available, or at least the first part of it?

BTW, what tool are you using to determine the audio length? I use AC3 Delay Corrector. It shows the number of audio frames, the time, and the delay.

[len0x]

I did more tests and: problem exist only when DVD2AVI started from command line. From within gui the same settings resulted in normal AC3 files (in every single VOB I tried command line execution had diff results from normal one, i.e. loosing half a second of audio). Hope this helps...

*EDIT* I use VDubMod for ac3 info...

[Guest]

OK, phwew, I thought I was losing my mind. :)

I'll try to duplicate using CLI code. One more question, please: Are you demuxing all tracks or just one? If you could give your CLI line it would be helpful.

[len0x]

Originally posted by neuron2
OK, phwew, I thought I was losing my mind. :)


I know :) I was using lots of versions of DVD2AVI and from diff apps, so at first I even forgot how to reproduce it. Then I tried another VOB and it was OK then I tried the first one and it was OK too. And only after that I remembered that I actually used command line as well :)

Originally posted by neuron2

I'll try to duplicate using CLI code. One more question, please: Are you demuxing all tracks or just one? If you could give your CLI line it would be helpful.

Just one track via command like this:
-AIF[first.vob] -IA=2 -FO=0 -CS=2 -YR=1 -TN=1 -OM=1 -DRC=0 -DSD=0 -DSA=0 -OF[output] -Exit

[Guest]

@len0x

Thank you. I've duplicated it too. It should be easy to fix. I'll start looking at it later tonight -- I've got my youth swim team to coach in the early evening.

So we have two issues for the release candidate:

1. Lost audio under CLI.
2. No clipping for VFAPI.

Both should be fixed before release.

BTW, does anyone know why DVD2AVI 1.77.3 has resize and letterbox sliders that are disabled? Is the resizing supposed to work or not? Hakko?

[DDogg]

AFAIK, I think it was just left unfinished. Jackei left the scene shortly after starting on this area of dvd2avi, came back a short time where he did a little more work on it, and then left permanently. Gee, that seems like ancient history, but I think that's how it was.

Yup, website show, "resize function unfinished"

[Guest]

I now understand the audio loss under CLI issue. The solution is a little tricky so it may take a day or two.

[len0x]

Originally posted by neuron2
I now understand the audio loss under CLI issue. The solution is a little tricky so it may take a day or two.

Can I ask what's the issue there ? I'm obviously not familiar with the code, but isn't it suppose to be same code for gui and for cli excution ?

[Guest]

Originally posted by len0x
Can I ask what's the issue there ? I'm obviously not familiar with the code, but isn't it suppose to be same code for gui and for cli excution ? Yes, but it wasn't, and I expect that the DVD2SVCD version has the same problem (if not, it must be down to 1.76 versus 1.77.3 differences). When you use the menus, after loading the VOB, DVD2AVI executes a decode thread with LOCATE_INIT and the thread kills itself after decoding the first picture to put in the window. That thread also decodes the sequence header and sets up a lot of variables. Then when you do the save project it executes another decode thread with LOCATE_RIP. But when you do the CLI operation, the LOCATE_INIT decode thread is not executed, and only the LOCATE_RIP decode thread is executed. My changes, which are now working, run both the LOCATE_INIT and LOCATE_RIP threads just as you would when operating through the menus.

I want to look at the VFAPI clipping issue before releasing a new beta.

EDIT: There won't be any clipping supported with VFAPI. MPEG2DEC3 is able to do it because it invokes the Crop() filter via env->Invoke(). But VFAPI uses the MPEG2DEC3 DLL outside of Avisynth. It's not a big deal as you can crop elsewhere.

I will release the CLI fix tonight.

[DDogg]

It's not a big deal as you can crop elsewhere. I was afraid of that due to some previous background, but I was hoping new eyes might see another way. Like you said, cropping can be done elsewhere. At least now I know it can't be done definitively.

[Guest]

I've completed the CLI audio fix. Feedback will be appreciated.

http://neuron2.net/fixd2v/decodefix.html [Release candidate 2]

[Guest]

Darn.

Who'd have thought a space in a version string could cause INI file support to fail. Please get RC3:

http://neuron2.net/fixd2v/decodefix.html [Release candidate 3]

[len0x]

Originally posted by neuron2
I've completed the CLI audio fix. Feedback will be appreciated.


Well audio seems to be the same when doing gui and CLI operation. But in both cases I have delay which is different from 1.77.3. For instance I have -80ms with 1.77.3 (and it's the same when reading ifo file for those vobs) and 0ms with RC3 (actually RC1 behaves the same as RC3 already). Is this a bug or a feature (due to frame inserting stuff)?

[Guest]

@len0x

Is the first GOP of the form IBBP... ?

[len0x]

Originally posted by neuron2
Is the first GOP of the form IBBP... ?

I'm a bit unprepared about this matter. How to find that out?

P.S. I narrowed down which beta introduced that: beta 20 (beta 19 produces perfect result).

*EDIT* Just read that it was fix for CruNcher, just wanted to be sure that it does what it suppose to.

*EDI2* My other concern - if it does produce a valid delay now - does this mean that you cannot demux audio outside DVD2AVI anymore if you plan to use it with new mpeg2dec3.dll ?

[len0x]

just checked that in VDubMod...

[Guest]

Your initial GOP is IBBP, so I am adjusting the audio delay to account for the delivery of the initial B frames in display order. I need you to answer this: How exactly did you obtain the VOB whose first GOP is IBBP?

>My other concern - if it does produce a valid delay now - does
>this mean that you cannot demux audio outside DVD2AVI anymore
>if you plan to use it with new mpeg2dec3.dll?

There will potentially be a sync difference if the first GOP is IBBP. You can adjust for that in one of several possible ways.

Let me think about this. I have an idea.

[len0x]

Originally posted by neuron2
I need you to answer this: How exactly did you obtain the VOB whose first GOP is IBBP?


I tried 3 different DVDs which I have at hands atm and all of them had IBBP opening sequence (I'm starting to be pretty confident that it's almost always the case). I ripped them all with DVDDecrypter...

*EDIT* I tried SmartRipper as well it and it didn't make any difference. I got another DVD to try and yes, it's IBBP again. May be it's region/type related (PAL). But I'm pretty sure it's always been like that for me and I didn't have any sync problems in the past... So I'm a bit confused now.