FFmpegSource

[stax76]

Thanks for the update Myrsloik, I tested various things with 3 files, with one sample there is a async problem, it is a DVB capture muxed to mkv with dsmux, some info in case you have time and interest:

http://www.mediafire.com/watch/y4biquprdehg3vm/async.mkv

source filter which name I forgot: freeze, FAILURE
FFVideoSource: async
LWLibavVideoSource: OK
DSS: async

I posted the original TS file lately to the AviSynth+ thread:

http://forum.doom9.org/showthread.php?p=1723364#post1723364

here is some technical info:

http://forum.doom9.org/showthread.php?p=1723382#post1723382

It was explained there are different ways to handle things, a possible solution to achieve compatibility between tools and workflows might be agreeing to the same approach.

[videoh]

FFVideoSource: async
LWLibavVideoSource: OK
Have you, or can you, compare the video output of these two frame-by-frame to determine if FFVideoSource is including or excluding extra frames at the start compared to LWLibavSource? And is the async constant or does it grow as the stream plays?

[manolito]

@stax76

FWIW I downloaded your async.mkv (it was packed into an FLV container), I also repacked your original .TS file into an MKV container using MKVMerge, and for all these source files the result was consistent:

Use DSS2Mod together with LAVFilters, ignore audio delays reported by MediaInfo if they are > 100ms, and get a result without any audio sync issues.

I tested it using AVStoDVD for MPEG2 output and also the old StaxRip version 1.1.9.0 for XviD and AVC output.


Cheers
manolito

[stax76]

@stax76

FWIW I downloaded your async.mkv (it was packed into an FLV container), I also repacked your original .TS file into an MKV container using MKVMerge, and for all these source files the result was consistent:

Use DSS2Mod together with LAVFilters, ignore audio delays reported by MediaInfo if they are > 100ms, and get a result without any audio sync issues.

I tested it using AVStoDVD for MPEG2 output and also the old StaxRip version 1.1.9.0 for XviD and AVC output.


Cheers
manolito

Don't forget that DVB often has ads and errors, there could be various cut/trim points to remove ads. I had av sync problems with mkvmerge and DSS. I need something 100% reliable with cutting with possibility to retain original audio format.

[videoh]

Any chance of an answer to my query, stax76?

[stax76]

Any chance of an answer to my query, stax76?

Comparing lsmash against ffms2 frame 77 is the same in the StaxRip preview and the frame count is also the same in the StaxRip preview, when I encode it's very surprising that lsmash is fine and ffms2 is not, this could be the issue a StaxRip user reported recently, I have no idea what's going on!

edit: 2.20 is fine

[stax76]

2.20 is sync, 2.21 is async, this must be the issue two StaxRip users reported:

Using the new 1.3.1.3 beta, I am getting 7 frames (300ms) of blank video added to the beginning of encoded videos causing audio sync issues. Actually the framecount stays correct (it cuts 300ms at the end), so the problem is more that the video is offset by 300ms. So far I have only had a chance to check this with an AVC source. The problem does not appear when previewing, only in the final encodes and happens regardless of output (1-pass/2-pass, Xvid/x264, AVI/MKV, AC3/MP3/None).

The problem appears to be with the ffms2 indexer that was updated. If I replace the /Apps/Plugins/ffms2 directory with the version that came with 1.3.1.0, there is no delay.

ETA: Just compared encodes from an MPEG-2 (DVD) source:
1.1.9.0 = 0 extra frames
1.3.1.0 = 0 extra frames
1.3.1.3 = 2 extra frames

[videoh]

Comparing lsmash against ffms2 frame 77 is the same in the StaxRip preview and the frame count is also the same in the StaxRip preview, when I encode it's very surprising that lsmash is fine and ffms2 is not, this could be the issue a StaxRip user reported recently, I have no idea what's going on!

edit: 2.20 is fine Thanks. It sure seems that ffms2 has a regression of some sort. Surely Myrsloik will look into it and we just need a little patience. Or you could diff the source code for the two versions to see what might have caused it.

[stax76]

Thanks. It sure seems that ffms2 has a regression of some sort. Surely Myrsloik will look into it and we just need a little patience. Or you could diff the source code for the two versions to see what might have caused it.

I hope it's easy to fix, here is another finding:

Thanks again for all the detailed responses.

