FFMS2000 - The experimental future of FFMS2 [Archive] - Page 4

Myrsloik

31st December 2017, 01:24

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

1st January 2018, 16:32

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

1st January 2018, 16:53

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

2nd January 2018, 05:02

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

FranceBB

2nd January 2018, 05:41

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

2nd January 2018, 06:02

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

2nd January 2018, 14:17

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

2nd January 2018, 14:54

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

2nd January 2018, 15:39

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

2nd January 2018, 17:49

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

10th January 2018, 07:45

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

10th January 2018, 12:35

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

10th January 2018, 13:11

real.finder

10th January 2018, 22:40

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

10th January 2018, 22:44

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

10th January 2018, 22:44

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

10th January 2018, 22:52

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

10th January 2018, 23:13

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

10th January 2018, 23:19

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

10th January 2018, 23:22

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

real.finder

10th January 2018, 23:37

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

11th January 2018, 00:07

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

11th January 2018, 00:15

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

12th February 2018, 14:43

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

12th February 2018, 15:06

Atak_Snajpera

12th February 2018, 15:18

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

12th February 2018, 15:25

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

Atak_Snajpera

12th February 2018, 15:27

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

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

Myrsloik

12th February 2018, 15:41

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

12th February 2018, 15:47

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

12th February 2018, 15:57

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

`Orum

28th February 2018, 23:21

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

sneaker_ger

28th February 2018, 23:30

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

28th February 2018, 23:35

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

`Orum

28th February 2018, 23:38

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

28th February 2018, 23:47

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

28th February 2018, 23:52

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

28th February 2018, 23:57

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

1st March 2018, 00:05

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

1st March 2018, 00:55

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

`Orum

1st March 2018, 10:21

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

1st March 2018, 11:55

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

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

`Orum

1st March 2018, 13:02

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

1st March 2018, 13:04

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

1st March 2018, 13:16

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

1st March 2018, 13:21

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

1st March 2018, 13:47

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

1st March 2018, 13:49

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

1st March 2018, 14:19

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.