<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<p>On Monday 23 May 2016 17:45:27 Filip Roséen wrote:</p>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<p>Attached is a patch that circumvents any potential issue by giving DecoderDispatchBlock a new argument named <code>b_do_cc</code> which simply toggles any potential invocation of <code>DecoderGetCc</code> on/off.</p>
</blockquote>
<p>So the goal was to simplify, and it ends up making things more intricate…</p>
</blockquote>
<p>That was my fear, hence the wording in a previous message (stating that it might not be worth-while “simplifying” the implementation if it turns out that such “simplification” adds complexity).</p>
<p>If it is somehow safe to assume that <code>p_packetizer->pf_get_cc</code> is always NULL for packetizers that deals with audio, or that it is actually safe having such callback invoked (for audio); then the patch in the below linked message applies:</p>
<ul>
<li>https://mailman.videolan.org/pipermail/vlc-devel/2016-May/107840.html</li>
</ul>
<p>Since I am unable to answer this question on my own, any help on the matter is appreciated.</p>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<p>Please, no. Do it properly, or don´t do it.</p>
</blockquote>
<p>I whole-heartedly agree, thanks.</p>
<p>/F</p>