I've been playing around with it. The encode speeds I get with threads=1 (that seems to be the main speed bottleneck) are really a lot slower than without. I tried it both ways with very low crf settings (like crf 25-26 and preset fast) and low resolution (1920x1080-->720x404), just to compare. Roughly 1/5 the speed (might be less depending on cpu).

Another thing I did, is try the new ffms 2.2.1 on 2 movies (neither seem to have null frames following the test you suggested) and both came out out of sync when I didn't use threads=1. Then switched back to 2.2.0, no issues there.

Maybe I'm doing something wrong, I don't know..

[videoh]

Just keep using 2.2.0 until something happens. Did you submit a trouble ticket?

[stax76]

Not yet, do you think it should be done?

[Myrsloik]

So depending on how you open a file (most likely how you seek in it) you get different frames back? Or is it just that there's a different number of frames reported?

[stax76]

So depending on how you open a file (most likely how you seek in it) you get different frames back?

Yes I think you can get different frames back, in the StaxRip preview there was no difference between ffms2 and lsmash but when encoding the result was completely async with ffms2

there are some findings in the MeGUI thread:

http://forum.doom9.org/showthread.php?p=1723473#post1723473

[Selur]

as a side note: I experience the same thing when using ffmpegsource2 with avi input (with b-frames) during encoding with x264; preview doesn't show duplicates, encode des.

[videoh]

2.2.1 uses a newer FFMPEG. Maybe the problem comes from that. Possibly you guys can test that directly as well.

[Reel.Deel]

I'm back with what I guess is kinda 2.22 rc1 (https://www.dropbox.com/s/wd2n9ivune4qd1t/ffms2-avs26test1.7z?dl=1).

So what needs to be tested is that the functions FFmpegSource2, FFImageSource and FFCopyrightInfringement still work as expected. They're now integrated into the plugin for convenience reasons (normal users will no logner need to fidget with ffms2.avsi). Don't forget to replace ffms2.avsi or you may get unexpected results.

If someone has the patience to test all the arguments for FFmpegSource2 and FFImageSource that'd be great. I may have made a typo somewhere.


There's something funky going on with FFImageSource. I tried loading a tif file and I got this error: FFVideoSource: Codec returned zero size video. Tried with a png and got this: FFVideoSource: No video track found. But it does work with a jpeg file and if I revert back to v2.21 all is well again.

[Myrsloik]

There's something funky going on with FFImageSource. I tried loading a tif file and I got this error: FFVideoSource: Codec returned zero size video. Tried with a png and got this: FFVideoSource: No video track found. But it does work with a jpeg file and if I revert back to v2.21 all is well again.

That's odd. You shouldn't be getting that kind of errors with my changes. Maybe it's because I used libav for my test builds but ffmpeg is used for the release.

[18fps]

The FFImageSource module works with a sequence of images (0000.tif,0001.tif,0002.tif, etc.) ?

[Myrsloik]

The FFImageSource module works with a sequence of images (0000.tif,0001.tif,0002.tif, etc.) ?

No, use a real image source plugin for that.

[Myrsloik]

