FFmpegSource

[smok3]

Thanks,
LSMASHVideoSource("cineform.mov", format = "YUV420P8")
did the trick.
p.s. And yes I admit the research laziness to anything windows related.

[shekh]

@LigH: thanks, but getting only some green stuff (http://shrani.si/f/1x/zp/2LLNmn6C/capture.png) in vdub window (LSMASHVideoSource and LwLibavVideoSource).
I've tested prores and cineform. Ideas? (win 7)

If you just want to pull it into vdub, you may just use my pack.
It does both vfw decoding (ffmpeg select..) and ffmpeg decoding (ffmpeg all..)

[smok3]

@shekh, Thanks, bookmarked, installed, tested. (Actually I was trying to review some of my old x264 encoding scripts, but after looking at that bat mess, mission aborted).

[feisty2]

is it possible to get the QP value of each frame for lossily compressed videos and tag that as some frame property (in vaporsynth)?
I want it cuz I want denoisers to have a self adaptive denoising strength on each individual frame

[LigH]

Great thinking, feisty2; it reminds me on my failed attempt to convince Donald Graft to implement Deblock() into his DG*Decode plugins. I lacked of technical details to explain it convincingly enough.

I remember some AviSynth plugins do use auxiliary "hint" channels to share a few details (e.g. TFM with TIVTC, or MPEG2Source(info=3) with ColorMatrix). But I have no idea how useful that is compared with the VapourSynth design; and they seem to be rather per-clip than per-frame, at least in these examples.

[StainlessS]

If they (frame properties) could accessed in advance, could be written to RT_Stats DBase (or Array) and accessed via Avisynth ScriptClip (or similar, and presumably VapourSynth), for use on frame by frame basis. Depends upon whether or not there is some tool to extract the data in the first place.

[Myrsloik]

is it possible to get the QP value of each frame for lossily compressed videos and tag that as some frame property (in vaporsynth)?
I want it cuz I want denoisers to have a self adaptive denoising strength on each individual frame

I will check to see if this information is still exposed in ffmpeg. I know they've done a lot of cleanups so it may or may not still be available.

[manolito]

@qyot27

Don't know if this is the appropriate thread for my question, but you are probably the one who can answer it...

Using the current FFmpeg version 3.1.2 (rogerdpack build for WinXP) I get a crash immediately if the input is an AVS script. The culprit is autoloading C-Plugins from the AviSynth\plugin folder.

For a long time I have autoladed C-Plugins like your ffms2 or Yadif by using an AVSI which loads the C-Plugin (your ffms2.avsi does this). This has always worked flawlessly until I tried to use FFmpeg v 3.1.2. The previous version by rogerdpack from July 2016 has no problems.

My AviSynth version is the plain vanilla 2.60 which can hardly be considered outdated. What did the FFMpeg devs change to cause this problem? Do I have to use AviSynth+ now to get FFMpeg to work?


Cheers
manolito

[qyot27]

@qyot27

Don't know if this is the appropriate thread for my question, but you are probably the one who can answer it...

Using the current FFmpeg version 3.1.2 (rogerdpack build for WinXP) I get a crash immediately if the input is an AVS script. The culprit is autoloading C-Plugins from the AviSynth\plugin folder.

For a long time I have autoladed C-Plugins like your ffms2 or Yadif by using an AVSI which loads the C-Plugin (your ffms2.avsi does this). This has always worked flawlessly until I tried to use FFmpeg v 3.1.2. The previous version by rogerdpack from July 2016 has no problems.

My AviSynth version is the plain vanilla 2.60 which can hardly be considered outdated. What did the FFMpeg devs change to cause this problem? Do I have to use AviSynth+ now to get FFMpeg to work?


Cheers
manolito
I'm not sure, exactly, but I can reproduce the behavior (with both 2.6 and Plus, so it wouldn't matter there). My guess is that there was something regarding DLL loading security - it may or may not have been in the libavformat AviSynth demuxer itself - that makes it to where AviSynth's plugins won't load if the directory they're in isn't on Windows' PATH. Or if C++ plugins were fine, it may have specifically been because the C plugins were being stored in a different folder than the others (meaning C plugins need to be on the PATH in this scenario, but C++ ones don't).

