FFMS2000 - The experimental future of FFMS2

[Myrsloik]

Okay. That appears to only work with VapourSynth though, not AviSynth+, so I won't be using it.

Anyway, I'm more interested in why the picture types are different between the two filters. Is there an unambiguous way to get the picture type for a frame? My fear is that AviSynth+'s frame cache may be causing some of the issues with getting the correct picture type from a variable being set.

No, there's no way in avisynth apart from running single threaded (maybe). Rewrite it properly. Or use a modern solution instead.

[`Orum]

No, there's no way in avisynth apart from running single threaded (maybe).
You mean, running FFVideoSource() with threads=1?
Or use a modern solution instead.
So software with the most recent commit 20 hours ago isn't "modern"?

[Myrsloik]

You mean, running FFVideoSource() with threads=1?

So software with the most recent commit 20 hours ago isn't "modern"?

No, avisynth with one thread. The whole system sets global variables so threading may cause races and unpredictable stuff. Sometimes. I guess. It's a horrible idea.

It's not about the commits, it's about the design, ideas and implementation. If you want to argue about that you're of course free to do so, but let me remind you that I'm not the one who's failing at encoding right now.

About the frame accuracy part all samples that aren't mpeg-ts or horribly broken work in the latest test build. At least that I know of. Of course the d9 tradition seems to be to just say things are broken all over the internet and never actually report bugs so they can be fixed...

[`Orum]

It's not about the commits, it's about the design, ideas and implementation.
Okay, so you're saying that it's simply your opinion that it's not "modern." This isn't really useful or fruitful for discussion or justification purposes.

If you want to argue about that you're of course free to do so, but let me remind you that I'm not the one who's failing at encoding right now.
I'm not sure what any of this has to do with encoding. It's the decoding I'm concerned about--after all this is a source filter, not an encoder.

Of course the d9 tradition seems to be to just say things are broken all over the internet and never actually report bugs so they can be fixed...
Did it occur to you that there might be a bug in FFVideoSource() and I'm simply trying to determine where the bug is? If, in fact, it is in FFVideoSource, I'd like to report it to you so that it can be fixed; this is a thread about testing, is it not? However, this bug could also be in LWLibAvVideoSource(), or in AviSynth+ itself.

My goal here is to be constructive, not argumentative or confrontational. I'd like to have bugs fixed, but in order to fix them, I need to know where they lie, and report them to the right developers (and will be reporting the issue with eac3to right after this post). Right now I'm just trying to see if in fact there is a discrepancy between the picture type I see reported by the FFPICT_TYPE variable and the actual frame in the stream. If so, the bug could still be in AviSynth+ or FFVideoSource(), but at least that information could be used to rule out (or in) other source filters like LWLibAVVideoSource().

If you know of a better way to help determine where the bug lies, I'm all ears.

EDIT: I think I finally know what is going on. First of all, here's a dataset of frame types for a 200-frame segment, where 0 = I-frame, 1 = P-frame, and 2 = B-frame: https://hastebin.com/zewicitigo.pl. The first column is the frame number, the second is the pict type as reported by FFVideoSource(), and the third as appears in LWLibAVVideoSource()'s cache.

What you'll notice is that I-frames always line up, and that's no coincidence. So why are the P/B frames out of order? Well, to decode the B-frames, you obviously need to have decoded the I/P frames they reference, which is why those are stored first in the stream. So, what you see in LWLibAVVideoSource()'s cache are the pict types as they are stored in the stream, whereas FFVideoSource()'s reports them as they are played back (i.e. the more useful one for filtering).

[StainlessS]

1st post FFMS2000 test7 link 404.

EDIT: FFMS2000 test8, "Platform returned code 127" (the specified procedure could not be found). [on XP32]

[Myrsloik]

1st post FFMS2000 test7 link 404.

EDIT: FFMS2000 test8, "Platform returned code 127" (the specified procedure could not be found). [on XP32]

XP is no longer supported by ffmpeg, you just missed the herps and derps a few pages back.

[StainlessS]

I'll stick with test 7 then (I still have it), thanx.

[ChaosKing]

No, avisynth with one thread. The whole system sets global variables so threading may cause races and unpredictable stuff. Sometimes. I guess. It's a horrible idea.

It's not about the commits, it's about the design, ideas and implementation. If you want to argue about that you're of course free to do so, but let me remind you that I'm not the one who's failing at encoding right now.

About the frame accuracy part all samples that aren't mpeg-ts or horribly broken work in the latest test build. At least that I know of. Of course the d9 tradition seems to be to just say things are broken all over the internet and never actually report bugs so they can be fixed...
I can confirm that vob is still not frame accurate. I tried many different vobs with test8 (in Vapoursynth) + heavy temporal filtering that resulted in ghosting and choppy output.
I had no problems with LWLibavSource and vob.

[poisondeathray]

I can confirm that vob is still not frame accurate. I tried many different vobs with test8 (in Vapoursynth) + heavy temporal filtering that resulted in ghosting and choppy output.
I had no problems with LWLibavSource and vob.

Did you try with specifying the rffmode ? default is zero.

rffmode=1 honors pulldown flags like dgindex

[ChaosKing]

vapoursynth.Error: Source: Function does not take argument(s) named rffmode
can't find it here either https://github.com/FFMS/ffms2/blob/master/doc/ffms2-vapoursynth.md

[Myrsloik]

Did you try with specifying the rffmode ? default is zero.

rffmode=1 honors pulldown flags like dgindex

