Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
10th May 2008, 00:52 | #1 | Link |
Registered User
Join Date: Jul 2007
Posts: 35
|
Mencoder can hang with AVS input
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: Code:
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) 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: Code:
@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 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 |
10th May 2008, 23:09 | #2 | Link |
Avisynth Developer
Join Date: Jan 2003
Location: Melbourne, Australia
Posts: 3,167
|
Can you successfully "play" thru to the end of the script in VirtualDub?
If you add Code:
... AudioDub(Last, BlankClip(Last)) 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. Code:
A=AviSource("file 1.avi") B=AviSource("file 2.avi") C=AviSource("file 3.avi") ... A ++ B ++ C ++ ... Code:
... A + B + C + ... |
12th May 2008, 09:44 | #3 | Link |
Registered User
Join Date: Jul 2007
Posts: 35
|
@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: Code:
AviSource("D:\Assemblies\Sweet Bird of Youth", fourcc="XVID") 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 |
13th October 2012, 19:12 | #4 | Link |
Registered User
Join Date: Oct 2001
Location: Germany
Posts: 7,277
|
I know this is an really old thread but I encountered the same problem, when loading a source through AviSource mencoder hangs after a while, while everything works fine when FFVideoSource is used.
AviSource("xvid.avi") -> hangs FFVideoSourceSource("xvid.avi", ffindex="xvid.ffindex") -> works fine As vfw decoder ffdshow is used,.. Does anyone know if there's some 'magic' option in mencoder that fixes this issue? (maybe tweaking the buffers or something) |
14th October 2012, 05:03 | #5 | Link | |
...?
Join Date: Nov 2005
Location: Florida
Posts: 1,420
|
Quote:
Although I only ever dealt with short clips that were affected by this; but I figure if the issue exists with short clips and is resolved that way, it'll probably also work for long ones. Or maybe switch the ffdshow-designated decoder from libavcodec to Xvid, although I haven't tried that at all. |
|
|
|