2019-02-13 8:10 GMT+01:00, Hendrik Leppkes <h.lepp...@gmail.com>:
> On Wed, Feb 13, 2019 at 2:57 AM Carl Eugen Hoyos <ceffm...@gmail.com> wrote:
>>
>> 2019-02-13 0:47 GMT+01:00, Hendrik Leppkes <h.lepp...@gmail.com>:
>> > On Tue, Feb 12, 2019 at 12:54 PM Carl Eugen Hoyos <ceffm...@gmail.com>
>> > wrote:
>> >>
>> >> 2019-02-12 12:37 GMT+01:00, Hendrik Leppkes <h.lepp...@gmail.com>:
>> >> > On Tue, Feb 12, 2019 at 12:28 PM Carl Eugen Hoyos
>> >> > <ceffm...@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.spdifThis stream works with my receiver that does not support Atmon, my patch creates a bitexact output. Thank you, Carl Eugen _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
