v1.3.0 vs v1.3.1 AV Decoder H264

[FranceBB]

Actually... in terms of upgrades, a very nice surprise from Grandmaster might come much sooner than you think, Graham!
I can't say anything more otherwise it's no longer a surprise, but...

Stay tuned!

[baev12]

Hi,

This is seemed fixed for h264 in 1.4, but unfortunatly if we feed our workflow with MXF XDCAM HD422 we get dropped frames again (with full decode also)... 1.3.0.2 is still our choice but we wait to use great Hosts group farming and Improved processing speed features that came with 1.4 version.

Thank you!

[emcodem]

@FranceBB will most likely be interested

[FranceBB]

Yes I'm very interested. ehehehehe
We're also XDCAM based and I can't see dropped frames while indexing, however I'd like to test one of your files and see if I can reproduce.
If I can, then it's almost definitely yet another issue with the indexer and I'll report it to StvG.

[baev12]

Hi,

I've got some source file from YT and prepared files which show the behavour on 0:15 and 2:10
Workflow consist of "A/V media" -> "Safe color" -> "Loudness" -> "XDCAM-HD"
https://1drv.ms/f/s!AiCi1F3i5cyxg3Ok1mT ... m?e=jyDjO1

[FranceBB]

I looked at the original file and it looks like a very normal OpenGOP XDCAM-50 file.
I ran it through the decoder and it detected the following issues/abnormalities:

- Found at least one B frame without second reference in a non closed GOP

At this point, all that was left was to run it through different indexers and see whether there was an issue or not.
Indexing it using LWLibavVideoSource() shows three different fields at 374, 375, 376, namely 00:00:14.96, 00:00:15:00, 00:00:15:04 and the same goes for FFVideoSource().
Now, in FFAStrans, the A/V Decoder uses the following command settings for your file to be precise:

Code: Select all

FFVideoSource("A:\MEDIA\temp\test01-190224-01source.MXF", fpsnum=25 , fpsden=1, seekmode=1)

This was tested with ffms2 3.1.0.0 1357+36 1c0dcfa (1393) from January 6th, 2024.
FFAStrans 1.4.0.4 is shipping with that very same version.
I decided to make a comparison between the original source and your encoded file hoping to see duplicated frames.
Stacking them horizontally shows movement in both clips at 374, 375, 376

Code: Select all

source=LWLibavVideoSource("A:\MEDIA\temp\test01-190224-01source.MXF")
encoded=LWLibavVideoSource("A:\MEDIA\temp\test01-190224-01result.mxf")

StackHorizontal(source, encoded)

however by going back and forth this way I could actually manage to find a repeated frame: 401.
Frame 401 at 00:00:16:04
I've seen these kind of errors before in indexers, however while ffms2 is generally very fragile (and repeats the previous frame whenever it finds some issues), libav tends to cope better, so I repeated the test with:

Code: Select all

LWLibavVideoSource("A:\MEDIA\temp\test01-190224-01source.MXF", fpsnum=25, fpsden=1)

and it didn't show the issue.
Unfortunately I don't have a solution right now 'cause this needs to be fixed by Steve, so I reported everything to him and I'm now waiting for him to reply. Thank you for reporting this, by the way, it really helps whenever issues are discovered in indexers and it's something I'm very passionate about.
I'll let you know as soon as Steve replies.

[emcodem]

Code: Select all

 I don't have a solution right now

There are many workarounds however.. e.g. work with closed GOP, do not use A/V decoder in the workflow etc... etc...

[FranceBB]

A small update: Steve acknowledged the bug and will look at this.
In the meantime, the new release candidate by Myrsloyk is also affected (albeit in a slightly different way).

I'll keep you posted.

do not use A/V decoder in the workflow

and not going through Avisynth? Never!

[baev12]

Hi!

Thank you for your attention and for your helpful software. We are waiting for a solution of course! )
"do not use A/V decoder" is not our way though - we need "Safe color" -> "Loudness" stuff.. ((

[emcodem]

we need "Safe color" -> "Loudness" stuff..

Of course. So the loudness is a pure ffmpeg action anyway but using the limiter in ffmpeg instead of avisynth requires some additional processors and smartness in the workflow. I can come up with an example for you but as i have never used limiter filter in ffmpeg it would require some serious work to ensure that what i did really works as expected.

The most obvious solution would be to just change the affected ffms2.dll by the one from the last working ffastrans version, i don't think there are were changes in ffastrans that prevent this but @FranceBB might know better