FFAStrans forum

Hi,

I've noticed after upgrading to v1.3.1 that files that go through an 'AV Media' node and are then transcoded to any number of formats - the outputted files will have dropped frames within them.

The dropped frames are always in the same place.

Example:

MXF AVC Intra 100 > AV MEDIA > Filter > H264
                                             > AV Script > DNxHD120 MXF

The H264 and the DNxHD120 file will have the dropped frames in the same sections. If I bypass the AV Media Node the files come out fine.

I've tried various setting options within AV Media node with no success.

I downgraded back to v1.3.0 and the issue goes away. Files passing through the AV Media Node and output without stuttering/dropped frames in sections.

HP Z4 G4 Workstation 64GB RAM Intel i9 109040X

I'm always all ears when it comes to the A/V Decoder as indexing is one of the parts of FFAStrans I care mostly about and I commit to all the time.
Unfortunately, though, I'm gonna need a few more info.
What are the settings for the A/V Decoder?
Can you try Full Decode on both audio and video and see if it's the same?

- if it still has dropped frames with full decode, then I'd like to see the logs

- if it doesn't have dropped frames with full decode, then it's unfortunately one of the indexers we use, namely ffms2, and I'll provide an emergency new builds that you guys will test.


Please keep me posted cause I have this thing at heart.

Hi,

I've run a test tonight, and it appears to not be dropped frames but rather stuck frames.

The issue only occurs, it appears when you have AV Decoder > Filter > Encoder. Without the 'Filter' node, the files are fine.

I've attached an example below. Two files with a suffix of _130 and _131 - referring to versions.

For my example, I've used the Timecode filter to burn in timecode.

At 10:00:06:05 you will notice that 10:00:06:06 is the same stuck frame on _131. The file marked _130 does not have this stuck frame.

I've tried using full-decode and the issue persists.

https://we.tl/t-wNqp2WU1GY

Yes, I can see that the frame is duplicated, however I have no way of reproducing it.
Besides, I can see that the H.264 file provided doesn't have the x264 parameters there and that it also has a bunch of metadata that I don't recognize.
When a file comes out straight from FFAStrans I would expect the x264 params to be included, so it means that you probably re-encoded it.

Anyway, I can't reproduce.
The fact that the file has duplicated frames might be because it was VFR originally and it was brought to CFR by the indexer, but with no logs, no workflow and no source, I can't reproduce.

I created a workflow like yours: and went on re-encoding a file similar to yours.
I checked the first 10 seconds and I couldn't find any duplicates:

https://we.tl/t-cWIJ01G6r2

Hi Frances,

The source file inputted was an AVC-Intra 100 MXF file encoded by Adobe Media Encoder. The H264 I've attached previously was created by FFAStrans.

I've attached the following:

AVC Intra 100 MXF - Encoded by Adobe Media Encoder - this is the source input file
- H264 created by FFAStrans 1.3.0
- H264 created by FFAStrans 1.3.1
- Workflow used by FFAStrans 1.3.0
- Workflow used by FFAStrans 1.3.1

The H264 outputted by 1.3.1 has stuck frames at 10:00:08:00

https://we.tl/t-VrQhkgMzUi

Happy to forward on logs - unsure where these are located?

Thanks

Hi,

Upon further testing, it is the Decode AV Media node being set to 'Intelligent'. It works in 1.3.0 fine, but it's throwing the stuck frames in 1.3.1

I'm positive I set this to Full Decode in previous testing, and it didn't sort it. Anyway, I've run a few tests with the above MXF AVC file and 1.3.0 'Intelligent' decode works fine, but in 1.3.1 it's throwing the stuck frames.

Thanks.

Uhmmmm looks like there has been some misunderstanding/issue on our internal Github as apparently the official 1.3.1 stable got shipped with a faulty version of the indexer, while my 1.3.1 had the right one, 'cause I imported your workflow and the file came out just fine.
I'm not gonna lie, our internal GitHub is a bit of a mess right now, but hopefully we'll bring it back to a sane state by the end of the 1.4 merge window.

Anyway, this was your file and your workflow ran through my FFAStrans 1.3.1 Development Snapshot 15-02-2023: https://we.tl/t-8Hh53civYJ
As you can see, there are no repeated frames at all.

For graham728:
Here's a copy of the build I used, namely FFAStrans 1.3.1 Development Snapshot 15-02-2023: https://we.tl/t-yZUuB008Dz
(link expires in 7 days, please test it again using this build)

For everyone else:
It will be fixed in 1.4, I'm so sorry about this.

Hi,

Sorry, I meant to reply to this. No need to apologise - the software is free, so it's not like we're paying for the up keep of it.

I'm happy enough keeping on the earlier version until a new version is released.

Thanks

Hi,

Looking to update to the latest version - was this issue corrected in the download option available from the main site?

No, the one you find in the download page of the website is still the old one, we didn't perform any other upgrades compared to last time, but you can use the 1.3.1 development snapshot build from February 15th 2023 I sent you last time which addressed the error.
If you want I can re-upload it, no biggie.
That's because February 15th 2023 was the very last time we worked on 1.3.1 before forking to 1.4.0

If you mean if it's fixed in 1.4.0, instead, of course it is!
But... 1.4.0 ain't public yet as it went through some major redevelopment work and there are lots of new features we tested since September 18th 2023, when the first non public 1.4.0 development snapshot was created.
The "latest and greatest" development snapshot is currently the one from January 16th 2024 called RC92 (i.e Release Candidate 92) which also includes some pretty neat optimizations on the DB operations done by Grandmaster, BUT it's still not ready to become public and I'll have to create a new build as Grandmaster has pushed some more fixes and improvements.

But yeah, 1.3.1 development snapshot from February 15th 2023 has it fixed and you can use it, while for everyone else, when you upgrade to 1.4.0 (when it will be released) it will also be fixed