spdifenc: Unusual frame timing (TrueHD)

[Mitzsch01]

Summary of the bug:
When playing back a file containing a Dolby TrueHD track with passthrough enabled and you skip forward or backward audio is lost. (I tried it with mpv) In the console, it shows the following message:

[ffmpeg] spdif: Unusual frame timing: 40872 => 18920, 40 samples/frame is not implemented. Update your FFmpeg version to the newest one from Git. If the problem still occurs, it means that your file has a feature that has not been implemented.
[ffmpeg] spdif: If you want to help, upload a sample of this file to https://streams.videolan.org/upload/ and contact the ffmpeg-devel mailing list. (ffmpeg-devel@ffmpeg.org)

It also occurs when you play a file that comes from a master and needed seamless branching. Whenever it hits the sequence that was merged, audio is lost and it shows the same message above.

This behavior is present after the commits for this issue ​https://trac.ffmpeg.org/ticket/7731 were merged. The implementation before that worked fine in this regard.

How to reproduce:
Play any TrueHD file with passthrough enabled and skip forward or backward in the file. In most cases, the audio will be lost and you see the message spdif: Unusual frame timing:. You may recover from this by skipping further.

mpv 0.34.0-116-gd92cf77be5 Copyright © 2000-2021 mpv/MPlayer/mplayer2 projects
 built on Sat Dec 25 17:26:05 CET 2021
FFmpeg library versions:
   libavutil       57.13.100
   libavcodec      59.15.101
   libavformat     59.10.100
   libswscale      6.1.102
   libavfilter     8.21.100
   libswresample   4.0.100
FFmpeg version: N-105030-g0c8741f819

Samples:
TrueHD files from ​https://kodi.wiki/view/Samples

[Mitzsch01]

The guys over at xbmc/Kodi just recently patched their TrueHD implementation and it works flawlessly. Maybe their code could be used as an inspiration? (if allowed) :)
​https://github.com/xbmc/xbmc/pull/20339 | ​https://github.com/xbmc/xbmc/pull/20595

[Balling]

Implementation of MAT in Lavfilters is better than in Kodi.

[Christian Holzer]

I can confirm this behaviour.
Skipping fw/bw causes the audio to drop out, multiple skips are required to get the audio back.

[Carl Eugen Hoyos]

This has still little similarities with a valid ticket...

[Mitzsch01]

