FFAStrans forum

Hey baev12, I have some very good news!
Myrsloik - the original developer of ffms2 - picked up the issue and fixed it personally.
You can find the current Release Candidate here: https://github.com/FFMS/ffms2/releases/tag/5.0-RC2
If you download the package, open it with WinRar or 7zip and you'll find two things:

- FFMS2.avsi
- a folder called "x64"

copy both FFMS2.avsi and the x64 folder and paste them it in the FFAStrans folder in Processors\avs_plugins\ffms2
This way FFAStrans is gonna use the new build and will therefore be able to index the file correctly.

p.s please note that this is a release candidate 2 and although it fixed this issue it might very well introduce new ones. In other words, if you find any new issue / regression, please let us know.

Well done Frankie (IF it is fixed actually, not sure if anybody checked it because i was not really able to see the original issue in the uploaded clips on PC screen so i cannot check if its fixed really)
Meanwhile we also know that we cannot just switch between 1.3.x and 1.4.x ffms.dll versions ^^

lol don't thank me, thank Myrsloik ehehehehe
Anyway, it is fixed, I checked it here on prem by going frame by frame on AVSPmod mod and using Info().
ffms2 v5 RC2 now has a behavior consistent with the one of LWLibav for this very particular clip.
Please note that v5 RC2 - albeit fixing the XDCAM Open GOP issue - also introduces some regressions.
In particular, the non regression testing went as follows:



Everything has been reported to Myrsloik.
The reason for those regressions is that Myrsloik didn't rebase his GitHub repo on the StvG Gitlab one, but rather kept going with the original one.
Whether those changes will ever be merged or not is unclear as some of the changes made by Steve didn't seem to be addressing the root cause of some issues but rather putting a plaster on it according to Myrsloik, therefore I think he wants to get them addressed correctly instead, which is why he's not yet merging those.

I guess we'll see in the next few days.
As for baev12 and everyone reading this, please acknowledge the image I posted above and the fact that ffms2 v5 is still a release candidate which fixes a thing and breaks some other, so, according to your particular use case, you have to choose whether it's worth swapping it with the current one shipped with FFAStrans 1.4.0.4 Stable or not.
Hopefully, by the time we get a new stable release of ffms2, all regressions will be sorted, but until then it's up for you guys to decide whether you wanna trade an issue for another.

FranceBB wrote: ↑Tue Feb 27, 2024 7:50 pm - FFMS2.avsi
- a folder called "x64"

Yes!
It looks like fixed one!
I will do some more tests if you don't mind )

Thank you! )

Hi!
I've recently installed v1.4.0.4 and just have encountered the frozen/dropped frames when setting the AV Media Decoder to "Intelligent".
Could it be using this misbehaving AV decoder also results in incorrect aspect ratios? When I feed it with IMX D-10 files (MXF OP1a, 720x576, AR 4:3, PAR 1.0667:1) and reencode it to IMX D-10 again, the results are always slightly distorted (stretch, fill and fit in the Encoder).
Setting the AV Decoder to "Full decode" also leads to distorted results, just a bit different.
Bypassing the AV Decoder leads to correct aspect ratios.

regards

Dropped frames are caused by the same issue: faulty indexer.
Please try the new Release Candidate 2 and report back on any issues.
As for the IMX files, that's slightly different.
IMX are 720x608 with the very top made of inactive lines where historically things like the TC, the TTX of the various pages etc were stored and the actual active lines were 720x576, so the decoder would have to read that apparently black bar, decode those info and then resize on playback to display the actual active lines resized according to the flag like for 16:9 1024x576.

The reason why you're getting the right AR with the encoder is that it goes straight into the filter_builder which performs the cropping and then feeds the encoder with the actual output so that the encoder is gonna be able to actually perform the encoding operation.
Unfortunately, if you go through Avisynth, then it's the indexer that is employed to store and passthrough those info to the filter_builder as it won't use the info from medianfo/exiftools/ffprobe any longer.

Now, if we index this with Avisynth we can see that it's 720x608 anamorphic flagged 16:9 with the active lines being just 576:

if we were to simply resize it to 16:9, we would get the wrong aspect ratio, in fact:


as you can see that's wrong 'cause it still has the non active lines at the top.
We gotta crop it, therefore:


So far so good, but we've done it manually and this is not what the filter_builder is doing.
When you open such a file yourself without Avisynth (i.e without the A/V decoder), then the filter_builder knows that it's an IMX50 and that it has to crop, however when it goes through Avisynth it becomes an uncompressed A/V stream and the filter_builder only has the frame properties to try to understand what that stream is, in particular for such a file the frame properties are:



but those are not reset after cropping.
In other words, after cropping, frame properties aren't adjusted and the filter_builder performs the wrong conversion.

In particular, here's what it's doing after it's fed with the AVS Script:
and here's what it's doing after it's fed with the source input file:
Top is wrong (source + Avisynth + filter_builder + encode) - Bottom is correct (source + filter_builder + encode):

Thanks for the explanations! But this was not a problem for the AV Decoder in v 1.3.1. (node "A/V Media")!
I've just compared the same simple workflow in v 1.3.1 and then in v 1.4.0.4. "A/V Media" node connected to IMX D-10 encoder.
v1.3.1 - works fine in "intelligent" and "full decode" - correct handling of 32 VBI lines and aspect ratio, results ok
v1.4.0.4 - "intelligent" - results slightly squeezed / small letterbox, "full decode" - result slightly squeezed + cropped content at top of frame

Yes, that's right.
That's because in 1.3.1 life was easier and there were no frame properties, only clip properties.
It will be fixed in FFAStrans 1.4.0.5.
In the meantime, you can download the processors.a3x file I'm attaching here:
Go to the FFAStrans installation folder in "Processors" and paste it there by replacing the original one.
You can do it on the fly without stopping the farm, it will be used as soon as a new transcode starts.
That's the power of .a3x

p.s don't thank me for the fix, when I went there to fix it I saw that Grandmaster Steinar already did so I just rebased my branch and compiled his code. He is Grandmaster after all.


As for everybody else who is interested in this whole indexing shenanigan, after talking to Steve, we finally have a stable version of ffms2 v5 r2390.
Basically instead of Myrsloyk merging the pull request from StvG over the last 4 years, it was easier to do it the other way round, so for Steve to port the latest Myrsloyk code changes to his branch.
This way we have v5 but we retain all the fixes and developments done by Steve over the last 4 years.

Here you can find the build: https://codeberg.org/StvG/ffms2/release ... 2_r2390.7z
As always, you can swap the executable and dll in Processors\avs_plugins\ffms2 of your current 1.4.0.4 release or you can wait for 1.4.0.5 to be released and it will be included there along with all the fixes.

In case you're wondering, yes, we did run non regression testing on this new stable release and it worked as expected (result of this new version in green).

Ok. Thanks for your advice and the link!

FranceBB wrote: ↑Wed Mar 06, 2024 12:43 pm processors.a3x

p.s don't thank me for the fix, when I went there to fix it I saw that Grandmaster Steinar already did so I just rebased my branch and compiled his code. He is Grandmaster after all.

This way we have v5 but we retain all the fixes and developments done by Steve over the last 4 years.

GrandThanx for you all !