<html><head></head><body>It is not I who used block_t for key events or other strongly typed queue elements. So don't ask me why it's done.<br>
<br>
And I already pointed out multiple differences between the proposed ancillary field and the other meta data fields. So the assertion that there are "absolutely" none is falsehood and this mail is "absolutely" wrong.<br><br><div class="gmail_quote">Le 26 juin 2018 23:25:50 GMT+03:00, Francois Cartegnie <fcvlcdev@free.fr> a écrit :<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre class="k9mail">Le 26/06/2018 à 19:58, Rémi Denis-Courmont a écrit :<br><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"> And this plain patently false. The corrupt flag used in input stream and <br> discontinuity flag used in audio output. Just like I already wrote.<br></blockquote><br><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"> It is. block_t has been used for input stream for at least 15 years. It's even <br> (ab)used for key events nowadays (also not me).<br></blockquote><br>How come key events (from demux?) be related to ES sample sidedata ?<br>That does not fit.<br><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #8ae234; padding-left: 1ex;"> Just check all the places that block_t is used for. It's far from only<br> ES coded data.<br></blockquote></blockquote></blockquote><br><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"> Indeed. block_t is a blob of binary data, with a few pieces of immediate <br> meta-data. This patch misuses it as an associative array of blobs.<br></blockquote><br>There's absolutely not difference from BLOCK_TYPE or BLOCK_*_FIELD<br>flags. Every flag enumerates a value where a field storage would make<br>more sense, we can't extend anything without running out of flags.<br>Sidedata is sidedata, 1 byte or 8 bytes timestamp. We just need storage.<br><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;"> Also, noone said it was ES coded data only, but also input_stream data.<br> And that's good because we need ancillary in both ES and input_stream data.<br></blockquote> <br> Even leaving aside design/taste considerations, input streams do not use <br> block_t internally and do not treat block boundaries as meaningful, so there <br> are no ways that this will work.<br></blockquote><br>Just like some flags or timestamps values are only meaningful between<br>some modules, data lifetime being limited by some known boundaries is<br>expected and wanted (decoder must handle or forward, otherwise be<br>passively dropped).<br></pre></blockquote></div><br>
-- <br>
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.</body></html>