FFMS2000 - The experimental future of FFMS2

[Myrsloik]

Originally Posted by 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

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]

Originally Posted by 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 ?

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]

Originally Posted by 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)?

You mean the stuff added in this commit? 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]

Originally Posted by 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.)

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]

Originally Posted by Myrsloik

I posted test2 NOW WITH 100% MORE XP HATE!

but it's still work in xp

[raffriff42]

Originally Posted by MysteryX

Only on doom9 you'll hear of 2000 as being the future

2000 still sounds impossibly futuristic. I can't get used to it.

In The Year 2000

[Myrsloik]

Originally Posted by 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.

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]

Originally Posted by Myrsloik

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]

Originally Posted by Groucho2004

Why would a user who for example just wants to decode a BD source care what compiler was used?

Originally Posted by Myrsloik

There's a known speed difference between compilers. That's why.

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

Originally Posted by Myrsloik

My test builds are never compiled for speed.

That makes more sense.

[Myrsloik]

Originally Posted by Groucho2004

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)