FFmpegSource - C-plugin

[amayra]

Thank you qyot27

[FranceBB]

FFMS2 C-plugin r1315+119

I get an error "Unhandled C++ exception" if I try to open a .thd audio file.
It's a TrueHD Dolby Atmos 7.1 audio file of about 4.7 GB.
FFAudioSource starts indexing, it reaches about 512 MB of RAM and then it crashes.
Can you try to index a similar TrueHD Dolby Atmos 7.1 audio file and reproduce the issue?
It happens on the old ffms2 version as well (I can't test ffms2000 with XP).
If you want I can upload the file.

MediaInfo

Audio
Format : MLP FBA 16-ch
Format/Info : Meridian Lossless Packing FBA with 16-channel presentation
Commercial name : Dolby TrueHD with Dolby Atmos
Codec ID : A_TRUEHD
Duration : 2 h 29 min
Bit rate mode : Variable
Bit rate : 4 534 kb/s
Maximum bit rate : 6 930 kb/s
Channel(s) : 8 channels
Channel layout : L R C LFE Ls Rs Lb Rb
Sampling rate : 48.0 kHz
Frame rate : 1 200.000 FPS (40 SPF)
Compression mode : Lossless
Stream size : 4.73 GiB (9%)
Title : TrueHD Atmos 7.1
Language : English
Default : Yes
Forced : No
Number of dynamic objects : 13
Bed channel count : 1 channel
Bed channel configuration : LFE

[qyot27]

I've added it to the first post, but I finally opted to enable the issues tracker on my personal FFMS2 repo on Github to track C plugin-related issues:
https://github.com/qyot27/ffms2_cplugin/issues

[qyot27]

New build. (https://forum.doom9.org/showthread.php?p=1829061#post1829061)

The AV1 decoder in this build is libdav1d. FFmpeg is four months newer.

[Taurus]

@ qyot27
A big Thank You for maintaining ffmpegsource.
Really appreciated :thanks::thanks::thanks:

[StainlessS]

@ qyot27
A big Thank You for maintaining ffmpegsource.
Really appreciated :thanks::thanks::thanks:

+ 1 on that, thanx muchly. :)

[StvG]

Thanks.

I compared the latest c-plugin version you posted vs ffms2 (non c-plugin) with QTGMC(sharpness=*) in AvsPmod. C-plugin eats ~4.4GB RAM while the othe build eats ~1.3GB RAM.
* - when values from 0.1 to 1.6 are tested
C-plugin continues to eat RAM for every new tested option until there is no free RAM. The non c-plugin doesn't have this behavior. I had crashes with c-plugin while using non c-plugin runs without problems in the same scenario.
Can take a look for fix/solution?

[Groucho2004]

I compared the latest c-plugin version you posted vs ffms2 (non c-plugin) with QTGMC(sharpness=*) in AvsPmod. C-plugin eats ~4.4GB RAM while the othe build eats ~1.3GB RAM.
* - when values from 0.1 to 1.6 are tested
C-plugin continues to eat RAM for every new tested option until there is no free RAM. The non c-plugin doesn't have this behavior. I had crashes with c-plugin while using non c-plugin runs without problems in the same scenario.
Can take a look for fix/solution?
Have you tried VirtualDub2 and/or AVSMeter to verify this? Maybe the problem lies with AVSPmod.

[qyot27]

The problem lies with the client program re-loading the script over and over again without necessarily releasing the AviSynth script environment completely, which also unloads the C-plugin and flushes the memory. It's been an 'issue'* for years and trying to drill down to exactly where it lies is maddening.

*I mean, not for users of programs like x264 or FFmpeg, since those only load and unload the script environment once per program instance. VirtualDub can exhibit it eventually if you open the script and then repeatedly hit F2. Every time, it tacks an additional 70MB onto VirtualDub's memory allocation.

[manolito]

A forum member at VideoHelp uploaded this 12-bit HEVC sample which causes problems with the current ffms2 C_Plugins:
https://forum.videohelp.com/attachments/48349-1552354471/hevc_test_12bit.mp4

The latest C-Plugin version which can handle this file is FFMS2 C-plugin 1140+101 from 2016. All later versions either cannot find the function "ffaudiosource", or they quit with an access violation.

Repacking the file from MP4 to MKV does not help either. The file itself looks healthy, plays fine in all my media players, and MKVToolNix does not complain when remuxing it to MKV.

Any thoughts? I always thought that the C-Plugin v.1140 is the most reliable one and I always use it, but it feels weird to me that for decoding a "modern" 12-bit source the old version handles it gracefully while all the newer version fail.

Cheers
manolito

[qyot27]

I can't reproduce this. It works fine here with the most recent build I've posted (from 2019-01-20 / r1334+120).

Those errors sound like something else is wrong in the AviSynth environment, though.

[filler56789]

FWIW, on my PC the latest FFMS2 C-plugin returns this message:

"FFVideoSource: no suitable output format found"

— whereas the DLL compiled on 2018/January/09 loads that video but makes VirtualDub crash when I click the play button.

[manolito]

"FFVideoSource: no suitable output format found"


Yes, that's the error I get when using te latest C-Plugin version, too. Win7 -64, everything else 32-bit.

[filler56789]

UPDATE:

adding colorspace="YV12" to FFVideoSource() is the solution to the PEBKAC :o situation.

Another new build (https://forum.doom9.org/showthread.php?p=1829061#post1829061); this time, using the C plugin under AviSynth 2.6 shouldn't error out with access violations if given high bit depth video. It will spit back the 'FFVideoSource: No suitable output format found' error since it won't do automatic downsampling anymore. The assumption, given high bit depth video, is outputting the same pix_fmt unless you use ConvertTo later in the script. The colorspace= parameter should work again, though, so you can force 8-bit output when you know you need it.

[manolito]

Thanks, this explains it...

But for software like AVStoDVD where the user cannot alter the FFVideoSource parameter to add a colorspace value this means that for high bit depth video the current ffms2 C-Plugins will not work. I will recomend to all A2D users to revert back to ffms2_r1140+101-avs+vsp.7z to avoid these issues.

[qyot27]

New build. (https://forum.doom9.org/showthread.php?p=1829061#post1829061)

Includes the AV1 parsing fix patches, along with two months' newer versions of FFmpeg and libdav1d.

[manolito]

Thanks for the new build r1340... :thanks:

I would like to make this fool proof for AVStoDVD, this means that I need to add the colorspace="YV12" param to the AVS file created by AVStoDVD somehow (not too hard, I already do intercept the encoder call).

The question is if this is really worth the trouble. The older version r1140 works nicely so far, does the new version r1340 offer any real world advantages? Does it support source formats which the older version doesn't? Or does it fix some serious bugs?

Cheers
manolito

[qyot27]

Does it support source formats which the older version doesn't?
AV1 is probably the most significant one. (https://en.wikipedia.org/wiki/AV1) r1140+101 was uploaded in October 2016, more than a year before the AV1 spec reached feature freeze, and a year and a half before the initial release of its reference software. Even just newer versions of libaom (the reference software) or libdav1d could be significant on just the topic of AV1; it's a shame that FFMS2 doesn't have something in place to switch among multiple libavcodec decoders (if available), depending on which currently gets better performance. FFmpeg itself didn't support decoding with libaom (http://git.videolan.org/?p=ffmpeg.git;a=commit;h=99cc3cf7a26cd4113e5047034577027d8c6f07a2) until March 2018, and didn't support libdav1d until November 2018 (http://git.videolan.org/?p=ffmpeg.git;a=commit;h=beaa350e24167f4ff31275a6114693f5ce7cd409).

[manolito]

Thanks for this info...

Looks like AV1 might become an important video format in the near future, source filters will need to support it. My efforts to add the colorspace parameter to the AVS script in A2D were only halfway successful. I can manipulate the encoding script, but for the preview a separate script is used which I cannot access. Hopefully MrC will find some time to fix it...


Cheers
manolito

[Ktzf01]

Thank you qyot 27 for these nice ffms2 builds. I find these very helpful. I was wondering if sometime a build with libaom (instead of libdav1d) would be available, just for comparison.

[manolito]

I'm not sure if a different thread for this post would be more appropriate (like the regular ffms2 thread or the AVS+ thread), but I chose this thread anyways because I know who I am talking to...:D

After installing the current AVS+ test build I did a couple of speed benchmarks using different source filters, and like before I stumbled over some odd behavior using ffvideosource in MT mode.

My tests were all 32-bit, latest AVS+ test version, several C-plugin versions of ffms2. I also tried LWLibavVideoSource and DSS2Mod. CPU was an Intel Core i5 3rd generation, I used 4 MT threads. Input was a HD MP4 file, I used AVStoDVD to convert it to DVD. The script was as simple as it gets, just the source filter, YV12 conversion and the resizer.

When I specify ffms2 in AVStoDVD, it generates this call:
Video = FFVideoSource("C:\Download\Test.mp4", track=-1, fpsnum=25, fpsden=1, colorspace="YV12", seekmode=2)

The fpsnum and fpsden params are used to make sure that the source filter issues CFR (DVD cannot handle VFR, and if the source is already CFR then these params should not cause any damage). Seekmode=2 is from a patch I did because the default Seekmode=0 was just too slow for my taste.

These are the speeds I get: (The values in brackets are without MT)
DSS2Mod: 115fps (95fps)
LWLibavVideoSource: 115fps (97fps)
FFVideoSource r1140: 59fps (97fps)
FFVideoSource r1340: 36fps (97fps)

This looks pretty bad for FFVideoSource, and the following fix worked for me:
Video = FFVideoSource("C:\Download\Test.mp4", track=-1, colorspace="YV12", seekmode=2).ChangeFPS(25)
I took away the fpsnum and fpsden params and used ChangeFPS to ensure CFR output. Suddenly the speed jumped up to 117fps.

This weird behavior only happens when MT is used. There must be something in the implementation of fpsnum and fpsden which seems to cause a race condition or so in AVS+ MT mode. Do you have an explanation for this?

And do you think that there are any catches when using ChangeFPS? According to the ffms2 docs all the fpsnum and fpsden params do is inserting or dropping frames to reach the desired CFR fps, and ChangeFPS does exactly the same thing. I have not found any visual problems so far using this workaround.


Cheers
manolito

[qyot27]

The behavior is a little more predictable. It happens with just a plain invocation of FFMS2:
FFVideoSource("test-av1opus.mp4")
This script opening a 1080p30 AV1/Opus test file averages ~260fps on my Apollo Lake Celeron J3455. AviSynth+ r2883, so prior to the recent commits.

Add Prefetch(4), and the average speed drops to ~10fps. Add ChangeFPS(25), it rises back up over 200fps.

But here's the thing: if ChangeFPS(25) is used and Prefetch(4) isn't, the speed is still over 200fps. If, however, ChangeFPS' linear parameter is set to false (the default is true) while using Prefetch, the speed drops to the same low number.

What this is saying, more likely than not, is that it has something to do with frame or memory caching (or in other words, ChangeFPS essentially nullifies the speed drop from FFMS2 being run in an MT script because by default, it's doing linear access). It also isn't isolated to the C plugin; the same sort of thing occurs with the August 11th build of the C++ plugin that HolyWu posted. fpsnum/den actually have nothing to do with it, and can be worked around using RequestLinear() from the TIVTC package:
FFVideoSource("test-av1opus.mp4",fpsnum=25000,fpsden=1000)
RequestLinear()
Prefetch(4)
The result in avsmeter: 226fps.

Beyond that, whether it's FFMS2's core reacting badly to MT or AviSynth+ being too aggressive with FFMS2 specifically, I can't say. Why FFMS' seekmode parameter wasn't working is one question. It would have supposedly forced linear access, but there was no speed up.

With AviSynth+GCC r2831, FFmpeg reports the following (since avsmeter can't run GCC builds):
plain script: 159fps
with Prefetch(4): 32fps
with ChangeFPS(25): 142fps
with ChangeFPS(25) and Prefetch(4): 170fps (!!!)
Now that result is interesting. It's the only one here where activating MT actually resulted in an increased fps, rather than the same fps or significantly lower. Unfortunately, you give up almost all plugin compatibility when using AviSynth+GCC, so it's more for checking whether there's something weird going on with the compilers (and based on this alone, there actually might be, although I wouldn't know what it is exactly).

[manolito]

Thanks for your research, much appreciated... :)

I can reproduce your findings that following the FFVideoSource call with RequestLinear brings back full speed.

Meanwhile I repeated my tests using LWLibavVideoSource, and to a lesser degree it shows the same behavior. Instead of 59 or 36 fps with FFVideoSource I get 80 fps with LWLibavVideoSource, but following the call with RequestLinear or ChangeFPS also brings back the full speed.

So it looks like it is an FFmpeg thing. Is this something the FFmpeg devs should fix, or should I ask pinterf for a workaround in AVS+? Or should I just live with it and use RequestLinear after the source filter as my standard procedure?


Cheers
manolito

[qyot27]

New build (https://forum.doom9.org/showthread.php?p=1829061#post1829061).

Five months newer versions of FFmpeg and libdav1d.

[manolito]

Thanks for the new builds...

If you now decided to also make C++ plugin versions, it is probably not a good idea to only promote them in this C-Plugin thread.

For the C++ plugins the situation already is a little bit confusing. We have current builds from HolyWu, StvG and now also from you (Myrsloik seems to have abandoned ffms2000).

Hard to find out the subtle differences between all these builds for the average Joe...


Cheers
manolito

[StainlessS]

Hard to find out the subtle differences between all these builds for the average Joe...
Yep, and some indication of the coder that did the build [in file name] would not be a complete waste of time.
[version resource in all future versions would also be nice, some have them, some dont]

& thanks Q27.

[qyot27]

For the C++ plugins the situation already is a little bit confusing. We have current builds from HolyWu, StvG and now also from you (Myrsloik seems to have abandoned ffms2000).
ffms2000 got merged into the upstream master branch in Nov 2017. That's why there's no new builds of it: all the builds, even the C plugin, have had those changes in them for over a year and a half.

Hard to find out the subtle differences between all these builds for the average Joe...

I dunno about the others, but you'd find out pretty quickly that these aren't normal C++ builds if you tried to use them. They'll only work with GCC builds of AviSynth+*, and thus should only ever be put in the plugins_gcc/plugins64_gcc folder(s). Very very niche at this point.

*of course, the normal C plugin builds work with GCC builds of AviSynth+ too, but that's sort of boring.

[Myrsloik]

Thanks for the new builds...

If you now decided to also make C++ plugin versions, it is probably not a good idea to only promote them in this C-Plugin thread.

For the C++ plugins the situation already is a little bit confusing. We have current builds from HolyWu, StvG and now also from you (Myrsloik seems to have abandoned ffms2000).

Hard to find out the subtle differences between all these builds for the average Joe...


Cheers
manolito

Why would I bother making builds when everyone else is already doing it? Seems like a lot of duplicated effort to me.

[ChaosKing]

Why would I bother making builds when everyone else is already doing it? Seems like a lot of duplicated effort to me.

You could make official releases :p

[Reino]

Hello qyot27,

Despite 'ffms2_r1315%2B119-avs%2Bvsp_lastxp.7z' being the last WinXP compatible SSE build you released I was wondering if https://github.com/qyot27/ffms2_cplugin (https://github.com/qyot27/ffms2_cplugin) itself is still WinXP compatible and suitable for non-SSE2 cpus.
I've tried to build FFM2 for Avisynth (https://msfn.org/board/topic/177308-ffmpeg-windows-xp-updated-builds-by-corone/?do=findComment&comment=1181347), but upon invoking FFVideoSource() I'm getting this typical error which leads me to believe it's actually not suitable for non-SSE2 cpus anymore. Or am I totally wrong?

[FranceBB]

qyot27, as you can see from the MSDN topic (https://msfn.org/board/topic/177308-ffmpeg-windows-xp-updated-builds-by-corone/page/2/?tab=comments#comment-1181358), CoRoNe (who's the one maintaining ffmpeg xp compatible binaries (https://rwijnsma.home.xs4all.nl/files/ffmpeg/?C=M;O=D) updated) actually managed to compile ffms2 targeting XP and when I tried it, FFAudioSource worked like a charm. When I tried to use FFVideoSource, it even created the .ffindex file relative to the video file I was trying to index, however it failed to open the uncompressed video stream in Avisynth and reported an access violation.

I'm just gonna report a few replies from MSDN to here for completeness:


I git cloned https://github.com/qyot27/ffms2_cplugin.git, patched a couple of files in order for compilation-errors to go away, made the library and executable and packed the necessary files.
You could try ffm2-2.18-736-g43dc804_avs+vsp-win32-xpmod-sse.7z (http://rwijnsma.home.xs4all.nl/files/ffms2/ffm2-2.18-736-g43dc804_avs+vsp-win32-xpmod-sse.7z), with the emphasis on "try".

Although the compilation-process went fine, I'm getting an application error pop-up "The instruction at "0x6ef94386" referenced memory at "0x00000000". The memory could not be "written"." the moment I try to open an avs-file like this...

FFVideoSource("<full-path-random-video>")
...with FFmpeg. This probably means there's SSE2 code in FFMS2 (not sure though). I'm not a C-coder, so unless someone could point me to the exact cause, I'm afraid this is all I could do.

'ffmsindex.exe' and "FFAudioSource()" did work fine during my tests though.



The following script works:

video=AVISource("Z:\Isilon\421.avi")
audio=FFAudioSource("Z:\Isilon\421.avi")
AudioDub(video, audio)

which means that FFAudioSource is working:

https://i.imgur.com/bw6BJaD.png


however if I try to use FFVideoSource directly it reports an access violation, just like the one you got:


FFVideoSource("Z:\Isilon\421.avi")


https://i.imgur.com/A73dqiE.png
https://i.imgur.com/YEasdT0.png

The weird thing is that it tries to do something and in fact the indexer does index the file and it creates the relative .ffindex file like: Analog_bad_source.avi.ffindex or test.ffindex which means that it's indeed working fine, but something fails when it tries to load the uncompressed video stream into Avisynth. Besides, it doesn't even have anything missing when I look at it in dependency walker. I mean, we're almost there, it can work on XP!

Did you compile it with /Zc:threadSafeInit as well?


No. Would it matter?


Yep, many Avisynth plugins can compile but don't work on XP without /Zc:threadSafeInit as XP doesn't have a way to handle the way they use to handle threads, therefore /Zc:threadSafeInit is needed to make them thread-safe and compatible with XP. If you could try to compile it again but with /Zc:threadSafeInit I can test it.

@qyot27... do you have any insights about what is causing the access violation? 'Cause, you know, it's working fine for everything but the very last part of showing the video inside Avisynth / ffmpeg etc.


@CoRoNe... for the records, I'm testing it with an SSE4.2 capable CPU on Windows XP, so, for now, my bets are on /Zc:threadSafeInit

[qyot27]

Nothing in the C-plugin or the FFMS2 core itself causes it to be incompatible with XP. It's entirely due to the dependencies linked into it (read: FFmpeg) and the compilation environment.

/Zc:threadSafeInit is completely meaningless to the C plugin, that's an MSVC option. The C plugin is built with MinGW-w64/GCC (maybe Clang, but I've never tried).

The GCC optimization level is probably at fault. Most of the builds I've provided use --optlevel=0 (and even --enable-debug) because something in -O2 screws over the src/avisynth_c/ sources specifically.

[Reino]

This is the first time I had to compile something with a debug-option for it to work. --optlevel=0 didn't work, but --enable-debug --extra-ldflags=-s does! Do you know why -O2 is so problematic?

Alright, ffm2-2.18-736-g43dc804_avs+vsp+ffmpeg-4.3-3133-g1128aa8-win32-xpmod-sse.7z (http://rwijnsma.home.xs4all.nl/files/ffms2/ffm2-2.18-736-g43dc804_avs+vsp+ffmpeg-4.3-3133-g1128aa8-win32-xpmod-sse.7z) it is.
So, FFMS2 2.18-736-g43dc804 (https://github.com/qyot27/ffms2_cplugin/commit/43dc8040cfc50677422cd48268a84f139d708acb) compiled with FFmpeg 4.3-3133-g1128aa8 (https://github.com/FFmpeg/FFmpeg/commit/1128aa875367f66ac11adc30364d5652919a2591). Both built with MinGW-w64 7.0.0 and GCC 9.3.0.
FFmpeg buildconf:
--arch=x86
--target-os=mingw32
--prefix=$mingw_w64_x86_64_prefix
--cross-prefix=$cross_prefix
--extra-cflags='-march=pentium3 -mtune=athlon-xp -O2 -mfpmath=sse -msse'
--pkg-config=pkg-config
--pkg-config-flags=--static
--enable-gpl
--enable-version3
--disable-bcrypt
--disable-debug
--disable-doc
--disable-htmlpages
--disable-manpages
--disable-podpages
--disable-schannel
--disable-txtpages
--disable-w32threads
--disable-avdevice
--disable-avfilter
--disable-devices
--disable-encoders
--disable-filters
--disable-hwaccels
--disable-muxers
--disable-network
--disable-programs
--disable-sdl2
--enable-libaom

[qyot27]

I've been stumped by it for years. If I could pinpoint exactly which option or combination of options in the optimizations causes it (it's not -O2 specifically, any level of optimization does it, -O2 is just the default¹), then I could try to hunt down the part of the plugin code that causes the issue. There was a point, back like 8 years ago, that it wasn't necessary. Updates to MinGW-w64 and/or GCC brought on the need to start messing around with the optlevel and then debug (--enable-debug is only needed for 32-bit builds, oddly enough; the 64-bit builds can get by with just --optlevel=0; --enable-debug also turns off the optimizations, but also sets -g in the C(XX)FLAGS, and stranger is that if you're stripping the symbols right back out at link time, that should make it equivalent to --optlevel=0, but it clearly isn't). That it seems to not cause problems for audio might help figuring out what part is at fault here; I wouldn't be surprised if it ends up being something in ff_vidsource.c.

¹because it's not needed for the core or, IIRC, even for the C++ or (now really deprecated) AvxSynth plugin. At least on Linux, anyway.

[Groucho2004]

- deleted -

[FranceBB]

Alright, ffm2-2.18-736-g43dc804_avs+vsp+ffmpeg-4.3-3133-g1128aa8-win32-xpmod-sse.7z (http://rwijnsma.home.xs4all.nl/files/ffms2/ffm2-2.18-736-g43dc804_avs+vsp+ffmpeg-4.3-3133-g1128aa8-win32-xpmod-sse.7z) it is.


OMG OMG OMG!
IT WORKS!!

https://i.imgur.com/x06fCqE.png

Other test with AVSPmod new ffms2 index: Image (https://i.imgur.com/xnvumMo.png)

Yes!! It works!!
annuntio vobis gaudium magnum: habemus ffms2!!
And with modern indexers, XP is more alive than ever! :D
Thank you, thank you, thank you so much!

@StainlesSs, Manolito, come here, we gotta celebrate (with social distancing)!! xD

https://youtu.be/roRQ2mNwMMQ

[StainlessS]

Great stuff, thiings looking up :)

[videoh]

http://rationalqm.us/misc/beat.jpg

[amayra]

http://rationalqm.us/misc/beat.jpg

I wonder why you are not banned yet?

[videoh]

Probably the mods have the sense of humor that you lack.

http://rationalqm.us/misc/road_ends.jpg

http://rationalqm.us/misc/change.jpg

[filler56789]

^ And probably "sense of humor" is a euphemism for «unconditional love» :sly:

[Groucho2004]

^ And probably "sense of humor" is a euphemism for «unconditional love» :sly:I'm not so sure about that.

Anyway, even though I was using XP intermittently until a few months ago, I find myself unable to do anything useful with it now. Lots of software/features I use just don't work (any more). I certainly enjoy doing everything 64 bit, especially working with raw images in Photoshop/Adobe Camera Raw which was a nightmare on 32 bit Windows (Adobe products consume memory like DonnyT does burgers :)). Not to mention that there are no drivers for contemporary graphics cards.

[videoh]

^ And probably "sense of humor" is a euphemism for «unconditional love» :sly: Sorry for being so lovable.

Not to mention that there are no drivers for contemporary graphics cards. That's a biggie.

[Reino]

Yes!! It works!!
That's good to hear! ;)
Thanks for the confirmation.

[manolito]

Took me a little while to test it thoroughly, but I can confirm that this build of ffms2 works nicely... :D

Under WinXP with a Non-SSE2 CPU no poblems with all my workflows.

Then I tested it under Win7-64 and AVS+ 3.51 32-bit. Also no unexpected issues, especially comparing it to the latest qyot27 XP build (which is already 2 years old) I did not find problems.

The problems I did find have nothing to do with this build, they are present in all ffms2 builds I have tested (C-plugins and also standard C++ plugins by StvG and MeteorRain). These problems occur when trying to decode a HD HEVC video plus AAC-LATM audio file in an MTS container (German DVB-T2 video captures).

When trying to decode the MTS file I got the error that no audio track was found. After repacking the MTS to MKV using the current MKVToolNix the audio track was detected and converted without any error messages, but the resulting audio was distorted and crackling so it was unusable.

Changing the audio source filter to either DSS2Mod with LAVAudio or to LWLibavAudioSource fixed the distortion. But under LWLibavAudioSource I could not get it running stable with multithreading.

The weird thing is that FFmpeg itself has no problem to decode the AAC-LATM track to WAV. My workaround for such sources is to use FFmpeg to repack the captured MTS to MKV using Copy for video and PCM for audio. This MKV decodes nicely without any quality issues under all my source filters.


So thanks again to CoRoNe for the continued support for us retro XP users. :thanks:


Cheers
manolito

[Emulgator]

Many thanks, CoRoNe !
This opens a detour path where highways have become unavailable.

[Reino]

If I could pinpoint exactly which option or combination of options in the optimizations causes it (it's not -O2 specifically, any level of optimization does it, -O2 is just the default¹), then I could try to hunt down the part of the plugin code that causes the issue.
I've done some testing and -fomit-frame-pointer (https://github.com/qyot27/ffms2_cplugin/blob/c_plugin/configure#L480-L484) proves to be the culprit:
if [ "$debug" != "yes" -a "$gprof" != "yes" ]; then
CFLAGS="$CFLAGS -fomit-frame-pointer"
CXXFLAGS="$CXXFLAGS -fomit-frame-pointer"
LDFLAGS="$LDFLAGS -s"
fi
This fixes that for now:
diff --git a/configure b/configure
index 376bcb8..cc07783 100755
--- a/configure
+++ b/configure
@@ -478,8 +478,8 @@ if [ "$pic" = "yes" ] ; then
fi

if [ "$debug" != "yes" -a "$gprof" != "yes" ]; then
- CFLAGS="$CFLAGS -fomit-frame-pointer"
- CXXFLAGS="$CXXFLAGS -fomit-frame-pointer"
+ CFLAGS="$CFLAGS -fno-omit-frame-pointer"
+ CXXFLAGS="$CXXFLAGS -fno-omit-frame-pointer"
LDFLAGS="$LDFLAGS -s"
fi
if [ "$debug" = "yes" ]; then

It does appear to be a GCC option of significance, because the 'ffms2.dll' I compiled earlier with --enable-debug --extra-ldflags=-s and with $CFLAGS containing -O0 is 23.413.760 bytes in size, while a new 'ffms2.dll' compiled with this fix and despite $CFLAGS containing -O2 is 23.564.800 bytes in size.

[qyot27]

I thought I'd tested that a few years ago, but maybe not. I recall that x264 used to have issues with -fomit-frame-pointer, not sure if it still does.

[Reino]

For those interested, I've made a new Windows XP compatible non-SSE2 build. See https://rwijnsma.home.xs4all.nl/files/ffms2/ (https://rwijnsma.home.xs4all.nl/files/ffms2/).

[manolito]

:thanks: :thanks: