does dvd2avi chop off frames?

[Guest]

Originally posted by jfcarbel
One more question for DVD2AVI developers and others... Would it be OK if we pursued this in a separate thread? This one is focused on getting correct rendering and a merger of existing functionality. Since you are contemplating significant revisions and/or new tools it really should be in a new thread.

[Guest]

Originally posted by Zeul
@neuron2

how close do you feel this is being to a public release? I only ask because a new version of NuMenu4U is to be released in the next day or so, and if possible the thought of being able to use the new fixed versions of dvd2avi and mpeg2dec3 appeals to me. apart from the obvious of using all frames the fact that the audio delay will now be exact is also of great benefit. Are these new 'fixed' versions only compatabile with avisynth 2.5+?

Zeul The full fix for frame delivery relies on both DVD2AVI and MPEG2DECX. I've only coded the fix so far for MPEG2DEC3, and it is an Avisynth 2.5 filter.

It's too early to say when the new code can leave beta. There are still some outstanding issues.

[Guest]

Originally posted by CruNcher
i have another Bug to report neuron2 for VOB this looks ok now but for DVB mpg streams their allways 2 shit frames encoded now @ the beginning with it maybe LOLi didnt introduced this 2 frames difference accedantialy because i know he streams HDTV hmm ? If the opening GOP is not closed due to an edit cut, then the first few frames are not decodable. You can either cut at closed GOP boundaries, or remove the frames after decoding. The main goal is to deliver all frames when the stream is correct.

[Guest]

@len0x

If I have understood you correctly, you are demuxing the audio. Then you use MPEG2DECx to generate a DivX AVI containing only the video. Then you fast recompress the DivX AVI with the audio. If you make the intermediate DivX AVI with MPEG2DEC3 original, it is in sync. If you make it with MPEG2DEC3dg it is async. The same demuxed audio is used in both cases. Thus, the two DivX intermediate AVI files must be different in a key way that explains everything, because MPEG2DEC3 is not involved in the final stage when the audio is added.

Can you compare the intermediate DivX files directly? I believe you said that one is a frame longer. But if you load them in VirtualDub and go to specific frame numbers in each, are they showing the same picture? I'm trying to ascertain if one has gained or lost frames relative to the other, because if I have understood you properly, that is the only way the final stage could produce different results. Also verify that the frame rates of the two intermediate DivX files are exactly 25.000 fps.

[jfcarbel]

neuron - I reposted my questions in a new thread per your request:
http://forum.doom9.org/showthread.php?s=&postid=374077

[CruNcher]

@neuron2
hmmm wouldn't it be possible to detect such a situation and drop those frames automaticaly ?
Dvd2avi your version doesn't show this 2 bad frames only when the file gets encoded via mpeg2dec3 they show up in the final encode and its hard to cut them @ the beginning when their is no keyframe :(

[jonny]

@neuron2 & len0x:
If this can help, i know that DivX 5.0.5 have a bug: it start serves an infinite number of "delay frames" (if you enable bframes) at the end of a second pass or multipass encode.
VDub, to prevent an infinite loop, cut out the last frame! (the truth is that DivX will never serve this frame)
So you have an avi with the last frame missing.
I dunno if this happen always or randomly (on my system i always obtain this result), anyway this could be a thing to take into account.

Cheers
jonny

[len0x]

Originally posted by neuron2

If I have understood you correctly, you are demuxing the audio. Then you use MPEG2DECx to generate a DivX AVI containing only the video. Then you fast recompress the DivX AVI with the audio. If you make the intermediate DivX AVI with MPEG2DEC3 original, it is in sync. If you make it with MPEG2DEC3dg it is async. The same demuxed audio is used in both cases.

Correct (well muxing is not done in fast recompress, but just direct copy mode, but I assume you meant that)

Originally posted by neuron2

Can you compare the intermediate DivX files directly? I believe you said that one is a frame longer. But if you load them in VirtualDub and go to specific frame numbers in each, are they showing the same picture?

DG file is two frames longer, one of them is a key frame according to vdubmod info. I opened both video files and indeed the same key number doesn't have the same picture! Right now I'm trying to find which frame is the first to be different... Stay tuned.

[len0x]

