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.lepp...@gmail.com> wrote: > On Thu, Feb 9, 2023 at 5:42 AM Marth64 <mart...@proxyid.net> wrote: > > > > Signed-off-by: Marth64 <mart...@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@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
