[FFmpeg-devel] [PATCH] ffprobe/eac3/mlp/dca: add detection of spatial audio extensions

[Marth64]

Hi,

Thank you for your time and thoughts. Some of this I had wondered about the
same.

Re: Hendrik, Using profile >
This was an original intention of mine but I changed course. I'm happy to
do it, but felt too unsure for a first pass.
My reasoning being that I'm not sure if the presence of extension metadata
itself qualifies as a discrete profile. For DCA in particular, I was
worried since DCA already expands to profiles (ES, XLL, etc.). I did not
want to clutter those distinctions with a "somewhat profile of a profile,
based on an educated guess without the reference docs" and break any
existing integrations. Likewise, EAC3 and TrueHD didn't have profiles, so
it felt tacked on for this case. So I settled with "extension" as the
marker. That said, I wasn't too thrilled about adding to AVCodecContext
either. I discovered and considered priv_data but then realized that this
is a pattern across 3 codecs, maybe more in the future. So definitely open
to guidance here. Profile is probably the next best bet.

I had gone down the frame-level inspection road at some point, but came to
a similar conclusion as you, it makes this less useful as a feature.

I am open to other's interpretation. Will ponder this a little more.

Re: Michael, show_bits_long >
Will fix. I am trying to procure another IMAX DTS material to test the
syncword better, so will push any of those changes together in the next 2
days.

Thank you!



On Thu, Feb 9, 2023 at 2:12 PM Hendrik Leppkes <h.leppkes at gmail.com> wrote:

> On Thu, Feb 9, 2023 at 5:42 AM Marth64 <marth64 at proxyid.net> wrote:
> >
> > Signed-off-by: Marth64 <marth64 at proxyid.net>
> > ---
> > Adds detection of spatial/object-based audio extensions in E-AC-3,
> > TrueHD, and DCA XLL (DTS). This includes Atmos, DTS:X, and IMAX formats.
> > Please let me know what I could improve, I'm learning still.
> > Thank you.
> >
>
> The detection itself seems fine to me, however we should talk about
> how the presence is communicated back to the user.
>
> A new flag in AVCodecContext goes against a variety of designs we try
> to avoid - namely having codec-specific things in a global struct, as
> well as having only one value, rather then per-frame values.
>
> So options that present themself to me:
> (a) Use "profile". At least for DTS that would fit quite nicely, as it
> already has profiles, and it seems like a logical extension. TrueHD
> and eac3 do not have profiles, but it might still be sensible to put
> it there. The advantage here is that it also automatically is conveyed
> in AVCodecParameters after avformat opens a stream, so the information
> is available early and lets players decide how to handle the stream.
> (b) Use per-frame side data. The early-availability advantage is not
> present here, so its not my favorite. side-data could be used in the
> future to transport the actual object metadata, if needed.
>
> So from where I'm standing we should maybe define profiles to use for
> these. In the past profiles were at least suggested for TrueHD Atmos
> before, but there were some objections, so maybe a good time to
> revisit and see where we go from here.
>
> - Hendrik
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".
>