FFmpegSource

[Myrsloik]

Doh. Made a mistake in ffmsindex and avisynth ffindex that would make it unflag video tracks for indexing in many cases. Here's a fixed build:

test2 (https://www.dropbox.com/s/daax9g9y5ydv2s2/ffms2-test2.7z?dl=1)

[stax76]

I tested 3-4 different source types, measured memory consumption, CPU usage and performance with AVSMeter against L-Smash, awesome work, perfect candidate to replace 2.20. :thanks:

[Myrsloik]

Here's test3 (https://www.dropbox.com/s/7pq2zwpwgtdved8/ffms2-test3.7z?dl=1).

The main noticable change is the framerate "correction". It should now more reliably pick common framerates if the input is close to one.

Previously it would "correct" framerates to 30001/1001, 25020/1001 or worse.

Test it and report your findings.

[Myrsloik]

I want to remove the SWScale() function from avisynth since swscale is so horrible in general and doesn't really add anything compared to already existing resizers.

Objections?

[stax76]

Thanks for the new build. Two PAL samples were ffms2 don't use 25 or 50:

https://www.dropbox.com/s/v6urrdq6ihid1k6/ffms2%20erkennt%20falsche%20fps.ts?dl=0

https://www.dropbox.com/s/j5bwk0u2055fhjp/SD%20-%20anamorphic.mpg?dl=0

[Myrsloik]

Thanks for the new build. Two PAL samples were ffms2 don't use 25 or 50:

https://www.dropbox.com/s/v6urrdq6ihid1k6/ffms2%20erkennt%20falsche%20fps.ts?dl=0

https://www.dropbox.com/s/j5bwk0u2055fhjp/SD%20-%20anamorphic.mpg?dl=0

The 50fps one is exactly 50fps and not changed at all. So that one works for me. No idea what you're getting for that one.

The other one is too far off from 25fps. ~24.9495 fps to be exact. Actually 25000/1001 (24.9750) is quite far off too, seen as a percentage. The current code will only adjust the framerate if it's within 0.05%. This small interval is needed since the difference between 25 and 25000/1001fps is only 0.1% and would otherwise cause more trouble than it solves.

The reason it's done at all is mostly to recover a normal fps from matroska files.

AssumeFPS() is your friend.

[stax76]

My understanding of frame rates and field processing, especially NTSC is basic at best. 30000/1001 and 24000/1001 are obviously NTSC but were does 25000/1001 come from?

The 50 fps sample is reported as 25 fps by MediaInfo! I tried to deinterlace it and use AssumeFPS but couldn't find a way to properly process it, only thing that helped was using fpsnum, fpsden arguments for FFVideoSource.

What StaxRip and I believe MeGUI too do is read the frame rate with MediaInfo and then use AssumeFPS. With the Ski sample this didn't work so I switched to use fpsnum and fpsden arguments in the latest StaxRip release.

[sneaker_ger]

The 50 fps sample is reported as 25 fps by MediaInfo! I tried to deinterlace it and use AssumeFPS but couldn't find a way to properly process it, only thing that helped was using fpsnum, fpsden arguments for FFVideoSource.
That can't be quite right. fpsnum/fpsden duplicates and/or deletes frames, it shouldn't help with deinterlacing.

The problem with the "SD - anamorphic.mpg" sample is probably initial delay. Delay makes an otherwise nice 25 fps cfr file into vfr with a peculiar average frame rate. Maybe delays should be handled differently? Does not really make sense to use them for the average fps calculation when we cannot map delays into AviSynth anyways (on account of being limited to cfr). :confused:

[stax76]

The ski sample is 50i right? MediaInfo reporting it as 25 fps should be a bug then.

[sneaker_ger]

It looks ok: frame rate 25, (implied) field rate 50

[stax76]

When I query the frame rate from AviSynth I get 50 fps from ffms2, something is wrong here, I've never seen a sample like this. How would a full script handling this properly look like?

[sneaker_ger]

Oh, you're right. ffms2 duplicates all frames for some reason. So fpsnum=25 (or similar like selecteven()/selectodd() or changefps()) might be valid after all

[Myrsloik]

Oh, you're right. ffms2 duplicates all frames for some reason. So fpsnum=25 (or similar like selecteven()/selectodd() or changefps()) might be valid after all

It's interlaced h.264. It's a known and annoying issue and even in FFmpeg it's handled differently (inexplicably doubled framerate and stuff).

[stax76]

Oh, you're right. ffms2 duplicates all frames for some reason. So fpsnum=25 (or similar like selecteven()/selectodd() or changefps()) might be valid after all

Ahh, now I understand what's wrong, maybe Myrsloik can fix it. I didn't know that fpsnum, fpsden mostly is about dropping frames so I'll go back to using AssumeFPS.

[Myrsloik]

Ahh, now I understand what's wrong, maybe Myrsloik can fix it. I didn't know that fpsnum, fpsden mostly is about dropping frames so I'll go back to using AssumeFPS.

Go annoy the FFmpeg developers until they begin to see common sense.

Not going to add a workaround unless money is involved. There may be some other TS issues lurking in that file too.

[stax76]

It's interlaced h.264. It's a known and annoying issue and even in FFmpeg it's handled differently (inexplicably doubled framerate and stuff).

l-smash-works fixes it, maybe workaround ffmpeg problem? Maybe ffmpeg could be fixed by reporting it?

[Myrsloik]

l-smash-works fixes it, maybe workaround ffmpeg problem? Maybe ffmpeg could be fixed by reporting it?

We (the union of disgruntled source filter writers of doom9) had a quick discussion about this. We all think FFmpeg sucks and that the behavior/API should be fixed in it.

Btw, interlaced fields is frame murder.

[stax76]

Thanks for investigating. I've done a small workaround, StaxRip includes 40 tools and plugins and since no software is perfect GUI authors constantly end up doing workarounds, I'm used to this. Most tools are pretty good, only mp4box sucks big time, I've every week a new problem with it, last week I discovered it's the only tool requiring VC++ 2010 runtime being present, not a big deal on it's own but after 20 more issues it starts to bother.

[LigH]

last week I discovered {mp4box is} the only tool requiring VC++ 2010 runtime being present

I believe jb_alvarado's media-autobuild_suite can compile MP4Box with GCC too. When it succeeds...

Well, that's not related to FFMS2. :o

No native AviSynth source plugin is perfect yet. Fortunately, we have a choice in many cases.

[RRD]

Hello,
When I use ffmsindex.exe -k on a 59.94 (60000/1001) fps .mkv file (MediaInfo 0.7.73 report (http://pastebin.com/VgxXG0Rt)), “fps 0” appears in the output (keyframe numbers are then listed properly). Why? Is this normal?


Other occurrences found with Google:
http://forum.doom9.org/showthread.php?p=1559483#1503
http://forum.selur.de/post7638.html#p7638
http://www.amara.org/en/videos/O0RyzUaR43Oe/ru/596359/
http://www.vidqt.com/id/leeIUjHh8aE?lang=ru
http://lj.blargh.info/mckf04.txt

[Myrsloik]

Hello,
When I use ffmsindex.exe -k on a 59.94 (60000/1001) fps .mkv file (MediaInfo 0.7.73 report (http://pastebin.com/VgxXG0Rt)), “fps 0” appears in the output (keyframe numbers are then listed properly). Why? Is this normal?


Other occurrences found with Google:
http://forum.doom9.org/showthread.php?p=1559483#1503
http://forum.selur.de/post7638.html#p7638
http://www.amara.org/en/videos/O0RyzUaR43Oe/ru/596359/
http://www.vidqt.com/id/leeIUjHh8aE?lang=ru
http://lj.blargh.info/mckf04.txt

It's normal. It always says 0 fps for some historical reason I can't remember. The notion of a keyframe list having a framerate is itself quite absurd.

[qyot27]

FFMS2 C-plugin r1015+85

Optimized for Pentium-III and SSE.

ffmpeg version r71895 git-0eec40b Copyright (c) 2000-2015 the FFmpeg developers
built with gcc 5.1.0 (GCC)
libavutil 54. 23.101 / 54. 23.101
libavcodec 56. 36.100 / 56. 36.100
libavformat 56. 31.102 / 56. 31.102
libavresample 2. 1. 0 / 2. 1. 0
libswscale 3. 1.101 / 3. 1.101
libswresample 1. 1.100 / 1. 1.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
--disable-filters
--disable-avfilter
--enable-avisynth
--cpu=pentium3
--extra-cflags='-mfpmath=sse -march=pentium3 -msse -mtune=pentium3'
--target-os=mingw32
--arch=x86

EDIT 2015-06-26: Newer build available here. (http://forum.doom9.org/showthread.php?p=1727818#post1727818)

[RRD]

It's normal. It always says 0 fps for some historical reason I can't remember. The notion of a keyframe list having a framerate is itself quite absurd.

OK, thanks. I am reassured.
The framerate mention may be there to allow easier timecode calculation for people who want to parse the .txt log that -k creates. As #1513 (http://forum.doom9.org/showthread.php?p=1559483#1513) mentioned, it would be nice to have a built-in function that displays both the keyframe numbers and the corresponding timecodes.
btw. would be nice to have something like -kc which would output the keyframe and the time belonging to it to an output file,.. ;)


Basically, integrating https://github.com/SAPikachu/VFRHelper (which uses FFMS2.dll for MKV, MP4 and FLV) for FFMS2's supported input formats.
(I cannot use VFRHelper 1.3.1 (2012-08-24) (http://www.sapikachu.net/vfrhelper/) on my .mkv file, it returns an error. :( Also, for some reason ffmsindex.exe manages to find keyframes 10 times faster than ffmpeg/ffprobe. )

[Myrsloik]

OK, thanks. I am reassured.
The framerate mention may be there to allow easier timecode calculation for people who want to parse the .txt log that -k creates. As #1513 (http://forum.doom9.org/showthread.php?p=1559483#1513) mentioned, it would be nice to have a built-in function that displays both the keyframe numbers and the corresponding timecodes.



Basically, integrating https://github.com/SAPikachu/VFRHelper (which uses FFMS2.dll for MKV, MP4 and FLV) for FFMS2's supported input formats.
(I cannot use VFRHelper 1.3.1 (2012-08-24) (http://www.sapikachu.net/vfrhelper/) on my .mkv file, it returns an error. :( Also, for some reason ffmsindex.exe manages to find keyframes 10 times faster than ffmpeg/ffprobe. )

Not going there. Maybe one day I'll add output of everything as text so you can parse it yourself.

[Myrsloik]

We're too lazy to improve ffinfo() so contributions would be appreciated. The changes we want are described in the issue below. Only average avisynth scripting skills needed. The values should obviously be displayed with the fancy names as text.

The issue is here:
https://github.com/FFMS/ffms2/issues/61

[StainlessS]

function FFColorSpace(int i) {
i=(i<0||i>10) ? 2 : i
return Select(i,"RGB","BT709 (ITU-R Rec.709)","Unspecified","Unspecified","FCC","BT470BG (ITU-R Rec.601)","SMPTE170M (ITU-R Rec.601)","SMPTE240M","YCOCG","BT2020_NCL","BT2020_NC")
}

function FFColorRange(int i) {
i=(i<0||i>2) ? 0 : i
return Select(i,"Unknown/Unspecified","Limited range (usually 16-235)","Full range (0-255)")
}

function FFCropping(int l,int t, int r,int b) {
return "Left="+String(l)+" Top="+String(t)+" Right="+String(r)+" Bottom="+String(b)
}

function FFSampAR(int num,int den) {
return String(num)+":"+String(den)+((num<=0 || den<=0)?"":string(Float(num)/den," (%.3f)"))
}

function FFPictType(int ch) {
s=chr(ch)
s = s + (
\ ch==73?" (Intra)":ch==80?" (Predicted)":ch==66?" (Bi-dir predicted)":ch==83?" (S(GMC)-VOP MPEG4)"
\ : ch==105?" (Switching Intra)":ch==112?" (Switching Predicted)":ch==98?" (FF_BI_TYPE [no good explanation available])"
\ : " (Unknown)")
return s
}

function FFInfo(clip c, bool "framenum", bool "frametype", bool "cfrtime", bool "vfrtime", string "varprefix",
\ bool "colorspace",bool "colorrange",bool "cropping",bool "sar",bool "version",bool "showprefix") {

framenum = default(framenum,true)
frametype = default(frametype,true)
cfrtime = default(cfrtime,true)
vfrtime = default(vfrtime,true)
varprefix = default(varprefix, FFVAR_PREFIX)
colorSpace = default(colorspace,true)
colorrange = default(colorrange,true)
cropping = default(cropping,true)
sar = default(sar,true)
version = default(version,true)
showprefix = default(showprefix,false)

c.frameevaluate("""
fftempstring = ""
varprefix = """" + varprefix + """"
""")

version ? frameevaluate("""fftempstring = fftempstring + "Version: " + FFGetVersion + "\n" """, after_frame=true) : nop()
framenum ? frameevaluate("""fftempstring = fftempstring + "Frame Number: " + string(current_frame) + " of " + string(framecount()) + "\n" """, after_frame=true) : nop()
# frametype ? frameevaluate("""fftempstring = fftempstring + "Picture Type: " + chr(eval(varprefix + "FFPICT_TYPE")) + "\n" """, after_frame=true) : nop()
frametype ? frameevaluate("""fftempstring = fftempstring + "Picture Type: " + FFPictType(eval(varprefix + "FFPICT_TYPE")) + "\n" """, after_frame=true) : nop()
cfrtime ? frameevaluate("""fftempstring = fftempstring + "CFR Time: " + FFFormatTime(round((current_frame * 1000) / framerate())) + "\n" """, after_frame=true) : nop()
vfrtime ? frameevaluate("""fftempstring = fftempstring + "VFR Time: " + FFFormatTime(eval(varprefix + "FFVFR_TIME")) + "\n" """, after_frame=true) : nop()
colorspace ? frameevaluate("""fftempstring = fftempstring + "ColorSpace: " + FFColorSpace(eval(varprefix + "FFCOLOR_SPACE")) + "\n" """, after_frame=true) : nop()
colorrange ? frameevaluate("""fftempstring = fftempstring + "Color Range: " + FFColorRange(eval(varprefix + "FFCOLOR_RANGE")) + "\n" """, after_frame=true) : nop()
cropping ? frameevaluate("""fftempstring = fftempstring + "Cropping: " + FFCropping(eval(varprefix + "FFCROP_LEFT"),eval(varprefix + "FFCROP_TOP"),eval(varprefix + "FFCROP_RIGHT"),eval(varprefix + "FFCROP_BOTTOM")) + "\n" """, after_frame=true) : nop()
sar ? frameevaluate("""fftempstring = fftempstring + "SAR: " + FFSampAR(eval(varprefix + "FFSAR_NUM"),eval(varprefix + "FFSAR_DEN")) + "\n" """, after_frame=true) : nop()
showprefix ? frameevaluate("""fftempstring = fftempstring + "Prefix: '" + varprefix + "'\n" """, after_frame=true) : nop()

return scriptclip("subtitle(fftempstring, lsp = 1)", after_frame=true)
}


UPDATED. Did not realize that varprefix could change with clip (I dont often use ffpegsource).
You might want to remove 'showprefix' stuff.
Alter as you will.

[StainlessS]

Myrsloik,
take another peek at previous post, not (I hope) quite a lousy as previous.
(incidentally I'm sitting in/on a chair too, FYI).

[Myrsloik]

Myrsloik,
take another peek at previous post, not (I hope) quite a lousy as previous.
(incidentally I'm sitting in/on a chair too, FYI).

Glorious work my chair based comrade! You efforts have now been merged with minimal changes.

[Myrsloik]

I am here to inform you of the glorious new 2.21 release. Go and update because it actually is a lot better than the previous one.

Those of you who still care about Avisynth and have minor coding skills may want to help with this small improvement (replace ffms2.avsi with real code):
https://github.com/FFMS/ffms2/issues/209

[filler56789]

I am here to inform you of the glorious new 2.21 release.

ありがとう、よっ。 Many :thanks:

[Sparktank]

I am here to inform you of the glorious new 2.21 release.

I saw the email update and was most pleased! :goodpost:
Thanks for the update.

http://i.imgur.com/bPRYtV0.png (http://imgur.com/bPRYtV0)

[stax76]

Thanks for the new version!

[LigH]

I don't always use FFMS2, but when I do I like using good versions.

imagines the beer drinking meme guy

[dipje]

.. The new 2.21 seems to make a mess ('behave differently') when opening my AVCHD files.

I always remuxed my .mts AVCHD files into .mkv with mkvtoolnix, and then opened the .mkv file with ffms2, and specifying the fpsnum / fpsden parameters. That was the way to get the video/audio sync OK in those files for me.

(The video + audio tracks don't always aline perfectly, my camera seems to start recording audio the moment you press record, but the video track starts less than a second later when the first pictures are actually coming in or something like that).

With the new 2.21 version, it seems to open OK, but after the first 20 frames or so (it varies file to file) it jumps back and the first 20 frames (or so) repeat.
If I try to open the .MTS file directly it creates garbage / artifacted frames around the 20 frames mark for a few frames and then it continues OK again. (Tested this only with Vapoursynth r27 x64 btw, but with both the 2.21-msvc and 2.21-icl x64 builds)

Reverting back to 2.20 fixes it.

[Myrsloik]

.. The new 2.21 seems to make a mess ('behave differently') when opening my AVCHD files.

I always remuxed my .mts AVCHD files into .mkv with mkvtoolnix, and then opened the .mkv file with ffms2, and specifying the fpsnum / fpsden parameters. That was the way to get the video/audio sync OK in those files for me.

(The video + audio tracks don't always aline perfectly, my camera seems to start recording audio the moment you press record, but the video track starts less than a second later when the first pictures are actually coming in or something like that).

With the new 2.21 version, it seems to open OK, but after the first 20 frames or so (it varies file to file) it jumps back and the first 20 frames (or so) repeat.
If I try to open the .MTS file directly it creates garbage / artifacted frames around the 20 frames mark for a few frames and then it continues OK again. (Tested this only with Vapoursynth r27 x64 btw, but with both the 2.21-msvc and 2.21-icl x64 builds)

Reverting back to 2.20 fixes it.

Always provide a sample if you want us to try debugging things.

[stax76]

I'm also interested in such a sample.

[dipje]

been a (long) time since I asked something here, what is the preferred method of sharing a sample? Got like a 6 second file, 16.4 mb. It's of my little son so I won't really like throwing it out there public, but to a few trusted devs is no problem.

If a shorter ok-to-go-public example is requested, I need to shoot a second or 3 with something to sync audio to tomorrow (it's night here now).

[mariner]

I am here to inform you of the glorious new 2.21 release. Go and update because it actually is a lot better than the previous one.

Those of you who still care about Avisynth and have minor coding skills may want to help with this small improvement (replace ffms2.avsi with real code):
https://github.com/FFMS/ffms2/issues/209

Greetings Myrsloik. Many thanks for sharing the update.

Would you also kindly advise if whatever lingering issues with interlaced contents and ts files have been resolved?

Many thanks and best regards.

[speedyrazor]

I would love to use this, but I open very large HD Quicktime movies (120GB) and indexing kills, taking way too long to even start working on the file. Is there a way to disable the indexing and cut the the chase?

[Myrsloik]

I would love to use this, but I open very large HD Quicktime movies (120GB) and indexing kills, taking way too long to even start working on the file. Is there a way to disable the indexing and cut the the chase?

Sure, just use something else to open files instead.

[LigH]

Indexing will be necessary to provide random access in an AviSynth script, using closest previous GOP starts before a seek point. This is quite important if you consider multithreading, where each thread may request a different frame number, and sequential access will be improbable.

FFMS2 will not rely on the possible existence of a keyframe index chunk because not all supported media formats will contain one, so it prefers to create an own index, but only once, it will be reused each time you access the same source file. You may disable writing the cache file to disk, but FFMS2 will still need to gather positions of decoding starts, so if you don't let it write a cache file, it will need to build an index in RAM each time you process the script.

If you want to rely on an index already present in a media file, rather use a different source filter which does so (in this case, maybe QTSource (http://forum.doom9.org/showthread.php?t=104293), which will require QuickTime to be installed).

Furthermore, QuickTime movies should belong to the "ISO Media" container family, so the LSMASHVideoSource() filter of L-SMASH Works may be recommendable as another alternative; it will usually write an own index cache file as well, though, but might do that faster.

[RTW47]

LSMASHVideoSource() filter of L-SMASH Works may be recommendable as another alternative; it will usually write an own index cache file as well, though, but might do that faster.
For lsmashvideosource() will the index always be stored inside ram, just like ffms2 with cache=false?

[LigH]

It may surprise you ... but L-SMASH Works contains a README file. :sly:

According to this one, there seems to be no cache file for the functions using the L-SMASH demultiplexer:

LSMASHVideoSource(string source, int track = 0, int threads = 0, int seek_mode = 0, int seek_threshold = 10,
bool dr = false, int fpsnum = 0, int fpsden = 1, bool stacked = false, string format = "")

In contrast to the functions using libavformat as demultiplexer:

LWLibavVideoSource(string source, int stream_index = -1, int threads = 0, bool cache = true,
int seek_mode = 0, int seek_threshold = 10, bool dr = false,
int fpsnum = 0, int fpsden = 1,
bool repeat = false, int dominance = 0, bool stacked = false, string format = "")

So it seems quite probable that LSMASHVideoSource() relies on media file internal index chunks. It will support only a few specific media formats, though: MP4, MOV, 3GPP

[foxyshadis]

It would be kind of nice if ffms could index on-demand for those huge files -- index up to the requested frame as frames are requested -- or in a background thread, but that means getting a developer interested, and so far no one seems to be. It would sure save time in those massive source situations.

[Myrsloik]

It would be kind of nice if ffms could index on-demand for those huge files -- index up to the requested frame as frames are requested -- or in a background thread, but that means getting a developer interested, and so far no one seems to be. It would sure save time in those massive source situations.

There's a huge problem with that idea. You don't know the framecount until it's too late to tell avisynth about it. That's why I never implemented it.

[mawen1250]

I've got wrong color when reading RGB24 image files (tested png and bmp) with ffms2.Source on VapourSynth.
Looks like the channels are swapped: BGR->GRB
The AviSynth's plugin works fine.

[Myrsloik]

I've got wrong color when reading RGB24 image files (tested png and bmp) with ffms2.Source on VapourSynth.
Looks like the channels are swapped: BGR->GRB
The AviSynth's plugin works fine.

Doh, I forgot abour that detail. Use shuffleplanes to work around it until a fixed version is available.

[RTW47]

you can use ShufflePlanes() to fix output

[Myrsloik]

Now it's fixed in git. I guess there'll be another release in a week or two.

[Myrsloik]

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.

- 2.22
- avisynth: Make FFMS2 a shorter alias for FFmpegSource2 to save some typing (Myrsloik)
- avisynth: Moved all source functions in ffms2.avsi into the actual plugin (Myrsloik)
- avisynth: Use 2.6 RC API and add output support for all new colorspaces (Myrsloik)
- vapoursource: Fix swapped RGB channels bug introduced in 2.21 (Myrsloik)

[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).

[Groucho2004]

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).
Post your (complete) script. Have you tried setting "threads" to 1?

[LigH]

Furthermore, it might be useful to have a MediaInfo analysis, to know which VfW codec was used to create the video stream inside the AVI.

[Kein]

Post your (complete) script. Have you tried setting "threads" to 1?


a=FFAudioSource("record.avi")
b=FFVideoSource("record.avi")
AudioDub(b, a).Trim(0,11367)


Furthermore, it might be useful to have a MediaInfo analysis, to know which VfW codec was used to create the video stream inside the AVI.

Format/Info : Audio Video Interleave
Format profile : OpenDML
File size : 22.1 GiB
Duration : 7mn 53s
Overall bit rate : 400 Mbps
Original source form/Distributed by : Video:YUV420|CompressV3 Audio:Speakers (VIA High Definition Audio)
Writing application : DxtoryCore ver2.0.0.127

Video
ID : 0
Format : xtor
Codec ID : xtor
Duration : 7mn 53s
Bit rate : 399 Mbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate : 30.000 fps
Bits/(Pixel*Frame) : 6.411
Stream size : 22.0 GiB (100%)

Audio
ID : 1
Format : PCM
Format settings, Endianness : Little
Format settings, Sign : Signed
Codec ID : 1
Duration : 7mn 53s
Bit rate mode : Constant
Bit rate : 1 536 Kbps
Channel(s) : 2 channels
Sampling rate : 48.0 KHz
Bit depth : 16 bits
Stream size : 86.7 MiB (0%)
Alignment : Aligned on interleaves
Interleave, duration : 100 ms (3.00 video frames)



AviSynth 2.6 release 32bit/ST, FFMS 2.21

[Groucho2004]

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).
I see you had trouble with this format before, have you tried a recent ffms2 build from qyot27?

[Kein]

Was there anything relevant to my issue?

[Groucho2004]

Was there anything relevant to my issue?
I don't know. It's almost always trial and error.
- Try a newer build
- Try "threads = 1"
- Try without the audio
- Upload a sample with which this can be reproduced

[real.finder]

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.

with .dv NTSC yv411 (4:1:1) say

http://i.imgur.com/wBSoJQ8.png

with c ver. by qyot27 work ok and output yv411

[LigH]

Does AviSynth offer a YUV 4:1:1 mode at all? I would expect it to have been upsampled to an available format (e.g. YUY2 or YV16 in YUV 4:2:2) when color space conversions are supported.

[jpsdr]

Yes, 2.6 support it.

[Myrsloik]

with .dv NTSC yv411 (4:1:1) say

http://i.imgur.com/wBSoJQ8.png

with c ver. by qyot27 work ok and output yv411

I want a small sample of that. Maybe it's some trivial bug or typo in the code.

[real.finder]

I want a small sample of that. Maybe it's some trivial bug or typo in the code.

this is avi section muxed from original .dv with avidemux http://samaup.com/a7o3lluxx2m6

[Kein]

- Try a newer build
- Try "threads = 1"
- Upload a sample with which this can be reproduced

1. It is the latest
2. non-MT version
3. Sure, examples:
RAW: https://yadi.sk/i/mLBfyGEMiTgBQ
AviSource: https://yadi.sk/i/p62ujJMFiTf5b
FFMPEG Source: https://yadi.sk/i/-6AGB76viTgBS

[fvisagie]

with .dv NTSC yv411 (4:1:1) say

http://i.imgur.com/wBSoJQ8.png

with c ver. by qyot27 work ok and output yv411

Bit of a medium shot, but it may be related to this (http://forum.doom9.org/showthread.php?p=1603682#post1603682).

[Groucho2004]

1. It is the latest
2. non-MT version
3. Sure, examples:
RAW: https://yadi.sk/i/mLBfyGEMiTgBQ
AviSource: https://yadi.sk/i/p62ujJMFiTf5b
FFMPEG Source: https://yadi.sk/i/-6AGB76viTgBS
The RAW sample is to big to download.
The "AviSource" is AVC wrapped in a .mp4 file
I can't guess what "FFMPEG Source" means.
So, I have no idea what any of these samples represent.

In order to reproduce something you have to provide the a sample of the source (ideally much smaller than 3GB) and the exact steps to reproduce the problem.

[LigH]

2. non-MT version

It doesn't matter if AviSynth is an MT version; some plugins fork threads on their own. For FFMS2, it can be necessary to limit this plugin specifically to only 1 decoder thread: If FFMS2 can handle an input file well, multiple decoder threads can speed up the decoding remarkably; but if FFMS2 may have issues with a format, multiple decoder threads make it even worse, and it gets completely confused.

[Myrsloik]

this is avi section muxed from original .dv with avidemux http://samaup.com/a7o3lluxx2m6

All unable to find suitable output format errors should now be fixed in git (at least the ones for formats new to avisynth 2.6). I simply forgot to add the last few lines of code needed.

[Kein]

The RAW sample is to big to download.
The "AviSource" is AVC wrapped in a .mp4 file
I can't guess what "FFMPEG Source" means.
So, I have no idea what any of these samples represent.
I'm not sure what so hard to understand:
AviSource is the sample encoded through AVS AviSource into AVC/MP4
FFMPEG Source is the sample encoded through AVS FFVideoSource/AudioSource/Dub into AVC/MP4 with the same (1:1) settings.

In order to reproduce something you have to provide the a sample of the source (ideally much smaller than 3GB) and the exact steps to reproduce the problem.
So, I did provide you a sample of the source, 2.4Gb (which is less than your suggested 3Gb) and you complained how big it is?
Are you replying to me for the sake of replying? I mean, I have a feeling you just keep up hollow discussion, why just not ignore my question then.

It doesn't matter if AviSynth is an MT version; some plugins fork threads on their own. For FFMS2, it can be necessary to limit this plugin specifically to only 1 decoder thread: If FFMS2 can handle an input file well, multiple decoder threads can speed up the decoding remarkably; but if FFMS2 may have issues with a format, multiple decoder threads make it even worse, and it gets completely confused.

i will try but doubt it will change much.

[LigH]

So, I did provide you a sample of the source, 2.4Gb (which is less than your suggested 3Gb) and you complained how big it is?

Not everyone has VDSL (and on top, many free file hosters throttle downloads to annoying speeds). Often it is still a pain and possibly a waste to download Gigabytes, especially if the effect may possibly appear with much smaller samples as well.

The FourCC "xtor" points at the DirectX capturing software DXtory; recording high resolutions without compression can be quite demanding for the harddisk, so I guess the reason might be dropped frames not being handled as well by FFMS2 as by AviSource.

[Groucho2004]

So, I did provide you a sample of the source, 2.4Gb (which is less than your suggested 3Gb) and you complained how big it is?
You're expecting me to download 2.4 G because you don't know how to cut a sample?

Are you replying to me for the sake of replying? I mean, I have a feeling you just keep up hollow discussion, why just not ignore my question then.
I have much better things to do than wasting time on discussions with a low signal to noise ratio and I just have lost interest in this one.

[AMED]

Hi,

I have a found a couple of samples that will encode correctly with FFMS2 v2.21 (also tested with v2.20 and v2.19) but fails with FFMS2 v2.22RC2. I'm using MeGUI and the samples do go through the indexing step but fail when it starts to encode. It seems to be related to them being MPEG2 (bluray rip via makemkv).

http://s24.postimg.org/ibjkaudat/Me_GUI_FFMS2.png

This is the error that MeGUI is showing when I try and encode with v2.22RC2
[Error] [18/08/2015 7:57:51 PM] Standard error stream
-[Information] [18/08/2015 7:57:52 PM] avs [info]: 1280x542p 0:0 @ 24000/1001 fps (cfr)
-[Information] [18/08/2015 7:57:52 PM] x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
-[Information] [18/08/2015 7:57:52 PM] x264 [info]: profile High, level 4.1
-[Error] [18/08/2015 7:57:52 PM] avs [error]: FFVideoSource: Frame accurate seeking is not possible in this file occurred while reading frame 0
-[Error] [18/08/2015 7:57:52 PM] avs [error]: FFVideoSource: Frame accurate seeking is not possible in this file occurred while reading frame 1

SAMPLE (http://www.mediafire.com/download/pxdww2kf137zuiz/SAMPLE.zip) (20MB)
SAMPLE2 (http://www.mediafire.com/download/djg6i2p8bk6lhuz/SAMPLE2.zip) (20MB)

[Kein]

You're expecting me to download 2.4 G because you don't know how to cut a sample?
It IS a 01:00 sample.


recording high resolutions without compression can be quite demanding for the harddisk, so I guess the reason might be dropped frames not being handled as well by FFMS2 as by AviSource.

Hmm, didn't think of that, altho, my HDD goes for 66-72MB/s so it should suffice in linear read for conversion.

[LigH]

Linear reading is not the problem; but what about writing during the recording, when Windows just even decides it must access the swap file urgently because the game being recorded allocates more RAM?

[Kein]

Linear reading is not the problem; but what about writing during the recording, when Windows just even decides it must access the swap file urgently because the game being recorded allocates more RAM?

Writing being done on another physical HDD. Swap is there too and it just 64Mb - I have 16Gb RAM and never hit limit during encoding.

[Myrsloik]

Here's 2.22 RC3 (https://dl.dropboxusercontent.com/u/73468194/ffms2-rc3.7z) or whatever.

Should fix the error when outputting to one of the new avisynth 2.6 formats.

Plorkyeran has also fixed some audio stuff.

Zzzzzzzzzzz...

[AMED]

I've just tested out v2.22RC3 with my sample and this is the error produced when trying to encode.

-[Error] [19/08/2015 10:51:36 a.m.] avs [error]: FFVideoSource: Frame accurate seeking is not possible in this file occurred while reading frame 2

It's seems that SMDegrain (http://forum.videohelp.com/threads/369142-Simple-MDegrain-Mod-v3-1-2d-A-Quality-Denoising-Solution) makes this error happen with FFMS v2.22+ and MPEG2 source.
LoadPlugin("D:\MeGUI\tools\ffms\ffms2.dll")
FFVideoSource("C:\Users\xxxxxx\Downloads\SAMPLE\SAMPLE.mkv", cachefile="C:\Users\xxxxxx\Downloads\SAMPLE\eecvorbg.ioq\SAMPLE.mkv.ffindex", fpsnum=24000, fpsden=1001, threads=1)
smdegrain()

[real.finder]

Here's 2.22 RC3 (https://dl.dropboxusercontent.com/u/73468194/ffms2-rc3.7z) or whatever.

Should fix the error when outputting to one of the new avisynth 2.6 formats.

Plorkyeran has also fixed some audio stuff.

Zzzzzzzzzzz...

now work with yv411 but with upside down green image

[Kein]

LigH
Yep, just confirmed - same issue with the videos recorded by ShadowPlay (NVENC)/OBS (x264).

[TsUNaMy WaVe]

I've got a mkv video. Somehow (with the ffinputdriver probably) VirtualDub opens it. But when I try to do it with AvsP it's just says "FFVideoSouce: Can't Open: "Sample.mkv"

Script:
LoadPlugin("C:\Program Files (x86)\AviSynth\plugins\ffms2.dll")
FFVideoSource("F:\Sample\Sample.mkv")

Video info:
General
Unique ID : 199069539360921106638242983202429760462 (0x95C366105ADFC63CAB333B7DFDAE73CE)
Complete name : F:\Sample\Sample.mkv
Format : Matroska
Format version : Version 4 / Version 2
File size : 1.22 GiB
Duration : 23mn 43s
Overall bit rate mode : Variable
Overall bit rate : 7 364 Kbps
Encoded date : UTC 2014-02-10 16:09:47
Writing application : mkvmerge v6.5.0 ('Isn't she lovely') built on Oct 20 2013 12:50:05
Writing library : libebml v1.3.0 + libmatroska v1.4.1

Video
ID : 3
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High 10@L5.1
Format settings, CABAC : Yes
Format settings, ReFrames : 14 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 23mn 43s
Nominal bit rate : 4 000 Kbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 10 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.080
Writing library : x264 core 132 r2323+704+51 d571b1c tMod [10-bit@4:2:0 X86]
Encoding settings : cabac=1 / ref=14 / deblock=1:-2:-2 / analyse=0x3:0x133 / me=umh / subme=10 / psy=1 / fade_compensate=0.00 / psy_rd=0.60:0.00 / mixed_ref=1 / me_range=24 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=18 / lookahead_threads=3 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / fgo=0 / bframes=8 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=500 / keyint_min=1 / scenecut=40 / intra_refresh=0 / rc=2pass / mbtree=0 / bitrate=4000 / ratetol=1.0 / qcomp=0.60 / qpmin=8 / qpmax=32 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / pb_ratio=1.30 / aq=4:0.80 / aq-sensitivity=10.00 / aq-factor=1.00:1.00:1.00 / aq2=0 / aq3=0
Default : Yes
Forced : No
Color range : Limited
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709

Audio
ID : 2
Format : FLAC
Format/Info : Free Lossless Audio Codec
Codec ID : A_FLAC
Duration : 23mn 43s
Bit rate mode : Variable
Channel(s) : 2 channels
Sampling rate : 48.0 KHz
Bit depth : 24 bits
Writing library : libFLAC 1.2.1 (UTC 2007-09-17)
Language : Japanese
Default : Yes
Forced : No

Text
ID : 1
Format : PGS
Muxing mode : zlib
Codec ID : S_HDMV/PGS
Codec ID/Info : Picture based subtitle format used on BDs/HD-DVDs
Default : Yes
Forced : No

Menu
00:00:00.000 : en:00:00:00.000
00:01:14.408 : en:00:01:14.408
00:02:45.040 : en:00:02:45.040
00:13:24.012 : en:00:13:24.012
00:21:32.208 : en:00:21:32.208
00:23:36.999 : en:00:23:36.999


Help?

[dipje]

-RC3 still has issues loading Prores files which worked before in 2.21 (stopped working from 'rc2', -delaytest). Kinda hoped the color-formats would have fixed it.

[Boulder]

Here's 2.22 RC3 (https://dl.dropboxusercontent.com/u/73468194/ffms2-rc3.7z) or whatever.

Should fix the error when outputting to one of the new avisynth 2.6 formats.

Plorkyeran has also fixed some audio stuff.

Zzzzzzzzzzz...This one doesn't work for me with my FFV1 files. It causes an access violation in Avisynth.dll when opening the video with FFVideoSource. Version 2.21 doesn't have this issue.

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

I'm confused - which is the recommended version to use that doesn't have the "off by one frame issue"?

[qyot27]

Even though I initially doubted it, it would appear the FFV1 issue (and it's not only FFV1; ffvhuff is also affected, at least) occurs due to colorspace issues.

I generated a test sequence with FFV1 using FFmpeg:
ffmpeg -f lavfi -i testsrc -vcodec ffv1 -t 10 test.avi
This video file caused the crash with FFMS2 (I'm testing the C plugin here, so chances are pretty high it's not in the plugin wrapper). By default, the testsrc outputs RGB.

However, if I force FFmpeg to write the file as 4:4:4,
ffmpeg -f lavfi -i testsrc -vcodec ffv1 -pix_fmt yuv444p -t 10 test.avi
It no longer crashes.

The results:
YV12/yuv420p = crash
YUY2/yuyv422 = [FFV1 doesn't support YUY2, it gets converted to standard 4:2:2, see below]
RGB24/bgr0 = crash
RGB32/bgra = works
YV16/yuv422p = works
YV24/yuv444p = works

Obviously this is a problem, since 4:2:0 and RGB24 are arguably the two most commonly-used pixfmts.

Furthermore, AvxSynth doesn't exhibit this behavior, even if avxffms2 is built with the updated sources. It lacks support for the 2.6 pixfmts, though. That's part of what made me start thinking it was pixfmt-related. The weird thing is that the last public build of the C-plugin (from June 25th) didn't exhibit this problem, and there haven't been any specific pixel format commits since.

[Myrsloik]

Even though I initially doubted it, it would appear the FFV1 issue (and it's not only FFV1; ffvhuff is also affected, at least) occurs due to colorspace issues.

I generated a test sequence with FFV1 using FFmpeg:
ffmpeg -f lavfi -i testsrc -vcodec ffv1 -t 10 test.avi
This video file caused the crash with FFMS2 (I'm testing the C plugin here, so chances are pretty high it's not in the plugin wrapper). By default, the testsrc outputs RGB.

However, if I force FFmpeg to write the file as 4:4:4,
ffmpeg -f lavfi -i testsrc -vcodec ffv1 -pix_fmt yuv444p -t 10 test.avi
It no longer crashes.

The results:
YV12/yuv420p = crash
YUY2/yuyv422 = [FFV1 doesn't support YUY2, it gets converted to standard 4:2:2, see below]
RGB24/bgr0 = crash
RGB32/bgra = works
YV16/yuv422p = works
YV24/yuv444p = works

Obviously this is a problem, since 4:2:0 and RGB24 are arguably the two most commonly-used pixfmts.

Furthermore, AvxSynth doesn't exhibit this behavior, even if avxffms2 is built with the updated sources. It lacks support for the 2.6 pixfmts, though. That's part of what made me start thinking it was pixfmt-related. The weird thing is that the last public build of the C-plugin (from June 25th) didn't exhibit this problem, and there haven't been any specific pixel format commits since.

Stack trace or it didn't happen.

[qyot27]

FFmpeg and FFMS2 built with debugging symbols,

RGB24:
D:\dap\vid\Incoming Files>ffmpeg
ffmpeg version r74701 git-628a73f Copyright (c) 2000-2015 the FFmpeg developers
built with gcc 5.1.0 (GCC)
configuration: --prefix=/home/qyot27/ffmpeg_build --cross-prefix=i686-w64-mingw32- --enable-gpl --enable-version3 --di
sable-w32threads --disable-doc --enable-debug --disable-stripping --enable-avisynth --disable-asm --disable-optimization
s --extra-cflags=-O0 --target-os=mingw32 --arch=x86
libavutil 54. 31.100 / 54. 31.100
libavcodec 56. 59.100 / 56. 59.100
libavformat 56. 40.101 / 56. 40.101
libavdevice 56. 4.100 / 56. 4.100
libavfilter 5. 39.100 / 5. 39.100
libswscale 3. 1.101 / 3. 1.101
libswresample 1. 2.101 / 1. 2.101
libpostproc 53. 3.100 / 53. 3.100
Hyper fast Audio and Video encoder
usage: ffmpeg [options] [[infile options] -i infile]... {[outfile options] outfile}...

Use -h to get full help or, even better, run 'man ffmpeg'

D:\dap\vid\Incoming Files>ffmpeg -f lavfi -i testsrc -vcodec ffv1 -t 10 test.avi
ffmpeg version r74701 git-628a73f Copyright (c) 2000-2015 the FFmpeg developers
built with gcc 5.1.0 (GCC)
configuration: --prefix=/home/qyot27/ffmpeg_build --cross-prefix=i686-w64-mingw32- --enable-gpl --enable-version3 --di
sable-w32threads --disable-doc --enable-debug --disable-stripping --enable-avisynth --disable-asm --disable-optimization
s --extra-cflags=-O0 --target-os=mingw32 --arch=x86
libavutil 54. 31.100 / 54. 31.100
libavcodec 56. 59.100 / 56. 59.100
libavformat 56. 40.101 / 56. 40.101
libavdevice 56. 4.100 / 56. 4.100
libavfilter 5. 39.100 / 5. 39.100
libswscale 3. 1.101 / 3. 1.101
libswresample 1. 2.101 / 1. 2.101
libpostproc 53. 3.100 / 53. 3.100
Input #0, lavfi, from 'testsrc':
Duration: N/A, start: 0.000000, bitrate: N/A
Stream #0:0: Video: rawvideo (RGB[24] / 0x18424752), rgb24, 320x240 [SAR 1:1 DAR 4:3], 25 tbr, 25 tbn, 25 tbc
Output #0, avi, to 'test.avi':
Metadata:
ISFT : Lavf56.40.101
Stream #0:0: Video: ffv1 (FFV1 / 0x31564646), bgr0, 320x240 [SAR 1:1 DAR 4:3], q=2-31, 200 kb/s, 25 fps, 25 tbn, 25
tbc
Metadata:
encoder : Lavc56.59.100 ffv1
Stream mapping:
Stream #0:0 -> #0:0 (rawvideo (native) -> ffv1 (native))
Press [q] to stop, [?] for help
frame= 250 fps= 15 q=-0.0 Lsize= 1029kB time=00:00:10.00 bitrate= 842.7kbits/s
video:1017kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 1.142499%

D:\dap\vid\Incoming Files>ffmsindex test.avi
Writing index... done... 100%

D:\dap\vid\Incoming Files>echo FFVideoSource("test.avi")>test.avs

D:\dap\vid\Incoming Files>mpv test.avs
Playing: test.avs
[ffmpeg/demuxer] avisynth: System exception - Access Violation
[ffmpeg/demuxer] (test.avs, line 1)
[lavf] avformat_open_input() failed
Failed to recognize file format.


Exiting... (Errors when loading file)

D:\dap\vid\Incoming Files>ffmpeg -i test.avs
ffmpeg version r74701 git-628a73f Copyright (c) 2000-2015 the FFmpeg developers
built with gcc 5.1.0 (GCC)
configuration: --prefix=/home/qyot27/ffmpeg_build --cross-prefix=i686-w64-mingw32- --enable-gpl --enable-version3 --di
sable-w32threads --disable-doc --enable-debug --disable-stripping --enable-avisynth --disable-asm --disable-optimization
s --extra-cflags=-O0 --target-os=mingw32 --arch=x86
libavutil 54. 31.100 / 54. 31.100
libavcodec 56. 59.100 / 56. 59.100
libavformat 56. 40.101 / 56. 40.101
libavdevice 56. 4.100 / 56. 4.100
libavfilter 5. 39.100 / 5. 39.100
libswscale 3. 1.101 / 3. 1.101
libswresample 1. 2.101 / 1. 2.101
libpostproc 53. 3.100 / 53. 3.100
[avisynth @ 059e4190] System exception - Access Violation
(test.avs, line 1)
test.avs: Unknown error occurred

D:\dap\vid\Incoming Files>gdb ffmpeg
GNU gdb (GDB) 7.9
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-msys".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Traceback (most recent call last):
File "<string>", line 3, in <module>
ImportError: No module named libstdcxx.v6.printers
/etc/gdbinit:6: Error in sourced command file:
Error while executing Python code.
Reading symbols from ffmpeg...done.
(gdb) r -i test.avs
Starting program: /d/dap/vid/Incoming Files/ffmpeg -i test.avs
[New Thread 1192.0x518]
ffmpeg version r74701 git-628a73f Copyright (c) 2000-2015 the FFmpeg developers
built with gcc 5.1.0 (GCC)
configuration: --prefix=/home/qyot27/ffmpeg_build --cross-prefix=i686-w64-mingw32- --enable-gpl --enable-version3 --di
sable-w32threads --disable-doc --enable-debug --disable-stripping --enable-avisynth --disable-asm --disable-optimization
s --extra-cflags=-O0 --target-os=mingw32 --arch=x86
libavutil 54. 31.100 / 54. 31.100
libavcodec 56. 59.100 / 56. 59.100
libavformat 56. 40.101 / 56. 40.101
libavdevice 56. 4.100 / 56. 4.100
libavfilter 5. 39.100 / 5. 39.100
libswscale 3. 1.101 / 3. 1.101
libswresample 1. 2.101 / 1. 2.101
libpostproc 53. 3.100 / 53. 3.100
[New Thread 1192.0x490]
[New Thread 1192.0x350]
[New Thread 1192.0x50c]
[New Thread 1192.0x51c]
[New Thread 1192.0x4e0]
warning: FFMS2 avs plugin: Initializing...
warning: FFMS2 - avs 2.6 mode
warning: Creation of mvCore at adresse : 217106452

Program received signal SIGSEGV, Segmentation fault.
0x0823c480 in ?? ()
(gdb) bt
#0 0x0823c480 in ?? ()
#1 0x08251c7f in ?? ()
#2 0x0814253e in ?? ()
#3 0x0770efb3 in ?? ()
#4 0x0770f925 in ?? ()
#5 0x0770452f in ?? ()
#6 0x07715398 in ?? ()
#7 0x077158c2 in ?? ()
#8 0x07712e3c in ?? ()
#9 0x1001d737 in ?? () from /c/WINDOWS/system32/avisynth.dll
#10 0x0cfceda0 in ?? ()
#11 0x10099050 in CreateScriptEnvironment () from /c/WINDOWS/system32/avisynth.dll
#12 0x1009bc40 in CreateScriptEnvironment () from /c/WINDOWS/system32/avisynth.dll
#13 0x1009c100 in avs_clip_get_error () from /c/WINDOWS/system32/avisynth.dll
#14 0x1009c530 in avs_clip_get_error () from /c/WINDOWS/system32/avisynth.dll
#15 0x1009c470 in avs_clip_get_error () from /c/WINDOWS/system32/avisynth.dll
#16 0x10098470 in DllGetClassObject () from /c/WINDOWS/system32/avisynth.dll
#17 0x10098f90 in CreateScriptEnvironment () from /c/WINDOWS/system32/avisynth.dll
#18 0x1009a490 in CreateScriptEnvironment () from /c/WINDOWS/system32/avisynth.dll
#19 0x10099730 in CreateScriptEnvironment () from /c/WINDOWS/system32/avisynth.dll
#20 0x1009c0a0 in CreateScriptEnvironment () from /c/WINDOWS/system32/avisynth.dll
#21 0x1009beb0 in CreateScriptEnvironment () from /c/WINDOWS/system32/avisynth.dll
#22 0x1009b9e0 in CreateScriptEnvironment () from /c/WINDOWS/system32/avisynth.dll
#23 0x1009b970 in CreateScriptEnvironment () from /c/WINDOWS/system32/avisynth.dll
#24 0x1009b4d0 in CreateScriptEnvironment () from /c/WINDOWS/system32/avisynth.dll
#25 0x1009ad00 in CreateScriptEnvironment () from /c/WINDOWS/system32/avisynth.dll
#26 0x10098780 in DllGetClassObject () from /c/WINDOWS/system32/avisynth.dll
#27 0x100986e0 in DllGetClassObject () from /c/WINDOWS/system32/avisynth.dll
#28 0x100987e0 in DllGetClassObject () from /c/WINDOWS/system32/avisynth.dll
#29 0x1009c120 in avs_clip_get_error () from /c/WINDOWS/system32/avisynth.dll
#30 0x1009bee0 in CreateScriptEnvironment () from /c/WINDOWS/system32/avisynth.dll
#31 0x1009c0d0 in CreateScriptEnvironment () from /c/WINDOWS/system32/avisynth.dll
#32 0x1009af00 in CreateScriptEnvironment () from /c/WINDOWS/system32/avisynth.dll
#33 0x1009b940 in CreateScriptEnvironment () from /c/WINDOWS/system32/avisynth.dll
#34 0x1009c3b0 in avs_clip_get_error () from /c/WINDOWS/system32/avisynth.dll
#35 0x100988c0 in CreateScriptEnvironment () from /c/WINDOWS/system32/avisynth.dll
#36 0x100986b0 in DllGetClassObject () from /c/WINDOWS/system32/avisynth.dll
#37 0x10099040 in CreateScriptEnvironment () from /c/WINDOWS/system32/avisynth.dll
#38 0x100996a0 in CreateScriptEnvironment () from /c/WINDOWS/system32/avisynth.dll
---Type <return> to continue, or q <return> to quit---
#39 0x10099930 in CreateScriptEnvironment () from /c/WINDOWS/system32/avisynth.dll
#40 0x100998a0 in CreateScriptEnvironment () from /c/WINDOWS/system32/avisynth.dll
#41 0x10099800 in CreateScriptEnvironment () from /c/WINDOWS/system32/avisynth.dll
#42 0x10099a00 in CreateScriptEnvironment () from /c/WINDOWS/system32/avisynth.dll
#43 0x100999d0 in CreateScriptEnvironment () from /c/WINDOWS/system32/avisynth.dll
#44 0x1009aba0 in CreateScriptEnvironment () from /c/WINDOWS/system32/avisynth.dll
#45 0x10098380 in DllGetClassObject () from /c/WINDOWS/system32/avisynth.dll
#46 0x10098800 in DllGetClassObject () from /c/WINDOWS/system32/avisynth.dll
#47 0x10098770 in DllGetClassObject () from /c/WINDOWS/system32/avisynth.dll
#48 0x10098440 in DllGetClassObject () from /c/WINDOWS/system32/avisynth.dll
#49 0x1009a430 in CreateScriptEnvironment () from /c/WINDOWS/system32/avisynth.dll
#50 0x1009bd40 in CreateScriptEnvironment () from /c/WINDOWS/system32/avisynth.dll
#51 0x1009b210 in CreateScriptEnvironment () from /c/WINDOWS/system32/avisynth.dll
#52 0x1009b920 in CreateScriptEnvironment () from /c/WINDOWS/system32/avisynth.dll
#53 0x1009a530 in CreateScriptEnvironment () from /c/WINDOWS/system32/avisynth.dll
#54 0x100984f0 in DllGetClassObject () from /c/WINDOWS/system32/avisynth.dll
#55 0x10098f70 in CreateScriptEnvironment () from /c/WINDOWS/system32/avisynth.dll
#56 0x10099aa0 in CreateScriptEnvironment () from /c/WINDOWS/system32/avisynth.dll
#57 0x100988b0 in CreateScriptEnvironment () from /c/WINDOWS/system32/avisynth.dll
#58 0x100984a0 in DllGetClassObject () from /c/WINDOWS/system32/avisynth.dll
#59 0x10099060 in CreateScriptEnvironment () from /c/WINDOWS/system32/avisynth.dll
#60 0x1009c020 in CreateScriptEnvironment () from /c/WINDOWS/system32/avisynth.dll
#61 0x4e5f544d in ?? ()
#62 0x5f454349 in ?? ()
#63 0x544c4946 in ?? ()
#64 0x00005245 in ?? ()
#65 0x4d5f544d in ?? ()
#66 0x49544c55 in ?? ()
#67 0x534e495f in ?? ()
#68 0x434e4154 in ?? ()
#69 0x00000045 in ?? ()
#70 0x535f544d in ?? ()
#71 0x41495245 in ?? ()
#72 0x455a494c in ?? ()
#73 0x00000044 in ?? ()
#74 0x53697641 in ?? ()
#75 0x68746e79 in ?? ()
#76 0x4956415f in ?? ()
#77 0x72756f53 in ?? ()
---Type <return> to continue, or q <return> to quit---
#78 0x00006563 in ?? ()
#79 0x53697641 in ?? ()
#80 0x68746e79 in ?? ()
#81 0x4956415f in ?? ()
#82 0x656c6946 in ?? ()
#83 0x72756f53 in ?? ()
#84 0x00006563 in ?? ()
#85 0x53697641 in ?? ()
#86 0x68746e79 in ?? ()
#87 0x5641575f in ?? ()
#88 0x72756f53 in ?? ()
#89 0x00006563 in ?? ()
#90 0x53697641 in ?? ()
#91 0x68746e79 in ?? ()
#92 0x65704f5f in ?? ()
#93 0x4c4d446e in ?? ()
#94 0x72756f53 in ?? ()
#95 0x00006563 in ?? ()
#96 0x53697641 in ?? ()
#97 0x68746e79 in ?? ()
#98 0x6168435f in ?? ()
#99 0x4665676e in ?? ()
#100 0x00005350 in ?? ()
#101 0x53697641 in ?? ()
#102 0x68746e79 in ?? ()
#103 0x6e6f435f in ?? ()
#104 0x74726576 in ?? ()
#105 0x00535046 in dither_color (shift=16, scale=608486912, eb=1955137116, eg=1153837092, er=-1960289244,
px=1403185358) at libavfilter/vf_paletteuse.c:152
#106 set_frame (search_method=<optimized out>, dither=4294905892, h=1157038079, w=-956229596, y_start=194427911,
x_start=1460237328, in=0x5bb9e8 <ff_bufqueue_add+131>, out=0x4c48300, s=0x8244c8b)
at libavfilter/vf_paletteuse.c:423
#107 set_frame_bruteforce_bayer (s=0x82444f6, out=0x56097401, in=0x5b85e8 <filter_frame+327>, x_start=79987456,
y_start=-1033976181, w=-859045884, h=409534314) at libavfilter/vf_paletteuse.c:975
#108 0xfffff768 in ?? ()
#109 0x082444f6 in ?? ()
Backtrace stopped: Cannot access memory at address 0xe8f18b5a
(gdb)

[qyot27]

YV12:
D:\dap\vid\Incoming Files>ffmpeg -f lavfi -i testsrc -vcodec ffv1 -pix_fmt yuv420p -t 10 test420.avi
ffmpeg version r74701 git-628a73f Copyright (c) 2000-2015 the FFmpeg developers
built with gcc 5.1.0 (GCC)
configuration: --prefix=/home/qyot27/ffmpeg_build --cross-prefix=i686-w64-mingw32- --enable-gpl --enable-version3 --di
sable-w32threads --disable-doc --enable-debug --disable-stripping --enable-avisynth --disable-asm --disable-optimization
s --extra-cflags=-O0 --target-os=mingw32 --arch=x86
libavutil 54. 31.100 / 54. 31.100
libavcodec 56. 59.100 / 56. 59.100
libavformat 56. 40.101 / 56. 40.101
libavdevice 56. 4.100 / 56. 4.100
libavfilter 5. 39.100 / 5. 39.100
libswscale 3. 1.101 / 3. 1.101
libswresample 1. 2.101 / 1. 2.101
libpostproc 53. 3.100 / 53. 3.100
Input #0, lavfi, from 'testsrc':
Duration: N/A, start: 0.000000, bitrate: N/A
Stream #0:0: Video: rawvideo (RGB[24] / 0x18424752), rgb24, 320x240 [SAR 1:1 DAR 4:3], 25 tbr, 25 tbn, 25 tbc
Output #0, avi, to 'test420.avi':
Metadata:
ISFT : Lavf56.40.101
Stream #0:0: Video: ffv1 (FFV1 / 0x31564646), yuv420p, 320x240 [SAR 1:1 DAR 4:3], q=2-31, 200 kb/s, 25 fps, 25 tbn,
25 tbc
Metadata:
encoder : Lavc56.59.100 ffv1
Stream mapping:
Stream #0:0 -> #0:0 (rawvideo (native) -> ffv1 (native))
Press [q] to stop, [?] for help
frame= 250 fps= 15 q=-0.0 Lsize= 955kB time=00:00:10.00 bitrate= 782.5kbits/s
video:944kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 1.230569%

D:\dap\vid\Incoming Files>ffmsindex test420.avi
Writing index... done... 100%

D:\dap\vid\Incoming Files>echo FFVideoSource("test420.avi")>test420.avs

D:\dap\vid\Incoming Files>ffmpeg -i test420.avi
ffmpeg version r74701 git-628a73f Copyright (c) 2000-2015 the FFmpeg developers
built with gcc 5.1.0 (GCC)
configuration: --prefix=/home/qyot27/ffmpeg_build --cross-prefix=i686-w64-mingw32- --enable-gpl --enable-version3 --di
sable-w32threads --disable-doc --enable-debug --disable-stripping --enable-avisynth --disable-asm --disable-optimization
s --extra-cflags=-O0 --target-os=mingw32 --arch=x86
libavutil 54. 31.100 / 54. 31.100
libavcodec 56. 59.100 / 56. 59.100
libavformat 56. 40.101 / 56. 40.101
libavdevice 56. 4.100 / 56. 4.100
libavfilter 5. 39.100 / 5. 39.100
libswscale 3. 1.101 / 3. 1.101
libswresample 1. 2.101 / 1. 2.101
libpostproc 53. 3.100 / 53. 3.100
Input #0, avi, from 'test420.avi':
Metadata:
encoder : Lavf56.40.101
Duration: 00:00:10.00, start: 0.000000, bitrate: 782 kb/s
Stream #0:0: Video: ffv1 (FFV1 / 0x31564646), yuv420p, 320x240, 776 kb/s, SAR 1:1 DAR 4:3, 25 fps, 25 tbr, 25 tbn, 2
5 tbc
At least one output file must be specified

D:\dap\vid\Incoming Files>ffmpeg -i test420.avs
ffmpeg version r74701 git-628a73f Copyright (c) 2000-2015 the FFmpeg developers
built with gcc 5.1.0 (GCC)
configuration: --prefix=/home/qyot27/ffmpeg_build --cross-prefix=i686-w64-mingw32- --enable-gpl --enable-version3 --di
sable-w32threads --disable-doc --enable-debug --disable-stripping --enable-avisynth --disable-asm --disable-optimization
s --extra-cflags=-O0 --target-os=mingw32 --arch=x86
libavutil 54. 31.100 / 54. 31.100
libavcodec 56. 59.100 / 56. 59.100
libavformat 56. 40.101 / 56. 40.101
libavdevice 56. 4.100 / 56. 4.100
libavfilter 5. 39.100 / 5. 39.100
libswscale 3. 1.101 / 3. 1.101
libswresample 1. 2.101 / 1. 2.101
libpostproc 53. 3.100 / 53. 3.100

D:\dap\vid\Incoming Files>gdb ffmpeg
GNU gdb (GDB) 7.9
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-msys".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Traceback (most recent call last):
File "<string>", line 3, in <module>
ImportError: No module named libstdcxx.v6.printers
/etc/gdbinit:6: Error in sourced command file:
Error while executing Python code.
Reading symbols from ffmpeg...done.
(gdb) r -i test420.avs
Starting program: /d/dap/vid/Incoming Files/ffmpeg -i test420.avs
[New Thread 3480.0xd94]
ffmpeg version r74701 git-628a73f Copyright (c) 2000-2015 the FFmpeg developers
built with gcc 5.1.0 (GCC)
configuration: --prefix=/home/qyot27/ffmpeg_build --cross-prefix=i686-w64-mingw32- --enable-gpl --enable-version3 --di
sable-w32threads --disable-doc --enable-debug --disable-stripping --enable-avisynth --disable-asm --disable-optimization
s --extra-cflags=-O0 --target-os=mingw32 --arch=x86
libavutil 54. 31.100 / 54. 31.100
libavcodec 56. 59.100 / 56. 59.100
libavformat 56. 40.101 / 56. 40.101
libavdevice 56. 4.100 / 56. 4.100
libavfilter 5. 39.100 / 5. 39.100
libswscale 3. 1.101 / 3. 1.101
libswresample 1. 2.101 / 1. 2.101
libpostproc 53. 3.100 / 53. 3.100
[New Thread 3480.0xf28]
[New Thread 3480.0xf2c]
[New Thread 3480.0xc44]
[New Thread 3480.0xc84]
[New Thread 3480.0xf30]
warning: FFMS2 avs plugin: Initializing...
warning: FFMS2 - avs 2.6 mode
warning: Creation of mvCore at adresse : 217106452

Program received signal SIGSEGV, Segmentation fault.
0x100266c5 in DllGetClassObject () from /c/WINDOWS/system32/avisynth.dll
(gdb) bt
#0 0x100266c5 in DllGetClassObject () from /c/WINDOWS/system32/avisynth.dll
#1 0x00004b00 in ?? ()
#2 0x00000078 in ?? ()
#3 0x05b06b90 in ?? ()
#4 0x1001ed20 in avs_vsprintf () from /c/WINDOWS/system32/avisynth.dll
#5 0x0d002820 in ?? ()
#6 0x07714cc2 in ?? ()
#7 0x07715182 in ?? ()
#8 0x1001d56e in ?? () from /c/WINDOWS/system32/avisynth.dll
#9 0x1001dde4 in avs_get_frame () from /c/WINDOWS/system32/avisynth.dll
#10 0x005e1288 in avisynth_read_packet_video (s=0x59e4720, pkt=0x22f638, discard=0) at libavformat/avisynth.c:501
#11 0x005e17c1 in avisynth_read_packet (s=0x59e4720, pkt=0x22f638) at libavformat/avisynth.c:640
#12 0x007105f7 in ff_read_packet (s=0x59e4720, pkt=0x22f638) at libavformat/utils.c:672
#13 0x00713115 in read_frame_internal (s=0x59e4720, pkt=0x22f938) at libavformat/utils.c:1328
#14 0x0071a1a5 in avformat_find_stream_info (ic=0x59e4720, options=0x59e4d30) at libavformat/utils.c:3262
#15 0x0040a59c in open_input_file (o=0x22fb80, filename=0x59e4484 "test420.avs") at ffmpeg_opt.c:945
#16 0x00412104 in open_files (l=0x59e44cc, inout=0x1183a37 <groups+215> "input", open_file=0x409d9d <open_input_file>)
at ffmpeg_opt.c:2910
#17 0x0041225d in ffmpeg_parse_options (argc=3, argv=0x59e4310) at ffmpeg_opt.c:2947
#18 0x004248e1 in main (argc=3, argv=0x59e4310) at ffmpeg.c:4143
(gdb)


Ut Video also exhibited the issue with RGB, and in that case, opening it with AVISource worked, while FFMS2 threw the same Access Violation shown above. It's not possible to test AVISource with FFV1 and ffvhuff because of ffdshow being horrifically outdated.

[Selur]

btw. what is the latest FFMS2 c-plugin version?

[qyot27]

FFMS2 C-plugin r1072+90

Optimized for Pentium III and SSE.

ffmpeg version r74638 git-4cd1d23 Copyright (c) 2000-2015 the FFmpeg developers
built with gcc 5.1.0 (GCC)

libavutil 54. 31.100 / 54. 31.100
libavcodec 56. 58.100 / 56. 58.100
libavformat 56. 40.101 / 56. 40.101
libavfilter 5. 37.100 / 5. 37.100
libavresample 2. 1. 0 / 2. 1. 0
libswscale 3. 1.101 / 3. 1.101
libswresample 1. 2.101 / 1. 2.101
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

This isn't the newest build, as it's from August 25th or thereabouts, but it's the most recent one that works. My latest test builds are crashing (not related to the stuff above, since it's doing it on every file) and I need to figure out why.

This build does not support AviSynth 2.5.

EDIT 2016-02-25: Newer build available here. (http://forum.doom9.org/showthread.php?p=1758567#post1758567)

[Selur]

Thanks for clearing that up and sharing that build. :)

Cu Selur

[filler56789]

@qyot27: Many thanks :thanks:

Specially for this ;)



configuration:

--disable-decoder=utvideo
--enable-libutvideo
--disable-decoder=dca
--enable-libdcadec


:sly:

[Kein]

Small update on the issue I reported before:
http://forum.doom9.org/showpost.php?p=1733006&postcount=2112
http://forum.doom9.org/showpost.php?p=1733014&postcount=2115

This is interesting, if i use FFMS to open and join two files through Dissolve:
a=FFAudioSource("1.avi")
b=FFVideoSource("1.avi")
c=AudioDub(b, a)

d=FFAudioSource("2.avi")
e=FFVideoSource("2.avi")
f=AudioDub(e, d)
Dissolve(a,f,60)

the final result will have desynced audio right when second clip start (firs one is fine). Same happens if I use AlignedSpace().

However, if I use UnalignedSpace() there is no audio-to-video sync issues. Odd. Exactly vice versa with AviSource (i.e. it works as intended).


Hmm, is there a Dissolve() analogue with UnalignedSpace() method?

Also, is there any other plugin a-la FFMS that allows you to load clips in its native colorspace without forcefully converting it like AviSource into RGB?

[LigH]

*Splice instead of *Space

AviSource does not "forcefully convert to RGB". Usually it asks the VfW codec which decoded formats it offers and which will match best a list of supported formats (e.g. DivX will usually be loaded as YV12). You may tell AviSource to request a target 'pixel_format', but when the VfW codec can't output this, AviSource would fail instead of accepting the next similar. — Maybe your DXTory VfW decoder was set up to "always output RGB", or simply returns RGB because it had recorded and saved RGB? I don't know if it is at all able to save YUV.

UnalignedSplice will match the video streams and the audio streams of both clips independently. If the video stream (a) and the audio stream (b) of the first clip (c) had a different length, this will usually introduce a skew from the joint on. But if the second clip contains audio with the same amount of skew (may happen when they were one continuous movie before and cut into segments), then the skewed audio will match again, like a "tongue and groove" joint. AlignedSplice (and Dissolve) instead will make video and audio streams match and fill up gaps; furthermore, loading d and e separately and dubbing them without checking for a possible audio skew and using DelayAudio(ms) will probably already have created an asynchronous clip f in this case.

[Kein]

*Splice instead of *Space
My bad it is late here.

AviSource does not "forcefully convert to RGB". Usually it asks the VfW codec which decoded formats it offers and which will match best a list of supported formats (e.g. DivX will usually be loaded as YV12). You may tell AviSource to request a target 'pixel_format', but when the VfW codec can't output this, AviSource would fail instead of accepting the next similar. — Maybe your DXTory VfW decoder was set up to "always output RGB", or simply returns RGB because it had recorded and saved RGB? I don't know if it is at all able to save YUV.

pixel_format NEVER worked for me regardless of source material and codec used.

As for DXTory format - this time I used FRAPS, not DXtory.


loading d and e separately and dubbing them without checking for a possible audio skew and using DelayAudio(ms) will probably already have created an asynchronous clip f in this case.
Hmm, not related to the subj but how can I check for skew?

[LigH]

VirtualDub (File Information); MediaInfo; GSpot ... at least one of them should probably be able to display a skew (delay) for the audio stream relative to the video stream.

[Kein]

VirtualDub (File Information); MediaInfo; GSpot ... at least one of them should probably be able to display a skew (delay) for the audio stream relative to the video stream.

No "skew" there, video and audio streams have the same exact length.

http://www.everfall.com/paste/id.php?syduozchnkmr

http://www.everfall.com/paste/id.php?jprv7cz45vsy

[jpsdr]

Is avresample (or swresample) now mandatory to build ffms2 ? I've tried to build without any of them, and build failed. It wasn't the case before, so i'm wondering if there is any change ?

[Jamaika]

I would like to ask how to properly give a title and language tracks in muxer ffmpeg(20150927) for container MOV. I can't cope.
ffmpeg.exe -i input_pol.srt ... -f mov -map 2:0 -metadata:s:2 language=pol -metadata:s:2 title/{changed to "handler"}="Subtitle (pol)" -sub_charenc UTF-8 -c:s mov_text ...
The result in MediaInfo 0.7.7:
Tekst
ID : 3
Format : Timed Text
Codec ID : text
Duration : 2 min.
Bit rate mode : Zmienna
Bit rate : 10 b/s
Stream size : 149 bajtów (0%)
Language : 25
Title{lack} : {lack}

Edit: OK, I found even a partial answer.
http://forum.doom9.org/showthread.php?t=165213
http://forum.doom9.org/showthread.php?t=171921

[Sparktank]

Although, already solved, that's an entirely different "ffmpeg". A binary encoder unrelated to Avisynth (directly unrelated; indirectly it can be useful).

[real.finder]

now work with yv411 but with upside down green image

still in 2.22 too

sample http://samaup.com/a7o3lluxx2m6

[real.finder]

is this ok? https://www.virustotal.com/en/file/678f0a3003f26f7daf7dac33d8af10241e53fefdb446cb8cae1e36c739cb757d/analysis/ from this https://github.com/FFMS/ffms2/releases/tag/2.22

[jpsdr]

Maybe there is a minor cosmetic display issue in the configure file, because my output is :

checking for AVRESAMPLE... no
checking for AVRESAMPLE... yes

Isn't the second not AVRESAMPLE but SWRESAMPLE ? Because i've not enabled AVRESAMPLE, but SWRESAMPLE wasn't disabled when i've build ffmpeg.

[szabi]

Hi

I downloaded ffms2-2.22-msvc (https://github.com/FFMS/ffms2/releases).
But I can not use it because:
http://abload.de/img/ffms2222-msvcxtp5b.png

Previous version does not have this issue.
Is there a solution?

bye
szabi

[Groucho2004]

It's clearly a false positive but check out the analysis from Virustotal (https://www.virustotal.com/en/file/af42e338285477302b93243331873fd21185126883fdbd2b2472c663c1f6e486/analysis/). The AV engines seem to get more stupid with each release.

Is there a solution?
Yes, don't use a AV program or use one that does not constantly try to keep you from using your computer.

[szabi]

Previous version does not have this issue.
Only new one.

[Groucho2004]

Previous version does not have this issue.
Only new one.
Are you going to post this until you get an answer that suits you? Which part of 'false positive' don't you understand?

[StainlessS]

szabi,
Some time ago I got a false + on a Visual Basic program that had a lot of small buttons on the form in multiple row/column,
only difference between data describing buttons was in the x,y coords. Some Antivirus programs saw this repeated
pattern with only slight differences, as a sort of malware mutation device and issued malware warnings.
All I had to do was rearrange the buttons in a different sequential order but same locations on form. (EDIT: To avoid false +ve).
Anti-Malware heuristics are not that good and do provide a lot of false +ve's.
If most AV software says its OK then trust that.

EDIT: Also, you can point this out as a potential false +ve to Avast (they will look into it and hopefully drop the false +ve,
the problem seems not to be with FFMpegSource but with Avast).

EDIT:
Threat:Win32:Malware-gen
I'm taking 'Malware-Gen' (generator) to be exactly as described above, it sees some kind of (almost identical) repeated sequence and thinks it is
some kind of malware mutation device. (BUT IT IS ONLY GUESSING, that's what heuristics are, guesses based on past experience
of real malware, but guesses nonetheless).

[LigH]

Well, it's not that simple. Yesterday I got emails looking like phishing or spyware injectors. The analysis by VirusTotal returned only 9/55, partially "generic", partially named.

I looked into the binary EXE, which was surprisingly not even packed or encrypted (I already have an eye for entropy), just a plain C build. Very suspicious, it seems to access an MS Jet database, and even contained an SQL statement looking for pageranks. Searching for this pattern in the web, I came to another malware "genome" analysis site: Invincea Cynomix. Didn't detect many suspicious features either. So this seems to be the case of a "false negative".

But we are drifting away. Might be best to cut off some of the last malware related posts?

[MysteryX]

What's the right way of using FFmpegSource2 with MT? Which MT mode has to be used?
SetMTMode(3,8)

And if I'm using MT mode, and when caching is disabled, does it repeat the indexing for each thread, increasing time?

[LigH]

If you call the FF*Source functions in a range where MT mode 3 or 5 is active, then they will be called only once. You can switch to MT mode 2 (omit the thread count here!) afterwards for thread-safe, cooperative filters. It is recommendable to use the function Preroll (http://avisynth.nl/index.php/Preroll)(video_frames, audio_seconds), available since MT 2.60 alpha 4.

Do not exaggerate the number of threads, especially when calling a function which may fork threads internally (e.g. QTGMC does so, more than 4 MT threads won't be recommendable, also due to RAM consumption).

[MysteryX]

How should I use Preroll? I'm searching online and cannot find *any* documentation or information at all about its 2 parameters.

I'm writing a simple script to auto-pitch the audio to 432hz in real-time. Do you see anything that needs tweaking?

PluginPath=""
LoadPlugin(PluginPath+"ffms2.dll")
LoadPlugin(PluginPath+"TimeStretch.dll")
SetMTMode(3,4)
FFmpegSource2(source="Like a Cat.mp4", atrack=-1, cache=false, threads=1)
SetMTMode(2)
SemiTone = -0.3176665363342977
TimeStretchPlugin(pitch = 100.0 * pow(2.0, SemiTone / 12.0))

I'm still having occasional audio/video sync problems.

[TheFluff]

don't try to mt ffms2, it does multithreaded decoding internally already

actually, don't use avs-mt at all, it's a bad idea and you're gonna have a bad time

[MysteryX]

don't try to mt ffms2, it does multithreaded decoding internally already

actually, don't use avs-mt at all, it's a bad idea and you're gonna have a bad time
Probably a good advice. I was having the problem of doubling the rate of instabilities and crashes by feeding an AviSynth script into MPC-HC, which then feeds the video into ffdshow and into SVP which creates another AviSynth instance to return it back to the player.

Two AviSynth instances within each other. If I disable MT for one, it should make it more stable. I'll test this tonight.

Plus it clearly is very optional in this scenario; although I was seeing a few lags and that's the reason why I had added it in the first place.

[MysteryX]

If I don't enable MT, the audio and video fall out of sync. If I do enable it, then it's in sync "most of the time".

Keep in my the CPU and GPU are loaded with SVP+madVR.

[LigH]

In your case, not using even one video filter, there is indeed no reason to use MT. It looks like you could even execute this brief sequence inside the AviSynth post-processing filter of ffdshow if you used this as DirectShow decoder filter to play your video in a media player, then you would not use FFMS2 but the internal ffdshow_source. Or it may even have an own TimeStretch PP filter, I'm not sure right now. At least both would be much more useful than reading an AviSynth script as source with MPC-HC.

[MysteryX]

SVP is doing exactly that: plugging into the ffdshow chain. I tried inserting the code into the AviSynth script it is already processing. However, it doesn't seem to have the ability to process the audio, which is processed some other way. Or is there a way to force the audio to be processed at the same time through ffdshow?

[MysteryX]

The script I'm using is working "most of the time", but I'm seeing some really weird behaviors when playing in MPC-HC. Occasionally, the playback will reset to the beginning. Occasionally, it will skip to the next video in the middle of playback. I never had any kind of such issue before using this auto-tuning script, and it's a very strange issue that is totally random and hard to reproduce. Can this be caused by FFmpegSource2, and is there a way to avoid that? Trying to figure out why it's happening and where it could be coming from.

I'm also controlling MPC-HC via API from a software I wrote, so the code in my software also could be responsible for some of it. It's just really weird. One thing I can think of that could cause problem in my software is if MPC-HC sees and reports the wrong video length, which could explain why it would skip to the next video in the middle of playback, but that wouldn't explain the times where it resets to the beginning of the same video in the middle of playback.

[StainlessS]

Not sure, but I think that I've experienced MPC-HC jumping back to beginning when hitting some kind of error
(when it should display an Avisynth error message).

EDIT: Think it happened mostly when error is on opening script, and just keeps trying and retrying again and again, etc.

[MysteryX]

Not sure, but I think that I've experienced MPC-HC jumping back to beginning when hitting some kind of error
(when it should display an Avisynth error message).

EDIT: Think it happened mostly when error is on opening script, and just keeps trying and retrying again and again, etc.

This would make sense. And when it skips to the next video, it's because it restarted the video and my software detected it had looped back to the beginning, assuming it ended, so it's switching to the next.

[sl1pkn07]

chromium (49.0.2618.8) detect https://github.com/FFMS/ffms2/releases/download/2.22/ffms2-2.22-msvc.7z as malicious and can't save it

[Myrsloik]

chromium (49.0.2618.8) detect https://github.com/FFMS/ffms2/releases/download/2.22/ffms2-2.22-msvc.7z as malicious and can't save it

That's a chromium bug

[LigH]

It will probably have looked up this URL at a service which contains a false positive. The fact that there are false positives about this file is known for months already, but unfortunately not for all of such "protection services".

[burfadel]

Any new builds?

[szabi]

szabi,
Some time ago I got a false + on a Visual Basic program that had a lot of small buttons on the form in multiple row/column,
only difference between data describing buttons was in the x,y coords. Some Antivirus programs saw this repeated
pattern with only slight differences, as a sort of malware mutation device and issued malware warnings.
All I had to do was rearrange the buttons in a different sequential order but same locations on form. (EDIT: To avoid false +ve).
Anti-Malware heuristics are not that good and do provide a lot of false +ve's.
If most AV software says its OK then trust that.

EDIT: Also, you can point this out as a potential false +ve to Avast (they will look into it and hopefully drop the false +ve,
the problem seems not to be with FFMpegSource but with Avast).

EDIT:

I'm taking 'Malware-Gen' (generator) to be exactly as described above, it sees some kind of (almost identical) repeated sequence and thinks it is
some kind of malware mutation device. (BUT IT IS ONLY GUESSING, that's what heuristics are, guesses based on past experience
of real malware, but guesses nonetheless).

Hi

Many thanks for the explaination.

bye
szabi

[qyot27]

FFMS2 C-plugin r1103+98

Optimized for Pentium III and SSE.

ffmpeg version r77598 git-dbfb2c1 Copyright (c) 2000-2015 the FFmpeg developers
built with gcc 5.3.0 (GCC)
libavutil 55. 11.100 / 55. 11.100
libavcodec 57. 21.100 / 57. 21.100
libavformat 57. 21.100 / 57. 21.100
libavfilter 6. 22.100 / 6. 22.100
libavresample 3. 0. 0 / 3. 0. 0
libswscale 4. 0.100 / 4. 0.100
libswresample 2. 0.101 / 2. 0.101
libpostproc 54. 0.100 / 54. 0.100

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

EDIT: Replaced the build with one from January that should work fine.

EDIT 2016-03-28: Newer build available here. (http://forum.doom9.org/showthread.php?p=1762372#post1762372)

[manolito]

Thanks for the new build...

Unfortunately this latest build does not like my Non-SSE2 Coppermine CPU any longer (access violation). :scared:

The previous build r1072c90 from last August still worked fine. Too bad...


Cheers
manolito

[feisty2]

Sadly nobody cares about copper mine CPUs

[LigH]

Strange if it is only optimized for P3 architecture. Can single libraries have higher requirements?

Regarding SSE2 ... I am already glad that AVX is not a required minimum already, thinking of the x265 development. ;)

[qyot27]

Thanks for the new build...

Unfortunately this latest build does not like my Non-SSE2 Coppermine CPU any longer (access violation). :scared:

The previous build r1072c90 from last August still worked fine. Too bad...
The difference in instruction sets wouldn't cause an access violation and allow AviSynth to error out cleanly. If there was a problem with the instruction set, it would crash immediately and you wouldn't get any actual error message (and running it in say, gdb, would show the problem as SIGILL). Or rather, the error would get thrown by Windows itself; AviSynth wouldn't know what hit it.

And more importantly, it also throws the access violation on Silvermont, so it's definitely not related to SSE2 and probably happens everywhere. Whatever it is happened on the FFMS2 side (which could also mean the C-plugin parts, after all) between January 2nd and yesterday, since the FFmpeg build it's linked against runs fine.

Absolute worst case is that GCC 5.3 is the cause of this, and nothing short of waiting for the next update (or rolling back to 5.2 or even 5.1) would fix it.

Sadly nobody cares about copper mine CPUs
My main hub computer uses a 1GHz Coppermine-128 Celeron. It's also the reason my builds have always targeted P3/SSE, although the need for that has all but been rendered moot since I got the Quantum Byte last October (I can't edit on the Byte due to disk space limitations, so pre-processing is still one reason for me to target it).

Strange if it is only optimized for P3 architecture. Can single libraries have higher requirements?
In the sense of one of the libs FFmpeg links to requiring a higher CPU or OS than FFmpeg itself is technically built to require? Sure, although that's not the case here.

The above description is actually what will happen if you build x264 on its defaults and FFmpeg on its defaults links against it, or if you happen to build FFmpeg with a MinGW toolchain that has the Secure API enabled. Neither of those FFmpeg builds would run on a P3 or XP setup, respectively, even though nothing about FFmpeg was explicitly set to require SSE2 or Vista+ - it simply inherits the limitations of the things it's linked against. The only way around that is through dynamic loading of the offending library, in which case you only hit this if you try to use that particular library. Regular static or dynamic linking will make the inheritance active in the host program pervasively, and any attempt at running it will hit the problem, regardless of whether the lib causing it was trying to be used or not.

In the case of the FFmpeg build I use for FFMS2, the only external libs it uses are zlib, bz2, lzma, and maybe iconv, aside from all the MinGW-related ones for network access and whatnot. None of them have been built to require SSE2 or Vista at a minimum.

[qyot27]

Yeah, there's something very weird happening here. Sometimes attempting to run the script a second or third time will finally succeed without an Access Violation, sometimes it might work on the first but fail on the second, and multiple runs may throw back different offending lines in FFMS2.avsi each time, and even bypassing FFMS2 and using FFVideo/AudioSource directly might work at first but then fail on the second.

I've updated the build announcement post with an older build (from January 2nd) that works. The differences are FFmpeg is about 1000 commits older, and FFMS2 is 6 commits older on the master branch.

I'll try to experiment more and try to figure out what's going on here. No ETA, though.

[manolito]

I've updated the build announcement post with an older build (from January 2nd) that works. The differences are FFmpeg is about 1000 commits older, and FFMS2 is 6 commits older on the master branch.

Yes, this one works! Thanks very much... :thanks:

[Taurus]

@qyot27: :thanks:
Some new fuel for an old XP Rig :D
Thanks

[burfadel]

FFMS2 C-plugin r1103+98 (http://www.mediafire.com/?nphy91iauld12ua)

Optimized for Pentium III and SSE.

EDIT: Replaced the build with one from January that should work fine.

I never tried the newer one, but this version doesn't work for me, it says %1 is an invalid win32 application when using with Staxrip. I then realised this is probably a 32 bit build only, and Staxrip is now 64-bit :).

Any chance of 64-bit builds? I'm guessing you would have to optimise for something a bit never than Pentium 3 :).

[StainlessS]

Perhaps qyot27 has more than enough on his plate, maybe Staxrip guy can make 64 bit compilation (not many others would be interested and qyot27's time might be better spent).

[qyot27]

The real problem is that I have no 64-bit Windows to accurately test against, and the times I've tried to test with 64-bit Wine (or building a 64-bit MinGW/GCC cross toolchain to even start working with) didn't fare so well. The 64-bit builds of AviSynth+ were different, since that still used MSVC.

Admittedly, that's been quite a while, and I should probably try again.

[stranno]

How can i load ProRes video (10bit) into FFMS2 64-bit + Avisynth+ 64-bit? Only 32-bit worked so far.

[burfadel]

How can i load ProRes video (10bit) into FFMS2 64-bit + Avisynth+ 64-bit? Only 32-bit worked so far.

You need to use a 64-bit build of ffms2. I have found that LSMASH-Works doesn't seem to work with a lot of 10-bit x264 sources whereas FFMS2 works beautifully. Not sure the cause of this. It seems 10-bit x264 has always caused a bit of a quandary on the decoder side of things with support. This is only with x264, with x265 10-bit doesn't have this issue and should really be the mainstream format (not 8-bit).

If you are using a proper 64-bit build of ffms2, you may need to try a different build?

[stranno]

You need to use a 64-bit build of ffms2. I have found that LSMASH-Works doesn't seem to work with a lot of 10-bit x264 sources whereas FFMS2 works beautifully. Not sure the cause of this. It seems 10-bit x264 has always caused a bit of a quandary on the decoder side of things with support. This is only with x264, with x265 10-bit doesn't have this issue and should really be the mainstream format (not 8-bit).

If you are using a proper 64-bit build of ffms2, you may need to try a different build?
I get a system exception error (access violation) with ffms2 2.22 64-bit + avisynth+ 1576 x64.

[stax76]

I never tried the newer one, but this version doesn't work for me, it says %1 is an invalid win32 application when using with Staxrip. I then realised this is probably a 32 bit build only, and Staxrip is now 64-bit :).

Any chance of 64-bit builds? I'm guessing you would have to optimise for something a bit never than Pentium 3 :).

StaxRip don't support C plugins, there is probably still a big memory leak that happens only in the C version of ffms2.

[burfadel]

It was a 32 bit build, running with 64 bit ffmpeg and x265 is probably the reason. It's good to have both ffms2 and lsmash-works, the (doom9 curse word) one depends on the source material.

[StainlessS]

Comodo Internet Security, still flags ffmsIndex.exe as malware, have submitted to Comodo (again), and posted in their forum a request to be White Listed.

[18fps]

I have a 100 GB prores HQ file, which I wasn't able to open with the 2.22. After the indexing, which the program completed without trouble, I got an access violation error. 2.21 opens it without trouble. I converted the file to FFV1 with ffmpeg, and when opening it with 2.22 got the same error as with the prores.

[LigH]

Just out of curiosity, how large are the index files in such cases? I remember that FFMS2 used to have trouble with indexing key-frame-only files, e.g. raw YUV AVIs, but I don't remember if that has been fixed in a specific range of versions. FFV1 may not have only key frames, but delta frames as well; still, there are probably a lot.

[18fps]

Just out of curiosity, how large are the index files in such cases?

Around 350 kb, I think. But version 2.21 had no trouble with them...

[Tima]

I have a 100 GB prores HQ file, which I wasn't able to open with the 2.22. After the indexing, which the program completed without trouble, I got an access violation error. 2.21 opens it without trouble. I converted the file to FFV1 with ffmpeg, and when opening it with 2.22 got the same error as with the prores.

I have the same problem with my 8Mb sample:

- FFMS 2.20 and 2.22 crash on opening
- FFMS 2.21 opens the video without crash (but some frames are wrong during stepping forward the first time)
- Same behaviour for both Lagarigth- and UT-encoded samples.

test-LAGS.avi: http://rghost.net/8CpZWhTvc
test-ULY2.avi: http://rghost.net/6vtBFTCqG

Here's also the same sample with audio stripped and without dropped frames (the original one has one such frame):
test-ULY2-nodrop.avi: http://rghost.net/6VwR5Sg6M

[qyot27]

FFMS2 C-plugin r1110+98

Optimized for Pentium III and SSE.

ffmpeg version r79153 git-c2bbcf1 Copyright (c) 2000-2016 the FFmpeg developers
built with gcc 5.3.0 (GCC)
libavutil 55. 19.100 / 55. 19.100
libavcodec 57. 32.100 / 57. 32.100
libavformat 57. 29.101 / 57. 29.101
libavfilter 6. 40.102 / 6. 40.102
libavresample 3. 0. 0 / 3. 0. 0
libswscale 4. 0.100 / 4. 0.100
libswresample 2. 0.101 / 2. 0.101
libpostproc 54. 0.100 / 54. 0.100

configuration:
--prefix=/home/qyot27/win32_build
--cross-prefix=i686-w64-mingw32-
--enable-gpl
--enable-version3
--disable-w32threads
--enable-avresample
--disable-encoders
--disable-muxers
--disable-doc
--disable-debug
--disable-devices
--disable-avdevice
--enable-avisynth
--cpu=pentium3
--extra-cflags='-mfpmath=sse -march=pentium3 -msse -mtune=pentium3 -fno-tree-vectorize'
--target-os=mingw32
--arch=x86
Actually up-to-date this time. The Access Violation issue from before was due to FFmpeg getting miscompiled (-fno-tree-vectorize fixes that problem).

EDIT 2016-10-19: Newer build available here. (http://forum.doom9.org/showthread.php?p=1783312#post1783312)

[filler56789]

FFMS2 C-plugin r1110+98 (http://www.mediafire.com/?k3yoexl7xsvqv3m)

Actually up-to-date this time.
The Access Violation issue from before was due to FFmpeg getting miscompiled
(-fno-tree-vectorize fixes that problem).

Thanks for the new&&fixed build :thanks:

[qyot27]

Users with older (read: ancient ones like my Pentium III drive host) computers may want to hold off, there's now an outright crash that gdb can't parse. It's not showing up as a missing function (the indicator for OS churn), or an illegal instruction (bad SIMD), so either FFMS2 doesn't like its own GCC optimization level* or something else has gone screwy. It's not happening on Silvermont, so if you have a decently new enough CPU you probably won't run into it.

*the Haali Matroska parser would cause a nasty memory problem on PIII with any optimization level, which is why I usually built the C-plugin as -O0. It may be doing it in some other part of the code now, since the Haali stuff was removed over a year ago.

[manolito]

Yeah, just found out on my real ancient Coppermine CPU (no SSE2). Can't even load the plugin:

http://i.imgur.com/2uIOsTK.png


Still thanks a lot for keeping your C-plugin updated.


Cheers
manolito

[poisondeathray]

@manolito - in some versions of avisynth/vdub combos , I've noticed that you need to specify the full path for LoadCPlugin ffms2.dll in the .avsi for it to work. Worth a try anyways

[manolito]

Yes, worth a try, but also no luck... Same error message.

[TheFluff]

System error 0x5 is ERROR_ACCESS_DENIED.

[poisondeathray]

I thought it was the same error, but my memory failed . I just tested by taking out the full path and it gives error=0x7e , just curious what that one means ? It loads fine with avspmod - ie. it's specific to vdub and ffms2 C-Plugin. Adding full path works for that error

What would cause a 0x5 ? Possibly a permissions issue ?

[TheFluff]

I thought it was the same error, but my memory failed . I just tested by taking out the full path and it gives error=0x7e , just curious what that one means ? It loads fine with avspmod - ie. it's specific to vdub and ffms2 C-Plugin. Adding full path works for that error

126 (0x7E) ERROR_MOD_NOT_FOUND (https://msdn.microsoft.com/en-us/library/windows/desktop/ms681381(v=vs.85).aspx)
The specified module could not be found.

What would cause a 0x5 ? Possibly a permissions issue ?
Usually it's a permissions issue, yes. Dunno what else can cause it.

[StainlessS]

126 (0x7E) ERROR_MOD_NOT_FOUND

It seems to use a lot of external dll's, check it out with Dependency Walker or Groucho2004 Avisynth Info tool (for missing requirements).

[manolito]

Usually it's a permissions issue, yes. Dunno what else can cause it.

I am on XP-32, file system on my system partition is FAT32. This should pretty much rule out a permissin issue.

[Tima]

FFMS2 C-plugin r1110+98 (http://www.mediafire.com/?k3yoexl7xsvqv3m)


Still crashes for me on my samples above (tried VapourSynth only).

[asarian]

Just out of curiosity, why can't FFVideoSource be frame-safe after all these years?! I'm using DGSource again (for my more demanding projects, that use QTGMC and MCTemporalDenoise and such), so I'm okay; but just wondering why that can't happen with FFVideoSource (it's indexing, after all).

[TheFluff]

Just out of curiosity, why can't FFVideoSource be frame-safe after all these years?! I'm using DGSource again (for my more demanding projects, that use QTGMC and MCTemporalDenoise and such), so I'm okay; but just wondering why that can't happen with FFVideoSource (it's indexing, after all).

Nobody really works on it these days. In fact, nobody's done that for years. There are a few corporate users who make sure that it keeps working with new versions of ffmpeg and they also occasionally fix the odd bug, but that's it. As far as I know, supporting interlaced H264 would require some special case code that nobody wants to bother writing. In transport streams there's also timestamp discontinuities (https://github.com/FFMS/ffms2/issues/258) to worry about. Someone might or might not be interested in doing something about that. It's not really hard if you know what you're doing, it's just that nobody wants to bother. It's the same with a bunch of Avs-MT issues like those non-reentrant resizers in Avs-MT that were broken for like a decade until someone solved it in the least sophisticated way possible recently, or that silly QTGMC slowdown thing that's been going on since forever because nobody who actually knows how to debug anything has bothered looking at it.

[asarian]

Nobody really works on it these days. In fact, nobody's done that for years. There are a few corporate users who make sure that it keeps working with new versions of ffmpeg and they also occasionally fix the odd bug, but that's it. As far as I know, supporting interlaced H264 would require some special case code that nobody wants to bother writing. In transport streams there's also timestamp discontinuities (https://github.com/FFMS/ffms2/issues/258) to worry about. Someone might or might not be interested in doing something about that. It's not really hard if you know what you're doing, it's just that nobody wants to bother. It's the same with a bunch of Avs-MT issues like those non-reentrant resizers in Avs-MT that were broken for like a decade until someone solved it in the least sophisticated way possible recently, or that silly QTGMC slowdown thing that's been going on since forever because nobody who actually knows how to debug anything has bothered looking at it.

Thanks. :) That was a very comprehensive answer.

[LigH]

Still unnecessary to full-quote it, for just one sentence as reply... ;)

[Selur]

Still crashes for me on my samples above (tried VapourSynth only).
Same here with Avisynth (Win10) , FFMS2 C-plugin r1110+98 still crashes with UT Video and lagarith samples. (LWLibavVideoSource works)

[TheFluff]

You should probably report problems on Github, not here, if you want to be sure someone sees them. I don't think anyone who actually fixes ffms bugs reads d9 with any regularity anymore.

[Bzor]

It's happiness, 5 days passed!

Hi! I have problem to build FFms2 with shared DLL with Minwg64 in Msys2. This is my config
--prefix=xxx --enable-shared --disable-static CXXFLAGS='-static-libgcc -static-libstdc++ -Wl,-Bstatic -lpthread -lwinpthread'

error: undefined "___imp_pthread_once"

use flags to import static libgcc and libwinpthread. Its working for another source but not working for ffms2.

Its successful when i used config --enbale-static --disable-shared to build only ffmsindex.exe

Am i wrong or is that bugs? Please help!

Thank you!

[jackoneill]

It's happiness, 5 days passed!

Hi! I have problem to build FFms2 with shared DLL with Minwg64 in Msys2. This is my config
--prefix=xxx --enable-shared --disable-static CXXFLAGS='-static-libgcc -static-libstdc++ -Wl,-Bstatic -lpthread -lwinpthread'

error: undefined "___imp_pthread_once"

use flags to import static libgcc and libwinpthread. Its working for another source but not working for ffms2.

Its successful when i used config --enbale-static --disable-shared to build only ffmsindex.exe

Am i wrong or is that bugs? Please help!

Thank you!

I had to patch winpthread when I compiled it static only:

--- mingw-w64-libraries/winpthreads/include/pthread.h 2014-10-26 04:11:33.000000000 +0200
+++ mingw-w64-libraries/winpthreads/include/pthread.h 2014-12-10 14:17:45.542746397 +0200
@@ -82,7 +82,9 @@
/* MSB 8-bit major version, 8-bit minor version, 16-bit patch level. */
#define __WINPTHREADS_VERSION 0x00050000

-#if defined DLL_EXPORT
+/* No __declspec crap needed when winpthreads is static.
+ * In fact, it produces linker errors (can't find __imp_blah). */
+#if defined DLL_EXPORTzzzzzzzzzzz
#ifdef IN_WINPTHREAD
#define WINPTHREAD_API __declspec(dllexport)
#else

[Reino]

FFMS2 C-plugin r1110+98 (http://www.mediafire.com/?k3yoexl7xsvqv3m)
WinXP SP3 on an ancient AMD Athlon XP 3200+ here.
Today I've updated r944+69 to r1110+98, but only to find out that it doesn't work anymore, because AvsPmod and FFPlay now report: Unable to load C Plugin: "ffms2.dll", error=0x5.
So far r944+69 is the latest build that works for me, because I can't test r1015+85 and newer as their downloadlinks don't work anymore.

[TheFluff]

SSE2 and Vista+ are a minimum requirement for a lot of things these days - it's been fifteen years since SSE2 was introduced, so if you want to do anything that requires even a moderate amount of computing power today, you're kind of expected to have it. I don't think anyone (except possibly qyot27) will go out of their way to release builds that work on CPU's without SSE2. If XP support starts requiring even a minuscule amount of developer effort, expect that to disappear as well.

[StainlessS]

Here, Win XP32SP3 C plug r1110+98 working OK here (at least that is the recorded version number that I believe I have, 14,731,264 bytes. Just checked,
is same as one I'm using).

I'm not using AvsPMod and Intel CPU here (Core Duo).

EDIT: OK, Fluffy seems to have pin pointed problem.

[qyot27]

In the interest of full disclosure, I do very little in the way of anything video related on my Coppermine anymore, and the builds are mainly still built for it out of habit and that i686 is a fairly normalized baseline target for 32-bit; and it lets me test stability since older machines run into problems much faster if something starts eating memory for breakfast and sparks a crash. But for the last seven months I've mostly used a Silvermont-based mini-PC for my video tasks (along with most everything else; the Coppermine setup is now mainly a jukebox, storage area, and disc burner). Prices on similar machines are very affordable (read: I bought mine for $170), so the cost argument of staying on really old hardware isn't nearly as powerful as it once was - and it's a lot more powerful than the PIII is, although that should be pretty obvious. I can downscale from 720p to 720x480 with Lanczos4 for encoding with HCenc for DVD authoring and get usually in the 18-23fps range, compared to ~2fps on the Coppermine.

The weird nature of this particular situation makes me think it's something that changed somewhere deep in the MinGW-w64 or GCC parts, which would be a nightmare to untangle (and at some point I'm sure this will happen in regard to XP support; in which case the only hope is that ReactOS reaches general viability* before then). The most optimistic scenario is that I misconfigured something when building those pieces and all I'd have to do is rebuild them to fix everything.

*the key word there being 'general'; it seems to already be more or less capable of running the AviSynth and VapourSynth ecosystems and at least the CLI tools (which shouldn't be a surprise, since Wine has been able to do most of that for years now). It's just the rest of system that presents a challenge for everyday use at the present time.

[Reino]

It seems the lifespan of my secondary computer is really approaching its end, because not only with AviSynth (plugins), but with a lot more software it's getting harder and harder to keep up-to-date.
Thanks for the legacy support this far, qyot27.

[lvqcl]

The weird nature of this particular situation makes me think it's something that changed somewhere deep in the MinGW-w64 or GCC parts, which would be a nightmare to untangle

Try to recompile it with -mstackrealign option. Maybe it'll help, who knows...

[FranceBB]

Sounds kinda weird 'cause the C++ Redistributable 2015 (the last released) works under XP, so, basically, it should run on XP.
I'm gonna try it as soon as I get home.

EDIT: I confirm it works in XP SP4.

p.s it's not a spam, but check MSFN for Win XP mods.

[LoRd_MuldeR]

Sounds kinda weird 'cause the C++ Redistributable 2015 (the last released) works under XP, so, basically, it should run on XP.
I'm gonna try it as soon as I get home.

EDIT: I confirm it works in XP SP4.

p.s it's not a spam, but check MSFN for Win XP mods.

MinGW/GCC uses the MSVCRT.DLL (C-Runtime) that is an integral part of Windows, not the one specific to Visual Studio which needs to be installed separately. So, the Visual C++ redistributable is not required for MinGW.

Also MinGW/G++ does not use Microsoft's MSVCP.DLL (Standard C++ Library), it uses the Libstdc++ by GNU.

Finally, latest Visual Studio can still produce binaries for Windows XP, but does not do so by default. Not sure about latest MinGW (Mingw-w64), but I wouldn't be surprised if they start using API's not preset in XP sooner or later.

And, of course, the compiler (runtime libs) is only one side. If the application code or any of the third-party libs uses API's not present in XP, then the whole thing won't work on XP - regardless what compiler you use.

(BTW: AVX unavoidably requires Windows 7 with SP-1 or later, no matter what. Older Windows versions did not save/restore the AVX registers on task switch)

[qyot27]

Sounds kinda weird 'cause the C++ Redistributable 2015 (the last released) works under XP, so, basically, it should run on XP.
I'm gonna try it as soon as I get home.

EDIT: I confirm it works in XP SP4.

p.s it's not a spam, but check MSFN for Win XP mods.
What does this have to do with anything? The problem being addressed over the last few posts has nothing to do with XP, but with the hardware. It'd most probably have the same crash issue on Windows 7, if a user was determined enough to install Win7 on a Pentium III system (which is possible, just extraordinarily unlikely).

MinGW/GCC uses the MSVCRT.DLL (C-Runtime) that is an integral part of Windows, not the one specific to Visual Studio which needs to be installed separately. So, the Visual C++ redistributable is not required for MinGW.

Also MinGW/G++ does not use Microsoft's MSVCP.DLL (Standard C++ Library), it uses the Libstdc++ by GNU.

Finally, latest Visual Studio can still produce binaries for Windows XP, but does not do so by default. Not sure about latest MinGW (Mingw-w64), but I wouldn't be surprised if they start using API's not preset in XP sooner or later.

And, of course, the compiler (runtime libs) is only one side. If the application code or any of the third-party libs uses API's not present in XP, then the whole thing won't work on XP - regardless what compiler you use.

(BTW: AVX unavoidably requires Windows 7 with SP-1 or later, no matter what. Older Windows versions did not save/restore the AVX registers on task switch)
At least as of MinGW-w64 4.0.4, the only thing that impedes XP support is enabling the secure API when building it, which allows Vista+'s *_s functions. But that's still disabled by default, even in 4.0.5 (and probably 4.0.6, but I haven't checked; not sure about 5.x). 4.0.5 is what I'd switched my toolchain to before FFMS2 and x264 started freaking out, but a couple of GCC 5.3.0's dependencies were also updated at the same time. Perhaps 4.0.6 fixes some of it, maybe not - reading the git history was remarkably unhelpful on trying to figure that out.

[FranceBB]

@qyot27... Didn't know it was about instructions (so CPU-related) instead of software-related when I replied. My bad.
Thank you both (qyot and lord Mulder) for clarifying it. :)

[StainlessS]

Just checked on Comodo forums, and on Mar 02,
ffmsindex.exe has been whitelisted.
So no more false +ve's from Comodo on that.

[Jamaika]

How convert the metadata comments?
Why are comments duplicated to another type metadata 'Movie_More' (©swr)?
I don't see it as standard MOV container.
https://developer.apple.com/library/mac/documentation/QuickTime/QTFF/Metadata/Metadata.html#//apple_ref/doc/uid/TP40000939-CH1-SW43
What does the abbreviation metadata and why prevents the display of information in players?
Can type (©swr) delete with film?

[LigH]

I don't understand your last post, Jamaika... what do you refer to?

Regarding "QuickTime metadata", I do remember that there are applications on Macs which create additional MOV files to source material without altering it, just to be able to manage it in its raw format (e.g. there was a professional DVD Authoring tool "Sonic DVD Creator" which created a metadata MOV in addition to imported MPEG-2 video *.m2v to store their attributes, not multiplexing the m2v into the MOV, only "linking" it). Is that in any way related to your case?

[TheFluff]

Jamaika: I understand most of those words, but I have no idea what you're talking about.

[Jamaika]

Regarding "QuickTime metadata", I do remember that there are applications on Macs which create additional MOV files to source material without altering it, just to be able to manage it in its raw format (e.g. there was a professional DVD Authoring tool "Sonic DVD Creator" which created a metadata MOV in addition to imported MPEG-2 video *.m2v to store their attributes, not multiplexing the m2v into the MOV, only "linking" it). Is that in any way related to your case?
Sorry. I don't know how to specify in their own language.
Rather, it isn't a DVD authoring tool "Sonic DVD Creator".
Anyway, what would it was not, it does not allow the display info of metadata, eg. in MPC-BE. I Wonder, why?

[LigH]

The metadata MOV does not contain any video track. Therefore a video player cannot display video attributes. The video track is in a separate file. The metadata MOV file only links to the separate video track. Most applications will probably not know how to handle linked tracks, they only know contained tracks.

[Jamaika]

THAT is true, but I don't mean metadata tracks. Everything is in a container (name, artist, date, comment and ©swr).
Hmm... I'm reading metadata from MediaInfo.

[LigH]

Ah, you mean metadata tags in different containers.

[rustyconc]

Hi,

I just updated avisynth (v2.6) and the ffms2 plugin files (v2.22). All works well with other videos (e.g. an mp4), but I have whole set of old Indeo 5.1 AVI files that FFVideoSource no longer handles. I reverted to the previous plugin I had installed (2.17) and all worked fine. Is this a deliberate loss or inadvertent?

Thanks

[hydra3333]

Goodness me.

I just visited https://github.com/FFMS/ffms2/releases to download the latest version https://github.com/FFMS/ffms2/releases/download/2.22/ffms2-2.22-msvc.7z for vapoursynth

... and chrome spewed and told me that ffms2-2.22-msvc.7z is malicious and blocked the download.

Other files from github dowloaded fine earlier this morning which suggests it doesn't like ffms2-2.22-msvc.7z specifically.

Anyone else had that ?

[Sparktank]

malicious and blocked

There should be sticky/PSA about freeware and Chrome.
And SourceForge.

[filler56789]

Goodness me.

I just visited https://github.com/FFMS/ffms2/releases to download the latest version https://github.com/FFMS/ffms2/releases/download/2.22/ffms2-2.22-msvc.7z for vapoursynth

... and chrome spewed and told me that ffms2-2.22-msvc.7z is malicious and blocked the download.

Just stop using Chrome :devil: problem solved :)

[hydra3333]

yes. yes, that is an option :)

Other files from github dowloaded fine earlier this morning which suggests it doesn't like ffms2-2.22-msvc.7z specifically.

mostly avoided getting stung (apart from a hack of estonian origin a few years ago which 100% knobbled windows) by not downloading stuff the big crowds say is unsafe.

This one is bemusing since chrome only hates ffms2 on github, so someone has complained about it for some reason ...

[asarian]

Speaking of ffmpeg, at what frame does the following error occur?

[vc1 @ 000001f2d0afa4c0] warning: first frame is no keyframe:01:30

1f2d0afa4c0 = 2,142,394,885,312 decimal, so that can't be the frame number. :)

[LigH]

This may be a high resolution time stamp, in units as specified in the displayed video format's specifications.

[asarian]

This may be a high resolution time stamp, in units as specified in the displayed video format's specifications.

Okay, thx. I'll look into the format some further.

[LigH]

By the way, time stamps don't need to be zero based. Compare against the time stamp of the first GOP to subtract its offset...

To avoid underflows when rewinding (a serious issue in such decks), DigiBeta recordings for professional DVD material often start with a time stamp offset at 1 hour or 10 hours, I learned in a DVD authoring studio.

[TheFluff]

Speaking of ffmpeg, at what frame does the following error occur?

[vc1 @ 000001f2d0afa4c0] warning: first frame is no keyframe:01:30

1f2d0afa4c0 = 2,142,394,885,312 decimal, so that can't be the frame number. :)

000001f2d0afa4c0 is not a timestamp, it's a pointer to some internal data structure and is completely meaningless to 99.9% of the users

of course it's always printed to stderr anyway because it's ffmpeg, they don't like these newfangled "debuggers" and sincerely hate their users

[stranno]

I'm trying to fast-forward a video but i get this error.

"Input audio sample format to TimeStretch must be float"

Audio input is PCM in24 (Apple ProRes video). I had no trouble before with AAC.

Does it have something to do with the audio indexing? Can it be fixed?

[LigH]

Please show us the exact command in your AviSynth script you want to use to "fast-forward".

You should know that a nummerical value of e.g. 3 is of type integer, but 3.0 is of type float, and if a function requires a float parameter, you may have to provide it with a decimal (if the parameter is a variable with an integer value, multiply it with 1.0). But well, who knows if the reason for this error message is at a completely different position ...

[Keiyakusha]

I'm trying to fast-forward a video but i get this error.

"Input audio sample format to TimeStretch must be float"

Audio input is PCM in24 (Apple ProRes video). I had no trouble before with AAC.

Does it have something to do with the audio indexing? Can it be fixed?

Not sure what are you doing and where. And how this is related to FFMS2, but compressed audio such as aac does not have a concept of bits per sample. That could be the reason it worked. So try converting your PCM to float before applying any processing, whatever that is..

[qyot27]

It's the decoding sample format being passed from FFMS2 to TimeStretch. libavcodec decodes AAC to float (read: outputs pcm_f32le), but it won't do anything to PCM that's already in an integer format.

Put ConvertAudioToFloat() between FFMS2 and TimeStretch.

[LigH]

True, I misread a part. It's not related to parameters... :o

[smok3]

Any bleeding edge compiles that would support cineform.mov type of stuff? (Or a ffms2 alternatives that would?)

[LigH]

ffms2 alternatives

Probably "L-SMASH Works (http://forum.doom9.org/showthread.php?t=167435)" (LSMASHSource.dll: LSMASHVideoSource for ISO Media containers like MP4/MOV/3GPP, LwLibavVideoSource in general).

[smok3]

@LigH: thanks, but getting only some green stuff (http://shrani.si/f/1x/zp/2LLNmn6C/capture.png) in vdub window (LSMASHVideoSource and LwLibavVideoSource).
I've tested prores and cineform. Ideas? (win 7)

[sneaker_ger]

It's because L-Smash does not dither down to a format natively supported by AviSynth by default. See README on how to force an 8 bit output format or read up on AviSynth high bitdepth.

[LigH]

Yes, you may have to specify the desired color subsampling and depth explicitly, such deepcolor formats might get decoded into wrongly interpreted pixels when you don't specify a pixel format. Please do some research on your own, I know it has been discussed before...

[smok3]

Thanks,
LSMASHVideoSource("cineform.mov", format = "YUV420P8")
did the trick.
p.s. And yes I admit the research laziness to anything windows related.

[shekh]

@LigH: thanks, but getting only some green stuff (http://shrani.si/f/1x/zp/2LLNmn6C/capture.png) in vdub window (LSMASHVideoSource and LwLibavVideoSource).
I've tested prores and cineform. Ideas? (win 7)

If you just want to pull it into vdub, you may just use my pack.
It does both vfw decoding (ffmpeg select..) and ffmpeg decoding (ffmpeg all..)

[smok3]

@shekh, Thanks, bookmarked, installed, tested. (Actually I was trying to review some of my old x264 encoding scripts, but after looking at that bat mess, mission aborted).

[feisty2]

is it possible to get the QP value of each frame for lossily compressed videos and tag that as some frame property (in vaporsynth)?
I want it cuz I want denoisers to have a self adaptive denoising strength on each individual frame

[LigH]

Great thinking, feisty2; it reminds me on my failed attempt to convince Donald Graft to implement Deblock() into his DG*Decode plugins. I lacked of technical details to explain it convincingly enough.

I remember some AviSynth plugins do use auxiliary "hint" channels to share a few details (e.g. TFM with TIVTC, or MPEG2Source(info=3) with ColorMatrix). But I have no idea how useful that is compared with the VapourSynth design; and they seem to be rather per-clip than per-frame, at least in these examples.

[StainlessS]

If they (frame properties) could accessed in advance, could be written to RT_Stats DBase (or Array) and accessed via Avisynth ScriptClip (or similar, and presumably VapourSynth), for use on frame by frame basis. Depends upon whether or not there is some tool to extract the data in the first place.

[Myrsloik]

is it possible to get the QP value of each frame for lossily compressed videos and tag that as some frame property (in vaporsynth)?
I want it cuz I want denoisers to have a self adaptive denoising strength on each individual frame

I will check to see if this information is still exposed in ffmpeg. I know they've done a lot of cleanups so it may or may not still be available.

[manolito]

@qyot27

Don't know if this is the appropriate thread for my question, but you are probably the one who can answer it...

Using the current FFmpeg version 3.1.2 (rogerdpack build for WinXP) I get a crash immediately if the input is an AVS script. The culprit is autoloading C-Plugins from the AviSynth\plugin folder.

For a long time I have autoladed C-Plugins like your ffms2 or Yadif by using an AVSI which loads the C-Plugin (your ffms2.avsi does this). This has always worked flawlessly until I tried to use FFmpeg v 3.1.2. The previous version by rogerdpack from July 2016 has no problems.

My AviSynth version is the plain vanilla 2.60 which can hardly be considered outdated. What did the FFMpeg devs change to cause this problem? Do I have to use AviSynth+ now to get FFMpeg to work?


Cheers
manolito

[qyot27]

@qyot27

Don't know if this is the appropriate thread for my question, but you are probably the one who can answer it...

Using the current FFmpeg version 3.1.2 (rogerdpack build for WinXP) I get a crash immediately if the input is an AVS script. The culprit is autoloading C-Plugins from the AviSynth\plugin folder.

For a long time I have autoladed C-Plugins like your ffms2 or Yadif by using an AVSI which loads the C-Plugin (your ffms2.avsi does this). This has always worked flawlessly until I tried to use FFmpeg v 3.1.2. The previous version by rogerdpack from July 2016 has no problems.

My AviSynth version is the plain vanilla 2.60 which can hardly be considered outdated. What did the FFMpeg devs change to cause this problem? Do I have to use AviSynth+ now to get FFMpeg to work?


Cheers
manolito
I'm not sure, exactly, but I can reproduce the behavior (with both 2.6 and Plus, so it wouldn't matter there). My guess is that there was something regarding DLL loading security - it may or may not have been in the libavformat AviSynth demuxer itself - that makes it to where AviSynth's plugins won't load if the directory they're in isn't on Windows' PATH. Or if C++ plugins were fine, it may have specifically been because the C plugins were being stored in a different folder than the others (meaning C plugins need to be on the PATH in this scenario, but C++ ones don't).

Correspondingly, if I add the folder that ffms2.dll / FFMS2.avsi / ffmsindex.exe reside in to the PATH, the issue goes away.

I'd actually had a nasty registry corruption issue on my WinXP machine not too long ago, so my plugins folder had disappeared from the PATH and I was hitting the problem. When I tried to use ffmsindex and it told me it couldn't see it, I pretty much realized what was going on. Added the plugins folder to the PATH, tried again, no problems with either 2.6 or Plus.

[manolito]

Thanks qyot27 for the quick reply.

Unfortunately including the "AviSynth\plugins" folder in my path does not make a difference. FFMpeg still crashes (called by AVStoDVD) with a message that Yadif cannot be loaded. If I remove Yadif from the plugins folder, I get the same message about ffms2.

I can live without Yadif, but ffms2 is essential for my workflows. And since the scripts are automatically created by AVStoDVD I do need ffms2 to be autoloaded.


Thanks and cheers
manolito

[qyot27]

Does it error out when not called by AVStoDVD but the folder is on the PATH?

You can try this build of FFmpeg. It's the same one I used to test:
http://www.mediafire.com/download/b588msbb584cp8e/ffmpeg_r81319.7z

If that one works, then it may be a compiler issue or a configuration issue with the build itself.

[Atak_Snajpera]

Guys what do you do to have correct colors with UHD HDR in FFMS2

MPC-HC
http://i.cubeupload.com/vHjdsr.png

FFMS2
http://i.cubeupload.com/H4Nr9m.png

Sample is here -> http://demo-uhd3d.com/fiche.php?cat=uhd&id=144

[manolito]

Does it error out when not called by AVStoDVD but the folder is on the PATH?

You can try this build of FFmpeg. It's the same one I used to test:
http://www.mediafire.com/download/b588msbb584cp8e/ffmpeg_r81319.7z

If that one works, then it may be a compiler issue or a configuration issue with the build itself.


Thanks for this FFmpeg build, but unfortunately it makes no difference. Even when I call FFmpeg outside of AVStoDVD and the AviSynth\plugins folder is in the path, I still get this error message:

E:\Programme\AVStoDVD\FFmpeg>ffmpeg.exe -i f:\download\test.avs i:\test.mpg
ffmpeg version r81319 git-8e8aff8 Copyright (c) 2000-2016 the FFmpeg developers
built on Aug 9 2016 23:50:26 with gcc 6.1.0 (GCC)
libavutil 55. 28.100 / 55. 28.100
libavcodec 57. 51.100 / 57. 51.100
libavformat 57. 46.100 / 57. 46.100
libavdevice 57. 0.102 / 57. 0.102
libavfilter 6. 50.100 / 6. 50.100
libavresample 3. 0. 0 / 3. 0. 0
libswscale 4. 1.100 / 4. 1.100
libswresample 2. 1.100 / 2. 1.100
libpostproc 54. 0.100 / 54. 0.100
[avisynth @ 039589a0] Unable to load C Plugin: "yadif.dll", error=0x7e
(YADIF.avsi, line 1)
f:\download\test.avs: Unknown error occurred

This is my PATH variable:
PATH=E:\Windows\system32;E:\Windows;E:\Windows\system32\WBEM;"E:\Programme\DVD2SVCD\AviSynth 2.5\plugins"

YADIF.avsi consists of just this line:
LoadCPlugin("yadif.dll")

And after removing YADIF from the AviSynth\plugins folder I get the same error for ffms2.


Cheers
manolito

[qyot27]

Why are there " around the path to the plugins folder in the PATH variable? Those are only necessary in the Command Prompt, PATH should properly recognize it without them.

[manolito]

Thanks for pointing this out, I did not know this. I did test if the path variable worked by copying a standalone executable into the AviSynth\plugins folder and calling this executable from a different drive and path. Which worked...

After removing the double quotes FFmpeg does behave differently. Calling FFMpeg with an AVS script as the input directly outside of AVStoDVD now works, but as soon as AVStoDVD calls FFmpeg it does crash again. Very strange...


Cheers
manolito


//EDIT//
The rogerdpack build 3.1.2 behaves exactly the same as your build.

[dipje]

Guys what do you do to have correct colors with UHD HDR in FFMS2

MPC-HC
...image...

FFMS2
...image...

Sample is here -> http://demo-uhd3d.com/fiche.php?cat=uhd&id=144

Just guessing here, but I'm thinking you would need to assume the input is in something like the bt2020 colorspace and you need to convert it / scale it down to whatever you want to encode to or display.. something like bt709/rec709... 'srgb'..

I'm guessing MPC-HC reads or assumes the correct colorspace and converts it while displaying (And thus while making screenshots), and ffms2 just assumes either bt601 or bt709 not doing anything with bt2020 or whatever your hdr vid is in?

edit: As I'm really new to the whole HDR movement and standards I decided to see and try for myself. Downloaded the sample, as well as the 'SDR' version of it.
First things first, I have not managed to replicate the look of the SDR version yet. It seems as if it received exposure changes in editing or something.

Second, I found that frame you posted (around frame no. 3850 in the HDR version, around 1m04 right?) and tested myself. My MPC-HC (and I took the latest nightly to be sure) does not look like your MPC-HC version at all.
My MPC-HC looks like your ffms2 so to speak. It's also the same as ffmpeg / ffplay displays it.

Third, not knowing the standards, (and seeing it is YUV 420 10bit) I was assuming BT2020 matrix - tv range, 2020-10 transfer curve and 2020 primaries. But that doesn't look any better.
The best I can get the HDR version to look (and close to your MPC-HC screenshot) is by assuming it's in BT2020 matrix - tv range, SMPTE 2084 transfer, DCI P3 primaries (although 2020 primaries look close as well).
ffprobe also reports "tv-range, bt2020nc/bt2020/smpte2084".

Since I do stuff in vapoursynth, I end up with something like this:
c = core.lsmas.LWLibavSource(source = r'Sony_4K_HDR_Camp.mp4')

c = core.fmtc.resample(c, w = 1280, h = 720, css = '444', kernel = 'spline36')

c = core.fmtc.matrix(c, mat = "2020", fulls = False, fulld = True, col_fam = vs.RGB)
c = core.fmtc.transfer(c, transs = "2084", transd = "linear", cont = 10)
c = core.fmtc.primaries(c, prims = "dcip3", primd = "709")
c = core.fmtc.transfer(c, transs = "linear", transd = "srgb")


I sample it down to 720p for testing, but I make it YUV 4:4:4 (and fmtconv scales it to 16bit at the same time). I then convert it to 16 bit RGB assuming BT2020 YUV matrix, then I convert it to RGB linear-light assuming smpte 2084 transfer curve. The 2084 curve in fmtconv is scaled to 10000nits while the HDR spec seems to use 1000nits, so the 'cont = 10' at the end scales it all down. Once in linear-light you convert the color primaries to rec709, and finally go from linear-light RGB back to regular srgb-gamma.

The colors and contrast seem to be OK (or ok-ish) but generally I think it's too dark. I don't know if I'm using a wrong curve somewhere or just need to boost the brightness

edit 2: I got the look you were giving in your MPC-HC screenshots by using latest madVR. Looking in the settings and the release description for 'madvr hdr' I get a feeling for what they're doing , and it's no wonder I can't get a 1-to-1 result. Thinking about all this, I'm actually quite happy with how far I got :P (which is the above script but with 2020 primaries instead of dcip3, and the final transfer target not being srgb but also 709. I then use core.std.Levels to boost the gamma and ended up with something like 1.5 to 1.8 that looks nice).
MadVR is doing all sort of dynamic stuff, not simple conversion. I compress the shadows and the highlights, and it has a 'over saturation' protection that tries to preserve the hues when the brightness gets higher.

So madVR is not doing just simple gamma and color-gamut conversions, but has more advanced stuff going on to try to preserve as much detail and get the 'intent' of the HDR data displayed on regular screens. I don't think you will get a 1-to-1 result until someone ports the madvr algo's over into a vapoursynth (or avisynth) plugin :)

[kolak]

ffpmpeg has just got MOV edit list support, so I assume this will also come one day to ffms2?

[burfadel]

I hope ffms2 is still being developed. It actually works better than LSmash-Works for some things, and LSW better for other things. Together, they cover most source files. I did have issues with LSW and ffms2 with .wmv files a couple of weeks ago, but dss2 source worked for those.

[18fps]

I hope ffms2 is still being developed.

Looking at the GitHub it looks like it is developed. But windows binaries are not being produced. I'm stuck with 2.18 since 2.20 can't open prores's movs.

[Myrsloik]

Looking at the GitHub it looks like it is developed. But windows binaries are not being produced. I'm stuck with 2.18 since 2.20 can't open prores's movs.

The problem is mostly that all developers hate developing FFMS2. Me included, and I even started it. It's just no fun because changing one line of code takes 5 min of thinking and then 10+ hours of testing. Because that's how fragile the thing is.

And even if everything works chances are good FFmpeg will change its own behavior next week anyway. Things like this is why I'd rather spend my time on VapourSynth or even my real job which feels more rewarding than this. I tried to compile a new binary yesterday but ragequit because of msys. That's how annoying it is just to compile it...

[qyot27]

And I've not gotten back to building the C plugin because sometime between December and May(-ish), something started causing Access Violations and I've not had the patience to attempt bisecting it.

I'm pretty sure issue #260 is actually the same GCC weirdness that I finally got to the bottom of in this thread (http://forum.doom9.org/showthread.php?p=1779858#post1779858). Or it stems from the change in the symbol trickery ifdef @Ln.67 in ffms.h to assuming _WIN32 vs. MSC_VER like it used to (the C plugin branch preserves it as MSC_VER because it breaks compilation of the C plugin otherwise). Or even both if we're talking about a 64-bit build here.

[Myrsloik]

And I've not gotten back to building the C plugin because sometime between December and May(-ish), something started causing Access Violations and I've not had the patience to attempt bisecting it.

I'm pretty sure issue #260 is actually the same GCC weirdness that I finally got to the bottom of in this thread (http://forum.doom9.org/showthread.php?p=1779858#post1779858). Or it stems from the change in the symbol trickery ifdef @Ln.67 in ffms.h to assuming _WIN32 vs. MSC_VER like it used to (the C plugin branch preserves it as MSC_VER because it breaks compilation of the C plugin otherwise). Or even both if we're talking about a 64-bit build here.

I'm curious, will you continue with your own fork if I add proper avs+ high bitdepth support?

[qyot27]

My work C-plugin side is near entirely to do with being able to build the plugin with GCC, because that allows it to easily fit into the rest of my cross-compilation environment (and keeps the number of things I have to use Visual Studio for to an absolute minimum).

[Myrsloik]

Have a current 64bit build (https://dl.dropboxusercontent.com/u/73468194/ffms2-2016-10-03.7z). Adds high bitdepth output for avs+. Enjoy broken 10bit files or force the output colorspace to YUV420P16 or whatever. May shit itself unless you use the latest avs+mt build. Or maybe not. I didn't test it.

Should be safe for VS use without disclaimers.

[Myrsloik]

Here's a combined 32 and 64 bit (https://dl.dropboxusercontent.com/u/73468194/ffms2-2016-10-07.7z) build.

Consider it RC level. It removes one horrible hack that broke a lot of files in the past so retest anything that wasn't working before (especially lossless codecs).

Since threads this size are horrible to navigate START CREATING PROPER ISSUES IN GITHUB. And host sample files where they can be found for a long time. That really helps.

I will from now on only investigate issues brought to my attention on the issue tracker or on IRC. Navigating this thread is impossible.

[Abs62]

Myrsloik
Where I can take avisynth.h to compile last git version? VideoInfo struct in headers from AviSynth 2.6 FilterSDK don't include needed functions and enums.

[Myrsloik]

Avs+ MT branch. But why do you need it? I just gave you a compile of the latest version.

[Abs62]

It is my habit - to test last git FFMS2 with last git FFMpeg libraries every week. ;)

[Myrsloik]

Here's a combined 32 and 64 bit (https://dl.dropboxusercontent.com/u/73468194/ffms2-2016-10-07.7z) build.

Consider it RC level. It removes one horrible hack that broke a lot of files in the past so retest anything that wasn't working before (especially lossless codecs).

Since threads this size are horrible to navigate START CREATING PROPER ISSUES IN GITHUB. And host sample files where they can be found for a long time. That really helps.

I will from now on only investigate issues brought to my attention on the issue tracker or on IRC. Navigating this thread is impossible.

This is a reminder. Test my build because I'll try to make a release of it sometime next week unless it's horribly broken.

[pinterf]

Thanks for the build!

I will report this on github with source files.

Tested with my latest avs+ dev build, 32 bits.

- v210 input: mapped to yuv422p10, ok.
- r210 format, I don't know if it is intended to work, I got message: FFVideoSource: No suitable output format found
- Tried may prores encoded files, mostly ok (mapped to yuv 10 bit) (yuv422p10le, yuv444p10le: apcn (sq), apch (hq), ap4h)

But one of prores ap4h profile encoding was failed to be recognized.

This one gets mapped to RGB32

ffmpeg -ss 00:35:57 -i film1.mov -to 00:00:10 -c:v prores_ks -profile:v 4 -pix_fmt yuva444p10le -framerate 16 -acodec copy ProresYuva444p10le_a.mov

This one is properly mapped to yuv444p10:

ffmpeg -ss 00:35:57 -i film1.mov -to 00:00:10 -c:v prores_ks -profile:v 4 -pix_fmt yuva444p10le -alpha_bits 0 -framerate 16 -acodec copy ProresYuva444p10le_b.mov

[Myrsloik]

Thanks for the build!

I will report this on github with source files.

Tested with my latest avs+ dev build, 32 bits.

- v210 input: mapped to yuv422p10, ok.
- r210 format, I don't know if it is intended to work, I got message: FFVideoSource: No suitable output format found
- Tried may prores encoded files, mostly ok (mapped to yuv 10 bit) (yuv422p10le, yuv444p10le: apcn (sq), apch (hq), ap4h)

But one of prores ap4h profile encoding was failed to be recognized.

This one gets mapped to RGB32

ffmpeg -ss 00:35:57 -i film1.mov -to 00:00:10 -c:v prores_ks -profile:v 4 -pix_fmt yuva444p10le -framerate 16 -acodec copy ProresYuva444p10le_a.mov

This one is properly mapped to yuv444p10:

ffmpeg -ss 00:35:57 -i film1.mov -to 00:00:10 -c:v prores_ks -profile:v 4 -pix_fmt yuva444p10le -alpha_bits 0 -framerate 16 -acodec copy ProresYuva444p10le_b.mov

I think I know why that happens. It's trying to preserve the alpha plane so it picks the only known output format with alpha. Give me a sample and I'll see if I can add proper alpha support or at least make it less bad...

[pinterf]

Reported and my 5 sec samples are available.
https://github.com/FFMS/ffms2/issues/273

[Myrsloik]

Reported and my 5 sec samples are available.
https://github.com/FFMS/ffms2/issues/273

So I'm poking the alpha stuff. How come you didn't add Y+A formats? FFmpeg has it so I'm curious. Not that I think anything actually uses it but still...

[pinterf]

So I'm poking the alpha stuff. How come you didn't add Y+A formats? FFmpeg has it so I'm curious. Not that I think anything actually uses it but still...

Well, I added, they are called CS_YUVA....
Anyway, in the latest dev build (on my form or in my pull request of the main MT branch) you can strip alpha from avisynth+ by RemoveAlphaPlane, so it's good if e.g. YUVA444P10 is returned.

[Myrsloik]

Well, I added, they are called CS_YUVA....
Anyway, in the latest dev build (on my form or in my pull request of the main MT branch) you can strip alpha from avisynth+ by RemoveAlphaPlane, so it's good if e.g. YUVA444P10 is returned.

I mean that FFmpeg also has YA8 and YA16 (monochrome+alpha). Just started adding them and then realizes avs+ doesn't have them.

I've added alpha support now so just a bit of testing to see if it fixes your clip and then a new build.

[Myrsloik]

Here's another 2.23 RC (https://dl.dropboxusercontent.com/u/73468194/ffms2-2016-10-10.7z)!

It adds support for all alpha formats in avs+ as well. TEST HARDERRRRRRRRRRRRR!!!!!!1111

[pinterf]

Great! It shows YUVA444P10.

For the earlier test you mentioned that avisynth's rgb32 was chosen as the nearest matching format, having alpha plane. Since the source was 10 bits, was it intentional choosing RGB32 instead of RGB64?

[Myrsloik]

Great! It shows YUVA444P10.

For the earlier test you mentioned that avisynth's rgb32 was chosen as the nearest matching format, having alpha plane. Since the source was 10 bits, was it intentional choosing RGB32 instead of RGB64?

It picked RGB32 since it was the only output format with alpha. I didn't add any new packed formats for output since planar is the future (and I didn't feel like individually handling the packed ones).

All possible output formats are in the source here (https://github.com/FFMS/ffms2/blob/master/src/avisynth/avssources.cpp#L270).

[Myrsloik]

2.23 has been released. Everyone should update since it fixes stuff. Except for you XP users. HAHAHAHAHAHAHAHAHA

[ndjamena]

2.23 doesn't work for me AT ALL.

Avisynth/VirtualDub throws an access violation, while ffmsindex simply crashes at 0%.

[Myrsloik]

2.23 doesn't work for me AT ALL.

Avisynth/VirtualDub throws an access violation, while ffmsindex simply crashes at 0%.

Fixed binaries will be up soon. The x64 version still works though.

[Myrsloik]

Fixed binaries have been uploaded.

[FranceBB]

@myrsloik... except for you, XP users
Never say never. I grabbed the source code, removed vapour synth support, and I'll compile it to make it work with XP x86 ;)

[GMJCZP]

@myrsloik...
Never say never. I grabbed the source code, removed vapour synth support, and I'll compile it to make it work with XP x86 ;)

Could you upload it please?

[StainlessS]

I'll compile it to make it work with XP x86

You da man, FranceBB, Danke Sehr [some people just dont care bout us poor XP users] :)

[FranceBB]

I will definitely upload it. Just give me some time because they didn't include every header in the master project and I'm adding them manually.

[GMJCZP]

Thank you, FranceBB. I will be awaiting. :D

[FranceBB]

FFMS2 v 2.23 - Windows XP

Link removed

Yep, it's working! ;)
There are several dlls you'll need to put in your plugin folder because FFMS2 uses some APIs that are not natively available in XP.
(you may get some "weird" error at the startup, but it's just a warning, it will load)

Dlls are x86 only.

Enjoy! ;)



http://www.msfn.org/board/uploads/monthly_2016_10/ffms2.png.f7471164e5648676cebc2fb649386533.png

[real.finder]

I test the one from https://github.com/FFMS/ffms2/releases with winxp in VM and work!

maybe Myrsloik joking!

[qyot27]

FFMS2 C-plugin 1140+101 (http://www.mediafire.com/?wkzc7249b6u8d6r)

Optimized for Pentium-III and SSE (32-bit)
Optimized for Core2 (64-bit)

ffmpeg version r82048 git-dfe7e55 Copyright (c) 2000-2016 the FFmpeg developers
built with gcc 6.2.0 (GCC)
libavutil 55. 32.100 / 55. 32.100
libavcodec 57. 63.103 / 57. 63.103
libavformat 57. 52.100 / 57. 52.100
libavfilter 6. 64.100 / 6. 64.100
libavresample 3. 0. 0 / 3. 0. 0
libswscale 4. 1.100 / 4. 1.100
libswresample 2. 2.100 / 2. 2.100
libpostproc 54. 0.100 / 54. 0.100

32-bit configuration:
--prefix=/home/qyot27/win32_build
--cross-prefix=i686-w64-mingw32-
--enable-gpl
--enable-version3
--disable-w32threads
--enable-avresample
--disable-encoders
--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
64-bit configuration:
--prefix=/home/qyot27/win64_build
--cross-prefix=x86_64-w64-mingw32-
--enable-gpl
--enable-version3
--disable-w32threads
--enable-avresample
--disable-encoders
--disable-muxers
--disable-doc
--disable-debug
--disable-devices
--disable-avdevice
--cpu=core2
--extra-cflags='-march=core2'
--target-os=mingw32
--arch=x86_64

Using the AviSynth+ headers currently causes Access Violations (which I've been trying to debug), so it's still using the old 2.6 header it always has.

[Thunderbolt8]

this might be a stupid question, but where can I find FFV1 so that I can use it as external codec in other kinds of video editing software?

[qyot27]

this might be a stupid question, but where can I find FFV1 so that I can use it as external codec in other kinds of video editing software?
Either you encode it through ffmpeg.exe, or ffdshow-tryouts VfW interface (although ffdshow is way, way outdated; you can't use FFV1v3, you're restricted to v1).

[filler56789]

FFMS2 C-plugin 1140+101 (http://www.mediafire.com/?wkzc7249b6u8d6r)

Many :thanks: again.

I switched to your C-plugin "ages ago" :cool: , and I never looked back :)

[TheRyuu]

FFMS2 v 2.23 - Windows XP

https://drive.google.com/file/d/0BzH7YVbfkU3oWVMzM1RpRWtHblU/view?usp=sharing

Yep, it's working! ;)
There are several dlls you'll need to put in your plugin folder because FFMS2 uses some APIs that are not natively available in XP.
(you may get some "weird" error at the startup, but it's just a warning, it will load)

Dlls are x86 only.

Enjoy! ;)

The official build works on XP. I've no idea how you're building this but it looks very very wrong with those included dependencies. What exactly is wrong with linking to the static runtime? Why are you including Windows system files?

In any case I cannot recommend anyone use this since the official builds should still work perfect fine with XP and don't contain the dll hell that this does. Using the system dll's from this package also has the potential to be dangerous.

[manolito]

FFMS2 C-plugin 1140+101 (http://www.mediafire.com/?wkzc7249b6u8d6r)


Thanks so much for this version, works perfectly on my WinXP Non-SSE2 computer... :thanks:

So far I was using version r1103 because the followup version FFMS2 C-plugin r1110+98 crashed right on startup. But this new version is perfect.
And I've not gotten back to building the C plugin because sometime between December and May(-ish), something started causing Access Violations and I've not had the patience to attempt bisecting it.

Looks like you sorted out these problems, and I really hope that you will continue to provide ffms2 C-Plugins for us poor XP users.

Except for you XP users. HAHAHAHAHAHAHAHAHA
Funny how such a very disrespectful remark triggered a lot of activity in this area...


BTW I tested the official Myrsloik release and the FranceBB release on my old Non-SSE2 machine, and they both did not work. Probably because they both expect a CPU with SSE2 capability.


Cheers and thanks again
manolito

[TheFluff]

Most things started requiring SSE2 years ago. There really isn't much benefit to supporting 15 year old CPU's when SSE2 brings so much useful stuff.

XP is kinda the same, nobody wants to test that shit and maintain additional codepaths (however few they might be) for a 15 year old OS that like three people on d9 use (it's the same three or four people who pop up every time this gets brought up). It's just not worth the effort, so if you want support you better provide it yourself - and do it right, don't ship with this huge pile of DLL garbage you found God knows where.

Sticking to XP is pure obstinacy at this point. If you're concerned about UGH EVIL M$!!! business practices you could just switch to Linux - while it has its own issues, not supporting modern software on old hardware isn't one of them. There's a reason we don't respect XP users: if you insist on using an ancient OS, you should expect to have to use ancient software with it. It's your choice to remain stuck in the past, nobody's forcing you to do it.

[FranceBB]

Use the official ones, don't use mine. I'll remove the link.

Edit: link removed.

Anyway, I'm sure I tried a previous releases (the test build he released before the official ones) and they didn't work in XP saying "it's not a valid C plugin". That's why when he released the new stable version, I didn't even download it, because I was sure they wouldn't have been working anyway. Then I read the comment, so... xD
Anyway, since the official ones work, there's no need to use mine, so I removed the link ;)
Thank you for supporting XP

[qyot27]

Looks like you sorted out these problems, and I really hope that you will continue to provide ffms2 C-Plugins for us poor XP users.
The problem hasn't really been sorted out (I said I was still getting Access Violations when using a couple of the patches not included in the newest build), but whether the problem with Access Violations I was referring to getting hit by in the first half of the year is the same problem with them I'm seeing now, I don't know.

[StainlessS]

It's strange what some people get their knickers in a twist over.
Come on Fluffy, stop living in the past and get on with your own life
(and let others get on with theirs).

[Myrsloik]

You're right, I shouldn't have posted those statements. Without a trigger warning (http://forum.doom9.org/showthread.php?t=127037). I'm so sorry about that. It's really great that we can settle this in a civilized and progressive way.

[FranceBB]

Myrsloik:
TRIGGER WARNING

The posts contained in this thread may be very upsetting for users of old operating systems


lol...
Well, now we have been warned xD

[GMJCZP]

Thank you for your builds, friends.

[Emulgator]

Because I have to maintain and run useful, but partly abandoned, and beautifully working software
from many different years across 8 different machines ranging from 2x XP32ProSP2, 3x XP32ProSP3, 2x Win7U64, 1x Win10...
Many thanks for the joint efforts to support XP, older hardware and the new stuff !

[Kein]

Original:


Audio
ID : 2
Format : AAC
Format/Info : Advanced Audio Codec
Format profile : LC
Codec ID : 40
Duration : 5mn 8s
Source duration : 5mn 7s
Bit rate mode : Constant
Bit rate : 192 Kbps
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 KHz
Compression mode : Lossy
Stream size : 7.19 MiB (1%)
Source stream size : 7.19 MiB (1%)
mdhd_Duration : 308000


Processed through FFMS2:

https://i.imgur.com/MilYKbJ.png

Is it, um, supposed to output it like that, pardon the dumb question?

Same recording opened through Vdub's FFMPEG's plugin:

https://i.imgur.com/ZTFWESc.png

[dipje]

what is weird with this output? That it outputs float?

Those audio compression formats are actually always something 'like float' internally. They most often don't have a concept of 'bitdepth' like hard PCM has.

So most decoders output to float if the other side supports it.
You see from that Vdub FFMPEG plugin screenshot that it also outputs to float (fltp) but the plugin directly converts the float to 16-bit integer.

The differences in length I wouldn't worry too much about. Most readers estimate the length by using the detected bitrate and such.

FFMS2 uses the index so it should know the exact number of samples so I'm betting it's the most precise length, the others lengths are estimates.

I (always) might be wrong though :P

[tebasuna51]

I (always) might be wrong though
Nope, you are (here) right.

[leoenc]

Let's say I don't need indexing. How difficult would it be to disable it in the code? Is it completely rooted in the design of ffms?
Is there any reason to expect problems when not indexing? Considering ffms is only used to decode the full source linearly. No trimming, no filters.

[Groucho2004]

Is it completely rooted in the design of ffms?Yes (pretty sure).

Is there any reason to expect problems when not indexing?The decoder won't work.

Considering ffms is only used to decode the full source linearly. No trimming, no filters.
In that case use DSS or AVIsource, no indexing required.

[LigH]

Yes, indexing is a quite important part of FFMS2, it will not rely on container formats having any keyframe index at all, but instead gather positions of all keyframes on its own, which is necessary for quick seeking across the whole movie to be able to know the decoding start position of each GOP (this is even more important when decoding with several threads).

But you can use FFVideoSource(cache=false); in this case, no cache file will be generated, instead a keyframe index will be kept in RAM. Still, it needs to be generated, each time you run the script.

If you don't want indexing at all, but rely on the container having a valid keyframe index (or a source filter handling the source format anyway), you have to use a different source filter. AviSource will use a keyframe index chunk in AVI containers. LSMASHVideoSource does this for ISO Media containers (MP4, MOV, 3GPP...). DSS2 in LAV Filters mode will use a local copy of LAV Filters and rely on their wits to handle the source format. And any DirectShow related source filter will rely on DirectShow ... (usually an "optimistic" solution).

[Myrsloik]

There's basically only one container where you most of the time don't need an index: AVI

This is under the assumption that the container index is correct and that dropped frames duplicate the previous frame. But with all these restrictions you can (more or less) just use the ffmpeg api directly without doing any fancy tricks.

[leoenc]

In that case use DSS or AVIsource, no indexing required.

DSS doesn't support 10-bit with AVIsynth+. ffms does.

[LigH]

Well, if ya ain't got no time for a keyframe index, ya ain't got time for optimal quality either. ;)

[leoenc]

Well, if ya ain't got no time for a keyframe index, ya ain't got time for optimal quality either. ;)

You have a point:)
You can't rush art...

[Myrsloik]

Here's the RC for FFMS 2.23.1 (https://dl.dropboxusercontent.com/u/73468194/ffms2-2.23.1-msvc.7z). The only change is that it's been compiled with a recent FFmpeg which should fix some issues. For example conversion to planar RGB output now works properly.

Report success/failure. I'll make the release official if nothing is broken.

[Atak_Snajpera]

Quick question. Is FFM2 v2.23.1 with Interlaced AVC footage still reports double number of frames?

[dipje]

@Myrsloik It's been a while since I tried FFMS2 builds. I tested 2.23.1 x64 through Vapoursynth. My usual tests are to see if it opens variants of Cineform, Prores and DNXHD OK or not.

I tried Cineform YUV422 P10, Cineform RGB, Prores HQ (422 P10), Prores 4444 without alpha (444 P10) and Prores 4444XQ with and without alpha (444 P10, recently added to ffmpeg so unknown vtag in previous ffms2 builds), and DNXHD 422 P10 and DNXHD 444 P10.

All open OK, but I have issues with Cineform RGB. A recent ffmpeg build (ffprobe) reports it as gbrap12le(10 bpc, bt709, progressive). I see that as planar RGB with alpha (which sounds correct). I don't get why the 'p12' and then the '10 bpc'. Cineform is often named as '12bit RGBA' while internally everything works as 10bpc as far as I know.

ANYWAY (I digress), the issue I have is that if I just try to open it without any special parameters, Vapoursynth (or ffms2, don't really know) gives an error 'Resize error 1026: RGB color family cannot be YUV'. The pixel format of the clip is reported as vs.RGB48. I only get the error while trying to preview / display the clip in Vapoursynth Editor. If I just 'run' the script VapoursynthEditor reports a valid script with RGB48 output. It seems as if it actually gives YUV data but reports it as RGB or the other way around or something? If I open the .vpy script in VDFilterMod (with RGB48) I just get the correct video showing. It seems as if the video output is OK, but wrongly tagged that trips up the preview-code or the resizers in Vapoursynth / VapoursynthEditor.

(I know realize this might also be VapoursynthEditor related which of course is not an official part of Vapoursynth).

If I add the 'format = vs.RGB48' or 'format = vs.RGB30' options the script still won't display in VapoursynthEditor, but if I add 'format = vs.YUV444P16' or 'format = vs.YUV444P10' the script opens and displays fine n VapoursynthEditor. But I don't know if I'm loosing some data or precision now? (Inside of FFMS2 the clip is apparently RGB '12bit' which it puts in RGB48, so if I add the format parameter it gets converted 'inside FFMS2' before being passed to Vapoursynth I guess, so the only thing I'm loosing in precision is RGB to YUV444 conversion I guess.

edit: Tried with L-Smash r921 (latest in the dropbox folder as of now) and it crashes on the Cineform RGB (RGBA) and the prores 4444 XQ Alpha file, so l-smash seems to have an issue with alpha channels so I can't compare. FFMS2 wins for now :)

[Myrsloik]

@Myrsloik It's been a while since I tried FFMS2 builds. I tested 2.23.1 x64 through Vapoursynth. My usual tests are to see if it opens variants of Cineform, Prores and DNXHD OK or not.
...

Are you really using the latest versions of everything? That Vapoursynth Editor issue sounds familiar

[Mystery Keeper]

L-Smash doesn't set correct matrix property for the clip after conversion. It confuses VS internal resize plugin which is used in VSEditor for preview.

[dipje]

I might have an outdated VapoursynthEditor on this machine, hold on let me update (since it only happened with rgb-a with ffms2 didn't think of anything else).

edit: Nope, that's not it. Latest r13 vs editor: Error on frame 0 request: Resize error 1026: RGB color family cannot be YUV

[VS_Fan]

Here's the RC for FFMS 2.23.1 (https://dl.dropboxusercontent.com/u/73468194/ffms2-2.23.1-msvc.7z). The only change is that it's been compiled with a recent FFmpeg which should fix some issues. For example conversion to planar RGB output now works properly.

Report success/failure. I'll make the release official if nothing is broken.
Good: It's working fine reading FFV1 videos (Versions 1 and 3). Previous release of FFMS2 (2.23) crashed immediately.

Thanks

[Myrsloik]

Now it's officially released as 2.23.1. Everyone should update. Should actually be usable as a high bitdepth image source now. Kinda.

[dipje]

So my yuv/rgb issue is classified as a problem with VapoursynthEditor ?

Since it happens only with ffms2 and only with Cineform RGB I thought it was something funky ffms2 was signaling. (Something like 'hey Cineform, that is yuv p10, but then not expecting that recent ffmpeg/libavcodec versions are returning RGB p10 or RGB p12 or something like that )

[Mystery Keeper]

So my yuv/rgb issue is classified as a problem with VapoursynthEditor ?

Since it happens only with ffms2 and only with Cineform RGB I thought it was something funky ffms2 was signaling. (Something like 'hey Cineform, that is yuv p10, but then not expecting that recent ffmpeg/libavcodec versions are returning RGB p10 or RGB p12 or something like that )There's no problem with VapourSynth Editor. There's problem with L-SMASH.
Instead ofres = core.lsmas.LWLibavSource(a,threads = 1,format = "RGB48")Usesrc_file = r"D:\vstests\遊魂 2 -you're the only one- 遊戲開場動畫（中文字幕版）.mp4"
src = core.lsmas.LWLibavSource(src_file, threads = 1)
src = core.resize.Spline16(src, format=vs.RGB48)

[LigH]

Is FFIndex (either in ffms2.dll or via ffmsindex.exe) able to support a list of VOB segments as source (like DGMPGDec does), if not even an IFO (ideally with a PGC/angle definition, or at least a PGC/angle VOB set stripped by the ripper in IFO/movie mode or PGCDemux), and an MPLS Blu-ray playlist?

If not yet ... where is the recommendable place to add such a feature request?
__

P.S.: Exists already... (http://code.google.com/p/ffmpegsource/issues/detail?id=78)

It's been on the todo list for ages, issue #33 (http://code.google.com/p/ffmpegsource/issues/detail?id=33) is an even older feature request for the same thing.

Phew, 4 years ago already. And since converters are moving towards 64 bit, the existence of source plugins supporting DGMPGDec indexes (*.d2v) could be useful. :rolleyes:

[dipje]

There's no problem with VapourSynth Editor. There's problem with L-SMASH.


.. but we're talking about ffms2 here, not l-smash.

[Jamaika]

@Myrsloik It's been a while since I tried FFMS2 builds. I tested 2.23.1 x64 through Vapoursynth. My usual tests are to see if it opens variants of Cineform, Prores and DNXHD OK or not.

I tried Cineform YUV422 P10, Cineform RGB, Prores HQ (422 P10), Prores 4444 without alpha (444 P10) and Prores 4444XQ with and without alpha (444 P10, recently added to ffmpeg so unknown vtag in previous ffms2 builds), and DNXHD 422 P10 and DNXHD 444 P10.

All open OK, but I have issues with Cineform RGB. A recent ffmpeg build (ffprobe) reports it as gbrap12le(10 bpc, bt709, progressive). I see that as planar RGB with alpha (which sounds correct). I don't get why the 'p12' and then the '10 bpc'. Cineform is often named as '12bit RGBA' while internally everything works as 10bpc as far as I know.

If I add the 'format = vs.RGB48' or 'format = vs.RGB30' options the script still won't display in VapoursynthEditor, but if I add 'format = vs.YUV444P16' or 'format = vs.YUV444P10' the script opens and displays fine n VapoursynthEditor. But I don't know if I'm loosing some data or precision now? (Inside of FFMS2 the clip is apparently RGB '12bit' which it puts in RGB48, so if I add the format parameter it gets converted 'inside FFMS2' before being passed to Vapoursynth I guess, so the only thing I'm loosing in precision is RGB to YUV444 conversion I guess.

edit: Tried with L-Smash r921 (latest in the dropbox folder as of now) and it crashes on the Cineform RGB (RGBA) and the prores 4444 XQ Alpha file, so l-smash seems to have an issue with alpha channels so I can't compare. FFMS2 wins for now :)
Never converts RGB48 to RGBxx CineForm, ProRes or DNxHD. This is absurd.
There are limitations with the colormatrix. ProRes is always in RGB BT601 and CineForm BT709.
The sony vegas 14 is illegal and incorrect operation. Even using the V210 or R210 then I would use yuv422p10le.
In my opinion this is not a problem editors only muxing encoders.

[Myrsloik]

Phew, 4 years ago already. And since converters are moving towards 64 bit, the existence of source plugins supporting DGMPGDec indexes (*.d2v) could be useful. :rolleyes:

It's stuck in "patches welcome" land. I never need it and now we have d2vsource as well...

[LigH]

... for VapourSynth. And what do users of AviSynth+ 64-bit use?

:eek: Oh, there is one (http://forum.doom9.org/showthread.php?p=1374605).

[Reel.Deel]

... for VapourSynth. And what do users of AviSynth+ 64-bit use?

:eek: Oh, there is one (http://forum.doom9.org/showthread.php?p=1374605).

MPEG2DecPlus: https://github.com/chikuzen/MPEG2DecPlus
Binary here (https://kuroko.fushizen.eu/bin/mpeg2decplus-0.1.1.zip); this version is for AVS+ only, support for avs 2.6 was added but you'll have to compile it yourself.

[dipje]

Never converts RGB48 to RGBxx CineForm, ProRes or DNxHD. This is absurd.
There are limitations with the colormatrix. ProRes is always in RGB BT601 and CineForm BT709.
The sony vegas 14 is illegal and incorrect operation. Even using the V210 or R210 then I would use yuv422p10le.
In my opinion this is not a problem editors only muxing encoders.

Not sure what you're saying here. I'm trying to load Cineform files.
A simple core.ffms2.Source() seems to return RGB48 for the Cineform files (reported as 12bpp RGB, so I guess it makes it 16bpp RGB because no support for 'RGB36'), but somehow still sets the format-tag to something YUV based which trips up the resizers in Vapoursynth which means I can't convert / resize it to anything.

edit:
Btw: (not to try to prove you wrong, but more to explain to me how it could be :))
I'm in After Effects (which doesn't understand the concept of YUV, it's completely RGB compositer), I make a little comp, export it yo ProRes 4444.
With ffms2 I load the file into Vapoursynth which returns it as '4444'. I convert it with fmtconv to RGB _with specifying the bt709_ color matrix. The end result in RGB is _exactly_ the same as my After Effects start. So the file seems to be bt709.
Ffmpeg had a time (or still does?) where it writes incorrect bt601 matrix-tags in the output file for ProRes, but those are ignored (in FCPX and the Adobe suite at least) anyway.

As another example, I can load a .MTS AVCHD file from one my cameras, which opens as YUV420P8. I use fmtconv to 'convert' it to YUV422P10. That YUV422P10 I pass to ffmpeg to encode to prores.
When I then load the original .MTS file and my ffmpeg-generated .mov file in After Effects and toggle the layers on and off, I see no differences. Which to me also seems to suggest the Prores data is bt709 and being interpreted as bt709. (The AVCHD .mts file is bt709 for sure).

[Jamaika]

Not sure what you're saying here. I'm trying to load Cineform files.
A simple core.ffms2.Source() seems to return RGB48 for the Cineform files (reported as 12bpp RGB, so I guess it makes it 16bpp RGB because no support for 'RGB36'), but somehow still sets the format-tag to something YUV based which trips up the resizers in Vapoursynth which means I can't convert / resize it to anything.
Maybe yes, maybe no.
I don't like to use Cineform becose the codec leaves sharp edges when converting RGB to YUV or YUV to RGB.
Examples of conversion in Sony Vegas 14. I do not have the ability to change parameters color range and matrix:
RGB48 to BlackMagic R210 --> The result far removed from the source. All colors changed.
RGB48 to Sony V210 --> Changed color range with PC to TV. Supposedly as standard.
RGB48 to Cineform yuv422p10le --> OK
RGB48 to Magix_prores_hq --> Changed color range with PC to TV. Supposedly as standard.

PS Codecs 10/12 bit don't have a color matrix bt2020nc.;)

[dipje]

Well, that's all fine and all, but it doesn't explain why I can't convert or resize Cineform RGB loaded files in Vapoursynth.
Saying why you don't like a codec doesn't help in figuring out if there is a bug in Vapoursynth, ffms2 or in my process :).

(btw, no color casts or changes here. Compared the native Cineform encoder/decoder in Adobe suite to other near-lossless intermediate codecs that I have access to (DNHD/DNXHR is now native in Adobe suit as well) and looked at them through 'difference maps'. No sharp edges and no visual differences at all. Looking at difference-maps when testing yuv422 codecs will of course show the differences at the edges in color-details because of the lower chroma resolution, but all yuv422 codecs have that. ffmpeg prores_ks with -q:v 3 together with the mirazon-prores suite on PC actually gave the least differences, specially considering the bitrate. But I have to use an outdated abonded 3rd party prores-codec to export it from Adobe suite and other programs. Cineform had a bit more differences, but they were much less in intensity and very natural over the image. Looking at the image while pixel-peeping I rated them in Cineform-first, prores 2nd, dnxhd last. The cineform files were a bit bigger though so it's a bit cheating).

[Selur]

What's the latest C Plugin version of ffms2 and where to get it?

[Groucho2004]

What's the latest C Plugin version of ffms2 and where to get it?qyot27 is the one who builds these so you go back a few posts in this thread and eventually arrive at this one (https://forum.doom9.org/showthread.php?p=1783312#post1783312). :)

[Selur]

Thanks totally overlooked that when I was scrolling back the posts,.. :)

[Selur]

Small question when using FFmpegSource in Vapoursynth.
When I use:
clip = core.ffms2.Source(source="C:/Users/Selur/Desktop/Test.ts",cachefile="H:/Temp/ts_6172c2a2969c38a25728d49450effe0d_491.ffindex",fpsnum=50)
my source get's decoded properly, when set a format using:
clip = core.ffms2.Source(source="C:/Users/Selur/Desktop/Test.ts",cachefile="H:/Temp/ts_6172c2a2969c38a25728d49450effe0d_491.ffindex",fpsnum=50,format=vs.YUV420P8)
I get an error.
The whole script is:
# Imports
import vapoursynth as vs
core = vs.get_core()
# Loading Plugins
core.std.LoadPlugin(path="G:/Hybrid/vsfilters/SourceFilter/FFMS2/ffms2.dll")
# Loading C:\Users\Selur\Desktop\Test.ts using FFMS2
clip = core.ffms2.Source(source="C:/Users/Selur/Desktop/Test.ts",cachefile="H:/Temp/ts_6172c2a2969c38a25728d49450effe0d_491.ffindex",fpsnum=50,format=vs.YUV420P8)
# Output
clip.set_output()
and the error I get is:
Failed to evaluate the script:
Python exception: 'list' object has no attribute 'set_output'
Traceback (most recent call last):
File "src\cython\vapoursynth.pyx", line 1491, in vapoursynth.vpy_evaluateScript (src\cython\vapoursynth.c:26905)
File "H:\Temp\encodingTempSynthSkript_22_51_09_5510.vpy", line 9, in <module>
clip.set_output()
AttributeError: 'list' object has no attribute 'set_output'

=> how to properly set the format ?

Cu Selur

[Myrsloik]

Look at the output. You get an array of two clips. Pick one. Or set alpha to false.

[Selur]

Thanks!

[qyot27]

FFMS2 C-plugin r1140+105-avs+vsp

Optimized for Pentium-III and SSE (32-bit)
Optimized for Core2 (64-bit)

ffmpeg version r83723 git-9ae762d Copyright (c) 2000-2017 the FFmpeg developers
built with gcc 6.3.0 (GCC)
libavutil 55. 47.101 / 55. 47.101
libavcodec 57. 82.100 / 57. 82.100
libavformat 57. 66.103 / 57. 66.103
libavfilter 6. 74.100 / 6. 74.100
libavresample 3. 2. 0 / 3. 2. 0
libswscale 4. 3.101 / 4. 3.101
libswresample 2. 4.100 / 2. 4.100
libpostproc 54. 2.100 / 54. 2.100

32-bit configuration:
--prefix=/home/qyot27/win32_build
--cross-prefix=i686-w64-mingw32-
--enable-gpl
--enable-version3
--disable-w32threads
--enable-avresample
--disable-encoders
--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

64-bit configuration:
--prefix=/home/qyot27/win64_build
--cross-prefix=x86_64-w64-mingw32-
--enable-gpl
--enable-version3
--disable-w32threads
--enable-avresample
--disable-encoders
--disable-muxers
--disable-doc
--disable-debug
--disable-devices
--disable-avdevice
--cpu=core2
--extra-cflags='-march=core2'
--target-os=mingw32
--arch=x86_64

Now supporting almost all of the new pix_fmts in AviSynth+. High bit depth in/out works, also YUVA, Planar RGB, and Planar RGBA are outputting green video - they don't crash, though. Not sure if that's due to something that needs fixing in FFMS2 or in AviSynth+ (r2420 was used for the tests).

I'm pretty certain now that the issues I was having with previous builds when trying to use the AviSynth+ header were caused by GCC miscompiling things, because Debug builds (-g) work, but Release builds immediately crash. Of course, even with Debug builds mostly working, there's some kind of issue with crashes on exit, which I wouldn't be surprised to find is also being caused by GCC miscompiling it.

AviSynth 2.6 will not work with this build. I may be able to avert this with the same sort of tactic I used to make Libav and FFmpeg distinguish between 2.6 and Plus. Because of this and the crash-on-exit thing mentioned above, I've also left the previous non-Plus build available.

EDIT 2018-01-02: Newer build available. (https://forum.doom9.org/showthread.php?p=1829061#post1829061)

[Atak_Snajpera]

Is this normal that in latest ffms2 2.23.1 all frames in VC-1 are detected as keyframes?
Example
# keyframe format v1
fps 0
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

FFMS 2.20
# keyframe format v1
fps 0
0
1
25
49
53
77
101
106
130
154
178
202
226
250
274
298
322
346
370
394
418
442
466
490

[LigH]

Would it be easy/complicated/expensive/illegal to have FFMS2 support HWAccel (https://trac.ffmpeg.org/wiki/HWAccelIntro) features of ffmpeg for decoding?

[stax76]

Would it be easy/complicated/expensive/illegal to have FFMS2 support HWAccel (https://trac.ffmpeg.org/wiki/HWAccelIntro) features of ffmpeg for decoding?

IIRC it's already supported but don't work (I don't remember if it was l-smash or ffms2), maybe you can find something in the docs.

[LigH]

Again, regarding playlist support:

It's been on the todo list for ages, issue #33 (http://code.google.com/p/ffmpegsource/issues/detail?id=33) is an even older feature request for the same thing.

A similar case just came up, a consumer camera recording MTS segments of up to 2 GB per piece, due to FAT32 restrictions of SD*C memory cards. Using a source call for each MTS segment separately goes out of memory easily on a 32 bit AviSynth.

I believe any source plugin supporting MPLS could help here. At the moment, the owner of such a camera may have to buy DGDec* or concatenate the segments before use.

[TheFluff]

Playlist support was rejected in the core since it just added a dependency on a playlist parser lib for no good reason (it could just as well be done on the calling side of the API). For VS there's ReadMPLS (https://github.com/HomeOfVapourSynthEvolution/VapourSynth-ReadMpls) as a standalone thing but I really don't think anyone cares about 32-bit Avisynth anymore.

[LigH]

So because a 64-bit AviSynth is less likely to run out of memory, supporting playlists (not only for convenience, but even for correct handling of segmented media formats) becomes automatically irrelevant?! :confused:

[Myrsloik]

So because a 64-bit AviSynth is less likely to run out of memory, supporting playlists (not only for convenience, but even for correct handling of segmented media formats) becomes automatically irrelevant?! :confused:

Yes, it's 2017. You're free to write a wrapper that creates/destroys source instances in a memory conserving way if you really care.

[LigH]

... if I was a C/C++ programmer. What I am not; I am only a user. So I have to hope that more competent people than me are able.

I am not sure if implementing a support for playlists is more complicated than implementing a different "partially shared" handling for source plugins which must be re-entrant per se.

I hope AviSynth+ author(s) know better.

Apart from that: What if a large medium is split without respect of GOP or even frame borders? It would be perfectly legal. Independent treatment of such segments would be a loss of content, instead. Thus, handling several source plugin instances would be a failure, in contrast to handling segments as continuous stream; but that would only work in a playlist.

[sneaker_ger]

Would it be difficult to implement ffmpeg's concat features (e.g. the "concat demuxer")?

[Myrsloik]

Would it be difficult to implement ffmpeg's concat features (e.g. the "concat demuxer")?

That's kinda been considered but I stopped thinking about it after d2vsource was released. It's useful for real segmented stuff at least that won't decode properly with just multiple sources. Add it to the maybe pile (create an issue about it if you want to make sure I don't forget it). I'm a busy person at the moment.

[TheFluff]

So because a 64-bit AviSynth is less likely to run out of memory, supporting playlists (not only for convenience, but even for correct handling of segmented media formats) becomes automatically irrelevant?! :confused:

Segmented source files is a different thing. As far as I know MPLS isn't that, it's literally just a playlist.

As far as your whining about running out of memory goes, I created 20 ffms2 instances for a 2GB MP4 in VS and the entire process ate less than 500 MB memory, so, well. It's kind of an insult from the 1970's, but really, if you want to encode big video files maybe you should get a real computer? Or if you have a real computer, stop using 32-bit Avisynth; it's not like there's been any reason to use it other than pure obstinacy for the last few years. You're kinda complaining about getting wet when you go outside in the rain while intentionally not bringing your umbrella, here.

[LigH]

Regarding my "whining":

a) not mine, just reporting what happened to another person; in the meantime we discovered that he used a way to open sources which took a lot more RAM per clip, but not yet why he claims to be unable to use a different source plugin as well as the 64-bit AviSynth+ at all. We will now concentrate on debugging these issues first.

b) it would be technically wrong anyway to use a sequence of source calls separately on each segment, because segments could be split regardless of GOP or even frame borders. Instead, one single source call would have to process a sequence of segment files. But how do you tell the order of the sequence, if not by using a playlist, in one or another form?

[TheFluff]

Segmented source files is a different thing. Didn't I just say that? I don't think MPLS is supposed to be used with things like GOP's split over file boundaries.

[LigH]

Then it would require a new proprietary "segmented sources sequence" (file list) format to be recognized as meta-input file. Similar to the header part of DG project files (the body part would already exist as the index file).

[TheFluff]

Why? If support for that kind of thing was added, the obvious way to access it would be to pass an array of filenames. If you want everything in a directory that starts with a given string and ends with .vob, just do the listing etc in Python. If you're using VS, that is.

[LigH]

No, the environment is still AviSynth{+}, no arrays here (maybe sprintf format string as alternative to a list file); and the owner of the mentioned camera has a sequence of MTS segments (similar to the content of Blu-ray, maybe, therefore the "obvious" thought of MPLS).

[TheFluff]

This would not be Avisynth specific if implemented, I'm talking about how it'd be exposed in the FFMS2 API.

[Andouille]

What does this have to do with video processing ?



Since crap Vapoursynth developers have read this wirthout replies...
NOTHING.

[Myrsloik]

Since crap Vapoursynth developers have read this wirthout replies...
NOTHING.

It has everything to do with video processing. You are NOTHING.

[mandarinka]

But what if Microsoft fixes the issue in the POSready branch? :devil:

[TheFluff]

Yes, and according to this:
https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/
I will also not get a slowdown of my computer for up to 30% which these (future) patches will introduce... :devil:

Cheers
manolito

The 30% figure is a vast exaggeration even for actually syscall-heavy workloads in practice. The impact for video processing is completely negligible.

I'm also kind of amused that you're bringing up performance. Since you don't have SSE2 I'm gonna guess you have an Athlon XP, which was the last even remotely common desktop CPU line that didn't have that. The ultimate Athlon XP's (Barton) launched in 2003, fifteen years ago. One single core on my current CPU is at least four times faster than an Athlon XP 3200+, and I have six such cores with two threads each. I'm really not that worried about a few percent lower performance.

More seriously, using a non-SSE2 CPU for any serious work in 2018 would be - measured in years - like running an Intel 486 (launched 1989) was in 2004 when Barton CPU's were still relatively recent. You need to recognize it for what it is: a retrocomputing nostalgia trip. It's cute, but don't demand that people should support modern software on it. I really don't recommend accessing the web with an XP machine simply because of the alarming and constantly increasing number of unpatched security vulnerabilities, and you definitely shouldn't be doing anything sensitive on it. Even if you insist on doing it, you're probably going to get shut out from various internet-connected services sooner rather than later, because by June this year a lot of internet stuff is going to be requiring at least TLS 1.0, which the XP system crypto libraries do not support. You can keep browsing the web with Firefox for a few more months because it bundles its own crypto, but anything that relies on system cryptography is simply not going to work anymore, and once Firefox stops getting updates you'll gradually lose secure internet access because you won't get certificate updates anymore.

[lvqcl]

But what if Microsoft fixes the issue in the POSready branch? :devil:

Currently their position is: (https://support.microsoft.com/en-us/help/4073119/windows-client-guidance-for-it-pros-to-protect-against-speculative-exe)

My Operating system (OS) is not listed. When can I expect a fix to be released?
Addressing a hardware vulnerability with a software update presents significant challenges and mitigations for older operating systems require extensive architectural changes. Microsoft is continuing to work with affected chip manufacturers and to investigate the best way to provide mitigations, which may be provided in a future update.

[FranceBB]

@lvqcl... and @TheFluff... Windows XP/POSReady machines will probably get the fix next week, on "patch Tuesday", together with other normal updates released every month 'till 2019.

[Andouille]

It has everything to do with video processing. You are NOTHING.

The impact for video processing is completely negligible.

Pretty :goodpost:

[Selur]

xp doesn't bother telling you about it.
lol,..

[mandarinka]

@lvqcl... and @TheFluff... Windows XP/POSReady machines will probably get the fix next week, on "patch Tuesday", together with other normal updates released every month 'till 2019.

Actually it seems that they won't. The kernel/user memory mapping split is apparently for 64bit only. Even 32bit Windows 10 don't apply it (small adress space maybe?) and leave Meltdown vulnerability open I guess. :scared::scared::scared:

https://twitter.com/aionescu/status/949442882062073856

[sneaker_ger]

When decoding TrueHD ffms outputs 32 bit (e.g. "Amaze (Lossless-ATMOS)" sample (https://thedigitaltheater.com/index.php/dolby-trailers/)). Isn't TrueHD 24 bit max?

[Myrsloik]

When decoding TrueHD ffms outputs 32 bit (e.g. "Amaze (Lossless-ATMOS)" sample (https://thedigitaltheater.com/index.php/dolby-trailers/)). Isn't TrueHD 24 bit max?

I didn't look at the file yet but basically there are no formats between 16 bit per channel and 32 bits per channel in ffmpeg. So most likely the decoder output it as 32 bit to not lose information.

[tebasuna51]

...but basically there are no formats between 16 bit per channel and 32 bits per channel in ffmpeg.

And what is this?: -acodec pcm_s24le

[dipje]

And what is this?: -acodec pcm_s24le

A codec name, not an internal processing format.

ffmpeg -sample_fmts:
name depth
u8 8
s16 16
s32 32
flt 32
dbl 64
u8p 8
s16p 16
s32p 32
fltp 32
dblp 64
s64 64
s64p 64

[tebasuna51]

Then ffmpeg is not a lossless decoder?

A lossless decoder must output the input depth of lossless formats, no mather the internal processing format.

[LigH]

Adding insignificant bits is no "loss", just "stuffing" (similar to video modes using 32 bit even though displays only support RGB 8880 with 24 bit, just because treating 24 bit data would be horribly slow, compared to stuffed 32 bits with DWORD memory alignment).

[dipje]

Then ffmpeg is not a lossless decoder?

A lossless decoder must output the input depth of lossless formats, no mather the internal processing format.

I guess.. from my own experience: Good luck changing minds on the ffmpeg-devel list :).

The thing to remember is, if they made sure the 'upscaling and then downscaling' produces bit for bit output, it's still lossless in my mind.

If you have a lossless 24bit integer codec, that outputs to 32bit integer in the ffmpeg pipeline, but the final output codec is pcm_s24le and they made sure the 'downscaling' procudes the exact same bits, it's lossless. At least to me :).

The moment you apply filters / effects / calculations on the s32 material, then yes, downscaling to pcm_s24le won't be bit for bit the same.. but you applied filters / effects, so lossless is out of question anyway.

Take a (short) 24bit wav file. Export it as a raw file containing s24 audio samples. Now encode the original wav file to the lossless codec of your choice that works internally in 24bit integer. Decode it through ffmpeg, and convert it to a raw file containing s24 audio samples again. Compare - bit-for-bit - the two raw files. I'm guessing they will be the same.


edit:
I just bought an album in 'hires audio 24bit / 44khz flac' to have some true 24bit lossless source files :).
Decoded the flac file with the 'official' flac utility to raw pcm, little endian, signed.
Then ffmpeg -i <inputfile> -f s24le <output file>
I compared (binary) the two raw output files, they were exactly the same. Not a single bit different.
And when I do 'ffprobe <input file>' the flac file is reported as being 's32 (24 bit)'

So ffmpeg _is_ lossless. Yes, it decoded s24 to s32 and then truncates it to s24 again, but the result is still bit for bit the same.

[Myrsloik]

I need your opinion about changing the default ffms2 behavior. As you know interlaced h264 files return double framerate output and this isn't what most of you want. So I'm thinking about making dropping every other frame automatic. The only problem is that I don't know if this has any negative effects or not.

Are there any additional problems when doing this? I know some of you even automatically generate scripts where this is done.

[sneaker_ger]

Mixed content?

[Myrsloik]

Mixed content?

Ok, you got me there. Won't change it then

[sneaker_ger]

Would it be difficult to integrate DXVA? The software VC-1 decoder in ffmpeg has been buggy for many years and it seems no one is interested or able to fix it making it more or less useless.

[LigH]

I would enjoy seeing an update after more than a year. I believe the libav* core developed a bit since... maybe API's changed and need some adaption.

[sneaker_ger]

Yes, it's about time. There were even a bunch of fixes for the software VC-1 decoder recently so maybe it's finally useful now.

[Daemon404]

You are always free to build it yourself or follow on GitHub. There have been significant changes in FFMS2 since 2.23.1, and it's almost ready for a new release, I think.

I want to finish some required VP9 changes (needed to fix some ridiculous libavcodec stuff that broke), and the last bit of stuff needed to keep MP4 edit lists from causing sync issues. After those, an RC or two and a release?

[Gser]

Yes, it's about time. There were even a bunch of fixes for the software VC-1 decoder recently so maybe it's finally useful now.

So you are saying it is not useful now? What should I use instead?

[sneaker_ger]

Alternatives for VC-1:
DGDecNV (http://rationalqm.us/dgdecnv/dgdecnv.html)
FRIMSource (https://forum.doom9.org/showthread.php?t=169651)
DirectShowSource() with LAV Video (https://forum.doom9.org/showthread.php?t=156191) (in LAV Video do not deactivate WMV MFT decoder, or use DXVA2 copy-back or D3D11)
DSS2() with LAV Video (in LAV Video do not deactivate WMV MFT decoder, or use DXVA2 or D3D11 - at least until it's built with newest ffmpeg)
DSS2mod (https://forum.doom9.org/showpost.php?p=1699301&postcount=33) (DSS2 with LAV inbuilt, I don't know if there are more recent versions but it's probably still good enough for VC-1 Blu-Ray)

Basically anything not based on non-recent ffmpeg software decoder ..

[LigH]

You are always free to build it yourself ...

... if you have both the knowledge how to use the required tools in general, and to handle the quirks of this specific project.

Especially for software which requires a Microsoft Visual Studio, I cannot build it myself, because I lack both the installation of its building environment and the experience to use it. I am already happy to run an MSYS2 environment if there are no failures.

I don't mind waiting another week or more if there is some certainty that a competent person will have success faster than me learning a completely new technology, up to a level where I am not completely clueless when issues arise.

:helpful:

[DJATOM]

You should try VS2017 community edition, it's free and I don't see any problems with compiled binaries.
Prev. update had some bugs in compiler (it was crashing on attempt to compile few projects), but now they are fixed.

[LigH]

Is there a verbose guide how to compile FFMS2? ffms2-api.md (https://github.com/FFMS/ffms2/blob/master/doc/ffms2-api.md) is a bit too brief for my level of VS knowledge. It would probably take a while to learn how to start a compilation, and where to take header files from and where to copy them to, and ...

It feels like telling me "just drive this car" when I am just used to driving a bicycle.

[Gser]

Alternatives for VC-1:
DGDecNV (http://rationalqm.us/dgdecnv/dgdecnv.html)
FRIMSource (https://forum.doom9.org/showthread.php?t=169651)
DirectShowSource() with LAV Video (https://forum.doom9.org/showthread.php?t=156191) (in LAV Video do not deactivate WMV MFT decoder, or use DXVA2 copy-back or D3D11)
DSS2() with LAV Video (in LAV Video do not deactivate WMV MFT decoder, or use DXVA2 or D3D11 - at least until it's built with newest ffmpeg)
DSS2mod (https://forum.doom9.org/showpost.php?p=1699301&postcount=33) (DSS2 with LAV inbuilt, I don't know if there are more recent versions but it's probably still good enough for VC-1 Blu-Ray)

Basically anything not based on non-recent ffmpeg software decoder ..
Thanks, I have used all of those DSS versions at some point but due to its fps issue I moved to ffmpegsource. I did not know about FRIMSource, it seems to be working nicely.

[LigH]

L-SMASH Works for AviSynth was just updated as well. VapourSynth version may follow?

[Gser]

L-SMASH Works for AviSynth was just updated as well. VapourSynth version may follow?

Yeah the newest L-smash does not work for VC-1 at all,at least not in avs+. Getting super corrupt frames with grey bits everywhere.

[LigH]

Well, l33tmeatwad (https://forum.doom9.org/showthread.php?p=1843162#post1843162) added a shared FFMS2 (so his shared L-SMASH Works build can use the same libav DLL's) ... but he made a mistake:

Note: The FFMS2_2.23.1_MSVC_SharedLibs.7z contains 64 bit libav DLL's in the x86 subdirectory. The ones in LSMASHSource_r941_MSVC_SharedLibs_hydra3333.7z are correct for 32 bit.

Regarding VC-1 decoding, as replied in the L-SMASH Source thread (https://forum.doom9.org/showthread.php?p=1844785#post1844785) already: It seems that there is a splitter issue; FFMS2 does it correctly. — Known as L-SMASH-Works issue #58 (https://github.com/VFR-maniac/L-SMASH-Works/issues/58).

[l33tmeatwad]

Well, l33tmeatwad (https://forum.doom9.org/showthread.php?p=1843162#post1843162) added a shared FFMS2 (so his shared L-SMASH Works build can use the same libav DLL's) ... but he made a mistake:

Note: The FFMS2_2.23.1_MSVC_SharedLibs.7z contains 64 bit libav DLL's in the x86 subdirectory. The ones in LSMASHSource_r941_MSVC_SharedLibs_hydra3333.7z are correct for 32 bit.

Regarding VC-1 decoding, as replied in the L-SMASH Source thread (https://forum.doom9.org/showthread.php?p=1844785#post1844785) already: It seems that there is a splitter issue; FFMS2 does it correctly. — Known as L-SMASH-Works issue #58 (https://github.com/VFR-maniac/L-SMASH-Works/issues/58).
Oops, it's fixed now.

[Gser]

Well, l33tmeatwad (https://forum.doom9.org/showthread.php?p=1843162#post1843162) added a shared FFMS2 (so his shared L-SMASH Works build can use the same libav DLL's) ... but he made a mistake:

Note: The FFMS2_2.23.1_MSVC_SharedLibs.7z contains 64 bit libav DLL's in the x86 subdirectory. The ones in LSMASHSource_r941_MSVC_SharedLibs_hydra3333.7z are correct for 32 bit.

Regarding VC-1 decoding, as replied in the L-SMASH Source thread (https://forum.doom9.org/showthread.php?p=1844785#post1844785) already: It seems that there is a splitter issue; FFMS2 does it correctly. — Known as L-SMASH-Works issue #58 (https://github.com/VFR-maniac/L-SMASH-Works/issues/58).
I updated to that version of FFMS2 and now I get this error
Process exits with error: 0xC000007B STATUS_INVALID_IMAGE_FORMAT (-1073741701)
I didn't get any errors before.

[Groucho2004]

Process exits with error: 0xC000007B STATUS_INVALID_IMAGE_FORMAT (-1073741701)That usually indicates the attempt to load a DLL with bitness mismatch (loading a 32 bit plugin with 64 bit Avisynth or vice versa).

[Gser]

That usually indicates the attempt to load a DLL with bitness mismatch (loading a 32 bit plugin with 64 bit Avisynth or vice versa).

That's one hellava misleading error. Seems the package only included the 32-bit version of ffmsindex. The updated ffmpegsource seems to work fine otherwise

[Groucho2004]

That's one hellava misleading error. Seems the package only included the 32-bit version of ffmsindex. The updated ffmpegsource seems to work fine otherwise
Yeah, the verbose message text from ntstatus.h is just as misleading:
// MessageId: STATUS_INVALID_IMAGE_FORMAT
//
// MessageText:
//
// {Bad Image}
// %hs is either not designed to run on Windows or it contains an error. Try installing the program again using the
// original installation media or contact your system administrator or the software vendor for support.
//
#define STATUS_INVALID_IMAGE_FORMAT ((NTSTATUS)0xC000007BL)

[LigH]

Check with DependencyWalker, load ffms2.dll in each specific bitness...

They require several API-MS-WIN-CORE-WINRT-*.DLL; are they unavailable in Windows 7? Several other API-MS-WIN-CORE-*.DLL are available, though.

This build is possibly not really independent of Visual Studio, or expects a newer Windows generation (WinRT is a hint, I guess).
_

Or maybe I am wrong, and they are only very indirect dependencies.

For me the AviSynth plugins seem to work. And they can create an index without the separate indexer too.

[l33tmeatwad]

That's one hellava misleading error. Seems the package only included the 32-bit version of ffmsindex. The updated ffmpegsource seems to work fine otherwiseThe original project files had ffmsindex disabled for the x64 build and I wasn't sure if that was on purpose so I just didn't include it. I can enable it and compile it as well.

[LigH]

I wonder if a separate indexer is really necessary. I believe it doesn't require the ffms2.dll itself (maybe the shared libav DLL's if it was built shared as well), and it will use an own 32 bit process which shall run on both a 32 and 64 bit Windows. So having it included in the package should be merely convenient for those {users who / applications which} run it explicitly.

[Gser]

I wonder if a separate indexer is really necessary. I believe it doesn't require the ffms2.dll itself (maybe the shared libav DLL's if it was built shared as well), and it will use an own 32 bit process which shall run on both a 32 and 64 bit Windows. So having it included in the package should be merely convenient for those {users who / applications which} run it explicitly.

It appears MeGUI does require the 64-bit version.

[l33tmeatwad]

It appears MeGUI does require the 64-bit version.I'll get it compiled when I get the chance. Is the current static binaries of 2.23.1 on the official repository not with FFMPEG 4.0? The shared libs build I did was just kinda....because I could, lol.

[LigH]

Release version 2.23.1 on github (https://github.com/FFMS/ffms2/releases) reports: "myrsloik released this on 18 Oct 2016". Do you know any newer (except your own)? MeGUI (32 bit) uses the same, according to its file date.

[l33tmeatwad]

Release version 2.23.1 on github (https://github.com/FFMS/ffms2/releases) reports: "myrsloik released this on 18 Oct 2016". Do you know any newer (except your own)? MeGUI (32 bit) uses the same, according to its file date.Oh, I suppose I should read...I guess not, I'll make sure to get that ffmsindex compile today then.

[l33tmeatwad]

Since there seemed to be interest...

FFMS2 2.23.1 (w/ FFmpeg 4.0)
Static Libs Build (x86 & x64) (http://www.mediafire.com/file/6e7ayxj6q8h7224) | Shared Libs Build (x86 & x64) (http://www.mediafire.com/file/dffpprzgud9xid6/) | Sources (https://www.mediafire.com/folder/3tv37w2c9ibps/Source)

Build Notes:
Compiled with Microsoft Visual Studio 2015
Shared Libs & Include Files were copied to the Visual Studio Directories in: C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC
Patch included with previous releases was applied to FFmpeg before compiling.

Static FFmpeg compiled with:
./configure --toolchain=msvc --enable-gpl --enable-version3 --disable-encoders --disable-programs --disable-filters \
--disable-network --disable-doc --disable-avdevice --disable-swresample --disable-postproc --disable-avfilter --enable-avresample
make install
Shared Libs FFmpeg compiled with:
./configure --toolchain=msvc --enable-gpl --enable-version3 --enable-shared --disable-encoders --disable-programs --disable-filters \
--disable-network --disable-doc --disable-avdevice --disable-swresample --disable-postproc --disable-avfilter --enable-avresample
make install

Visual Studio Project Modifications (Static Build)
Project Properties > Configuration Properties > Linker > Input
- Additional Dependencies: bcrypt.lib;

Changes to libs.cpp (Both Builds)
#pragma comment(lib, "zlibstat.lib")

Changes to libs.cpp (Shared Libs)
#pragma comment(lib, "avutil.lib")
#pragma comment(lib, "avcodec.lib")
#pragma comment(lib, "avformat.lib")
#pragma comment(lib, "swscale.lib")
#pragma comment(lib, "avresample.lib")

Included Libs:
LibAV (from FFmpeg 4.0) (https://github.com/ffmpeg/ffmpeg/releases)
zlib 1.2.11 (http://zlib.net)

Other Software:
MSYS2 (https://www.msys2.org/) (i686 & x86_64)
Yasm 1.3.0 (http://yasm.tortall.net/Download.html) (General Use Executables)

[Myrsloik]

Since there seemed to be interest...
Insert compiled stuff here

Feel free to compile a current git master as well. I've simply been too busy and it'll probably have fixed a lot of issues for some peopl.e.

[ChaosKing]

@l33tmeatwad VS chrashes instantly with no error. Tried with static and shared build, Vapoursynth x64. But it creates an index file.

[l33tmeatwad]

@l33tmeatwad VS chrashes instantly with no error. Tried with static and shared build, Vapoursynth x64. But it creates an index file.That's odd, I just installed VapourSynth and was able to preview a script in VapourSynth Editor and encode it through FFmpeg using the static build plugin.

[poisondeathray]

ffms2 static x64 compiled by l33tmeatwad, VS x64 works for me too. Win8.1

Thanks.


@ChaosKing - did older ffms2 crash too with that source?


-This newer ffms2 also decodes some VP9 variants that older ffms2's had problems with
-But still problems with interlaced VC-1

[ChaosKing]

I tried different videos, it's always the same. My cpu is a Ryzen 1700.
The old ffms2 work fine with all tested videos.

[l33tmeatwad]

I tried different videos, it's always the same. My cpu is a Ryzen 1700.
The old ffms2 work fine with all tested videos.What OS are you using?

[ChaosKing]

Win10 x64 Pro 17134 (the latest one)

[l33tmeatwad]

Win10 x64 Pro 17134 (the latest one)Could you give an error log? Also, what version of vcredist do you have installed?

[ChaosKing]

I haven't changed anything but now it's working O_O
I know that I restarted my pc, tried it in vs editor and with vspipe. It didn't work ... and now magically it works.

[ChaosKing]

Not that I need this, but I noticed that your ffms2 dll can not load http links like this:
clip = core.ffms2.Source("https://www.animemusicvideos.org/guides/avtech31/images/avs/rainbow-orig.jpg").std.DuplicateFrames([0]*20)
It works with Myrsloiks ffms2 dll.

[l33tmeatwad]

Not that I need this, but I noticed that your ffms2 dll can not load http links like this:
clip = core.ffms2.Source("https://www.animemusicvideos.org/guides/avtech31/images/avs/rainbow-orig.jpg").std.DuplicateFrames([0]*20)
It works with Myrsloiks ffms2 dll.I disabled a few things to reduce the size of the dependencies so that probably does not work because when compiling FFmpeg I used the option "--disable-network".

[ChaosKing]

@l33tmeatwad I know now why I had crashes with your ffms2 version. It crashes with a "Basic Windows bitmap format" avi.
I have one script where a logo.avi is imported with a BMP format and I didn't realise this immediately.


Writing application : Adobe After Effects CC 2018 (Windows)

Video
ID : 0
Format : RGB
Codec ID : 0x00000000
Codec ID/Info : Basic Windows bitmap format. 1, 4 and 8 bpp versions are palettised. 16, 24 and 32bpp contain raw RGB samples
Duration : 12 s 971 ms
Bit rate : 922 Mb/s
Width : 1 484 pixels
Height : 1 080 pixels
Display aspect ratio : 1.374
Frame rate : 23.976 (24000/1001) FPS
Bit depth : 8 bits
Bits/(Pixel*Frame) : 24.000
Time code of first frame : 00:00:00:00 / 00:00:00:00
Time code source : Adobe tc_A / Adobe tc_O
Stream size : 1.39 GiB (100%)

[LigH]

For such uncompressed DIB AVI sources, AviSource() is by far superior, because it lets Windows decode a bitmap format it knows best. FFMS2 is more suitable for compressed source formats.

A severe problem for AviSynth is reading video sources with a low number of palette colors. It does not support such indirect palette color modes, only "direct color" formats.

[poisondeathray]

I can replicate ChaosKing's issue with uncompressed 8bit RGB

some other observations (only x64 vpy versions tested, partly because his original crash was in vapoursynth). Tested both 1484x1080 and 1920x1080 (in case it was some weird frame dimension component contributing). And export from vdub2 (in case some weird metadata component was contributing from Adobe/AE)

l33tmeatwad => crash
ffms2000-test8 => ok
ffms2-2.23.1-msvc => crash
ffms2-2.23-clang => crash


And AVISource works fine on Win as expected, but do linux/mac users have access AVISource() in vapoursynth ?

[LigH]

Probably not as in "use VfW - ICM", because it won't require WINE, it would have to interpret DIB frames on its own ... apart from that, I don't know VapourSynth well, I don't know if it can handle palette color modes at all. If it does, basically, then you should convert it to a direct color mode ASAP.

[ChaosKing]

NICE! Some avi files that I tested yesterday that had problems with random seeking are now fixed too. thx

I get 50fps with "Holi Festival" 1080p from here https://www.elecard.com/videos

[zambelli]

Two questions about the colorspace parameter of FFVideoSource():

1. if an interlaced YUV 4:2:0 video is loaded with a colorspace parameter where the requested colorospace requires YUV 4:2:0 to be upsampled to 4:2:2 or 4:4:4 - e.g. "YUV422P10" or "YUV444P8" - does FFMS2 automatically decide whether to use progressive or interlaced chroma upsampling for each frame? Let's assume the interlaced video has proper metadata describing its interlaced coding methods.

2. if a YUV video is loaded with a colorspace parameter where the requested colorspace is RGB - e.g. "RGB24" or "RGBP10" - does FFMS2 automatically determine whether to use Rec.601, Rec.709 or Rec.2020 based on detected metadata? Or does it always default to one of them?

[Myrsloik]

Two questions about the colorspace parameter of FFVideoSource():

1. if an interlaced YUV 4:2:0 video is loaded with a colorspace parameter where the requested colorospace requires YUV 4:2:0 to be upsampled to 4:2:2 or 4:4:4 - e.g. "YUV422P10" or "YUV444P8" - does FFMS2 automatically decide whether to use progressive or interlaced chroma upsampling for each frame? Let's assume the interlaced video has proper metadata describing its interlaced coding methods.

2. if a YUV video is loaded with a colorspace parameter where the requested colorspace is RGB - e.g. "RGB24" or "RGBP10" - does FFMS2 automatically determine whether to use Rec.601, Rec.709 or Rec.2020 based on detected metadata? Or does it always default to one of them?

1. Maybe? Probably not? You should never use the internal conversion if at all possible anyway. That's my recommendation.

2. Maybe? Probably not? You should never use the internal conversion if at all possible anyway. That's my recommendation.

I hope that helps. Don't use the internal conversion. It only exists to give you the least bad output compromise based on the source format.

[Stereodude]

Is this the best plugin to use for opening a file with VP9 video? Also, does it support high-bit-depth AVIsynth+ color formats if the source is >8-bits?

[LigH]

VP9 should be supported by at least either FFMS2 or L-SMASH Works. Probably both.

[sneaker_ger]

Also, does it support high-bit-depth AVIsynth+ color formats if the source is >8-bits?
It does (automatically).

[Stereodude]

VP9 should be supported by at least either FFMS2 or L-SMASH Works. Probably both.
Am I allowed to ask why FFMS2 returns extra duplicated frames and an odd framerate for VP9 from YouTube? The same VP9 decodes with the LAV filters in MPC-HC without the duplicated frames and at the expected frame rate.

[LigH]

To let the developers check for reasons, it may be useful to provide a sample video ID hash and format ID number for youtube-dl... and did you compare with LwLibavVideoSource?

[Stereodude]

To let the developers check for reasons, it may be useful to provide a sample video ID hash and format ID number for youtube-dl... and did you compare with LwLibavVideoSource?
LwLibavVideoSource seems to decode it correctly. nGncW_ueyHA / 248

Using LwLibavVideoSource AVSmeter64 reports:
Number of frames: 12773
Length (hh:mm:ss.ms): 00:08:52.741
Frame width: 1920
Frame height: 1080
Framerate: 23.976 (24000/1001)

Using FFMS2 AVSmeter64 reports:
Number of frames: 13304
Length (hh:mm:ss.ms): 00:08:39.229
Frame width: 1920
Frame height: 1080
Framerate: 25.623 (250000/9757)

[Selur]

32bit version too please. :)

[ChaosKing]

Thx. I guess libdav1d will only be available in v4.2?

[Taurus]

32bit version too please. :)
Yes, please!

[LigH]

And L-SMASH Works too... ah, sorry, off-topic :o

[ChaosKing]

Thx for compiling ffms2 with dav1d. Sadly the decoding of av1 files looks broken. pink blocks etc.
But I get 200fps with dav1d and no seeking issues xD

[ChaosKing]

https://forum.doom9.org/showthread.php?p=1866894#post1866894
Looks fine with libaom. But I can't be sure that rav1e produced 100% valid encodes.

[ChaosKing]

I made an encode with the linked rav1e.exe: The image just "freezes" after ~20 frames with dav1d (but no pink blocks anymore). No problems with libaom. So is it a decoder or encoder issue?
https://www.dropbox.com/s/2dznywf410qoabe/rav1e_b_180.ivf?dl=1

[sneaker_ger]

The sample decodes fine through ffmpeg and ffplay with libdav1d 0.2.0.

[qyot27]

It might be related to this PR that has to do with fixing FFMS2's handling of VP9 (https://github.com/FFMS/ffms2/pull/323); the most recent note is that fixing the PR is probably needed for AV1 now too.

Read: it may have nothing to do with the encoder or the decoder, but about the ability of FFMS2 to use the FFmpeg API to parse the bitstream in the correct way, and certain encoder/decoder combinations expose errant behavior in the parser. This would explain why ffplay (or mpv) works fine on the same sample and the same build of libdav1d that FFMS2 uses, but FFMS2 exhibits problems.

[masterkivat]

ffms2-7c36121-win64 (https://drive.google.com/open?id=1uu38YBCStzE0Od0D7n5OWECxUzz7xQGp)

Libraries:
FFmpeg 4.2-dev-93293-gdb332832a1
libdav1d 0.2.1-e29cb9af
libvpx 1.8.0-198-gaba995832
libxml2 2.9.9
openssl 1.1.1b

Thanks HolyWu for the meson build system :)
this can be used on Vapoursynth? (like, renaming libffms2.dll to ffms2.dll and put on 'plugins64'?)

[ChaosKing]

this can be used on Vapoursynth? (like, renaming libffms2.dll to ffms2.dll and put on 'plugins64'?)

Yes, it even works without renaming. :eek:

[ChaosKing]

No decoding issues with this build. I get 66fps. With the previous build https://forum.doom9.org/showthread.php?p=1866411#post1866411 it's under 40fps, so a nice increase at least!

[qyot27]

It might be related to this PR that has to do with fixing FFMS2's handling of VP9 (https://github.com/FFMS/ffms2/pull/323); the most recent note is that fixing the PR is probably needed for AV1 now too.

Read: it may have nothing to do with the encoder or the decoder, but about the ability of FFMS2 to use the FFmpeg API to parse the bitstream in the correct way, and certain encoder/decoder combinations expose errant behavior in the parser. This would explain why ffplay (or mpv) works fine on the same sample and the same build of libdav1d that FFMS2 uses, but FFMS2 exhibits problems.
Now that I've had some time, I can confirm that yes, those patches (after being adjusted to also handle AV1 in addition to VP9) do appear to fix the problems FFMS2 has with AV1 through libdav1d. No apparent freezing, no corrupted blocks with the test sample I'd been using (https://www.youtube.com/watch?v=2nXYbGmF3_Q).

Of course, it's probably a case of the patches needing to be reworked differently from their current state, so...

[ChaosKing]

ffms2-7c36121-win64 (https://drive.google.com/open?id=18W6Hg1xEf78FOvL5lFp_YFQAQ368K15W)

New build with libdav1d and also applied the modified patch.

Libraries:
FFmpeg 4.2-dev-93320-g5ab44ff20c
libdav1d 0.2.1-7f7b5586
No more corrupted blocks and ~280fps with 1080p, tested video was encoded with rav1e.

[filler56789]

*bump* :)

32bit version too please. :)

[tuanden0]

ffms2-7c36121-win64 (https://drive.google.com/open?id=18W6Hg1xEf78FOvL5lFp_YFQAQ368K15W)

New build with libdav1d and also applied the modified patch.

Libraries:
FFmpeg 4.2-dev-93320-g5ab44ff20c
libdav1d 0.2.1-7f7b5586

I got error "There is no function named 'FFAudioSource'" when using it with AVS :confused:

[Groucho2004]

I got error "There is no function named 'FFAudioSource'" when using it with AVS :confused:
1. Post your script
2. Run Avisynth Info Tool from my signature

[Morku]

I got error "There is no function named 'FFAudioSource'" when using it with AVS :confused:

Same here with 'ffvideosource("MVI_0001.MOV")'
Build of HolyWu is fine.

[OS/Hardware info]
Operating system: Windows 10 (x64) (Build 17763)

CPU: Intel(R) Core(TM) i7-8086K CPU @ 4.00GHz / Coffee Lake (Core i7)
MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, FMA3, AVX, AVX2
6 physical cores / 12 logical cores


[Avisynth info]
VersionString: AviSynth+ 0.1 (r2772, MT, x86_64)
VersionNumber: 2.60
File / Product version: 0.1.0.0 / 0.1.0.0
Interface Version: 5
Multi-threading support: Yes
Avisynth.dll location: C:\Windows\SYSTEM32\avisynth.dll
Avisynth.dll time stamp: 2018-12-20, 12:55:16 (UTC)
PluginDir2_5 (HKLM, x64): C:\Program Files (x86)\AviSynth+\plugins64
PluginDir+ (HKLM, x64): C:\Program Files (x86)\AviSynth+\plugins64+


[CPP 2.5 Plugins (64 Bit)]
C:\Program Files (x86)\AviSynth+\plugins64\avstp.dll [1.0.3.0]
C:\Program Files (x86)\AviSynth+\plugins64\colormatrix.dll [2.5.0.0]
C:\Program Files (x86)\AviSynth+\plugins64\dfttest.dll [1.9.4.0]
C:\Program Files (x86)\AviSynth+\plugins64\dither.dll [2015-12-30]
C:\Program Files (x86)\AviSynth+\plugins64\EEDI2.dll [0.9.2.0]
C:\Program Files (x86)\AviSynth+\plugins64\LSMASHSource.dll [2018-05-30]
C:\Program Files (x86)\AviSynth+\plugins64\TDeinterlace.dll [1.1.0.0]

[CPP 2.6 Plugins (64 Bit)]
C:\Program Files (x86)\AviSynth+\plugins64+\ConvertStacked.dll [2018-12-20]
C:\Program Files (x86)\AviSynth+\plugins64+\DirectShowSource.dll [2018-12-20]
C:\Program Files (x86)\AviSynth+\plugins64+\ImageSeq.dll [2018-12-20]
C:\Program Files (x86)\AviSynth+\plugins64+\Shibatch.dll [2018-12-20]
C:\Program Files (x86)\AviSynth+\plugins64+\TimeStretch.dll [2018-12-20]
C:\Program Files (x86)\AviSynth+\plugins64+\VDubFilter.dll [2018-12-20]
C:\Program Files (x86)\AviSynth+\plugins64\AutoAdjust.dll [2.6.0.0]
C:\Program Files (x86)\AviSynth+\plugins64\Average.dll [0.94.0.0]
C:\Program Files (x86)\AviSynth+\plugins64\aWarpsharpMT.dll [2.0.1.0]
C:\Program Files (x86)\AviSynth+\plugins64\DCTFilter_avx2.dll [0.5.0.0]
C:\Program Files (x86)\AviSynth+\plugins64\Deblock.dll [2013-12-03]
C:\Program Files (x86)\AviSynth+\plugins64\DePan.dll [2.13.1.3]
C:\Program Files (x86)\AviSynth+\plugins64\DePanEstimate.dll [2.10.0.2]
C:\Program Files (x86)\AviSynth+\plugins64\eedi3.dll [0.9.2.3]
C:\Program Files (x86)\AviSynth+\plugins64\fft3dfilter.dll [2.6.0.0]
C:\Program Files (x86)\AviSynth+\plugins64\FrameRateConverter-x64.dll [2017-09-02]
C:\Program Files (x86)\AviSynth+\plugins64\grunt-x64.dll [2016-05-17]
C:\Program Files (x86)\AviSynth+\plugins64\KNLMeansCL.dll [2018-01-29]
C:\Program Files (x86)\AviSynth+\plugins64\masktools2.dll [2.2.18.0]
C:\Program Files (x86)\AviSynth+\plugins64\mvtools2.dll [2.7.40.0]
C:\Program Files (x86)\AviSynth+\plugins64\nnedi3.dll [0.9.4.51]
C:\Program Files (x86)\AviSynth+\plugins64\RgTools.dll [0.97.0.0]
C:\Program Files (x86)\AviSynth+\plugins64\SmoothAdjust.dll [3.2.0.0]
C:\Program Files (x86)\AviSynth+\plugins64\svpflow1.dll [4.2.0.133]
C:\Program Files (x86)\AviSynth+\plugins64\svpflow2.dll [4.2.0.145]
C:\Program Files (x86)\AviSynth+\plugins64\TIVTC.dll [1.0.11.0]
C:\Program Files (x86)\AviSynth+\plugins64\vinverse.dll [2013-11-30]
C:\Program Files (x86)\AviSynth+\plugins64\yadifmod2.dll [0.0.2.0]

[Scripts (AVSI)]
C:\Program Files (x86)\AviSynth+\plugins64+\colors_rgb.avsi [2016-07-05]
C:\Program Files (x86)\AviSynth+\plugins64\AnimeIVTC.avsi [2018-04-17]
C:\Program Files (x86)\AviSynth+\plugins64\Deblock_QED.avsi [2017-05-05]
C:\Program Files (x86)\AviSynth+\plugins64\dither.avsi [2015-12-30]
C:\Program Files (x86)\AviSynth+\plugins64\FFMS2.avsi [2019-02-22]
C:\Program Files (x86)\AviSynth+\plugins64\FrameRateConverter.avsi [2017-09-03]
C:\Program Files (x86)\AviSynth+\plugins64\LSFmod.avsi [2018-07-13]
C:\Program Files (x86)\AviSynth+\plugins64\QTGMC.avsi [2019-02-21]
C:\Program Files (x86)\AviSynth+\plugins64\SMDegrain.avsi [2019-02-18]
C:\Program Files (x86)\AviSynth+\plugins64\Srestore.avsi [2019-02-21]

[Uncategorized DLLs (64 Bit)]
C:\Program Files (x86)\AviSynth+\plugins64\ffms2.dll [2019-03-11]

[Uncategorized files]
C:\Program Files (x86)\AviSynth+\plugins64+\colors_rgb.txt [2016-07-05]
C:\Program Files (x86)\AviSynth+\plugins64\ffmsindex.exe [2019-03-11]

[Groucho2004]

Same here with 'ffvideosource("MVI_0001.MOV")'I have no idea what to make of this ffms2.dll. PE Explorer seems to think it's corrupt. There are no exports whatsoever.

@Wolfberry
I presume you tested this build so it worked in your environment. Any idea why it does not work for others?

[ChaosKing]

Maybe it was compiled only with vapoursynth support? It only works in VS on my machine.

[ChaosKing]

I can't get it to work in avs or via avs.Loadplugin. How did you test it in VS?

I get some "FunctionExists not implemented" messages in VS with core.avs.LoadPlugin(r"D:\ffms2.dll"),
but clip = core.avs.FFVideoSource(r"D:\amy.mkv") or clip = core.avs.ffms2(r"D:\amy.mkv") doesn't work.

[tuanden0]

I am using the meson build system by HolyWu: https://github.com/FFMS/ffms2/pull/338

The src/avisynth source files are indeed missing.

I compiled a new build (https://drive.google.com/open?id=1U8uIYflE8sbEJkNyN90Yv3oZpJTgqu8H) with AVS+ headers

Tested by using core.avs.LoadPlugin and it loads.
Libraries are the same as the previous build.
I tried your new build but still missing FFAudio Source :confused:

Here's my script:
a=FFAudioSource("E:\Download\Source\Discovery\[JAV-11] Sora Aoi Collection.mkv")
a=AssumeFPS(a, 24000, 1001)
c=FFVideoSource("E:\Download\Source\Discovery\[JAV-11] Sora Aoi Collection.mkv",colorspace="YV12")
c=AssumeFPS(c, 24000, 1001)
AudioDub(c,a)

[filler56789]

I understand why there are no avisynth support in the autotools / meson build system.

Because gcc compiled plugins will not work in (msvc compiled) avisynth, so no avisynth support unless I can build it with msvc (so far it fails miserably)

Are you really sure of that? :confused:

When you say gcc, ¿don't you mean «a NON-MinGW-w64 toolchain»? :confused:

[Groucho2004]

Are you really sure of that? :confused:

When you say gcc, ¿don't you mean «a NON-MinGW-w64 toolchain»? :confused:
Avisynth C++ plugins must be built with MSVC or Intel C/C++ compiler (which uses MSVC libraries and linker).
Avisynth C-plugins however can be also be built with GCC.

[filler56789]

Avisynth C++ plugins must be built with MSVC or Intel C/C++ compiler (which uses MSVC libraries and linker).
Avisynth C-plugins however can be also be built with GCC.

Thanks for the clarification *THUMBS UP*

[VS_Fan]

Problem in AviSynth: Does this build support it?
Script error: ffindex does not have a named argument "uft8"

[VS_Fan]

It's working fine. I must have made some mistake. thanks again

[LigH]

I'm not sure which parameter would support a text codepage ... but if there is any at all: It's UTF, not UFT.

[Nico8583]

Hi :)
Could you tell me the difference between original releases, Wolfberry's releases and HolyWu's releases ?
I would like to use it with latest AviSynth+ MT in order to decode 1080p/4K video.
Thank you !

[Wolfberry]

My builds are for VapourSynth only.

HolyWu builds are AviSynth+ compatible and use newer libraries than the official one on GitHub, so you should use that.

[Nico8583]

Thank you ;)

[Nico8583]

I'm trying to open an AVS (.264 file extracted from a Blu ray with tsMuxeR) with FFmpegSource2 but it doesn't work.
I use "ffms2-r1273+4-win64-20190401" and "AviSynthPlus-MT-r2772".
The ffindex is created but if I try to encode with x264, it starts but nothing happen and if I try to open it with MPC-BE, it stays at "Opening'.
My AVS script is very simple :
LoadPlugin("ffms2.dll")
FFmpegSource2("D:\MyFile.264")
Could you help me ?
Thank you !

[sneaker_ger]

How long did you wait? FFmpegSource2 needs to index the file first. If the file is big and your HDD slow it can take minutes.

[Nico8583]

I tried 2 ways : let the AVS create the ffindex and create manually the ffindex then launch encoding/playing. Same result.

[sneaker_ger]

How long did you wait? How big is your file? How fast is your HDD (SSD?)?

[Nico8583]

I've deleted ffms2.dll and ffmsindex.exe from plugins64's AviSynth+ folder and copy it locally in the AVS folder and now it works.
Thank you for the help and sorry for inconvenience.

[LigH]

By the way, this is a raw video stream. FFVideoSource is sufficient here.

[dandyclubs]

megui 2908 x64
ffms2-r1273+4-win64-20190401
AviSynthPlus-MT-r2772

i replace ffms2.dll and ffmsindex.exe from ffms2-r1273+4-win64-20190401

bluray to mkv by megui hd streams extractor

make avs file by megui file indexer ffmsindex

but

megui hang when open avs script creator windows

error clould not read avs frame

https://i.imgur.com/r38lI2i.png

[stax76]

Is there a recent build that is not using the C interface and supports both avs and vs. I cannot use the C interface in staxrip because it is leaking memory.

[StainlessS]

Is there a recent build that is not using the C interface and supports both avs and vs. I cannot use the C interface in staxrip because it is leaking memory.
HolyWu post #2465, ffms2-r1273+4-win64-20190401.7z :- https://forum.doom9.org/showthread.php?p=1870563#post1870563
Is CPP, NON XP, Avs+ 64 bit(no x86 dll), supporting 10Bit, Only tested with 1920x1080 YUV422P10. (VS not tested, but has a VapourSynthPluinInit according to DependencyWalker).
Missing doc:- https://github.com/FFMS/ffms2/blob/master/doc/ffms2-avisynth.md

Older HolyWu version that is same as above:- ffms2-20181016-f3c6b00-win64.7z
https://forum.doom9.org/showthread.php?p=1858199#post1858199

EDIT: There is yet another at post 2489, ffms2-20190214-7c36121-win64.7z, Untested.

[stax76]

@StainlessS

I tried 2019-04-01 and it appears to have a memory issue as well.

[StvG]

You can try this (http://www.mediafire.com/file/yhctxufbr4pztd4/ffms2.7z/file) version too.

[stax76]

Thanks, I get this error:

Indexing using ffmsindex failed with exit code: -1073741511 (0xC0000139)
The exit code might be a system error code: {Entry Point Not Found}
The procedure entry point hs could not be located in the dynamic link library hs.

[StvG]

Can you try indexing with ffms2 (ffvideosource() will index the file)?

[stax76]

For staxrip I would need ffmsindex.

[StvG]

I added ffmsindex (same download link).
Do you have installed Visual C++ Redistributable for Visual Studio 2015+ (https://support.microsoft.com/en-us/help/2977003/the-latest-supported-visual-c-downloads)?

[stax76]

ffmsindex and memory management is working now, thanks! :thanks:

[StainlessS]

STvG,
How did you modify the zip on MediaFire without editing your original post #2483 link ? (Is it a paid MediaFire account option).

Thanx in advance.

[StvG]

I used trial upload option (without creating account). A pop up window appeared with options skip/replace/keep both when I uploaded the updated ffms2.7z (same file name as the previous one). I replaced the old file with the new one and the shared link is kept.
Other cloud services have an additional option to keep both files with same file names but without renaming any of them - old one is hidden and there is option to see versions of the files. Maybe MediaFire has this option too but just it's not available without account.

[StainlessS]

Thanks StvG,
I've had a little look around but dont see anything obvious to replace file using same link (Free Account).
If anyone has located MediaFire method to replace file for same link (in free of paid acc), then please post a howto somwhere, cheers.

[ChaosKing]

@StainlessS Have you considered hosting your stuff on github?
If a "stable link" is important, maybe dropbox is also an option for you.

[StainlessS]

@StainlessS Have you considered hosting your stuff on github?


Yes thanks, I considered it last time you suggested it :)
still same response though, not lookin' forward to figuring out the GIT stuff, maybe one day.

[stax76]

:thanks:

[frank]

HolyWu's release of ffms2 has the seek issue at ts streams again but the version (2.31.00 ??) from StvG is ok and much smaller.

StvG, how did you compile it?

[StvG]

My build has reverted those commits (https://forum.doom9.org/showpost.php?p=1848947&postcount=97). I didn't include any additional libraries (only ffmpeg release/4.1) but I guess the big difference in sizes comes from different compilers (I used msvc).

Here (https://www.sendspace.com/file/dvfvki) can be downloaded a newer build. It has reverted this commit (https://github.com/FFMS/ffms2/commit/722a02d77685e94c7aa7f39b6b38666d544cacb7) which should fix that issue (https://github.com/FFMS/ffms2/issues/345). Also it has removed the same thing related to AVC (https://github.com/FFMS/ffms2/blob/master/src/core/videosource.cpp#L189) which should fix an issue with 1 frame off.

[Wolfberry]

I didn't include any additional libraries
Your FFmpeg build doesn't have zlib? That's an additional library outside of FFmpeg source code.
but I guess the big difference in sizes comes from different compilers (I used msvc).

I will guess the size difference is beacause the Holywu build has more additional libraries than your build (libaom, libopenjpeg...)

[StvG]

Your FFmpeg build doesn't have zlib? That's an additional library outside of FFmpeg source code...

It has zlib.

[ChaosKing]

I've made a seeking test with "StvG ffms2" and it performs the same as "ffms2_test8.dll" https://forum.doom9.org/showthread.php?t=176231

[StvG]

Can you show which samples are VP9.mkv and VC1.mpg in your test?
Thanks

[ChaosKing]

Can you show which samples are VP9.mkv and VC1.mpg in your test?
Thanks

https://www.dropbox.com/sh/bxwibb20m8rnnro/AABmPSXEWGgE7nBK-PvwyU6Aa?dl=0

I wished the newer ffmpeg (ffms2) versions would also be frame accurate for the h264 mp4 files...

[videoh]

DGDecNV works good for that use case. If you have an nVidia card I can give you a free license (also any other Doom9 developers or contributors, just shoot me a PM).

[FranceBB]

I'm trying to index a DCP sample which has been exported in XYZ 4:4:4 12bit, however FFVideoSource seems to internally convert it to YUV 4:4:4 12bit.
Now I'm wondering... is there a way to let FFVideoSource output XYZ rather than YUV if someone wants to?
I mean, don't get me wrong, the idea of having the conversion done automatically is fine, but what if someone wants to get the original XYZ color space?

Images of what I mean:
Indexing (YUV) (https://i.imgur.com/WB4raGy.jpg) - Source (XYZ) (https://i.imgur.com/4NXvKJa.png)

Thank you in advance,
Frank.

[LigH]

AviSynth source filters can only output color spaces supported by AviSynth. At least to an AviSynth clip variable, to give following video filters any sensible meaning.

Regarding a "conversion" between XYZ and YUV, it might even just directly translate unknown color space components without any matrix math.

To receive different formats explicitly, it would have to be able to write a separate output file...

Does this "XYZ" refer to the CIE XYZ 1931 color space?

[Myrsloik]

I'm trying to index a DCP sample which has been exported in XYZ 4:4:4 12bit, however FFVideoSource seems to internally convert it to YUV 4:4:4 12bit.
Now I'm wondering... is there a way to let FFVideoSource output XYZ rather than YUV if someone wants to?
I mean, don't get me wrong, the idea of having the conversion done automatically is fine, but what if someone wants to get the original XYZ color space?

Images of what I mean:
Indexing (YUV) (https://i.imgur.com/WB4raGy.jpg) - Source (XYZ) (https://i.imgur.com/4NXvKJa.png)

Thank you in advance,
Frank.

VapourSynth might pass it through and there's a slight chance it'd be somewhat correctly flagged as well. I have no idea what you'd do with it next though since there's not much that can correctly work with the format.

[FranceBB]

Does this "XYZ" refer to the CIE XYZ 1931 color space?

Yes, CIE XYZ 1931.

VapourSynth might pass it through and there's a slight chance it'd be somewhat correctly flagged as well. I have no idea what you'd do with it next though since there's not much that can correctly work with the format.

I see... Well, although it's represented correctly, the idea would be to convert XYZ 1931 with my LUT rather than relying on the indexer to do that, but that's just a guess. I believe that for the vast majority of people having it in YUV 4:4:4 12bit planar is absolutely fine.

[real.finder]

if the convert between XYZ and YUV is lossless then it's ok, or maybe ffms2 need flag parameter (https://forum.doom9.org/showthread.php?p=1817009#post1817009)

isn't CIE XYZ more close to RGB than YUV? and CIE Lab is more close to YUV as said here (https://forum.doom9.org/showthread.php?p=1817006#post1817006)

maybe avs+ need to add those CIE things

[StvG]

I've made a seeking test with "StvG ffms2" and it performs the same as "ffms2_test8.dll" https://forum.doom9.org/showthread.php?t=176231

This one (https://www.sendspace.com/file/wyefy3) (built against ffmpeg 4.1.4) has fixed VP9 seeking and AV1 support (aom).

Btw "lsmas.LWLibavSource()" is showing "ok" for "VP9.mkv" (https://forum.doom9.org/showthread.php?t=176231) for most of the builds but the frames number is different than "ffms2.Source()" builds with "ok" for "VP9.mkv". How come?

[ChaosKing]

This one (https://www.sendspace.com/file/wyefy3) (built against ffmpeg 4.1.4) has fixed VP9 seeking and AV1 support (aom).

Btw "lsmas.LWLibavSource()" is showing "ok" for "VP9.mkv" (https://forum.doom9.org/showthread.php?t=176231) for most of the builds but the frames number is different than "ffms2.Source()" builds with "ok" for "VP9.mkv". How come?

This is something I noticed for some files too. In this case lsmas is not decoding it properly but still manages to return the correct frames (or at least the same frames while it was reading the file linearly)

I plan to make a new table with some more infos like detected total frame numer, fps, color space etc. ...

EDIT: And it seems I downloaded also some "problem" files where I don't know if testing these are a good thing or not.

[FranceBB]

ffms2-r1275+2-win64-20190808 (https://www.mediafire.com/file/erzaltr7hw7bc5r/ffms2-r1275+2-win64-20190808.7z/file)


Update to FFmpeg 4.2.
Switch to libdav1d for AV1 decoding.


May I ask you an x86 version for ffms2 as well?

Thank you in advance,
Frank

[jlw_4049]

ffms2-r1275+2-20190811 (https://www.mediafire.com/file/9dmplqvm17wpre0/ffms2-r1275+2-20190811.7z/file)


Update to FFmpeg 4.2.
Switch to libdav1d for AV1 decoding.


This build takes about 7 minutes and 30 seconds after indexing to finish. Stvg's build takes about 1 minute and 10 seconds after on a 4k Remux. What is the difference?

[jlw_4049]

What program did you use for testing to get the indexing time? ffmsindex.exe?

I'm using StaxRip. Both of them actually index at the same speed. However, after they are done indexing StaxRip minimizes to the background for 1 or 8 minutes depending on the filter. Seems like the filter is looping or something, as it slowly makes 1 .avs file, then the 2nd .avs file like 6 minutes later before finally bringing the GUI back up.

I can't figure out if it's an issue with Stax or with the filters. I'm also talking to Stax76 as well. Hoping to figure it out :/

[jlw_4049]

The filter itself never makes .avs file.

Try testing with another program like AvsPmod or VirtualDub2 and see whether the issue persists.

You are right. The issue isn't with the indexer. My apologies!

[stax76]

The filter itself never makes .avs file.

Try testing with another program like AvsPmod or VirtualDub2 and see whether the issue persists.

I tried with VirtualDub2 (uses avifile api like staxrip) and the problem persists, it needs minutes to load, the reason is the amount of subtitles streams, in this case there are 45 subtitle streams. StvG's last build loads in ten seconds.

MediaInfo:

https://pastebin.com/5Qd4qjA8

[Patman]

This one (https://www.sendspace.com/file/wyefy3) (built against ffmpeg 4.1.4) has fixed VP9 seeking and AV1 support (aom).

Btw "lsmas.LWLibavSource()" is showing "ok" for "VP9.mkv" (https://forum.doom9.org/showthread.php?t=176231) for most of the builds but the frames number is different than "ffms2.Source()" builds with "ok" for "VP9.mkv". How come?Hi STvG,

can you make new build with ffmpeg 4.2?

Gesendet von meinem HMA-L09 mit Tapatalk

[stax76]

@HolyWu

Thanks for the build, if it persists I try to reproduce it with a smaller file that I will upload then.

edit:

I'm still working on the issue but the first test shows that it's fixed!

[StvG]

Hi STvG,

can you make new build with ffmpeg 4.2?

Gesendet von meinem HMA-L09 mit Tapatalk

Hi. Here (https://www.sendspace.com/file/pv1gz6) is the updated version.
ffmpeg - n4.3-83e0b71
aom - 6788a07

[stax76]

@HolyWu

It's fixed, for my large test file the load time is now 25 seconds and the close time is 13 seconds, exactly identical to StvG's build, before the load time was several minutes, file is 50 GB, 3 audio and 45 subtitle tracks.

I've remuxed the file including all tracks and the load time was the same but after I remuxed it including only one audio and only one subtitle track the load time is 1 second !!!

edit:

3 audio tracks, 49 PGS subtitle tracks: 25 seconds load time
3 audio tracks, 0 PGS subtitle tracks: 1 second load time
1 audio tracks, 2 PGS subtitle tracks: 2 seconds load time
1 audio tracks, 10 PGS subtitle tracks: 3 seconds load time
1 audio tracks, 20 PGS subtitle tracks: 6 seconds load time

[Patman]

Hi. Here (https://www.sendspace.com/file/pv1gz6) is the updated version.
ffmpeg - n4.3-83e0b71
aom - 6788a07

Thanks a lot.

[ChaosKing]

Hi. Here (https://www.sendspace.com/file/pv1gz6) is the updated version.
ffmpeg - n4.3-83e0b71
aom - 6788a07
It seems FFmpeg 4.3 fixes some issues with frame seeking accuracity.

https://i.imgur.com/Gc3d5YV.png

[Natty]

Hi. Here (https://www.sendspace.com/file/pv1gz6) is the updated version.
ffmpeg - n4.3-83e0b71
aom - 6788a07

:thanks:

[StvG]

It seems FFmpeg 4.3 fixes some issues with frame seeking accuracity.

https://i.imgur.com/Gc3d5YV.png

Can you test the previous version with ffmpeg 4.1.4 (https://forum.doom9.org/showthread.php?p=1880545#post1880545)? I'm curious what is the difference.
Thanks.

[Myrsloik]

It seems FFmpeg 4.3 fixes some issues with frame seeking accuracity.

https://i.imgur.com/Gc3d5YV.png

Nice table. You've really captured why I hate to develop FFMS2.

[ChaosKing]

Can you test the previous version with ffmpeg 4.1.4 (https://forum.doom9.org/showthread.php?p=1880545#post1880545)? I'm curious what is the difference.
Thanks.

4.1 looks the same except it can't open the MXF file. The problems started with FFmpeg 4.2:devil: (but only for ffms2, lsmash is still frame accurate for almost everything.)

[StvG]

https://www.dropbox.com/sh/bxwibb20m8rnnro/AABmPSXEWGgE7nBK-PvwyU6Aa?dl=0

I wished the newer ffmpeg (ffms2) versions would also be frame accurate for the h264 mp4 files...

Here (https://ln2.sync.com/dl/8f41e53a0/j3h7zccs-idw6xu46-8qtydpnx-7xudd6ez/view/default/3079247800013) updated version. "ffms2_seeking_issue.mp4" is again "ok".
ffmpeg - n4.3-cc78783
aom - 05b3304

[ChaosKing]

Here (https://www.sendspace.com/file/dbwbfv) updated version. "ffms2_seeking_issue.mp4" is again "ok".
ffmpeg - n4.3-cc78783
aom - 05b3304

Can confirm. Seems like the "best" ffms2 version since the "ffms2-test8.dll" release.

[Natty]

Here (https://www.sendspace.com/file/dbwbfv) updated version. "ffms2_seeking_issue.mp4" is again "ok".
ffmpeg - n4.3-cc78783
aom - 05b3304

:thanks: working fine. lighter in size and maybe faster.

[Atak_Snajpera]

Here (https://www.sendspace.com/file/dbwbfv) updated version. "ffms2_seeking_issue.mp4" is again "ok".
ffmpeg - n4.3-cc78783
aom - 05b3304

pro tip. Use mediafire.com. sendspace is very slow (~80KiB/s)

[MeteorRain]

BTW if you need a (kinda) reliable and fast upload space for releases, I can provide some for free.

[StvG]

BTW if you need a (kinda) reliable and fast upload space for releases, I can provide some for free.

I wouldn't bother you with such thing.

The link is edited.

[StvG]

Update (https://ln2.sync.com/dl/917b6fe60/d9e5tyaq-qwmnwnbq-ks2xwnur-j9bbdfcz):
- ffmpeg n4.3_a746359;
- dav1d 0.4.0 (seeking accurate with threads=1 and still ~50% faster than aom).

[ChaosKing]

Update (https://ln2.sync.com/dl/917b6fe60/d9e5tyaq-qwmnwnbq-ks2xwnur-j9bbdfcz):
- ffmpeg n4.3_a746359;
- dav1d 0.4.0 (seeking accurate with threads=1 and still ~50% faster than aom).

Can confirm threads=1 is seeking accurate. (and threads=2 definitely not :D)

[FranceBB]

Update (https://ln2.sync.com/dl/917b6fe60/d9e5tyaq-qwmnwnbq-ks2xwnur-j9bbdfcz):
- ffmpeg n4.3_a746359;
- dav1d 0.4.0 (seeking accurate with threads=1 and still ~50% faster than aom).

Thank you for the updated build.

[markfilipak]

I see that my postings and the answers are being deleted. Could you leave them up long enough for me to copy them?

[StainlessS]

I would not know why your posts might be being deleted, however I think maybe you should not be posting in the developer section [EDIT: Programmer] , either avisynth, or maybe more at home in Newbies forum.

Here on Wiki the Internal filters section:- http://avisynth.nl/index.php/Internal_filters
and External:- http://avisynth.nl/index.php/Internal_filters

And x64:- http://avisynth.nl/index.php/AviSynth%2B_x64_plugins

[markfilipak]

I would not know why your posts might be being deleted, however I think maybe you should not be posting in the developer section [EDIT: Programmer] ...
Sorry. I didn't know. And I don't know of other forums. I was just following published links to here from the various git and plugin sites. For example,
@https://github.com/AviSynth/AviSynthPlus,
"Visit our forum thread <http://forum.doom9.org/showthread.php?t=168856> for compilation instructions and support"

... either avisynth, or maybe more at home in Newbies forum.

Where? Do you have a link?

The wiki doesn't accept questions.

[StainlessS]

To be fair, I have always disliked that our more accomplished programmers seem to deem it below themselves to have a thread in Avisynth Usage forum.
they only post threads in devs forum, and so everything is a bit screwed up [I wanted to use another word].
It is a complex world, & no place more so than this.

Avisynth Usage Forum:- http://forum.doom9.org/forumdisplay.php?f=33
Avisynth Newbies Forum:- http://forum.doom9.org/forumdisplay.php?f=6

The wiki doesn't accept questions.
I think a Wiki (I aint looked this up), is kinda like an accumulation of knowledge, a log of questions asked before [and hopefully answered too].

The place to ask questions is the forum, but as you have found out, not all questions will have answers that are to your liking.

As I've always said, "Life's a bitch and then you die", and I can give personal assurance that it dont get no better after that, kinda makes you wonder if the whole shabang was worth the effort.

[Groucho2004]

To be fair, I have always disliked that our more accomplished programmers seem to deem it below themselves to have a thread in Avisynth Usage forum.You and I must be part of the less accomplished breed then, right? :)

[markfilipak]

To be fair, I have always disliked that our more accomplished programmers seem to deem it below themselves to have a thread in Avisynth Usage forum.
they only post threads in devs forum, and so everything is a bit screwed up [I wanted to use another word].
It is a complex world, & no place more so than this.

Avisynth Usage Forum:- http://forum.doom9.org/forumdisplay.php?f=33

Thanks. I stumbled on the breadcrumbs and backed up through them and discovered forum #33.

Avisynth Newbies Forum:- http://forum.doom9.org/forumdisplay.php?f=6
Thanks for the link. It isn't avisynth (or avisynth+) oriented -- it doesn't even mention them -- but I'll try it.

The place to ask questions is the forum, but as you have found out, not all questions will have answers that are to your liking.
I have pretty thick skin. But the greeting here is chilly. In my case, I could become a developer, but ...such an unfriendly reception... It's discouraging and indicates that users are not welcome (which is a bad indicator of overall success for the application).

[Groucho2004]

I have pretty thick skin. But the greeting here is chilly. In my case, I could become a developer, but ...such an unfriendly reception... It's discouraging and indicates that users are not welcome (which is a bad indicator of overall success for the application).I went through every single of your 22 posts and could not find anything but helpful replies to them even though some of your posts indicate that you'd rather be spoon-fed information than do a bit of googling.

This is a forum for information exchange, don't expect users to blow candy up your bunghole.

[StainlessS]

In my case, I could become a developer

AhHa!,
So you think that we should have a forum for newbies that might or might not, at some future point in time, become developers. [interesting point of view].

And, no offence intended, but it dont really matter whether you may/may not at some unspecified point in future time be a developer, if you are asking newbie
questions in developer forum, you should be thankful for any kind of non abusive response at all. :)

Likewise, developer questions in Newbie Forum would be out of place.

EDIT: @ G2K4, obviously I do not count myself in my meandering about the other gifted/less gifted users of the forum [I am of course and as you would expect, be above all of that],
but I see that you readily accept and know your own position in the scheme of things. If one knows ones limits, one is rarely disappointed with ones achievements, and there lies your
future happiness or at least acceptance of what is, and what is not.

[poisondeathray]

I have pretty thick skin. But the greeting here is chilly. In my case, I could become a developer, but ...such an unfriendly reception... It's discouraging and indicates that users are not welcome (which is a bad indicator of overall success for the application).

There were some budget cutbacks and the cheer department got axed. (So no welcome wagons this year.)

This is all you get on such short notice
https://postimg.cc/8J7KpncS

In the past, you probably would have been "put on vacation" (suspended) for such multiple infractions, for not following the rules . For 1, 1a, 2, plus a few others. Seriously :scared: .
https://forum.doom9.org/forum-rules.htm

[videoh]

I could become a developer, but ...such an unfriendly reception... For sure! I tried to become a developer here too. But the admin decided to murder me. Now I am a happy nobody, and you are the next victim. Good luck!

[kedautinh12]

Update (https://ln2.sync.com/dl/917b6fe60/d9e5tyaq-qwmnwnbq-ks2xwnur-j9bbdfcz):
- ffmpeg n4.3_a746359;
- dav1d 0.4.0 (seeking accurate with threads=1 and still ~50% faster than aom).

Your ffms2 still error with .ts
Example:
https://drive.google.com/file/d/11tsEN5_qTqLJLCt8Q_jrBi6AYwcdwpX6/view?usp=drivesdk

[Patman]

Your ffms2 still error with .ts
Example:
https://drive.google.com/file/d/11tsEN5_qTqLJLCt8Q_jrBi6AYwcdwpX6/view?usp=drivesdk

Hi,

i can't reproduce the failure with your file.

[kedautinh12]

Hi,

i can't reproduce the failure with your file.

Error: "couldn't read avs frame"

[StvG]

Error: "couldn't read avs frame"
I can't reproduce the issue too.

Update: (https://cloud.owncube.com/s/McQSH8JG67zzKt4)
- ffmpeg n4.3_9cd56bb;
- dav1d 0.5.1 (default threads=1 for AV1).

[kedautinh12]

I can't reproduce the issue too.

Update: (https://cloud.owncube.com/s/McQSH8JG67zzKt4)
- ffmpeg n4.3_9cd56bb;
- dav1d 0.5.1 (default threads=1 for AV1).

My warning log when load example video with your built:
[Warning] Log
-[Information] Versions
--[Information] MeGUI: 2913 x64
--[Information] MeGUI Debug Data: available
--[Information] Update Check: development update server
--[Information] System Information
---[Information] Operating System: Windows 10 Pro 1903 x64 (10.0.18362.476)
---[Information] .NET Framework: 4.0 (4.0.0.0)
---[Information] .NET Framework: 4.8 (4.8.03752)
---[Information] Redistributables
----[Information] Microsoft Visual C++ 2005 x64: 8.0.61000
----[Information] Microsoft Visual C++ 2005 x86: 8.0.61001
----[Information] Microsoft Visual C++ 2010 x64: 10.0.40219
----[Information] Microsoft Visual C++ 2010 x86: 10.0.40219
----[Information] Microsoft Visual C++ 2012 x64: 11.0.61030
----[Information] Microsoft Visual C++ 2012 x86: 11.0.61030
----[Information] Microsoft Visual C++ 2013 x64: 12.0.40664
----[Information] Microsoft Visual C++ 2013 x86: 12.0.40664
----[Information] Microsoft Visual C++ 2015-2019 x64: 14.23.27820
----[Information] Microsoft Visual C++ 2015-2019 x86: 14.23.27820
---[Information] DPI: 100% (96/96)
---[Information] Monitor 1
----[Information] Resolution: 1366x768
----[Information] Primary Screen: True
--[Information] Component Information
---[Information] Haali Media Splitter: 1.13.138.14 (14-04-2013)
---[Information] Haali DSS2: not installed
---[Information] ICSharpCode.SharpZipLib: 0.85.5.452 (07-08-2008)
---[Information] MediaInfo: 18.05.0.0 (08-05-2018)
---[Information] SevenZipSharp: 0.64.3890.29348 (02-01-2011)
---[Information] 7z: 9.20 (18-11-2010)
--[Information] AviSynth Information
---[Information] AviSynth Wrapper
----[Information] Version: 1.0.2847.0
----[Information] Date: 06-05-2018
----[Information] Interface: 3
---[Information] AviSynth
----[Information] AviSynth Status: ignored as portable build is forced
---[Information] AviSynth portable
----[Information] File Version: 3.4
----[Information] File Date: 20-10-2019
----[Information] File Name: AviSynth+ 3.4 (r2923, 3.4, x86_64)
----[Information] File Path: e:\megui-2913-64\avisynth.dll
----[Information] AviSynth Version: AviSynth+ 3.4 (r2923, 3.4, x86_64)
----[Information] AviSynth+: true
----[Information] AviSynth MT: true
----[Information] AviSynth Status: active
-[Information] Update detection
--[Information] [11/26/2019 6:42:53 AM] Cannot use update server http://megui.org/auto/. Reason: Update server is not available
--[Information] [11/26/2019 6:42:54 AM] Connected to server: http://megui.tmebi.de/test/
--[Information] [11/26/2019 6:42:57 AM] No package requires an update
-[Information] FileIndexer
--[Information] [11/26/2019 6:43:26 AM] MediaInfo
---[Information] File: C:\Users\84945\Downloads\Video for test\Haru no Hi - Aimyon PV.ts
---[Information] General
----[Information] Format: MPEG-TS
----[Information] FileSize: 147849216
----[Information] PlayTime: 00:04:22.912
---[Information] Video
----[Information] ID: 4352
----[Information] StreamOrder: 0-0
----[Information] CodecID: 27
----[Information] Format: AVC
----[Information] FormatInfo: Advanced Video Codec
----[Information] Width: 1440
----[Information] Height: 1080
----[Information] FrameCount: 7852
----[Information] FrameRate: 29.970
----[Information] Duration: 00:04:21.995
----[Information] ScanType: Interlaced
----[Information] Bits Depth: 8
----[Information] AspectRatio: 1.778
----[Information] AspectRatioString: 16:9
----[Information] PixelAspectRatio: 1.333
----[Information] Delay: 1079.911
---[Information] Audio
----[Information] ID: 4353
----[Information] StreamOrder: 0-1
----[Information] CodecID: 15
----[Information] Format: AAC
----[Information] FormatVersion: Version 2
----[Information] FormatInfo: Advanced Audio Codec
----[Information] FormatProfile: LC
----[Information] Muxing Mode: ADTS
----[Information] SamplingRate: 48000
----[Information] SamplingRateString: 48.0 kHz
----[Information] Channels: 2
----[Information] ChannelsString: 2 channels
----[Information] ChannelPositionsString2: 2/0/0
----[Information] BitRateMode: VBR
----[Information] Delay: 1079.911
----[Information] [11/26/2019 6:43:27 AM] The language information is not available for this track. The default MeGUI language has been selected.
-[Information] Log for job1 (idx, Haru no Hi - Aimyon PV.ts -> Haru no Hi - Aimyon PV.ts.ffindex)
--[Information] [11/26/2019 6:43:30 AM] Started handling job
--[Information] [11/26/2019 6:43:30 AM] Preprocessing
--[Information] [11/26/2019 6:43:30 AM] Job command line: "E:\MeGUI-2913-64\tools\ffms\ffmsindex.exe" -t -1 -f "C:\Users\84945\Downloads\Video for test\Haru no Hi - Aimyon PV.ts" "C:\Users\84945\Downloads\Video for test\Haru no Hi - Aimyon PV.ts.ffindex"
--[Information] [11/26/2019 6:43:30 AM] Process started
--[Information] [11/26/2019 6:43:30 AM] Standard output stream
---[Information] [11/26/2019 6:43:33 AM] Writing index... done.
--[Information] [11/26/2019 6:43:30 AM] Standard error stream
--[Information] [11/26/2019 6:43:36 AM] MediaInfo
---[Information] File: C:\Users\84945\Downloads\Video for test\Haru no Hi - Aimyon PV.ts.ffindex
---[Information] General
----[Information] FileSize: 84348
--[Information] [11/26/2019 6:43:36 AM] Postprocessing
---[Information] [11/26/2019 6:43:41 AM] Deleting intermediate files
--[Information] [11/26/2019 6:43:41 AM] Job completed
-[Warning] AVS Script Creator
--[Warning] [11/26/2019 6:43:41 AM] Could not read frame: FFVideoSource: Out of bounds frame requested
--[Warning] [11/26/2019 6:43:50 AM] Could not read frame: FFVideoSource: Out of bounds frame requested

[LigH]

ffms2-r1275+2-20190811 (https://www.mediafire.com/file/9dmplqvm17wpre0/ffms2-r1275+2-20190811.7z/file)

:confused: It disappeared...

[kedautinh12]

:confused: It disappeared...

Yeah, cause ffmpeg n4.3_9cd56bb can decoding more format than it

[LigH]

I missed StvG's release, only looked for HolyWu's...

[kedautinh12]

I missed StvG's release, only looked for HolyWu's...

He pass FFmpegSource and focus l-smash source release

[kedautinh12]

My warning log when load example video with your built:
[Warning] Log
-[Information] Versions
--[Information] MeGUI: 2913 x64
--[Information] MeGUI Debug Data: available
--[Information] Update Check: development update server
--[Information] System Information
---[Information] Operating System: Windows 10 Pro 1903 x64 (10.0.18362.476)
---[Information] .NET Framework: 4.0 (4.0.0.0)
---[Information] .NET Framework: 4.8 (4.8.03752)
---[Information] Redistributables
----[Information] Microsoft Visual C++ 2005 x64: 8.0.61000
----[Information] Microsoft Visual C++ 2005 x86: 8.0.61001
----[Information] Microsoft Visual C++ 2010 x64: 10.0.40219
----[Information] Microsoft Visual C++ 2010 x86: 10.0.40219
----[Information] Microsoft Visual C++ 2012 x64: 11.0.61030
----[Information] Microsoft Visual C++ 2012 x86: 11.0.61030
----[Information] Microsoft Visual C++ 2013 x64: 12.0.40664
----[Information] Microsoft Visual C++ 2013 x86: 12.0.40664
----[Information] Microsoft Visual C++ 2015-2019 x64: 14.23.27820
----[Information] Microsoft Visual C++ 2015-2019 x86: 14.23.27820
---[Information] DPI: 100% (96/96)
---[Information] Monitor 1
----[Information] Resolution: 1366x768
----[Information] Primary Screen: True
--[Information] Component Information
---[Information] Haali Media Splitter: 1.13.138.14 (14-04-2013)
---[Information] Haali DSS2: not installed
---[Information] ICSharpCode.SharpZipLib: 0.85.5.452 (07-08-2008)
---[Information] MediaInfo: 18.05.0.0 (08-05-2018)
---[Information] SevenZipSharp: 0.64.3890.29348 (02-01-2011)
---[Information] 7z: 9.20 (18-11-2010)
--[Information] AviSynth Information
---[Information] AviSynth Wrapper
----[Information] Version: 1.0.2847.0
----[Information] Date: 06-05-2018
----[Information] Interface: 3
---[Information] AviSynth
----[Information] AviSynth Status: ignored as portable build is forced
---[Information] AviSynth portable
----[Information] File Version: 3.4
----[Information] File Date: 20-10-2019
----[Information] File Name: AviSynth+ 3.4 (r2923, 3.4, x86_64)
----[Information] File Path: e:\megui-2913-64\avisynth.dll
----[Information] AviSynth Version: AviSynth+ 3.4 (r2923, 3.4, x86_64)
----[Information] AviSynth+: true
----[Information] AviSynth MT: true
----[Information] AviSynth Status: active
-[Information] Update detection
--[Information] [11/26/2019 6:42:53 AM] Cannot use update server http://megui.org/auto/. Reason: Update server is not available
--[Information] [11/26/2019 6:42:54 AM] Connected to server: http://megui.tmebi.de/test/
--[Information] [11/26/2019 6:42:57 AM] No package requires an update
-[Information] FileIndexer
--[Information] [11/26/2019 6:43:26 AM] MediaInfo
---[Information] File: C:\Users\84945\Downloads\Video for test\Haru no Hi - Aimyon PV.ts
---[Information] General
----[Information] Format: MPEG-TS
----[Information] FileSize: 147849216
----[Information] PlayTime: 00:04:22.912
---[Information] Video
----[Information] ID: 4352
----[Information] StreamOrder: 0-0
----[Information] CodecID: 27
----[Information] Format: AVC
----[Information] FormatInfo: Advanced Video Codec
----[Information] Width: 1440
----[Information] Height: 1080
----[Information] FrameCount: 7852
----[Information] FrameRate: 29.970
----[Information] Duration: 00:04:21.995
----[Information] ScanType: Interlaced
----[Information] Bits Depth: 8
----[Information] AspectRatio: 1.778
----[Information] AspectRatioString: 16:9
----[Information] PixelAspectRatio: 1.333
----[Information] Delay: 1079.911
---[Information] Audio
----[Information] ID: 4353
----[Information] StreamOrder: 0-1
----[Information] CodecID: 15
----[Information] Format: AAC
----[Information] FormatVersion: Version 2
----[Information] FormatInfo: Advanced Audio Codec
----[Information] FormatProfile: LC
----[Information] Muxing Mode: ADTS
----[Information] SamplingRate: 48000
----[Information] SamplingRateString: 48.0 kHz
----[Information] Channels: 2
----[Information] ChannelsString: 2 channels
----[Information] ChannelPositionsString2: 2/0/0
----[Information] BitRateMode: VBR
----[Information] Delay: 1079.911
----[Information] [11/26/2019 6:43:27 AM] The language information is not available for this track. The default MeGUI language has been selected.
-[Information] Log for job1 (idx, Haru no Hi - Aimyon PV.ts -> Haru no Hi - Aimyon PV.ts.ffindex)
--[Information] [11/26/2019 6:43:30 AM] Started handling job
--[Information] [11/26/2019 6:43:30 AM] Preprocessing
--[Information] [11/26/2019 6:43:30 AM] Job command line: "E:\MeGUI-2913-64\tools\ffms\ffmsindex.exe" -t -1 -f "C:\Users\84945\Downloads\Video for test\Haru no Hi - Aimyon PV.ts" "C:\Users\84945\Downloads\Video for test\Haru no Hi - Aimyon PV.ts.ffindex"
--[Information] [11/26/2019 6:43:30 AM] Process started
--[Information] [11/26/2019 6:43:30 AM] Standard output stream
---[Information] [11/26/2019 6:43:33 AM] Writing index... done.
--[Information] [11/26/2019 6:43:30 AM] Standard error stream
--[Information] [11/26/2019 6:43:36 AM] MediaInfo
---[Information] File: C:\Users\84945\Downloads\Video for test\Haru no Hi - Aimyon PV.ts.ffindex
---[Information] General
----[Information] FileSize: 84348
--[Information] [11/26/2019 6:43:36 AM] Postprocessing
---[Information] [11/26/2019 6:43:41 AM] Deleting intermediate files
--[Information] [11/26/2019 6:43:41 AM] Job completed
-[Warning] AVS Script Creator
--[Warning] [11/26/2019 6:43:41 AM] Could not read frame: FFVideoSource: Out of bounds frame requested
--[Warning] [11/26/2019 6:43:50 AM] Could not read frame: FFVideoSource: Out of bounds frame requested

I think everyone can't fix my error

[videoh]

Or nobody wants to help you with downloaded files.

[ChaosKing]

Use seekmode=0 for ts /m2ts files with ffms2 or try lsmash.

[kedautinh12]

Use seekmode=0 for ts /m2ts files with ffms2 or try lsmash.

Still error with seekmode=0 but .ts work with ffms2 2.23.1 in https://github.com/FFMS/ffms2/releases

[l33tmeatwad]

Compiled the last official stable release with FFMPEG 4.2.2 libs, figured a few people may be interested in having it so here it is:

FFMS2 2.23.1 (w/ FFmpeg 4.2.2)
Static Libs Build (x86 & x64) (http://www.mediafire.com/file/yyabrt1jkmmlvsn) | Sources (https://www.mediafire.com/folder/3tv37w2c9ibps/Source)

Build Notes:
Compiled with Microsoft Visual Studio 2015
Shared Libs & Include Files were copied to the Visual Studio Directories in: C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC
Patch included with previous releases was applied to FFmpeg before compiling.

Static FFmpeg libs compiled with:
./configure --toolchain=msvc --enable-gpl --enable-version3 --disable-encoders --disable-programs --disable-filters \
--disable-network --disable-doc --disable-avdevice --disable-swresample --disable-postproc --disable-avfilter --enable-avresample
make install

Visual Studio Project Modifications
Project Properties > Configuration Properties > Linker > Input
- Additional Dependencies: bcrypt.lib;

Changes to libs.cpp
#pragma comment(lib, "zlibstat.lib")

Included Libs:
LibAV (from FFmpeg 4.2.2) (https://github.com/ffmpeg/ffmpeg/releases)
zlib 1.2.11 (http://zlib.net)

Other Software:
MSYS2 (https://www.msys2.org/) (i686 & x86_64)
Yasm 1.3.0 (http://yasm.tortall.net/Download.html) (General Use Executables)

[FranceBB]

Thank you, I just tried the x86 build and it works fine. :)

[kedautinh12]

Compiled the last official stable release with FFMPEG 4.2.2 libs, figured a few people may be interested in having it so here it is:

FFMS2 2.23.1 (w/ FFmpeg 4.2.2)
Static Libs Build (x86 & x64) (http://www.mediafire.com/file/yyabrt1jkmmlvsn) | Sources (https://www.mediafire.com/folder/3tv37w2c9ibps/Source)

Build Notes:
Compiled with Microsoft Visual Studio 2015
Shared Libs & Include Files were copied to the Visual Studio Directories in: C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC
Patch included with previous releases was applied to FFmpeg before compiling.

Static FFmpeg libs compiled with:
./configure --toolchain=msvc --enable-gpl --enable-version3 --disable-encoders --disable-programs --disable-filters \
--disable-network --disable-doc --disable-avdevice --disable-swresample --disable-postproc --disable-avfilter --enable-avresample
make install

Visual Studio Project Modifications
Project Properties > Configuration Properties > Linker > Input
- Additional Dependencies: bcrypt.lib;

Changes to libs.cpp
#pragma comment(lib, "zlibstat.lib")

Included Libs:
LibAV (from FFmpeg 4.2.2) (https://github.com/ffmpeg/ffmpeg/releases)
zlib 1.2.11 (http://zlib.net)

Other Software:
MSYS2 (https://www.msys2.org/) (i686 & x86_64)
Yasm 1.3.0 (http://yasm.tortall.net/Download.html) (General Use Executables)

thanks, but still error with .vob file
-[Information] AutoEncode
--[Information] C:\Users\84945\Downloads\Video for test\VTS_01_1.vob.video-muxed.mkv
---[Information] [1/3/2020 8:09:25 AM] No Target Size (use profile settings)
---[Information] [1/3/2020 8:09:25 AM] Split Size: null
---[Information] [1/3/2020 8:09:25 AM] Eliminating duplicate filenames
----[Information] [1/3/2020 8:09:25 AM] Video output file: C:\Users\84945\Downloads\Video for test\VTS_01_1.vob.video.264
----[Information] [1/3/2020 8:09:25 AM] Muxed output file: C:\Users\84945\Downloads\Video for test\VTS_01_1.vob.video-muxed.mkv
----[Information] [1/3/2020 8:09:25 AM] Encodable audio stream 0: C:\Users\84945\Downloads\Video for test\VTS_01_1.vob_track_1_vietnamese.audio.m4a
-[Information] Log for job1 (audio, VTS_01_1.vob_track_1_vietnamese.avs -> VTS_01_1.vob_track_1_vietnamese.audio.m4a)
--[Information] [1/3/2020 8:09:25 AM] Started handling job
--[Information] [1/3/2020 8:09:25 AM] Preprocessing
--[Information] [1/3/2020 8:09:25 AM] MediaInfo
---[Information] File: C:\Users\84945\Downloads\Video for test\VTS_01_1.vob_track_1_vietnamese.avs
---[Information] AVS input file detected. Getting media information from AviSynth.
---[Information] General
----[Information] Format: AVS
----[Information] FormatString: AviSynth Script
----[Information] FileSize: 196
----[Information] PlayTime: 00:03:57.2050000
---[Information] Audio
----[Information] ID: 0
----[Information] Format: AVS
----[Information] SamplingRate: 48000
----[Information] SamplingRateString: 48000
----[Information] Channels: 2
----[Information] ChannelsString: 2 channels
----[Information] BitRateMode: CBR
----[Information] Delay: 0
----[Information] [1/3/2020 8:09:27 AM] The language information is not available for this track. The default MeGUI language has been selected.
--[Information] [1/3/2020 8:09:28 AM] AviSynth script
---[NoImage] ClearAutoloadDirs()
---[NoImage] AddAutoloadDir("E:\MeGUI-2913-64\tools\avs\plugins")
---[NoImage] Import("C:\Users\84945\Downloads\Video for test\VTS_01_1.vob_track_1_vietnamese.avs")
---[NoImage] # detected channels: 2
---[NoImage] # detected channel positions:
---[NoImage] Normalize()
---[NoImage] return last
--[Information] [1/3/2020 8:09:28 AM] Command line used: -ignorelength -cbr 129000 -if - -of "{0}"
--[Information] [1/3/2020 8:09:28 AM] AviSynth script environment opened
--[Information] [1/3/2020 8:09:29 AM] Script loaded
--[Information] [1/3/2020 8:09:29 AM] Output Decoder
---[Information] [1/3/2020 8:09:29 AM] Channels: 2
---[Information] [1/3/2020 8:09:29 AM] Bits per sample: 16
---[Information] [1/3/2020 8:09:29 AM] Sample rate: 48000
--[Information] [1/3/2020 8:09:29 AM] Job command line: E:\MeGUI-2913-64\tools\eac3to\neroAacEnc.exe -ignorelength -cbr 129000 -if - -of "C:\Users\84945\Downloads\Video for test\VTS_01_1.vob_track_1_vietnamese.audio.m4a"
--[Information] [1/3/2020 8:09:29 AM] Process started
--[Information] [1/3/2020 8:09:29 AM] Standard output stream
--[Information] [1/3/2020 8:09:29 AM] Standard error stream
---[Information] [1/3/2020 8:09:33 AM] *************************************************************
---[Information] [1/3/2020 8:09:33 AM] * *
---[Information] [1/3/2020 8:09:33 AM] * Nero AAC Encoder *
---[Information] [1/3/2020 8:09:33 AM] * Copyright 2009 Nero AG *
---[Information] [1/3/2020 8:09:33 AM] * All Rights Reserved Worldwide *
---[Information] [1/3/2020 8:09:33 AM] * *
---[Information] [1/3/2020 8:09:33 AM] * Package build date: Feb 18 2010 *
---[Information] [1/3/2020 8:09:33 AM] * Package version: 1.5.4.0 *
---[Information] [1/3/2020 8:09:33 AM] * *
---[Information] [1/3/2020 8:09:33 AM] * See -help for a complete list of available parameters. *
---[Information] [1/3/2020 8:09:33 AM] * *
---[Information] [1/3/2020 8:09:33 AM] *************************************************************
--[Information] [1/3/2020 8:09:35 AM] MediaInfo
---[Information] File: C:\Users\84945\Downloads\Video for test\VTS_01_1.vob_track_1_vietnamese.audio.m4a
---[Information] General
----[Information] Format: MPEG-4
----[Information] FileSize: 3874803
----[Information] PlayTime: 00:03:57.269
---[Information] Audio
----[Information] ID: 1
----[Information] StreamOrder: 0
----[Information] CodecID: mp4a-40-2
----[Information] Format: AAC
----[Information] FormatInfo: Advanced Audio Codec
----[Information] FormatProfile: LC
----[Information] FormatSettingsSBR: No (Explicit)
----[Information] SamplingRate: 48000
----[Information] SamplingRateString: 48.0 kHz
----[Information] Channels: 2
----[Information] ChannelsString: 2 channels
----[Information] ChannelPositionsString2: 2/0/0
----[Information] BitRateMode: VBR
----[Information] [1/3/2020 8:09:35 AM] The language information is not available for this track. The default MeGUI language has been selected.
--[Information] [1/3/2020 8:09:35 AM] Postprocessing
---[Information] [1/3/2020 8:09:35 AM] Deleting intermediate files
--[Information] [1/3/2020 8:09:35 AM] Job completed
-[Error] Log for job2 (video, VTS_01_1.vob.avs -> VTS_01_1.vob.video.264)
--[Information] [1/3/2020 8:09:35 AM] Started handling job
--[Information] [1/3/2020 8:09:35 AM] Preprocessing
--[Information] [1/3/2020 8:09:35 AM] AviSynth input script
---[NoImage] LoadPlugin("E:\MeGUI-2913-64\tools\ffms\ffms2.dll")
---[NoImage] FFVideoSource("C:\Users\84945\Downloads\Video for test\VTS_01_1.VOB", fpsnum=24000, fpsden=1001, threads=1, colorspace="YUV420P8")
---[NoImage] #deinterlace
---[NoImage] #crop
---[NoImage] LanczosResize(720,392) # Lanczos (Sharp)
---[NoImage] #denoise
--[Information] [1/3/2020 8:09:36 AM] resolution: 720x392
--[Information] [1/3/2020 8:09:36 AM] frame rate: 24000/1001
--[Information] [1/3/2020 8:09:36 AM] frames: 5687
--[Information] [1/3/2020 8:09:36 AM] length: 00:03:57.195
--[Information] [1/3/2020 8:09:36 AM] aspect ratio (avs): 90:49 (1.837)
--[Information] [1/3/2020 8:09:36 AM] color space: I420
--[Warning] [1/3/2020 8:09:36 AM] --vbv-bufsize is not restricted. Maximum value for level 4.1 is 78125. Playback may be affected. Reselect AVC level/profile or target playback device in the x264 preset to set the proper value.
--[Warning] [1/3/2020 8:09:36 AM] --vbv-maxrate is not restricted. Maximum value for level 4.1 is 62500. Playback may be affected. Reselect AVC level/profile or target playback device in the x264 preset to set the proper value.
--[Information] [1/3/2020 8:09:37 AM] Job command line: "E:\MeGUI-2913-64\tools\x264\x264.exe" --level 4.1 --preset veryslow --crf 18 --deblock -3:-3 --keyint 23 --min-keyint 1 --bframes 16 --aq-mode 3 --merange 64 --psy-rd 1.0:0.15 --no-fast-pskip --sar 1:1 --frames 5687 --output "C:\Users\84945\Downloads\Video for test\VTS_01_1.vob.video.264" "C:\Users\84945\Downloads\Video for test\VTS_01_1.vob.avs"
--[Information] [1/3/2020 8:09:37 AM] Process started
--[Information] [1/3/2020 8:09:37 AM] Standard output stream
--[Error] [1/3/2020 8:09:37 AM] Standard error stream
---[Information] [1/3/2020 8:09:39 AM] avs [info]: 720x392p 1:1 @ 24000/1001 fps (cfr)
---[Information] [1/3/2020 8:09:39 AM] avs [info]: color matrix: undef
---[Information] [1/3/2020 8:09:39 AM] x264 [info]: using SAR=1/1
---[Information] [1/3/2020 8:09:39 AM] x264 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2
---[Information] [1/3/2020 8:09:39 AM] x264 [info]: profile High, level 4.1, 4:2:0, 8-bit
---[Information] [1/3/2020 8:09:39 AM] x264 [info]: cabac=1 ref=16 deblock=1:-3:-3 analyse=0x3:0x133 me=umh subme=10 psy=1 fade_compensate=0.00 psy_rd=1.00:0.15 mixed_ref=1 me_range=64 chroma_me=1 trellis=2 8x8dct=1 cqm=0 deadzone=21,11 fast_pskip=0 chroma_qp_offset=-3 threads=3 lookahead_threads=1 sliced_threads=0 nr=0 decimate=1 interlaced=0 bluray_compat=0 constrained_intra=0 fgo=0 bframes=16 b_pyramid=2 b_adapt=2 b_bias=0 direct=3 weightb=1 open_gop=0 weightp=2 keyint=23 keyint_min=1 scenecut=40 intra_refresh=0 rc_lookahead=23 rc=crf mbtree=1 crf=18.0000 qcomp=0.60 qpmin=0:0:0 qpmax=69:69:69 qpstep=4 ip_ratio=1.40 aq=3:1.00 aq-sensitivity=10.00 aq-factor=1.00:1.00:1.00 aq2=0 aq3=0
---[Information] [1/3/2020 8:09:39 AM] x264 [info]: started at Fri Jan 03 08:09:38 2020
---[Error] [1/3/2020 8:13:26 AM] avs [error]: FFVideoSource: Out of bounds frame requested occurred while reading frame 5675
---[Error] [1/3/2020 8:13:26 AM] avs [error]: FFVideoSource: Out of bounds frame requested occurred while reading frame 5676
---[Information] [1/3/2020 8:13:27 AM] x264 [info]: frame I:256 Avg QP: 7.17 size: 16613
---[Information] [1/3/2020 8:13:27 AM] x264 [info]: frame P:1559 Avg QP:14.80 size: 8027
---[Information] [1/3/2020 8:13:27 AM] x264 [info]: frame B:3860 Avg QP:18.03 size: 3799
---[Information] [1/3/2020 8:13:27 AM] x264 [info]: consecutive B-frames: 9.2% 6.7% 14.2% 35.2% 15.9% 11.5% 2.8% 0.8% 0.0% 0.4% 0.8% 0.4% 0.0% 0.2% 0.0% 0.8% 0.9%
---[Information] [1/3/2020 8:13:27 AM] x264 [info]: mb I I16..4: 66.5% 18.2% 15.3%
---[Information] [1/3/2020 8:13:27 AM] x264 [info]: mb P I16..4: 3.6% 6.3% 3.4% P16..4: 11.8% 5.6% 4.7% 1.0% 0.4% skip:63.2%
---[Information] [1/3/2020 8:13:27 AM] x264 [info]: mb B I16..4: 0.1% 0.7% 0.9% B16..8: 12.4% 5.6% 2.4% direct: 1.4% skip:76.5% L0:40.9% L1:37.8% BI:21.3%
---[Information] [1/3/2020 8:13:27 AM] x264 [info]: 8x8 transform intra:32.3% inter:42.1%
---[Information] [1/3/2020 8:13:27 AM] x264 [info]: direct mvs spatial:99.5% temporal:0.5%
---[Information] [1/3/2020 8:13:27 AM] x264 [info]: coded y,uvDC,uvAC intra: 44.3% 48.1% 42.5% inter: 7.9% 7.6% 4.0%
---[Information] [1/3/2020 8:13:27 AM] x264 [info]: i16 v,h,dc,p: 73% 15% 6% 7%
---[Information] [1/3/2020 8:13:27 AM] x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 15% 14% 21% 6% 8% 10% 8% 9% 9%
---[Information] [1/3/2020 8:13:27 AM] x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 12% 11% 12% 8% 14% 13% 10% 10% 10%
---[Information] [1/3/2020 8:13:27 AM] x264 [info]: i8c dc,h,v,p: 67% 13% 11% 8%
---[Information] [1/3/2020 8:13:27 AM] x264 [info]: Weighted P-Frames: Y:1.3% UV:0.3%
---[Information] [1/3/2020 8:13:27 AM] x264 [info]: ref P L0: 61.1% 7.9% 15.3% 6.0% 3.5% 2.5% 1.6% 0.9% 0.6% 0.4% 0.2% 0.1% 0.0% 0.0% 0.0% 0.0%
---[Information] [1/3/2020 8:13:27 AM] x264 [info]: ref B L0: 83.0% 8.6% 4.0% 1.7% 1.1% 0.7% 0.5% 0.2% 0.1% 0.1% 0.0% 0.0% 0.0% 0.0%
---[Information] [1/3/2020 8:13:27 AM] x264 [info]: ref B L1: 96.8% 3.2%
---[Information] [1/3/2020 8:13:27 AM] x264 [info]: kb/s:1062.28
---[Information] [1/3/2020 8:13:27 AM] encoded 5675 frames, 24.88 fps, 1062.28 kb/s, 29.97 MB
---[Information] [1/3/2020 8:13:27 AM] x264 [info]: ended at Fri Jan 03 08:13:26 2020
---[Information] [1/3/2020 8:13:27 AM] x264 [info]: encoding duration 0:03:48
--[Information] [1/3/2020 8:13:27 AM] Job completed

video test: https://drive.google.com/open?id=1IjCojW2jgSLjJNaUwqKpJm74NlbwGrep

[tebasuna51]

thanks, but still error with .vob file
...
---[Error] [1/3/2020 8:13:26 AM] avs [error]: FFVideoSource: Out of bounds frame requested occurred while reading frame 5675
---[Error] [1/3/2020 8:13:26 AM] avs [error]: FFVideoSource: Out of bounds frame requested occurred while reading frame 5676
...

video test: https://drive.google.com/open?id=1IjCojW2jgSLjJNaUwqKpJm74NlbwGrep

You must know something about VOB files.
If you load your IFO file over PgcDemux you can see the image attached.

Your video duration is 4:05.00, if you create one file per VID (Click Process! in the image) you obtain 2 VOB files:

VTS_01_1_001.VOB
------------------------------------------------------------------------------
VOB, 1 video track, 1 audio track, 0:03:57
1: MPEG2, 480p24 /1.001 (16:9) with pulldown flags
2: RAW/PCM, 2.0 channels, 16 bits, 48kHz

VTS_01_1_002.VOB
------------------------------------------------------------------------------
VOB, 1 video track, 0:00:08
1: MPEG2, 480i60 /1.001 (16:9)

The first one can be managed without problems with any decoder and obtain a perfect video 23.976 with the audio.

The second one is a true 29.970 credit (Sony) video without audio.
Seems than FFVideoSource crash when the final credit change video and audio parameters.

BTW MeGUI work fine for me, managing the correct video and don't offer me use ffms2 decoder, only DGIndex or DGIndexNV.

[l33tmeatwad]

thanks, but still error with .vob file


video test: https://drive.google.com/open?id=1IjCojW2jgSLjJNaUwqKpJm74NlbwGrep
Any particular reason you are trying to use ffms2 and not DGIndex then mpeg2source?

[kedautinh12]

Oh, thanks

[kedautinh12]

BTW MeGUI work fine for me, managing the correct video and don't offer me use ffms2 decoder, only DGIndex or DGIndexNV.

I see megui offer some .ts file use DGIndex but video encoded audio don't sync with video, same error with L-Smash
Video test: https://drive.google.com/a/my.smccd.edu/file/d/10S58IpaUueoRTEfo1cX1hJfxTFPp2I0Y/view?usp=drivesdk
After i was changed to ffms2 and audio can sync with video

Alternatively, megui offer some .ts with L-smash and it's work perfectly
Video test: https://drive.google.com/a/my.smccd.edu/file/d/1GzeVf1ecvarEz_d5TiK7Y4TNlpvkU-fw/view?usp=drivesdk

[kedautinh12]

Any particular reason you are trying to use ffms2 and not DGIndex then mpeg2source?

I see DGIndex too old (2010), i want found new index continue updated like ffms2 or l-smash to replaced DGIndex

[StainlessS]

I see DGIndex too old (2010), i want found new index continue updated like ffms2 or l-smash to replaced DGIndex

See here:- https://en.wiktionary.org/wiki/if_it_ain%27t_broke,_don%27t_fix_it,

[Groucho2004]

See here:- https://en.wiktionary.org/wiki/if_it_ain%27t_broke,_don%27t_fix_it,Mmm, so true.

I wonder what the kids these days qualify as "too old". Is there a formula? Something like (current time) - (last time I crapped my diapers)?

[tebasuna51]

I see megui offer some .ts file use DGIndex but video encoded audio don't sync with video, same error with L-Smash...

Please don't cross posts.
Like the questions are related with MeGUI please read that thread:
https://forum.doom9.org/showthread.php?p=1894677#post1894677

(I leave the post here because the links are broken in the other thread)

[LigH]

DGMPGDec is just as "too old" as MPEG-2 video :p

[manolito]

Compiled the last official stable release with FFMPEG 4.2.2 libs, figured a few people may be interested in having it so here it is:


Just tested this build using some HEVC sources, but it has a bad regression concerning HEVC seeking.

The build I use normally is from STvG from Nov 2019, and HEVC seeking works with this build. The meatwad build does not include the fix for seeking, it is unusable for HEVC sources.

[lansing]

Non utf-8 file path support with DGIndex after all these years seems to be a good reason to hop onto another train.

[LigH]

If just any other "train" supported playlists like d2v indexing across a set of VOB segments ... but neither FFMS2 nor L-SMASH Works do. So you need to extract a PGC as continuous file (e.g. using PGCDemux or any DVD ripper with "PGC VOB" output or M2V video demux).

[kedautinh12]

Non utf-8 file path support with DGIndex after all these years seems to be a good reason to hop onto another train.

that why i like source filters continued update

[l33tmeatwad]

Non utf-8 file path support with DGIndex after all these years seems to be a good reason to hop onto another train.
Does D2V Witch support non-utf8 file paths?

[videoh]

Non utf-8 file path support with DGIndex after all these years seems to be a good reason to hop onto another train. There's no reason that can't be updated as per DGDecNV. I'll try to find time for it.

[Matias]

Is it possible to repair error like this?
https://i.imgur.com/F9Bn5JC.png

[Myrsloik]

Is it possible to repair error like this?
https://i.imgur.com/F9Bn5JC.png
Only by cutting away the bits with a different format.

I'll probably implement it in BestAudioSource some day.

[gpower2]

Hey people! Is there any news about an official release for FFMS2?
I see 202 commits after the latest release in GitHub.

[Nico8583]

Hi ! Same question than gpower2, is there a new version for FFMS2 ? Thank you !

[gpower2]

Hey people, since no one seems to have the time for providing a new build for our beloved FFMS2 lib, I decided to make the best out of the COVID quarantine and try to have a go for it.

It was not easy, especially for someone who doesn't compile C/C++ open source cross platform projects often, like me. :P
But at last I managed to have a fully working (and quite a speedy one) x64 build!

ffms2-0628fe6-win64-20200404.7z (https://bit.ly/2UIFKGU)

I only needed a x64 one, if I manage to find the time I'll provide with a x86 one, but this is one time expensive process, so don't get your hopes up.

Enjoy people! :)


Build details for the next one who tries to do that:

FFMpeg

branch master, commit: a6e56d12a413013d3a4b39f670e5495805965a67 (https://github.com/FFmpeg/FFmpeg/commit/a6e56d12a413013d3a4b39f670e5495805965a67)
April 3, 2020

Build tools:

MSYS2 x86_64 20190524
Latest MSYS2 packages (pacman -S make pkg-config diffutils nasm)
VS 2019 16.5.2 Community Edition


Build instructions:

Download latest MSYS2 from http://msys2.github.io/
Open Visual C++ command prompt with environment set for 64-bit MSVC compilation. In my case it is called "x64 Native Tools Command Prompt for VS 2019".
Now open MSYS console from within the MSVC command prompt:
C:\msys64\msys2_shell.cmd -use-full-path
NOTE: You must specify "-use-full-path" in order for the MSYS2 console to know the PATH from the VS command prompt
Use "pacman" in MSYS2 console to install the packages needed for building FFMpeg
pacman -S make pkg-config diffutils nasm
Configure FFmpeg - run following command in MSYS console:
./configure --arch=x86_64 --target-os=win64 --toolchain=msvc
Build the binaries - run following command in MSYS console:
make
Install the binaries - run following command in MSYS console:
make install
NOTE: By default they should end up in C:\msys64\usr\local



ZLib

branch master, commit: cacf7f1d4e3d44d871b605da3b647f07d718623f (https://github.com/madler/zlib/commit/cacf7f1d4e3d44d871b605da3b647f07d718623f)
Jan 15, 2017 (zlib 1.2.11)

Build tools:

Build from contrib\vstudio\vc14\zlibvc.sln in VS 2019 16.5.2 Community Edition in Release x64 configuration
Used the contrib\vstudio\vc14\x64\ZlibStatRelease\zlibstat.lib



FFMS2

branch master, commit: 0628fe69f014c398d1c5d15d99934a88a4a65c3b (https://github.com/FFMS/ffms2/commit/0628fe69f014c398d1c5d15d99934a88a4a65c3b)
Mar 30, 2020

Build tools:

Build from build-msvc\ffms2.sln in VS 2019 16.5.2 Community Edition in Release x64 configuration


MSVC Project changes:

WindowsTargetPlatformVersion: 10.0.16299.0 => 10.0
PlatformToolset: v141 => v142
Added "../../zlib" in IncludePath
Added "../../zlib/contrib/vstudio/vc14/x64/ZlibStatRelease" in LibraryPath
Added "bcrypt.lib" in Linker AdditionalDependencies
Changed "zlib.lib" to "zlibstat.lib" in Linker AdditionalDependencies
Added "../../zlib/contrib/vstudio/vc14/x64/ZlibStatRelease;../../ffmpeg64/lib" in Linker AdditionalLibraryDirectories


Links that helped me fill the blanks:
http://ffmpeg.org/platform.html#Windows
https://ffmpeg.zeranoe.com/forum/viewtopic.php?f=5&t=7497

[tolias63]

Oh, nice work! Thanks, Gpower2!

[filler56789]

FFMS2 latest x64 build

:goodpost: and :thanks:

[Stereodude]

Is ffms2 supposed to be frame accurate when seeking?

[StvG]

Another ffms2 update (https://cloud.owncube.com/s/nSEQsddidmFYyCX):
- ffms2@bda9eeb;
- ffmpeg n4.3@72be5d4661;
- zlib 1.2.11;
- dav1d 0.6.0.

[Myrsloik]

Is ffms2 supposed to be frame accurate when seeking?

Yes, except when it's not. It mostly depends on the container and a bit on the codec.

[StainlessS]

Yes, except when it's not.

Or to put it another way,

No, except when it is. :)

[kedautinh12]

ffms2-0628fe6-win64-20200404.7z (https://bit.ly/2UIFKGU)


same error with StvG ver

video test: https://drive.google.com/file/d/1GzeVf1ecvarEz_d5TiK7Y4TNlpvkU-fw/view?usp=sharing

log:

-[Information] Versions
--[Information] MeGUI: 2913 x64
--[Information] MeGUI Debug Data: available
--[Information] Update Check: development update server
-[Information] Operating System: Windows 10 Pro 1909 x64 (10.0.18363.720)
-[Information] .NET Framework: 4.0 (4.0.0.0)
-[Information] .NET Framework: 4.8 (4.8.03752)
-[Information] Microsoft Visual C++ 2005 x64: 8.0.61000
-[Information] Microsoft Visual C++ 2005 x86: 8.0.61001
-[Information] Microsoft Visual C++ 2010 x64: 10.0.40219
-[Information] Microsoft Visual C++ 2010 x86: 10.0.40219
-[Information] Microsoft Visual C++ 2012 x64: 11.0.61030
-[Information] Microsoft Visual C++ 2012 x86: 11.0.61030
-[Information] Microsoft Visual C++ 2013 x64: 12.0.40664
-[Information] Microsoft Visual C++ 2013 x86: 12.0.40664
-[Information] Microsoft Visual C++ 2015-2019 x64: 14.24.28127
-[Information] Microsoft Visual C++ 2015-2019 x86: 14.24.28127
-[Information] Redistributables
-[Information] DPI: 100% (96/96)
-[Information] Resolution: 1366x768
-[Information] Primary Screen: True
-[Information] Monitor 1
--[Information] System Information
-[Information] Update detection
-[Information] Haali Media Splitter: 1.13.138.14 (14-04-2013)
-[Information] Haali DSS2: 2.0.0.13 (01-01-2019)
-[Information] ICSharpCode.SharpZipLib: 0.85.5.452 (07-08-2008)
-[Information] MediaInfo: 18.05.0.0 (08-05-2018)
-[Information] SevenZipSharp: 0.64.3890.29348 (02-01-2011)
-[Information] 7z: 9.20 (18-11-2010)
--[Information] Component Information
-[Information] Version: 1.0.2847.0
-[Information] Date: 06-05-2018
-[Information] Interface: 3
-[Information] AviSynth Wrapper
-[Information] AviSynth Status: ignored as portable build is forced
-[Information] AviSynth
--[Information] [4/11/2020 8:02:09 AM] Cannot use update server http://megui.org/auto/. Reason: Update server is not available
--[Information] [4/11/2020 8:02:09 AM] Cannot use update server http://megui.tmebi.de/test/. Reason: Update server is not available
--[Information] [4/11/2020 8:02:09 AM] Using cached update config and server: http://megui.tmebi.de/test/
--[Information] [4/11/2020 8:02:09 AM] No package requires an update
-[Information] File Version: 3.5
-[Information] File Date: 02-04-2020
-[Information] File Name: AviSynth+ 3.5 (r3106, 3.5, x86_64)
-[Information] File Path: e:\megui-2913-64\avisynth.dll
-[Information] AviSynth Version: AviSynth+ 3.5 (r3106, 3.5, x86_64)
-[Information] AviSynth+: true
-[Information] AviSynth MT: true
-[Information] AviSynth Status: active
-[Information] AviSynth portable
--[Information] AviSynth Information
-[Information] FileIndexer
--[Information] [4/11/2020 8:02:25 AM] MediaInfo
---[Information] File: C:\Users\84945\Downloads\Video for test\Hikoutei - King Gnu.ts
-[Information] Format: MPEG-TS
-[Information] FileSize: 147849216
-[Information] PlayTime: 00:04:22.912
---[Information] General
-[Information] ID: 4352
-[Information] StreamOrder: 0-0
-[Information] CodecID: 27
-[Information] Format: AVC
-[Information] FormatInfo: Advanced Video Codec
-[Information] Width: 1440
-[Information] Height: 1080
-[Information] FrameCount: 7852
-[Information] FrameRate: 29.970
-[Information] Duration: 00:04:21.995
-[Information] ScanType: Interlaced
-[Information] Bits Depth: 8
-[Information] AspectRatio: 1.778
-[Information] AspectRatioString: 16:9
-[Information] PixelAspectRatio: 1.333
-[Information] Delay: 1079.911
---[Information] Video
-[Information] ID: 4353
-[Information] StreamOrder: 0-1
-[Information] CodecID: 15
-[Information] Format: AAC
-[Information] FormatVersion: Version 2
-[Information] FormatInfo: Advanced Audio Codec
-[Information] FormatProfile: LC
-[Information] Muxing Mode: ADTS
-[Information] SamplingRate: 48000
-[Information] SamplingRateString: 48.0 kHz
-[Information] Channels: 2
-[Information] ChannelsString: 2 channels
-[Information] ChannelPositionsString2: 2/0/0
-[Information] BitRateMode: VBR
-[Information] Delay: 1079.911
-[Information] [4/11/2020 8:02:26 AM] The language information is not available for this track. The default MeGUI language has been selected.
---[Information] Audio
-[Information] Log for job1 (idx, Hikoutei - King Gnu.ts -> Hikoutei - King Gnu.ts.ffindex)
--[Information] [4/11/2020 8:02:28 AM] Started handling job
--[Information] [4/11/2020 8:02:28 AM] Preprocessing
--[Information] [4/11/2020 8:02:28 AM] Job command line: "E:\MeGUI-2913-64\tools\ffms\ffmsindex.exe" -t -1 -f "C:\Users\84945\Downloads\Video for test\Hikoutei - King Gnu.ts" "C:\Users\84945\Downloads\Video for test\Hikoutei - King Gnu.ts.ffindex"
--[Information] [4/11/2020 8:02:28 AM] Process started
--[Information] [4/11/2020 8:02:28 AM] Standard output stream
--[Information] [4/11/2020 8:02:28 AM] Standard error stream
---[Information] [4/11/2020 8:02:31 AM] Writing index... done.
--[Information] [4/11/2020 8:02:35 AM] MediaInfo
---[Information] File: C:\Users\84945\Downloads\Video for test\Hikoutei - King Gnu.ts.ffindex
-[Information] FileSize: 85117
---[Information] General
--[Information] [4/11/2020 8:02:35 AM] Postprocessing
---[Information] [4/11/2020 8:02:40 AM] Deleting intermediate files
--[Information] [4/11/2020 8:02:40 AM] Job completed
-[Information] AVS Script Creator
--[Warning] [4/11/2020 8:02:40 AM] Could not read frame: FFVideoSource: Out of bounds frame requested
--[Warning] [4/11/2020 8:02:41 AM] Could not read frame: FFVideoSource: Out of bounds frame requested

[kedautinh12]

FFMS2 2.23.1 (w/ FFmpeg 4.2.2)
Static Libs Build (x86 & x64) (http://www.mediafire.com/file/yyabrt1jkmmlvsn) | Sources (https://www.mediafire.com/folder/3tv37w2c9ibps/Source)


use normally with this ver

[gpower2]

same error with StvG ver

video test: https://drive.google.com/file/d/1GzeVf1ecvarEz_d5TiK7Y4TNlpvkU-fw/view?usp=sharing

log:

I just provided a build with the latest versions of all dependencies at the time. I haven't tampered with the code in the slightest.

I guess it's a regression bug or something.

However, for .ts files, I recommend using LSMASH source filter, since it seems to be frame accurate instead of FFMS2, at least in my experience. ;)

[Nik92]

Hi,

I have a captured video in HuffYUV and when I open it using FFmpegSource2 in Avisynth+ some frames are dropped which leads to audio to be out of sync.

No such issue when using AVISource, 319405 frames total, 25 fps:
https://forum.doom9.org/attachment.php?attachmentid=17330&stc=1&d=1589011239

But with FFmpegSource2 319008 frames total, 397 frames are dropped, 24.969 fps:

https://forum.doom9.org/attachment.php?attachmentid=17331&stc=1&d=1589011332

Also no dropped frames if I open with FFmpegSource2 the same video but encoded in FFV1.

Is it just me or FFmpegSource2 is not working correctly with HuffYUV?

Thanks

[Myrsloik]

Hi,

I have a captured video in HuffYUV and when I open it using FFmpegSource2 in Avisynth+ some frames are dropped which leads to audio to be out of sync.

No such issue when using AVISource, 319405 frames total, 25 fps:
https://forum.doom9.org/attachment.php?attachmentid=17330&stc=1&d=1589011239

But with FFmpegSource2 319008 frames total, 397 frames are dropped, 24.969 fps:

https://forum.doom9.org/attachment.php?attachmentid=17331&stc=1&d=1589011332

Also no dropped frames if I open with FFmpegSource2 the same video but encoded in FFV1.

Is it just me or FFmpegSource2 is not working correctly with HuffYUV?

Thanks

Huffyuv in avi should always work perfectly. Which ffms2 version did you try?

Does the captured file by any chance contain exactly 397 dropped frames?

[zorr]

My experience with ffmpegsource and dropped frames in Huffyuv clips is that they are skipped (tests done with Vapoursynth's core.ffms2.Source).

VirtualDub however shows them as duplicate frames so what I did was preprocess the video with VirtualDub so that the dropped frames are included as duplicates. It would be nice if there was a more elegant way.

[Nik92]

Huffyuv in avi should always work perfectly. Which ffms2 version did you try?
I tried with 2.23.1 and the one provided by gpower2 a few posts earlier.
Does the captured file by any chance contain exactly 397 dropped frames?

I'm not sure how to get the amount of dropped frames but when capturing I think I remember there was this number (or very close) of inserted frames reported by VirtualDub.


My experience with ffmpegsource and dropped frames in Huffyuv clips is that they are skipped (tests done with Vapoursynth's core.ffms2.Source).

VirtualDub however shows them as duplicate frames so what I did was preprocess the video with VirtualDub so that the dropped frames are included as duplicates. It would be nice if there was a more elegant way.
Could you please share what preprocessing was done with VirtualDub?

[zorr]

Could you please share what preprocessing was done with VirtualDub?

Load the video into VirtualDub and set the compression to Huffyuv. Select the "Fast recompress" option at the Video menu. Then save as AVI.

The resulting file no longer has dropped frames (at least VirtualDub cannot find them anymore) and they are replaced as duplicate frames.

[videoh]

AVI/VFW is so 90s.

[stranno]

I have been using FFMS2 + ProRes for years and everything works fine. But now I have switched to h264/h265 and FFMS2 struggles with the audio. Seeking, using any player (MPC-HC), and trimming, using NVEncc, takes A LOT of time.

Using FFVideoSource alone I have no problems at all, it seeks perfectly fine and it has a top-notch performance. Extracing the audio track and loading it using FFAudioSource also works. But loading the audio track from the MKV makes the decoder to struggle like hell.

I'm using the latest StvG build (from this page of the thread) but I also have tried more builds. Same problems.

Video seems to be fine, its MKV + h264 + AAC LC ADTS.

Any idea?

[Myrsloik]

I have been using FFMS2 + ProRes for years and everything works fine. But now I have switched to h264/h265 and FFMS2 struggles with the audio. Seeking, using any player (MPC-HC), and trimming, using NVEncc, takes A LOT of time.

Using FFVideoSource alone I have no problems at all, it seeks perfectly fine and it has a top-notch performance. Extracing the audio track and loading it using FFAudioSource also works. But loading the audio track from the MKV makes the decoder to struggle like hell.

I'm using the latest StvG build (from this page of the thread) but I also have tried more builds. Same problems.

Video seems to be fine, its MKV + h264 + AAC LC ADTS.

Any idea?

The audio support is bad. If you can tolerate slightly worse performance give bestaudiosource a try. Otherwise keep demuxing...

[stranno]

The audio support is bad. If you can tolerate slightly worse performance give bestaudiosource a try. Otherwise keep demuxing...
Thank you Myrsloik. It does the job perfectly fine and performance hit is tolerable. Is there room for performance improvements? Are you still working on it? Would indexing allow better performance?

[Myrsloik]

Thank you Myrsloik. It does the job perfectly fine and performance hit is tolerable. Is there room for performance improvements? Are you still working on it? Would indexing allow better performance?

1. Nope, the performance basically is what it is. Don't expect it to change at all.
2. Yes.
3. The whole idea is to not index and simply sacrifice a bit of cpu time for linear decoding. If you start indexing you end up with FFMS2.

[stranno]

1. Nope, the performance basically is what it is. Don't expect it to change at all.
2. Yes.
3. The whole idea is to not index and simply sacrifice a bit of cpu time for linear decoding. If you start indexing you end up with FFMS2.
Again, many thanks. I will stick with bestaudiosource.

[wonkey_monkey]

As I'm having problems getting DGDecNV to work on my new computer, I'm trying ffmpegsource on a 30Gb blu-ray rip (demuxed .264 file). It works, but it takes forever to open each time (15 minutes or so. It's not re-indexing as far as I can tell; I created the .ffindex file on the command line and its modified date hasn't changed).

Is this just how slow it is with such large files?

[stax76]

Normally with MKV both ffms2 and l-smash are super fast indexing, staxrip uses LWLibavVideoSource for raw files by default, probably better.

[videoh]

Is this just how slow it is with such large files? Sounds like something is sideways. Shouldn't be like that. Happy to help with DGDecNV if you want to open a new thread or visit my forum. Laptops can be problematic. :sly: But MX150 looks like a fine GPU. Let's see if we can sort things out for you.

[wonkey_monkey]

Sounds like something is sideways. Shouldn't be like that. Happy to help with DGDecNV if you want to open a new thread or visit my forum. Laptops can be problematic. :sly: But MX150 looks like a fine GPU. Let's see if we can sort things out for you.

Thanks - already done, as I guess you know, unless you are somehow GPU-psychic.

As for ffmpegsource, I just tried with a 780Mb .m2ts file. It indexed in 30 seconds or so, and subsequent opens were instant. I'll now try with a 39Gb .m2ts...

[videoh]

unless you are somehow GPU-psychic. All seeing, all knowing.

[wonkey_monkey]

The 39Gb M2TS file took 17 minutes to index the first time, then opened instantly the next time.

I went back to the 30Gb .264 file, renamed the existing index file (created on the command line: 609,535 bytes), and opened the script in VirtualDub. It took nearly 30 minutes, created an index file which is 632,958 bytes, but still didn't open instantly the next time (I let it got for 10 minutes before giving up).

I've now remuxed the .264 into a .ts, and it's working as expected, so I guess it was just something about that .264 file.

[videoh]

I guess it was just something about that .264 file. Sounds very doubtful, especially if it opened fine the first time. Sounds like an index management issue for elementary stream files.

[wonkey_monkey]

I've run into a problem with FFmpegSource, and I'm not sure if it isn't just something which is already understood to happen and just doesn't affect most users.

https://filebin.net/ycobtv5flicijv2e/trim.ts?t=9ldisa80

I can open this file with VirtualDub via Avisynth and ffmpegsource2 and I can step forward through it frame-by-frame without problems. The trouble starts when I try to step through it backwards - once they fall out of whatever caches they might be in (e.g. by advancing past frame 50), frames 24 and 25 become duplicates of frame 26. This is a problem because the filters I want to call on this clip do a lot of random access and the end result suffers from these duplicates even when stepped through forwards.

seekmode = 0 fixes it, but is impractical since the source file has 180000 frames and it takes several minutes to seek into the middle of the file.

Is there any other way to avoid this, or is there another source filter (edit: an x64 one, since my project is ravenous for RAM) for h.264/.ts that won't exhibit this behaviour? (apart from DGIndexNV, which I know would work fine but my new laptop isn't compatible with it).

[poisondeathray]

@w_m , lsmash works ok , HolyWu branch

https://github.com/HolyWu/L-SMASH-Works/releases

[wonkey_monkey]

Thanks, I'll give it a try.

ffmpegsource also seems to have a habit of silently killing VirtualDub at random. Hopefully LSmash won't do that either.

[wonkey_monkey]

@w_m , lsmash works ok , HolyWu branch

https://github.com/HolyWu/L-SMASH-Works/releases

It (LWLibavVideoSource) doesn't cause frames 24 and 25 to become duplicates of 26... but it does cause frame 55 to become a duplicate of frame 56 :(

You can also exhibit this behaviour by adding the "reverse" filter and stepping through forwards.

[manolito]

For me seeking in transport stream has always been problematic, even when using an indexing source filter. I made it a habit to repack transport streams into an MKV container before I do anything else to them.

Tested your sample, and after using MKVToolNix to repack the file all my source filters (even DSS2Mod) behaved nicely.

[poisondeathray]

It (LWLibavVideoSource) doesn't cause frames 24 and 25 to become duplicates of 26... but it does cause frame 55 to become a duplicate of frame 56 :(

You can also exhibit this behaviour by adding the "reverse" filter and stepping through forwards.


threads=1 looks ok, but slower

Does that computer not have nvidia card ? Interesting that gpu decoding with decoder="h264_cuvid" works (or prefer_hw=1) , but intel QS does not on that clip (prefer_hw=2)




Tested your sample, and after using MKVToolNix to repack the file all my source filters (even DSS2Mod) behaved nicely.

This did not work for me using ffms2 or lsmash x64 (same problem); and dss2 x64 drops the last frame

[stax76]

In my experience it's better to use ffmpeg to remux ts to mkv, that is the default handling in staxrip, mkvmerge is fine for playback but not so for editing, causes sync issues.

[wonkey_monkey]

Well this is a minefield...

Results of remuxing to MKV (with ffmpeg):

LWLibavVideoSource: still skips frame 55
LSmashVideoSource: doesn't open this container
FFMpegSource2: seems to work okay so far

Results of remuxing to MP4 (with ffmpeg):

LWLibavVideoSource: still skips frame 55
LSmashVideoSource: First two frames get repeated, a couple of later frames get skipped. Definite no-go.
FFMpegSource2: Freezes on the first few frames, skips a couple of later frames (despite claiming to be frame accurate on Avisynth wiki)

--------------------------------------------------------------------------------------------------------

Is this all as expected?

[qyot27]

It may be the method you're using to rip the Blu-ray. If I have to, I make a full-disc decrypted backup with MakeMKV (arguably you could maybe do a more restricted rip using BlurayTestAndDecrypt and libaacs/KEYDB.cfg, but you'd lose the disc structure), and then use mkvmerge to remux the main title to MKV by giving it the index.bdmv to parse. No demuxing to elementary streams and then remuxing them into other containers, if that's where the .ts sample came from.

I say this because there was a point, not sure how long ago exactly or if it's been fixed since, that MakeMKV's Matroska output acted strangely when given to source filters (or maybe it was eac3to? Like I said, it was a while ago). The simplest way to sidestep the problem is not to let MakeMKV make an MKV of whatever you're ripping.

[Atak_Snajpera]

Well this is a minefield...

Results of remuxing to MKV (with ffmpeg):

LWLibavVideoSource: still skips frame 55
LSmashVideoSource: doesn't open this container
FFMpegSource2: seems to work okay so far

Results of remuxing to MP4 (with ffmpeg):

LWLibavVideoSource: still skips frame 55
LSmashVideoSource: First two frames get repeated, a couple of later frames get skipped. Definite no-go.
FFMpegSource2: Freezes on the first few frames, skips a couple of later frames (despite claiming to be frame accurate on Avisynth wiki)

--------------------------------------------------------------------------------------------------------

Is this all as expected?

I can confirm. Remuxing to mkv with mkvtoolnix solves nothing
https://i.postimg.cc/NMh37s2w/Untitled-1.png

[wonkey_monkey]

I'd forgotten about Seek Tester! Definitely going to put that to some good use.

Does it seek forward and store a hash per frame, or something, and then seek randomly and test the hashes to see which frames are returned?

[kedautinh12]

Any update FFmpegSource with FFmpeg 4.3.1??

[StvG]

ffms2 (https://cloud.owncube.com/s/tcwyzNJ6LgD2iN7):
- ffmpeg n4.4@1c7e55dd50;
- zlib 1.2.11;
- dav1d 0.7.1.

[kedautinh12]

ffms2 (https://cloud.owncube.com/s/tcwyzNJ6LgD2iN7):
- ffmpeg n4.4@1c7e55dd50;
- zlib 1.2.11;
- dav1d 0.7.1.

Thanks

[Myrsloik]

FFMS 2.40-RC1 (https://github.com/FFMS/ffms2/releases/tag/2.40-RC1)

Test it. Don't bitch about missing libraries (apart from zlib but I think I got that one included).

[kedautinh12]

FFMS 2.40-RC1 (https://github.com/FFMS/ffms2/releases/tag/2.40-RC1)

Test it. Don't bitch about missing libraries (apart from zlib but I think I got that one included).

Thanks

[ChaosKing]

My results:
https://i.imgur.com/S2Y6JY3.png

[Myrsloik]

My results:


What's different in the stvg builds? From what I can tell the results should be more similar.

[StvG]

This (https://pastebin.com/raw/0wS5syun) is the patch for my builds.

[StainlessS]

Impressive update, thanks.

[Myrsloik]

This (https://pastebin.com/raw/0wS5syun) is the patch for my builds.

Oh, mostly a rollback of the still partial VP9 fixes and such. Can't please all formats at once I guess.

[amayra]

there any reason for not using GitHub Actions or appveyor ?

[Myrsloik]

My results:


Where can I find all the test clips?

[ChaosKing]

You can find 70% of the clips here https://www.dropbox.com/sh/bxwibb20m8rnnro/AABmPSXEWGgE7nBK-PvwyU6Aa?dl=0
Others are bigger vob files etc that I can't upload.

(you can set dl=1 to download all files as zip)

[kedautinh12]

You can find 70% of the clips here https://www.dropbox.com/sh/bxwibb20m8rnnro/AABmPSXEWGgE7nBK-PvwyU6Aa?dl=0
Others are bigger vob files etc that I can't upload.

(you can set dl=1 to download all files as zip)

Can you up 30% to google drive??

[ChaosKing]

I uploaded some missing clips. Should be enough test files now.

[StainlessS]

Chaos, perhaps you got some of them from here in usage sticky[Consolidated list of test video clip resources ]:-
https://forum.doom9.org/showthread.php?t=135034

Some of those are truly massive[like maybe 500GB for some lossless IIRC].

[Myrsloik]

2.40 released (https://github.com/FFMS/ffms2/releases/tag/2.40)

Identical to RC1.

Have a look at BestAudioSource (https://forum.doom9.org/showthread.php?t=177337) for all your audio needs!

[kedautinh12]

2.40 released (https://github.com/FFMS/ffms2/releases/tag/2.40)

Identical to RC1.

Have a look at BestAudioSource (https://forum.doom9.org/showthread.php?t=177337) for all your audio needs!

Same error with STvG ver

log:
-[Information] Versions
--[Information] MeGUI: 2913 x64
--[Information] MeGUI Debug Data: available
--[Information] Update Check: development update server
-[Information] Operating System: Windows 10 Pro 1909 x64 (10.0.18363.720)
-[Information] .NET Framework: 4.0 (4.0.0.0)
-[Information] .NET Framework: 4.8 (4.8.03752)
-[Information] Microsoft Visual C++ 2005 x64: 8.0.61000
-[Information] Microsoft Visual C++ 2005 x86: 8.0.61001
-[Information] Microsoft Visual C++ 2010 x64: 10.0.40219
-[Information] Microsoft Visual C++ 2010 x86: 10.0.40219
-[Information] Microsoft Visual C++ 2012 x64: 11.0.61030
-[Information] Microsoft Visual C++ 2012 x86: 11.0.61030
-[Information] Microsoft Visual C++ 2013 x64: 12.0.40664
-[Information] Microsoft Visual C++ 2013 x86: 12.0.40664
-[Information] Microsoft Visual C++ 2015-2019 x64: 14.24.28127
-[Information] Microsoft Visual C++ 2015-2019 x86: 14.24.28127
-[Information] Redistributables
-[Information] DPI: 100% (96/96)
-[Information] Resolution: 1366x768
-[Information] Primary Screen: True
-[Information] Monitor 1
--[Information] System Information
-[Information] Update detection
-[Information] Haali Media Splitter: 1.13.138.14 (14-04-2013)
-[Information] Haali DSS2: 2.0.0.13 (01-01-2019)
-[Information] ICSharpCode.SharpZipLib: 0.85.5.452 (07-08-2008)
-[Information] MediaInfo: 18.05.0.0 (08-05-2018)
-[Information] SevenZipSharp: 0.64.3890.29348 (02-01-2011)
-[Information] 7z: 9.20 (18-11-2010)
--[Information] Component Information
-[Information] Version: 1.0.2847.0
-[Information] Date: 06-05-2018
-[Information] Interface: 3
-[Information] AviSynth Wrapper
-[Information] AviSynth Status: ignored as portable build is forced
-[Information] AviSynth
--[Information] [4/11/2020 8:02:09 AM] Cannot use update server http://megui.org/auto/. Reason: Update server is not available
--[Information] [4/11/2020 8:02:09 AM] Cannot use update server http://megui.tmebi.de/test/. Reason: Update server is not available
--[Information] [4/11/2020 8:02:09 AM] Using cached update config and server: http://megui.tmebi.de/test/
--[Information] [4/11/2020 8:02:09 AM] No package requires an update
-[Information] File Version: 3.5
-[Information] File Date: 02-04-2020
-[Information] File Name: AviSynth+ 3.5 (r3106, 3.5, x86_64)
-[Information] File Path: e:\megui-2913-64\avisynth.dll
-[Information] AviSynth Version: AviSynth+ 3.5 (r3106, 3.5, x86_64)
-[Information] AviSynth+: true
-[Information] AviSynth MT: true
-[Information] AviSynth Status: active
-[Information] AviSynth portable
--[Information] AviSynth Information
-[Information] FileIndexer
--[Information] [4/11/2020 8:02:25 AM] MediaInfo
---[Information] File: C:\Users\84945\Downloads\Video for test\Hikoutei - King Gnu.ts
-[Information] Format: MPEG-TS
-[Information] FileSize: 147849216
-[Information] PlayTime: 00:04:22.912
---[Information] General
-[Information] ID: 4352
-[Information] StreamOrder: 0-0
-[Information] CodecID: 27
-[Information] Format: AVC
-[Information] FormatInfo: Advanced Video Codec
-[Information] Width: 1440
-[Information] Height: 1080
-[Information] FrameCount: 7852
-[Information] FrameRate: 29.970
-[Information] Duration: 00:04:21.995
-[Information] ScanType: Interlaced
-[Information] Bits Depth: 8
-[Information] AspectRatio: 1.778
-[Information] AspectRatioString: 16:9
-[Information] PixelAspectRatio: 1.333
-[Information] Delay: 1079.911
---[Information] Video
-[Information] ID: 4353
-[Information] StreamOrder: 0-1
-[Information] CodecID: 15
-[Information] Format: AAC
-[Information] FormatVersion: Version 2
-[Information] FormatInfo: Advanced Audio Codec
-[Information] FormatProfile: LC
-[Information] Muxing Mode: ADTS
-[Information] SamplingRate: 48000
-[Information] SamplingRateString: 48.0 kHz
-[Information] Channels: 2
-[Information] ChannelsString: 2 channels
-[Information] ChannelPositionsString2: 2/0/0
-[Information] BitRateMode: VBR
-[Information] Delay: 1079.911
-[Information] [4/11/2020 8:02:26 AM] The language information is not available for this track. The default MeGUI language has been selected.
---[Information] Audio
-[Information] Log for job1 (idx, Hikoutei - King Gnu.ts -> Hikoutei - King Gnu.ts.ffindex)
--[Information] [4/11/2020 8:02:28 AM] Started handling job
--[Information] [4/11/2020 8:02:28 AM] Preprocessing
--[Information] [4/11/2020 8:02:28 AM] Job command line: "E:\MeGUI-2913-64\tools\ffms\ffmsindex.exe" -t -1 -f "C:\Users\84945\Downloads\Video for test\Hikoutei - King Gnu.ts" "C:\Users\84945\Downloads\Video for test\Hikoutei - King Gnu.ts.ffindex"
--[Information] [4/11/2020 8:02:28 AM] Process started
--[Information] [4/11/2020 8:02:28 AM] Standard output stream
--[Information] [4/11/2020 8:02:28 AM] Standard error stream
---[Information] [4/11/2020 8:02:31 AM] Writing index... done.
--[Information] [4/11/2020 8:02:35 AM] MediaInfo
---[Information] File: C:\Users\84945\Downloads\Video for test\Hikoutei - King Gnu.ts.ffindex
-[Information] FileSize: 85117
---[Information] General
--[Information] [4/11/2020 8:02:35 AM] Postprocessing
---[Information] [4/11/2020 8:02:40 AM] Deleting intermediate files
--[Information] [4/11/2020 8:02:40 AM] Job completed
-[Information] AVS Script Creator
--[Warning] [4/11/2020 8:02:40 AM] Could not read frame: FFVideoSource: Out of bounds frame requested
--[Warning] [4/11/2020 8:02:41 AM] Could not read frame: FFVideoSource: Out of bounds frame requested

[kedautinh12]

video test: https://drive.google.com/file/d/1BlzSQ-xD1ct9sEriL1n6YtfyPf1bJpT1/view?usp=sharing

[tebasuna51]

video test: https://drive.google.com/file/d/1BlzSQ-xD1ct9sEriL1n6YtfyPf1bJpT1/view?usp=sharing
Denied access

[Myrsloik]

video test: https://drive.google.com/file/d/1BlzSQ-xD1ct9sEriL1n6YtfyPf1bJpT1/view?usp=sharing

.ts? .TS?

That's simply unsupported and has never worked well. Remux into a real container and try again.

[kedautinh12]

.ts? .TS?

That's simply unsupported and has never worked well. Remux into a real container and try again.

i seen work normal with 2.23.1

[LigH]

Anyway, let mkvtoolnix remultiplex it to MKV and you are on a pretty solid base.

[kedautinh12]

Denied access

I was seted permission

[StvG]

ffms2 (https://cloud.owncube.com/s/C3ELrqtA5braszk):
- ffmpeg n4.4@9b72cea446;
- zlib 1.2.11;
- dav1d 0.7.1;
- set frame properties - _DurationNum (int), _DurationDen (int), _AbsoluteTime (float), _SARNum (int), _SARDen (int), _Matrix (int), _Primaries (int), _Transfer (int), _ChromaLocation (int), _ColorRange (int), _PictType (string), _FieldBased (int), MasteringDisplayPrimariesX (float array), MasteringDisplayPrimariesY (float array), MasteringDisplayWhitePointX (float), MasteringDisplayWhitePointY (float), MasteringDisplayMinLuminance (float), MasteringDisplayMaxLuminance (float), ContentLightLevelMax (float), ContentLightLevelAverage (float).

[real.finder]

ffms2 (https://cloud.owncube.com/s/C3ELrqtA5braszk):
- ffmpeg n4.4@9b72cea446;
- zlib 1.2.11;
- dav1d 0.7.1;
- set frame properties

thanks! I hope the ffms2 guys add the patch to https://github.com/FFMS/ffms2

edit: seems audio don't has new avs+ properties, right? but seems there are "BASCHANNEL_LAYOUT and BASVALID_BITS" in https://forum.doom9.org/showthread.php?t=177337

aside from that and slightly off-topic asd also added frame properties https://github.com/Asd-g/MPEG2DecPlus/releases so the only one left is LSMASHSource (lets hope HolyWu do it soon)

[kedautinh12]

ffms2 (https://cloud.owncube.com/s/C3ELrqtA5braszk):
- ffmpeg n4.4@9b72cea446;
- zlib 1.2.11;
- dav1d 0.7.1;
- set frame properties - _DurationNum (int), _DurationDen (int), _AbsoluteTime (float), _SARNum (int), _SARDen (int), _Matrix (int), _Primaries (int), _Transfer (int), _ChromaLocation (int), _ColorRange (int), _PictType (string), _FieldBased (int), MasteringDisplayPrimariesX (float array), MasteringDisplayPrimariesY (float array), MasteringDisplayWhitePointX (float), MasteringDisplayWhitePointY (float), MasteringDisplayMinLuminance (float), MasteringDisplayMaxLuminance (float), ContentLightLevelMax (float), ContentLightLevelAverage (float).

Thanks

[kedautinh12]

ffms2 (https://cloud.owncube.com/s/C3ELrqtA5braszk):
- ffmpeg n4.4@9b72cea446;
- zlib 1.2.11;
- dav1d 0.7.1;
- set frame properties - _DurationNum (int), _DurationDen (int), _AbsoluteTime (float), _SARNum (int), _SARDen (int), _Matrix (int), _Primaries (int), _Transfer (int), _ChromaLocation (int), _ColorRange (int), _PictType (string), _FieldBased (int), MasteringDisplayPrimariesX (float array), MasteringDisplayPrimariesY (float array), MasteringDisplayWhitePointX (float), MasteringDisplayWhitePointY (float), MasteringDisplayMinLuminance (float), MasteringDisplayMaxLuminance (float), ContentLightLevelMax (float), ContentLightLevelAverage (float).

I replaced old ffms2_64 in aegisub with your ver but aegisub64 error with notification: "The procedure entry point FFMS_DoIndexing could not be located in the dynamic link library C:\Program Files\Aegisub\aegisub64.exe

[LigH]

That sounds funny to me, as if something tries to load aegisub64.exe as a DLL (not the ffms2.dll). But maybe there is just a separator missing, and the message ends at "library".

[kedautinh12]

That sounds funny to me, as if something tries to load aegisub64.exe as a DLL (not the ffms2.dll). But maybe there is just a separator missing, and the message ends at "library".

I comeback and use normally with old ver ffms2 2.23.1. i think some new commit was removed or change structure function FFMS_DoIndexing

[zambelli]

What are the factors that have most impact on ffmsindex performance? File size/bitrate? Specific containers? Specific codecs? I notice that some videos take a lot longer to index than others - sometimes it takes 10-15 minutes to index a video, and I'm curious where the bottleneck is.

[LigH]

One factor I remember right away: If you try to index uncompressed video or audio, the index file can get extremely huge and needs a lot of time to be written.

The container can be a factor too. Some keep video and audio in easily accessible units, others may switch between them in the middle of a frame's content.

[FranceBB]

Yep and some codecs are faster / better indexable than others.
For instance, it takes way less to index an H.264 than it generally takes to index an Apple ProRes of the same size, so even codecs might come into play here.
Still, for me, the one that slows me down, the real bottleneck, is the LAN.
You know, I use Avisynth at work all the time and it's not exactly easy to justify the "waiting" while you index an 800 GB AppleProRes file over the network with a connection of 1 Gbit/s...
I generally act as a "stalker", though, and I watch the RAM being allocated while it's indexing in AVSPmod. This way, I get a "feeling" of what it's doing and how long it's gonna take.
Oh and if it has 16 PCM audio tracks, the painful waiting even worse...
Still, all in all, I'm kinda happy to wait 'cause, despite that, ever since 2006, ffms2 and LSMASH made make me index and then encode pretty much everything...

[zambelli]

Because indexing performance is so unpredictable sometimes I prefer to run the ffmsindex.exe process manually before I even try to load the script. It doesn't make it run any faster, of course, but at least that way I can track its progress and estimate time needed.

Some of the worst performance I've observed so far seems to be indexing AVI files with FFV1 video. A 100GB file (1hr 720p60 YUY2) can take nearly 30 mins to index on an 8th gen i5, which is barely 2x speed. It probably doesn't help that the indexing process is not fully multi-threaded.

[wonkey_monkey]

https://forum.doom9.org/showthread.php?t=176878

Seektester is a handy utility for determining whether ffmpegsource is seeking correctly for a given container/codec.

[FranceBB]

Thanks for the tool. By the way, it would be nice to have AVSPmod display it somehow as well.
I would be fine even with a very simple command line progress bar that occasionally pops-up...

[manolito]

I solved almost all of my indexing annoyances by using DSS2Mod by forclip (using 32-bit only). Thanks wonkey_monkey for recommending the Seek Tester utility. I just tested DSS2Mod using different AVC clips. Only SD resolution, only progressive. Container formats were MP4, MKV and FLV. For DSS2Mod I used "preroll=15". In all tests I did not get any seek errors, so at least for such sources this source filter works excellently...

[Matias]

I replaced old ffms2_64 in aegisub with your ver but aegisub64 error with notification: "The procedure entry point FFMS_DoIndexing could not be located in the dynamic link library C:\Program Files\Aegisub\aegisub64.exe

Use Kainote Beta, this has a dll from StvG
https://github.com/bjakja/Kainote

[StvG]

ffms2 (https://cloud.owncube.com/s/g35T64mo6SNQBpF):
- ffmpeg n4.4@9208b72a38;
- zlib 1.2.11;
- dav1d 0.7.1;
- changed the default threads number:
* VP9 - min(CPU logical processors, 8);
* AV1 - 1 when CPU logical processors = 1, otherwise 2;
* rest - CPU logical processors;
- MPEG2 streams in mkv container should be ok now.

[manolito]

Thanks for this new ffms2 version... :thanks:

I can confirm that the seek errors with VP9 sources are fixed.

[kedautinh12]

Use Kainote Beta, this has a dll from StvG
https://github.com/bjakja/Kainote

thanks

[kedautinh12]

ffms2 (https://cloud.owncube.com/s/g35T64mo6SNQBpF):
- ffmpeg n4.4@9208b72a38;
- zlib 1.2.11;
- dav1d 0.7.1;
- changed the default threads number:
* VP9 - min(CPU logical processors, 8);
* AV1 - 1 when CPU logical processors = 1, otherwise 2;
* rest - CPU logical processors;
- MPEG2 streams in mkv container should be ok now.

thanks

[44vince44]

thanks StvG !

[StainlessS]

Yes indeed, merci StvG.

[wonkey_monkey]

Does anyone know if there any known problems with crackling audio with ffmpegsource? I made a screen recording which plays fine in VirtualDub and MPC-HC, but loading it via AviSynth with atrack=1 results in crackly audio. Audio codec is AAC.

[real.finder]

Does anyone know if there any known problems with crackling audio with ffmpegsource? I made a screen recording which plays fine in VirtualDub and MPC-HC, but loading it via AviSynth with atrack=1 results in crackly audio. Audio codec is AAC.

is it ok with https://forum.doom9.org/showthread.php?t=177337 or LSMASHSource?

[Myrsloik]

Does anyone know if there any known problems with crackling audio with ffmpegsource? I made a screen recording which plays fine in VirtualDub and MPC-HC, but loading it via AviSynth with atrack=1 results in crackly audio. Audio codec is AAC.

Lots of audio issues are known.

[poisondeathray]

Is it possible for ffms2 to support float read/import?

ffmpeg has had float support for a while; for example you can read/write EXR as "gbrpf32le" (or with alpha "gbrapf32le")

But avs+ supports "RGBPS" (or with alpha "RGBAPS ")

Or is there something preventing ffms2 from navigating this pixel format ?

[kedautinh12]

New issue here:
https://forum.doom9.org/showthread.php?p=1943303

[FranceBB]

One of my colleagues reported that when Indexing a WAV which is larger than 2 GB, the audio is silent from a certain point onward even if he's using the x64 build for Avisynth.
I wonder if rf64 (which would be the extension needed to come around the original wav size limit) has been implemented in FFAudioSource().
Anyway, ffmpeg seems to support wav's bigger than 2 GB, even when the rf64 extension is not used in the source file, in fact in FFMpeg decoding works fine.
Here is a way to quickly create a test wav file to reproduce the problem:

ffmpeg -f lavfi -i "sine=frequency=1000:sample_rate=48000:duration=3600" -f lavfi -i "sine=frequency=2000:sample_rate=48000:duration=3600" -f lavfi -i "sine=frequency=3000:sample_rate=48000:duration=3600" -f lavfi -i "sine=frequency=4000:sample_rate=48000:duration=3600" -f lavfi -i "sine=frequency=5000:sample_rate=48000:duration=3600" -f lavfi -i "sine=frequency=6000:sample_rate=48000:duration=3600" -f lavfi -i "sine=frequency=7000:sample_rate=48000:duration=3600" -f lavfi -i "sine=frequency=8000:sample_rate=48000:duration=3600" -filter_complex amerge=inputs=8 c:\temp\out.wav

Indexing it with FFAudioSource() causes the problem.

The problem doesn't occur with WAVSource().

The issue has been reported in the bug tracker here: https://github.com/FFMS/ffms2/issues/389

[tebasuna51]

Does not make sense index a pcm samples wav, to locate a sample in a file you only need know the number of bytes per sample (in the header) and multiply.
The size of a index to all samples can be bigger than the WAV file.
Of course WavSource don't have this problem because don't make index.

BTW you can use RaWavSource from NicAudio to support WAV files bigger than 4 GB, and also RF64 or W64

[FranceBB]

Of course I can use NicAudio(), but the thing is that one of my colleagues used FFAudioSource() by mistake and found the issue so he reported it to me and I was like: first of all, demux with FFMpeg and use WAVSource(), second of all, thank you for letting me know, I might as well just report it to the FFAudioSource () developers to get it fixed, so here I am.

[Myrsloik]

Of course I can use NicAudio(), but the thing is that one of my colleagues used FFAudioSource() by mistake and found the issue so he reported it to me and I was like: first of all, demux with FFMpeg and use WAVSource(), second of all, thank you for letting me know, I might as well just report it to the FFAudioSource () developers to get it fixed, so here I am.

I made BestAudioSource so I'd never have to look into audio bug reports for FFMS2 ever again. True story.

[kedautinh12]

DNX120 fixed in L-SMASH Works, need fix in ffms2. Thanks
https://forum.doom9.org/showthread.php?p=1949542#post1949542

[StvG]

ffms2_1c6169a (https://ppp.woelkli.com/s/bx8zFHStJT9aCqs) (pass: tTnkia1ToVkw):
- ffms2@4567314;
- ffmpeg 4.4@1bc1757 (https://github.com/HomeOfAviSynthPlusEvolution/FFmpeg/tree/custom-patches-for-lsmashsource);
- zlib 1.2.11;
- dav1d 0.9.1;
- added FFAudioSource/FFMS2/FFmpegSource2 parameter "drc_scale" (float type, AC3 decoding).

[FranceBB]

Uh, new build, sweet, thanks. :)

[filler56789]

ffms2_1c6169a (https://ppp.woelkli.com/s/bx8zFHStJT9aCqs) (pass: tTnkia1ToVkw):
- ffms2@4567314;
- ffmpeg 4.4@1bc1757 (https://github.com/HomeOfAviSynthPlusEvolution/FFmpeg/tree/custom-patches-for-lsmashsource);
- zlib 1.2.11;
- dav1d 0.9.1;
- added FFAudioSource/FFMS2/FFmpegSource2 parameter "drc_scale" (float type, AC3 decoding).

:goodpost: and :thanks:

[Myrsloik]

A somewhat untested build with a pile of changes. This should slay most of your poor quality forks.

- 2.3000
- Added support for VapourSynth API4 (Myrsloik)
- Added basic Avisynth+ frame property support (Myrsloik)
- Added Rotation and Flip properties for VapourSynth (Myrsloik)
- Added long path support for ffmsindex in windows (Myrsloik)
- The audio gap fill logic is now optional and usually disabled by default (Myrsloik)
- Allow the drc_scale option to be set when decoding audio (Myrsloik)
- Allow the enable_drefs and use_absolute_path demuxer options to be used when indexing (Myrsloik)

FFMS3000 test1 (https://www.dropbox.com/s/1u8r4ia5phatjgx/ffms3000-test1.7z?dl=1)

[videoh]

@Myrsloik

If I want to support your API4 with DGDecodeNV, will I need to maintain two versions, one for API3 and one for API4? Thank you.

[Myrsloik]

@Myrsloik

If I want to support your API4 with DGDecodeNV, will I need to maintain two versions, one for API3 and one for API4? Thank you.

It's fairly easy to support both. See the FFMS2 source for an example. I'll probably improve the nfMakeLinear handling a bit before the final release so less things will be horribly slow as well.

[videoh]

Thank you, I will have a look.

[videoh]

So, does Vapoursynth try the new API with VapourSynthPluginInit2() and if it fails tries again with VapourSynthPluginInit()?

The diff between vapoursource.cpp and vapoursource4.cpp is quite extensive and scares me a bit. Is there a comprehensive guide to things that need to be changed to use API4? Thank you.

[Myrsloik]

So, does Vapoursynth try the new API with VapourSynthPluginInit2() and if it fails tries again with VapourSynthPluginInit()?

The diff between vapoursource.cpp and vapoursource4.cpp is quite extensive and scares me a bit. Is there a comprehensive guide to things that need to be changed to use API4? Thank you.

A mostly complete summary can be found here:

https://github.com/vapoursynth/vapoursynth/blob/doodle1/APIV4%20changes.txt

Note that a lot of changes are mostly renaming.

[longwin]

ffms2_1c6169a (https://ppp.woelkli.com/s/bx8zFHStJT9aCqs) (pass: tTnkia1ToVkw):
- ffms2@4567314;
- ffmpeg 4.4@1bc1757 (https://github.com/HomeOfAviSynthPlusEvolution/FFmpeg/tree/custom-patches-for-lsmashsource);
- zlib 1.2.11;
- dav1d 0.9.1;
- added FFAudioSource/FFMS2/FFmpegSource2 parameter "drc_scale" (float type, AC3 decoding).

Thank you for your build.

[gale]

Video encoded in vc1. With FFVideoSource the number of frames is one more than with eac3to.

[FranceBB]

Opened a new bug about a ZLog2 HDR H.265 UHD file (yes, there's more than just PQ and HLG in the world ehehehe): https://github.com/FFMS/ffms2/issues/395

[poisondeathray]

Opened a new bug about a ZLog2 HDR H.265 UHD file (yes, there's more than just PQ and HLG in the world ehehehe): https://github.com/FFMS/ffms2/issues/395

What versions ? Works ok for me.

avs+ r3482 x64

ffms2_StvG_1c6169a_20210814 (this is the one a few posts above) x64

L-SMASH-Works-20210811 x64
https://github.com/HomeOfAviSynthPlusEvolution/L-SMASH-Works/releases

I didn't test actual encode, but ran through ffmpeg rawvideo, so it goes through each frame, and completes
ffmpeg -i ffms2.avs -c:v rawvideo -an -f null NUL

Preview of ffms2 and lsmash scripts in avspmod looks ok, seeking to random frames


Simple AVS Script 2:

LWLibavVideoSource("T:\_RUBRICHE\MASSIMO\A002C0023_20211019172852_0001.MOV")

Expected behavior:

The file is supposed to be indexed correctly with the whole 3 minutes.

My lsmash index completed (yours apparently did not) , looks ok seeking in avspmod

[FranceBB]

FFMpeg 5 has been released and it supports IMF decoding by feeding it the cpl file.
Is it gonna be available for FFMpegSource2() too?

[Myrsloik]

FFMpeg 5 has been released and it supports IMF decoding by feeding it the cpl file.
Is it gonna be available for FFMpegSource2() too?

No idea. Depends on whether or not the current index method can be adapted. Also time. I have no time.

[kedautinh12]

Waiting for StvG ver :D

[LigH]

Don't ask which version VirtualDub2 still uses...

[Matias]

Kainote Beta have newest ffms2 based on ffmpeg 5.0
https://github.com/bjakja/Kainote (link in the description)

[kedautinh12]

Glad to see he comeback after long time against with diseased :D

[FranceBB]

I'll wait for the official ffms2 stable release, I'm not in the mood of testing things out right now, but thanks for the heads up.
Speaking of ffmpeg 5.0, I'm gonna quote myself from the LWLibav thread: (https://forum.doom9.org/showthread.php?p=1967162#post1967162)

I have a question, or rather a feature request: when an .xml is given to the indexer like LWLibavVideoSource("CPL.xml") and LWLibavAudioSource("CPL.xml") please try to use the IMF decoder built into FFMpeg rather than return an error.
That would be really cool as this way we're gonna have IMF support inside Avisynth!

the same applies for FFVideoSource("CPL.xml") and FFAudioSource("CPL.xml") and of course FFMpegSource2("CPL.xml", atrack=-1).

[OrangeColaJuice]

Kainote Beta have newest ffms2 based on ffmpeg 5.0
https://github.com/bjakja/Kainote (link in the description)

Gives error in avisynth.
>no function

[LigH]

More details please. Which function exactly is not found? Searching for common strings, it contains e.g. AvisynthPluginInit3 and FFVideoSource/FFAudioSource.

[OrangeColaJuice]

More details please. Which function exactly is not found? Searching for common strings, it contains e.g. AvisynthPluginInit3 and FFVideoSource/FFAudioSource.
It could be 32 bits and I haven't tested that.
I just replaced my old .dll with the one from the beta software and nothing works, no matter what variation of the name or known abbreviation of the function I try.

[LigH]

Then please call AVSMeter (https://forum.doom9.org/showthread.php?t=174797) -avsinfo -l -lf in a console and search for errors and supported "ffms2_..." functions in the generated avsinfo_x86.log; it might be possible, though, that most recent versions of plugins (incl. FFMS2) require AviSynth+ and don't really work anymore with legacy AviSynth versions...

[OrangeColaJuice]

Then please call AVSMeter (https://forum.doom9.org/showthread.php?t=174797) -avsinfo -l -lf

Turns out it is a 64 bit dll so I've reinstalled the 64 bit AviSynth, pic related.
https://files.catbox.moe/0cs5pg.png

more:
https://files.catbox.moe/kfeb6z.png

[StvG]

ffms2_6ad7738 (https://ppp.woelkli.com/s/NMk6MyD6LZR7nYH) (pass: u7Uezbh3fTHM):
- ffms2@90975ec;
- ffmpeg n5.1@1764a6887b;
- zlib 1.2.12;
- dav1d 1.0.0;
- AviSynth: set Dolby Vision RPU data in frame props.

[FranceBB]

ffms2_6ad7738 (https://ppp.woelkli.com/s/NMk6MyD6LZR7nYH) (pass: u7Uezbh3fTHM):
- ffms2@90975ec;
- ffmpeg n5.1@1764a6887b;
- zlib 1.2.12;
- dav1d 1.0.0;
- AviSynth: set Dolby Vision RPU data in frame props.

Thanks for the new build! Works like a charm :)

[Matias]

Turns out it is a 64 bit dll so I've reinstalled the 64 bit AviSynth, pic related.
https://files.catbox.moe/0cs5pg.png

more:
https://files.catbox.moe/kfeb6z.png

Yeah you right it's something weird with this ffms2, works well with aegisub but not with avisynth+

[StainlessS]

Yeah you right it's something weird with this ffms2, works well with aegisub but not with avisynth+

32 bit avisynth requires 32 bit dll's, 64 bit requires 64 bit dll's,
nothing weird there.

[Matias]

32 bit avisynth requires 32 bit dll's, 64 bit requires 64 bit dll's,
nothing weird there.

I installed a 64-bit version of Avisynth+ and 64-bit StvG version work well but ffms2 from Kainote beta not working with avisynth+
StvG version not working with Kainote Beta 0.9.9.1436 but working with AegisubDC

[LigH]

If Kainote is a 32 bit application, then it will use only a 32 bit AviSynth (no matter whether legacy AviSynth 2.60 or AviSynth+ 3.x), which loads only 32 bit plugins subsequently.

Some people only build a 64 bit version of plugins because most people use AviSynth+ in 64 bit with 64 bit video encoders, the need for 32 bit AviSynth plugins may decrease because there are not many applications anymore which only exist in 32 bit. Kainote appears to be such a rare case?

[Matias]

If Kainote is a 32 bit application, then it will use only a 32 bit AviSynth (no matter whether legacy AviSynth 2.60 or AviSynth+ 3.x), which loads only 32 bit plugins subsequently.

Some people only build a 64 bit version of plugins because most people use AviSynth+ in 64 bit with 64 bit video encoders, the need for 32 bit AviSynth plugins may decrease because there are not many applications anymore which only exist in 32 bit. Kainote appears to be such a rare case?

Kainote stable have 32 and 64 bit version (stvg ffms2 work with stable version), beta have only 64 bit version, I think it's something changed in program (error is talk about missing FFMS_FreeChapters in stvg ffms2), but it's not important, program is usable with bulid in ffms2
I only tested avisynth+ becouse @OrangeColaJuice had problem with ffms2 from Kainote Beta and this not working for me too
Previously, I only tested Kainote beta ffms2 in AegisubDC and I thinked it's good ffms2 for everything but I was wrong

[OrangeColaJuice]

ffms2_6ad7738 (https://ppp.woelkli.com/s/NMk6MyD6LZR7nYH) (pass: u7Uezbh3fTHM):
- ffms2@90975ec;
- ffmpeg n5.1@1764a6887b;
- zlib 1.2.12;
- dav1d 1.0.0;
- AviSynth: set Dolby Vision RPU data in frame props.

This is what I was waiting for, cheers!
:goodpost:

[filler56789]

ffms2_6ad7738 (https://ppp.woelkli.com/s/NMk6MyD6LZR7nYH) (pass: u7Uezbh3fTHM):
- ffms2@90975ec;
- ffmpeg n5.1@1764a6887b;
- zlib 1.2.12;
- dav1d 1.0.0;
- AviSynth: set Dolby Vision RPU data in frame props.

Grazie mille. :thanks:

[StvG]

Who downloaded ffms2_6ad7738 (https://ppp.woelkli.com/s/NMk6MyD6LZR7nYH) (pass: u7Uezbh3fTHM), download it again. FFmpeg was built without zlib (FFImageSource couldn't open png files), now it's fixed.

[FranceBB]

Who downloaded ffms2_6ad7738 (https://ppp.woelkli.com/s/NMk6MyD6LZR7nYH) (pass: u7Uezbh3fTHM), download it again. FFmpeg was built without zlib (FFImageSource couldn't open png files), now it's fixed.

I generally use ImageSource(), that's why I didn't notice.
Thanks for the heads up, though. :)

[Ceppo]

Is ffvideosource frame accurate with trim/temporal filter when importing a m2v file (DVD source)? I'm asking because I noticed it is x2 faster than regular d2v source filters :eek:

[FranceBB]

Is ffvideosource frame accurate with trim/temporal filter when importing a m2v file (DVD source)? I'm asking because I noticed it is x2 faster than regular d2v source filters :eek:

Technically it should.
The only issues I had with FFVideoSource() were with some MPEG-2 .ts files in which interlacing was screwed up once indexed while DGIndex did it right and a DNxHD 25i which had the interlacing screwed up once indexed due to a rather complicated bug which incidentally LWLibav also had, but that got fixed straight away in LWLibavVideoSource. Anyway, if FFVideoSource ever gives you problem, the sensible thing is to report the bug and then try with LSMASH.dll and call LWLibavVideoSource (). ;)

[Ceppo]

I had no problem at all, just wanting to check since another user didn't raccomanded to use it that way.

Thank you.

[jlw_4049]

Who downloaded ffms2_6ad7738 (https://ppp.woelkli.com/s/NMk6MyD6LZR7nYH) (pass: u7Uezbh3fTHM), download it again. FFmpeg was built without zlib (FFImageSource couldn't open png files), now it's fixed.

Works significantly better then the official release one! Thanks!

[kedautinh12]

Who downloaded ffms2_6ad7738 (https://ppp.woelkli.com/s/NMk6MyD6LZR7nYH) (pass: u7Uezbh3fTHM), download it again. FFmpeg was built without zlib (FFImageSource couldn't open png files), now it's fixed.

Your FFmpeg can't index my video in Megui. Example: https://mega.nz/file/eHQSWJxB#eSXcMype583W9Bij7L0jpot5Hse3WNdg9B2t4mxACPw

[StvG]

I can't help (not using MeGUI). The file is opening normally when MeGUI is not used.

[kedautinh12]

I can't help (not using MeGUI). The file is opening normally when MeGUI is not used.

My error logs in Megui:
-[Information] Log for job1 (idx, 2208012100.ts -> 2208012100.ts.ffindex)
--[Information] [04/08/2022 8:38:48 CH] Started handling job
--[Information] [04/08/2022 8:38:48 CH] Preprocessing
--[Information] [04/08/2022 8:38:48 CH] Job command line: "C:\Megui\MeGUI-2924-64\tools\ffms\ffmsindex.exe" -t -1 -f "C:\Users\ADMIN\Downloads\2208012100.ts" "C:\Users\ADMIN\Downloads\2208012100.ts.ffindex"
--[Information] [04/08/2022 8:38:48 CH] Process started
--[Information] [04/08/2022 8:38:48 CH] Standard output stream
--[Information] [04/08/2022 8:38:48 CH] Standard error stream
---[Information] [04/08/2022 8:38:48 CH] Indexing error: Audio decoding error
--[Error] [04/08/2022 8:38:48 CH] Process exits with error: 1
--[Information] [04/08/2022 8:38:48 CH] Job completed

[FranceBB]

Your FFmpeg can't index my video in Megui. Example: https://mega.nz/file/eHQSWJxB#eSXcMype583W9Bij7L0jpot5Hse3WNdg9B2t4mxACPw

It must be limited to MeGUI then, 'cause with AVSPmod it indexes it... https://i.imgur.com/BxAPDPW.png


--[Information] [04/08/2022 8:38:48 CH] Standard error stream
---[Information] [04/08/2022 8:38:48 CH] Indexing error: Audio decoding error
--[Error] [04/08/2022 8:38:48 CH] Process exits with error: 1
--[Information] [04/08/2022 8:38:48 CH] Job completed

Well, but I can see that the audio is indexed correctly...

https://i.imgur.com/Dn2LcS0.png

[StvG]

My error logs in Megui:
-[Information] Log for job1 (idx, 2208012100.ts -> 2208012100.ts.ffindex)
--[Information] [04/08/2022 8:38:48 CH] Started handling job
--[Information] [04/08/2022 8:38:48 CH] Preprocessing
--[Information] [04/08/2022 8:38:48 CH] Job command line: "C:\Megui\MeGUI-2924-64\tools\ffms\ffmsindex.exe" -t -1 -f "C:\Users\ADMIN\Downloads\2208012100.ts" "C:\Users\ADMIN\Downloads\2208012100.ts.ffindex"
--[Information] [04/08/2022 8:38:48 CH] Process started
--[Information] [04/08/2022 8:38:48 CH] Standard output stream
--[Information] [04/08/2022 8:38:48 CH] Standard error stream
---[Information] [04/08/2022 8:38:48 CH] Indexing error: Audio decoding error
--[Error] [04/08/2022 8:38:48 CH] Process exits with error: 1
--[Information] [04/08/2022 8:38:48 CH] Job completed

Try to index only the video stream without the audio one.

[Kurtnoise]

My error logs in Megui:
-[Information] Log for job1 (idx, 2208012100.ts -> 2208012100.ts.ffindex)
--[Information] [04/08/2022 8:38:48 CH] Started handling job
--[Information] [04/08/2022 8:38:48 CH] Preprocessing
--[Information] [04/08/2022 8:38:48 CH] Job command line: "C:\Megui\MeGUI-2924-64\tools\ffms\ffmsindex.exe" -t -1 -f "C:\Users\ADMIN\Downloads\2208012100.ts" "C:\Users\ADMIN\Downloads\2208012100.ts.ffindex"
--[Information] [04/08/2022 8:38:48 CH] Process started
--[Information] [04/08/2022 8:38:48 CH] Standard output stream
--[Information] [04/08/2022 8:38:48 CH] Standard error stream
---[Information] [04/08/2022 8:38:48 CH] Indexing error: Audio decoding error
--[Error] [04/08/2022 8:38:48 CH] Process exits with error: 1
--[Information] [04/08/2022 8:38:48 CH] Job completed
Looks like ffmsindex does not like -1 arg when only one audio stream is in TS files. Thats works correctly when several audio streams are there though...So, forcing the command line to -t 1 should work.

[kedautinh12]

Try to index only the video stream without the audio one.

Only video should work. Thanks

[kedautinh12]

Looks like ffmsindex does not like -1 arg when only one audio stream is in TS files. Thats works correctly when several audio streams are there though...So, forcing the command line to -t 1 should work.

In megui is auto app. I think can't add command line

[Kurtnoise]

In megui is auto app. I think can't add command line
make a bug report on megui tracker, I will have a look...

[kedautinh12]

make a bug report on megui tracker, I will have a look...

Ok, here
https://sourceforge.net/p/megui/bugs/972/

[SilSinn9801]

Who downloaded ffms2_6ad7738 (https://ppp.woelkli.com/s/NMk6MyD6LZR7nYH) (pass: u7Uezbh3fTHM), download it again. FFmpeg was built without zlib (FFImageSource couldn't open png files), now it's fixed.

Is this build compatible with the new VapourSynth R55+ method of storing alpha (from RGB+alpha PNG image sources) as a VideoNode property (rather than as a second clip in a 2-clip array like what the last official FFMS2 build –2.40– still does)? (This in reference to the issue I’m having here (https://forum.doom9.org/showthread.php?p=1973343).)

EDIT: Nevermind, it does after I tested it (https://forum.doom9.org/showthread.php?p=1973347#post1973347).

[wonkey_monkey]

I don't know if anyone knows, or needs to know, but I've been playing around with FFMS2 versions and I find I get seeking inaccuracies with myrsloik's 2.40 (original file was .mkv, but I also remuxed to .ts and .mp4 to no avail).

There is no problem with StvG's latest, nor with myrsloik's 2.23.1.

Edit: just found this: https://github.com/FFMS/ffms2/issues/394

[StvG]

ffms2_41af11c (https://ppp.woelkli.com/s/oJxxHkSrfqWeXYN) (pass: 6mO5osne0aCG):
- ffms2@780e931;
- ffmpeg@b95b2c;
- zlib 1.2.13;
- libxml2 v2.10.3;
- dav1d 1.0.0;
- AviSynth: set Dolby Vision RPU data in frame props.

[StvG]

ffms2_ad42af1 (https://ppp.woelkli.com/s/Zntfn8yMSdJDJn7) (pass: dhNsmKt69th1):
- ffms2@1031029;
- ffmpeg@4113445;
- dav1d 1.1.0.

[FranceBB]

Ah. A new update? Sweet.
Thanks for the new build, will test soon, right after lunch!

[filler56789]

ffms2_ad42af1 (https://ppp.woelkli.com/s/Zntfn8yMSdJDJn7) (pass: dhNsmKt69th1):
- ffms2@1031029;
- ffmpeg@4113445;
- dav1d 1.1.0.

:thanks: for the fresh build.

[FranceBB]

So far so good with the new build, I haven't received any errors on the jobs that have been running in our farm since the upgrade.

https://i.imgur.com/AgxIhKd.png

all the social x264 stuff, the streamix x262 stuff and the Remaster tape stuff went through successfully and the indexing was always with ffms2, so... looks good! :)

[kedautinh12]

So far so good with the new build, I haven't received any errors on the jobs that have been running in our farm since the upgrade.

https://i.imgur.com/AgxIhKd.png

all the social x264 stuff, the streamix x262 stuff and the Remaster tape stuff went through successfully and the indexing was always with ffms2, so... looks good! :)
Are you test with latest commit ffms mainstream??
https://github.com/FFMS/ffms2

[FranceBB]

@kedautinh12 it's the latest StvG build.

- ffms2@1031029;
- ffmpeg@4113445;
- dav1d 1.1.0.

He posted it here the other day, so I would assume yes:

ffms2_ad42af1 (https://ppp.woelkli.com/s/Zntfn8yMSdJDJn7) (pass: dhNsmKt69th1):
- ffms2@1031029;
- ffmpeg@4113445;
- dav1d 1.1.0.

[manuelin]

ffms2_ad42af1 (https://ppp.woelkli.com/s/Zntfn8yMSdJDJn7) (pass: dhNsmKt69th1):
- ffms2@1031029;
- ffmpeg@4113445;
- dav1d 1.1.0.

ffms2_41af11c (https://ppp.woelkli.com/s/oJxxHkSrfqWeXYN) (pass: 6mO5osne0aCG):
- ffms2@780e931;
- ffmpeg@b95b2c;
- zlib 1.2.13;
- libxml2 v2.10.3;
- dav1d 1.0.0;
- AviSynth: set Dolby Vision RPU data in frame props.

ffms2_6ad7738 (https://ppp.woelkli.com/s/NMk6MyD6LZR7nYH) (pass: u7Uezbh3fTHM):
- ffms2@90975ec;
- ffmpeg n5.1@1764a6887b;
- zlib 1.2.12;
- dav1d 1.0.0;
- AviSynth: set Dolby Vision RPU data in frame props.

Hello!
I wanted to report a bug that occurs in the latest versions and did not occur in older versions.

The problem is that when I use FFVideoSource(), if the file path has some special character (for example letters like "á", "é", "í", "ó", "ú", "ñ", etc.) it fails and can't find the file.
This happens in ad42af1 and 41af11c, however in 6ad7738 (and I think older versions as well) it works fine without any problem.

It would be greatly appreciated if it could be fixed and work like old versions again.
Thank you so much!

[LeXXuz]

Second that. Noticed the very same thing with German umlauts in file names.

[StvG]

Hello!
I wanted to report a bug that occurs in the latest versions and did not occur in older versions.

The problem is that when I use FFVideoSource(), if the file path has some special character (for example letters like "á", "é", "í", "ó", "ú", "ñ", etc.) it fails and can't find the file.
This happens in ad42af1 and 41af11c, however in 6ad7738 (and I think older versions as well) it works fine without any problem.

It would be greatly appreciated if it could be fixed and work like old versions again.
Thank you so much!

Second that. Noticed the very same thing with German umlauts in file names.

Tested with FFVideoSource("Aá.mov"):
- using the latest AvsPmod (https://forum.doom9.org/showthread.php?p=1983578#post1983578) - error "Can't open file 'Aa.mov`;
- using ffmpeg/avsmeter64/VirtualDub2_44282 - no issues.

Are you using AvsPmod? Can you try to run the script with ffmpeg? Can you open the file with VirtualDub2?

[LeXXuz]

Tested with FFVideoSource("Aá.mov"):
- using the latest AvsPmod (https://forum.doom9.org/showthread.php?p=1983578#post1983578) - error "Can't open file 'Aa.mov`;
- using ffmpeg/avsmeter64/VirtualDub2_44282 - no issues.

Are you using AvsPmod? Can you try to run the script with ffmpeg? Can you open the file with VirtualDub2?

I use MeGUI for indexing. Indexing starts and runs through the file after that MeGui is unable to open the indexfile in its AVS script creator stating file not found. In the log I can see the filename for opening the file doesn't have German umlauts but functional characters. Like its having the wrong char set.

Thought it's a MeGUI problem but it doesn't occur with older ffms versions.

[manuelin]

Tested with FFVideoSource("Aá.mov"):
- using the latest AvsPmod (https://forum.doom9.org/showthread.php?p=1983578#post1983578) - error "Can't open file 'Aa.mov`;
- using ffmpeg/avsmeter64/VirtualDub2_44282 - no issues.

Are you using AvsPmod? Can you try to run the script with ffmpeg? Can you open the file with VirtualDub2?

Yes, I use AvsPmod.

But I think there is no problem with AvsPmod neither with AviSynth nor with script, since using the same AvsPmod and the same AviSynth and the same script and simply replacing the "ffms2.dll" and "ffmsindex.exe" files of the 3 versions I mentioned, FFVideoSource() works or does not work depending on the ffms2.dll/ffmsindex.exe files you use.

I previously reported the problem in the ffms2 repository but they replied to me that it is not ffms2 problem:
https://github.com/FFMS/ffms2/issues/414
So then I decided to report it here, since I use the files shared in this thread.

Thank you very much!

[FranceBB]

Tested in AVSPmod mod 2.7.3.6 x64 on Windows Server 2019 and indeed "L'uomo che Ingannò la Morte MPEG-2 FULL HD SDR BT709 YUV422 25i TFF 8bit.mxf" doesn't seem to be an acceptable title due to the accent on "ò" resulting in the error "FFIndex: Can't open..." etc

https://i.imgur.com/5QWJLCu.png


Testing the very same script in Virtual Dub x64 also shows the issue:

https://i.imgur.com/0qMnZbJ.png

and so does ffplay:

https://i.imgur.com/55CYfda.png

and so does x264:

https://i.imgur.com/lOVvdnl.png

[qyot27]

Make sure the script is UTF-8 encoded.

Set Windows' systemwide codepage to UTF-8.

Do CLI work in Windows Terminal, since it can correctly display international characters.

Use ffmsindex to index the files.

[StvG]

Is ffms2_ad42af1_v1_x64 (https://ppp.woelkli.com/s/H4kXCaZczp6cksc) (pass: BLxmx6YsVJ03) any better?

[LeXXuz]

Is ffms2_ad42af1_v1_x64 (https://ppp.woelkli.com/s/H4kXCaZczp6cksc) (pass: BLxmx6YsVJ03) any better?

Yes. This version works fine for me. :) :thanks:

[kedautinh12]

Is ffms2_ad42af1_v1_x64 (https://ppp.woelkli.com/s/H4kXCaZczp6cksc) (pass: BLxmx6YsVJ03) any better?

how about x86??

[filler56789]

Is ffms2_ad42af1_v1_x64 (https://ppp.woelkli.com/s/H4kXCaZczp6cksc) (pass: BLxmx6YsVJ03) any better?
how about x86??
:goodpost: +1.
There are VfW codecs which are 32-bit only,
such as the olde and goode DivX.

[FranceBB]

how about x86??

Not quite as updated, but there are x86 builds from Reino. (https://rwijnsma.home.xs4all.nl/files/ffms2/?C=M;O=D)


:goodpost: +1.
There are VfW codecs which are 32-bit only,
such as the olde and goode DivX.

He released those in January 2023: https://forum.doom9.org/showthread.php?t=181802&page=4

Specifically, this is the 08-01-2023 ffms2 build: Link (https://rwijnsma.home.xs4all.nl/files/ffms2/ffms2-2.18-756-4d45afc-avs-vsp_ffmpeg-5.2-2131-fcd557a-win32-xpmod-sse.7z)
and of course his x86 builds are also XP compatible ;)
Perhaps, if you want a more updated one, like one from March instead of January, you can ask him in his dedicated topic and I'm sure he'll be happy to do that. ;)

[filler56789]

...
Perhaps

Not perhaps, surely.
I still don't know if you really misunderstood what kedautinh12 and I said,
OR if you just simulate misunderstandings for having some reason to post something. :D

[FranceBB]

Not perhaps, surely.
I still don't know if you really misunderstood what kedautinh12 and I said

It's midnight.
It's been a long day... Sorry about that

[Reel.Deel]

:goodpost: +1.
There are VfW codecs which are 32-bit only,
such as the olde and goode DivX.

Not sure what VfW has to do with FFMS2. FFmpeg has its own decoding libraries and does not rely on VfW.

[StvG]

how about x86??

Redownload ffms2_ad42af1_v1.

[manuelin]

Is ffms2_ad42af1_v1_x64 (https://ppp.woelkli.com/s/H4kXCaZczp6cksc) (pass: BLxmx6YsVJ03) any better?

It is still giving error, but now the problem is different...

Now the problem of the characters may be solved. I mean, I think there is another problem now.

Now every time I try to load the script, every time I reload it with F5, it shows me a different error... Something very strange.
The different errors that are displayed each time I press F5 are the following:
Failed to open 'XXXX.ffindex'
Failed to open 'XXXX.mkv'
Can't open 'XXXX.mkv'
The index does not match the source file

In fact, after reloading and trying many (many, many) times, sometimes it does work and loads the video..... Very strange.


Thank you very much for everything!

[filler56789]

Redownload ffms2_ad42af1_v1.

Thanks :thanks: again.

[StvG]

It is still giving error, but now the problem is different...

Now the problem of the characters may be solved. I mean, I think there is another problem now.

Now every time I try to load the script, every time I reload it with F5, it shows me a different error... Something very strange.
The different errors that are displayed each time I press F5 are the following:


In fact, after reloading and trying many (many, many) times, sometimes it does work and loads the video..... Very strange.


Thank you very much for everything!

What happens if you run the script with AVSMeter?

[manuelin]

Is ffms2_ad42af1_v1_x64 (https://ppp.woelkli.com/s/H4kXCaZczp6cksc) (pass: BLxmx6YsVJ03) any better?

It is still giving error, but now the problem is different...

Now the problem of the characters may be solved. I mean, I think there is another problem now.

Now every time I try to load the script, every time I reload it with F5, it shows me a different error... Something very strange.
The different errors that are displayed each time I press F5 are the following:
Failed to open 'XXXX.ffindex'
Failed to open 'XXXX.mkv'
Can't open 'XXXX.mkv'
The index does not match the source file

In fact, after reloading and trying many (many, many) times, sometimes it does work and loads the video..... Very strange.


Thank you very much for everything!

What happens if you run the script with AVSMeter?

I have tried AVSMeter and the same thing happens.

Every time I run the command, each time it shows me a different error from those I indicated in my previous comment.

[Emulgator]

What happens if you delete the old index file first and then F5 ?

[manuelin]

What happens if you delete the old index file first and then F5 ?

There is no ffindex file, it starts to process and load the video but finally it gives an error and the ffindex file is not generated.

[kakaze]

Is ffms2_ad42af1_v1_x64 (https://ppp.woelkli.com/s/H4kXCaZczp6cksc) (pass: BLxmx6YsVJ03) any better?
no, the same problems, typical errors, if the language in the path/file names is not English (in my case Cyrillic). This is both in AvsPmod and in the console script.
there is no such problem in ffms2_6ad7738.

[LeXXuz]

Yes. This version works fine for me. :) :thanks:

Have to revoke this as well. Still problems with files with German umlauts in the path name. No idea why it worked with the one file I tested it back then.

[StvG]

ffms2_r1360 (https://ppp.woelkli.com/s/H4kXCaZczp6cksc) (pass: BLxmx6YsVJ03):
- AviSynth: input filenames converted to UTF-8.
- ffms2@cf7c4b2;
- ffmpeg@7ecf1bf;
- libxml2 v2.10.4.

[kakaze]

ffms2_r1360 (https://ppp.woelkli.com/s/H4kXCaZczp6cksc) (pass: BLxmx6YsVJ03):
- AviSynth: input filenames converted to UTF-8.
- ffms2@cf7c4b2;
- ffmpeg@7ecf1bf;
- libxml2 v2.10.4.
now it works, thx

[Rob105]

Reading documentation for Avisynth+ (https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/faq/faq_loading_clips.html#how-do-i-load-mp4-mkv-m2ts-evo-into-avisynth) i found that to open MP4 need to use function FFmpegSource()

Which is missing in plugin v2.40, spent like hour troubleshooting this before i found this solution (https://forum.videohelp.com/threads/326930-ffmpegsource2-error-in-Avisynth#post2024539). :mad:

Wish you have provided proper ffms2.avsi that included this function with your plugin v2.40.

[qyot27]

Reading documentation for Avisynth+ (https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/faq/faq_loading_clips.html#how-do-i-load-mp4-mkv-m2ts-evo-into-avisynth) i found that to open MP4 need to use function FFmpegSource()

Which is missing in plugin v2.40, spent like hour troubleshooting this before i found this solution (https://forum.videohelp.com/threads/326930-ffmpegsource2-error-in-Avisynth#post2024539). :mad:

Wish you have provided proper ffms2.avsi that included this function with your plugin v2.40.
Uh, no. You're missing a 2. FFmpegSource2. Which has been included in the C++ plugin for years at this point.

That FAQ entry is referring to the old 1.x version of FFmpegSource, which is well over ten years out of date.

[kedautinh12]

When L-SMASH-Works and DGDecNV have Fixed _FieldBased, i thinh we can wait until FFMS2 have that fixed :D

[tormento]

When L-SMASH-Works and DGDecNV have Fixed _FieldBased
Yesterday DGDecNV slipstream fixed _FieldBased.

[flossy_cake]

ffms2_ad42af1 (https://ppp.woelkli.com/s/Zntfn8yMSdJDJn7) (pass: dhNsmKt69th1):
- ffms2@1031029;
- ffmpeg@4113445;
- dav1d 1.1.0.

Thanks for this, but rffmode=1 is not working in this new version - the video freezes and black screen.

Also if rffmode=1 is fixed, please can you make it set the field order per-frame, since many NTSC DVDs have dynamic field order and even Bob() will not work on them because Avisynth will display frames in wrong order because FFMS2 is not telling Avisynth the field order of the source clip.

Test clip: https://rationalqm.us/misc/lainvob.vob

Test script:

FFMS2(clip, atrack=-1, rffmode=1)

ScriptClip(last,
\ """

fieldbased = propGetAny("_FieldBased")
parity = GetParity(current_frame)

if (!IsInt(fieldbased)){fieldbased = "undefined"}
else if (fieldbased==0){fieldbased = "progressive"}
else if (fieldbased==1){fieldbased = "bottom field first"}
else if (fieldbased==2){fieldbased = "top field first"}

if (!IsBool(parity)){parity="undefined"}
else if (parity==true){parity = "top field first"}
else if (parity==false){parity = "bottom field first"}

Text( "_FieldBased: " + fieldbased + "\n" + "GetParity: " + parity + "\n", lsp=0)

\ """)



To summarise:


FFMS2 support for rffmode=1 is completely nonfunctional
FFMS2 rffmode=1 needs to set the field order so that avisynth knows the field order of each frame


:thanks:

[StvG]

ffms2_r1363 (https://ppp.woelkli.com/s/H4kXCaZczp6cksc) (pass: BLxmx6YsVJ03):
- AviSynth: both GetParity and _FieldBased now can be changed per frame.
- ffms2@cf7c4b2;
- ffmpeg@4b1969;
- zlib 1.2.13;
- dav1d 1.2.1;
- libxml2 v2.11.4.

[kedautinh12]

Wow, sound good :D

[FranceBB]

Thank you for the new build!
So far so good. :)

[tebasuna51]

Please support AviSynth+ r4001 (https://forum.doom9.org/showthread.php?p=1989323#post1989323) including the audio channel mask.

[rgr]

Is it a known issue that ffms2 doesn't respect "Delay relative to video : -200ms"?

[StvG]

ffms2_r1369 (https://ppp.woelkli.com/s/H4kXCaZczp6cksc) (pass: BLxmx6YsVJ03):
- AviSynth: fixed GetParity (rffmode > 0) and _FieldBased. (bugs introduced in the previous version)
- AviSynth: added support for audio channel mask.
- AviSynth: fixed fps (rffmode > 0). (bug introduced by the new FFmpeg API from the beginning of 2023)
- ffms2@cf7c4b2;
- ffmpeg@9310ff;
- zlib 1.3;
- dav1d 1.2.1;
- libxml2 v2.11.5.

Is it a known issue that ffms2 doesn't respect "Delay relative to video : -200ms"?

Does ffmpeg respect it by default?

[tebasuna51]

ffms2_r1369 (https://ppp.woelkli.com/s/H4kXCaZczp6cksc) (pass: BLxmx6YsVJ03):
...
- AviSynth: added support for audio channel mask.
...

Thanks, to obtain the audio channel mask with last avs+ we need before:

global OPT_UseWaveExtensible = true # Needed to use global OPT_dwChannelMask=
audio=FFAudioSource("8w3D.ec3")
global OPT_dwChannelMask=FFCHANNEL_LAYOUT

Now is enough:

audio=FFAudioSource("8w3D.ec3")

to obtain the channel mask if is included in the source.

[FranceBB]

- AviSynth: fixed GetParity (rffmode > 0) and _FieldBased. (bugs introduced in the previous version)
- AviSynth: added support for audio channel mask.
- AviSynth: fixed fps (rffmode > 0). (bug introduced by the new FFmpeg API from the beginning of 2023)

Thank you for fixing those and most importantly for supporting audio channel masks.
Tebasuna and I are probably the only two people excited for it, but still, thank you! XD

[kedautinh12]

Me too :D

[Myrsloik]

ffms2_r1369 (https://ppp.woelkli.com/s/H4kXCaZczp6cksc) (pass: BLxmx6YsVJ03):
- AviSynth: fixed GetParity (rffmode > 0) and _FieldBased. (bugs introduced in the previous version)
- AviSynth: added support for audio channel mask.
- AviSynth: fixed fps (rffmode > 0). (bug introduced by the new FFmpeg API from the beginning of 2023)
- ffms2@cf7c4b2;
- ffmpeg@9310ff;
- zlib 1.3;
- dav1d 1.2.1;
- libxml2 v2.11.5.

Does ffmpeg respect it by default?

Is the current patch set available somewhere?

[tebasuna51]

Is the current patch set available somewhere?

It is included in the download.

Of course you need also the last avisynth.h (https://github.com/AviSynth/AviSynthPlus/blob/master/avs_core/include/avisynth.h)

[Myrsloik]

It is included in the download.

Oh, only as a single monolithic mess with no comments as to why certain parts are relevant? That's a lot less helpful.

I did however see that getparity is implemented for avisynth. Does anything actually use that?

[kedautinh12]

Oh, only as a single monolithic mess with no comments as to why certain parts are relevant? That's a lot less helpful.

I did however see that getparity is implemented for avisynth. Does anything actually use that?

I think avisynth more helpful than vapoursynth thread of doom9 :D

[StvG]

Just a heads up that from this version (https://forum.doom9.org/showthread.php?p=1986154#post1986154) there is a regression about the handling of the unicode filenames.

If you have issues about unicode filenames complain to the used app for reading/opening the avs script that doesn't support unicode filenames or just active the Unicode UTF-8 support in Windows (if available).

Starting from this post (https://forum.doom9.org/showthread.php?p=1992697#post1992697) you can read about AvsPmod.

I'll upload the code used for my builds to codeberg and then post a new version.

[StvG]

Seeking test with ffms2_r1369 (https://forum.doom9.org/showthread.php?p=1991852#post1991852) and ffms2 build from f20827c (https://github.com/FFMS/ffms2) (both using the same versions of the external libraries). The used video files (https://drive.google.com/file/d/1-95lSEnxu3aGZS3WqwJPaYHSk4M7GSr9/view?usp=share_link).

https://thumbs2.imgbox.com/70/4c/WbhGLirM_t.png (https://imgbox.com/WbhGLirM)

[FranceBB]

In other words, from the chart and the test assets, there's no scenario in which someone should be using the legacy Myrsloik 2020 version given that the new version 2023 builds you keep producing addressed plenty of the issues it had.
Once again, thank you for keeping the project alive, in fact your builds have now become the standard included in FFAStrans and also the one my colleagues and I use at work on a daily basis :)

[StvG]

Also you probably noticed that there are files with same names but different containers. I remuxed the files from ts,mts,mpg,mp4... to mkv. Other than VC-1 the other codecs are ok when mkv is used.

[FranceBB]

Ok, so, after some rather extensive testing and after wondering "why?" many times, I actually realized one thing: FFMpeg's mxf muxer for MJPEG2000 RGB48 HDR PQ files is now completely broken.
It already had its own issues (https://trac.ffmpeg.org/ticket/10001) a year ago with the wrong bit depth being written in the container and the CDCI essence descriptor UL (i.e YUV 4:4:4) being used instead of the RGBA essence descriptor UL (i.e RGB48), but now it got worse.
You now may be wondering: "Well, that's an ffmpeg problem, what does it have to do with FFVideoSource()"?
Well, simply enough, now the video in the mxf container remuxed by ffmpeg is so broken that FFVideoSource() - albeit indexing it - shows repeated/duplicated frames all over the place while dropping some other frames (I tested both ffms2 version r1347 from January 2023 and version r1369 from September 2023) and they both have issues. I even tried different seeking modes like forcing linear, specifying fpsnum=24000 and fpsden=1001 etc but nothing really helped.
Please note that this is not necessarily a problem of ffms2, but rather FFMpeg muxing the file blatantly incorrectly in the mxf container.
On the other hand, muxing the very same file in the mkv container has no issues at all and in fact both versions of ffms2 index it just fine and without any repeated/duplicated frames, correctly reporting 23,976p.

So, this post is to warn everyone and avoid having other people spending hours in debugging:
if anyone has to deal with MJPEG2000 files in mxf muxed by FFMpeg, please remux them in mkv and they'll work like a charm.


For reference, here's the original mxf file:


General
Complete name : Test.mxf
File size : 295 GiB
Duration : 57 min 30 s
Overall bit rate : 734 Mb/s
Frame rate : 23.976 FPS

Video
ID : 2-2
Format : JPEG 2000
Format profile : IMFS4k@ML6SL4
HDR format : SMPTE ST 2086, HDR10 compatible
Muxing mode : MXF
Codec ID : 0D010301020C0600-0401020203010313
Duration : 57 min 30 s
Bit rate : 716 Mb/s
Width : 3 840 pixels
Height : 2 160 pixels
Display aspect ratio : 16:9
Frame rate : 23.976 (24000/1001) FPS
Color space : RGB
Bit depth : 12 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 3.600
Stream size : 288 GiB (97%)
Title : Image Track
Color range : Full
Color primaries : BT.2020
Transfer characteristics : PQ
Matrix coefficients : BT.2020 non-constant
Mastering display color primaries : Display P3
Mastering display luminance : min: 0.0050 cd/m2, max: 1000 cd/m2


and here's what happens after remuxing it with ffmpeg's mxf muxer:



General
Complete name : Test.mxf
Format : MXF
Format version : 1.3
Format profile : OP-1a
Format settings : Closed / Complete
File size : 295 GiB
Duration : 57 min 30 s
Overall bit rate : 734 Mb/s
Frame rate : 23.976 FPS
Package name : File Package: SMPTE ST 422 / ST 2067-5 frame wrapping of JPEG 2000 codestreams
Writing application : FFmpeg OP1a Muxer
Writing library : Lavf (mingw32)

Video
ID : 2
Format : JPEG 2000
Format profile : IMFS4k@ML6SL4
HDR format : SMPTE ST 2086, HDR10 compatible
Format settings, wrapping mode : Frame
Codec ID : 0D010301020C0100-0401020203010100
Duration : 57 min 30 s
Bit rate : 716 Mb/s
Width : 3 840 pixels
Height : 2 160 pixels
Display aspect ratio : 16:9
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:4:4
Bit depth : 16 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 3.600
Stream size : 288 GiB (97%)
Color primaries : BT.2020
Transfer characteristics : PQ
Matrix coefficients : BT.2020 non-constant
Mastering display color primaries : Display P3
Mastering display luminance : min: 0.0050 cd/m2, max: 1000 cd/m2
Delay_SDTI : 3573570



In other words the container is lying as it's saying that it's a 4:4:4 16bit file, while it's actually an RGB48 file, which causes FFVideoSource() to be rather "confused" about it.
The range information (originally full range) is also lost, which of course is very bad for any automation you might have depending on it to be set correctly in the Avisynth frame properties.
On the other hand, remuxing it to .mkv has no issues at all and preserves everything correctly.
So, in a nutshell, if you get an FFMpeg muxed MJPEG2000 in mxf, please remux it to a sensible container like mkv before indexing it, otherwise the result is gonna be completely wrong.

[FranceBB]

ffms2_r1369 (https://ppp.woelkli.com/s/H4kXCaZczp6cksc) (pass: BLxmx6YsVJ03):
- AviSynth: fixed GetParity (rffmode > 0) and _FieldBased. (bugs introduced in the previous version)
- AviSynth: added support for audio channel mask.
- AviSynth: fixed fps (rffmode > 0). (bug introduced by the new FFmpeg API from the beginning of 2023)
- ffms2@cf7c4b2;
- ffmpeg@9310ff;
- zlib 1.3;
- dav1d 1.2.1;
- libxml2 v2.11.5.

Don't hate me, but I'm still having issues with files that have Italian accents. :(

[LeXXuz]

Don't hate me, but I'm still having issues with files that have Italian accents. :(

Same here with german characters. I stopped using ffms and LSmash some time ago. At least DGIndex doesn't have the slightest problem with special characters in file names. And it is still the most precise indexer imho as long as you use it on elementary steams and not containers.

[StvG]

Don't hate me, but I'm still having issues with files that have Italian accents. :(

Same here with german characters. I stopped using ffms and LSmash some time ago. At least DGIndex doesn't have the slightest problem with special characters in file names. And it is still the most precise indexer imho as long as you use it on elementary steams and not containers.

Post #2769 (https://forum.doom9.org/showthread.php?p=1992722#post1992722).

[FranceBB]

If you have issues about unicode filenames complain to the used app for reading/opening the avs script that doesn't support unicode filenames


That is quite literally FFMpeg, which, in theory, does, so there must be something else going on here.
Validating scripts with ffprobe and ffmpeg results in an error on both sides.
I'll come up with more examples on Monday.

[StvG]

Just a heads up that from this version (https://forum.doom9.org/showthread.php?p=1986154#post1986154) there is a regression about the handling of the unicode filenames...

... I'll upload the code used for my builds to codeberg and then post a new version.

Wait for the new version or use old version.

[StvG]

The source code is here (https://codeberg.org/StvG/ffms2).

ffms2_r1386 (https://codeberg.org/StvG/ffms2/releases/tag/r1386)

@FranceBB, you can try this version.

If AvsPmod is used, make sure the used version is >=2.7.5.5 to avoid issues with the file names.

[FranceBB]

The source code is here (https://codeberg.org/StvG/ffms2).

ffms2_r1386 (https://codeberg.org/StvG/ffms2/releases/tag/r1386)

@FranceBB, you can try this version.

Woah, thank you a lot, gotta try it straight away! :)

Ok, so, tested on a real life workflow (slowmotion from 100fps to 25fps and encode in XDCAM-50) with a simple file called:

Test accenti àèéùì.MP4


Version ffms2_r1369 (old):
Validate: FFVideoSource: Failed to open 'Test accenti Ã*èéùì.MP4'

https://i.imgur.com/WiniJlM.png


Version ffms2_r1386 (new):

the encoding started just fine

https://i.imgur.com/19oH7X2.png

and went on to complete just fine. ;)

https://i.imgur.com/7EOVgPS.png

Thank you, thank you, thank you!
I upgraded all my production systems. :)
This is gonna be a very nice surprise for the news department guys as they clock in just a few hours, at 5AM.

[kedautinh12]

Strange, I'm using with AvsPmod 2.7.5.5 but still have error
https://i.imgur.com/w4dfjxX.png
Sample: https://drive.google.com/file/d/1VAcp5b28eCjlqwZoNxd0z3Ge4R3pRbJK/view?usp=sharing

[StvG]

Strange, I'm using with AvsPmod 2.7.5.5 but still have error
https://i.imgur.com/w4dfjxX.png
Sample: https://drive.google.com/file/d/1VAcp5b28eCjlqwZoNxd0z3Ge4R3pRbJK/view?usp=sharing

Make sure you don't have other version than r1386.

[kedautinh12]

Make sure you don't have other version than r1386.

I'm sure, only one file .dll and .exe in ffms folder and in the avs+ autoload folder don't have any version of ffms2

[StvG]

What about open the script with avsmeter64/virtualdub2?

[kedautinh12]

What about open the script with avsmeter64/virtualdub2?

I trid with Megui but I got this error too

[StvG]

Are you sure your path to the file is correct or you have write permission?

[kedautinh12]

Are you sure your path to the file is correct or you have write permission?

I'm sure, and I use it normally with non-utf8 file name in same folder

[kedautinh12]

I tried with DGDecNV and it's work normally

[StvG]

I'm sure, and I use it normally with non-utf8 file name in same folder

What's your system locale?

https://ibb.co/SrF2NZy

[kedautinh12]

I changed to Vietnamese region and restart but the error continues

[StvG]

I change system locale to Vietnamese. AvsPmod errors but avsmeter64, virtualdub2 is fine.

[kedautinh12]

I change system locale to Vietnamese. AvsPmod errors but avsmeter64, virtualdub2 is fine.

so why need change system locale when DGDecNV don't need change it and working with AvsPmod and Megui??

[StvG]

You wrote you have the same error with avsmeter64 and virtualdub2 (post #2785) but they are fine. The error is only with AvsPmod.

[StvG]

Try this AvsPmod (https://filebin.net/43ggbshts33bxncf). It should work.

Edit: Doesn't DGDecNV index the file with own app? You don't index the file with DGDecNV and AvsPmod like you do with ffms2, right?

[kedautinh12]

You wrote you have the same error with avsmeter64 and virtualdub2 (post #2785) but they are fine. The error is only with AvsPmod.

I said same error with Megui. Ok i'd rather change file name utf8 to non-utf8 or use DGDecNV for utf8 file name with AVSPmod or Megui than change and learn to use other app

[StvG]

Try the AvsPmod version from my previous post.

As far as DGDecNV - it's irrelevant to this issue because it opens/creates the files with own app and then you just use the index file in AvsPmod/Megui. On the other side ffms2/lsmashsource are using AvsPmod/MeGui (or whatever app) to open/index the file. So as already wrote in post #2769 - "If you have issues about unicode filenames complain to the used app for reading/opening the avs script that doesn't support unicode filenames or just active the Unicode UTF-8 support in Windows (if available)." in this case it's still AvsPmod issue especially if avsmeter64/virtualdub2 are working.

Edit: If you have issues with MeGui too, raise the issue to their devs to support UNICODE file names.

[kedautinh12]

Try the AvsPmod version from my previous post.

As far as DGDecNV - it's irrelevant to this issue because it opens/creates the files with own app and then you just use the index file in AvsPmod/Megui. On the other side ffms2/lsmashsource are using AvsPmod/MeGui (or whatever app) to open/index the file. So as already wrote in post #2769 - "If you have issues about unicode filenames complain to the used app for reading/opening the avs script that doesn't support unicode filenames or just active the Unicode UTF-8 support in Windows (if available)." in this case it's still AvsPmod issue especially if avsmeter64/virtualdub2 are working.

Edit: If you have issues with MeGui too, raise the issue to their devs to support UNICODE file names.
I don't think that. L-smash-works 20231010 1144.0.0.0 works normally with both AvsPmod and Megui until Asd-g release this commit (https://github.com/HomeOfAviSynthPlusEvolution/L-SMASH-Works/commit/5b27e80294cc95dd71f66ce891dbf44882e00dd1) and it's not work anymore with utf8 file name when I use L-smash-works 20231106 1147.0.0.0. Issue here (https://github.com/HomeOfAviSynthPlusEvolution/L-SMASH-Works/issues/49). That proves Megui and AvsPmod already support .avs file have utf8 character

[kedautinh12]

I tested with three latest build ffms2, L-SMASH-Works, DGDecNV in Megui and AvsPmod. Two is ffms2 and DGDecNV can index file but only DGDecNV can open preview video normally. Older ver of L-SMASH-Works can index and open preview video normally

[StvG]

Why don't you test the AvsPmod from post #2794 (https://filebin.net/43ggbshts33bxncf) with ffms2_r1386 and your file?

https://ibb.co/GkR10jk

[kedautinh12]

Why don't you test the AvsPmod from post #2794 (https://filebin.net/43ggbshts33bxncf) with ffms2_r1386 and your file?

https://ibb.co/GkR10jk

The AvsPmod from post #2794 (https://filebin.net/43ggbshts33bxncf work normally with ffms2_r1386. After, I checked the older ver r1369 and it works with Megui, AvsPmod 2.7.5.5 but can't use with your AvsPmod shared
https://imgur.com/a/i9F2OYO

[Boulder]

The method for adding Unicode support to DGIndexNV also works with other apps, I use it myself with VirtualDub2 and avs2yuv64 to be able to use Unicode characters in paths. See "UTF-8 Notes.txt" in the DGIndexNV package.

[StvG]

The AvsPmod from post #2794 (https://filebin.net/43ggbshts33bxncf work normally with ffms2_r1386. After, I checked the older ver r1369 and it works with Megui, AvsPmod 2.7.5.5 but can't use with your AvsPmod shared
https://imgur.com/a/i9F2OYO

The older ffms2 r1369 works with Megui and AvsPmod 2.7.5.5 because you set the correct system locale. For example, set Bulgaria for system locale and you will see how r1369+Megui/AvsPmod 2.7.5.5 will fail with your file but my test AvsPmod+r1386 is working. That's the whole point of the unicode support - to be not dependent on the system locale.

[kedautinh12]

The older ffms2 r1369 works with Megui and AvsPmod 2.7.5.5 because you set the correct system locale. For example, set Bulgaria for system locale and you will see how r1369+Megui/AvsPmod 2.7.5.5 will fail with your file but my test AvsPmod+r1386 is working. That's the whole point of the unicode support - to be not dependent on the system locale.

No, I get back and reset before this test and r1369 work perfectly with English (United States)

[StvG]

No, I get back and reset before this test and r1369 work perfectly with English (United States)

What no? Did you read what I wrote? Am I writing in a non-understandable way?

It's second time I write exactly what you should do to see that r1369+AvsPmod 2.7.5.5/Megui is broken but you do something completely different and then you say: "No...".
The first time I explicitly asked you to test virtualdub2/avsmeter64 but you tested Megui.

I'm talking on a wall. Basta.


For anyone else having issues with file names and r1386 - test the script with virtualdub2/avsmeter64/ffmpeg. If you still have issues with these programs report here. If you don't have issues with these but you have issue with other program you use to open the avs script (AvsPmod/Megui...) do not complain here, complain to devs of the used program.

[kedautinh12]

What no? Did you read what I wrote? Am I writing in a non-understandable way?

It's second time I write exactly what you should do to see that r1369+AvsPmod 2.7.5.5/Megui is broken but you do something completely different and then you say: "No...".
The first time I explicitly asked you to test virtualdub2/avsmeter64 but you tested Megui.

I'm talking on a wall. Basta.


For anyone else having issues with file names and r1386 - test the script with virtualdub2/avsmeter64/ffmpeg. If you still have issues with these programs report here. If you don't have issues with these but you have issue with other program you use to open the avs script (AvsPmod/Megui...) do not complain here, complain to devs of the used program.

Ok, I think you said I changed the system locate to Vietnamese before is the correct system locate so I said to you that I changed back to English (United States) before the test. And yeah, Bulgari has correctly broken to r1369 but I changed it to Vietnamese and it's working again. I think some system locale doesn't work correctly with Megui and AvsPmod when use r1369

Edit: With Vietnamese system locate, r1386, virtualdub2 from here (https://forum.doom9.org/showthread.php?p=1993799#post1993799), I got error too. I open .avs file via virtualdub2
https://i.imgur.com/vc32ZKF.png

Edit 2: avsmeter too
https://i.imgur.com/CniZUw5.png

Edit 3: FFMPEG too
https://i.imgur.com/8SKOzac.png

[kedautinh12]

The method for adding Unicode support to DGIndexNV also works with other apps, I use it myself with VirtualDub2 and avs2yuv64 to be able to use Unicode characters in paths. See "UTF-8 Notes.txt" in the DGIndexNV package.

I tried with your suggestion but Megui and AvsPmod don't work with r1386

[StvG]

Ok, I think you said I changed the system locate to Vietnamese before is the correct system locate so I said to you that I changed back to English (United States) before the test. And yeah, Bulgari has correctly broken to r1369 but I changed it to Vietnamese and it's working again. I think some system locale doesn't work correctly with Megui and AvsPmod when use r1369

Edit: With Vietnamese system locate, r1386, virtualdub2 from here (https://forum.doom9.org/showthread.php?p=1993799#post1993799), I got error too. I open .avs file via virtualdub2


Edit 2: avsmeter too


Edit 3: FFMPEG too



Make sure you're using r1386 - https://ibb.co/4mSnx3f

[kedautinh12]

I'm sure:
https://i.imgur.com/quf6PVZ.png

[kedautinh12]

Ok, it's works now with check a box Beta: Use Unicode UTF-8 for worldwide language support in Megui and AvsPmod
https://i.imgur.com/J3j1mNf.png

Edit: but I can't use same way with Virtualdub2 and avsmeter64
Edit 2: My mistake when I save script .avs as ANSI so Virtualdub2 and avsmeter64 don't work. A way above only use with Megui and AvsPmod don't support utf8

[StvG]

r1386 should work without the check. Can you share the output of avsmeter64 -avsinfo?

[kedautinh12]

r1386 should work without the check. Can you share the output of avsmeter64 -avsinfo?

https://jumpshare.com/s/5UgR7DiSNYzLfFeJp0he

[StvG]

Come on... we're talking about UTF-8 and you saved your scrtipt (.avs) as ANSI? It's no surprise all apps avsmeter64/ffmpeg/virtualdub2 complains.

Try this test (https://filebin.net/jjekjv1l9mkleevp). Just open test.bat and you should have the video playing.

[kedautinh12]

Ok, when i change code to utf8 in avs file. VirtualDub2/AVSMeter/FFMPEG work without check beta box

[Emulgator]

StvG, many thanks !
Region setting: Deutsch, UTF-8 support unticked.
Your UTF-8 test.bat calling UTF-8 script calling ffplay on Vietnamese-named video ác quá.mkv with source filter ffms2.dll version 1386 works here.
P.S. And AvsPmod 2.7.5.5 fails and 2.7.3.6M works on the same script.
P.P.S. And the new AvsPmod 2.7.5.6 works. Thanks to gispos !

[StvG]

ffms2_r1387 (https://codeberg.org/StvG/ffms2/releases/tag/r1387)

[FranceBB]

ffms2_r1387 (https://codeberg.org/StvG/ffms2/releases/tag/r1387)

Seems to be working just fine with Avisynth + x264 + FFMpeg AAC + MP4Box:

https://i.imgur.com/HOTBnsJ.png

[flossy_cake]

ffms2_r1387 (https://codeberg.org/StvG/ffms2/releases/tag/r1387)

Not working for me unfortunately:

https://i.ibb.co/GHTMyCR/Untitled-1.png

The latest "official" version here (https://github.com/FFMS/ffms2/releases/tag/2.40) is working for me, but suffers the issue with interlaced MPEG2 where it doesn't properly obey the repeat field flags, resulting in broken output like random frames having wrong field order and wrong frame pacing type visual effects. It's fine for x264/x265 progressive stuff though, just not NTSC DVDs which unfortunately is most of what I'm using Avisynth for.

[StvG]

@flossy_cake, mpc-hc 2.1.2 (https://github.com/clsid2/mpc-hc/releases/tag/2.1.2) works for me with the following script:

FFVideoSource("1080p.mkv")

Run avsmeter64 with the script to see if there is error.

You can be more specific. For example, what's the used script so one could reproduce the issue.

[kedautinh12]

Did you update to latest the vc++?
https://github.com/abbodi1406/vcredist/releases

[flossy_cake]

@flossy_cake, mpc-hc 2.1.2 (https://github.com/clsid2/mpc-hc/releases/tag/2.1.2) works for me with the following script:

FFVideoSource("1080p.mkv")


Thanks that works for me too. So I guess it's somehow audio related since ffms2() doesn't work for me.

Unfortunately interpretation of MPEG2 repeat field flags is still wrong compared to LWLibav and DGDecode which both get it right. Here (https://drive.google.com/file/d/1QaVeLqnl0oOlclrb89O9NrkcWDGvKpzK/view?usp=sharing) is a test clip, try:


FFVideoSource("C:\S01E02_cut.mkv", rffmode=1)
Bob()


Placing an AssumeTFF/AssumeBFF before the Bob doesn't fix it since FFVideoSource's interpretation of the repeat field flags appears to be dynamically wrong -- some frames are ok, others are not.

Compare with:


LWLibavVideoSource("C:\S01E02_cut.mkv", repeat=true)
Bob()



edit: I should mention that clip is not an ideal test clip as it's been remuxed from the DVD VOB, and something about doing that seems to trip up certain decoders for that particular DVD. I can upload the full 1GB VOB if you want to see how the repeat field flags are interpreted correctly by LWLibav and DGDecode.

edit: was able to make a short VOB clip using DVDShrink - uploaded here (https://drive.google.com/file/d/1mbHHgNyNFJdFPZDcJbJ0USK6d47HAKDR/view?usp=sharing). LWLibAv and DGDecode play it correctly while FFMS does not, so I think that would be the ideal test file.

edit: if I had to guess what is going on, perhaps FFMS is obeying the repeat field flags but just not getting the field order right. There is a table here (https://github.com/HomeOfAviSynthPlusEvolution/L-SMASH-Works/issues/32) which shows how repeat fields should be handled to produce the final presented frames (the bottom row marked "decode frame" is what FFMS should output).

If the issue is occurring within the ffmpeg binaries (https://ffmpeg.org/doxygen/trunk/vf__repeatfields_8c_source.html) used by FFMS then I'm guessing it's probably not something that could be fixed in the avisynth plugin anyway.

[hello_hello]

Not working for me unfortunately

I have the same issue with the 64 bit versions of ffms2_r1386 and ffms2_r1387. I haven't tested the 32 bit versions yet.

FFMS2 with audio enabled (or FFAudioSource) produces an access violation error message (AvsPmod). I assumed it was a problem relating to running Avisynth in Wine on Linux originally, but I've also tested it on Windows 11 with the same result.

https://imgur.com/xe28LfT.png

[StvG]

@flossy_cake, thanks for the samples. rffmode=0 is ok but rffmode=1 gives different results than lwlibavvideosource. Have to take a look.

@hello_hello, I have no issues with the following:

FFVideoSource("test.mkv")

a=FFMS2("test.mkv", atrack=-1)
#FFAudioSource("test.mkv")
AudioDub(a)
Waveform()

You can share a sample so I can reproduce the issue.

[kedautinh12]

I follow step by step in utf8.txt (the file in DGDemux) with ffms r1386. Some step like run regedit file and change name DGIndexNVutf8 manifest file to Meguiuft8 manifest (sorry i can't remember exactly file name cause i don't near the PC now) and put same folder with megui.exe. But Megui.exe don't work with ffms2 r1386 when try index file. I tried it with AVSPmod but it's don't work too. Lately, I tried this step and it's work without change name of utf8 file
https://github.com/HomeOfAviSynthPlusEvolution/L-SMASH-Works/issues/49#issuecomment-1807345434

[kedautinh12]

Megui 2944 x64 don't work with ffms2 r1386 and L-SMASH-Works 20231106 1147.0.0.0 but it's work with ffms r1387 and L-SMASH-Works 20231117 1156.0.0.0

Here my Megui 2944 (https://drive.google.com/file/d/1Mv19aMfGD-6zJc1MrDhKcGm39VhiDhGT/view) you can try download from offical page but it's only work with avs+ 3.5 and you need MeGUI AvisynthWrapper from Pinterf to work with avs+ >=3.6 while my link already have this

[kedautinh12]

1, Megui 2944 x64
2, file name ác quá (https://drive.google.com/file/d/1VAcp5b28eCjlqwZoNxd0z3Ge4R3pRbJK/view?usp=drivesdk)
3, Megui same notification error with AVSPmod when try indexing with ffms r1386
https://forum.doom9.org/showthread.php?p=1993755#post1993755

I thought you will fix easily with more info :D

[flossy_cake]

@flossy_cake, thanks for the samples. rffmode=0 is ok

rffmode=0 in my experience is not usable with NTSC DVDs containing repeat field flags either. It seems the only way to play back NTSC DVDs which use repeat fields flags is to obey those flags. DG talks about it here (https://www.rationalqm.us/dgmpgdec/DGIndexManual.html#FieldOp):


Ignore Pulldown Flags - The pulldown flags are ignored. This allows one to obtain the raw encoded MPEG pictures, with no repeated fields. However, because repeated fields intended for display are ignored and not displayed, the resulting frame rate may differ from the source frame rate. It may even vary throughout the clip, due to irregular patterns of pulldown flags. If the pulldown is irregular, use of this option will cause the audio-video sync to change at different parts of the clip, and most likely sync will not be acceptable. This option is mostly intended for power users, who would use it as a diagnostic aid for inspecting the encoded MPEG pictures. Although this option ignores the flags, they are still stored in the D2V file although DGDecode will also ignore them.


Here (https://drive.google.com/file/d/1xz_WEX36iv8tpC18zR8e8-etGwtqfuVb/view?usp=drive_link) is a longer clip from an NTSC DVD with repeat field flags where you should see the issue -- it wasn't obvious on the previous Lain clip as there weren't any audio cues correlating to anything on screen, but it was likely playing the video at the wrong rate due to ignorance of repeat field flags. If you leave the video playing for about 1 minute after the intro it should be out of sync by then. I was using:


video = FFVideoSource(clip, rffmode=0)
audio = FFAudioSource(clip)
AudioDub(video, audio)

[flossy_cake]

This may help with debugging... I saw Lwlibav includes the frame properties _EncodedFrameTop and _EncodedFrameBottom which say which source frame was used to generate the top and bottom fields of the current_frame.

Take this frame for example:

https://c.l3n.co/i/slQcjC.png

It says the top field of this frame was from frame 2475 and bottom field was from 2476. 2475 comes before 2476 so it means this particular frame should be top field first. I suspect the issue is that occasionally FFMS2 is getting this wrong and puts in the wrong location. But FFMS doesn't populate any frame properties from this clip. I looked at FFInfo() but it didn't show more useful info.

[kedautinh12]

I remember ffms2 already had frame properties

[flossy_cake]

I remember ffms2 already had frame properties

Sorry yes, StvG's version does -- the _FieldBased property:


_FieldBased
0=frame based (progressive), 1=bottom field first, 2=top field first


There is also


GetParity (clip, int n)
Returns true if frame n is top field first of frame-based clip


Comparison LWLibAV vs FFMS: https://drive.google.com/u/0/uc?id=1nbX3ZnaiVfg3JbAa0tOqb4pFuyxG80LS&export=download

https://c.l3n.co/i/sSpXlH.png

Script used to render the above clip:


file = "c:\S01E02_cut.mkv" # https://drive.google.com/u/0/uc?id=1QaVeLqnl0oOlclrb89O9NrkcWDGvKpzK&export=download

lwlav = LWLibavVideoSource(file, repeat=true)
lwlav = lwlav.Trim(938, 1042) ++ lwlav.Trim(2606, 2684) ++ lwlav.Trim(2779,2915)
lwlav = lwlav.ScriptClip("""
if (propGetAny("_FieldBased")==0){fb="progressive"}
if (propGetAny("_FieldBased")==1){fb="BFF"}
if (propGetAny("_FieldBased")==2){fb="TFF"}
if (GetParity(current_frame)==true){gp="TFF"}
if (GetParity(current_frame)==false){gp="BFF"}
SubTitle("Correct" + "\n"
\ + "_Fieldbased: " + fb + "\n"
\ + "GetParity(): " + gp
\ , align=5, text_color=$00FF00, lsp=0, size=30)
\ .SubTitle("LWLibavVideoSource(file, repeat=true)", size=30)
\ """)
lwlav = lwlav.Bob()

ffvs = FFVideoSource(file, rffmode=1)
ffvs = ffvs.Trim(938, 1042) ++ ffvs.Trim(2606, 2684) ++ ffvs.Trim(2779,2915)
ffvs = ffvs.ScriptClip("""
if (Defined(propGetAny("_FieldBased"))){
if (propGetAny("_FieldBased")==0){fb="progressive"}
if (propGetAny("_FieldBased")==1){fb="BFF"}
if (propGetAny("_FieldBased")==2){fb="TFF"} }
else { fb = "undefined" }
if (GetParity(current_frame)==true){gp="TFF"}
if (GetParity(current_frame)==false){gp="BFF"}
SubTitle("Incorrect" + "\n"
\ + "_Fieldbased: " + fb + "\n"
\ + "GetParity(): " + gp
\ , align=5, text_color=$FF0000, lsp=0, size=30)
\ .SubTitle("FFVideoSource(file, rffmode=1)", size=30)
\ """)
ffvs = ffvs.Bob()

StackHorizontal(lwlav, ffvs)



__________________________________________________________________________

P.S I deleted my previous 2x2 tiled comparison video as it was wrong because according to GetParity():

FFMS2(rffmode=1) # some frames are TFF, others BFF
FFMS2(rffmode=1).AssumeTFF() # all frames TFF
FFMS2(rffmode=1).AssumeBFF() # all frames BFF

So my comparison script was wrong there, please ignore that (I've deleted it).

I suppose it's still useful for showing that FFMS2(rffmode=1).AssumeBFF() doesn't resolve the issue since doing a Bob() on that still shows frames presented in the wrong order.

[flossy_cake]

By the way it seems the _FieldBased prop is unreliable in both LWLibav & FFMS2 - this frame for example is clearly not progressive despite being flagged as such:


https://a.l3n.co/i/sScJPz.png

edit: now that I look at the actual definition of FieldBased, perhaps none of the frames should be flagged as _Fieldbased=0 (progressive). Fieldbased I think is what you get after a SeparateFields() - every frame is now a single field, and this clip isn't that. Maybe it's referring to what the decoder sees internally, not really sure.

There is a field-based flag, but contrary to what you might expect, this flag is not related to interlaced video. In fact, all video (progressive or interlaced) is frame-based, unless you use AviSynth filters to change that. There are two filter who turn frame-based video into field-based video: SeparateFields and AssumeFieldBased.

Also I tried a ScriptClip ComplementParity workaround for FFMS2 and that still produced fields in nonlinear order (visible by framestepping through the bobbed output).

Perhaps this wasn't much of an issue in the past as most people do their IVTC/deinterlacing at half rate so half the frames get thrown away anyway and that reduces or eliminates the issue.

[real.finder]

in DVD case it's kinda complicated, back then this is https://github.com/Asd-g/MPEG2DecPlus/issues/9#issuecomment-1114307244 what I see do the job in these cases, you can read all comments if you like

[StvG]

By the way it seems the _FieldBased prop is unreliable in both LWLibav & FFMS2 - this frame for example is clearly not progressive despite being flagged as such:


https://a.l3n.co/i/sScJPz.png

edit: now that I look at the actual definition of FieldBased, perhaps none of the frames should be flagged as _Fieldbased=0 (progressive). Fieldbased I think is what you get after a SeparateFields() - every frame is now a single field, and this clip isn't that. Maybe it's referring to what the decoder sees internally, not really sure.



Also I tried a ScriptClip ComplementParity workaround for FFMS2 and that still produced fields in nonlinear order (visible by framestepping through the bobbed output).

Perhaps this wasn't much of an issue in the past as most people do their IVTC/deinterlacing at half rate so half the frames get thrown away anyway and that reduces or eliminates the issue.

Try this version (https://filebin.net/ygbp9loimbe82o80).

I probably should remove _FieldBased when rffmode > 0. The frame you showed is constructed from fields of one frame marked as interlaced (bottom first) and one frame marked as progressive.

[flossy_cake]

Try this version (https://filebin.net/ygbp9loimbe82o80).


Oh my gosh you bloody beauty! Rffmode 1 appears to be working perfectly, and the Avisynth parity (getparity) stays locked for the whole clip which avoids potentially confusing any downstream deint/IVTC filters. Fantastic, really happy with this.

:thanks:

However I must use a different filter for audio otherwise FFMS crashes with that same message I posted earlier (hello_hello having same issue it seems).

Previously I wrote that using FFAudioSource instead of FFMS2 avoided the crash, but it turns out I had a different dll version that time - v1349 according to file properties. So v1349 doesn't crash, but your two most recent betas of v1387 are both crashing. Hopefully that offers a clue. I have tried the suggestions here (https://forum.doom9.org/showthread.php?p=1994336#post1994336) and here (https://forum.doom9.org/showthread.php?p=1994461#post1994461) without effect.

[flossy_cake]

Try this version (https://filebin.net/ygbp9loimbe82o80).

Hmm, seems to crash when multithreading is enabled:

ffms2(clip, rffmode=1) # or FFVideoSource
bob() # remove this line = no crash
prefetch(4)


Sidenote: must remember to delete .ffindex files before trying a new dll version otherwise the old index files will be used by the new dll, and this was creating some bugged behaviour for me.

[StvG]

Hmm, seems to crash when multithreading is enabled:

ffms2(clip, rffmode=1) # or FFVideoSource
bob() # remove this line = no crash
prefetch(4)


Sidenote: must remember to delete .ffindex files before trying a new dll version otherwise the old index files will be used by the new dll, and this was creating some bugged behaviour for me.

I can reproduce this crash and will take a look later.

About the audio. As I wrote I cannot reproduce the issue. You can share a sample that causes the crash and the used script.

[flossy_cake]

About the audio. As I wrote I cannot reproduce the issue. You can share a sample that causes the crash and the used script.

For me it's crashing on all files, eg.

file = "C:\S01E02_cut.mkv" #https://drive.google.com/u/0/uc?id=1QaVeLqnl0oOlclrb89O9NrkcWDGvKpzK&export=download

video = FFVideoSource(file, rffmode=1)
audio = FFAudioSource(file, track=-1)
AudioDub(video, audio)

Must be something system specific - here are my installed C++ runtimes

https://a.l3n.co/i/sMSvZ7.png

https://a.l3n.co/i/sMnItM.png

edit: also tried moving all dlls out of /plugins/ folders leaving only ffms2

[hello_hello]

@hello_hello, I have no issues with the following:

FFVideoSource("test.mkv")

a=FFMS2("test.mkv", atrack=-1)
#FFAudioSource("test.mkv")
AudioDub(a)
Waveform()

You can share a sample so I can reproduce the issue.

Sorry about the slow reply. Here's a small sample if it's still helpful.

audio test.mkv (https://files.videohelp.com/u/210984/audio%20test.mkv)

[StvG]

@flossy_cake, the crash isn't related to the Redistributable Runtimes.
@hello_hello, thanks for the sample. I have no issues with it and the showed script (AvsPmod used). What app did you use to run/open the script?

Anyway, try ffms2_test1 (https://filebin.net/v6l7es0xouzs166j).

[hello_hello]

I'm using AvsPmod, but I get the same error when I open the script with MPC-HC. It's happening with Avisynth running in Wine and also on Windows 11 in VirtualBox.
I haven't let Windows update itself for a while. I'll do that later and report back if it makes a difference.

https://imgur.com/ApmC3Gj.png

ffms2_test1 produces a different error message, unfortunately, but it's the same for both Wine and Windows and AvsPmod and MPC-HC.

https://imgur.com/8w5CCrL.png

Edit: I also tried replacing 64 bit Avisynth.dll 3.7.2 with version 3.7.3, but nothing changed.

Edit: I have the 32 bit version of Avisynth+ installed in a 32 bit Wine prefix (I don't have it installed on Windows) and FFMS2 r1387 produces the same access violation error message. The video on it's own is still okay.

https://imgur.com/SnS7eoV.png

[StvG]

@hello_hello, with ffms2_test1 I get the same error ("... zero size audio"). Try ffms2_test2 (https://filebin.net/lkjey5n6ocu2c4jg).

[hello_hello]

Did you use latest vc++ (https://github.com/abbodi1406/vcredist/releases)?

I have now but it made no difference. I also installed the latest updates for Windows 11. I'd forgotten how slow and painful that process is.

As it didn't solve the problem I thought I'd try some older FFMS2 versions. Fortunately I didn't have to go back far. 64 bit r1369 works normally in Wine and on Windows 11. 32 bit r1369 works normally in a 32 bit Wine prefix.
It's a mystery.....

https://imgur.com/Gd2chi5.png

[kedautinh12]

r1387 work with me too

[hello_hello]

@hello_hello, with ffms2_test1 I get the same error ("... zero size audio"). Try ffms2_test2 (https://filebin.net/lkjey5n6ocu2c4jg).

Thanks, but unfortunately that takes me back to the access violation error. It's still happening in both Wine and Windows 11.
I've even tried completely emptying the auto-loading plugins folder (aside from FFMS2) just in case.... but it didn't help.

Cheers.

[kedautinh12]

You can check with Dependencies, drag and drop ffm2.dll to app
https://github.com/lucasg/Dependencies/releases

[StvG]

Thanks, but unfortunately that takes me back to the access violation error. It's still happening in both Wine and Windows 11.
I've even tried completely emptying the auto-loading plugins folder (aside from FFMS2) just in case.... but it didn't help.

Cheers.

You're using not very recent avs+? Try this ffms2_test3 (https://filebin.net/itul9nrgrswy8816).

You can check with Dependencies, drag and drop ffm2.dll to app
https://github.com/lucasg/Dependencies/releases

It's not related to the dependencies. If some dependency is missing the error will be that the function ffms2 is not found.

[hello_hello]

You're using not very recent avs+? Try this ffms2_test3 (https://filebin.net/itul9nrgrswy8816).

Success!!!! Thank you.

I'm using Avisynth+ 3.7.2, because I haven't been motivated to replace DitherTools yet, but I did try 3.7.3 and it produced the same access violation error.

If I was to ask you what the problem was, would I understand the answer?

Thanks again!

[StvG]

Success!!!! Thank you.

I'm using Avisynth+ 3.7.2, because I haven't been motivated to replace DitherTools yet, but I did try 3.7.3 and it produced the same access violation error.

If I was to ask you what the problem was, would I understand the answer?

Thanks again!

For r1369 when I initially added audio channel mask I added similar check to this one (https://github.com/FFMS/ffms2/pull/421/commits/f12c48a2a903e32093d8f3f0feeb446057b0a11a) - if the new audio property is not supported by avs+ (not very recent version) it would not add such property. After the official ffms2 added audio channel mask (https://github.com/FFMS/ffms2/commit/ef243ab40b8d4b6d18874c6cef0da1a2f55a6a45) (without such check if avs+ supports channel mask), I removed my patch for channel mask. Now I have to add again this check.

ffms2_test1 is using different ffmpeg libraries and that's why the error was different. It's ffmpeg culprit.

About DitherTools - you can try this one (https://gitlab.com/uvz/AviSynthPlus-Plugins-Scripts/-/blob/master/plugins64+/dither.dll?ref_type=heads) with the newer avs+.

[hello_hello]

For r1369 when I initially added audio channel mask I added similar check to this one (https://github.com/FFMS/ffms2/pull/421/commits/f12c48a2a903e32093d8f3f0feeb446057b0a11a) - if the new audio property is not supported by avs+ (not very recent version) it would not add such property. After the official ffms2 added audio channel mask (https://github.com/FFMS/ffms2/commit/ef243ab40b8d4b6d18874c6cef0da1a2f55a6a45) (without such check if avs+ supports channel mask), I removed my patch for channel mask. Now I have to add again this check.

Well that's annoying because as I wrote in an earlier post I checked it with Avisynth+ 3.7.3 but it still produced the same error. Well.... apparently I didn't... because I tried again and r1387 works fine with Avisynth+ 3.7.3. Maybe I did something silly like replace Avisynth.dll in the wrong Wine prefix or replaced it while AvsPmod was still open or something..... sorry about that.

About DitherTools - you can try this one (https://gitlab.com/uvz/AviSynthPlus-Plugins-Scripts/-/blob/master/plugins64+/dither.dll?ref_type=heads) with the newer avs+.

Cheers. I'll update Avisynth+ now.

[kedautinh12]

About DitherTools - you can try this one (https://gitlab.com/uvz/AviSynthPlus-Plugins-Scripts/-/blob/master/plugins64+/dither.dll?ref_type=heads) with the newer avs+.

This dither for 64 bit, you need ask Asd-g to support 32 bit with newer avs+ too, @hello_hello
https://gitlab.com/uvz/AviSynthPlus-Plugins-Scripts/-/issues

[StvG]

ffms2_r1390 (https://codeberg.org/StvG/ffms2/releases/tag/r1390)

[hello_hello]

ffms2_r1390 (https://codeberg.org/StvG/ffms2/releases/tag/r1390)

Thanks.

[flossy_cake]

ffms2_r1390 (https://codeberg.org/StvG/ffms2/releases/tag/r1390)

^ this is working for me too, with regards to both audio and prefetch.

In light of this ffms2 is now top tier for me. If it could do multithreaded indexing to speed up the indexing process, that would put it ahead of LWLibav for me personally - would that even be possible in theory or is indexing a strictly linear process?

[rgr]

"int atrack = -2
The audio track to open. atrack=-1 means select the first available track. atrack=-2 (the default) means audio is disabled."

It would be useful to know in the manual that the track numbering starts from 1.

[Myrsloik]

"int atrack = -2
The audio track to open. atrack=-1 means select the first available track. atrack=-2 (the default) means audio is disabled."

It would be useful to know in the manual that the track numbering starts from 1.

It doesn't. All tracks share the same number series. Your file probably has video as track 0.

[rgr]

It doesn't. All tracks share the same number series. Your file probably has video as track 0.

Ok now I understand. The description suggested to me that ffms2 only renumbers audio tracks.

[rgr]

I downloaded a new version (I don't remember what old one I had) and I see some error.
ffms2 creates (at least for some files) the index file from scratch, even though one already exists (and was created by the new version of ffms2).

[rgr]

I downloaded a new version (I don't remember what old one I had) and I see some error.
ffms2 creates (at least for some files) the index file from scratch, even though one already exists (and was created by the new version of ffms2).

I found an error pattern -- for files with national characters in the name, the ffindex file is always created even if it exists.

[StainlessS]

Good post rgr, :goodpost:
helps dev find code location of error.

[StvG]

ffms2_r1391 (https://codeberg.org/StvG/ffms2/releases/tag/r1391)

AviSynth: fixed unnecessary index recreating.

[FranceBB]

Thank you!
Looks like I have something to test on Monday ehehehehehe

[flossy_cake]

ffms2_r1391 (https://codeberg.org/StvG/ffms2/releases/tag/r1391)

AviSynth: fixed unnecessary index recreating.

I was just wondering about FFGetVersion()... this returns 3.1.1.0 with the above build. I want to check it in my script to make sure the user who uses my script (which uses ffms2) is using YOUR fork of ffms2 with the recent rffmode fix... wondering what should I check for in the version number string to make sure of that. i.e what convention for numbering you will use in the future, eg. as long as all 4 digits are > 3 & 1 & 1 & 0 should I be safe to assume it is your r1391 or above?

Thanks

[StvG]

I was just wondering about FFGetVersion()... this returns 3.1.1.0 with the above build. I want to check it in my script to make sure the user who uses my script (which uses ffms2) is using YOUR fork of ffms2 with the recent rffmode fix... wondering what should I check for in the version number string to make sure of that. i.e what convention for numbering you will use in the future, eg. as long as all 4 digits are > 3 & 1 & 1 & 0 should I be safe to assume it is your r1391 or above?

Thanks

If you do right click on the dll file Properties->Details, the version strings are different than the official ffms2. Also the version is 3.1.0.0... instead of 3.1.1.0... I remember that the upstream changed the version from 3.0.1.0 to 3.1.1.0 (https://github.com/FFMS/ffms2/commit/dc5953c05ee5665330dbb63293355cc00e9d4895#diff-6f9d3ed22601609f9f0a456e33d6d633eae61e73b49fe76e6a681cac113f017f) instead 3.0.1.0->3.1.0.0 but obviously I didn't change ffms.h.

As for FFGetVersion() I can add the revision number, so the output will be "3.1.0.0 r1391".

[flossy_cake]

As for FFGetVersion() I can add the revision number, so the output will be "3.1.0.0 r1391".

:thanks:

[flossy_cake]

@StvG

I'm just having some issues with interlaced AVC files - recordings of broadcast TV from Enigma2 PVR (it remuxes them to .ts files on its hard drive)

To even get anything usable (seekable) with FFMpegVideoSource I must first run the .ts files through this ffmpeg pseudo-repair:

"ffmpeg.exe" -i "C:\recording.ts" -c copy "C:\repaired.ts"

I suppose this is not so remarkable if the PVR itself has to cut the stream when it makes the recording, so there is probably going to be some weirdness in the stream anyway.

Test file 1: 576i AVC 25.0fps (https://drive.google.com/file/d/1ZuEXrzeQK4RUx9FpMJmvCGt23fRlDDYA/view?usp=sharing)
Problem: plays at 12.5fps when rffmode=1, plays at 24.973fps when rffmode=0

Test file 2: 1080i AVC 25.0fps (https://drive.google.com/file/d/1Dusyec9ce6OPIRb-p5AhMbzstKEPqv-d/view?usp=sharing)
Problem: "no audio track found" when track=-1. Setting track=1 result in "audio track contains no audio frames"

audio = FFAudioSource(filePath, track=-1)
video = FFVideoSource(filePath, rffmode=1)
AudioDub(video, audio)
SubTitle(string(FrameRate)+"fps", align=5)


LWLibAv plays them without issue
edit: except it needs av_sync=true to match FFAudioSource's adjustdelay=-1

:thanks:

[StvG]

ffms2_r1393 (https://codeberg.org/StvG/ffms2/releases/tag/r1393)
Added revision to the displayed version.
Fixed fps (rffmode > 0) (H264).


Test file 2: 1080i AVC 25.0fps (https://drive.google.com/file/d/1Dusyec9ce6OPIRb-p5AhMbzstKEPqv-d/view?usp=sharing)
Problem: "no audio track found" when track=-1. Setting track=1 result in "audio track contains no audio frames"

audio = FFAudioSource(filePath, track=-1)
video = FFVideoSource(filePath, rffmode=1)
AudioDub(video, audio)
SubTitle(string(FrameRate)+"fps", align=5)


LWLibAv plays them without issue
edit: except it needs av_sync=true to match FFAudioSource's adjustdelay=-1

:thanks:

ffmpeg -i "1080i AVC.ts" -vcodec copy vid.h264 -acodec copy aud.ac3

Muxing vid.h264 and aud.ac3 with mkvtoolnix -> no issues.

[flossy_cake]

ffms2_r1393 (https://codeberg.org/StvG/ffms2/releases/tag/r1393)
Added revision to the displayed version.
Fixed fps (rffmode > 0) (H264).

:thanks:

I did notice the frame rate is still 24.x instead of 25.0 when rffmode=0, but it seems that could be easily workedaround with AssumeFPS(25) or defaulting rffmode to 1.

[flossy_cake]

To even get anything usable (seekable) with FFMpegVideoSource I must first run the .ts files through this ffmpeg pseudo-repair:

"ffmpeg.exe" -i "C:\recording.ts" -c copy "C:\repaired.ts"


I forgot about the seekmodes... seekmode 2 resolved this issue for me, so I don't need to run it through the above repair process.

Without performing the above repair, the fps issue is resolved also.

This leaves the only issue being the audio issue on the 1080i test file. Here (https://drive.google.com/file/d/1AnagYIoIeXZQjhJNtYFKHnblvxSQpq01/view?usp=sharing) is the original unrepaired 1080i .ts file straight from the PVR if it's of any use.

[StvG]

:thanks:

I did notice the frame rate is still 24.x instead of 25.0 when rffmode=0, but it seems that could be easily workedaround with AssumeFPS(25) or defaulting rffmode to 1.

I forgot about the seekmodes... seekmode 2 resolved this issue for me, so I don't need to run it through the above repair process.

Without performing the above repair, the fps issue is resolved also.

This leaves the only issue being the audio issue on the 1080i test file. Here (https://drive.google.com/file/d/1AnagYIoIeXZQjhJNtYFKHnblvxSQpq01/view?usp=sharing) is the original unrepaired 1080i .ts file straight from the PVR if it's of any use.

If you do demuxing and muxing, as I wrote in my previous post, you will see that ffmpeg gives multiply "Application provided invalid, non monotonically increasing dts to muxer in stream 0: x >= x". Also if you do the mentioned demuxing+muxing, the resulted mkv file have 25fps with rffmode=0 too. I wouldn't use other containers than mkv with ffms2 (for anything). If you don't want remuxing ts or other containers to mkv, go with l-smash-works (it's more reliably for the containers other than mkv) or other source filter.

[FranceBB]

Hey Steve, sorry to bother you but one of my colleagues in Germany reported a bug.
The source file (https://onedrive.live.com/?authkey=%21AKTWZPhkRjP%2DoeY&id=B1CCE5E25DD4A220%21499&cid=B1CCE5E25DD4A220) is an XDCAM-50 file, namely an MPEG-2 Open GOP file 4:2:2 25i TFF 8bit BT709 SDR muxed in mxf:

General
Complete name : A:\MEDIA\temp\test01-190224-01source.MXF
Format : MXF
Commercial name : XDCAM HD422
Format version : 1.3
Format profile : OP-1a
Format settings : Closed / Complete
File size : 1.35 GiB
Duration : 3 min 13 s
Overall bit rate : 60.0 Mb/s
Frame rate : 25.000 FPS
Encoded date : 2024-02-19 12:05:39.760
Writing application : Grass Valley K.K. EDIUS 8.5.3.3262

Video
ID : 2
Format : MPEG Video
Commercial name : XDCAM HD422
Format version : Version 2
Format profile : 4:2:2@High
Format settings : CustomMatrix / BVOP
Format settings, BVOP : Yes
Format settings, Matrix : Custom
Format settings, GOP : M=3, N=12
Format settings, picture structure : Frame
Format settings, wrapping mode : Frame
Codec ID : 0D01030102046001-0401020201040300
Duration : 3 min 13 s
Bit rate mode : Constant
Bit rate : 50.0 Mb/s
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate : 25.000 FPS
Standard : Component
Color space : YUV
Chroma subsampling : 4:2:2
Bit depth : 8 bits
Scan type : Interlaced
Scan order : Top Field First
Compression mode : Lossy
Bits/(Pixel*Frame) : 0.965
Time code of first frame : 00:00:00:00
Time code source : Group of pictures header
GOP, Open/Closed : Open
GOP, Open/Closed of first frame : Closed
Stream size : 1.12 GiB (83%)
Color range : Limited
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709
Delay_SDTI : 0


When he indexes it with

FFVideoSource("A:\MEDIA\temp\test01-190224-01source.MXF", fpsnum=25 , fpsden=1, seekmode=1)

it shows a repeated (i.e duplicated) frame, namely Frame 401 at 00:00:16:04, however using

LWLibavVideoSource("A:\MEDIA\temp\test01-190224-01source.MXF", fpsnum=25, fpsden=1)

there are no duplicated frames.

This was tested with ffms2 3.1.0.0 1357+36 1c0dcfa (1393) from January 6th, 2024.

In particular, FFInfo() shows

https://i.imgur.com/DM4ov9l.png
https://i.imgur.com/db2yWUs.png


for the two identical frames (401 and 402).
You can see that they're identical 'cause the yellow leaf falling from the tree at the bottom doesn't move and stays still.
These are frame 401 and 402 decoded by LWLibavVideoSource("A:\MEDIA\temp\test01-190224-01source.MXF", fpsnum=25, fpsden=1) with Info():

https://i.imgur.com/MK2fDOJ.png
https://i.imgur.com/yKAm4lM.png


you can see the leaf actually moving as it's on its way to the ground...

Here you can find both the source and the re-encoded output which contains the duplicated frame: Link (https://1drv.ms/f/s!AiCi1F3i5cyxg3Ok1mT4ZEYz_qHm?e=jyDjO1)

The source is called "source" of course.

p.s I assume that StvG stands for "Steve G" but correct me if I'm wrong xD

[Myrsloik]

FFMS2 5.0 RC1 (https://github.com/FFMS/ffms2/releases/tag/5.0-RC1)

Test it. Report your findings. Open proper issues on github.

- 5.0
- Fixed all issues with FFmpeg 6.1 which is now the minimum requirement
- Fixed av1 decoding
- Added HDR10+ and DolbyVision metadata
- Fixed audio decoding that could otherwise get stuck in an infinite loop on certain files
- Fixed framerate in Avisynth when using VFR=>CFR mode
- Dropped VapourSynth API3 support
- Indexer now has a configurable progress update interval
- Alpha planes are now correctly marked as being full range
- The full set of demuxer options can now be passed using the FFMS2 API
- Now sets channel layout in Avisynth+

[StvG]

...FFVideoSource("A:\MEDIA\temp\test01-190224-01source.MXF", fpsnum=25 , fpsden=1, seekmode=1) ...

Hey,

Indeed specifying fpsnum returns wrong frames.

Just FFVideoSource("A:\MEDIA\temp\test01-190224-01source.MXF") is ok. I have to look at this.

[kedautinh12]

Hey,

Indeed specifying fpsnum returns wrong frames.

Just FFVideoSource("A:\MEDIA\temp\test01-190224-01source.MXF") is ok. I have to look at this.

Will you update your ffms2?

[FranceBB]

Hey,

Indeed specifying fpsnum returns wrong frames.

Just FFVideoSource("A:\MEDIA\temp\test01-190224-01source.MXF") is ok. I have to look at this.

Yep, specifying just FFVideoSource() works, but it's indeed weird. Generally having dups when fpsnum and fpsden are specified only happens when the decoder finds some issues with a certain frame. I'm not really sure why it's getting this result instead... :(



FFMS2 5.0 RC1 (https://github.com/FFMS/ffms2/releases/tag/5.0-RC1)

Test it. Report your findings.

Thank you for releasing a new major version and its release candidate.
I noticed that it's 64bit only. Are we gonna get a 32bit version too once the stable version is gonna be out?
The second question is: does it include all the changes StvG made over the last 4 years?
It would actually help to have like one single codebase.
Anyway, this new version is also affected by the bug I reported above but in a slightly different way.
Frame 401 and Frame 402 are the very same frame and they don't match the former frames.
In version 5.0.0.0 RC1 we have the leaf falling (that was supposed to be at frame 401-402) at frame 399-400 (which is wrong 'cause it means that it missed some frames before) and there's movement:

https://i.imgur.com/fOJKu7s.png
https://i.imgur.com/TSzh0pp.png

but as soon as we get to frame 401-402 we get the same frame repeated twice:

https://i.imgur.com/mjFkDfc.png
https://i.imgur.com/i7IaRpZ.png


What's worse is that frame 401-402 (duplicated) of version 5.0.0.0 RC1 should actually be frames 403-404 as correctly reported by LWLibavVideoSource():

https://i.imgur.com/luga1Wa.png
https://i.imgur.com/aNohXw8.png

[Myrsloik]

https://github.com/FFMS/ffms2/releases/tag/5.0-RC2
(5.0-RC2)
Fixes these issues reported by FranceBB:

duplicate/dropped frames in CFR mode with the same framerate as the source (or a multiple)
incorrect seeking in files where the decoder only uses slice threading


I'd really appreciate if someone runs seek tests on this build.

And to answer the rest of FranceBB's questions:

StvG's changes are hacks at best that change and prod until a single file "works". It's useful for end users in the short term but of no use to the project long term. The actual FFMS2 development aims at doing things as correctly as possible and get things fixed upstream when possible.
If there's great demand for a 32 bit version maybe I'll release that but let me remind you that x64 is over 20 years old now and every single x86 CPU worth encoding with has supported it since then more or less. Do you really need a 32 bit build or are you simply chasing the memory of your encoding youth?

[FranceBB]

Thank you for the new build!
I tested it and it indeed fixed the issue. :)
I'm gonna make it go through some regression testing as well on a few known use-cases and I'll let you know, but thank you in advance for this.

About the 32bit version, of course 64bit CPUs and OS have been around for several years, but the problem is that some Avisynth plugins are still 32bit.
Sure, there are workarounds like using MPPipeline etc, but some people prefer to use 32bit Avisynth instead, which is why, in FFAStrans (FFMpeg Avisynth Transcoder) (https://forum.doom9.org/showthread.php?t=176655), the freely available project I constantly and very passionately contribute to, we also offer the option to use 32bit Avisynth with 32bit plugins in the workflows, hence the need of a 32bit indexer. :)

[poisondeathray]

5.0-RC2 is missing PNG support (images, or PNG in MOV)

FPS returned for short video (1 frame) prores in mov is incorrect (should be 24/1 fps , but results in 12288 fps)
https://www.mediafire.com/file/9kghx7frsant1fe/ff_pr4444.mov/file

[ChaosKing]

I'd really appreciate if someone runs seek tests on this build.




More or less the same as before, compare with older builds https://forum.doom9.org/showthread.php?t=176231
https://i.imgur.com/e1SxjXS.png

crowd sample is now ok :D

[Myrsloik]

5.0-RC2 is missing PNG support (images, or PNG in MOV)

FPS returned for short video (1 frame) prores in mov is incorrect (should be 24/1 fps , but results in 12288 fps)
https://www.mediafire.com/file/9kghx7frsant1fe/ff_pr4444.mov/file

Fixed both. Vcpkg stopped compiling ffmpeg with zlib by default.

[hello_hello]

Yep, specifying just FFVideoSource() works, but it's indeed weird. Generally having dups when fpsnum and fpsden are specified only happens when the decoder finds some issues with a certain frame. I'm not really sure why it's getting this result instead... :(

Way back in 2014, I had a clever idea that MeGUI could also encode VFR video correctly if it added fpsnum and fpsden to a script when using FFMS2 as the source filter. Zathor thought it was a good idea too, until eventually we discovered it wasn't. To this day I think MeGUI still adds fpsnum and fpsden to a script for some container formats. I almost feel guilty about it.
Originally the problem seemed limited to AVIs (https://forum.doom9.org/showthread.php?p=1730881#post1730881), but over time I discovered it could happen with any format and even sometimes with VFR video. When it was reported in the FFMS2 thread at the time, the response was underwelming (https://forum.doom9.org/showthread.php?p=1679226#post1679226). Lsmash was, at least at the time, just as likely to suffer from the same problem, dropping frames it shouldn't and duplicating others, but eventually I got used to the idea that if one of them didn't work properly with a particular file the other likely would.

I wonder if it's the same problem finally being fixed, or something new. I enjoyed the trip down memory lane though. :)

[StvG]

... I'd really appreciate if someone runs seek tests on this build...

https://ibb.co/bLzGmXX
https://ibb.co/vZsFK3J

The video files and the previous git version that is tested are from here (https://forum.doom9.org/showthread.php?p=1992736#post1992736).

Also tested @3a5d85c with the rffmode=1 commits - it doesn't fix the issues (related (https://forum.doom9.org/showthread.php?p=1994388#post1994388)). It needs per frame reading of the tff flag. Below is example with the first few hundreds frames marked as tff but after that there are bff:
https://ibb.co/VvNB5W9
https://ibb.co/T8v3Gmf

Edit: also maybe check for the avs+ channel mask should be added to avoid undefined behavior when older avs+ is used (related (https://forum.doom9.org/showthread.php?p=1994891#post1994891)).

[kedautinh12]

I can see from the StvG's test, his ffms still better when can decode Zenit.mkv, ffms2_seeking_issue.mp4, interlaced_h264.mkv, and 3d-parrot.mkv. They still don't add commits from StvG

[Myrsloik]

I have a question about the ffms2_seeking_issue.mp4 sample: Does anyone know exactly how it was generated or where it comes from? Was it remuxed from something else using ffmpeg?

[ChaosKing]

I have a question about the ffms2_seeking_issue.mp4 sample: Does anyone know exactly how it was generated or where it comes from? Was it remuxed from something else using ffmpeg?

I think i remuxed it with ffmpeg from the mkv version.

[Myrsloik]

I think i remuxed it with ffmpeg from the mkv version.

Here's an inconvenient truth for you: FFmpeg is buggy and marks all I-frames as proper seekpoints whe muxing mp4. This means there's an insane number of invalid mp4 files out there with no good workaround (you'd have to parse the whole bitstream or something which is outside the scope of FFMS2). Even FFmpeg itself will seek badly in these files. So if you want a small task try remuxing the mkv=>mp4 files again but this time don't use FFmpeg.

You may be surprised at the outcome.

Meanwhile I'll have a quick peek at interlaced h264 and vc1 do seem to have regressed a bit...

[ChaosKing]

I had a feeling that ffmpeg mp4 was kinda broken. But didn't expect it to be this bad...
What would be a good alternative tool for mp4 files?

[tebasuna51]

I had a feeling that ffmpeg mp4 was kinda broken. But didn't expect it to be this bad...
What would be a good alternative tool for mp4 files?

Answers to this question moved to a new thread MP4 muxers (https://forum.doom9.org/showthread.php?p=1998341#post1998341), because are off topic here.

[StvG]

ffms2 20240306_r1390

ffms2_r2390 (https://codeberg.org/StvG/ffms2/releases/tag/r2390)

Differences compared to 5.0-RC2 (https://github.com/FFMS/ffms2/releases/tag/5.0-RC2):
* In some cases can be seek accurate while `5.0-RC2` is not (for example, https://imgbb.com/bLzGmXX https://imgbb.com/vZsFK3J)
* AviSynth: GetParity and _FieldBased are set per frame
* AviSynth: rffmode=1 that uses every frame tff/bff
* AviSynth: set _EncodedFrameTop and _EncodedFrameBottom (rffmode > 0)
* AviSynth: both ANSI and UTF8 file names are supported
* _ColorRange is set per frame
* Supported older AviSynth+ version that doesn't have audio channel mask property

[kedautinh12]

Nice, thank @StvG

[tebasuna51]

Confused, this new release is r1390, and the previous was r1393

StvG typo, modified to r2390

[Guest]

StvG typo, modified to r2390

Has been rectified (:

Thanks @StvG & @teba

[FranceBB]

Thank you for v5 r2390.
I tested it against the OpenGOP MPEG-2 file and it's working fine now. :)

[Myrsloik]

5.0 RC3 (https://github.com/FFMS/ffms2/releases/tag/5.0-RC3)
Now with FFmpeg that has zlib and some other fun libraries included.

Don't bother reporting any of the listed known issues. They'll probably be resolved before the next release.

[flossy_cake]

ffms2 20240306_r1390

ffms2_r2390 (https://codeberg.org/StvG/ffms2/releases/tag/r2390)

Differences compared to 5.0-RC2 (https://github.com/FFMS/ffms2/releases/tag/5.0-RC2):
* In some cases can be seek accurate while `5.0-RC2` is not (for example, https://imgbb.com/bLzGmXX https://imgbb.com/vZsFK3J)
* AviSynth: GetParity and _FieldBased are set per frame
* AviSynth: rffmode=1 that uses every frame tff/bff
* AviSynth: set _EncodedFrameTop and _EncodedFrameBottom (rffmode > 0)
* AviSynth: both ANSI and UTF8 file names are supported
* _ColorRange is set per frame
* Supported older AviSynth+ version that doesn't have audio channel mask property

:thanks:

(and thanks for remembering to preserve the FFGetVersion() format)

[rgr]

VFR.

I have a question about VFR reading. Will:
ffms2 ("file.mp4")
read *all* frames with the average fps?

I want to make sure I don't have any missed or duplicate ones.

[LigH]

Avisynth supports only one frame rate per clip.

[FranceBB]

Yes and it will output the average FPS, so it will drop scenes with more frames and duplicate scenes with less frames.
Generally what you want to do is specify fpsnum and fpsden and set them to the maximum framerate.
For instance, if file.mp4 was shot on a mobile, has a maximum fps of 60fps (normal motion) and a minimum fps of 10fps (when it was recording static scenes), then:

FFMpegSource2("file.mp4", atrack=-1)

would return a 35fps stream with duplicated frames and dropped frames, which is NOT what you want.
What you want is a 60fps stream so that motion is preserved and whenever frames were lower because there was no motion, they're duplicated, which they would be anyway if you were displaying it on a 60Hz monitor, so:

FFMpegSource2("file.mp4", fpsnum=60000, fpsden=1000, atrack=-1)

[tebasuna51]

FFMpegSource2("file.mp4", attack=-1)
A typo, I suppose, for
FFMpegSource2("file.mp4", atrack=-1)

[rgr]

Yes and it will output the average FPS, so it will drop scenes with more frames and duplicate scenes with less frames.

And that's what I want to avoid. I just want all frames (without duplicating or dropping) like VirtualDub does. So I want to treat VFR as CFR. I'll change the FPS later anyway, and the audio doesn't matter.

[FranceBB]

A typo

yep, fixed. :)

And that's what I want to avoid. I just want all frames (without duplicating or dropping)


You... can't, I'm afraid. You can only output a certain framerate and to obtain that ffms2 will either drop or duplicate.
The best bet is to set fpsnum and fpsden to get the maximum output framerate so that it will never drop frames.
Sure, there will be dups scattered here and there, but that's not a problem.
Why? Simple. It's because it's exactly what you would see if you were to open a VFR video on any other player.
Simply put, if you have a video with VFR that oscillates from 10fps to 60fps as the example I mentioned above and you were to play it on your computer connected to a 60Hz monitor, the player would output 60fps all the time to the monitor (that's excluding FreeSync/GSync monitors which are not that common anyway).


In other words, trust me, just set fpsnum and fpsden to the maximum FPS of the video and you're gonna be fine.
Encoding it as CFR is gonna be fine anyway 'cause x264 is really good at spotting duplicated frames so it will just put a B frame there with a reference to the former frame, thus wasting virtually no bitrate. Besides, if you still wanna re-encode it to VFR instead of CFR post Avisynth, you still can anyway as FFMpeg->libx264 can automatically remove dups and encode it as VFR for you. ;)

[poisondeathray]

If the MP4 is timestamp VFR variety - It does not drop frames if you omit the fpsnum, fpsden options . You only get the encoded frames and average FPS .

If you enter fpsden, fpsnum, it will add duplicates and/or drop frames to achieve the desired CFR

[tebasuna51]

If the MP4 is timestamp VFR variety - It does not drop frames if you omit the fpsnum, fpsden options . You only get the encoded frames and average FPS.

AFAIK now, to preserve the audio sync, you must add the (...,timecodes = "timestamp.txt",... ) in order to mux video/audio with that in a container.

[poisondeathray]

AFAIK now, to preserve the audio sync, you must add the (...,timecodes = "timestamp.txt",... ) in order to mux video/audio with that in a container.

Yes, and that will give you a file similar to the original in terms of VFR timing . You can also extract timestamps with other methods such as ffmpeg, mkvextract (for mkv), mp4fpsmod (for mp4)

One benefit of not using fpsnum, fpsden is you get unique frames - this is beneficial if you were using temporal filtering, or if you were using "slow" filters such as some machine learning - there is no reason to use duplicates

You can add ChangeFPS to add the duplicates frames and make it CFR afterwards . There are also VFR to CFR avs plugins that read the timestamp/timecodes file if you needed CFR

[hello_hello]

And that's what I want to avoid. I just want all frames (without duplicating or dropping) like VirtualDub does. So I want to treat VFR as CFR. I'll change the FPS later anyway, and the audio doesn't matter.

FFMS2 can write the timecodes to a text file while indexing. You can use the TimeCodes argument to specify the name/location of the timecodes file.
The video is decoded at the average frame rate, but if you happen to be encoding with the x264 encoder, you can add the timecodes to the command line and it'll encode in VFR mode.

--tcfile-in "D:\timecodes.txt"

It's been a while since I've encoded anything as VFR, but the first line of the timecodes file should look like this:
# timecode format v2
or this:
# timestamp format v2
I can't remember if x264 accepts both these days, but if the timecodes file isn't recognized, try changing the first line.

[hello_hello]

You can add ChangeFPS to add the duplicates frames and make it CFR afterwards . There are also VFR to CFR avs plugins that read the timestamp/timecodes file if you needed CFR

At the risk of being argumentative, ChangeFPS can't convert VFR to CFR correctly. If you had an imaginary video where the first half was 15fps and the second half was 30fps, the average frame rate would be 25fps. If you used ChangeFPS(30) to convert it to 30fps, the extra frames would be inserted evenly throughout the video, but to keep the A/V sync, the extra frames all need to be inserted in the first half.

[poisondeathray]

At the risk of being argumentative, ChangeFPS can't convert VFR to CFR correctly. If you had an imaginary video where the first half was 15fps and the second half was 30fps, the average frame rate would be 25fps. If you used ChangeFPS(30) to convert it to 30fps, the extra frames would be inserted evenly throughout the video, but to keep the A/V sync, the extra frames all need to be inserted in the first half.

Correct - and that's important to clarify. I only mentioned ChangeFPS because rgr didn't need audio or sync . He could use AssumeFPS without drops or duplicates as well

I also mentioned avs plugins that read the timecodes when converting to CFR, which is better way to do it when you have audio.

https://github.com/Asd-g/TimecodeFPS

https://github.com/jojje/VfrToCfr-the-other-one

[ravewulf]

yep, fixed. :)



You... can't, I'm afraid. You can only output a certain framerate and to obtain that ffms2 will either drop or duplicate.
The best bet is to set fpsnum and fpsden to get the maximum output framerate so that it will never drop frames.
Sure, there will be dups scattered here and there, but that's not a problem.
Why? Simple. It's because it's exactly what you would see if you were to open a VFR video on any other player.
Simply put, if you have a video with VFR that oscillates from 10fps to 60fps as the example I mentioned above and you were to play it on your computer connected to a 60Hz monitor, the player would output 60fps all the time to the monitor (that's excluding FreeSync/GSync monitors which are not that common anyway).


In other words, trust me, just set fpsnum and fpsden to the maximum FPS of the video and you're gonna be fine.
Encoding it as CFR is gonna be fine anyway 'cause x264 is really good at spotting duplicated frames so it will just put a B frame there with a reference to the former frame, thus wasting virtually no bitrate. Besides, if you still wanna re-encode it to VFR instead of CFR post Avisynth, you still can anyway as FFMpeg->libx264 can automatically remove dups and encode it as VFR for you. ;)

Just to make sure this is explicitly corrected:

int fpsnum = -1, int fpsden = 1
Controls the framerate of the output; used for VFR to CFR conversions. If fpsnum is less than or equal to zero (the default), the output will contain the same frames that the input did, and the frame rate reported to Avisynth will be set based on the input clip's average frame duration. If fpsnum is greater than zero, FFVideoSource will force a constant frame rate, expressed as a rational number where fpsnum is the numerator and fpsden is the denominator. This may naturally cause FFVideoSource to drop or duplicate frames to achieve the desired frame rate, and the output is not guaranteed to have the same number of frames that the input did.

https://github.com/FFMS/ffms2/blob/master/doc/ffms2-avisynth.md#int-fpsnum---1-int-fpsden--1

[FranceBB]

Fair enough.

[Myrsloik]

Let me present the successor to FFMS2: BestSource...2!

It has Avs+ and VS support. Guaranteed frame/sample accurate seeking for both audio and video. The seeking is also very fast for almost all files.

https://github.com/vapoursynth/bestsource/releases/tag/R2-RC1

Due to these great advances the future of FFMS2 is quite bleak. There will probably be a final release in a few months and then I'll abandon the project.

[rgr]

But FFMS2 opens video and audio without AudioDub...

[Myrsloik]

But FFMS2 opens video and audio without AudioDub...

Orly?

https://github.com/FFMS/ffms2/blob/master/src/avisynth/avisynth.cpp#L311

[rgr]

Orly?

https://github.com/FFMS/ffms2/blob/master/src/avisynth/avisynth.cpp#L311

Rly! I swear I don't have to write!

[FranceBB]

The question now remains whether StvG will keep going with his builds or not.
Ideally we could end up in a place where:

- FFVideoSource() / FFAudioSource() / FFMpegSource2() is maintained by StvG
- LWLibavVideoSource() / LWLibavAudioSource() / LSMASHVideoSource() / LSMASHAudioSource() is maintained by asd-g
- BSVideoSource() / BSAudioSource() is maintained by Myrsloyk

That on top of the old last resort DirectShowSource() would allow quite some choices for Avisynth users in general.
After all those years, it seems unthinkable to see ffms2 follow NicAudio in the graveyard...

As to BestSource, I'll test it through, but I have so many workflows relying on ffms2 that I'm really skeptical at the moment to migrate.

[Myrsloik]

Rly! I swear I don't have to write!

I've sneakily updated the release so you don't have to write ever again!

[StvG]

The question now remains whether StvG will keep going with his builds or not.

There are recent updates on the upstream. If in the end my fork doesn't bring something additional, I will have no reason to continue with the builds otherwise I will keep the fork alive. At the moment these are the differences (https://forum.doom9.org/showthread.php?p=1998674#post1998674).

[kedautinh12]

You can continue keep it updates cause updates on the upstream don't have x86 version

[rgr]

1. ffms2-5.0-RC3-msvc.7z -- can't open files with national characters (for example "ąćęłńóśż"), reverting to ffms2_r2390.7z fixes the problem.
https://imgur.com/VXSMx5J

2. ffms2_r2390.7z -- cannot read VFR files correctly with ffms2("test-ąćęłńóśżź.mp4",atrack=-1,fpsnum=50), video and audio are desynchronized (about 0,5s after 2-3h). Reverting to ffms2-2.40-msvc.7z unfortunately does not cure the problem. I can send a sample, but only privately, and it has 22GB... I'm trying to find the reason and workaround, but players and VirtualDub play the file correctly. Edit: The VFR issue also affects ffms2-5.0-RC3-msvc.7z

Edit: I tested LWLibavVideoSource. Video and audio are synchronized.

Edit 2: I tried using ffms2("file.mp4",atrack=-1).changeFPS(50) but it doesn't work (there is the same audio delay). The problems lie somewhere deeper in ffms2.

[rgr]

I've sneakily updated the release so you don't have to write ever again!

Super! But I don't see it in the manual :) (Edit: But I see now.)

Edit: However, it would be worth starting a new thread for BS :)

I tried running BestSource:

a=BSVideoSource("test.mp4",fpsnum=50)
b=BSAudioSource("test.mp4")
AudioDub(a,b)

but nothing has happened for several minutes, 50MB/s disk load (4% on SSD) and 23% CPU usage... (MPC).


Edit: After 30(!) minutes, playback started. I guess it takes too long... Unfortunately, the audio delay is the same as in the case of ffms2. Only LWLibavVideoSource can handle this VFR.

[rgr]

I checked all plugins when reading VFR. This is the video offset relative to the correct one (Libav) in ffms2 and Best (it is identical in both).


plugin: frame number:
Libav: 182 631 21846 100294 200945 553462

Best: 182 631 21845 100289 200935 553435
ffms2: 182 631 21845 100289 200935 553435

In VirtualDub, the ffmpeg plugin reads like libav (-1 frame), while the Cache Input Driver plugin reads like ffms2/best.


It looks like ffms2/best completely ignores this parameter.
The video actually deviates only slightly from 50fps, maybe that's the reason?

Frame rate: 50,000 FPS
Minimum frame rate: 42.735 FPS
Maximum frame rate: 60.241 FPS
https://i.imgur.com/ZkLO0ke.png

[Myrsloik]

Super! But I don't see it in the manual :) (Edit: But I see now.)

Edit: However, it would be worth starting a new thread for BS :)

I tried running BestSource:

a=BSVideoSource("test.mp4",fpsnum=50)
b=BSAudioSource("test.mp4")
AudioDub(a,b)

but nothing has happened for several minutes, 50MB/s disk load (4% on SSD) and 23% CPU usage... (MPC).


Edit: After 30(!) minutes, playback started. I guess it takes too long... Unfortunately, the audio delay is the same as in the case of ffms2. Only LWLibavVideoSource can handle this VFR.

THere is a forum thread here: https://forum.doom9.org/showthread.php?t=185408

Eactly what did you open that took 30 minutes? And what did you read it from? I'm curious now

[rgr]

If the MP4 is timestamp VFR variety - It does not drop frames if you omit the fpsnum, fpsden options . You only get the encoded frames and average FPS .

If you enter fpsden, fpsnum, it will add duplicates and/or drop frames to achieve the desired CFR

Thanks -- that's what I meant.

[rgr]

Eactly what did you open that took 30 minutes? And what did you read it from? I'm curious now

Video from HDMI recorder -- 22GB, 4h long, H265.

Opened from .avs file via BSSource. Creating the cache file took so long.

https://i.imgur.com/CCD1KQE.png

[LigH]

Well, there are file formats which are hard to parse, because it requires sequential reading across the whole file, due to the lack of a header which contains a lot of useful information (like a list of GOP start positions) right in the beginning. TransportStreams, as used in Digital Broadcast, are such a case. Raw H.264/H.265 video streams too, they would strictly even require parsing bit by bit, fortunately most are conveniently aligned at least at byte boundaries.

[rgr]

Yes, but ffms2 or Libav do it much faster, so there is room for improvement.

[LigH]

Ah, okay; I guess BestSource needs its own thread then, I did not notice you mean "BS in contrast to FFMS2 and LSW".

[rgr]

So to be in line with the topic, I will write that ffms2 does not want to support long paths -- with 219 characters (including national ones) I get:

[in#0 @ 000002752ddb7a00] Error opening input: Unknown error occurred
Error opening input file testXXX.avs.
Error opening input files: Unknown error occurred

[rgr]

5.0 RC3 (https://github.com/FFMS/ffms2/releases/tag/5.0-RC3)
Now with FFmpeg that has zlib and some other fun libraries included.

Don't bother reporting any of the listed known issues. They'll probably be resolved before the next release.

He does not accept this path. "Unknown error occurred".

D:\_na pena\_klienta247(mDV-exp)\Adaś Komarnicki nad morzem (25.06.2002 14.52).avi

Version 2.40 works ok.
Version ffms2 r2390 - I haven't tested it yet.

[Myrsloik]

5.0 RC4 (https://github.com/FFMS/ffms2/releases/tag/5.0-RC4)

Lots of fixes and probably the final RC because now we're completely out of people who give a shit.

[rgr]

5.0 RC4 (https://github.com/FFMS/ffms2/releases/tag/5.0-RC4)

Lots of fixes and probably the final RC because now we're completely out of people who give a shit.

As in my post above -- RC4 does not want to open files with national characters. This wasn't a problem with long paths, my error.

Now I'm testing VFR file support.

Edit: Yes, there is still a shift of 35 frames with a clip of approximately 4 hours.
1st row - original VFR
2nd row - LWlibavSource
3rd row - ffms2

[FranceBB]

we're completely out of people who give a shit.

One last thing, I can see that you updated the APIs to 6.1.1
Before you give up on ffms2 and move to BestSource, may I ask you to update the APIs one last time to integrate with FFmpeg 7.x so that we're gonna be safe for a while relinking against newer ffmpeg version ourselves coming this new release cycle? :)

[Myrsloik]

You won't be "safe" at all. Every new ffmpeg version usually requires new workarounds or that an old hack is removed. 5.0 is tested with ffmpeg 6.1.x and that's how it is.

[Daemon404]

FWIW, I will still be around to maintain FFMS2, as I have been for ~10 years now, even if/when Myrsloik has moved on to BestSource.

(It was no easy feat to log in here... You last visited: 18th August 2019 at 19:09).

[pandv2]

FWIW, I will still be around to maintain FFMS2, as I have been for ~10 years now, even if/when Myrsloik has moved on to BestSource.


Thanks, the alternatives are not well suited for my project.

[FranceBB]

Hey StvG,
I have two files exported from AVID after the editor edited a LiveU internet stream (i.e the initial quality was poor).
They're XDCAM-50, which means FULL HD MPEG-2 High Profile Main Level 4:2:2 yv16 25i TFF BT709 SDR.
The audio is CH.1 Left Italian CH.2 Right Italian carried as discrete mono PCM 24bit 48000Hz.
The container is an mxf.

So far so good, I've seen plenty of similar files, however what I'm wondering is why ffms2 seems to be populating the frame properties with some bogus values in terms of matrix, primaries and transfer.

Those are the two files:

Sample 1: https://wetransfer.com/downloads/0c94e12942d0a0a3d9c17bf7c1d3acd420240704122313/272718
Sample 2: https://we.tl/t-AJU0XLq86w

When I index them with:

video=FFVideoSource("A:\MEDIA\temp\FL RUGBY.mxf")
ch1=FFAudioSource("A:\MEDIA\temp\FL RUGBY.mxf", track=1)
ch2=FFAudioSource("A:\MEDIA\temp\FL RUGBY.mxf", track=2)
audio=MergeChannels(ch1, ch2)
AudioDub(video, audio)

I get the following frame properties:

https://i.imgur.com/FEPt19z.png

As you can see, Matrix, Primaries and Transfer are set to 3 which is a bogus value, while I expected them to be set to 1 as they're BT709.


If I do something like:

video=FFVideoSource("A:\MEDIA\temp\FL RUGBY.mxf")
ch1=FFAudioSource("A:\MEDIA\temp\FL RUGBY.mxf", track=1)
ch2=FFAudioSource("A:\MEDIA\temp\FL RUGBY.mxf", track=2)
audio=MergeChannels(ch1, ch2)
AudioDub(video, audio)

AssumeTFF()
Bob()

ConverttoRGB24()

it errors out with "Unknown matrix" 'cause it doesn't recognize the value 3, so either I nuke frame properties like:

video=FFVideoSource("A:\MEDIA\temp\FL RUGBY.mxf")
ch1=FFAudioSource("A:\MEDIA\temp\FL RUGBY.mxf", track=1)
ch2=FFAudioSource("A:\MEDIA\temp\FL RUGBY.mxf", track=2)
audio=MergeChannels(ch1, ch2)
AudioDub(video, audio)

propclearall()

AssumeTFF()
Bob()

ConverttoRGB24()

or I manually specify the values like so:

video=FFVideoSource("A:\MEDIA\temp\FL RUGBY.mxf")
ch1=FFAudioSource("A:\MEDIA\temp\FL RUGBY.mxf", track=1)
ch2=FFAudioSource("A:\MEDIA\temp\FL RUGBY.mxf", track=2)
audio=MergeChannels(ch1, ch2)
AudioDub(video, audio)

propSet("_Matrix", 1) #BT709
propSet("_Transfer", 1) #BT709
propSet("_Primaries", 1) #BT709

AssumeTFF()
Bob()

ConverttoRGB24()

and of course I could always just manually populate ConverttoRGB24(matrix="Rec709") like so:


video=FFVideoSource("A:\MEDIA\temp\FL RUGBY.mxf")
ch1=FFAudioSource("A:\MEDIA\temp\FL RUGBY.mxf", track=1)
ch2=FFAudioSource("A:\MEDIA\temp\FL RUGBY.mxf", track=2)
audio=MergeChannels(ch1, ch2)
AudioDub(video, audio)

AssumeTFF()
Bob()

ConverttoRGB24(matrix="Rec709")


In other words, as long as I'm encoding things manually, that's not really an issue, but the problem is that those are part of an automated workflow, so they keep failing and I *have to* encode them manually all the time.

https://i.imgur.com/ysongyR.png


If I perform a mediainfo on the file, matrix, transfer and primaries are correctly identified as BT709, so I wonder why ffms2 is marking them as 3 rather than 1 in the frame properties...


General
Complete name : A:\MEDIA\temp\FL RUGBY.mxf
Format : MXF
Commercial name : XDCAM HD422
Format version : 1.3
Format profile : OP-1a
Format settings : Closed / Complete
File size : 1.02 GiB
Duration : 2 min 46 s
Overall bit rate : 52.7 Mb/s
Frame rate : 25.000 FPS
Package name : Source Package
Encoded date : 2024-07-08 08:21:58.088
Writing application : Avid Technology, Inc. Avid MediaProcessor Plug-In 1.0.60.10070.1
Writing library : MXF::SDK (4.7.14) on Win64 4.7.14.10177.1

Video
ID : 512
Format : MPEG Video
Commercial name : XDCAM HD422
Format version : Version 2
Format profile : 4:2:2@High
Format settings : BVOP
Format settings, BVOP : Yes
Format settings, Matrix : Default
Format settings, GOP : Variable
Format settings, picture structure : Frame
Format settings, wrapping mode : Frame
Codec ID : 0D01030102046001-0401020201040300
Duration : 2 min 46 s
Bit rate mode : Constant
Bit rate : 50.0 Mb/s
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate : 25.000 FPS
Color space : YUV
Chroma subsampling : 4:2:2
Bit depth : 8 bits
Scan type : Interlaced
Scan order : Top Field First
Compression mode : Lossy
Bits/(Pixel*Frame) : 0.965
Time code of first frame : 00:00:00:00
Time code source : Group of pictures header
GOP, Open/Closed : Open
Stream size : 994 MiB (95%)
Color range : Limited
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709

Audio #1
ID : 768
Format : PCM
Format settings : Little
Format settings, wrapping mode : Frame (AES)
Codec ID : 0D01030102060300-0402020101000000
Duration : 2 min 46 s
Bit rate mode : Constant
Bit rate : 1 152 kb/s
Channel(s) : 1 channel
Sampling rate : 48.0 kHz
Frame rate : 25.000 FPS (1920 SPF)
Bit depth : 24 bits
Stream size : 22.9 MiB (2%)
Locked : Yes

Audio #2
ID : 1024
Format : PCM
Format settings : Little
Format settings, wrapping mode : Frame (AES)
Codec ID : 0D01030102060300-0402020101000000
Duration : 2 min 46 s
Bit rate mode : Constant
Bit rate : 1 152 kb/s
Channel(s) : 1 channel
Sampling rate : 48.0 kHz
Frame rate : 25.000 FPS (1920 SPF)
Bit depth : 24 bits
Stream size : 22.9 MiB (2%)
Locked : Yes

Other #1
ID : 1-Material
Type : Time code
Format : MXF TC
Frame rate : 25.000 FPS
Time code of first frame : 10:00:00:00
Time code of last frame : 10:02:46:17
Time code settings : Material Package
Time code, stripped : Yes
Title : Timecode

Other #2
ID : 0-Source
Type : Time code
Format : MXF TC
Frame rate : 25.000 FPS
Time code of first frame : 10:00:00:00
Time code of last frame : 10:02:46:17
Time code settings : Source Package
Time code, stripped : Yes

Other #3
Type : Time code
Format : SMPTE TC
Muxing mode : SDTI
Frame rate : 25.000 FPS
Time code of first frame : 10:00:00:00

[StvG]

ffprobe -show_frames "FL RUGBY.mxf" > log.txt shows that these frame properties have value "reserved" - https://i.ibb.co/C8Hvz6P/Untitled1.png

[FranceBB]

Ah... Gotcha.
So it is an ill created file after all!
At this point I'm not even sure where Mediainfo is getting BT709 from eheheheh.

[Emulgator]

Could it be that there was guesswork implemented like width<720 -> 601, width>=720-> 709 ?
Zenitram (Martinez from Mediainfo) should know.

[isidroco]

Tried both ffms2-5.0-RC4-msvc and final ffms2-5.0-msvc, can't get audio working:
When using FFAudioSource or ffms2( X, atrack=-1 ) I get: "System Exception - Access Violation"
Tried small videos: .MOV (with wav PCM) .MP4 (with AAC) and .MKV (with Flac), all fails in the same way.
Works fine with ffms2_r1369 or other older versions.
Tested both in W10 20h2 x64 and Win7 x64, with Avysynth+ v3.7.2 r3661 with same results.

[rgr]

Tried both ffms2-5.0-RC4-msvc and final ffms2-5.0-msvc, can't get audio working:
When using FFAudioSource or ffms2( X, atrack=-1 ) I get: "System Exception - Access Violation"
Tried small videos: .MOV (with wav PCM) .MP4 (with AAC) and .MKV (with Flac), all fails in the same way.
Works fine with ffms2_r1369 or other older versions.
Tested both in W10 20h2 x64 and Win7 x64, with Avysynth+ v3.7.2 r3661 with same results.

I use ffms2_r2390.7z. It doesn't work very well with VFR, but there are no other problems. Your versions don't work for me either, but for different reasons.

[isidroco]

I use ffms2_r2390.7z. It doesn't work very well with VFR, but there are no other problems. Your versions don't work for me either, but for different reasons.

Thanks, worked great. I don't use VFR, most processing from my camera, and some digitilazations from analog sources (all fixed frame rate).

[Tima]

My results:
https://i.imgur.com/S2Y6JY3.png

Could you please run your seeking test suite against FFMS2 v5.0 and share the results?

[ChaosKing]

My results for ffms2 5.0
https://i.imgur.com/6Fj6o3d.png

[rgr]

What does it mean?
"Fixed all issues with FFmpeg 6.1 which is now the minimum requirement"

Can I load the avs file into "ffmpeg version 2024-02-26-git-a3ca4beeaa-full_build-www.gyan.dev Copyright (c) 2000-2024 the FFmpeg developers built with gcc 12.2.0 (Rev10, Built by MSYS2 project)" ?

[LigH]

FFmpegSource contains an own core of FFmpeg (libavcodec, libavformat) to be able to read different source media formats into AviSynth. It does not matter where you load that AviSynth script into.

Version 6.1 of FFmpeg is the minimum requirement for FFmpeg sources to build the FFmpegSource AviSynth plugin with. If you don't compile it, it doesn't matter to you.

[wonkey_monkey]

Is there any way (for me, as a user) to speed up FFmpegSource audio seeking?

I'm opening some blu-ray rips (my own) with multiple DTS-MA/DTS tracks and I'm getting significant pauses, sometimes of several seconds, when jumping around in the video and hitting play in VirtuaDub2. It seems to be due to audio, because if I open the files without audio, or remove the audio track in Avisynth, the pauses disappear.

LSmashSource2 failed to open it; LibavSource2 worked and doesn't have any pauses. I've always used FFmpegSource up until now though, and it's quite a bit quicker to load initially.

[Myrsloik]

Is there any way (for me, as a user) to speed up FFmpegSource audio seeking?

I'm opening some blu-ray rips (my own) with multiple DTS-MA/DTS tracks and I'm getting significant pauses, sometimes of several seconds, when jumping around in the video and hitting play in VirtuaDub2. It seems to be due to audio, because if I open the files without audio, or remove the audio track in Avisynth, the pauses disappear.

LSmashSource2 failed to open it; LibavSource2 worked and doesn't have any pauses. I've always used FFmpegSource up until now though, and it's quite a bit quicker to load initially.

Not without extra steps, no. You can reencode the audio to flac and use either ffms2 or bestsource which will be fast.

But why are you even using this for latency sensitive previewing?

[wonkey_monkey]

But why are you even using this for latency sensitive previewing?

You make it sound like it's an unreasonable thing to do. It's not; LibavSource2 manages it just fine. I just thought there might be a way FFmpegSource could match it.

Edit: I don't think FFmpegSource is indexing audio properly in MKV files.

[pintcat]

I'd also love to see a 32bit version of this plugin since I'm forced to use a couple older programs which do support AVISynth, but are only availabe as 32bit/x86 making me stick to the older v2.40 of FFMS2.

[rgr]

FFMS2 (last version) can't open a file when the AviSynth script is encoded in e.g. CP-1250, not UTF.
The old version of FFMS2 (2390), LWLibavVideoSource and BestSource don't have this problem (but the latter has been indexing my file for a few minutes and there's no end in sight - but at least it works).

https://gcdnb.pbrd.co/images/36YfWpReI8mx.png?o=1

[StvG]

I don't know what you're referring by "newer version than r2390" but there is no newer version than r2390. The plugin from github and this from codeberg are different so they shouldn't be treated as just "older / newer".

[tebasuna51]

Of course are different versions, but your r2390 (https://codeberg.org/StvG/ffms2/releases/tag/r2390) is older (2020) than 5.0 (https://github.com/FFMS/ffms2/releases/tag/5.0) (2024) from Myrsloik.

The question is this file:
LoadPlugin("C:\Test\StvG\ffms2.dll")
FFVideoSource("C:\Ñu.mkv")
saved like ANSI or UTF8 (without BOM) work fine.

But using C:\Test\5.0\ffms2.dll only work saved as UTF8 (without BOM).
There are other differences (see the links and the ChaosKing tests #2617 and #2941) and select your preference.

[rgr]

I don't really have a choice, as I haven't found a version other than 2390 that works properly with ANSI.

[StvG]

Of course are different versions, but your r2390 (https://codeberg.org/StvG/ffms2/releases/tag/r2390) is older (2020) than 5.0 (https://github.com/FFMS/ffms2/releases/tag/5.0) (2024) from Myrsloik.

The question is this file:

saved like ANSI or UTF8 (without BOM) work fine.

But using C:\Test\5.0\ffms2.dll only work saved as UTF8 (without BOM).
There are other differences (see the links and the ChaosKing tests #2617 and #2941) and select your preference.

r2390 is not from 2020 - it's from 2024-03-06 (https://codeberg.org/StvG/ffms2/releases/tag/r2390).

The official ffms2 doesn't handle ANSI and will not handle it until there is change in its code. If you don't see changes in the changelog about it don't expect to magically work.

[tebasuna51]

r2390 is not from 2020 - it's from 2024-03-06 (https://codeberg.org/StvG/ffms2/releases/tag/r2390).

You are right I mistake the folder date (2022-04 image 1) with the file date (2024-03 image 2) but still the 5.0 is newer (2024-05 image 3).

BTW the preference must be by other differences, not by not support ANSI avs files when there are free tools (notepad++ (https://notepad-plus-plus.org/downloads/)) to easy change ANSI <-> UTF8 codification.

I don't know how rgr make the avs files but some tools (like MeGUI) make avs with UTF8 already.

[tebasuna51]

I don't know if is still valid the differences here:

ffms2 r2390 [StvG] StvG publicó esto 2024-03-06 06:18:34 +00:00
Differences compared to 5.0-RC2:
1 In some cases can be seek accurate while 5.0-RC2 is not
2 AviSynth: GetParity and _FieldBased are set per frame
3 AviSynth: rffmode=1 that uses every frame tff/bff
4 AviSynth: set _EncodedFrameTop and _EncodedFrameBottom (rffmode > 0)
5 AviSynth: both ANSI and UTF8 file names are supported
6 _ColorRange is set per frame
7 Supported older AviSynth+ version that doesn't have audio channel mask property
Some comments:
2 and 6) I don't know when is needed GetParity, _FieldBased and _ColorRange set per frame

7) Use Avs+ older than 3.7.3 it is not recommended at all.

5) Problem already commented

3 and 4) rffmode removed in 5.0. To evaluate the impact read the help in RC 4:
##### int rffmode = 0
Controls how RFF flags in the video stream are treated; in other words it's equivalent to the "field operation" mode switch in DVD2AVI/DGIndex.
Valid modes are:

- **0**: Ignore all flags (the default mode).
- **1**: Honor all pulldown flags.
- **2**: Equivalent to DVD2AVI's "force film" mode.

Note that using modes 1 or 2 will make `FFVideoSource` throw an error if the video stream has no RFF flags at all.
When using either of those modes, it will also make the output be assumed as CFR, disallow vertical scaling and disallow setting the output colorspace.
`FFPICT_TYPE` will also not be set as the output is a combination of several frames.
Other subtle behavior changes may also exist.

Also note that "force film" is mostly useless and only here for completeness' sake, since if your source really is safe to force film on, using mode 0 will have the exact same effect while being considerably more efficient.

1) About the seek accurate we have the ChaosKing test (image). Seems we need set seekmode = 0 (slow seek) for mpeg2.VOB (standard DVD), mpeg1.mpg and VC1.mpg. The default seems valid for other files.
The help about this parameter can be interesting:
##### int seekmode = 1
Controls how seeking is done. Mostly useful for getting uncooperative files to work.
Valid modes are:

- **-1**: Linear access without rewind; i.e. will throw an error if each successive requested frame number isn't bigger than the last one.
Only intended for opening images but might work on well with some obscure video format.
- **0**: Linear access (i.e. if you request frame `n` without having requested all frames from 0 to `n-1` in order first, all frames from 0 to `n` will have to be decoded before `n` can be delivered).
The definition of slow, but should make some formats "usable".
- **1**: Safe normal. Bases seeking decisions on the keyframe positions reported by libavformat.
- **2**: Unsafe normal. Same as mode 1, but no error will be thrown if the exact seek destination has to be guessed.
- **3**: Aggressive. Seeks in the forward direction even if no closer keyframe is known to exist. Only useful for testing and containers where libavformat doesn't report keyframes properly.

[StvG]

I don't know if is still valid the differences here:

ffms2 r2390 [StvG] StvG publicó esto 2024-03-06 06:18:34 +00:00
Differences compared to 5.0-RC2:
1 In some cases can be seek accurate while 5.0-RC2 is not
2 AviSynth: GetParity and _FieldBased are set per frame
3 AviSynth: rffmode=1 that uses every frame tff/bff
4 AviSynth: set _EncodedFrameTop and _EncodedFrameBottom (rffmode > 0)
5 AviSynth: both ANSI and UTF8 file names are supported
6 _ColorRange is set per frame
7 Supported older AviSynth+ version that doesn't have audio channel mask property

Some comments:
2 and 6) I don't know when is needed GetParity, _FieldBased and _ColorRange set per frame

7) Use Avs+ older than 3.7.3 it is not recommended at all.

5) Problem already commented

3 and 4) rffmode removed in 5.0. To evaluate the impact read the help in RC 4:

2, 3, 4 - discussed (https://forum.doom9.org/showpost.php?p=1994388&postcount=2820), discussed (https://forum.doom9.org/showpost.php?p=1994660&postcount=2827) and next posts.

7 - keep in mind the official ffms2 will just crash instead to give error message.

The latest official ffms2 5.0 (2024-05-28) have changes that significantly impact the decoding (https://github.com/FFMS/ffms2/pull/437). This is the main reason that I wrote that both variants shouldn't be considered as just newer/older.

[rgr]

I don't know if is still valid the differences here:


Some comments:
2 and 6) I don't know when is needed GetParity, _FieldBased and _ColorRange set per frame

7) Use Avs+ older than 3.7.3 it is not recommended at all.

5) Problem already commented

3 and 4) rffmode removed in 5.0. To evaluate the impact read the help in RC 4:


1) About the seek accurate we have the ChaosKing test (image). Seems we need set seekmode = 0 (slow seek) for mpeg2.VOB (standard DVD), mpeg1.mpg and VC1.mpg. The default seems valid for other files.
The help about this parameter can be interesting:

Other:
- 2390 does not set PAR for each frame separately (but rather sets it, but from the stream property, not from the frame property)
- 2390 for AVI files (captured from a DV camera) recognizes incorrect fps (50.32 or 49.68 or similar instead of 50)
- 2390 does not handle VFR correctly, but I don't think any ffms2 does

[StvG]

Other:
- 2390 does not set PAR for each frame separately (but rather sets it, but from the stream property, not from the frame property)
- 2390 for AVI files (captured from a DV camera) recognizes incorrect fps (50.32 or 49.68 or similar instead of 50)
- 2390 does not handle VFR correctly, but I don't think any ffms2 does

Can you elaborate?

- PAR: can you show example of what you mean?
- AVI fps: it looks like rounding errors. Can you share short video sample with this issue?

[rgr]

- PAR
When I read an AVI file from a DV camera that is partly recorded in 4:3 and partly in 16:9, the 2390 version returns the same PAR for each frame. LWLibavVideoSource changes the PAR to the correct one for each frame, MPC also changes the aspect ratio from where the PAR changes.

- AVI (M2TS)
My mistake -- it's an M2T file. I'll give the link privately, because ffms2 has bigger problems with it anyway :)

- VFR
https://files.fm/u/cemhy7vrmx (upload in progress... 6 files)

[StvG]

The tebasuna51 comment you quoted is about the differences between the ffms2 version not between ffms2 and LSMASHSource/other source filter.
To be clear - the differences you wrote are between ffms2 and LSMASHSource not between the ffms2 versions.

Thanks for the samples.
You can test this version (https://files.catbox.moe/n7x0o5.zip). It sets _SARxxx frames props per frame and uses more robust fps calculation.

Edit: The file you shared (M2T one) is damaged (has video corrupted packages) - https://i.ibb.co/TxCGxwTR/Untitled.png

[FranceBB]

Hey StvG, thank you for picking up ffms2 and maintaining it while Myrsloyk was away, I think everyone here appreciates what you've done during this time.
To me and plenty others your builds are now the de facto standard and main branch of ffms2. :)
After talking to asd-g, he introduced a new parameter in LWLibavAudioSource() which I think FFAudioSource() would also greatly benefit from.
Such a parameter is a boolean called "fill_audio_gaps" which can be set to either true or false.
What it does is basically read the PTS while indexing and - if there's a gap in the audio track - it fills it with silence so that the audio stays synced with the video and ends up having the same duration instead of being shortened (and therefore desynced) from the point of the gap onwards.
Here's the commit: https://github.com/HomeOfAviSynthPlusEvolution/L-SMASH-Works/commit/7dc8ba9295aafa5e99a59903cdd62c4fffc512a5
I tested it and it seems to be working reliably well and it could help in plenty of occasions, especially with .ts and .mxf containers in which CRC Errors are very common as there might be plenty of issues with incoming signals that are recorded, so my question is: would you be interested in adding a similar parameter/feature in FFAudioSource()?

[StvG]

There is "fill_gaps" parameter (int) that was broken the last time I tested it.

[wonkey_monkey]

How easy would it be for an external program to read an .ffindex file to inform itself which frames are keyframes?

[LigH]

Not so trivial. In the sources (ffms2-git\src\core\indexing.cpp) I read that it is single-file zipped (like in UNIX zip .z or GNU zip .gz or .xz or similar, not PKZIP, I believe, see: ffms2-git\src\core\zipfile.cpp).

If I am not wrong, L-SMASH Source does not compress the index.

[FranceBB]

If I am not wrong, L-SMASH Source does not compress the index.

Correct, unlike the .ffindex files produced by FFVideoSource() and FFAudioSource(), the .lwi created by LWLibavVideoSource() and LWLibavAudioSource() is not compressed, it's human readable and it has an XML based structure.
Truncated example for reference:


<LSMASHWorksIndexVersion=0.0.3.0>
<LibavReaderIndexFile=18>
<InputFilePath>A:\Ingest\MEDIA\temp\HNK02043_MO.mxf</InputFilePath>
<FileSize=110707651>
<FileLastModificationTime=1739477225>
<FileHash=0x7f12b33eb742a48e>
<LibavReaderIndex=0x04000000,0,mxf>
<ActiveVideoStreamIndex>+0000000000</ActiveVideoStreamIndex>
<ActiveAudioStreamIndex>+0000000004</ActiveAudioStreamIndex>
<DefaultAudioStreamIndex>-0000000001</DefaultAudioStreamIndex>
<FillAudioGaps>1</FillAudioGaps>
<StreamInfo=0,0>
Codec=2,TimeBase=1/25,Width=1920,Height=1080,Format=yuv422p,ColorSpace=2
</StreamInfo>
<StreamInfo=1,1>
Codec=65548,TimeBase=1/48000,Channels=2:0x3,Rate=48000,Format=s32,BPS=24
</StreamInfo>
<StreamInfo=2,1>
Codec=65548,TimeBase=1/48000,Channels=2:0x3,Rate=48000,Format=s32,BPS=24
</StreamInfo>
<StreamInfo=3,1>
Codec=65548,TimeBase=1/48000,Channels=2:0x3,Rate=48000,Format=s32,BPS=24
</StreamInfo>
<StreamInfo=4,1>
Codec=65548,TimeBase=1/48000,Channels=2:0x3,Rate=48000,Format=s32,BPS=24
</StreamInfo>
Index=1,POS=182043,PTS=0,DTS=0,EDI=0
Length=1920
Index=2,POS=193583,PTS=0,DTS=0,EDI=0
Length=1920
Index=3,POS=205123,PTS=0,DTS=0,EDI=0
Length=1920
Index=4,POS=216663,PTS=0,DTS=0,EDI=0
Length=1920
Index=0,POS=228203,PTS=0,DTS=-1,EDI=0
Key=1,Pic=1,POC=0,Repeat=1,Field=1
Index=1,POS=419285,PTS=1920,DTS=1920,EDI=0
Length=1920
Index=2,POS=430825,PTS=1920,DTS=1920,EDI=0
Length=1920
Index=3,POS=442365,PTS=1920,DTS=1920,EDI=0
Length=1920
Index=4,POS=453905,PTS=1920,DTS=1920,EDI=0
Length=1920
Index=0,POS=465445,PTS=3,DTS=0,EDI=0
Key=0,Pic=2,POC=3,Repeat=1,Field=1
Index=1,POS=885093,PTS=3840,DTS=3840,EDI=0
Length=1920
Index=2,POS=896633,PTS=3840,DTS=3840,EDI=0
Length=1920
Index=3,POS=908173,PTS=3840,DTS=3840,EDI=0
Length=1920
Index=4,POS=919713,PTS=3840,DTS=3840,EDI=0
Length=1920
Index=0,POS=931253,PTS=1,DTS=1,EDI=0
Key=0,Pic=3,POC=1,Repeat=1,Field=1
Index=1,POS=1025687,PTS=5760,DTS=5760,EDI=0
Length=1920
Index=2,POS=1037227,PTS=5760,DTS=5760,EDI=0
Length=1920
Index=3,POS=1048767,PTS=5760,DTS=5760,EDI=0
Length=1920
Index=4,POS=1060307,PTS=5760,DTS=5760,EDI=0
Length=1920
Index=0,POS=1071847,PTS=2,DTS=2,EDI=0
Key=0,Pic=3,POC=2,Repeat=1,Field=1
Index=1,POS=1422586,PTS=7680,DTS=7680,EDI=0
Length=1920
Index=2,POS=1434126,PTS=7680,DTS=7680,EDI=0
Length=1920
Index=3,POS=1445666,PTS=7680,DTS=7680,EDI=0
Length=1920
Index=4,POS=1457206,PTS=7680,DTS=7680,EDI=0
Length=1920
Index=0,POS=1468746,PTS=6,DTS=3,EDI=0
Key=0,Pic=2,POC=6,Repeat=1,Field=1
Index=1,POS=1859511,PTS=9600,DTS=9600,EDI=0
Length=1920
Index=2,POS=1871051,PTS=9600,DTS=9600,EDI=0
Length=1920
Index=3,POS=1882591,PTS=9600,DTS=9600,EDI=0
Length=1920
Index=4,POS=1894131,PTS=9600,DTS=9600,EDI=0
Length=1920
Index=0,POS=1905671,PTS=4,DTS=4,EDI=0
Key=0,Pic=3,POC=4,Repeat=1,Field=1
Index=1,POS=2281430,PTS=11520,DTS=11520,EDI=0
Length=1920
Index=2,POS=2292970,PTS=11520,DTS=11520,EDI=0
Length=1920
Index=3,POS=2304510,PTS=11520,DTS=11520,EDI=0
Length=1920
Index=4,POS=2316050,PTS=11520,DTS=11520,EDI=0
Length=1920
Index=0,POS=2327590,PTS=5,DTS=5,EDI=0
Key=0,Pic=3,POC=5,Repeat=1,Field=1
Index=1,POS=2704255,PTS=13440,DTS=13440,EDI=0
Length=1920
Index=2,POS=2715795,PTS=13440,DTS=13440,EDI=0
Length=1920

[wonkey_monkey]

Not so trivial. In the sources (ffms2-git\src\core\indexing.cpp) I read that it is single-file zipped (like in UNIX zip .z or GNU zip .gz or .xz or similar, not PKZIP, I believe, see: ffms2-git\src\core\zipfile.cpp).

Ah, zlib, my old nemesis (I tried to get it to work once but it's... less than simple).

Luckily I've found a nice modernised stream buffer wrapper (zstr) for zlib, although it did need a tweak to allow to read "fast compressed" zlib as used by FFMS2 (the author was guided by a Stack Overflow post that omitted that kind of header).

[Edit: zstr doesn't seem to work properly with ffindex files, bugging out after ~2500 bytes]

Hopefully indexing.cpp can guide me through parsing an index.

Thanks!

[qyot27]

How easy would it be for an external program to read an .ffindex file to inform itself which frames are keyframes?
If you're controlling the generation of the .ffindex in the first place through a host application, I would think it easier to just make sure you pass -k to ffmsindex:
FFmpegSource2 indexing app
Usage: ffmsindex [options] inputfile [outputfile]
If no output filename is specified, inputfile.ffindex will be used.

Options:
-f Force overwriting of existing index file, if any (default: no)
-v Set FFmpeg verbosity level. Can be repeated for more verbosity. (default: no messages printed)
-p Disable progress reporting. (default: progress reporting on)
-c Write timecodes for all video tracks to outputfile_track00.tc.txt (default: no)
-k Write keyframes for all video tracks to outputfile_track00.kf.txt (default: no)
-t N Set the audio indexing mask to N (-1 means index all tracks, 0 means index none, default: 0)
-s N Set audio decoding error handling. See the documentation for details. (default: 0)
-u N Set the progress update frequency in seconds. Set to 0 for every percent. (default: 1)
-o string Set demuxer options to be used in the form of 'key=val:key=val'. (default: none)

FFmpeg Demuxer Options:
--enable_drefs
--use_absolute_path

Obviously that's not quite the same as reading it from an existing .ffindex, but if the mechanism is already there in some form...

[wonkey_monkey]

I've managed to get this far decoding the video track in the index (values are little endian):

PTS OriginalPTS Keyframe FilePos MarkedHidden OriginalPos PosInDecodingOrder RepeatPict SecondField
80|02|00|00|00|00|00|00 80|02|00|00|00|00|00|00 01 4c|01|00|00|00|00|00|00 00 ff|ff|ff|ff|ff|ff|ff|ff ff|ff|ff|ff|ff|ff|ff|ff 01|00|00|00 00
80|02|00|00|00|00|00|00 80|02|00|00|00|00|00|00 01 bc|4e|00|00|00|00|00|00 00 00|00|00|00|00|00|00|00 00|00|00|00|00|00|00|00 01|00|00|00 00
80|02|00|00|00|00|00|00 80|02|00|00|00|00|00|00 00 9e|4e|00|00|00|00|00|00 00 00|00|00|00|00|00|00|00 00|00|00|00|00|00|00|00 01|00|00|00 00
80|02|00|00|00|00|00|00 80|02|00|00|00|00|00|00 00 bb|30|00|00|00|00|00|00 00 00|00|00|00|00|00|00|00 00|00|00|00|00|00|00|00 01|00|00|00 00


This seems to indicate that the first two frames are keyframes, but from opening the file directly in VirtualDub I know that keyframes are at frame 0, 25, 50, 75... every 25 frames (presumably maximum GOP length, as later in the index I can see several examples of keyframes separated by 25 frames) until the first out-of-pattern keyframe at frame 557.

So the frames VirtualDub reports as keyframes do all seem to be marked as keyframes in the index, but so are many other apparently non-keyframe frames :confused: E.g. frame 1 (shown above), 4, 7, 11, in fact every third frame up to frame 28. Then there are a few more spurious keyframes before it settles at around frame 50 and matches the video - until frame 540, which is reported as a keyframe in the index but not by VirtualDub.

Not sure what FilePos could mean either, since its value never goes very high (only up to about 300,000) compared to the filesize of 14Gb.

The other fields never seem to change - PTS and OriginalPTS obviously relate to the constant framerate - except for the -1s for OriginalPos and PosInDecodingOrder on frame 0.

Anyone got any idea what I'm missing with regard to keyframes?

[StvG]

...
Hopefully indexing.cpp can guide me through parsing an index.
...

You should look at track.cpp for parsing .ffindex. An example (https://github.com/FFMS/ffms2/blob/master/src/core/track.cpp#L38-L56).

[wonkey_monkey]

I used track.cpp to determine what those fields delimited above are.

Could there be such a thing as a de facto keyframe? I.e. a frame labelled as P or B but which doesn't actually depend on the content of any other frames? If so, maybe ffmpeg is identifying them as keyframes.

[StvG]

P and B frame never can be keyframe.
Key frames are only I type.

The frame info in .ffindex is pretty much the same as what ffmpeg/ffprobe output. You can just do ffprobe -show_frames -select_streams 0 -i input.video | findstr "key_frame pict_type" > frame_info.txt


key_frame=1
pict_type=I
key_frame=0
pict_type=B
key_frame=0
pict_type=B
key_frame=0
pict_type=B
key_frame=0
pict_type=P

[wonkey_monkey]

Ah, now I get it: https://forum.doom9.net/showthread.php?p=1834568

VirtualDub differentiates between IDR frames [K] and regular I-frames [I]. Ideally I need to know which are IDR frames, but that doesn't seem to be specified in the ffindex. I can probably work with that, it just won't be quite as effective.

[StvG]

https://github.com/FFMS/ffms2/blob/master/src/core/indexing.cpp#L531
Here is stored in ffindex https://github.com/FFMS/ffms2/blob/master/src/core/indexing.cpp#L567

[Myrsloik]

I don't know why you need to know keyframes but beware, FFmpeg has a lot of bugs. For example the huffyuv decoder reports no keyframes (lol) and while the keyframe flag should only be set for IDR-frames in h264 due to bugs in FFmpeg it will happily mark I-frames as "keyframes" in remuxed files.

Lots of fun bugs and corner cases even in common containers and formats.

[wonkey_monkey]

I don't know why you need to know keyframes

A cache so I can step backward without it stuttering on every frame (now it only stutters when it moves into the previous GOP)/to make edits and dissolves faster. Works pretty well.

[wonkey_monkey]

...and then I found out ffms2 isn't frame accurate with h264 in .mp4 :eek: Back to the drawing board...

[Myrsloik]

...and then I found out ffms2 isn't frame accurate with h264 in .mp4 :eek: Back to the drawing board...

May I interest you in our lord and savior BestSource?

[wonkey_monkey]

May I interest you in our lord and savior BestSource?

Right now, if there's a finished and working Windows build (for Avisynth+), then sure. If I have to compile it myself, I'm still too traumatised from LSMASHSource.

Edit: Oh there is. Good. Testing now.

More edit: Does over ten minutes (still waiting) to open a one hour 14Gb .mp4 sound right to you? :confused:

Yet another edit: 30 mins total indexing time. It's going to take two solid days to index my sources :D:eek:

More info: Once first load finished in VirtualDub, all the audio channels were present, but they were all silent. Opening the same .avs file in a new VirtuaDub window, the audio was all present, but the framerate was incorrectly determined to be 25.764fps instead of 25fps (same as with original load). SeekTester confirms frame accuracy, so that's nice. But that indexing speed is a killer (but worth it for the frame-accuracy guarantee).

[StvG]

ffms2 r2395 (https://codeberg.org/StvG/ffms2/releases)
Diff from the original version (https://codeberg.org/StvG/ffms2/src/branch/doom9/doc/ffms2-changelog.md#differences-from-the-original-version)

@FranceBB, you can try now fill_gaps (https://codeberg.org/StvG/ffms2/src/branch/doom9/doc/ffms2-avisynth.md#int-fill_gaps-0).

[rgr]

ffms2 r2395 (https://codeberg.org/StvG/ffms2/releases)
Diff from the original version (https://codeberg.org/StvG/ffms2/src/branch/doom9/doc/ffms2-changelog.md#differences-from-the-original-version)

@FranceBB, you can try now fill_gaps (https://codeberg.org/StvG/ffms2/src/branch/doom9/doc/ffms2-avisynth.md#int-fill_gaps-0).

I have a nice file to test this with :)
"Determining and filling audio gaps (fill_gaps)"
Does ffms2 handle overlapping audio "blocks"? (negative gap)

Edit: I understand that the version from February 9, 2025 no longer needs to be tested?

[rgr]

More edit: Does over ten minutes (still waiting) to open a one hour 14Gb .mp4 sound right to you? :confused:

Yet another edit: 30 mins total indexing time. It's going to take two solid days to index my sources :D:eek:.

Yes, indexing time is painful :). But it still handles the more difficult cases best.

[StvG]

Does ffms2 handle overlapping audio "blocks"? (negative gap)

No.

Edit: I understand that the version from February 9, 2025 no longer needs to be tested?

Yes, there is no need to be tested.

[rgr]

xxxxx

[rgr]

ffms2:

https://gcdnb.pbrd.co/images/nqVfo969xg3Q.png?o=1

LWLibavAudioSource:

https://gcdnb.pbrd.co/images/lwtf1CUhuPKO.png?o=1

[StvG]

Just use the correct fill_gaps value for this audio.

[flossy_cake]

2, 3, 4 - discussed (https://forum.doom9.org/showpost.php?p=1994388&postcount=2820), discussed (https://forum.doom9.org/showpost.php?p=1994660&postcount=2827) and next posts.


Hi StvG, unfortunately rffmode=1 appears broken in r2395 with black flashing frames every 500ms or so.

The previous 2 releases (r2390, r1393) are fine.

To reproduce it on your end with r2395 here is a test clip which is genuine soft telecine NTSC DVD MPEG2 remux made with MakeMKV from my original discs: https://drive.google.com/uc?export=download&id=1xz_WEX36iv8tpC18zR8e8-etGwtqfuVb


FFVideoSource("NTSC soft telecine.mkv", rffmode=1)


edit: have posted the issue here as well - https://codeberg.org/StvG/ffms2/issues

[rgr]

ffms2:

https://gcdnb.pbrd.co/images/nqVfo969xg3Q.png?o=1

LWLibavAudioSource:

https://gcdnb.pbrd.co/images/lwtf1CUhuPKO.png?o=1

Just use the correct fill_gaps value for this audio.

It's not that simple. There are gaps, but also overlapping blocks.

[StvG]

Hi StvG, unfortunately rffmode=1 appears broken in r2395 with black flashing frames every 500ms or so.

The previous 2 releases (r2390, r1393) are fine.

To reproduce it on your end with r2395 here is a test clip which is genuine soft telecine NTSC DVD MPEG2 remux made with MakeMKV from my original discs: https://drive.google.com/uc?export=download&id=1xz_WEX36iv8tpC18zR8e8-etGwtqfuVb


FFVideoSource("NTSC soft telecine.mkv", rffmode=1)


edit: have posted the issue here as well - https://codeberg.org/StvG/ffms2/issues

Try this version (https://files.catbox.moe/2sc2rq.7z) and this version (https://files.catbox.moe/vmuh46.7z).

It's not that simple. There are gaps, but also overlapping blocks.

The parameter name suggests it is for gaps. For more complex cases use dedicated audio filters.

[flossy_cake]

Try this version (https://files.catbox.moe/2sc2rq.7z) and this version (https://files.catbox.moe/vmuh46.7z).


Thanks, the black flash frames are gone and both dll's appear to behave correctly with my NTSC DVD remux test files which have MPEG2 streams containing a mixture of 23.976p frames with repeat flags and 29.97i frames with no repeat flags.

Lain S01E01 (https://drive.google.com/uc?export=download&id=1Pm2V6bbrrcTJezbta7HWjW3VEa5GBz7E)
Caroline in the City S02E09 (https://drive.google.com/uc?export=download&id=1xz_WEX36iv8tpC18zR8e8-etGwtqfuVb)
MacGyver Trail to Doomsday (https://drive.google.com/uc?export=download&id=1iXWVXqZvZjy_LI346VB31INnvhDcvib6)

Because you've made 2 versions of the dll, I'm super curious to know what the difference is!

I can't do a more rigorous test to see what the differences might be, because if I put both dll's into the plugins64 folder, Avisynth will only recognise one of them. So I can only test one at a time and can't do a side-by-side comparison with StackHorizontal().

[Boulder]

I can't do a more rigorous test to see what the differences might be, because if I put both dll's into the plugins64 folder, Avisynth will only recognise one of them. So I can only test one at a time and can't do a side-by-side comparison with StackHorizontal().

Take a look at the end of this Wiki page, there's a way to bypass that one.

http://avisynth.nl/index.php/LoadPlugin

[flossy_cake]

Take a look at the end of this Wiki page, there's a way to bypass that one.

http://avisynth.nl/index.php/LoadPlugin

Are you sure that would work because the function name inside both dll's is still the same. I think I would have to render the first one to a mpeg file , then change the plugins64 dll to the second one to do the StackHorizontal comparison with the mpeg rendered one

[Boulder]

Are you sure that would work because the function name inside both dll's is still the same. I think I would have to render one of them to a mpeg file so I can change the dll in plugins64

The prefix in the special call mentioned on the page ensures that the function is picked from the correct dll.

[flossy_cake]

The prefix in the special call mentioned on the page ensures that the function is picked from the correct dll.

Yes I just saw, you replied before I could delete my reply :)

[flossy_cake]

Can't see any difference between the 2 dlls on those 3 test clips with rffmode=1. The decoded frames have:

Same Avisynth parity
Same _EncodedFrameTop & _EncodedFrameBottom
Visually identical field output after SeparateFields()
Same frame count

Results: clip1 (https://i.imgur.com/9leYLDP.jpeg), clip2 (https://i.imgur.com/0KPHGmC.jpeg), clip3 (https://i.imgur.com/yOnqQdS.jpeg)

source = "C:\TestClip.mkv"

dll1 = 2sc2rq_FFmpegSource2(source, rffmode=1, cache=false)
dll2 = vmuh46_FFmpegSource2(source, rffmode=1, cache=false)

top_left = dll1.PropShow(align=1, bold=true, size=20).Info().SelectEvery(1,0,0).Text("2sc2rq.dll", align=9, bold=true)
top_right = dll2.PropShow(align=1, bold=true, size=20).Info().SelectEvery(1,0,0).Text("vmuh46.dll", align=9, bold=true)

bottom_left = dll1.SeparateFields().PointResize(720, 480).Text("2sc2rq.dll", align=9, bold=true)
bottom_right = dll2.SeparateFields().PointResize(720, 480).Text("vmuh46.dll", align=9, bold=true)

StackVertical(StackHorizontal(top_left, top_right), StackHorizontal(bottom_left, bottom_right))


So now I'm even more curious what the difference is between those 2 dlls :)

[StvG]

@flossy_cake, thanks for testing.

The difference:
- one uses the current ffms2 code and has patched ffmpeg
- other has changed ffms2 code to work correctly with modern ffmpeg versions

[StvG]

ffms2 r2406 (https://codeberg.org/StvG/ffms2/releases)
Diff from the original version (https://codeberg.org/StvG/ffms2/src/branch/doom9/doc/ffms2-changelog.md#differences-from-the-original-version)

[flossy_cake]

ping

Hi StvG, I was wondering how much headache it would be to add an argument to FFAudioSource to tell ffmpeg which audio format to remix to?

eg. LWLibavAudioSource(layout="stereo") (https://github.com/HomeOfAviSynthPlusEvolution/L-SMASH-Works/blob/master/AviSynth/README.md) tells ffmpeg to downmix to stereo.

I find it useful because manually implementing a stereo downmix in Avisynth script is tricky and I'd rather trust ffmpeg to do it since that is a robust library that already knows how to do the remixing using libswresample.

Also I use Normalize() and SoxFilter() quite a lot for realtime screening and it gets slow processing eg. 6 channels (load times and seeking are faster with 2 channels).


mono = FC
stereo = FL+FR
2.1 = FL+FR+LFE
3.0 = FL+FR+FC
3.0(back) = FL+FR+BC
3.1 = FL+FR+FC+LFE
4.0 = FL+FR+FC+BC
quad = FL+FR+BL+BR
quad(side) = FL+FR+SL+SR
4.1 = FL+FR+FC+LFE+BC
5.0 = FL+FR+FC+BL+BR
5.0(side) = FL+FR+FC+SL+SR
5.1 = FL+FR+FC+LFE+BL+BR
5.1(side) = FL+FR+FC+LFE+SL+SR
6.0 = FL+FR+FC+BC+SL+SR
6.0(front) = FL+FR+FLC+FRC+SL+SR
hexagonal = FL+FR+FC+BL+BR+BC
6.1 = FL+FR+FC+LFE+BC+SL+SR
6.1(back) = FL+FR+FC+LFE+BL+BR+BC
6.1(front) = FL+FR+LFE+FLC+FRC+SL+SR
7.0 = FL+FR+FC+BL+BR+SL+SR
7.0(front) = FL+FR+FC+FLC+FRC+SL+SR
7.1 = FL+FR+FC+LFE+BL+BR+SL+SR
7.1(wide) = FL+FR+FC+LFE+BL+BR+FLC+FRC
7.1(wide-side) = FL+FR+FC+LFE+FLC+FRC+SL+SR
7.1(top) = FL+FR+FC+LFE+BL+BR+TFL+TFR
octagonal = FL+FR+FC+BL+BR+BC+SL+SR
cube = FL+FR+BL+BR+TFL+TFR+TBL+TBR
hexadecagonal = FL+FR+FC+BL+BR+BC+SL+SR+TFL+TFC+TFR+TBL+TBC+TBR+WL+WR
downmix = DL+DR


Bonus points if you can also give us args for

center_mix_level (default = 0.707 (−3 dB))
surround_mix_level (default = 0.707 (−3 dB))
lfe_mix_level (default = 0)

:thanks:

[StvG]

I need some time for this.