FFMS2000 - The experimental future of FFMS2

[Myrsloik]

Here's the second test build of FFMS2000, an experimental future version of FFMS2. Test it for regressions relative the previous FFMS2 release.

FFMS2000 test8 (https://www.dropbox.com/s/snepd7t006fpg8o/ffms2000-test8.7z?dl=1)

- 2.2000 test8
- Fixed issue with dropped/repeated frames in vc1 with multiple b-frames after seeking (Myrsloik)
- Fixed issue with dropped/repeated frames in h264 when the reorder buffer size is too small (Myrsloik)
- Improved seeking in mpeg and mpegts streams (Myrsloik)
- Added rgb(a)p8 output to Avisynth+ (Myrsloik)
- Added VP9 support (Daemon404)
- Fixed incorrectly reporting the output as limited range when it's in fact unknown and likely to be full range (Myrsloik)
- Added mastering display metadata output (Myrsloik)
- VapourSynth source now defaults to not outputting alpha (Myrsloik)
- Removed the now unused demuxer, dumpmask, audiofile and utf8 arguments from the source filters (Myrsloik)
- Removed ability to dump audio tracks (Myrsloik)
- Fixed incorrect colorimetry metadata reported when converting the output to another colorspace (Myrsloik)
- Sources now simply reference the index instead of copying large parts of it (Myrsloik)
- Use new FFmpeg decoding API (Myrsloik)
- Fixed several bugs in output format selection (Myrsloik)
- FFMSIndex will now properly error out with invalid arguments (Myrsloik)
- Add rotation metadata export (Myrsloik)
- Add stereoscopic metadata export (Myrsloik)
- Created new Visual Studio 2017 projects (Myrsloik)
- Removed old mingw version support (Myrsloik)
- Removed support for old FFmpeg versions (Myrsloik)
- Removed libav support (Myrsloik)
- Discontinuous Timestamp Support (Daemon404)
- Add FFMS_Deinit (Daemon404)
- Fix mid-stream parameter changes (Daemon404)

[StainlessS]

It of course supports XP, yes :)

(thought not) :(

[amayra]

i would like to thank you for your great work i will run some tests and give you feedback :thanks:

It of course supports XP, yes :)

(thought not) :(

I don't hope so :devil:

[StainlessS]

Thank you everybody, except amayra.

EDIT: Checked it, and it does work on XP, lovely :) Thank you M.

[TheFluff]

Myrsloik is most of the time a sorta reasonable person, unlike me who would have actively chosen to make it incompatible with XP just out of pure spite

[burfadel]

It's XP, not Windows 7 or 8.1. If they want to stick with such an old OS why do they want the latest in everything else? If the computer really is that old, I douby encoding 1080P would be that productive. Not saying 1080P or 720P encoding with x264/x265 is impossible, just not practical. If it manages the speed it's likely the quality settings are so low that encoding at 480P would give much better picture.

What wrong with using older, compatible versions? If the old versions are so bad, why still run XP?!

[real.finder]

It's XP, not Windows 7 or 8.1. If they want to stick with such an old OS why do they want the latest in everything else? If the computer really is that old, I douby encoding 1080P would be that productive. Not saying 1080P or 720P encoding with x264/x265 is impossible, just not practical. If it manages the speed it's likely the quality settings are so low that encoding at 480P would give much better picture.

What wrong with using older, compatible versions? If the old versions are so bad, why still run XP?!

I think using old OS is another story than using newer filter update

anyway, I was using xp too until I bought new laptop with win 7 included, many people don't like change their os but they update it as possible

and if you can keep support for old things in new update, why you will not do it? for example I did some update to SMDegrain but I kept the 2.5 avs support, the only script that I remove the 2.5 support from it was QTGMC cuz there are chroma bug in Bob() with 420 subsampling and to solve it in avs 2.5 we will make the script more slow

[StainlessS]

Myrsloik is most of the time a sorta reasonable person
Yes, so much nicer and more worthwhile person than Fluffy. :)

unlike me who would have actively chosen to make it incompatible with XP just out of pure spite

You dont need to state the obvious :)

If the old versions are so bad, why still run XP?!
I suppose that means that you update because you think older versions are 'so bad'.
I refuse point blank to go M$ after XP, Vista left such a bad taste in my mouth that anything remotely resembling it makes me shudder.

Not saying 1080P or 720P encoding with x264/x265 is impossible, just not practical.
I'm personally not too bothered about HD (I got lo rez almost kaput eyes).
As far as speed is concerned, I'm not too bothered either, I farm encodes off to one of several P4's running XP, and they can take as much time as they like, I dont care.
Even if I did run W7 on No 1 m/c I would not use anything that does not run on XP.

[feisty2]

i would like to thank you for your great work i will run some tests and give you feedback :thanks:



I don't hope so :devil:

There's really just nothing you can do to change the mind of an old and stubborn person, most people tend to get more and more stubborn and refuse to advance as they get older anyways

[amayra]

There's really just nothing you can do to change the mind of an old and stubborn person, most people tend to get more and more stubborn and refuse to advance as they get older anyways

i crack this as joke so you dont need to be so mean... so please stay in the topic OS discussion is off topic here

[Atak_Snajpera]

Ok I understand people who hate latest M$ experiment called Win10 aka Service10 aka Ads10 aka ShutUPAndGiveMeYourData10 but Win7 (NT6.1) is really great replacement for WinXP (NT5.1).
Mature, stable and works excellent with RyZen/KabyLake.

[Groucho2004]

Ok I understand people who hate latest M$ experiment called Win10 aka Service10 aka Ads10 aka ShutUPAndGiveMeYourData10 but Win7 (NT6.1) is really great replacement for WinXP (NT5.1).
Mature, stable and works excellent with RyZen/KabyLake.I have been playing around with W7 in a VM for quite some time and I have to agree. After removing junk with NTLite and some registry tweaks I can live with it. Nice to know that contemporary CPUs work.

[manolito]

I probably have made a reputation here to be a diehard XP fan. In fact I do have a Win7 notebook (Core i5) running in parallel to my old desktop which runs XP simply because its hardware does not even allow to install Win7. So I do have a direct comparison...

XP is still so much easier to use than Win7 for me. For Win7 I have to apply countless tweaks (DS filters, UAC, ZIP handling, VirtualStore, Permissions to name a few) until it does things the way I need them. And it still uses much more resources than XP. I have an XP installation imaged for my Core i5 notebook, and after installing this image the notebook feels much more responsive.

And what I have read recently about Win7 support for newer CPUs, I applaud AMD for continuing support for RyZen under Win7, but for Intel it looks like M$ bribed them to discontinue support for Win7 even if there is no technical reason. For KabyLake I read that you have to apply some obscure patches to get it to work under Win7.

Cheers
manolito

[jackoneill]

Can I interest y'all in a Linux distribution? It's definitely not made by Microsoft.

[StainlessS]

I would appreciate a Linux distribution of ffms2000, (guess we have to wait a few years for ffms2017). :)

[TheFluff]

ffms2 has been cross platform from the start, it just doesn't have an avisynth plugin on linux

works fine in vapoursynth, tho

e: looks like compilation might be a bit broken at the moment though

[MysteryX]

I would appreciate a Linux distribution of ffms2000, (guess we have to wait a few years for ffms2017). :)
Only on doom9 you'll hear of 2000 as being the future

[StainlessS]

All I know is, I tried to install ffms on Linux and it failed because of some un-resovlable dependance, and at that point I gave up.
(Much like I have on previous attempts at linux trials).

EDIT: Linux dont work flawlessly, till it does I'm somewhat tempted to use the less than desirable XP.

EDIT: Sorry, OT again, lets get back on it.

[Myrsloik]

I posted test2 NOW WITH 100% MORE XP HATE!

See the first post. It now has FFmpeg compiled with zlib so it should support more formats again (compared to 2.23). And some bug fixes too.

[sl1pkn07]

fail build in linux


make: *** No rule to make target 'src/core/lavfaudio.cpp', needed by 'src/core/lavfaudio.lo'. Stop.
make: *** Waiting for unfinished jobs....


fms2000 branch on ffms2 github

[Myrsloik]

fail build in linux


make: *** No rule to make target 'src/core/lavfaudio.cpp', needed by 'src/core/lavfaudio.lo'. Stop.
make: *** Waiting for unfinished jobs....


fms2000 branch on ffms2 github

This isn't a Linux test

