[vlc-devel] [RFC] DTS-HD and audio_format_t

[Filip Roséen]

Hi Thomas,

On 2016-11-04 17:46, Thomas Guillem wrote:

> Hello,
> 
> In order to play DTS-HD samples via HDMI I need a way to differentiate
> DTS from DTS-HD. Theoretically, they should use the same fourcc, since
> DTS-HD is just an extension of the DTS codec (we can play a DTS-HD
> sample as DTS if we skip the substream, and use only the core).

*"they should use the same fourcc"* is very much relevant to what I
believe is the best way to handle it. Though, needless to say, I am
certainly not the most qualified to respond to your question given my
fairly short involvement with the VLC stack. 

> But some aout like wasapi or audiotrack need to know if the format is
> DTS or DTS-HD. For example, in wasapi, if the
> KSDATAFORMAT_SUBTYPE_IEC61937_DTS_HD format initialization fails, we can
> fallback to KSDATAFORMAT_SUBTYPE_IEC61937_DTS and modify to
> audio_format_t to tell the spdif converter that we only want to send the
> DTS CORE.
> 
> So my question is: how to differentiate DTS from DTS-HD in
> audio_format_t.
> 
>  - Add a DTSHD fourcc: VLC_FOURCC('d','t','s','h'). This is kind of
>  wrong since this should be the same codec but then we don't need to
>  modify audio_format_t.
> 
>  - Add a new int i_profile in audio_format_t ? This is the correct way
>  but this will be used only for this codec.

I believe the above is the way to go, and honestly I think it would
make sense to restructure the contents of `struct es_format_t`.

If there is one audio format that requires extra information inside
`audio_format_t`, there will probably be others (maybe not now, but
hey.. better safe than sorry, and prepare for the future).

----------------------------------------------------------------------

[Black Eyed Peas - Union](https://www.youtube.com/watch?v=rT_-Ln7eWpw)
----------------------------------------------------------------------

Moving `es_format_t::i_profile`, and perhaps `es_format_t::i_level`
(plus other relevant *data-members*), inside both `video_format_t` and
`audio_format_t`, while also putting `es_format_t::{video,audio,subs}`
inside a `union` would, in my opinion, be a clean interface that would
solve this, and other, problems.

Currently it is somewhat confusing that both `es_format_t::audio`,
`es_format_t::video`, and `es_format_t::subs`, can be "active", even
though `es_format_t::i_cat` states that only one should be used.

The common members of `audio_format_t`, `video_format_t`,
`subs_format_t` could be put in a structure shared by both, in order
to avoid *code-duplication*.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20161104/6acb5295/attachment.html>