Log in

View Full Version : Would DirectShowSource still work when adding subtitles?


fvisagie
1st September 2009, 09:46
Hi All,

I've previously used the DirectShowSource filter quite successfully to frame serve DV AVI to FFmpeg for encoding. Audio and video remained in sync etc. and all was well.

This time round I need to add ASS inlay subtitles. If possible I'd like to stick with DirectShowSource since evaluating alternatives is non-trivial. The project's playing time is ~3 hrs and it takes over two days to encode on my computer (there are also over 1,300 subtitles to check!).

However, I understand that DirectShow is frame inaccurate and am concerned that might affect subtitle synchronisation.

Which led me to wonder about the nature of its frame inaccuracy. If it only has problems with seeking back-and-forth, it should be OK for linear rendering such as when encoding, even with subtitles, surely?

On the other hand, if its problem has to do with incorrectly determining and/or reporting the current frame number even with linear rendering, it won't work when adding subtitles, right?

I would be very grateful if somebody could shed some light on the nature of DirectShow's frame inaccuracy and help me determine whether it remains a suitable source filter for encoding when subtitles are added?

Many thanks,
Francois

TheFluff
1st September 2009, 10:33
don't use directshowsource for anything involving subtitles, the end

I'm not sure what you mean by "evaluating alternatives is non-trivial" but for DV AVI you're most likely best off with ye olde avisource(). If you absolutely must have a directshow solution for some reason, at least use dss2(), which is frame-accurate.

fvisagie
1st September 2009, 11:02
I'm not sure what you mean by "evaluating alternatives is non-trivial"

Sorry for not being clearer. I've had so many cases where a short test clip comes out fine with the new tool or setting I'm trying and then bombs out on the project file, that the only way to be sure if it works is to test on the project file itself. In this case, trying with OpenDML, then maybe with AVIFile and so on, waiting 2 days each time before you can even start evaluating the results... that's what I tried to say :).

but for DV AVI you're most likely best off with ye olde avisource().

The source is ~36GB, but I could convert to Type 2 for OpenDML if that is advised, so how does it compare to AVIFile?

If you absolutely must have a directshow solution for some reason, at least use dss2(), which is frame-accurate.

Sticking with what has worked so far might limit the introduction of additional issues, but how do I specify dss2()? I haven't found any reference to it in the AVS 2.5.8 documentation.

sneaker_ger
1st September 2009, 11:33
It works similar to DirectShowSource:
dss2("clip.avi",fps=x)

AFAIK it always does a VFR->CFR conversion (like "convertfps=true" in DirectShowSource") and it's video only (no audio). There's not really much you can do wrong. I personally had problems with rendering the subtitles over DirectShow (sometimes they would disappear for a short time or start blinking...) so I would recommend using vsfilter.dll as a AviSynth plugin ( TextSub("subtitles.ass") ).

fvisagie
1st September 2009, 12:12
I've been using TextSub in other projects and appreciate your recommendation for this one.

My AVS has been reporting: "Script error: there is no function named "DSS2", but now I know why: http://avisynth.org/mediawiki/index.php?title=FFmpegSource&action=edit&redlink=1. Didn't realise it was an external filter :).

In the process I also came across these useful threads:
http://forum.doom9.org/showthread.php?t=134275
http://forum.doom9.org/showthread.php?p=1285639#post1285639

Thanks for your inputs.

TheFluff
1st September 2009, 13:24
The source is ~36GB, but I could convert to Type 2 for OpenDML if that is advised, so how does it compare to AVIFile?
How does what compare to AVIFile? AviSource() will load huge AVI files just fine, if that's what you're asking (it will automatically detect and parse OpenDML AVI files). The OpenDML reading code is actually taken from VirtualDub, by the way, so if VirtualDub handles it correctly (and vdub is pretty much the most reliable AVI reader there is) then so will Avisynth.

fvisagie
1st September 2009, 13:57
How does what compare to AVIFile? AviSource() will load huge AVI files just fine, if that's what you're asking (it will automatically detect and parse OpenDML AVI files).

I was interested in how OpenDMLSource compares to AVIFileSource in terms of accuracy, possible colour-space conversion quality issues etc., and then realised it's a moot point for this project anyway - the 36GB file is too large for AVIFileSource.

The reference to Type 2 conversion related to OpenDML. With Type 2 it also plays audio, removing the need to load audio separately and possibly introducing sync issues. At least that's my thinking.

For what it's worth, for this project (DV AVI with inlay subs -> FFmpeg -> MPEG-2) at this point it then looks sensible to narrow down the options to:
* investigate whether it's possible to load ASS/SSA subtitles into FFmpeg directly;
* failing that use AVS to frame serve video + subs with OpenDMLSource + VSFilter

Thanks for your help!

PS. I saw that OpenDMLSource comes from VirtualDub! And it was with the latter that I cleaned up scene edges and transitions in my project, all... let me see, 1677 of them! The result was clean, precise and predictable, so I have every faith in its OpenDML implementation.

Gavino
1st September 2009, 14:11
I suspect even the much-maligned DirectShowSource will work OK with DV files, since every frame is effectively a keyframe and there are no GOP issues. Indeed you've already said it worked fine on your large project (without subtitles).

@TheFluff: Is there any reason why adding subtitles should mess things up? Does this require a different frame access pattern?

fvisagie
1st September 2009, 14:30
@Gavino, to you this is probably old hat, but I've found http://avisynth.org/mediawiki/DirectShowSource which points out that some issues arise through lack of specification at decoder level, specifically frame-accurate seeking.

However, I also tend to suspect that a DV decoder especially would really have to be badly broken to not provide frame-accurate seeking.