Correspondingly, if I add the folder that ffms2.dll / FFMS2.avsi / ffmsindex.exe reside in to the PATH, the issue goes away.

I'd actually had a nasty registry corruption issue on my WinXP machine not too long ago, so my plugins folder had disappeared from the PATH and I was hitting the problem. When I tried to use ffmsindex and it told me it couldn't see it, I pretty much realized what was going on. Added the plugins folder to the PATH, tried again, no problems with either 2.6 or Plus.

[manolito]

Thanks qyot27 for the quick reply.

Unfortunately including the "AviSynth\plugins" folder in my path does not make a difference. FFMpeg still crashes (called by AVStoDVD) with a message that Yadif cannot be loaded. If I remove Yadif from the plugins folder, I get the same message about ffms2.

I can live without Yadif, but ffms2 is essential for my workflows. And since the scripts are automatically created by AVStoDVD I do need ffms2 to be autoloaded.


Thanks and cheers
manolito

[qyot27]

Does it error out when not called by AVStoDVD but the folder is on the PATH?

You can try this build of FFmpeg. It's the same one I used to test:
http://www.mediafire.com/download/b588msbb584cp8e/ffmpeg_r81319.7z

If that one works, then it may be a compiler issue or a configuration issue with the build itself.

[Atak_Snajpera]

Guys what do you do to have correct colors with UHD HDR in FFMS2

MPC-HC
http://i.cubeupload.com/vHjdsr.png

FFMS2
http://i.cubeupload.com/H4Nr9m.png

Sample is here -> http://demo-uhd3d.com/fiche.php?cat=uhd&id=144

[manolito]

Does it error out when not called by AVStoDVD but the folder is on the PATH?

You can try this build of FFmpeg. It's the same one I used to test:
http://www.mediafire.com/download/b588msbb584cp8e/ffmpeg_r81319.7z

If that one works, then it may be a compiler issue or a configuration issue with the build itself.


Thanks for this FFmpeg build, but unfortunately it makes no difference. Even when I call FFmpeg outside of AVStoDVD and the AviSynth\plugins folder is in the path, I still get this error message:

E:\Programme\AVStoDVD\FFmpeg>ffmpeg.exe -i f:\download\test.avs i:\test.mpg
ffmpeg version r81319 git-8e8aff8 Copyright (c) 2000-2016 the FFmpeg developers
built on Aug 9 2016 23:50:26 with gcc 6.1.0 (GCC)
libavutil 55. 28.100 / 55. 28.100
libavcodec 57. 51.100 / 57. 51.100
libavformat 57. 46.100 / 57. 46.100
libavdevice 57. 0.102 / 57. 0.102
libavfilter 6. 50.100 / 6. 50.100
libavresample 3. 0. 0 / 3. 0. 0
libswscale 4. 1.100 / 4. 1.100
libswresample 2. 1.100 / 2. 1.100
libpostproc 54. 0.100 / 54. 0.100
[avisynth @ 039589a0] Unable to load C Plugin: "yadif.dll", error=0x7e
(YADIF.avsi, line 1)
f:\download\test.avs: Unknown error occurred

This is my PATH variable:
PATH=E:\Windows\system32;E:\Windows;E:\Windows\system32\WBEM;"E:\Programme\DVD2SVCD\AviSynth 2.5\plugins"

YADIF.avsi consists of just this line:
LoadCPlugin("yadif.dll")

And after removing YADIF from the AviSynth\plugins folder I get the same error for ffms2.


Cheers
manolito

[qyot27]

Why are there " around the path to the plugins folder in the PATH variable? Those are only necessary in the Command Prompt, PATH should properly recognize it without them.

[manolito]

Thanks for pointing this out, I did not know this. I did test if the path variable worked by copying a standalone executable into the AviSynth\plugins folder and calling this executable from a different drive and path. Which worked...

After removing the double quotes FFmpeg does behave differently. Calling FFMpeg with an AVS script as the input directly outside of AVStoDVD now works, but as soon as AVStoDVD calls FFmpeg it does crash again. Very strange...


Cheers
manolito


//EDIT//
The rogerdpack build 3.1.2 behaves exactly the same as your build.

[dipje]

Guys what do you do to have correct colors with UHD HDR in FFMS2

MPC-HC
...image...