What is needed to make it a valid ticket? Do you need a sample file? (Any truehd sample from this page should show the problem => ​https://kodi.wiki/view/Samples)

[acedogblast]

I have a short semi-working fix. I was looking through the kodi code that Mitzsch01 referenced and found a small difference. On line 475 on spdifenc.c where there is a comment about the sanity check where MAT_FRAME_SIZE is divided by 2. In the kodi code that same code used MAT_FRAME_SIZE multiplied by 2 instead. I have built mpv with this modified change and it mostly fixed the dropouts when playing normally but will still drop audio on seeking. Overall it is more stable with less dropouts. Tested with the opening race scene on Cars 3 which was dropping a lot with the atoms track.

[Balling]

have built mpv with this modified change and it mostly fixed the dropouts when playing normally but will still drop audio on seeking

Please give git diff and send a patch. Also, please verify that Lavfilters (​https://codecguide.com/download_kl.htm) HAVE NO dropouts at all on Cars 3. THANKS!!

[acedogblast]

Change spdifenc.c to reduse dropouts.

[acedogblast]

Replying to Balling:

have built mpv with this modified change and it mostly fixed the dropouts when playing normally but will still drop audio on seeking

Please give git diff and send a patch. Also, please verify that Lavfilters (​https://codecguide.com/download_kl.htm) HAVE NO dropouts at all on Cars 3. THANKS!!

This patch should be tested more to ensure that it is a net improvement to the dropout issue.

[Balling]

Can you compare to Lavfilters implementation? It should have no dropouts. ​https://github.com/search?q=repo%3ANevcairiel%2FLAVFilters+MAT+&type=commits

[acedogblast]

Replying to Balling:

Can you compare to Lavfilters implementation? It should have no dropouts. ​https://github.com/search?q=repo%3ANevcairiel%2FLAVFilters+MAT+&type=commits

Lavfilters is made for Windows and is built on top of ffmpeg's avformat but does has it's own demuxer for trueHD. Since I use Linux it does not natively run on my setup but I will be looking over their code.

[Mitzsch01]

Over at the plex forums, we also discussed this problem. One of the plex devs has made patch that works reasonably well, minor problems left. Have a look here => ​https://forums.plex.tv/t/dolby-truehd-passthrough-modified-mpv-build/802742/78

[acedogblast]

Replying to Mitzsch01:

Over at the plex forums, we also discussed this problem. One of the plex devs has made patch that works reasonably well, minor problems left. Have a look here => ​https://forums.plex.tv/t/dolby-truehd-passthrough-modified-mpv-build/802742/78

That patch works rather well. Seeking around works well now. Still one dropout on Cars 3.

[Balling]

Still one dropout on Cars 3.

What if you combine two patches?

[Balling]

I also had some time to test an upstream ffmpeg/mpv version with my LG TV, that luckily also supports Dolby TrueHD and to my surprise, it did not showed the issue. (Would also explain why you @gbooker02 are not seeing this one with your setup) Skipping inside the file did not broke audio playback like seen with my AVR. Also, a movie with seamless branching worked almost (you could hear some crackling when hitting the spot where those files were merged) fine. Whereas it would immediately break with my AVR.

But LG C9 is the reference implementation and you are supposed to remove one of the minor duplicates on the seamless branch point. See: ​https://github.com/domyd/mlp and I quote:

It's important to not delete the frame that contains the major sync, but to delete the minor frame duplicate at the end of a stream. Also, the frames don't actually match exactly, so you'll need to use some tolerance when comparing them.

Cars 3 has seamless branching. You need to rip it correctly using that tool.

[Mitzsch01]

Replying to Balling:

Still one dropout on Cars 3.

What if you combine two patches?

The patch found in the Plex forums already has the "*2" patch applied.

[Mitzsch01]

But LG C9 is the reference implementation and you are supposed to remove one of the minor duplicates on the seamless branch point. See: ​https://github.com/domyd/mlp and I quote:

Cars 3 has seamless branching. You need to rip it correctly using that tool.

Good point. The movie I used for testing (Baywatch) was "created" with makeMKV version 1.14.3 which did not include the better TrueHD demuxer. I will try to rip it again with the newest version. The "perfect" TrueHD demuxer was added to makeMKV in version 1.15.4 as written in the linked GitHub repo. Maybe then my issues will vanish.

[Balling]

Generally when I encounter this glitch, I can seek back 10 seconds and replay the same section without issue, which was still the case here. Because I was uncertain if I heard an error or a false positive due to the raucous sound effects of the scene, I replayed the scene 15-20 times in quick succession and was able to get the exact same glitch to happen! I included a live recording of what that presents as.

Very interesting. 9 hours may mean this is drop frame timecode issue. Hmmm... You see drop frame timecode is used in TrueHD. Yet, DF is not 30/1.001, it is only 29.97, that means it still accumulates 1 frame every 9 hours 15 minutes.

[Balling]

Looks related: ​https://patchwork.ffmpeg.org/project/ffmpeg/patch/20200412195626.9090-1-anssi.hannula@iki.fi/

that replaced MAT_FRAME_SIZE / 2 with MAT_PKT_OFFSET * 50

[Vern Dias]

Are you ever going to address this issue?

Multiple people are seeing this. For example, on AVS forum recently

MidnightWatcher said:
Well, I tried audio-exclusive=yes last night but Atmos tracks still cut out while seeking during playback. I thought maybe Windows had "Allow applications to take exclusive control of this device" disabled but it's enabled. I also tried ao=wasapi but still the same issues on my end.

The issue has been addressed in LAVFilters, why is it still an issue in ffmpeg?

I opened a ticket with MPV, they say they cannot fix an issue caused by an issue in ffmpeg.

The response from MPV follows:

"...looked into it a bit more to be a bit more helpful, here's the related ffmpeg ticket where you could request for the linked patch to be merged. It doesn't seem like the patch is a complete fix, but it doesn't appear to regress anything so it should still be fine. I don't think mpv can do anything about this, certainly not another daily build just for one user.'

Could you please consider merging the patch into the daily releases so others can take advantage of the existing workaround / fix.

[lamoon]

I've been following this issue for a few months. Tracking it down from all the different forums it comes up in, is like a part-time job in itself.

Like Vern, I also want to know if anyone is going to look into merging the fix for this issue? There's clearly quite a few people out there confirming this is an actual issue, and that this fix does work.