VDubMod doesn't obey the start frame I've chosen

[brownstem]

Hi, I've used VDubMod 1.5.10.1 many times for trimming various .avi files. Lately I've been having constant problems with it freezing during Save .avi, with the log file saying things like "Dub: Processing thread has not cycled for ten seconds. Possible livelock..."

Occasionally I've had this problem before, but only infrequently, and I could always close/reopen VDubMod and get the .avi to eventually save correctly. Now I'm getting it much more on some files and can't ever get the trimmed .avi to save properly. Specifically, these are approx. 350MB Xvid files with variable mp3 audio, and I'm just trimming the first minute and last minute (credits) of each file. Direct stream is selected, and I say "no" to fixing the headers. These settings have always worked like a charm before.

Is there something I can change to get this baby cooking again? Thanks in advance for any help.

UPDATE: OK, I found the build 2429 update and now I can save. Now there's a new problem. The outputted video doesn't begin where I "told" VDubMod to begin. I advanced frame by frame, chose my beginning for the segment, then chose the end. But the outputted file begins about 3 seconds earlier in the source video than I selected. Is there a way to VDubMod to obey the frame I've chosen? Thanks.

[unskinnyboy]

UPDATE: OK, I found the build 2429 update and now I can save. Now there's a new problem. The outputted video doesn't begin where I "told" VDubMod to begin. I advanced frame by frame, chose my beginning for the segment, then chose the end. But the outputted file begins about 3 seconds earlier in the source video than I selected. Is there a way to VDubMod to obey the frame I've chosen? Thanks.
You can only cut thru keyframes (I-frames) using VirtualDubMoD even if you choose a frame in between as the starting/end point.

[brownstem]

Thanks, unskinnyboy. Do you happen to know of any way I can edit with more specific parameters (possibly another .avi editing tool)? I'm assuming there's something out there that can edit frame-by-frame.

[eb]

"frame-by-frame" you can do when re-encoding in VDM, you can also delete individual frames
When direct video coping, start always begins with I-frame

[brownstem]

Cool, EB, thanks. So basically it's just the time involved in re-encoding? Can I get away with Fast (as opposed to Normal or Full)? I understand that Full can take many hours. Also, don't these options result in ridiculously large output files? Thx.

[eb]

switch to FULL and see what you can do with video.
switch to NORMAL - '' -
switch to FAST - '' -

switching to FAST can speed up compression process up to 50% or more, but there are no picture display when encoding

It has nothing to do with file size, only compression parameters are connected with file size

[unskinnyboy]

@brownstem, Not sure what big deal is 3 secs of video, but anyways...

The reason for I-frames in a video stream is to be able to edit/cut the video and to be able to seek, so that is where you should be cutting it through. If there is some other freeware/shareware/paidware which is able to cut thru non-keyframes (which I doubt), then it is undesirable in any case. If it was possible/desired, then don't you think VirtualDubMoD would have had it already?

If there is a difference of ~3 seconds from the point where you specified to where VDub actually cuts it, it is because of the Max. I-frame interval specified when the file was encoded, which is usually set at 300 for NTSC (10x framerate is the recommended setting, so 29.971x10 = 299.71 ~ 300). I am assuming it is NTSC since your 350 MB-XviD-VBR mp3 smells like TV episodes to me.

If you were so finicky about the editing, what you should have done while creating the file (_If_ you created the file [?]), was to use a lesser number for the Max I-frame interval which would have resulted in more keyframes between point A and point B than what you have now, which in turn would have given you more control over editing the stream. But keep in mind that more bitrate would be needed in this case to encode the video as a whole and as a result, for the same filesize the quality would be inferior.

What I suggest you do is to cut out the unwanted clip thru the keyframes, re-encode just the cut clip, insert more keyframes into it while re-encoding, cut it to your heart's content and then join it back to the original file. This way you don't have to re-encode the whole file (If you do --> quality loss again).

[brownstem]

Thanks. Actually, in this case I was not the encoder, otherwise I wouldn't have had this issue in the first place (generally I use a Hauppauge card to record a large mpeg file from my digital cable box, then trim with Womble before creating Xvids...seems to work fine). The i-frames explanation was informative, and it's only because I try to make clean edits whenever possible in creating .avi batches that I'm even asking any of this. But given the trade off I think I'll stick with my current three-seconds-too-long file. Thx.

[mic]

When capturing for re-encoding, I've always captured all I frame because it would make for easier editing, but I also thought it would increase the quality. Some of the posts in this thread got me curious, so I finally got around to running a semi-quick test.

Using digital cable on-demand for test source, captured about 5 minutes worth using both all I frame & normal mpg2 structure with bitrate set to 12.5. Going through the DGIndex/DGDecode in V/Dub routine to create mjpeg avi's, loaded the results in Vegas so direct comparison could be made muting/unmuting top track. Couldn't really see any difference besides very slight amount of random noise in both tracks, so created stills from each track for comparison.

In photo editing software put one image on top of the other and set blending mode to difference. The max value I could find with cursor (everything looked black), was rgb 10/10/10, which is probably variance in noise. Kind of blew my theory of higher quality using all I frame :(

[pelmen]

so recording with I frame interval of 0 gives no noticable difference? is it more CPU intensive, or am I likely to run into more dropped frames on capture from analogue video?

(i have lots of VHS tapes of music videos and have just been using full processing each for each clip i edit from my captures since direct stream editing wasn't keyframe accurate where i wanted either). i will have to give that a try for my next batch of captures as it would save me a ton of time editing later on.

I wonder if it'd be possible to partially re-encode (either through a filter or add as a new feature to the main app) where you select a series of keyframe ranges (eg the first 500 frames and last 800 frames) and convert all frames in the range to I frames? that would help with editing existing files and save the hassle of trying to workaround with splitting up the source into multiple parts just to full process one section at a time then rejoin.

[mic]

so recording with I frame interval of 0 gives no noticable difference? is it more CPU intensive, or am I likely to run into more dropped frames on capture from analogue video?
Lower CPU load, but larger files. Originally all I frame was default for lower powered CPUs to avoid dropped frames, but that was several CPU generations ago running 300 - 800 mHz if I remember correctly.
I wonder if it'd be possible to partially re-encode (either through a filter or add as a new feature to the main app) where you select a series of keyframe ranges (eg the first 500 frames and last 800 frames) and convert all frames in the range to I frames? that would help with editing existing files and save the hassle of trying to workaround with splitting up the source into multiple parts just to full process one section at a time then rejoin.
I've been seeing more software lately for frame accurate editing of mpg2 that I'd think would almost have to operate that way. I know Hauppage has a downloadable free editing tool (no idea on if it will install/work without one of their products), there's always Cuttermaran, and searching google for "mpg2 editing software" brought up 3 or 4 more I think. I don't want to make more work for anybody, but could see it work I think once Avery Lee completes the new plugin architecture -- don't know anyone would do it now knowing a re-write might be needed.