Page 2 of 3

Re: v1.3.0 vs v1.3.1 AV Decoder H264

Posted: Fri Jan 26, 2024 10:07 pm
by 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! :D

Re: v1.3.0 vs v1.3.1 AV Decoder H264

Posted: Wed Feb 14, 2024 8:35 am
by 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!

Re: v1.3.0 vs v1.3.1 AV Decoder H264

Posted: Wed Feb 14, 2024 9:49 am
by emcodem
@FranceBB will most likely be interested

Re: v1.3.0 vs v1.3.1 AV Decoder H264

Posted: Wed Feb 14, 2024 5:43 pm
by 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.

Re: v1.3.0 vs v1.3.1 AV Decoder H264

Posted: Mon Feb 19, 2024 6:02 pm
by 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

Re: v1.3.0 vs v1.3.1 AV Decoder H264

Posted: Mon Feb 26, 2024 3:03 pm
by 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. ;)

Re: v1.3.0 vs v1.3.1 AV Decoder H264

Posted: Mon Feb 26, 2024 4:09 pm
by 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... :mrgreen:

Re: v1.3.0 vs v1.3.1 AV Decoder H264

Posted: Tue Feb 27, 2024 8:28 am
by 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.
emcodem wrote: Mon Feb 26, 2024 4:09 pm do not use A/V decoder in the workflow
and not going through Avisynth? Never! :twisted:

Re: v1.3.0 vs v1.3.1 AV Decoder H264

Posted: Tue Feb 27, 2024 12:07 pm
by 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.. ((

Re: v1.3.0 vs v1.3.1 AV Decoder H264

Posted: Tue Feb 27, 2024 3:58 pm
by emcodem
baev12 wrote: Tue Feb 27, 2024 12:07 pm 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