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

[Hendrik Leppkes]

On Wed, Feb 13, 2019 at 2:57 AM Carl Eugen Hoyos <ceffmpeg at gmail.com> wrote:
>
> 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?

With every hardware? Who knows. My receiver does not support Atmos
either and it plays streams that exceed the 2560 size just fine with
correct muxing into MAT frames - although I haven't tested that one in
the ticket specifically I don't think, and I'm not near that receiver
until next week.

> Can you already provide a test stream for the audio stream
> from the ticket?
>

Sure, why not, although I have no idea how one would play this, since
you would need to make sure full MAT frames are always read and output
as one (ie. every 61440 bytes), and unfortunately our raw PCM demuxer
does not support specifying a wanted packet size, oh well.
https://files.1f0.de/tmp/truehd_11mbit_bug.spdif

Otherwise it should fit the typical TrueHD bitstreaming criteria, ie.
192kHz 8ch 16-bit "PCM", 61440 bytes frame size.

- Hendrik