FFMS2
...image...

Sample is here -> http://demo-uhd3d.com/fiche.php?cat=uhd&id=144

Just guessing here, but I'm thinking you would need to assume the input is in something like the bt2020 colorspace and you need to convert it / scale it down to whatever you want to encode to or display.. something like bt709/rec709... 'srgb'..

I'm guessing MPC-HC reads or assumes the correct colorspace and converts it while displaying (And thus while making screenshots), and ffms2 just assumes either bt601 or bt709 not doing anything with bt2020 or whatever your hdr vid is in?

edit: As I'm really new to the whole HDR movement and standards I decided to see and try for myself. Downloaded the sample, as well as the 'SDR' version of it.
First things first, I have not managed to replicate the look of the SDR version yet. It seems as if it received exposure changes in editing or something.

Second, I found that frame you posted (around frame no. 3850 in the HDR version, around 1m04 right?) and tested myself. My MPC-HC (and I took the latest nightly to be sure) does not look like your MPC-HC version at all.
My MPC-HC looks like your ffms2 so to speak. It's also the same as ffmpeg / ffplay displays it.

Third, not knowing the standards, (and seeing it is YUV 420 10bit) I was assuming BT2020 matrix - tv range, 2020-10 transfer curve and 2020 primaries. But that doesn't look any better.
The best I can get the HDR version to look (and close to your MPC-HC screenshot) is by assuming it's in BT2020 matrix - tv range, SMPTE 2084 transfer, DCI P3 primaries (although 2020 primaries look close as well).
ffprobe also reports "tv-range, bt2020nc/bt2020/smpte2084".

Since I do stuff in vapoursynth, I end up with something like this:
c = core.lsmas.LWLibavSource(source = r'Sony_4K_HDR_Camp.mp4')

c = core.fmtc.resample(c, w = 1280, h = 720, css = '444', kernel = 'spline36')

c = core.fmtc.matrix(c, mat = "2020", fulls = False, fulld = True, col_fam = vs.RGB)
c = core.fmtc.transfer(c, transs = "2084", transd = "linear", cont = 10)
c = core.fmtc.primaries(c, prims = "dcip3", primd = "709")
c = core.fmtc.transfer(c, transs = "linear", transd = "srgb")


I sample it down to 720p for testing, but I make it YUV 4:4:4 (and fmtconv scales it to 16bit at the same time). I then convert it to 16 bit RGB assuming BT2020 YUV matrix, then I convert it to RGB linear-light assuming smpte 2084 transfer curve. The 2084 curve in fmtconv is scaled to 10000nits while the HDR spec seems to use 1000nits, so the 'cont = 10' at the end scales it all down. Once in linear-light you convert the color primaries to rec709, and finally go from linear-light RGB back to regular srgb-gamma.

The colors and contrast seem to be OK (or ok-ish) but generally I think it's too dark. I don't know if I'm using a wrong curve somewhere or just need to boost the brightness

edit 2: I got the look you were giving in your MPC-HC screenshots by using latest madVR. Looking in the settings and the release description for 'madvr hdr' I get a feeling for what they're doing , and it's no wonder I can't get a 1-to-1 result. Thinking about all this, I'm actually quite happy with how far I got :P (which is the above script but with 2020 primaries instead of dcip3, and the final transfer target not being srgb but also 709. I then use core.std.Levels to boost the gamma and ended up with something like 1.5 to 1.8 that looks nice).
MadVR is doing all sort of dynamic stuff, not simple conversion. I compress the shadows and the highlights, and it has a 'over saturation' protection that tries to preserve the hues when the brightness gets higher.

So madVR is not doing just simple gamma and color-gamut conversions, but has more advanced stuff going on to try to preserve as much detail and get the 'intent' of the HDR data displayed on regular screens. I don't think you will get a 1-to-1 result until someone ports the madvr algo's over into a vapoursynth (or avisynth) plugin :)

[kolak]

ffpmpeg has just got MOV edit list support, so I assume this will also come one day to ffms2?

[burfadel]

I hope ffms2 is still being developed. It actually works better than LSmash-Works for some things, and LSW better for other things. Together, they cover most source files. I did have issues with LSW and ffms2 with .wmv files a couple of weeks ago, but dss2 source worked for those.

