DNX120 indexing is broken unless -thread_type slice is specified in FFMpeg

[FranceBB]

Hi there, DNX120 indexing is broken in:

• LWLibavVideoSource
• FFVideoSource
• DirectShowSource (LAV)
• FFMpeg
• Davinci Resolve

The following players also fail to decode it properly:

• MPV
• MPC-HC (LAV)
• PotPlayer

The following software decode it correctly:

• AVID Media Composer
• AVID Media Director
• Adobe Premiere
• EVS Hardware Playout Ports

Here's the mediainfo:

This is how it's indexed:

And this is how it should be instead:

How to reproduce:

FFVideoSource("Z:\20210429WiganvHullFCX_C921h25m29s09.mxf")

and also

FFVideoSource("Z:\20210429WiganvHullFCX_C921h25m29s09.mxf", threads=1)

The same happens with

LWLibavVideoSource("Z:\20210429WiganvHullFCX_C921h25m29s09.mxf")

and

LWLibavVideoSource("Z:\20210429WiganvHullFCX_C921h25m29s09.mxf", threads=1)

and the very same thing happens with:

ffplay -i "/home/FranceBB/Downloads/20210429WiganvHullFCX_C921h25m29s09.mxf"

however the decoding is fixed if -thread_type slice is specified:

ffplay -i "/home/FranceBB/Downloads/20210429WiganvHullFCX_C921h25m29s09.mxf" -thread_type slice

Unfortunately, I cannot share the footage of the game (for obvious reasons, it's a copyrighted event), however I asked them to send me a non-sensitive content and they put a blue cloth on the camera and recorded a sample... I know it kind of sucks as a sample, but here we go:

Sample - https://we.tl/t-SvCQRPGikp

Please also notice that I've raised the issue in FFMpeg: https://trac.ffmpeg.org/ticket/9255 And on Doom9: https://forum.doom9.org/showthread.php?p=1943307

[FranceBB]

There are also some DNX120 that play ok from some cameras and some other DNX120 that have green fields (unless we use the -thread_type slice flag) from some totally different cameras.

Going deeper in the analysis, those from the camera brands that are decoded correctly have:

[dnxhd @ 000001f4fd9d7c80] interlaced 3, cur field 1

those from the camera brands that are decoded incorrectly (unless -thread_type slice is specified) have:

[dnxhd @ 0000013fc0277c80] interlaced 2, cur field 0

the values are bits in the frame header, what i don't get is why we have the entries 2 times

[dnxhd @ 0000025bc07c7c80] interlaced 2, cur field 0 [dnxhd @ 0000025bc07c7c80] Profile cid 1242. [dnxhd @ 0000025bc07c7c80] 1920x1080, 4:2:2 8 bits, MBAFF=0 ACT=0 [dnxhd @ 0000025bc07c7c80] interlaced 2, cur field 0 [dnxhd @ 0000025bc07c7c80] 1920x1080, 4:2:2 8 bits, MBAFF=0 ACT=0

in the cameras that produce the version with the decoding issue, it's 2 times "interlaced 2, cur field 0" while in the camera brands that produce a file correctly decoded without any flag, only the first entry is the same while the second entry is [dnxhd @ 00000222415e7c80] interlaced 3, cur field 1

[dwbuiten]

To me this sounds purely like an FFmpeg bug, and totally irrelevant to FFMS2's issue tracker?

[FranceBB]

Well, actually I don't know whether they're gonna fix it or not, so here is the thing: I don't know how ffms2 calls the ffmpeg decoders, however setting the threads to 1 in ffmpeg solves the decoding issue, while it doesn't in ffms2, therefore I was wondering whether it would be possible to actually implement some logic in ffms2 to detect if it's a DNX120 interlaced file and use the option "-thread_type slice" instead of frame + slice upon decoding in order to fix the indexing.... you know what I mean?

[FranceBB]

ASD-G fixed it in LSMASH (LWLibavVideoSource). A similar workaround should be applied in ffms2 https://github.com/HomeOfAviSynthPlusEvolution/L-SMASH-Works/commit/e5bb1ecb71f0edb5b7632b1013faaed77277e2b4

[myrsloik]

Sure looks like a real FFmpeg bug. I'll wait for upstream to fix it.