rffmode doesn't affect seeking, it's just a wrapper around the output. Mpeg(ts) seeking has never been that reliable anyway which is why a lot of people simply recommend remuxing. Use d2vsource for those things.

[poisondeathray]

Seeking is one thing, but it should affect the "choppy" output . You should expect a difference between ignoring RFF flag, vs. honoring RFF flag wouldn't you ? But that switch apparently isn't in the vpy version

[ChaosKing]

Seeking is one thing, but it should affect the "choppy" output . You should expect a difference between ignoring RFF flag, vs. honoring RFF flag wouldn't you ? But that switch apparently isn't in the vpy version

I guess because of the wrong seeking some frames were replaced by wrong frames by the temporal filter thus choppy output.

I just thought maybe I can improve my laziness by not using dgindex, but apparently not :D

[poisondeathray]

d2v can give you choppiness too if you set wrong mode . Set it to ignore pulldown flags and see what happens... There are 2 different issues here (at least)

But it should be possible for ffms2 to be as good as lsmash shouldn't it ? You said you had no problems in this specific case: "I had no problems with LWLibavSource and vob." . Even though it's still not as consistent as dgindex in other cases...

[Myrsloik]

d2v can give you choppiness too if you set wrong mode . Set it to ignore pulldown flags and see what happens... There are 2 different issues here (at least)

But it should be possible for ffms2 to be as good as lsmash shouldn't it ? You said you had no problems in this specific case: "I had no problems with LWLibavSource and vob." . Even though it's still not as consistent as dgindex in other cases...

There's a difference in how things are indexed. Basically FFMS2 makes a lot of assumptions like timecodes are correct and that the libavformat demuxers can always seek accurately. Other source filters like the d2v using ones don't and instead more or less index which specific bytes are needed by each frame (or something thereabout).

[ChaosKing]

Maybe choppiness was the wrong word to use... It's more like frame jumps or sometimes wrong frame order.

I just run this nice little script: seek-test.py https://gist.github.com/dubhater/3a2c8a59841cae49ecae25cd47ff78d2

ffms2: lots of wrong frame requests
Requested frame 328, got frame 330.
Previous requests: 20 255 273 214 162 429 78 251 105 395 328
Requested frame 283, got frame 284.
Previous requests: 255 273 214 162 429 78 251 105 395 328 283

lsmash: 100% accurate seeking

[poisondeathray]

FYI - lsmash can have problems with dvd / vob too . I've had wrong framerate, different framecount (different frames) . It handles leading b's differently that d2v too. "Accurate" seeking is a moot point when frames aren't accurate to begin with... This affects both vpy and avs versions.

[lansing]

Since ffmpeg can now hardware accelerated decode (https://trac.ffmpeg.org/wiki/HWAccelIntro#CUDACUVIDNVDEC) videos if one has a Nvidia card, can this feature be implemented to ffms2 as well?

[Selur]

A fresh build to support av1 would be great. :)
Thanks!

[voran]

Hi!

Is it possible to build ffms2.so Vapoursynth plugin using https://github.com/FFMS/ffms2 repo on Linux?

[Iron_Mike]

is it possible to load an image sequence directly via FFMS2 ? if so, what is the syntax for the file mask ?

Thanks.

[FranceBB]

is it possible to load an image sequence directly via FFMS2 ? if so, what is the syntax for the file mask ?

Thanks.

Well, FFVideoSource loads video, FFAudioSource loads audio, so you can easily guess that FFImageSource loads images. :P

FFImageSource("img.jpg")

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

[Groucho2004]

Well, FFVideoSource loads video, FFAudioSource loads audio, so you can easily guess that FFImageSource loads images. :P
The question was about an image sequence. I don't think FFMS can do that, ImageSource/ImageReader (http://avisynth.nl/index.php/ImageReader) should fit nicely.

[ChaosKing]

A quick google search showed this ffms2 gscript combo https://forum.doom9.org/showthread.php?p=1826439#post1826439

[Groucho2004]

A quick google search showed this ffms2 gscript combo https://forum.doom9.org/showthread.php?p=1826439#post1826439
Yes, I just found that, too. However:
It is really slow.

[Iron_Mike]

thanks guys, I saw that post as well, was just checking in if FFmpegSource 2 has been updated to support image sequences... as that is what video is... :p

ffmpeg loads image sequences just fine... FFMS 2 is advertised as a wrapper for it, hence my question...

Thanks.

[FranceBB]

The question was about an image sequence. I don't think FFMS can do that, ImageSource/ImageReader (http://avisynth.nl/index.php/ImageReader) should fit nicely.

My bad, I missed that.

[ChaosKing]

lsmash has the same broken output that ffms had before with av1 files.
And can't open ivf files as it seems.

the ffms2 build is ok.

[ChaosKing]

If there's no "dav1d patch" available for lsmash, then building it with libaom would be a better option I guess?

[ChaosKing]

Looks good now.

One tiny thing :D
I get this in console
[libaom-av1 @ 00000271adb00740] 1.0.0-1457-geca009dba
[libaom-av1 @ 00000271adaf6480] 1.0.0-1457-geca009dba
Is this normal or some kind of debug output?

[tebasuna51]

...
Both are vapoursynth plugins.

Please use VapourSynth subforum to include these plugins, this is Avisynth Development subforum.

[amayra]

any hope to see new build ?

[Matias]

Can you reupload ffms2000??

[Myrsloik]

This thread should be closed. The FFMS2000 branch was merged long ago and noe it only creates confusion.