[18fps]

I hope ffms2 is still being developed.

Looking at the GitHub it looks like it is developed. But windows binaries are not being produced. I'm stuck with 2.18 since 2.20 can't open prores's movs.

[Myrsloik]

Looking at the GitHub it looks like it is developed. But windows binaries are not being produced. I'm stuck with 2.18 since 2.20 can't open prores's movs.

The problem is mostly that all developers hate developing FFMS2. Me included, and I even started it. It's just no fun because changing one line of code takes 5 min of thinking and then 10+ hours of testing. Because that's how fragile the thing is.

And even if everything works chances are good FFmpeg will change its own behavior next week anyway. Things like this is why I'd rather spend my time on VapourSynth or even my real job which feels more rewarding than this. I tried to compile a new binary yesterday but ragequit because of msys. That's how annoying it is just to compile it...

[qyot27]

And I've not gotten back to building the C plugin because sometime between December and May(-ish), something started causing Access Violations and I've not had the patience to attempt bisecting it.

I'm pretty sure issue #260 is actually the same GCC weirdness that I finally got to the bottom of in this thread (http://forum.doom9.org/showthread.php?p=1779858#post1779858). Or it stems from the change in the symbol trickery ifdef @Ln.67 in ffms.h to assuming _WIN32 vs. MSC_VER like it used to (the C plugin branch preserves it as MSC_VER because it breaks compilation of the C plugin otherwise). Or even both if we're talking about a 64-bit build here.

[Myrsloik]

And I've not gotten back to building the C plugin because sometime between December and May(-ish), something started causing Access Violations and I've not had the patience to attempt bisecting it.

I'm pretty sure issue #260 is actually the same GCC weirdness that I finally got to the bottom of in this thread (http://forum.doom9.org/showthread.php?p=1779858#post1779858). Or it stems from the change in the symbol trickery ifdef @Ln.67 in ffms.h to assuming _WIN32 vs. MSC_VER like it used to (the C plugin branch preserves it as MSC_VER because it breaks compilation of the C plugin otherwise). Or even both if we're talking about a 64-bit build here.

I'm curious, will you continue with your own fork if I add proper avs+ high bitdepth support?

[qyot27]

My work C-plugin side is near entirely to do with being able to build the plugin with GCC, because that allows it to easily fit into the rest of my cross-compilation environment (and keeps the number of things I have to use Visual Studio for to an absolute minimum).

[Myrsloik]

Have a current 64bit build (https://dl.dropboxusercontent.com/u/73468194/ffms2-2016-10-03.7z). Adds high bitdepth output for avs+. Enjoy broken 10bit files or force the output colorspace to YUV420P16 or whatever. May shit itself unless you use the latest avs+mt build. Or maybe not. I didn't test it.

Should be safe for VS use without disclaimers.

[Myrsloik]

Here's a combined 32 and 64 bit (https://dl.dropboxusercontent.com/u/73468194/ffms2-2016-10-07.7z) build.

Consider it RC level. It removes one horrible hack that broke a lot of files in the past so retest anything that wasn't working before (especially lossless codecs).

Since threads this size are horrible to navigate START CREATING PROPER ISSUES IN GITHUB. And host sample files where they can be found for a long time. That really helps.

I will from now on only investigate issues brought to my attention on the issue tracker or on IRC. Navigating this thread is impossible.

[Abs62]

Myrsloik
Where I can take avisynth.h to compile last git version? VideoInfo struct in headers from AviSynth 2.6 FilterSDK don't include needed functions and enums.

[Myrsloik]

Avs+ MT branch. But why do you need it? I just gave you a compile of the latest version.

[Abs62]

It is my habit - to test last git FFMS2 with last git FFMpeg libraries every week. ;)

[Myrsloik]

Here's a combined 32 and 64 bit (https://dl.dropboxusercontent.com/u/73468194/ffms2-2016-10-07.7z) build.

Consider it RC level. It removes one horrible hack that broke a lot of files in the past so retest anything that wasn't working before (especially lossless codecs).

Since threads this size are horrible to navigate START CREATING PROPER ISSUES IN GITHUB. And host sample files where they can be found for a long time. That really helps.

I will from now on only investigate issues brought to my attention on the issue tracker or on IRC. Navigating this thread is impossible.

