FFmpegSource

[qyot27]

EDIT 2013-10-04: Newer build here:
http://forum.doom9.org/showthread.php?p=1646661#post1646661

FFMS2 C-plugin r836

Optimized for Pentium III and SSE.

Explanation of the revision number: the difference between trunk and Git's internal revision counting is 67 commits, so it's just the dumb math of running 'git rev-list --count HEAD' on the cplugin_master branch (https://github.com/qyot27/ffms2/commits/cplugin_master) and then adding 67 to it. The short version: ignore the revision number right now, it's caught up to the master branch.

Since FFmpeg got the Opus-in-Matroska stuff sorted out over the last couple days, it's been patched to also be capable of handling that.

Built against ffmpeg version r56269 git-108b91c.

FFmpeg configuration:
--enable-gpl
--enable-version3
--disable-w32threads
--enable-avresample
--enable-libopus
--disable-decoder=utvideo --enable-libutvideo
--disable-decoder=vp8 --enable-libvpx
--disable-encoders
--enable-avisynth
--disable-muxers
--disable-debug
--disable-network
--disable-hwaccels
--disable-indevs
--disable-outdevs
--cpu=pentium3
--extra-cflags='-mfpmath=sse -march=pentium3 -msse -mtune=pentium3 -DPTW32_STATIC_LIB'
--target-os=mingw32
--arch=x86

[TheRyuu]

ffms2-2.19.7z (https://github.com/FFMS/ffms2/releases/download/2.19/ffms2-2.19.7z)

2.19 is the same as 2.18 except it actually compiles outside of msvc, hence the skip to 2.19. See the 2.18 release post (https://github.com/FFMS/ffms2/releases/tag/2.18) for a changelog.

2.19 20130917

Built with MSVC 2012 Update 3:
c99-to-c89 7e75aa9 https://github.com/libav/c99-to-c89
ffmpeg 78f680c http://www.ffmpeg.org/
opencore-amr 0.13 http://sourceforge.net/projects/opencore-amr/
zlib 1.28 http://www.zlib.net

../ffmpeg/configure --enable-gpl --enable-version3 --enable-runtime-cpudetect \
--disable-debug --samples=/f/build/fate-ffmpeg-samples --toolchain=msvc \
--enable-w32threads --enable-avresample --enable-zlib \
--enable-libopencore-amrnb --enable-libopencore-amrwb --disable-inline-asm \
--disable-muxers --disable-encoders --disable-filters --disable-hwaccels \
--disable-network --disable-devices

[qyot27]

EDIT: Newer build available here. (http://forum.doom9.org/showthread.php?p=1650386#post1650386).

FFMS2 C-plugin r783+33

Optimized for Pentium III and SSE. Includes a fix that allows the plugin to work with the current version of AviSynth+. (https://github.com/qyot27/ffms2/commits/cplugin_master)

I've settled on a different method of representing the revision number, which is why the number dropped.

Built against FFmpeg r56888 git-bb9e9ee, has a single patch to avoid crashing on non-SSE2 processors (https://github.com/qyot27/FFmpeg/commits/videodsp_sse_workaround)

FFmpeg configuration:
--cross-prefix=i686-w64-mingw32-
--enable-gpl
--enable-version3
--disable-w32threads
--enable-avresample
--enable-libopus
--disable-decoder=utvideo
--enable-libutvideo
--disable-decoder=vp8
--enable-libvpx
--disable-encoders
--enable-avisynth
--disable-muxers
--disable-debug
--disable-network
--disable-hwaccels
--disable-indevs
--disable-outdevs
--cpu=pentium3
--extra-cflags='-mfpmath=sse -march=pentium3 -msse -mtune=pentium3 -DPTW32_STATIC_LIB'
--target-os=mingw32
--arch=x86

[easyfab]

There is now a native Vp9 and Hevc decoder in ffmpeg, can FFMS2 use this ?

[qyot27]

There is now a native Vp9 and Hevc decoder in ffmpeg, can FFMS2 use this ?
If it's been built against a new enough build of FFmpeg it can. It's more or less automatic (for the lavf demuxer, anyway).


EDIT: Newer build available here. (http://forum.doom9.org/showthread.php?p=1658765#post1658765)

FFMS2 C-plugin r800+29

Optimized for Pentium III and SSE.

Built against FFmpeg r57511 git-8930637:
--enable-gpl
--enable-version3
--disable-w32threads
--disable-ffprobe
--disable-avdevice
--disable-swresample
--disable-postproc
--disable-avfilter
--enable-avresample
--disable-doc
--disable-debug
--disable-encoders
--disable-muxers
--disable-network
--disable-hwaccels
--enable-libilbc
--enable-libopus
--enable-libspeex
--disable-decoder=utvideo --enable-libutvideo
--enable-avisynth
--cpu=pentium3
--extra-cflags="-mfpmath=sse -march=pentium3 -msse -mtune=pentium3 -DPTW32_STATIC_LIB"
--target-os=mingw32
--arch=x86

[easyfab]

Thanks for the build.

[LigH]

Works with HEVC video in MP4. But due to the complexity of the format, random seeking is a bit unreliable (or just very slow to get decoded to the target?), linear access strongly recommended.

[AlanHK]

When using an MKV source with multiple audio tracks, is there a way to get the native specs?

Often it's obvious, different languages or number of channels, but I have some with with AC3 stereo at a high bit rate and AAC stereo at a low rate. How can I be sure which one I'm decoding?

Or what can reliably give me the same "atrack" number that ffms2 uses and the spec of that track?

[TheFluff]

When using an MKV source with multiple audio tracks, is there a way to get the native specs?

Often it's obvious, different languages or number of channels, but I have some with with AC3 stereo at a high bit rate and AAC stereo at a low rate. How can I be sure which one I'm decoding?

Or what can reliably give me the same "atrack" number that ffms2 uses and the spec of that track?

I thought that ffmsindex would tell you but apparently I was wrong. The API does expose the information as well but apparently there's no way to access it short of writing your own program. I guess we should really add an option of listing all tracks to ffmsindex.

[raffriff42]

>what can reliably give me the same "atrack" number that ffms2 uses and the spec of that track?

This little batch file will. FFprobe.exe (or ffmpeg.exe or ffplay.exe) will list the stream numbers and other information on any file it understands. In limited tests I have found the stream numbers to be compatible with FFMS. I keep this batch file in my Send To folder for quick info on any media file."path\to\ffmpeg\ffprobe.exe" -i "%~dpnx1"
pause

[LigH]

Using libav decoders, FFMS2 is apparently able to decode Lagarith YUV 4:2:0; but Lagarith YUV 4:2:2 fails, according to tests by users in the German doom9/Gleitz forum. But this format is used by some people for e.g. analog capturing or intermediately for interlaced conversions.

Therefore I'd like to put a feature request to get Lagarith YUV 4:2:2 supported too. According to JEEB, it may be possible in conjunction with 4:2:0, if it doesn't differ severely. Provided any developer has enough time and interest in it.

Are there better places to ask for it than here?
__

P.S.:

It is already implemented. Sorry for the noise. The reporter must have used an outdated version...

[Selur]

@qyot27: could you build a current version? Saw 'Fix infinite loop on garbage data at the beginning of AAC files' form 10th of december and wanted to test it.

[qyot27]

@qyot27: could you build a current version? Saw 'Fix infinite loop on garbage data at the beginning of AAC files' form 10th of december and wanted to test it.
Coincidentally, I had built it about 5 hours ago, mostly for having a newer build of FFmpeg.

FFMS2 C-plugin r809+35

Optimized for Pentium-III and SSE.

FFmpeg configuration:
ffmpeg version r59267 git-10a9f33 Copyright (c) 2000-2013 the FFmpeg developers
built on Dec 20 2013 23:42:33 with gcc 4.8.2 (GCC)

configuration:
--prefix=/home/qyot27/win32_build
--cross-prefix=i686-w64-mingw32-
--enable-gpl
--enable-version3
--disable-w32threads
--enable-avresample
--disable-doc
--enable-libopus
--disable-decoder=utvideo
--enable-libutvideo
--disable-encoders
--disable-muxers
--disable-doc
--disable-debug
--disable-network
--disable-hwaccels
--disable-indevs
--disable-outdevs
--cpu=pentium3
--extra-cflags='-mfpmath=sse -march=pentium3 -msse -mtune=pentium3 -DPTW32_STATIC_LIB'
--target-os=mingw32
--arch=x86

EDIT 2014-03-21: Updated build here (http://forum.doom9.org/showthread.php?p=1674530#post1674530)

[Selur]

Nice! Thanks!

[Taurus]

Thank you!

[pandv2]

@qyot27: Thanks for your build.

I replaced an more older oficial build with your build. And my program (a C# program) has stopped working.

After investigation is because:

In the oficial build the functions are exported as: _FFMS_Init@8
But in your build the functions are exported as: FFMS_Init@8, without the initial underscore.

I don't know who is correct, but I would appreciate if both builds can follow the same schema.

Windows like more the schema with the underscore, because I can name the function FFMS_Init and is automatically linked. With your dll i need to add a atributte (EntryPoint="FFMS_Init@8") to each function.

[qyot27]

@qyot27: Thanks for your build.

I replaced an more older oficial build with your build. And my program (a C# program) has stopped working.

After investigation is because:

In the oficial build the functions are exported as: _FFMS_Init@8
But in your build the functions are exported as: FFMS_Init@8, without the initial underscore.

I don't know who is correct, but I would appreciate if both builds can follow the same schema.

Windows like more the schema with the underscore, because I can name the function FFMS_Init and is automatically linked. With your dll i need to add a atributte (EntryPoint="FFMS_Init@8") to each function.
Not possible, because they aren't built with the same compiler. The official builds are compiled with MSVC, the C plugin is compiled with GCC/G++ - while C is coincidentally cross-compatible between the two (as I understand it), C++ is not (http://forum.doom9.org/showthread.php?t=169730). FFMS_Init is defined in the C++ portion of FFMS2's code, so it's affected by the fundamental difference in name mangling (et al.) between G++ and MSVC.

You'll probably just want to stick with the official releases:
https://github.com/FFMS/ffms2/releases

[Plorkyeran]

All of ffms2's public API, including FFMS_Init, is declared as extern "C". GCC just doesn't default to the C name mangling scheme used for Windows DLLs. Building with -fleading-underscore should fix that, but may break loading it as an avs c plugin. If that's the case, a def file is probably required.

[LoRd_MuldeR]

Not possible, because they aren't built with the same compiler.

Well, technically it is possible, I think. Different C++ compilers use different name mangling schemes, which causes this kind of problems. Since there is no official standard for name mangling, no compiler is "wrong" or "correct". But even in C++ code you can use extern "C" to have the function exported with a plain C name. Furthermore, even if you have an existing DLL, you can generate your own import library (.lib) for that DLL using the "lib" tool and a suitable DEF file. Using the DEF file method, the name of the DLL entry point and the corresponding C/C++ symbol name don't have to be the same (which is in contrast to the auto-generated import libraries). So you could do something like:

LIBRARY ffms2.dll
EXPORTS
_FFMS_Init@8=FFMS_Init@8

Plorkyeran was faster ;)

[qyot27]

extern "C" had skipped my mind, sorry.

I'm not sure if -fleading-underscore actually did anything. It still seems to show up sans leading underscore when I check in dllexp.

[Reino]

Lately I've been doing some audiomixing with AviSynth for a videogame's dynamic soundtrack. The soundtrack consists of a lot of small mp3 segments of about 5 to 10 seconds which I initially opened with BassAudioSource(). Last week I decided to have a look if it would make a lot of difference if I would use NicMPG123Source(), or FFAudioSource() instead. These are my findings, after having encoded AviSynth's output with avs2pipemod and takc.exe to TAK:
Sample_BassAudioSource.tak - 477kbps, 4045809 samples
Sample_NicMPG123Source.tak - 478kbps, 3935217 samples
Sample_FFAudioSource.tak - 495kbps, 4045809 samples
Sample_Audacity-2.0.5.tak - 475kbps, 4045809 samples (I've done the mixing before with Audacity)
NicAudio had 'resyncing' issues, but that's another story.
I was wondering if anyone knows if FFAudioSource is adding noise, doing dithering, or anything else that explains the higher bitrate?

[jdobbs]

Coincidentally, I had built it about 5 hours ago, mostly for having a newer build of FFmpeg.

FFMS2 C-plugin r809+35 (http://www.mediafire.com/?ih96amt5vik278b)

Optimized for Pentium-III and SSE.

FFmpeg configuration:
ffmpeg version r59267 git-10a9f33 Copyright (c) 2000-2013 the FFmpeg developers
built on Dec 20 2013 23:42:33 with gcc 4.8.2 (GCC)

configuration:
--prefix=/home/qyot27/win32_build
--cross-prefix=i686-w64-mingw32-
--enable-gpl
--enable-version3
--disable-w32threads
--enable-avresample
--disable-doc
--enable-libopus
--disable-decoder=utvideo
--enable-libutvideo
--disable-encoders
--disable-muxers
--disable-doc
--disable-debug
--disable-network
--disable-hwaccels
--disable-indevs
--disable-outdevs
--cpu=pentium3
--extra-cflags='-mfpmath=sse -march=pentium3 -msse -mtune=pentium3 -DPTW32_STATIC_LIB'
--target-os=mingw32
--arch=x86I tried to use this -- but when I use the LoadPlugin() line I'm getting a message saying "This is not a plugin dll for Avisynth 2.5" (or close to that). Did I miss something?

[qyot27]

I tried to use this -- but when I use the LoadPlugin() line I'm getting a message saying "This is not a plugin dll for Avisynth 2.5" (or close to that). Did I miss something?
LoadCPlugin(), or just make sure that FFMS2.avsi (which also takes care of loading it) is alongside ffms2.dll in the plugins folder.

[jdobbs]

Thanks!

[fvisagie]

I'm having trouble with output from my Canon HF G30. Frames are skipped, returned out of sequence and/or the total frame count seems wrong. I'm using AVS 2.60 Alpha 4 and FFMS2 2.19 with Haali Media Splitter 20130623 installed and configured for OGM and MPEG PS/TS as per the FFMS2 user manual. Testing was done with progressive encoding so if libav still has PAFF issues those shouldn't apply. The camera can be configured for AVCHD and MP4 output formats, but both produce similar errors. Remuxing AVCHD output to MP4 or MKV also does not help.

Following are some example output clips with problem details. The error list is probably not exhaustive, but I'm at least listing what I've found. I'm using this script to simulate and evaluate scrubbing of each clip:

source="AVCHD.MTS"

FFIndex(source=source)
FFMS2=AudioDub(FFVideoSource(source=source, fpsnum=50, fpsden=1), FFAudioSource(source=source)).Subtitle("FFMS2", size=36, align=1).Scrub()

LoadPlugin("C:\Program Files\Haali\MatroskaSplitter\avss.dll")
DSS2=DSS2(source).ConvertToYV12(matrix="PC.709", interlaced=false).Subtitle("DSS2", size=36, align=1).Scrub()

StackVertical(FFMS2, DSS2)

function Scrub(clip c) {
c.ShowFrameNumber(scroll=true, size=36)
Trim(0,11) + Trim(10,10) + Trim(9,9) + Trim(8,8) + Trim(7,7) + Trim(6,6) + Trim(5,5) + Trim(4,4) + Trim(3,3) + Trim(2,2) + Trim(1,1) + Trim(0,-1)
}


AVCHD.MTS (http://www.mediafire.com/download/7tb6q0kmyk3uj2h/AVCHD.MTS) is an untouched AVCHD format recording, and its scrubbed version is scrubbed AVCHD.MTS.avi (http://www.mediafire.com/watch/q7dmvwikfiie1mc/scrubbed%20AVCHD.MTS.avi):
* Frame 0 appears too early in time (i.e. preceding frames aren't shown)
* Rewinding from 10 to 9 the jump is too big and frame 9 is shown twice, and the jump between 6 and 5 is too big
* When the original clip is manually scrolled forward and backward, frames eventually appear closer to the correct time (+/- 4 frames later), but this results in 3 repeated frames at the beginning of the clip. This scrolling forward and backward sometimes causes further frame sequencing problems, even for normal sequential forward access.
* Reverse scrolling from the end of the original clip produces many initial repeats

MP4.MP4 (http://www.mediafire.com/watch/hsg242s1nbi4ai3/MP4.MP4) is an untouched MP4 format recording, and its scrubbed version is scrubbed MP4.MP4.avi (http://www.mediafire.com/watch/nnjxnr0nwd52xpa/scrubbed%20MP4.MP4.avi):
* The first 3 frames are repeats
* Rewinding, frame 9 is out of sequence, the jump from 6 to 5 is too big and the last 3 frames are repeats again
* Manually scrolling forward and backward a larger number of frames than in the script (or repeatedly) seems to remove rewind sequence errors, but the repeated frames at the beginning of the clip remain
* Reverse scrolling from the end of the original clip appears to work correctly, although it seems the last 2 frames aren't shown

AVCHD.MP4 (http://www.mediafire.com/watch/ym7ozxcdqdv4dc3/AVCHD.MP4) was remuxed from AVCHD.MTS with ffmpeg, and its scrubbed version is scrubbed AVCHD.MP4.avi (http://www.mediafire.com/watch/c88g8za3jdjvk2l/scrubbed%20AVCHD.MP4.avi):
* The first 3 frames are repeats
* Rewinding, frame 9 is a duplicate of 7 and the jump between 6 and 5 is too big and the last 3 frames are repeats again
* Manually scrolling forward and backward a larger number of frames than in the script (or repeatedly) seems to remove rewind sequence errors, but the repeated frames at the beginning of the clip remain
* Reverse scrolling from the end of the original clip appears to work correctly, although it seems the last 2 frames aren't shown

AVCHD.MKV (http://www.mediafire.com/download/ceo2p3m7ci4lch8/AVCHD.MKV) was remuxed from AVCHD.MTS with DSMux, and its scrubbed version is scrubbed AVCHD.MKV.avi (http://www.mediafire.com/watch/r45it3hp4zo5jje/scrubbed%20AVCHD.MKV.avi):
* The first 3 frames are repeats
* Reverse scrolling from the end of the original clip seems to correctly show the last frame, except that it is repeated 4 times before being replaced by a new frame

In summary, with this camera's output FFMS2 fared best with the MKV container, the MKV container combination still had problems with starting/ending frame numbers, and to some extent those problems seem to be shared with all combinations tried.

If I'm doing something wrong, please set me straight. Otherwise, I hope this information can assist towards improving FFMS2. I'd be happy to produce more clips and/or tests if necessary.

On the other hand, please feel free to suggest alternatives if you feel that's appropriate. Although remuxing to MKV might seem usable in theory if one is prepared to tolerate start/end inaccuracies, in practice I'm sitting with 450 clips @ 33GB and that just from 1 trip! With other formats I liked FFMS2 for its frame accuracy and video+audio support; from that point of view something like DSS2 isn't ideal either.

Thanks a lot,
Francois

[LigH]

You should not create MKV with ffmpeg, only with mkvmerge. Multiplexers of several formats in ffmpeg are notorious for probably incomplete results, due to the FIFO processing in ffmpeg (output is written only once to allow piping if required). Instead, mkvmerge may be considered as closest to the MKV specs.

I guess you may have interlaced AVC video in your M2TS. This combination used to be the least supported by different software. It may or may not help to limit "threads=1" in FFVideoSource. But using L-SMASH Source may be a more reliable alternative here.

[fvisagie]

You should not create MKV with ffmpeg


Apologies, AVCHD.MKV was in fact remuxed from AVCHD.MTS with Haali Media Splitter's DSMux.

I guess you may have interlaced AVC video in your M2TS.

Valid issue to consider, but I strongly believe that isn't the case here. Apart from the fact that MediaInfo etc. agree with the camera that its output is progressive, with SeparateFields() and VirtualDub's bob doubler (None - alternate fields) I see no field-based motion, and I don't see any interlacing artifacts either.

It may or may not help to limit "threads=1" in FFVideoSource.

Unfortunately that doesn't help here.

But using L-SMASH Source may be a more reliable alternative here.

I'll look into that, thanks.

[Selur]

You could also try FFMS2 C-plugin r809+35 which qyot27 posted; remember LoadCPlugin is needed for this.

[qyot27]

You could also try FFMS2 C-plugin r809+35 which qyot27 posted; remember LoadCPlugin is needed for this.
Technically yes, but not entirely. FFMS2.avsi contains the LoadCPlugin line, so if you keep the .dll and .avsi together in your plugins folder, it'll act as if the C plugin is autoloading. For that matter, Import("path/to/FFMS2.avsi") if they aren't in plugins/ (but still together) would probably accomplish it too.

Or use AviSynth+, since it does allow C-plugins to autoload without any special handling. This could also be read as 'just use AviSynth+ anyway'*.


*Caveat for *nix users: the builds currently don't work in Wine because they were built with VS2012 (with the MT branch, VS2012 is required because of C++11; however, it is possible to build r1576 with VS2010 and that would work in Wine).



The way I understand the state of MPEG-TS remuxing support is that even if you do remux it to MKV with any number of tools, you may still need to remux the MKV with mkvmerge because it could still have issues (or just give the TS file to mkvmerge directly). I seem to remember this being the case with eac3to remuxes needing to be treated with mkvmerge afterward to standardize them. I'm not sure how true any of this still is, though.

[LigH]

The way I understand the state of MPEG-TS remuxing support is that even if you do remux it to MKV with any number of tools, you may still need to remux the MKV with mkvmerge because it could still have issues (or just give the TS file to mkvmerge directly).

For this reason, I recommended the use of mkvmerge so explicitly too. ;)

Interlaced video in Transport Streams seems to have quirks only few tool developers understood well.

[fvisagie]

AVCHD.MKV (http://www.mediafire.com/download/ceo2p3m7ci4lch8/AVCHD.MKV) was remuxed from AVCHD.MTS with DSMux, and its scrubbed version is scrubbed AVCHD.MKV.avi (http://www.mediafire.com/watch/r45it3hp4zo5jje/scrubbed%20AVCHD.MKV.avi):
* The first 3 frames are repeats
* Reverse scrolling from the end of the original clip seems to correctly show the last frame, except that it is repeated 4 times before being replaced by a new frame

You should not create MKV with ffmpeg, only with mkvmerge.

For the sake of completeness, remuxing with mkvmerge instead yields the following:
* The first 3 frames are repeats

Another interesting thing I noticed now is that for the MTS clip FFVideoSource(source=source) would report a frame rate of 49209/1001; for the (mkvmerge) remux it reports a frame rate of 50 and the output is 2 frames longer. As far as I can tell, however, the original MTS clip shouldn't be and isn't VFR.

With DSS2() I also had a surmountable problem (http://article.gmane.org/gmane.comp.multimedia.matroska.devel/4794) with the original MTS clip, which also disappeared with the mkvmerge remux. With DSS2() the mkvmerge remux is 1 frame longer.

I'm still looking into L-SMASH and the FFMS2 C-plugin.

Thanks for the suggestions so far.

[LigH]

Regarding the strange TS framerate, I could imagine that the FFMS2 indexer incorrectly relates the number of (wrongly?) counted frames with the timecode difference between first and last GOPs. One reason may be that not the best matching demuxer was used in the indexing step. You may try to select a specific other demuxer. But as already documented in the FFMS2 AviSynth documentation, FFMS2 simply is not reliable with MPEG TS sources, even when Haali's Media Splitter is installed and used during indexing.

And if even the MKV remultiplexed by a current version of mkvmerge is wrong, then there is certainly a chance that the content of the TS is a little odd; people knowing the quirks of DVB by heart may understand better than me why.

[fvisagie]

One reason may be that not the best matching demuxer was used in the indexing step. You may try to select a specific other demuxer.

Unfortunately none of those improved matters.

But as already documented in the FFMS2 AviSynth documentation, FFMS2 simply is not reliable with MPEG TS sources, even when Haali's Media Splitter is installed and used during indexing.

Sadly my experience seems simply to prove that. I've had identical results (using these inputs) also with FFMS2 C-plugin r809+35, unfortunately.

Thanks for your inputs.

[Selur]

As a side note: LWLibavVideoSource might be also worth a try. (Personally I prefer DGs tools for transportstreams.)

[turbojet]

I've had no luck with ffms2 and ts files.

lwlibavvideosource works great for ts files, it's also very fast compared to the others especially if dr=true (but remember to crop if video padded to mod16).

If you plan on using DSS2 for ts files, best to use dss2mod (https://code.google.com/p/xvid4psp/downloads/detail?name=DSS2%20mod%20%2B%20LAVFilters.7z&can=2&q=) and set lookahead to 100+. It's a self contained dll that doesn't rely on haali.

[fvisagie]

I'm having trouble with output from my Canon HF G30. Frames are skipped, returned out of sequence and/or the total frame count seems wrong.

But using L-SMASH Source may be a more reliable alternative here.

In my testing so far LWLibavVideoSource() works perfectly. On the original M2TS files, without any remuxing or other preparation being required :).

What I find puzzling, though, from LWLibavVideoSource()'s README:
* This function uses libavcodec as video decoder and libavformat as demuxer.
- isn't libav being blamed for FFMS2's problems with MPEG PS/TS?

I've had no luck with ffms2 and ts files.

lwlibavvideosource works great for ts files, it's also very fast compared to the others especially if dr=true (but remember to crop if video padded to mod16).

If you plan on using DSS2 for ts files, best to use dss2mod (https://code.google.com/p/xvid4psp/downloads/detail?name=DSS2%20mod%20%2B%20LAVFilters.7z&can=2&q=) and set lookahead to 100+. It's a self contained dll that doesn't rely on haali.

That's useful input, thanks. I'll look into dr=true and dss2mod also.

[LigH]

The libav libraries have their forks too, and have been developed further ... probably in different ways in different projects. I am not the one with the insight in both FFMS2 and L-SMASH sources. Someone who has may explain where the difference is. But obviously in or close to the MPEG TS splitters used in either.

[lansing]

I'm trying to test ffms2 in both vapoursynth 32bit and 64bit version and ran into problem. Every time I load the same script and switch from virtualdub 32bit and 64bit, it will create a new index file overwriting the old one, and the size of the index files are different. Shouldn't the index be universal among 32bit and 64bit?

[Myrsloik]

I'm trying to test ffms2 in both vapoursynth 32bit and 64bit version and ran into problem. Every time I load the same script and switch from virtualdub 32bit and 64bit, it will create a new index file overwriting the old one, and the size of the index files are different. Shouldn't the index be universal among 32bit and 64bit?

In an ideal world it should. However the index is more or less a dump of internal memory structures so it isn't. Nobody's bothered to try to unify the mess.

[lansing]

In an ideal world it should. However the index is more or less a dump of internal memory structures so it isn't. Nobody's bothered to try to unify the mess.

or at least add a dot extension to differentiate the two, like abc.mkv.32bit.ffindex and abc.mkv.64bit.ffindex, and the filter will know which one to look for onload, so that the index file won't be replacing itself when we switch from 32bit to 64bit program.

[fvisagie]

or at least add a dot extension to differentiate the two, like abc.mkv.32bit.ffindex and abc.mkv.64bit.ffindex

You're probably aware of this, but if you're prepared to script separately for 32 and 64-bit, you can do that yourself. Default parameter value for FFIndex(), FFVideoSource() & FFAudioSource():

string cachefile = source + ".ffindex"

[lansing]

You're probably aware of this, but if you're prepared to script separately for 32 and 64-bit, you can do that yourself. Default parameter value for FFIndex(), FFVideoSource() & FFAudioSource():

string cachefile = source + ".ffindex"


that will lose the point of auto detect and one script for both version.

[icezellion]

As a side note: LWLibavVideoSource might be also worth a try. (Personally I prefer DGs tools for transportstreams.)

DGAVCDec completely fails on particular AVC transport streams. In this case, FFVideoSource works perfectly. For MPEG-2 transport streams I still use DGMPGDec though. Haven't bothered to use anything else since it still seems to do the job (I don't have a Nvidia GPU). I'm always open to trying other source filters as long as they process transport streams properly, and provide some additional benefit.

[LigH]

DGAVCDec is outdated anyway, using an obsolete version of libavcodec which did not even support PAFF interlacing yet (it was just one of the few frame-accurate versions cooperating with the DG*Dec framework).

Selur rather refers to current hardware accellerated tools like DGDecNV/IM. But yes, they require specific video decoder chips (Nvidia / intel Core i). "L-SMASH Works" does not, and is very reliable too (more than FFMS2, even with Haali support, regarding TransportStreams). And in addition, there is a DSS2Mod filter which can also use a local copy of LAV Filters natively (it doesn't need to be installed as DirectShow filters).

The alternative, to use FFMS2 rather reliably, is to multiplex TS to MKV using mkvmerge.

[qyot27]

FFMS2 C-plugin r827+36-avs+vsp

Optimized for Pentium-III and SSE.

FFmpeg r61474 git-d1bb179, built on Mar 14 2014 22:33:23 with gcc 4.8.2 (GCC):
configuration:
--prefix=/home/qyot27/win32_build
--cross-prefix=i686-w64-mingw32-
--disable-doc
--enable-gpl
--enable-version3
--disable-w32threads
--enable-avresample
--enable-libopus
--disable-decoder=utvideo
--enable-libutvideo
--disable-encoders
--disable-muxers
--disable-doc
--disable-debug
--disable-network
--disable-hwaccels
--disable-indevs
--disable-outdevs
--cpu=pentium3
--extra-cflags='-mfpmath=sse -march=pentium3 -msse -mtune=pentium3 -DPTW32_STATIC_LIB'
--target-os=mingw32
--arch=x86

EDIT 2014-05-22: Updated build here. (http://forum.doom9.org/showthread.php?p=1681399#post1681399)

[LigH]

:thanks:

Here an excerpt from the changelog since v2.18:

2.20

Add support for Opus in MKV when ffmpeg/libav are built with libopus (qyot27)
vapoursource: Provide _AbsoluteTime metadata (Daemon404)
Fix a pile of small things found by Coverity (Daemon404)
Add support for HEVC in MKV (qyot27)
Fix infinite loop on garbage data at the beginning of AAC files (Plorkyeran)
Deal with the never-ending bitrot from FFmpeg/Libav API changes (Daemon404, Plorkyeran)
Make indexes not arch-specific and trivially smaller (Plorkyeran)

[icezellion]

Thanks :) Is it possible for me to provide FFMS2 developers a 60 second H264 TS file (from Sky HD)? I haven't had any issues so far, and I think the issue is likely due to where the file was trimmed at with VideoReDo. Basically at the start of the encoded result, the video pauses for perhaps a second or two, but aside that everything else is perfect. I am doubtful it's a FFMS2 issue though, since all the other recordings from have been more or less perfect (and more of an issue where it was cut at).

[Taurus]

@qyot27
:thanks: for sharing

[Boulder]

I just get a "Unable to load C Plugin" error with that one :( ffms2.dll is in the Avisynth plugins folder along with the ffms2.avsi script.

[LigH]

Is your 7-zip outdated (older than version 9.20)? It seems to happen often for different people who use a 3rd-party unpacker which uses a 7-zip DLL from a stable but obsolete version. Since Version 9.20 beta, 7-zip prefers an improved LZMA2 algorithm for multithreading, which can't be unpacked reliably with older versions, but they are not able to detect the difference.