Mencoder can hang with AVS input

[bidmead]

A little bit of background: I'm using the Archos TV+ box as a source of TV recording for my home cinema network. The Archos TV+ records to DiVX, single pass, 2500Kbps, with 4-bit ADCPM sound (don't ask!), resulting in large (2GBish) files. Well, actually the Archos TV+ in its wisdom splits the files at around 1GB, but I can generally join them up (with VirtualDub) without any dropped frames. The result of this process creates a large OpenDML AVI container for the original DiVX and ADCPM streams.

To remove ads and generally clean up I transcode these files via AviSynth with scripts that look something like this, at their simplest:

AVISource("D:\Assemblies\A Man Apart\A Man Apart.VM-A.avi")
Trim(316, 173038)
Dissolve(Trim(0, 30100) , Trim(37025, 172722), 25)
Dissolve(Trim(0, 66726) , Trim(73652, 165773), 25)
Dissolve(Trim(0, 100701) , Trim(107627, 158823), 25)


I've been successfully feeding the output from this into a DOS script based around 2-pass ffmpeg accessed through the Windows XP SendTo mechanism. The gotcha with ffmpeg is that it automatically outputs into an ODML AVI when the output file gets bigger than around 1GB. An ODML container will play fine with my Pinnacle ShowCenter until, typically, the last couple of minutes, when the movie will abruptly abort. The solution is to ensure the container is always AVI 1 -- but I haven't found a way of guaranteeing that with ffmpeg.

So I'm trying to switch to mencoder, which has the -noodml option. Unforch, there's a different big gotcha with mencoder. An AVS script like the one above does the first pass just fine, but at the very end of that pass mencoder hangs and won't go on to the second pass.

By minimalising the mencoder script down to a single pass, barebones implementation I've discovered that what's causing the hang is that large AVISource input file originating from the Archos TV+ box. Smaller input files don't have this problem. I've tried using AVIFileSource and OpenDMLSource instead of AVISource, but this doesn't help. It seems that AVISource isn't closing the input file at the end of pass 1, and for some reason this is keeping mencoder from closing the output file. Mencoder doesn't exit, and retains its lock on the output file. You'll wait forever for a second pass when mencoder's in this mood... :-)

A workaround is to use DirectShowSource for the AVI input file, but I'm not too happy with this, particularly as I'm not 100 per cent sure what's actually going on here.

Here's my mencoder script, stripped right down to single pass to highlight the problem:

@echo off

rem chb 9-May-08

set ENCODER="C:\Program Files\MediaCoder\codecs\mencoder.exe"
set RENAME="mencoder.4.2.2@999"

set PASS1OUT="%~dp1%~n1.%RENAME%.avi"
rem PASS1OUT=nul.avi

%ENCODER% %1 -ovc lavc -oac lavc -ffourcc XVID -o %PASS1OUT%

pause
exit


If the AVS script is using AVISource, as above, the mencoder script runs, produces a valid output file, but then hangs, without arriving at the pause prompt. (It also hangs -- without, obviously, producing an output file if you substitute nul.avi as the output).

But if you use DirectShowSource in the AVS script men, the script merrily reaches the pause prompt and all will run smoothly into a second pass (haven't put that together yet, but I'm sure it will).

Can anyone shed any light on why AVISource is stopping the show here?

--
Chris

[IanB]

Can you successfully "play" thru to the end of the script in VirtualDub?

If you add...
AudioDub(Last, BlankClip(Last))to the end of your script (with AviSource) does it complete? (the audio will be silenced)

Which ADPCM codec are you using? A few of the older ones choke around the 2^31 mark.

Why do you bother physically joining the source clips into 1 big file, why not just append the file segments in your script? i.e.A=AviSource("file 1.avi")
B=AviSource("file 2.avi")
C=AviSource("file 3.avi")
...
A ++ B ++ C ++ ...or perhaps...
A + B + C + ...if the files have been sliced unaligned.

[bidmead]

@IanB Thanks for that swift response and excellent questions.

The script plays fine in VDub and, eg, MPC. I've also established that audio isn't the problem -- using KillAudio() in the script to remove the audio stream still results in the reported hang at the end of pass 1.

The reason I've been using VDub to concatinate the pieces is twofold:

a) The recording tends to have a generous top and tail, and I use VDub to snip off most of the excess (leaving it to the AviSynth script to do the final frame-accurate top and tailing).

b) I'm still not confident that the Archos TV+ can split the recording without dropping frames. Concatinating in VDub is an easy way to check this. Tests so far suggest that the Archos TV+ does a good job in this respect, so I may revert to doing the cat inside the AVS script as you suggest.

But Good News! I woke up this morning realising that I hadn't explored all the possible options of AviSource(). There's an option that allows you to set the FourCC, and thus determine which decoder AviSource will use to turn the compressed incoming stream into frames.

As I think I mentioned, the Archos TV+ box uses DiVX to encode (or at least sets a DiVX FourCC), and so I guess AviSource is evoking the DiVX decoder by default. When I switched to, eg:

AviSource("D:\Assemblies\Sweet Bird of Youth", fourcc="XVID")

...the hanging problem went away. So DiVX seems to be the culprit here. I tend to do this stuff on pretty entry-level hardware, so it may be that DiVX expects to be able to create bigger buffers than my memory allows. Or something. I dunno.

If anyone can shed any light on this, from theory or experience, I'd be very interested.

Also, if there's any interest in the 2-pass mencoder SendTo script I'm currently refining for the Pinnacle ShowCenter (and I guess other early generation standalones), let me know and I'll post it up here. It lets me just right-click on the AVS script in Explorer and send it to the encoder without having to power up yet another GUI.

--
Chris