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)