<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<meta http-equiv="Content-Style-Type" content="text/css" />
<meta name="generator" content="pandoc" />
<title></title>
<style type="text/css">code{white-space: pre;}</style>
</head>
<body>
<p>Hi Thomas,</p>
<p>On 2016-11-04 17:46, Thomas Guillem wrote:</p>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;color:#500050">
<pre><code> 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).</code></pre>
</blockquote>
<p><em>“they should use the same fourcc”</em> 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.</p>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;color:#500050">
<pre><code> 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.</code></pre>
</blockquote>
<p>I believe the above is the way to go, and honestly I think it would make sense to restructure the contents of <code>struct es_format_t</code>.</p>
<p>If there is one audio format that requires extra information inside <code>audio_format_t</code>, there will probably be others (maybe not now, but hey.. better safe than sorry, and prepare for the future).</p>
<hr style="height:1px;margin-bottom:20px;background-color:#ddd;color:#ddd" />
<h3 id="black-eyed-peas---union"><a href="https://www.youtube.com/watch?v=rT_-Ln7eWpw">Black Eyed Peas - Union</a></h3>
<p>Moving <code>es_format_t::i_profile</code>, and perhaps <code>es_format_t::i_level</code> (plus other relevant <em>data-members</em>), inside both <code>video_format_t</code> and <code>audio_format_t</code>, while also putting <code>es_format_t::{video,audio,subs}</code> inside a <code>union</code> would, in my opinion, be a clean interface that would solve this, and other, problems.</p>
<p>Currently it is somewhat confusing that both <code>es_format_t::audio</code>, <code>es_format_t::video</code>, and <code>es_format_t::subs</code>, can be “active”, even though <code>es_format_t::i_cat</code> states that only one should be used.</p>
<p>The common members of <code>audio_format_t</code>, <code>video_format_t</code>, <code>subs_format_t</code> could be put in a structure shared by both, in order to avoid <em>code-duplication</em>.</p>
</body>
</html>