This is a reminder. Test my build because I'll try to make a release of it sometime next week unless it's horribly broken.

[pinterf]

Thanks for the build!

I will report this on github with source files.

Tested with my latest avs+ dev build, 32 bits.

- v210 input: mapped to yuv422p10, ok.
- r210 format, I don't know if it is intended to work, I got message: FFVideoSource: No suitable output format found
- Tried may prores encoded files, mostly ok (mapped to yuv 10 bit) (yuv422p10le, yuv444p10le: apcn (sq), apch (hq), ap4h)

But one of prores ap4h profile encoding was failed to be recognized.

This one gets mapped to RGB32

ffmpeg -ss 00:35:57 -i film1.mov -to 00:00:10 -c:v prores_ks -profile:v 4 -pix_fmt yuva444p10le -framerate 16 -acodec copy ProresYuva444p10le_a.mov

This one is properly mapped to yuv444p10:

ffmpeg -ss 00:35:57 -i film1.mov -to 00:00:10 -c:v prores_ks -profile:v 4 -pix_fmt yuva444p10le -alpha_bits 0 -framerate 16 -acodec copy ProresYuva444p10le_b.mov

[Myrsloik]

Thanks for the build!

I will report this on github with source files.

Tested with my latest avs+ dev build, 32 bits.

- v210 input: mapped to yuv422p10, ok.
- r210 format, I don't know if it is intended to work, I got message: FFVideoSource: No suitable output format found
- Tried may prores encoded files, mostly ok (mapped to yuv 10 bit) (yuv422p10le, yuv444p10le: apcn (sq), apch (hq), ap4h)

But one of prores ap4h profile encoding was failed to be recognized.

This one gets mapped to RGB32

ffmpeg -ss 00:35:57 -i film1.mov -to 00:00:10 -c:v prores_ks -profile:v 4 -pix_fmt yuva444p10le -framerate 16 -acodec copy ProresYuva444p10le_a.mov

This one is properly mapped to yuv444p10:

ffmpeg -ss 00:35:57 -i film1.mov -to 00:00:10 -c:v prores_ks -profile:v 4 -pix_fmt yuva444p10le -alpha_bits 0 -framerate 16 -acodec copy ProresYuva444p10le_b.mov

I think I know why that happens. It's trying to preserve the alpha plane so it picks the only known output format with alpha. Give me a sample and I'll see if I can add proper alpha support or at least make it less bad...

[pinterf]

Reported and my 5 sec samples are available.
https://github.com/FFMS/ffms2/issues/273

[Myrsloik]

Reported and my 5 sec samples are available.
https://github.com/FFMS/ffms2/issues/273

So I'm poking the alpha stuff. How come you didn't add Y+A formats? FFmpeg has it so I'm curious. Not that I think anything actually uses it but still...

[pinterf]

So I'm poking the alpha stuff. How come you didn't add Y+A formats? FFmpeg has it so I'm curious. Not that I think anything actually uses it but still...

Well, I added, they are called CS_YUVA....
Anyway, in the latest dev build (on my form or in my pull request of the main MT branch) you can strip alpha from avisynth+ by RemoveAlphaPlane, so it's good if e.g. YUVA444P10 is returned.

[Myrsloik]

Well, I added, they are called CS_YUVA....
Anyway, in the latest dev build (on my form or in my pull request of the main MT branch) you can strip alpha from avisynth+ by RemoveAlphaPlane, so it's good if e.g. YUVA444P10 is returned.

I mean that FFmpeg also has YA8 and YA16 (monochrome+alpha). Just started adding them and then realizes avs+ doesn't have them.

I've added alpha support now so just a bit of testing to see if it fixes your clip and then a new build.

[Myrsloik]

Here's another 2.23 RC (https://dl.dropboxusercontent.com/u/73468194/ffms2-2016-10-10.7z)!

It adds support for all alpha formats in avs+ as well. TEST HARDERRRRRRRRRRRRR!!!!!!1111

[pinterf]

Great! It shows YUVA444P10.

For the earlier test you mentioned that avisynth's rgb32 was chosen as the nearest matching format, having alpha plane. Since the source was 10 bits, was it intentional choosing RGB32 instead of RGB64?

[Myrsloik]

