View Full Version : Can someone tell me where to go? ;-)
Starduster
15th April 2016, 15:19
I usually visit this forum when I have a problem. Recently I had one and it was quickly taken care of by you all. However, it left me a little confused on a couple of issues so here's my questions:
1. Which path should I take, AVISynth 2.6 and beyond or AVISynth+? Why the split?
2. Which is better to use for transcoding most video files, DirectShowSource or FFAudioSource + FFVideoSource? When would I use one over the other? In my code, I have been using the later but DirectShowSource is there too only commented out and I don't remember why.
You're opinions are greatly appreciated.
MWilson
15th April 2016, 15:22
I can't answer your first question. But the FFVideoSource + FFAudioSource combo and LSmashSource are what I personally go to.:o
StainlessS
15th April 2016, 15:57
It is generally thought best to avoid DirectShowSource due to it being not frame accurate (needed for heavy duty scripts using any kind of
non-linear access or motion compensation and such). Basically, use anything else other than DirectShowSource, if possible.
Avisynth/Avisynth+, well matter of personal choice really and I'm not gonna start saying that my choice is better than someone else's,
you are on your own there. :)
Why the split ? as always, not everyone is always totally happy with a particular product, and decided they could do better,
whether or not it is better is your decision.
manolito
15th April 2016, 16:17
Like StainlessS pointed out, DirectShowSource has been developped for playback and not for random access. But if your conversion only needs linear access, I find it pretty useful.
It also depends on the DirectShow filters which are used together with DirectShowSource. The current versions of LAVfilters do an excellent job.
Another DirectShow based approach is to use DSS2Mod by forclip. It exposes some internal DirectShowSource parameters, the most useful one being the "Preroll" parameter. Using this parameter I found that DSS2Mod together with LAVfilters is frame accurate in the majority of cases, so these days I prefer it over ffms2 or LSmash.
Cheers
manolito
wonkey_monkey
15th April 2016, 16:36
ffmpegsource isn't frame accurate for every kind of source, either.
http://avisynth.nl/index.php/FFmpegSource#Compatibility
raffriff42
15th April 2016, 18:15
>ffmpegsource isn't frame accurate for every kind of source, either.
That information is at least three years old, and possibly much older. It may still be true and may not be. If someone has some updated tests, I will be happy to update the wiki page.
Sharc
15th April 2016, 18:41
ff.....Source still seem to have issues with interlaced material / timecode. Whenever possible I prefer DGSource() using the index from DGindex...
wonkey_monkey
16th April 2016, 00:25
>ffmpegsource isn't frame accurate for every kind of source, either.
That information is at least three years old, and possibly much older. It may still be true and may not be. If someone has some updated tests, I will be happy to update the wiki page.
It's definitely still true. I've tried it with VOB/MPG recently.
Myrsloik
16th April 2016, 10:40
>ffmpegsource isn't frame accurate for every kind of source, either.
That information is at least three years old, and possibly much older. It may still be true and may not be. If someone has some updated tests, I will be happy to update the wiki page.
Spoiler: It's not. Whether or not it's frame accurate depends mostly on the ffmpeg implementation of the parsers and how they interact with the FFMS2 method of doing things. Also, the past several years have mostly just been maintenance. To improve things further you'd more or less need to start over from scratch and do things differently. Like LSmashSource for example. But that brings another set of issues... Or a specialized solution like d2vsource that only does one format well. Basically every single container needs special handling even when using ffmpeg to do this. That takes too much time.
Sharc
16th April 2016, 11:03
As a probably "average" user I would prefer a well maintained system over a number of (competing) forks with similar intentions but introducing new bugs and limitations. Well, it's wishful thinking and you might say it's against "progress" ..... ;)
raffriff42
16th April 2016, 11:38
Spoiler: It's not. Whether or not it's frame accurate depends mostly on the ffmpeg implementation of the parsers and how they interact with the FFMS2 method of doing things. So I would expect performance to improve for some of these containers and possibly get worse for others due to ffmpeg changes as you say. I'm just saying, someone who has experience with these containers should run some new tests. (I never see any problems with FFMS2 myself, as I stick to AVI, MP4 and MOV.)
By the way, that wiki information has not changed since July 2011 (http://web.archive.org/web/20110702120157/http://avisynth.org/mediawiki/FFmpegSource#Compatibility) (when I suppose you wrote it)
I see some slight changes in your documentation on GitHub (https://github.com/FFMS/ffms2/blame/ddb63222fb0d9bd8b6d1b50038a010df666204ff/doc/ffms2-avisynth.md) (removed "with two notable exceptions, namely MP3 and AC3 where FFmpeg's decoders seem to be completely broken...") which should (and will) be incorporated in the wiki.
TheFluff
16th April 2016, 14:29
So I would expect performance to improve for some of these containers and possibly get worse for others due to ffmpeg changes as you say. I'm just saying, someone who has experience with these containers should run some new tests. (I never see any problems with FFMS2 myself, as I stick to AVI, MP4 and MOV.)
By the way, that wiki information has not changed since July 2011 (http://web.archive.org/web/20110702120157/http://avisynth.org/mediawiki/FFmpegSource#Compatibility) (when I suppose you wrote it)
I see some slight changes in your documentation on GitHub (https://github.com/FFMS/ffms2/blame/ddb63222fb0d9bd8b6d1b50038a010df666204ff/doc/ffms2-avisynth.md) (removed "with two notable exceptions, namely MP3 and AC3 where FFmpeg's decoders seem to be completely broken...") which should (and will) be incorporated in the wiki.
Plorkyeran rewrote most of the audio seeking code a few years ago and then fixed a bunch of exotic edge cases last July. It should be reliably sample-accurate now (until ffmpeg changes a bunch of stuff, I guess).
Video seeking is like always, though.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.