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.