Great! It shows YUVA444P10.

For the earlier test you mentioned that avisynth's rgb32 was chosen as the nearest matching format, having alpha plane. Since the source was 10 bits, was it intentional choosing RGB32 instead of RGB64?

It picked RGB32 since it was the only output format with alpha. I didn't add any new packed formats for output since planar is the future (and I didn't feel like individually handling the packed ones).

All possible output formats are in the source here (https://github.com/FFMS/ffms2/blob/master/src/avisynth/avssources.cpp#L270).

[Myrsloik]

2.23 has been released. Everyone should update since it fixes stuff. Except for you XP users. HAHAHAHAHAHAHAHAHA

[ndjamena]

2.23 doesn't work for me AT ALL.

Avisynth/VirtualDub throws an access violation, while ffmsindex simply crashes at 0%.

[Myrsloik]

2.23 doesn't work for me AT ALL.

Avisynth/VirtualDub throws an access violation, while ffmsindex simply crashes at 0%.

Fixed binaries will be up soon. The x64 version still works though.

[Myrsloik]

Fixed binaries have been uploaded.

[FranceBB]

@myrsloik... except for you, XP users
Never say never. I grabbed the source code, removed vapour synth support, and I'll compile it to make it work with XP x86 ;)

[GMJCZP]

@myrsloik...
Never say never. I grabbed the source code, removed vapour synth support, and I'll compile it to make it work with XP x86 ;)

Could you upload it please?

[StainlessS]

I'll compile it to make it work with XP x86

You da man, FranceBB, Danke Sehr [some people just dont care bout us poor XP users] :)

[FranceBB]

I will definitely upload it. Just give me some time because they didn't include every header in the master project and I'm adding them manually.

[GMJCZP]

Thank you, FranceBB. I will be awaiting. :D

[FranceBB]

FFMS2 v 2.23 - Windows XP

Link removed

Yep, it's working! ;)
There are several dlls you'll need to put in your plugin folder because FFMS2 uses some APIs that are not natively available in XP.
(you may get some "weird" error at the startup, but it's just a warning, it will load)

Dlls are x86 only.

Enjoy! ;)



http://www.msfn.org/board/uploads/monthly_2016_10/ffms2.png.f7471164e5648676cebc2fb649386533.png

[real.finder]

I test the one from https://github.com/FFMS/ffms2/releases with winxp in VM and work!

maybe Myrsloik joking!

[qyot27]

FFMS2 C-plugin 1140+101 (http://www.mediafire.com/?wkzc7249b6u8d6r)

Optimized for Pentium-III and SSE (32-bit)
Optimized for Core2 (64-bit)

ffmpeg version r82048 git-dfe7e55 Copyright (c) 2000-2016 the FFmpeg developers
built with gcc 6.2.0 (GCC)
libavutil 55. 32.100 / 55. 32.100
libavcodec 57. 63.103 / 57. 63.103
libavformat 57. 52.100 / 57. 52.100
libavfilter 6. 64.100 / 6. 64.100
libavresample 3. 0. 0 / 3. 0. 0
libswscale 4. 1.100 / 4. 1.100
libswresample 2. 2.100 / 2. 2.100
libpostproc 54. 0.100 / 54. 0.100

32-bit configuration:
--prefix=/home/qyot27/win32_build
--cross-prefix=i686-w64-mingw32-
--enable-gpl
--enable-version3
--disable-w32threads
--enable-avresample
--disable-encoders
--disable-muxers
--disable-doc
--disable-debug
--disable-devices
--disable-avdevice
--cpu=pentium3
--extra-cflags='-mfpmath=sse -march=pentium3 -msse -mtune=pentium3'
--target-os=mingw32
--arch=x86
64-bit configuration:
--prefix=/home/qyot27/win64_build
--cross-prefix=x86_64-w64-mingw32-
--enable-gpl
--enable-version3
--disable-w32threads
--enable-avresample
--disable-encoders
--disable-muxers
--disable-doc
--disable-debug
--disable-devices
--disable-avdevice
--cpu=core2
--extra-cflags='-march=core2'
--target-os=mingw32
--arch=x86_64

Using the AviSynth+ headers currently causes Access Violations (which I've been trying to debug), so it's still using the old 2.6 header it always has.