<html><head></head><body>Hi,<br><br>The problem is, you can't always give them both. In many cases, the "expected" meta is some kind of codec-specific parameter that might not be extracted by the demuxer/packetizer. So idiots will keep complaining about mismatch no matter what.<br><br>And then you have those who'll complain that the decoded and encoded values don't match.<br><br><div class="gmail_quote">Le 27 janvier 2020 17:07:35 GMT+02: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 27/01/2020 à 15:54, Rémi Denis-Courmont a écrit :<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;">Hi,<br><br>That won't change anything w.r.t. to id10t errors. Decoded parameters will still be confusing, until/unless they are removed completely (and I'd rather close bugs as invalid than conceal some meta).<br><br></blockquote><br>And then re-implement everything when people complain they have no more<br>info.. We already have people complaining about missing info in the api.<br><br>Someone decided to create inconsistency by showing aout value for audio<br>& original codec for video for some unknown reason.<br><br>That's always the same story: people are looking up for the values that<br>$toolname shows. Just give them both, they'll match with the one they<br>expect.<br></pre></blockquote></div><br>-- <br>Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.</body></html>