[FFmpeg-devel] [PATCH]lavf/spdifenc: Automatically insert truehd_core bitstream filter

[Carl Eugen Hoyos]

2019-02-13 0:47 GMT+01:00, Hendrik Leppkes <h.leppkes at gmail.com>:
> On Tue, Feb 12, 2019 at 12:54 PM Carl Eugen Hoyos <ceffmpeg at gmail.com>
> wrote:
>>
>> 2019-02-12 12:37 GMT+01:00, Hendrik Leppkes <h.leppkes at gmail.com>:
>> > On Tue, Feb 12, 2019 at 12:28 PM Carl Eugen Hoyos <ceffmpeg at gmail.com>
>> > wrote:
>> >>
>> >> Hi!
>> >>
>> >> Attached patch intends to fix ticket #7731.
>> >
>> > This is not a fix. The vast majority of TrueHD Atmos tracks work just
>> > fine with the current limitations, and would needlessly drop the Atmos
>> > information for every stream.
>>
>> Is it possible to detect if the Atmos core has to be dropped?
>
> Not beforehand, since the size of future frames is of course unknown,
> and there are no indications in the bitstream.
> One could consider starting to drop Atmos data after it happened once,
> but it'll probably still glitch out audio at that point.
>
> Ideally the truehd spdif muxer should be revised to support a more
> flexible buffering model, but its a tad bit complicated with the way
> the spdif muxer is setup, and I've only recently learned myself how
> its presumably supposed to be done, since the specifications are not
> openly available.

I did a few experiments before reading your mail:
If I use a burst rate of significantly less than 2000 bytes
audio gets broken with my receiver.
Can you confirm that in any way?
Otoh, it does not seem to help to insert memset(0)
between frames if the burstrate is too low.
("burstrate": gap between beginnings of thd frames)

It is not necessary to put 12 frames in both half-MAT frames,
15 and 9 work fine here.

My receiver always fails / produces hickups if the thd stream
contains atmos data: Are you sure it is supposed to work?
Can you already provide a test stream for the audio stream
from the ticket?

Carl Eugen