New test version (32bit only) (https://www.dropbox.com/s/7sikruow5ych9u7/ffms2-seekbugfixtest1.7z?dl=1). This one should correct the weird behavior around the first frames introduced in 2.21.

Because some code was moved around to fix another bug ffms2 would in most cases think it was on frame 1 instead of frame 0 until a seek was triggered.

Report your findings.

[sneaker_ger]

Beginning repeats, sample with positive video delay:
https://mega.co.nz/#!w412mAzJ!sV2LwE_XDtRyoawRJgS-3OAiBx2qws7y-0pinrSqhfg

[Myrsloik]

Beginning repeats, sample with positive video delay:
https://mega.co.nz/#!w412mAzJ!sV2LwE_XDtRyoawRJgS-3OAiBx2qws7y-0pinrSqhfg

Is that really a bug relative to 2.20? The important thing is that my test version matches 2.20 even if it doesn't work completely with your samples.

[sneaker_ger]

I don't know what exactly you're asking me. I think it's a regression somewhere between May 2nd ("ffms2-test3.7z") (a.pomf.se/wovqof.7z) and 2.21 final.

2.20 stable: async (https://github.com/FFMS/ffms2/issues/174)
2nd May ("ffms2-test3"): perfect
2.21 stable: sync but beginning repeats
ffms2-seekbugfixtest1: same as 2.21 stable

I'd need to look deeper but the results would indicate that 2nd May cut the audio correctly while 2.21+ seem to repeat video instead of cutting audio?

[Myrsloik]

I don't know what exactly you're asking me. I think it's a regression somewhere between May 2nd ("ffms2-test3.7z") (a.pomf.se/wovqof.7z) and 2.21 final.

2.20 stable: async (https://github.com/FFMS/ffms2/issues/174)
2nd May ("ffms2-test3"): perfect
2.21 stable: sync but beginning repeats
ffms2-seekbugfixtest1: same as 2.21 stable

I'd need to look deeper but the results would indicate that 2nd May cut the audio correctly while 2.21+ seem to repeat video instead of cutting audio?

That's very odd, I never touched any delay handling code in my changes and it very obviously did work for a brief moment. BUT!

This isn't the bug I was trying to fix with my latest build. Instead it was a possible one frame off issue in the beginning of video only.

[Patman]

Hello myrsloik,

Is it possible to create a 64 bit version? I want to test it with staxrip x64.

[Myrsloik]

Here's yet another test build (https://www.dropbox.com/s/eneprw5kfw7s5wk/ffms2-delaytest1.7z?dl=1). Let's call it kinda 2.22 rc2.

It should fix the weird video repeat at the start with delayed video. And some other issues related to it that were a lot less obvious.

[Selur]

Small question: is there an option to output 10bit output for 10bit input when using FFVideoSource (with Avisynth not Vapoursynth) or does FFVideoSource always output 8bit video?

[Myrsloik]

Small question: is there an option to output 10bit output for 10bit input when using FFVideoSource (with Avisynth not Vapoursynth) or does FFVideoSource always output 8bit video?

It's always 8 bit. 2.22 will be the first version to even support all the new avisynth 2.6 formats for output.

Stacked output could be added fairly easily but none of us (the glorious developer collective) like hacks or use avisynth much anymore. I'd rather see avs+ add real support for it.

Feel free to produce your own special versions with support for it added. I think someone used to do that earlier too.

[Selur]

Thanks for the info. :)

[Reel.Deel]

I think someone used to do that earlier too.

The patched FFMS2 (http://avisynth.nl/index.php/High_bit-depth_Support_with_Avisynth#FFMS2) is still around, not too terribly outdated either. Not sure if it handles bit depths greater than 10 correctly though.

[Patman]

Here's yet another test build (https://www.dropbox.com/s/eneprw5kfw7s5wk/ffms2-delaytest1.7z?dl=1). Let's call it kinda 2.22 rc2.

It should fix the weird video repeat at the start with delayed video. And some other issues related to it that were a lot less obvious.

Hi Myrsloik,

your latest version of ffms2 works very well for me. Since i've updated to version 2.22 rc2 there is no audio delay in final encoded files. Great work!

[stax76]

2.22 rc2 works fine, delay issue is fixed. :thanks:

[fvisagie]

Here's yet another test build (https://www.dropbox.com/s/eneprw5kfw7s5wk/ffms2-delaytest1.7z?dl=1). Let's call it kinda 2.22 rc2.

It should fix the weird video repeat at the start with delayed video. And some other issues related to it that were a lot less obvious.

This addresses some of the AVCHD frame counting and sequencing issues I reported here (http://forum.doom9.org/showthread.php?p=1664848#post1664848). Both MP4 and MKV remuxes of AVCHD M2TS now decode fine. In fact, Subtract() shows zero difference between any FFMS2 or LWLibavVideoSource() decode of either MP4 or MKV (or also the original MTS in the case of LWLibavVideoSource()). The original AVCHD MTS still does not decode correctly in FFMS2.

The latest FFMS2 C-plugin on this thread shows the same behaviour.

In case you'd like to look into this a little further, here's (http://www.mediafire.com/download/7tb6q0kmyk3uj2h/AVCHD.MTS) a short AVCHD M2TS sample.

[Myrsloik]

This addresses some of the AVCHD frame counting and sequencing issues I reported here (http://forum.doom9.org/showthread.php?p=1664848#post1664848). Both MP4 and MKV remuxes of AVCHD M2TS now decode fine. In fact, Subtract() shows zero difference between any FFMS2 or LWLibavVideoSource() decode of either MP4 or MKV (or also the original MTS in the case of LWLibavVideoSource()). The original AVCHD MTS still does not decode correctly in FFMS2.

The latest FFMS2 C-plugin on this thread shows the same behaviour.

In case you'd like to look into this a little further, here's (http://www.mediafire.com/download/7tb6q0kmyk3uj2h/AVCHD.MTS) a short AVCHD M2TS sample.

I looked at it and it's just weird in general. No idea what to do about it. If remuxing makes it work I probably won't invest more time in it.

[Boulder]

I cannot get the latest test version working, indexing goes fine but using FFVideoSource with SEt's latest Avisynth MT build throws an access violation when opening the script in VirtualDub. I'm on Win7 64-bit.

EDIT: files encoded with FFV1.

[Myrsloik]

I cannot get the latest test version working, indexing goes fine but using FFVideoSource with SEt's latest Avisynth MT build throws an access violation when opening the script in VirtualDub. I'm on Win7 64-bit.

Avisynth mt isn't supported. Especially not if it works with other Avisynth versions.

[Boulder]

I did a quick test on the official Avisynth 2.6.0 and it's a no-go as well.

Here's a sample: https://drive.google.com/file/d/0BzeF_1syecQwV0xQQkg4ZHRhRzA/view?usp=sharing

[Myrsloik]

I did a quick test on the official Avisynth 2.6.0 and it's a no-go as well.

Here's a sample: https://drive.google.com/file/d/0BzeF_1syecQwV0xQQkg4ZHRhRzA/view?usp=sharing

Looks like an issue with the file or FFV1 decoding. Does it work in 2.21?

[Boulder]

Yes, no errors with that one (the ICL build).

[qyot27]

FFMS2 C-plugin r1050+87

Optimized for Pentium-III and SSE.

ffmpeg version r73159 git-803bdc5 Copyright (c) 2000-2015 the FFmpeg developers
built with gcc 5.1.0 (GCC)
libavutil 54. 27.100 / 54. 27.100
libavcodec 56. 45.100 / 56. 45.100
libavformat 56. 38.102 / 56. 38.102
libavfilter 5. 18.100 / 5. 18.100
libavresample 2. 1. 0 / 2. 1. 0
libswscale 3. 1.101 / 3. 1.101
libswresample 1. 2.100 / 1. 2.100
libpostproc 53. 3.100 / 53. 3.100

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

FFMS2.avsi is still needed in order to provide FFmpegSource2 and FFImageSource wrapping functions for the C-plugin, as the porting for those has to be done separately from the master branch due to the difference in language. I have no ETA on when that might happen.

EDIT 2015-09-15: Newer build available here. (http://forum.doom9.org/showthread.php?p=1739037#post1739037)

[LigH]

Complaint in the German doom9/Gleitz board (http://forum.gleitz.info/showthread.php?47282-Avisynth-mit-Virtualdub-kann-MTS-Datei-nicht-einlesen&p=451536&viewfull=1#post451536): Navigating in a script with an MTS file loaded, using FFMS2 (release 2.21) and trims and fades and subtitles, tend to get async, can take a lot of time in VirtualDub, even make it unresponsive. There is a suspicion that PGS subtitles might cause it. But it will be investigated further...

[stax76]

Isn't there a rffmode parameter using VapourSynth, google found a vapoursynth.cpp file where I can see a parameter called rffmode but when I try to use it the runtime says there is no such parameter.

[Myrsloik]

Isn't there a rffmode parameter using VapourSynth, google found a vapoursynth.cpp file where I can see a parameter called rffmode but when I try to use it the runtime says there is no such parameter.

It's only a bit of leftover code from the avisynth side. There's no actual implementation of it. It could be added but zero interested developers...

[sofakng]

I'm trying to use the latest version of FFmpegSource2, but when I try to load AVI or WMV files it crashes. However, MP4 files work perfectly.

Is this a known issue?

[Myrsloik]

I'm trying to use the latest version of FFmpegSource2, but when I try to load AVI or WMV files it crashes. However, MP4 files work perfectly.

Is this a known issue?

Define "latest version"and post samples of the crashing files if you want anyone to care

[hello_hello]

ffms2 doesn't seem to be happy with indexing AVI audio when the audio stream contains non-audio data, which I understand some muxing programs use instead of an audio delay.

I'm pretty sure it's a "junk data" problem as I have an AVI with a 16ms audio delay (according to MediaInfo) and when I remux it with MKVMergeGUI it complains about the junk data, removes it and applies an appropriate delay instead. ffms2 won't index the MP3 audio in that AVI. The error message is:

FFAudioSource: The audio track contains no audio frames.

I'm using (according to MeGUI) version 2.22 RC2, but ffms2 has refused to index such audio for as long as I can remember.

[shinchiro]

Any idea when 2.22 will officially released? I tried using v2.21 but unfortunately it has sync problem with the subtitle

[Myrsloik]

Any idea when 2.22 will officially released? I tried using v2.21 but unfortunately it has sync problem with the subtitle

It's basically done. Just need to prod Plorkyeran into making the release compiles. My RC2 build is about as good as it will get if you need the fixes sooner.

[dipje]

Loving that the 'delaytest1' version (2.22 RC2?) fixes the MTS / AVCHD weird stream offset reading that got introduced with 2.21.
, P
But I hit another regression it seems from 2.21 to this delaytest1 version (or I'm doing something wrong). It seems reading Prores files (doesn't really matter which variant) results in crashes. Vapoursynth x64 (R27, Pyhton34), Win 8.1 x64.

Using 2.21 (ICL or msvc) works. This script is readable by Virtualdub:
import vapoursynth as vs
core = vs.get_core()

c = core.ffms2.Source(source = r'prores-hq-test.mov')

c.set_output()
enable_v210 = True

Removing the .ffindex file, replacing ffms2.dll and ffmsindex.exe with the ones from 'ffms2-delaytest1' and opening the script crashes Virtualdub. "Out-of-bounds memory access (access violation) occurred in module 'veedub64'.
But also 'vspipe -p prores-hq-test.vpy nul:' crashes from the commandline (in Vspipe.exe). Deleting the .ffindex file and returning to 2.21-icl or 2.21-msvc fixes the problem.
The file used in this case was a 23mb 1 second full-hd clip of film-noise, https://www.sendspace.com/file/85ako4

Another Prores file (Prores 444) downloaded from the ARRI sample site (490mb, ftp://ftp-footage.arri.de/02a_ProRes_16-9_1920x1080/25fps/, the first one in this case. Username 'ALEXA' password 'samplefootage' as listed publicly on this site: http://www.arri.com/camera/alexa/learn/alexa_sample_footage/).
This is a Prores 444 file, so it gives YUV444P10. Using the same script as before (but changing the filename of course) and trying to test it with vspipe results in another vspipe.exe crash.

Feeding the exact same script into Virtualdub gives the expected "VFW module doesn't support YUV444P10 output" error message.
Turning the script into this:
import vapoursynth as vs
core = vs.get_core()

c = core.ffms2.Source(source = r'J001C013_140110_R6MS.mov')
c = core.fmtc.resample(c, css = '422')
c = core.fmtc.bitdepth(c, bits = 10, dmode = 3)

c.set_output()
enable_v210 = True

to turn the YUV444P10 into YUV422P10 results in both vspipe.exe and Virtualdub crashing. Once again, reverting back to 2.21 ICL or MSVC fixes the problem.


I (just) downloaded the latest Zeranoe FFmpeg Build Version: git-0671dc5 (2015-07-22), 64bit static.
I tried a simple 'ffmpeg -i <inputfile.mov> -vcodec dpx outputtest-%04d.dpx' on both the Prores quicktime files and they both converted OK, making me think (the latest) ffmpeg is still able to process Profiles ok.
Also, L-Smashworks I have installed (L-SMASH-Works-r785-20150629-64bit) with 'core.lsmas.LWLibavSource' opens the files fine. So LibAV seems to open Prores files still, or am I wrong in these assumptions somewhere? :P.

Anyway, for now I don't really have a problem with it all since I can use L-Smashworks for opening my MTS / AVCHD files and then use ffms2 2.21 for the rest of the Prores workflow, but it would be a shame if this would 'stay in' this and future versions limiting me to stay on 2.21 :(.

[Kein]

Any idea what can cause absolutely insane frameskipping and thus desync with FFMS (both "live" and in final render)? AviSource works fine, but if I use FFMS to open recorded AVI it behaves weirdly slow and inconsistent (after the index build).