I hope that now I can provide more info about the problem.
I found exact frame at which sync breaks. It the first frame of the second M2V file (I haven't checked all other starting points of each M2V, but I'm confident it's where async starts). Frame 44255 is not only async, but it's also broken (I'll mail you, Don, pictures of both frames, so that you can see the difference). It has a small square of garbage in the left bottom corner. This frame is perfectly OK if using mpeg2dec3.dll 1.10

Hope this helps.

P.S. if someone knows how to cut a piece of M2V file then I can do a small sample of beginning of the second M2V file and sent it to Don.

[RB]

Originally posted by len0x
P.S. if someone knows how to cut a piece of M2V file then I can do a small sample of beginning of the second M2V file and sent it to Don.
Try Mpeg2Schnitt from http://de.geocities.com/martin_dienert/ . Hope you read German...

[len0x]

Originally posted by RB
Try Mpeg2Schnitt from http://de.geocities.com/martin_dienert/ . Hope you read German...

Well, when trying to open the file it says something like this:
"Datei filename.m2v wird nicht unterstützt". So my guess it can't open it... :)

[Guest]

@len0x

I have an idea what may be happening. If I am correct, beta 6 should not show this problem. Can you try it please?

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

[len0x]

Originally posted by neuron2

I have an idea what may be happening. If I am correct, beta 6 should not show this problem. Can you try it please?


Will do. First I'll do an encode of just first two M2Vs (to speed things) and report back.

[Jeffster]

Originally posted by len0x
P.S. if someone knows how to cut a piece of M2V file then I can do a small sample of beginning of the second M2V file and sent it to Don.

Perhaps ReStream (http://shh.dvdboard.de/restream.html) will help if you still need a tool?... it has an option to "cut a stream at a specific sequence header".

Regards
Jeff

[Guest]

Originally posted by CruNcher
@neuron2
hmmm wouldn't it be possible to detect such a situation and drop those frames automaticaly ?
Dvd2avi your version doesn't show this 2 bad frames only when the file gets encoded via mpeg2dec3 they show up in the final encode and its hard to cut them @ the beginning when their is no keyframe :( I will address this issue after resolving len0x's issue. But why can't you trim them in the AVS script before reencoding:

mpeg2source()
trim()

Would it help if I delivered blank frames or copies of the first decodable frame?

[CruNcher]

@neuron2


But why can't you trim them in the AVS script before reencoding:

mpeg2source()
trim()

Would it help if I delivered blank frames or copies of the first decodable frame?


Because the Demuxed audio file would still include those 2 bad frames ?
Black frames would be fine yes but if this can be avoided by droping them in dvd2avi imidiatly when they get detected would be a cleaner way i think.

[Guest]

Originally posted by CruNcher
@Because the Demuxed audio file would still include those 2 bad frames ? I understand your issue and am thinking about the best way to handle it. Perhaps the decoder could have an option allowing selection of handling for initial non-decodable frames:

1. Return black frames.
2. Copy first decodable frame.
3. Delete frames.

I've seen decoders that just macroblock as I do now, so it is not unprecedented, but also, as you cogently point out, not ideal.

[len0x]

You were right about beta 6. It doesn't have any problems on sample encoding I've just done.

[Guest]

@len0x

Great! Then I understand the problem and can easily fix it. The problem is that I am in San Jose on a business trip and my development environment is back in Chicago. I can release a fixed version tomorrow night and try to address Cruncher's issue this weekend.

Thank you for your efforts to assist in diagnosing this problem.

[len0x]

Good to hear that! Just let me know when new version ready and I'll do full encodings over the weekend. And thanks to you too!

[CruNcher]

@neuron2
that would be great thx :)

[Guest]

Sorry people, my plane got delayed and I couldn't get home in time last night to put anything together as promised. But I do have a new release for you now.

Beta 13 is a fix for len0x's issue and a fix for CruNcher's issue. Nondecodable initial frames are replaced with copies of the first decodable frame. That seemed to me to be the most rational thing to do.

Note: The CruNcher fix applies only for the MPEG2DEC3 method at this time and will be applied to Save AVI, Preview, and VFAPI in DVD2AVI in a future version.

@len0x

Please advise if this corrects your issue as I haven't actually duplicated it.

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

[Guest]

What do you people want first: command line version or VFAPI support?

[len0x]

Originally posted by neuron2
What do you people want first: command line version or VFAPI support?

I vote for CLI support :)

P.S. I queued a couple of encodes (including one which gave us the trouble) - should have results at some point tomorrow.

[len0x]

Did you remove the code for using mpeg2dec3.dll as external dll again?
(as I can't open d2v for preview anymore)

*EDIT* functions seems to be there, but for some reasons I can't use beta 13 in GK...

although I still will be able to test the issue...

[Guest]

Originally posted by len0x
Did you remove the code for using mpeg2dec3.dll as external dll again?
(as I can't open d2v for preview anymoreNo, I didn't change anything and it works fine when I run the GetPic example code. Are you sure you are using the right filename for the DLL?

[len0x]

Originally posted by neuron2
No, I didn't change anything and it works fine when I run the GetPic example code. Are you sure you are using the right filename for the DLL?

That's weird, I can use beta 12 and 1.10 version ok, but not beta 13...

P.S. i'm only using openMPEG2Source(), getFrame(), getRGBFrame(), closeVideo() functions...

*EDIT* It seems that I have only problems with that Godfather d2v (other project I have is ok). I'm looking at the d2v file now - stay tuned...

[Guest]

Originally posted by len0x
That's weird I agree. Standing by...

[len0x]

I rebuilt d2v project of Godfather and it worked ok with beta 13 of mpeg2dec3.dll. Now I cannot open the other project though :) I rebuilt it twice already, but still cannot open properly. (previous version of mpeg2dec3 can still open everything). Look very non-deterministic to me.

I recall ppl having such problems with pervious versions of DVD2AVI when one day a particular version just stopped working. I'm trying to search the forum now...

[Guest]

Is it only happening through GKnot? Or do you have similar problems just opening with MPEG2DEC3 via Avisynth?

[len0x]

Originally posted by neuron2
Is it only happening through GKnot? Or do you have similar problems just opening with MPEG2DEC3 via Avisynth?

Just tried opening avs file in VdubMod and got:
Avisynth open failure:
Evaluate: Unrecognized exception!
(avs file line 17)

Line 17 is mpeg2source()...

*EDIT* I cannot open any (i.e. 1.77.3 as well) projects for that movie with beta 13 of mpeg2dec3.dll (I'm not sure now if first time I opened it I was using the correct dll...)

[Guest]

Does it happen when opening or only after you try to display the first frame? In other words if you just open D2V but don't navigate does it crash, or only when you rewind or step in Vdub?

[len0x]

it crashes just on opening... not even seeking or playing...

[Guest]

OK, I am going to make a beta 14 with just the av sync fix and not the CruNcher fix. Stand by...

EDIT: Try beta 14: http://neuron2.net/fixd2v/decodefix100b14.zip

If it still fails, I'll need to see the D2V file.

[len0x]

Confirmed! It's working with beta 14...

[Guest]

OK, thank you. I'll take a closer look at the CruNcher fix code, although it appears OK. Please advise regarding the AV sync result.

[len0x]

Originally posted by neuron2
Please advise regarding the AV sync result.

OK, now I'll leave it for encoding until tomorrow. Will inform you about results then.

P.S. it seems that I came across every possible error with movies I'm trying to encode :)

[Guest]

@len0x

Yes, you're my favorite beta tester. :D

[Guest]

I have fixed the CruNcher issue code and it won't crash anymore. Please get beta 15:

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

Initial non-decodable frames are replaced with a copy of the first decodable frame. If you look at DebugView output, you'll see a line reporting the number of bad (replaced) frames if closed_gop is false.

This is the completed fix for the decoding, so we need to bang on this version. If it holds up, I'll do the command line version of DVD2AVI and make a first non-beta release.

[len0x]

sorry, i don't have results on beta 14 yet. well, encoding is definitely finished, but i couldn't get to work place where it was done :) should have them tomorrow morning.

Don, would you say i have to do encoding with beta 15 as well, or async will definitely be gone, assuming that beta 14 is ok, and i juts have to make sure i can open project which was crashing with beta 13?

[Guest]

Originally posted by len0x
Don, would you say i have to do encoding with beta 15 as well, or async will definitely be gone, assuming that beta 14 is ok, and i juts have to make sure i can open project which was crashing with beta 13? If it works in 14 it should be OK in 15, at least as far as the async issue was concerned. I don't see any need for retesting if it is OK in 14.

[Guest]

I cranked out a command line version. Note that the syntax is different because DVD2AVI 1.77.3 is different. Please see the file CommandLine.txt for details. I tested it a bit, but the onus is on the users to notify me of any problems/issues. :)

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

[CruNcher]

great news i test 15 now with DVB source but neuron couldn't you just cut those 2 nondecodable frames out like the old mpeg2dec3 did it ,instead of creating dupes ?

[Guest]

I don't want to do that. It makes special cases and tricky code. Cut your clips properly. :eek:

How are you ending up with these broken GOPs and why do the initial duplicates bother you so much?

[len0x]

OK, encodes with beta 13 went OK (no async problems). And beta 15 opens that crashing projects with no problems as well.

Regarding command line version: what was changed comparing to the command line version of 1.76?

[MLS]

Nice, maybe we can bug eyes'only to put your cli version in the new DIF4U.

/MLS

[Zeul]

I will certainly be implementing this into NuMenu4U asap. Thanks neuron2 for your extensive work on this problem. Are you planning to do a fixed version for Avisynth 2.07/8?

Zeul

[Guest]

Originally posted by len0x
Regarding command line version: what was changed comparing to the command line version of 1.76? The new syntax is documented in the CommandLine.txt file and reflects the menu options provided by version 1.77.3. You can compare this file to the corresponding file available with 1.76 CLI.

[Guest]

Originally posted by Zeul
Are you planning to do a fixed version for Avisynth 2.07/8? I can make one. How badly is it needed? Why are people not upgrading to 2.5?

[len0x]

Originally posted by neuron2
The new syntax is documented in the CommandLine.txt file and reflects the menu options provided by version 1.77.3. You can compare this file to the corresponding file available with 1.76 CLI.

I wish someone can point me to the 1.76 CLI version download which includes CommandLine.txt, coz all versions I have don't have this file with them... :(

P.S. Unfortunately i'm not the author of R4R tool which is using CLI version of the DVD2AVI and bundled with GK package, so I'd like to know if new CLI has backward compatibility with 1.76?