[amayra]

i think there performance issues in test2 it doesn't matters which source i use speed decrease even in 360p video
Is there any reason for that ?

[Myrsloik]

i think there performance issues in test2 it doesn't matters which source i use speed decrease even in 360p video
Is there any reason for that ?

There shouldn't really be a difference. How much did it decrease?

[madshi]

Would it be possible to also export the HDR metadata (SMPTE 2086)? Specifically the gamut and min/max luminance of the mastering display?

That would be helpful for handling of HDR videos.

FWIW, LAV Splitter/Video Decoder already exports them, so maybe you can find out how from the LAV source code (if the license permits)?

[Myrsloik]

Would it be possible to also export the HDR metadata (SMPTE 2086)? Specifically the gamut and min/max luminance of the mastering display?

That would be helpful for handling of HDR videos.

FWIW, LAV Splitter/Video Decoder already exports them, so maybe you can find out how from the LAV source code (if the license permits)?

You mean the stuff added in this commit (https://github.com/Nevcairiel/LAVFilters/commit/499aca4ebf01dec35a0af702e682643028d274da)? Looks simple enough.

[madshi]

Yep, exactly that stuff! It's helpful when processing HDR content.

(JFYI: Blu-Ray style HDR uses a _Transfer of 16. Fortunately, ffms2 already reports that properly.)

[sneaker_ger]

LAV also reads HDR metadata from mkv/webm container. (as used by Youtube for HDR)

[Groucho2004]

Decoding speed using a UHD h.264 clip:

[OS/Hardware info]
Operating system: Windows XP (x86) Service Pack 3.0 (Build 2600)
CPU: Intel(R) Core(TM) i5-2500K CPU @ 3.30GHz
CPU features: MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AVX*
(* CPU feature not supported by OS)


[Avisynth core info]
VersionString: AviSynth+ 0.1 (r2294, MT, i386)
VersionNumber: 2.60
File version: 0.1.0.0
Interface Version: 6
Multi-threading support: Yes
Avisynth.dll location: D:\WINNT\system32\avisynth.dll
Avisynth.dll time stamp: 2016-10-26, 17:29:37 (UTC)
PluginDir+ (HKLM, x86): E:\Apps\VideoTools\AvisynthRepository\AVSPLUS_x86\plugins
PluginDir2_5 (HKLM, x86): E:\Apps\VideoTools\AVSPlugins\AutoLoad


[Clip info]
Number of frames: 1000
Length (hh:mm:ss.ms): 00:00:20.000
Frame width: 3840
Frame height: 2160
Framerate: 50.000 (50/1)
Colorspace: i420

[Script]
FFVideoSource("420_4K.264")
AssumeFPS(50, 1)


qyot27's latest C-plugin (r1140):
[Runtime info]
Frames processed: 1000 (0 - 999)
FPS (min | max | average): 3.638 | 632.4 | 23.84
Memory usage (phys | virt): 500 | 531 MiB
Thread count: 17
CPU usage (average): 88%

ffms2000:
[Runtime info]
Frames processed: 1000 (0 - 999)
FPS (min | max | average): 2.519 | 616.6 | 18.12
Memory usage (phys | virt): 403 | 422 MiB
Thread count: 13
CPU usage (average): 84%

[Myrsloik]

You can't compare those. That one is compiled with mingw.

[Myrsloik]

Yep, exactly that stuff! It's helpful when processing HDR content.

(JFYI: Blu-Ray style HDR uses a _Transfer of 16. Fortunately, ffms2 already reports that properly.)

Are primaries and whitepoint even relevant? Isn't that effectively included in the already exported values?

[madshi]

Blu-Ray style HDR is always stored with BT.2020 matrix and BT.2020 primaries. BT.2020 is practically used as a "container". Most UHD Blu-Rays only use a subset of the BT.2020 container. The metadata tells us which primaries the master display was calibrated with. Which is usually DCI. This information can be used to pick a suitable gamut compression curve.

[real.finder]

I posted test2 NOW WITH 100% MORE XP HATE!


but it's still work in xp :)

[raffriff42]

Only on doom9 you'll hear of 2000 as being the future
2000 still sounds impossibly futuristic. I can't get used to it.
https://www.dropbox.com/s/g6pdwzt303xkmqo/Conan2000.jpg?raw=1
In The Year 2000 (https://youtu.be/kmzpdd4pWvM?t=58)

[Myrsloik]

Blu-Ray style HDR is always stored with BT.2020 matrix and BT.2020 primaries. BT.2020 is practically used as a "container". Most UHD Blu-Rays only use a subset of the BT.2020 container. The metadata tells us which primaries the master display was calibrated with. Which is usually DCI. This information can be used to pick a suitable gamut compression curve.

I think I added support for it properly now. Do you happen to have a small sample I can use for testing?

[madshi]

This one should do the trick:

http://demo-uhd3d.com/fiche.php?cat=uhd&id=145

[Groucho2004]

You can't compare those. That one is compiled with mingw.Why would a user who for example just wants to decode a BD source care what compiler was used? Maybe I'm missing something but isn't this just another source filter for a variety of formats?

[Myrsloik]

There's a known speed difference between compilers. That's why. I can tell you the result long before you do the test. My test builds are never compiled for speed.

[Groucho2004]

Why would a user who for example just wants to decode a BD source care what compiler was used?
There's a known speed difference between compilers. That's why.:confused::confused::confused: Apart from the fact that you're stating the obvious, are you sure you read my question?


My test builds are never compiled for speed.That makes more sense.

[Myrsloik]

:confused::confused::confused: Apart from the fact that you're stating the obvious, are you sure you read my question?


That makes more sense.

About statements, I'm obviously asking for correctness testing. If you desperately need OVER 9000 FPS you shouldn't be using the extra experimental versions of anything because us developers have a bad habit of turning on extra debug settings. Also corrupt output is much more likely which would slow things down even more when you have to REDO EVERYTHING!

Release builds are obviously different...

[Selur]

Feature request: Support .mpls parsing. It's really a pain to always load all the separate files a playlist makes up and later join them together,... (FFmpeg itself can handle playlist files fine when build with libbluray)

[Myrsloik]

Feature request: Support .mpls parsing. It's really a pain to always load all the separate files a playlist makes up and later join them together,... (FFmpeg itself can handle playlist files fine when build with libbluray)

That sounds complicated... I'd kinda like to avoid it. Maybe someone can make a ffms2 compile with libbluray and see what happens. Maybe it'll work automatically then. I don't think anyone's done that.

[Myrsloik]

Test3 uploaded. Some more fixinations and improvements. Now handles all your VP9 needs!

[shekh]

Is it good idea to merge (some part of) it to VirtualDub source plugin? Basically what I miss from bare ffmpeg is accurate per-frame timestamps.

[Myrsloik]

Is it good idea to merge (some part of) it to VirtualDub source plugin? Basically what I miss from bare ffmpeg is accurate per-frame timestamps.

I would definitely make it a separate input plugin. All the tricks used can lead to issues worse than naive ffmpeg usage. I wouldn't mind including vdub support of it's contributed.

[shekh]

I already accumulated a frightening amount of tricks to make ffmpeg work.. Want to add some sort of option, not separate plugin.
Can you briefly describe what ffms does now? My idea is to just run a scan of stream and save pts/dst of each frame (similar to running ffprobe). And which frames are keys.

[Myrsloik]

There's no brief description. It's a long list of horrible ideas. See the source. Your hacks are a puny collection. We parse the bitstream for some formats. Use dts OR pts depending on the time of day. Switch between byte and timestamp seeking. Guess decoding delays (badly). Audio is even nastier.

[TheFluff]

I already accumulated a frightening amount of tricks to make ffmpeg work.. Want to add some sort of option, not separate plugin.
Can you briefly describe what ffms does now? My idea is to just run a scan of stream and save pts/dst of each frame (similar to running ffprobe). And which frames are keys.

That'll just get you to where FFMS was like five years ago. FFMS has an API, use that.

I think the main thing we've learned from FFMS is that while ffmpeg has a unified API that is the same for all formats, you can definitely not count on every format behaving the same (or in fact even behave similarly), nor on the documented functionality/behavior to work consistently for all formats, etc etc. One of the best ways to illustrate this is some of the comments in the ffms source - where someone's been forced to add some godawful workaround and explained why. Some of my favorites:

https://github.com/FFMS/ffms2/blob/ffms2000/src/core/indexing.cpp#L471
https://github.com/FFMS/ffms2/blob/ffms2000/src/core/track.cpp#L218 (really, just read this entire source file, it shows why your idea is painfully inadequate)
https://github.com/FFMS/ffms2/blob/ffms2000/src/core/videosource.cpp#L654
https://github.com/FFMS/ffms2/blob/ffms2000/src/core/audiosource.cpp#L160 (again, audiosource.cpp is worth reading in its entirety)

[shekh]

Yes I have experience. My favorite is "block_align" field. The docs should really say "this is meaningless value, we just need room for random stuff"
I wonder if any issue found by FFMS resulted in some fix in FFMPEG to improve it?

[Myrsloik]

Yes I have experience. My favorite is "block_align" field. The docs should really say "this is meaningless value, we just need room for random stuff"
I wonder if any issue found by FFMS resulted in some fix in FFMPEG to improve it?

I don't think any meaningful fixes happened. Framr accurate seeking isn't a supported usr case.

[Mystery Keeper]

Test 3 still gives me wrong frames for VP9. Further in time compared to the source video.

[dipje]

I have issues with .MTS files (avchd so they contain h264 and ac3).

The files have some weird timing . The audio starts sooner than the video most of the time. It seems when I press record on my camera it starts capturing audio immediately, but video takes half a second or so to get going. So the timecodes of the videostream don't start at 00:00:00. What ffms2000 seems to do is freeze-frame the first videoframe until a/v sync is achieved.
But halfway through the files the frames seem to jump backward and forward , weird glitches. Glitches that aren't there with ffplay or playing through mpc-hc and lavfilters.

The thing is, I don't think this is a regression from ffms2, I think ffms2 also has the same issue, and the issue comes from the libavformat demuxer for MTS which is 'not recommended' I believe.

In older ffms2 versions (2.1 or earlier even ?) You could disable the libav demuxer during indexing, so it would use another one (don't know which, haali or something from matroska that could read MTS ? ). Or maybe I remuxed the MTS files to mkv to prevent issues.

Anyway, lsmash libav reads them ok. It uses a different MTS parser right ?

All other files I use recently (magicyuv 10bit RGB, dnxhr 444, Cineform RGB ) seem to work just fine. (Only tested through Vapoursynth x64)

[Myrsloik]

I have issues with .MTS files (avchd so they contain h264 and ac3).

The files have some weird timing . The audio starts sooner than the video most of the time. It seems when I press record on my camera it starts capturing audio immediately, but video takes half a second or so to get going. So the timecodes of the videostream don't start at 00:00:00. What ffms2000 seems to do is freeze-frame the first videoframe until a/v sync is achieved.
But halfway through the files the frames seem to jump backward and forward , weird glitches. Glitches that aren't there with ffplay or playing through mpc-hc and lavfilters.

The thing is, I don't think this is a regression from ffms2, I think ffms2 also has the same issue, and the issue comes from the libavformat demuxer for MTS which is 'not recommended' I believe.

In older ffms2 versions (2.1 or earlier even ?) You could disable the libav demuxer during indexing, so it would use another one (don't know which, haali or something from matroska that could read MTS ? ). Or maybe I remuxed the MTS files to mkv to prevent issues.

Anyway, lsmash libav reads them ok. It uses a different MTS parser right ?

All other files I use recently (magicyuv 10bit RGB, dnxhr 444, Cineform RGB ) seem to work just fine. (Only tested through Vapoursynth x64)

Do you have a sample MTS file? It could be timestamp discontinuities (or something else) we're trying to fix right now.

I have no idea what l-smash uses. All I know is that it does everything very differently.

Haali splitter support was removed several years ago because haali stopped developing it looooooooong ago (and lavf got better)

[zub35]

Add the ability to convert vfr to cfr using two methods: duplicate or blend.
Only DSS2 does the correct conversion, by duplication.

[Myrsloik]

Add the ability to convert vfr to cfr using two methods: duplicate or blend.
Only DSS2 does the correct conversion, by duplication.

Duplication already exists. Also lrn2vfr. It's 2017.

[zub35]

Duplication already exists. Also lrn2vfr. It's 2017.

This is not right. ffms averages fps and discards frames that exceed it.
Dss2 works with the top bar of VFR and duplicates frames to it, without discarding.
p.s. Or maybe I do not understand something ...

Also that's when fps jumps to the insane 1000, and then all the other frames are duplicated to it, which is also bad.
It is necessary that ffms find the average maximum value, discarding too large bursts.

[Myrsloik]

This is not right. ffms averages fps and discards frames that exceed it.
Dss2 works with the top bar of VFR and duplicates frames to it, without discarding.
p.s. Or maybe I do not understand something ...

No frames are discarded umless you use the cfr mode. You're wrong.

[zub35]

sample: https://cloud.mail.ru/public/BX68/Cxg3rF7iX (sorry, only erotic)
dss2 30fps and 20970 frames [11:38.999]
ffms2000 20.220fps and 14113 frames [11:37.958]

Because of what, the video in ffms is accelerating, then slowing down

[Myrsloik]

Don't even have to look at it. It's because it has dropped frames (duplicates/nvops) and only returns actually coded frames. The file is vfr and you're using the vfr mode. Everything works as expected.

[zub35]

The video is not behaving naturally. Rides with acceleration and deceleration. This not normal
Also, it would still be great ffms2000 worked with timecodes_v2 in this conversion vfr to cfr, loading them from file. This was-would be useful for raw streams.

[Myrsloik]

The video is not behaving naturally. Rides with acceleration and deceleration. This not normal

Lrn2vfr. The dropped frames do exactly that.

[TheFluff]

Use the parameters fpsnum and fpsden if you want CFR by duplicating frames. You could try reading the manual, you know. It's really not bad at all.

(the default behavior is to output coded frames and optionally a timecodes file so you can do the right thing instead of this silly CFR business)

[dipje]

Do you have a sample MTS file? It could be timestamp discontinuities (or something else) we're trying to fix right now.

You have a private message

[Myrsloik]

Test4 released. Fixes some minor issues in the avisynth source.

[madshi]

Is the HDR metadata included in this build? How exactly is it transported?

[Myrsloik]

Is the HDR metadata included in this build? How exactly is it transported?

It's exported as new fields in FFMS_Frame. And set as the frame propertiesMDMDisplayPrimariesX
MDMDisplayPrimariesY
MDMWhitePointX
MDMWhitePointY
MDMMinLuminance
MDMMaxLuminance

[madshi]

Hmmmm... I tried this:

video = core.ffms2.Source('LG_Chess_HDR.mp4')

const VSFrameRef *src = vsapi->getFrameFilter(n, d->node, frameCtx);
const VSMap *props = vsapi->getFramePropsRO(src);
int error;
int transfer = (int) vsapi->propGetInt(props, "_Transfer", 0, &error); if (error) transfer = -1;
int maxLum = (int) vsapi->propGetInt(props, "MDMMaxLuminance", 0, &error); if (error) maxLum = -1;
It works for "_Transfer", but I get error "1" (which seems to mean "peUnset") when asking for "MDMMaxLuminance". I also tried "propGetFloat()", but same error. What am I doing wrong?

Btw, which data format does "MDMDisplayPrimariesX/Y" use?

[Myrsloik]

Float, array of 3 values. Just like ffmpeg exports it.

[madshi]

Ok, tried "vsapi->propGetFloat(props, "MDMDisplayPrimariesX", 0, &error)", but I also get error 1.

[Myrsloik]

Ok, tried "vsapi->propGetFloat(props, "MDMDisplayPrimariesX", 0, &error)", but I also get error 1.

It's not flagged for all frames. Request a 100 or so and one will have it.

[sneaker_ger]

For HEVC (and probably AVC) it should apply to all frames of a GOP, I think.
https://forum.doom9.org/showthread.php?p=1804070#post1804070

[Myrsloik]

Applying and being flagged are different things. This is how the ffmpeg api handles things.

[madshi]

Sorry, but still doesn't work. All first 100 frames in 2 different HDR demos I've tried (one MKV, one MP4) report error 1. LAV -> madVR during video playback report metadata just fine, so the metadata is definitely there.

But even if it worked after a couple dozen frames, I'm not sure it's a good idea for a VapourSynth filter to request 100 frames in advance just to be able to get metadata? Of course it would be possible to work without the metadata first, and then switch to a different processing mode once the metadata is available, but that doesn't sound really nice, either.

[Myrsloik]

Sorry, but still doesn't work. All first 100 frames in 2 different HDR demos I've tried (one MKV, one MP4) report error 1. LAV -> madVR during video playback report metadata just fine, so the metadata is definitely there.

But even if it worked after a couple dozen frames, I'm not sure it's a good idea for a VapourSynth filter to request 100 frames in advance just to be able to get metadata? Of course it would be possible to work without the metadata first, and then switch to a different processing mode once the metadata is available, but that doesn't sound really nice, either.

LG_Chess_HDR.mp4 has it on the first frame for me. I guess adding logic to repeat the metadata for every frame could be useful but that one appears to work. Can I have a sample that doesn't work?

(it does however have some kind of seek issue so that'll be fun to debug)

[madshi]

LG_Chess_HDR.mp4 is one of the files I tested with, and I weren't able to read any MDM metadata in the first 100 frames... :( Maybe I did something wrong? VapourSynth\plugins64\ffms2.dll is definitely from today, though.

Remembering/repeating the metadata would probably be useful, at least until you know for sure that the content is no longer HDR (e.g. next GOP?).

[Myrsloik]

LG_Chess_HDR.mp4 is one of the files I tested with, and I weren't able to read any MDM metadata in the first 100 frames... :( Maybe I did something wrong? VapourSynth\plugins64\ffms2.dll is definitely from today, though.

Remembering/repeating the metadata would probably be useful, at least until you know for sure that the content is no longer HDR (e.g. next GOP?).

Even tested exactly the dll I uploaded. Still works. I use clip.text.FrameProps() to show all properties and it's there. Odd

[madshi]

I didn't know "clip.text.FrameProps()" existed, it's quite useful! It helped me find the issue:

I had tested with the VapourSynth Editor, and for some reason it had loaded an old ffms2.dll from a python subfolder instead of the regular location. When running the vpy script directly, metadata transport works fine!

Sorry for the false alarm, and thanks for adding HDR metadata support. It would still be nice to have it working from frame 1, and to have it remember the metadata, if possible.

[sneaker_ger]

But it is working on the first frame? At least on the LG sample. But probably most others as well.

[madshi]

I've tested with 2 different samples and it seems to work on the first frame for both. So it seems there's no issue there.

[Myrsloik]

Due to a few huge coincidences and madshi's transport stream (with mp4 extension, just that took me a while to realize) we may have found a better strategy for seeking in mpeg and mpegts. Grab test5 from the first post and report your results relative to test4. It should have a lot less seeking issues in mpeg and transport streams now. Download link in the first post.

It would be very helpful if you throw all your mpeg and transport streams at it.

[sneaker_ger]

Yes, looking good.

Don't forget to let test5 create new .ffindex files, people.

[Myrsloik]

Yes, looking good.

Don't forget to let test5 create new .ffindex files, people.

Yes, delete all old ones. I forgot to bump the index version and using an old index=>old issues.

[dipje]

The weird things I had at the start of my MTS files seem fixed now. Stepping through the files (forward) reveal nothing out of the ordinary an all good.

Stepping backwards still starts acting weird, but you might just call that 'by design and do not seek backwards' I don't know.
If I start stepping backwards (after having stepped forward through the whole video) the first few frames seek very quick (cached I guess) then the frames seek back slower (to be expected, seeking backwards in a file that is not All-I).
But after around 80 frames the picture 'freezes'. I can step back a few frames but they all look the same (they didn't while seeking forward through the file). This lasts for around 10 frames (GOP length?). Then it goes to slowly seeking backwards frame by frame again.

Now, if I start stepping forward at this moment, those 10 'freeze frames' are still there. I have to step back a whole lot more and then step forward ago and now the exact same frames step forward OK. So is there actually some seeking gone bad here, or is the Vapoursynth cache being naughty? Or both?

What appears to be happening is that after seeking +/- 80 frames backwards ffms2 produces 10 frames of 'freeze frame', and Vapoursynth caches those 10 frames, so stepping them forward again will not fix it while the bad frames are still in the cache.

@Myrsloik: You still have my MTS example file right? Create a simple script that opens it with ffms2 with nothing more, open it in Vapoursynth Editor. Go to the last frame, then start holding down the arrow-down key to step backward. Around frame 192 the 'freeze frame' occurs. Also happens in VDFilterMod (to rule out a bug in Vapoursynth Editor or something).
If I open the file and don't seek to the end but instead seek to frame +/- 220 and start holding down the arrow key, the glitch once again occurs at frame +/- 192 (same spot) so it does seem related to that position in the file, not the amount of frames I stepped backwards or anything.

PS (And yes, I deleted .ffindex file before I started)
PS2 (And I'm talking about test5, just to be clear)

[stax76]

It would be very helpful if you throw all your mpeg and transport streams at it.

How would I handle audio, dump or audiodub?

I want to encode this sample:

http://www.mediafire.com/file/t51xbk6wsb5kvdf/480p__AVC__59%2C940fps__AC3_2.0__Growing_Pains.ts

Some script code and command lines to get me started would be helpful.

[Myrsloik]

The weird things I had at the start of my MTS files seem fixed now. Stepping through the files (forward) reveal nothing out of the ordinary an all good.

...

Interesting. It at least seems to improve and probably exposes a few different issues. So many old hacks to re-evaluate in there...

I wish I'd kept a bigger collection of samples.

[Atak_Snajpera]

Is this normal that in latest ffms2000 test5 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

[Myrsloik]

Is this normal that in latest ffms2000 test5 all frames in VC-1 are detected as keyframes?
...

No, can I have a small sample?

[Atak_Snajpera]

No problem give me 15 minutes...

[Atak_Snajpera]

ok done
http://www.mediafire.com/file/98z5ynb5m6dwb0r/VC-1.mkv

[Myrsloik]

ok done
http://www.mediafire.com/file/98z5ynb5m6dwb0r/VC-1.mkv

Must be a broken mkv/ffmpeg bug. The parser really does report all the frames as keyframes. I'll poke it a bit more but definitely not my fault.

[FranceBB]

It seems that the latest ffms2000 breaks BePipe -> NeroAACEnc compatibility.
Although the audio stream is detected by BePipe, NeroAACEnc can't encode it and fails.

[Myrsloik]

It seems that the latest ffms2000 breaks BePipe -> NeroAACEnc compatibility.
Although the audio stream is detected by BePipe, NeroAACEnc can't encode it and fails.

Audio handling wasn't changed at all. Oddly enough.

[FranceBB]

Uhm... Well, with the stable FFMpegSource2 I was able to open a file in avisynth, and pipe the audio using BePipe to NeroAACEnc, but I can't with ffms2000.
I think you can reproduce my error pretty easily with any source.

Sample:

FFMpegSource2("Ep1.avi", fpsnum=24000, fpsden=1001, atrack=-1)

BePipe.exe --script "Import(^AVS Script.avs^)" | neroAacEnc.exe -lc -br 320000 -if - -of "audio.m4a"

[FranceBB]

Hi,
I have an .mka audio track which contains two tracks: the first one is a FLAC lossless audio track with 6 channels, and the second one is an AC3 stereo audio track.
When I use FFAudioSource() it takes the second track (AC3) instead of the very first one.
I think it should use the first available audio track, so FLAC.
Is this a bug? Do you want me to upload the .mka file?


General
Unique ID : 174555563715229058114849233714037036678 (0x83522DC00F66393A809D00CAF83E9686)
Complete name : O:\episodi\[VCB-Studio] Shingeki no Bahamut Genesis [Ma10p_1080p]\bahamutep2audiodolby.mka
Format : Matroska
Format version : Version 4 / Version 2
File size : 664 MiB
Duration : 23 min 52 s
Overall bit rate mode : Variable
Overall bit rate : 3 890 kb/s
Encoded date : UTC 2016-11-12 14:21:14
Writing application : mkvmerge v9.5.0 ('Quiet Fire') 64bit
Writing library : libebml v1.3.4 + libmatroska v1.4.5

Audio #1
ID : 1
Format : FLAC
Format/Info : Free Lossless Audio Codec
Codec ID : A_FLAC
Duration : 23 min 52 s
Bit rate mode : Variable
Bit rate : 3 249 kb/s
Channel(s) : 6 channels
Channel positions : Front: L C R, Side: L R, LFE
Sampling rate : 48.0 kHz
Frame rate : 11.719 FPS (4096 spf)
Bit depth : 24 bits
Stream size : 555 MiB (84%)
Writing library : libFLAC 1.2.1 (UTC 2007-09-17)
Language : Japanese
Default : Yes
Forced : No

Audio #2
ID : 2
Format : AC-3
Format/Info : Audio Coding 3
Format settings, Endianness : Big
Codec ID : A_AC3
Duration : 23 min 52 s
Bit rate mode : Constant
Bit rate : 640 kb/s
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 kHz
Frame rate : 31.250 FPS (1536 spf)
Bit depth : 16 bits
Compression mode : Lossy
Stream size : 109 MiB (16%)
Language : Japanese
Service kind : Complete Main
Default : No
Forced : No

[Myrsloik]

Are both tracks manually selectable?

[FranceBB]

Yes, sure. I can select them using potplayer. If I just open the file, it plays the FLAC track as default.

[Myrsloik]

Released test6. Download link in first post.

[Mystery Keeper]

Test6 finally opens VP9 properly. Thank you!

[stax76]

@Myrsloik

I believe there is a memory leak with the x64 build, I've not examined it in detail, in staxrip for every job memory grew 50-100 MB, I always thought it's staxrip and I've been too careless with resources, forgetting to detach event handlers and things, I changed my design and had major problems with it, by accident I noticed that it don't happen with l-smash, I've tried with VirtualDub, after every opening and closing circle memory grows 10 MB, for GUIs this is very problematic because they don't keep one script open but rather work with multiple scripts opening and closing them on demand. I've currently an issue on the tracker by somebody that is trying to batch process 3200 files in one go. :-)

[manolito]

That's what you get from including experimental versions of helper applications in a stable version of your own software... :devil:

[stax76]

I knew it was coming. ;)

[Myrsloik]

I knew it was coming. ;)

Exactly how are you using it? What's the simplest script to reproduce?

[stax76]

FFVideoSource("file")

Only opening and closing avs+ in VirtualDub x64.

[burfadel]

It isn't releasing memory when a project is closed and another one is loaded in the same instance.

[lansing]

How do I dump the keyframe to a text file?

[Atak_Snajpera]

ffmsindex.exe -k input.mkv

[StainlessS]

How do I dump the keyframe to a text file?

ffmsindex.exe -k input.mkv

I could not get above to work, "ffmsindex.exe is not a valid Win32 application". (on XP32, EDIT: In alert box)
[EDIT: Followed by "Access is Denied" in command line]

Maybe I did something wrong.

but this works from within avs script


# From InitExternalPlugins.avsi in Plugins"
#fn4= "C:\Program Files\AviSynth\plugins\FFMS2000_CPP\ffms2_26.dll" # FFMpegSource CPP Plugin
#Exist(fn4) ? LoadPlugin(fn4) : NOP

VNAM = ".\test.mpg"
FRAMES = ".\Frames.txt"
WRITETYPE = "I" # Write I Frames, for types see http://avisynth.nl/index.php/FFmpegSource
###
WRITE = (FRAMES!="")
FRAMES = (WRITE) ? RT_GetFullPathName(FRAMES) : ""
VNAM = RT_GetFullPathName(VNAM)

(WRITE) ? RT_FileDelete(FRAMES) : NOP

FFIndex(VNAM)
FFVideoSource(VNAM)

ScriptClip("""
Type=Chr(FFPICT_TYPE)
(WRITE && TYPE==WRITETYPE) ? RT_WriteFile(FRAMES,"%d",current_frame,Append=True) : NOP
RT_Subtitle("FrameNumber: %d of %d\nPicture Type: %s",current_frame,FrameCount,Type)
""",after_frame=true)


EDIT: And writing frame types to an RT_Stats DBase:- http://forum.doom9.org/showthread.php?p=1775515#post1775515

[Groucho2004]

I could not get above to work, "ffmsindex.exe is not a valid Win32 application". (on XP32)
That error usually indicates that the binary was built with VC2015/17 without the XP compatibility switches or you're using the 64 bit version.

[StainlessS]

ffmsindex.exe references Kernel32.dll, so I assume is 32 bit.

Also get in DependencyWalker, "FFMS2.DLL, Error opening file. The system cannot find the file specified (2)".
Although dll is in same directory as both exe and command line.
But clicking on the dll error line within DW, brings up the DW report on the dll (so it does find it).

Does not really matter, I dont need it working, thanx G2K4.

[Groucho2004]

ffmsindex.exe references Kernel32.dll, so I assume is 32 bit.On Win64 it's also kernel32.dll (system32, not syswow64).

[StainlessS]

I was using old (probably supplied with W2K setup disks) version of Dependency Walker, just downed v2.2 latest:- http://www.dependencywalker.com/
for both x86 and x64, loaded ffmsindex.exe into the DW 32 bit,
"Error: At least one required implicit or forwarded dependency was not found."
Down to not being able to find the dll again.

Loaded 64bit DW into 32bit DW, and got

Error: At least one module has an unresolved import due to a missing export function in an implicitly dependent module.
Error: Modules with different CPU types were found.
Warning: At least one delay-load dependency module was not found.
Warning: At least one module has an unresolved import due to a missing export function in a delay-load dependent module.

So, looks like missing XP compiler switches.

[Groucho2004]

Loaded 64bit DW into 32bit DW:confused:

[StainlessS]

Just a test to see if 64bit exe gave additional error messages about CPU, which it did (but additional not present for ffmsindex.exe, so assume is 32bit).

EDIT: Maybe a wrong assumption.

EDIT: Loading 32bit DW into 32bit DW,
Warning: At least one delay-load dependency module was not found.
Warning: At least one module has an unresolved import due to a missing export function in a delay-load dependent module.

No CPU warnings.

[TheFluff]

I have some foggy memory telling me that there's some LoadLibrary path customization thing that doesn't work on XP. Clearly you should just put everything into system32.

[StainlessS]

Just tried copying the ffmsindex.exe and ffms2_26.dl to system32, and repeat

ffmsindex.exe -k test.mpg

Same result, "ffmsindex.exe is not a valid Win32 application".

Thanx anyway Fluffy, but not of any great necessity for me, I've never attempted (prior to today) to use ffmsindex.exe on its own.

[Groucho2004]

I have some foggy memory telling me that there's some LoadLibrary path customization thing that doesn't work on XP. Clearly you should just put everything into system32.
LoadLibraryEx() (https://msdn.microsoft.com/en-us/library/windows/desktop/ms684179(v=vs.85).aspx) does support some flags that are not supported on XP/Server 2003. Without seeing the code we can of course only assume that this may be the problem.

[lansing]

Must be a broken mkv/ffmpeg bug. The parser really does report all the frames as keyframes. I'll poke it a bit more but definitely not my fault.

Any update on this issue? I have the same problem with a m2ts file, it's reporting keyframe every 24 frames. If it's a bug, where do I report it?

[george84]

Test5 and Test6 from first post not found on dropbox

[Atak_Snajpera]

Any update on this issue? I have the same problem with a m2ts file, it's reporting keyframe every 24 frames. If it's a bug, where do I report it?

What happens if you remux .m2ts to .mkv using eac3to?

[Myrsloik]

Download link fixed. No idea why dropbox decided to break it.

[Atak_Snajpera]

Does anybody know why ffms duplicates frames in Interlaced h.264 streams using Separated fields as store method?

video-Duplicated-frames.mkv
Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4
Format settings, CABAC : Yes
Format settings, RefFrames : 2 frames
Format settings, GOP : M=2, N=13
Muxing mode : Container profile=@0.0
Codec ID : V_MPEG4/ISO/AVC
Duration : 33 s 160 ms
Bit rate mode : Variable
Bit rate : 20.8 Mb/s
Maximum bit rate : 22.0 Mb/s
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 25.000 FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Interlaced
Scan type, store method : Separated fields
Scan order : Top Field First
Bits/(Pixel*Frame) : 0.400
Stream size : 82.0 MiB (98%)
Default : No
Forced : No


video-no-duplicated-frames.mkv
Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : Main@L4
Format settings, CABAC : Yes
Format settings, RefFrames : 2 frames
Format settings, picture structure : Frame
Muxing mode : Container profile=@0.0
Codec ID : V_MPEG4/ISO/AVC
Duration : 22 s 720 ms
Bit rate : 11.7 Mb/s
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 25.000 FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Interlaced
Scan type, store method : Interleaved fields
Scan order : Top Field First
Bits/(Pixel*Frame) : 0.226
Stream size : 31.7 MiB (98%)
Default : No
Forced : No
Color range : Limited
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709



https://www.mediafire.com/file/1o0bjcd9vlnoio1/FFMS%20bug.7z
Open video-Duplicated-frames.avs and video-no-duplicated-frames.avs in 32 bit MPC-HC and use combination CTRL+arrows to see what I mean.

[Myrsloik]

Hint: look at the known issues

[stax76]

I've reported this some years ago, my workaround:


Dim miFPS = MediaInfo.GetFrameRate(p.FirstOriginalSourceFile)
Dim avsFPS = p.SourceScript.GetFramerate

If (CInt(miFPS) * 2) = CInt(avsFPS) Then
Dim src = p.Script.GetFilter("Source")
src.Script = src.Script + BR + "SelectEven().AssumeFPS(" & miFPS.ToInvariantString + ")"
p.SourceScript.Synchronize()
End If

[Atak_Snajpera]

Yes I do the same if mediainfo reports Separated Fields.

[hello_hello]

Does anybody know why ffms duplicates frames in Interlaced h.264 streams using Separated fields as store method?

I wonder if that relates to the problem with enabling "rffmode" I've been experiencing.

I was fiddling around with the old FFMpegsource2 script (changing the function name to avoid conflicts) in order to enable audio by default, and I also set rffmode=1 as the default, but I discovered for progressive h264 it causes ffms2/ffms2000 to output half the source frame rate. For the sources I tested, Info() said the frame rate was 24000/2002 instead of 24000/1001 (with one exception where it reported 1.#inf (1/0) as the frame rate).
rffmode=0 fixed the problem.

[hello_hello]

While I'm here, although I probably don't care anyway, was the utf8=true/false argument removed from this version of ffindex/ffms2 for a reason? Just curious...

Cheers.

[Myrsloik]

While I'm here, although I probably don't care anyway, was the utf8=true/false argument removed from this version of ffindex/ffms2 for a reason? Just curious...

Cheers.

Yes, it was removed.

[burfadel]

Any new test versions? The test 6 is approaching 7 months old and I see there have been multiple commits :)

[Myrsloik]

Any new test versions? The test 6 is approaching 7 months old and I see there have been multiple commits :)

I guess I'll make one in a bit. Should have lots of interesting new bugs to find as well by now...

[burfadel]

Happy to test :)!

[stax76]

Me too, especially file extensions h264, h265 and ts.

[kypec]

I have been using FFMS2000 in VapourSynth until I found out recently that it is not reliable for MKV sources (https://forum.doom9.org/showthread.php?p=1820545#post1820545). :(
Luckily, L-SMASH replacement proved to be 100% deterministic so that's what I'm going to use further.

[Atak_Snajpera]

The only huge problem for me with newer versions of FFMS is broken seeking on VC-1 (each frame is detected as keyframe?!)

[Myrsloik]

New build

[Atak_Snajpera]

Great! This version fixes crashing on some .aac audio files!

[burfadel]

Has worked so far here great as well!

[AKBabel]

Hi to all,
I am new here, but I have used avisynth for a couple of years now and coded some filters for it.
So in the past it was possible to load DPX image files (10Bit per channel) into avisynth via FFImageSource, that doesn’t work anymore with FFMS2000 and avisynth+.
I have tried to load them via FFVideoSource and that works, but the output is RGB32 instead of RGBP10 or other higher bit depth formats.
Also FFMS2000 seems not to support DNG files.
Is it possible to find some solutions for this problems?

[Myrsloik]

Hi to all,
I am new here, but I have used avisynth for a couple of years now and coded some filters for it.
So in the past it was possible to load DPX image files (10Bit per channel) into avisynth via FFImageSource, that doesn’t work anymore with FFMS2000 and avisynth+.
I have tried to load them via FFVideoSource and that works, but the output is RGB32 instead of RGBP10 or other higher bit depth formats.
Also FFMS2000 seems not to support DNG files.
Is it possible to find some solutions for this problems?

Loading dpx should work. Can I have a simple file? Which is the most recent FFMS2 version where it worked?

Did DNG ever work in any FFMS2 version?

[AKBabel]

I have tried to open the DPX files directly in VirtualDub Mod, it seems to work, they are interpreted as RGBA64.
If I encode them as ffv1 in mkv container, I can load that mkv into VirtualDub, same result RGBA64.
But when I open the DPX files through FFMS2000 they are interpreted as RGB32.
Here is a file: https://www.file-upload.net/download-12842158/NEH183trim2_0974533.DPX.html

I'll try to found out, which version it was, that could open them via FFImageSource().

Did DNG ever work in any FFMS2 version?No, DNG was never supported by FFmpeg. I found that out recently.
I still hope that it may happen too.

[AKBabel]

Loading dpx should work. Can I have a simple file? Which is the most recent FFMS2 version where it worked?
I have checked.
The version where FFImageSource could open DPX is 2.17.0.0 (obviously it returns RGB32).
When trying to open DPX with FFImageSource from FFMS2000, it returns the Error:
FFVideoSource does not have a named argument ''utf8''

[Myrsloik]

I have tried to open the DPX files directly in VirtualDub Mod, it seems to work, they are interpreted as RGBA64.
If I encode them as ffv1 in mkv container, I can load that mkv into VirtualDub, same result RGBA64.
But when I open the DPX files through FFMS2000 they are interpreted as RGB32.
Here is a file: https://www.file-upload.net/download-12842158/NEH183trim2_0974533.DPX.html

I'll try to found out, which version it was, that could open them via FFImageSource().

No, DNG was never supported by FFmpeg. I found that out recently.
I still hope that it may happen too.

You didn't update ffms2.avsi. The utf8 argument was removed.

[18fps]

I have checked.
The version where FFImageSource could open DPX is 2.17.0.0 (obviously it returns RGB32).
A single DPX image or a DPX images sequence?

[AKBabel]

You didn't update ffms2.avsi. The utf8 argument was removed.
Now I have done that. So it works with FFImageSource now, but the result is still RGB32.
A single DPX image or a DPX images sequence?
It is a sequence but I use a GScript to load them via FFImageSource.

[poisondeathray]

@AKBabel -
In the meantime, you could use FFMS2 in vapoursynth which supports RGB30 and image sequences with python , or imagemagick plugin for vapoursynth which will return RGB float

Since FFMS2 in vpy supports it properly , and avisynth+ supports "RGBP10" , I suspect it should be possible

PS. can you post your GScript image sequence loader script ? How is the performance / seeking latency ?

[lansing]

With the test7 version, I have a animation vob file that was being auto ivtced to 23.976fps on load, but other similar vobs were unaltered. Issue exist in both avs+ and vapoursynth.

ffms2('sample.vob')

[Myrsloik]

With the test7 version, I have a animation vob file that was being auto ivtced to 23.976fps on load, but other similar vobs were unaltered. Issue exist in both avs+ and vapoursynth.

ffms2('sample.vob')

See rff handling and soft telecine

[AKBabel]

PS. can you post your GScript image sequence loader script ? How is the performance / seeking latency ?

This is the script:
inf=FFImageSource(dir+filename+String(startframe, lcdigits)+filetype)
v_width = inf.Width
v_height = inf.Height
v_type = inf.PixelType
video = BlankClip((endframe-startframe), v_width, v_height, pixel_type=v_type).KillAudio()
video = video.ScriptClip("""FFImageSource(String(current_frame+startframe, dir+filename+lcdigits)+filetype)""")

It is really slow. I guess there are better options, but I only had to deal with short sequences until now. So if you have tips, please tell me.

[lansing]

See rff handling and soft telecine
##### int rffmode = 0

- **0**: Ignore all flags (the default mode).
- **1**: Honor all pulldown flags.
- **2**: Equivalent to DVD2AVI's "force film" mode.
It was already default to 0, but it still ivtc my video. Setting it to 1 would ignore the flag instead. Is it the problem with the dvd itself?

[TheFluff]

##### int rffmode = 0

- **0**: Ignore all flags (the default mode).
- **1**: Honor all pulldown flags.
- **2**: Equivalent to DVD2AVI's "force film" mode.
It was already default to 0, but it still ivtc my video. Setting it to 1 would ignore the flag instead. Is it the problem with the dvd itself?

There is no problem, it's doing exactly what the manual says its supposed to be doing, you just got the meaning of "ignore pulldown flags" backwards. Soft telecined DVD's using RFF flags ("pulldown flags") only have 23.976 coded progressive pictures per second in the stream. An analog NTSC TV can't play 23.976fps progressive so the player telecines on-the-fly on playback by outputting some fields twice. Which fields it repeats is controlled by the "repeat field flag", RFF - each frame has a flag that can say repeat top or repeat bottom field. FFMS2 defaults to ignoring these flags (that is, it doesn't duplicate fields) and showing you the coded progressive frames only. If you want to load the VOB in telecined form (sometimes desirable if it's hybrid material and you want to do IVTC with postprocessing yourself) you tell it to honor the RFF flags.

Most DVD's are hard telecined and actually have 29.97 coded fields per second instead, but no RFF flags so there's nothing to ignore.

[Atak_Snajpera]

Would be possible to have those options available in ffms2 for HDR to SDR conversion?
https://ffmpeg.org/ffmpeg-filters.html#tonemap

[Myrsloik]

Would be possible to have those options available in ffms2 for HDR to SDR conversion?
https://ffmpeg.org/ffmpeg-filters.html#tonemap

No, that's format conversion and not decoding. If you read the fine print you realize it's a wrapper for zimg.

[lansing]

Does the "missing frames here and there" issue from decoding ts file only happen on seeking. I have this problem when decoding a specific part of a m2ts file and wonder if it will affect encoding.

[Myrsloik]

Does the "missing frames here and there" issue from decoding ts file only happen on seeking. I have this problem when decoding a specific part of a m2ts file and wonder if it will affect encoding.

Yes, probably. At least 99% of all the missing frame issues happen around seeking.

[Myrsloik]

Test8 released. Link in the first post. The two new interesting improvements (apart from fresh ffmpeg) are:
- Fixed issue with dropped/repeated frames in vc1 with multiple b-frames after seeking (Myrsloik)
- Fixed issue with dropped/repeated frames in h264 when the reorder buffer size is too small (Myrsloik)

[Atak_Snajpera]

Interesting ;) I was experiencing those two bugs in my Distributed Encoding mode (This mode exposes immediately any issues with seeking). Last working version was 2.20.

[real.finder]

Test8 set the RIP for winxp now :devil: Test7 was work fine

[FranceBB]

Test8 set the RIP for winxp now :devil: Test7 was work fine

Same on my machine, running Windows XP Professional x86.
Test7 was working, Test8 doesn't work on XP.

[real.finder]

Same on my machine, running Windows XP Professional x86.
Test7 was working, Test8 doesn't work on XP.

I test it in VirtualBox actually, I have winxp in it for some playing around and nostalgia for the past

[TheFluff]

ffmpeg finally voted to drop Windows XP support completely a few weeks ago and I think the first patches that require Vista+ (http://ffmpeg.org/pipermail/ffmpeg-devel/2017-December/222774.html) have already been merged. It's not really possible to keep FFMS2 XP compatible anymore even if you wanted to, and I'm pretty sure Myrsloik really doesn't want to.

[FranceBB]

According to Dependency Walker, test8 binary uses a few kernel calls that are not available in XP, such as: AcquireSRWLockExclusive, InitOnceBeginInitialize, InitOnceComplete, InitializeConditionVariable, InitializeSRWLock, ReleaseSRWLockExclusive, SleepConditionVariableSRW, WakeAllConditionVariable, WakeConditionVariable.

[TheFluff]

Yeah, that's the new ffmpeg threading code (the patchset I linked in the previous post). They cleaned up some locking stuff and in the process removed the Win32 backwards compatibility stuff they had so it doesn't work with XP anymore. Not much ffms2 can do about it.

[lvqcl]

I think the first patches that require Vista+ have already been merged.

Yes, a week ago: http://git.videolan.org/?p=ffmpeg.git;a=commit;h=9b121dfc32810250938021952aab4172a988cb56

[poisondeathray]

1) ffms2000-test8 , test7 cannot read a simple PNG(RGBA) in MOV for either x86/x64 avs or x64 vpy , for either the main track or alpha . (neither can ffms2-2.23.1-msvc)
"no video track found"

But ffms2-2.23-clang can read it

sample
http://www.mediafire.com/file/h4e0fcprxzwaed1/spinning_dollar_sign_PNG.mov

[Myrsloik]

I have tried to open the DPX files directly in VirtualDub Mod, it seems to work, they are interpreted as RGBA64.
If I encode them as ffv1 in mkv container, I can load that mkv into VirtualDub, same result RGBA64.
But when I open the DPX files through FFMS2000 they are interpreted as RGB32.
Here is a file: https://www.file-upload.net/download-12842158/NEH183trim2_0974533.DPX.html

I'll try to found out, which version it was, that could open them via FFImageSource().

No, DNG was never supported by FFmpeg. I found that out recently.
I still hope that it may happen too.

Can't reproduce this. I did notice that some output formats like RGBP10 were missing (recently added to FFmpeg) so I added those. Bot opening you FFMS2 and FFImageSource works like it should. Try the next build and see I guess. Avs+ seems to have a weird error for unsupported output formats in vfw though but that's a different issue.

[Myrsloik]

1) ffms2000-test8 , test7 cannot read a simple PNG(RGBA) in MOV for either x86/x64 avs or x64 vpy , for either the main track or alpha . (neither can ffms2-2.23.1-msvc)
"no video track found"

But ffms2-2.23-clang can read it

sample
http://www.mediafire.com/file/h4e0fcprxzwaed1/spinning_dollar_sign_PNG.mov

That's just me forgetting to compile ffmpeg with zlib. Will do that next time.

[real.finder]

That's just me forgetting to compile ffmpeg with zlib. Will do that next time.

what about make test9 work for xp as last version that work with xp? I don't really use xp now except in VirtualBox, but you will make xp users happy for once

[sneaker_ger]

XP users can get this (https://forum.doom9.org/showthread.php?t=175173). From what I understand ffms2000 changes are included as they've been merged with the main ffms2 branch.

[Myrsloik]

what about make test9 work for xp as last version that work with xp? I don't really use xp now except in VirtualBox, but you will make xp users happy for once

This was discussed in the main FFmpegSource thread. FUCK XP USERS. Also FFmpeg dropped support for XP. I hope someone hacks your ancient VM.

XP support was officially discontinued in FFMS2 several years ago.

[real.finder]

XP users can get this (https://forum.doom9.org/showthread.php?t=175173). From what I understand ffms2000 changes are included as they've been merged with the main ffms2 branch.

it's c one not c++, it will not autoload in old avs and some users has another problems with c plugins

I hope someone hacks your ancient VM.


lol :D

[StainlessS]

I have cast a spell against all XP haters, your jacksies will all heal up within the next 6 months,
its gonna be awful, but me guesses that you will not repeat the offence.
Love & Kisses, one, XP o-phile

[Groucho2004]

it's c one not c++, it will not autoload in old avs and some users has another problems with c pluginsCan you point out what problems users have with C-plugins?

[sneaker_ger]

it will not autoload in old avs
Can't you just make an "autoload_ffms.avsi":
loadcplugin("ffms2.dll")
?

[real.finder]

Can you point out what problems users have with C-plugins?

like sometimes it won't load with loadcplugin and need to use Load_Stdcall_plugin instead, and not everyone knows this

Can't you just make an "autoload_ffms.avsi":
loadcplugin("ffms2.dll")
?

I already know this

[Groucho2004]

like sometimes it won't load with loadcplugin and need to use Load_Stdcall_plugin instead, and not everyone knows thisI suppose you're referring to this (https://forum.doom9.org/showthread.php?p=1776218#post1776218) nuisance?

[real.finder]

I suppose you're referring to this (https://forum.doom9.org/showthread.php?p=1776218#post1776218) nuisance?

yes, some people have avisynth_c.dll in their autoload so that will happen

[Atak_Snajpera]

I think I found a bug in TrueHD 7.1 decoding.
Audio is playing too fast. If I convert .thd to .w64 or .flac with eac3to then everything is ok.
http://www.mediafire.com/file/73sau01zs1w6c8w/TrueHD_BUG.7z

[Myrsloik]

I think I found a bug in TrueHD 7.1 decoding.
Audio is playing too fast. If I convert .thd to .w64 or .flac with eac3to then everything is ok.
http://www.mediafire.com/file/73sau01zs1w6c8w/TrueHD_BUG.7z

Did you compare with a recent ffmpeg?

[Atak_Snajpera]

Are you sure it's an ffmpeg problem and not with your Convert8chTo2ch() function?

No problem:
v=BlankClip(fps=25, length=10000)
a=ffaudiosource("1_audio_English.thd")
AudioDub(v, a)
GetChannel(3)


Without downmix I get A/V issues in encoded file. Besides, everything works fine with 7.1 .w64 and 7.1 .flac. This only happens with TrueHD. DTS-MA is also working fine.

[sneaker_ger]

And your 7.1 w64 and flac are also 8 channel 48kHz 32 bit integer?

[Atak_Snajpera]

Both 16 bit and 24 bit are working fine. (w64 and flac)

Did you compare with a recent ffmpeg?
Test8 does the same.

[Myrsloik]

Both 16 bit and 24 bit are working fine. (w64 and flac)


Test8 does the same.

I said FFmpeg. As in ffmpeg.exe. The audio logic is basically untouched the past 3+ years in ffms2...

[sneaker_ger]

Something very weird with this. The problem only happens when using your downmixing script. Without it the output is fine (just like with ffmpeg). Maybe the conversion seeks in the audio or something like that? And it's not happening with linear conversion?

[Atak_Snajpera]

Who knows maybe seeking is broken while decoding TrueHD ...

[`Orum]

Does this filter support frame-accurate seeking? That was always my beef with the original FFMS2 filter...

[sneaker_ger]

Supposed to: yes. Does it always work? Maybe not. There is no guarantee. But some issues have been fixed (and this branch has now been merged into main ffms2). If you find a sample that poses a problem make a report on the issue tracker (https://github.com/FFMS/ffms2/issues) (incl. the sample).

[poisondeathray]

threads=1, seekmode=0 might help with frame accurate seeking for some types of files

[`Orum]

Thanks, I'll give it a try. On another note, was there a reason the filter name (not the DLL file name, that can easily be renamed) wasn't changed with this release? I'd like to run some side-by-side tests (though to be fair they're not that useful with the lack of accurate seeking in the original FFMS2), but with the same filter name for both, I'm not sure that it's possible.

Maybe with two different scripts each using LoadPlugin() and then Import()ing them into one script? Though I'm not sure that will work either, as I think Import() effectively just adds the text of the other scripts.

[poisondeathray]

Maybe with two different scripts each using LoadPlugin() and then Import()ing them into one script? Though I'm not sure that will work either, as I think Import() effectively just adds the text of the other scripts...

This should work , explicitly loading the version - but make sure your autoload plugin is clear of ffms2.dll versions

Import() will load the script as a "video", if that script referenced a source filter which loaded a video

But I'm not 100% clear how that is affected when you have multiple versions of ffms2 loaded at the same time; maybe it defaults to one or the other ? I would expect the explict loading should be correct, but not sure about that... Or another way is to encode them to lossless intermediates then compare

[`Orum]

But I'm not 100% clear how that is affected when you have multiple versions of ffms2 loaded at the same time; maybe it defaults to one or the other ? I would expect the explict loading should be correct, but not sure about that... Or another way is to encode them to lossless intermediates then compare
Well, I would think that trying to load two different filters in AviSynth with the same name would cause some sort of error, but I've never tried.

On a similar vein, where is the source for this? It's GPL'ed, but I don't see links to his refactored code, and it's not included in the release archive. He has links to the original repo only.

[poisondeathray]

Couldn't you just rename the dll? ffms2_v2.dll, ffms2_v3.dll etc...

I don't know where source is, maybe in Myrsloik's head :devil:

[`Orum]

Couldn't you just rename the dll? ffms2_v2.dll, ffms2_v3.dll etc...

Yeah, I've already renamed the DLL, but running into another problem. The original ffms2 DLL is in the autoload path, and I can't remove it as I have another encode going (that's not even actually using it, but it was autoloaded!). I don't want to terminate this encode as that results in lots of time lost, and there's no "UnloadPlugin()" function in AviSynth+.

Oh well, I'll just wait until my encode finishes to try it out.

[VS_Fan]

I don't know where source ishttps://github.com/FFMS/ffms2/tree/ffms2000

[`Orum]

Ah, thanks for the link. Unfortunately, I can't get frame-accurate seeking with this even when the video is in a matroska container. Well, maybe with seekmode=0, but that's so slow it's unusable for my test cases. Unfortunately I won't be able to upload the sample either, as it's both copyrighted and large.

I'll see if I can create another file that demonstrates the problem, that's both copyright free and of a more practical size.

[Myrsloik]

https://github.com/FFMS/ffms2/tree/ffms2000

That's not the latest source. As has been said it was merged with master.

[`Orum]

Okay, I think I've discovered what's causing the seeking issues. The mkv with the problem was muxed by eac3to, and MediaInfo reports the muxing library as: Haali DirectShow Matroska Muxer 1.13.138.14. This appears to seek properly with LWLibAVVideoSource(), but not with FFVideoSource().

If, however, I remux that file via MKVToolNix (I have v20 installed right now), and use that with FFVideoSource(), it appears to offer frame-accurate seeking! MediaInfo obviously reports the more official library that MKVToolNix uses: libebml v1.3.5 + libmatroska v1.4.8. Is the Haali DS MKV Muxer really that "bad"? Does it not generate indices or something? Why does LWLibAVVideoSource() apparently seek that correctly, but FFVideoSource() won't?

Another interesting thing came up as well. I'm looking at frame types (I guess more commonly referred to as "picture type") from both LWLibAVVideoSource()'s cache file (which appear to be the "Pic=" value), as well as those reported by FFVideoSource() (via its FFPICT_TYPE variable), but they don't agree. I'm not even sure which is right at this point, so is there some unambiguous way to determine what picture type a frame actually is? Then I'll at least know in which filter the error lies.

[Myrsloik]

Okay, I think I've discovered what's causing the seeking issues. The mkv with the problem was muxed by eac3to, and MediaInfo reports the muxing library as: Haali DirectShow Matroska Muxer 1.13.138.14. This appears to seek properly with LWLibAVVideoSource(), but not with FFVideoSource().

If, however, I remux that file via MKVToolNix (I have v20 installed right now), and use that with FFVideoSource(), it appears to offer frame-accurate seeking! MediaInfo obviously reports the more official library that MKVToolNix uses: libebml v1.3.5 + libmatroska v1.4.8. Is the Haali DS MKV Muxer really that "bad"? Does it not generate indices or something? Why does LWLibAVVideoSource() apparently seek that correctly, but FFVideoSource() wont?

Another interesting thing came up as well. I'm looking at frame types (I guess more commonly referred to as "picture type") from both LWLibAVVideoSource()'s cache file (which appear to be the "Pic=" value), as well as those reported by FFVideoSource, but they don't agree. I'm not even sure which is right at this point, so is there some unambiguous way to determine what picture type a frame actually is? Then I'll at least know in which filter the error lies.

Yes, the haali muxer is known to be broken and discontinued for a very long time. Mkvtoolnix is the only thing you should ever use.

[`Orum]

Yes, the haali muxer is known to be broken and discontinued for a very long time. Mkvtoolnix is the only thing you should ever use.
AFAIK though eac3to doesn't support using a mkv muxer other than Haali's, unfortunately. I guess it's just one more headache to deal with when you have to work with playlists (playlist -> mkv via eac3to -> mkv via mkvtoolnix).

[Myrsloik]

AFAIK though eac3to doesn't support using a mkv muxer other than Haali's, unfortunately. I guess it's just one more headache to deal with when you have to work with playlists (playlist -> mkv via eac3to -> mkv via mkvtoolnix).

Not my problem, the age of the all encompassing GUIs ended over 10 years ago. No dogs or dinosaurs allowed in the park.

[`Orum]

Not my problem, the age of the all encompassing GUIs ended over 10 years ago. No dogs or dinosaurs allowed in the park.
Not sure what GUIs have to do with it (as eac3to is a command-line program), but is there any chance of getting playlist support in FFMS2? Otherwise eac3to is still a necessary evil.

[Myrsloik]

Not sure what GUIs have to do with it (as eac3to is a command-line program), but is there any chance of getting playlist support in FFMS2?

No, never. There's already another plugin that loads playlists (https://github.com/HomeOfVapourSynthEvolution/VapourSynth-ReadMpls) you can use.

[`Orum]

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.

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